Persistence and Long-Running Agents

Most of our early HAAW journey happened quickly: a prompt arrived, the model performed inference, tokens were generated, and an answer appeared. An agentic mission can be very different. It may begin now, wait for something that has not happened yet, resume tomorrow, survive a machine restart, request human approval next week, and continue only after new evidence arrives.

Long-Running Does Not Mean Continuously Thinking

Suppose the mission is:

The system does not need to run transformer inference continuously for three days.

Between those events, the GPU may be doing something completely unrelated—or may even be powered off.

What Actually Has to Persist?

For a mission to survive time, the system needs more than the original sentence describing the goal.

Return to Our Five Kinds of “Memory”

The earlier HAAW memory page becomes especially important here.

A long-running system therefore cannot depend on “the model remembering” in the casual human sense. The surrounding system must preserve enough durable state to reconstruct the job later.

The Mission Record

A durable mission record might conceptually contain:

The exact implementation may be a database, queue, workflow engine, file, durable task store or another system. The important point is architectural:

Waiting Is a Real State

Earlier we encountered waiting as a synchronization cost. In a long-running mission, waiting becomes a first-class operating state.

The system might be waiting for:

• a scheduled time,
• a file to appear,
• a person to approve an action,
• a shipment to arrive,
• a service to recover,
• a price or measurement to cross a threshold,
• another agent to finish work,
• an external API to return a result, or
• new evidence that makes the next step possible.

Event-Driven Resumption

A persistent agent does not necessarily ask itself every second, “Has it happened yet?” A surrounding scheduler or event system can wake the mission when there is reason to do more work.

This is another place where the agent system is larger than the LLM. Timers, event queues, databases and workflow software can remain responsible for persistence while the model is completely idle.

Resuming Is Not Simply “Continue Where You Left Off”

Time has passed. The world may have changed.

Before acting on an old plan, a robust system may need to revalidate:

• Does the mission still exist?
• Is this still the current mission version?
• Are the old constraints still valid?
• Are credentials and permissions still valid?
• Did a human cancel or modify the job?
• Has another process already completed the action?
• Is the evidence stale?
• Has the target system changed?

Time Makes Evidence Stale

At 9:00 AM a tool may report:

If the mission resumes at 2:00 PM, that observation remains valid evidence about what was observed at 9:00 AM. It is not automatically evidence about the service at 2:00 PM.

This is why long-running systems need freshness rules and re-observation. Old evidence should not silently masquerade as current state.

Authority Can Become Stale Too

Suppose a human approves a configuration change Monday afternoon, but the system cannot execute it until Tuesday morning.

Is Monday's approval still valid?

The answer depends on the control design. Approval may be scoped by:

• specific action,
• specific target,
• specific mission version,
• specific expected state,
• time window, or
• one-time execution.

If relevant state changed while waiting, the system may need to revalidate or request approval again.

Long-Running Autonomy Has an Envelope Through Time

Our autonomy envelope now gains another dimension: time.

An action authorized today may not be authorized next week. A credential can expire. A mission can be cancelled. A human can reduce permissions. A policy can change.

Checkpointing a Mission

We have used the word checkpoint before in training, where a checkpoint can preserve model parameters and related training state. Here the word means something different.

A mission checkpoint is a durable record sufficient to reconstruct meaningful task state after interruption.

That checkpoint might include evidence references rather than copying every observation into one enormous context.

Why Not Keep the Entire Conversation Forever?

Because context is finite and expensive.

A mission lasting weeks could accumulate:

• thousands of tool calls,
• many model inferences,
• logs and documents,
• human messages,
• failed attempts,
• replans,
• approval records, and
• intermediate artifacts.

Stuffing all of that into every new inference would consume context capacity and computation.

Long-running systems therefore may externalize detailed history and bring only selected material back into active context.

Compression Creates Risk

Summarization is useful—but a summary is not identical to the original evidence.

It can omit:

• a qualification,
• a timestamp,
• a failed attempt,
• a conflicting observation,
• an authority limitation, or
• a detail that becomes important later.

This is exactly where provenance becomes important. A summary can point back to the underlying event or artifact.

Mission Identity Matters

If a mission wakes repeatedly over several weeks, each execution needs to know which mission it belongs to.

A stable mission identifier helps distinguish:

• the original mission,
• later revisions,
• retries,
• duplicate wake events,
• parallel branches, and
• replacement or cancelled missions.

This is the same lineage problem we encountered with retries and multi-agent work—now stretched across time.

Duplicate Wake-Ups and Idempotency

Imagine an event arrives twice:

If two workers resume the same mission independently, the system must avoid performing a one-time external action twice.

Persistent systems therefore often need operation IDs, state versions, locks, transactions, idempotent operations or other coordination mechanisms.

What If the Machine Restarts?

If mission state exists only in RAM, a reboot may erase the mission.

If the durable state has been safely stored, another runtime instance can potentially reconstruct it:

The continuity belongs to the persisted mission state—not necessarily to one continuously existing OS process, GPU process or model instance.

Could the Model Change While the Mission Sleeps?

Yes. A long-running system may resume using a different model version, runtime version, tool version or policy configuration.

That raises an important forensic and operational question:

Not necessarily.

A robust record may therefore preserve relevant version information for:

• model,
• runtime,
• tool definitions,
• external tools or APIs,
• policy/control configuration, and
• mission instructions.

Long-Running Does Not Mean Immortal

Every persistent mission needs conditions under which it ends.

A task that can persist indefinitely without a meaningful stop condition is not merely “very autonomous.” It is a control-design problem.

The WITNESS View

Long-running missions make WITNESS especially valuable because human memory is a poor substitute for a reconstructable event record spread across days or weeks.

WITNESS would want to preserve:

• mission ID and mission versions,
• creation time and originating authority,
• each active/inactive/waiting interval,
• wake trigger and reason,
• model/runtime/tool versions used during each work interval,
• evidence and its timestamp,
• summaries plus links to source evidence,
• replans and why they occurred,
• approval and permission changes,
• human interventions,
• external state changes,
• verification results, and
• the final stop condition.

The Boundary

We can now separate another set of ideas that casual language tends to blend together.

A long-running AI agent is therefore not best pictured as an artificial mind sitting awake for weeks thinking about one problem.

It is better pictured as a durable mission system that preserves state, sleeps when there is nothing useful to do, wakes when a dependency changes, reconstructs the relevant context, revalidates the world and its authority, performs another bounded piece of work, records what happened, and either continues, waits, escalates or stops.