Building
AI workers
Named colleagues with one job each — how to define them, run them, schedule them, and put several of them in one chat.
A worker is an AI colleague with a name, a specialization, and a curated set of abilities. Where the assistant is a generalist who knows your whole workspace, a worker is someone who does one thing and does it the same way every time.
Find them under Workers.
Defining one
Ask for it in a sentence — “I want a worker that reviews new invoices for missing PO numbers” — or fill in the form yourself. A worker has:
| Name | It gets a birth name and a number, like Nova 4471. You can rename it. |
| Specialization | The brief. What it’s for, how it should behave, what it must never do. |
| Abilities | Which parts of the workspace it may touch — data, views, files, specific integrations. |
| Model | Which model runs it. Cheaper for routine sweeps, stronger for judgment. |
Keep the brief tight. A worker with one clear job outperforms one with four vague ones, and you can always define a second worker.
Running one
On demand — run it from its page, or ask the assistant to. You watch it work: what it’s thinking, which tools it’s calling, what it has changed so far. Stop it at any point.
On a schedule — “every weekday at 7am” or “the first of the month”. It runs unattended and leaves its result where you’ll find it. Scheduled runs are listed with their outcome, so a job that failed at 3am is visible at 9am rather than silently missing.
From outside — a worker can be exposed as a callable tool, so another system or another agent can invoke it through your workspace’s MCP connection.
Group chat
Any conversation can become a group chat by adding workers to it. This is the part people find surprising, so it’s worth being precise about the rules.
A mention is a command. @Nova must answer. That holds in every direction — you to a
worker, a worker to another worker, a worker to you. Nobody ignores a direct address.
No mention means, at most, an offer. A worker that notices something in its lane says one line — “their source field is empty on eight of those, I can backfill it” — and then waits. It does not act on its own. This is deliberate: a room full of agents that volunteer work is a room you stop trusting.
Humans share the thread. Several workspace members can sit in the same chat as the workers, see everything each one did, and take over at any point.
You can stop anyone. Interrupt one worker mid-sentence, or halt the whole room. A stopped worker leaves behind what it had already finished, not a half-written record.
Two kinds of participant. Workers from your roster are permanent and reusable. A worker created on the spot for one conversation is temporary — it lives in that chat only, unless you promote it to the roster.
Archived chats stay readable. When a chat is done, it goes read-only. The transcript and the temporary workers remain visible; they just can’t take another turn.
Watching one work
While a worker runs you see a live card: its current step, the tools it has used, how much it has spent, and whether it’s waiting on something. If it needs a decision from you, it asks in the chat and pauses rather than guessing.
Cost
Workers spend tokens like everything else, and their usage is metered against the workspace. A scheduled worker that runs hourly against a large dataset is the most common source of a surprising bill — see Usage for how to see it before it surprises you.
Good workers, bad workers
Good: “Every morning, check yesterday’s inspections for missing photos and list the sites that need a revisit.”
Bad: “Keep an eye on things and let me know if anything looks off.” No definition of off, no definition of things, no way to tell whether it did its job.
If you can’t say what a successful run looks like, the worker can’t either.
Next
- Workflows & triggers — for work that’s a fixed sequence rather than a judgment call.
- Usage — what your workers cost.