Platform
A control plane, workers on your machines, and the agents you already use
The control plane holds the queue, policies and history. Workers run next to your code, drive coding agents and report back. Everything else — recovery, verification, Git — happens on that path.
Architecture
One control plane, many workers
Workers connect outbound over HTTPS and WebSocket, so developer machines and build servers need no inbound ports. A worker that loses its connection keeps running its tasks and syncs later. See the concepts.
Control plane
queue · scheduler · policies · audit · API
Outbound HTTPS and WebSocket from each worker
Worker · laptop
macOS
web-app
project
Claude Code
agent
Own login (Claude)
provider
Worker · build-01
Linux
api
project
Codex
agent
OpenAI API
provider
Worker · desktop
Windows
mobile-app
project
OpenCode
agent
Ollama (local)
provider
Worker
Everything that touches your code runs here
Agents, the model gateway, Git, verification and capabilities all run on the worker, as your user, inside mapped project folders.
Control plane
HTTPS for state · WebSocket for offers and heartbeats
Worker (native process, runs as you)
Agent manager
adapters: claude-code, codex, gemini, opencode, aider
Provider manager + model gateway
own logins, add-on models, 127.0.0.1 only
Git manager
task branches, no destructive commands
Verification engine
tests · types · lint · build · browser
Capabilities
skills · MCP servers · plugins
Recovery + event buffer
checkpoints, leases, offline buffering
Credentials in the OS credential store · local UI on 127.0.0.1:47821
Task lifecycle
Explicit states, visible reasons
A task is queued, claimed, prepared, run and verified. Waits for limits or input do not count as runtime; failures that need a person say why.
- QUEUED
- CLAIMING
- PREPARING
- RUNNING
- VERIFYING
- COMPLETED
- WAITING_FOR_LIMIT · WAITING_FOR_INPUT — pauses that don't count as runtime
- VERIFYING → RUNNING — failed checks go back to the agent
- RECOVERY_REQUIRED — a person decides; retry continues from the checkpoint
Recovery
Limits and crashes are routine, not failures
Checkpoints let any session — or another worker — continue a task. The fallback policy decides whether to wait, switch agent, provider or model, or ask a person.
Provider limit
reported by the agent
Checkpoint
.agent-orchestration/
Wait or fall back
policy: wait · agent · provider · ask
Resume
same task, next session
Capabilities
Skills, MCP servers and plugins, per scope
Before a task starts, the worker gathers the capabilities installed for its organization, project and task, keeps the compatible and healthy ones, and hands them to the agent.
Task
scope: org · project · task
Capability plan
compatible + healthy + approved
Skills · MCP · plugins
prompt · tools · hooks
Agent
runs with them
Principles
Enforced in code
Agent-neutral core
The scheduler, task engine and dashboard contain no agent-specific logic. Each agent is an adapter.
Agent ≠ provider
Which CLI runs and which model it uses are independent choices, made per task by policy.
MongoDB is the source of truth
Claims and leases are atomic database updates. The queue only signals, so losing Redis loses no work.
Explicit state machine
Tasks move only through declared transitions; every step is an event with a correlation id.
Tenant isolation
Organization ids come from verified membership, never from requests. Every query is scoped.
No shell interpolation
Commands are argument arrays; prompts go through stdin or files, never the command line.
Read how each part works.
The documentation covers every component, with its verification status.