If you build agents for a living, three pieces of news from the same fortnight should change how you plan your next quarter — not because any of them is a product you'll buy, but because together they close out a whole class of integration work you were doing by hand.
First: the Agent2Agent protocol — Google's standard for agents talking to other agents — is moving into the Agentic AI Foundation, the same home as MCP, where it will sit beside the protocol that connects agents to tools and data. The foundation has grown from fewer than 40 members at its December 2025 launch to more than 250, with Google, Microsoft, Amazon, Anthropic, OpenAI, Bloomberg, Shopify and Block among the backers. (Axios)
Second: GitHub published Agent Plugins 1.0 — an open standard that packages agent skills and MCP server configuration into one installable plugin that works across VS Code, Copilot CLI and the Copilot app. It shipped with AWS, Anysphere, Microsoft, OpenAI and Vercel, with Google joining as a core maintainer, and it pairs with enterprise MCP allowlists so administrators can approve or block individual servers. (The GitHub Blog)
Third: the MCP 2026-07-28 specification made the protocol fully stateless — servers can now run in a single Worker with no sticky sessions, no held-open streams, no replay machinery. (Cloudflare Blog)
Put together, the message is unambiguous: agent-to-tool connectivity and agent-to-agent connectivity are commoditizing. The protocol wars in those layers are ending in the usual way — a foundation, a spec, and a package format.
The diagram everyone can now draw
The industry has converged on a picture like this:
models → skills/plugins → MCP tools/data → A2A agent coordination → retrieval → context → governance → execution → observability → outcomes
Two of those arrows — tools/data and agent coordination — just got standards bodies and package managers. That's genuinely good news. It means the integration tax you've been paying to wire one agent to one tool, and one agent to another, is going the way of hand-rolled SSL stacks.
But look at the middle of the diagram. Between "retrieval" and "execution" sit two words that stayed open this month: context and its governance. (Action governance had a busy week — Cloudflare's Agent Access Model task-scopes what an agent may do — but governing what an agent may know, and whether what it knows is still true, is a different axis, and nobody standardized that.)
Why connectivity standardization makes the context problem worse
Standardized connectivity is a multiplier on context flow, not a guard on it. Once any agent can talk to any tool through MCP, and any agent can delegate to any other agent through A2A, the number of paths along which a piece of organizational context can travel explodes — while the mechanisms deciding what may travel, when it was true, and who was allowed to see it stay exactly as manual as they were last year.
Consider what a standardized plugin actually carries: a skill, and the MCP configuration that connects it to your systems. The spec governs the packaging and the allowlist. It says nothing about the facts the skill will read — whether the record it retrieves was superseded yesterday, whether the customer's phone number is still consented for outreach, whether the "approved budget" the agent is about to cite was approved for this purpose or just a purpose.
That's not a criticism of the plugins spec, or of A2A, or of stateless MCP. They're each solving the problem they set out to solve. It's an observation about layer boundaries: connectivity is a protocol problem, and protocols standardize well. Context is a contract problem, and contracts don't standardize — they get governed.
A context contract has to answer questions a transport never sees:
- Provenance — where did this fact come from, and does the source still stand behind it?
- Temporal validity — when was this true in the world, and when did the system learn it? The newest fact is not automatically the governing one.
- Scope — this agent, for this task, may see this much. Tool permissions don't imply context permissions; an agent authorized to call a CRM API still has no business reading every record in it.
- Delivery history — what was actually sent to which agent, and what happened because it was sent?
None of those are fields in a plugin manifest. All of them are the difference between an agent stack that's merely connected and one an organization can trust.
What we'd tell a team building on this stack today
- Adopt the standards for what they standardize. MCP for tools, A2A as it matures for agent-to-agent, portable plugins for packaging. Fighting connectivity commoditization is wasted motion.
- Don't confuse the allowlist with the boundary. An MCP allowlist governs which servers an agent may call. It cannot govern which facts the agent may act on — that's a layer up, and it's yours.
- Design context as a contract, not a cache. A shared memory that any agent can read is the naive version of this layer. The version that survives audit answers provenance, validity, scope and delivery for every fact it serves — before serving it.
The connectivity layers just got boring, in the best way. That's precisely what makes the un-standardized middle the most defensible place left to build.
Northsun is the memory and enrichment layer for AI agents. Every agent proposes. Northsun governs.
Choose Northsun as your agent memory layer.