Monday 06:00 - scheduler
The weekly stock report is built and filed before anyone is awake, because a clock fired, not because someone asked.
Buyer's guide
Always-on AI agents: what 24/7 actually requires
"Always on" is doing a lot of work in most product copy. Sometimes it means the website is up. Sometimes it means an agent will answer if you message it. Occasionally it means what a buyer actually wants: that work happens while nobody is watching. This is a checklist for telling those apart - written so it is useful even if you end up choosing something else.
Five mechanisms, five separate questions
Unattended operation is not one feature. It is five, and a platform can have four of them convincingly and still leave you with a gap that only shows up in month three.
A scheduler. Work that fires on a clock - hourly, daily, every Monday. Ask what granularity it supports and, more usefully, what happens to a run that is missed. The honest answer from most systems is "nothing", and knowing that up front changes how you design around it.
Standing instructions. Conditions checked on an interval rather than at a fixed time: watch for this, tell me if that. The question to ask is how often the check runs, because "continuously" is almost never true and the real answer is usually minutes.
Background workers. Work the agent starts on its own initiative and continues without a conversation attached. This is the one most chat-shaped products do not have at all.
Work-item pickup. A queue of assigned tasks the agent collects rather than being handed. It is what makes an agent a member of a team instead of a tool someone operates.
Live channels. Connections held open to the places messages arrive. If a customer writes at midnight, something has to be holding that connection.
The question nobody asks in a demo
Does the work survive the connection that started it?
In a lot of products, a task is running inside the page you started it on. Close the tab, lock your phone, walk into a lift and lose signal, and the work stops - not because it failed, but because its lifetime was the socket's lifetime. This is invisible in a demo, where nobody closes anything, and it is the difference between an agent you can start something with and an agent you can hand something to.
Ask it directly: if I start this on my phone and my phone locks, what happens? The good answer is that the run is detached from the viewer, that reconnecting replays exactly what you missed, and that there is an explicit Stop control - because if closing the window no longer stops the work, something else has to.
Four limits any honest vendor will name
Approvals are a hard stop. A well-governed agent waits for a human before anything irreversible. That is a feature, and it also means autonomy has a ceiling by design. If a vendor claims unlimited autonomous operation and strong approval controls in the same breath, one of the two is decorative.
Background work is budgeted. An agent working unattended runs against a step budget and a wall-clock limit, both adjustable. Without them, a confused loop runs until someone notices, which is a worse failure than stopping early.
Standing instructions are minutes, not seconds. Polling granularity is a real constraint. For "tell me if a customer is unhappy" that is irrelevant. For anything trading-shaped it is disqualifying.
Usage is metered. An agent that works all night is using model capacity all night. Whatever the pricing shape, unattended operation has a cost curve, and the useful thing is to be able to see it rather than to be promised it is free.
Turning it off
The counterpart to autonomy is a switch, and it should exist at more than one level: off for the whole fleet, off for one agent, and - the case people forget - on for one agent when the fleet default is off. Overrides that only work in the restrictive direction are not really overrides.
The checklist
Take these to any vendor, including us. Does a schedule exist, and what happens to a missed run? How often are standing instructions checked? Can the agent work with no conversation open? Can work be assigned to it? Does a run survive the browser closing, and can I see what I missed? What are the step and time budgets, and can I change them? What waits for a human, and who counts as a human? How do I turn all of it off, per agent and fleet-wide? What does a busy night cost?
A vendor who answers all nine without hedging is worth taking seriously. A vendor who answers "yes" to the first and treats the rest as details has a demo, not a service.
How the five mechanisms show up in a week
One agent, no human present for most of it.
Tuesday 14:20 - standing instruction
A supplier email mentions a delay. The condition was being polled, so it surfaces the same afternoon rather than at the next review.
Wednesday 23:40 - live channel
A customer asks on WhatsApp whether an order shipped. The connection was held open, so they get an answer, not a callback form.
Thursday - work-item pickup
A colleague assigns a research task. The agent collects it on its own poll rather than waiting to be prompted.
FAQ
What does "always-on" actually mean for an AI agent?
At minimum, that five separate things are running with no human present: a scheduler for clock-driven work, standing instructions polled on an interval, background workers for self-directed tasks, a queue the agent collects assigned work from, and live connections to the channels messages arrive on. A product can have some of these and not others, so it is worth asking about each.
Can an AI agent work overnight without me?
Yes, within limits worth knowing. It will stop at any action configured to need human approval, and background work runs against a step budget and a time limit rather than indefinitely. Those are deliberate: the alternative is an agent that loops until someone notices.
What happens if I close the browser while an agent is working?
On a well-built platform, nothing - the run is detached from the connection that started it, and reconnecting replays what you missed, tool calls and results included. That also means closing the window is no longer how you stop something, so there has to be an explicit Stop control. Ask about both together.
How do I stop a runaway agent?
Three ways, and a platform should offer all of them: an explicit Stop on the run itself, budgets that end it on their own, and approval gates that hold it before anything irreversible. You should also be able to disable autonomous operation per agent and across the whole fleet.
Does an always-on agent cost more to run?
Yes - an agent working while you sleep is using model capacity while you sleep. That is the point of it, but it means the useful question is not whether it costs more, it is whether you can see the cost per turn and cap it before a surprise arrives at the end of the month.
Related reading
Where to go next.
Local vs cloud AI agents
Where unattended work becomes impossible on a machine you carry.
What stops when you close your laptop
The failure modes, diagnosed one at a time.
Docs: approvals and trust
How trust levels and approval categories are configured.
Docs: automation
Scheduled tasks and monitoring, in reference form.
The budgets described here are adjustable defaults rather than fixed figures, and they can be changed fleet-wide or per agent. Checked 13 September 2026.
Nine questions, one call.
Bring the checklist. If a workflow of yours does not need any of it, we would rather tell you that than sell you a deployment to run something a spreadsheet could handle.