Problem
Every new AI tool promises an agent. The result can be paradoxical: more local autonomy and more global chaos.
One agent doesn’t know other agents exist. Another doesn’t know what tools it has permission to use. Another integrates data with its own connector. Another uses direct APIs. Each solves its own world, but the company accumulates islands.
Without protocols, the organization doesn’t get a system. It gets a swarm without a map.
Thesis
A2A + MCP are important because they shift the conversation from product to nervous system.
MCP structures how an agent accesses context and tools. A2A structures how agents discover each other, expose capabilities, and collaborate. Together, they draw an architecture: agents that don’t live as isolated features, but as coordinable nodes.
Framework
Think about the architecture in four contracts:
- Discovery: how it’s known that an agent or tool exists.
- Capability: what it can do and under what limits.
- Invocation: how it’s asked to work.
- Evidence: how it returns status, result, and traces.
Mini-case: a sales agent needs to prepare a proposal. It can ask for context from a CRM MCP server, invoke a legal agent to review clauses, call a financial agent for margin, and return a proposal with evidence. Without protocols, each step is an ad hoc integration.
Measurable signal: percentage of agent capabilities exposed through discoverable and versioned contracts.
Posture: the future is not a mega-agent. It’s a governed network of capabilities.
Why it matters now
Google presented Agent2Agent as an open protocol for interoperability between agents and ceded it to the Linux Foundation. MCP has become a reference for connecting models with tools and data. The AI Security Institute has observed strong growth in public agent tools, especially in MCP ecosystems.
The practical conclusion: companies need to think about protocols before the agent map grows without governance.
Anti-example
“Each team chooses its own agent framework.”
It may accelerate at first. Then it creates duplication, inconsistent permissions, repeated data, and handoffs that are impossible to audit.
Protocol (3 steps)
- Map capabilities, not vendors. What the organization can do with agents.
- Define minimum contracts. Description, owner, permissions, inputs, outputs, errors, and traces.
- Version integrations. A tool change shouldn’t break the nervous system.
| Contract | Serves for | Risk if missing |
|---|---|---|
| discovery | finding capabilities | duplication |
| capability | understanding limits | tool abuse |
| invocation | requesting work | fragile integration |
| evidence | auditing result | black box |
| versioning | evolving | silent breakages |
Related
- MCP in enterprise: the standard that avoids agent chaos
- Agent Handoffs: frictionless transfers between humans and agents
- Tool Registry: the new risk map for enterprise agents
Sources consulted
- Google Developers Blog: Announcing the Agent2Agent Protocol
- A2A protocol specification
- Model Context Protocol documentation
Next step
Make a list of ten agent capabilities that your company already has or wants to have. Don’t put tool names. Put contracts: who invokes, what it receives, what it returns, and how it’s audited.
Translated from the Spanish original with AI assistance and reviewed for accuracy. Read the original in Spanish.