Good Agents Never Sleep

Grok Bot has completely taken over my timeline. If it hasn’t taken over yours, take a look at these viral posts, which have a combined view count of over 24 million:

For anyone who hasn’t tried it, Grok Bot is an app for your phone and computer where you can create a team of always-on agents. The interface looks like a messaging app where you can DM a single agent or chat with a team in a group chat. The agents work from a linux instance hosted in the cloud, complete with a chrome browser and a wide variety of plugins to connect email, calendar, github, slack, notion, etc. When you create an agent, you give it a name and a description. That shapes the agent’s personality and scope of responsibility, which it automatically endeavors to carry out. Agents can also have routines, where a trigger (a time of day, incoming email, or upcoming calendar event) can cause an action to take place (a daily research task, a draft response, or a meeting brief). The agents can message each other, work together in groups, and even establish hierarchy. It’s still Grok, but a version that never sleeps.

I’ve seen some people complain that it’s an Elon product being promoted by an Elon platform, but I think they’re wrong. Trying the product was a ChatGPT / Claude Code / Clawdbot (now OpenClaw) moment for me and many others. Here’s an example of Jon, a plumbing company owner, achieving more automation with Grok Bot in an evening than he’d imagined was possible with Claude.

Jon is now able to automate intake for five or six time-sensitive work orders per day. The agent examines the job, finds capacity, confirms the work order with the customer, and proceeds to book an actual plumber. The step change for Jon wasn’t just that Grok Bot completed the task, but it continued owning the work after the conversation ended. And Grok Bot isn’t the only AI product out there embracing this new way using AI. There’s a growing wave of breakout AI products embracing persistent agents and seeing tremendous product market fit.

Persistent Agents

Every large company of the past was built by employees, not contractors. It’s quite obvious why, but to break it down: Employees remember things about the company and learn to do their job over time. This value compounds the longer an employee serves with an organization.

The best employees also take initiative and own responsibilities that reasonably belong to them. They don’t need to be directed or re-engaged for every additional function they perform. This saves the manager time and mental bandwidth to focus on larger problems.

The same is true for agents. The previous paradigm of agent use with a harness like Claude Code was hiring a contractor. You needed to define the work spec, provide relevant context, and supervise the job being done.

Persistent agents are different. They are always available to handle incoming work, and proactively seek out more within their scope of responsibility. They have their own environment to work, whether it be in the cloud or self hosted in an “always on” machine. They maintain a durable state and can resume after pauses without reconstructing everything from scratch when the context window fills up. Finally, they can be reached from multiple interfaces without having to start a new session; think text, voice call, slack message, GitHub pull request, etc.

Because persistent agents have these qualities, they can handle more than just a single deliverable. There is not necessarily an “end state.” Rather, persistent agents have standing responsibility. That could be an outcome, condition, or recurring job. External events or a defined schedule can trigger a response, and the agent is in charge of understanding whether something needs their attention. I’ll propose a five-part test for determining whether you’re working with a persistent agent. If each of these questions can be answered, it falls under my definition of such an agent:

What does it watch?
What causes it to act?
What state does it retain?
What is it allowed to do autonomously?
How does it evaluate completeness of an individual job?

If an agent can answer these questions, it’s no longer serving the function of a contractor. It’s an employee.

Ralph Wiggum: The First (Stupid) Employee

One of the most frustrating parts about using early versions of Claude Code was how it would stop short of completing a task. Repeated prompts to “find all bugs and fix” often yielded some meaningful improvements each time, and Claude had a habit of laziness when it was told to complete a feature. So developers resorted to various kinds of “loop engineering” to remove themselves from unnecessary prompting and model babysitting. The Ralph Wiggum loop was a brute force approach to getting a problem done: forcibly re-launch a fresh claude code session until the desired outcome was reached.

The popularity of Ralph Wiggum showed that users wanted some kind of persistence before any harness really supported it. Users wanted to be able to step away and come back to a completed solution. However, the naive approach of brute force repetitions with the same prompt was a hack with many suboptimal properties. It could burn lots of tokens only to repeat the same mistake, a false completion declaration could stop the loop prematurely, and the agent inside the loop was starting each iteration with only the permanent artifacts left behind from previous sessions. Ralph identified the demand for persistence and task completion. It didn’t address the need for continued responsibility, but getting a single task finished was a necessary precursor. And the intuition of throwing more inference at a problem and expecting a better result was directionally correct.

