AI-Powered IT Operations Management with Multi-Agent Systems

iberdrola · Energy · 2026 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise IT operations and service management

Iberdrola needed to reduce bottlenecks in ServiceNow change management and incident management by validating change requests, enriching incidents, and helping users select change models while preserving enterprise security, observability, compliance, and workflow integration.

Constraints:

• ServiceNow remains the operational system of record and primary input surface
• change management requires deterministic validation and mandatory-field checks
• incident enrichment should adapt to incident complexity instead of running every specialist every time
• agents need standardized access to internal tools and data without custom integration code for each source
• enterprise security requires identity, authorization, VPC isolation, and private connectivity
• production agent operations require infrastructure metrics and LLM-specific traces

Architecture

Iberdrola built three AgentCore-backed agentic workflows around ServiceNow: a deterministic change-validation pipeline, an adaptive incident-enrichment system, and a conversational change-model assistant. ServiceNow requests flow through a REST API to a MicroGateway that routes to use-case agents. Agents run as containerized LangGraph services on Amazon Bedrock AgentCore Runtime, with session memory, identity, MCP-style gateway tools, OpenTelemetry/CloudWatch observability, and Langfuse traces. The inference layer uses LiteLLM to standardize access to Amazon Nova, Anthropic Claude, and other Bedrock models with Bedrock Guardrails. The data layer combines real-time operational access with ETL from ServiceNow into S3 and RDS with pgvector for semantic search.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  servicenow["servicenow"] --> microgateway["microgateway"]
  microgateway --> agentcore-runtime["agentcore-runtime"]
  agentcore-runtime --> agentcore-memory["agentcore-memory"]
  agentcore-runtime --> agentcore-gateway["agentcore-gateway"]
  agentcore-runtime --> agentcore-identity["agentcore-identity"]
  agentcore-runtime --> agentcore-observability["agentcore-observability"]
  agentcore-observability --> langfuse-observability["langfuse-observability"]
  agentcore-runtime --> litellm-inference-proxy["litellm-inference-proxy"]
  litellm-inference-proxy --> bedrock-guardrails["bedrock-guardrails"]
  agentcore-gateway --> data-layer["data-layer"]
  microgateway --> change-validation-workflow["change-validation-workflow"]
  change-validation-workflow --> rule-extractor["rule-extractor"]
  change-validation-workflow --> content-validator["content-validator"]
  change-validation-workflow --> aim-model-analyst["aim-model-analyst"]
  aim-model-analyst --> data-layer
  change-validation-workflow --> phase-transition["phase-transition"]
  microgateway --> smart-solver-agent["smart-solver-agent"]
  smart-solver-agent --> tag-classifier["tag-classifier"]
  smart-solver-agent --> incident-similarity-agent["incident-similarity-agent"]
  incident-similarity-agent --> data-layer
  smart-solver-agent --> incident-associator["incident-associator"]
  smart-solver-agent --> change-associator["change-associator"]
  smart-solver-agent --> context-retriever["context-retriever"]
  context-retriever --> data-layer
  microgateway --> conversational-change-assistant["conversational-change-assistant"]
  conversational-change-assistant --> servicenow

Components

Data flow

A user starts in ServiceNow. ServiceNow calls a REST API on the MicroGateway, which routes the request to the relevant agent use case. AgentCore Runtime executes containerized LangGraph agents, while AgentCore Identity handles authentication, AgentCore Memory preserves session state, and AgentCore Gateway exposes external tools through MCP-style interfaces. The agents call models through LiteLLM and Bedrock, use Bedrock Guardrails for output safety, and retrieve operational or analytical data from ServiceNow, S3, RDS, and pgvector-backed search. Telemetry flows to CloudWatch and Langfuse. Outputs return to ServiceNow as validation feedback, enriched incident context, or pre-filled change-model recommendations.

Why this architecture

