What the Agentic AI Foundation's Four Agent Projects Solve, and What They Leave Open

Introduction: what the four agent projects actually solve

On 2026-10-22 the Agentic AI Foundation announced four open projects — Agent Skills, Open Responses, OpenEnv, and OpenSandbox — framed around interoperability and infrastructure gaps in agent development. That is the entire confirmed record: one foundation, four project names, one framing sentence, one date.

This post maps what each of those projects solves for agent interoperability, which seam of a JavaScript agent stack each one sits on, and what the announcement leaves unresolved — so you can decide what to build now and what to wait on. What builders did not get is spec text. The public material behind this post is the announcement coverage itself, and past the four names and the interoperability framing, details are thin. So this post separates what the announcement establishes from what each name implies, and labels the second category as inference.

My position: these are not four products competing for adoption. They are four seams in an agent stack. Agent Skills sits at capability packaging, Open Responses at the response envelope, OpenEnv at the environment contract, OpenSandbox at execution isolation. Which one matters to you depends on which seam is currently breaking in your own code — and for most JavaScript agent codebases in production right now, exactly one of them is on fire.

What the Agentic AI Foundation announcement actually establishes

Confirmed, from the source:

• The Agentic AI Foundation announced four open projects.
• Their names: Agent Skills, Open Responses, OpenEnv, OpenSandbox.
• The stated framing: interoperability and infrastructure gaps in agent development.
• The announcement date: 2026-10-22.

Nothing else. I am not going to invent repository URLs, spec versions, maintainer lists, licence terms, or governance structure, because none of that is in the material I have. If you see a post that lists WG chairs and a v0.1 schema for these projects today, check where those facts came from.

The four project names and the stack gap each one points at

The middle column is my reading of the names, not a quotation from a specification. That distinction matters more than usual here: a name is a design hint, a spec is a set of obligations.

What the public material does not say

Unknown from the announcement, and each one blocks adoption:

• No spec text is referenced. A format without a document is a press release.
• No conformance suite or test vectors. Without them, "compatible" is self-declared.
• No versioning or deprecation policy. For a wire format this is the whole ballgame.
• No stated relationship to existing provider APIs. Does Open Responses wrap OpenAI-shaped payloads, replace them, or ignore them?
• No reference implementation named in JavaScript. Python-first is a reasonable guess given the ecosystem, but I am not asserting it.

These are unknowns, not absences. They may exist; I could not verify them at the time of writing.

Four seams in a JavaScript agent stack, and the symptom each one causes

Take a boring, realistic Node/TypeScript agent: a loop, a tool registry, an HTTP client to a model provider, and a step that writes and executes code. Four seams, four symptoms an engineer actually sees in a terminal.

Skills. The same capability is redefined per framework and drifts, because each framework wants different metadata. Symptom: three copies of lookupOrder, three slightly different argument contracts, one of them accepting a raw SQL fragment.

Responses. Parsing lives in application code. Symptom: the provider ships a new finish reason or changes a streaming delta shape, your switch falls through to the default branch, and a truncated turn gets marked complete.

Environments. There is no reset. Symptom: a failing run cannot be reproduced, because state accumulated in module-level variables and a scratch directory nobody cleans up.

Sandbox. Agent-generated code runs with the process's own privileges. Symptom: you find out during an incident review, not a test.

Agent Skills — packaging capability without packaging prompts

The seam here is portability of a capability definition. The hard part is not the file format — JSON Schema has existed for a decade. It is agreeing on what a skill may assume about its runtime: which secrets it sees, whether it can retry, what a timeout means, whether it can write.

The symptom: skill drift across frameworks

In ordinary framework work, the same "look up an order" capability gets rewritten once per framework: a different description field for the model, different argument validation, different error contract (throws vs { ok: false }), different timeout handling. The capability is identical; the packaging is not. This is an observation from day-to-day integration work, not a measured study — I have not counted drift across a corpus of repos.

A manifest you can ship before the standard lands

You can get most of the benefit today by writing the descriptor yourself and generating each framework's tool definition from it.

{
"name": "orders.lookup",
"version": "1.2.0",
"description": "Look up a single order by id. Read-only. Returns status and total.",
"inputSchema": {
  "type": "object",
  "properties": {
    "orderId": { "type": "string", "pattern": "^ord_[a-z0-9]{10}$" }
  },
  "required": ["orderId"],
  "additionalProperties": false
},
"sideEffect": "read",
"requiredScopes": ["orders:read"],
"timeoutMs": 5000
}

