AWS Security Agent, AWS DevOps Agent, AWS FinOps Agent covered three separate agents. This article is what happens when a client stops buying them separately.
No enterprise client wants three separate vendor relationships for security, operations, and cost — they want one Day 2 operating model, and they will ask an SI partner to be the single point of accountability for it. This article is the composition: how DevOps Agent, Security Agent, and FinOps Agent sit on one substrate and become one sellable managed-services SKU, rather than three articles’ worth of separate line items on an invoice.
1. Why Composition, Not Just Coexistence
Running three agents side by side is not the same as composing them. The value of composition shows up specifically at incident boundaries: an availability incident that DevOps Agent is investigating may turn out, three hops into the root-cause chain, to be a cost event — a runaway process driving both latency and spend — or a security event — a credential compromise manifesting as unusual traffic. MCP and Agent-to-Agent (A2A) support, now present across the DevOps, Security, and FinOps agents, is what lets one agent hand off to another mid-investigation instead of stopping at the boundary of its own domain and reporting “not my problem” back to a human.
svc-checkout-prod triggers DevOps Agent’s investigation. It correlates the latency spike against a deployment three hours prior and a memory-utilization climb, but confidence on “bad deploy” stays below its act threshold. Rather than escalate to a human immediately, the A2A handoff lets it query FinOps Agent’s cost data for the same entity: cost-per-transaction on that service jumped 40% in the same window, consistent with a resource leak, not a traffic spike. That correlation lifts DevOps Agent’s root-cause confidence past its action threshold, and it rolls back the deployment via SSM Automation — a resolution that required cost data DevOps Agent never directly owns, retrieved from a system it never has to be told exists, because both agents resolve svc-checkout-prod to the same entity in the same observability graph.2. The Shared Substrate
What actually makes composition possible is that all three agents read from the same observability foundation — CloudWatch, Application Signals, X-Ray — and run on the same Bedrock AgentCore infrastructure. That is not a coincidence; it’s why the entity-resolution discipline (a consistent service.name across every signal, covered in this practice’s earlier observability work) pays off doubly here: the same identity model that lets a human correlate a trace with a log now lets DevOps Agent’s incident investigation hand off cleanly to FinOps Agent’s cost analysis, because both agents are looking at the same entity graph.
3. Productizing the Composed Practice
Enterprise — the full composed practice: custom SRE agents, Security Agent embedded in CI/CD, FinOps Agent wired to a dedicated cost-allocation structure, sold as a single managed-services retainer with one SLA covering availability, security posture, and cost governance together.
SMB — a standardized composed package at a flat monthly fee, using the templated configurations from each individual article rather than custom tuning.
DNB — API-first and consumption-priced: the client’s own engineering team owns the pager and the pipeline, and the partner’s product is the composed configuration plus periodic governance review, billed against actual agent usage rather than a flat retainer.
What changes for the SI partner
This is the article that turns three separate technical capabilities into one commercial conversation. A prospect evaluating “should we hire an MSP” is not comparing your DevOps Agent expertise against a competitor’s DevOps Agent expertise — they’re comparing whether you can own the whole operating model or whether they’ll need three vendors and an internal integrator to make your three point solutions talk to each other. Selling the composition, not the components, is the difference between being one of three vendors and being the vendor.
Business Value Mapping
| Technical capability | Business outcome | Metric / KPI | Primary stakeholder |
|---|---|---|---|
| MCP + A2A cross-agent handoff | Root cause resolved even when it crosses availability/security/cost boundaries | % of incidents resolved without human domain-hopping | VP Engineering / Ops |
| Shared entity graph (CloudWatch, Application Signals, X-Ray) | One identity model, no reconciliation tax between agent domains | Entity-resolution rate across agents | Platform architect |
| Composed practice sold as one SLA | Single point of accountability instead of three vendor relationships | Client vendor-count reduction | Client CTO / procurement |
| Consumption-priced DNB tier | Cost scales with actual usage across all three domains combined | Blended cost per composed investigation | CFO |
| Tiered composed SKU (Enterprise/SMB/DNB) | One commercial motion instead of three separate sales conversations | Deal cycle time vs. selling agents separately | Partner CRO |
Three agents sold separately are three products. Three agents that hand off to each other mid-investigation are one operating model — and only one of those is worth a retainer.
Sources: This Month in AWS Observability: June 2026 (MCP and A2A protocol support across AWS agents) · AWS Cloud Operations Blog, AWS DevOps Agent A2A integration documentation · Amazon Bedrock AgentCore shared runtime documentation.
