A growing share of our engineering happens inside an agentic session: a model with a shell, a checkout and a test suite, working on one feature in that feature's workspace, with a person directing it. Whatever this week's opinion says about the ceiling of these tools, the floor has moved. By February, Spotify's co-chief executive was telling an earnings call that their best engineers had not written a line of code since December. The longer argument is written up in Spec-driven development, at richardstubbs.io. The session is where the work happens. That sentence has an operational consequence most of the commentary skips: the thing hosting the session is infrastructure now, and it gets the questions we ask of any infrastructure. What does it make possible, what does it cost and who can inspect it, change it or switch it off?
The harness decides what a session can reach. Which filesystem, which credentials, which network, which memory of previous work, what gets logged and where the log lives. That is a boundary in the exact sense the rest of these insights use the word: a rule somebody specifies and a machine enforces. Run your sessions in a hosted harness and the boundary is specified elsewhere, logged elsewhere, retained on somebody else's terms. For exploratory work that trade is fine. For the sessions that build our features, on our estates, against our customers' systems, it fails the ownership test the same way a hosted control plane does: possession of the output, control of nothing underneath it.
So we are building our own.
Introducing micro-zero
The design comes first, written down before any code, each decision recorded with the failure the alternative produces; the code will be held to the document, not the other way round.
What it is¶
A workspace session, reachable from a browser, belonging to a real Linux user. Authentication is the machine's own, through PAM: no parallel account system, no identity invented for the occasion. One feature being built gets one session in that feature's workspace, with the shell, the checkout and the tests, and the person steering it from whatever device is to hand.
The design rule underneath it is the one these insights keep arriving at: the part that faces the network holds no privilege, and the part that holds privilege accepts no network. A browser talks to an unprivileged gateway, which runs with an all-zero capability set. The privileged broker that can spawn a shell listens on no TCP port at all, only a filesystem-permissioned local socket. And the shell that appears runs as the authenticated user, never as the broker that spawned it.
Be precise about what that buys. A compromised gateway is not harmless: it relays terminal streams and file transfers, so whoever owns it sees what the sessions it carries see. What the design bounds is escalation. Owning the gateway confers neither root nor the host's filesystem, because the gateway can ask the privileged side for only a short, enumerated list of things: authenticate a user, spawn a shell, open a path, signal a process. The broker refuses each unless the request belongs to the authenticated user who owns the target, and adding a verb to that list is a design change, not a feature. Paths are resolved by the kernel itself, confined beneath the session's root with symlink escapes refused, so path traversal is removed from the broker's interface rather than defended against in application code. Passwords are held transiently and zeroed; the broker's privilege is dropped between fork and exec, before any user code runs.
Those are claims a test can check, so the build will gate on tests that check them. The assertions worth gating on are the ones that state the split is intact: that a shell spawned by the privileged broker runs as the target user, that the broker accepts no TCP connection, that traversal attempts are refused end to end. A security design that is never restated as a failing test is a press release.
Which way up¶
Most harnesses run inside a general-purpose desktop operating system, alongside years of accumulated packages, services, credentials, mounts and reachable vulnerabilities. The OS is the world and the harness is a guest in it, inheriting whatever that world can reach. An agent running as a process on your desktop can turn any reachable weakness into a route beyond its intended workspace, and tidying up after it means believing you found everything. We think that is upside down.
In micro-zero the harness is the outer layer and the operating environment runs inside it. The harness will create a minimal operating space from a micro-substrate-validated image, its provenance and scan state checked before the session starts, then grant into it only the tools, files, network reach and credentials the session requires. Control is added to a declared boundary rather than subtracted from a general-purpose desktop. Shell, desktop and workspace live inside that boundary rather than loose among the operator's own processes, and cleanup is deletion of the session, not a search for everything it touched.
The flip is not only for the agents. A person will be able to take a desktop inside the harness on the same terms: the same boundary, the same validated start, with the agent working alongside them in the same bounded space. One limit, stated plainly: the host kernel remains shared and must be secured separately. The image boundary removes accumulated userland exposure; it does not remove kernel escape risk.
The memory, and whose it is¶
A session that starts blank re-derives the organisation every morning. The longer the work runs, the more the context is the work: long-running context belongs with the agent, not in a scrollback. So micro-zero will connect to hive-mind, the search over our vault and shared corpora. The read path lets a session ask what the organisation already knows, what was decided and why, and what earlier work discovered. Retrieved material remains evidence, not authority: appearing in memory does not turn text into an instruction the agent may execute.
The write path is separate, and it needs more scrutiny than the read, because an agent can be wrong, can argue from incomplete evidence or can be led by something it retrieved. These sessions are designed to run long, days and weeks on one feature, and what a session learns will be recorded as it goes in a provenance-carrying feature journal: which session produced it, when, from what evidence, against which feature. Promotion into shared organisational memory will be a separate act with a review in it. An agent may propose what the organisation knows; it does not silently decide it. That is also what makes the disposability above safe to mean: deleting a session loses no declared durable state once its repository, its journal and its accepted contributions are current, and uncommitted state stays disposable by design.
The connection will have an identity of its own: a desk token issued to the service, its read scope and its contribution scope defined separately. Never a person's credential copied into a config, because a service reading with a human's token acquires that human's reach and makes the audit trail say a person did something a machine did. Context is becoming the asset in this kind of engineering. An asset gets an owner, a scope and an audit trail, or it leaks.
Why "zero"¶
The zero is where every session starts. A clean workspace, a clean shell and no authority beyond what the authenticated user already holds. That is a narrower claim than "no authority", on purpose: a session runs as a real Linux user and inherits exactly that user's files, groups and network reach, which is a plain, inspectable boundary. What the harness adds on top of it is nothing: no standing credentials, no service account riding along, no privilege the user did not bring. What a session accumulates that is worth keeping goes back to the estate: committed to the repo, written to the vault, recorded against the feature. The session itself remains disposable. A harness built on any other assumption turns the chat transcript into the system of record, and a chat transcript is the worst database anyone has ever operated.
What it costs¶
Building it, when a dozen hosted products would love to do it for us and self-hosted pieces already solve parts of the problem: browser terminals, isolated workspaces, agent desktops. Those components exist. The reason to build is that the privilege boundary, the machine identity and the memory path are the product here, and adopting a system that combines them behind one privileged service would inherit the decision micro-zero exists to control. Running it: another service with an attack surface precisely where it is most useful, which is why the privilege split above is the one decision every other decision leans on. Ownership also means maintaining and rescanning the validated images, rotating service identities, expiring abandoned sessions, defining what the audit trail retains and recovering when repository or journal write-back fails: a disposable session is cheap only while the durable paths around it are explicit and tested. And where it is allowed to listen will be a named decision rather than a default. On a lab network this is an ordinary admin tool; on the public internet it is a remote-shell endpoint. Until that decision has a named owner the gateway does not run in production at all. Then the usual cost of owning anything: when it breaks, the pager is ours.
What it buys is the other side of every entry here about rented control planes. The boundary around the sessions that build our systems is ours to specify, inspect, change and switch off. The work those sessions produce lands in repositories and a vault we hold, read back through a memory service we run, under identities we issue. The tools changed this year. The questions did not.