Long-running AI agents need a clear way to finish, stop, and resume. A model that keeps working for hours is useful only when the work stays inside an agreed job and leaves evidence someone can check.

I compared current runtime documentation and long-horizon research with the question a client will eventually ask: if this stops halfway through, can we tell what happened and continue without repeating the expensive parts?

My recommendation is a small supervision contract. Give the agent a bounded outcome, verified milestones, enforced budgets, a durable run record, explicit action authority, and an operator who can cancel the run.

What long-running AI agents actually are

A long-running agent carries one unfinished job across multiple rounds of reasoning, tool use, waiting, and possibly restarts. The meaningful continuity is the job and its state, rather than a process that must remain awake continuously.

Consider an assistant auditing a folder of client documents, resolving conflicting facts, and preparing a review package. Its work may span several sessions because documents arrive late, an integration fails, or a person must approve the next step.

A daily assistant can run a short job repeatedly without doing long-horizon work. Our scheduled agent guide covers what starts a run; this guide covers what keeps an unfinished run coherent.

Elapsed time alone is a poor design requirement. Ask which decisions depend on earlier results, what must survive interruption, and which actions would be costly to repeat.

Separate runtime, memory, and reliability

Three questions often get bundled together: can the infrastructure keep the job alive, can the agent recover its context, and can it deliver an acceptable result? Passing one does not answer the others.

Cloudflare's long-running agent documentation distinguishes durable state from in-memory variables, timers, and open requests that disappear on eviction. That distinction explains why an active session and a recoverable job need different controls.

Benchmarks also need careful reading. METR's time horizon measures task difficulty using human expert completion time at a specified success level; it does not measure how long an agent can run unsupervised.

Its tasks primarily involve software, machine learning, and cybersecurity. METR's limitations note also cautions against translating that measure into dependable delegation for every business task.

I would use those results to understand a research trend, then evaluate the actual client workflow separately. A model's benchmark horizon cannot replace a recovery drill or an acceptance check.

Write the finish condition before the plan

“Research our competitors” can expand indefinitely. “Prepare a source-linked comparison of the approved vendors, flag unresolved pricing questions, and save a draft for review” gives the run an observable destination.

Specify the output, its owner, the approved inputs, and the excluded actions. For a draft research package, explicitly exclude contacting vendors, buying reports, and publishing conclusions unless someone separately authorizes them.

Our spec-driven agent guide shows how to agree those boundaries with a client. The supervision contract adds operational details: when the run pauses, what evidence it saves, and who can authorize continuation.

I would make completion a conjunction: the deliverable exists, the acceptance checks pass, and the final status records what remains uncertain. A polished answer with missing citations is still an incomplete research job.

Keep the acceptance criteria independent of the agent's confidence. The agent can propose that it is finished; a validator or named reviewer decides whether the required evidence is present.

Build milestones around evidence

A useful milestone answers a business question. “Collected documents” becomes “the approved folder inventory is saved, missing files are listed, and every downloaded file has a source identifier.”

For the next milestone, require a claims table linking each conclusion to a document and passage. For the final milestone, require a readable draft with unsupported conclusions removed or visibly qualified.

Anthropic's November 2025 harness experiments found that coding agents could leave ambiguous progress or declare completion prematurely. Incremental work, progress artifacts, and end-to-end verification helped in that coding setting.

My proposed translation to client work is a checkpoint with an artifact, a check, and a continuation decision. The source demonstrates an engineering approach, rather than a measured success rate for document audits.

• Artifact: what was saved, where, and under which version.
• Check: what passed, failed, or remains unverified.
• Decision: continue, revise, wait for input, or stop.

Choose boundaries where redoing work would hurt or where a mistaken intermediate conclusion could contaminate later work. Saving every trivial thought produces noise; saving only the final answer leaves a fragile run.

Enforce budgets outside the prompt

“Please stay under budget” helps the model plan, but the runtime must decide whether another call is allowed. Keep the authoritative counters in the supervisor or tool gateway, where the agent cannot rewrite them.