Everything above is inert. The tool it describes is a fake local lookup; no credentials appear in the descriptor, and scope names are declarative labels your enforcement layer checks, not secrets.

What Agent Skills would have to specify to replace it

Requirements, not claims about what the project does:

• Schema dialect. JSON Schema 2020-12, or a subset with documented restrictions.
• Side-effect declaration. How a skill says "this writes" versus "this is read-only", and what consumers must do with that.
• Secret and scope binding. Whether scopes are declared by the skill, granted by the host, or both — and where enforcement happens.
• Versioning against model behaviour. A capability may work with one model's tool-calling style and fail with another's. Does the descriptor carry that, or the host?

Open Responses — normalizing the envelope, not the semantics

This seam is the response object: content blocks, tool-call deltas, streaming events, refusal and finish reasons, usage accounting.

Why the envelope is where lock-in actually lives

Switching models is a config change. The parsing layer is what calcifies, because it spreads. Every place you touched choices[0].delta.tool_calls is a place a provider bump reaches into application code. The cost is not the first edit; it is the diff review on the eighth, when a finish reason changed meaning and you found out from a user.

A narrow adapter with a normalized result type

export type FinishReason = "stop" | "length" | "tool_call" | "refusal" | "error";

export interface NormalizedTurn {
text: string;
toolCalls: Array<{ id: string; name: string; args: unknown }>;
finishReason: FinishReason;
usage: { inputTokens: number; outputTokens: number };
}

// The only file in the repo allowed to know provider-specific field names.
export function fromProviderTurn(raw: any): NormalizedTurn {
return {
  text: raw?.choices?.[0]?.message?.content ?? "",
  toolCalls: (raw?.choices?.[0]?.message?.tool_calls ?? []).map((c: any) => ({
    id: c.id,
    name: c.function?.name,
    args: JSON.parse(c.function?.arguments ?? "{}"),
  })),
  finishReason: raw?.choices?.[0]?.finish_reason === "tool_calls" ? "tool_call" : "stop",
  usage: {
    inputTokens: raw?.usage?.prompt_tokens ?? 0,
    outputTokens: raw?.usage?.completion_tokens ?? 0,
  },
};
}

The caller sees the difference immediately:

// before: msg.choices[0].message.tool_calls?.[0].function.arguments
// after:  turn.toolCalls[0].args

Note the deliberate gap: unknown finish reasons above collapse to "stop". That is a bug I would fix before shipping — but it is a bug in one file, visible in review, instead of everywhere.

The open half: semantics under a shared shape

A common envelope does not make behaviour portable. Divergence survives in three places:

1. What a finish reason means. length from one provider can mean max tokens; from another it can mean the model stopped mid-tool-call.
2. How partial tool calls stream. Some providers emit argument fragments; some emit complete calls at the end. A shared envelope either flattens this or leaks it.
3. How errors surface. HTTP status, in-band error objects, or a stream that just stops.

So Open Responses would plausibly reduce diff churn. It would not, by itself, make an agent behave the same on two providers. That is a semantics problem, and standards are bad at semantics.

OpenEnv — an environment contract for stateful agent episodes

The seam is the observation/action loop: how an agent observes state, acts, and receives a terminal signal.

Environments are not tool schemas

A tool call is stateless — same input, same output, no memory. An episode has state: reset returns an initial observation, step applies an action and returns the next observation plus a terminal flag (and often a reward), and a seed makes the initial state reproducible. Most JavaScript agent code has no reset concept at all, which is exactly why reproducing a failure means re-running the whole session and hoping the model samples the same way.

Four environment guarantees worth building regardless of the spec

Four things worth having whether or not OpenEnv lands:

• Seedable initial state. reset(seed) must be deterministic for the environment's own state, independent of model sampling.
• Explicit episode boundary. One task, one episode. No cross-contamination via module scope.
• Deterministic reset. Files, temp dirs, and in-memory caches returned to a known state, verified by the harness.
• Recorded action log. Append { step, action, terminal } so a failure can be replayed against the environment even if the model's output cannot be.

