Always-On Agents

Always-On Agents are the new shiny toy in AI.

Pretty much every major AI platform is working on its own version of that. Back in November 2025, the project that later became OpenClaw went viral by showing what a persistent personal agent could look like. Microsoft introduced Scout, now called Autopilot. xAI followed with Grok Bot, Meta with Muse, and OpenAI introduced Dots during its latest DevDay.

From a capability perspective, Always-On Agents are the next step in the delegation curve that started with chatbots:

Chat → get an answer

Work → get an outcome

Always-On → keep an ongoing goal on track

Always-On Agents don’t wait for your next prompt. They keep working in the background, come back to tasks later and continue pursuing a broader goal.

Technically, you can imagine them like a never-ending chat with an LLM where the LLM acts like an orchestrator for any task that might come.

The key difference is that there isn’t necessarily one single output where you can say: done. The goal stays the same, while what needs to happen next keeps changing over time.

The reason I’m explaining this to you is that sooner or later, someone inside your organization will pitch this to you.

When do you need something like this – and when does it actually make sense economically?

To answer that, let’s explore the idea a bit more.

As I explained before, we’re leaving the LLM chatbot era behind and increasingly demand outcomes from our AI agents, not just simple answers.

Let me give you an example:

In a chat-based world you would ask an LLM:
“What are the biggest risks in this project?”

An outcome could be:
“Create the project status presentation.”

Now the Always-On thinking would be:
“Keep this project on track.”

Whatever that eventually means.

Today the agent might check whether someone responded. Tomorrow it might schedule a meeting. Next week it might notice that a decision has stalled and ask someone for an update.

As you can imagine, to work effectively, Always-On Agents need access to tools.

They need ongoing access to files, communication channels and systems relevant to their job so they can trigger the next right action.

Which creates a whole new set of problems, but we’ll get to that in a bit.

First, let’s look at where you’d actually need this.

To be honest, we’re still figuring out which business use cases genuinely justify this level of autonomy.

A lot of the demos so far have been consumer-focused. From a business point of view, I think Microsoft gave some of the clearest examples:

As you can see, this is highly flexible, ongoing work. The situation keeps changing, and the next useful action cannot always be specified in advance.

But here’s an important distinction: recurring does not automatically mean Always-On.

Most ongoing work still doesn’t need an Always-On Agent.

“Send this report every Monday” is ongoing too. But it can be automated using a simple AI workflow. If you want to create a report from a bunch of files, you’ll need a Work Agent like in ChatGPT Work or Copilot Cowork.

Only if the job is to keep the reporting process moving, chase missing inputs, handle exceptions and adapt when requirements change are you potentially looking at an Always-On use case.

But you shouldn’t try to force it into one.

Therefore my rule is:

The point isn’t to minimize autonomy for its own sake. The thing is that every additional degree of autonomy comes with a growing bill:

The distinction matters both commercially and operationally.

A Work Agent runs until its task is complete.

An Always-On Agent may keep checking context, reasoning, calling tools and interacting with systems for days or weeks.

That can mean materially higher token and infrastructure consumption.

A chatbot might give you a wrong answer.

A Work Agent might produce a wrong outcome or take a wrong action.

But an Always-On Agent might give you one blunder after another as they “work towards the goal”. Like this Muse which not only negotiated poor prices on Facebook Marketplace, but also revealed the user’s home address for pick-up, without their knowledge.

Since these systems have more time, more context, more tools and often more persistent access, their potential blast radius for things that can go wrong is significantly bigger.

And you might realize it too late.

“Create this presentation” has a fairly clear boundary.

“Keep this project on track” gives the system much more discretion.

Now you need answers to questions such as:

Most organizations aren’t ready for this conversation yet.

Persistent autonomy also means persistent access.

You need permissions, system integrations, audit trails, monitoring, approval gates and ways to contain risky actions.

That means thinking much more explicitly about permissions, isolation, human approval and observability.

That part alone creates significant overheads if you’re operating in scenarios where the actions and outcomes affect not just one single person, but an entire organization.

The point isn’t that Always-On Agents are good or bad.

But if someone is pitching you something like Microsoft Autopilot, Muse or Dots, here are three questions to ask:

If a workflow can solve your problem reliably, use the workflow. If a personal Work Agent can deliver the outcome, use the Work Agent. Move to Always-On only when the ongoing responsibility genuinely requires it.

Always-On Agents will likely become easier to buy, build and deploy. That does not make them the default architecture for ongoing work. You have to be ready when the pitch for always-on agents arrives. That’s why the useful skill right now is knowing when the additional autonomy is justified.

The technology is moving from answers, to outcomes, to ongoing responsibility. Use it only if your governance and business cases are ready to move with it.

See you next Saturday,
Tobias