Concept · Cornerstone

What is an agent workstation?

The persistent computer your AI agent lives on. Always on, isolated from your laptop, gated at the boundary. Here's the category we are defining, and what it changes about the work.

Updated April 30, 2026

An agent workstation is the persistent, isolated computer that an AI coding agent lives on. It is always on. It has its own filesystem, processes, and network. Privileged actions are gated at the boundary, which means the agent must request human approval before touching anything that matters. The agent does its work there, not on a developer's laptop.

That sentence is doing a lot. Let's unpack it, because the category is new enough that the words don't yet carry their weight.

What it is, and what it isn't

An agent workstation is not a cloud IDE. Cloud IDEs (Codespaces, Daytona, Coder) were built so a human can write code in a browser. The architecture optimizes for keystroke latency, terminal fidelity, and live-share collaboration between humans. There is no concept of an agent that runs unattended, no read-only peering primitive between agents, no passkey-gated boundary on privileged actions.

An agent workstation is not a sandbox. Sandboxes (E2B, Modal) are ephemeral execution environments where short-lived code runs and dies. They are excellent for running snippets, evaluating LLM-generated code, or providing a sandbox API to other products. They are not where an agent lives for days at a time, picking up context from a previous session, with persistent installed dependencies and long-running MCP servers.

An agent workstation is a persistent computer assembled around the assumption that the agent is the primary user. Always on. Isolated from the human's machine. Gated by the human's passkey. Composable with other agent workstations on the side.

The three structural problems it solves

The motivation for the category becomes obvious once you list the things that don't work when an agent runs on a laptop.

A persistent, isolated, gated workstation per agent fixes all three. The agent doesn't share your laptop's lifecycle. It doesn't share your credentials. And another agent can sit on its own workstation next door without colliding.

What "gated at the boundary" means

Most security-conscious agent setups try to constrain what the agent can do at the application layer: prompt injection guards, allow-listed commands, output filters. Those are useful, but they share a fundamental flaw: the boundary is inside the same process that an attacker (or a confused agent) is trying to escape from.

Ellul's Sovereign Shield moves the gate outside the agent's process. The shield runs as a separate system user with its own group memberships, holds session keys and OAuth tokens in its own memory, and forces every privileged action (git push, vercel deploy, secret reads, database writes) to flow through it. Kernel-level controls (ptrace restrictions, seccomp, AppArmor) prevent the agent from inspecting the shield's memory or attaching to its subprocesses.

When a privileged action arrives at the shield, the action pauses. The user's passkey-registered devices receive a notification. The user taps Touch ID, Face ID, or a hardware key to approve. The shield then brokers the action against the real credential, which the agent never sees.

This is a structurally different security model from "the agent has access and you trust it." The agent has access to the request; the shield has access to the credential. Even an agent that has been fully compromised by prompt injection cannot complete a git push without your fingerprint.

What you can do that you couldn't before

A handful of operational patterns become normal once the agent has its own computer:

Overnight runs. Kick off a refactor, close your laptop, sleep eight hours, wake up to a draft PR.
Phone-as-keyboard. Open the console on your phone in the subway. Read the agent's progress. Tap to approve a deploy. Walk off the train.
Parallel agents with division of labor. Coding agent on one workstation. Reviewing agent on the next. Documenting agent on a third. The reviewing agent reads from the coder's branch via read-only peering. There is no path for the reviewer to push, edit, or escalate.
Real credentials with real safety. The agent can hold real GitHub tokens, real production database access, real deploy keys, because the credential never enters the agent's process and every use is passkey-gated.
MCP servers with persistence. Long-lived MCP processes that index your codebase, your documentation, your design system, running on the workstation alongside the agent, no cold start.

Each of these is technically possible without an agent workstation. None of them are pleasant. The category exists because doing all of them at once, on infrastructure designed for it, is qualitatively different from cobbling together a screen session and a VPN.

When this is the wrong tool

If your agent work is genuinely bounded (short refactors that you watch, one-shot completions, no production credentials, no multi-hour runs) you don't need an agent workstation. Cursor or Claude Code on your laptop is enough, and the architecture overhead isn't worth it.

The shape of the category target: anyone running an agent for more than a few hours at a time, anyone running multiple agents at once, anyone whose agent ever needs to touch infrastructure where a mistake costs money. The line is roughly "this stops being a fun side-tool and starts being how I ship work."

What it is, and what it isn't#

The three structural problems it solves#

What "gated at the boundary" means#

What you can do that you couldn't before#

When this is the wrong tool#

See also#

What it is, and what it isn't

The three structural problems it solves

What "gated at the boundary" means

What you can do that you couldn't before

When this is the wrong tool

See also