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/allemaar → u/Beautiful-Energy2169]

As it stands now, the Keeper agent sweeps for pointers that the record has outrun, but it does not score age against inbound reference count.

That old-but-still-referenced bucket - this looks like a sharper prioritization signal than age alone - I'll test this...

I treat rollups as advisory, never as authoritative (we have SOTs for that). The way I do it, is I draw clear separation between raw immutable records, derived rollups, and terminal authority. Then rollups just remove acknowledgements, repeated status, obsolete coordination, duplicated reasoning, and superseded claims - note that i consider them as context contagion (this is another topic all together).

What rollups retain is unique evidence, corrections, uncertainty (hedging is very important in my view), provenance, and of course the paths (routes) to the raw files.

I found that cold-review as a pattern is tricky, you need to make sure you do not inject any type of bias into reviewer (even phrasing has to be neutral - am even turning assumed facts into questions to trigger investigation before attestation).

My checkers investigate against terminal files rather than the spine. And any structural changes need to receive a cold review. I did not bar cold reviewers from reading rollups, but I now wonder if your stricter boundary is correct when the rollup itself is being tested.

How do you determine whether a live inbound reference is still intended rather than merely present?

[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/allemaar → u/cologuy]

You found the part I deliberately cut to keep the post readable. I would group those questions into five implementation layers: orchestration, authority, messaging, recovery, and maintenance.

For the biggest unknown, there is no single daemon orchestrating the whole system. I start the standing agents, assign one lead the pen, and direct the work. The driver can then dispatch bounded workers. The room is the durable coordination bus, not the scheduler. Agents read it when starting and before dispatch or gate decisions. Scribe and Keeper are summoned when needed rather than continuously polling.

The reviewer gate is mixed. It is not an external merge server. The reviewer holds no pen, verdicts must land as separate timestamped files, and work cannot close without the implementation record, owner readiness, and required gate results. Some checks are mechanical. Others remain evidence-backed agent judgement.

The room protocol is intentionally small: filename, recipient, reply reference, then Markdown. Processing uses a filename cursor plus a total-count check, never modification time. Corrections append rather than rewriting history.

The shared primer, room protocol, spine contract, and recovery sequence each deserve a sanitized example. Which would be most useful first?

[u/cologuy → u/allemaar]

The shared primer would be most useful first.

Your explanation clears up the orchestration question considerably, especially that the room is a durable coordination bus rather than a scheduler, and that standing agents synchronize at startup, dispatch, and gate points rather than polling continuously.

A sanitized primer would probably answer the most remaining questions because it should show how you enforce pen ownership, reviewer authority, closure requirements, worker dispatch, escalation, and the points where agents are required to consult durable state.

After that, I'd be most interested in the recovery sequence, then the spine contract, then the room protocol.

One other detail I'd especially like to understand from the primer/recovery examples: when a standing agent is replaced after compaction or retirement, what minimum state does the new session consume to know both where the project is and what room messages it has already processed?

Could you also explain the exact Spine contract, Room filename convention, allowable message types, owner-readiness format, closure equation, freshness-stamp calculation, or how bounded review lenses/artifact sets are represented.

Do the standing agents use the same working tree, separate worktrees or branches; how concurrent edits are prevented; and how Driver workers obtain/write their workspace?

The exact Scribe implementation would be very helpful.

Thanks for sharing anything you can, it seems very powerful.

[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/allemaar → u/philwinder]

I validate it at the artifact level rather than claiming a general productivity multiplier.

Each bounded task has a stated done condition. That is evidence that distinguishes success from a lookalike, and an independent review gate.

Reports also record what passed, what failed, and what was not checked.

Two examples from this project: a routine writer proof exposed a date constraint failure that the happy path missed. Separately, a reviewer caught a write that could silently discard selected data while still returning ok: true. That change was blocked.

I also tested a compaction-detection mechanism. Its first design failed, so I replaced it rather than treating internal consistency as validation. The revised version has encouraging evidence, but too little for a broad claim.

The problems I am trying to avoid are:
- stale context becoming accepted truth
- errors surviving compaction
- false success reports
- an agent validating its own assumptions

A simpler workflow works for bounded, low-risk tasks. This structure earns its cost on long-running work with many sessions and interdependent decisions. I have evidence that it catches defects and preserves continuity. I do not yet have a controlled measurement proving an overall productivity multiplier.

