One Person, One Agent

From six months of hands-on Hermes to Dots, Muse, and TraeWork, I've come to believe more and more that what an agent really needs is not a chat box, but a long-lived running instance.

At a glance

Since the start of this year I've been using OpenClaw and Hermes constantly. Later, when we built a multi-user agent product, we went with "one Hermes instance per user." Recently Dots, Muse, Grok Bot, Manus, and the domestic WorkBuddy, QwenWork, and TraeWork have all been pushing the agent out of the chat window and into a working environment that persists.

I've come to believe more and more that the point of a persistent agent isn't the Cloud Computer at all. It's whether Identity, Memory, Files, Permissions, Tasks, and Runtime can all persist together, long-term. The PC era was one computer per person; the mobile internet era is one phone per person. In the agent era, it will very likely become: one person, one agent.

At the start of this year I began using OpenClaw and Hermes fairly heavily. At first, of course, I was still treating them as agent frameworks: wire some tools up to the model so it could read files, run Shell commands, call search, execute Skills, then give it some memory so it wouldn't treat every startup as our first meeting.

The longer I used them, the more I noticed my own way of using them changing. I stopped just opening a chat window, asking my question, and closing it again. I started handing whole things over to Hermes. The project sits there, the files sit there, the Skills sit there — I come back after a while, and it still knows what it is doing.

Later, when we were building our company's multi-user agent product, we made a design decision that looked a bit "heavy": every user runs their own Hermes instance. Not everyone sharing one agent with a user_id stuffed into the prompt, but genuinely one per person.

At the time I didn't think of it as any particularly special product idea — it was mostly for engineering reasons. Different users have different files, memory, permissions, Skills, configuration, and tasks, and cramming all of that into a single agent made a lot of things more complicated rather than fewer.

But over the past month, going back over some of the new products on the market, I suddenly noticed that everyone seems to be heading in roughly the same direction. Just by different routes.

Why We Ended Up With One Hermes Per Person

Multi-user in traditional SaaS is easy to understand. There's one backend service, shared by everyone. Every row in the database carries a user_id, the file system is isolated by tenant, and the permission system decides what you're allowed to see. Early AI chat products were basically the same: you send a prompt, the backend calls the model, the model gives you an answer. Even once chat history was added, it was still fundamentally a Request / Response service.

But once agents started actually doing things, it got a lot more complicated. An agent doesn't only have chat history. It may have its own working directory, with the project it's currently handling inside it; it may have Skills installed that belong to that one user; there may be a service already logged in inside its browser; its Memory may hold everything the user has accumulated over a long stretch of time; and there may be tasks running right now, or a few waiting to pick up tomorrow.

At that point, what a user corresponds to is no longer a few rows in a database. It's closer to a working environment that is running.

That is largely why we ended up running a separate Hermes for every user:

User A
  ↓
Hermes A
  ├── Memory
  ├── Files
  ├── Skills
  ├── Profile
  ├── Credentials
  └── Tasks

User B
  ↓
Hermes B
  ├── Memory
  ├── Files
  ├── Skills
  ├── Profile
  ├── Credentials
  └── Tasks

The large language model underneath can of course be shared, and GPUs, inference services, search, RAG, ASR, TTS — all of those capabilities can be built as shared services. But that agent state layer on top, I'm increasingly unwilling to share.

So what I now mean by "one person, one agent" is not that everyone gets their own GPU, and not that everyone really needs a physical computer. It's that every person needs an agent state space of their own.

Big Tech Has Started Giving Agents a Place to Live

On September 29, OpenAI released Dots. The official description of a Dot is very direct: it's an always-on agent that can keep pushing work forward between two conversations, has its own Cloud Computer, can connect to apps, and retains the context a long-running task needs.

That's a big difference from ordinary ChatGPT conversation. Ordinary chat is still fundamentally "you come to me," while a Dot starts to become "this thing is your job from now on."

Meta got there a bit earlier, releasing Muse on September 8. Behind Muse sits a Secure VM: a persistent, isolated Linux virtual machine with a full browser. Meta's description of it is also interesting — "a computer you share with your agent," with the files, the browser, and the compute all persisting long-term.

xAI's Grok Bot goes even more directly. Officially they call it always-on agents. The bot has a browser, a file system, and a terminal; it can keep working after you've closed your laptop, and it can hold long-term context — it can even save a workflow you demonstrated into a Skill and run it again on a schedule.

Manus is heading the same way, and more visibly. It launched Cloud Computer in June this year, turning the temporary Sandbox that used to be destroyed once a task ended into a persistent, always-on virtual environment. By Manus 2.0, Cloud Computer, Automations, Remote Control, and Agent Team have been combined together even further.

