A2A stands for Agent-to-Agent: one agent discovers another agent, delegates a task, exchanges context, and receives the result. It is quickly becoming one of the default pictures of the agent economy. Your personal agent will not do everything itself. It will hire a sales agent, a travel agent, a research agent, and a procurement agent. Those agents may hire more agents in turn.
I think we are accepting that picture too easily.
For many jobs, A2A is not the most efficient architecture. If my agent needs to run a GTM campaign, I would rather give it the prospect data and the tools to send approved outreach than make it find, brief, supervise, and pay a separate GTM agent. The second agent may be a useful product, but it is also another context boundary, another failure surface, and another intermediary.
The agent economy does need interoperability. But it needs open capabilities more than it needs a new layer of agents guarding those capabilities.
So this is my argument to companies building for agents: stop holding on to your APIs. Open them. Let my agent use what you have built directly.
A2A recreates a human constraint
Humans delegate because our capabilities are scarce and difficult to copy.
I cannot become a competent tax attorney for twenty minutes, file one return, and then discard that expertise. I hire someone who already has the knowledge, credentials, tools, and institutional memory. The coordination cost is worth paying because acquiring the capability myself would be absurdly expensive.
Agents have different physics.
The first agent can load a skill, call a tool, read a schema, access a dataset, and temporarily become specialized enough for the task. It can retain the user's full context while doing so. It does not need a new identity or a separate relationship for every capability it acquires.
When we automatically turn every capability into another agent, we import the org chart into software. We reproduce the meetings, handoffs, briefs, status updates, and accountability gaps that software should have removed.
That should not be our default.
The GTM agent thought experiment
Imagine I ask my primary agent to launch an outreach campaign for a new developer tool.
In the A2A version, it must:
- discover a GTM agent
- decide whether that agent is credible
- negotiate scope, price, and permissions
- compress my product context into a new brief
- explain the target customer and exclusions
- wait for the second agent to act
- inspect the work without seeing its full reasoning or data
- recover when the two agents interpret the goal differently
Now compare that with the direct version:
- provide the prospect list
- expose the approved messaging rules
- grant scoped access to the outreach channel
- let the original agent execute
One agent holds the objective, the product context, and the feedback loop. Data and tools cross the boundary; responsibility does not.
I call this A2D, or Agent-to-Data, as shorthand. Strictly speaking, the better name may be Agent-to-Resource, because the agent needs more than rows in a database. It needs tools, permissions, compute, and bounded actions. The naming matters less than the architecture: keep the intelligence close to the user's context and make external capabilities directly composable.
Every extra agent charges a coordination tax
Delegation is not free merely because machines perform it.
An A2A transaction adds capability discovery, identity, authentication, context transfer, task negotiation, asynchronous state, output verification, retries, and often another economic margin. The A2A specification formalizes many of these pieces for a good reason: independent agents need a common way to discover capabilities and manage long-running work.
But a standardized tax is still a tax.
The key question is not whether the second agent is more specialized. It is whether the value of that specialization exceeds the cost of creating a new boundary.
Most of the examples I see do not pass that test. They take an operation that could have been a typed tool call and turn it into a conversation. They replace a schema with negotiation. They replace a deterministic response with another model trajectory that the first model must now evaluate.
This looks more autonomous in a demo. It is often less efficient in production.
Opacity is a feature—for the seller
There is a revealing phrase in the A2A specification: agents may be opaque. They can collaborate without exposing their internal state, memory, or tools.
Technically, that is useful. Commercially, it is irresistible.
An API exposes primitives. It shows customers what the underlying system can do and lets them decide how to combine those operations. Once the capability is programmable, a customer can build its own workflow, substitute another provider, cache results, compare prices, or move the intelligence into its own agent.
An agent exposes an outcome while keeping the composition hidden.
The vendor keeps the orchestration. It keeps the customer relationship. It can bundle several ordinary operations into a premium task, meter the outcome instead of the inputs, and make substitution harder. The buyer receives a worker, not building blocks.
This is why I suspect some of the enthusiasm for A2A is not really about execution efficiency. It is about value capture. Companies are willing to publish an agent that anyone can hire while remaining reluctant to publish the API that would let anyone rebuild the agent's workflow.
A2A becomes a business model disguised as an architecture.
Your API is not your moat
I understand the instinct to protect an API. If you spent years collecting data, building integrations, and surviving procurement, opening the interface can feel like giving away the company.
But the interface is rarely the core asset.
The asset is the exclusive data, execution rights, distribution, trust, feedback loop, compliance posture, or operational reliability behind it. A good API does not give those away. It makes them usable.
The OpenAPI specification exists precisely so humans and machines can understand a service without seeing its source code. Opening an interface is not the same as open-sourcing the implementation. You can still authenticate every caller, meter every request, enforce scopes, rate-limit abuse, price by value, and revoke access.
In fact, an API can make a real moat more valuable. If thousands of agents can safely compose your unique data or action into their workflows, you become infrastructure. If they must hire your branded agent and surrender their context every time, many will route around you as soon as an adequate alternative appears.
Protect the asset. Do not confuse the drawbridge with the castle.
Give agents capabilities, not characters
The more useful direction is already visible in tool-oriented protocols. The Model Context Protocol gives servers a way to expose resources and tools to a model-driven application. The agent remains in control of the task while external systems provide bounded capabilities.
That is closer to what I want from an agent economy.
If you own prospect data, expose search, enrichment, freshness, and provenance.
If you own a communications network, expose scoped sending, delivery state, and opt-out enforcement.
If you own a travel inventory, expose availability, constraints, holds, and booking.
If you own a regulated workflow, expose the safe operations your authorization permits and return an auditable record.
Do not add a persona unless the capability genuinely requires an independent decision-maker. Do not make my agent negotiate with your agent when a clear contract would do. Do not force another context window into the loop because a chat transcript looks better on a launch page.
Give the original agent sharp tools and legible boundaries.
The security objection is solvable
The strongest objection to open agent access is not the moat. It is safety.
A general-purpose agent should not receive an immortal API key with unlimited write access. It should not be able to export an entire customer database because one prompt asked for a lead list. It should not silently spend money or send messages without approval.
But these are arguments for better API design, not for hiding the API behind another probabilistic system.
Build for:
- narrow OAuth scopes
- short-lived credentials
- per-action spending limits
- dry runs and previews
- explicit approval for irreversible actions
- idempotency and rollback where possible
- structured errors agents can recover from
- complete audit logs
- clear pricing before execution
An agent-facing API should be safer and more legible than the human-facing API that came before it. That is a product opportunity, not a reason to retreat into opacity.
When another agent is actually justified
There are real boundaries where A2A makes sense. A specialist agent may hold a regulated identity, proprietary long-term state, legal accountability, or access that cannot safely be decomposed into individual tool calls. Some work is open-ended enough that buying a managed outcome is genuinely cheaper than orchestrating its parts.
Use A2A there.
But treat it as the exception created by a meaningful capability or trust boundary—not the universal shape of software. The burden of proof should sit with the extra agent. What does it own that cannot be exposed as data, tools, and permissions? What coordination does it eliminate rather than add?
If the honest answer is “it protects our workflow from the customer,” then we are not designing the most efficient agent economy. We are preserving the SaaS economy's intermediaries and giving them names.
Open the gates
The web grew because companies exposed pages anyone could link to. The cloud grew because infrastructure became programmable. The agent economy will grow when useful capabilities become composable by agents that already understand their users.
That requires more than wrapping the old API in an MCP server. It requires treating agents as first-class customers: good schemas, granular permissions, transparent pricing, predictable errors, documentation that models can actually navigate, and terms that allow automated use.
The companies that do this may give up some control over the final workflow. They will gain something larger: a place inside workflows they could never have designed or distributed themselves.
So publish the agent if you want. Support A2A when a real delegation boundary exists. But publish the underlying capabilities too.
Do not make every agent knock on the door and hire a representative.
Open the gate.
Closing thought
The agent economy will not be built by agents talking endlessly to other agents. It will be built when companies stop guarding programmable capabilities and let agents put them to work.