A dedicated AI agent machine: what your spare PC needs beyond tmux
You should be able to close your laptop without losing the job, exposing your keys or losing control of what happens next.
A dedicated AI agent machine is a computer set aside to run your agent and its tools. It can use a cloud model without a local GPU. A spare PC solves laptop sleep and resource contention. Reliable work also needs recovery after a crash, protected credentials, outbound limits, a working stop control and a record you can inspect.
If you already run Hermes, OpenClaw or Claude Code on a spare PC, server or DGX Spark, the useful question is what happens when that setup goes wrong. Staying powered on is a start. It does not tell you whether a restarted job will repeat an action.
- A dedicated AI agent machine separates the agent's workload from your daily computer, but its accounts and network access still need limits.
- Restarting an agent process does not establish which outside actions already completed.
- Credentials and outbound controls need protection from the account running the agent.
- Test recovery, access, stopping and the action record with disposable work before relying on the machine.
Why people give their agent its own computer
Closing your laptop should not abandon the job on it. A separate machine also keeps agent builds and browser sessions from fighting your daily work for resources. You can leave the tools installed, keep project state in place and reconnect when you need to inspect something.
Ken Mazaika's account of his agent setup makes availability the starting point: persistent files and scheduled work on a machine that does not disappear when his laptop sleeps. Pedro Alonso's home lab uses tmux sessions per project, with mosh and Tailscale for reconnecting from another device. Those are useful answers to an ordinary operational problem.
Separation can also keep an agent away from your personal files and everyday logins. Microsoft's guidance for evaluating OpenClaw calls for a dedicated VM or separate physical system, dedicated credentials and non-sensitive data. It also calls for monitoring and a rebuild plan. A separate chassis alone does not supply those controls.
This article assumes you have chosen to host the tools yourself. For the earlier decision about where execution should happen, use the local vs cloud AI agents guide.
What the usual setup gets right
You do not need a local GPU just to call a cloud model. Mazaika's setup and lleg.dev's mini-PC guide both make that choice. Running model inference locally is a different workload with its own requirements. Buy for the work you actually intend to run.
The lleg.dev guide also puts access through Tailscale rather than opening the services to the public internet, runs Hermes as a service and uses Orca to manage coding agents in separate Git worktrees. Private remote access, service management and separate working copies all earn their place. Keep the service account separate from your personal account, and leave your personal credentials off it.
Credit the tools for the problems they solve. tmux lets you detach and reattach to a terminal session. A service manager can start a process again. A worktree gives a coding agent its own checkout. None of those statements establishes that an unfinished task resumes correctly or that the process cannot read another directory.
Five things the box still cannot do for the agent
These are checks for your configuration, not claims that every harness lacks these features. Some setups already supply parts of them. Run the checks with fake tokens, sample files and a test endpoint that has no live consequences.
1. A restarted process needs to know what already happened
Suppose the agent submits a request, the destination accepts it, and the process crashes before saving the receipt. On restart, a transcript may show an unfinished step even though the outside action happened. Repeating it can create a duplicate.
KeepState's architecture documentation draws that boundary explicitly: restoring a machine checkpoint cannot reverse a completed action in an external service. It recommends making external actions safe to retry, including idempotency, where the destination recognizes a repeated request as the same operation.
Check it: point a disposable task at a test endpoint that records request IDs. After a request arrives, use kill -9 <agent-pid> on that test agent and watch what happens when your service manager restarts it, or restart it yourself. Inspect the endpoint and the saved job record. Repeat around the point where the receipt is saved, then test a reboot separately.
A useful result shows whether the request completed and prevents a duplicate. A journal should retain the intended action, its stable ID and its receipt. A journal alone cannot guarantee this for every external service: if completion is uncertain and the destination cannot recognize a retry, pause for reconciliation. The long-tasks guide explains why continuity needs more than a live process.
2. The account running the agent may also hold its keys
The lleg.dev guide stores Hermes tokens in an .env file readable by the service account. That keeps other ordinary accounts out. Code running as the service account can still read it. A malicious skill does not need to persuade the model to reveal a secret if its shell can open the file.
Check it: place a dummy token file under the same ownership and permissions as the real token file. From the agent's actual account and execution environment, try cat /path/to/dummy-token-file > /dev/null. A successful read means that account can retrieve the contents. Do not paste real keys into a terminal transcript or an agent conversation to prove the point.
For credentials the agent should use without reading, put the raw key behind a separate service that permits specific operations on its behalf. Protect that service's configuration too. Merely hiding a value from the model's prompt leaves it exposed if the agent's tools can retrieve it. The permissions guide covers how to narrow what that credential can authorize.
3. Private access to the box does not limit its outbound traffic
A private connection lets you reach the machine without publishing its control interface. It does not, by itself, decide where the agent can send a file. Microsoft's OpenClaw guidance separately recommends restricting outbound access to required destinations.
Check it: from the agent account, inside the same container or network environment as its tools, run curl -I https://example.com/, provided that domain is outside your allowlist. Send no task data. If it connects, the path permits that destination. If it fails, inspect the enforcement log to distinguish a policy denial from a DNS, certificate or connectivity failure.
This probes an unknown destination from the policy's point of view, not a random site carrying your files. Follow it with checks of other enabled network tools. An outbound rule enforced outside the agent must cover those paths, and the agent account must be unable to rewrite it. An instruction saying to visit approved sites is not that control.
4. STOP needs to work without the agent's cooperation
A chat message asking the agent to stop depends on it processing the message. Killing a tmux session may also leave a child process, scheduled job or remote request running. You need to know which work your stop control actually reaches.
Check it: locate your STOP control before starting a disposable task that launches a child process and queues a harmless request to your test endpoint. Trigger STOP, then inspect the process tree, queue and endpoint. Check that no new action can start under the withdrawn permission and that a service restart cannot quietly resume it.
Keep the stop control outside the account whose work it stops. Record anything already submitted that cannot be recalled. Stopping local execution does not undo an accepted remote request, so the record must distinguish work prevented from work already completed.
5. Yesterday's work needs a record you can read
A completion message leaves out the part you most need when something breaks: what the agent tried, what actually changed and where it stopped. With concurrent agents, you also need to attribute each action to the job and account that performed it.
Check it: pick yesterday's task, or a completed disposable run. Without asking the model to reconstruct events, find the instruction, actions, destinations, permission decisions, failures and output receipts. Trace a claimed result back to what changed. Check that denied actions and your STOP event appear too.
Keep the authoritative record somewhere the agent cannot silently rewrite. The audit-trail guide explains the useful fields. That record also lets you move from approving each action to monitoring familiar work without giving up the ability to inspect it.
Box, VM or container
Choose according to what must be kept apart. Convoy's isolation guide distinguishes runtime restrictions, containers, virtual machines and separate machines. It also makes a point worth checking before you launch another coding agent: worktrees separate edits, not processes or credentials.
- A dedicated physical box separates the workload from your daily workstation. Shared folders, credentials and reachable systems can still connect their risks. Do not leave your personal home directory mounted just because the hardware is separate.
- A VM supplies a separate guest kernel and a convenient rebuild boundary. Its host integrations and shared folders still need review. A snapshot does not roll back an action already accepted elsewhere.
- A container can limit filesystem and process access when configured for that purpose. Review mounted paths and privileges. A container with broad host access defeats the separation you meant to create.
- A Git worktree gives each agent a working copy for parallel edits. It does not stop a process running as your user from reading your other files.
These choices can be combined. A spare server can host separate VMs for unrelated work, with tighter tool restrictions inside each. Use the same recovery, credential, outbound, STOP and record checks wherever the agent runs.
What this means for the OS on that machine
You can build these controls on stock Linux with a harness, service management, restricted accounts and separate enforcement services. That is real engineering, and a well-configured setup deserves credit. Changing the OS label does not prove better behavior.
The harness manages the agent's loop: instructions, model calls and tools. The system underneath must preserve the unfinished job and its action receipts, protect credentials, enforce outbound rules, carry the stop decision across restarts and retain the record. If the agent account can rewrite those limits, your setup depends on it choosing to obey.
ERIKA is being built as that kind of operating system for a machine you own. This describes the direction, not a claim that it has passed the checks above. For the wider definition, read what an AI operating system is.
FAQ
Do I need a GPU to run an AI agent at home?
Not if the model runs through a cloud API and the local tools do not need one. Local model inference is a separate workload. Choose hardware for the model and tools you actually plan to run.
Should I run my AI agent on a separate computer?
A separate machine can keep agent workloads away from your daily files and logins. A VM can also provide separation. In either case, restrict credentials and network access, and test recovery and stopping before relying on it.
Is a spare PC, mini PC or DGX Spark better for an agent?
Start with the workload. A cloud-model agent and local model inference have different requirements. This guide does not rank hardware; use the same recovery, access and stopping checks on whichever machine you choose.
What happens to an AI agent when the machine reboots?
That depends on the setup. A service manager may restart the process, but unfinished work needs saved task state and records of completed outside actions. Where completion is uncertain, the job should pause for reconciliation rather than blindly retry.
Sources
Sources checked October 29, 2026. The exercises above are our proposed checks, not reported test results for these tools or for ERIKA. The personal build logs describe their authors' configurations.