Comparison
AGNTCon + MCPCon 2026: A Selection Guide to the Agentic AI Foundation's Ten Projects
图示：来源页预览图（仅作编辑上下文；版权归属原发布方） · 来源引用：www.infoq.com
Every protocol eventually has to grow up in public. At AGNTCon + MCPCon North America 2026, the Agentic AI Foundation marked the end of its first year with ten projects under governance — four of them announced at the show: OpenSandbox, Open Responses, Agent Skills, and OpenEnv. Keynotes from Anthropic, OpenAI, Google, and UC Berkeley pointed at the same three anxieties: MCP running in production, MCP as an attack surface, and agents that carry their own identity rather than borrowing a human's credentials.
The headline is the project count. The actual story is the shape of the portfolio. One year in, the Foundation no longer looks like a single-protocol body. It looks like a stack — transport and tool-calling at the bottom, containment and identity around it, packaging and evaluation on top. That's good news for interoperability and mildly bad news for anyone who was hoping to make one architectural bet and be done.
This guide treats the four new projects as options rather than announcements, and asks the only question that matters for a team with a roadmap: which of these do you adopt now, which do you prototype, and which do you watch?
The four new projects, briefly
OpenSandbox is the containment layer. It addresses the moment an agent stops describing actions and starts executing them — running generated code, invoking tools with side effects, touching a filesystem. The value proposition is blast-radius reduction: a defined boundary where an agent can fail without taking production with it. If you have ever shipped an agent with a subprocess call and a prayer, this is aimed at you.
Open Responses is the portability layer. It standardizes the shape of agent/model output — tool calls, multi-turn state, streaming events, traces — so an interaction recorded against one vendor's API can be replayed, evaluated, or migrated against another. This is the least glamorous and most strategically consequential of the four, because it attacks lock-in at the data layer rather than the prompt layer.
Agent Skills is the packaging layer. It gives expertise a distribution format: a versioned bundle of instructions, references, and optional scripts that an agent loads on demand instead of carrying every domain rule in a monolithic system prompt. Think of it as the difference between "our prompt is 40,000 tokens" and "our agent has a skill it opens when a customer asks about refunds."
OpenEnv is the evaluation layer. It defines an environment interface for testing and training agents against reproducible tasks. Without something like this, every "our agent scores 87%" claim is unfalsifiable, because the harness is bespoke and the tasks are private.
A caveat worth stating plainly: all four are early. Specs are published and reference implementations are appearing, but the ecosystem around each is thin enough that the maturity column below should be read as directional, not certified.
Comparison table
| Project | Layer | What it actually gives you | Where it's thin | Security surface | Adopt if… |
|---|---|---|---|---|---|
| OpenSandbox | Execution | Isolation boundary for agent-run code and tool calls | Runtime maturity, escape hardening, ops tooling | High — it is the control | Your agent executes anything it generated |
| Open Responses | Interop | Vendor-neutral schema for outputs, tool calls, traces | Adapter coverage across providers | Low — but it is where audit logs come from | You run multi-vendor or need replayable traces |
| Agent Skills | Packaging | Versioned, loadable capability bundles | Supply-chain review, signing, registry norms | Medium — third-party content in your prompt path | Your prompt is outgrowing maintainability |
| OpenEnv | Evaluation | Reproducible task environments for testing/training | Task libraries, scoring norms | Low | You cannot defend your eval methodology |
| MCP (incumbent) | Transport/tools | The substrate everything else plugs into | Authorization ergonomics | Very high — see below | Always. This is the baseline, not an option |
The criteria that should drive the decision
Four dimensions separate a real adoption from a conference-driven one.
| Criterion | Weight | The question to ask |
|---|---|---|
| Irreversibility of failure | Highest | If this component misbehaves, can it corrupt data, spend money, or leak a secret? |
| Time-to-first-value | High | Can one engineer get a working prototype inside two weeks? |
| Vendor neutrality | Medium-high | Does adopting it reduce or increase your switching cost in 18 months? |
| Governance maturity | Medium | Is there a real maintainer group, or one company's roadmap with a logo? |
Note the inversion: the least exciting project often scores highest. OpenSandbox and Open Responses win on irreversibility and neutrality. Agent Skills wins on time-to-first-value but loses on governance, because the hard problem isn't the format — it's reviewing what strangers put inside it.
Recommendation by scenario
You are shipping a customer-facing agent that runs code. Adopt OpenSandbox now, before the feature ships. Pair it with egress restrictions and a hard timeout. This is the one case where "wait for the spec to settle" is the wrong answer, because the incident you're preventing doesn't wait either.
You have agents across two or more model providers. Prototype Open Responses. The near-term win isn't migration, it's observability: one trace schema means one dashboard, one eval harness, one incident review. Migration optionality is the bonus.
Your prompt library has become an unmaintainable monolith. Adopt Agent Skills with a private registry and mandatory review. Treat every skill as third-party code, even the ones your own team wrote, because six months from now you won't remember who did.
You are being asked to prove your agent is good. Adopt OpenEnv. Internal benchmarks decay into folklore surprisingly fast, and a standardized environment is the cheapest defense against an evaluation you can't reproduce.
You are still getting MCP into production at all. Adopt none of the four yet. Harden the MCP deployment first — see below. Bolting a sandbox onto an unauthenticated tool surface is decorating a house with no locks.
You are in a regulated environment. Sequence it: Open Responses first (audit trail), OpenSandbox second (containment), OpenEnv third (evidence), Agent Skills last (supply-chain review burden). Governance review will be your bottleneck, not engineering.
图示：HEXOPS 原创配图（受选题启发，非复制原文图片） · 来源引用：www.infoq.com
MCP's turn to security is the real agenda
The reason the security track dominated the conference is that MCP's threat model did not exist when the protocol was drafted. It does now, and it is uncomfortable. Tool descriptions are executable influence — a malicious server can smuggle instructions into the text an agent reads as documentation. Delegation chains invite confused-deputy problems where a privileged agent is talked into acting on a lower-privileged caller's behalf. Broad scopes get granted once and inherited forever. And third-party MCP servers are a supply chain that most organizations currently install with the same rigor they apply to a browser extension.
The "agents with their own identities" thread from the Anthropic, OpenAI, Google, and UC Berkeley keynotes is the structural answer. An agent that authenticates as itself, with its own narrow scopes and a delegable, revocable credential, is auditable in a way an agent running on a borrowed API key never will be. That shift — from "the agent acts as the user" to "the agent is a principal" — is more consequential than any single spec in the ten-project list.
Which reframes the four new projects neatly. OpenSandbox bounds what an agent can do. Open Responses records what it did. OpenEnv lets you verify what it does under test. Agent Skills defines what it can pick up. Identity, notably, is the gap: there is no OpenIdentity in this cohort, and until there is, that layer stays vendor-specific.
A ninety-day plan
Weeks 1–2: inventory every MCP server in your stack and every scope you've granted. This is unglamorous and finds most of your problems. Weeks 3–6: prototype OpenSandbox behind one non-critical agent, and Open Responses as your trace schema for a single workflow. Weeks 7–10: write two internal Agent Skills with mandatory review, and stand up one OpenEnv environment for your highest-stakes eval. Weeks 11–13: decide, in writing, which of the four you are not adopting this year and why. A selection guide you never disagree with isn't a guide.
The Foundation shipping ten projects in twelve months is impressive. It is also a warning: the surface you're expected to evaluate is growing faster than your capacity to evaluate it. Pick by blast radius, not by announcement date.
Sources
- Primary: Hoblitzell, Andrew. "AGNTCon + MCPCon 2026: Agentic AI Foundation Adds Four Projects as MCP Turns to Security." InfoQ, October 2026. https://www.infoq.com/news/2026/10/agntcon-mcpcon-2026/
- Background: Model Context Protocol specification and security guidance — https://modelcontextprotocol.io
- Background: Agentic AI Foundation project listings and governance documentation (consult directly for current maturity status of OpenSandbox, Open Responses, Agent Skills, and OpenEnv)
- Note: Vendor keynotes referenced (Anthropic, OpenAI, Google, UC Berkeley) are summarized from conference coverage; consult primary recordings for exact claims.
