Intelligent alarm management for power and utilities using Amazon Bedrock AgentCore

Power generation and transmission and distribution (T&D) operators work with multiple operational systems that don’t share a common interface, including distributed control systems (DCS), SCADA, process historians, computerized maintenance management systems (CMMS), and protection relays. Control rooms at generation plants and utility operations centers receive thousands of alarms per day across these systems. During system events, dozens of alarms can trigger within minutes; most are sympathetic cascade effects rather than independent faults. Identifying the root cause requires querying three to four separate applications, which typically takes 25–40 minutes.

Industry standards such as ISA-18.2, IEC 62682, and EEMUA Publication 191 define alarm management best practices, but the gap between the standard and operational reality remains wide. Traditional alarm management tools are rule-based and system-specific. They can’t correlate a sensor trend in the process historian with an overdue preventive maintenance task in the CMMS, an OEM technical bulletin in the document management system, and a similar past incident in the ticketing system.

In this post, we demonstrate how a large North American Utility is currently running a multi-agent AI architecture on Amazon Bedrock AgentCore to compress alarm triage from hours to minutes, avoiding the manual, multi-system investigation that operators perform dozens of times per shift. We will walk through the industry problem, the multi-agent design, and a reference implementation on GitHub that you can deploy into your own environment.

The alarm management challenge

The ISA-18.2 standard (Management of Alarm Systems for the Process Industries) and EEMUA Publication 191 define what good alarm management looks like. The gap between the standard and reality is wide, as detailed in the following table.

These numbers apply across both power generation control rooms and T&D operations centers. The alarm sources differ (DCS and PI Historian in a plant, SCADA and IEC 61850 IEDs in a substation), but the operator experience is the same: too many alarms, too little context, and no automated way to correlate across systems.

Why the problem persists

Operators investigating an alarm must manually query multiple siloed systems:

• Process historian (such as AVEVA PI) for sensor trends and rate-of-change analysis
• Computerized Maintenance Management System (CMMS) such as IBM Maximo or SAP PM for maintenance history, overdue preventive maintenance (PM), and failure patterns
• Document management for OEM alarm-response procedures, IEEE/IEC standards, and SOPs
• Ticketing and incident history for similar past events and their resolutions

Each system provides one piece of the picture. No single tool correlates a vibration trend with an overdue bearing replacement, an OEM technical bulletin, and three similar past failures that led to forced outages. During an alarm flood, this sequential investigation is impossible.

Solution overview

A single monolithic AI agent can’t effectively serve all four data domains. Process historian data requires time series analysis expertise. Maintenance records require understanding of CMMS work order lifecycles and reliability-centered maintenance (RCM). Equipment documentation requires Retrieval Augmented Generation (RAG) over technical manuals. Incident history requires SQL analytics over a structured ticketing schema.

A multi-agent pattern addresses this: specialized agents for each data domain, orchestrated by a supervisor agent that understands alarm management standards and synthesizes cross-domain findings into a single actionable report.

The following diagram illustrates the solution architecture.

Figure 1: Intelligent Alarm Management for Power and Utilities — Multi-agent triage on Amazon Bedrock AgentCore architecture diagram

The key components are as follows:

• Amazon Bedrock AgentCore Runtime hosts all agents and Model Context Protocol (MCP) tool servers as managed runtimes. Operators don’t need to provision network and compute orchestration infrastructure.
• Strands Agents SDK provides the Python agent framework with built-in tool use, reasoning traces, and streaming responses.
• MCP tool servers expose each backend through a standardized protocol. Adding a new data source (such as a SCADA historian, emissions monitoring system, or weather API) means deploying one new MCP server with no changes to existing agents.
• Amazon Bedrock Knowledge Bases with Amazon S3 Vectors provides RAG over equipment manuals, SOPs, OEM technical bulletins, alarm response runbooks, and historical incident reports. Source documents are uploaded to an Amazon Simple Storage Service (Amazon S3) bucket; the knowledge base then syncs that bucket on demand, chunks each document, generates embeddings with Amazon Titan Text Embeddings v2, and writes the vectors to S3 Vectors for similarity retrieval.
• Amazon Aurora PostgreSQL Serverless stores operational tickets and supports SQL analytics over past incidents and ISA-18.2 alarm KPIs.
• Anthropic Claude Sonnet on Amazon Bedrock (Claude Sonnet 4.6 in this implementation) powers reasoning across agents.

