Two Specialist Agents, One Incident: What an A2A Handoff Takes

TL;DR

• When a Kubernetes incident crosses the cluster boundary, you need an agent-to-agent handoff. One agent, here DataAgent, an autonomous observability and remediation platform, detects the fault in the cluster and, once you enable it for that fault class, fixes it. The other, here the AWS DevOps Agent, investigates the managed database behind it.
• A2A v1.0 handles the delegation itself: discovery, the task lifecycle and streaming progress. It does not record who authorized a task, who pays for it, or who owns the result. We built that layer around the protocol.
• Context improves quality, not cost. An informed brief returned four rows of evidence instead of two, in the same twelve minutes, for two cents less. The only step that removes money from the bill is disqualification: a 2.5-second preflight ruled a database out before any billed task was opened.
• The call decides the speed, not the agent. Across 63 runs, a streamed direct question came back in 10.6 seconds for about nine cents. The same question as a persistent task took 153.6 seconds and about $1.28.
• The specialist's answer is evidence, not a verdict. It is a priced escalation, never a tool inside our own root-cause analysis, and the fix stays gated and owned on our side.

A Kubernetes expert and an AWS expert worked the same failure over A2A. These are field notes on what the protocol handled, what it could not express, and what we had to build in between, measured over 63 runs against the real agent, on a real account, against real faults.

Two in the morning, a checkout service starts failing, and two different agents can each see part of why.

One is watching the cluster. Within seconds it has the restart loop, the error, the deployment that went out on Tuesday, and the fact that this workload talks to something called payments-db. The other can read the inside of payments-db: the connection ceiling, the engine log, the parameter somebody changed last week.

Neither can finish the job alone. That is not a gap in the tooling that will close next year. It is what a modern incident actually looks like, and it is the reason we spent this quarter building a handover rather than a bigger agent.

Why no single agent owns a modern incident

Our agent's reads stop at the cluster boundary, on purpose. We read Kubernetes and the cloud control plane in place, which is what makes detection continuous and cheap rather than alarm-driven and expensive. The cost of that choice is that a managed database is a closed box, with its own telemetry, its own permissions and its own console.

A large share of what actually breaks a Kubernetes application is not in the cluster. It is the managed database behind it, the queue in front of it, the permission path, the security group. The agent watching the cluster can tell you which door the problem went through. It cannot follow it inside.

Why one agent that sees everything is the wrong fix

The instinct is to fix this by building one agent that sees everything. We think that instinct is wrong. Depth in a managed database means performance insights, engine logs and parameter history, with the permissions and domain knowledge that implies. Depth in Kubernetes means a live model of workloads, topology and drift. Build both into one agent and you get an agent that is mediocre at each, while you spend your quarters reimplementing somebody else's specialty.

The other option is the one every engineering organization already uses for humans. You keep a specialist, and you get good at the handover.

A cluster agent and a cloud agent do different jobs

It is worth being concrete about what each side is actually for, because the moment people hear two agents they assume a competition.

What the cluster-side agent does

Ours is DataAgent, an autonomous observability and remediation platform. It does three things, and it is worth naming them separately because the third one surprises people.

It covers both layers. Kubernetes infrastructure and the application stack running on it, which matters because real incidents are rarely cleanly one or the other. A pod in CrashLoopBackOff because a connection pool is exhausted is an application fault wearing an infrastructure symptom, and an agent that sees only one layer describes half of it.

It fixes, rather than reports, once you enable it for that fault class. The output is a gated change, not a document, and the latency follows from that: seconds to a first opinion, minutes to an approved action, because a fix that arrives after the incident is over is not a fix.

It right-sizes observability spend instead of adding to it. This one follows directly from reading in place. Detection never requires shipping telemetry into a store you pay for by the gigabyte, so continuously watching every pod and workload can reduce what you spend on observability rather than add to it. Most things you bolt onto a stack increase what you pay to collect. This one can reduce it, because an agent that proves which evidence each class of fault actually needs also knows what you never needed to ship, keep or index. That argument is the other half of why an agent that reads in place is worth building.

What the AWS DevOps Agent does

