Agent architecture

How always-on agents keep their work when their computers sleep

A Stanford lecture on leerob follows the architecture behind persistent agents, from saved machine state and durable workflows to selective updates, delegated tasks and compressed memory.

Keep the work beyond the session

An always-on agent can spend part of its time asleep. In his Stanford lecture, leerob describes a system that wakes when a message arrives, starts a computer if the task requires one, then saves their state before putting both back to sleep. Conversation logs, memories and routines persist between those periods of activity, so continuing the work does not require keeping the machines running.

The lecture begins with a model calling tools in a loop, a harness with an immediate limitation: "you close your laptop and the process stops," leerob says. Moving the agent to a server lets it run independently of the user's laptop, while a separate Linux machine supplies files, a browser and a desktop where it can save material and build a record of its work with the user. A direct request can start that work, but so can a Slack message, an email or another event.

That arrangement changes the conversation as well as the location of the process. "It knows when to be quiet," leerob says of an agent that works in the background and returns with an important update. He places this after earlier ways of working with AI, from copying code into an editor to terminal agents and dedicated applications that run agents in parallel; in his account, the user increasingly steers ongoing work, including interrupting a request with a change that the model and harness must understand together.

Ordinary files give that ongoing work a searchable history. In leerob's description, a user profile accompanies prompts while a working log records completed activity, so the agent can retrieve earlier work when asked. Skills preserve procedures in Markdown, plugins supply additional tools, and routines run prompts on a schedule, connecting stored instructions with work that can begin without another direct request.

Separate the loop from the computer

The server that hosts the agent loop remains separate from the computer that the agent uses, which leerob describes as a Firecracker virtual machine with support for snapshots and direct user access. A critical Linux update illustrates the reason for that separation: the system can rebuild the computer while keeping the conversation and execution state on the server.

Incoming events pass through a router that removes duplicates and decides how to bring them into the conversation, while the system considers whether an update deserves the user's attention. The speaker compares that decision with a colleague choosing when to report progress. Recovering interrupted work requires another mechanism: durable workflows resume from the point of failure, rather than merely putting a task back into a queue after a crash, and leerob says the team uses Temporal for that infrastructure.

The client connects to this machinery through a single tool, "send to user," as leerob calls it, while commands, file operations and other heavier capabilities live on the server. averagely on X singles out this feature of the talk, describing SendToUser as a simple connection that moves much of the complexity to the server. The client still chooses how to present what arrives, whether as a sign-in form or a draft that the user can edit and approve.

Give the main conversation room

Tool discovery addresses the space available in the model's working context. Loading every connector's complete tool definitions would leave less room for the conversation, leerob explains, so the harness can expose names and retrieve details when a tool becomes relevant. The agent can work outward from information already in the conversation to connected services, search, the browser and the full desktop before returning an unresolved need to the user; within the browser, it can examine page structure or accessibility information before relying on pixels.

Delegation serves the same effort to contain context. The aim, leerob says, is to "keep the conversation as sparse as possible," so helpers run commands or make extensive tool calls and return results without adding their entire working histories to the main conversation. Each helper has a durable workflow that can preserve progress through a crash, while the main agent manages the work and its to-do list. The user can check progress, send a message or stop a helper.

That division of work sits beside questions about operating costs in posts by poteto on X. Responding to a user, poteto recommends asking the bot to check for expensive routines and reduce messages between bots, adding that routines usually account for costs that accumulate quickly. The post concerns where activity comes from, while leerob's lecture examines how the harness contains the context that activity produces; both describe work that requires management beyond a single exchange.

Preserve context and permission

Security decisions also sit inside the harness. In the lecture, leerob calls for reviewing shell commands and treating incoming emails or webhooks as untrusted material rather than user instructions; for actions such as sending an email, he says, "ask the user first." Password handling can have a separate product workflow that keeps credentials outside model conversations. In its own announcement, claudeai on X describes Claude Duet as a proactive agent that keeps working when the user steps away and checks before acting on the user's behalf, connecting ongoing work with user involvement.

For long conversations, leerob recommends keeping tool definitions and system instructions stable between calls so the unchanged portion of the prompt can remain cached. Long outputs can go into files, while helpers can take on expensive work such as interpreting screenshots. As with selective tool discovery, these choices keep detailed material outside the main conversation while leaving it available to the agent.

Eventually the conversation still needs compression, and "all compression is lossy," leerob says. He describes compacting while the prompt cache remains warm so the user can return to a summary, while memory retains core user facts alongside dated logs and temporary scratchpad notes. Files hold material outside those immediate layers for the agent to search. Across a replaceable computer, workflows that resume after failure, helpers that return results and records that remain searchable, the architecture separates what must stay in the conversation from what can be recovered when needed.