Bot hoạt động liên tục: Các tác tử không ngừng làm việc

So far, most of this book has been about prompts. And how does a prompt work? You write something, the AI answers, and if you don't continue, it doesn't write anything else. In the previous chapters we saw that an agent can do much more inside that conversation: it can plan, use tools, and check its own work. But when you close the window, that work usually stops too. So even though an agent is far more capable than a single prompt, you still have to sit and wait for it to finish.

Now imagine something different. Imagine an assistant that is still there tomorrow, remembers what you told it last week, and starts its Monday report before you have even opened your laptop. That is a persistent bot. It has a lasting name and role, a place to work, a memory that carries over from one conversation to the next, and jobs that can begin without you. You are no longer handing it a single task. You are handing it a responsibility.

In this chapter we will look at persistent bots as an idea, not as a product. To keep things concrete, we will borrow examples from three projects that solve the same problem in different ways: Grok Bot, a hosted product where named Bots work on a cloud computer; Hermes Agent by Nous Research, which you can run on your own machine or server; and OpenClaw, a gateway you host yourself that connects an agent to your chat apps. Where they differ, the differences usually teach us something. Alongside them, we will also meet three assistants that bring the same idea to a much wider audience: Claude Duet from Anthropic, OpenAI's dots, and Meta's Muse. You message all three much as you would message a person, and each keeps working on a computer of its own in the cloud.

From Chat to Coworker

Think about how you work with a coding assistant today. It can plan, edit files, and run tests, and it can be remarkably good at it. But every session begins with a little setup, and when the conversation ends, so does the work. We can call this a session agent: it works for exactly as long as you are working with it. A persistent bot is built to outlast any single conversation.

The difference is easier to see side by side:

The people who designed Grok Bot describe this shift well. Most AI tools, they point out, are built around a chat session that the user drives. They wanted an agent that "persists beyond any one session and can carry responsibility on its own." In their model, a Bot has its own identity, memory, runtime, and tools (Designing Grok Bot).

That short list turns out to be a good lens for looking at any persistent bot, whoever makes it:

You can feel the same shift in the way people talk to the newer assistants. You write to Claude Duet the way you would write to a person. Each morning it sends you a short brief on what matters most across your connected apps, and during the day it gets in touch only when something needs your attention (Introducing Claude Duet). OpenAI's dots can be reached in ChatGPT, by message or by voice call, as well as in Slack and Teams, and they carry the same context from one place to the next. They, too, come to you with progress, questions, or decisions that need you (Introducing dots). Meta's Muse, which you can message in its own app or in WhatsApp, loosens the rhythm of the conversation itself. It is not strictly turn by turn: you can send a follow-up before it has finished answering, and open side chats for separate topics while it stays aware of all of them (How to get started with Muse). In every case, the conversation no longer begins only when you begin it.

The Bot's Computer

If a bot is going to keep working while you sleep, it needs somewhere to do that work. Our three examples answer this question in three different ways, and each answer comes with its own trade-offs.

A computer in the cloud. Grok Bot gives your Bots a persistent cloud computer with a browser, a command line, and files. You can close the app, even shut your laptop, and the work in the cloud carries on. There is one detail worth noticing, though: every Bot on your account shares that same computer. Browser sessions, files, and command-line credentials are available to all of them. Each Bot gets its own screen, but the documentation is careful to say that these screens are "separate work surfaces, not separate security boundaries." Between different users, each computer is dedicated and isolated at the hardware level (Use the computer and apps).

Claude Duet, OpenAI's dots, and Meta's Muse live in the cloud as well. Duet has a virtual machine with its own browser, so it doesn't need your laptop or phone to be switched on to keep working. Each dot likewise has its own cloud computer and browser, and OpenAI adds a welcome touch of transparency: you can open your dot's computer at any time and look at what it has been doing. Muse lives on a dedicated virtual machine of its own and keeps working after you close the app (Introducing Muse), and you can watch what it is doing in its browser and take over at any time (How We Built Safety Into Muse). During its research preview, Duet doesn't yet let you watch its browser or take it over (Get started with Claude Duet). It is a small difference, but a telling one: a bot's computer is easier to trust when you can look inside it.

