agent handoffs need contracts, not vibes

A2A joining the Agentic AI Foundation is one of those announcements that can look boring if you only read the protocol names.

Another foundation. Another standard. Another diagram with agents talking to agents, tools talking to agents, agents discovering other agents, and everyone promising an open ecosystem.

Fine.

The interesting part is not the branding.

The interesting part is that agent-to-agent interoperability is leaving the demo layer.

A2A is now being positioned as part of an open agentic stack: AGENTS.md for instructions, MCP for agent-to-tool access, agentgateway for traffic mediation, and A2A for agent-to-agent discovery, delegation, and collaboration. At the same time, MCP’s 2026-07-28 specification work is making the tool side more operational: stateless requests, explicit headers, tasks, apps, authorization hardening, and deprecation policy.

That combination matters.

Not because “agents can talk now.”

They already could, in the same way two services can technically communicate if you glue enough JSON and optimism between them.

It matters because the industry is trying to turn agent collaboration into infrastructure.

And once something becomes infrastructure, the question changes.

The question is no longer “can this agent hand work to that agent?”

The question is “what contract governs the handoff when it fails at 2:13 in the morning and the customer-visible thing is still broken?”

mcp is tools, a2a is coworkers

The simple mental model is this:

MCP helps an agent connect to tools and data.

A2A helps an agent connect to other agents.

That distinction sounds neat, and mostly it is. An MCP server exposes capabilities: search this document store, file this ticket, query this database, call this deployment tool, list these resources, run this workflow. A2A exposes another agent as a collaborator: here is what I can do, here is how to reach me, here is the kind of task I can accept, here is how I return work.

One is agent-to-capability.

The other is agent-to-worker.

Both reduce integration friction. That is the good part.

It is also the part that should make platform teams sit up.

Lower integration friction never just removes work. It changes the shape of the work. When REST APIs became easy to expose, companies did not end up with five carefully governed APIs. They ended up with hundreds of APIs, some owned, some half-owned, some haunted by a team name from three reorganizations ago.

When queues became easy, everything became asynchronous until nobody knew where the retry storm started.

When Kubernetes made workloads portable, every team discovered they were a platform team, usually against their will.

Agent interoperability will do the same thing.

It will create more handoffs.

handoffs are where production systems lie to you

Most demo videos are about the happy path.

Agent A receives a request. It discovers Agent B. Agent B knows procurement, or payroll, or shipping, or incident response, or SAP, because apparently the enterprise future is just a group project with better latency. Agent B does its part. Agent A summarizes the result. Everyone claps politely.

That is not the version I care about.

I care about the version where Agent B accepts the task but cannot finish it.

Or starts it twice.

Or finishes it after Agent A has already timed out and delegated the same work elsewhere.

Or needs human approval in the middle.

Or returns a partial answer that looks final.

Or uses a tool Agent A was not allowed to use directly, which means delegation became permission laundering with a nicer diagram.

This is where “agent collaboration” stops being cute.

A handoff is not a vibe. It is a distributed systems boundary.

And distributed systems boundaries need contracts.

the contract starts with identity

If one agent delegates work to another, the first boring question is: who is actually acting?

Not “what is the agent name in the UI?”

Real identity.

Which user initiated the work? Which agent accepted it? Which organization owns that agent? Which runtime executed it? Which credentials were available? Which policy context traveled with the request? Which downstream actions happened as the user, as the originating agent, as the receiving agent, or as some service account nobody wants to admit exists?

This gets uncomfortable fast because agent delegation blurs authority.

If I ask an engineering agent to investigate an outage, and it asks a database agent for help, and the database agent calls a query tool, what identity should the database see?

The human?

The first agent?

The second agent?

The workflow?

The answer probably depends on the action. Read-only troubleshooting is different from changing a feature flag. Querying aggregate metrics is different from exporting customer rows. Asking a finance agent for an explanation is different from authorizing a refund.

That means the handoff contract needs to carry identity and scope explicitly.

Otherwise, the company will eventually discover that “agent-to-agent interoperability” became a convenient way for work to cross permission boundaries without anyone noticing.

delegation needs scope, not charisma

An agent card or capability document is useful. A receiving agent should be able to describe what it can do, how to call it, what formats it accepts, which modalities it supports, and what kind of task state it returns.

But production teams need more than a capability brochure.

They need a delegation contract.

What tasks may this agent accept? What tasks must it reject? Can it call other agents? Can it call paid tools? Can it access private data? Can it take irreversible actions? Can it ask a human for approval? Can it continue after the caller disconnects? Can it keep state? For how long? Under whose retention policy?

This is the part that separates interoperability from operability.

Interoperability says Agent A can reach Agent B.

Operability says Agent A knows what it is allowed to ask, what Agent B promised to do, what happens if Agent B does not finish, and who owns the mess.

That sounds boring because it is.

Good.

