Agent-to-Agent Coordination: What to Standardise First

23 July 2026 · Bedrock AI

Before any two AI agents can coordinate reliably, an architect has to fix five things that no protocol ships by default: a shared vocabulary for what each agent is actually capable of, an identity and permission model for non-human actors, a task contract both sides honour under failure, a way to trace and audit the exchange, and a fallback path for when coordination breaks down. Protocols like Google’s Agent2Agent (A2A) supply the wire format for these decisions. They don’t make the decisions for you.

What Actually Breaks When Agents Coordinate Without Standards?

What breaks first is almost never the network call: it’s the assumption that both agents mean the same thing by the words in the message.

An agent that reports “task completed” might mean the API returned 200, or it might mean the downstream effect the requester actually cared about has happened. Without a shared definition of task states, a coordinating agent either trusts a completion signal it shouldn’t, or polls and re-checks everything, which defeats the point of delegating in the first place. The second failure mode is integration sprawl: every new agent pairing gets a bespoke handler, because nobody agreed on a common message shape, and the system that was meant to reduce coordination overhead quietly recreates the point-to-point mess that API sprawl caused a decade earlier. The third, and most dangerous, is silent scope creep: an agent granted broad tool access for one task reuses that access for a task nobody authorised, because the permission model was never scoped per-interaction in the first place.

None of these are protocol bugs. They’re standardisation gaps the architect left open.

What Does the A2A Protocol Actually Standardise?

A2A standardises discovery, task structure and transport security, not organisational decisions about who is allowed to ask whom for what.

Under the Linux Foundation since mid-2025 and now at v1.0, A2A gives every agent an Agent Card: a machine-readable JSON document describing its skills, input and output modes, service endpoint and authentication requirements, so a calling agent can discover what another agent can do without a human wiring up the integration by hand (A2A specification). Work is represented as a Task with an explicit lifecycle (submitted, working, input-required, completed, failed, canceled), which is the closest thing the protocol has to the “what does completed mean” problem above. Security is handled at the transport layer: OAuth 2.0, API keys and mTLS are all supported, with credentials passed via the Authorization header on each call rather than negotiated once and cached (Tyk’s A2A architecture guide).

That’s a genuinely useful floor. It is still only the floor: an Agent Card tells you an agent claims a capability, not whether your organisation trusts it with that capability in this context.

What Must an Architect Standardise on Top of the Protocol?

Five things sit above the protocol layer, and none of them come pre-filled in an Agent Card.

1. A shared capability taxonomy. Agree what “refund,” “escalate” or “approve” mean across every team’s agents before any of them call each other, or the same word will silently mean five different actions.
2. Non-human identity and scoped permissions. Every agent needs its own verifiable identity, not a shared service credential, with permissions scoped to the specific task and time window it’s operating in, not standing access it keeps between calls.
3. A task contract with explicit failure semantics. Define what each lifecycle state guarantees, what happens on partial completion, and who is notified when a task lands in input-required and nobody answers.
4. End-to-end tracing across the agent chain. A single user request that crosses four agents needs one trace ID that survives all four hops, using something like OpenTelemetry with W3C Trace Context headers, or an incident becomes a set of disconnected logs nobody can reassemble.
5. A tested fallback for coordination failure. Decide in advance what happens when an agent doesn’t respond, responds with something malformed, or responds correctly to the wrong task: a human escalation path, a safe default, or a hard stop, chosen before it’s needed rather than improvised during an incident.

Skip any one of these and A2A still runs. It just runs without anyone being able to say, after something goes wrong, exactly what happened and who was allowed to make it happen.

How Is A2A Different From MCP, and Why Does the Difference Matter Here?

A2A and MCP standardise two different layers of the same system, and treating them as competitors is the fastest way to under-build one of them.

Most production systems need both: MCP so an agent can reliably reach the tools and data it depends on, A2A so that agent can hand off part of a job to another agent without a bespoke integration. Architects who only standardise one layer end up with agents that can either use tools reliably or coordinate reliably, never both at once.

How Should Identity and Permissions Work Between Agents?

Every agent needs a verifiable identity distinct from the human or service account that deployed it, because the moment two agents share a credential, you lose the ability to say which one did what.

This is the part most teams under-invest in, because it’s slower to set up than pointing every agent at the same API key. The fix is scoped, short-lived credentials issued per task: an agent calling another agent should present a token that proves who it is, what it’s authorised to ask for, and for how long, not a standing key that still works next week for a task nobody scoped. Where agents cross organisational boundaries, that means OAuth flows negotiated per interaction rather than assumed once at deployment. Where they stay inside one organisation, it still means distinct service identities per agent, logged separately, so an audit trail can answer “which agent, acting on whose authority, did this” without guesswork.

How Should Disagreement and Failure Between Agents Be Handled?

Coordination design isn’t finished until you’ve specified what happens when it fails, because the failure path is where the actual risk in multi-agent systems lives.

Three patterns cover most of it. First, timeouts with an explicit default: if Agent B doesn’t respond to Agent A’s task within a defined window, the system should know whether to retry, escalate to a human, or fail closed, and that decision shouldn’t be improvised live. Second, schema validation on every inbound task and response, not just outbound ones, because a malformed message from a coordinating agent is functionally identical to a malicious one until it’s been checked. Third, a kill switch that any agent in the chain, or a human supervisor, can pull to halt a coordination sequence before it compounds: a small ownership error passed between three agents becomes a much larger one by the time it reaches a fourth. Design that switch before deployment, not during an incident.

FAQ

Do I need A2A if all my agents run inside one framework like LangGraph or CrewAI? Not necessarily. Frameworks that keep orchestration in-process can coordinate agents without a wire protocol. A2A earns its place when agents live in different frameworks, different teams, or different organisations and need to discover and call each other without custom integration work for every pair.

Does adopting A2A replace the need for an API gateway between agents? No. A2A standardises the message format and task lifecycle; it doesn’t enforce which agents are allowed to reach which others. Most production deployments still put a gateway or policy layer in front of A2A traffic to apply the permission and rate-limiting decisions the protocol leaves open.

Who inside the organisation should own the Agent Card registry? Whoever owns tool and API governance today. An Agent Card is a capability claim, and treating it as just another engineering artefact without governance oversight is how the permission-scope problem in this article happens in practice.

Should every agent be allowed to talk to every other agent by default? No. Default-deny is the safer starting position: an explicit allow-list of which agents can call which, reviewed the same way you’d review service-to-service permissions, prevents the quiet capability creep that’s hardest to detect after the fact.

What happens to an A2A task that never resolves? That depends entirely on the fallback design in the section above. Without an explicit timeout and escalation policy, an unresolved task usually just hangs, consuming resources and blocking whatever depended on its result, until someone notices manually.

Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.