A Long-running Agent Is Not Always Running

Published: 2026-08-28 5,119 words 16 min read

We usually understand “long-running” as a process that remains alive. A database, queue, or web service occupies memory and listens until it exits, so a Long-running Agent might seem to be a model instance that stays online and keeps thinking.

Agents use another kind of continuity. An Agent may perform no inference for hours; its process and machine may be gone, and it may restart with a different model. If its goals, history, and judgments can be restored, we still regard it as the same Agent. Its longevity comes from state that can be reconstructed repeatedly.

Most of the Time, the Agent Is Not Running

A traditional Long-running Service follows this lifecycle:

Text
UTF-8|1 Line|
process starts → keeps running → process exits

Its continuity is tied to the process. An Agent looks different:

Text
UTF-8|6 Lines|
wake up
  → load persistent state
  → assemble the current context
  → execute one Turn
  → save the result
  → go to sleep

Between wake-ups there may be no model instance, active inference, or inference cost. An Agent might analyze code and record a plan on Monday, then wake after an event on Wednesday and resume the project. No computation occurred for two days, but the restored Agent knows its objective, completed work, and next step. The two runs form one continuous process.

Distinguish Agent, Conversation, Session, and Turn

Four concepts are often conflated:

  • Agent: a persistent identity and its behavioral constraints.
  • Conversation: persistent dialogue history associated with the Agent.
  • Session: one active connection between a user or system and the Agent.
  • Turn: one model invocation and inference.

A Session can include many Turns, a Conversation can span Sessions, and an Agent can participate in many Conversations. Closing a browser may end a Session while preserving the Conversation. Releasing a model container ends a Turn while stored goals and memories remain available for the next connection. Changing machine, runtime, or even model need not break continuity; what matters is sufficient consistency in the restored identity, history, goals, and behavior.

Identity here is persistent material: system instructions, user relationships, task state, long-term memory, conversation history, and runtime resources and permissions. Their assembly for a particular run produces the behavior of the current Agent.

The Harness Is the Agent’s Operating System

A model invocation sees only its context window. It does not automatically save an experience or naturally remember it next time. The external Harness preserves and restores the Agent by managing conversations, memory, tools, environments, and model calls, then selecting what enters each Turn.

Agent systemOperating system
Context windowPhysical memory
Conversation historyDisk
CompactionCompression and paging
RecallLoading data back on demand
Long-term memoryPersistent structured storage
HarnessOperating system

A Conversation can grow while context remains finite, just as disk may be large while a process has limited memory. The Harness compacts old material, preserves recent messages, and retrieves relevant history. It decides what belongs in the current working set and what must be loaded later. Before each call, it uses those choices to reconstruct the Agent’s present “consciousness.” Separate model invocations thereby appear as one continuous actor.

Continuity Is a Compilation Result

At wake-up, the Harness combines several sources:

Text
UTF-8|8 Lines|
system prompt
+ agent memory
+ conversation summary
+ recent messages
+ recalled history
+ current environment
+ available tools
= the Agent the model actually sees in this Turn

This resembles compilation rather than replay. A finite context budget requires selection, compaction, and reorganization. The system stores source material; the model sees a compiled result.

A critical decision may remain in a three-month-old database record, but if compaction omitted it and retrieval misses it, the current model does not know it. Preserved history means only that material can be retrieved. Continuity depends on whether the Harness compiles the right history into context for the present task.

Conversations Can Grow While Memory Remains Limited

Agent products may make Conversations appear unlimited, but a Harness only hides the underlying context limit. Every selection can lose information.

1. Compaction Loss

Summaries often preserve a conclusion while losing exact wording, evidence, rejected options, and conditions. “Choose A because this environment does not support B; reconsider after an upgrade” can become “The project chose A.” The decision survives, but its reason and reversal condition disappear.

2. Recall Failure

Retrieved information depends on the current query. Different wording, or failure to notice that old history is relevant, can prevent a match. The information still exists, but the system does not know to look for it now: forgetting at the retrieval layer.

3. Identity Drift

If important experience remains only in Conversation history, each restoration can differ. One summary emphasizes preferences and another the current task; one retrieval finds an agreement and another misses it. Through many incomplete restorations, behavior, style, and judgment can gradually drift. Saving all history is relatively easy. Restoring what matters for the next action is harder.

Measure Long-running Agents by Recoverability

Design priorities should move from process uptime to state recovery: test whether critical constraints re-enter context when needed, and distinguish the recent working set, Conversation archive, long-term experience, and current environment.

Practical questions include:

  • Does the Agent wake knowing its goal and completed actions?
  • Can it recover important decisions and their conditions?
  • Does it remember durable agreements with the user?
  • Can it distinguish old facts from a changed environment?
  • Does core behavior remain stable after a model or runtime change?

The concrete test is to terminate the process, let the task sleep, and perhaps replace the runtime or model before waking it again. Check whether it recovers the goal, completed actions, conditions behind key decisions, and durable user agreements—and whether it notices environmental change. A database full of Conversations does not establish continuity if the restored Agent cannot use them.