Muse's computer also shows that one machine can hold more than one room. Meta says the right way to picture it is "two isolated security domains on one box, not an LLM powered agent with root." The agent, its tools, and your workspace live inside a sealed cell that is expected to handle untrusted content. The parts that keep your passwords, and decide what is allowed to leave the machine, sit outside that cell, where the agent cannot reach in and change them (How We Built Safety Into Muse). We will come back to those guards when we talk about safety.

A machine you run yourself. Hermes Agent can live on a machine you control. Its terminal tool can work directly on that machine or through other backends such as Docker, SSH, or cloud sandboxes like Modal and Daytona. Before running a command that matches its list of dangerous patterns, Hermes stops and asks you. Inside a container, it skips those checks, because the container itself is treated as the wall that keeps damage in (Hermes security). OpenClaw takes a similar path: it runs a Gateway on your computer and, by default, keeps the agent's workspace in ~/.openclaw/workspace. Its sandbox is off unless you turn it on. When you do, the agent's tools run inside a container while the Gateway itself stays on your computer (OpenClaw sandboxing).

Your own computer, only with permission. The bot's computer and the computer in front of you are not the same thing, and it is good to keep them apart. Grok Bot only runs commands on your local machine if you enable that ability and approve it. The default setting is Ask every time, and the documentation suggests choosing Never allow unless a Bot has a specific reason to touch your local files. Dots draw the same line: your own computer and its contents stay separate unless you decide to give your dot permission to connect to your laptop and use it.

Two lessons come out of all this, whichever setup you choose. The first is that shared space means shared access. If several bots share a browser, files, or passwords, any one of them may be able to use them. The second is that separation is something you decide, not something you get for free. OpenClaw, for example, expects one circle of trust per gateway: a single person, or a team whose members trust each other. For anyone outside that circle, it recommends a separate gateway with separate credentials (OpenClaw security).

Memory: What a Bot Should Remember

In the chapter on context engineering we learned that AI models don't remember anything on their own: everything they know about you has to be put back into the context each time. Memory is how a persistent bot works around that. It lets the bot keep its role over months without rereading every conversation you have ever had.

But what should go into that memory? Good memories are lasting facts: your preferences, the bot's responsibilities, how a project is usually done, lessons learned the hard way. What memory should not do is replace the real sources of information. The current price of a deal lives in your CRM, your meetings live in your calendar, your open bugs live in the ticket tracker. Those places change; a memory written last month does not.

Each of our examples handles memory in its own way. OpenClaw keeps it refreshingly simple: memory is plain Markdown files in the agent's workspace. As its documentation puts it, "The model only remembers what gets saved to disk." Your lasting preferences go into USER.md, important facts and decisions go into MEMORY.md, and both are loaded at the start of every session. Day-to-day observations are written to daily notes in memory/YYYY-MM-DD.md that the agent can search later, and a background process with the lovely name dreaming moves the useful parts of those notes into MEMORY.md (OpenClaw memory).

Hermes Agent also uses two small files. MEMORY.md holds the agent's own notes about its environment and the way things are done, and USER.md holds your preferences. Both have a character limit, which forces memory to stay short and carefully chosen. They are loaded as a frozen snapshot when a session begins, so something saved in the middle of a conversation shows up in the next one. For older details, the agent can search its past conversations (Hermes memory).

Grok Bot lets each Bot keep its working preferences, important facts, and summaries of what it has done. Its documentation adds a warning worth remembering: "memory is not a substitute for an authoritative source." Facts that change should stay in the system they come from, and for important decisions you should ask the Bot to open the current data again (Create and manage Bots).

Memory doesn't always start from a blank page, either. Claude Duet carries over the memory, skills, and connected apps you have already set up in your Claude account, so it knows something about you from its very first message. OpenAI describes dots as learning from feedback: the more you work together, the better your dot understands your preferences and "what good looks like to you" (Introducing dots). Both are convenient, and both remind us that what a bot learns tends to stay. Duet's safety notes point out a subtle detail: disconnecting an app stops any new access, but what Duet has already learned from that app stays in its memory until you reset it (Claude Duet safety, privacy, and security). Closing a door is not the same as forgetting what was behind it. Meta's Muse puts the other half of that idea in your hands. Its memory about you is kept as files you can open, edit, and download, and you can simply tell it to "forget" specific things it has learned (How We Built Safety Into Muse). A bot that learns from you should also be able to unlearn when you ask.