AWS's Agentic AI Lens recommends explicit duration, token, and termination specifications, checkpoint decisions, and remaining budgets that cascade into delegated work. Those are architectural requirements, not properties a prompt automatically provides.

Define whether approval waiting counts against active time, and separately keep an expiry for the whole job. Otherwise a paused task can resume much later using an outdated brief or stale authority.

In concurrent systems, reserve budget before issuing calls and reconcile actual usage afterward. Without that reservation, several workers can each see the same remaining allowance and collectively overspend it.

Count recovery costs and dependent failures

A restart is part of the same job. It should inherit remaining budget, previous action records, and the original deadline rather than receiving a fresh allowance that quietly expands the client's commitment.

Use workload arithmetic before quoting savings. A hypothetical run could spend $1.20 on model calls, $0.40 on paid tools, $0.10 on runtime, and $0.30 recovering from a failure, for $2.00 total.

Those figures are invented inputs for a planning example, not current vendor prices. The calculation notes show the assumptions; real billing must use the selected provider's meters, allowances, and actual charges.

Dependent steps also expose why repeated local success can leave disappointing overall results. If twenty required steps each independently succeed with probability 0.95 and there is no recovery, the chance they all succeed is 0.95 to the twentieth power, about 36 percent.

That is a hypothetical probability product, not an estimate of any model's performance. Real errors are often correlated, and verification or repair changes the process, so do not use that number as a forecast.

The design implication is modest: verify intermediate outputs and recover from failures before extending the chain. Our agent evals guide helps turn that intent into cases with observable outcomes.

Save a recovery package, not just a summary

A conversational summary explains what the agent thought. A recovery package also identifies the committed artifacts, source versions, completed effects, remaining authority, and next eligible operation.

LangGraph's persistence documentation separates thread checkpoints from cross-thread stores and warns that in-memory checkpointers lose data on restart. Select storage that survives the failure you intend to recover from.

I would keep the durable run record compact and put large documents elsewhere. The record points to evidence; it does not embed an ever-growing transcript or duplicate every source file.

run_id: stable job identifier
spec_version: approved scope
status: running | waiting | paused | completed | cancelled
checkpoint_version: latest committed state
artifacts: identifiers, versions, checksums
verified_milestones: evidence and check outcomes
action_ledger: intended payloads and confirmed receipts
remaining_budget: spend, time, attempts, actions
pending_approval: payload version and expiry
next_operation: eligible step and preconditions

Download the editable run contract template as a starting point. It is a design artifact, not an executable supervisor or a built-in Pickaxe feature.

Write checkpoints atomically or transactionally, retain a last known good version, and apply access controls to artifacts and logs. Credentials belong in a secret store, not in the recovery package.

Resume by reconciling reality

When a run wakes, begin by checking the record against the world. A source document may have changed, an approval may have expired, or a tool may have completed an operation after the connection disappeared.

Verify the last saved artifact before depending on it. If its checksum or version differs, invalidate the dependent milestone and decide what must be regenerated.

Then reconcile unfinished actions using provider receipts, object identifiers, or a reliable lookup. An operation with an unknown outcome deserves a distinct status; labeling it “failed” can invite a duplicate write.

Recheck identity, permissions, the approved payload, and remaining budget before taking the next action. A saved approval is evidence of an earlier decision, not permanent authority for a revised destination or amount.

Use one active owner for each run. A lease or equivalent concurrency control prevents an old worker and a replacement from both continuing the job.

The storage and tool layers should reject writes from a superseded owner. Merely asking the old agent to stop cannot reliably protect against a delayed response arriving after a replacement starts.

Make retries safe for external actions

Read retries and write retries deserve different policies. Reading a document again usually costs time; sending the same message again or creating another invoice can create a business problem.

Stripe's idempotent request documentation provides a concrete, scoped example: retrying an operation with the same key can return the stored result, subject to its endpoint rules and key retention behavior. That protection does not automatically apply to a CRM or email tool.

