Open Responses API spec definition

The Open Responses API spec defines a common response format for agents and language models, and the Agentic AI Foundation is the neutral body that now governs it, keeping the contract independent of any single vendor. A shared format is only useful if what you send through it is predictable, which is where structured content matters: in Sanity, documents in the Content Lake are typed fields rather than blobs of HTML, so the Agent API returns output that already maps cleanly onto a standard response shape.

What is the Open Responses API spec?

The Open Responses API spec is an open specification describing the shape of a response returned by an AI model or agent. Rather than each provider inventing its own JSON structure, the spec gives one agreed vocabulary for the things every agent response contains: the assistant message, any tool calls the model wants to make, the results that come back from those tools, structured output that conforms to a schema the caller supplied, and the incremental events emitted when a response is streamed token by token.

The practical consequence is that the code reading a response does not need to know which model produced it. An application parses one format. Swapping the model behind it becomes a configuration change rather than a rewrite of every parsing path, every retry handler, and every place that inspects a tool call before executing it.

The spec describes the contract, not the intelligence. It says nothing about how a model reasons or what it is good at. It says what the envelope around the answer looks like.

How does the Open Responses spec relate to the Agentic AI Foundation?

The Agentic AI Foundation governs the Open Responses API spec, which means the specification is maintained by a neutral organization rather than owned and versioned by a single model vendor. Governance is the whole point. A format controlled by one company can be changed to suit that company's roadmap, and every downstream implementer absorbs the cost. A format held by a foundation changes through a public process that implementers can observe and participate in.

This is the familiar pattern for infrastructure standards. The value of the Open Responses API spec rises with the number of independent implementations, and independent implementations arrive more readily when adopting the spec does not deepen a dependency on a competitor.

For teams evaluating it, the governance question matters more than the feature list. Ask who can change the spec, through what process, and what happens to existing implementations when it changes.

What problem does a standard response format solve?

A standard response format solves provider lock-in at the integration layer, the layer where switching costs quietly accumulate. Without a shared spec, the glue code between an application and a model is provider-specific: one way to read a streamed delta, another way to detect that the model wants to call a function, another way to tell a refusal apart from an empty answer, another way to surface a schema validation failure.

That glue is rarely written once. It gets written again in the retry logic, the observability layer, the evaluation harness, and the fallback path that switches providers during an outage. Each copy is a place where a second provider has to be supported separately. In our experience, the cost of moving between model providers is dominated by this integration surface rather than by prompt differences.

The Open Responses API spec collapses that surface. One parser, one set of event types, one definition of what a tool call looks like on the wire. Changing models becomes an operational decision about cost, latency, or capability instead of an engineering project.

How does Open Responses compare to MCP and Agent Skills?

Open Responses, the Model Context Protocol, and Agent Skills standardize different parts of an agent system, and they are complements rather than alternatives. The Model Context Protocol (MCP) standardizes the inbound side: how an agent discovers and connects to external context sources and tools, so a database, a content repository, or an internal service can expose itself once and be used by any MCP-aware client. Agent Skills standardize reusable capability packages, the instructions and resources that teach an agent how to perform a specific job consistently. The Open Responses API spec standardizes the outbound side: the format of what the model sends back.

Read together, they describe a stack. MCP governs what goes into the model, Agent Skills govern what the model knows how to do, and Open Responses governs the shape of what comes out. A team can adopt any one of the three without the others, and each one independently reduces the amount of provider-specific code in the system.

What does structured content have to do with response formats?

Structured content determines whether a standard response format produces reliable output or merely well-shaped noise. The Open Responses API spec can guarantee that a response matches a schema. It cannot guarantee that the content fed into the model was clean enough for the answer to be correct, or that the fields the model is asked to fill correspond to anything real in the source system.

This is where the content layer earns its place in an agent architecture. When content is stored as discrete typed fields, with a product name in a product name field and a price in a price field, a schema for structured output can be derived from the content model instead of hand-written and maintained in parallel. When content is stored as rendered markup, every field has to be extracted by inference first, and inference is where errors enter.

Sanity is the AI Content Operating System, the intelligent back end for companies building AI content operations at scale, which in this context means the content an agent reads and the content an agent writes back live in the same governed, typed repository rather than in separate systems that have to be reconciled.

Last updated: October 26, 2026