Smart Node is a platform for running self-hosted AI agents: you deploy it on a Linux server you own or rent, and the agents operate under your configuration, with your runtime, data, and task history stored locally.
Short answer: Smart Node installs on a Linux server and runs AI agents in isolated processes under your control. Your operational data, documents, conversation history, and credentials stay on that server. Whether prompts sent to AI models leave your network depends on whether you configure local model inference or route reasoning to an external provider.
Is this the right fit for you?
This is a deployment decision, not a signup. Two assumptions hide inside the phrase self-hosted, and both are worth checking before you spend an afternoon on installation: that self-hosting means nothing leaves your network, and that self-hosting means nothing costs money once per-seat fees are gone. Neither is automatic.
It fits when:
- Several people on your team need agents, and you do not want to buy a licence for each of them.
- You control, or can rent, a Linux server (Ubuntu or Debian) with at least 2 vCPU, 4 GB RAM, and 20 GB SSD.
- External messages, record deletions, and privileged commands must wait for a human confirmation before they happen.
- It matters where stored records physically sit, for your own policy or for a client's.
- Someone on your side can administer a Linux server, or you have an integrator who can.
It does not fit when:
- Nobody can deploy and maintain a Linux server, and no managed service provider is in place.
- You need a guarantee that no reasoning traffic ever leaves your network, without provisioning dedicated GPU hardware for local model inference.
- You expect the total bill to fall to zero once per-seat fees are gone.
- You need a compliance certificate (HIPAA, SOC2, GDPR) to come out of the installer.
- You want a fully managed, hands-off service.
Warning: Self-hosted describes where the runtime and the stored records live. It says nothing about what happens to a prompt when an agent asks an external model to reason about a task. Those are two separate decisions, and this page keeps them separate.
If that profile matches your situation, Deploy a private node and check the prerequisites against your own hardware before anything else.
What you get
Six capabilities, each stated as the consequence for your team rather than as a feature name.
| Capability | What it means for your team |
|---|---|
| Agent process isolation | Each agent runs as its own system process. One agent cannot read another agent's data or credentials. |
| Human approval gates | Sending external email, deleting records, and running privileged commands require your explicit confirmation first. |
| Hybrid inference | You decide, per agent, whether reasoning goes to an external frontier model gateway (Anthropic, Google, OpenAI) or runs on local model weights on your own hardware. |
| Per-node licensing | One node serves your whole team. There is no per-seat or per-user subscription fee. |
| Secret store | Third-party API keys and mailbox passwords stay on your server and are never placed in the text sent to a model provider. |
| Event log | Every agent action lands in an append-only log, so you can reconstruct what an agent did and when. |
The isolation claim is the one worth testing, so here is what holds it up. Agents run under separate Linux system accounts, which means the operating system, not the application, enforces the boundary between them. Credentials live in a local secret store and are resolved through an allowlist at the moment a tool runs, over authenticated local Unix domain sockets, so a key reaches the tool that needs it and never enters a model prompt. Tool access is granted per agent through an explicit capability allowlist, and multi-agent work moves through a Message Bus, a task tracker, and Workflow definitions rather than through shared files.
For the full list of components and how they connect, see the full component overview.
What it costs to run, and where the tradeoff sits
Most evaluations of on-premise AI agents come down to two questions: where the records sit, and what it costs to keep them there. Running your own node is infrastructure-sized, not subscription-sized. The minimum for a node that routes reasoning to remote model gateways is 2 vCPU, 4 GB RAM, and 20 GB SSD, which is a modest VPS tier. What stops is per-seat licensing: one node serves the entire team. What continues is hosting, operating system updates and maintenance, and per-token charges at any external model gateway you use.
The trade-off is the data boundary, and it has two sides that are easy to blur. Runtime state, documents, conversation history, configuration, and credentials stay on hardware you own or rent, and none of it is used to train third-party public models. But when an agent sends a reasoning request to an external frontier model gateway, the context payload of that specific request travels to that provider and is governed by the provider's commercial API policies, not by anything on your server. Messages sent through external Channels, whether public email networks, Telegram, or cloud voice, cross those networks as well. Running fully private AI agents, with no external API calls at all, requires dedicated CPU or GPU compute sized to the model weights you choose. Which path an agent takes is a decision you make per agent, not once for the whole platform.
Two obligations come with the deployment and do not transfer to anyone else by default: host security, operating system updates, monitoring, backups, and recovery are yours, or your managed service provider's.
Tip: Decide the model routing policy for each agent before installation, not after. An agent that writes internal summaries and an agent that drafts outbound email do not need the same routing, and configuring them separately from the start avoids a rewrite later.
Frequently asked questions
Do my prompts leave the server when agents reason about a task?
It depends on how that agent is configured. If the agent routes to an external frontier model gateway, the context payload for that request goes to that provider. If the agent runs on local model weights on your own hardware, it does not. The hybrid inference model lets you set this per agent, so a local-only agent and a gateway-backed agent can run on the same node.
What is the minimum hardware I need to get started?
2 vCPU, 4 GB RAM, and 20 GB SSD for a node that uses remote model gateways. That tier is enough for the runtime, the task queue, the documents, and the event log. Running fully private local models without external API calls is a different requirement: it needs dedicated CPU or GPU compute sized to the model weights you intend to run.
Is there a per-user or per-seat fee?
No. Licensing is per node, and one node serves an entire team. Removing per-seat fees does not remove cost: hosting, server maintenance, and per-token gateway charges remain, and they scale with usage rather than with headcount.
Can an agent send an email or delete a file without my approval?
No. Externally visible and irreversible actions pass through human-in-the-loop gates: sending external email, publishing content, deleting records, running privileged shell commands, and monetary spend all require explicit confirmation before execution. Agents also operate under declared scopes with least-privilege tool grants, so an agent cannot reach a capability it was never given.
What communication channels can agents work through?
Browser-based web chat (the office panel), internal agent mail, SMTP and IMAP email, Telegram bots, and voice interfaces through the Gemini Live API. Channel adapters sanitize inbound input and map each conversation to a persistent thread the agent refers back to throughout the task.
Who is responsible for keeping the server secure and up to date?
You are, or the managed service provider you appoint. Host security, operating system patching, monitoring, backups, and recovery procedures sit with the operator of the infrastructure. Installing the platform does not produce regulatory compliance on its own; compliance depends on the whole configuration, your access policies, your retention practices, and your administrative procedures.
How to start
Three steps take you from evaluation to a running node.
- Confirm prerequisites. Check that your server runs Ubuntu or Debian with at least 2 vCPU, 4 GB RAM, and 20 GB SSD, and decide whether you are starting with an external model gateway API key or with hardware for local inference.
- Work through the installation runbook at docs/install. It covers the prerequisites and the full installation sequence in order.
- Configure your first agent. Give it a Role, connect a Channel, define which Tools it may call, and set the human approval gates for anything irreversible. Then read the Event log as it works.
Once the node is running, you have a platform that serves your whole team from infrastructure you control, with stored records that never leave it and a routing decision you can change per agent.
Get started, or read the security architecture first if the boundary details are what your decision turns on.