You hand an agent a job that is too big for one pass. It comes back with something confident, well written, and wrong in three places nobody checked.
So you split the work across several agents, and now two of them are editing the same file and quietly undoing each other, and the transcript still looks fine.
Both problems come from the same gap: nobody decided who does what before anything was spawned. This is how we structure ours, what we got wrong, and the rules that survived contact with real work.
A role is a decision, not a task
The first version of our team was a list of job titles: designer, developer, QA, writer. It read like an org chart and it did almost nothing, because a title describes a kind of work rather than a call that has to be made.
The version that works defines each role by the decision it owns. Not "the architect designs the system" but "the architect decides whether this can be built on the platform we are on, and rejects direction that cannot." Not "the PM writes specs" but "the PM decides what every editable thing is called, what type it is, and where it lives, so no developer has to guess."
The test: if you cannot name a decision the role makes that would otherwise be made badly or not at all, the role is ceremony. Delete it. Every role you keep is a routing rule you have to remember.
Write it down as a file, not a prompt
A team that lives in a prompt gets re-described every session, drifts every time, and cannot be argued with. A team that lives in a file in the repository can be read, corrected, and cited.
Ours is a single markdown file at the root. It carries the roles, what each one owns, what each one must have read, the staffing patterns, the escalation paths, and the rules that keep getting broken. When something goes wrong twice, the fix goes into that file rather than into a one-off instruction that expires.
The practical benefit is that agents can read it. An agent that starts a task by reading the charter knows who to escalate to and what it is not allowed to decide, without you saying so.
Nobody is instantiated by default
The failure mode on the multi-agent side is not too few agents. It is spinning up the whole team for a one-line change.
So the charter carries a staffing table: work type on the left, the roles to instantiate on the right. A bug fix gets the owning developer and one reviewer. A new product gets the full board. A research question gets three read-only agents in parallel and nobody else.
Default to the smallest pattern that covers the job, and scale up only when the work crosses into the next row. An unnecessary agent costs more than tokens. It is a voice in the transcript with an opinion, and opinions have to be reconciled.
Make two roles argue on purpose
The single most useful structural trick we found: pair the roles that design things, and require them to critique each other before anything reaches approval.
We have two architects. One owns the overall system, one owns the components. Each reads the other's proposal, names the specific failure mode they expect, and they iterate until they have a plan both will defend. Agreement without at least one round of real challenge is treated as a defect, because it usually means neither of them looked.
This matters more with agents than with people. An agent asked to review a plan will tend to find it reasonable. An agent asked to refute a plan, with the instruction to default to rejection when uncertain, finds things. The framing does most of the work.
The same applies to verification. A single agent asked "is this finding real?" agrees with itself. Several agents, each given a different lens — does it reproduce, is it a security issue, is it a performance claim — catch failures that redundancy alone will not.
Say what each role must have read
The most expensive rework we had came from work that was wrong before anyone wrote a line: direction the platform could not express, specs that assumed behaviour the system does not have.
The charter now carries an accountability table. Each role, the documents it must have read, and the specific thing it is accountable for catching. The creative role is accountable for proposing nothing the platform cannot render. The product role is accountable for specs precise enough that no developer improvises.
This is not about making agents read more. It is about moving the constraint check earlier than the build. A constraint discovered by a developer costs a full loop; the same constraint named in the brief costs nothing.
One owner per file
Two agents working the same file in the same pass will collide, and the way they collide is quiet — the second one rewrites work the first one did, and the transcript looks fine.
So work is split by surface, never by task size. Core and components and motion. Module A and module B. Page A and page B. Never "you write the markup and they write the styles."
If the work does not split cleanly along file boundaries, it is sequential work, and running it in parallel will cost more than it saves. Accepting that is what makes parallelism safe everywhere else.
Parallelise the work, serialise the gates
Squads run at the same time. The chain from direction to architecture to specification to build does not.
Skipping a link in that chain produces rework, not speed. It feels faster because something is happening sooner, and it is slower because the thing happening is wrong. The gates exist to make wrongness cheap.
What you can safely overlap is everything downstream of a settled decision. Content can be written while modules are built. Several reviewers can work at once. A pipeline where each item flows through all stages independently beats a barrier where everything waits for the slowest item in each stage.
Give roles hard boundaries, in writing
Agents drift toward doing more. A role that owns direction will start specifying implementation. A role that owns approval will start rewriting the thing it was asked to approve.
So the boundaries are explicit and phrased as prohibitions. The product role does not design and does not architect; an approved brief goes to the design role, never as a finished solution. The approval role rejects with a named objection and what would make it approvable, and never rewrites the proposal itself. The release role never publishes without a human saying so.
The most important boundary is the one at the top. Ours says, in the file: this role is not the user. Publishing, pricing, going live and scope are always a human call. Without that line, a sufficiently confident team will decide it has permission.
Verification is a role, and it reports rather than fixes
Agents report success. They report it when tests fail, when a page renders blank, and when the thing they were asked to check was never run. This is the failure mode that costs the most trust, and no amount of instruction inside the building agent fixes it.
What works is a separate role whose only output is findings, run against the real artefact — the live URL, the real browser, the actual file — and which is explicitly not allowed to fix anything. Report only, then hand back to whoever owns that file.
On large builds we run it as a loop: reviewer audits, developer fixes, repeat until clean. The separation is what makes it work. A reviewer that can fix things starts fixing instead of finding.
None of this makes the output correct
This is the part most writing on the subject leaves out, so it is worth being blunt about: structure reduces certain classes of error. It does not make a team of agents reliable, and a bigger team is not a more accurate one.
Agents state things with the same confidence whether they are right or not. They infer numbers that were never in the source. They report a task complete when it silently failed. They agree with a plan because agreeing is the shape of the expected response. Adding roles does not remove any of that — every new agent is another source of the same failure, and a large team can produce a very consistent, very well-organised wrong answer.
What the structure buys you is narrower: independent passes over the same work, by agents that have not seen each other's reasoning, are more likely to catch a specific error than one agent checking itself. That is a real gain and it is not the same as correctness.
Concrete examples from our own runs, all of which shipped past the structure and were caught by a human reading the output:
- A cost model built on an invented figure — the hours per unit of work were assumed, not measured, and every conclusion downstream inherited the error.
- A search click-through rate described as a conversion rate. Both are percentages, they measure different things, and the recommendation built on it was wrong.
- A report that four reviews were complete when three had returned and one had failed silently.
None of those were caught by having more roles. They were caught because a person read the output and asked where a number came from.
So: keep a human in the loop for anything that leaves the building or costs money. Ask agents to cite the source of every number and treat an uncited one as unverified. Make "I could not verify this" an acceptable answer, because if it is not, you will get a confident invention instead. And separate the agent that produces work from the agent that checks it, knowing that both can still be wrong together.
Structure makes a team of agents useful. It does not make them trustworthy, and designing as though it does is how you ship a confident mistake at scale.
What we got wrong
Three things, in case they save you the same passes.
We added roles that owned nothing. The first charter had a leadership layer because org charts have one. Half of it had no decision attached and was skipped every time. What survived is the version where each senior role exists for a standing question that spans projects, and is skipped entirely on a named task.
We let the charter go stale. The file described a process nobody followed for about a month, which is worse than having no file, because agents read it and follow the wrong thing. Somebody has to own keeping it true, and that ownership has to be written down like everything else.
We asked agents to verify their own work. Obvious in hindsight. It took a few confident, wrong completion reports to make it a structural rule rather than a preference.
Start with four
You do not need two dozen roles. Ours grew to that because we ship several kinds of product, and most days we instantiate three or four of them.
If you are starting, four covers most of it: someone who decides what gets built, someone who decides how it gets built, someone who builds, and someone who checks — where the checker cannot fix and the builder cannot approve. Add roles when you can name the decision that is currently being made badly.
Write it in a file. Give each role a decision, a boundary, and a list of what it must have read. Then let the work tell you what is missing.
A boilerplate to start from
We have written up the structure as a blank charter you can start from: the roles with their owns / decides / does-not triplets, the staffing table, the escalation paths, and the rules above. The decisions are left empty, because they depend on what you build — the point is the shape, not our version of it.
It is a markdown file. Drop it in your repository, delete what does not apply, and let the work tell you what is missing.
Leave your email below and we will send it over.