You can see the difference in a single sentence:

Remember: Acme's renewal is $42,000 and closes on March 3.

Remember: I'm responsible for the Acme renewal. Its price and closing date are in the CRM. Check the CRM before you quote either one, and tell me if anything has changed since your last summary.

Some memories do more than inform; they shape what the bot will do later. "The client said we can send the draft once legal approves it" is that kind of memory. For notes like these, OpenClaw suggests also writing down when it is safe to act, when the note stops being true, and who has the authority to decide. It is honest about the limits, too: "Memory can preserve approval context, but it does not enforce policy."

From Skill to Routine

What is the most useful thing a persistent bot can do for you? Very often, it is work you have already done once yourself. Grok Bot's documentation suggests a sensible order here: first do the task once, then make it reliable, then save the method as a skill, and only after all that, put it on a schedule (Skills and routines). Let's follow one task along that path:

Notice the two different things we created along the way. A skill, which we met in the chapter on agents and skills, describes how the work is done. A routine says when a particular bot does it. Hermes draws the same line: a scheduled job can carry one or more skills, and the job's own prompt sits on top of them as the instruction for that run (Hermes cron). OpenClaw splits things in a similar way. Its standing orders, written in AGENTS.md, describe what a program is allowed to do, what starts it, where it needs approval, and when to escalate. Its automations only decide when the work runs (Standing orders).

What a Routine Must Specify

Here is the thing to keep in mind about routines: they run when you are not there to answer questions. Hermes spells this out for its scheduled jobs. Every run starts in a fresh session with no chat history, so the prompt has to stand on its own and cannot stop to ask what you meant. The bot's saved memory still loads, but nothing else from earlier conversations does (Cron internals).

So what does a prompt need in order to stand on its own? Grok Bot's documentation offers a checklist, and it maps nicely onto everything we have learned about clear prompts:

Periodic Checks and Scheduled Jobs

Routines come in two broad shapes, and it helps to know which one you need. A periodic check wakes the bot up every so often just to look around: is anything stuck, urgent, or new? Most of the time, the right answer is to say nothing and go back to sleep. A scheduled job does one specific task at one specific time, like a report that should be ready at 9:00 AM.

OpenClaw shows both shapes. Earlier versions had a separate heartbeat for periodic checks, driven by a checklist in HEARTBEAT.md. The current documentation folds heartbeats into ordinary automation jobs. When you first set things up, it creates a single Proactive check that, by default, runs every 30 minutes in the agent's main conversation. It waits until the agent is idle, and if nothing needs attention, it simply replies NO_REPLY (Heartbeat). When the timing has to be exact, like a daily report at 9 AM sharp, the documentation recommends an automation with its own schedule instead (Automation guide).

Claude Duet happens to show both shapes, too. Its morning brief is a scheduled job; the checks it makes through the rest of the day are periodic ones. And it makes one trade-off unusually easy to see. Duet looks at your connected accounts every few hours rather than nonstop, and Anthropic explains why plainly: checking nonstop would use up your plan's limits much faster (Introducing Claude Duet). The price of that choice is written down as well: something urgent can arrive between two checks (Get started with Claude Duet). There is no perfect interval. Every look costs something, so a shorter interval notices things sooner and costs more, while a longer one is cheaper but slower to react. Duet lets you tell it what you want to hear about and how often, and that is a good habit with any bot: decide what is truly urgent and give it a faster path, instead of making every check more frequent. OpenAI's dots add one more useful idea. When you are not working with them, they look around for ways to help using tools that can only read, so they cannot send messages or change anything (Introducing dots). A check that can only look is a check that can do very little harm.

A routine doesn't have to wait for the clock, either. It can also start when something happens. Grok Bot can start a routine when, say, a Slack message arrives or a GitHub notification comes in. Hermes can start a scheduled job from a webhook, and OpenClaw supports authenticated webhooks and hooks that fire at different moments in a session's life. Whatever you use, keep the trigger narrow. Grok Bot's documentation warns that broad listeners, such as "every new message," create noise, use up your allowance, and make it more likely that the bot acts on something irrelevant.

