Most small businesses that try to add AI end up with customer data spread across a dozen SaaS platforms and per-seat subscription costs that climb with every new hire.
Short answer: An AI-powered small business can run its agents on a server you own or rent, configured for specific operational roles such as email handling, document drafting, and customer chat, with no per-seat licensing fees for your team. Deployment requires a Linux server with at least 2 vCPU, 4 GB RAM, and 20 GB SSD storage, plus either API access to an external model gateway such as Anthropic Claude or Google Gemini, or local GPU hardware if you want inference to remain fully on your server. This guide covers each step in order; for a broader map of what AI can do across a small business, the AI for small business overview is a useful starting point.
What you need before you start
Four things have to be in place before the first agent runs: a server that meets the minimum specification, a source of model inference, someone who can administer Linux, and a written list of the tasks you want agents to own.
- Confirm the server: Ubuntu or Debian Linux with at least 2 vCPU, 4 GB RAM, and 20 GB SSD storage. That configuration is sufficient when agents send their reasoning to an external model gateway, and it is not sufficient for inference that runs on the host.
- Choose the model source: API credentials for one external gateway (Anthropic, Google Gemini, or OpenAI), or a provisioned local model runner on dedicated GPU or CPU hardware sized to the model weights you intend to use.
- Arrange Linux administration: either in-house skills or an integrator. There is no browser-based installer.
- Write the task inventory: the repeating tasks you want agents to own, such as email triage, customer inquiries, document drafts, and scheduling messages. Mark every task that produces an irreversible external action, because those will need a human approval gate.
Steps to get AI agents running in your business
- Map the tasks. List the repeating operational tasks you want agents to own: email triage, customer inquiries, document drafts, scheduling messages. For each one, note whether it produces an irreversible external action. You finish this step with a written scope per role.
- Provision the server. Ubuntu or Debian, minimum 2 vCPU, 4 GB RAM, 20 GB SSD. Decide now whether agents may send context to an external model provider. If they may not, size dedicated compute for local inference at this point rather than after installation. You finish with a host that meets the minimum and a decision about where inference runs.
- Install the platform and connect a model source. Follow the prerequisites and installation runbook at /docs/install. Store model gateway API keys, mailbox passwords, and third-party tokens in the local secret store, where agents resolve them by reference through local tool wrappers. Credentials are never inserted into model prompts. You finish with a running node and a working model connection.
- Create agent roles and assign tool grants. Each agent runs in an isolated process with a declared scope. Grant only what the role needs: an email-handling agent gets mailbox access, not shell or database access. Assign each role a model matched to its task complexity, from the local runner or from an external gateway. You finish with roles that can do their job and nothing adjacent to it.
- Connect your business channels. Supported channels are browser-based web chat, SMTP/IMAP email, Telegram bots, and voice. Every channel sanitizes its input and maps an incoming conversation to a persistent thread. You finish with conversations arriving in one place instead of several inboxes.
- Configure human approval gates. Sending external email, publishing content, deleting records, executing privileged shell commands, and monetary spend are held for explicit human confirmation before they execute. For any role that performs an irreversible external action, this is required configuration, not a preference.
- Run test tasks before going live. Exercise each agent on representative inputs through a test channel or a dedicated test mailbox. Confirm that the event log records the expected actions and that the approval gates fire before any external send. You finish with evidence rather than an assumption.
How to check it worked
Four checks tell you the deployment is behaving.
- Check the event log after your test tasks. It records every agent action and state change in append-only form, so confirm that the expected actions appear with the right role attribution.
- Trigger a test send to an external address and confirm the approval gate holds it for confirmation before it leaves.
- Confirm that credentials resolve from the secret store without error. A credential resolution failure in the event log points to a misconfigured allowlist, not to a missing system permission.
- Send one message through every connected channel and confirm it appears in a persistent thread rather than starting a new one.
What goes wrong and how to tell
Most deployment problems trace back to one of two assumptions: that nothing leaves the server by default, and that the platform maintains the host.
Warning: In the default configuration, agents route reasoning to an external model gateway, and the context payload sent with each request leaves your server. Data held in your local databases, documents, and memory is never used to train third-party public models, but the prompt payload transmitted to a gateway is governed by that provider's commercial API policies and not by your server's controls. If you assumed full data locality without provisioning local inference, that assumption does not hold.
Running everything on local inference removes that transit. It also replaces it with dedicated GPU or CPU hardware sized to the model weights you choose, plus the maintenance that hardware brings. The two paths are not mutually exclusive: different agents on the same node can be configured with different models, so a role that handles sensitive records can run locally while a drafting role uses a gateway.
The second assumption concerns the host. The platform manages the agent runtime. It does not manage the operating system underneath it. OS updates, backups, monitoring, and recovery are the operator's responsibility, whether that operator is you or a managed service provider.
Warning: Tool grants drift wider than the role. An agent given access to a tool will use it, and the failure is usually quiet: a drafting agent with database access that nobody intended to grant. Audit the grants against the task inventory from step one after every change to a role.
Frequently asked questions
Does my business data get used to train AI models?
No. Data stored in your local databases, documents, and memory is not used to train third-party public models. What leaves the server is the specific prompt payload of a request sent to an external model gateway, and that payload is handled under the provider's commercial zero-retention API policies. If the answer matters for a particular dataset, run that role on local inference instead.
How much does it cost to run AI agents for a small business?
There is no per-seat licensing cost, so adding staff does not add software seats. What remains is server hosting, hardware if you run local inference, ongoing system maintenance, and per-token charges from your model gateway. Hosting rates and per-token rates vary by provider, region, and model, and they change, so read the VPS provider's pricing page and the gateway provider's pricing page for current numbers rather than planning against a figure from an article.
Can I run AI agents with no data leaving my server?
Yes, in one specific configuration: exclusively local model weights, zero outbound network adapters, and no external channels such as public email, Telegram, or cloud voice. Anything short of that sends something out. The lowest-cost way to start is an external gateway, where the prompt payload for each call leaves the server under the provider's terms, so the honest question is which of your roles need the stricter setup.
What tasks can AI agents handle for a small business?
Repeating operational work with a clear input and a checkable output: email triage and drafting, customer inquiries over web chat, email, Telegram, or voice, document drafting with version history, scheduling messages, and multi-step workflows tracked as tasks. Agents also coordinate with each other through a message bus and a task tracker, which is what lets a request move from intake to a finished, reviewed result.
Do I need technical staff to manage this?
Yes. Deploying and administering a Linux server takes real proficiency, and if you do not have it in house, an integrator is the practical answer. There is no browser-based installer, and OS updates, backups, monitoring, and recovery stay with you or your provider. Agents run inside bounded workflows under human oversight; the platform does not replace the person managing it.
Set up your node
Pick the task with the clearest input and the least external risk, wire up one channel and one approval gate, and read the event log before you add a second role. When you are ready to run that role on hardware you control, set up your node.