You've tried the chat window. It writes a decent email. Then you close the tab and it forgets your customers, your pricing, and the fact that you never write "just circling back." Tomorrow you type all of it again.
That isn't a workforce. That's a very fast temp who starts their first day, every day.
"AI workforce" has been used to sell you at least four different things this year, most of them a chat box with a new logo on it. So here is the definition we actually build against — part by part — followed by the list of things it explicitly is not. The second list matters more.
A worker is six parts, and none of them is magic
In askTheodor, a worker is not a conversation. It's a record on your machine with six parts:
A job. You pick a profession from the catalog — Customer Support Specialist, Operations Manager, Copywriter, Grant Writer, Executive Assistant, Electrician, Event Planner, SEO Specialist, Data Analyst, Recruiter, Executive Chef, Property Manager. 95 of them. Picking one pre-fills the worker's name, title, system prompt and a starting set of skills. You edit all of it afterwards. The profession isn't a personality — it's a starting posture. The Customer Support Specialist opens with "Acknowledge first, then solve. Match the customer's tone. Every ticket is also data — flag the patterns." That's the whole trick. It's a prompt you didn't have to write.
A brain. Each worker points at one model. Not the app — the worker. Your support worker can run on a local model that never leaves the machine; your researcher can point at a frontier cloud model for the hard reasoning. Local models run in-process or via Ollama and LM Studio; cloud is opt-in, one of 49 providers, and only if you connect one. The point isn't that you can mix. It's that routine work shouldn't cost frontier prices, and confidential work shouldn't leave the building at all.
A memory. Workers write to their own long-term memory and recall from it semantically on later runs. Workers in the same company can also recall each other's relevant memories — hard-isolated per company, so your client A worker can't see client B's. This is the part people mistake for the AI "learning." It isn't. The model weights never change. What changes is the context the worker sees at the start of every run — and that compounds.
A tool allowlist. Read files. Write files. Fetch a URL. Drive a real browser. Run a shell command. Call an MCP server you've connected. Each worker gets only the tools you tick. This is enforced in the agent loop, not in the prompt — a disallowed tool call is blocked server-side, not politely discouraged. A worker that only has read access cannot write, no matter how the model is talked into it.
A task queue. Workers have tasks with real IDs, not just chat history. A worker can list its own open tasks and move them: To-do → In-progress → Review → Done. Tasks can be assigned by you, or by a manager worker to a subordinate, and each assignment opens with a written kickoff brief so the worker's chat is never a blank screen.
A mailbox and a paper trail. Each worker has an inbox, a list of work products it produced, and an activity log. When something runs while you're asleep, you see it in a "work done while you were away" panel the next morning.
You can choose anyone of the included workers, or create your own.
What it looks like on a Tuesday
Concrete version. You run a six-person e-commerce shop. Support eats your mornings.
You hire a Customer Support Specialist and name her Nadia. Profession pre-fills her prompt and her starting tools: read files, write files, fetch a URL, save memory, recall memory. You point her brain at a local model — support triage doesn't need a frontier model and you'd rather customer names stayed on the machine. You drop your returns policy and your last 40 resolved tickets into the Library so she can retrieve them.
You connect your support inbox as a channel. A refund request arrives at 06:40. Nadia reads it, recalls that this customer had a delayed shipment in March, retrieves the returns policy, and drafts a reply that references both.
She does not send it. The draft waits for you. [CHECK: is an outbound send on a connected email channel per-send approval-gated, or is connecting the channel itself the gate? I can confirm the approval modal covers file writes, shell commands and outbound HTTP — I'm not certain of the exact email path, don't want to overstate it.]
You read it at 08:15, change one sentence, approve. Ninety seconds instead of fifteen minutes. Nadia saves what she learned about that customer. Next month, she already knows.
Now the part that matters: what it is not
It is not autonomous employees. A worker doesn't decide what your business needs. It runs the task in front of it, with the tools you gave it, and stops. Multi-step plans exist, but you approve the plan before its first task runs.
It is not a smarter model. Same model everyone else has. What differs is what it walks in knowing — your brand, your policy, your last 40 tickets — and what it's allowed to touch. Context and permissions, not intelligence.
It is not a replacement for judgement. It's a replacement for the second draft. Someone still has to know whether the refund is the right call. That someone is you.
It is not 95 different intelligences. It's one model wearing 95 different sets of instructions and permissions. We'd rather say that plainly than let you discover it in week three.
It is not a chat window with a costume. The difference between a persona and a worker is memory, tools, a queue, and a gate. Take those four away and you have a costume.
The honest trade-off
Approval is all-or-nothing per tool. If you trust a worker with "write files," you've trusted it with writing any file inside its sandbox — you can't say "this worker may write invoices but not touch the customer list." That's a real limitation, and until it's finer-grained we'd rather you knew before you granted the permission than after.
The related one: small local models are not always reliable at calling a tool. They sometimes write out what they would have done instead of doing it. For supervised daytime work that's a two-second annoyance. For unattended overnight runs it's the reason we tell people to point autonomy at a model they trust and start with supervised tasks.
One next step
If you want the field-by-field version — how the allowlist is enforced, how memory is scoped, what the approval gate covers — it's all in the docs, written by the person who built it. Start there before you start a trial. https://docs.asktheodor.com
