The Open Agent Stack Arrives: A2A, MCP, and AGNTCY

2025 quietly became the year agents learned to collaborate

If you work on AI inside a large company, you probably felt it rather than read it on a splashy billboard. Over a nine-week stretch, a practical open stack for agent interoperability slipped into place. On June 23, 2025 the Linux Foundation announced the Agent2Agent project, a protocol that lets agents from different vendors find each other, exchange context, and coordinate work without sharing their private internals Linux Foundation launches the A2A project. On July 29, the Foundation welcomed AGNTCY, a shared infrastructure layer for discovery, identity, messaging, and observability across multi-agent systems Linux Foundation welcomes the AGNTCY project. Then on August 25, Solo.io’s agentgateway was accepted, giving the ecosystem a purpose-built data plane for agent protocols. Put together with the already popular Model Context Protocol from Anthropic, the stack looks less like a science project and more like the next enterprise network.

We can now say out loud what many teams have been quietly shipping: interoperable agents are here. They are not perfect and the specs are still maturing, but the connective tissue exists and is open.

The stack, in plain language

Think of multi-agent work as a mixed team of specialists. To solve a customer’s billing dispute, you might need a finance agent to read invoices, a support agent to parse transcripts, and a data agent to join customer tables. Each is built by a different group, often using different vendors or frameworks. The open stack gives them a way to cooperate safely.

Agent2Agent protocol (A2A): the lingua franca for agent-to-agent messaging and task coordination. Agents can be opaque. They do not expose their internal tools or prompts. Instead, they publish a short description of who they are and what they can do, then exchange structured messages and task updates. A2A is the switchboard.
Model Context Protocol (MCP): how an agent talks to tools and data sources. An MCP server makes a capability available, like querying a ledger or posting a ticket. The agent, acting as an MCP client, calls the server with structured inputs and receives structured outputs. MCP is the universal adapter to real systems. For why modularity matters at the skill level, see Claude Agent Skills and modular design.
AGNTCY: shared infrastructure that enterprises can run or consume to handle cross-cutting needs. It covers discovery, identity, secure messaging, routing, and observability for multi-agent systems. Think of it as the control plane for an Internet of Agents.
agentgateway: a protocol-aware data plane, built to understand A2A and MCP, apply policy, and collect telemetry with low overhead. It fits where you would put an API gateway or service mesh waypoint, but it speaks agent dialects. For orchestration implications, compare with GitHub Agent HQ orchestration insights.

Together, these layers mirror the early internet stack. MCP plays the role of clean plug points, A2A is the routing and conversation layer among complete applications, and AGNTCY plus agentgateway provide the policy and transport scaffolding that operations teams need.

Why this favors modular builders over monoliths

Monolithic agents feel convenient at the start. One big brain, one vendor, one bill. In production, the tradeoffs accumulate fast.

Change cost: monoliths force you to redeploy the whole system when you only need to upgrade a capability. Modular agents let teams ship upgrades to one MCP server or swap one agent behind an unchanged A2A endpoint.
Compliance isolation: permissions and audit scopes can match the actual work. An MCP server for payments can run with least-privilege tokens and full audit, while a content summarizer uses a different policy. With A2A, the collaborating agents do not need to inherit each other’s secrets to coordinate. That reduces blast radius.
Talent focus: teams can specialize. Your data platform group owns two or three MCP servers. Your support engineering team owns the triage agent. Your finance engineering team owns the reconciliation agent. A2A binds them into a single workflow without centralizing ownership.
Vendor leverage: when the protocol is the interface, vendors compete on implementation quality, not on lock-in. You can swap an MCP server or an entire agent and keep the rest of the system running. Security layers can harden these swaps with guardian agents and AI firewalls.

If you remember the move from application servers to microservices, this will feel familiar. The value shifts to those who design clear module boundaries, invest in interfaces and policy, and ship small, safe changes often.

What your team can ship this quarter

You do not need a replatform to benefit. Here is a pragmatic four-part plan that fits into a normal quarter and builds reusable foundations.

