An AI employee needs an office. Give it one you own.

A chatbot sees what you paste into it. An agent sees your inbox, your file server, your calendar, your API keys, and then acts, unsupervised, at three in the morning. That is a different privacy problem, and it deserves a different piece of infrastructure.

What an "AI employee" actually does now

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 actually work on.

Now consider that the agent's context, the thing sent to whatever model you configured, is not your prompt. It 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 are not exporting queries. You are exporting a rolling sample of your business, chosen by a machine, without a 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.

None of this argues against agents. It argues that 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 practically interesting tier is the 70B class at 4-bit, Hermes 4 70B, Llama 3.3 70B, Qwen3-class models of similar size, comfortably resident with tens of gigabytes left for a long context window, which is what an agent actually burns memory on. 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, not below it, which is precisely why it is the interesting box for this workload rather than a laptop.

The always-on cost argument

We are not going to invent a token count for your agent, and you should distrust anyone who does. But note the shape of the two bills.

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 structure to put between yourself and automation you actually 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 went 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

Model server and agent runtime on the same box, agent reachable only over your own network, secrets never leaving it.

# 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 where the reliability actually lands today.

Where agents still fall over

We run these. 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. It is also exactly the kind of thing you want running on your own hardware while the field figures the rest out, because the failure modes above are much cheaper when the blast radius ends at a machine you own.

The short version

Agents changed the privacy question from "what did I send" to "what can it reach." An AI employee needs a place to sit that has your data in it, your keys in it, and a bill that does not punish you for letting it work. A dedicated Spark in EU-Central, or one on the shelf in your own office, is that place.