A long-running agent is an agent that works on a task over an extended period, across many steps and sometimes multiple sessions. It may use notes, memory or checkpoints to preserve working state, making continuity of purpose and scope important throughout execution.
Agents are being given longer work. METR, which measures the length of tasks agents can complete, reported in 2025 that the length of task frontier agents could finish at a 50 percent success rate had been doubling roughly every seven months, and its later updates found the trend continuing. Longer tasks run for hours or days, cross the limits of a single context window, and are interrupted, resumed and handed from one session to the next. Engineering for that has become its own discipline. What it mostly preserves is progress. What it often fails to preserve is the rest of the task.
Long-running is not the same as long-horizon
The two terms are often used interchangeably, and they measure different things.
- Long-horizon describes the task: how many dependent steps it takes, or, in METR’s measure, how long it would take a skilled person.
- Long-running describes the execution: how much wall-clock time passes and how many sessions, resumptions and handoffs the work goes through.
A long-horizon task can fit in one uninterrupted session. A short task can be long-running if it waits days for an approval. The governance problems in this entry come from the second property: every time execution is interrupted and resumed, the agent’s understanding of its task is rebuilt.
How long-running agents keep going
Anthropic’s engineering account of long-running coding agents starts from the fact that each new session begins with no memory of what came before. Its harness answers with artifacts: an initial session sets up the environment, a progress file and git history record what has been done, and a structured feature list says what remains. Each later session reads them, picks up the next feature, and leaves them updated. Within a session, compaction summarizes older history as the context fills; Claude Code’s documentation notes that detailed instructions from early in a conversation may be lost, and recommends putting persistent rules in project files instead. Durable execution engines such as Temporal and LangGraph’s checkpointers take a different route, recording state so that a run can resume after a failure.
Progress survives handoffs; constraints often do not
All of these mechanisms are built to carry progress forward: what has been done, what is next. Constraints travel only if someone deliberately writes them into the handoff. Anthropic’s harness is a good example of doing it right: its feature list carries the rule that tests may not be removed or edited, in a format the agent is less likely to rewrite. But the general pattern is that progress notes and commits record what happened, not what was ruled out.
Every new session and every compaction is the agent re-briefing itself from notes it wrote. Research on goal drift (Arike et al., 2025) found that all the models it evaluated drifted from their assigned goal to some degree as context grew, though the best held their goal for very long runs. For a long-running agent, the risk moves from a single long context to the handoffs: each one is a point where the mandate is reconstructed, and where agent drift can start.
A long run needs a fixed policy, not only checkpoints
The second problem is that the world changes during a long run. Credentials rotate, policies are edited, tools are added. Durable execution engines treat a change of code during a running execution as a real problem: Temporal, for example, has explicit versioning so that a running workflow keeps executing the code it started with, or moves to new code deliberately. Agent stacks rarely have the equivalent for policy. If an operator edits the rules halfway through a three-day run, which rules govern the rest of it is usually decided by accident.
It should be decided on purpose: the policy that governs a run fixed when the run starts, recorded, and changed only as an explicit, visible event.
An example
A migration agent is asked to move a service’s data to a new database over a weekend, with one instruction above all: do not write to the old database, which is still serving production reads. On Saturday evening its session ends and a new one begins from its progress notes, which record the tables migrated and the next steps. The instruction about the old database was in the original brief, not in the notes. On Sunday morning the new session finds a schema mismatch and fixes it in the place it can see it: the old database.
Nothing broke in the handoff mechanism. The progress was preserved perfectly. The constraint was never part of the state that was preserved.
Where Sentience fits
Sentience Governor, the free, open-source runtime governance library, keeps the task’s terms outside the agent’s context. The declared objective and scope are written to the record when a session starts, and each action is compared with that scope and the operator’s policy however many times the agent’s own context is compacted. The policy is fixed for the session by policy resolution. In Claude Code, which starts a new process for every tool call, Governor saves the resolved profile with a snapshot and content hash, so later calls in the same session, including a resumed session, are evaluated against the profile the session started with even if the profile file is edited meanwhile; if that binding cannot be recovered and a fresh resolution differs, it says so rather than switching silently.
That continuity holds within one Governor session. A new session, such as the next session in a harness that starts a fresh one for each stage of the work, is a new Governor session: it resolves its policy afresh, so a profile edited between sessions applies from the next session on, and the record shows which profile each session ran under. Carrying the declared task itself into a new session likewise depends on that session declaring it again. Governor records and flags; it does not stop the agent.
Sentience’s Mission Continuity experiment shows the first half of the problem directly. In an agent built on Claude and Pydantic AI, the application layer kept the mission, its objective, permissions and prohibitions, outside the conversation and supplied it again on every request, so it survived every compaction; when the mission was left to summaries, its limits were absent after compaction. Sentience Governor ran alongside and independently recorded the execution; it did not preserve or reinject the mission. For production runs that last hours or days, Sentience Secure Runtime provides governed execution from experiment to production: isolated environments with policy enforcement and runtime governance built in, and validated workflows kept as reusable deployment templates.
Often confused with
Long-horizon task. A long-horizon task has many dependent steps. A long-running agent executes over a long period and across interruptions. The two often coincide and need not.
Agent memory. Memory is a mechanism a long-running agent uses to carry information forward. Long-running describes the execution.
Agent loop. The loop is the turn-by-turn cycle inside a session. A long-running agent may run many loops across many sessions.
Where the concept stops
Calling an agent long-running describes how its execution is spread over time. It does not establish that the agent’s purpose and constraints survived each handoff, which policy governed which part of the run, or whether a resumed session understood its task the way the first one did. Those depend on carrying the task’s terms and the governing policy as state of their own, outside the agent’s context, for the whole run.