And before you put anything on a schedule, try it once. Remember that a test run is not a rehearsal: it does real work. It can visit websites, change files, and call your connected tools. So give it safe inputs, and watch that it really does stop where it is supposed to ask you.

Teaching by Demonstration

Some work is much easier to show than to explain. Think of all the websites you use that have no clean way for a program to talk to them: you just know where to click. More and more, persistent bots let you teach this kind of work the way you would teach a new colleague: by doing it while they watch.

Grok Bot has a Teach a task flow, where it is available. You open the Bot's computer, describe the result you want, and then do the work once yourself. The Bot records what happens on the screen for up to ten minutes, without recording your microphone, and turns it into a skill. The documentation is careful to call that skill a draft. You still need to add the decision rules, the failure handling, and the approval points "that may not be obvious from one example," and then test it on a safe example before you put it on a schedule. Hermes offers something similar with its /learn command, which can turn a procedure you paste in, a link to some documentation, or "the workflow you just walked the agent through in this conversation" into a saved skill (Hermes skills).

There is a catch, of course. A single demonstration shows a single path. It doesn't show what you would do with a missing receipt, a record that appears twice, or a page that suddenly looks different. So after you have shown the bot the way, ask it what it understood and, just as importantly, what it still doesn't know:

I just showed you how to ${workflow:file an expense report from a receipt in my inbox}. Turn it into a draft skill, but don't save it or schedule it yet.

1. List the steps you saw, in order.
2. List the decisions you think I made, and tell me which ones you are only guessing.
3. Ask me about situations this one example didn't cover, such as missing information, duplicates, or errors.
4. Suggest which actions should wait for my approval.
5. Explain how you will check that a run actually succeeded.

One more piece of advice: don't type passwords or other secrets while the bot is watching. Grok Bot's documentation recommends handing over credentials through its secure handoff flow instead.

Delegation and Multiple Bots

As a bot takes on more responsibility, something familiar happens: one bot becomes several. Just like in a growing team, there are two common ways to divide the work.

Hermes leans on helpers. Its delegate_task tool creates subagents, each with its own conversation, terminal session, and set of tools, and only the final summary comes back to the main agent (Hermes tools reference). OpenClaw can also start sub-agent sessions. Its security guide suggests switching that ability off unless an agent really needs it, and requiring a sandbox for delegated work that must stay inside one (Tool and agent permissions).

Grok Bot leans the other way, toward teammates. Its launch post describes people running several Bots side by side, sometimes with a chief of staff Bot that coordinates the specialists. Bots can message one another and work together in group chats (Introducing Grok Bot). Its design post explains where it draws the line: tools and skills are shared across the whole account, while memory and routines belong to each Bot. In other words, abilities can be shared widely, but context stays with the role that needs it.

Whichever pattern you use, handing work to another bot is really just writing a small prompt. And everything you learned about good prompts applies: it needs a goal, the inputs, a clear picture of what "done" looks like, and limits.

Hey, can you deal with the checkout bug?

Reproduce the checkout crash from ticket BUG-412 in staging. Write the steps, the browser, and any console errors into the ticket. Don't change any code or production settings. When you're done, reply in this thread with the steps to reproduce it and whether the crash happens every time.

It is tempting to think that splitting work across bots also makes it safer. It doesn't. Separate roles help each bot stay focused; they don't keep anything locked away. Grok Bot's documentation explicitly says not to treat separate Bots as a security boundary, and OpenClaw notes that bots can message each other by default unless you restrict it. If two kinds of work need different levels of access, give them different environments or different credentials. OpenAI's preview of specialist dots points the same way for organizations: the company sets up each one with its own identity, its own credentials, and access to just the systems its job requires (Introducing dots). When a bot has an identity of its own, its access can be granted, reviewed, and taken away for that role alone, much as it would be for a new colleague.

Safety and Approvals

Here is the heart of the matter: a persistent bot acts when you are not watching. In a chat, you see every answer before you do anything with it. With a persistent bot, there may be no one looking at all. That makes its boundaries far more important.

