An operating system for
AI coding agent sessions

The problem

Multi-agent development is uncontrolled

You spin up three Claude sessions on different features. One silently clobbers the other's files. A Cursor agent duplicates work that's already on an unmerged branch. Nobody knows who changed what, or whether the changes stayed within scope.

The code gets written. The governance doesn't exist.

The insight

OS primitives mapping

Operating systems solved process coordination decades ago: isolation, scheduling, memory management, locks, audit logs. These primitives map directly to multi-agent development — not as a metaphor, but as convergent engineering. We arrived at the same abstractions by solving the same class of problems.

Governance model

Constitution, compile, verify

Your repo gets a constitution — a YAML file declaring rules, deny patterns, file budgets, and checks. It compiles into a tamper-evident governance lock with a hash chain. Every session verifies the lock before starting. If the constitution changed but wasn't recompiled, the hash won't match — governance drift is caught before any agent writes a line of code.

Change the rules, recompile, commit. The hash chain updates. Adapters regenerate. Every agent sees the new governance on their next session start. No deploy, no restart, no coordination — just git.

exo compose takes it further: it compiles the constitution, config, feature manifest, and requirement registry into a single sealed policy artifact (.exo/policy.sealed.json) with a SHA-256 integrity hash. Session-start auto-recomposes if sources have changed. Session-finish verifies the seal and recomposes for the next session. One canonical artifact, always fresh.

How it works

Session lifecycle

Every AI agent session runs under governance. The lifecycle is simple — start, work, finish — but a lot happens at each boundary.

At session-start, ExoProtocol compiles everything the agent needs into a bootstrap prompt: governance rules, scope constraints, sibling awareness (who else is working), machine context (CPU/RAM), and operational learnings from prior sessions. The agent sees this first, before any user instructions.

At session-finish, drift detection scores how well the work stayed within scope. A closeout memento captures what was learned. The lock is released. The next agent inherits the knowledge.

Session-start intelligence

What the agent sees before writing a line of code

All advisories are just that — advisory. They never block session start. They surface in the bootstrap prompt so the agent can make informed decisions.

Entropy control

Drift detection + intent accountability

Every session gets a drift score (0–1) measuring how well the work stayed within scope. The formula weights scope compliance (50%), file budget (35%), and boundary violations (15%). It's deterministic, not vibes.

Tickets can be intents — with brain dumps, boundaries, success conditions, and risk levels. Child tickets trace back to parent intents. Orphan detection catches work that drifted away from stated goals.

Together, drift scoring and intent hierarchies give you a quantitative answer to "did the agent do what we asked?" — see the deep dive for the full formula.

Architecture

Four layers, frozen kernel

The kernel is intentionally small: load_governance, verify_governance, open_session, mint_ticket, validate_ticket, check_action, resolve_requirements, commit_plan, append_audit, seal_result. That's it. Everything else — session lifecycle, drift detection, feature tracing, dispatch, adapters, GC — lives in the stdlib.

Every CLI command has a matching MCP tool. Works with Claude Code, Cursor, and any MCP-compatible client.

Multi-agent coordination

Agent handoff with context transfer

Agent A builds the API. Agent B needs to write the tests. session-handoff atomically finishes A's session, writes a handoff record with summary, reason, and next steps, then releases the lock. When B starts on the same ticket, the handoff context is injected into its bootstrap prompt.

Handoff records are one-shot — consumed on start, never stale. The receiving agent sees exactly what was done, what needs doing, and which branch to continue from. No copy-pasting between chat windows.

Vendor agnostic

Works with any agent, any model, any SDK

ExoProtocol doesn't care which LLM is driving the session. Claude Code, Cursor, Windsurf, Copilot, OpenAI Agents SDK, open-source models — if it can read a prompt and write files, ExoProtocol can govern it.

The adapter layer generates config files native to each tool: CLAUDE.md for Claude Code, .cursorrules for Cursor, AGENTS.md for GitHub Copilot. Same governance, different surface. Switch models mid-project without losing session history or drift tracking.

Quickstart

Three commands to governed development

# One-shot setup (init + compile + adapters + hooks + gitignore + git-track)
pip install exoprotocol && exo install

# Dispatch a ticket and acquire a lock
exo next --owner your-name

# Start a governed agent session
EXO_ACTOR=agent:claude exo session-start \
  --ticket-id TICKET-001 \
  --vendor anthropic --model claude-code \
  --task "implement the feature described in the ticket"

# Finish — runs drift detection, writes memento, releases lock
EXO_ACTOR=agent:claude exo session-finish \
  --summary "implemented feature, added tests"

exo install does everything in one shot: scans your repo, generates a project-aware constitution, compiles governance, writes adapter files (CLAUDE.md, .cursorrules, AGENTS.md), installs Claude Code hooks, creates .exo/.gitignore, and commits governance files to git. Idempotent — safe to run again anytime.

Integration

MCP server

Every CLI command has a matching MCP tool. Install, point your agent at it, done.

// Claude Code / Cursor — add to your MCP config
{
  "mcpServers": {
    "exo": {
      "command": "exo-mcp",
      "args": [],
      "env": { "EXO_ACTOR": "agent:claude" }
    }
  }
}

No external services

Everything lives in .exo/

Governance state, tickets, session history, mementos, audit logs, feature manifests, requirement registries — all stored as files in your repo. Git is the source of truth. Git is the transport. No SaaS, no database, no accounts.

.exo/ is designed as its own governance namespace inside your repo. Non-ephemeral files (constitution, config, lock, tickets) are committed to git so CI pipelines, other agents, and team members all see the same governance. Ephemeral data (cache, logs, locks, active sessions) is excluded via .exo/.gitignore. exo install sets this up automatically.

For teams that want full separation, exo sidecar-init mounts .exo/ as a dedicated git worktree on an orphan branch — giving app code and governance state independent git histories. Auto-commits at every lifecycle boundary (start, finish, suspend, resume) keep the governance branch current without polluting your app history.

pip install exoprotocol is all you need.

Observability

Governance you can measure

ExoProtocol isn't just rules — it's instrumented. Every session produces structured data that feeds into metrics, traces, and fleet-level drift aggregation.