How it's built · the engineering
A workflow-automation engine written from scratch — no orchestration framework underneath. Single-purpose specialists with fixed contracts, composed into validated control-flow graphs, run by a concurrency-safe dispatcher, with human gates and a learning loop. Every decision below is one I can defend end to end.
The reusable parts — one job, reused everywhere
verify runs in all three recipes. Its job never changes — does this output actually
hold up? — only the standard it's checked against differs. Same code, three configs; that's
why a new use case mostly reuses what's on the shelf instead of building from scratch.
“the classification and routing fit the issue, and the reply is relevant and asks for anything genuinely missing”
pass · 0.60 — flagged: the reply never asks for the Turbopack / Next.js version, which actually matters here.
“on-brand (no hype, no emojis, numbers over adjectives), coherent, and not making unsupported factual claims”
pass · 0.82 — flagged: “numbers over adjectives” barely exercised — the piece stays conceptual.
STRICT — ≥ 2 concrete numeric stats · names a specific failure mode · no hype words · no emojis · under 4 sentences
pass · 0.90 — no issues; this is the bar the draft→rewrite loop chased until it cleared.
Same specialist, three jobs — the recipe author sets the standard, the specialist does the rest. Most parts across these recipes are shared exactly like this; only the recipe-specific middle is new.
Under the hood — three parts, click to open
Describe a task → the Composer builds a validated workflow → the Dispatcher runs it on a board → the Specialists do the work and learn. One line each; open any for the detail.
Given only a plain-English description, the Composer re-wrote specialists I'd hand-built — scored against their real, human-labeled evals, it matched the originals. When it can't cover a use case it flags the missing specialist and refuses to call the recipe runnable — it doesn't fake capability. The Validator then statically checks the graph (entry/exit, reachability, loop termination, contract compatibility) and rejects invalid ones up front, not halfway through a run.
| specialist | auto-written | hand-built |
|---|---|---|
| classify | 6/6 · 100% | 6/6 |
| rank | 3/3 · 100% | 3/3 |
| route | 3/3 · 100% | 3/3 |
The board is the shared surface the dispatcher writes onto. Work streams in and flows through the graph concurrently; a specialist clones per item (the stacked chips); when verify flags a draft it loops back to rewrite (the red curve); the rest wait at the gate for a human. Deliberately dumb, single-writer, concurrency-safe by construction — the piece I'm most proud of. Flow is illustrative.
Each specialist is a tiny agent with one fixed contract, one job — small enough to test and trust on its own. And it learns: a deliberately weak one went 4/8 → 8/8 from six curated examples on an independent eval (retrieval few-shot, no fine-tuning), then was promoted to trusted. the real run →
Cold, it follows a wrong instinct. Six curated examples → 50% → 100%, then trusted. Retrieval-injected few-shot, no fine-tuning.
classify # item → one category in { item, categories, criteria } out { label, confidence, reasoning }
The same instance labels bug types for triage and content angles for content — only the categories change. That's why parts are reusable.