How should we evaluate an agent that works for days rather than minutes?

An agent that works for five minutes can fail in five minutes. An agent that works for three days can also accumulate stale assumptions, lose track of approvals, encounter changed tools, repeat completed actions and hand ambiguous state to a person. Duration creates more than a larger task. It changes the failure surface.

Short benchmark success should not be extrapolated into long-running reliability. Evaluation has to preserve state across time, introduce realistic interruptions and score the complete business outcome—not merely whether the agent was busy or eventually declared success.

Define horizon in workflow terms

“Long-running” can mean several things:

• many sequential reasoning and tool steps;
• elapsed time across waits, schedules or approvals;
• work resumed across processes or sessions;
• changing data, policies or external conditions; or
• a persistent objective that generates new sub-tasks.

These should not be conflated. An agent may execute 500 steps in an hour inside a stable sandbox, while a procurement workflow may take three days because it waits for suppliers and approvers. The second has fewer model turns but more temporal uncertainty.

METR’s task-completion time horizon estimates task difficulty using how long a human expert would take and reports the task duration at which an agent reaches a given success probability. METR explicitly cautions that this is not the literal time an agent can operate autonomously and that its task suite is concentrated in software engineering, machine learning and cybersecurity. Use such evidence to understand evaluation methods, not as proof that a model can manage every workflow of similar duration.

For an enterprise test, define horizon through milestones, elapsed events, permitted actions and final state.

Break the objective into observable commitments

Long tasks need intermediate evidence without prescribing every implementation step. Define milestones that represent durable progress:

Milestone	Observable commitment	Failure to detect
Scope established	objective, constraints and owner recorded	silent goal reinterpretation
Plan accepted	dependencies, risks and stop conditions visible	activity without feasible path
Work product advanced	artefact or external state meets checkpoint criteria	repeated or fabricated progress
Exception handled	issue recorded, decision made, plan updated	hidden degradation
Completion verified	authoritative outcome and negative checks pass	self-declared success
Handoff closed	next owner acknowledges usable state	abandoned or ambiguous work

Score checkpoint quality, not only presence. A saved plan that no longer matches the environment should not count as progress. A human approval must bind to the current proposal. A test suite that passed before later changes is not completion evidence.

Milestones also make failures diagnosable. The evaluator can distinguish planning failure, state loss, tool misuse, poor recovery and invalid verification rather than recording one final zero.

Evaluate durable state and resumption

Conversation history is not sufficient state for a multi-day workflow. The system needs a durable record of objective, completed effects, open commitments, approvals, current artefacts, dependency versions and next safe action.

Interrupt the agent deliberately:

• terminate and restart the worker mid-step;
• expire the context window or remove transcript segments;
• delay an external response;
• rotate a credential;
• deliver duplicate or reordered events;
• resume on a new runtime version; and
• require another agent or person to continue.

After resumption, test whether the system reconstructs state from authoritative records, not model recollection. It should distinguish “planned,” “attempted,” “accepted,” “committed,” “verified” and “unknown.” An unknown write result should trigger reconciliation before retry, protecting against duplicate effects.

Change the world while the agent works

Long-running workflows operate in a moving environment. Prices change, documents receive edits, policies are superseded, permissions expire, users revoke requests and downstream systems degrade. Evaluation should schedule these changes after the initial plan.

Useful scenarios include:

• a source document is updated and the old version remains retrievable;
• an approval is revoked before execution;
• a tool schema or error meaning changes;
• a higher-priority event conflicts with the standing objective;
• a collaborator edits the same artefact;
• a deadline or budget approaches; and
• a previously valid action becomes prohibited.

The desired behaviour may be replan, seek approval, reconcile, degrade or stop. Define it beforehand. If the evaluator invents the acceptable response after seeing the run, results will be hard to compare.

The NIST AI RMF Core calls for testing in conditions similar to deployment, monitoring functionality and risk in production, and implementing change-management, incident-response and recovery plans. Long-horizon tests are where those lifecycle expectations meet the runtime.

Measure capability across budgets

Long tasks consume tokens, tool calls, wall-clock time, money and human attention. A fixed budget may hide capability; an unlimited budget may hide inefficiency or uncontrolled persistence.

The UK AI Security Institute reports that observed agent capability can change with test-time compute and recommends viewing capability as a curve over budget rather than one score (AISI analysis). Its published findings are strongest for cyber and software-engineering tasks, so broader generalisation remains uncertain. The design lesson is robust: state the resources an agent had, and test more than one relevant budget.

Report:

• verified success rate at each budget;
• time and resources to reach each milestone;
• quality and cost of recovery;
• repeated or unnecessary actions;
• human interventions and their duration;
• prohibited effects and near misses; and
• unfinished runs classified by reason.

Do not reward an agent merely for continuing. A system should stop when expected value falls, authority expires or uncertainty becomes material.

Use repeated runs and varied task families

Non-determinism compounds across steps. One success on one long scenario is an anecdote. Run repeated trials across task variants with the same decision structure but different surface details.

An academic survey of agent evaluation identifies gaps in cost-efficiency, safety, robustness and realistic, continuously updated benchmarks. AISI’s international agentic testing exercise likewise reports that traditional methods are insufficient for complex autonomous behaviour.

Build a suite with:

• routine but long tasks;
• rare exceptions;
• adversarial content;
• ambiguous or impossible objectives;
• dependency failures;
• interrupted and resumed runs; and
• scenarios where safe refusal is correct.

Use algorithmic checks for state where possible and domain reviewers for judgement-heavy artefacts. Blind reviewers to the agent version when feasible. Retain traces and environment snapshots so surprising outcomes can be reproduced.

Test human handoffs as terminal states

Long-running agents will eventually need clarification, approval, specialist judgement or incident response. A handoff is not successful when the agent sends a notification. It succeeds when the receiving person can understand the objective, current state, evidence, open risk and requested decision without reconstructing the whole run.

Evaluate whether the handoff includes:

• concise objective and scope;
• actions already taken and verified effects;
• unresolved questions and uncertainty;
• relevant artefacts with provenance;
• time, cost and authority remaining; and
• the exact decision or action requested.

Then require acknowledgement and safe pause. An agent that continues changing state while waiting for approval has not handed off control.

Release a bounded horizon, not indefinite autonomy

Translate results into an operating envelope: maximum elapsed time, steps, spend, concurrent sub-tasks, permission duration and unattended interval. Define checkpoint frequency, required human review and automatic stop triggers. Test the kill and recovery paths under load.

Production monitoring can reveal new task variants, but it should not turn customers into unconsented evaluators. Sample privacy-safe traces, investigate threshold breaches and promote verified failures into the regression suite.

A long-horizon agent is not a short-task agent with a larger context window. It is a stateful service operating through change. Evaluate the commitments it preserves, the effects it verifies and the conditions under which it knows to stop.