Always-On AI Agents: Who Approves the Run at 3am?

An always-on AI agent is one whose runs can start without you. A schedule starts it, an event in a connected app starts it, or it decides on its own that something is worth doing while you are asleep. That is a change in the trigger, not a promotion to a higher autonomy level.

What surprises people is what happens to approval. An approval prompt needs somebody to answer it. Remove the human from the room and the prompt does not queue up politely, it stops existing. Anthropic writes this down for its scheduled runs: routines "run autonomously as full Claude Code cloud sessions: there is no permission-mode picker, and the session runs shell commands, uses skills committed to the cloned repository, and calls any connectors you include, all without stopping for approval apart from some artifact actions" (Claude Code routines, research preview).

So the question in the title has a dull answer. You did, when you saved the trigger.

What makes an agent always-on

Four things can start a run, and only the first one involves you being present.

1. A human message. The default since the first chat interface. The agent runs while you watch.
2. A schedule. A cron expression or a preset cadence fires the same prompt again.
3. An event. A pull request opens, an email arrives from a named sender, an alert crosses a threshold.
4. The agent itself. It decides, with no trigger you wrote, that something is worth looking at.

Only the fourth is new, and only one shipping product documents it. OpenAI calls it proactive research: "When you are not actively working with your dot, it looks for ways to help in the background." The guardrail is the interesting part. That background work "accesses the apps you already connected using read-only restricted tools", so it cannot send messages, change app content, or control your browser or computer (Introducing dots, 29 September 2026).

Read-only self-initiated work, write access only on a trigger you wrote. That is the shape of the safe version, and it is worth copying if you build your own.

What shipped on 29 September 2026

Two products added always-on behaviour on the same day.

OpenAI dots. A dot is "an always-on agent in ChatGPT that can take on ongoing responsibility and keep making progress between conversations", running on GPT-6 Astra with its own cloud computer. Access to your local machine is optional and starts turned off. OpenAI's help centre names three ways a run starts without a new message: background research, proactive review of connected information, and scheduled reminders or recurring tasks (Getting started with your dot).

Availability is narrower than the announcement suggests. Dots are rolling out to Pro users in markets excluding the European Economic Area, Switzerland and the UK, and to Business Premium users across all supported ChatGPT regions. Enterprise, Edu and Healthcare can try a beta once a workspace admin turns it on, and it is off by default. The first dot is included in Pro or Business Premium at no extra cost, with an allowance for deeper work and extended limits for the first month after launch. OpenAI has not published a price for additional dots.

Perplexity Computer Automations. Automations replace Scheduled Tasks and add event triggers plus memory of previous runs. Computer can run "on a schedule or when a specified event occurs in Slack, Gmail, Outlook, Linear, or GitHub", narrowed by conditions such as an email from a particular sender that asks for a decision (Computer adds Automations, 29 September 2026).

One detail in that post is the most honest pricing statement in the category: "Automations don't use credits when Computer is watching for a trigger. Credits are spent only when Computer runs an assignment." Watching is free, acting is metered. Perplexity does not name a plan price for Automations, only that they are available to Computer users.

Always-on does not mean more autonomous

Autonomy is what an agent may do once it is running. Always-on is what starts it. They are different axes, and the category keeps collapsing them into one.

They do travel together, for a mechanical reason rather than a philosophical one. A run with no audience cannot stop and ask. So every vendor shipping always-on work has moved the approval decision earlier, from the run to the configuration.

Each does it differently. A dot takes per-action rules: you describe an action, then pick one of four behaviours, Take action without asking, Take action if pre-approved, Ask before taking action, or Hand off to you. "Pre-approved" has a specific meaning there: you explicitly requested the action in your prompt. Perplexity asks you to "specify which actions Computer can take on its own and which need human review" when you write the assignment. Claude Code routines do not ask at all; the approval surface is the configuration form, and the docs say so directly: remove the connectors a routine does not need, because "Claude can use every tool from an included connector, including writes, without asking for permission during a run".

That last line is the whole post in one sentence. The permission boundary for an always-on agent is not a prompt. It is the list of repositories, the network policy and the connector list you picked once.

Every placement in that table comes from a directory listing, each one verified against the vendor documentation linked above on the date printed on the listing page.

