A planner, parallel researchers, a writer and a reviewer, built so a crash, a database failover or a model outage cannot lose or repeat work.
How it works
›Every change in a run is written to a durable event log first. State in the database is a fast copy that can be rebuilt from it.
›Delivery is at least once, so every step and every tool call carries an idempotency key and a repeat is harmless.
›Workers are replaceable. A coordinator resumes unfinished runs from the last checkpoint; retries use backoff and bad events go to a dead-letter store.
›One run fans out into many calls (about 20 model calls, 12 tool calls and 40 state writes). The simulator models this as step events per second, not per run.
What you'll build
The run API and its data model
An event log, workers and a state database
Agent, tool and state consumer groups with model capacity
A peak design inside a monthly budget
Survival of a worker crash, a state-store failover and a model-provider outage