A monolithic agent that handles all four data domains faces context window saturation, produces generic responses across domains, and processes queries sequentially. In contrast, a multi-agent architecture allows each agent to focus on a single domain with deep expertise (ISO vibration standards, CMMS lifecycle, NERC PRC-005 compliance). The supervisor agent invokes all agents in parallel, reducing latency. Adding a new data source requires only a new agent and MCP server without modifying existing components. Each agent produces its own reasoning trace, making the system auditable at every step.

How it works: Triage in action

In our example use case, an operator at a combined-cycle gas plant monitors Unit 1 during a normal day shift. A new alarm appears: “TUR-001.BRG3.VIB: HIGH VIBRATION, 68 micrometers.”

The operator enters into the chat interface: “Turbine 1 bearing 3 vibration alarmed at 68 microns. What’s going on?”

The Supervisor agent recognizes this as an alarm triage request and fans out to all four specialized agents simultaneously:

• PI Historian agent – This agent queries the process historian and finds:
  • 30-day trend: Vibration ramping from 45–68 micrometers over 2 weeks
  • Bearing #3 temperature correlating: 68–78°C over the same period
  • Pattern classification: Real and advancing (not chattering, fleeting, or stale)
  • At the current 1.5 µm/day rate, the ISO 10816 Alert threshold (80 µm) is reached in approximately 5 days
