The goal is what nearly everyone who uses coding agents wants: give one a job, go and do something else, then come back to find that it chose a sensible approach and finished the whole thing.
Getting there has taken me three experiments in five months. Neither of the first two became the system I use today; what they taught me now shapes Arcwell and the production agent work I do for customers.
The first agent did not know when to stop
My February attempt was a local application containing almost everything: chat, tools, a database, terminal sessions, automations, skills, channel adapters and early experiments with multiple agents. It was not architecturally pure, but the proximity made it productive. When something broke, the relevant code and state were usually close enough to find.
Then I added automatic continuation. Long answers were hitting their output limit, so the runtime let the model carry on in another turn. During one run the agent finished the useful answer and continued for two more rounds. The system knew that a response had ended. It had no way to decide that the job was done.
Only the repair survives in the history: Cap length-truncation auto-continue at 5 rounds, committed four days after the project began. The cap stopped one kind of runaway spending without answering the more important question.
I had spent most of my energy expanding what the agent could do. It could call tools, maintain terminal sessions, work with files and continue across model limits. None of those capabilities told it whether it had satisfied the request, left a requirement untouched, or produced something which actually worked.
That distinction is now part of the production agent I work on. Before a turn can finish, it audits the requirements which remain. Code produced by a worker stays incomplete until it has been integrated and the resulting build, tests or other declared check have passed. A confident final answer may be pleasant to receive; it is not evidence of completion on its own.
The second runtime contained three different products
I had also been using “the agent” to describe three jobs which happened to share model APIs.
A personal assistant needs continuity, conservative permissions and enough memory to act sensibly over time. A specialist adviser needs carefully maintained knowledge, provenance and strong retrieval. A coding agent needs an isolated workspace, a real execution environment and enough latitude to change software without reaching beyond its assignment.
Putting all three in one runtime gave me a substantial common core and three compromised products. When I moved the coding runtime to the edge in April, the laptop stopped quietly covering for unfinished design. Workers needed isolated processes and durable access to their files; scheduled jobs needed state that survived a restart; model calls, browser sessions and publishing needed boundaries I could reason about.
The move exposed how much design the laptop had been supplying accidentally. A file could be “owned” by whichever process happened to have it open; a retry could live in memory; recovery could rely on the original terminal still existing. Once an agent was expected to outlive its tab, model stream and process, every piece of work needed a durable owner.
Porting the code was relatively quick. Most of the work went into decisions the laptop had allowed me to postpone: what should survive, who could change it and which component owned recovery. Moving to the edge forced those product boundaries into the design.
One transcript was doing six jobs
Recovery still felt fragile in the third attempt, and eventually the reason became obvious: I had made one transcript serve as the model’s memory, the user interface, the recovery log, the tool ledger, the approval queue and the progress indicator.
That arrangement works tolerably while a person sits in front of a chat. A transcript is written to be read. It smooths over retries, omits intermediate state and turns several attempts into a coherent exchange. Recovery needs the less elegant account of exactly what completed, what failed, what was approved and what still belongs to somebody.
In the third runtime, durable events record tool calls, results, approvals, context changes and worker status. The transcript, progress display, replay and recovery path are separate projections of those records. A dead tab is unremarkable: the worker carries on behind the boundary, and a reconnecting page replays the events it missed.
This changed how I understood several behaviours I had blamed on the model. An agent which seemed distracted might have lost an important decision during context compaction. One which appeared overconfident might be looking at a cleaned-up transcript which concealed a failed retry. A stale plan could survive because the user saw a correction which the next prompt no longer contained. Better bookkeeping fixed behaviour I had been trying to prompt away.
The generic provider interface also broke once streaming semantics, tool-call formats, token accounting and recovery behaviour diverged. The later systems deal with those differences at the boundary and normalise them into durable records early enough for the rest of the runtime to reason about them.
I only found multi-agent work dependable once every subagent had a bounded job, a named owner and an abort path. Its edits are not complete merely because it reports success; integration and verification happen against the resulting artifact. When something stalls, the operator can see which piece of work stopped and what evidence exists, rather than reading a conversation and guessing.
Where those lessons went
The customer-used agent I develop at work now checks what remains before declaring a task complete. Worker code has to survive integration and the declared build, test or validation step. Durable work state lives outside the worker transcript, and structured progress records drive the interface people use to understand a long run. Those are direct consequences of the three systems described here.
Arcwell applies the same experience in a different way. I chose not to build a fourth general-purpose agent runtime because Claude and Codex are already the agents I want to use. Arcwell adds the memory, research, policy, scheduled work and operator views around them. Jobs continue after a chat turn ends; queues, cursors, decisions, evidence and failures remain available when I need to understand what happened later.