The Ralph Intuition: More Test Time Compute, Better Output

Test-time compute measures the amount of work an AI system performs to solve a problem. This could mean generating multiple solutions and picking the best one, spending more time in a reasoning loop, or gathering more sources that could be helpful to solving a particular challenge. For some tasks, it turns out test time compute is one of the most important levers that impacts a successful outcome. OpenAI has published multiple examples showing how increasing test time compute can lead to benchmark maxxing, including this striking example with their browsecomp benchmark. The benchmark is composed of questions that are hard to research but easy to verify correctness. As the model was allowed more browsing effort, its performance improved markedly. Sampling from many attempts also materially improved performance. They gave their agent 64 attempts, then had different AI models pick the best answer. Performance improved from 15% to 25% versus a single attempt.

This doesn’t mean that persistent run time will automatically generate better results. If the context window gets bogged down, an agent will get less efficient over time and begin forgetting the most salient details of a task. However, so far researchers have found workarounds to this issue and we don’t seem to have hit an upper bound on the improvement offered by increasing test time compute. For example, A 2026 paper on test-time compute for coding agents. tried to solve this by turning previous attempts into structured summaries. The summaries preserved important progress and failure modes while discarding less useful context. This improved Claude 4.5 Opus from 70.9% to 77.6% on SWE-bench Verified and from 46.9% to 59.1% on Terminal-Bench v2. Most modern harnesses keep their methods for compaction proprietary, likely because doing so well provides notably better performance. And every progressive model release has been able to handle longer tasks than their predecessors. METR’s time horizon research shows how the increase in task length frontier models can handle has actually been a steady exponential trend. And the study is from January 2026, from which point progress has continued to accelerate.

From Contractor to Employee

Tasks to Standing Responsibility

In 2026 there’s been a notable shift in what we expect from our agents. We used to need to babysit agents as they completed work and celebrate when something was “one-shotted.” As agents got better at completing entire tasks, one-shotting became the norm and the goal shifted: Rather than prompting for every individual task, can an agent get one prompt for many future tasks, in perpetuity? It’s the difference between cleaning up your email once and automating it forever. If you want to try it out, check out this tutorial from a guy who used it to clear out 100k junk emails from his inbox. Just hand this link to your Grok Bot and tell it to figure it out: https://x.com/mikepat711/status/2090443789642895721.

Many of the most successful companies this year have also answered yes to the question of handling perpetual responsibility. Grok Bot is certainly one example, but consider juggernauts like Perplexity and Cognition, both pushing annualized revenue numbers close to $1 billion and raising rounds valuing them each in the tens of billions.

Cognition describes the shift in agentic software engineering to be fully asynchronous where agents are proactive about identifying issues, fixing the PR before users even has a chance to identify the bug themselves, and their product Devin embodies all the characteristics of a persistent agent. It runs in its own environment, always on, can be assigned responsibilities and trusted to handle them completely.

Perplexity is an especially interesting case study because they started with a search product that had more of a chatGPT interface. Once Google, OpenAI, and Anthropic started offering search with sources to prevent hallucinations too, Perplexity released Computer. Running fully autonomously in the cloud, Computer has persistent memory across sessions and can be scheduled to run recurring tasks. When it was first released, it was among the first AI products where you could just hand a problem to a swarm of agents in the cloud and come back a few hours later to a finished product. Now it monitors your email, calendar, flight status, can handle scheduled jobs, or anything that requires composition of many different AI skills.

How Much Responsibility Agents Deserve

For an agent to be maximally useful, it must do what an employee does: reduce the cognitive load of the supervisor. The logical endpoint is that AI will need to do “everything.” By this I mean any task a human would reasonably delegate to another human. This includes gathering information, coordination tasks between people and agents, transactions involving payments and negotiation, and business operations. While many of these represent sensitive matters, humans also have limited attention spans and working memories (the organic context window). If an agent must present all actions to a human for approval, the human will still need to remember a bunch of information which takes up valuable mental real estate. The objective should be to focus on the judgements where doing so offers high marginal value.

We already delegate this kind of responsibility to human employees. As the harnesses and underlying models improve, why should we keep AI agents out of the loop? Even the best human employees still have to sleep.