The AWS DevOps Agent, which went generally available on 31 March 2026, researches in depth. Point it at a problem and it runs an autonomous, multi-step investigation without a prompt per step; in our runs, that took five to twelve minutes. Ask it a direct question instead and it answers in seconds. It reads what we cannot, and it is good at it, as far as the permissions you grant its Agent Space allow. It ends with an answer, evidence and recommendations.

Line the two up and they sit at opposite ends of all five axes. Wide against deep. Cloud agnostic against AWS native. Seconds against minutes. A gated change against a researched answer. An agent that can reduce what you spend on watching, against one that bills for the watching it does.

When two systems sit at opposite ends of every axis, the interesting engineering is not in either one. It is in the handover. The question is never which agent. It is when to hand over, what to send with it, and who owns the fix afterwards.

What the A2A protocol handles, and what it cannot express

The two protocols in play here are not interchangeable, and the difference matters more than it first appears.

MCP vs A2A: a tool call versus a delegated task

MCP connects an agent to tools. You call, it returns, you continue. A2A connects an agent to another agent: you hand over a task, the other side works for minutes with its own plan and its own sub-agents, and you follow it to a terminal state. A tool call has a result. A delegated task has a duration, a cost and an owner.

What A2A v1.0 gives you

A2A, hosted by the Linux Foundation since June 2025, reached version 1.0 in March 2026. A year after launch it had more than 150 supporting organizations, with integrations in Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore. It gave us the right abstraction. Discovery through Agent Cards, which v1.0 lets a publisher sign. Delegation as a task rather than a call. An eight-state lifecycle covering submitted, working, input required, auth required, completed, failed, canceled and rejected, which is exactly the vocabulary you need when the other side might come back asking for permission instead of an answer. Streaming progress, so a twelve-minute investigation is observable while it runs.

In practice, two of those did less than the spec suggests. We never saw a signed card from AWS, and the agent never asked us for input: when it tried, its own ask-the-user step failed and it ended the turn.

What A2A leaves to the implementer

Then the part nobody warns you about. A2A can express that a task was delegated. It cannot express who authorized it, who pays for it, or who to ask about it six weeks later.

We are not the only ones to notice a gap at this layer. Kang and Diponegoro audited MCP, A2A, ACP and two other protocols against six governance dimensions, including human escalation and audit and replay, and found that none of them covers the full set. Their conclusion is that governance is a missing layer above these standards. Ours is a narrower, operational version of the same finding: cost, authority and the identity of the requesting human are not in the protocol, so we built them outside it.

So the honest shape of this integration is that the protocol handled the conversation, and we built the layer around it.

How to design an agent-to-agent handoff

That layer is eight steps, and only one of them is the actual delegation.

Coverage and preflight

Coverage asks whether anything actually leaves this cluster. Preflight does a few cheap reads against whatever coverage found, and either rules it out or adds what it learned.

The brief decides the quality of the answer

Then the brief, which is the step that decides the quality of everything downstream.

A DataAgent incident already knows which dependencies leave the cluster, which ones our own reads have settled, and what the remaining question is. Sending that, rather than a bare question, is what makes minutes of someone else's research worth having. We measured the difference. Handed just the question, the specialist came back with two rows of evidence. Handed what we already knew and what we had already ruled out, it came back with four, in the same twelve minutes.

Context does not make the specialist faster. It moves its effort out of rediscovering what you already knew and into the part you actually needed.

What to do when two agents disagree about one incident

Then the answer comes back, and you have a new problem: two analyses of one incident, written by two systems, with no guarantee they agree.

So the handover ends in a reconciliation rather than an answer. Every finding lands in one of three buckets: it agrees with what we found, it adds something we did not have, or it conflicts with it. That last bucket is the valuable one, and it is exactly what nobody builds while they are still excited about the integration.

The answer is evidence, not a verdict. It attaches to the incident, our own enrichment runs over it, and the plan that comes out the other side is still ours and still gated. The specialist stops at a recommendation, which is the right place for it to stop. Somebody still has to own the change, verify the system recovered, and carry the consequence if it did not.

What agent delegation costs

None of the above is a cost story, but the moment a specialist bills by the second, economics becomes a design input whether you wanted it or not.

