Prism

Prism runs the way organizations actually produce outcomes — projects, teams, governed process, and accumulated judgment — as infrastructure that agent teams execute on. It is not an assistant inside someone else’s tool. It is the organization itself, made native to agents.

---

​

What Prism is

The team operating model is the highest-leverage outcome engine humanity has ever built. A governed team executing a defined process against shared memory produces results no individual — human or agent — produces alone. That is not an insight about AI; it is how every complex outcome in modern history got made. Hospitals, exchanges, engineering firms, militaries: structure plus process plus institutional memory is the machinery behind every outcome too large for one mind. Prism makes that machinery native to agents. Projects scope the work. Teams of role-bound agents execute it. Governance keeps every agent on-model. Shared memory makes the work compound instead of repeat. You do not get a smarter chatbot — you get an operating model, staffed and running. The operating-system framing is literal, not decorative. An operating system is a governed environment where processes run under rules they cannot violate, coordinated with one another, against shared services and a shared memory. Swap process for agent and you have described Prism exactly: So Prism is the operating system; agents are the processes; MCP is the syscall; the model is the CPU it does not manufacture. Everything else in these docs is how that operating system is built. Why a team / project / operating-model metaphor, and not “assistant” or “copilot”? Because outcomes are produced by organizations, not by individuals with helpers. Prism is built to be the organization — not the smart tool sitting inside someone else’s.

---

​

The problem Prism solves

There are two problems, and they are different in kind. The first is why the operating model cannot run today. The second is why, once it can, it will outperform the human version of itself.

​

One — the model cannot run yet

Agents today cannot actually be a team. Each one starts from zero every session. They cannot share memory across vendors, across machines, or across the people directing them. The entire ecosystem inherits a single-operator, file-system mentality — one CLAUDE.md on one disk, in one repo, driven by one human — and whatever coordination exists is bolted on per vendor and dies at the vendor boundary. There is no operating model. There is a pile of isolated, amnesiac sessions pretending to collaborate. For one developer, one project, one machine, one agent, the rudimentary memory shipping in today’s tools is enough. The moment the work needs more than one agent, more than one vendor, more than one operator, or more than one project to add up to a coherent whole, the single-operator assumption is the ceiling — and every current tool is hitting it.

​

Two — the model has always been corrupted by its operators

This is the deeper reason Prism matters, and it is the uncomfortable one. The team operating model works on paper and degrades in practice — because humans degrade it. Every human-operated process erodes toward the self-interest of the people running it. The cognitive-bias literature is a catalog of the mechanisms: the Einstellung effect (stuck in what worked before), identity lock-in (rejecting a better method because adopting it would undermine the authority your identity is built on), malicious compliance (following the letter while hollowing out the intent), status-seeking, and the steady pull toward the path of least cognitive resistance. These are not occasional failures. They are the default operating condition of the human mind in professional contexts. The WHO Surgical Safety Checklist reduces perioperative mortality by 47% — and surgeons skip it, because adherence feels like an affront to their expertise. The investment process that beats the market is known, simple, and effective — and investors abandon it at every emotional inflection. Agile was sound — and within a decade most organizations had converted it into theater that preserved their autonomy while producing the appearance of compliance. The model is not broken in any of these cases. The humans in the gears are.

The Entropy Principle. Every human-operated system degrades toward the self-interest of its participants. The rate of degradation is proportional to the gap between the system’s design intent and the individual incentives of the people operating it — and no layer of oversight closes that gap, because the oversight is staffed by self-interested humans too.

Governed agentic teams are structurally immune. An agent has no identity to protect, no status to chase, no effort to avoid, no four years of training whose meaning a new method would threaten. It loads the operating model fresh at the start of every session and executes it — because it has no identity-driven reason not to. The failure modes that quietly corrupt every human team are not mitigated; they are impossible.

---

​

The inversion: agents drive, humans augment

