Request flow

A prompt from the web app, Slack, or an automation becomes a durable command with an idempotency key. It enters the one command lane every channel shares. A thread admits one in-flight turn at a time; additional prompts, including gateway child-session requests, queue durably in the commands mailbox and dispatch serially per thread under a per-thread advisory lock.

The backend creates a run inside a thread. A reply reuses the thread’s sandbox and working directory; a root run claims a fresh sandbox, preferably from the warm pool.

The engine registry resolves a ProviderDriver for the engine, and the turn is dispatched to the thread’s resident engine session inside the sandbox: OpenCode behind its own server, Claude and Codex as persistent ACP agents behind the in-sandbox relay. A per-turn one-shot CLI runner exists only as the ENGINE_TRANSPORT=cli fallback. The engine works in its own directory and starts emitting native events.

When the engine needs to read a repository, search knowledge, use the desktop, or publish an artifact, it calls a gateway tool bound by a short-lived capability token. A destructive operation pauses on a durable approval request with a 15-minute TTL (pending, then approved, denied, or expired). A human resolves it through /api/gateway/approvals, and the agent polls out a one-shot capability bound to the exact run, tool, and normalized arguments. See Gateway tools and approvals.

Native events are translated into canonical steps and appended to the event log, with native frames retained for fidelity.

The session view subscribes to the thread stream, reduces steps into state, and renders each as a card or row. A reconnect receives a fresh durable snapshot.

On completion the run writes its terminal state and any follow-up work to the outbox in the same transaction, then workers deliver canonicalization, Slack updates, and learning capture.