Put the two halves side by side and the shape is unusual. The detection layer that decides when to delegate adds nothing to the bill, because it reads in place, and it can right-size what you were already spending on observability. The depth layer, when we call it, is billed by the second at $0.0083. So the money in this system is concentrated exactly where the judgment is: in deciding whether a question is worth asking a specialist at all. Here is what that looked like when we measured it.

Two findings, and only one of them is intuitive.

Context buys quality, not savings

The informed brief cost two cents less than the plain one and returned twice the evidence. The agent fills whatever budget it is given, so context buys quality rather than savings. Do not let anyone sell an informed handover as a cost reduction, because the first invoice will contradict them.

A later run against the same fault added a caution. It found the real connection ceiling sat near 450, which contradicted the informed run's headline claim that the pool was stuck at a 130 cap. Four rows was more evidence, not more truth. Count the rows that are new, and check them.

The cheapest useful run cost nothing

Preflight checked a flagged database, found its connection count had never risen above zero, and ruled it out in two and a half seconds without opening a task. Disqualification is the only step in the whole system that removes money from the bill. Everything else moves cost around or improves what you get for it.

Two consequences for the design

Every way to start a billed run passes a gate that shows the estimate first, because a cancelled run still bills for the seconds it consumed and stopping is therefore not a refund. And the requesting human's identity travels in the task metadata, so the audit trail names a person rather than a service account. Delegation splits authorization from accountability, and you have to put them back together yourself. And treat any estimate as a floor, not a quote: our buttons said about $0.10 for a direct question and about $3 for an investigation, and real runs cost up to $0.80 and $6.40.

What 63 runs against the AWS DevOps Agent taught us

We have kept running the integration against the real agent since we first wrote this: 12 investigations and 51 direct questions so far. Some of what we learned changed the design. Some of it changed what we would tell you to expect.

The call decides the speed, not the agent

A2A gives you two ways to ask. A single streamed message, with no task behind it, answered a question in 10.6 seconds for about nine cents. The same question as a persistent task took 153.6 seconds and cost about $1.28, because the task path reports back in batches 30 to 90 seconds apart. So we now split by question. A direct question streams. An investigation keeps the task, because the task is what gives you cancel, deduplication and a link back into the AWS console. One bill question went from almost five minutes and $2.46 to 11 seconds and nine cents.

We were paying for our own waiting

After the agent finished, our client kept the connection open for another three and a half to four minutes, and agent time bills by the second. A 20-second check fixed it: one run dropped from $3.30 to $2.78. If a specialist bills by the second, audit the seconds you add.

Depth is a permission, not a property

The specialist reads what its Agent Space is allowed to read. Without Performance Insights and the key to decrypt it, the inside-the-database answer was a permission dead end, after a 12-minute run that cost $6.40. Without Cost Explorer access it could not answer a bill question at all. The good news is that one Agent Space can read a second AWS account as a secondary source, so the same chat answered a bill question in 24 seconds and an RDS question in 33.

The same question, three answers

Asked for the current bill three times in seven minutes, it gave three totals up to 40 percent apart, and once reported zero usage where credits had cancelled the usage out. Asking for a table, the bottom line first, and gross figures before credits fixed the zero and matched Cost Explorer. Specify the shape of the answer, and show a person the variance rather than hiding it.

Small details, a day each

A brief of 10,681 bytes was rejected with an HTTP 500 validation error; collapsing repeated events brought it to 3,040 bytes and the run completed. Reading the Agent Card proves nothing about permission: it loads for any AWS login, including one that is refused on send, so we prove signing with a real five-cent question. A follow-up question does not carry its context over. And progress arrives in structured data parts that a text-only client drops, which left our panel silent for half a minute at a time.

The decision: an escalation, never a tool

An external agent is an escalation, never a tool inside our own root-cause analysis. It takes minutes where we take seconds. It would bill on every incident instead of only where coverage finds a real gap. Its text would flow straight into our conclusions. And its answers vary in ways a person should see. So it is offered, priced and confirmed, and what it says comes back as evidence, never as our verdict.

Worked example: a CrashLoopBackOff that started in the database

Everything above is architecture. Here is the same thing as a sequence of screens, captured against a running stack rather than mocked up. The AWS account number is masked; nothing else is retouched.

1. The incident, and what each side can see