The MCP problem: input_required with nobody home

This is the part that will bite developers first, and I have not seen it written down anywhere.

Revision 2026-07-28 of the Model Context Protocol replaced held-open bidirectional streams with multi round-trip requests. When a server needs something from the user mid-call, it returns an InputRequiredResult carrying an elicitation/create request, and the client retries the original call with the answers attached in inputResponses (elicitation specification).

The client has exactly three replies: accept, decline or cancel. Accept means a user approved and submitted. Cancel means the user "dismissed without making an explicit choice". There is no fourth action meaning "nobody was here".

For URL mode the wall is explicit. Clients MUST NOT open the URL without explicit consent from the user, MUST show the full URL for examination before consent, and MUST open it so that neither the client nor the model can inspect the content or the user's input. An unattended run at 3am cannot satisfy any of those. It cannot consent on your behalf, and a client that does so is violating the specification, not being helpful.

The specification already anticipated this: servers "SHOULD NOT assume that elicitation requests will always succeed, and MUST handle cases where the user declines or cancels".

Three practical consequences, if you connect MCP servers to a scheduled agent:

• Treat input_required as a stop, not a retry. Return cancel, end the run, and surface it. A retry loop against a server that wants a human will burn tokens until the limit stops it.
• Move third-party auth out of the run. URL mode exists for OAuth and credentials. Complete those flows interactively, before the first scheduled run, so stored tokens are already bound to your identity.
• Audit which of your servers can elicit at all. A server that never needs input is safe to schedule. One that elicits on a cold cache is a scheduled failure with extra steps.

If the revision itself is new to you, what still talks to what after MCP 2026-07-28 covers the compatibility matrix behind this change.

If you are building one yourself

The frameworks give you the loop. The trigger is yours to supply, and that is where the cost lives.

LangGraph Platform ships crons as a first-class primitive: pass a cron expression to the Crons client, and "on the specified schedule, the server will: Create a new thread with the specified assistant [and] Send the specified input to that thread". Stateless crons open a new thread per execution, thread-specific crons reuse one. Cron jobs "are run in the background and do not interfere with normal invocations of the graph" (LangChain cron jobs).

The same page carries the warning every always-on build eventually earns: "It is very important to delete Cron jobs that are no longer useful. Otherwise you could rack up unwanted API charges to the LLM!" A forgotten trigger is not idle. It is a subscription you stopped reading.

Two more things an unattended agent needs that an interactive one borrows from you. It needs a browser that is not your browser, which is why dots run their own cloud browser and why managed browser infrastructure such as Browserbase exists for teams building the equivalent. And it needs a desktop surface if the work is not browser-shaped, which is the job OpenAI Computer Use does at the API level.

What to check before you switch on a trigger

Six checks, in order, and none of them takes long.

1. Name the trigger type out loud. Schedule, event, API call, or self-initiated. If you cannot say which, you do not know when this thing runs.
2. List what it can reach, not what it will do. Repositories, connectors, network allowlist, connected apps. The prompt is a wish. The configuration is the permission.
3. Find the pause control before the first run. Dots pause from the profile menu, Claude Code routines from an on/off switch, Automations from the Automations surface. Find it while you are calm.
4. Check what happens when an MCP server asks for input. See above. The honest answer is a stopped run and a notification.
5. Work out the idle cost and the run cost separately. Perplexity publishes that watching is free. Most do not. A cron job on a managed platform bills per run whether or not the run was useful.
6. Read one full transcript before trusting the status light. Anthropic's own docs warn that a green run status "means the session started and exited without an infrastructure error. It does not mean the task in your prompt succeeded."

The four-behaviour model dots use is the right mental model even on platforms that do not offer it. For every action your agent can take, decide in advance: on its own, only if asked, ask first, or never. Write that list before the trigger, because after the trigger there is nobody to ask.

Start with the autonomy level of whatever you are about to leave running. Every entry in the agent directory carries its autonomy, environment and ecosystem placement plus the date somebody last opened the vendor's docs, and Claude Code is the listing to read first if a scheduled coding agent is what you have in mind. For the permission question underneath all of this, is Claude Code auto mode safe covers what a classifier can and cannot see while a run is in flight.