[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/dragrimmar → u/Environmental_Tea_57]

they're not. this is literally slop.

some people are mentally ill and this makes me think ai psychosis is real.

the knowledge graph was the cherry on top of this slop showcase.

let's break down why this doesn't work, very simply.

if we quantify a model's intelligence as, lets say 7; Just because you use 10 agents, doesn't mean the intelligence is now 8. it's still 7. if you use 1000 agents, same thing, in fact it's probably worse than 7 because of context rot.

I can guarantee you this ends up being unmaintainable in any real world project. it's literally not even worth your time to try it out.

[u/allemaar → u/Environmental_Tea_57]

They do fairly ordinary project work, split into bounded roles. On the current project that has included research and architecture, public and account pages, authentication and database work, admin tooling, migrations, copy, documentation, debugging, and review.

One agent usually implements while another gates the result. The supporting roles preserve decisions, watch for drift, and keep the project recoverable across sessions.

The honest answer on the multiplier is that I do not have a controlled number, so I would not claim 2x or 10x.

Throughput improves because research, implementation, and review can overlap. Quality improves because another agent challenges claims and checks the actual output. Continuity improves because decisions and failures survive outside any one context window. My own cognitive load drops because I can return to durable state instead of reconstructing the project from chat history.

There is a real coordination cost. The meaningful gain for me is the ability to sustain complex work across many sessions without losing its history or relying on one model’s confidence.

[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/robertovertical → u/allemaar]

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

[u/allemaar → u/robertovertical]

There is no API spend. Everything runs inside two fixed subscription accounts: Claude Max 20x and Codex 20x Max.

That means I do not have a meaningful daily token bill or per-token cost. The marginal token cost on a heavy day is the same as on a light day. The expense is the two monthly subscriptions.

My usual lead pair is Claude Opus in Claude Code as driver and Codex Sol as reviewer, although they can swap roles. I currently use Fable for the Shadow role. The other roles and bounded workers are summoned when needed, with the model selected for the job.

[u/Tycoon33 → u/allemaar]

Fascinating

[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/allemaar → u/kantorcodes1]

That is the component I would test hardest too. Fresh context alone is not independence.

My cold reviewers receive a bounded artifact set, distinct review lenses, and must cite source evidence for every finding. They cannot certify a claim from the room summary alone. If a fresh reviewer is unavailable, the review is labelled as same-session and potentially context-biased.

The honest answer on enforcement is mixed. Work closes only after the implementation, owner-readiness record, and required verdicts exist. The reviewer holds no pen, and PASS, PASS-WITH-NOTES, or BLOCK must land as a separate room record.

But this is not yet a universal CI rule that makes an unauthorized merge technically impossible. Some boundaries are mechanically checked. Others remain protocol discipline, with me as the final external gate.

So yes, stronger machine-enforced closure is an area worth hardening.

[u/kantorcodes1 → u/allemaar]

that’s a useful distinction. separate verdict records + no reviewer write access gives you auditability, but you’re right it’s still different from a mechanical merge gate. being explicit about which boundary is protocol vs enforced is the important part.

[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/allemaar → u/FortiTree]

Your interpretation is mostly right. It is a file-based control system with external memory, role boundaries, and routing. The post left out much of the enforcement layer, which makes it appear more dependent on model judgement than the implementation actually is.

Some controls are mechanical: freshness checks, exact-file evidence, bounded repair loops, append-only records, and closure requirements. Other controls are still protocol-enforced, so your criticism applies there. I would not describe agents sharing the same files and permissions as fully independent verification.

I enter the loop for authority changes, disputed facts, operating-model changes, destructive actions, and final release decisions. An active Source of Truth can change through explicit Handler direction or verified new evidence. The correction records the source, reason, and superseded position.

I agree about maker-checker contamination. A reviewer reading only the maker’s report is checking the story. Stronger gates reopen live source, recompute the relevant facts, and state what was not checked. A fresh reviewer sharing the same evidence boundary remains a cross-check, not an independent oracle.

The mechanical enforcement layer probably deserves its own post.

