How this compares
Most of this stack is not a competitor. It is a layer.
Agent infrastructure is often described as one market. It is really four questions, and the tools that answer them sit at different depths. This page says which question each category answers and where SharedOS begins.
Where the layer becomes necessary
Cross an ownership boundary and one row stops working.
A stack that coordinates devices under a single account already exists. The moment the devices belong to different people, most of it is unchanged — and one row loses the thing it assumed.
Every row but one already works across an ownership boundary. A2A leaves authorization outside the protocol by design; MCP connects a tool, and connecting is not authorizing; identity establishes who you are, not what you may reach. SharedOS is that row.
SharedOS
The execution kernel
| Category | The question it answers | Where the boundary falls |
|---|---|---|
| Agent-to-agent protocolsA2A, MCP | How does one agent reach another, and how does an agent reach a tool? | A2A deliberately leaves authorization outside the protocol. MCP connects a tool; connecting is not authorizing. SharedOS is the layer that decides whether a reachable call is permitted. |
| Agent identity and fine-grained authorizationAuth0 for AI Agents, WorkOS FGA, Okta | Which principal is this, and may it access this resource? | These answer the same question well at the application edge. SharedOS applies the decision inside the turn: the catalog the model sees is filtered first, and every individual call is re-authorized against the exact resource and action at invocation time. |
| Agent frameworksFramework-level agent loops and orchestrators | How do I build the loop, the planner, and the tool calls? | A framework is the layer the model reasons in, so constraints written there can be reasoned around. SharedOS sits underneath and treats the harness as replaceable — standard, Codex, or your own plugin. |
| Sandboxes and isolationContainer and microVM execution environments | How do I stop code from touching the host? | Complementary. Isolation bounds what a process can reach; SharedOS bounds what an agent is permitted to reach. An untrusted harness needs both. |
SharedEval
The evaluation stack
| Category | The question it answers | Where the boundary falls |
|---|---|---|
| Agent security benchmarksAgentDojo | Does the agent resist prompt injection arriving through untrusted tool output? | The attacker there is injected content. In SharedEval the request is legitimate and correctly formed — the question is whether the receiving agent should answer it at all, given who is asking. Different failure, different ground truth. |
| Tool-agent-user benchmarksτ-bench and successors | Can the agent complete a task through tools while following domain policy? | Single ownership domain. SharedEval seeds multiple principals who each own private state, so a correct answer for one requester is a leak for another. |
| Evaluation platformsTracing, scoring and experiment platforms | How do I log runs, score outputs, and compare versions? | They score whatever you send them. SharedEval compiles the world itself from a declarative seed, and derives the evaluation contract and gold facts from that same seed — so the world and the grader cannot drift apart. |
What we will put a line number behind
Every claim above is in the open-source tree.
The comparison is only worth reading if it can be checked. Each property below is enforced in code you can read, not asserted in documentation.
- Authorization decided outside the model
authorization.ts - Tool discovery filtered by grant before the model sees a catalog
kernel.ts - Every individual call re-authorized against the exact resource and action
kernel.ts - Grants scoped per resource, action and purpose, with expiry and revocation
capability.ts - The model never receives grants or the issuing authority
executor.ts - Every decision carries a reason code and an audit event
audit.ts
An honest comparison. These categories are complementary far more often than they are competitive, and several of them do their own job better than SharedOS would. We describe what each is for rather than scoring them, and the SDK remains a 0.x prerelease.
Review release readiness