• Maximo Maintenance agent – This agent queries the CMMS and finds:
  • Bearing replacement PM (WO#45678) is 2 months overdue
  • Last similar failure: TUR-001 bearing #2, March 2026, required a 3-day forced outage
  • Proactive repair cost: $45K average; reactive (post-failure): $180K average
  • Required bearing assembly is in warehouse stock
• Document Knowledge agent – This agent retrieves from the knowledge base:
  • OEM TIL-2024-017: Bearing vibration limits for H-class gas turbines
  • ISO 10816-3: 68 µm = “Satisfactory” zone, 80 µm = “Alert”, 130 µm = “Alarm”
  • OEM recommendation: Investigate bearing condition when trend exceeds 0.5 µm/day (current rate is 1.5 µm/day, which is 3x the threshold)
• Ticket Analytics agent – This agent queries past incidents from the asset-ticketing database:
  • Three similar bearing degradation events across the fleet
  • Two of three resulted in forced outages when not addressed within 7 days
  • Average resolution time when caught early: 8 hours of planned maintenance

The Supervisor agent synthesizes these findings into a single report:

SEVERITY: HIGH

Bearing #3 degradation in progress on TUR-001. Vibration trending toward ISO Alert threshold within 5 days at the current rate. Correlated temperature rise confirms mechanical wear. Bearing replacement PM is 2 months overdue.

Recommended actions:

1. Schedule bearing inspection within 48 hours (parts in stock)
2. Increase vibration monitoring frequency to hourly
3. Set conditional alarm at 75 µm for early warning
4. Plan 8-hour maintenance window during next low-demand period

Risk if deferred: 67% probability of forced outage within 10 days based on fleet history. Cost differential: $45K planned vs. $180K+ unplanned.

The total processing time is a few minutes, compared to a typical 40–60 minutes of manual investigation across the same systems.

Alarm flood scenario: Generation and T&D

The architecture handles multi-asset alarm floods with the same pattern. For example, during a regional storm, the operator console floods with 14 alarms in 10 minutes across a generation site and three substations, exceeding the ISA-18.2 flood threshold. The operator asks one question: “Major storm; our console is flooding. What is the actual root cause, what is sympathetic, and what should we do first?”

The Supervisor agent fans out to all agents. The PI Historian agent correlates timestamps and identifies two independent events: a lightning fault on a transmission line (with eight sympathetic downstream alarms that will self-clear) and a heatwave-driven transformer winding hot-spot (independent of the storm, approaching the IEEE C57.91 105°C threshold). The Supervisor agent separates root causes from symptoms, prioritizes actions, and cites the applicable standards, all in a single response.

Implementation details

The implementation uses the Strands Agents SDK for orchestration, with backend data sources exposed as language-agnostic MCP tool servers (demonstrated in Python and .NET). Domain expertise, including ISA-18.2 alarm pattern classifications, is encoded directly in agent system prompts. The entire system deploys using a single AWS Cloud Development Kit (AWS CDK) stack. The complete implementation is available on GitHub.

Agent orchestration with Strands SDK

The Supervisor agent uses the Strands Agents SDK to invoke specialized agents through the Amazon Bedrock AgentCore InvokeAgentRuntime API:

@tool
def invoke_specialized_agent(agent_key: str, query: str) -> str:
    """Invoke a specialized Alarm Management agent and return its response."""
    agent_arn = AGENT_REGISTRY[agent_key]["arn"]
    payload = json.dumps({"prompt": query}).encode("utf-8")

    response = agentcore_client.invoke_agent_runtime(
        agentRuntimeArn=agent_arn,
        runtimeSessionId=_current_session_id.get(),
        contentType="application/json",
        accept="application/json",
        payload=payload,
    )

    body = response.get("response") or response.get("body")
    raw = body.read() if hasattr(body, "read") else body
    result_text = raw.decode("utf-8") if isinstance(raw, bytes) else str(raw)

    parsed = json.loads(result_text)
    return parsed.get("response", result_text)

MCP tool servers for data access

Each backend is exposed through an MCP server. The PostgreSQL MCP server, for example, provides text-to-SQL with a safety guard that rejects non-SELECT statements before they reach the database:

@mcp.tool()
def run_query(sql: str) -> str:
    """Run a single read-only SELECT/WITH statement against the asset-ticketing database."""
    _assert_select_only(sql)  # Rejects INSERT/UPDATE/DELETE/DDL via sqlparse
    response = rds_client.execute_statement(
        resourceArn=CLUSTER_ARN,
        secretArn=SECRET_ARN,
        database=DATABASE_NAME,
        sql=sql,
        includeResultMetadata=True,
    )
    columns = [c["name"] for c in response.get("columnMetadata", [])]
    rows = [dict(zip(columns, _decode(r))) for r in response.get("records", [])]
    return json.dumps({"sql": sql, "row_count": len(rows), "results": rows}, default=str)

The PI Historian MCP server is implemented in .NET 8 (because the OEM Web API SDK is .NET-based) and runs as a custom ARM64 container on AgentCore Runtime:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddMcpServer()
    .WithHttpTransport(o => o.Stateless = true)
    .WithTools<SensorDataTools>()
    .WithTools<TrendAnalysisTools>();

var app = builder.Build();
app.MapMcp("/mcp");  // POST /mcp on port 8000
app.Run("http://0.0.0.0:8000");

This demonstrates a key advantage of MCP: the protocol is language-agnostic. Python, .NET, Node.js, and most languages that support HTTP can serve as an MCP tool server on Amazon Bedrock AgentCore.

ISA-18.2 alignment in agent prompts

The agents encode domain expertise directly in their system prompts. The PI Historian agent, for example, classifies every alarm into ISA-18.2 pattern categories:

### ISA-18.2 Alarm Pattern Classification

Classify any alarm query into one of these patterns:

- **Chattering**: cycles in/out more than 3 times in 1 minute (tuning/deadband issue)
- **Fleeting**: clears on its own within seconds (noise/filtering issue)
- **Standing**: continuously active for hours (largest source of alarm fatigue)
- **Stale**: tag unchanged for days (suspect frozen signal/failed transmitter)
- **Real and advancing**: monotonically tracking toward threshold (report time-to-threshold)

Infrastructure as code

The entire system deploys with one parent AWS CDK stack composed of two nested stacks:

• StorageStack (nested) – S3 documents bucket, Amazon Bedrock knowledge base with S3 Vectors (1024-dim, cosine similarity, Amazon Titan Text Embeddings v2)
• RuntimeStack (nested) – Five AgentCore agent runtimes and four MCP server runtimes, with AWS Identity and Access Management (IAM) grants wired between supervisor, sub-agents, and MCPs

cdk deploy alarm-management  # Deploys both nested stacks in dependency order

Key design decisions

Four core design decisions shape the solution’s architecture, balancing fast evaluation with production safety and operator trust:

• Mock-by-default for rapid evaluation – Every MCP server includes a built-in simulator. Clone the repository, deploy, and the demo runs end-to-end against bundled mock data covering six ISA-18.2 scenario archetypes. Switch to real backends by setting environment variables with no code changes required.
• MCP for data source abstraction – Adding a new data source (such as a weather API for storm correlation, an emissions monitoring system, or a SCADA historian) requires deploying one new MCP server. Existing agents and the Supervisor agent remain unchanged.
• Reasoning transparency – The Supervisor agent streams the full reasoning trace, including which agents were invoked, what each found, and how findings were synthesized. Operators see the chain of evidence behind every recommendation, building trust in the system’s conclusions.
• Text-to-SQL safety – The PostgreSQL MCP server parses every SQL string with sqlparse and rejects multi-statement input, any keyword other than SELECT/WITH, and a comprehensive banned keyword list. The LLM can’t mutate the database through this interface.

Prerequisites

To implement the solution, you must have the following:

• AWS account with Amazon Bedrock model access (Anthropic Claude Sonnet 4.6, Amazon Titan Text Embeddings v2)
• AWS CDK v2.170+
• Python 3.10+ and .NET 8 SDK
• Docker (for AWS CDK container image builds)

Deploy and run

Deploy the infrastructure and run the UI with the following commands:

git clone https://github.com/aws-samples/sample-intelligent-alarms-agent.git

cd intelligent-alarm-management-agent

# Deploy infrastructure
cdk bootstrap aws://<ACCOUNT_ID>/<REGION>
cdk deploy alarm-management

# Run the operator chat UI locally
cd ui/streamlit
cp .env.example .env   # Add SUPERVISOR_AGENT_ARN from CDK output
streamlit run app.py

The system runs end-to-end against mock data immediately. Point the MCP servers at your process historian, CMMS, Aurora PostgreSQL-Compatible, and Amazon Bedrock knowledge base backends when ready for production data.

Verify the deployment

After Streamlit launches, ask a sample question, such as “Show me the vibration trend on TUR-001 bearing 3 over the last 24 hours.” The UI streams a response with a reasoning trace; that confirms the Streamlit application, the Supervisor agent, and the PI Historian agent are all reachable and responding.

Cost considerations

This reference architecture provisions billable AWS resources, including AgentCore runtimes, Amazon S3, Amazon Bedrock Knowledge Bases, and Amazon Elastic Container Registry (Amazon ECR). For a low-traffic demo running in mock mode, expect approximately $10–$30 per month. Real-mode use (Aurora cluster, sustained invocations, heavier knowledge base ingestion) runs materially higher. Use AWS Cost Explorer to monitor actual spend.

Clean up

To remove the deployed resources, run the following command:

cdk destroy alarm-management

This permanently deletes uploaded documents and knowledge base ingestion data. Back up custom documents first.

Extending the solution

This reference architecture demonstrates reactive alarm triage, where the operator asks a question and gets an answer in minutes. The natural extensions include:

• Predictive alarming – Catching degradation before alarms are triggered, using the same PI Historian agent to continuously monitor trends against learned baselines
• Automated work order generation – When the system identifies a maintenance need, creating a draft Maximo work order with the correct failure code, priority, and parts list
• Alarm rationalization acceleration – Using the Ticket Analytics agent to identify bad actor alarms (top-N most frequent) and recommend suppression, re-prioritization, or setpoint changes aligned with ISA-18.2 benchmarks
• Shift handover intelligence – Summarizing the outgoing shift’s alarm activity, open investigations, and pending actions for the incoming operator

Scaling tools with Amazon Bedrock AgentCore Gateway

This reference implementation passes each MCP server’s full tool list to the agents at startup, which works well at the current scale (roughly a dozen tools across four servers). As the fleet grows to include SCADA, weather, emissions, protection relay, and other data sources, the combined tool count will eventually exceed what fits comfortably in a single agent’s context. If the tool count crosses roughly 50–100, Amazon Bedrock AgentCore Gateway becomes the recommended pattern: tools are registered after they’re in the gateway, and the agent retrieves only the semantically relevant subset for each query rather than carrying every tool definition in every prompt. This keeps prompt size bounded and latency predictable as new data sources are added.

Security and compliance posture

This architecture provides defense-in-depth across identity, encryption, network isolation, and auditability:

• Least-privilege agent permissions – Each AgentCore agent runtime and MCP server runtime operates under its own IAM execution role with tightly scoped policies. The Supervisor agent can invoke sub-agents, but sub-agents can’t invoke each other. MCP servers receive only the permissions needed to reach their specific backend. This prevents lateral movement by design.
• Secrets management – Backend credentials are stored in AWS Secrets Manager and referenced by Amazon Resource Name (ARN) at runtime. Secrets are not embedded in agent prompts, environment variables, or source code. Secrets Manager supports automatic rotation, and access is audited using AWS CloudTrail.
• Encryption at rest and in transit – Data stored in Amazon S3, Aurora PostgreSQL-Compatible, and Amazon Bedrock Knowledge Bases is encrypted at rest using AWS Key Management Service (AWS KMS). Key rotation policies and access logging are configurable. Service-to-service communication traverses TLS 1.2+ encrypted channels.
• Network isolation – AgentCore runtimes and MCP servers run within managed compute environments with no public internet exposure by default. Connections to on-premises systems can be routed through AWS PrivateLink or virtual private cloud (VPC) endpoints, keeping OT/IT data off the public internet.
• Logging and monitoring – CloudTrail captures API calls across Amazon Bedrock, Amazon Bedrock AgentCore, Secrets Manager, Amazon S3, and AWS KMS. Amazon CloudWatch collects agent invocation metrics, latency, and error rates. The Supervisor agent’s full reasoning trace is logged per session, recording which agents were invoked, what data was accessed, and how findings were synthesized.
• Guardrails – Amazon Bedrock Guardrails applies content filtering and topic denial policies to model invocations. These prevent prompt injection, block generation of unsafe content, and enforce topic boundaries so agents stay within their operational domain.

Conclusion

Alarm management in power and utilities is a well-documented operational discipline. Industry standards (ISA-18.2, EEMUA 191) define targets, the problem is quantified (60–80% nuisance alarms, daily flood events), and effective alarm management has been identified as an important contributor to operational reliability. The remaining gap is the ability to correlate across siloed operational systems in real time.

A multi-agent architecture on Amazon Bedrock AgentCore addresses this gap. Specialized agents query each data domain in parallel, and a supervisor agent synthesizes their findings against alarm management standards, reducing triage from hours to minutes with full reasoning transparency.

The reference implementation is ready to clone, deploy, and evaluate against your own operational data. Start with the mock scenarios to understand the agent interactions, then connect your PI Historian, CMMS, and document systems to see the value against real alarm events.