[Dev Workflow] The Two Axes That Let a Fleet of AIs Collaborate Without Re-Explaining

Plain-Language Version: The Two Things Your AI Must Remember

When you work with an AI assistant across many sessions, it has to remember two very different kinds of thing. One is durable knowledge — facts that stay true, like "this server is set up this way" or "I already tried that and it failed." The other is live state — where it is in the task right now: which step it just finished, what's still running, what to do next.

These need to live in different places, because they behave differently. You look up knowledge when you need it. You have to write live state down constantly, because the moment a session ends it's gone — and no amount of "better memory" brings it back.

This is the capstone of this two-axis arc, so I'm stepping back: it turns out all the pieces I built are two halves of a single system, run by the same handful of rules. The payoff is that different AIs — and different tools — can pick up each other's half-finished work without me explaining anything twice. The nerdier "why it all holds together" part is at the end and clearly marked.

---

Preface

At 3am a training run finished, and a fresh Codex session picked up where Claude Code had left off — read what was already known, read what was still in flight, ran the next command, and closed the task. I was asleep. None of that works if the two AIs only share a chat log.

This is the last post in an arc that's been building one thing from two directions. Part 12 and Part 13 built the knowledge half — how a pile of notes becomes something an agent can search, connect, and reuse. Part 9 and Part 10 built the state half — how a task in flight survives a dead session and moves between CLIs. This post is where they turn out to be the same system. I'll lay out that shape first, then — at the end, skippable — the one pattern I only noticed once every layer was built.

Two half-lives of information: what I know vs. what I'm doing

The whole system rests on one distinction: information has two half-lives, and you store each kind where its half-life wants to live.

Durable knowledge stays true across tasks — the shape of a codebase, a deploy recipe, a rule I've settled on, an approach I tested and rejected. It's long-lived, so it belongs in a memory you look up: plain notes, made findable by search, connected by a graph, and topped with a distilled layer of settled conclusions. That's the knowledge axis, and it's what Parts 12 and 13 built.

Live state is the opposite: it's the perishable specifics of one task in flight — which of five steps are done, which background command is running, which two dead ends I already ruled out, what to run next. It's true for an hour and then it's garbage. It belongs in a file you write to constantly: a handoff file, updated at every state transition. That's the state axis, from Parts 9 and 10.

The reason to keep them apart is that neither one covers for the other. A perfect knowledge base doesn't save a task when the session dies — the half-finished work was never knowledge, it was state (that's the whole thesis of Part 9). And a perfect handoff file doesn't stop the tenth agent from asking me to re-explain who I am and what I've ruled out — that's not state, it's knowledge. Neglect either axis and the other failure keeps happening.

Where the axes cross: a fleet that hands off without re-explaining or losing work

The two axes exist to meet at one moment: when work passes from one agent to another. That handoff happens constantly in my setup — a quota runs out and a fresh session takes over, Claude Code hands a task to Codex, a self-hosted model picks up an overnight job. Every one of those is a stranger walking into a task mid-stream.

For that stranger to continue, it needs both axes at once. It reads the live state — the handoff file — so it doesn't lose the half-finished work: what's done, what's running, what's next. And it reads the knowledge — the distilled memory — so it doesn't make me re-explain the standing context: who I am, the constraints, the approaches already ruled out. Drop either and the handoff fails a different way. State alone, and the new agent knows exactly where the task is but re-derives every decision from scratch. Knowledge alone, and it knows all my preferences but has no idea what the last session actually did.

The 3am handoff worked because both files were sitting there, current, in a directory both CLIs can read. That's the entire trick to "multi-agent collaboration": there is no live coordination between the agents at all. They never talk to each other. They take turns reading and writing the same files.

One philosophy, applied twice

Here's the part that makes it one system instead of two: the knowledge axis and the state axis are governed by the exact same five rules. I didn't plan that — I noticed it after the fact, which is usually the sign that a design is actually coherent rather than just consistent-on-paper.