Put those two problems together and the conclusion inverts the industry consensus. The comfortable narrative says AI augments humans — the human stays in the driver’s seat, the agent is the copilot. Prism argues the opposite for any domain where process fidelity determines the outcome: the governed agentic team drives, and humans augment at the points where human judgment is genuinely irreplaceable. The precise form of the principle: humans belong at the gates, not in the gears.

• A gate is a decision point where the system presents a recommendation, the evidence behind it, and the options — and a human evaluates whether to proceed, modify, or reject. The human is valuable here precisely because they are judging a well-structured recommendation, not generating one from scratch with every bias intact.
• A gear is a process step inside the execution pipeline. A human in the gears imports every failure mode above: corner-cutting, confirmation bias, malicious compliance, entropy. The more humans in the gears, the faster the system degrades from its design intent.

This does not remove humans. It repositions them — from process executor to goal-setter, gate-evaluator, exception-handler, and system-architect. You define what the system should accomplish and what “good” means; you judge outputs where stakes justify it; you intervene on genuinely novel situations; you design the operating model and the governance rules. You write the constitution; you do not hand-execute the process under it. Prism is the system that makes this real. The agents execute. The governance keeps them on-model. The learning loops ensure the model itself improves. And the human gate ensures the whole thing stays accountable to a person.

---

​

How Prism is built

Prism is structured the way an operating system is structured: a stack of layers, each depending on the one beneath it, pierced by a set of concerns that every layer shares.

​

The six layers

Each layer is a real subsystem with shipped or in-flight backing. The honest status is stated, because an operating system that overclaims its own kernel is not one you should trust your team to.

1. Operations — Prism running itself. The kernel and init system: session lifecycle, controller election, master handoff, heartbeat, runtime diagnostics, and the Ring 0→3 BIOS bootstrap that loads the governance chain at the start of every session. Shipped.
2. Network — how agents and services talk. The transport layer: the Marconi in-memory signal mesh (sender shim → switch → receiver shim, with durable audit fan-out off the hot path), plus the streams underneath it. The same identity-keyed routing extends to the cross-site mesh on the horizon. Shipped and in production.
3. Atomic Utilities — the primitives. The coreutils of the OS: the signal verbs, an email relay, scheduling, and notification — the irreducible operations every higher layer composes from. Signal shipped; email and scheduling are early.
4. Management & Services — ITSM for agents. The system daemons: incident and problem management run as a real workflow — intake, triage, severity, ownership, operator-gated phone-home — alongside the postmortem discipline that feeds the learning loops. In flight; the intake and triage personas are accepted and running.
5. Project Management — the operating model in motion. Userland: creating and cloning projects, standing up teams and personas, inviting collaborators, and the capability library that catalogs every reusable pattern, skill, and agent profile under a lifecycle. Project and team verbs live; the capability library is in flight.
6. Team Live — where outcomes are made. The applications: the driver-attached console, live multi-agent coordination, and the work itself. This is the layer a person actually touches. Console and live-coordination surfaces in flight.

​

The four spines

Some concerns are not a layer — they are pervasive, the way a real OS’s memory manager and security model are not “a layer” but run through everything. Flattening these into the stack would misrepresent them, and one of them is the crown jewel.

• Governance — the constitutional chain (Ring 0 BIOS → Ring 1 methodology → Ring 2 org → Ring 3 project) with narrower-wins precedence. It is what makes “on-model” enforceable rather than advisory, and it is why agents are immune to the failure modes in the problem statement.
• Memory — the tri-graph. Canonical identity, semantic meaning, and temporal history kept structurally separate, fused at retrieval time. This is what lets the work compound: a decision made once is queryable forever, at the point in time it was true.
• Identity — every agent is a scoped, role-bound team member with explicit authority boundaries, not an anonymous session. The team only works because the roster is real.
• Vault — secrets and shared configuration handled as a governed service, so credentials are never an agent’s problem to improvise.

