Neutral Is Not Ready: The Agentic AI Foundation's Five Projects

Five donors, one owner

If you are choosing what to build an agent on this quarter, something changed this week. On 17 August 2026 Google’s Agent2Agent protocol became a hosted project of the Agentic AI Foundation. That completes the set. Anthropic donated the Model Context Protocol. Block donated goose, its local agent. OpenAI donated AGENTS.md, the instruction file coding agents read. Solo.io donated agentgateway. Now Google has donated the protocol agents use to hand work to each other.

Three of those donors sell competing frontier models. The other two sell infrastructure that has to work with all of them. They have handed five pieces of one stack to a body founded in December 2025 under the Linux Foundation, where Amazon, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI all hold platinum membership. The governing board is chaired by AWS, and the technical committee is chaired by David Soria Parra, one of MCP’s creators, who works at Anthropic. That last detail is worth holding on to: the most mature project in the foundation is also the one whose author chairs its technical committee, and the reason to trust it anyway is that its evidence is public and checkable, not that its governance looks neutral.

For a team deciding what to build on this quarter, the interesting question is not that this happened. It is what it changes, and the honest answer is narrower than the announcements suggest. Neutral governance answers who owns the project. It says nothing about whether the project is ready.

What a donation actually buys

Something genuine changes here, and it is worth naming precisely. Before the donation, MCP was Anthropic’s project. If Anthropic’s strategy had moved, the specification, the trademark and the reference implementations would have moved with it. After the donation, the specification sits with a foundation whose board includes that vendor’s competitors, and the license and trademark are held somewhere no single member controls.

That matters most for the decision nobody enjoys defending: writing a protocol into a product roadmap two years out. The risk that a competitor’s protocol gets deprecated because its owner changed direction is a risk you cannot mitigate with engineering. Moving the project to a foundation retires that particular risk and leaves two ordinary ones behind: the specification may evolve in a direction you dislike, and a donated project can still lose its maintainers when the donor’s reason to staff it fades. Both of those you can at least watch in public.

The press release does not say what membership fails to buy. Projects enter through a public proposal process that examines governance, licensing and community, and nothing in it asks whether the software works in production. There is no maturity review, no support contract, and no requirement that a second implementation exists. If you have been waiting for a neutral home before adopting one of these, the wait is over and the work is unchanged: read the specification, check who else has implemented it, and try it against your own system.

One project per layer

Put the five side by side and they look like a stack. AGENTS.md is what the agent is told about your repository. goose is a runtime an agent runs inside. MCP is how it calls tools. agentgateway sits in front of that traffic and applies policy. A2A is how one agent hands work to another.

Neat, and mostly a coincidence. Five organizations donated five projects for five reasons, and the foundation commissioned none of the layers. The tiling is loose where it matters: goose is itself an MCP client rather than a layer above it, agentgateway is a proxy for the other protocols rather than a peer of them, and MCP and A2A overlap enough that their communities argue in public about where a tool call ends and a delegated task begins.

The seams are where the work sits. Each project has authorisation work of its own; none of them specifies what happens between them. Take one case: a person starts a task, an agent delegates it over A2A, and the agent on the other side makes an MCP tool call three hops later. Whose identity arrives at that call, and what a gateway policy should do when the delegated task comes back asking a question, is written down nowhere. Those are the decisions each team still makes for itself, and shared ownership does not settle them.

Which ones to build on now

The five are not equally ready, and the useful question is which of them earns a place in your stack this quarter.

MCP is the one to bet a product on. It is the only one of the five with a dated revision history, and its July 2026 revision was substantial: requests became stateless, an extensions framework arrived, and the tier-one SDKs shipped support on the day it landed. It has a registry, still in preview, and the widest client support of anything here. If you are exposing your systems to agents this year, this is the surface. The risk you take is that a young specification keeps moving under you, and its new deprecation policy bounds that to a twelve-month window.

AGENTS.md costs nothing, so adopt it today. It is a Markdown file at the root of your repository that coding agents read before they work. There is no runtime, no dependency and no lock-in, and adoption costs an afternoon. Maintenance is where it gets expensive, because a stale instruction is not ignored, it is obeyed. What belongs in the file, and what the measurements say about the parts most people write, is an argument of its own.

A2A is real and narrower than it sounds. The specification reached 1.0 in March 2026, the foundation counts more than 150 organizations behind it, and IBM folded its competing delegation protocol into it a year ago. That is a healthy project. The question it answers is how an agent that belongs to you hands a task to an agent that belongs to somebody else. There is a real case for it inside one company too: agent cards give you discovery when teams build on different frameworks, and the task lifecycle handles work that waits, fails halfway or comes back asking a question. Weigh that against what you already run, because for a single team on a single framework, a job queue does the same work with fewer moving parts. Adopt A2A when the agent on the other side is outside your control, or when it is built by people who did not choose your stack.

goose and agentgateway answer questions you may not have asked yet. goose is a local-first agent that runs on your machine and extends through MCP servers, which is a genuine position rather than a me-too product: the work stays local, the extensions are the same ones your other tools speak, and Block runs it at its own scale. It competes with the coding agents your team already pays for, so choose it on that comparison and not on its address.

agentgateway is the one I would argue about hardest, because the case for it is stronger than its position in this list suggests. It mediates traffic between agents, models and tools, and applies policy and observability at that boundary. My own view is that a gate belongs in the permission system rather than in a prompt, and a gateway in front of your MCP servers is exactly such a place. So the honest version is not “wait until you have many agents”. It is this: if your first production MCP server is exposed to anything you do not control, the boundary needs an owner, and a gateway is one credible way to give it one. What you should not do is stand one up because it shares a foundation with MCP, and then discover you are operating a component whose policy nobody has written.

What to watch next

Two things about this foundation deserve a European reader’s attention more than the project list does. It runs eight working groups, and one of them works on governance, risk and regulatory alignment, including mapping to the EU AI Act. Specifications that arrive with regulatory mapping attached are worth more to a company that has to answer an auditor than the same specifications with better benchmarks.

The second is the registry question. MCP’s registry is still in preview, and until a project has a place where implementations are listed, verified and namespaced, every adoption decision is somebody reading a README and hoping. Watch whether the foundation extends that discipline across its projects, because a catalogue with verified provenance is the thing that turns five donations into something you can plan around.

None of this changes what you do on Monday. Put AGENTS.md in the repository, build the tool surface on MCP, and leave the other three until you meet the problem each one solves. What the foundation took off the table is the risk that a vendor walks away from a protocol you already shipped. What it left is the risk that was always yours: whether this works on your data, at your volume, with your auditor in the room.