AI agent vs AI worker: where the line is
An agent is the category. A worker is an agent configured for one job it does unattended. The difference is who starts it, and it changes what you build.
"Agent" has been stretched to cover a chat window with a search tool and a system that files your invoices overnight. Those are not the same thing, and the line between them is sharper than the vocabulary suggests.
The short version: **an AI agent is the category. An AI worker is an agent set up to do one specific job unattended.** The distinguishing question is not how capable it is. It is who starts it.
Three things people call an agent
| Assistant | Agent | Worker | |
|---|---|---|---|
| Starts | You type | You type | A schedule or an event |
| Scope | Whatever you ask | Whatever you ask, with tools | One job, written down |
| Tools | Usually none | Yes | Yes, at a granted level |
| Identity | Yours | Yours | Its own key |
| Memory | The conversation | The conversation | Facts carried between runs |
| Output | Text to read | Work in a sandbox or your apps | Work in your real accounts |
| Record | Transcript | Transcript | A receipt per run |
The middle column is where most products sit today, and it is genuinely useful. The jump that matters is the third column, and it is a jump rather than a slope.
The test
Ask one question of anything calling itself an agent:
If nobody opens anything tomorrow, does the work happen?
If no, it is an assistant or an agent. If yes, it is a worker. Everything else, model quality, tool count, reasoning depth, is orthogonal. A brilliant agent that waits for you is still waiting.
This is worth being pedantic about because the answer determines what you have to build. An agent needs a good model and a good tool surface. A worker needs three more things, and they are the hard part.
Putting a number on the difference
The distinction sounds philosophical until you count the initiations. Take one job, done hourly across a ten hour working day, for a year:
| Assistant or agent | Worker | |
|---|---|---|
| Times the work happens | Only when you start it | ~2,600 runs a year |
| Human initiations required | ~2,600 | 1, at setup |
| Happens while you are on holiday | No | Yes |
| Happens at 3am | No | If you scheduled it |
| Marginal cost of the next run | Your attention | A few tool calls |
The row that matters is the second. An assistant needs a person present 2,600 times; a worker needs one setup and then nobody. That is not a productivity improvement on the same activity, it is a different activity, which is why "agent" and "worker" being used interchangeably causes so much confusion about what these systems are for.
It is also why the practical bar is higher. Something a person initiates 2,600 times gets corrected 2,600 times. Something initiated once gets corrected when somebody eventually notices.
What unattended actually demands
A written instruction. Not a prompt you improvise per session, but a standing brief that holds on the four hundredth run, including cases you did not think about on the first. When you are present, you notice a bad answer and rephrase. Nobody is present.
Explicit app permissions. It is going to touch a real inbox while you sleep. What it may read and what it may write has to be decided in advance, and be narrower than "everything you can reach". That is what an app firewall is: access per app at Off, Read or Write, revocable without stopping the worker.
Rules for what it may do. Which people it may contact, what must never leave, what to do when it is unsure. These are not prompt lines; they are controls enforced outside the model, because an instruction is a request a model under pressure can talk itself past.
Notice that none of the three is about intelligence. They are all about operating something you are not watching.
Why the job has to be narrow
"Handle my email" is not a job a worker can do. This is:
When a lead replies to the outbound sequence, check the CRM for their stage, draft a reply in our voice, and leave it in drafts for me.
The narrow version has a definition of done, a small set of apps, and a small set of ways to go wrong. All three are testable. The vague version has none, so nothing can be verified and nothing can be trusted.
This is also why workers come in fleets rather than as one general assistant. You do not build one worker that does everything; you put several narrow ones on several narrow jobs:
| Worker | Apps | Starts on | Its one job |
|---|---|---|---|
| Executive Daily Briefing | calendar, email, tasks | Schedule | A prioritised morning brief |
| Inbound Lead Qualifier | email, crm | Event | Qualify, file, draft the first reply |
| Engineering Pulse | github | Schedule | PRs needing review, stale branches, failing workflows |
| Follow-Up Tracker | email, tasks | Schedule | Threads you are waiting on, and the nudge |
Four workers, four keys, four access grants, each switchable off without touching the others. That decomposition is not tidiness, it is how blast radius stays small.
The failure mode: treating a worker like an assistant
The common mistake is not technical. It is handing a worker an assistant-shaped job and being disappointed.
An assistant-shaped instruction is broad and relies on you to steer: "keep on top of my inbox". Given to something that runs unattended, "keep on top of" resolves differently every morning, and by the time you notice, forty threads have been handled forty inconsistent ways.
The tell is that you cannot say what a successful run looks like without using the word "appropriate". If the definition of done needs your judgement in the loop, the job is not ready to leave the loop.
The reasonable objection
"This is a scheduler with a language model attached. You have rebranded cron."
Half fair. The scheduling part is old, and anyone who has run cron jobs recognises the shape. What is new is what sits between the trigger and the work: a system that can read unstructured input, decide what it means, and act, which is exactly the step that previously required a person and made the whole category impossible.
What is also new, and less discussed, is that the failure model changed. A cron job fails loudly and deterministically. A worker fails plausibly: it produces something reasonable-looking that is wrong. That is why the interesting engineering is not the scheduler but the restraints, the receipts, and the hard caps. Cron never needed contact rules because cron never improvised.
When you do not want a worker
Naming this matters, because the honest set of jobs is smaller than the enthusiasm suggests.
- The task is not repeatable. One-off research does not need a key, a schedule and a receipt. Open an assistant.
- The judgement cannot be written down. If you cannot express the job as an instruction that holds on the four hundredth run, it is not ready.
- Mistakes are not recoverable. Drafts are recoverable. Sent money is not. Start where the downside is a nuisance.
- The work is genuinely interactive. Pair programming is a conversation, not a job to hand off.
- Volume is tiny. Under a handful of items a week, a person does it faster than you will tune the worker.
A good candidate is repeatable, has a definition of done, and its mistakes are recoverable. Fail any of those and the answer is an assistant, for now.
Where kits come in
You do not assemble a worker from nothing. A worker kit is the package with all of it already written and tested by a publisher: the instruction, the app permissions per level, the memories, the schedule or trigger, and per-model grades.
Taking a kit mints a worker in your own account, with its own key and only the access you granted, in about a minute. That is the practical answer to "the three things unattended demands": somebody already did them, and you can read exactly what they decided before you agree to it.
Browse the directory for what that looks like, or see /pricing for what running a fleet costs.
FAQ
What is the difference between an AI agent and an AI worker?
An AI agent is the general category: a model that uses tools to pursue a goal, driven by you in a session. An AI worker is an agent configured to do one specific job unattended, on a schedule or a trigger, with its own key, its own per-app permissions and a receipt for every run. The test is whether the work happens when nobody opens anything.
Is an AI worker the same as an agentic workflow?
Close enough that the terms are often swapped. "Agentic workflow" usually describes the pattern of an agent taking multiple steps toward a goal; "AI worker" names the configured thing that does one such job unattended, with an identity and permissions of its own.
Do I need a worker, or is an assistant enough?
If the value shows up when you sit down, an assistant is enough. If it should show up at 7am on a Tuesday while you are asleep, you want a worker. Many people want both, for different tasks.
What makes a job a good candidate to automate this way?
Three things together: it is repeatable, it has a definition of done you can state without the word "appropriate", and its mistakes are recoverable. Drafting a reply is a good candidate. Sending money is not.
How long does it take to set up an AI worker?
About a minute if you start from a kit, because the instruction, the access rules and the wiring ship pre-written and tested. You connect the accounts it asks for and deploy it. The Free plan runs 5 workers with no card and no expiry.