Multi-Agent Workflow
A specialist for each step. Context they can read, not change.
In 30 seconds
- Problem
- How do you give coding agents clear roles, and delivery context they can read but not change?
- My part
- I built the workflow: specialist coding agents that implement, review and verify, read-only tools for CI and source-control context, and a searchable knowledge base compiled automatically from work sessions.
- Result
- The build trace is a recorded run of this same workflow: 52 steps and 16 commits from the Nov 10–11, 2026 redesign of this site, errors and retries included.
The workflow in numbers
- Delegations
- 514 delegations to subagents across 121 sessions, Oct 9–Nov 11, 2026.
- Sessions
- 38% of those sessions delegated work.
- Reviews
- 93 review calls.
- Verifications
- 57 verification calls.
- Read-only lookups
- 709 lookups through the read-only CI and source-control tools.
- Knowledge base
- 199 pages, compiled from 130 of 131 recorded sessions.
- Searches
- 188 searches of the knowledge base.
- This site
- 55 commits over five days, through November 11, 2026.
How it works
The build trace is a recorded run of this same workflow. One agent implements, one reviews, one verifies, and an orchestrating agent plans, delegates, integrates and commits.
The agents do real work with write access: they edit files, run tests and commit. What they know about delivery, the CI runs and source control, they read through read-only tools, so an agent can’t start a deploy or a merge by mistake. Anything that touches production waits for my approval.
When a review or a check fails, the findings come back to me. Either I correct the agent so it learns to do it properly, or I take that step over myself and hand it back as a worked example. Then the loop runs again.
In the 77 traces of this site’s build, review and verification were selective: a verifier ran in 2 of 108 delegations and a reviewer in 14, and “Review before commit” passed in only 12 of 32 scored traces.
Reproduce this Evaluators · dashboard Trace data · JSON
- Orchestrator Plans and delegates
- Agent Implements
- Agent Reviews
- Agent Verifies
- Me Correct or take over
- Me Approve production
- Result Verified change
- The orchestrator hands a task to an implementing agent.
- The change goes to a reviewing agent.
- If the review passes, a verifying agent runs the checks.
- A failed review comes back to me.
- A failed check comes back to me.
- I correct the agent, or take the step over and hand it back as a worked example, and it runs again.
- A verified change lands.
- If it touches production, it waits for my approval.
- Once I approve, it goes ahead.
- Passes
- Fails, back to me
- My steps
Where the work goes
| Role | Delegations |
|---|---|
| General purpose | 142 |
| Implementation (loop role) | 104 |
| Quality review (loop role) | 93 |
| Verification (loop role) | 57 |
| UI and design | 34 |
| Analysis | 19 |
| Housekeeping | 19 |
| Release helper | 18 |
This site as a test
This site is where the workflow is easiest to see. Up to a fixed commit on November 11, 2026, it took 55 commits over five days. The recorded replay covers 16 of those commits, from the Nov 10–11 redesign.
| Day | Commits |
|---|---|
| Nov 7 | 2 |
| Nov 8 | 11 |
| Nov 9 | 7 |
| Nov 10 (in the replay) | 18 |
| Nov 11 (in the replay) | 17 |
| Checkpoint | Tests |
|---|---|
| Nov 9 | 39 |
| Nov 10 (a) | 65 |
| Nov 10 (b) | 94 |
| Nov 11 (a) | 102 |
| Nov 11 (b) | 139 |
| Nov 11 (c) | 160 |
| Nov 11 (d) | 163 |
| Steps | Count |
|---|---|
| Recorded steps | 52 |
| Ended in an error | 8 |
| Then retried or fixed | 6 |
Reproduce this Build trace page Trace file · JSON
Why I work this way
I think more of engineering will look like this: you split the work, delegate it to agents, and automate the checks around them. My time goes to the parts that need judgment: what to build, how to split it, and whether the result is right.
Delegation only works with a gate. Agents can be wrong, and they sound just as sure when they are. An edit, a test run or a commit is easy to read and undo; a production change isn’t. So the agents ask first, and I approve.
One hard decision
Each handoff between agents costs something. The receiving agent gets a summary instead of the full context, and a task that dies midway has to be handed off again.
My conclusion: keep one agent in charge of integration and commits, and add specialists where an independent check is worth more than the handoff. The multi-agent workflow I built is set up that way: one subagent implements, one reviews, one verifies, and they get read-only access to delivery tools.
One limit
In the recorded run, 8 of its 52 steps ended in an error, and 6 of those are followed by a recorded retry or fix. Both tasks that stopped midway and left partial edits behind were delegated worker tasks. One was interrupted and one lost its connection, and both were resumed.
There is no second run with more or fewer agents, so the trace cannot tell you whether this split beat one agent doing everything. The counts above show how much I use the workflow, not how well it works, and I don’t publish success or approval rates.