Give a permitted write a stable operation identifier and record its intended payload before execution. Store the provider's receipt afterward, and keep that identifier across retries of the same intent.

If the destination supports idempotency, verify its actual guarantees and expiry. If it does not, use a supported deduplication or reconciliation mechanism; when you cannot establish the outcome, stop for human inspection.

Do not promise “exactly once” because a checkpoint exists. A crash between the remote write and the local receipt still creates uncertainty unless the external system and recovery process resolve it.

Keep a retry ceiling and distinguish transient failures from invalid inputs or revoked permissions. Repeating an unauthorized request with more confidence cannot make it legitimate.

Approve a specific proposed change

An approval should show what will happen: destination, payload, relevant source evidence, and consequences. The operator needs a concrete action to assess, rather than a vague request to let the agent continue.

Bind the decision to the proposed payload version. If the recipient, amount, content, or relevant facts change, the supervisor should decide whether fresh approval is required under the agreed policy.

LangGraph interrupts illustrate durable waiting for external input. Its documentation also explains that resumed nodes execute again, making side effects before an interrupt a duplicate-risk boundary.

Separate preparing a proposal, waiting for authority, and executing the approved action. A tool gateway should validate the recorded authority just before the write.

Our human oversight guide covers approval fatigue. I would reserve mandatory gates for meaningful consequences and use automated checks for repetitive, reversible work already within the agreed scope.

Give pending approvals an owner and an expiry outcome. Silence leaves the run waiting or stopped under its policy; it never becomes approval because a timer elapsed.

Put cancellation outside the agent

A usable kill switch changes authoritative run state and prevents new calls or writes. It must work when the agent is confused, stuck inside a tool call, or no longer reading instructions.

I would distinguish pause, which preserves a resumable job, from cancel, which closes it and requires explicit authorization to create a successor. Give the user a visible explanation of which one they selected.

The supervisor checks cancellation before dispatching work, and the action gateway checks it again before side effects. Where supported, cancel active provider jobs and revoke or expire the relevant run-scoped credentials.

Cancellation cannot undo an email already sent or guarantee that every in-flight remote call stopped. Reconcile those operations afterward and show confirmed effects separately from uncertain ones.

Test the operator path from the same interface a client would use. If stopping a run requires finding a developer with server access, the deployment has an operational dependency the client should understand.

Save a final cancellation checkpoint when possible, but retain a hard termination path for a hung worker. The recovery record should already be durable enough to survive that abrupt stop.

Watch progress as well as liveness

A heartbeat means a worker reported that it is alive. AWS Step Functions error handling treats a missing task heartbeat as a timeout condition; that signal alone does not establish useful work.

Track the last verified milestone separately from the last worker signal. A run can emit regular updates while repeating the same search or rewriting the same draft without improving it.

Also track external-action acknowledgments. “Submitted” in an agent message is different from a stored receipt confirming that the destination accepted the operation.

My preferred status update names the current milestone, the artifact saved, the remaining blocker, and the next decision. “Still thinking” tells the client little about whether intervention would help.

Set alerts around missed progress expectations, budget exhaustion, unknown write outcomes, and required human decisions. Keep routine healthy updates available in the run view without repeatedly interrupting the owner.

The watchdog needs its own health monitoring. A stopped supervisor can leave a job looking quiet and healthy, so check that the monitoring path itself is still running and authorized.

Choose a runtime that matches the failure

For a short, reversible task, an ordinary request-response integration may be enough. When interruption would discard valuable work, choose a durable job record and a way to resume it.

For a multi-step process with defined stages, a workflow engine can own persistence, retries, and waiting. For open-ended reasoning within a stage, let an agent work inside that bounded stage rather than handing it the entire business process.

A sandbox gives the agent somewhere to execute tools or manipulate files. You still need to establish whether its files survive replacement, how checkpoints leave the machine, and who owns continuation.

