An agent — the same primitive as the counter

How it works

The model is stubbed and runs in this tab, so the demo is deterministic: ask about a process, a patch, a worker or durable and it searches; give it arithmetic and it calculates; say refund 20 and it has to ask you first.

An agent loop is a process. Not "a process under the hood" — the same one the counter demo uses. State is a let, the mailbox is for await, every change is a yield, and the page binds to it the way it binds to a todo list. The transcript above is that state: the streaming answer is its last line while it arrives, and the finished step lands in the same place.

for await (const msg of self) { for (let turn = 0; turn < MAX_TURNS; turn++) { const plan = await d.step(`plan-${turn}`, () => model.plan(transcript, SPECS, { signal: self.signal })) if ('answer' in plan) { /* stream it, one yield per chunk */ break } const result = await d.step(`tool-${turn}`, () => callTool(tools, plan.tool, plan.args)) transcript.push(`${plan.tool}(${plan.args}) → ${result}`) yield s } }

Tools are processes

A tool call is call(). That is why the counters above are live — each tool is a running process with state of its own — and why a tool could just as well be on a server: it is reached by a registry lookup, and a registry lookup does not care about distance.

It is also why human-in-the-loop needs no mechanism. The approval tool simply does not reply until you click:

for await (const msg of self) { switch (msg.type) { case 'request': // parked until somebody decides waiting = [...waiting, { ...msg, reply: msg.reply }] break case 'decide': // a person decided waiting[0]?.reply(msg.ok) waiting = waiting.slice(1) break } yield state() }

The agent's side of that is an ordinary await that takes as long as it takes. The queue is ordinary state, so the buttons above are an ordinary view of it.

Durability is a wrapper

The agent is wrapped in durable(): each message is journaled before it is handled, each d.step is journaled as it completes, and the state and the cursor are committed together when the process asks for its next message. Press kill the machine in the middle of a question — the process is disposed, the next lookup activates a new one, and it carries on from the journal instead of asking the model again.

Two honest details. An effect that was in flight when the process died runs again, because its result never landed: a step executes at least once and is recorded exactly once, and it is handed an idempotency key so the outside world can make it exactly-once too. And the store is a port: the adapter here keeps everything in a Map, and a real one implements the same eight methods over whatever it is built on, with the process above it unchanged.

const run = durable(agent, { store, key: (args) => args.id })

A real model

The stub is one Model; claude.ts (the Messages API) and openai.ts (chat completions, which local servers such as Ollama, vLLM and llama.cpp speak too) are two more, on plain fetch. plan is native tool calling, say reads the streamed answer word by word, and the process's signal cancels the stream. Add ?model=claude to this page's address, or ?model=openai&id=llama3.2&base=http://localhost:11434/v1, and paste a key when asked: it is held in memory for this tab and never stored.

const model = claudeModel({ apiKey, fetch }) // or openAiModel({ model, baseUrl, apiKey, fetch })

The tests (agent.test.ts) run all of this with no DOM and no network: the model is an argument, the tools are processes, and the run reads as a transcript of yields. adapters.test.ts drives the two real adapters the same way, replaying API responses through a fetch it passes in.