Analysis / Development and agents
AI agents without being tied to one provider
Businesses investing in AI agents risk building critical workflows around a provider they may eventually want to replace. New projects joining the Agentic AI Foundation offer a practical route towards portability, although open specifications do not remove every migration obstacle.
Businesses can make AI agents easier to move between model providers, provided portability is considered during development rather than after deployment. Open standards allow instructions, tool connections and parts of the model interface to be reused. They do not guarantee identical results, preserve every platform feature or eliminate the cost of migration.
On 22 October 2026, the Linux Foundation announced four additions to its Agentic AI Foundation (AAIF) at AGNTCon + MCPCon North America in San Jose.
The most immediately relevant for businesses building agents are Agent Skills, contributed by Anthropic, and Open Responses, contributed by OpenAI.
Both address a practical question: how much of an agent can you keep if you decide to use a different AI platform?
The AAIF is bringing more of the agent stack under neutral governance
The Agentic AI Foundation launched in December 2025 with three projects. Following the latest additions, it now hosts 10 projects.
The four new contributions cover different technical requirements:
- Agent Skills (Anthropic): a portable format for packaging instructions, scripts and supporting resources.
- Open Responses (OpenAI): a common specification for requests, outputs and streaming events across model providers.
- OpenEnv (Hugging Face): a framework for building and sharing agent training and evaluation environments.
- OpenSandbox (Alibaba): isolated execution environments for agent workloads and code.
They join existing projects including MCP, AGENTS.md, A2A, goose, agentgateway and Agent Router.
The Linux Foundation announcement emphasises vendor-neutral governance, meaning no individual company controls the direction of the projects.
For businesses, this provides a stronger foundation for choosing technologies that are not entirely dependent on one vendor's decisions.
It does not mean that every AI platform must adopt these specifications.
Agent Skills makes procedural knowledge easier to reuse
An Agent Skill is typically a folder containing a SKILL.md file, with optional scripts and reference material.
It gives an agent instructions for a particular task or business process.
For example, a company might create a skill describing how purchase orders should be checked, which fields require validation and how the final report should be formatted.
The benefit of a shared format is that those instructions can be carried into compatible agent environments without rebuilding the documentation from scratch.
According to Anthropic, more than 70 agent platforms have integrated Agent Skills since December 2025, including ChatGPT, Cursor, GitHub Copilot and VS Code.
Anthropic also reports approximately 1 million published skills and nearly 280 million installations. These are company-reported adoption figures, rather than independently verified totals.
Its contribution includes the Agent Skills name, logo, GitHub organisation and agentskills.io domain.
Using or contributing to the standard does not require AAIF membership. Proposed next steps include versioned releases, a formal proposal process and security guidance for skill authors and installers.
For a closer look at structuring reusable instructions, see our guide to AGENTS.md and agent project documentation.
Open Responses tackles the model API dependency
Where Agent Skills addresses an agent's instructions, Open Responses focuses on how applications communicate with models.
Based on the OpenAI Responses API, the specification defines a shared request structure, consistent streaming events and extensible tooling.
Consider a business application that sends customer information to an AI model, receives structured output and then invokes tools to update another system.
If the integration is written directly around one proprietary API, changing providers may involve substantial changes to application code.
An interface built around Open Responses could reduce that translation work when both providers implement the specification.
There is an important limitation: Open Responses is a newly contributed specification, not a universally supported interface.
Even with compatible request formats, models may differ in their capabilities, tool handling and generated output.
An API can standardise communication without standardising intelligence.
Our article on why the same model behaves differently with different agent harnesses explores the importance of the surrounding execution environment.
Which parts of an AI agent are actually portable?
A useful architecture separates business knowledge from the infrastructure used to execute it.
| Criterion | What to check |
|---|---|
| Agent instructions | Keep procedures in accessible files such as AGENTS.md. |
| Agent Skills | Use the open format and avoid unnecessary platform-specific dependencies. |
| Tool connections | Consider MCP for compatible external integrations. |
| Model interface | Separate API calls from business logic and assess Open Responses support. |
| Memory and history | Confirm that important records and state can be exported. |
| Proprietary tools | Document alternatives and replacement requirements. |
| Model behaviour | Retest actual workflows when switching providers. |
| Access and permissions | Manage credentials independently wherever possible. |
The Model Context Protocol already offers a common approach to connecting agents with external tools. Our MCP standards and implementation guide explains where it fits.
The distinction is between portable components and portable outcomes.
A skill may load successfully in another product while producing different results because the model or execution environment behaves differently.
What to require from whoever builds your AI agent
Businesses should define portability requirements before committing to an implementation.
1. Accessible instructions. Business rules and agent procedures should be delivered as editable files.
2. Documented integrations. Tool connections, permissions and dependencies should be explained.
3. Separated business logic. Provider-specific API code should not be unnecessarily embedded throughout the application.
4. Recoverable data. Important conversation history, state and operational records need an export strategy.
5. Migration testing. Representative tasks should be available for evaluating another model before making a change.
These requirements will not make switching providers free or automatic.
They can, however, reduce the amount of work required to evaluate alternatives and limit the risk of losing accumulated business knowledge.
What should your business decide this week?
Review an existing or planned AI agent and identify which components would need replacing if its model provider changed. Prioritise making instructions accessible, documenting integrations and separating provider-specific code before adding more functionality. If you are planning an agent for internal operations, tell us which systems you want to connect so we can assess an architecture that allows future changes without rebuilding the entire workflow.
Sources
Checked on October 25, 2026