What the Agentic AI Foundation Adds

Four new projects make parts of agent development easier to reuse while leaving important compatibility and security questions open

BunCosmos Research Lab | 25 October 2026

The Agentic AI Foundation (AAIF) has brought four widely relevant pieces of AI infrastructure under one umbrella. Agent Skills, Open Responses, OpenEnv and OpenSandbox address different problems: how an agent acquires task instructions, how an application communicates with a model, how an agent is trained and tested, and where its code runs. The additions make a more reusable agent ecosystem plausible. They do not, by themselves, produce a complete system whose parts are interchangeable or secure by default.

Announced by the Linux Foundation on 22 October, the projects were contributed by Anthropic, OpenAI, Hugging Face and Alibaba respectively. They bring AAIF to ten hosted projects, joining MCP, goose, AGENTS.md, A2A, agentgateway and Agent Router. This was an announcement about project stewardship and participation, not the simultaneous invention of four new technologies. [1]

For anyone trying to understand the significance, the useful question is what can now move between products with less rewriting. The answer is encouraging at specific boundaries, and much less settled when it comes to an agent’s overall behaviour.

Four projects with different jobs

Project	What it makes reusable	What it does not guarantee
Agent Skills	Instructions and supporting files for a task	The same tools, permissions or results on every host
Open Responses	A common interface for model requests and outputs	Identical model behaviour or portable provider state
OpenEnv	Interactive environments for training and evaluation	A valid reward or a fair comparison without careful setup
OpenSandbox	APIs for creating and using execution environments	Safety independent of runtime and operator configuration

An application programming interface, or API, defines how programs communicate. These projects offer a content format, an API specification and two frameworks for environments and execution. Their roles can complement one another without forming a mandatory sequence. [2, 6, 9, 12]

Agent Skills makes procedural knowledge portable

An agent often needs more than a capable model. It needs to know how a particular task should be done: which template to use, which checks matter and where supporting material lives. Agent Skills packages that procedural knowledge in a folder. Its required SKILL.md file contains a name, a description and instructions; scripts, references and other assets can sit alongside it. A skill can consist entirely of instructions, so installing one need not involve executable code. [2]

The design loads information in stages. The agent initially sees a short catalogue of available skills. It loads fuller instructions when a task calls for them, then retrieves supporting files as needed. This avoids placing every procedure into every conversation. The host application still decides how to discover skills, activate them, manage context and enforce permissions. [3]

There is concrete reuse outside Anthropic. GitHub documents support across several Copilot surfaces, including its command-line tools and coding agents. That is useful evidence that the format travels between products. GitHub also warns that supported locations and editor features vary, which illustrates why format support should not be mistaken for identical operation. [4]

Consider a hypothetical skill for preparing a monthly sales report. Its instructions and spreadsheet template may be easy to share. A helper that depends on a particular connector, installed library or authenticated account will require more work. Two models can also interpret the same procedure differently. The portable package reduces repeated setup; the host and its available tools still determine whether the task succeeds.

Anthropic’s donation includes the Agent Skills name and logo, GitHub organisation and domain. Its announcement proposes versioned releases, a formal proposal process and security guidance as future work. Those proposals should be distinguished from functionality already delivered. Nor does an open format make every independently distributed skill package open source. [2, 5]

Open Responses standardises the model conversation

Applications must send requests to language models and interpret what comes back. That exchange has become more complicated as models call tools, produce different kinds of content and stream results in stages. Open Responses provides a common specification, derived from OpenAI’s Responses API, for representing those interactions. It defines structured items such as messages and function calls, along with events that describe progress and completion. [6]

A shared interface can reduce the amount of provider-specific translation an application needs. It also gives routing and logging systems more consistent material to work with. But a common shape for a request cannot make different models equally capable. It cannot ensure that they choose the same tool, interpret an instruction in the same way or recover from a mistake equally well.

Ollama offers a useful example of both adoption and limits. It supports Responses requests, but its documentation explicitly limits that support to stateless operation. Features such as continuing a stored conversation through previous_response_id are not supported. An application relying on server-held history therefore cannot assume that changing the endpoint address is enough. [7]

The same distinction applies to reasoning data and hosted tools. An identifier for a response stored by one provider does not give another provider access to that state. Provider-specific encrypted content and extensions can also retain dependencies even when the surrounding request uses a shared schema. Open Responses describes the exchange; it does not supply a universal tool-execution service or a portable memory system. [6]

The project has acceptance tests for practical behaviours including streaming, tool calls, image input, compaction and WebSocket continuation. That is more useful than a compatibility logo alone. A meaningful claim still needs to identify the endpoint, model, specification version and tests passed. Passing a selected suite is evidence about that configuration, not proof that every provider feature or application will behave identically. [8]

OpenEnv makes agent tasks easier to share and examine

Testing an agent is different from asking a model a single question. An agent may take an action, inspect the result, make another choice and continue until a task succeeds or fails. OpenEnv gives developers a common way to package and serve environments for this kind of interaction. Its interface supports resetting a task, taking a step and returning observations, rewards and information about whether the episode has ended. [9]

In reinforcement learning, a reward is the signal used to encourage desired behaviour during training. For evaluation, a task’s scoring rules help judge the result. OpenEnv provides infrastructure around these interactions, but the quality of the task and its scoring remain crucial. An agent can perform well against a weak grader without doing the job a human actually wanted.

Its Harbor integration is a practical example. Harbor supplies tasks, agents, verifiers and sandbox backends; OpenEnv adds its environment interface and captures interactions with the model. The documentation distinguishes evaluation traces from training data: the latter needs exact records of the model’s text units, or tokens, and their probabilities from a supported serving engine. A readable transcript alone is not equivalent to that training record. [10]