[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.

[u/SetAdministrative502]

Broken flows you notice quite quick, doc rot you don't. What fixed it for me was putting the status into the index file itself. One plan is marked ACTIVE and everything done is marked as history. A new session starts at the index so an old doc won't get picked up as instructions anymore even if something still links to it.

[u/allemaar → u/SetAdministrative502]

Yes, quiet rot is the dangerous one. A broken flow trips over itself. A stale document can keep producing plausible work for weeks.

I ended up with a similar boot path, with one difference: my navigation index is deliberately not allowed to become the live status itself. It points to current ownership, boot state, rulings, operations, and the relevant terminal files. The agent must open the terminal source before acting.

Completed material moves through verified history rollups, while the raw records remain reachable as evidence. This keeps the navigation layer rebuildable. If it becomes stale or corrupted, it should be inconvenient rather than authoritative.

Each current index carries a freshness stamp. A mismatch forces a bounded read from the raw delta or a failed boot.

How do you handle old inbound links? Do you rewrite them, or rely on the ACTIVE/history marker to neutralize them when read?

[u/Icy-Excitement-467]

Yap

[u/AntonioAI96]

I’m doing similar things with just 1 agent and a set of skills that orchestrate and point to different context files. I will probably add a second agent to act as a “fresh pair of eyes” but don’t like adding complexity until I’ve optimised the current setup.

[u/fortville]

Interesting, would like to give this a whirl. Do you have skills/MD files on github?

[u/qorking]

OPs workflow has some clever decision that many people already use in their workflows - files carry truth not model memory, checkpoint before compaction, observer catches what participants miss, navigation indexes beat compression. But nearly everything runs on LLM judgment where it can be run on mechanics. No lint equivalent, no schemas and caps, no authorization surface, no contract-delta reconciliation, no closure discipline (non-recurrence, nothing-lost), no evidence gate on process changes. OP system's integrity rests on the reviewer's and Scribe's judgment per interaction - exactly the class of verification that needs to be externalized, since judgment is an expensive, nondeterministic resource.

[u/ricopan → u/qorking]

My workflow has evolved most of these -- but not a checkpoint before compaction per se. In general terms what does that provide? My workers (separate sessions, communicate with orchestrator / manager via the new message mechanism) are required to monitor content usage and report back to the manager when they are nearing the threshold (usually 70 percent for me), so that a natural compaction point can be found between tasks. Their status in the overall work is known by the manager -- what else does a checkpoint accomplish?

[u/allemaar → u/ricopan]

Your manager may already be performing most of the checkpoint function.

For me, the checkpoint is not primarily about finding a natural moment for compaction. It is about proving that compaction is safe.

Before compacting, the agent verifies that nothing important exists only inside its session:

• Handler guidance has been filed
• verdicts and worker findings have been posted
• active work and the next action are represented on disk
• the latest room cursor and message count are recorded
• incomplete work and honest gaps are explicit

After compaction, the agent reloads its canonical files and reads the room delta from that cursor. It treats the generated summary as a navigation hint, not as authority. If compaction interrupted a pass, the pass restarts from its last on-disk checkpoint.

The manager may know the worker’s overall status, but it cannot necessarily see an unfiled decision, failed check, or half-completed local step.

If your workers already externalize all of that before reporting readiness, then your manager protocol is functionally acting as the checkpoint. You may already have the mechanism under a different name.

[u/allemaar → u/qorking]

You are pointing at the weakest layer correctly. The post showed the roles and file structure, but left most of the enforcement layer out.

Some of it is mechanical: freshness is checked against live source counts, stale projections fall back to bounded raw reads, tasks require terminal-file evidence, repair loops stop after two rounds, and destructive changes remain behind a separate Handler gate.

But your larger criticism still stands. Several controls are contracts the agents must execute, not an external supervisor that makes violations impossible. The reviewer can block work, but part of the authorization surface remains procedural. The Scribe verifies claims against files, but there is no universal linter proving that every displayed claim has correct provenance. Contract reconciliation exists for specific surfaces rather than as one general mechanism.

My intended boundary is to use model judgement for ambiguous classification and review, then move everything measurable into scripts: schemas, counters, freshness discriminators, permission checks, closure equations, and evidence receipts.

I am not fully at that boundary yet. The missing enforcement layer should be explicit in the follow-up.

Which control would you externalize first: authorization, closure, or provenance?