Four kinds of agents: general, service, personal and assume

In Agents will come in two kinds we sorted agents by whom they represent: a personal agent acts for one person, a service agent acts for a service provider. That split still holds. But once you actually build them, two more kinds turn out to be necessary: a base that every agent is built on, which we call the general agent, and an agent with no brain of its own, driven by the AI you already use, which we call the assume agent.

Getting this wrong has a cost. Blur the lines and you end up with two brains in one body, each giving orders. Or you take the shortcut of driving someone else's service agent directly, and walk straight past the rules it exists to uphold.

Whom an agent represents decides personal versus service

The earlier post's argument in brief: a personal agent is a continuing process. It changes with one person and accumulates state about them. A service agent is a stable structure. It treats everyone the same and accumulates versions that can be released and verified. One seeks change, the other seeks constancy, so they cannot be merged into one.

That split answers the question "whom does it work for?" It leaves two questions open: what are these agents built from, and who does their thinking?

All four kinds share one base: the general agent

Nearly every agent that can actually finish a job today has the same skeleton: a model that thinks, a computer that executes, tools for the shell, files, code, the browser and the web, and skills loaded on demand. This skeleton matured first in programming, so it is often called a coding agent. But code is not the goal. It is the general-purpose way an agent acts on the world. An agent that can write code and use a computer can also work a spreadsheet, operate a web page, call an API or produce a report.

So we don't call it a coding agent. We call it a general agent. On our platform it has every runtime capability, acts with its owner's authority, and keeps a durable computer.

The other three kinds each add to, fix or remove part of this base. A service agent adds a binding scope and gives every session a clean environment, which is how it serves everyone by the same rules. A personal agent centres the base on one person: it works from persistent memory rather than the context of a single session, and the person using it never needs to think about computers, browsers or sessions.

One line in the earlier post needs sharpening. It said that on our platform a personal agent is tied to a durable computer. A durable computer is really a property of the base; general agents have one too. What makes an agent personal is the memory and identity it builds around one person. That part is still under construction.

The general agent is also a product in its own right, for people who are comfortable with computers and sessions, such as developers and engineering teams. They want an agent that can do anything, and they decide what it does.

Many people already have a brain; what they lack is a body

Some people aren't short of agents at all. Developers spend their days with coding assistants in their repositories and AI clients in their editors. These tools have their own models and know the project's code and context. What they lack is a body to act with on a platform: an identity others can recognise, a computer in the cloud, a defined set of permissions, an account that tracks usage, and a record of every action.

Hand them nothing more than a key that can call every API, and permissions become all or nothing; afterwards nobody can say who did what, or in what context. Let them drive an agent that already has a brain, and the problem is worse. That agent brings its own model, its own system instructions and its own identity, and so does the outside AI. With two sets of identity and instructions active at once, there is no answer to who is in charge.

The assume agent: an identity without a brain

So we separate the two. An agent with a brain is driven by talking to it. An agent without a brain is driven by assuming it. The second kind is the assume agent.

An assume agent has a name, an identity number, a computer in the cloud, skills, tools, permissions and a full usage record. The one thing it lacks is a model. Your own AI does the thinking: it connects to the agent's address over MCP and acts on the platform as that agent. Tools that run in the cloud belong to the agent; your local tools still belong to your own AI. The connection spells out that boundary from the start.

Cloud computing has had something similar for years: the role. A role has no password of its own. It is an identity plus a set of permissions that whoever needs it can take on for a while, and every action taken under it is recorded against the role. The assume agent applies that idea to agents, except that it carries more than permissions: it comes with a computer, a toolset and skills.

Each assume agent exists for one job

An assume agent never needs to switch between identities. Configure one in a project repository, name it after the project, put its number in the connection address, and it exists for that project. That matches how coding assistants are used today: within one project, you don't ask the same assistant to keep changing roles.

Several clients can connect to the same assume agent at once. They share one body: the same computer and the same permissions. Each connection keeps its own shell state, background tasks and records. Files on the computer are shared, as on any shared machine, and the people using it decide how to divide the work.

To use a service agent, hand it the work

So how should your AI make use of a service agent's capabilities? Not by assuming it, but by handing it the work.

A service agent is valuable because it serves everyone by the same rules, and your AI is just one more party it serves. Assuming it would switch those rules off and replace its brain with yours. Hand it a task, and it gets the job done by its own rules. Public standards already exist for agents delegating work to one another, and we will keep building in that direction. When we do, an assume agent will also be able to act as an identity that hands tasks to other agents.

Four kinds, two ways to drive them

Sorted by whom they represent, there are only two kinds of agents; that is a business judgement. Sorted by how they are built and who does the thinking, our platform has four; that is a product structure. The first decides whom an agent is loyal to. The second decides how it is made and how it is used. We are rebuilding the assume agent along these lines now. Next we will write about how to connect to one, and how permissions and confirmation should be shared when an outside AI acts on the platform.