PilotSwarm Architecture

A durable execution runtime for GitHub Copilot SDK agents, powered by duroxide (a Rust durable-orchestration engine). What durability buys: crash recovery, durable timers, session dehydration, multi-node scale-out.

Two runtime components

• Client — creates sessions, sends prompts, subscribes to events. Lightweight, needs no GitHub token, handles only serializable data.
• Worker — runs LLM turns, executes tool handlers, owns the Copilot runtime. Needs a GitHub token. Tools are registered here.

Both connect to the same PostgreSQL. Duroxide coordinates between them, which is why the client can hold no handler functions: everything crossing that boundary must survive a database round-trip.

The path of one turn

Client → duroxide orchestration → SessionProxy activity
       → SessionManager → ManagedSession → CopilotSession (Copilot SDK)

The rule that shapes everything: replay

The orchestration is a generator replayed from the beginning on every new event, so it must yield the identical sequence each time. Date.now(), Math.random(), crypto.randomUUID(), setTimeout, and any I/O are therefore banned inside it — the deterministic substitutes are ctx.utcNow(), ctx.newGuid(), ctx.scheduleTimer(), and activities. Changing the yield sequence creates a new orchestration version, which is why versions are frozen rather than edited.

Storage

Session state lives in the CMS (copilot_sessions schema); facts live in their own schema. All data access goes through stored procedures with versioned migrations applied under advisory locks, so concurrent workers can start safely against the same database.

Composition

A session can spawn sub-agents, each its own session with its own conversation and tools, running concurrently under a parent. Capability arrives as agent packages: a manifest plus agents, skills, worker tools, and MCP servers.