The phrase "hire AI employee" names an outcome without naming any of the steps that produce it. What sits behind the phrase is a process running on a server your business controls, doing a defined job with a defined set of permissions, and stopping at the actions you have decided a person must approve.
That last part is the difference between this and buying another subscription seat. On a self-hosted multi-agent platform, the runtime, the task history, the documents and the conversation records stay on a machine you own or rent. Nothing about the work depends on a vendor's tenancy.
Short answer: An AI employee is an agent process running on a server you control, assigned a declared role, restricted to an explicit list of tools, and configured to wait for your confirmation before taking any irreversible action. Setting one up means writing the role definition, provisioning a server, and configuring the agent's boundaries before it handles real work. For the broader case for AI in small business operations, see AI for Small Business.
What you need before you start
Four things have to exist before configuration begins. Each is a decision or a resource, not a purchase.
- Confirm the server meets the minimum: Ubuntu or Debian Linux with 2 vCPU, 4 GB RAM, and 20 GB SSD storage, rented from a hosting provider or running on hardware you own.
- Choose the inference route. An external model gateway such as Anthropic Claude, Google Gemini, or OpenAI keeps the hardware requirement at that minimum, and needs an account with that provider. Running models entirely on local hardware removes the external API calls and raises the compute requirement to match the model weights.
- Arrange the Linux administration. Either someone on staff administers the server, or a managed service provider or integrator does it on your behalf. This is not a no-code deployment.
- Write the role definition. One document covering what the agent does, which channels it uses, which decisions it makes alone, and which actions need your sign-off.
Steps, in order
- Write the role definition. Put in writing what the agent does, what it decides on its own, and what waits for your confirmation. Every configuration choice that follows is measured against this document, which serves as both job description and authorization policy.
- Provision the server. Stand up the Linux machine on a hosting provider or on your own hardware. The agent's task history, documents, and conversation records will live there, not in someone else's account.
- Install the platform. Install Smart Node on the server. The installation sets up the runtime, the local databases, the secret store, and the process environment the agent runs inside.
- Create the agent and bind it to the role. Create the agent record and attach the role definition from Step 1. The agent runs as an isolated process with its own system identity, separated from other agents and from the host system.
- Grant tool access under a least-privilege allowlist. Every capability the agent needs, whether reading documents, sending internal messages, querying a task list, or calling an external API, is granted explicitly. Nothing is available by default. Grant what the role definition requires and nothing else.
- Set human approval gates. Choose which actions wait for your confirmation. External email, deletion of records, publishing content, and privileged system commands are the actions the platform will not execute until a person confirms. The gate intercepts the action, presents it to you, and the agent waits.
- Connect a communication channel. Give the agent a channel for tasks and replies: the browser office panel, an email inbox, a Telegram bot, or a voice interface. Inbound messages are sanitized and mapped to a persistent thread, so a conversation picked up today continues where it left off.
Tip: Write the role definition before you open the server console. Every later configuration screen is a question that document should already have answered, and widening scope after tools are granted is how an agent ends up holding access nobody intended.
How to check it worked
Run three tests before the agent touches real work. Read the results against the role definition, not against what you assume the agent will do.
- Send a test task through the assigned channel and confirm the agent replies on that same channel, inside the scope of its role.
- Trigger an action that sits behind a human approval gate, such as composing a test email to an external address, and confirm the system intercepts it and presents a confirmation request. The message must not leave until you confirm.
- Read the Event log, which records every action in sequence, and confirm the test task appears there with no actions outside the role scope.
What goes wrong and how to tell
Two failures show up early, and both are diagnosed the same way: compare the Event log against the role definition you wrote in Step 1.
Warning: If the agent routes nearly every action to human approval, the gate thresholds are more conservative than the role definition requires. Compare the list of intercepted actions against the role definition and adjust the gate configuration to match the declared scope.
Over-gating is not a safety win. It turns the agent into a queue of requests and recreates the bottleneck the hire was meant to remove. Narrow the gates to the actions the role definition marks as irreversible or externally visible.
Warning: If the agent attempts actions you did not expect, the tool allowlist or the role scope is broader than intended. Review the capability list item by item against the role definition from Step 1 and remove any grant the role does not require.
One more behavior looks like a fault and is not. When a task calls an external model gateway, the context payload for that request travels over the network to that provider, under the provider's commercial API policies. That is how a hybrid inference model works: runtime, storage, and the Event log stay on your server, while the reasoning for that particular request does not. The same applies to messages sent through external channels such as Telegram or public email, which traverse those networks to reach their destination. A deployment that must keep all processing on its own hardware needs local compute sized to the chosen model weights, which is a larger machine than the minimum VPS specification.
Frequently asked questions
How is an AI agent different from a chatbot?
A chatbot answers a message and holds no state between sessions; an agent keeps state across them. An agent also maintains a task queue, initiates actions rather than only responding, and works inside a declared role with an explicit list of tools it is permitted to use.
Can the AI access my customer data or financial records?
Only the data you explicitly grant it. Tool grants control which documents, data sources, and external services the agent can reach, and process isolation keeps one agent out of another agent's records. No agent starts with access to anything.
What stops the AI from sending the wrong email to a client?
An approval gate does. Sending email to an external address is an irreversible external action, so the platform intercepts it and waits. The agent cannot proceed until a person confirms, and the email does not send before that confirmation.
Do I need a developer to set this up?
Yes, or an integrator who provides that capability on your behalf. Deploying and administering a Linux server requires technical proficiency, and because the platform runs on infrastructure you manage, someone has to manage it.
How much does it cost to run an AI employee?
No per-seat licensing fee applies; the costs are infrastructure and tokens. You pay your hosting provider for the server and per-token fees to whichever external model gateway you connect. Running entirely on local model weights eliminates the gateway fees and moves the cost into hardware beyond the minimum VPS specification.
Next step
Once the role definition is written and the server meets the minimum, deploy a node and configure the agent's boundaries before it handles real work: Set up your node.