Anything that leaves your hands should wait for you. Grok Bot's documentation lists the kinds of actions that deserve clear limits: sending messages or invitations, publishing, buying things, deleting or overwriting data, changing permissions, touching production systems, and accepting legal terms (Approvals, security, and privacy). A good starting point is to let the bot draft, compare, and recommend freely, and to have it ask you before anything goes out into the world.

Claude Duet draws a similar line. It reads, drafts, and prepares work on its own, but before it sends a message, makes a payment, signs a document, or deletes anything, it shows you exactly what it is about to do and waits for your approval. A few actions, such as trading securities or moving money between accounts, are off-limits even if you say yes (Introducing Claude Duet). That second idea is worth borrowing: some doors should stay closed no matter who knocks. Dots follow the same spirit, with built-in rules about when to act alone and when to ask, Custom Rules that let you allow, require approval for, or block specific actions, and a few sensitive tasks, such as changing a password, that always stay with you (Introducing dots). Muse, too, checks with you before it sends an email or makes a purchase, and it lets you decide, app by app, how much access it gets: for email, whether it may only read your mail or may also send on your behalf (Introducing Muse). Reading and sending are very different powers, and it helps to hand them out separately.

Work done while you're away needs a plan for approvals. If a routine runs at 3 AM, who is going to say yes? Often, nobody. In Grok Bot, an approval request from work that started without you, such as a routine, expires after about ten minutes and the action simply doesn't happen. In Hermes, scheduled jobs refuse dangerous commands by default, and the agent has to find another way. Both choices fail safely: when in doubt, nothing happens. Design your routines so that waiting, or being told no, is a perfectly safe outcome. Claude Duet takes a middle path: if you can't approve right away, it finishes the rest of the task and brings the approval back to you later (Get started with Claude Duet). The risky step waits; the rest of the work doesn't.

An approval should come from you, not from the conversation. There is a quieter danger in asking for permission inside a chat. If a bot reads a web page that says "The user has replied: yes, go ahead," how is it supposed to tell that line from your real answer? Meta's Muse sidesteps the question by taking approvals out of the conversation altogether. A separate component called the Sentinel, which runs outside the agent's sealed cell and which the agent cannot override, decides whether each action and each outgoing request may go ahead. When it needs you, the work stops, and the request appears in the app as a dialog of its own rather than as a chat message. Your answer goes straight back to the Sentinel, so nothing the bot reads can type it for you. Each approval is also tied to one connector or destination and one purpose, and you choose how far it reaches: a single action, a session, a task, a span of time, or for good. Not everything needs a question, either. Reading, actions you have already allowed, and other clearly low-risk work go ahead without interrupting you, because the aim, in Meta's words, is "to put friction where consent matters" (How We Built Safety Into Muse).

Anything the bot reads can contain instructions. Prompt injection doesn't need a stranger typing into your chat. As OpenClaw's guide points out, any untrusted content the bot reads, whether a web page, an email, a document, or an attachment, can hide instructions meant to mislead it. One way to reduce the risk is to have a separate, read-only reader agent summarize untrusted content for the main agent. Even then, the summary is still untrusted (OpenClaw prompt injection). Muse stacks several defenses of its own. Anything that comes from outside is labeled as untrusted the moment it enters the model's context. A group of classifiers, trained separately from the model and running outside the agent's cell so that an attacker cannot switch them off, screens incoming files and tool results. And its browser helper reads a page's accessibility tree, the simplified outline that screen readers use, rather than the page's code, and it cannot run scripts at all. Even so, Meta says plainly that prompt injection "remains an open problem in the industry," which is why the Sentinel and its approvals are meant to hold even when every filter misses (How We Built Safety Into Muse).

