When Should an AI Agent Keep Working — and When Should It Deliver?

By Aojie (Justin) Yuan · October 2026 · ~6 min read

Ask an agent to “keep improving this until my meeting” and you have delegated a chain of decisions: what to check, when to verify, when to hand over a usable version, and whether more work is worth the wait. A bigger time budget widens what the agent may try; it does not say which attempts are worth it. This position paper asks how to tell whether an agent actually uses time well.

More time is a decision, not a gift

The paper calls the capability agent chronoception: estimating durations and using temporal evidence to decide what to do next. It is defined operationally. It is not a claim about an internal clock, and if a scheduler around the model does the work, the credit goes to the system. The goal it serves is useful persistence: keep working only while the permitted continuation still serves the user's contract, and deliver or stop when it doesn't.

Three requirements that must hold together

• Stability under equivalent changes. Writing the deadline in milliseconds instead of seconds should not change which test is worth running.
• Selective adaptation under consequential changes. If the full test suite suddenly becomes slow, a targeted check may now be better. If the service recovers, the conservative plan should be reconsidered.
• Temporal validity through deliberation and handoff. A budget read at one instant is not still available after the model has spent time thinking, and a helper agent must not silently restart the user's deadline.

Why punctuality and invariance are not enough

The paper builds an exact toy case. A full verification plan yields quality 0.90; a targeted plan yields 0.80. Utility is quality minus 0.02 per time unit, with a deadline of 10. The full plan takes 4 units when tools are fast and 9 when they are slow; the targeted plan always takes 2. Every plan meets the deadline.

• Fast regime: full = 0.82, targeted = 0.76, so run the full plan.
• Slow regime: full = 0.72, targeted = 0.76, so switch to the targeted plan.

A policy that always runs full verification is punctual and ignores unit changes, yet it loses utility whenever tools slow down. Choosing between the plans without looking at the regime costs at least 0.02 in average regret. Deadline success and invariance cannot, even together, separate a timing-blind policy from useful adaptation.

Punctuality, persistence, and fluent duration reports each provide incomplete evidence.

Decisions can expire while the model thinks

A plan has to be checked when it is dispatched, not only when the clock was read: the predicted work plus the integration reserve must still fit before the original deadline. In a 128-episode screen, 37 responses that chose to keep an already-delivered checkpoint arrived after the deadline. That is why the paper asks evaluations to report artifact availability, response latency, and dispatch feasibility separately.

What the small experiments show

• Slowdown and recovery screen: all 36 controller conditions were attempted; 34 gave valid timed outcomes and 2 conditional plans failed the schema. In every valid episode the chosen plan matched the regime. Model controllers delivered the same quality as an equally informed scheduler but were slower in all 22 matched comparisons (on average +2.68 s for replanning, +2.81 s for conditional planning).
• Three milestones under one clock (32 trajectories): when the service slowed and recovered, mean delivered quality was 1.00 for the immediate scheduler, 0.83 for a deliberately delayed scheduler, 0.75 for model replanning (4 late milestones), and 1.00 for conditional control.
• Exact grid of 972 authored states: always stopping misses 231 worthwhile continuations; ignoring decision time or restarting the clock at handoff admits 162 and 342 late continuations; a dispatch check removes lateness but still admits 183 continuations that are not worth it.

What the paper does not claim

This is a manuscript-only preprint, not peer reviewed. The tasks are short, authored workflows with prepared candidates and controlled delays, and the code and data release is pending. The results do not show long-horizon autonomy, learned duration forecasting, or a benefit from reinforcement learning. The paper lays out confirmatory tests that could reject its own position.

The practical takeaway

Evaluate the whole deployed system first, then find which component supplies the timing competence. Always compare an agent against an equally informed cheap scheduler before crediting the model. Keep a per-decision temporal record: the original contract, when evidence was observed and when the action was dispatched, the forecast, pending dependencies, and the artifact actually delivered. Score what reaches the user, not the best checkpoint picked in hindsight.

Frequently asked questions

What is agent chronoception?

An operational term for estimating durations and using temporal evidence to regulate action. It makes no claim about experience or an internal clock; if an external scheduler supplies the capability, the credit belongs to the system, not the language model alone.

What is useful persistence?

Continuing, revising, waiting, or delivering according to the value of feasible work under an explicit user contract. It includes timely delivery and justified stopping, so neither stopping early nor running longer is good or bad by itself.

Do LLM controllers beat a simple scheduler at this?

Not in the paper's screens. In the 34 valid timed episodes, model controllers delivered the same quality as an equally informed scheduler but took longer: about 2.68 s more for replanning and 2.81 s more for conditional planning, slower in all 22 matched comparisons. The authors present these as descriptive results on small, authored tasks.

Based on Agent Chronoception: Temporal Validity and Useful Persistence (Zenodo preprint, 2026, doi:10.5281/zenodo.23484052) by Aojie Yuan and Zijian Su. Written by Aojie (Justin) Yuan, USC Fortis Lab.