If you only look at the product names, these things look nothing alike. Strip away the UI, though, and the same things are starting to appear underneath: the agent has its own files, browser, long-term state, account permissions, tasks, and scheduler — and it keeps running after you leave.

This is no longer the old "bolt a few Tools onto an LLM" idea.

China Is Walking the Same Road

A few products out of China recently have been pretty interesting too.

Tencent's WorkBuddy leans more toward local. Once authorized, it can read and operate on local files directly, plan and execute tasks on your own machine, and it supports Skills, MCP, multiple tasks, and multi-agent collaboration. Tencent's own description of it is no longer a chatbot but "a desktop workbench."

QwenWork Office is yet another shape. It puts Workspace, files, Connectors, Computer Use, and scheduled tasks together. The scheduled tasks in particular feel like a pretty key change: once you close the browser, the task can still run in the cloud on schedule. The official line is blunt about it — from "it moves when you ask it to" to "it gets to work on its own at the appointed time."

TraeWork may be the one that best embodies this local-plus-cloud shift among all of these recent products. The desktop version can run locally or run in the cloud; the web version is itself in the cloud. The phone is more like an agent scheduler, managing tasks in the cloud and across several of your personal computers. Once a device goes offline, tasks can switch over to the cloud and keep running, with task state synced across phone, web, and desktop.

Getting to this point, I actually noticed an interesting distinction: some products are giving the AI a computer, while others are letting the AI move into mine.

The Cloud Computer in Dots, Muse, Grok Bot, and Manus is closer to the first kind; the desktop capabilities of WorkBuddy and QwenWork are closer to the second; and TraeWork is clearly trying to connect the two.

My own way of using Hermes has also leaned toward the second kind all along. A lot of things happen directly on my own machine — files local, Skills local, and the model can be local too. But the two routes end up solving the same problem:

An agent has to live somewhere.

The Cloud Computer Isn't Really the Point

A lot of products have recently started emphasizing Cloud Computer, and it's easy to come away thinking the next stage of agents is "hand every AI a virtual machine." I don't think it's that simple.

A virtual machine is just one relatively easy-to-understand implementation. What actually matters is whether the agent can keep all of these things long-term:

Identity
   ↓
Memory
   ↓
Files
   ↓
Skills / Tools
   ↓
Credentials / Permissions
   ↓
Tasks / Goals
   ↓
Scheduler / Events
   ↓
Runtime

It can run in a VM, a container, a local process, or some kind of controlled sandbox. The form of the implementation isn't the point. What actually changed is this: these things are starting to bind to the agent, rather than to any single conversation.

Before, when I opened an AI product, what I usually faced was a "capability." I want to write code, so I call up Codex; I want to search, so I call up Search; I want to analyze a file, so I throw the file in. Once the task is done those capabilities are still sitting there, but "the thing that was doing the working" is gone.

A persistent agent is the other way around. The model underneath can be swapped, the browser can be swapped, the search tool can be swapped — but the agent itself is still there. It remembers this project, it knows how far it got last time, the files are still where they were, and a tool you authorized yesterday can still be used today.

That is the change in these recent products that I actually find interesting.

The Real Trouble Is Whether a Task Can Keep Going

A few days ago I was using Codex on an AI Infra comic project, and a task got halfway through before I ran out of quota. My first reaction at that moment wasn't "when does the quota come back." It was a different question:

Why can't it just wait for the quota to come back and pick up where it left off?

The task itself didn't disappear. The code is still there, the todo list is still there, the goal hasn't changed. The only thing that changed is that it can't call the model right now.

For an agent that genuinely lives long-term, this should really only be:

RUNNING
   ↓
RESOURCE_UNAVAILABLE
   ↓
WAITING
   ↓
RESOURCE_AVAILABLE
   ↓
RUNNING

and not:

RUNNING
   ↓
Chat ends

That's also the feeling that kept growing on me a few days ago while I was researching Paperclip and going back over things like /loop and /goal in Hermes.

If an agent is just a chat product, then "exiting the chat" is a perfectly natural boundary. But the moment I hand it a goal, the chat should no longer be the lifecycle. The goal should be.

Once You Actually Build It, the Problems Are Very Old-Fashioned

Of course, "one person, one agent" sounds great. Once you actually build it, you run into a lot of very old-fashioned problems.

After one chat request ends, the server can basically release its resources. An agent that lives long-term — when does it count as "no longer needed"? A user goes quiet for ten minutes: do you stop it? Once you stop it, where do the Memory, the files, and the task state go? And what about tasks that are still running? When you bring it back up the next day, how do you restore the previous state?

