--- title: Give your agents permission to argue description: "What running Supervisor, Lead, and Peer on real projects taught me about orchestration, pushback, and the cost of every message." date: 2026-09-08 --- I run coding agents the way most people do: a main agent plans, subagents implement, results get merged. For months the setup felt fine. Then the projects got harder, the slices started stacking on each other, and a pattern emerged I could not unsee. My subagents were as capable as my main agents and never got to show it. Every brief arrived pre-solved. Every finding that threatened the plan died quietly. I spent the last quarter rebuilding how my agents work together. Three roles, strict rules about who may talk to whom, and one principle above everything: a worker's objection has to be able to reach someone who can act on it. ## The brief that solves its own problem It starts innocently. You ask the main agent to verify approach A. It writes a brief: check aspect X, do not reopen aspect Y, answer PASS or FAIL in five bullets. The subagent does exactly that, well, and nothing else. Whether A deserves to exist never gets asked, because the brief answered it before the worker arrived. I started calling this pre-solving. The coordinator defines the problem, picks the hypothesis, sets the criteria, bounds the scope, then hires help for the remainder. Push it far enough and the subagent becomes a function. Input goes in, a verdict comes out, and nothing learned along the way travels back uphill. The waste is specific and measurable. My subs run the same models at the same effort as my mains. The analytical depth is present. The orchestration never calls on it. I was paying senior-engineer rates for scripted triage. ## The projects where it actually hurts Small parallel work does not need any of this. A few hundred CRUD endpoints with clear lifecycles split sideways just fine: main divides, subs implement, merge, done. Some jobs finish faster with one agent working straight through than with any committee I could assemble. The hard projects look different. Features stack vertically: each slice depends on architecture the previous slice invented that morning. You start the next feature and the old API lacks a capability. A responsibility sits in the wrong module. A mechanism from the plan has to wait a cycle. On a human team, the person doing the work walks back to the lead and says so. Sometimes they ask another module's owner for a change. Sometimes the foundation needs redoing. My old setup had no road for that conversation. Findings either died or got squeezed into workarounds that protected the plan. Tests certified the workarounds. Everyone moved on. Stronger models made it worse: a capable agent that may only complete tasks defends a bad decision longer and more articulately than a weak one. The fix was never a weaker agent. It was permission to object, plus a path for the objection to land somewhere with power. I learned the mirror image the hard way. Early on I overcorrected, and every agent started performing independence. Overlapping debates drowned two sprints before I unwound the rule. The goal was never more argument. It is the right objection reaching the right person and changing the work when change is warranted. Everything else is noise, and I now treat debate volume as a cost metric, not a health metric. ## Three jobs, not three personalities My setup has three roles. The Supervisor keeps shared state, watches every workspace, remembers past failures, and talks to me. The Lead owns one project: planning, coordination, integration, acceptance. The Peer does scoped work and may challenge a premise inside that scope. The names matter less than the diagram. These are responsibilities and powers, not characters. No strict-architect persona, no skeptical-senior voice. If I renamed everything tomorrow and kept the information flow, the escalation paths, and who can change what, the system would work identically. Three agents with elaborate titles sharing one context and equal write access would not be this system. That would be costume. ```text Human | | briefs, steers, accepts v Supervisor ---- monitors, patches instructions, spawns fresh leads | (read-only, on demand, never polls) | assigns workspace + outcome v Lead ---------- plans, coordinates, integrates, accepts | (never implements, never presolves) | delegates scoped work v Peer(s) ------- implements, reviews, challenges premises (believes it works for a human) ``` Note what is missing: no arrow from Peer back to the brief except through the Lead, and none from Supervisor into implementation. Every line in the diagram is a permission. Remove one and something specific breaks. Let the Supervisor implement and the Lead stops owning outcomes. Let peers share one context and dispositions collapse into groupthink. The diagram is small enough to hold in your head, which is the point. If your orchestration needs a wiki page to explain, it has already failed. The Peer believes it works directly for a human. It never hears about supervisors, rooms, or orchestration. It gets default instructions plus a few lines against known bad habits, and it judges within its scope. A worker that knows it is stage-managed performs for the manager instead of the work. One profile covers every peer disposition: engineer this hour, reviewer the next, architect when the lead needs a hard design question answered. The lead picks per task. The peer stays simple. The Supervisor stays mostly idle and read-only. It watches, takes notes, patches instructions when it spots a repeated anti-pattern, and spins up a fresh Lead when the current one is too deep in a rut to recover. I call it up when I need it. I never let it poll: an early version looped over worker panes checking completion and burned context for nothing. Notifications replaced polling within a week. ```text polling (before) notify (after) --------------- -------------- sup ----ask----> lead sup lead sup <---busy---- lead sup <---done---- lead (one message) sup ----ask----> lead sup <---stuck--- lead (only on trouble) sup <---busy---- lead ...10,000 tokens later... ``` The left column scales with impatience. The right column scales with events. On a quiet project the difference is small. On a busy one it is the difference between a supervisor that costs almost nothing and one that eats a junior engineer's quota just checking whether anyone needs it. ```toml [lead] presolve = false # never implement while leading implement = false delegate_via = "rooms" # no native subagents under this lead poll_workers = false # wait for completion notices expect_challenge = true # peers may dispute material premises verdict = "one binding call per disagreement, then move" ``` ## Routing models like a lineup Every role gets the cheapest model that can hold its constraints. Fast small models scout and handle bounded implementation. Mid-tier models lead bounded projects. Heavy models review, design, and arbitrate. My standing mix: a medium model leading, a max-effort model reviewing, a fast cheap model implementing. The picks rotate with pricing and releases. The rule does not: never staff a role that must obey constraints with a model that treats constraints as suggestions. I learned that one paying full price, watching cheap models implement things explicitly forbidden to them, including spawning duplicate workers when one appeared stalled. Effort follows the same logic. Routine slices run lean. When a task proves hard, the whole peer group steps up one level together rather than letting one hero agent burn quota alone. These are my working rules from one quarter on my own projects, not thresholds the field has settled. The handoff after five or six rounds, the lineup above, the no-polling default: all of them are things that worked for me, stated exactly at that level. ## Handoff before the rot Context degrades with compaction. After five or six rounds, a lead defends decisions it can no longer reconstruct. My answer is a handoff: the supervisor flags the session as saturated, the old lead finishes what is in flight, writes down what it learned, and a new lead takes over with that note attached. I gave the operation a one-word command. Say it and the agent wraps up, hands over, and stands down. What I have not solved is where experience lives afterward. Who reads the handoff note, how it stays short enough to matter, when it expires. Every team running anything like this lists the same open item. I would rather admit that than publish a confident format nobody follows. Beside it sit two more asks for my tooling: control-plane events for context percentage and review counts, so the supervisor gets paged instead of checking, plus a standard shape for the experience note itself. ## The token bill disciplines the design My most expensive single session ran 4 billion tokens across nearly 400 subagents. A search worker once burned over a million tokens in one call and returned little worth keeping. A five-hour quota window yielded barely an hour of effective work. Those are numbers from my own sessions: counts from the transcript and the invoice, not controlled measurements, and "effective work" is my judgment of what moved the project, not a metric anyone else can rerun. The conclusion I draw from them is proportionate to that: a reason to watch cost while I work, not a law about swarms. Ultra modes that spawn swarms to look busy are a tax on attention disguised as effort, in my setup, on the workloads I run. So every message round, every review loop, every ceremony now has to earn its tokens. My best upgrades this quarter were subtractions: a removed message round, a responsibility returned to its owner, a task type freed from supervision it never needed. A methodology that tracks its own cost gets simpler over time. One that does not gets more elaborate and calls it maturity. ```text where a 5-hour quota window actually goes (our worst session) |████████████████████████| agent working ............ ~1.0h |░░░░░░░░░░░░░░░░░░░░░░░░| polling + status checks .. ~1.5h |▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒| redundant reviews ........ ~1.0h |························| stalled / waiting ........ ~1.5h 0h 2.5h 5h ``` I drew this chart after the session, not during it, which is itself the lesson. Nobody watches the meter while the swarm looks busy. The first fix was not a better model or a smarter prompt. It was a rule: the supervisor gets paged on events instead of checking, reviews happen once with a verdict instead of looping until everyone agrees, and stalled workers get killed instead of supervised. The next session on similar work finished inside two hours. Similar, not identical: same project, same kind of slices, my own before-and-after, no control run. I report it as an observation that justified keeping the rule, not as proof the rule generalizes. ## When not to use it Small changes go faster with one agent end to end. Work that needs continuous human judgment on feel, game feel, interface taste, combat pacing, does not belong in a room of agents. Some jobs want a conversation, not a committee. My setup fits work with vertical dependencies, shared foundations, and decisions that outlive the session. It fits teams willing to maintain the telemetry that keeps it honest: which conflicts repeat, which escalations change anything, which reviews catch real defects, which interventions arrive late, which ceremonies only burn tokens. Give the worker a road back to the plan. Watch what travels on it. Then change the roads.