Why Most AI Agents Die After One Session and How Long-Running Ones Survive

Why so many agents feel temporary

Anyone who has used ChatGPT, Claude or another tool-calling agent has seen the usual arc:

1. You hand over a goal.
2. The agent gets to work.
3. It calls a few tools.
4. The conversation grows long.
5. Answers get worse, or the session simply ends.

That is the ordinary chat-agent experience. It suits short tasks and falls apart when the work stretches over hours or days.

A long-running agent keeps making progress over a much longer span, be it hours, days or weeks, and doesn't lose its work when the context fills up or the process is restarted. Here is the idea from the ground up, followed by the patterns that make it work.

Start simple: what a long-running agent is

An ordinary agent is like someone who works in a single meeting room and forgets everything on leaving it. A long-running agent behaves more like a person who:

• keeps a notebook, which is durable external state;
• writes down progress, which is checkpointing;
• can step out and return later, which is session persistence;
• carries on exactly where they stopped, which is resuming from the last state.

In technical terms, such an agent can survive several context windows, survive restarts and crashes (fault tolerance), leave structured material behind in the form of artifacts and session logs, and resume without starting from zero.

Holding state outside the model and recovering cleanly from it is a central part of what people call harness engineering.

The three walls

Nearly every long-running agent runs into the same three problems.

1. Finite context. Each model has a limited context window, and even big windows fill up. When one is full, older information is dropped or compressed and the agent's decisions deteriorate. This is often called context rot.
2. No persistent state. A new session usually begins with blank memory. With nowhere external to keep progress, each restart is like a new hire joining the project knowing nothing about its history.
3. Weak self-checking. Models lean optimistic. Asked whether the work is done, they often say yes when it's only partly finished. With no outside check, incomplete work gets marked complete.

These three explain why simple agents can't run reliably for long.

From basics to useful patterns

Once the walls are clear, the question is how people get past them. Four foundational patterns keep reappearing.

• Checkpoint and resume. The agent saves progress in a structured form at intervals. If something fails, it restarts from the last good checkpoint instead of the beginning.
• External memory. Important facts live outside the model's context, in files, a database or a session store, and the agent reads them at the start of every new session.
• Human in the loop. For significant decisions, the agent pauses, waits for a person to approve or reject, then continues. This has to be designed carefully so state doesn't go stale during the wait.
• Separate roles. Rather than one giant agent doing everything, systems often split the job: one part plans, one executes and one checks quality. That lowers the odds of confusion or overconfidence. It's usually known as a multi-agent or sub-agent setup.

Simple on their own, these patterns are powerful together.

A mental model

A useful picture: the model is the brain, the tools are the hands, and the session log together with external state is the memory that survives.

If brain and hands are tied to a single temporary process, the system dies with it. If memory lives outside, a fresh process can wake up, read the memory and continue. That is the core architectural shift.

What becomes possible

Once agents survive longer, new kinds of work open up:

• research that takes several days;
• large code migrations;
• ongoing monitoring and ambient background work;
• workflows that need human approval partway through;
• teams of agents coordinating over time.

Short chat agents are good at answering questions. Long-running ones begin to be useful for owning real outcomes.

From demo to production

Most demos stop at this point, and real engineering starts. Five patterns carry the weight.

1. Checkpoint and resume

This is the most important pattern, because the most common failure in long work is lost progress. Imagine an agent that has processed 200 documents and hits an error on the 201st. With no checkpoint, meaning a snapshot of memory or process state, the entire run is wasted. Many agents respond by restarting the whole process, which burns a great many tokens.

A good system writes durable progress at intervals, recording:

• what has been completed;
• what is still pending;
• any important intermediate results.

After a restart, the agent reads the last checkpoint and continues from there. This one habit removes a large amount of fragility and also saves tokens.

2. Memory outside the model

There are usually two kinds:

• Working memory is what the agent needs right now, inside the current context.
• Durable memory is what must outlast a session, and it's stored externally.

Durable memory can live in structured files such as progress.txt, plan.json or notes.md, in a database, in a session store or in a specialised memory service. The principle is simple: the model can forget, but the system around it shouldn't.

3. Keep generation and evaluation apart

Models grade their own work unfairly and tend to be too generous. A common and effective fix is to split the roles, so one part produces the work and another judges whether it's good enough. These can be two different agents, or one model used in two modes with different instructions. What matters is that completion isn't decided only by the producer.

A frequent arrangement is a supervisor or planner, then task experts as workers, then a judge, which handles distribution and orchestration. The next pattern covers it in more detail.

4. Human approval done properly

Many systems claim to support approval but implement it badly. The weak version saves some JSON, sends a notification, hopes a person replies and later tries to resume, often with stale state.

The better version treats the pause as part of the workflow itself. The agent reaches a clear decision point, saves its state cleanly and waits. When the person responds, the agent resumes knowing exactly why it paused. This matters most for actions with consequences, such as spending money, changing production systems or sending messages outside the organisation.

5. Coordinating many agents

As tasks grow, a single agent doing everything gets messy. A steadier arrangement splits responsibility:

• planners explore the problem and break it into tasks;
• workers carry out focused pieces;
• judges decide whether an iteration is good enough.

Cursor has reportedly moved toward this approach after earlier coordination attempts failed. It cuts chaos and stops agents from stepping on each other.

What a production stack looks like

A realistic stack often has three layers:

1. Agent logic, meaning the prompts, tools and decision loop.
2. The harness, meaning session management, workflow control, retries and recovery.
3. Managed primitives, meaning durable storage, scheduling, long-running tools, event triggers and observability.

Google's ADK, for instance, ships building blocks for sessions that persist, execution that survives restarts, and triggers driven by events. With those, an agent may sit idle for ages and still pick up correctly afterwards. Anthropic's writing about harnesses stresses separating the brain, which is the model and its loop, from the hands, which are the execution environments, and from the session, which is the durable event log.

Vendors use different names, but the idea is shared: state and recovery must live outside any single temporary process.

Design rules that help

These habits reliably make systems sturdier:

• Write important progress to durable storage every time.
• Prefer structured artifacts such as JSON, markdown logs and task lists over memory held as plain prose.
• Treat failure as normal and plan for it.
• Make resuming the default route and not a special case.
• When quality matters, keep the producer and the evaluator separate.
• Use compaction or summarisation when the context starts growing too large.
• Design approval points on purpose instead of adding them later.

Small decisions compound. One good checkpoint strategy can rescue a multi-day run and save both time and tokens.

Limits that remain

Even with good architecture, hard limits stay:

• Cost. Long runs consume many tokens.
• Security. A system that runs longer has a bigger attack surface.
• Alignment drift. Over a long period the agent can slowly wander from the original intent.
• Verification. Some kinds of quality still need human judgment.

The human role doesn't vanish. It changes. Instead of performing every step, people define goals, set constraints, review critical decisions and handle exceptions the system can't safely settle.

Where this leaves you

Short chat agents suit questions and small jobs. Long-running agents suit work that takes time, spans several sessions or has to survive real-world interruptions.

The change has less to do with making the model smarter and more to do with making the surrounding system durable, recoverable and honest about its own progress. Seen as systems that must outlast time, failure and context limits, agents become much easier to design. Agents capable of owning meaningful work tend to come from teams that put persistence and recovery at the center of the design.