Once there are more and more agents, these stop being only LLM problems and start becoming process management, task queues, resource scheduling, permissions, isolation, persistence, failure recovery, and cost accounting.

Memory is no different. An agent that really stays with you for months or years obviously can't start from zero every time — but "remember everything" is equally wrong. Projects end, preferences change, and yesterday's information may already be stale today. If everything just keeps piling into Memory, the agent may not end up understanding you better. It may just end up messier.

So what a long-lived agent really needs is not an endlessly growing chat log, but an information system that can update, prune, archive, and reorganize. That problem is nowhere near solved — and I'm still experimenting with it constantly myself every time I use Hermes.

Local and Cloud Will Probably End Up Blurred Together

A cloud agent's biggest advantage is obvious: it's always online, and it doesn't matter if you shut your computer. But a local agent has its own advantages, because a lot of my things are on the computer to begin with — code, photos, documents, Git repos, dev environments, ComfyUI, and all the scripts and tools I've written myself.

If, just to get an agent to do one task, you first have to upload all of that to some other cloud computer, sometimes you've gone around in a circle.

A few weeks back I ran a local Qwen3.8-27B, attached Qwen-Image 2.1, and had the agent generate picture books and comics by itself. Before, I operated the software and made the images one by one. Now it's more like handing the task to the agent and checking in every so often on how far it's gotten.

Looking back, I think this is the same thing again: the local image model is just one of its Tools, the LLM is only one component, and what's actually valuable is the agent that keeps existing.

So the future probably won't be a choice between a Cloud Agent and a Local Agent. The more likely outcome is: tasks that need to be online long-term go in the cloud; anything involving large local datasets, privacy, or local software stays on your own computer; and the phone turns into a control entry point.

TraeWork's current "computer + cloud + phone as scheduler" shape, I think, already shows a hint of that direction.

From "Feature" to "Instance"

Writing to this point, I think I can go back and answer a question: what exactly is new about these recent agent products?

If it's only Browser Use, Shell, MCP, and Skill, then none of it is new. Open-source projects like OpenClaw and Hermes have been doing it for a long time, and I've been using them myself since the start of the year.

What is actually starting to change is that the product is slowly moving from:

"There's an agent feature here."

to:

"There's an agent of your own here."

Those two look like they're only a few characters apart, but the system design behind them is completely different. The first is a capability; the second is an instance. A capability can be called and replaced at any time. An instance leaves history behind, accumulates state, and can keep working while you're away.

So now when I look at Dots, Muse, Grok Bot, Manus, QwenWork, WorkBuddy, and TraeWork, I find myself not particularly agonizing over which one has more features or which model has a higher Benchmark.

The underlying model still matters, of course. But from here on, whether an agent is good to use will probably depend more and more on some other things: where it lives, what it remembers, what permissions it holds, whether it can keep working while I'm away, whether it can recover when something goes wrong, and whether, when I come back, it still knows how far it got.

None of that used to look like AI at all. Now it increasingly looks like the core of an agent.

One Person, One Agent

After the personal computer appeared, it slowly became one PC per person. After the smartphone appeared, it became one phone per person.

I don't know whether the future really turns into "one AI computer per person." Physically, maybe not — one server can perfectly well carry a lot of agents, and a local computer can run several instances at once.

But logically, I've come to feel more and more strongly: one person, one agent will probably hold.

It has its own memory, files, permissions, tasks, and running state. You can swap the model, you can add new Skills, you can move to a different computer — but the agent itself is still there.

When I started using Hermes at the beginning of this year, I honestly hadn't thought this far. At the time it just seemed that an agent which could read files on its own, run commands, and call tools was already pretty fun.

After half a year of using it, my focus has slowly shifted from "what can it do" to:

Can it stay alive.

The changes in these recent products only made me more certain of this.

---

References

• OpenAI — Getting started with your dot
  https://help.openai.com/jv-id/articles/20001530-getting-started-with-your-dot

• Meta — Muse
  https://ai.meta.com/muse

• xAI — Grok Bot Overview
  https://docs.x.ai/grok-bot/overview

• Manus — Cloud Computer
  https://help.manus.im/en/articles/15392111-what-is-the-cloud-computer

• Tencent WorkBuddy — Product Guide
  https://www.workbuddy.cn/docs/workbuddy/From-Beginner-to-Expert-Guide/Product-Guide

• Alibaba Cloud QwenWork — Computer Use / Scheduled Tasks
  https://www.alibabacloud.com/help/zh/qwenwork/computer-use

• TraeWork — What is TraeWork
  https://docs.trae.cn/work_what-is-trae-work