Building an Autonomous AWS SRE Copilot with MCP, Bedrock Nova and Human Approval

For about a year, the industry has been fixated on ChatOps: attaching LLMs to Slack or Telegram as clever wrappers around CI/CD pipelines. Chatbots, though, are only the visible tip. Real enterprise value comes from moving from reactive chatbots to autonomous agents. An autonomous Site Reliability Engineering (SRE) copilot built on Amazon Bedrock (Nova), the Model Context Protocol (MCP) and AWS shows what that looks like. It does more than trigger pipelines. It looks into live production incidents on its own, pulls metrics and logs, works out root causes and applies fixes, all inside a secure trust boundary with a human in the loop.

The managed option: AWS DevOps Agent

Before building anything custom, an architect should ask whether AWS already offers this. It does, in a form. AWS launched the DevOps Agent at re:Invent 2025, in preview from December 2025 and generally available from March 2026. It is a serious multi-agent system aimed at autonomous incident response on AWS.

It goes well beyond older tools like DevOps Guru:

• Autonomous incident response. A firing CloudWatch alarm starts an investigation that correlates telemetry, logs, traces, code changes and deployment history to find a root cause and draft mitigation plans.
• Proactive prevention. It studies historical incident patterns and suggests improvements to observability, infrastructure and pipelines.
• Release readiness reviews. It reviews code changes and deployment pipelines before they reach production.
• Multi-agent design. A lead orchestrator directs specialized sub-agents for log analysis, root cause and similar jobs, the same pattern used in this build.
• Broad integrations. Datadog, Dynatrace, New Relic, Splunk, PagerDuty, GitHub, GitLab, ServiceNow and Slack connect out of the box.

On paper, it covers what an SRE team could ask for.

Why build a custom one

The catch is access. The DevOps Agent comes bundled with AWS Support plans at Business+ and Enterprise level and isn't available to the general public on demand. An organization on Developer Support, a startup, an independent team or a consultant working in a client's account without Enterprise Support simply can't use it.

The managed service suits teams already on Enterprise Support that work within standard AWS patterns, since AWS has done the heavy lifting and integrations are broad. For an AI architect, though, the more interesting question is whether the pattern is understood well enough to build it independently and extend it where the managed product stops. That is what this project shows.

The core problem: tools at scale

Models like Amazon Nova understand distributed systems, AWS architectures and complex debugging. Out of the box they are still brains in a jar. They can't see CloudWatch metrics or touch DynamoDB tables.

Giving an LLM outside tools traditionally meant fragile custom code:

1. Define a JSON schema for the tool.
2. Write a Python function that runs it.
3. Hardcode AWS credentials into the agent's runtime.

That ties the agent tightly to the infrastructure, which creates security headaches and maintenance bottlenecks.

Enter MCP

The Model Context Protocol, introduced by Anthropic and fast becoming an industry standard, handles this neatly. It is a standardized protocol, something like USB-C for AI, linking models to external data sources and tools. Rather than hardcoding AWS tools into the agent, a separate MCP server is built. It lives inside the AWS environment with the necessary IAM roles and exposes strictly typed, semantic tools over the standard protocol. The agent, running anywhere, connects as an MCP client. It needs no AWS credentials, because it just asks the server to run tools for it.

Freedom to pick the model

Because MCP doesn't care which model is on the other end, the SRE agent orchestrator can use whichever one fits:

Amazon Nova  ─┐
Claude 3.5   ─┼──→  SRE Agent Orchestrator  ──→  MCP Server  ──→  AWS Cloud
OpenAI GPT-4o─┘          (agent.py)                (server.py)

Evaluating a model from another provider means changing a line of code. The MCP server and all the secure AWS tooling it exposes stay exactly the same.

Architecture of the SRE copilot

1. The target infrastructure

To give the agent something to repair, a standard serverless microservice is deployed with Terraform: API Gateway in front of a Lambda function that writes to a DynamoDB table. The deliberate flaw is a crippled table provisioned with only 1 read capacity unit and 1 write capacity unit. Under any real load, this API throws ProvisionedThroughputExceededException errors.

2. The MCP server

A Python FastMCP server plays the hands and eyes, exposing four SRE capabilities:

• describe_architecture finds all AWS resources (ARNs) carrying an application tag.
• query_cloudwatch_metrics fetches time-series data such as ThrottledRequests.
• query_cloudwatch_logs runs CloudWatch Logs Insights queries to locate stack traces.
• remediate_dynamodb_capacity is a mutating tool that raises table capacity.

The trust boundary is where the human enters. The read-only tools are fully autonomous, so the model can use them as much as it likes to investigate. The remediation tool, however, enforces a strict human-in-the-loop block. Before calling the AWS API, it stops and asks the operator in the terminal for a [y/N] approval, displaying the model's justification. Having an auditable checkpoint on every state-changing action, shaped by an organization's own rules, is something DevOps Guru and Amazon Q don't provide.

3. The autonomous agent

The agent is a small Python script that talks to the Amazon Bedrock Converse API through boto3, with the Amazon Nova model family chosen for capability and low cost. It runs an autonomous while loop:

1. It receives a prompt such as "Users report the Payment API is timing out. Fix it."
2. It asks the MCP server which tools exist.
3. It maps the MCP tool schemas straight into the Bedrock Converse format.
4. It starts reasoning: find the Payment API resources, check their metrics, then read the logs.
5. It calls tools through MCP, feeds results back to Bedrock and continues until it has a fix and triggers the remediation tool.

The loop in action

Pointed at the throttled DynamoDB table and asked to find out why the demo API returns 429 and 500 responses, the agent works through these steps:

1. It calls describe_architecture to find the Lambda and DynamoDB table ARNs.
2. It calls query_cloudwatch_metrics on the table, looks at ProvisionedThroughputExceededRequests and spots a huge spike.
3. To be certain, it calls query_cloudwatch_logs on the Lambda function, parses the JSON logs and confirms a ProvisionedThroughputExceededException.
4. It concludes capacity is insufficient and calls remediate_dynamodb_capacity, asking for 50 RCU and 50 WCU.

Here the MCP server intercepts the call and prompts the human:

=======================================================
⚠️ URGENT: AGENT REQUESTING PERMISSION TO MODIFY INFRASTRUCTURE
=======================================================
Action: Scale DynamoDB Table 'sre-copilot-payments-dev'
New Capacity: Read=50, Write=50
Agent's Reason: The table is experiencing severe throttling (ProvisionedThroughputExceededException). Scaling up to mitigate the incident.
=======================================================
Approve this change? [y/N]: y

The same agent also runs as a Streamlit chat application, showing the proposed solution and the approval step. Once the human approves, capacity is updated and the incident is resolved.

What this architecture buys

Separating the brain (Amazon Nova through Bedrock) from the hands (AWS APIs) with MCP yields flexibility that managed AWS tools can't match:

• LLM portability. Swapping Nova for Claude or GPT-4o is one config change.
• Security. Raw credentials never reach the LLM runtime.
• Safety. Mutating actions pass through a customizable human approval step.
• Extensibility. A new tool, whether PagerDuty, a Datadog API query or a ServiceNow ticket check, is a single @mcp.tool() function away.
• Autonomy. The agent explores read-only telemetry freely, so it can diagnose unusual issues that pattern-matching tools like DevOps Guru would miss.

Cloud operations look set to move away from monolithic managed services that lock teams in, toward composable, model-agnostic, auditable agents that teams build, own and keep improving. This is a pattern fit to take to production, not merely a demo.

For reference, the MCP specification is published at modelcontextprotocol.io, and AWS Labs maintains open-source reference MCP servers.