The Agentic AI Foundation's Standards Stack: MCP, A2A, and Goose

The Agentic AI Foundation is developing a standards stack built around three protocols — MCP for tool discovery and invocation, A2A for agent-to-agent authentication, message routing and state synchronization, and Goose as a reference implementation and conformance test harness. The foundation positions the work as plumbing-layer infrastructure rather than a product launch, with Goose explicitly not intended as a production orchestration framework but as a way to validate interoperability and catch bugs before deployment.

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. 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: 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: 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: 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. ┌─────────────────────────────────────────────────────────┐ │ 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: 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. | 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: When to adopt MCP: When to adopt A2A: When to use Goose: When to avoid these standards: MCP and A2A assume agents operate in a trusted environment. The protocols do not enforce: Production deployments need additional layers: The foundation provides the wire protocol. You provide the security controls. 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: The standards do not solve observability. They give you the hooks to build it yourself. 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.