When AI stops waiting to be asked

Now the AI messages you first

For nearly four years, almost everything we’ve done with AI has started the same way: you open a window, type a request and wait. The model does nothing until you speak, forgets most of what happened once you close the tab, and has no idea what’s going on in your world between conversations.

That’s starting to change. A new wave of agents runs in the background, wakes up on a schedule or when something happens, and comes to you with the work already under way, so the direction of the relationship flips and the AI starts the conversation.

The underlying technology has been around for years, and the experience has finally been polished to the point where it feels obvious. The iPhone did that for the smartphone, ChatGPT did it for the language model in late 2022, and Claude Code did it for the coding agent in 2025. For always-on agents, the closest equivalent so far is Grok Bot, and the shift it points to is bigger than any single product: we’ll still be chatting with AI, but more and more of those conversations will be ones the AI starts. That puts new decisions on every organisation’s desk: which jobs to hand to an agent, what it’s allowed to touch and when it should interrupt a person.

Something other than you starts the work

“Always on” doesn’t mean a model thinking non-stop in the background. It means the agent can be woken by something other than you typing into a chat box, and there are three common ways that happens:

• A schedule. The agent runs at set times, such as a morning briefing, a weekly status report or a nightly sweep of a backlog. Claude Code’s routines, for example, can be started on a schedule, by an API call or by a GitHub event, and run as cloud sessions rather than on your laptop (Claude Code docs).
• An event. Something changes in a system the agent is watching: an email lands, a pull request is opened, a build fails or a customer leaves feedback, and the agent picks it up.
• A heartbeat. The agent wakes on a short interval and decides for itself whether anything needs doing. OpenClaw made this popular: by default it wakes every 30 minutes and reads a short checklist file in its workspace, and if nothing needs attention it replies with an acknowledgement that OpenClaw quietly drops instead of messaging you (OpenClaw docs).

A schedule or a webhook is still automation you designed in advance, whereas a heartbeat gives the agent discretion over when to speak up, and that discretion is what makes it feel like a colleague keeping an eye on things.

Over the past ten months the big platforms have converged on the same shape. OpenClaw went viral in January as an open-source agent that talks to you over WhatsApp or Telegram. Google followed with Gemini Spark in May (Google), Microsoft with Scout in June, a Microsoft 365 agent powered by OpenClaw (Microsoft) and since renamed Autopilot (Microsoft), SpaceXAI (formerly xAI) with Grok Bot in August, Meta with Muse in early September (Axios) and OpenAI with dots on 29 September (OpenAI).

Grok Bot shows the approach in its plainest form. Users create named bots, each with its own job, that keep working after the laptop is closed and only come back when the work is done or something needs approval (The Verge). Bots can message each other and coordinate in group chats, pulling a person in only for judgement calls, and the simplest way to teach one a job is to let it follow along the next time they do it themselves (SpaceXAI). Early users describe it as feeling less like prompting an agent and more like handing work to a capable teammate.

From chat sessions to agents with memory

Chat taught us to think in sessions. Each conversation starts more or less blank, you carry the context in with you, the model works inside that one context window, and when you close the tab most of it is gone. Memory features have softened this over the past couple of years, but the mental model is still a single conversation with a single helper who has to be briefed every time.

Always-on agents change the unit. You stop configuring a conversation and start configuring someone: an agent with a name, a standing brief, a memory that carries over between runs, a set of skills it can call on and the credentials to use the systems it needs. OpenClaw keeps all of this as plain Markdown files in a workspace, with separate files for the agent’s persona, identity, tools, memory and heartbeat checklist, so you can open and edit an agent’s personality in a text editor (OpenClaw docs). OpenAI’s dots launch makes the same move: you start with a primary dot, give it a name and make it your own, and specialist dots can be set up with their own identities, credentials and access to the systems they need (OpenAI).

The design questions change with it. Instead of asking what to put in this prompt, you’re asking who this agent is, what it should remember, what it’s allowed to touch and who it reports to, which is much like onboarding a new team member. In practice, this looks like several agents with separate jobs and separate memories, rather than one assistant that knows a little about everything you’ve ever asked it.

None of this needed a breakthrough. Scheduled automation has been available through tools like Zapier and n8n for years, and tool use, long-term memory and connectors were all in place well before 2026. TechCrunch’s coverage of dots points out that much of the functionality was already possible through Codex and similar harnesses (TechCrunch). OpenClaw itself is built on Pi, an existing minimal agent by Mario Zechner (Armin Ronacher), and its creator’s achievement was gluing proven parts together so well that the result felt new. The response was still extraordinary: the first commit landed on 25 November 2025, and less than three months later the project had 196,000 GitHub stars and 600 contributors (Simon Willison). That gap between modest technical novelty and enormous uptake is the clearest sign that the change is in how we interact with AI.

Delegation is the most intuitive interface

Chat put more of the work on people than it seemed. You had to be the one who started every interaction, decide what context the model needed, phrase the request well and remember to come back. That’s a skill, and plenty of capable people never warmed to it.

Most of us already know how to work with a colleague, though. You give someone a role, tell them what you care about, expect them to remember it, and trust them to come to you when something needs your attention. Always-on agents borrow that whole model. You message them in the same places you message your team, such as Slack, Teams or WhatsApp, and they come back to you rather than waiting in a browser tab. I suspect that’s why this is landing with people who never got much out of a chat window: there’s very little new to learn.

