MCP Gave Agents Tools. A2A Gives Agents Colleagues.

For most of the last two years, the architecture of an AI agent has looked roughly the same. The model reasons. The agent decides. MCP gives it access to capabilities.

That was an important step. Instead of building custom integrations between every agent and every system, the Model Context Protocol gave agents a standard way to interact with tools, resources and data.

But another architectural problem is appearing.

What happens when the capability an agent needs is not a tool? What if the capability is another agent?

A travel agent might need a flight specialist. A support agent might need a billing agent. A procurement agent might need a supplier-negotiation agent. A software engineering agent might need a security-review agent.

At that point the architecture stops looking like Agent → Tool and starts looking like Agent → Agent.

That is the problem the Agent2Agent Protocol - A2A - is trying to standardise. And the distinction matters:

MCP standardises access to capabilities. A2A standardises collaboration between autonomous systems.

Or more simply: MCP gave agents tools. A2A gives agents colleagues.

We already know how to connect software

Consider how software architecture evolved. An application once contained almost everything it needed. Then systems became distributed, and instead of one giant application we built specialised services - payments, orders, inventory - each owning a capability while the application coordinated them.

Eventually standards emerged around those interactions: HTTP, REST, gRPC, OpenAPI, OAuth, event streams, service discovery. They let independently developed systems communicate without understanding one another's internals.

Agents are heading toward the same problem. Except agents are not quite APIs.

An API usually exposes a relatively deterministic operation. The input contract is known, the output contract is known, the operation is reasonably predictable:

POST /calculate-tax
{ "income": 120000 }

An agent is different. You might tell an agent: investigate why this customer's refund has not arrived and resolve the issue.

The receiving agent may need to understand the request, inspect several systems, ask a follow-up question, wait for information, perform multiple operations, generate an artifact, request authorisation, and then continue.

That is not a function call. It is delegation of work. A2A is designed around that distinction.

What A2A actually is

The Agent2Agent Protocol is an open standard for communication between independent agent systems. Google originally developed it and contributed it to the Linux Foundation, which has hosted the project since mid-2025. In 2026 A2A reached version 1.0 - described by the project as its first stable, production-ready specification. Its technical steering committee includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP and ServiceNow.

The protocol lets agents discover what another agent can do, work out how to talk to it, delegate work, exchange messages and structured data, track long-running tasks, receive intermediate updates, exchange generated artifacts, request additional input, and handle authentication - all without exposing their internals.

That last point is the important one. A2A assumes agents may be opaque. Agent A does not need access to Agent B's prompt, model, memory, tools, planner, reasoning trace, framework or internal database. Agent B presents a defined external contract.

One side could be LangGraph plus GPT. Another could be Semantic Kernel plus a local model. Another could be a custom deterministic workflow with no model in it at all. A2A does not require them to share an implementation architecture.

Which is why the better analogy isn't A2A is an API for AI. It is closer to: A2A is a service protocol for autonomous applications.

MCP and A2A solve different problems

There has been understandable confusion here, because both involve agents talking to external systems. But the boundary is clean.

MCP connects an agent to a capability - a CRM, a database, GitHub, search, files, an internal API. The agent is the intelligence coordinating those capabilities.

A2A connects an agent to another agent - each of which may perform its own reasoning, planning, tool use and execution.

The A2A project describes the two as complementary rather than competing, and the interesting architecture is what happens when you use both.

We are no longer building a single agent with lots of tools. We are building a network of specialised autonomous services.

A2A turns agents into services

This is where it becomes architecturally significant.

Suppose your application has one giant agent handling customer support, billing, refunds, fraud, shipping, identity, product knowledge and retention. That agent needs access to everything. Its context becomes enormous, its permissions become extremely broad, its prompts become complicated, its failure surface expands, and testing becomes difficult because everything is coupled.

Each agent owns a domain, and can have its own model, tools, memory, permissions, policies, evaluation and deployment lifecycle.

