16,000 Words and Nobody Finished It, So He Just Posted Eight Architecture Diagrams

An author once wrote a 16,000-word tutorial on building a multi-agent team, covering everything from concepts and architecture to a nine-step implementation, with a general template included in the main text. Not many people read it, and people still came asking basic questions. So he tried a different approach: he pulled the diagrams out of the article and posted them separately.

Diagrams are easier to finish than text; there's no arguing with that.

Taken together, the eight diagrams form an architecture that is actually running. The core division of labor can be summed up in one sentence: the Bot inside Grok Bot stays online permanently and has long-term memory, and handles orchestration; Codex on the Mac starts per task and exits when done, and handles execution; GitHub Issues serve as tickets, recording tasks and progress.

Structurally, every team looks the same: the Team Lead breaks down tasks and assigns work, the Worker produces output, the Reviewer validates it, and the Publisher releases it externally. All teams are coordinated by a Chief of Staff, and Bots hand off to one another via Handoff. When someone asked in the comments about the handoff method, the author added a clarification about scope: teams do not communicate with one another; only within a team do they exchange messages.

The Reviewer role was singled out for discussion. One reader said that when testing a system, what they fear most is testing it themselves. The author's corresponding approach is to open a separate read-only Codex Session for validation, without carrying over the execution conversation, looking only at the output and acceptance criteria.

The three standard teams are for articles, products, and video. The article team has six Bots; drafts must pass two checks—the Editor reviews content and expression, and the Researcher verifies facts and data—and neither checker participated in writing the draft. The product team has five Bots; QA and PM each handle one validation pass, one checking whether there are problems with the implementation, and the other checking whether the thing meets requirements. The video team has six Bots; editing and visual work are split by deliverable, so they can proceed in parallel, and things that need repeated polishing, like covers, can also be iterated separately.

The value of the diagrams is here: you don't need to design the division of labor from scratch yourself. The author's suggestion is to send the diagrams to Claude Code or Codex, let them understand it, and then have them help you build it. You may not need to type every command yourself, but at least you need to know what this system is doing, so that when something goes wrong you know which part to check.

There are also parts not captured in the diagrams. The author's choices were: one Ticket corresponds to one Session and one working directory; concurrency on the Mac is limited to two Codex instances; scheduled tasks are kept to only three types, because every wake-up costs quota. He also described the failure surface very plainly: Grok Bot is still in public beta, and its interface and features change quickly; Memory may misremember or expire; Prompt Injection still has no complete solution; system constraints can reduce risk but cannot eliminate it.

These details are dry to read, but they are exactly why the arrows in the diagrams can actually run. A reader asked a more practical question: when upstream delivers half a day late, should downstream wait, switch plans, or just call someone? The diagrams cannot answer this question, and the article has no standard answer either.

If you want to get started, the starting point is smaller than you might imagine: one Chief of Staff, plus one Team Lead and one or two Workers, and let one Ticket go from requirement to acceptance. Once that runs smoothly, add a second team.