Managing AI Workers Like a Team

There is a difference between using AI and managing AI. Using it looks like a chat window: you ask, it answers, the tab closes, and nothing is left behind. Managing it looks like a roster: a named role, a job with a definition of done, a record of what happened, and a decision waiting for you at the end.

That second shape is what we are building toward with Works, our AI employee management system. It is in development, and it is deliberately organized like a team rather than a conversation. Here is what changes when you make that switch, and what it costs you.

Why the chat window stops scaling

A chat window is excellent for thinking out loud. It is a poor container for recurring work. The same three problems show up every time someone tries to run real operations through one.

• Context has to be rebuilt every session. You paste the same background, the same file, the same tone rules, and you get slightly different results because you paraphrased yourself differently.
• Nothing accumulates. There is no place the work lives between sessions, so improvements you made last week exist only in a transcript you will not go find.
• There is no record. If someone asks what the AI did on Tuesday and what it changed, you are scrolling.

None of that is a flaw in the model. It is a flaw in the container. A chat window was never meant to be a system of record, and asking it to be one is how you end up with work you cannot audit.

An employee is a role, not a prompt

In Works, an employee starts with a sentence. You describe the work you want off your plate, and the connected model drafts a name, a role, and a set of instructions. You watch the draft come together, and then you edit it before the employee exists.

The editing is the point. The draft is a fast first pass at a job description, and a first pass at a job description is almost never right. You are the one who knows that the report goes to the shop foreman and not the office, that the client hates bullet points, that Friday numbers are always provisional. Writing that down once, as standing instructions, is what stops you from re-explaining it every time.

You can also give an employee a workspace: notes, instructions, and text files that sit alongside the job it is meant to do. The reference material stops being something you paste and starts being something the role has.

A definition of done is most of the work

The hard part of delegation has never been describing the task. It is describing what finished looks like, precisely enough that someone else can hit it without you in the room. That is true for a new hire and it is true here.

Before you assign anything, we would push you to write four things down:

• Inputs: what the work starts from, and where that lives.
• Output shape: the format, the length, the file it lands in. "A summary" is not a shape. "Five bullets, one per job, in this doc" is.
• Boundaries: what the employee should not touch, change, or send.
• Escalation: what it should do when the answer is unclear, which is usually stop and say so rather than guess.

If you cannot write those four for a task, the task is not ready to hand to anyone. AI does not fix an unclear assignment. It executes it faster, which is worse.

Watching work instead of waiting for it

Once work is assigned, you want to see it. Works records actions, results, and run history, and lets you follow activity as it happens, so there is a difference between "running," "finished," and "waiting on you." You can give employees individual tasks or configure recurring work.

The same problem shows up one level down, with terminal sessions. If you are running several CLI workers at once, you become the polling loop: you tab between windows, read scrollback, and try to remember which one was blocked. Works can connect supported CLI sessions and bring their activity into view, where its manager collects progress, surfaces blockers, and prepares briefings.

That is the real shift. Not that the work gets done without you, but that you stop hunting for the status of it. Attention goes where something is stuck rather than where you happened to look.

The review step is the one that matters

You can pause employees, and you can review proposed file changes before they are saved. We consider that the most important behavior in the product, not a safety footnote.

Our rule of thumb for what should never land without a human: anything that costs money, anything that leaves the company, and anything that is hard to undo. Sending the email, issuing the credit, deleting the records, pushing to production. The value of an AI worker is in the ninety percent of the job that is assembly, not in the last click that commits you.

The same separation applies to desktop control. Relay, our window automation tool, lives inside Works, and you operate it directly. Opening Relay in the workspace does not automatically hand every employee control of your desktop. Those are two different grants and we keep them that way on purpose.

What you are actually signing up for

A few honest constraints, because they shape what this is good for.

Works is currently a local application. Employee configurations, workspace files, and run history live on your machine, and tasks and schedules run while the Works runtime is running and the machine is awake. That is a real limit. It is not a cloud service quietly working through the night while your laptop is shut. In exchange, the record of what your team did is yours and sits where you can see it.

You connect a compatible model. If you choose a cloud provider, that provider receives the prompts and workspace content used for that work, which is a good reason to be deliberate about what you put in a workspace. Connected CLI workers use their own model connections and permissions, separate from the employees you create.

Managing is still managing

The tooling does not remove the management work. It makes it visible. Clear roles, written standards, a record you can inspect, and a person who decides what ships are the same four things that make a human team function, and they do not become optional because the worker is software.

If you want to try this, do not start with the job you understand least. Start with one you already do well enough to grade, where you would notice immediately if the output were wrong. Give it a clear definition of done, watch a few runs, and keep the review step. If that goes well, add a second job.

Works is in development. If there is a workflow you would want on that roster, tell us about it.