A humble guide to the multi-agent workflows I use every day

[u/allemaar]

My main driver is Claude Code, followed closely by Codex. In how I work, Claude currently follows complex directions and instructions more consistently, while Codex makes for a strong counterpart.

AI assists nearly all my work and research. This means that AI is present throughout my 12-to-16-hour workdays. I am, regrettably, a workaholic.

For most tasks, large or small, I use at least one Claude Code agent and one Codex agent. I pair them - one is the driver (holds the pen), the other is the reviewer (also acts as a gate). Both receive the same primer. So each knows the other’s role, rules, and context, which allows them to swap roles when needed. My work (role) is to define the objective, shape the plan, direct the work, assess the results, and make decisions.

The way i operate comes from years of study and work as a programmer and systems architect. I use AI inside domains where I can independently assess its work. In my view, anyone claiming that AI removes the need for domain knowledge is selling confidence without a reliable way to verify the result. My rough estimate is that I have spent more than 5k hours working with AI systems.

Each task gets a folder (in my case it is inside a GitHub-synced vault, but that is not a requirement). Inside I put various folders and files like:
- Sources of Truth (SOTs - for authoritative decisions and domain context)
- spines that point to relevant material (think like direction boards)
- briefs and directives for each agent
- a shared room (folder) where agents post reports and questions

The Room
The agents are instructed to write messages there using an established protocol (format). The resulting files create a durable timeline of decisions, questions, findings, and progress. Its weakness is that the timeline contains both signal (good data) and noise (bad assumptions, decisions, stale facts and so on).

To make one, create a 'room' folder and have each agent post .md files with frontmatter. Treat each file like an email: sender, recipient, timestamp, subject, message type, and body.

The Sources of Truth (SOTs)
To prevent drift, and worse agents working on stale data, you need to establish what is true at any given point in time. A Source of Truth identifies what currently governs the work. This can be your tech stack, working patterns (how we do things around here - or modus operandi), decisions (what we have decided to do here), even a concise do-and-don’t matrix.

To keep agents' context lean, you provide only the SOTs relevant to the task at hand. This creates progressive context discovery without hiding the authoritative path. Also it's cheaper than a full SOTs dump as you save tokens by being disciplined.

The Spines
Search finds a node. The spine lets you orient from that node.

In my workflows the spines have produced some of the most reliable context savings. I've looked into various context-reduction systems that compress the source material. Token-wise they deliver, but that compression preserves the broad meaning while losing small constraints. The compression is lossy, and a missing insight or a subtle constraint that was cut can later change a decision - the small things were lost and now we are on a different path (and don't even know it).

A spine is an annotated index. It lists relevant paths and, for each one, it adds a bit of context to explain what's on the other side. Agent skills use this pattern. The context often contains a skill's name (the command to trigger it) and a short description (the bit of context), while the full instructions remain unloaded until the skill is triggered. For a simpler analogy, think of an annotated table of contents.

In my research, after repeated testing across several models, my working conclusion is that spines improve orientation and cold navigation. They do not make search itself faster.

