Smart Node runs AI agents for your restaurant's reservation inquiries, guest communication, staff coordination, and marketing workflows on a server you own, with no per-seat licensing fee and with guest records stored on your infrastructure rather than inside a vendor's multi-tenant cloud.
If you have been comparing AI for restaurants and stopped at the point where guest names, phone numbers, and conversation history leave the building, this page is about that boundary: what runs on your hardware, what still crosses the network, and which actions a staff member has to approve before they happen.
Short answer: Smart Node is a self-hosted multi-agent platform that takes over the high-volume, repetitive communication work of a restaurant operation: receiving reservation inquiries through web chat, Telegram, and voice channels, sending confirmation emails after staff sign-off, routing task reminders to the right person, and drafting marketing sends for human review. A single node serves your full team with no per-user licensing fee, and guest names, contact details, conversation threads, and operational records are stored in local databases on your server.
Next step: confirm the hardware minimum and read the install runbook. Set up your node.
What you get
Five capabilities run on your server. Four of the five produce work that a staff member reviews before it reaches a guest or the public.
| Area | What agents handle | What requires staff sign-off |
|---|---|---|
| Reservation inquiries | Inbound requests from web chat, Telegram, and voice, each logged to a persistent thread | Every outbound confirmation email |
| Guest communication | Answers, thread history, follow-up timing | Any external message before it sends |
| Staff coordination | Task routing, shift reminders, prep checklists by role | Privileged system changes |
| Marketing | Draft campaigns and promotional copy | Every send to a list |
| Data storage | Guest names, contact details, and operational records in local databases on your server | Not applicable |
The isolation is what makes those boundaries hold. Each agent runs as its own Linux system account with its own declared tool grants, so the agent answering reservation inquiries cannot read the marketing agent's mailbox or reach a tool it was never granted. Third-party API keys and mailbox passwords stay in a local secret store and are resolved at execution time; they are never written into a model prompt. Every action an agent takes is appended to an event log on your server, which is where you look when a guest says a confirmation never arrived.
If that inventory matches how your venue already works, the next step is a node on a machine you control: Deploy a private node.
How it works in a normal week
A 60-cover restaurant, one manager, six staff, mid-week.
Monday morning. A guest submits a reservation request through the web chat widget on the restaurant site. An agent receives the inquiry, logs it to a conversation thread, and drafts a confirmation email. The manager reviews the draft and approves the send. The confirmation goes out from the restaurant's own mail domain, and the approval is recorded.
Tuesday. A Telegram message arrives asking about dietary options. The agent answers inside the Telegram channel and stores the thread on the server. No staff action is needed for that inbound reply.
Wednesday. The weekend promotion draft is waiting in the human review queue. The manager edits two lines and approves it. The send executes only after that confirmation, and the edited version is what goes out.
Thursday. The prep workflow for Friday runs on its own. Shift assignments and the opening checklist route to staff through internal messaging. No external email is involved, and nothing needs approving.
Friday evening. A voice inquiry comes in and the agent handles it in real time. The call log is written to the server.
Two deliberate outbound sends left the restaurant that week, the confirmation and the campaign, and a named person approved both. The rest was internal coordination and record keeping, with the event log holding the sequence.
What it costs to run, and the trade-off
Minimum hardware for a node that uses external model gateways is 2 vCPU, 4 GB RAM, and 20 GB SSD on Linux (Ubuntu or Debian). A VPS at that specification is a standard product at most hosting providers; current rates vary by provider, so check them against your own quote. There is no per-seat fee, and one node serves the whole team whether that is six people or sixty. When an agent routes a task to an external frontier model gateway (Anthropic, Google Gemini, or OpenAI), that provider bills per token, and the volume tracks the number of guest conversations and how complex each one is. Running high-accuracy models locally instead, with no external calls at all, requires dedicated CPU or GPU hardware sized to the model you choose.
The trade-off has two parts, and both land on you. First, self-hosting means the organization, or an integrator you pay, owns host security, operating system updates, monitoring, backups, and recovery. Second, on the default configuration the reasoning step leaves the building even though the records do not. When an agent handles a multi-part guest question or drafts a promotional email, the context payload for that request travels over the network to an external model provider, governed by that provider's commercial zero-retention API policy rather than by your local storage settings. If no guest-related content may leave your infrastructure, the deployment has to run local model weights on dedicated hardware with outbound model egress disabled. That is a supported configuration, and it is a different machine, budget, and setup effort than a 2 vCPU VPS.
Warning: A human approval gate holds the outbound email. It does not hold the inference request behind the draft. If the agent used an external model gateway to write the confirmation, that request left the server before the manager saw the draft. The gate protects the send, not the reasoning step.
Who this fits
It fits when:
- You field 30 or more reservation inquiries and guest messages a week and want agents handling the first response across web chat, Telegram, and voice.
- Keeping guest names, emails, phone numbers, and conversation history on infrastructure you own is a business requirement or a stated preference.
- Your licensing cost should stay flat as you hire, rather than rising with every seat.
- You have or can rent a Linux VPS (Ubuntu or Debian) with at least 2 vCPU and 4 GB RAM.
- You have a technical staff member, or you can engage an integrator for Linux setup and ongoing administration.
It does not fit when:
- You need a direct integration with a named reservation platform such as OpenTable, Resy, or SevenRooms. Those are not built-in connections in this architecture.
- Your workflow requires marketing or guest emails to fire automatically with no human approval step. Every external send waits for a person.
- Nobody on your side can administer a Linux server and you cannot retain an integrator.
- You need guaranteed local-only inference on a standard VPS. That runs on the default hardware only if you provision dedicated GPU capacity.
Frequently asked questions
Can the AI handle reservation requests automatically, without someone watching every message?
Inbound requests, yes; outbound confirmations, no. Agents receive and log every inquiry without staff intervention, then draft the reply. A staff member approves the confirmation before it sends, so the inbound layer runs unattended while the outbound layer always has a named approver.
Where is my guest data stored, and does any of it go to a cloud service?
Guest names, contact details, and conversation history live in local databases on your server, along with the event log of agent actions. The one thing that leaves is the content payload of a prompt routed to an external model gateway when an agent needs frontier reasoning, and that transit is governed by the provider's commercial zero-retention API policy.
What stops the AI from sending emails to guests on its own?
A mandatory human-in-the-loop gate holds every outbound external email until a staff member confirms it. The platform classifies external email as an irreversible action, and irreversible actions require explicit human confirmation before execution.
How does the cost compare to a per-seat restaurant SaaS tool?
There is no per-seat fee, so headcount does not change the licence line. You pay for a VPS that meets the 2 vCPU and 4 GB minimum, plus per-token fees at whichever model gateway your agents use, scaled to conversation volume. Against a per-seat tool the saving grows with the number of people who need access; hosting prices depend on your provider.
Does the AI use my restaurant's data to train public AI models?
No. Data stored in the local databases on your server is not used to train third-party public models. Context sent to an external gateway during inference is handled under that provider's commercial API terms, which is a separate question from training and is the reason the trade-off above matters.
Do I need a developer to set this up?
You need someone comfortable administering a Linux server, or an integrator who is. Deployment and day-to-day administration are not designed for a non-technical owner, and there is no hosted setup service behind this product.
Can it connect directly to OpenTable or Resy?
Not as a built-in capability. No named third-party reservation platform integrations are listed for this architecture, so that connection would take a custom tool integration, and it cannot be presented as available out of the box.
How to start
- Confirm your server meets the minimum: Linux (Ubuntu or Debian) with 2 vCPU, 4 GB RAM, and 20 GB SSD, plus a model gateway credential from Anthropic, Google Gemini, or OpenAI if you intend to use external inference.
- Review the component overview to confirm the agent types and channels cover your workflows: reservations, email, Telegram, voice, and marketing.
- Read the installation runbook for the full prerequisite checklist and the setup commands.
- Deploy your node. From that point, your agents, channels, and workflows run on your infrastructure, and the event log on your server is the record of what they did.
When the prerequisites check out, the install path is the whole job: Get started.