One handbook, every harness

We should be the easy case. We use every AI harness there is, the environment an AI agent works in: open source, closed, the expensive one, the one that was best last Tuesday. We build our own, with an AI stack under it. We run agents the way coders do, with instruction files and memory folders next to the code, and it works.

Then we try to share it. Between two developers on one project: fine. Between a developer and a coworker who doesn't code: harder. Between a person and an agent on a different harness: now we're drawing diagrams. A task we've tuned until it runs beautifully lives in exactly one environment, held together by files only one of us has. And it has a shelf life of about three months, because a better way arrives most weeks.

That's us, and we're the easy case.

Starting from zero #

Every agent run starts from nothing unless it has memory. And the memory is local: one machine, one harness, one format. Change the harness and it stays behind. Change the provider, same. A colleague leaves and their folder leaves with them.

Coding half-solved this by accident. The instruction files live next to the code, and the code is shared, versioned, and survives a change of tool. Nobody designed that for AI. It was already there.

Skills are the same idea on purpose. Claude Code has them, Codex has them: a way of working as a plain text file you can hand to someone. It's true, it's good, and it's the right direction. At the start, it's all you need.

Then you add a second harness, and a third, and the runs get long. Somewhere along the way the files stop describing how to name things and start describing how the business decides things. That's no longer a skill you hand to someone. It's a handbook you have to keep. It has to stay current, live in one place, and outlive whoever wrote it.

This isn't an AI problem #

It's onboarding done backwards. A new colleague arrives every morning with no memory of yesterday, so each of us writes them a handbook, in our own tool, in our own format, in a place only we know. That's the same knowledge maintained twelve times, by twelve people, and kept current by none of them.

And the company can't read any of it. Nobody can check what's in there, correct it, or keep it when the person or the tool goes. How the business decides things is being written down in places the business doesn't own.

What we did about it #

What a long run learns has to outlive the tool it ran on, and the tool changes every few months. So we made three decisions.

First, we took the part of our own harness that hands an agent the right pages, recipes and memory at the right moment, and turned it into a service any agent can connect to. Claude Code, Codex, our own, whichever is running that week. One handbook, every harness.

Second, you can take the whole handbook with you. It downloads as plain files in Google's Open Knowledge Format, OKF. It's yours, not ours, and it stays readable in software nobody has built yet.

Third, a handbook isn't only for agents. People have to read it, correct it and argue about what goes in. So it lives in the workspace we built for our long agent jobs, where people work with each other and with agents under one set of rules.

All three together became Honto Library, and it's now the centre of how we work. It's built on OKF, extended with native data: tables, charts and records an agent can query directly, not just read. It also records which pages the agents actually read and how the work turned out, which we use to tune our agents.

The fair objection: a shared handbook is exactly the kind of document nobody keeps up to date. That's true of every handbook that can't see who reads it. Ours records which pages the agents actually open and how the work turned out, so a stale page shows up instead of quietly misleading.

So the agents don't start from zero any more. They start from everything the last run learned. We can see which pages they read. Whether they understood them is, as with any new colleague, another matter.