Iberdrola separated agent resources, inference, and data so each layer could evolve independently while sharing platform services. AgentCore supplied managed runtime, memory, gateway, identity, and observability primitives so teams could focus on agent logic. LangGraph fit the deterministic change-validation flow because it supports graph structure, branching, and audit trails. The incident workflow used adaptive orchestration because simple tickets do not need every specialist agent. LiteLLM and Bedrock Guardrails abstracted model access and safety controls, while VPC deployment and OAuth-backed identity met enterprise security constraints.

• Vector-enhanced validation – Pgvector-enabled PostgreSQL supports semantic similarity searches, enabling the AIM Model Analyst agent to match change models b"

Models used: Amazon Nova · Anthropic Claude · Amazon Bedrock models · large language models · LangGraph agents · LiteLLM

Scale

• The system targets thousands of change requests and incident tickets.
  “thousands of change requests and incident tickets are managed, streamlining processes and enhancing productivity across departments.”article, stated
• Agent sessions can run for up to 8 hours for complex workflows.
  “Each agent session can run up to 8 hours for complex workflows.”article, stated
• AgentCore Gateway is described as scaling tool discovery from tens to hundreds of targets.
  “AgentCore Gateway automatically indexes tools and provides serverless semantic search, scaling from tens to hundreds of targets, totally managed.”article, stated
• The incident-management workflow uses five specialized agents.
  “Five specialized agents (Tag Classifier, Incident Similarity, Incident Associator, Change Associator, Context Retriever) are available”article, stated
• The change-validation workflow uses four specialized agents.
  “The workflow processes change requests through four specialized agents—Rule Extractor, Content Validator, AIM Model Analyst, and Phase Transition”article, stated
• The data layer includes ETL from ServiceNow into S3 and RDS with pgvector.
  “Raw ServiceNow data flows through ETL processes into Amazon Simple Storage Service (Amazon S3) storage, then into Amazon Relational Database Service (Amazon RDS) databases enhanced with pgvector exte”article, stated

Alternatives considered (roads not taken)

Custom integration code for every data source

Rejected because: AgentCore Gateway provides MCP-style standardized interfaces that agents can consume consistently, especially for ServiceNow endpoints.

Direct model-specific API calls inside each agent

Rejected because: LiteLLM provides a consistent model-access abstraction so agents can use multiple model variants through standardized API calls.

Keyword-only change-model matching

Rejected because: The AIM Model Analyst uses pgvector-enabled semantic similarity so technical descriptions can match appropriate change models beyond simple keywords.

Always run every incident enrichment agent

Rejected because: The Smart Solver Agent selectively invokes specialists based on missing context and value-add, so simple incidents can receive lighter processing.

Build and operate all agent infrastructure internally

Rejected because: The managed AgentCore runtime, memory, identity, gateway, and observability services reduce infrastructure complexity and custom development overhead.

Patterns

multi-agent-orchestration (architecture)

Iberdrola uses both sequential specialized agents for change validation and adaptive specialist selection for incident enrichment.

tool-use-orchestration (operations)

AgentCore Gateway exposes ServiceNow and external tools as standardized MCP-style interfaces for agents.

agent-memory (state)

AgentCore Memory stores session state, conversation history, and intermediate processing results for multi-step workflows.

model-routing (inference)

LiteLLM abstracts access to Amazon Nova, Anthropic Claude, Bedrock, and other model variants so agents can use standardized calls.

hybrid-search (retrieval)

The data layer combines real-time operational access, analytical datasets, ETL, RDS, and pgvector semantic search.

safety-policy-enforcement (safety)

Bedrock Guardrails provide model-output safety controls, while Identity and VPC deployment enforce enterprise access boundaries.

observability-tracing (operations)

AgentCore Observability, OpenTelemetry, CloudWatch, and Langfuse provide infrastructure and LLM-specific traces.

structured-output-contract (contracts)

The deterministic change-management workflow validates mandatory fields and formatted information before requests progress.

Tradeoffs

Use managed AgentCore primitives

Chose AgentCore Runtime, Memory, Gateway, Identity, and Observability over custom-built agent hosting, memory, tool gateway, identity, and monitoring infrastructure.

