{"slug": "agents-should-be-durable-not-long-lived", "title": "Agents Should Be Durable, Not Long-Lived", "summary": "AI agents should be built as durable state with short compute leases rather than long-lived processes, argues a technical essay. The model separates agent runs from executing workers, allowing millions of active runs without millions of processes, though it requires cheap state reconstruction and idempotent side effects. The essay compares this to how large web systems stopped assigning permanent server processes to users.", "body_md": "# Agents Should Be Durable, Not Long-Lived\n\nA common way to build an AI agent is to treat it as a long-running process. A worker receives a request, enters an agent loop, calls models and tools, waits for results, and eventually returns an answer.\n\nThis works well until agents start doing real work.\n\nAn agent may spend twenty minutes researching a problem, wait ten minutes for a build, ask a user for approval, or come back hours later when an external job finishes. Keeping a worker alive for the whole run wastes resources and makes failures expensive. A deployment, crash, or machine restart can also destroy work that has already happened.\n\nA better model is to separate the **agent run** from the **process executing it**.\n\nThe agent run is durable. Its state, messages, tool results, budget, and current position are stored outside the worker. The worker is temporary. It leases a runnable agent, performs useful work for a short period, checkpoints the new state, and disappears.\n\nConceptually:\n\nAnother worker can later continue from the checkpoint.\n\nThis does not mean every model or tool call needs its own process. That would create unnecessary scheduling and state-reconstruction overhead. A worker might instead receive a 30- or 60-second lease and execute several agent steps while progress is being made.\n\nThe important boundary is **waiting**.\n\nIf an agent needs to wait five minutes for CI, it should not sleep for five minutes. It records that it is waiting and exits. When CI finishes—or a timer fires—the run becomes runnable again.\n\nThe same pattern works for rate limits, human approval, scheduled actions, external callbacks, and communication between agents.\n\nThis changes how we think about an agent.\n\nInstead of:\n\n```\none agent = one process\n```\n\nwe get:\n\n```\none agent = durable state\n          + a sequence of short compute leases\n```\n\nThat model has an interesting scaling property. A system might contain one million active agent runs without needing one million running processes. Most agents will usually be waiting. Only the agents with something useful to do need compute.\n\nThere are costs. State must be cheap to reconstruct. Side effects must survive retries without being executed twice. Browsers, shells, and sandboxes may need their own longer-lived services. Streaming also needs to be independent from whichever worker currently owns the run.\n\nBut these are infrastructure problems we already know how to solve.\n\nLarge web systems stopped assigning a permanent server process to every user long ago. Agent systems may eventually make the same transition.\n\nThe useful abstraction is therefore not a *short-lived agent*.\n\nIt is a **durable agent with a leased executor**.", "url": "https://wpnews.pro/news/agents-should-be-durable-not-long-lived", "canonical_source": "https://julin.ai/2026/08/26/durable-agents/", "published_at": "2026-08-26 22:34:08+00:00", "updated_at": "2026-08-26 22:48:49.950791+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/agents-should-be-durable-not-long-lived", "markdown": "https://wpnews.pro/news/agents-should-be-durable-not-long-lived.md", "text": "https://wpnews.pro/news/agents-should-be-durable-not-long-lived.txt", "jsonld": "https://wpnews.pro/news/agents-should-be-durable-not-long-lived.jsonld"}}