By MD Jehad H.·October 1, 2026·4 min read·Operator playbook

OpenAI's always-on agents need an off switch too

Drafted through my n8n + AI pipeline, edited by me.

Dots, OpenAI's new agent feature announced at DevDay on September 29, run on their own dedicated computer instead of waking up only when you ask them to. They hold state, keep a browser open, and stay connected to OpenAI's app ecosystem around the clock. For a small business owner, that is a real change from the automations you run today, and it changes what you need to check before turning one on.

What OpenAI actually announced

At DevDay, OpenAI introduced Dots as an always-on agent inside ChatGPT. Each Dot gets a persistent compute instance, its own browser, and local state that survives between sessions, so it can pick up a task, work on it in the background, and come back with results without you re-opening a chat. OpenAI also shipped GPT-6.1 Sol, a cheaper model built for exactly this kind of long-running, agentic work, priced at roughly a fifth of its top-tier Astra model for comparable agentic coding and computer-use tasks.

The real shift: always-on agents versus a scheduled automation

Most of what small businesses run today, whether that is an n8n workflow, a Zapier zap, or a Make scenario, fires on a trigger, does one job, and stops. Nothing is sitting there holding your QuickBooks login or your inbox open between runs. An always-on agent is different by design: it keeps a session alive, keeps credentials loaded, and keeps working even when nobody is watching the screen. That is the entire selling point, and it is also the entire new risk surface.

	Trigger	Runs when	Credential exposure	Who reviews output
Scheduled automation (n8n, Zapier, Make)	Event or schedule	Seconds to minutes, then stops	Open only during the run	You, after it finishes
Always-on agent (Dots)	You assign a goal, once	Continuously, in the background	Open for the life of the session	Whoever remembers to check back

A scheduled workflow holds credentials for seconds. An always-on agent holds them indefinitely, which is the tradeoff you're actually buying.

What to actually do before you turn one on

1
Pick a task with no money attached
Research, drafting, monitoring, and summarizing are fine first jobs. Invoicing, payments, and anything that touches a bank or card connector should wait until you have watched an agent work for a few weeks.
2
Scope the connected apps to exactly what the task needs
OpenAI's agent ecosystem reaches thousands of connected apps. Connect only the two or three the task actually requires, not your whole stack, the same way you would scope an API key.
3
Set a review checkpoint, not just an end state
Because the agent keeps running, give it a check-in point, daily or per-task, where it reports what it did before it goes further. Don't wait for a final output to see the first problem.
4
Put someone's name on it
An agent that runs unattended still needs an owner who gets the alert if it stalls, loops, or does something unexpected. Assign that person before you assign the task.

The credential question doesn't go away

A session that never closes is a session that never has to re-authenticate. If a Dot is connected to your email, your CRM, and a payment tool at the same time, that is three live credentials sitting open for as long as the agent is running, not just during a single automation step.

None of this replaces your scheduled workflows. A lead-capture automation or an invoice follow-up still belongs in n8n, Zapier, or Make, where the job starts, finishes, and the credentials close. Always-on agents make more sense for the open-ended work that doesn't fit a trigger: watching a market for changes, drafting replies to a backlog, or keeping a research doc current. Start there, not with the task that touches your books.

Does a Dot cost more to run than a regular automation?

Yes, by design. A persistent compute instance that stays on costs more than a workflow that runs for seconds and stops, and OpenAI's own pricing for the cheaper Sol model still assumes far more usage per task than a triggered automation.

Can I just try it on something low-stakes first?

That's the right instinct. Give it a single, reversible, non-financial task for two or three weeks and watch how it behaves before connecting anything that touches money or customer data.

If you're weighing whether an always-on agent belongs in your stack or whether a scheduled workflow already does the job better, send me what you're trying to automate and I'll help you figure out which one fits.

Building something this should run inside?

Book a systems call

Keep reading