OpenEnv also publishes compatibility evidence with useful limits. Its 15 September qualification covered 29 adapters across four provider profiles using two fixed tasks per pair. Fourteen adapters met the report’s local definition of stable, nine were experimental and six unstable. The authors describe these as compatibility smoke tests, not benchmark scores or proof of production reliability. The accompanying training diagnostic consumed captured data but did not synchronise model weights, so it does not demonstrate sustained learning. [11]

That candour matters. An environment standard makes repeated experiments easier to organise, while task versions, starting conditions, model settings and grading still determine what a comparison means. Training and evaluation also need not sit in the middle of every production request. OpenEnv can support the development process without being a compulsory step in a deployed agent’s workflow.

OpenSandbox provides execution boundaries that must be configured

Many useful agents eventually execute code or manipulate files. OpenSandbox provides infrastructure for creating and managing the environments where that work happens. Its architecture separates the service that controls a sandbox’s lifecycle from components inside the sandbox that handle commands, files and other execution tasks. It supports Docker and Kubernetes backends and multiple workload types, including coding, browsers and evaluation. [12]

This can make execution infrastructure easier to replace or operate consistently. It also creates a distinction readers should keep in view: the API used to request a sandbox is different from the mechanism that isolates it. A familiar API can sit above deployments with different runtime protections, network policies and exposed services.

The project’s network documentation makes that dependence concrete. One mode restricts which domain names a sandbox can resolve, while a stronger mode adds controls over network packets. Those mechanisms have different capabilities and runtime constraints. A statement that an agent runs in a sandbox therefore leaves important questions unanswered about which destinations it can reach and which connections are actually blocked. [13]

Credentials and mounted files matter as much as network settings. A secret deliberately made available inside an execution environment is part of that workload’s authority. An allowed external service may still permit an unwanted action. OpenSandbox’s secure-access guidance likewise treats endpoint protection as an operational responsibility rather than assuming that a provisioned sandbox is safe to expose. [12, 14]

The practical conclusion is to name the protection being claimed. Runtime isolation can reduce exposure to untrusted code. Restricting network access can reduce routes for data leakage. Neither establishes that an agent understood the user’s intention or that a permitted tool action was appropriate. Those decisions need controls outside the model’s instructions.

The projects already connect in specific ways

Some of the connective tissue is real code. Harbor’s v0.24.0 release contains an OpenSandbox adapter, while OpenEnv documents its Harbor integration. That establishes a route between the environment framework, an evaluation framework and a sandbox backend. The adapter also states limits, including its use of prebuilt images for a single-container path. A supported route is more informative than a diagram, but it does not establish that every OpenEnv qualification result used that backend. [10, 15]

Agent Skills has another bridge through MCP, the Model Context Protocol. The published Skills extension defines discovery and retrieval of skill content from MCP servers. It requires file integrity checks and preserves the identity of the originating server. Its documentation also says SDK and host support is still being implemented. A product that reads local SKILL.md folders does not automatically support this transport extension. [16]

Taken together, these examples support a measured conclusion. Developers can reuse components across several boundaries today. They still need to choose and test the agent application, model route, tools and execution configuration. The documented integrations do not establish a single, jointly qualified system combining all four newcomers.

Open governance has its own distribution of power

AAIF’s institutional role is to support projects under the Linux Foundation. Its charter defines a directed fund that raises, budgets and spends money for approved projects, while each project has separate technical governance. That distinction matters: joining the same foundation does not give every project an identical decision process. [17]

Representation at foundation level is also unequal. The charter caps Platinum membership at eight and gives each Platinum member a board representative; Gold members share one seat. For specified decisions, including charter changes and admitting additional top-level projects, a two-thirds board vote is required. During a three-year startup period, those decisions additionally require approval from every Platinum member that has contributed a top-level project. [17]

These are significant institutional rights, not evidence of misconduct or a veto over every code change. They do show why vendor neutrality should be understood as a governance arrangement rather than a promise of equal influence for all participants. [17]

Project-level rules can provide other routes to participation. Open Responses adopted a technical charter on 21 October that assigns technical oversight to a steering committee, opens contribution and maintainer participation to people who meet its rules, and intends committee meetings to be public. Anthropic separately says that using or contributing to Agent Skills does not require AAIF membership. These mechanisms deserve attention alongside corporate membership lists. [18, 5]

What this changes for people building and using agents

Shared formats can make useful work less dependent on the first product in which it was created. A team may preserve a procedure when changing its agent application, compare models through a more consistent interface, reuse evaluation tasks or choose a different execution backend. Those are worthwhile improvements even when switching still requires engineering and retesting.

The security tradeoff is equally concrete. A reusable package can carry a good procedure to more users, but the same distribution channel can carry hostile instructions or unsafe code. Reviewing only the main instructions misses helpers and dependencies. Reviewing only code misses directions that misuse an otherwise legitimate tool. The MCP Skills extension explicitly distinguishes verifying that content matches a manifest from trusting that content. [3, 16]

For buyers and developers, the strongest evidence will be specific: which versions interoperate, what permissions are enforced, what happens when an action is denied, and whether a task still works after a component changes. These questions concern the full workflow, beyond whether a request fits a schema.

AAIF’s expansion gives that work a larger shared home. Its near-term value lies in reducing duplicated integration work and making the remaining boundaries easier to inspect. The success of the effort will be measured by working migrations and reliable deployments, rather than by treating ten projects as ten interchangeable layers.