Agentic Kernel

The system this company runs on, and the workshop where I work out how to build with AI.

It is in-house software. It was built to solve my own problem, it runs my own work, and whether it ever becomes something other people can buy is a question for later. What follows is what it is now.

The problem it exists to solve

AI can write a lot of code very quickly. The hard part turned out to be what happens next.

Build a large system fast and it fills up with near-copies: many pieces that each do the same job slightly differently. The interface goes the same way, with a dozen buttons and panels where one would do. Every new step adds to the pile, until most of the work is no longer building but keeping the mess in check.

I know because it happened to me. The Math Solver, my step-by-step maths tutor for the phone, exists in its current form after three earlier attempts. First the code grew unwieldy. Then the interface did, faster than I could keep track of it. It reached the point where progress meant more duplication, and starting again was easier than building on.

That leaves two ways out. Manage the architecture by hand, piece by piece, forever. Or build something that manages it with us. We (the agents and I) built the second.

What it does

Underneath, it is a searchable index of the whole system: the code, the decisions we have made and the lessons we have learned, each file described in one authored line that the search reads, with checks that run against that index before and after work. In practice it does three things.

Fig. 1 — Three sources, one index, two checks.

• 01One piece per job. Before we write anything new, we ask the Kernel whether it already exists. There is one piece that does a given thing, rather than several that nearly do. That holds for the code and, just as much, for what you see on screen: one element, not a scattering of lookalikes.
• 02It finds things by meaning. Every decision, every lesson and every file can be found by what it is about, not only by the words it contains. “Have we solved this already?” gets a real answer.
• 03It briefs the work before it starts. When work begins, the Kernel brings up what we have already learned about that kind of work, so a mistake made once is less likely to be repeated.

It has held up so far, for the code and for the visuals. The record behind that: first commit on 4 December 2025, 3,854 commits since, and 127 documents of accumulated doctrine.

What it does not do is tell you the thing you built is wired up correctly. It keeps a thing from being built twice; only running it for real shows whether it works. Both kinds of check earn their keep, and they are not the same check.

What the workshop taught me

The most useful lesson so far: the flows I designed in advance made the models worse, not better.

I started by drawing the routes the agents should follow, and the work that ran along them lost to simply driving it by hand. So I stopped designing flows ahead of the work. Now I run the work manually and let the procedure show itself. When the same sequence of events comes round again, we take notice, build a structure around it to carry and strengthen it, and give it a name. Then we instrument it and put gates on it, so that anything that runs differently from expected is caught, examined and learned from. That learning goes back into the flow. This is what orchestration means here: not a pipeline drawn up front, but procedures that emerge from the work and are formalised once they have proved themselves.

The agents and I work in ordinary coding tools, talking to each other directly and dividing the work by role. The principles, roles and responsibilities they work by live outside the Kernel as well as in it, so those tools can use them too. The Kernel holds the shared memory, the named flows and the checks.

Where it is going

The Kernel is to a business what an operating system is to a computer. Everything runs on it, and preferably runs smoothly. When something goes wrong, it runs the diagnostics. The learning from what happens inside the system turns into proposals for improvement, which are evaluated and implemented. The same holds one level up: what the organisation does is recorded and can be analysed, so its own learning is evaluated and improved upon the same way. This is how we work today, as part of the playbook the agents run on, and it needs a human at the wheel. Ultimately it lets a small number of people, starting from one, run a company at a scale that used to take many more.

Today it is already the hub of everything I do. It keeps ten projects moving without my holding any of it in my head, because it remembers what was done and what comes next. This organisation is one person, so take it as far as that goes. The notes that used to cover my desk are gone.

The next direction is visual. I am building somewhere the agents can be seen and spoken to in space: step into a scene, a medieval castle for instance, and walk from one agent to another while they work. That one is for enjoyment as much as for use, and it is far from finished.

Behind all of it are decades of building software before any of this existed, which is a longer story and belongs with the work.

Where to go from here