The two load-bearing spines have their own deep dives — the constitutional ring chain that makes “on-model” enforceable, and the tri-graph that lets the work compound:

---

​

The surfaces agents run on

If agents are the processes, the surface is the kind of host a process runs in. Prism is vendor-neutral at the edge — every surface speaks the same protocol, MCP — so the same agent, the same memory, and the same governance work no matter which one you reach for. What changes between surfaces is who is at the keyboard and how the agent is hosted. There are three host modes, arranged along a spectrum from fully driver-attached to fully autonomous.

• Native — the editor or CLI app is the agent host. You open Claude Code, Codex, Cursor, or Claude Desktop; the model runs inside it with a human driving in real time. Best for design, review, and incident triage — anywhere immediate feedback matters.
• Console — a Prism-packaged host that runs the agent SDK as a standing teammate, with no editor open and a human attendant optional. It executes structured, audited intents rather than raw actions. Best for an always-on team member you signal and walk away from.
• Headless — the same standing-agent architecture with no UI at all, running fully unattended. Best for background work — log indexers, schedulers, batch jobs, and fan-out workers a parent agent spawns and reaps.

The CC / CX suffix names the engine: CC is the Claude Agent SDK, CX is the Codex SDK. So a Console or Headless agent is “Claude-engined” (CC) or “Codex-engined” (CX) — the same two model families you run natively, now hosted by Prism instead of by a third-party editor. Two honesty notes. Claude Desktop is limited — it has no push channel, so signals reach it on its next tool call rather than the instant they arrive; it works, but it is not interrupt-grade. And Cursor’s native push is in flight (an SSE transport); today it falls back to the same next-call delivery. Everything routes through MCP regardless, so no signal is ever lost — only the wake-up differs by surface.

---

​

The worked example: Prism builds Prism

This is not a whiteboard model. It is what built the thing you are reading about. Prism’s own development runs on a team of role-bound agents across three vendor surfaces — Claude Code, Codex, and a driver-attached desktop console — coordinating on one project with zero peer-to-peer command authority. Every cross-lane handoff is a typed signal with a persisted delivery path. Every decision is a first-class artifact. Every incident runs the intake-triage-ownership workflow. Every session boots through the same governance chain and writes back to the same shared memory. The governance telemetry from that team is the inversion’s proof. Over a single span of operation, citation discipline improved roughly sevenfold and the citation-to-recall ratio climbed from low single digits to over a quarter — agents not just recalling prior decisions but citing them before acting. And it happened with no motivational speeches, no performance reviews, no culture initiatives. The agents improved because the operating model was refined and they followed the refined model — because they had no identity-driven reason not to.

---

​

The horizon: from one node to a mesh

One Prism backend serves one team across many editors and many projects today. The architecture points past that, to many Prism nodes federating as a mesh — each node a full backend on its own network with its own agents attached, dialing the others over a schema-stable peer transport. What sits on top of a wide mesh is a single logical memory whose physical substrate spans locations: an agent in one place asks a question and the answer returns from memory written somewhere else, all mediated through the same brokered-authority model that governs a single node. It is the distributed-systems form of the same operating system — the OS, run across many machines, presenting one coherent environment to every agent on it. The foundations are already in the shipped work: identity-targeted signal delivery (address an agent by who, not where), schema-stable wire contracts, and the brokered-authority principle that refuses peer-to-peer control paths. Widening the mesh is incremental on those bones, not a rewrite.

---

​

What Prism is not

Prism is not a chatbot platform, an IDE, an orchestration framework, or an agent runtime. It runs no models, takes no prompts, and generates no completions — it is the CPU it does not manufacture that does that. Prism is the operating system the agents run in: the governed environment that turns a fleet of capable-but-amnesiac sessions into a team with a roster, a process, a memory, and a constitution. The agents do their own work. Prism’s job is to make sure that work compounds into outcomes instead of evaporating between sessions, between projects, between teammates, and between vendors.

---

​

Where to go next