AWS DevOps Agent expands with custom SRE agents and MCP/A2A protocols
DevOps Agent now runs scheduled SRE bots and plugs into any MCP/A2A tool—turning reactive ops into automated, composable workflows.
View original announcement →Visual Summary
graph TD
A{{AWS DevOps Agent}}:::announced
B([Custom SRE Agents]):::feature
C([MCP/A2A Protocols]):::feature
D((Kiro/Claude IDEs)):::external
E(Amazon Bedrock):::compute
F([Incident-Skip Rules]):::feature
G([Knowledge & Skills]):::feature
H((Sub-Agents)):::external
I([Quality Dashboards]):::feature
D ==>|"headless access"| A
A -->|"schedules"| B
A -->|"exposes via"| C
H -->|"connects via A2A"| A
E -->|"powers"| H
A -->|"applies"| F
A -->|"leverages"| G
A -.->|"tracks quality"| I
C -.->|"enables"| D
classDef announced fill:#ff9900,stroke:#ec7211,color:#fff,font-weight:bold
classDef compute fill:#e3f2fd,stroke:#1565c0,color:#1565c0
classDef storage fill:#e8f5e9,stroke:#2e7d32,color:#2e7d32
classDef feature fill:#fff3e0,stroke:#e65100,color:#e65100
classDef external fill:#f5f5f5,stroke:#616161,color:#616161
What's New
AWS DevOps Agent has expanded significantly with support for custom SRE agents, bring-your-own sub-agents, and headless access via the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocols. Teams can now create scheduled agents within Agent Spaces to automate recurring operational workflows such as daily database health checks or log anomaly detection. The release also includes chat enhancements, incident-skip rules, Git-managed skills, memory-enhanced knowledge, human labeling, customer-created dashboards, and availability in five new AWS Regions.
How It Works
- Custom SRE Agents: Teams create and schedule agents within Agent Spaces that run on a defined cadence (e.g., daily, hourly), enabling automated recurring tasks like database health reporting, slow query detection, or 24-hour log anomaly reviews without manual intervention.
- Headless Access via MCP: Developers invoke DevOps Agent capabilities programmatically from external tools—such as the Kiro IDE, Claude, or other coding assistants—using the Model Context Protocol, allowing production health checks and issue investigations without switching contexts.
- Bring-Your-Own Sub-Agents via A2A: Teams connect custom agents built on Amazon Bedrock or third-party frameworks to DevOps Agent using the Agent-to-Agent (A2A) protocol, extending its native capabilities with domain-specific logic or proprietary tooling.
- Enhanced Knowledge Layer: Agent instructions (AGENTS.md), skills, and memories are unified under a single Knowledge page with three tabs; topology understanding refreshes automatically for active Agent Spaces, keeping infrastructure context current.
- Incident-Skip Support: Customer-defined rules allow the agent to bypass specific incident types, reducing noise and preventing unnecessary escalations based on known, acceptable conditions.
- Task Quality Tracking: Human labeling workflows and customer-created dashboards provide visibility into agent task quality, enabling teams to measure, audit, and improve agent performance over time.
- Cross-Region Monitoring: An Agent Space created in one supported Region can monitor and investigate resources across all AWS Regions within an associated account, eliminating the need for per-Region Agent Spaces.
Why It's Important
- Closes the automation gap in SRE workflows: Scheduled custom agents replace manual, repetitive operational tasks (health checks, log reviews, parameter tuning audits), freeing SRE teams to focus on higher-value work.
- Enables composable AI operations: A2A protocol support means DevOps Agent becomes a node in a broader multi-agent ecosystem rather than a standalone tool, unlocking complex, chained automation scenarios.
- Meets developers where they work: MCP-based headless access and the Kiro IDE integration remove context-switching friction, making production observability a native part of the development workflow.
- Reduces alert fatigue: Incident-skip rules give teams fine-grained control over what the agent acts on, preventing known non-issues from consuming agent cycles or generating spurious notifications.
- Improves trust and governance: Human labeling and quality dashboards introduce a feedback loop that makes agent behavior measurable and auditable—critical for organizations adopting AI in production operations.
- Broader global reach: Expansion to 11 total supported Regions (including São Paulo, Mumbai, Singapore, Sydney, and Tokyo) makes the service viable for global enterprises with data residency requirements.
How It's Different
- Protocol-native interoperability: Unlike most cloud-native DevOps tools that require proprietary SDKs or console access, DevOps Agent exposes its capabilities via open protocols (MCP and A2A), making it composable with any compatible agent or IDE.
- Scheduled agent execution within a managed space: Rather than requiring external orchestration (e.g., Lambda cron jobs or Step Functions) to run periodic operational checks, Agent Spaces natively support cadence-based agent scheduling.
- Extensible via third-party agent frameworks: Competing managed DevOps AI tools typically lock teams into a single vendor's agent ecosystem; DevOps Agent's A2A support allows Bedrock-native and third-party agents to be plugged in as sub-agents.
- Unified knowledge management: The consolidation of AGENTS.md instructions, skills, and memories into a single Knowledge page with automatic topology refresh is a more integrated approach than managing these artifacts separately across multiple systems.
- Quality feedback loop built in: The combination of human labeling and customer-created dashboards for task quality is a differentiator—most AI DevOps tools lack native mechanisms for teams to score and track agent output quality.
When to Prefer It
- When your SRE team runs recurring manual checks: If engineers are spending time on daily or weekly operational reviews (database health, log scanning, parameter audits), custom SRE agents on a schedule directly replace that toil.
- When you use Kiro, Claude, or other MCP-compatible tools: Teams already invested in MCP-compatible IDEs or coding assistants can access production health and investigation capabilities without adopting a new console or workflow.
- When you need to integrate proprietary or specialized agents: Organizations with existing Bedrock agents or third-party AI agents that have domain-specific knowledge (e.g., a security agent, a cost optimization agent) can connect them to DevOps Agent via A2A rather than rebuilding capabilities.
- When alert noise is a significant operational problem: Teams dealing with high volumes of known, benign incidents can use incident-skip rules to filter them out systematically, improving signal-to-noise ratio.
- When operating across multiple AWS Regions: Because a single Agent Space can monitor resources across all Regions in an associated account, this is preferable to deploying and managing separate monitoring solutions per Region.
- When AI agent governance and auditability are required: Enterprises in regulated industries or with internal AI governance mandates will benefit from the human labeling and quality dashboard features to demonstrate oversight of automated decisions.
Availability
- Status: Generally Available (GA) as of June 15, 2026, based on the public announcement; no preview or beta qualifier is indicated.
- Supported Regions (11 total): US East (N. Virginia), US West (Oregon), Canada (Central), South America (São Paulo), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London).
- Cross-Region monitoring: A single Agent Space can monitor resources in any AWS Region within an associated account, regardless of where the Agent Space itself is created.
- Service endpoints: Each Region exposes a dedicated HTTPS endpoint in the format
aidevops.<region>.amazonaws.com. - Pricing: Not explicitly stated in the announcement; refer to the AWS DevOps Agent pricing page for current details.
- Limitations: Agent Space data (investigations, topology, recommendations) is stored in the Region where the space is created; Region selection should account for data residency requirements. Third-party integration considerations apply for cross-Region setups.
