Notion raised the longest single unattended task its agents will take from five minutes to more than twenty-four hours — a factor of about 288 — and nothing in the announcement is a model change. The ceiling moved because the company rebuilt where the run lives: a dedicated service with a queue-backed worker loop that survives restarts, a thread that condenses as it grows, and large tool results set aside instead of carried. If you are waiting for a frontier release to make day-long agents possible, you are waiting for the wrong thing; the number you can actually sell is a property of your harness.
At a glance
Everything below is from Notion's own announcement and help centre, dated 19 October 2026. No independent measurement of any of it existed at the time of writing.
| What changed | Before | After | Mechanism named |
|---|---|---|---|
| Longest single unattended task | 5 minutes | More than 24 hours | Dedicated service, queue-backed worker loop, survives restarts |
| Long-run context handling | Not described | Condensing + set-aside | Conversations condensed; large tool results set aside |
| Oversight of a long run | Human, inline | "Review for me" | A separate model checks actions and flags ones to approve |
| Billing unit | Prior Notion AI plan | Standard + Select credits | 1,500 routed + 500 user-choice per Business/Enterprise seat |
Reporting on the release calls it the sixth generation of the harness. That detail matters more than the hour figure: six rebuilds of the scaffolding around a model is what a 288× change in unattended duration actually took, and none of those rebuilds is something you could have bought from a model provider.
Why five minutes was the old ceiling
A five-minute cap is not a statement about a model's stamina. It is the signature of a turn that executes inside a request — an HTTP request, a serverless invocation, a websocket session — where the platform's own timeout is the hard stop and the work has nowhere to be if the process goes away. Nothing about the model knows or cares that five minutes elapsed. The constraint belongs entirely to the thing holding the loop, which is the point the agent harness keeps making: the scaffolding has properties the weights do not.
What Notion describes replacing it with is the standard answer, and its standardness is a feature. Each session runs on a dedicated service. The task goes on a queue. A worker loop takes one step at a time and writes its progress somewhere that outlives the worker, so a restart resumes rather than restarts. That is durable state and resumability, and it is the same shape as the durable-execution engines covered in LangGraph plus Temporal — a workflow whose steps are replayable against a log.
The thing worth copying is not the architecture, which was already well understood. It is the recognition that the unattended ceiling was never a capability question in the first place, so the engineering that moves it is ordinary distributed-systems engineering with a well-known cost: once steps replay, every side effect the agent can perform has to be idempotent, or a resume turns one email into two. Idempotency and retries is the bill for durability, and it comes due the day you ship the worker loop, not the day the first replay happens.
Three mechanisms, three different bills
The release names all three, and reading them together is more informative than reading any one of them. Durability buys you a run that survives infrastructure and charges you idempotency. Context handling buys you a run that fits in a window and charges you fidelity. Oversight buys you a run nobody watches and charges you the error rate of whatever is watching instead. The 24-hour number is the product of all three, and a team that ships only the first gets a durable agent that degrades quietly into incoherence somewhere around hour three.
The context bill is the one most often underestimated, because its failure is not an error. "Condensing conversations" and "setting aside large tool results" are the two levers in context compaction and shaping tool results, and both work by throwing information away on purpose. Twenty hours into a run, the agent is not reasoning over what happened; it is reasoning over a summary of a summary of what happened, and the specific detail it needs — the exact error string from hour two, the one row that did not match — is precisely the kind of thing a condenser drops as noise. Forgetting and supersession is about doing this deliberately rather than as a side effect of a token budget.
Which gives the measurement nobody publishes, including here: not whether an agent can run for 24 hours, but whether its answer at hour 20 is better than its answer at hour 2. A long run that compacts aggressively can be worse than a short one, and the only way to know is to score the same task at both horizons on your own work. Notion published no customer-level data on task quality or typical credit consumption alongside the duration claim, which is the normal state of affairs for this kind of announcement and is why the duration figure should be read as a capability of the runtime rather than a promise about outcomes.
The horizon you can sell is not the ceiling you can run
A ceiling says the run will not be killed. It says nothing about whether the run succeeds, and the gap between those two is where most disappointment with long-horizon agents lives. Task horizon is the unit that keeps them apart: the length of job an agent finishes on its own at a stated success rate. The headline numbers in that literature are 50% horizons — a coin flip — and the reliability you would actually deploy against, around 80%, runs roughly five times shorter.
So a product that will keep a task alive for 24 hours has told you about the denominator and nothing about the numerator. The arithmetic is unforgiving in exactly the way it always is: a task long enough to need a day is a task with hundreds of steps, and hundreds of steps at even 99% per-step reliability is a coin flip overall. Durability does not fix that; it only guarantees that the failure, when it comes, will be the agent's and not the platform's. That is a real improvement — a lost run tells you nothing, where a completed-but-wrong run is at least diagnosable — but it is a different improvement from the one the headline suggests.
The practical read: treat a vendor's duration ceiling as a constraint that has been removed, not a capability that has been added. Then go and measure your own 80% horizon on your own tasks, because that number is what you can promise a customer, and it did not change on 19 October.
Nobody is watching, so something else has to be
A 24-hour unattended run breaks the oversight model that every approval UI assumes, which is that a human is nearby. Notion's answer is "Review for me": a separate model inspects the agent's actions and surfaces for approval the ones it flags as potentially unsafe. This is the same move as Claude Code's auto permission mode, where a classifier reviews each action, and it is the same move as the risk-scaled agent controls Microsoft announced on the same day, which narrow what an agent may do as its assessed risk rises.
The convergence is not a coincidence — it is what you are forced into once the run outlives the attention span of the person who started it. It is also a genuine advance over a session-global permission toggle, because a classifier can make a per-action judgement that a single setting cannot. Progressive autonomy works through why that gap exists and where the rung should actually live.
But be precise about what has been purchased. A reviewer model converts an explicit policy decision into a prediction with a false-negative rate, and from that moment the reviewer's miss rate is your safety margin. That demands the treatment any detector gets — a confusion matrix measured on your own action distribution, a threshold chosen against the asymmetry between a wrongly-approved payment and a wrongly-blocked file rename, and drift monitoring as the action mix changes. Risk-scored permissions covers the operational version, and repairing agent side effects covers the part of the day-long run that the reviewer missed.
The meter changed in the same release
The duration announcement arrived alongside a new billing unit, and the pairing is not accidental: a product that can spend 24 hours on one task needs a spend ceiling that does not depend on anyone watching. Business and Enterprise seats now carry 1,500 Standard credits a month for work where Notion's router picks the model and 500 Select credits for work where the user picks one or runs a custom agent. Credits reset monthly, do not roll over, and cannot be pooled or transferred between members. Existing customers moved on 2 November.
What is not published is the exchange rate. No credit-to-token or credit-to-task conversion appears anywhere, and the router that decides which model serves your task — and therefore how many credits it burns — is the vendor's. That combination means the supplier sets both terms of your bill. The company's pitch for the router is that it matched Opus 5.5 and Astra at roughly 90% lower average cost across more than twenty common use cases; its own help centre states the figure as 87% lower than Opus 5.5. Both are vendor tests, and the three-point gap between two first-party statements of the same saving is a reasonable estimate of how precisely anyone outside can reconstruct this.
The usable response is to measure credits per completed task on your own traffic and keep the series, which is the whole argument of agents priced in credits. One structural consequence deserves naming here because it bites on exactly the workload this release enables: with no pooling and no rollover, a 24-hour run by one power user draws down that seat's allowance alone. Size each seat against its own peak, not the team's average, or your heaviest users hit a wall in the last week of the month while everyone else's balance expires unused.
What to copy, and what to skip
| If your ceiling is… | The actual constraint | Do this first |
|---|---|---|
| Minutes | The run lives inside a request | Move the loop to a worker with durable state; make side effects idempotent before you do |
| An hour or two | The context window, not the platform | Condense deliberately and set aside large tool results; score the task at two horizons |
| A day, but quality drifts | Compaction is dropping what matters | Pin the facts the task depends on outside the thread; stop compacting those |
| A day, and nobody watches | Oversight, not duration | Add a reviewer and measure its false-negative rate before trusting it |
And one thing to skip: do not reach for more agents. The instinct when a task is too long for one run is to split it across several, and the coordination tax usually exceeds the benefit — subagents and the multi-agent material on this wiki both land on the same conclusion. A durable single loop is the cheaper fix for duration, and it was the fix Notion reached for too.
FAQ
Did a new model make 24-hour agent runs possible?
Nothing in Notion's 19 October 2026 announcement attributes the change to a model. The mechanisms it names are a dedicated service with a queue-backed worker loop that survives restarts, conversation condensing, and setting large tool results aside — all runtime engineering.
Is it 24 hours or more than 24 hours?
The company's two statements differ: the announcement blog says agents can work a single task for more than 24 hours, while the release notes say up to 24 hours. Treat it as "about a day" and note that both figures are a ceiling on duration, not a success rate.
Does a longer ceiling mean the agent is more reliable?
No. A ceiling guarantees the run will not be killed by the platform; it says nothing about whether the run succeeds. The number that predicts a deployment is the task horizon at a reliability you would accept, typically around 80%, which runs roughly five times shorter than the 50% figure usually quoted.
What does a day-long run cost under the new credit system?
Notion publishes no credit-to-task conversion, and its router decides which model serves each step, so the credit cost of a given task is not derivable from the outside. Measure credits per completed task on your own workload and keep the series.
What breaks first when you extend an agent's run?
Usually side effects, then coherence. Once a worker can resume, steps replay, so any non-idempotent action can happen twice. After that the limiting factor is compaction: the agent late in a long run is reasoning over a summary, and the detail it needs may already have been dropped.
Further reading
On this wiki:
- Task horizon — why the 50% figure is a coin flip and the 80% one runs five times shorter.
- Durable state and resumability — the pattern the ceiling change is built on.
- Idempotency and retries — the bill durability sends you.
- Context compaction — what condensing a long thread actually throws away.
- Agents priced in credits — measuring a bill whose unit you were not given.
- Progressive autonomy — where the rung belongs when the session dial cannot express it.
- Long-lived sessions and deploys — shipping code under a run that outlives the deploy.