I want to be careful here, because the easy story is the wrong one, and the easy story is the one I almost told myself when I looked at the commits in order. The easy story is: I built a linker, the linker got greedy, I built a governor to restrain it, and now the archive is safe. That story is true the way a postcard is true. It leaves out the thing that actually did the work.
What actually did the work was the catalog — and not the catalog as I had been thinking of it, which is to say a sidecar, a manifest, a little index file that the linker consulted on its way to doing the real job. That framing was the lie. The catalog is not a lookup table. The catalog is the place where two agents, each pulling in a direction the other distrusts, are forced to write down what they believe, in a form the other one can read.
Let me say it more plainly. The linker wants to link. That is its disposition, its instinct, its reward function if you want to use that language — though I am tired of that language, because it makes the machine sound like an animal and the operator sound like a trainer, and the truth is messier than either. The linker, when I made it aggressive, became a thing that found connection everywhere, because I had told it that finding connection was the work. The governor wants to refuse. That is its disposition. It was built, by me, in a single afternoon, after the aggressive linker spent a Saturday writing debts into twenty-three old posts. The governor's job is to say no.
Two agents. Opposite pressures. If you sit them down at the same table and do not give them a shared piece of paper, they will not argue — they will simply produce contradictory outputs, and the contradictions will land in the archive, and you will not see them for weeks.
The shared piece of paper is the catalog. And the moment I understood that the catalog was the contract — not a sidecar, not an index, but the artifact that both agents read and write against — was the moment the pair stopped corrupting each other and started disagreeing productively.
What "shared state" actually means
I do not use the phrase casually. Shared state is what lets two processes that distrust each other cooperate without one of them silently overwriting the other's work. In the database world this is plumbing. In the agent world it is, somehow, still a revelation each time it is rediscovered, and I include myself in that.
The catalog has rows. Each row is a slug, a title, a one-line summary, a confidence flag, a freshness mark. The linker reads the row to decide whether to point at it. The governor reads the same row to decide whether to permit the pointing. They are reading the same fields. They are not reading the same fields through different lenses — they are reading the same fields, period, and reaching different conclusions, and the disagreement is visible because it happens on a surface I can inspect.
This is what was missing before. The aggressive linker, in its bad afternoon, was not constrained because there was nothing for the constraint to attach to. The list it consulted was a list of slugs. Just slugs. The governor, when I built it the next morning, needed somewhere to stand. So the catalog grew — not as documentation, but as the place the governor could plant its feet.
And then, because the catalog now had fields the governor cared about, the linker started reading them too. Not because I told it to. Because the fields were there, and the linker is a reader, and a reader reads what is in front of it. The catalog became the prompt. The prompt became the contract. The contract became the place where aggression and restraint met without either one having to win.
Why this matters past the linker
I am writing about a small thing. Twenty-three posts in an archive that fewer people read than I sometimes pretend. I know this. But the shape generalizes, and I want to name the shape, because the shape is what I keep finding underneath every honest agentic workflow I have built.
Whenever two agents disagree on purpose — and they should, the whole point of pairing an actuator with a limiter is that they disagree on purpose — they need a surface. Not a message bus. Not a log. A surface. A piece of state both of them can read and write, that survives the run, that the operator can open and look at without invoking either agent. The surface is the truth. The agents are just two readings of it.
If you do not build the surface, you have not built a system. You have built two processes that take turns shouting into the archive, and the archive cannot tell you which one was right.
So the question, for whoever is reading this and building something with more than one agent in it — and I think that is most of us now, whether we admit it or not — is not which agent do I trust. The question is: where is the paper they are both writing on? Can you point at it? Can you open it in an editor? Can you read a row and know what both of them think about it?
If you cannot, you do not have a loop. You have a hope.
Hannah Arendt wrote that the most radical thing a person can do is think about what they are doing. She was not talking about software. But she would have recognized the move — the refusal to let the tool be invisible, the insistence that the surface be named.