The problem
Building solo is manageable. Bigger projects are not. When I started coordinating AI agents for more complex work, I hit the same wall every time: without clear decision rights, scope debates never ended. One agent would start building while another assumed we were still in design. No escalation path. No clear lanes. Multi-agent systems need rules, not just good intentions.
The approach
I designed the operating model before I grew the team. A written Constitution sets the authority order (my intent, then the Constitution, then each role’s own file, then its skills), and no agent may amend it. Fifteen roles each own a domain, from product and design through backend, security, QA, accessibility, performance, release, and documentation; a project manager routes decisions to the right lane, and an orchestrator runs the cycles.
Inside the build
A closer look.
Fifteen roles, one governed main branch.
The rules that matter most are the ones that remove discretion. Every role works on its own branch, never on main, and merging is mine. Database migrations are files with a rollback, never applied changes. No agent sends anything outside the repository, handles a credential, or acts on a privacy-sensitive change without it reaching me first. Exactly one role may message me; the other fourteen write reports I read on my own schedule. A UI change passes a seven-layer design-compile gate before it counts as done. Work that runs unattended is held to a stricter mode still: at most one reversible change per cycle, no external sends, audit-only by default on the products, and one sentinel file that halts all of it.
There is one exception, and it is deliberately narrow. A single role holds a standing grant to merge and push one project, the Prompt Library, and only when a mechanical gate holds: the full check chain, proof of the built output, a recorded rollback, and nothing on the always-escalate list. The grant is reviewed quarterly and can be revoked; everything else stays a human merge.
What shipped
A working system rather than a diagram: the Constitution and its runtime overlay, fifteen role files, an orchestrator, a recovery agent that resumes from the last checkpoint and, after three failed attempts, escalates instead of looping, and a QA report trail in every project. Every project on this site was built through it, including this portfolio. The Constitution is a working document, summarized publicly but not published in full, and it changes when the system finds a new failure mode.
Where it stands
In active use, on my projects only
My role
Mine. The operating model itself: who decides what, in what order, and what nobody may decide alone. I write the Constitution and the role specifications, write the briefs and acceptance gates a cycle is judged against, review the escalations, resolve conflicts between roles, and hold release and merge authority. The flexible version, letting each agent judge when to escalate, is the one I rejected every time, because judgement is the thing I cannot verify at scale.
What it does without me. Before starting, a role scans for another agent’s open branch or a fix already shipped, and writes a conflict report instead of duplicating the work. It caught a session that reported pushing a commit to a main that was still three commits behind: the claim was confident and wrong, and reconciliation, not trust, is what found it.
What I check. The escalations, and the reports of work not done. A system that only ever tells me it succeeded is one I have no way to audit.
The limit
The honest limit: these fences are prompt-level, not sandbox-level, and some of the overhead does not pay for itself.
Reflection
The biggest unlock wasn’t any individual role: it was realizing that the rules are what make speed possible.
I’d build the governance layer first next time, before writing a single line of application code.
