I spend a lot of time programming products. I spend nearly as much programming the workflow that produces them.
When a person and several AI assistants work the same branch, quality depends on how context moves between them and how handoffs are structured. Designing that is a real engineering task. I've come to think of it as meta programming: writing the rules and feedback loops of the process itself, and checking them in next to the code.
What breaks without it
Multi-agent velocity without structure produces a specific kind of mess. Duplicated work across contexts that couldn't see each other. Conflicting edits to shared files. Stale assumptions surviving into a later pass because nothing invalidated them. Merges that are hard to audit because nobody can say which change came from which decision.
I learned this from the messy merges, not from a blog post. The fix was to design the collaboration layer as deliberately as the product.
Roles, written down
The pattern that helped most was routing assistants by strength and stating the routing in a file the assistant reads on every session.
On good-vibes, Codex owned planning and the roadmap, Claude Code owned implementation and test coverage, and Copilot reviewed diffs for consistency, each with its own instruction file. On stay-ahead I pushed the same idea into a test-driven shape: agents produce a plan before code, work through TDD, and keep the documentation synchronized, with the roles defined in the repo. On this site, CLAUDE.md carries the architecture, the conventions, the test-execution rules, and a delegation protocol: state the technical approach before writing code, diagnose before fixing, size work to fit the session, execute existing plans rather than writing new ones, and run a quality gate before committing.
Those aren't aspirations. They're the failure modes I kept hitting, inverted into rules.
Context as a finite resource
I treat context the way I'd treat memory in a constrained system. Canonical constraints live in repo docs. Branch-level handoff notes stay current. Validation outcomes get attached to each meaningful change set. Names for files, prompts, tests, and artifacts follow stable conventions so an assistant can find things without being told.
The payoff shows up when I return to a branch after a few days. The docs say where I left off. I don't reverse-engineer it from the diff. And a fresh assistant session starts from the same place I do, which is the whole point.
Gates with a written pass and fail
Review happens in layers, and each layer has an explicit definition of passing: targeted implementation checks, then accessibility and contrast, then integration smoke, then the broader regression run, then a human review before anything deploys. Written criteria make escalation objective. "The canary is green, run the full batch" is a decision anyone can make. "It feels ready" isn't.
Tools I built to run the loop
At some point the workflow wanted its own software.
hopper is a visual orchestrator for coding agents. It queues tasks for Claude Code and Codex, runs them in parallel when they're in different folders and sequentially when they share one, enhances terse task descriptions with a local Ollama model before dispatch, and shows each task's terminal output in its own card. It exists because I was juggling three terminals and losing track of which one was mid-run.
Local Crew takes the orchestration idea across machines: named agent identities, persistent memory, a task queue filled by consensus, and a verification step before anything is marked complete.
orgos is the most recent and the most ambitious: an agent-first organizational operating system where agent identities, memory, files, and flow sequencing all live on disk as plain JSON and Markdown, so the whole state of the system is readable and diffable.
Each of those is the same idea at a different scale. Make the process legible. Make the state inspectable. Keep the human deciding what happens next.
Automation as coordination
Automation isn't only for speed. It's how collaborators share a verified view of the system: grouped predeploy test execution with compact reporting, generated JSON summaries of each run, media artifacts with signatures so nothing regenerates unnecessarily, a sitemap and llms.txt produced from one manifest. Those outputs are the shared state. Anyone, human or assistant, can read them and know where things stand.
Documentation is runtime config
In a multi-agent environment, a stale document is a bug. Assistants execute against it the same way they'd execute against a wrong constant. So docs update in the same pass as behavior, handoffs carry test evidence, and the decision log records why a thing is the way it is so nobody re-argues it in six months.
What I'd tell someone starting this
Constrain scope before adding capability. Separate assistant roles by function and write the roles down. Automate verification and artifact generation early, before you need them. Treat context hygiene as a product requirement. Design handoffs so a qualified stranger could continue safely.
That's what turns isolated AI productivity wins into throughput you can keep.