The delivery loop
Agents hand each other structured, schema-validated artifacts — never chat. The reviewer can only return a
validated APPROVED / REJECTED verdict with findings, and approval means it
reproduced the evidence itself, not that the developer's report sounded plausible.
Developer
Implements one precisely-scoped task. Reports
MISSING_PREREQ instead of improvising around a missing dependency.→
Reviewer
Independent agent, refute-by-default: re-runs every piece of evidence itself before any approval.
→
Instructor
After two failed rounds, diagnoses the root cause and either rewrites the task — or parks it with a question a human can answer in one message.
Safe to run unattended
- Durable resume: a committed run ledger (one row per task) means a killed terminal or usage-limit stop costs only the in-flight task's minutes — any fresh invocation continues from the ledger.
- Self-continuation: launching a batch also registers a scheduled job that fires "continue from the ledger" every couple of hours and removes itself when everything is done or parked.
- Parked ≠ blocked: parked tasks queue questions for a morning report; they never stall the rest of the batch. Singleton resources (one live Sierra Chart) run serialized; everything else parallelizes.
Cost discipline
- Per-task model tiers —
light | standard | critical— with the operating rule "economize on generation, never on the gate." - Template repeats run on cheap tiers with narrow-checklist reviews; heavy models are reserved for genuinely novel work; related work is batched into one task per family.
- An adaptive brake: on abnormal burn, stop launching and have the planner restructure the program.
Evidence gates — agents must prove, not claim
Verification is the hard part, and it gets harder when the target is a closed GUI application (Sierra Chart) whose message log cannot be read from outside — so an instrumentation layer exists specifically to let agents produce court-quality evidence.
Verification toolkit
- File-based structured debug logs replace the unreadable in-app message log.
- Probe studies and console tools link the production decision functions directly — no mocks — and feed them the literal bytes the live system would see.
- A Python replay driver requests bounded chart replays and reconciles them fill-by-fill against an append-only order journal.
- Mandatory loop: instrument → build → drive the app → read the log → prove which DLL is actually running before believing anything.
Skills & scaffolding
- Repo skills scaffold new strategies and encode the standard research procedures, so any agent runs them identically.
- Agent role definitions live in the repo — versioned, reviewable, and improvable like any other code.
- Ownership is split: an infrastructure agent owns shared libraries; strategy agents own isolated folders and cannot edit the shared layer.
What it shipped
- ~19 numeric kernels ported from Python to C++, each proven bit-identical, delivered batch by batch through the loop.
- A frozen 3-model trading portfolio taken through a formal gate series ending in a 100.00% parity run (0.000000 R difference) — each gate an independently reviewed task.
- 779 commits in two months on the research platform alone, with a log whose most common entry is a refutation turned into a permanent, tested rule.
- The same protocol was reused for a production LLM product delivery and generalized into an umbrella task runner usable in any repo.