This article began with two planning screenshots for a tiered group of AI agents.
They routed search and inventory to a scout tier, criticism and specified edits to a critic/editor tier, and design or original copy to a writer tier. A governing session coordinated the work.
The routing table was sensible, but the more useful line sat beneath it:
That shifted the design question from model selection to write authority: who can change state, within what scope, and with what evidence?
A governing session orchestrates the work, merges findings, launches checks, and lands commits. Find-and-list stages go to a scout model. Judging, verification, and specified edits go to a critic/editor model. Design and original copy go to a design/writer model. Seven bounded work packages proceed one writer at a time. Each change then moves from writer to reviewer to a fresh verifier; fixes return to the assigned writer.
Today’s best scout, critic, or designer will not keep that title forever. Prices change. Latency changes. Context windows change. A new release can overturn a routing table quickly.
The roles are more durable.
A scout finds and lists. A critic judges. An editor makes a specified change. An architect designs. The governing session holds the brief, reconciles findings, and decides when a result is ready to land.
This is not a claim that one named model is universally better than another. The assignments in the diagram came from one implementation plan, not a laboratory benchmark. The useful idea is to match the stage to the least expensive model that can do the job reliably—then measure what actually happens.
Search agents should be able to inspect broadly. Reviewers should be able to challenge a design. Verifiers should be able to reproduce a finding from fresh context.
None of that means they need write authority.
This distinction sounds small until several agents are working at once. If every worker can edit the same files, a swarm becomes a race. One agent fixes a name while another rewires the type. A third applies a reviewer’s suggestion against stale state. The final diff may pass a test while quietly combining three incompatible intentions.
Parallel reading is easier to coordinate than concurrent writes. Parallel judgment can be useful. Parallel writing is where the collisions begin.
“One writer at a time” only matters if the system enforces it.
If the design uses a write lease, enforce it at the boundary that owns the state rather than only in the prompt. Record the active writer, its allowed scope, and the version of the state it inspected. Reject stale, overlapping, or out-of-scope writes.
The point is not to make the orchestration elegant. It is to make an unauthorized change difficult.
That same rule applies to vocabulary controls, file boundaries, shell access, delivery destinations, and any other place where an agent can turn an interpretation into an external effect. Permissions have to live at the boundary where the effect occurs. Instructions inside a prompt are not a security boundary.
A reviewer asks whether the work is good. A verifier asks whether a specific claim is true.
Those jobs should not collapse into the writer checking its own answer.
In the planning screenshots behind this figure, the intended flow gives each step a reviewer and each finding a fresh verifier. If a fix is needed, it returns to the assigned writer rather than becoming a reviewer edit.
That is a stronger pattern than “use more agents.” It preserves responsibility. The writer owns the change. The reviewer owns the critique. The verifier owns the reproduction. The governing session owns the decision to land.
Independence still needs care. Two agents using the same model, prompt, and context can share the same blind spot. Fresh context helps, but meaningful independence may also require different evidence, adversarial probes, or a different model family.
A single writer can become a bottleneck. It may leave expensive reviewers waiting. It may slow a large change that could have been safely split across isolated worktrees or disjoint files.
That is the trade.
I would rather start with clear ownership and deliberately relax it than start with a swarm of writers and try to reconstruct responsibility after the merge.
When work can be partitioned cleanly, use separate branches, sandboxes, or resources with explicit ownership. The principle is not “only one agent may ever write.” It is “only one accountable writer may write to a given state boundary at a given time.”
The authority model becomes operational at the command surface.
The operator should be able to see who requested a change, who held the lease, what scope was allowed, what command ran, what changed, which reviewer objected, what the verifier reproduced, and whether Undo is still possible.
That means explicit verbs and inspectable state:
plan · lease · apply · status · diff · review · verify · receipt · undo
Protocols such as MCP and A2A can help with discovery and coordination. For operators, the important boundary is the command surface: the point where the system checks permission, executes the request, records the resulting state, and exposes a recovery path.
A chat window can summarize the run; the receipt should show the request, permission check, state change, verification result, and recovery path.
Model routing and parallel agents do not create accountability on their own. Accountability comes from a named writer, a bounded state surface, independent review, and evidence that the final state matches the claim.