• Files are the source of truth. Knowledge is markdown notes; live state is handoff and ticket files. Not a database, not the chat history — plain files, because a file is the only thing that outlives the process that wrote it.
• Every index is a rebuildable cache. On the knowledge side, the search index and the graph rebuild from the notes. On the state side, the session-start summary of "what's in flight" is just a view rebuilt from the handoff files. Delete any of them and regenerate; nothing is lost.
• Drift is tolerated; I'm the only gate. Two machines can hold slightly different knowledge, and I don't reconcile it. owner on a handoff is a routing hint, not a lock. Promotion to canonical, and takeover of someone else's task, are both my call — no agent gates another.
• Nothing is taken at face value — verify at the point of use. A note is re-verified against current state before it's believed; the next owner re-runs the last completed step before building on it; a dispatched report is re-checked against the actual result. Staleness is caught at read time, never assumed away at write time.
• Externalize whatever has to outlive the process. Both axes are the same move — take something that would die inside a session (a hard-won conclusion, a task's live state) and write it to a file — applied to two different half-lives.

What the whole system buys you

Put both axes under one philosophy and you get four properties that no single piece delivered on its own:

• A heterogeneous fleet is cheap to grow. Claude Code, Codex, a self-hosted sib — adding one costs nothing but pointing it at the same files. It reads the knowledge and the state like everyone else; there's no per-agent onboarding.
• No single failure loses the work. A blown context window, a spent quota, a crashed CLI — the work is in files, so another agent (or the same one, cold) resumes it. Nothing lives only in a session anymore.
• You rarely have to repeat yourself. The knowledge axis kills "explain who you are again"; the state axis kills "remind me where we were." Between them, a handoff is a read, not a conversation.
• Nothing drifts silently. Because every claim is verified at the point of use, a stale note or a wrong "done" surfaces when someone relies on it — not months later. The system tells on itself.

That's the design. If you just want to build it, the checklist at the end is the whole thing. If you want the one observation that ties the whole arc together, read on.

The rule every layer rediscovered on its own

This is the retrospective bit — the single pattern I noticed only after all six layers existed. It's not needed to build the system; skip to the takeaways if you just want the shape.

Every layer of this arc, built weeks apart for unrelated reasons, independently converged on the same rule: never trust a system's description of itself — verify at the point of use. I kept re-learning it in a new disguise:

• On the knowledge axis: a "dead" mirror folder that was still being written to at 2:30am (Part 11) — its self-description was stale, and only checking its actual mtime caught it. A canonical note that can exist and still get ignored (Part 13) — present isn't the same as consulted.
• On the state axis: a dispatched report that says "done" but isn't (Part 10) — a report is a claim, not a result. And the protocol's own rule that flagged a live 19-hour training run as "abandoned, take it" (Part 9) — a self-authored rule, executed faithfully, and wrong.

Four different layers, one failure mode: something described itself, the description had quietly stopped matching reality, and the only defense was to check against the real thing at the moment you relied on it. Once I saw it in four places I stopped treating it as four bugs and started treating it as the system's central law.

And that law is exactly what makes a heterogeneous fleet safe to run. I'm not trusting Claude Code to be right, or Codex, or a self-hosted model — models I swapped and upgraded all through this arc. I take none of them at their word. Every handoff re-verifies the last step; every report gets re-run; every note gets re-checked. The producer never signs off on its own high-stakes work — a rule I first ran into as a governance point in Part 11, and which turns out to be the same read-time verification, one more time. The models got better every month I worked on this. The thing that let them collaborate wasn't a better model. It was refusing to believe any of them without a receipt.

Takeaways

Where the time went. Not building the two axes — they were built one post at a time over weeks. The insight was free and came last: noticing that the knowledge half and the state half were running the same five rules, and that "verify at the point of use" wasn't a handoff detail but the law holding the whole thing up.

Reusable diagnostics. When a handoff fails, ask which axis was empty — did the new agent lose the work (state), or re-derive the decisions (knowledge)? They have different fixes. When you're deciding where something lives, ask its half-life: durable → the memory you look up, perishable → the file you write constantly. And when any agent, report, or rule tells you something, treat it as a claim to verify at the point you use it, never a fact to file.

The general principle. A multi-AI fleet doesn't collaborate through live coordination — it collaborates by taking turns reading and writing the same files, under one philosophy: files are the truth, indexes are rebuildable, drift is tolerated, the human is the only gate, and nothing is taken at face value. That last rule is what lets you point a fleet of models you don't fully trust at the same work and get reliable results anyway.

The checklist: running a multi-AI fleet on files

1. Split by half-life. Durable knowledge goes in a memory you look up (search + graph + a distilled layer). Perishable task state goes in a handoff file you write on every transition. Don't store one in the other's home.
2. Make files the source of truth. Not the chat history (it dies with the session), not a database (it becomes a system you maintain). Every index or summary over the files is a rebuildable cache.
3. Let agents take turns, not talk. Collaboration is one directory both CLIs read and write, not live coordination. A handoff is a read of two files — the state and the knowledge — not a conversation.
4. Keep yourself the only gate. Tolerate drift; make owner a routing hint; let promotion and takeover be human calls. Don't build an agent that gates another agent.
5. Verify at the point of use. Re-run the last "done" before building on it, re-check a report against the real result, re-verify a note against current state. This one rule is what makes an untrusted, heterogeneous fleet safe.

That's the arc: six posts that turned a pile of markdown and a couple of CLIs into a system where different AIs hand off work without re-explaining it or losing it — not by trusting the models, but by never having to.