1) Publish Agent Cards for the agents you already have

An Agent Card is a small JSON document that describes an agent’s identity, capabilities, preferred transport, and endpoint. It lives at a predictable path so other agents can discover it. Start by giving each production agent a stable identity and a published card.

Where to put it: host at a well known path such as /.well-known/agent.json behind HTTPS.
What to include: name, description, endpoint URL, preferred transport, skills, required authentication schemes, and contact.
How to secure it: do not embed secrets. If cards reveal internal agents, place the path behind network policy and authentication.

Example Agent Card skeleton:

{
  \"protocolVersion\": \"0.2.x\",
  \"name\": \"Invoice Reconciliation Agent\",
  \"description\": \"Matches purchase orders, invoices, and payments across systems and flags discrepancies.\",
  \"url\": \"https://agents.acme.com/a2a/recon/v1\",
  \"preferredTransport\": \"JSONRPC\",
  \"skills\": [
    {\"id\": \"reconcile\", \"description\": \"Reconcile an invoice with a purchase order and payment\"},
    {\"id\": \"explain\", \"description\": \"Explain a mismatch with source references\"}
  ],
  \"authentication\": {
    \"schemes\": [
      {\"type\": \"oauth2\", \"scopes\": [\"recon.read\", \"recon.write\"]}
    ]
  },
  \"contact\": {\"email\": \"agents@acme.com\"}
}

Ship list:

Create a repository for Agent Cards with review gates and linting.
Add a card to each agent’s automated release. Reject builds that forget to update the version or required scopes.
Stand up a simple internal page that lists agent names and links to their card URLs. This becomes your first A2A directory.

2) Stand up two MCP servers that wrap real business systems

Pick one system of record and one system of engagement. For example, a ledger database and a ticketing system. Implement a minimal read-plus-write surface with clear, typed inputs and outputs.

Use OAuth for authentication and require scopes that match the smallest possible action set.
Implement structured outputs. Agents should not parse free text to find an identifier.
Add metrics from day one. Emit request counts, error rates, latency percentiles, and per-scope authorization decisions.

Ship list:

A deployable MCP server container for each system.
A client quickstart that shows a single happy path and a failure path.
A policy document listing which agents can call which methods with which scopes.

3) Build a lightweight A2A directory for discovery and routing

You do not need a global registry to get started. Stand up a simple service that indexes Agent Cards, validates required fields, and exposes a search endpoint for your organization.

Start with a catalog that only your primary assistant agent uses. It should be able to answer: which agent handles reconciling invoices, which agent handles ticket classification, which supports streaming.
Validate cards on ingestion. Reject or quarantine cards with missing fields or mismatched transports. Quality here prevents a lot of runtime pain.
Cache and revalidate on an interval so you can catch changes in capabilities and authentication requirements.

Ship list:

A service that crawls known domains for /.well-known/agent.json and stores the parsed result.
A small admin dashboard for approvals and status.
A client library that picks an agent by skill id and returns an endpoint and auth scheme.

4) Wire in observability and identity from the start

Agent systems fail at the edges. The fastest way to avoid week-long outages is to instrument the control and data planes early.

Identity: use OpenID Connect for end users and workload identities for agents. Propagate identity across A2A calls using transport layer standards. Terminate tokens at the boundary and issue scoped downstream credentials as needed.
Transport security: require TLS 1.3 for all agent and MCP traffic. Prefer mutual TLS for internal hops. Rotate certificates automatically.
Tracing: adopt OpenTelemetry. Assign every A2A task an id and carry it through agent hops and MCP calls. Record who requested what, what tools were invoked, and what scopes were used.
Policy: define least privilege by default. For MCP, set method-level scopes. For A2A, authorize by skill id and caller identity. Deny by default and add allow rules as you onboard use cases.

Ship list:

A per-request audit event that includes agent caller, target, method, scopes, task id, and outcome.
Dashboards that show top failing skills, slow MCP methods, and A2A retry loops.
A weekly review where you prune unused scopes and rotate keys.

A reference flow: employee onboarding across vendors

