You close the laptop, and the agent stops working. Until recently that’s how most AI agents lived: an agent in the terminal is a process on your computer, and it stops along with it. A new class of autonomous AI agents is built differently. They have their own computer in the cloud, their own memory and their own habits. An email or a message from a colleague wakes them up, they work at night and write to you only when they have something to say. In the English-speaking world they’re called always-on.
Lee Robinson explained how they work inside on Stanford’s CS146S course, “The Modern Software Developer”; the lecture recording appeared on YouTube on 11 October. Robinson came from Cursor, which SpaceX agreed in June to buy for $60 billion, and at SpaceX he now builds Grok Bot, an app where AI “bots” work on a cloud computer while you get on with your own things. This isn’t a product ad but a breakdown of its architecture: how an AI agent of this kind works, what building blocks it’s made of and which engineering techniques make it reliable, cheap and unobtrusive. Some of what he talks about is, by his own account, still in development. Here are the main points.
Four eras of working with AI
Robinson divides recent history into four eras. In the first, code was copied out of ChatGPT and pasted into the editor by hand. It feels like that was decades ago, but in fact it was a few years.
In the second era, the model started editing files and running terminal commands by itself. Inside there’s a simple loop: the model calls a tool, looks at the result and decides what to do next. The program around the model that runs this loop, passes messages to the model, gives it tools and executes commands is called the harness. That’s the word used below.
In the third, agents got apps of their own, people started running several of them in parallel, some in the cloud. But the person remained the bottleneck: they confirmed every terminal command themselves.
The fourth era is always-on. The agent has its own computer and its own memory, learns new skills on the job and doesn’t stop when you go to bed.
The conversation with the agent itself has changed too. Before, you gave it a task and waited, and pressed “allow” or “deny” for every command. Now you can steer the agent as it goes: “look at this thread”, and a second later, “oh, do it on Thursday”. Earlier models got confused by this; today’s understand that the second message refines the first.
Manual confirmations are giving way to auto-review: a separate model checks commands before they run. Robinson is sure that in a blind comparison the reviewer model would more often turn out to be more careful than a person, who gets tired after a hundred approved commands and presses “yes” without looking. Models have got smarter and the interface simpler: working with an agent has come down to messaging, as you would with a colleague in a chat app. Everyone knows how to message, and that, Robinson believes, is the main reason such products are gaining popularity so fast right now.
Six things models have learned to do
Always-on agents became possible thanks to several shifts in the models themselves. Robinson names six.
- They keep following instructions for a long time. With the right compression of the conversation, a model works confidently for hours and days without losing track.
- They delegate work. The main agent hands separate tasks to helpers, subagents, and gets the result back from them.
- They call tools reliably. A couple of years ago models got calls muddled and made things up all the time. Robinson believes the hallucination problem has largely been solved. That’s his assessment: he gives no figures in the lecture.
- They work with powerful tools. Not just commands and files, but a whole Linux computer, recording demo videos and computer use, the ability to click around a screen like a person. That means the agent can work with many websites and services that have no API or MCP server, the ways programs usually connect to a service directly. Robinson goes as far as saying any such service, but in practice logins, CAPTCHAs, site restrictions and interface bugs get in the way.
- They keep knowledge in files. Models are excellent at searching files with ordinary Linux commands, so the agent’s memory is simply text files.
- They learn by example. Show the bot how to do a task, and it’ll turn that into a skill, a note or a routine so it can repeat it on its own later.
A skill is a Markdown file with instructions on how to do a specific task well. A whole ecosystem has already grown up around skills, and Grok Bot has plugins: ready-made sets of skills and connections to services. A routine is a prompt on a schedule, like a cron job. Robinson’s conclusion: the agent doesn’t need any special entities; it all comes down to an ordinary computer, with files, commands and a browser.
AI agent architecture: triggers, server, computer
Robinson’s diagram of an autonomous agent has three parts. On the left are triggers: what wakes the agent up. In the middle is the server, where the agent loop runs. On the right is the computer, on which the agent does hands-on work: files, commands, browser.
The agent sleeps until it’s called
“Always-on” doesn’t mean “always running”. At rest, both the agent’s server and its computer are asleep. A message comes in, and the server brings up the agent’s state. A browser is needed, and the computer wakes up. The work is done, and both go back to sleep, while the conversation, memory and routines are saved to a database. Keeping a computer switched on for every user is expensive, and there wouldn’t be enough computers in the world for everyone anyway.
It’s not only the owner who can wake the agent: a Slack message, an email, a call, a meeting. Robinson says that at SpaceX employees already send bots to meetings they can’t make themselves, and the bot listens and brings back notes. The agent is also woken by its own background work that has run for hours and finally finished.
All signals go through a router. It removes duplicates, decides which conversation to put an event into, and asks the key question: is it worth bothering the person? A colleague who comes over after every small step is irritating. Usually a report once a day is enough, depending on the task.
Its own computer in the cloud
The agent’s computer is a virtual machine on Firecracker, Amazon’s open technology for lightweight VMs. The state of such a machine is easy to save as a snapshot, switch off and later start again from the same point. The machine holds the agent’s files, and has a terminal and Chrome. You can connect to it, see what the agent is doing and take over control. In the Grok Bot documentation this is called Take over: the bot hits a login form on a website, you log in yourself and hand control back to it.
The agent’s commands run not on your laptop but on the cloud machine. If you have five or ten bots, each can have its own screen with a browser. But that isn’t a wall between them: according to the Grok Bot documentation, bots on the same account share a computer, and one bot can reuse browser login sessions left by another.
Why the agent’s brain lives on the server
The agent loop runs not on the VM but on the server. It’s the old “thin client, fat server” principle, and it has three advantages. The agent’s logic can be updated on the server straight away, without a new app version in the App Store. Heavy tasks like transcribing audio or generating images run faster on the server than on a phone. And the industry has long known how to scale servers for load spikes.
But the main thing is independence. If the loop lived on the VM, it couldn’t be switched off without killing the agent. As it is, the machine can be rebuilt at any moment, for example to urgently patch a vulnerability in Linux, and the agent won’t notice any downtime.
Why a server crash doesn’t reset progress
Say the agent is doing a three-step task, and the server crashes on the third step. With an ordinary task queue, all three steps start again from the beginning after the restart. A durable workflow saves the results of completed steps and carries on from the third after a failure. Grok Bot uses the open-source Temporal for this, so as not to build complex machinery from scratch. One caveat: a step that broke off in the middle may run again. So, as a slide from the lecture points out, steps are written so that a repeat is harmless; protection against, say, sending an email twice is something the developer builds in themselves.
Incoming messages have different priorities. If the owner writes “change the meeting date”, the agent interrupts the current step: the owner’s message matters more than anything else. Messages from group chats, Slack threads and background routines go to the back of the queue. And if several messages arrive in a row, the agent combines them into a single turn.
The agent harness: one tool for everything
One detail sets the Grok Bot harness apart from similar products: between the app and the server there’s exactly one tool, “write to the user”. Everything heavy lives on the server: commands, files, calling the cloud agent, screen recording. The app simply exchanges messages with the server, so a new client (mobile, desktop, email, Slack) connects without any rework.
The app, on the other hand, decides by itself how to show a reply. Robinson gives examples. The agent needs to log in to a service: the app can show a login form and bring in a password manager such as 1Password. A payment is needed: call a payment service, for example Stripe Link or X Money. The action is irreversible, an email or a Slack message for instance: show a draft that can be edited and approved. And sometimes the agent doesn’t need to reply at all: an emoji reaction is enough.
Tools on demand
A model has a context window: everything it sees right now, meaning instructions, the conversation, the results of its work. Its size is limited and counted in tokens, the pieces of words the provider charges for. Every connected tool takes up room in the window: a name, a description, a parameter schema. Connect Google Drive, Gmail and YouTube connectors, and a noticeable part of the window is taken before the conversation even starts.
That’s why popular harnesses show the model tool descriptions not all at once but as needed. At Anthropic this is the job of the tool search tool: it finds suitable tools and adds their descriptions to the context when they’re needed. Hermes Agent handles skills in a similar way: only a list goes in the prompt, and the agent opens the full text when a skill is needed.
A ladder from cheap to expensive
The general principle is to try the cheapest and most reliable way first, then move up:
- What the agent already knows from the conversation.
- A plugin, MCP server or API: for example, bank data through Plaid.
- A web search: say, the score of yesterday’s match.
- The browser on its own computer.
- The whole desktop: scripts, commands, building something on the Linux machine.
- Only if nothing has worked: ask a person.
That’s how a good colleague behaves: they don’t pester you over every little thing but try on their own first.
There’s a similar ladder when the agent works with a website in the browser. A screenshot is expensive. It’s cheaper to read the page’s HTML, and cheaper still to read the accessibility tree, a simplified list of buttons, links and fields that makes it easy to find where to click. If that doesn’t help either, say a modal window has popped up, the agent looks at a picture of the screen and clicks on pixels, like a person. The last rung is a person again: a two-factor authentication code or a CAPTCHA.
The lead and the helpers
The main agent works like a team lead: it keeps a task list, hands out work to helper subagents, checks them, writes to them and can stop them. Its own conversation has to stay as short as possible. A helper gets a clean working memory and runs a hundred commands, while the main agent gets only the answer, and all the rough work doesn’t clutter its context. That way the main conversation grows more slowly, and the agent runs into the limit of the context window less often. There’s no such thing as infinite context, but with techniques like these the product gives the impression that there’s enough of it for any long piece of work.
Each helper is a durable process too. If the video helper crashes or runs out of memory, it restarts and restores its work from the saved state. The whole scheme, Robinson admits, is copied from how you’d ideally scale a team of engineers on a hard task.
From the team’s practice he adds a few lessons. Tools shouldn’t be added or removed in the middle of a turn: it breaks the cache, which is covered below. Tool descriptions and schemas are better kept short: every word in them is paid for in every request. You can give the agent one tool, the terminal, and it’ll cope with almost everything. But if the model spends 90% of its time on commands for a single operation, it pays to make a separate tool for it: cheaper, and clearer for the people who review the agent’s work. And one more thing: error messages are worth writing as you would for a person, saying what broke and what to do next. It helps agents just as it helps people.
AI agent security: an email isn’t an order
An agent that works on its own for weeks has to be trusted, and Robinson lists what you’d ideally have in place for that. A separate model checks the agent’s commands, even on an isolated machine. An email in the inbox can turn out to be phishing, and a webhook, an automatic notification from another service, can be forged, and such data mustn’t be executed as the owner’s instructions. This is prompt injection, and according to Robinson the industry still has a lot of work to do here. Irreversible actions like sending an email are best agreed with a person first. And passwords and payment details are better kept out of the conversation with the model altogether; separate mechanisms are built into the product for them.
These are recommendations, not a built-in guarantee of any agent: what exactly is switched on depends on the product and its settings. We went through the same rules for a personal agent in the article on protecting an agent in group chats.
Why an AI agent is expensive: it all comes down to the prompt cache
Robinson says that context engineering and harness engineering are almost the same thing for him. That’s an exaggeration: as you can see above, a harness is also tools, routing, recovery from failures and security. But managing context is one of its main jobs: the less context the agent uses, the cheaper and smarter it is.
The main lever is the prompt cache. On every turn the agent sends the model the whole conversation again plus one new message. If the beginning of the request hasn’t changed, the provider takes it from the cache, and cached tokens cost several times less. So the system prompt and tool descriptions are kept unchanged, and you only pay full price for the fresh tail. If something at the beginning of the request has changed, the cache only works up to that point, and everything after it is paid for at full price. The cache can also simply expire if the agent has been quiet for a long time. Robinson suggests treating an unexpected miss as something like a bug: look for what broke the stable beginning of the request. The exact caching conditions differ from provider to provider.
He recalls January 2026, when OpenClaw took off and people were running it en masse on model providers’ subscriptions. The agents worked around the clock, harnesses didn’t yet know how to protect the cache, there were lots of misses, and quite a few fixes were needed.
The cost-saving techniques Robinson lists:
- long command output isn’t put into the context but saved to a file, and the agent reads the piece it needs itself;
- screenshots and other heavy work are handed to a helper, so as not to bloat the main agent’s context;
- anything unnecessary is regularly removed from the context, both for the sake of cost and so that the model recalls what matters better;
- prompt sections are kept in a fixed order: if the team is testing a new piece of the system prompt on some users, it mustn’t shift the others, or the cache breaks for everyone;
- the cache is warmed up in advance: you’ve opened the chat and started typing, and the server is already preparing the prompt, like a browser that preloads a page while you hover over a link.
The most elegant technique is to compress the conversation while the cache is warm. Sooner or later a long conversation hits the limit of the context window, say at 200,000 tokens, and has to be squeezed into a short summary. Any compression loses details, and a good algorithm here is a PhD-level problem. But the moment can be chosen wisely. Say your conversation with the bot has reached 100,000 tokens, and you’ve left. The provider’s cache doesn’t live long, from a few minutes to an hour. While it hasn’t gone cold, compressing the conversation is cheap, and Grok Bot does it straight away, without waiting for you to come back. Half an hour later you’ll carry on from a compact summary, and every new message will cost less. We’ve collected other places where agents quietly burn tokens in our token-saving checklist.
AI agent memory: three layers and files
What should the agent remember, and what can it forget? Robinson breaks memory down into layers. Key facts about the user go into every request: if a person likes writing in lower case, that has to be respected in every reply, otherwise one message with capitals will look odd. A log of past conversations is kept by date, like a colleague who writes down what they did each day: ask “what was I doing last week?”, and the agent will find the answer. Scratch notes help with the current task and aren’t meant to be kept long: they may be useful only for the next half hour or hour. Everything else sits in files, and the agent finds what it needs by searching.
Key facts need constant review: keep what matters today and remove what’s no longer relevant, like a garbage collector in programming. The brain works the same way: right now you’re not thinking about a football match, even though you remember it.
Hermes Agent is set up in a similar way: persistent notes sit in the system prompt in full, the archive of past conversations is available through search, and skills are loaded on demand. The details are in the breakdown of Hermes Agent memory.
The flywheel: the model learns from the product’s mistakes
Training a model happens in three stages. First comes pre-training: the model reads huge amounts of text and gets a general understanding of the world. Then supervised fine-tuning (SFT) on examples: it’s taught on exemplary dialogues to behave like an assistant or an agent. And reinforcement learning (RL), which is like training in a game where the model learns to win. For an always-on agent, at the SFT stage the model is shown how to work inside a specific harness and what tools it has. At the RL stage it’s taught to follow instructions, pick the right skill out of hundreds and put the cursor exactly where it needs to go.
How the model is served matters too. The main agent you message has to reply instantly. But for a helper working in the background for a long time, the difference between ten and twelve minutes no longer matters, and that’s where you can save.
The team improves the product in two loops. The short one is daily: the agent made a mistake, the mistake becomes a test task (an eval), the team fixes the harness, the prompt or the way the model is served on the servers, checks the fix on that task and rolls it out. The long one runs once a month or every few months: a new model is trained on the collected mistakes, shows better results on the same tests and goes into the product.
New models also open up new scenarios. For example, there’s almost no data on how bots behave in group chats: that behaviour is only just taking shape. Robinson mentions Moltbook, a social network for AI agents, as a reminder that many agents talking to each other can go wrong, and so models need to be taught this.
“Delete the product”
The principle Robinson brought from Cursor to SpaceX sounds like a provocation: “delete the product”. Today’s models are the worst we’ll ever have. That means in six months the interface may have to be built again from scratch. Almost everything he talked about would have sounded different six months ago. Hence the strategy: build for the next generation of models and do as little as possible, a simple interface through which the model thinks and acts for you.
What to expect in six months to a year
Robinson’s bets for the next 6–12 months are these. Agents will work not for hours and days but for weeks and months. Models will get better at recalling past conversations, through graphs, files or something else; research is going in different directions. A digital colleague will start getting the same tools as a new employee at onboarding: companies are only just getting used to this. Many people will simply talk to the agent by voice, possibly through gadgets like the one OpenAI and Jony Ive are preparing. And the agents themselves will learn to turn experience into skills and instructions, and companies will start writing down their processes so that an agent can read them.
There’s no shortage of open problems either. How do you test an agent that works for a month if new models come out every month? How do you protect the harness so the agent isn’t hijacked by attackers? When should the agent stay quiet, and when should it write first? “I see you missed yesterday’s class, here’s the recording and the notes”: is that care or intrusiveness? Robinson honestly admits there’s no perfect balance yet. And one more safe bet: in a year the world will be using far more tokens, so saving at every step will only matter more.
At the end, a thought about the market. People say all AI apps are the same: a sidebar, a chat, an agent. Robinson passes on the reply from Alex at OpenRouter: in 2005 everyone was also making “the same thing”, a server, a database, forms for creating and deleting records. It’s simply the new norm. Every product will either get an agent part of its own or become a data source for someone else’s agent. And each building block of an always-on agent (durable processes, sandboxes, cloud computers, memory, skills, connections to services, voice, payments, identity, quality checks, observability) is a separate market with twenty start-ups in it already.
Robinson’s advice to students is to understand the system’s architecture and read the code the agent writes: the consequences of architectural decisions only grow over time. And also to try building their own agent harness and to learn how language models work, just as it’s useful for a web developer to understand databases.
Details from the slides
These are Grok Bot’s settings, not a common standard for all agents, but they show well how such a system is put together in practice.
Computer. A Firecracker virtual machine, one per user, with Debian inside. A few minutes after the last activity, but never in the middle of a turn, it goes to sleep: files go to cloud storage, memory and disk are saved as a snapshot, and the machine stops. On the next tool call the snapshot is restored, and logins to services and installed programs stay in place.
Memory. The profile holds up to 100 facts about the user within 4,000 characters, and it’s always in the prompt. The 30 most relevant recent log entries go into the prompt. Notes fade quickly, and the agent finds everything else by searching memory. After each turn, a separate pass adds new facts and replaces old ones, and it can only delete the facts it was shown. Important facts move up, old ones gradually sink. Facts about you are shared by all your bots, but each writes to its own file. And the model is told plainly: memory is information, not instructions.
Security. A separate model checks risky actions before they run. If it blocks an action, you get a confirmation request, and if you haven’t answered within 15 seconds, the action is denied. Text from emails and webhooks is marked as untrusted. The bot doesn’t write to people until you’ve asked it to, and new routines need your consent. Passwords are kept in environment variables and don’t reach the model, and actions on your laptop need permission.
Compression. After a big turn, with a prompt over 100,000 tokens, about 10 minutes pass, the cache is still warm, and that’s when the summary is written. If background work will wake the agent soon anyway, compression is skipped. The agent’s last few messages to you are kept verbatim. And if a turn is too long, the conversation can be compressed in the middle too.
Cache and tools. Until the next compression, the tools, the system prompt and the first message don’t change by a single character. If a service update changes a tool description, a short note arrives in the ongoing conversation, not new text. An unavailable tool isn’t removed; it returns a clear error. The description and schema of each tool are no longer than 4,000 characters. And one more rule for the ladder of methods: if the connector to a service is broken, the agent shouldn’t get around it through the browser; it should say so and ask.
How to build a personal AI agent right now
Grok Bot is a closed product, included in the paid SuperGrok and Cursor subscriptions. But many of the building blocks from the lecture exist in open tools too. My personal agent runs on Hermes Agent on a rented server, I message it in Telegram, and it already has many of the techniques from the lecture:
- routines are cron jobs; how they break without anyone noticing and how to avoid that, I covered in the article on hermes-cron;
- skills are the same Markdown instructions; where to find them and how to vet them is covered in the overview of skills and plugins for Hermes;
- the nightly memory clean-up in my agent is done by the hermes-dreaming plugin, and since version 3.3 its fact confirmations can be double-checked by a cloud judge;
- where to start: with the guide to installing Hermes and connecting it to Telegram.
And three rules from the lecture worth applying to any agent today. Everything irreversible (emails, payments, posts) the agent prepares as a draft, and you send it. Emails and other people’s messages are data, not commands. And don’t demand a report on every step from the agent: a good colleague writes when there’s something to say.
FAQ
What is an autonomous AI agent, in plain words?
It’s an AI agent that keeps working without an open conversation: it runs tasks on a schedule and on events (an email, a message, a meeting) and decides by itself when to write to you. Usually it lives on a server for this, and in the architecture Robinson breaks down, it also has memory and a cloud computer. In English such agents are called always-on.
How is an AI agent different from a chatbot?
A chatbot answers questions. An AI agent carries out a task: it calls tools by itself (commands, the browser, email, services), looks at the result and decides what to do next. An agent in the terminal, the way Claude Code or Codex is usually run, works as a process on your computer: the laptop goes to sleep, and the work stops. An autonomous agent needs an environment that works without you: it survives failures and restarts, and it’s not only your messages that can wake the agent.
What is Grok Bot and who can use it?
It’s an app from SpaceXAI and Cursor: the beta came out on 11 August 2026. You give the bot a task in a chat or by voice, and it works on a cloud computer with a browser and a terminal. According to xAI as of 26 August, Grok Bot is included in the SuperGrok, SuperGrok Plus, SuperGrok Heavy, Cursor Pro, Pro+, Ultra and Cursor Teams subscriptions, and there’s a waiting list for large enterprise deployments. You sign in with a Cursor account.
Why does an agent need subagents?
So that the details of separate tasks don’t take up the main agent’s context. A helper does the heavy work in its own clean working memory and returns only the result, so the main agent works longer without compression and loss of detail.
Why can an autonomous AI agent be expensive?
On every turn the agent sends the model the whole conversation again. If the beginning of the request changes, the cache doesn’t work, and you have to pay full price for the whole context. What helps: an unchanging system prompt, short tool descriptions, long results in files instead of the context, subagents for heavy work and compressing the conversation at the right time.
Is it safe to give an AI agent access to email?
It’s best to start with reading and preparing drafts. If the product can check the agent’s actions with a separate model, switch that on, and allow sending emails only after your confirmation. The agent should treat incoming emails as data, not instructions: according to Robinson, the industry still has work to do on protection against prompt injection. Which of these protections exist and are switched on depends on the particular agent and its settings.
