We Stopped Giving Agents Computers. We Started Hiring Them.

For about a year, our whole story fit in one sentence: give every agent a real computer.

It was a good sentence. It was even the right one. While the rest of the industry was wiring agents into ephemeral containers and 30-second serverless functions, we handed each one a genuine cloud machine — a filesystem, memory, a network, state that survives. We wrote essays about it. We called the computer a primitive, and it is.

But a primitive is a starting point, not a destination. And after watching people actually live with these machines for months, we noticed something. The computer was powerful and completely anonymous. You would open a fresh agent, give it a box, type a prompt, and a brilliant stranger would do excellent work and then evaporate. The next morning you did it again. Same brilliance, no memory of yesterday, no name, no place in your team. It was like running a company entirely on day-laborers who happen to be geniuses — and forgetting that the thing companies actually do is hire people.

A computer is something you give. An employee is someone you hire. This post is about the day we stopped doing the first thing and started doing the second.

The thing we kept bumping into

The tell was always the same small moment of friction. You would get an agent set up just right — the correct instructions, the right tools mounted, the context loaded, a computer warmed up — and it would do something great. And then you would want to use it again tomorrow, for a slightly different task, and there was no "it" to come back to. There was only the box and the prompt. Every session started from zero.

People worked around this the way people always do. They saved prompts in notes. They copied the same setup into a new task. They kept a mental map of "the agent I use for the deploy stuff" that existed nowhere in the product. The product modeled a computer. The user was modeling a coworker. That gap was the whole problem, and once we saw it we couldn't unsee it.

So we asked the obvious question: what would it take for the thing you come back to tomorrow to actually be a someone, not a something?

What turns a tool into a teammate

It turns out the gap between "an agent with a computer" and "an employee" is made of four very ordinary things. None of them is exotic. All four together change what the thing is.

A name

This sounds trivial and it is not. The moment a worker has a name, you can refer to it, route work to it, and remember what it is good at. "Ask Mira to pull the weekly numbers" is a different mental operation than "open a new task, paste the analytics prompt, attach the database context, and wait." A name is the handle that lets a thing persist in your head and in your team's vocabulary. Everything social about work runs through names.

A profile

A profile is who the employee is when no one is typing at it: its role, its standing instructions, its tone, the boundaries of what it should and shouldn't do. This is the part that used to live in a prompt you re-pasted every morning. Now it lives on the employee. The deploy specialist always knows it is the deploy specialist. The researcher always writes the way you taught it to. You configure the person once, not the task every time.

A computer

This is the primitive we already believed in, and it does not go away — it gets an owner. The employee has its own machine: a real cloud computer with a filesystem and persistent state that belongs to that employee. Its work, its installed skills, its working files, its history — they live somewhere that is durably theirs. The computer stopped being a disposable box you rent for a task. It became the desk a specific coworker sits at.

An identity

This is the one that quietly makes everything else real. An employee has its own identity — its own credentials, its own scoped access, its own connected accounts. It can be granted exactly what it needs and nothing more. It can act in your systems as itself, and you can see what it did, as itself. An anonymous prompt that borrows your keys is a script. A worker with its own identity, scoped and auditable, is a member of your organization. That distinction is the difference between "a clever automation" and "someone you can actually trust with the company credit card."

Name, profile, computer, identity. Snap those four together and the noun changes. You are no longer holding a tool. You have hired a coworker.

And then you give it work

Here is where the reframing earns its keep. Once the worker is a real, persistent employee, assigning it work becomes the most natural thing in the world — exactly the way you would hand a task to a human colleague.

You can talk to it. Open the employee, describe what you need, and it goes to its computer and does the work — then comes back when it is done, the same way you would tap a teammate on the shoulder and check in later. The task lands on a specific desk, owned by a specific worker who already knows its job.

Or you can assign work through the API. The same employee, the same identity, the same computer — addressed by a program instead of a person. A webhook fires and your researcher gets a task. A nightly job hands your analyst the day's numbers. Your error tracker files a bug straight to the engineer. It is the same coworker either way; you have just opened a second door into their office. A human walks in through one, your systems walk in through the other, and the worker on the other side does not care which door the work came through.

This is the part we find genuinely lovely. The moment the unit is an employee rather than a session, "assign a task" stops being a UI concept and becomes an organizational one. You are not launching jobs. You are delegating to staff — and your staff happens to be reachable by API.

One employee becomes a team

The second you can hire one, you can hire several — and the interesting thing is that they don't blur together, because each one has the four things that keep it distinct. A name to call. A profile that holds its role. Its own computer, so its files and history don't bleed into anyone else's. Its own identity, so it can only touch what it is supposed to touch.

So you end up with something that looks less like a control panel and more like an org chart. A researcher who knows your sources. An engineer who owns a repo. A deploy specialist who is the only one allowed near production. An analyst the rest of your systems hand numbers to on a schedule. Each is specialized, each stays specialized, and routing the right ask to the right employee becomes the actual skill — the same skill any manager already has.

None of this required us to invent a new abstraction. It required us to stop inventing one. Companies already know how to organize work: you hire people, you give them roles and access, you assign them tasks, you trust them within a scope. We just made the "people" be AI, and kept everything else exactly as familiar as it already was.

The bet

We used to say the unit of AI work is the computer. We were close. The computer is the body. What was missing was everything that makes a body a someone — a name to call it by, a role it holds onto, a desk that stays its own, an identity it can act and be accountable through.

Our bet now is that the durable unit of AI work is not the prompt, and not the session, and not even the computer. It is the employee. The teams that get the most out of AI won't be the ones with the cleverest one-off prompts. They'll be the ones who built a real staff — coworkers with names and identities and their own machines — and then simply did what every good organization does: handed them work and trusted them to do it.

You don't rent a computer to an agent anymore. You hire someone, give them a computer, and get back to running the company.