When an agent can work for 24 hours: checkpoints, budgets and handoffs
Notion says its agents can now work on a single task for up to 24 hours. Here is how to design the operation around a long-running agent so it stays controllable.
On 19 October 2026 Notion announced a rebuilt agent harness and said its agents "can work on tasks for up to 24 hours." A task that runs for a day is no longer a chat; it is a shift. And a shift needs the same things any shift needs: a brief, checkpoints, a budget, and a handoff. This article is a vendor-neutral way to design them.
What changed, and what did not
Notion's release also says agents now have their own computer and browser, better context management and a "Review for me" mode with safety checks, and that its Auto router matches each task to a model. The release gives no detail on how those pieces work, and its cost claim ("about 90% lower average cost" across 20+ tasks, compared with two named models) applies only to the tasks Notion tested. We use the announcement as a signal, not as a benchmark.
The signal is clear: agent runs are getting longer. Anything that runs for hours can drift, loop, spend, or act on stale information. None of that is solved by a better model alone; it is solved by how the operation around the agent is built.
- 01Written briefGoal, limits, definition of done
- 02Work in slicesShort units with a saved state
- 03CheckpointJournal entry and budget check
- 04Human gateOnly for the risky actions
- 05HandoffResult, open items, next owner
If a checkpoint fails, the task pauses and goes to its owner.
Step 1: a brief the agent cannot reinterpret
A long task magnifies a vague instruction. Write the brief as a short procedure:
- Goal and definition of done: what the finished work looks like, in checkable terms.
- Limits: systems the agent may read, systems it may write to, actions it may never take.
- Escalation: the situations where it stops and asks, and whom it asks.
Step 2: work in slices with a saved state
Do not let a 24-hour task live in one continuous context. Break it into slices (a batch of records, one customer, one document) and write the state after each: what was done, what is pending, what was decided and why. That journal is what lets the task resume after an error, be audited afterwards, and be handed to a person or another agent without rereading everything.
Step 3: checkpoints with a budget
At every checkpoint, check three things automatically:
- Progress: did the number of finished items move since the last checkpoint? No movement twice in a row means stop.
- Spend: time, credits or API cost against the limit set in the brief.
- Scope: did the agent touch anything outside the systems the brief allowed?
A failed check pauses the task and notifies its owner. It does not retry silently.
Step 4: put the human gate on actions, not on time
"A person reviews every hour" does not scale. Gate the irreversible or external actions instead: sending a message to a customer, changing a price, paying, deleting. Reads and drafts run freely; those actions wait for approval or follow a rule written in advance. Features like a review mode help, but the list of what needs review is an operating decision, and it belongs to the owner of the workflow.
Step 5: end every run with a handoff
The last output is not "done". It is a record: what was completed, what was skipped and why, what needs a person, and where the journal lives. If the next step is not written, the agent has created work for someone without telling them.
What to do this week
Pick one agent task that already takes more than an hour. Write its brief, its three checkpoint checks and its list of gated actions on one page, and run the next instance against that page. If you cannot name the owner who receives the handoff, the task is not ready to run for 24 hours, whatever the vendor says it can do.