In April 2025, Google released a protocol for agent-to-agent communication. Within three months, Google had donated it to the Linux Foundation, where AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow signed on to govern it. By December, Anthropic and OpenAI had put MCP and AGENTS.md under the same roof through the Agentic AI Foundation. Azure, Amazon Bedrock AgentCore, and Google Cloud have integrated A2A natively, and more than 150 organizations now support it. Release to Linux Foundation-governed 1.0 took eleven months. The communication layer now has an owner.
The state layer doesn't. A2A defines how agents send tasks and return results. It says nothing about where the state those tasks depend on actually lives, who owns it, or what happens when two agents touch it at once. In production multi-agent systems, those aren't protocol details; they're architecture decisions that determine whether shared state stays consistent, durable, governable, and auditable. The coordination point is the database, not the task message, and that's exactly what the protocol leaves undefined.
What is A2A, and how is it different from MCP? 
A2A enables horizontal agent-to-agent connection: It defines how one agent delegates work to another across vendors, teams, and infrastructure stacks, without either side needing to know how the other works internally.
MCP, Anthropic's Model Context Protocol, is vertical: it defines how a single agent connects to external tools and data sources within its own context window.
The two protocols address different layers of the same problem:
Production multi-agent systems use both. An orchestrating agent uses A2A to route a task to a specialist. The specialist uses MCP to call the tools it needs to complete it. They're not competing standards. They're different layers of the same architecture.
Neither protocol addresses what must happen at the data and state layer underneath both of them.
What AGENTS.md standardizes, and what it leaves out
AGENTS.md reinforces the same architectural pattern as MCP and A2A: it standardizes an interface while leaving durable state outside the standard.
In August 2025, OpenAI, Google, Cursor, Factory, and Sourcegraph shipped AGENTS.md, a plain Markdown file that tells a coding agent how to operate in a repository: build commands, conventions, test procedure, boundaries. A README for agents. Within months it was in more than 60,000 open source projects, and by December OpenAI had donated it to the Agentic AI Foundation, the same Linux Foundation body Anthropic, OpenAI, and Block formed to steward MCP alongside it.
So the agent stack now has three open standards, one per interface. MCP defines how an agent reaches tools and data. A2A defines how agents delegate to each other. AGENTS.md defines how an agent receives its operating instructions.
Notice what all three have in common. Each standardizes a contract, and each deliberately says nothing about state. AGENTS.md is the purest example: it's a static file. It can tell an agent what to do. It can't remember what the agent did. No memory of previous runs, no record of decisions made, no identity, no audit trail. The spec keeps it that way on purpose: plain Markdown, no required fields, no schema. (Claude Code is a useful data point here: as of this writing it still reads its own CLAUDE.md rather than AGENTS.md natively, a small reminder that even the instruction layer hasn't fully consolidated, let alone the state layer underneath it.)
That's three layers of the stack settling on the same design choice: standardize the interface, leave the state to you. Durable memory, shared state, identity, and auditability all land on the data layer underneath.
Why A2A makes the database problem harder
A2A makes the database problem harder because agents can coordinate across organizational boundaries without sharing a state store, consistency model, or view into each other's internals.
With a single agent using MCP, the infrastructure problem is more tractable: one agent, one context window, one consistency model.
When an orchestrator delegates to a specialist at a different organization, that specialist is autonomous. It may use a different database, memory layer, transaction model, and consistency guarantee entirely. A2A makes the agents interoperable at the communication layer; it does not make their state models interoperable.
So what's the consistency guarantee across the full workflow?
The A2A protocol defines how the task is sent and how the result is returned. It says nothing about state management, memory handling, or data consistency during execution. That's intentional. The spec explicitly keeps agent internals opaque from one another.
That opacity is what makes interoperability work. Everything that follows is the bill for it.
How A2A affects shared state and transaction consistency
A2A agents have no transaction model between them. The protocol defines how their messages move, not how concurrent reads and writes to shared state remain consistent.
In traditional distributed systems, services coordinating on shared data can use distributed transactions, two-phase commit, or saga patterns to define what happens if one service fails mid-operation.
When an A2A orchestrator agent distributes subtasks to specialist agents running in parallel, the protocol provides no equivalent state management guarantee.
Here's the anomaly concretely. Two agents both check whether a task is claimed, both see that it isn't, and both claim it. Both agents' transactions are open at the same time:
Read Committed doesn't error here because each statement reads from its own snapshot: nothing ties Agent 2's earlier read of claimed = false to its later write, so the overwrite is legal. At SERIALIZABLE, CockroachDB treats that earlier read as part of the transaction's consistency contract. When the underlying data changes, the second transaction aborts with a retryable error instead of silently overwriting Agent 1's claim. The isolation level of the shared store, not the protocol, determines whether this conflict is detected before it becomes corrupted shared state that downstream agents may continue acting on.
The obvious rejoinder: careful SQL avoids this at any isolation level. A conditional write (UPDATE ... SET claimed = true WHERE task_id = ... AND claimed = false, checking rows affected) or SELECT FOR UPDATE closes this particular hole. True, and beside the point. That fix assumes every access path was written by someone who saw the race coming. Agentic systems are exactly where that assumption dies: agents compose queries at runtime, retry on their own schedule, and multiply access paths faster than any review can audit them. Serializable isolation makes this class of concurrency failure the store's responsibility rather than relying on every access path to anticipate it.
A second objection: isn't this what durable workflow engines like Temporal already solve?
Partly. A workflow engine checkpoints execution so a crashed process can resume, which is necessary but not the guarantee an A2A workflow needs. Temporal's event history can tell you what your activities did. It doesn't govern shared data outside that execution boundary: what another organization's agent accessed, whether concurrent writes remain consistent, or whether months later a compliance team can query what data was touched and under whose identity. Those are queryable, joinable, access-controlled data questions. Agent state across an A2A boundary is data-shaped, not workflow-shaped.
A workflow engine is a reasonable place to checkpoint your own agent's execution. It isn't a substitute for the shared, governed data layer two independent organizations need to reason about each other's state.
How A2A handles context transfer, and what it leaves to agent memory
A2A lets one agent send a task description and selected context to another, but it doesn't solve shared agent memory. When agents need context beyond what travels with the task, they need durable external storage both sides can query.
Anthropic frames context as a critical but finite resource. Managing it within a single long-running agent is already hard. However, "relevant context" is undefined by the A2A spec, so the receiving agent otherwise starts fresh.
A2A transfers selected context between agents, leaving teams to determine how much state should persist across the handoff.
Anthropic's work on long-running agents points toward durable external context storage that agents query, rather than carry in-window. For multi-agent systems, that memory isn't only semantic recall or vector retrieval. It can also include operational state: what work has completed, what decisions were made, which resources were touched, and what another agent can safely act on next.
Across an A2A boundary, that raises a harder question: Where does shared context live when agents from different organizations build on each other's work, and who owns it? Closing that gap takes a store both sides can query directly, not a bigger task message.
How A2A complicates identity across organizational boundaries
A2A doesn't define the identity a third-party specialist should use when it acts on another agent's behalf. Credential pass-through and independent identity are the two obvious models, and both create problems.
Within a single organization, agents need per-session identities, scoped credentials, and explicit delegation chains that narrow permissions at each hop. Across an organizational boundary, the question gets harder: Under what identity does that specialist act?
Credential pass-through. The orchestrator passes its identity to the specialist. The specialist acts under your organization's credentials. Any error or breach in the specialist's system now has the blast radius of your organization's data access scope.
Independent identity. The specialist operates under its own identity entirely. Your organization no longer controls how that identity is scoped or enforced, making cross-boundary access governance dependent on the specialist's system.
The missing capability is enforceable delegation: a way to give the specialist only the authority required for one task, preserve who delegated that authority, and revoke or expire it when the work ends. The emerging pattern is explicit delegation, covered in the Patterns section below. It requires a token service that understands A2A task scope. The protocol doesn't provide one.
Related
Built for AI: Scaling IAM, Metadata Management, and Vector Search on One Database — how AI leaders like Ory/OpenAI and CoreWeave unify identity, metadata, and vector search on one distributed SQL platform.
Why A2A complicates observability across organizational boundaries
A2A doesn't guarantee a complete audit trail across organizational boundaries. Each organization can run a different observability system, and the protocol doesn't require them to agree on what execution data to log or share.
For an agentic workflow, observability means more than infrastructure health or database metrics. Reconstructing execution can require the task, tool calls, data accessed, identity used, state changes, and result to remain correlated across the handoff.
Even a useful single-agent audit trail is demanding: every tool call, input, output, identity, and cost, in order. But one team controls the full execution. An A2A pipeline can cross organizations and observability systems, making a complete reconstruction dependent on what each side records and exposes.
Consider a loan-processing pipeline that delegates compliance verification to a third-party agent over A2A. The orchestrating agent handles document intake and risk scoring; the specialist performs the compliance check.
Then a regulatory exam asks a straightforward question: for a set of flagged applications, what customer data did the compliance verification step access, and under what credentials?
The orchestrating agent's logs are complete: task sent, result received, status completed. The specialist agent's internal execution is opaque by design: what data it queried, what rules it applied, under what identity it accessed applicant records. That opacity is what makes A2A interoperable across organizations.
It's also what makes the honest audit answer "we don't know." Reconstructing the specialist's behavior from partial evidence isn't good enough for a regulator. The fix is negotiating cross-boundary logging with the specialist vendor before the first production task runs, not after the exam.
Patterns for the data layer across A2A boundaries
Three patterns are emerging for A2A systems that cross organizational boundaries: shared external memory for context transfer, checkpoint-based state management for fault tolerance, and explicit delegation with automatic expiry for identity.
These patterns are already appearing in production. The Linux Foundation's one-year report on A2A cites deployments spanning supply chain, financial services, insurance, and IT operations.
Shared external memory layers handle context transfer. Rather than serializing context into task messages, teams build a shared, queryable store both sides of the A2A boundary can access. Done carelessly, this is a 20-year-old integration antipattern: two organizations pointing application code at the same tables with no contract between them is exactly how the identity and audit problems above compound instead of resolving. Done deliberately, it isn't table sharing. It's a governed context store with a schema contract for context objects, row-level access policies enforced at the database layer, and consistency strong enough that one agent can't silently corrupt what another depends on. Who hosts it is itself a design decision: orchestrator-hosted, specialist-hosted, or hosted by a neutral third party. Each choice shifts who holds root access, who pays for it, and whose auditors sign off.
That store must preserve the properties established above under real cross-organizational workloads: serializable access to shared state, durable checkpoints that survive a region failure, and database-level access enforcement. None of that is protocol-layer work.
Checkpoint-based state management handles fault tolerance. A workflow engine can make execution durable; the shared store has to make the state that execution depends on durable and consistent. If a specialist fails mid-task, the orchestrator needs the last consistent state to retry or compensate. That means persisting enough state after significant operations to resume from a known-good point rather than re-running the full workflow from scratch. Transport-layer delivery guarantees are not sufficient for this.
Explicit delegation with automatic expiry handles identity. The orchestrator issues a task-scoped credential, the specialist uses it for that task only, and it expires at completion. The audit trail covers both the issuance and the use. The implementation pattern for per-session, scoped credentials in a single-organization agent system is covered in detail in "Why Your AI Agent Has an Identity Problem." The same principles apply across an A2A boundary, with the added complexity that you don't control the other side's enforcement.
Related
The Architect's Playbook for Building AI-Ready Systems — practical architectures for vector workloads, real-time consistency, agent memory, and global scale on distributed SQL.
When You Don't Need A2A (or Any of This)
Not every multi-agent system has this problem. You can skip A2A, and most of the data-layer work above, if any of the following describes your system.
Every agent runs inside one organization, on one framework. Sub-agents in a single LangGraph, ADK, or OpenAI Agents SDK app share a runtime. Your framework's state management and your database's transactions already cover them; A2A adds a network boundary you don't need.
One agent, many tools. That's MCP's job. Wiring A2A between components that could be tool calls adds latency and failure modes without adding capability.
Specialists only read. If delegated agents never write shared state, the consistency problem collapses to caching and staleness. Identity and audit still apply. Transactions mostly don't.
The workflow is disposable. Prototypes re-run from scratch. Checkpointing is overhead until re-running has a cost.
The condition that changes the answer is an organizational boundary plus writes: the first time an agent you don't operate writes state your workflow depends on, everything above applies.
Questions to Answer Before You Build on A2A
If you're designing a multi-agent system that uses A2A, the infrastructure questions to answer before you write protocol code:
Who owns the shared state between agents, and under what consistency model?
What context travels with an A2A task, and how does the receiving agent access the rest?
What identity governs each agent in the workflow, and how does delegation narrow at each hop?
What does a complete audit record look like across your full A2A pipeline?
What happens to in-flight state if an agent mid-workflow goes down?
For third-party specialist agents, also ask:
6. What's the data access boundary between your system and the specialist, and who enforces it at the database layer rather than at the application layer?
7. How do you build a useful audit trail across an organizational boundary where you don't control the other side's logging and identity model?
The communication layer has an owner now. What remains is the data infrastructure underneath it: shared state, durable context, identity across boundaries, and observability at the handoff.
Serializable isolation, survival across region failure, and database-enforced access policy are requirements that distributed SQL is built to address. Memori, a SQL-native memory engine for agents, provides the governed context layer described above on CockroachDB.
Most of that work is being figured out in production incidents. Architecture reviews are cheaper.
Ready to go deeper?
The identity and governance challenges in multi-agent systems within a single organization are covered here: "Why Your AI Agent Has an Identity Problem."
The broader infrastructure challenges that determine whether agentic AI ships to external production, including state management, thundering herd, blast radius, and observability: "What Breaks When Agentic AI Reaches Production?"
Anthropic's framework on context engineering is the right starting point for thinking about what has to happen at the memory layer before, during, and after an A2A task handoff: "Effective context engineering for AI agents."
For a look at what durable, queryable agent memory looks like when these patterns are actually deployed, the Memori Labs integration walkthrough is a useful reference: "CockroachDB + Memori Labs: Keeping Agent Context Alive."
An AGENTS.md You Can Paste In
Paste this into a repo that has agents writing to a shared CockroachDB store. It encodes the pattern this post argues for, instead of just describing it.
Props: Thank you to Cockroach Labs' David Bressler for review of this article.
A2A handles communication between agents, while the data layer must keep their shared state consistent and resilient. Learn how CockroachDB supports consistent, resilient state for multi-agent systems. Talk to an expert.
Built for AI-driven scale
Unify operational data, vector search, and durable agent state in one resilient, distributed SQL database. Start with $400 in free credits. Trusted by Fortune 50 financial institutions and teams in 40+ countries.
Quentin Packard is GM of Americas at Cockroach Labs, where he works with engineering and infrastructure leaders building production-grade agentic AI systems. He previously helped build Splunk's observability business and has worked across infrastructure automation, secrets management, and real-time data governance at HashiCorp and early-stage startups. His writing draws on direct conversations with enterprise teams navigating AI and data architecture in production.