Picture a new hire onboarding flow with four independent parts.

HR agent: owns forms, benefits enrollment, and policy acknowledgements. Talks to an HR system via MCP.
IT agent: provisions accounts and devices. Talks to identity and configuration systems via MCP.
Finance agent: sets up payroll and expense limits. Talks to a finance system via MCP.
Assistant agent: the user-facing orchestrator that receives the user’s request, delegates to other agents over A2A, and stitches the results into a single experience.

Here is how the open stack simplifies the mess:

Discovery: the assistant agent queries your A2A directory for skills named onboard.start, it.findings, and payroll.setup. It receives three Agent Cards with endpoints and auth schemes.
Coordination: the assistant sends an A2A message to the HR agent to start onboarding and subscribes to task updates. The HR agent calls its MCP servers for forms and policies. When device setup is needed, the HR agent emits a handoff message that includes a task id and a requested skill. The IT agent accepts and proceeds.
Security: the assistant never sees the HR system’s tokens. Each MCP call is scoped to the method invoked. A2A calls carry caller identity, and policy allows handoffs only for allowed skills and roles.
Operations: traces show a single task id passing through four agents and six MCP calls. An operator can see that IT is waiting on an HR form signature and why.

The human outcome is the simplest part. The employee fills in one form, sees updates appear in their assistant, and gets a laptop on day one.

The governance reality check

Two pieces of this stack, A2A and AGNTCY, now live under Linux Foundation governance. MCP remains an independent open protocol that is widely implemented and supported. This split is healthy. It reduces the chance of a single vendor controlling the whole flow. It also means you should plan for version drift. Treat protocols like you treat APIs.

Practical steps:

Pin protocol versions in code and in Agent Cards. Upgrade in controlled rollouts.
Keep adapters small. Put transport and message parsing at the edges, then translate to internal types.
Track deprecations and allocate capacity for spec changes each quarter.

How to buy and how to ask vendors the right questions

As you procure tools or renew contracts, favor products that plug into the stack without custom glue. Ask vendors to show, not tell.

Do you publish a valid Agent Card for your agent or assistant product, with a stable endpoint and transport that we can test in staging?
Which MCP servers do you provide, and which are community supported? Show a method list with request and response types.
Can your agent accept A2A tasks from our orchestrator and emit handoffs to our internal agents? Provide a demo with identity and policy configured.
How do you export telemetry? Show OpenTelemetry traces that carry our task id across your components.

These questions separate products that embrace interoperability from those that market it.

Why this sets up the TCP and IP moment for agents

In the early internet, small, focused protocols did the heavy lifting. Transmission Control Protocol and Internet Protocol were not monoliths. They were thin layers that made it possible for very different systems to send packets reliably. Everything else grew on top: the web, email, streaming.

A2A is not trying to be an agent brain. MCP is not trying to be an application runtime. AGNTCY and agentgateway are not trying to be your entire platform. They are the connective rules and roads. As more enterprise agents speak these protocols, markets will reorganize around capabilities that can be discovered, invoked, and composed.

The near-term implication is clear. You can stop waiting for a single vendor suite to catch up with your use cases. You can start publishing Agent Cards, standing up small MCP servers, indexing a directory, and observing everything. Each step pays for itself. Put these pieces together and your agents will begin to find one another, negotiate tasks, and coordinate across business and vendor boundaries.

The longer-term implication is bigger. Once agents can find and trust each other, whole categories get simpler. Integration projects shrink. New entrants can offer a single powerful skill without selling a platform. Compliance teams get better audit trails by default. And users get software that feels cohesive even when it comes from many places.

A smart close for a pragmatic year

No single announcement made 2025 the year of agent interoperability. A series of practical moves did. Open specification work, donated code, and neutral governance gave enterprises permission to build. The right bet now is not a monolith. It is a playbook that assumes many agents and many vendors, stitched together by open protocols. Ship the four pieces above and you will feel the network effect kick in. When you can swap an agent like you swap a network card, you know the stack is real. That is how the Internet of Agents starts: with small, concrete steps that make the next step obvious.