The Agentic AI Foundation is building a standards stack to solve a problem most teams hit after their first agent proof-of-concept: how do you wire together agents from different vendors, let them share tools, and coordinate multi-step workflows without writing custom glue code for every integration?
Three protocols sit at the core of this effort. MCP (Model Context Protocol) standardizes how agents discover and invoke tools. A2A (Agent-to-Agent) defines how agents authenticate, route messages, and synchronize state across organizational boundaries. Goose provides a reference implementation and testing harness to validate that agents built on these standards actually interoperate.
This is infrastructure work, not a product launch. The foundation is designing the plumbing layer that sits between your orchestration framework and the agents you deploy.
The Three-Layer Standards Stack
MCP: Tool Boundary Protocol
MCP standardizes the interface between agents and external tools. Instead of each agent runtime implementing its own function-calling format, MCP defines:
- A JSON-RPC 2.0 transport for tool discovery and invocation
- A schema registry for tool capabilities and parameter types
- A context attachment mechanism for passing state between tool calls
MCP servers expose tools as resources. Agents query the server for available tools, inspect schemas, and invoke methods. The protocol does not dictate how the agent decides which tool to call or how it interprets results. That remains in the orchestration layer.
A2A: Agent Coordination Protocol
A2A handles communication between agents that may run on different platforms, in different organizations, or with different security contexts. Key responsibilities:
- Authentication: Mutual TLS or OAuth 2.0 token exchange at the agent boundary
- Message routing: Agents register capabilities and subscribe to task types; the A2A broker routes requests to capable agents
- State synchronization: Shared context objects that track workflow progress, decisions, and intermediate results across agent handoffs
A2A does not enforce a specific orchestration pattern. You can build choreography (agents react to events) or orchestration (a central coordinator dispatches tasks). The protocol provides the message bus and state store; you choose the control flow.
Goose: Reference Implementation and Harness
Goose is both a working agent runtime and a conformance test suite. It implements MCP and A2A, exposing hooks for custom tool providers and agent logic. Teams use Goose to:
- Validate that their MCP servers return well-formed schemas
- Test A2A message routing under network partitions or authentication failures
- Build proof-of-concept multi-agent workflows without writing protocol adapters
Goose is not a production orchestration framework. It is a reference to prove the standards work and a harness to catch interoperability bugs before they reach production.
Architecture: How the Protocols Wire Together
┌─────────────────────────────────────────────────────────┐
│ Orchestration Layer │
│ (LangGraph, Temporal, custom code) │
└───────────────────┬─────────────────────────────────────┘
│
┌───────────┴───────────┐
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Agent A │◄─────►│ Agent B │
│ (MCP client) │ A2A │ (MCP client) │
└───────┬───────┘ └───────┬───────┘
│ │
│ MCP │ MCP
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Tool Server │ │ Tool Server │
│ (MCP server) │ │ (MCP server) │
└───────────────┘ └───────────────┘
Flow for a multi-agent task:
- Orchestrator assigns a task to Agent A
- Agent A queries its MCP server for available tools
- Agent A invokes a tool, receives partial results
- Agent A publishes a message to the A2A broker: "Need data enrichment, here's the context"
- A2A broker routes the message to Agent B based on registered capabilities
- Agent B queries its own MCP server, invokes tools, returns results via A2A
- Agent A receives the enriched data, completes the task, returns to orchestrator
The orchestrator does not know about MCP or A2A. It sees agents as black boxes that accept tasks and return results. The standards handle the internal coordination.
Trade-Offs and Failure Modes
| Concern | MCP | A2A | Goose |
|---|---|---|---|
| Versioning | Schema evolution via semver; clients must handle unknown fields | Message format versioning; routers drop incompatible versions | Reference implementation lags production use |
| Authentication | No built-in auth; relies on transport (HTTPS, mTLS) | OAuth 2.0 or mTLS at agent boundary; token refresh on long workflows | Test harness does not enforce production-grade auth |
| State consistency | Stateless tool calls; agent manages context | Shared state objects; eventual consistency on distributed workflows | In-memory state store; not suitable for multi-node deployments |
| Observability | No trace propagation spec; custom logging per server | A2A broker can log routing decisions; no standard trace format | Goose logs to stdout; no structured telemetry |
| Backward compatibility | Breaking schema changes require new tool versions | Agents must negotiate protocol version during handshake | Goose updates may break tests for older MCP/A2A versions |
Common failure modes:
- Schema drift: Agent expects a tool parameter that the MCP server no longer provides. The agent crashes or retries indefinitely.
- Routing loops: Agent A delegates to Agent B, which delegates back to Agent A. A2A broker does not detect cycles by default.
- Token expiration: Long-running workflows hit OAuth token expiry mid-task. A2A does not auto-refresh; the agent must handle re-authentication.
- Partial state loss: Agent crashes after publishing an A2A message but before persisting local state. The receiving agent processes the message, but the sender has no record of the request.
Implementation Considerations
When to adopt MCP:
- You have multiple agent runtimes (LangChain, AutoGen, custom) that need to share tools
- You want to decouple tool development from agent logic
- You need a registry of available tools that agents can query at runtime
When to adopt A2A:
- You are building multi-agent workflows where agents run in different processes or organizations
- You need agents to discover and delegate to each other without hardcoded routing
- You want a message bus abstraction instead of direct HTTP calls between agents
When to use Goose:
- You are prototyping a multi-agent system and want to validate interoperability early
- You need a conformance test suite for your MCP or A2A implementation
- You want a working example to study before building production adapters
When to avoid these standards:
- You have a single-agent system with a fixed set of tools. Direct function calls are simpler.
- Your agents run in a single process and share memory. A2A adds network overhead for no benefit.
- You need sub-100ms latency. The protocol negotiation and message routing add tens of milliseconds per hop.
Security Boundaries
MCP and A2A assume agents operate in a trusted environment. The protocols do not enforce:
- Input validation: Agents must sanitize tool parameters before invoking MCP servers
- Rate limiting: MCP servers can be overwhelmed by agents making thousands of tool calls
- Capability isolation: An agent with access to one MCP server can invoke any tool that server exposes
Production deployments need additional layers:
- API gateways in front of MCP servers to enforce rate limits and authentication
- Policy engines that restrict which agents can invoke which tools
- Audit logs for all A2A messages and MCP tool invocations
The foundation provides the wire protocol. You provide the security controls.
Observability Gaps
Neither MCP nor A2A includes a standard for distributed tracing. If Agent A invokes a tool via MCP, then delegates to Agent B via A2A, which invokes another tool, you have no automatic way to correlate those events into a single trace.
Options:
- Inject trace context into MCP tool parameters and A2A message headers. Requires custom instrumentation in every agent and tool server.
- Use a sidecar proxy that intercepts MCP and A2A traffic, extracts identifiers, and emits traces to OpenTelemetry. Adds deployment complexity.
- Log correlation IDs at the orchestration layer and pass them through the stack. Requires agents to propagate IDs and emit structured logs.
The standards do not solve observability. They give you the hooks to build it yourself.
Technical Verdict
Use MCP if you need a vendor-neutral tool registry and want to avoid writing custom adapters for every agent runtime. The protocol is stable, the reference servers are production-ready, and the ecosystem is growing.
Use A2A if you are building multi-agent systems where agents need to discover and coordinate with each other dynamically. The protocol is newer and less battle-tested than MCP, but it solves a real problem that orchestration frameworks do not address.
Use Goose for prototyping and conformance testing. Do not deploy it to production. Build your own agent runtime on top of MCP and A2A, using Goose as a reference.
Avoid these standards if you have a simple, single-agent system or if you need the absolute lowest latency. The protocols add complexity and overhead. Use them when the alternative is writing custom glue code for every integration.
The Agentic AI Foundation is building the plumbing layer for multi-agent systems. The standards are not finished, the tooling is not polished, and the failure modes are not all documented. But if you are deploying agents at scale, this is the infrastructure conversation you need to have.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.