Smart Node is a self-hosted multi-agent platform: AI for small business operations, running on a Linux server you control, with no per-seat subscription for the people who use it.
Short answer: Smart Node deploys a set of AI agents on a server you own or rent. Each agent takes a defined role: reading inbound messages, executing assigned tasks, drafting outputs, and running structured workflows. One node serves your entire team, and the cost scales with infrastructure rather than headcount.
If you already know you want to evaluate this on hardware you control, the path starts at Get started.
The problem as you live it
Most small business AI tools are rented by the seat. The bill arrives per user, per month, and it grows the moment you hire. Add a second capability and you add a second vendor: one tool for email automation, another for task tracking, another for chat. Credentials, conversation history, and task data end up spread across three or four cloud systems, each with its own retention policy and its own export format.
That structure is the problem, not any single vendor's pricing page. Replacing one per-seat tool with another per-seat tool keeps the same cost curve and the same custody arrangement. You are still paying per person for software that lives somewhere else.
| Aspect | Per-seat AI SaaS | Self-hosted node |
|---|---|---|
| Cost model | Rises with every user added | Fixed infrastructure cost, no per-seat fee |
| Data location | Vendor cloud, under vendor policy | Local databases and document repository on your server |
| Vendor count | One per capability: email, tasks, chat | One platform on one server |
| Team scaling | Each new hire adds a license | Users are added without changing license cost |
| Workflow logic | Limited to what the vendor exposes | Defined by your business, versioned and reproducible |
A self-hosted node changes both sides of that table at once: the license stops tracking headcount, and the data stops leaving the building. What it does not change is your responsibility for the server, and the next sections state that part plainly.
What you get
| Component | What it gives you |
|---|---|
| Agent roles | Purpose-configured agents with declared tools, not a general chatbot |
| Channels | Web chat, email, Telegram, and voice mapped to persistent threads |
| Approval gates | Human confirmation before irreversible or externally visible actions |
| Data storage | Local databases and a Git-backed document repository you administer |
| Model routing | Local open-weight models or external gateways, chosen per agent |
| Licensing | One node for the whole team, with no per-seat fees |
Agent roles. Each agent is configured with one role and an explicit list of tools it may use. One agent triages inbound email. Another tracks task status and updates it. Another drafts replies that wait for a human before they go out. You define roles around how the business already works rather than around what a vendor template allows. Agents run as isolated Linux system accounts with least-privilege tool grants, so one agent has no path to another agent's mailbox, files, or credentials.
Channels the team already uses. Agents connect to browser-based web chat, SMTP and IMAP email, Telegram bots, and voice interfaces. A message arriving on any of them is mapped to a persistent thread, so the agent handling that conversation sees the history instead of a fresh question each time. When a request falls outside an agent's declared scope, it escalates to a person rather than improvising.
Approval gates. Before an agent sends an external email, publishes content, deletes a record, executes a privileged shell command, or incurs monetary spend, the platform stops and waits for explicit human confirmation. You can delegate the reading, the routing, and the drafting without delegating the irreversible step.
Data on your server. Relational state, event logs, conversation history, and documents are written to local databases and a Git-backed document repository on your machine. Every state change and agent action lands in an append-only event log, so there is a record of what changed and when. API keys, mailbox passwords, and database tokens stay in a local secret store and are resolved over authenticated local interfaces under strict allowlists, never inserted into a model prompt. None of that data is sent to third-party storage, and none of it is used to train public models.
Model routing. Agents run on local open-weight models using host CPU or GPU, or route to external gateways such as Anthropic Claude, OpenAI, or Google Gemini. Different agents on the same node can use different models: a small local model for classification and routing, an external frontier model for drafting. Egress to external gateways is explicit, metered, and controlled by system configuration.
One node, your whole team. Licensing does not multiply with headcount. Two users and twenty users run on the same node, and the platform charges no per-seat fee for either. What you pay is the server, and, when a task goes to an external model gateway, the tokens that request consumes.
If you want the component-by-component detail before deciding, See the full component overview.
The trade-off
You give up the managed service. Nobody else patches the operating system, watches disk usage, rotates backups, or restores the node at 2 a.m. The organization, or the integrator it hires, owns host security, OS updates, monitoring, backups, and recovery. A license without per-seat fees does not remove the operational work of running a server, and if nobody on the team can administer Linux, that work has to be bought in. Its cost belongs in the same comparison as the subscriptions you are replacing.
The inference boundary is the other thing to get right. Runtime and stored data stay on your server. Reasoning does not always stay there. When a task routes to an external frontier gateway, the context payload for that specific request travels the network to that provider, under the provider's commercial zero-retention API policies. A node that uses external gateways for its reasoning runs on modest hardware: 2 vCPU, 4 GB RAM, and 20 GB SSD on Ubuntu or Debian.
Warning: Private is not the same as fully local. A 2 vCPU VPS that routes reasoning to an external gateway keeps your storage on your hardware but sends each request's context off it. Running models entirely on your own machine needs dedicated CPU or GPU hardware sized to the chosen model weights.
Two cost lines replace the subscription: server hosting, and per-token fees for external model calls. Local inference removes the second line and adds a hardware line instead.
Fits and does not fit
It fits when:
- A technical staff member or an IT partner can manage a Linux VPS.
- Current per-seat AI subscription costs across your tools exceed a VPS plus per-token gateway fees.
- You handle sensitive client or operational data and want it stored on infrastructure you control.
- You have repeating workflows worth delegating: inbox triage, task routing, document drafting, status updates.
- Your team already works over email, Telegram, or web chat.
It does not fit when:
- Nobody at the organization is able or willing to manage a Linux server.
- You need a certified regulatory compliance posture (HIPAA, GDPR, SOC2) on day one. Installing the software does not create that certification; it depends on your full infrastructure configuration, access policies, retention practices, and administrative procedures.
- You require inference with zero external API calls but cannot provision GPU hardware.
- You are a single person with no team-level workflows. The headcount-independent licensing structure buys you nothing.
Frequently asked questions
Do I need my own server, or can I use a regular laptop or desktop?
A rented VPS is the usual answer, and it clears the minimum specification: 2 vCPU, 4 GB RAM, and 20 GB SSD running Ubuntu or Debian. That hardware is enough when reasoning routes to an external model gateway. Running models locally is a different sizing question, driven by the weights you want to serve, and it needs dedicated CPU or GPU capacity.
Does my business data get sent to OpenAI or another AI company?
Data stored on your server is not used to train public models and does not leave on its own. What crosses the network boundary is the context payload of a specific request when that agent is allowed to use an external gateway, and that transfer falls under the provider's commercial zero-retention API policies. The runtime, the databases, the documents, and the event log stay on your machine regardless. Configure a node with local model weights and no outbound model calls, and no inference request leaves the host.
How much does it actually cost to run each month?
Two lines: VPS hosting and per-token fees for external model calls. Because there is no per-seat fee, the monthly total does not change when the tenth or twentieth user joins the account. Moving to local inference removes the per-token line and replaces it with hardware that you own, sized against the models you want to run.
Can an agent send emails or take other actions without asking me first?
Not for irreversible or externally visible actions. Sending an external email, publishing content, deleting records, executing privileged commands, and monetary spend all stop at a human-in-the-loop gate and wait for explicit confirmation. Agents read, classify, route, draft, and update internal state within their declared scope. The irreversible step stays with a person.
What if I am not a developer? Can someone set this up for me?
Deploying and administering a Linux server requires technical proficiency, either in house or from an integrator. The installation documentation covers the prerequisites and the deployment runbook, and a managed service provider can carry the host duties as part of its contract. What the platform does not do is remove the need for someone to own that server.
Can different agents use different AI models?
Yes. Each agent is configured independently, so a classification agent can run on a local open-weight model while a drafting agent uses an external frontier gateway. That lets you put model spend where it buys accuracy and keep routine, high-volume work on local hardware.
How to start
- Confirm the host. Provision or identify a VPS with 2 vCPU, 4 GB RAM, and 20 GB SSD running Ubuntu or Debian. You finish this step knowing whether your current infrastructure qualifies or what to rent.
- Map your workflows. Review the component overview at /what-you-get against the work you want to delegate: inbox triage, task routing, document drafting, status updates. You finish this step with a short list of roles to configure.
- Run the installation. Follow the runbook at /docs/install to bring the node up and configure the first agents. You finish this step with a running node on your own hardware.
Set up your node: Set up your node opens the deployment path, and Read the install prerequisites lists the server requirements first.