Why a durable bus
JetStream gives durable streams, per-consumer acknowledgement and replay, with a much lighter operational footprint than Kafka on a small lab cluster. A consumer that crashes resumes from its last ack instead of losing the gap.
Atlas: an event-driven trading platform, built by an agent fleet I designed and govern.
Two layers. The runtime is a set of small services on a durable event bus, built around one rule: when the system is unsure, it stops and says so. The build system is the fleet of AI agents that writes that runtime, under a review process whose strictest gate sits at the money boundary.
I don't hand-type most of this code. I designed the architecture, wrote the specifications, set the review rules, and I own what ships.
Every box below is drawn from the running system. No account data, no strategy parameters.
- 01 · Runtime
- 02 · An order, failing safely
- 03 · The regime state machine
- 04 · The build system
- 05 · Where the tools fall short
01 · Runtime
Small services, one durable bus, one source of truth
Market and chain data come in, get normalized, and flow as typed events through NATS JetStream. Each service owns one decision and records it in Postgres before anything downstream acts on it. Every step in the logical flow below is an event on the bus.
← scroll the diagram →
Transactional outbox
A service writes its state change and the event describing it in one database transaction; a relay publishes afterwards. So a crash can never leave the database and the bus disagreeing.
Structural isolation
Broker SDKs are imported only inside execution adapters. Strategy, risk and portfolio code cannot place an order even by mistake, and live execution is a separate service that ships disabled.
Contracts, not conventions
Events travel in versioned envelopes checked against a registry. An event that fails its contract is quarantined for a human, not silently dropped or half-applied.
02 · Failure handling
An order, failing safely
The hard question for any execution system: the process sends an order, then crashes or times out before it learns the result. Did the order go through? Atlas answers with a stable client order ID, a lookup at the broker before any retry, and a hard stop when the lookup can't settle it.
← scroll the diagram →
Idempotency by construction
The client order ID is derived from the order request itself, so a retry or replay produces the same key. The broker can recognize a duplicate, and we can look the order up by that key.
Reconciliation is a separate witness
A separate service reads the broker's own account through a client whose whole surface is read-only calls, then compares it with our book to the cent and to the share. A discrepancy is recorded with its amount and sent to a human.
Where limits live
Per-trade limits are the risk service's durable decision, and execution re-verifies that decision synchronously at submit. The switch and control posture sit above both. Changing any of them is a gated action (see 04).
03 · One algorithm, in detail
The regime state machine, and why it doesn't flap
The regime engine classifies the Bitcoin market into one of six cycle states from five groups of signals. A naive classifier flips state every time an input crosses a threshold. This one uses hysteresis: entering a state is easy to justify, but leaving it takes sustained evidence.
Dwell
A state must hold for a minimum number of days before it can be left. The count lives in config, not in code.
Exit buffer
A held state counts as broken only when an input is beyond its cutoff by a margin. A value wobbling on the line can't cause a flip.
Edge-triggered shocks
A market shock may bypass dwell and the step limit, but only once per shock event. An earlier level-triggered version held the gate open for days after a single crash and produced one-to-four-day flips. Review caught that.
Regimes persist
If no rule fires on a given day, that's a gap in rule coverage, not a fact about the market, so the state holds. UNKNOWN is reserved for missing data. Before this change, 29% of days were UNKNOWN and 42% of spells re-entered the state they had just left.
Deterministic replay
Hysteresis makes the state path-dependent, and inputs arrive late. So each run replays the full history from the earliest data instead of appending to yesterday's answer. Writes are idempotent upserts.
No magic numbers
Every decision cutoff is loaded from one config file, and CI rejects numeric literals in the decision code. A cutoff still marked draft makes its rule unevaluable, so the rule can't fire on it.
04 · The build system
How an agent fleet ships code without being trusted
Every change starts as a written specification in the task tracker and ends as a reviewed merge. No agent approves its own work. The dispatcher never merges, and review comes from a different model family than the builder. Changes that touch money go through a stricter path with a human at the end.
← scroll the diagram →
Specs over prompts
A task is a structured spec with acceptance tests, rendered into the builder's prompt once. Anything a builder needs has to be in the spec. A comment added later never reaches it.
Review that can say no
A reviewer that can only approve is decoration. Refusals are routine, carry a named defect and fix, and loop back to the builder.
The record precedes the action
Decisions at the money boundary are written to an append-only ledger before they take effect. A row written afterwards is a story about an action, not an authorization for it.
05 · Where the tools fall short
What agents get wrong, and the review that catches it
AI-written code fails in recognizable ways, and most of them look like success. These are real failures from this system, each now a standing review check.
A green suite that never ran the code
Over a thousand tests passed, and none of them called the function under review. Every sign-off now proves the suite reaches the change: mutate the change, and a named test must go red.
Each side correct, the join wrong
Two components, each correct against its own tests, were wrong together. Neither suite could see it. Composition defects need a test that spans the seam.
The near-neighbour question
A freshness check read a different table than the one it vouched for, and stayed green exactly when it was needed. Before trusting an instrument, state what it literally measures.
Unknown is not tripped
A draft of the exit exemption in 02 caught any kill-switch error, so an unreadable switch would have let orders through. Review narrowed it to a confirmed trip and added a test proving an unreadable switch still blocks.