Ask for failure demonstrations before choosing infrastructure. Have the provider or builder show a restart, an expired credential, a duplicate start, and a cancelled write with the corresponding run evidence.

The agent harness guide explains the components behind those controls. The choice here should follow the workload's interruption and authority requirements, rather than whichever product advertises the longest session.

Use Pickaxe as the client-facing layer

For a client-facing service, I would use Pickaxe to collect the request, apply the agent's instructions and knowledge, and present the result. The long-running job can sit behind a narrowly scoped integration when it needs a durable supervisor.

Pickaxe Actions can connect agents to external tools and workflow platforms. The documentation distinguishes connections using the owner's account from those using each end user's account, which matters when a job accesses client systems.

Keep the boundary explicit: an Action submits a job and returns an identifier; an authorized status lookup retrieves its state; a separate permissioned path requests cancellation. Treat this as a proposed architecture that requires integration work.

I am not claiming that adding an Action creates native durable checkpoints, a run-wide budget gateway, or the cancellation contract described here. Verify those controls in the external runtime and the complete deployed flow.

Keep account isolation in the job service, too. A client-provided job identifier must not let someone inspect another customer's artifacts or cancel their work.

Worked example: a document audit that stops at review

Here is a proposed workflow for a fictional agency reviewing an approved folder of product documentation. The output is a source-linked draft identifying missing or conflicting claims; the agent cannot edit source files or send the report.

The agency first approves the folder, the output format, the source cutoff, and a named reviewer. The run records that scope and an overall expiry before fetching anything.

Its first milestone saves the document inventory and flags inaccessible files. Its second produces a claims table with source passages; its third prepares a draft only from verified or explicitly qualified claims.

Suppose an integration times out after saving the claims table. Recovery checks the saved artifact and receipt, then continues from drafting instead of reading every document again.

If a source changes during the interruption, the run revisits affected claims before drafting. If the reviewer asks for a new deliverable, that becomes a revised scope with its own budget decision.

The final handoff is a draft, source ledger, check results, and unresolved questions. This example describes a design proposal, not a customer deployment, measured time saving, or demonstrated success rate.

Pilot long-running AI agents by injecting failures

Before letting a run touch important records, try a small failure-injection pilot in a test environment. The following six categories, each tested both during active work and after a restart, give twelve proposed cases.

That count is a starting plan, not a validated sample size or a claim that passing guarantees safety. Expand it around the actual tools, permissions, and consequences.

Use the pilot checklist to record expected behavior before each trial. Keep failed cases visible; repeating a run until it passes does not erase the earlier failure.

Measure usable outcomes, operator review time, recovery overhead, duplicate effects, and total job cost. Those measures tell you whether the service helps the client, beyond whether the worker remained alive.

Questions buyers should ask

Does a bigger context window solve long-running work?

It can reduce how often context must be refreshed, but it does not preserve remote receipts or stop duplicate workers. Our agent memory guide covers how durable information differs from the model's active context.

How long should the agent be allowed to run?

Set the deadline from the deliverable, measured pilot costs, and consequences of delay. There is no universal duration that makes an agent dependable.

Can the client close the browser?

Only if the implementation accepts the job durably and lets the client reconnect to its status. Test that behavior explicitly; a streaming chat response alone does not prove it.

Should every step need approval?

Use the agreed authority boundary. Automate reversible work already authorized, and pause for consequential changes that require a specific human decision.

Can a cancelled job be resumed?

A pause can be resumable under its existing contract. Treat cancellation as a closed job, and create an explicitly authorized successor if the owner later wants to continue.

Start with one bounded job

I would begin with a draft-only workflow whose output someone can inspect. Give it a finish condition, a durable record, a hard budget, and a cancellation path before increasing its autonomy.

Then deliberately interrupt it and check the evidence. The important question is whether the next session knows what is verified, what is uncertain, and what it is allowed to do.

If you want to build the client interface, Pickaxe's agent guide is a useful starting point. Keep the deeper runtime contract visible so the service you sell has an operational owner as well as an impressive demo.