The support agent doesn't need direct access to the billing database. It can ask the billing agent: investigate invoice 48372 and determine whether the customer's refund was processed.

That changes the security boundary as well as the application boundary - and the security one is the bigger deal. A support agent that cannot reach the billing database cannot be talked into reading it.

The Agent Card: a business card for an agent

Before one agent delegates work to another, it needs to answer a basic question: what can you do?

A2A introduces the Agent Card for this. It is a JSON metadata document describing an agent:

{
  "name": "Billing Agent",
  "description": "Handles customer billing and refund investigations",
  "url": "https://billing.example.com/a2a",
  "skills": [
    {
      "name": "investigate_refund",
      "description": "Investigates refund and payment status"
    },
    {
      "name": "explain_invoice",
      "description": "Explains invoice line items"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  }
}

The real specification carries considerably more structure, including authentication and protocol information. But the architectural idea is simple: the agent publishes a machine-readable description of its own capabilities.

Clients retrieve the public card from a well-known path, following RFC 8615 conventions:

https://{domain}/.well-known/agent-card.json

A2A 1.0 also supports signed Agent Cards, giving cryptographic verification of agent identity and metadata - which matters the moment you are trusting a card that claims I am the official Finance Agent.

This begins to look very similar to service discovery. Except instead of discovering GET /customers/{id}, we discover "this agent knows how to investigate billing disputes." That is a higher-level capability boundary.

APIs expose operations. Agents expose skills.

This distinction is subtle but consequential.

An API exposes getPayment(), getRefund(), getInvoice(), updateRefund(), sendEmail(). The caller composes them into a sequence.

An agent can expose a single skill: investigate a customer's refund problem. Internally it may call every one of those operations. The caller does not need to know.

A2A therefore moves service interfaces from operations toward outcomes. That may be one of the most consequential changes in agentic software architecture - and it is worth noticing that it cuts both ways. An interface defined by outcomes is easier to call and much harder to test, because the set of things that might happen behind it is no longer enumerable.

Messages are not tasks

One thing A2A gets right is recognising that not every interaction should become a workflow.

"What currencies do you support?" needs a simple Message. No persistent workflow required.

"Investigate this payment dispute, contact the appropriate systems and prepare a resolution recommendation" may take hours. So A2A creates a Task.

The specification distinguishes stateless Messages from stateful Tasks for exactly this reason. Tasks progress through a defined lifecycle and can pause for additional input or authentication before reaching a terminal result.

The pause states are the interesting part. A task that discovers halfway through that it needs the customer's bank reference number does not have to fail. It moves to input-required, the calling agent supplies what is missing, and work resumes. That is considerably richer than a function call and a return value.

Agents need asynchronous architecture

Many API calls complete in milliseconds. Agent work might take thirty seconds, five minutes, two hours, or two days.

Imagine asking an agent to compare the contractual terms across 150 supplier agreements and produce a risk report, or investigate this production incident and continue until the affected systems recover. You cannot hold a request-response connection open for that.

Streaming delivers incremental progress while a connection remains active. For longer-running or disconnected scenarios, A2A supports push notifications to a client-provided webhook, letting the calling system reconnect when something significant changes.

This makes A2A feel less like RPC and more like a combination of API, workflow engine, messaging system and task protocol.

Artifacts: agents produce things

Agent work often creates more than conversational text - a report, a PDF, structured JSON, a spreadsheet, an image, a code patch, an analysis.

A2A models these as Artifacts. Messages and artifacts are themselves composed of smaller Parts, which can hold text, file references or structured data.

That matters because agent collaboration isn't just conversation. It is work-product exchange.

A real multi-agent example

Imagine an enterprise procurement system. The user asks: find a suitable cloud monitoring provider, assess security and compliance, negotiate pricing assumptions and prepare a recommendation.

The Procurement Agent doesn't need to know how the Security Agent evaluates vendors. It asks: evaluate Vendor X against our security requirements.

The Security Agent might internally use a policy database, a vendor questionnaire, SOC 2 documents, a security scoring model and an internal risk policy. All of that stays behind the agent boundary. The result might simply be a risk rating, a list of blocking issues and a set of recommended controls.

That is service encapsulation applied to autonomous systems.

A2A does not mean "agents chatting"

When people hear agent-to-agent, the mental model is often two chatbots making small talk. That is probably the least interesting interpretation.

A2A is much more useful viewed as distributed work delegation. Agent A delegates a goal. Agent B executes independently. An artifact or task result comes back.

Agent B might not even use an LLM. It could be a deterministic workflow, a rules engine, an ML model, a human workflow, or a hybrid. From the caller's perspective, what matters is the capability contract.

Which means trust becomes architecture

Once agents communicate across boundaries, security gets much more interesting. Who is Agent B? Who operates it? Is Agent B allowed to invoke Agent C? Can it spend money? Can it expose data received from Agent A?

A2A sensibly builds on familiar enterprise mechanisms rather than inventing a new identity system. Production communication uses HTTPS; authentication can rely on OAuth 2.0 and OpenID Connect. Agent Cards advertise supported security schemes, and A2A 1.0 adds signed cards for cryptographic verification of identity and metadata.

But authorisation remains the responsibility of the agent implementation. A protocol makes communication interoperable. It does not make every participant trustworthy.

The confused deputy problem gets much more interesting

Suppose Agent A has limited permissions and Agent B has broad ones. Can Agent A convince Agent B to perform something Agent A would never be permitted to do directly?

That is the classic confused deputy problem, now with a probabilistic deputy that can be argued with in natural language.

Authorisation cannot just mean Agent C trusts Agent B. It has to carry the original principal, the consent that was given, the scope of what was delegated, and how far delegation may propagate.

A2A provides the communication foundation. The harder governance problem remains ours to solve.

Observability becomes distributed tracing for reasoning systems

Something goes wrong. The final answer is incorrect. Was it the coordinator? The delegation? Bad context? Incorrect supplier data? A tool failure? Model reasoning? A permission rejection? A stale artifact? A timeout?

The A2A enterprise guidance recommends integrating with distributed tracing systems such as OpenTelemetry, propagating trace context through standard HTTP headers and logging identifiers such as task and correlation IDs.

Distributed agents inherit every challenge distributed services already had - latency, timeouts, retries, partial failure, versioning, eventual consistency - and then add non-deterministic reasoning, context management, model variability and semantic ambiguity on top.

Distributed systems were already difficult. We are adding probabilistic participants to them.

Don't build a multi-agent system just because you can

A2A makes multi-agent architectures easier to compose. That does not mean everything should become an agent.

If Agent → Function works, do not replace it with Agent → Agent → Agent. You have added network latency, failure modes, model cost, security boundaries, observability complexity and deployment complexity, potentially without gaining anything.

Use an agent boundary when the remote capability genuinely needs independent reasoning, domain ownership, multiple internal tools, long-running work, a different security boundary, a different team, or a different organisation.

For calculate tax, a function is better. For investigate this customer's unusual tax situation and identify the applicable rules, an agent may make sense.

The lesson microservices already taught us

Breaking a monolith into 200 services doesn't automatically improve architecture. Sometimes you just create a distributed monolith.

Agent systems face exactly the same risk. Instead of one complicated agent, you could end up with 37 agents, 14 models, 8 frameworks, hundreds of prompts and thousands of network interactions - and nobody able to explain why anything happened. Every one of those agents also has to be scheduled, isolated, routed to and paid for, which is a problem that lands on your infrastructure.

A distributed probabilistic monolith, which is considerably worse than the original.

A2A solves interoperability. It does not solve architecture. Good agent boundaries look like good service boundaries: clear responsibility, an owned domain, well-defined permissions, observable behaviour, a replaceable implementation. A Payments Agent or a Security Review Agent is a sensible boundary. A Read File Agent is a tool wearing a costume.

The agent harness and A2A fit together

This connects directly to the other shift happening in agent architecture. Inside an individual agent, we increasingly see an agent harness owning planning, state, memory, tools, permissions, evaluation, observability and model routing - with the model as one component inside that runtime.

Now put A2A around it.

Two distinct architectural concerns, cleanly separated. The harness answers how does an agent operate internally? A2A answers how do autonomous agents interact externally?

That separation is healthy. It means Agent A should not care whether Agent B runs GPT, Claude, Gemini, DeepSeek, a local model, a rules engine, or no LLM at all. It cares what Agent B can do.

A2A 1.0 makes this more than an experiment

A2A began as a relatively young protocol in 2025. By 2026 the picture had changed. Version 1.0 introduced or strengthened production-focused capabilities including multiple protocol bindings, version negotiation, native multi-tenancy so a single endpoint can host many agents, signed Agent Cards, modernised security flows, streaming, push notifications and task lifecycle semantics.

The specification now separates a canonical data model from abstract operations and concrete bindings - JSON+HTTP, JSON-RPC and gRPC - and the project maintains SDKs in Python, JavaScript, Java, Go, .NET and Rust.

That does not guarantee A2A becomes the permanent winner. Protocols evolve, standards compete, architectures change. But the underlying problem is unlikely to disappear. If we genuinely build millions of autonomous software agents, they will need a standard way to discover, identify and collaborate with each other.

Agents become network-addressable capabilities

This is where it gets interesting beyond the protocol itself.

Today we expose an API endpoint. Tomorrow we may expose an agent capability. Instead of asking which endpoint performs this operation?, an agent might ask which trusted agent can accomplish this outcome?

Discover the capability, evaluate the Agent Cards, select an agent, authenticate, delegate the task, monitor progress, receive the artifact, evaluate the result. That looks less like API orchestration and more like a dynamic service marketplace.

These agents could belong to different teams, companies, clouds, frameworks or countries. The caller needs only identity, capability, contract, permissions, task state and result.

We have seen this movie before. The early web had isolated applications until HTTP, HTML, URLs, DNS and TLS let independent systems participate in one network. Enterprise software went monolith, services, APIs, service discovery, distributed systems. Agentic software looks like another run at the same progression - single LLM, LLM plus tools, agent, agent runtime, specialised agents, interoperability, networks.

MCP helped with one transition. A2A is attempting the next.

Where MCP ends, A2A begins

So I would reduce the distinction to this. Through MCP, an agent reaches things it can use. Through A2A, it reaches colleagues it can ask.

MCP made capabilities accessible. A2A makes intelligence composable.

Underneath all of it, the same four movements: models become replaceable, tools become discoverable, agents become interoperable, work becomes delegatable. The LLM provides the intelligence. The harness provides the runtime. MCP provides the tools. A2A provides the network.

MCP was an important shift because it stopped every AI application inventing its own integration layer. A2A tackles the next layer up. Not how does an agent call an API? but how does an agent delegate work to another autonomous system it may know almost nothing about?

That requires more than a function call. It requires discovery, identity, capability declaration, communication, task state, artifacts, streaming, authentication, delegation and observability.

That is why A2A matters. Not because agents need to chat with each other - but because agents are becoming independent software services. And independent services eventually need protocols.

MCP gave agents tools. A2A gives agents colleagues. The first lets an agent use software. The second lets agents compose intelligence.

If agentic architecture keeps moving this way, the next generation of software may not simply call APIs. It may discover another agent, delegate an outcome, monitor the task, and continue when the work is done.

That is a very different application architecture. And we are only beginning to understand what it will look like.

This post is about the boundary between agents. Its companions take the layer above and the layer below: the model is not your agent is about the runtime inside a single agent, and Kubernetes is becoming an AI workload orchestrator is about the infrastructure a network of them has to run on.