Topics discussed:

• The thesis: replace a large fixed toolset with a single "eval code" tool and let the agent compose everything else as functions. 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, but code composes much further, so 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, which he wanted because an editor you can extend without leaving it 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.
• 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, which Nikolai thinks is a mistake the field inherited by copying Claude Code's CLI when 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, and it can push JavaScript to the browser, so it models the client as well as the server; Arjun Sanyal's read was that 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 it 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 pushed on two fronts. On storage, his own research found files faster and more accessible for agents, so SQLite surprised him — Nikolai's answer is that 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; Brian's retort was that the OS indexes your files, so your files already are a database. On tokens his objection was sharper: 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, which is the point of being able to reach into your own agent.
• The thing Nikolai hasn't solved is context: it gets contaminated too fast with failed tool calls and stale reasoning, linear history is the wrong shape, and he wants something task- or intention-based with micro-compaction rather than naive whole-history compaction. Ryan Brush's counter was the trade-off — harnesses will do much of that for you automatically, but then you're limited to what the harness does. Asked separately how to use FHIR skills and knowledge bases 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, because models hallucinate and terminology mapping especially needs an expert checking and guardrails, which Arjun rounded out as coding agent plus knowledge bases plus best-practice skills plus a human who can tell whether the generated code is right.