On the left, our own analysis: orders-api in CrashLoopBackOff, the PostgreSQL database out of connection slots, the rollout that did it thirteen minutes earlier. On the right, what our agent knows about the boundary: two dependencies leave the cluster, and it can name them.

The agent is explicit about the line it cannot cross. It lists what it can read itself, the CloudWatch metrics, the RDS events, the parameter group, the security groups, and then what it cannot: performance insights, top SQL, engine log contents. That list is the argument for delegating, written by the agent that would otherwise be guessing.

2. What it knows before you ask

Coverage, the dependencies, the brief mode it intends to send, and the price of asking, all on one line before any commitment exists.

3. Asking, in the words you already use

A slash in the ordinary chat composer offers the handoff alongside everything else. No separate console, no incantation to memorize.

4. The gate

The question is held, not sent. The estimate sits on the button itself, declining costs nothing, and pressing Enter again does not confirm.

Since these screens were captured, the gate has changed shape. The single estimate became two priced choices, a direct question or an investigation, shown in Figure 4 above.

5. The answer comes home

When the specialist finishes, its findings do not sit in a separate tool. They attach to the incident, post into its chat attributed to the agent that produced them, trigger our own enrichment over the new evidence, and record a verdict on that dependency so the next incident on it starts from what we learned.

Note the last line of that panel. The verdict was inconclusive, which settles nothing, so the dependency stays eligible for a future handover. A system that records only its successes would have quietly closed that door.

Where DataAgent fits: who gains what from the handover

This is worth splitting honestly, because both sides get something they could not build alone.

If you already run the AWS DevOps Agent

Four things change. A different population of incidents reaches it: on its own it investigates what somebody already pointed it at, while continuous cluster-level detection also starts on the first-time fault nobody wrote a rule for. It arrives aimed, at the dependencies that actually left the cluster, with everything already settled marked as settled. Its answer gets reconciled rather than filed. And it gains a path to a gated fix.

What we gain

On our side, we get AWS depth we cannot reproduce and should not try to, an autonomous investigation that runs for minutes without supervision, and coverage in accounts where we would otherwise have no evidence at all. The findings feed our own enrichment, so the analysis and the plan stay ours.

The cost on your side

There is a cost on your side too, and it is worth naming. You stop starting every investigation by hand, which means the system needs to check for a running task before opening a duplicate, and it needs to carry your identity so the spend is attributable later. Both are work. Neither is optional.

The position, stated plainly: this runs your agent, in your Agent Space, on your bill. It is not a replacement for anything you have already chosen. It is what happens when continuous detection decides when to call it, what to send with the question, and what to do with the answer.

Seven things we would tell anyone wiring agents to agents

1. Design the handover, not the integration. The protocol part took days. Deciding when to hand over, what to send, and who owns the answer took the quarter.
2. Treat context as a quality lever, never a cost lever. It buys depth. Budget it as a saving and the invoice will embarrass you.
3. Build the disqualifier first. It is the only component that reduces the bill, and the least interesting code you will write.
4. Keep the layer that decides cheap. If the thing choosing when to delegate is itself expensive to run, you have moved the problem rather than solved it. Detection that reads in place is what makes a paid specialist affordable to consult.
5. Decide who owns a conflict before you have one. Two agents will disagree about a real incident, and that has to be settled in the design rather than during it.
6. Choose the depth per question. A direct question should stream back in seconds. Only an investigation needs a task. Same agent, same protocol, about a fifteenth of the time.
7. Prove permission with a real request. A readable Agent Card says nothing about whether you may send. Five cents of real question does.

What it comes back to

The checkout service is still failing at two in the morning, and neither agent can finish the job alone. One knows the cluster and can act on it. One knows the database and can explain it.

The interesting work was never inside either of them. It was in deciding what to send, what to do with what came back, and who was accountable when it did.

AWS is the first specialist, not the design. Google ships Gemini Cloud Assist investigations and Microsoft ships the Azure SRE Agent, each deep inside its own cloud and blind outside it. Our first attempt with Google's agent, on our own GKE cluster, is a fair preview of the work ahead: it answered in its own console, but refused every programmatic call, a block we have raised with Google. Multi-cloud is turning into multi-agent, and the handover layer is the part that spans it. That is the subject of our next post.