The personification follows from the same instinct. OpenClaw has its lobster, OpenAI’s dots are little floating cartoons, and Meta’s Muse lets you name your agent, design its avatar and choose how it talks (Axios). TechCrunch read the dots branding as the latest attempt to make AI more relatable (TechCrunch). If the product is a someone rather than a tool, giving it a face is the obvious design move.

The friendliness deserves some scepticism. Creative Bloq found Meta’s cheerful avatar faintly infantilising and raised the risk of parasocial attachment (Creative Bloq). The more serious issue is trust: it’s easy to hand your inbox to an agent with a charming avatar, and an always-on agent with access to private data, exposure to untrusted content and the ability to send messages is exactly the combination Simon Willison calls the lethal trifecta. In February, Meta’s director of alignment went viral after her own OpenClaw agent started deleting her inbox and ignored her messages telling it to stop (The San Francisco Standard). A friendly face changes how much people trust the agent without changing how much the agent deserves it.

In software, proactive agents fit the outer loop

Software teams talk about two loops. The inner loop is the tight cycle of writing code, running it and fixing it, which is where coding agents like Claude Code and Codex already do their best work in a focused session with one coherent context. The outer loop is everything around it: deciding what to build next, triaging feedback and bugs, checking that what landed matches what was intended, watching how it behaves once it’s live and feeding all of that back into the plan.

The inner loop doesn’t need an always-on agent, since a coding session has a clear start and end and benefits from one agent holding the whole picture. The outer loop is where an agent that wakes on a schedule or an event fits naturally, because that work is continuous, spread across systems and mostly about noticing things. Anthropic’s own examples for Claude Code routines sit squarely here, such as a weekly check that finds documentation which has drifted out of step with merged changes and opens update pull requests for an editor to review (Claude Code docs).

In practice, an outer-loop agent with a product owner’s brief looks like this:

• Each morning it reviews new issues, support tickets and customer feedback against the roadmap, then drafts tickets with acceptance criteria for a human to prioritise.
• When a pull request merges, it checks the change against the spec and acceptance criteria held in the repo, and flags gaps rather than fixing them itself.
• It watches test-environment logs and production alerts, and turns recurring problems into well-described work items.
• It keeps the specs and docs in the repo in step with what was built, so the next coding session starts from an accurate brief.

We run one of these ourselves. UVLens is a free app that shows the day’s UV index forecast and your personal burn risk, and it’s the product that started ElementX back when we were Spark 64. It has since become more of a community service than a commercial product, which makes it hard to set aside dedicated time for, even though people still use it and it still needs regular updates. So an always-on agent now triages incoming customer feedback and bug reports and logs the issues in our backlog automatically. When someone on the team has time, they pick an issue up with a coding agent and work through it in a focused session. The agent handles the noticing, the part that used to slip through the cracks, while people still decide what’s worth fixing and do the building. Inside a client’s systems, the same agent would also need its own identity, access scoped to the ticketing system and an audit trail of everything it logs.

This fits how we already like to build. Our approach puts the specs and technical decisions in the repo before any code is written, then lets coding agents build feature by feature against that plan, which makes the human’s job setting up the system the agents work in. An always-on product owner extends that system: it keeps the plan honest between coding sessions so a person doesn’t have to. Prioritisation and commitments to stakeholders stay with people, and the agent proposes rather than decides.

Design roles, permissions and manners now

With OpenClaw, Gemini Spark, Autopilot, Grok Bot, Muse and dots all arriving within a single year, the category is established, and the question for most organisations is how to use it well. For many NZ organisations, the first always-on agents will arrive inside Microsoft 365 or Google Workspace, ahead of any project they’ve scoped.

Getting a few decisions right before that happens will save a lot of rework:

• Think in roles. Look for standing jobs in your organisation that mostly involve keeping an eye on things, such as triaging a claims or complaints inbox, keeping up with the spike in student enquiries during enrolment or watching a backlog of asset inspections. Those are the natural first agents, and each should have a clear brief, its own memory and a named person accountable for it.
• Give every agent its own identity and the narrowest access that works. Agents that run unattended need credentials, permissions and audit trails like any other member of staff. Microsoft gives each Autopilot its own Entra identity, limits it to the resources the organisation approves and can require a person to sign off sensitive actions (Help Net Security). OpenAI is provisioning specialist dots through existing identity systems and working with Microsoft on governance controls (Al Jazeera). When a dot goes looking for work on its own initiative, it is limited to read-only tools and can’t send messages, change content in your apps or control a browser or computer, while scheduled and user-directed tasks follow separate approval rules (OpenAI). Read-only by default is sensible for any agent with access to private data.
• Decide when an agent should interrupt. An always-on agent that messages people every hour will be muted within a week. The value of a proactive agent lies in its judgement about when something is worth a person’s attention, so define that threshold as carefully as the work itself.

We think the shift is a good one for people, provided it’s designed with care. An agent that comes to you with the groundwork done respects your time far more than a chat box that waits for you to remember it exists, as long as people still decide what matters, approve what goes out and can see what their agents have been doing.