Open Responses Went Neutral. Your Agent Stack Still Won't Port

Last Updated: October 27, 2026

What actually changed in the week of 22 October

Four donations landed at once. The Agentic AI Foundation announced Agent Skills from Anthropic, Open Responses from OpenAI, OpenEnv from Hugging Face and OpenSandbox from Alibaba, bringing it to 10 hosted projects in its first year, up from the three it launched with in December 2025. They join A2A, Agent Router, agentgateway, AGENTS.md, goose and MCP under the same vendor-neutral governance.

The projects were deliberately chosen to cover different strata: how agents gain skills, how applications talk to models across providers, how agents are trained and evaluated, and where agents run safely. That framing is accurate, and it is also the source of the confusion. Four layers went neutral in one week, so the pitch collapsed into “the agent stack is now open”. It isn’t. Four of maybe nine layers went neutral, at four different levels of maturity.

Portability is not one property. Audit it layer by layer

The useful question is not “is this open?” but “if I swap the provider on Monday, how many lines change and how many behaviours change?” Those are different numbers, and the second one is the one that hurts.

Model interface: ports well, up to the tests that exist

Open Responses is a genuine piece of engineering. It models output as items, streaming as semantic events rather than raw deltas, and objects as state machines with a defined set of valid states. That is the right abstraction, and it is already implemented by Vercel AI Gateway and Databricks Model Serving, with support claimed across AWS Bedrock, Hugging Face, Nvidia, OpenRouter, Red Hat, LM Studio, Ollama and vLLM, per The New Stack’s reporting on the donation.

Now read the conformance suite. The acceptance tests cover basic text responses, system prompts, streaming SSE events, function tool calling, image input, multi-turn history, compaction, and a set of WebSocket continuation and recovery cases. That is the portability guarantee in full. Prompt-cache behaviour, reasoning-trace round-tripping, hosted tool parity, rate-limit header semantics, structured-output strictness and cost accounting are not in it. An implementation can pass every test and still behave differently from the one you built against on every axis that determines whether your agent finishes a task.

The spec is honest about this in a way the press coverage is not. It says an implementer is compliant if they implement the spec or a proper superset of it, and that extended item types — and any trajectory containing them — should not be assumed portable across other Open Responses servers. Provider-specific hosted tools get namespaced with an implementor slug and are explicitly outside the portable core. Which means a “compliant” endpoint is a floor, not a contract about your workload.

Skills and instructions: the text ports, the runtime does not

Agent Skills is the cleanest win of the four. A skill is a directory with a SKILL.md carrying name, description and instructions, plus optional scripts/, references/ and assets/, loaded through three-stage progressive disclosure: discovery on name and description, activation of the full instructions when a task matches, then execution. That is plain files in version control. It ports by git clone.

What does not port is everything that makes the skill fire. Discovery depends on the host’s matching implementation and on how the model weighs a one-line description against a crowded system prompt; the same skill library activates at noticeably different rates across models, and you only see it in aggregate. Bundled scripts assume an execution environment with a filesystem, an interpreter and permission to run — move the same skill to a hosted agent with no code execution and the instructions survive while the useful half silently doesn’t. Third-party support is arriving fast: TanStack AI 1.0 ships portable Agent Skills so any tool-calling model can load SKILL.md files. Treat that as format portability, not behaviour portability.

Eval environments and sandboxes: portable substrate, no policy

OpenEnv is a containerised service exposing an agent interface, MCP and the Gym training protocol. OpenSandbox gives you multi-language SDKs, unified sandbox APIs, Docker and Kubernetes runtimes, and a sandbox protocol defining lifecycle and execution APIs. Both are valuable and both are substrate. Neither carries your egress allow-list, your secret injection path, your data residency constraint or your per-tenant blast radius. The isolation primitive is now standard; the isolation policy is still a thing you write and maintain.

“four different companies chose to contribute them to neutral governance”

— Manik Surtani, CTO and co-founder, Agentic AI Foundation, Linux Foundation

The layers nobody donated

Here is the layer-by-layer audit I would put in front of a buyer. The right-hand column is the rebuild cost, and it is where the budget goes.

The bottom four rows are not an oversight by the foundation. They are application concerns that differ per business, so no spec can absorb them. But they are also where the engineering months go, and a “no lock-in” pitch built on the top five rows quietly implies the bottom four come along for free.

Two specifics worth naming. First, state: Open Responses supports server-side continuation via previous_response_id, and the conformance suite includes a store:false reconnect case that validates a previous_response_not_found error and a clean recovery path. If you let store default on, your conversation state now lives at the provider in a format nobody promised to export. The portable interface has hidden a non-portable store behind it.

Second, permissions. The spec does give you allowed_tools as a hard per-request constraint that servers must enforce, rejecting or suppressing calls to tools outside the list — genuinely useful, and it lets you narrow the menu without invalidating prompt caches. What it does not give you is where that list comes from: the tenant policy, the role model, the approval ladder for destructive actions. That is your orchestration layer, and it is the single largest body of code in every production agent I have built.

The swap test: one workflow, one adapter, count what breaks

Do not argue about portability in a design review. Measure it. Pick one workflow that is already in production, build a second provider adapter behind the same interface, and run both against the same fixtures.

Rules of thumb from running this: if the swap takes under a day, you never had meaningful coupling and the neutral layer saved you little. If it takes over three weeks, your abstraction is decorative and the portability claim in your doc is false. The useful middle is a few days of adapter work plus a prompt and eval pass — and that eval pass is the part teams forget to budget.

Where I would still write a provider-native adapter

The neutral layer is the right default for the boring 80%: text generation, streaming to a UI, function calling, multi-turn history, image input. Build there and the swap test comes back cheap.

I would still go native, deliberately and with the coupling documented, in four cases. When a provider-hosted tool is the product — computer use, deep research, native code execution — because the spec namespaces these as implementor extensions and tells you not to assume the trajectory ports. When prompt-cache economics decide the unit cost, because cache key behaviour under mid-conversation tool changes is where the margin lives and it is not conformance-tested. When you need reasoning traces round-tripped faithfully, since the spec permits providers to return opaque encrypted reasoning content whose format is provider-specific and which clients must treat as non-inspectable. And when latency targets are tight enough that an extra translation hop matters.

The honest version of the architecture decision is not “neutral or native”. It is: neutral interface for the common path, native adapters for the two or three capabilities you are deliberately coupled to, and a written note of what each coupling costs to unwind. We keep that matrix per provider on our model coverage page and revisit it whenever a lab ships a new hosted tool.

What to put in the architecture doc

Replace the phrase “no vendor lock-in” with four numbers: engineer-days to swap the primary model provider for your highest-volume workflow; the completion-rate delta you measured when you did; the list of vendor-extension features you depend on; and the name of the person who owns the thread store, the credential broker and the quota ledger. If any of those four is missing, the portability claim is aspirational.

Then be realistic about maturity. TanStack AI’s 1.0 is a good model of how to communicate this: the core APIs are stable and the agent harness ships as experimental 0.x with documented recovery limits, including in-memory child-agent waits that do not resume across hosts, and a note that its permissions plugin is not a sandbox. That is what an honest status line looks like. Most agent platform pitches you will hear this quarter do not have one.

The donations are good news. Shared schemas, a neutral TSC, a public conformance suite and a standard sandbox protocol all lower the cost of changing your mind later. They do not lower it to zero, and the gap between “lower” and “zero” is roughly the orchestration layer — which is exactly the part we end up building on every engagement. If you want the swap test run against your own workflow before the architecture doc gets signed, start here.