Open Responses arrives at the AAIF: fewer ties between AI providers

The fragmentation of language model APIs is one of those problems that doesn't show up in sales presentations, but that consumes hours of work in any technical team. OpenAI has decided to make a move: it donates its Open Responses specification to the Agentic AI Foundation (AAIF), the umbrella promoted within the Linux Foundation that already hosts projects such as MCP, A2A, AGENTS.md, goose, agentgateway or Agent Router. The news was broken by The New Stack and, beyond the headline, it has very concrete implications for anyone who develops or maintains software in an SMB.

What Open Responses is and why it matters

The underlying idea is simple to explain and complicated to execute: almost all LLM providers already offer the same basic building blocks (messages, tool calls, function calling, etc.), but each one represents them in its own way in its API. The result is that changing models means rewriting integrations, maintaining adapters per provider and accepting that part of the code will remain tied to a specific vendor.

Open Responses proposes a set of common API calls that work across providers. It is not a model or a product: it is a specification. And that nuance is key, because its value depends on as many players as possible adopting it.

Who supports it and who stays out

The initial backing is broad. According to the published information, there are already implementations or declared support from AWS (in Bedrock), Databricks, LM Studio, Ollama, Hugging Face, Nvidia, OpenRouter, Red Hat, Vercel, as well as open source projects such as vLLM and OGC (formerly Llama Stack). Vercel AI Gateway and Databricks Model Serving already implement it, which gives a practical signal: it is not just a statement of intent.

The absences also say a lot. Anthropic, OpenAI's direct rival, keeps its own Messages API, and Google has its Interactions API. Anthropic is a member of the AAIF, so the door remains open to future adoption, but today it is not on the list. The project's own contribution guide acknowledges that the core schemas were copied from the OpenAI API, something worth keeping in mind: the specification is born with the DNA of a specific provider, even though its governance moves to a neutral foundation.

The detail that many SMBs overlook

There is a nuance worth highlighting: the ecosystem has bifurcated. OpenAI's Chat Completions API became an early reference, but Anthropic's Messages API has gained weight, largely due to the pull of Claude Code, and there are already providers such as DeepSeek, Moonshot, Z.ai or MiniMax that expose Anthropic-compatible endpoints. That is, there are two lineages coexisting. Precisely that fracture is what a neutral specification like Open Responses aims to correct.

For an SMB, the practical consequence is not immediate, but it is strategic. If your product or your automations depend on a single provider, any change in price, quota or model forces you to touch code. If the integration layer relies on a standard, the change is reduced to configuration. The difference between one thing and the other is measured in development days and operational risk.

What we recommend from ForgeNEX

• Separate business logic from the model call. Even if today you use a single provider, encapsulate the calls behind your own layer. If Open Responses consolidates, that layer will be thinner; if not, it will have saved you anyway.
• Don't rewrite anything because of the news. The specification is young and its governance has just started. Adopting it makes sense in new projects or in planned refactorings, not as an urgent migration.
• Watch Anthropic and Google. The real usefulness of the standard depends on the big players joining. If they stay out, we will continue with adapters per provider.
• Take the opportunity to review costs and dependencies. It is a good time to inventory which models you use, where and with what criticality. Many SMBs discover in this exercise that they have more integrations than they thought.

This move fits with a trend we have already been observing: AI stops being an isolated experiment and enters the architecture. We talked about it when discussing process automation with n8n and AI and also when comparing Claude, GPT and Gemini. In both cases, the conclusion was the same: portability is worth money.

The fine print of neutrality

The fact that the AAIF is part of the Linux Foundation provides something that a single provider cannot give: a neutral home where to develop the specification in common. The foundation's technical committee will initially be made up of the project maintainers, which in practice means that those who have contributed the most will have more weight in decisions. It is reasonable, but one should not confuse governance neutrality with technical neutrality: the starting point is OpenAI's schemas and that will shape the design for a while.

For an SMB's IT team, the sensible reading is this: welcome any initiative that reduces integration work, but let's not bet the architecture on the standard succeeding. Let's design as if we were going to change providers tomorrow, because we probably will. And if Open Responses ends up being the common denominator, so much the better for everyone: less code stuck to the vendor and more time dedicated to what really differentiates a business.

Source: The New Stack. Analysis and adaptation: ForgeNEX.