When I started wiring agents into my daily work, it went about as you'd expect: a flood of half-finished changes, conflicting edits across the same files, no shared memory of what anyone was supposed to be doing. The agents were capable. The orchestration was not.
What follows is the set of pillars that stabilized it — not a tutorial, not a product pitch, and not something to copy. Take what fits, leave the rest.
1. God, King, Worker — shaped delegation, not a flat pool
Flat agent pools — spin up N workers, throw tasks at them, collect results — break down when tasks have dependencies or need judgment. Some decisions need direction. Some need routing. Some just need raw execution.
The shape that worked here is a three-role split:
- God sets the direction: what are we building, why, and what does "done" mean. One voice at the top.
- King routes the work: reads the contracts, decomposes the plan, fans out to workers, and validates results against the source of truth before anything ships.
- Workers execute with fresh context windows — no accumulated drift, no stale assumptions from three tasks ago. Each worker gets exactly the slice it needs and nothing else.
This isn't hierarchy for its own sake — it's about giving each role the right context. Workers carrying full project state burn tokens and drift. A King doing the work loses the bird's-eye view. A God micromanaging workers becomes the bottleneck.
Batch width matters. Fan out as wide as the work genuinely decomposes — not wider. Serializing independent slices wastes time; padding the batch with invented work wastes compute. The King finds real seams, states cross-slice contracts up front, and lets workers run in parallel without mid-flight negotiation.
Anti-copy-paste note: your team might need two roles or five. The point isn't the names — it's that delegation has shape matching how your work decomposes.
2. Contracts as source of truth
The fastest way to break an agent system is to let it guess. Agents extrapolate brilliantly and forget which extrapolation was wrong last time.
Contracts fix this. Before any edit, the agent walks the contract chain for the file it's touching. The contract says what invariants hold, what seams exist, and what changed last time someone was here. After the edit, the contract updates. Gaps get filed and tracked.
This isn't documentation. Documentation drifts. Contracts are blocking — if a contract says "never add a subcommand that implies per-agent identity," the agent cannot add one. It's a live constraint, not a stale paragraph.
The contract layer handles cross-cutting concerns too: deploy rules, testing gates, observability contracts, LLM routing rules. Agents that touch the system read the same source of truth.
Anti-copy-paste note: the contract format here fits this project's size and velocity. A team of two might use a shared Markdown file. Fifty engineers, fifteen services — something heavier. The principle — "agents never guess what they can read" — is what travels.
3. Plan on the surface, route through contracts
Agents are too eager to start coding. Give one a task and it'll open files before thinking about the shape of the change.
The fix: planning must happen on a visible surface before execution. The plan names what changes, what stays the same, what contracts it touches, and what the acceptance criteria are. The plan itself is a contract artifact — future agents (or future you) can read it to understand why something was built the way it was.
Plans serve more than one audience: the human operator, the King decomposing work, Workers getting their slice, and the agent picking up this codebase months from now.
Anti-copy-paste note: the planning format here is property-based — "what must remain true after this change" — because that's what agents respect. Your team might plan differently. The principle is that planning happens before action, on a surface everyone can see.
4. Drift detection as a first-class concern
Systems that are never checked drift. Agent-orchestrated systems drift faster — agents are confident and fast, a bad combination when the ground has shifted.
Two checks help catch this:
- Architecture drift scans compare the live codebase against stated principles. If a principle says "every test creates a scratch workspace with guaranteed teardown" and a new test doesn't, the scan catches it. Gaps are either bugs or evidence that a new principle is needed.
- Contract audits walk the full contract chain for a path and flag anything that doesn't match. Cross-references, stale constraints, missing gap resolutions — surfaced before they cause surprises.
Anti-copy-paste note: pick a few invariants, check them automatically, treat every gap as a fix or a new invariant.
5. Every session ends with a retro
Agents make mistakes. The question is whether they repeat them.
After every significant session, the agent runs a retro: what went wrong, at what step, was it a model issue, a harness issue, or a task-scoping issue. Triaged by category, patterns become visible across sessions. A model that consistently fails at type-aware refactors gets flagged. A harness limitation blocking a whole class of tasks gets surfaced.
The retro output can inform contracts and planning, so the next session's agent can reference the last mistakes before starting.
6. Urgent work has its own shape
Urgent work doesn't fit the normal delegation pipeline. You don't want God→King→Worker fan-out when something needs fixing now.
Urgent triage is a separate router: categorize the issue, scope its impact, run probes, route to the right responder. It trades planning depth for speed. The first job is containment — understanding can follow.
Anti-copy-paste note: What matters is that your normal workflow and your urgent workflow are different things — don't try to make one pipeline handle both.
None of this is magic. It's six patterns that emerged from watching agents fail in predictable ways and building guardrails at the failure points. Delegation needs shape. Contracts need to block, not just document. Plans need to be visible before action. Drift needs catching before it compounds. Sessions need to learn. Urgent work needs its own path.
Take what makes your system safer. Ignore the rest. Your project is not my project — and that's the whole point.
Top comments (0)