An AI employee needs an office. Give it one you own.
An always-on AI agent belongs on a dedicated machine that serves its own model, not on a metered API. A chatbot sees what you paste into it. An agent sees your inbox, your file server, your calendar and your API keys, then acts unsupervised at three in the morning. That is a different privacy problem, and it needs different infrastructure: a rented DGX Spark in EU-Central or a box in your own office.
What an "AI employee" does today
The clearest example is OpenClaw: the project that started life in November 2025 as Clawdbot, was renamed Moltbot after Anthropic objected to the name, and now ships as OpenClaw under the MIT license from the OpenClaw Foundation. It went from launch to over 100,000 GitHub stars in under a week in early 2026 (CNBC), and the count has kept climbing since.
Architecturally it is not a chat window. A local Gateway process is the control plane: it holds sessions, tools, events and channel connections. You talk to it through the messaging apps you already use (WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Google Chat) or through its CLI, TUI and Control UI. It runs shell commands, drives a browser, reads and writes files, handles mail and calendar. And a heartbeat scheduler wakes it on an interval so it does things you did not ask for in that moment.
That last property is the whole distinction. OpenClaw is one instance of a general pattern that also shows up in Nous Research's Hermes Agent framework, in coding agents, and in every internal "ops bot" a team has quietly built this year. The stack is now boringly standard:
- Tool use: the model emits a structured call, a runtime executes it, the result comes back into context.
- MCP: the Model Context Protocol, donated by Anthropic to the Linux Foundation's Agentic AI Foundation in December 2025 and now the default wire format for tools across the major frameworks. Latest spec revision: 2026-07-28.
- Computer use: browser and desktop control for the systems that never got an API.
- Scheduling: cron or heartbeat, the thing that turns an assistant into an employee.
Why agent privacy is a categorically bigger exposure than chat
With a chatbot, the blast radius is what you typed. With an agent, it is everything the agent is standing next to. Consider what has to sit on the machine for an agent to be useful at all: mail credentials, calendar tokens, a messaging session per channel, SSH keys, cloud API keys, and read access to the files you work on.
The agent's context, which is what gets sent to whatever model you configured, is your prompt plus the email it just read, the file it just opened, the ticket it just fetched, and the shell output it just captured. Point that at a US-hosted API and you export a rolling sample of your business, chosen by a machine, with no human reviewing each item. For anyone with a GDPR obligation, that is a materially harder thing to reason about than "we use a chat assistant."
The evidence that this is not hypothetical arrived fast. In February 2026 SecurityScorecard reported 40,214 internet-exposed OpenClaw instances, with 35.4% flagged vulnerable; Infosecurity Magazine reported 12,812 exposed instances susceptible to remote code execution. Giskard's researchers demonstrated prompt-injection exploitation of a deployment in January 2026, and Snyk's ToxicSkills audit found detectable prompt injection in 36% of skills published to the ClawHub marketplace. OpenClaw's own docs are blunt about the model: treat inbound messages as untrusted input, require pairing approval on DM-capable channels, and note that tools run on the host by default.
| Dimension | Chat assistant | Autonomous agent |
|---|---|---|
| What leaves the machine | What you paste | Whatever the agent reads to do its job |
| Who selects the data | A human, per message | The model, per step |
| Credentials held | None | Mail, chat, cloud, SSH, files |
| Runs when you sleep | No | Yes, that's the point |
| Worst-case failure | A leaked prompt | An injected instruction executed with your rights |
| Natural cost shape | Bursty, per-token | Continuous, fits a flat rate |
This is no argument against agents. An agent is an employee with keys to the building, and you would not seat that employee in a rented desk in another jurisdiction if you had the choice.
Which open agentic models fit in 128 GB
An agent's model needs three things above all: reliable structured tool calling, enough context to hold a long task, and enough instruction-following to not wander. Nous Research's Hermes family is explicitly post-trained for that job.
Hermes 4 shipped in August 2025 (technical report arXiv:2508.18255) in 14B, 70B and 405B sizes, all post-trained from Meta's Llama 3.1 bases and released open-weight on Hugging Face under the Llama 3 community license. It is a hybrid-reasoning family: the model can deliberate inside <think>…</think> before answering, toggled by flag or system prompt. Tool calls use the Hermes <tool_call>{…}</tool_call> format, for which parsers ship inside vLLM and SGLang, meaning your serving stack understands the calls without glue code. Nous followed the models with Hermes Agent, an open agent framework, in early 2026.
On a DGX Spark's 128 GB of unified memory, the practical tier is the 70B class quantized to FP8 or 4-bit: Hermes 4 70B, Llama 3.3 70B and Qwen3-class models of similar size. They stay resident with tens of gigabytes left for a long context window, which is where an agent spends its memory. The 405B tier does not fit; the 14B tier fits trivially but is where tool-calling discipline starts to fray.
Be honest about the trade here, because OpenClaw's own local-models documentation is: it recommends at least a 64k context window for local models, warns that "small or heavily quantized checkpoints raise prompt-injection risk," and tells you to run the largest full-size variant you can host. Their reference hardware suggestion for a comfortable local setup is two maxed-out Mac Studios or an equivalent GPU rig. A single Spark is in that class of machine, which is why it suits this workload and a laptop does not.
Per-token billing punishes an always-on agent
I won't invent a token count for your agent, and you should distrust anyone who does. The shape of the two bills is enough.
A metered API charges per token, and an agent's token consumption is not driven by how much you use it. It is driven by its heartbeat interval, the size of the documents it ingests, and how many reasoning steps a task takes, all of which grow as the agent gets more useful. Every improvement to your agent is a line-item increase. That is a bad incentive to put between yourself and automation you want more of.
A dedicated node charges the same whether the agent is idle or hammering. Overnight batch work, hourly inbox triage, a scheduled scrape at 04:00, a retry loop that ran three times longer than expected: all free at the margin. Continuous, unattended, unpredictable-per-step workloads are the textbook case where flat-rate capacity beats metering, and an AI employee is the most continuous workload most teams will ever run.
A practical starting architecture on a Spark
Run the model server and the agent runtime on the same box, reach the agent only through your own tunnel, and keep its credentials on that machine instead of sending them through a third-party API.
# 1, serve an agentic model with native Hermes tool parsing vllm serve NousResearch/Hermes-4-70B-FP8 \ --max-model-len 65536 \ --enable-auto-tool-choice \ --tool-call-parser hermes \ --host 127.0.0.1 --port 8000 # 2, point the agent at the local endpoint, never at a public API export OPENAI_BASE_URL=http://127.0.0.1:8000/v1 export OPENAI_API_KEY=local # 3, run the agent as a service, not a terminal you forgot to close sudo systemctl enable --now openclaw
Nous publishes Hermes 4 70B as BF16 plus an official FP8 checkpoint (NousResearch/Hermes-4-70B-FP8); vLLM reads the quantization config from the repo, so no --quantization flag is needed. Budget for it: FP8 weights are roughly 70 GB, which fits 128 GB with room for a 64k KV cache, while the BF16 repo at roughly 140 GB does not fit one node. If you want more headroom, community 4-bit AWQ builds of the same model exist on Hugging Face, at some quality cost.
Then the parts that matter more than the install:
- Bind locally, tunnel deliberately. Nothing on 0.0.0.0. Reach the Gateway over WireGuard or Tailscale. The 40,000-instance exposure number above is what happens when this step is skipped.
- Sandbox the tools. Run the agent as its own unprivileged user, in a container, with an explicit allowlist of directories. "Tools run on the host by default" is a default to change, not to accept.
- Scope credentials down. Give the agent its own mail account, its own API keys, its own SSH key with a forced command. Never your personal keychain. Assume any credential the agent can read is a credential a prompt injection can exfiltrate.
- Audit the skills you install. A third-party skill is code plus instructions running with your agent's rights. Treat a skill marketplace like npm on a bad day.
- Keep a human gate on irreversible actions. Sending, paying, deleting, publishing. Read-only autonomy plus approved writes is as far as reliability goes today.
Where agents still fall over
I run agents like these, and they are not employees yet, whatever the framing. Long multi-step tasks still drift. The error rate compounds per step, so a ten-step job fails far more often than a two-step job with the same per-step accuracy. Prompt injection remains structurally unsolved: any agent that reads untrusted content can be instructed by that content, and no model in this class is immune. Smaller local models are noticeably worse at both. And a scheduled agent fails silently by default, which means you need monitoring on the agent itself, on top of the monitoring on the box.
The honest position is that an autonomous agent today is a very good junior doing narrow, repetitive, mostly-reversible work under review, not a headcount replacement. That is still worth a lot. Give it a dedicated machine with its own scoped credentials while the field figures the rest out: the failure modes above are much cheaper when the blast radius ends at one box.
The short version: give it a dedicated machine
Agents changed the privacy question from "what did I send" to "what can it reach." An AI employee needs a machine of its own for your data and keys, and a bill that does not punish you for letting it work. A dedicated Spark in EU-Central, assigned only to you and serving your own model, or one on the shelf in your own office, fits that.