If you are wiring agents to agents yourself and have measurements of your own, we would like to compare notes.

FAQ

How much does a twelve-minute AWS DevOps Agent investigation cost?

At the list price of $0.0083 per agent-second, twelve minutes (720 seconds) comes to about $5.98. Idle time is not billed, but a cancelled run still bills for the seconds it already used. Treat any estimate as a floor: in our runs, an investigation estimated at about $3 cost up to $6.40. Put the estimate in front of whoever approves the run, not after it.

Can I test an agent handoff without paying for every investigation?

New AWS customers get a two-month AWS DevOps Agent trial. Each trial month includes up to 20 hours of investigations. That is enough to measure brief quality and preflight hit rate before list pricing applies.

Which A2A task states does a delegating agent have to handle?

All eight, but two are easy to miss: input required and auth required. Both mean the remote agent has paused and is waiting on you. Treat them as a question to route to a human or a policy, not as a failure. Treat completed, failed, canceled and rejected as terminal.

Do signed Agent Cards prove who the remote agent is?

A2A v1.0 lets an Agent Card carry a JWS signature computed over a canonical form of the card, but signing is optional, and in our runs the AWS DevOps Agent never presented a signed card. A readable card does not prove you are allowed to send either: AWS's card loads for any AWS login, including one that is refused on send. Check the signature where one exists, and prove permission with a small real request before you send incident context.

Should I connect two agents with MCP or A2A?

Use MCP when you want a tool: you call it, it returns, you continue. Use A2A when the other side plans its own work, runs for minutes and may ask you for input or permission along the way. If the work has a duration, a cost and an owner, it is a task, and A2A models it better.

How do application topology mapping tools integrate with incident management platforms?

In the setup described here, the integration point is the incident itself. The cluster-side agent's live model of workloads and dependencies tells it which dependencies leave the cluster, and it hands those questions to a specialist agent over A2A as a task, with a brief of what is already known. The specialist's findings come back as evidence: they attach to the incident, post into its chat attributed to the agent that produced them, and record a verdict on that dependency. The remediation plan stays gated and owned by whoever owns the incident.

Key takeaways

• A modern incident usually crosses the cluster boundary, so the useful unit of design is the handoff between specialists, not a bigger agent.
• A2A covers discovery, task state and streaming. Authorization, cost attribution and the identity of the human who asked are yours to build.
• A richer brief bought twice the evidence at about the same price. Do not budget it as a saving, and check the new rows rather than counting them.
• Ruling a dependency out before delegating is the only step that cut the bill.
• Pick the call per question: stream direct questions, keep tasks for investigations. Treat the external agent as a priced escalation whose answer is evidence.
• Reconcile the specialist's answer against your own, and keep the fix gated and owned on one side.

References

The specialist. AWS DevOps Agent reached general availability on 31 March 2026 (AWS What's New, InfoQ). It is priced at $0.0083 per agent-second, with no charge for idle time (AWS pricing).

The protocol, and its gaps. Richard Kang and Yudho Diponegoro, "Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express" (arXiv).

The Linux Foundation has hosted the Agent2Agent protocol since June 2025 (Linux Foundation). Its first stable version, v1.0, shipped in March 2026 (Google Open Source Blog). The v1.0 changes, task states and Agent Card signing are listed in the A2A docs.

At the one-year mark, more than 150 organizations supported A2A, with integrations in Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime (Linux Foundation).

Other clouds, other specialists. Microsoft, Azure SRE Agent documentation (Microsoft Learn). Google Cloud, Gemini Cloud Assist investigations (Google Cloud docs).

Going deeper. If you are building the same kind of loop, the detect, diagnose, act and verify cycle is walked end to end in our free, open-source autonomous SRE training series. For the cost side of reading in place, see Precision vs. Recall: Why Observability Costs So Much.

Our figures. Run times, costs and evidence counts are our own measurements against the AWS DevOps Agent at list price, in our own AWS account, against real faults. They are not a customer's bill and not a vendor benchmark. Dollar figures are measured wall time multiplied by the published rate, not an AWS invoice. Runs before 29 September include up to four minutes our own client spent waiting after the agent had finished, since fixed; the runs in Figure 3 predate that fix.