Stanford CS146S: How always-on agents work

Lee’s Stanford lecture extends the familiar model-and-tools loop into an agent that can keep state beyond a laptop session. Messages, schedules or external events can wake it, and it can work in the background before deciding whether an update deserves the user’s attention.

The lecture explicitly includes work in progress. Weeks or months of useful autonomous work are a direction to build and evaluate, not an established reliability guarantee. The architecture must make continuity possible while still allowing servers and computers to sleep when they are not needed.

The server holds conversation and agent state; a separate cloud computer supplies files, shell commands, a browser and desktop interaction. Lee describes snapshotting and restarting a virtual machine, with a live view that a person can also control.

The separation lets the computer be rebuilt or shut down independently of the agent loop. A thin client can display state and send messages while heavier work stays server-side. A machine snapshot preserves execution state, but that is different from proving the agent remembers every important fact or can safely repeat every external action.

13:45View full image

The lecture contrasts restarting a whole task with a durable workflow that records progress and can resume after failure. Temporal is the described implementation choice, while each helper can have its own recoverable workflow.

This is a simplified architectural distinction, not a claim that all queues lack checkpoints or that durable replay makes every side effect exactly once. A real system still needs appropriate step boundaries and handling for repeated tool calls. Incoming messages also need priorities: direct steering may interrupt work, while background events can be queued or combined.

16:45View full image

Lee describes a narrow communication path between client and server, while the client chooses how to render a result: text, a sign-in flow, a draft to edit or a lightweight reaction. The server carries the heavier tool capabilities.

A simple interface does not mean every action is silently authorized. The lecture specifically includes asking the user to inspect or approve an irreversible outgoing message and keeping secrets outside the model conversation. Those choices are part of the product architecture, not friction that persistence automatically removes.

Loading every tool schema into every prompt consumes working space before the agent has done any useful work. Dynamic discovery keeps a lighter index and retrieves detailed instructions when a tool becomes relevant.

The lecture then describes moving among known context, APIs, search, browser structure, screenshots and desktop interaction. A dedicated tool can be better than repeatedly rebuilding a shell routine. The goal is an efficient and reliable path to evidence, while access boundaries still apply; falling back to a browser does not authorize bypassing authentication or another person’s permissions.

A main agent can delegate tool-heavy work to helpers and receive a bounded result instead of importing every intermediate command and screenshot. That keeps the primary conversation smaller and can let different tasks optimize for different latency needs.

Lee later explicitly notes that infinite context is not real. Summaries can omit details, and the main agent still needs enough evidence to use a helper’s answer responsibly. Delegation changes where work and context live; it does not remove cost, errors or the need to preserve important failure information.

The lecture separates running commands on an isolated computer from treating all inputs as trusted. An email or webhook may contain instructions an attacker wants the agent to follow, but it is not thereby a user command.

A reviewing model can provide another check, yet the talk’s broad comparative enthusiasm is not a public security benchmark. Lee acknowledges continuing work on prompt injection and secure harnesses. Isolation, authorization, credential handling and review address different parts of the problem; none alone establishes perfect protection.

Lee emphasizes keeping reusable prompt sections and tool definitions stable where appropriate, so repeated calls can benefit from caching. Fixed ordering and careful rollout of prompt changes can reduce avoidable cache disruption.

He also describes compacting a long conversation while the relevant cache is still warm. Exact windows and prices depend on the serving system; the lecture’s examples are not a current pricing guide. More importantly, compaction is lossy. Preserving critical constraints and correctness can require a change even when it costs a cache hit.

The lecture separates core facts, dated work logs and temporary scratch notes. Files provide a way to retrieve details later instead of carrying everything in the immediate prompt.

That structure can support continuity without implying perfect recall. A durable file can still be stale, irrelevant or read incorrectly. The engineering task is deciding what to retain in active context, what to retrieve when needed and what to retire, while preserving the facts and constraints necessary for the present task.

Lee describes an inner product loop: turn an incorrect tool call or other failure into an evaluation, fix the harness, prompt or inference behavior, then check the case before shipping. A separate outer loop trains and evaluates new models over time.

This is different from a deployed agent updating its weights after every conversation. The distinction helps assign responsibility for a fix and test whether it persists. New models can unlock different interfaces, but improvement in one evaluation is not proof of safe behavior in every group chat or long-running workflow.

The lecture’s forecasts include longer-running agents, better memory and easier interfaces. Lee asks how to evaluate a month-long workflow when model releases themselves may arrive on a similar cadence. He also leaves the balance between useful proactivity and annoying interruption unresolved.

Those questions are part of the argument, not gaps to hide with a success claim. The closing advice is to understand system design, inspect architecture and learn enough about models to make better product decisions. Persistence is a collection of engineered mechanisms and checks, rather than a promise that a colleague-like chat surface can already work indefinitely without supervision.