The first agent runtime I built this year didn’t know when to stop. In February I watched it finish an answer and continue for two more rounds because the system had no completion check. I can’t show you that run. Only the fix survives: one commit line capping automatic continuation at five rounds. After watching an agent spend rounds on a finished answer, I stopped trusting its progress reports and returned to checking the work by hand. That removed much of the value of delegating it.
Hand an agent a refactor, investigation, or deployment in the morning, and by evening you should be able to trust its account of the work. Building that has been expensive. Since February I have built three runtimes and discarded two.
All three live in private repos, so I can describe them but not link them. The first was a local, all-in-one workspace whose initial import on 17 February was already broad rather than cautious. The second was an edge-native rewrite of the same instincts that landed on 9 April. The third is the kernel I run today, built around durable events, projections, work items, and approval gates. This week I ran git log through all three histories with a single test: what did each version make visible that the one before it could hide?
February put everything in one room
Version one solved delegation by proximity. Chat surface, tool runtime, local database, terminal sessions, automations, skills, channel adapters, and the first swarm experiments all lived in a single application. It wasn’t elegant, but when something broke, the pieces sat close enough together that finding the break rarely took long.
The commit history moves fast. Four days after the import, on 21 February, a large platform expansion added services, UI, skills, and files called soul documents that gave each agent a standing personality. Four fixes landed the same day and proved more instructive. The first four days fit in six lines at the bottom of the log:
$ git log --format='%as %s' | tail -6
2026-02-21 Remove personality presets (friendly/pragmatic)
2026-02-21 Scale down chat heading sizes and match inline code font size
2026-02-21 Cap length-truncation auto-continue at 5 rounds
2026-02-21 Fix model token limits: pass maxOutputTokens to LLM API
2026-02-21 Phase 9-J: skills, soul documents, services, UI, and infra
2026-02-17 Initial commitThe third line is the cap from the run that opens this post. It was filed four days into the project, between a font-size fix and a token-limit fix.
Together those four lines describe an agent with plenty of capability and little spending discipline. Responses ignored their token budget, the chat surface used oversized headings, and personality presets stood in for policy. The important code sat underneath the prompt: schemas, approval policy, path checks, result truncation, command lifetimes, session IDs, and links between each tool result and its originating call.
By the end of the month I was asking the system smaller, stricter questions: is this tool read-only, does this command stay inside its directory, has this response hit its budget, can the user open the skill file and read what it does.
April stopped pretending to be a laptop
System two began from one architectural bet: the runtime would no longer get to behave like a laptop. Processes became isolates; files, durable workspace views; cron, scheduled state; browser sessions, model calls, memory, and publishing all moved behind platform-shaped boundaries. The design question changed from “can this run in the cloud” to “which durable object owns this kind of truth.”
The rewrite landed on 9 April. Two days later came the swarm runtime and chat performance work. The following day added a Claude-native runtime and overhauled long-running tasks. Within the week, the chat stream had been rebuilt and runtime recovery hardened. Porting the code went quickly. Reassigning ownership took longer because every invariant kept safe by adjacency in the February workspace needed a named owner.
Once an agent can outlive its browser tab, model stream, and original process, its working state must survive a closed tab and restarted process. A transcript cannot own that state. Transcripts are written for readers; they smooth over retries and narrate partial work. Recovery needs the precise point where a run stopped.
Six jobs for one transcript
By the third system I could name the defect: the transcript held six jobs at once, serving as model history, user interface, recovery log, tool ledger, approval queue, and progress indicator. The live kernel separates them. Tool calls, results, approvals, context changes, and worker status are recorded as durable events. The transcript, progress view, recovery path, and replay are projections of that record.
You could read this as event-sourcing for its own sake, and for a chat product it would be; transcripts have carried chat products for years without complaint. The break comes with delegation. The moment a run is allowed to continue after I close the tab, something other than a rendered conversation has to know, exactly and replayably, what has happened so far.
What converted me is what the split does to recovery. The kernel treats a dead tab as nothing special: the worker keeps going behind the boundary, a stalled model stream gets retried there too, and a page that reconnects replays the events it missed and shows the run as it actually stands, the parts that happened while the tab was gone included.
Multi-agent work became interesting to me again on the same terms. In the current kernel a subagent takes an owned, scoped task with its own abort path; edits and deploys carry their owner and approval trail; and the verification pass opens the produced artifact and checks it against the task.
The tests changed shape alongside the runtimes. February’s suite asked whether the pieces worked; April’s asked whether the runtime survived; the kernel’s take the sentence “the agent can do this” and ask under which interruption, through which projection, with whose permission, after which replay, and with what visible evidence. A model stream that stalls without reporting anything used to be a support mystery. Now it is a failing test.
Context management uses the same records. Conversations grow, tool output is noisy, and models can lose important information inside their own output. I used to describe the resulting runs as distracted, overconfident, or overly loyal to a stale plan. Those apparent moods were bookkeeping errors. The kernel now records what the model may still remember, what the user can inspect, what can be reconstructed, and what must never disappear quietly. Correcting the ledger removed most of those behaviours. Providers also need explicit treatment. The first system hid every model behind one generic interface until streaming semantics, tool-call formats, token counting, and recovery paths diverged. The April version became Claude-native. The kernel handles provider-specific behaviour at the boundary and normalises it into durable events early.
What survived
I still want agents to run long investigations, delegated builds, browser-validated deployments, and work that continues while I sleep. After three generations, I trust the surrounding machinery: permissions, budgets, durable events, replay, recovery, explicit ownership, and tests that can disprove the product’s promises.
The three systems in this post remain private, but their design has moved into Arcwell, an MIT-licensed Rust platform for Codex, Claude, and other MCP-capable agents. It uses durable records, policy gates, work runs, and projections. STATUS.md records what works and what does not yet.