A Working Protocol for Claude and Codex

Failure surface

The problem showed up in three forms at once. First, two agents were working on the same codebase with separate skill libraries and no shared memory. Second, the “learning loop” that was supposed to capture improvements was effectively fake: 89 signal records, blank event fields, no real transfer of judgment. Third, project folders kept turning into archaeology sites full of version drift, duplicate build environments, and no obvious canonical output.

Why it breaks

That combination does not scale. It works only as long as one person can remember who knows what, which file is current, what bug was fixed last week, and which lessons matter. The moment the work gets busy, or another agent joins, or another person touches the project, the whole thing collapses back into rediscovery.

The fix

The solution was deliberately low-tech. One shared skills library in `~/Desktop/~Working/skills/`. One append-only `_BUILD_LOG.md` in each project so every session starts by reading what happened and ends by writing what changed. One `_WORKSPACE.md` that defines canonical files, folder rules, and cleanup expectations. One promotion path from “Skill candidate: Yes” to a real reusable skill. That is enough to turn isolated sessions into a system.

Inline memory

The important architectural choice is that memory is inline with the work. The agent that does the work writes the record. No background hook pretending to infer what mattered. No side-channel telemetry that can fail silently. If the work happened, the evidence lives next to the work. That makes the system legible to both humans and models.

How it scales

This scales better than it looks because the protocol is agent-agnostic. It does not depend on Claude-specific features or Codex-specific memory. Any model that can read markdown and follow file conventions can participate. Add a third agent and the rules do not change: read the skills, read the local build log, respect the workspace contract, append what you changed, promote durable lessons.

Why local wins

It also scales because the memory is local before it becomes global. Project-specific facts stay in the project. Cross-project judgment gets promoted into skills only when it proves reusable. That prevents the shared system from filling up with noise. The build log is the event stream. The skills library is the compressed knowledge layer.

Next layer

If I were formalizing the next version, I would add four things. An agent registry so capabilities are explicit rather than informal. A project manifest so safe write zones, validation commands, and canonical outputs are machine-readable. A promotion queue so skill extraction has visible latency instead of relying on good intentions. Protocol health metrics so the system can detect repeated fixes, stale skills, unresolved open items, and missing log coverage before decay gets normalized.

How others learn

The most important question is how someone else learns it. Not by reading one huge manifesto. They learn it by moving through layers. First, the public build entry explains the problem and the shape of the solution. Then the longer guide and musing show the reasoning. Then the shared skills index shows the categories of reusable judgment. Then a real project folder shows `_BUILD_LOG.md` and `_WORKSPACE.md` in practice. The pattern has to be visible at every level: explanation, rule, example, repetition.

What this becomes

That is why I think of it as an operating layer rather than a prompt trick. A prompt can make one session better. A protocol can make the next session better. An ecosystem can make the next person better. The point is not “I have two AI tools.” The point is that the work compounds instead of resetting every time a new model or a new collaborator enters the room.