Boring is the right emotional temperature for production contracts.

retries are where agent workflows get expensive

Every handoff needs a failure model.

This is not optional. It is the difference between a multi-agent workflow and a loosely supervised pile of attempts.

Can a delegated task be retried safely? Is the task idempotent? Does the caller provide an idempotency key? Does the callee deduplicate? Can the caller cancel the task? What does cancellation mean if the callee already started downstream work? Can the task return partial progress? Can it be resumed? How long should the caller wait before escalating?

We already learned this with APIs, queues, background jobs, workflow engines, and incident automation.

“Try again” is not a strategy.

It is a strategy only after you know what retry means.

Agents make this worse because the handoff may not be a single request. It may be a long-running investigation, a plan, a code change, a data enrichment chain, or a customer support workflow that waits for human input.

MCP’s newer task and explicit-handle work is interesting here because it pushes state into visible handles instead of hiding everything in a transport session. That is the right direction. A long-running operation should have a durable identity. A caller should be able to poll it, cancel it, resume it, and explain it later.

A2A-style agent work needs the same discipline.

If an agent gives another agent a task, the task should not evaporate into “the model is thinking.”

It should become a thing.

A thing with an owner, state, deadline, budget, inputs, outputs, trace, and failure mode.

provenance is not a nice-to-have

The other thing every handoff needs is provenance.

When the final answer comes back, a reviewer should be able to see more than the polished summary. Which agent did which part? Which tools did each agent call? Which data sources contributed? Which intermediate results were accepted? Which were discarded? Which approvals happened? Which policies blocked actions? Which assumptions crossed the boundary?

Without that, multi-agent systems will create a new kind of production ambiguity.

The work “got done”, but nobody can explain how.

That is not autonomy. That is an audit problem with a chat interface.

Provenance matters for security, but it also matters for quality. If an incident-response agent delegates log analysis to another agent, and that agent silently ignores one region because the query timed out, the final report may look confident and still be wrong. If a research agent asks a finance agent for market context, the final answer needs to show whether the finance agent used fresh data, cached data, or a fallback model making sad little guesses.

The point is not to drown humans in traces.

The point is to make the trace available when the answer matters.

the platform checklist

If I were responsible for agent interoperability inside a company, I would not start by arguing about which protocol wins.

I would start with inventory.

Which agents exist? Who owns them? What can they do? Which tools can they reach? Which data can they see? Which other agents can call them? Which environments run them? Which version is production?

Then I would require explicit capability documents.

Not marketing descriptions. Operational ones. Accepted task schemas, rejected scopes, auth requirements, latency expectations, retry semantics, cancellation behavior, data classification, budget rules, approval boundaries, and support contacts.

Then I would version the handoff contracts.

If Agent A depends on Agent B for a workflow, that dependency should be visible somewhere better than a prompt. Contract changes should have migration notes. Breaking changes should have dates. Deprecated behavior should have a removal policy. The boring API-management muscles still apply.

Then I would trace cross-agent work end to end.

One workflow ID across the caller, callee, tools, approvals, and final output. Not because tracing is fashionable, but because debugging a distributed agent workflow without correlation IDs sounds like a punishment for something I did in a previous sprint.

Then I would test failure paths.

Agent unavailable. Agent slow. Agent returns partial data. Agent asks for approval. Agent exceeds budget. Agent rejects scope. Agent starts work and then receives cancellation. Agent delegates to a forbidden downstream agent. Agent returns output that violates the caller’s schema.

If those cases are not tested, the production behavior is mostly a rumor.

standards are good, but they do not remove ownership

I like that A2A is moving under neutral governance. I like that MCP is getting more operationally serious. I like that agent interoperability is becoming less vendor-specific and less glued together by bespoke adapters.

That is progress.

But standards do not remove ownership.

They make ownership more important.

Once protocols make handoffs easier, more teams will create them. Once more teams create them, the platform needs a way to govern identity, scope, retries, task state, budgets, approvals, provenance, audit, and human-readable failure.

The practical lesson is not “agents can talk.”

The practical lesson is that agent handoffs are production contracts now.

Treat them like APIs. Treat them like queues. Treat them like jobs. Treat them like incident runbooks. Give them names, versions, owners, deadlines, traces, and failure modes.

Interoperability without operability is not a platform.

It is just a larger surface area for ambiguity.

And ambiguity is where production systems go to make humans look tired.

references

• AAIF: A2A joins AAIF’s open agentic stack
• A2A Protocol documentation
• A2A GitHub repository
• Linux Foundation: A2A Protocol surpasses 150 organizations
• Model Context Protocol specification 2026-07-28
• MCP Blog: The 2026-07-28 MCP Specification Release Candidate
• Cloudflare Blog: The next generation of MCP
• Axios: Google’s A2A protocol gets a new home

To test my projects, I use Railway. If you want $20 USD to get started, use this link.