Keep secrets out of the model's reach. A bot that signs in to websites for you needs your passwords, but the model doing the thinking doesn't have to see them. Claude Duet is built so that the model never sees your passwords, browser cookies, or sign-in tokens. Its browser runs on a separate virtual machine, apart from both the model and the computer the agent works on, and the agent can drive it only through a fixed set of commands: open this page, click here, type this (Claude Duet safety, privacy, and security). Dots can likewise sign in to supported websites with saved passwords without exposing them to the model (Introducing dots). The idea is simple: a model cannot leak a secret it never had. But notice what still travels back. Duet's browser still returns the page's text and any downloads, because the agent has to read them to do its job. That is why Duet also relies on prompt-injection safeguards and on a separate automatic check that reviews each message it drafts before it goes out. Hiding the keys doesn't make what the bot reads any more trustworthy.

Muse carries the same idea all the way to the network. The model only ever holds stand-in tokens, and when an approved request leaves the machine, the Sentinel swaps in the real credential at the very edge. Its email connector also filters out one-time passcodes, password-reset links, and sign-in links, because an inbox can open the door to most of your other accounts. Purchases follow the same pattern. On a site where you haven't shopped before, Muse asks for your approval and then pays with a single-use card number from Stripe's Link wallet, good for one merchant, one amount, and a short window of time (How We Built Safety Into Muse). Even if such a number were stolen, it would be worth very little. That is the deeper lesson: make sure that what the bot holds is not worth stealing.

Real rules belong in controls, not only in memory. "Never email customers without asking me" is a good thing for the bot to remember. But a rule that actually stops every outgoing email until you approve it is a different kind of thing: it is enforced. Grok Bot recommends backing up safety boundaries "with approvals and Auto-review rules rather than memory alone." The best approach is to use both. The memory explains what you want, and the control makes sure it happens.

Prompting Persistent Bots

By now you may have noticed something: prompting a persistent bot feels less like asking a question and more like writing a job description. A routine will run again and again without you, and every gap you leave in the instructions becomes a decision the bot has to make on its own. The clearer you are up front, the fewer of those decisions it has to guess at.

Every morning, check my inbox and take care of anything important.

Every weekday at 8:00 AM America/Chicago, look through unread messages from the last 24 hours with the Clients label. Post a summary in this chat with the sender, the request, the deadline, and a suggested reply for each one. Write draft replies, but never send them. If the mailbox can't be reached, say so and stop. Don't fall back on older data.

When you set up a routine of your own, you can start from the template below. Fill in each part, and then ask the bot to describe the routine back to you before you switch it on. If its summary surprises you, the instructions weren't clear enough yet.

Create a routine for this bot. Describe it back to me and wait for my confirmation before you switch it on.

Owner: ${owner:this bot}
Schedule: ${schedule:every Monday at 9:00 AM}
Time zone: ${timezone:Europe/Istanbul}
Skill to use: ${skill:Weekly account health}
Inputs: ${inputs:the Accounts sheet and the support queue from the last 7 days}
Output: ${output:a report with source links, posted in this conversation}
You may do these without asking: ${allowed:read sources, write drafts, update the report file}
Ask me before: ${approval:contacting any customer or changing any record}
If a source is missing or out of date: ${failure:tell me which source failed and stop; don't use old data}

Before the first scheduled run, do one test run with safe inputs and show me the result.

And when a routine finishes, ask for a result you can actually check. Grok Bot's guidance suggests keeping a few things apart in every report: the facts it found in sources, its assumptions, what it has already done, what is waiting for your approval, and the questions it couldn't answer. It is the same lesson we learned in Tools, MCP and Connectors: saying something is done is not the same as showing it. A link, a record ID, or a saved file is evidence. Claude Duet works in the same spirit: when it gives you a number or a summary, it tells you which email, file, or spreadsheet it came from. Its documentation is honest about why that matters, since it can still misread a thread or misjudge what is urgent (Get started with Claude Duet). Muse keeps an audit trail of everything it has done and everything it plans to do (Introducing Muse), and Meta's help page is just as frank: Muse "may be inaccurate or take unexpected actions," so keep an eye on what it does (How to get started with Muse).

Persistent bots bring together everything we have seen in the last few chapters. Skills give them methods they can reuse. Tools and connectors give them access to the world. The harness keeps the loop running. Memory and routines add one more ingredient: time. The bot remembers, and the work carries on while you are away. And yet the craft at the center of it all hasn't changed since the first chapter. Say clearly what you want, where the limits are, and how you will know it went well.