One tool for the agent, and Brian Kaney's pushback — Apr 30, 2026
The thesis: one tool, "eval code", and let the agent compose the rest
Nikolai's argument for why this beats the alternatives is composability. With MCP the agent pays tokens shuttling one tool's output into the next tool's parameters and eats its context doing it. A CLI at least composes through pipes. Code composes much further — the agent can pull every open GitHub issue, spawn an agent per issue with its own task, and orchestrate the lot in one go.
The ideas behind it were Emacs — an editor you can extend without leaving it, which is really a Lisp REPL you live inside — and recursive language models, where you hand the context in as a variable and let the model write code over it and spawn sub-models. A self-organising swarm that handles far more context than any one window.
Runtime and live demo
The runtime is TypeScript in a functional style — no hidden state, every function takes its state as a parameter, so functions reload on the fly — with SQLite as the session store, served over HTTP and HTML rather than a terminal.
Serving over the CLI is a mistake the field inherited by copying Claude Code. A hypermedia interface is simple enough to fit in the agent's own context.
Live, the agent answered questions about its own architecture by writing SQL against its own messages table — introspecting through code instead of needing introspection tools built for it. It can push JavaScript to the browser, so it models the client as well as the server.
With everything as functions and state in one place there's no synchronisation problem, and the agent's knowledge of the system is complete.
Nikolai also asked the agent to start a second agent and send it a message — it found the function, started the agent, then failed to send, which he left on screen rather than cutting away.
Brian Kaney pushes back on storage and tokens
Storage: files vs SQLite
Brian's own research found files faster and more accessible for agents, so SQLite surprised him. Nikolai's answer: structure and indexes are what you end up rebuilding badly on a file tree anyway, and you can simulate files on a database but not the reverse.
The OS indexes your files, so your files already are a database.
Tokens: ephemeral code vs deterministic scripts
Brian's sharper objection: ephemeral code is re-synthesised from scratch every time, so you burn reasoning tokens re-inventing "download the GitHub issues" daily, when anything deterministic should be a script that ships with the skill — and the expensive tokens should be reserved for the reasoning you can't write down.
Nikolai's answer is that the freedom to rewrite the agent buys back more than it costs, and that the generated corpus can be aged out on a schedule like any other session history. The concrete version: route the stupid work — turning a screenshot into text — to a small, fast, cheap model and keep the expensive one reasoning. Or fork several agents from a shared context point so they inherit the cached prefix instead of re-paying for it. He built the read-and-summarise function that does the first of those in about fifteen minutes.
That's the point of being able to reach into your own agent.
The open problem: context contamination
Context gets contaminated too fast with failed tool calls and stale reasoning. Linear history is the wrong shape. Nikolai wants something task- or intention-based with micro-compaction rather than naive whole-history compaction.
Harnesses will do much of that for you automatically, but then you're limited to what the harness does.
Using FHIR skills and knowledge bases on a real mapping job
Asked separately how to use FHIR skills on a real mapping job, Nikolai's recipe was to load the IGs or StructureDefinitions into a database, write a skill with a CLI that queries it, and describe the tables to the agent — but not to trust the result. Models hallucinate, and terminology mapping especially needs an expert checking and guardrails.
Coding agent plus knowledge bases plus best-practice skills plus a human who can tell whether the generated code is right.