export interface Environment<S, A> {
reset(seed: number): Promise<{ observation: S }>;
step(action: A): Promise<{ observation: S; terminal: boolean; reward?: number }>;
}

Two methods. Both map cleanly onto a test harness you already have: reset is beforeEach, step is the assertion body.

OpenSandbox — the boundary that matters most operationally

Of the four, this is the only one where not waiting carries real risk. Agent-authored code is untrusted code by construction, and "untrusted" is not a mood — it is a statement about who can influence the input.

Threat model in one paragraph

Model output is attacker-influenced input. A hostile tool description, a fetched file, or a page the agent reads can carry instructions that steer what code gets generated and executed during the run. The OWASP LLM Top 10 framing for prompt injection applies: the model is a conduit, not the adversary. The defence is not a better prompt; it is a boundary that holds when the prompt fails, because some fraction of the time it will.

A minimum sandbox checklist

Verify the boundary instead of assuming it

A sandbox you have not tested this way is a hope, not a control. Adapt this to your runtime — the flags below are Docker's — and treat the output as illustrative rather than a contract.

docker run --rm \
  --network none --read-only --tmpfs /tmp:size=16m \
  --memory 256m --cpus 0.5 --pids-limit 128 \
  --user 65534:65534 \
  node:22-alpine node -e '
(async () => {
  const out = { envKeys: Object.keys(process.env).sort() };
  try {
    const r = await fetch("https://example.com", { signal: AbortSignal.timeout(3000) });
    out.network = "HTTP " + r.status;
  } catch (e) { out.network = e.name + ": " + (e.cause?.code ?? e.message); }
  try { require("fs").writeFileSync("/etc/probe", "x"); out.rootfs = "WRITABLE"; }
  catch (e) { out.rootfs = e.code; }
  console.log(JSON.stringify(out));
})();
'

Illustrative output:

{"envKeys":[],"network":"TypeError: ENOTFOUND","rootfs":"EROFS"}

Three signals to check: envKeys empty (nothing leaked in), network failing at DNS (no route out), and EROFS on the root filesystem. If any comes back differently, the boundary is not where you think it is. Run this in CI, against the same image tag production uses.

Where the four meet, and what none of them covers

Tools, envelopes, environments, and sandboxes are plumbing. Identity, authorization, and audit sit above the plumbing, and all four projects appear — from the names alone — to be silent on them.

The unresolved seam: identity and authorization

• Agent Skills: who grants orders:read to a skill, and does the declared scope bind the host or merely describe intent?
• Open Responses: when a turn includes a tool call, whose identity is asserted for the downstream request?
• OpenEnv: is the environment run as the user, the agent, or a service identity — and does reset reset the credentials too?
• OpenSandbox: how does sandboxed code obtain a short-lived, narrowly-scoped credential without a long-lived secret in its environment?

These are open questions, not findings. A standard that answers them poorly is worse than one that stays out of the way.

The unresolved seam: conformance and evals

A shared format without a conformance suite and published test vectors degrades into N dialects that all claim compliance. SQL did this. Tool-calling schemas are doing it now, and "compatible" keeps meaning "roughly". The fix is boring: a test suite you can run, with expected outputs checked in.

Adopt, abstract, or wait: what to build before the specs land

Conclusion: build the boundaries before the standards land

The announcement is a reasonable map of where the agent stack hurts. The four names are more informative than the details right now, and that is fine — the names tell you which seams someone with a foundation budget thinks are worth standardizing.

The durable move is to build those four boundaries in your own code first. Write the skill manifest. Write the adapter. Write reset/step. Write the sandbox check and put it in CI. Then a published standard becomes a replacement for your implementation rather than a rewrite of your application.

What would change this view: published spec text, a conformance suite with test vectors, or a reference implementation running in a JavaScript runtime. Any one of those moves at least one row of the table above from "abstract" to "adopt".

Further Reading

• Agentic AI Foundation Announces Four New Projects: Agent Skills, Open Responses, OpenEnv, and OpenSandbox — announcement coverage, Yahoo Finance Singapore, 2026-10-22.
• OWASP Top 10 for LLM Applications — the prompt-injection and excessive-agency framing referenced in the sandbox threat model.

Primary spec material for the four projects was not available at the time of writing, so no spec, repository, or governance links are listed here.