Rationale: Managed primitives reduce infrastructure complexity and let teams focus on agent logic while preserving enterprise-grade controls.

Choose deterministic workflow for change validation

Chose sequential LangGraph agents with identical validation steps over fully adaptive or free-form change validation.

Rationale: Change validation needs compliance-friendly consistency, mandatory-field checks, conditional branching, and audit trails.

Choose adaptive orchestration for incidents

Chose Smart Solver selective specialist engagement over a fixed full incident-enrichment pipeline for every ticket.

Rationale: Incident tickets vary in complexity, so adaptive routing saves resources while still allowing full contextual analysis when needed.

Add an inference abstraction

Chose LiteLLM proxy across Amazon Nova, Anthropic Claude, Bedrock, and other models over hard-coding agents to one provider or model API.

Rationale: The proxy supports model experimentation and consistent calls without modifying agent code for each model variant.

Use dual observability

Chose AgentCore/OpenTelemetry/CloudWatch plus self-hosted Langfuse over infrastructure logs alone.

Rationale: Infrastructure metrics and LLM-specific traces answer different production debugging questions.

Gotchas (what bit them)

The case study reports broad productivity gains without hard measured deltas.

Root cause: The AWS article is promotional and focuses on architecture rather than before/after metrics, error rates, or cost measurements.

Resolution: Treat the architecture as well-supported but keep outcome claims qualitative unless separately measured.

Adaptive incident orchestration can be harder to debug than deterministic flows.

Root cause: The Smart Solver dynamically decides which specialist agents to invoke based on incident content and missing context.

Resolution: The system pairs adaptive routing with explicit observability through AgentCore, CloudWatch, OpenTelemetry, and Langfuse traces.

Enterprise agents required significant identity and network isolation work.

Root cause: Agents needed to access internal resources, ServiceNow endpoints, and downstream tools while meeting enterprise security requirements.

Resolution: The architecture used VPC configuration, VPC endpoints, Entra ID integration, OAuth 2.0, and AgentCore Identity.

Managed platform speed comes with platform-dependency tradeoffs.

Root cause: The implementation relies heavily on AgentCore, Bedrock, AWS networking, CloudWatch, ECR, EKS, S3, and RDS.

Resolution: Open standards and framework-agnostic choices such as MCP, OpenTelemetry, LangGraph, LiteLLM, and Langfuse reduce but do not remove lock-in.

Evaluation and failure-handling details are under-specified.

Root cause: The source describes observability and architecture but not agent accuracy metrics, testing strategy, or model-failure handling.

Resolution: Downstream use should treat this as an architecture pattern case, not a validated performance case.

Evaluation

The source describes production monitoring rather than a full model-evaluation methodology: AgentCore Observability captures OpenTelemetry logs and metrics in CloudWatch, and a self-hosted Langfuse deployment on EKS provides spans and traces for LLM and agent behavior. The article does not report accuracy metrics or before/after error rates.

Metrics: AgentCore Runtime logs and metrics · OpenTelemetry telemetry · CloudWatch operational metrics · Langfuse spans and traces · agent session isolation · qualitative productivity and data-quality claims

Outcomes

• Iberdrola deployed three agentic IT-operations use cases: change validation, incident enrichment, and conversational change-model selection.
• The architecture manages thousands of change requests and incident tickets through ServiceNow-integrated agents.
• The article claims reduced bottlenecks, faster ticket resolution, and consistent data handling, but does not provide measured deltas.
• The implementation demonstrates reusable enterprise agent infrastructure with managed runtime, identity, memory, gateway, observability, VPC access, and model abstraction.
• The incident workflow can selectively engage five specialist agents, while the change workflow uses four sequential validation agents.

The source describes thousands of change requests and incident tickets, each agent session running up to 8 hours, five specialist incident agents, four change-validation agents, Gateway scaling from tens to hundreds of tool targets, and a data layer spanning ServiceNow ETL, S3, RDS, and pgvector.