The phrase "AI employee" is common now, but most descriptions skip the part a business owner needs most: what the thing concretely does, and where it stops without a human.
Short answer: An AI employee is a software agent assigned a defined role, given access only to the specific tools that role requires, and configured to pause and ask for human confirmation before taking any action that cannot be reversed. It handles work that follows a predictable pattern: routing inquiries, drafting replies, processing structured requests. It does not replace judgment; it handles the volume that does not need it.
How an AI employee is structured
Five components make up one AI employee, and each of them also marks a limit. Together they answer both halves of the question at once: what the agent can do for you, and what it cannot do without you. The same structure appears across AI in small business operations; what separates one product from another is how strictly each part is enforced.
| Component | What it means in practice |
|---|---|
| Role | The agent is configured for one job: customer inquiries, invoice routing, document drafting. It does not take on work outside that scope. |
| Tools | The agent can use only the tools granted to it for that role, and nothing else. One agent cannot reach another agent's mailbox, files, or credentials, because each runs in its own isolated Linux system account. |
| Channel | Work arrives and leaves through a defined path: a business email inbox, browser chat, a Telegram bot, a voice line. |
| Human gate | Before sending a message outside the business, deleting a record, running a privileged command, or spending money, the agent stops and waits for a person to confirm. |
| Event log | Every action and every confirmation is written to an append-only log you can read afterwards. Nothing is overwritten or quietly dropped. |
Read the table as a set of permissions rather than a feature list. A role tells you what the agent is for. The tool list tells you how far it can reach. The gate list tells you where you still have to be present.
A worked example: one agent handling customer email
Say one agent is configured for a single job: handling inbound customer email.
A message arrives in the business inbox. The email channel adapter reads it over IMAP, sanitises the input, and maps the conversation to a persistent thread, so a later reply knows what was said before. The agent then searches the business document library for the material that answers the question and drafts a reply.
Before that reply leaves the building, the draft is surfaced to a person. They approve it, edit it, or discard it. Only an approved draft is sent, and this gate for outbound external email is not a setting that gets quietly switched off later.
Every step lands in the event log: the message received, the documents retrieved, the draft, the approval, the send. Reading that log after the first week tells you more about whether the setup is right than any configuration screen.
Most of what the agent handles stays on your server; one step does not. The mailbox, the documents, the thread history, and the log live on the machine you control. When the drafting step is routed to an external model gateway such as Anthropic Claude or Google Gemini, the context of that request, meaning the customer's message and the document excerpts the agent selected, travels to that provider and is handled under its commercial zero-retention API policy. The mailbox credentials do not travel with it: they sit in a local secret store, are resolved locally, and are never placed into the model prompt. If a class of email must not leave the machine at all, that role needs local model weights on your own hardware. The full list of boundaries is documented in security architecture.
Steps to set one up
- Choose one job that follows a predictable pattern. Routing inquiries, answering a defined class of email, or turning structured requests into records all qualify. Start with one role, not several.
- List what the agent must read and what it must be able to do. That list determines which tools and channels to connect. Grant only what the role requires.
- Decide where a person must confirm before the agent acts. Any action that sends a message outside the business, deletes a record, or involves monetary spend needs a gate, and these cannot be skipped.
- Provision a Linux server. Ubuntu or Debian, minimum 2 vCPU, 4 GB RAM, and 20 GB SSD when inference routes to an external model gateway such as Anthropic Claude or Google Gemini. Running a fully local model instead requires substantially more compute, sized to the model weights you choose.
- Install and configure the node. The installation runbook covers prerequisites and the configuration order.
- Run one test task end to end, then read the event log. Confirm three things: the agent used only the tools it was granted, the gate fired before the external action, and the log entry matches what actually happened.
Common mistakes
- Grant the minimum set of tools for one job at first setup, and widen scope only after a task has run clean.
- Leave the human gates switched on. They cover irreversible actions, so removing one moves the risk from a confirmation prompt to a sent email or a deleted record.
- Check where each request actually goes before choosing the first task. If a task's context would be sent to an external model gateway, decide whether that is acceptable for that data.
- Start with the routine case, not the exception. A bounded workflow handles the pattern it was configured for and will not improvise correctly on a case outside its role.
- Read the event log after the first live run. It is how you verify that the agent stayed inside its granted tools and that the gate fired before the external action.
Frequently asked questions
Is an AI employee the same as a chatbot?
No. A chatbot answers whatever a person types and stops there. An AI employee has a defined role, a fixed set of granted tools, and permission to act: send mail, write a document, create a task. It also carries two things a chatbot does not, a gate that stops it before irreversible actions and a log of everything it did.
Does my business data go to OpenAI or Anthropic when I use this?
Partly, and which part travels depends on how you route the work. Documents, conversation history, and configuration stay on your server. When a role is routed to an external model gateway such as Anthropic Claude or Google Gemini, the specific context of that request goes to that provider under its commercial zero-retention API policy. Provision local model weights and that request stays on the machine. Messages sent through external channels, including Telegram, public email networks, and cloud voice, traverse those networks as well.
How many AI employees can I run on one server?
It depends on the hardware and on where the reasoning happens, not on a licence count. The base node runs on 2 vCPU, 4 GB RAM, and 20 GB SSD when inference goes to an external gateway, and every agent you add shares that CPU, memory, and local database. Routing roles to external gateways keeps local load light; running local model weights moves the demand to CPU or GPU memory sized to the model. There is no per-seat subscription fee that stops you at a headcount, so the practical ceiling is what your machine can carry under your own workload.
Can the agent work overnight without anyone watching it?
Yes for work inside its declared scope, and no for actions with external consequences. Overnight the agent can read mail, search documents, draft replies, and prepare tasks. Sending an external email, publishing content, deleting a record, running a privileged command, or spending money waits for a human confirmation before it executes. A night shift is possible; an unattended one that sends mail is not.
What does it cost to run an AI employee?
Infrastructure and tokens, not seats. You pay for the server or VPS the node runs on, plus per-token charges at whichever model gateway you route work to, with no per-seat subscription fee. Running local model weights trades token charges for hardware. Either way there is no zero-cost operation: host security, OS updates, monitoring, and backups remain your responsibility.
Next step
Check your server against the requirements above, then Set up your node to begin configuration.