Product
AI employee vs. chatbot vs. assistant: the real difference
Aug 10, 2026 · 6 min read
Updated Aug 17, 2026
A chatbot answers the message in front of it. An assistant does what you ask while you stay in the thread. An AI employee holds a role: it keeps your facts between runs, works a queue on a schedule, obeys written limits on what it may do alone, and leaves money and outbound messages to a person.
Each of those parts is a record you can open. A role is a prompt with a validator, kept in code. Your facts are knowledge items, read into the prompt on every run. A timer wakes the work loop every 15 minutes. Each run lands in a journal with its inputs, its outcome and its error text.
Six axes, three answers
The three categories usually get compared on how well they talk. The differences that decide whether the work gets done sit elsewhere: in what survives the end of a conversation, in who starts the next piece of work, and in what the software is allowed to do while nobody is watching.
| Axis | Chatbot | AI assistant | AI employee |
|---|---|---|---|
| Memory | The open conversation; closing the window ends it | The current thread, plus what you paste back in | Knowledge items stored per brand, read into the prompt on every run |
| Initiative | Waits for a visitor to type | Waits for you to prompt it | A timer every 15 min; 7 days for the market analyst, 24 h for the morning brief |
| Queue | One message at a time | One thread at a time | Rows in a job table — queued, running, ok, failed — one job per tick |
| Limits of authority | Whatever the widget was wired to reach | Whatever tools you granted for the session | Approval rules, spend caps and a kill switch checked before every outbound write |
| Reporting | Transcripts, read after the fact | The thread you were sitting in | Journaled runs, proposals and decisions with timestamps and outcomes, failures included |
| Human control | You review the log later | You are the one typing | Drafts; the lead responder has no send path of its own |
What a role is, in code
A role is a prompt paired with a validator, and the two live next to each other in the codebase. The validator throws out a result that breaks the role's own rules: a number with no named source, an ad past the platform's length caps, a checklist item marked green with no reason written next to it. A failed validation is a failed run, and it stays visible as one.
Five roles ship inside the platform today — market analyst, creative writer, campaign proposer, lead responder, brief composer. Each is registered against its own module, so renaming one breaks the build instead of going quietly missing. The jobs a pilot is usually scoped around, from sales to support to accounting, are built on the same draft-and-approve loop.
How the memory actually works
Two mechanisms, both boring on purpose. Your material is stored as knowledge items per brand — facts, policies, legal restrictions, audiences, cases — and read into the prompt on each run, so two answers a month apart cite the same source. Marking an item verified is a separate, deliberate action, which keeps a repeat import from handing old facts a fresh timestamp.
The second mechanism is the handoff between runs. The output of one successful run becomes the input of the next role in the chain: the analyst's decision feeds the writer, the writer's drafts feed the proposer, and the validator downstream checks its own output against what it was handed. A decision made on Monday still shapes what gets drafted on Friday.
Who decides what
Reading, analysing, drafting and journaling run unattended. Everything that touches money or a customer stops at a gate, and each gate is a check inside the write path.
- The first reply to a lead is a draft, because the role that writes it has no send path.
- An action in the approval class waits for a person, and an action the rulebook has never seen counts as needing approval too.
- Daily and monthly spend caps are records in the database, checked inside the same gate before the money moves.
- The kill switch is checked before every outbound write, and engaging one takes a written reason that is stored with it.
- A pending approval that runs out of time stays undecided. An expiry is never read as a yes.
- If the rulebook cannot be read, the outbound write is refused, because a write with unread checks is a write with no checks.
“The honest test: ask what happens to the work when nobody has the chat window open.”
Employee experience: the same parts, pointed inward
Internal questions have the shape of customer ones. A new hire asks what the last one asked — expense limits, time off, who signs what — and the answer already sits in a document nobody rereads. The handbook becomes knowledge items, the reply comes back as a draft with the passage it used attached, and whoever sends it can check the answer against the source in seconds.
Reporting inward works the same way. One role writes a brief every 24 hours from the actual state of the system, and its validator compares every number in the text against the inputs it was handed, so a figure that came from nowhere fails the run instead of landing in an inbox.
Where it stops today is worth saying plainly. One platform connector ships — Meta ads — plus an endpoint any web form or quiz can post to, which is how an internal help form reaches a role right now. Telegram sits in the planned group. Slack, Teams and helpdesk tools are built against your account during a deployment.
When a chatbot is the right call
Plenty of the time. One page, a narrow FAQ, small volume, nothing to update once the conversation ends — a widget covers that in an afternoon for very little money. An assistant covers the other easy case: a person at the keyboard who wants the draft faster on one-off work.
A role earns its keep when the job continues after the answer: a CRM record to update, a booking to make, an invoice to chase, an overnight queue that has to be ready by morning. At that point the question shifts from how well the software talks to what it is allowed to do, and what it leaves behind for you to check.
A chatbot sits on a channel and answers whoever writes to it from the material it was given. An assistant sits in a thread you drive and does what you ask of it there. Both hold context for the length of the conversation. Neither one carries a role, a work queue, or a rule about what it may do without you.
Two ways. Your material is stored as knowledge items per brand — facts, policies, legal restrictions, audiences, cases — and read into the prompt on every run. And the output of one successful run becomes the input of the next role in the chain, so a decision made on Monday still shapes what gets drafted on Friday.
No. The role that writes the first reply to a lead has no send path. Launching a campaign, changing a budget or pausing something sits in the approval class, an action the rulebook has never seen counts as needing approval, and a pending approval that expires stays undecided. When the rulebook cannot be read, the outbound write is refused.
Yes, with the same parts pointed inward. Your handbook and policies become knowledge items, an internal help form posts to the same endpoint a customer form uses, and the answer comes back as a draft with its source attached. Slack, Teams and helpdesk tools are scoped and built during a deployment.
Starter is $149 per month, Scale is $599 per month, Enterprise is custom. The rate is per digital employee per month, with seats, messages and tokens left unmetered, so the bill holds still when a busy week doubles the volume.