Open Responses joins AAIF with a new governance charter

Open Responses has joined the Agentic AI Foundation, giving the project a foundation home for its shared model API specification. The Linux Foundation announced the addition on October 22, alongside Agent Skills, OpenEnv and OpenSandbox. OpenAI contributed Open Responses. This is a governance milestone, not the launch of a new model or a replacement for every provider’s API.

For developers, the useful question is whether a common interface makes applications easier to move between providers. Foundation stewardship addresses how that interface evolves. It does not remove the need to check the features, failures and model behavior that an application depends on.

What the new charter changes

The technical charter adopted October 21 establishes Open Responses as a series of LF Projects, LLC. Maintainers initially form its voting Technical Steering Committee. Meetings are intended to be public. Decisions seek consensus, with specified voting and escalation procedures when needed.

The charter assigns project trademarks to LF Projects or an associated host. Contributors retain copyright in their work. It specifies Apache 2.0 for code and CC BY 4.0 for documentation, with a process for license exceptions. Charter amendments need two thirds of the entire committee and LF Projects approval.

The current contribution file lists nine initial voting maintainers across OpenAI, Databricks, Amazon, Hugging Face, Ollama, OpenRouter and Ramp. Those are named individuals, not a promise that every company using the specification has a voting seat.

A common interface is not a common model

The project overview describes a shared schema for calling language models, streaming results and composing agent workflows. Items represent model output and tool use. The design leaves room for provider specific features rather than forcing every capability into the common core. Its aim is less translation between interfaces, not identical behavior from different models.

This work predates the foundation announcement. The published changelog records the initial specification on January 15 and an April 24 release adding WebSocket transport, compaction and message phase fields. No October specification release appears on that page. Those existing features should not be described as newly shipped by the governance change.

Our Agent Skills governance and portability coverage addresses a different part of the same problem. Skills package instructions and resources for agents. Open Responses concerns the interface through which applications call models. A portable instruction package and a compatible API contract solve different integration tasks.

How developers can propose changes

The contribution process asks for a problem statement, a proposed specification change, compatibility impact and a conformance test plan. After initial feedback, contributors can submit a pull request with documentation and tests. Published releases include dated schema and prose snapshots that are immutable. That gives implementers a specific version to target rather than only a moving website.

What the acceptance tests can tell you

The acceptance test page currently lists ten browser tests and seven CLI tests. They cover areas including response schemas, streaming events, function calls, image inputs and compaction. The CLI cases also exercise WebSocket continuation and recovery after reconnecting. The page asks for the endpoint, model and authentication details needed to run checks against an implementation.

The repository documentation describes the same suite for local use and continuous integration. Each HTTP request, including its response body, has a thirty second deadline. WebSocket connections and individual turns use that deadline too. A timeout fails the affected test while others continue. These are documented test rules, not latency measurements from ByteForward.

Treat a passing contract test as evidence about that contract, not a guarantee of answer quality. An application can accept the same response shape from two models while receiving different tool arguments or different substantive answers. This article does not report running the suite or validating a provider.

A practical migration checklist

Before changing providers, choose the dated specification your client expects and list the features your workflow actually uses. Check streaming completion, tool result handling and reconnect behavior. Then run representative tasks with the intended model and compare the outputs your application needs, rather than relying on a compatibility label alone.

The governance change gives teams a public process to follow when a shared contract needs to evolve. Deployment remains a separate decision. Keep interface checks, model evaluations and access permissions distinct so that a successful schema check is not mistaken for approval to run an agent with production tools.

Generated editorial illustration for ByteForward with the Open Responses name. Symbolic hardware, not a product photograph. Project owners retain trademark rights. No endorsement.