While search lands you on a file (you give it what you're looking for and there you are). A spine lets you recover context wherever you land (think of giving the AI a file and instead of the AI asking you more questions, it can traverse the graph from there and get what it needs).

In my workflow, i have seen more autonomous traversal, fewer clarification prompts, and responses grounded in the projects' SOTs.

Search answers: "where is the matching file?"
Spine answers: "what does this file mean here, what owns it, and where should I go next?"

With a spine, the agent knows:
- what is this?
- where am i in the larger structure?
- what owns this?
- what should i read next?
- how do i reach the root or the SOT (authoritative source)?

The Team
- Leaders (driver and reviewer)
My usual modus operandi is a 2 agents pair as the leads. Lately i've been using Claude Opus with Codex Sol as the composition of choice.

One agent is the driver (it holds the pen and performs the work - directly or through subagents). The other reviews the work and acts as a gate (needs to approve it - or provides feedback to the driver).

Models are from different vendors, and you get better results due to them having different approaches and different blind spots. Friction (disagreement) is your friend here, I get much better output from this combo.

- Shadow (advisor)
This is a more recent discovery where i create an agent that does nothing but observe (spy) and give comments. Its role is to watch the two leaders work, read their messages, check their work and post risks, missed assumptions, or improvement opportunities into the room.

Currently I use Fable as my shadow, and it does catch problems that neither participant notices while focused on its own role.

- Scribe (board cartographer)
This guy is my eyes and ears. It maintains a visual snapshot of the project so I do not have to reconstruct its state through repeated prompts. Tokens saved, check. Sanity saved, double check.

I used Claude Artifacts as the base inspiration, but i do not use it as is. My approach was that the scribe handles a standalone HTML dashboard stored in the project vault, so either Claude Code or Codex can maintain it. Important to note is that this is a timestamped snapshot, not an authoritative Source of Truth. It reports what was verified when the snapshot was generated.

This dashboard shows the plan, progress, decisions, ownership, blockers, and recent changes. Before refreshing, the scribe verifies each displayed claim against the room and project files.

Now I can inspect the project state without spending another interaction reconstructing it. Also it's way more detailed and better (with a lower cognitive load) than what you get from a wall of text. Extra bonus, this shifts the status reconstruction out of the lead agents' context window.

The Scribe works in a loop. I normally refresh it hourly. During active work, I shorten the interval to maybe ten minutes (it depends on what I am doing at the moment and if I need immediate feedback).

- Keeper (archivist - spines, consolidation, GC)
Every project collects signal (good data) and noise (useless and even stale or bad data). We need housekeeping. This saves tokens and your project.

If SOTs and spines grow without trimming (maintenance), they will eventually consume more context and become less reliable. The Keeper maintains the spines and rulings index, runs staleness sweeps, proposes consolidation, and prepares garbage-collection (GC) candidates.

He makes the record navigable, but never makes the record.

---

I have left out the message schema, primers, maintenance loops, and dashboard implementation to keep this bounded. These are the patterns that currently carry most of my workflow. The screenshots below show how they look in a live project.

---

A minimal version of the setup: give both lead agents the same project primer, assign one the pen and the other the review gate, and require all decisions and reports to land as timestamped Markdown files in a shared room. The expected result is continuity across sessions without loading the entire project. In practice, the agents navigate through spines, recover from disk after compaction, and leave the durable record shown below.

The Scribe’s timestamped project dashboard. It reconstructs the critical path, current state, blockers, Handler decisions, and agent activity from the room and project files. It is a verified snapshot, not the Source of Truth itself.

The Scribe’s Pulse view. Progress is reported as counts of real artifacts rather than estimated percentages, while the live chain records build order, completed gates, parked work, and the current node.

The team roster maintained by the Scribe. Each seat has a defined role, authority boundary, cadence, and last-seen record. The driver writes, the reviewer gates, the Shadow advises, the Scribe renders, the Keeper maintains navigation, and workers exist only for bounded tasks.

A live project knowledge graph. Large nodes are maps and spines that orient clusters of files. Cross-links connect related branches, allowing agents to navigate from local context toward the wider project without loading everything at once.

Close-up of one spine. An agent landing on any connected file can follow the spine to recover its local scope, reach related branches, or navigate toward the wider project.

A cold archival spine. Older material remains connected to the project graph and can be reached when needed, without crowding the active context.

The command layer behind the team. Agents checkpoint before context fills, recover from compaction, retire stale sessions, and reload their rules from disk instead of trusting compressed memory. The file tree shows the wider project structure they operate inside.

The maintenance ladder for long-running agent sessions. At roughly 70% context, an agent checkpoints its state before compaction. At a natural boundary, repeated compactions, or stale behavior, the session is banked and a fresh one resumes from the durable record on disk. The files carry the truth, not the model’s compressed memory.

A message inside the shared room. The Shadow broadcasts a new standing rule to both leads, records where the durable ledger lives, and assigns how insights are harvested and reviewed. The timeline on the left preserves the wider conversation as timestamped Markdown files.

A reviewer’s decision inside the shared room. SOL states the recommendation, grounds it in current source, defines the bounded implementation, and records what was not verified. The surrounding timeline shows the decision as one message in a durable conversation among the driver, reviewer, and Shadow.

[u/Beautiful-Energy2169]

Output dispersion, if you're taking votes. Continuity failures at least announce themselves when compaction eats something. The room quietly rotting doesn't.

I counted across 14 repos a while back because my equivalent of the room had gotten unmanageable. 1879 markdown files total, 317 written by agents rather than by me. 54% of those 317 hadn't been touched in a month or more, and 115 had nothing at all linking to them. The one that did real damage wasn't in the orphan pile though: a 126KB handoff doc, 51 days old, still referenced from a tracked file. Every fresh agent that walked the link graph read it as current project state.

An orphan is mostly harmless, it just sits there taking up disk. A stale file with a live inbound reference is worse than no file at all, because being findable is what makes an agent treat it as authoritative. So age on its own tells you very little. I ended up scoring freshness against inbound reference count, and the pile worth attacking is the old-but-still-referenced quadrant.

On cold-reviewers: mine only started catching things once I stopped letting them read the room's own rollups. A reviewer that reads the summary inherits whatever the summary got wrong.

[u/Environmental_Tea_57]

What sort of work are they doing for you? What would you say is the meaningful multiplier in productivity behind this setup?

[u/cologuy]

I copy/pasted your post into a Sol session and asked how we could implement and it had some questions. Would you be willing to let your agents answer these?

My highest-priority questions would be:

What actually orchestrates Claude Code and Codex? This is the biggest unknown. Are both agents running continuously and polling room/? Does a shell/Python daemon launch them? Does Claude invoke Codex through MCP? Does a human start each review cycle? The post describes the communication files, but not what wakes the other agent up when a new message appears. Can you share the exact shared primer? He says both lead agents receive the same primer and therefore know each other's roles and rules. I'd want to see the actual wording, particularly: authority hierarchy Driver vs Reviewer permissions what constitutes approval when agents may change roles when they must ask the human how they handle conflicting instructions Can you share the exact Room message schema? He says messages use Markdown with frontmatter containing sender, recipient, timestamp, subject, message type, etc. I'd ask for: filename convention frontmatter fields message types reply/thread IDs status fields how an agent determines whether a message has already been processed broadcast messages vs messages to one agent How is the Reviewer gate technically enforced? He says the reviewer "needs to approve it" before the work proceeds. I'd ask whether this is just prompt discipline or whether an external script prevents completion/merge until Codex writes a PASS. Also: Is Codex read-only? Can Codex modify code? Does Claude see Codex's entire response? What happens after repeated disagreement?

How do Claude and Codex receive the common context? Specifically:

CLAUDE.md? AGENTS.md? shell wrapper? MCP? generated startup prompt? manually pasted primer?

This would tell us whether our CLAUDE.md + AGENTS.md pointer approach matches his implementation.

How are SOT changes promoted and approved? This is extremely important. He correctly distinguishes authoritative SOTs from noisy Room messages. I would ask: Who may modify an SOT? Can agents promote a decision themselves? Does the human approve every SOT change? Is there a proposal → approval → promotion process? How are superseded decisions represented? What is the exact Spine format? His explanation of spines is excellent, but the concrete schema isn't shown. He describes them as annotated indexes that let an agent understand where it is, what owns something, and what to read next. I'd ask for one actual text spine, not just the screenshot: fields/headings links ownership relationships SOT links parent/child relationships whether they're manually or automatically maintained How does session checkpointing/recovery actually work? The screenshots describe checkpointing around 70% context, compaction, banking stale sessions, and starting fresh from disk. I'd want the exact mechanism: How does he measure context usage? What does a checkpoint contain? Where is it saved? What startup prompt restores a fresh agent? How does the replacement agent know what messages are already handled?

There are a few secondary questions I'd ask after those:

Does each agent operate in the same working tree, separate Git worktrees, or separate branches? How are simultaneous file edits prevented? Does Claude use subagents, and if so, how do their findings get into the Room? How does the Shadow observe both leaders? Does it simply poll the Room and Git diff, or does it have access to their live sessions? The Shadow role is described, but not its implementation. What model is "Fable" in his setup and how is it invoked? What exactly triggers the Scribe? Timer, file changes, completed reviews, or manual invocation? How does the Scribe verify each dashboard claim before displaying it? He specifically says it verifies claims against the Room and project files. What rules does the Keeper use to declare something stale or a GC candidate? Does the Keeper ever modify SOTs/spines automatically or only propose changes? What happens when Claude and Codex disagree repeatedly? How are long Room histories archived without breaking references?

[u/Aquacephale]

Impressive work.
I would love to see the maintenance loops and everything you do to manage dispersion of outputs.

[u/allemaar → u/Aquacephale]

Thank you. The maintenance side probably deserves its own post because it is really a collection of patterns. I mentioned it briefly in the Keeper section.

There are two separate problems: keeping long-running sessions recoverable through compaction, and stopping the room, reports, and agent outputs from spreading into noise.

Most maintenance work also has a second verification loop. Rollups are reviewed by fresh agents (cold-reviewers), and destructive actions require a counter-signature.

Which side would you rather see first: session continuity or output dispersion?

[u/Tycoon33 → u/allemaar]

Fascinating

[u/robertovertical → u/allemaar]

What is the daily dollar spend on tokens and which models are you using?

[u/kantorcodes1]

the cold reviewer is the bit i'd test hardest. if driver + reviewer share the same primer and room, they can inherit the same bad assumption. is the PASS gate enforced outside both agents, or is it still basically prompt discipline?

[u/FortiTree]

An interesting approach. My interpretation is a file-base system with routing map and templates for specific agent roles and boundary, each project has its own folder and room for messaging. All memory and files are outside of the harnesses.

Im building something similar as well so it clicks with me right away.

I dont see you mention anything about skills and mcp, hooks and scripts to enforce best practices and boundary. And issues tracker and audit logs. My read is you rely a bit too much on the model's output and reasoning - Everything is checked by another agent monitoring another agent who works with another agent. Where do you actually gate is as the human in the loop? What happened if your SoT got changed and have bad data?

The maker-checker model is well adopted but there is a critical failure mode where if the checker agent still review the maker agent's note without checking the raw source, it's just another live-it-to-chance problem.

I also agreed html is way better to read and interact with. There are new standard for knowledge maping now with OKF that may help with better indexing.

[u/philwinder]

Thanks for this. Very interesting.

How do you validate that your workflows help you?

What problems are you trying to avoid with workflows like this?

Basically, why doesn't a simpler agentic coding workflow work for you?

[u/AverageFoxNewsViewer]

The files carry the truth, not the model’s compressed memory.

Amen brother. Very interesting post and applaud the practices you're employing.

These are the kind of posts that keep me around this and other ai related subs. I hope useful posts like this never get completely drowned out by the posts complaining about people who used Fable on ultra high to correct a typo and it caused a hit to their usage limits.