The Hekton Control Plane

For a while my plan for context was the plan everyone starts with: keep everything, in one place, synced. One vault, every note, every decision, every half-finished thought, mirrored so any agent or device could reach it. It felt responsible, the way a very full junk drawer feels responsible.

Then I tried to publish something, and the plan revealed what it actually was. The same synced store that made my private working memory convenient also made it one careless step from public. The question I could not answer was not “where is my context.” I knew exactly where it was. The question was “what is allowed to leave,” and I had never drawn that line anywhere a machine could see it.

The problem is not storage, it is the boundary

Agentic work produces context faster than any human can file it. Every session leaves notes, decisions, dead ends, and the occasional secret that wandered in from a config file. Storage is the easy part. Disks are cheap and Markdown is small.

The hard part is that this pile is two things at once. It is the working memory that makes the next session smart, and it is a stack of material that ranges from publishable to absolutely-not. Treat it as one undifferentiated store and you have built a pipeline that points your private reasoning at whatever audience the store is synced to. The danger is not that you lose the context. It is that you keep all of it, equally, with no seam.

A folder holds everything you put in it. A boundary decides what is allowed to leave. They are not the same thing, and only one of them keeps you safe.

I tried to fix it by being careful

My first solution was discipline. I would simply remember not to sync the sensitive bits. I would keep the private notes in a different corner and move only the safe material across, by hand, when I thought of it.

This worked exactly as well as every plan that depends on a tired human remembering a rule at the wrong hour. Sometimes I synced too much. More often I synced nothing for days because the manual step was friction and friction loses. A boundary that lives in your good intentions is not a boundary. It is a near miss you have not had yet.

What got weird: the context split into layers on its own

Once I stopped trying to manage one pile and started watching how the work actually moved, the context sorted itself into three distinct places, each with a different job.

There were the working repos, where code and raw context live and where most of the mess is allowed to exist. There was a curated mirror, a vault that holds the durable, shareable shape of a project: its docs, decisions, backlog, session logs, and architecture notes. And underneath both there was a thin layer of machine-readable metadata that declared, per project, what kind of thing this was and what it was allowed to do.

The surprise was that I had not designed three layers. The work had. The moment I let the repo be messy and asked only a curated subset to travel, the boundary stopped being a chore and became a shape.

What worked: a curated projection with one hard rule

The mechanism that holds it together is a sync that is not a copy. When a project’s durable context travels to the shared brain, it goes as a curated projection: documentation, decisions, backlog, session logs, and architecture notes. Source code, build output, lock files, and secrets do not cross. That is not a guideline I try to honour. It is the rule the sync enforces, every time, whether I am paying attention or not.

The friction problem solved itself the same way. I do not have to remember to sync. The daily brief notices when a project has done real work and drifted from its mirror, and it nudges. I run the sync, the projection updates, the nudge clears. The discipline moved out of my head and into a loop that runs whether I am sharp that morning or not.

And the per-project boundary is declared, not described. Each project carries machine-readable fields that say what it is and what it may do, including its privacy boundary and whether writing to the shared vault is even allowed. The lab that hosts this very blog, for example, is marked public, with vault writes switched off. The rule is not a paragraph in a wiki I hope someone read. It is a value a script can check before anything moves.

The reusable part: draw the seam, then automate it

If you take one thing from this, do not copy my three layers. Draw your own seam first. For your context, answer three questions: what is allowed to leave, in what shape, and what is the one thing that must never cross. Then put that answer somewhere a machine can read it, not somewhere you have to remember it.

A control plane is not a folder, a tool, or a tidy vault. It is the boundary plus the mechanism that enforces it. The folder is where things sit. The control plane is what decides whether they are allowed to move. You can build the whole thing out of Markdown, a few scripts, and one rule you refuse to make optional.

The day the boundary lives only in my memory again is the day I have lost it.