In Two Planes of Work we made a promise: put an agent between people and the systems they work through, and the shape of the work changes — the person stops being the workflow engine and starts directing it. That piece was about the what. It left the harder question open: what does it actually take to build the agent in the middle, so that it behaves faithfully?
A promise is not a solution. For agent mediation to become one, we need delivery patterns and architectures that hold up under real work — and those are only starting to emerge. A lot of what's being tried doesn't make sense yet. Some of it does. What follows is our take on what does: one reference architecture, offered to adopt, adapt, or improve on — not the final answer.
You already have the hard parts
Start by noticing how little is actually missing. Look again at the mediation picture — a user, an agent, and a substrate — and take that last word seriously. A substrate is a system with its screens stripped away: the data, plus the rules that govern it, plus the operations it allows. A set of legal moves, not raw storage. Every system your business already runs is one of these, wearing a UX built for a human operator. The UX is so dominant we mistake it for the system itself: ask someone what their CRM is, and they'll describe its screens.
So take stock. You already have the substrates. You already have the users. Both of the expensive things are in place — and the substrates can be reached where they already live, through the same interfaces the screens use underneath. Most systems already expose them; where there's an API, there's a way in. Nothing has to be migrated, replaced, or rebuilt. What's missing is only the piece in the middle.
Two honest caveats come with that stock-taking, and they shape everything after. First, the substrates are never perfect — real systems are messy, and part of the work is meeting them as they are rather than as they should be. Second, and more important: "you have the users" means more than headcount. The users carry knowledge. A great deal of how the substrate is actually operated — which move comes next, and why — lives nowhere but in their heads. It was never written down; it isn't institutional knowledge; it's habit and judgment, walking around. Ideally that wouldn't be true. Usually it is — and turning it into something durable is part of what has to change.
The agent needs two things
And the piece in the middle is a humble object: an agent is just an LLM in a loop with tools. For it to operate a substrate faithfully — not improvise, not skip a step, not invent — it needs exactly two things:
- Access — the tools to reach the substrate where it lives.
- Understanding — the account of how to operate it correctly: what the things are, what rules must hold, and how to carry out work at every level of granularity, from a single transaction to a multi-phase, nested workflow.
Access without understanding is a loose cannon; understanding without access is a consultant with no keyboard. Supplying both is the entire job — and access is the familiar half: a tool, a connection, a key. Understanding is the half that bites.
Take a CRM with a sales funnel. For an agent to move a record through that funnel correctly — this stage before that one, this field required first, this transition never skipped — it has to understand the funnel. And no amount of poking at the API will teach it: the endpoints expose the operations, not the policy for using them. That understanding has to come from somewhere else — a procedure document, say. But in most shops the procedure document doesn't exist; the policy lives in the head of whoever runs the funnel.
So the name of the game is to get it somewhere the agent can see it — into the workspace. That can mean writing it into a capability directly, or, just as good, encoding it wherever it already lives and having the capability point there. A pattern we lean on: when the system is a spreadsheet, its rules already sit in a Read Me tab, so the capability doesn't copy them — it references them. Either way the tacit becomes legible, and the moment it does, it is two things at once: the instruction the person follows, and the program the agent runs.
The specification is the program
Ask where understanding comes from in ordinary software. Conventional software carries its rules and logic in code. But for that code to reflect what the business wants — not merely what happened to be in a developer's head — the intent had to be written down and specified first, then translated into code. Two costs come with that translation. It loses fidelity: a gap opens between what was specified and what got built, and it widens as both sides drift. And the code quietly becomes the de facto source of truth — so your operation's real rules end up living in the least readable, least governable place they possibly could.
An LLM runtime dissolves that gap — but not by magic, and this is the part worth being exact about. When the agent reads the account of how your systems work and acts on it directly, the specification can be the program. It isn't compiled into an executable somewhere else; read well, it is the executable. The bridge from spec to code, and the drift it breeds, simply falls away.
Can be is not is, though. The runtime only opens the door; walking through it is a matter of organization. The source of truth has to be arranged for the environment it now runs in, and that means clearing two bars at once:
- It has to stay maintainable by its human authors. People own these rules and keep them current; an account they can't read and edit will rot.
- And it has to be coherent to an agent running in a loop — organized so that for any given move, the model assembles exactly the right, complete instruction: nothing missing, nothing contradictory. Everything downstream depends on it.
Getting that organization right is the actual design problem. The runtime makes an executable source of truth possible; organizing it for both authors and agent is what makes it work. And underneath all of it sits a quiet piece of good news: you should have that governed account anyway. Every serious operation needs at least one source of truth for how its systems and rules work, and it should never be the code — it should live somewhere legible. So the ask is not "do new work." It is: take the account you already owe yourself, and put it where an agent can run it.
A workspace is where they're situated
"Where an agent can run it" is what we mean by a workspace — a plainer word than it sounds. A workspace is simply the environment an agent operates in: what tools it has, and what else around it is reachable. It is the whole reason one "LLM in a loop with tools" behaves differently from another — same model, different workspace, different system. And a workspace is, first and foremost, a directory. Anyone who has used a coding agent knows this in their hands: you open it in a folder, and everything the agent can know and do flows from what's arranged there.
So the move is small and natural: situate the access and the understanding inside that directory, in an agreed structure. Once the structure is agreed, it becomes a contract. You can drop any capable agent into the workspace, and by navigating the structure it can operate the substrates on the users' behalf, as intended — because everything it needs is arranged where it will look for it.
reviews · approves
reachable in place
This direction is not ours alone, and we won't pretend it is. Claude Code's plugins and skills are already on this path — packaging capability and instruction so an agent can pick them up and use them. A living workspace pulls those threads together into a single structure built to clear both bars at once: legible to its human authors, coherent to its agent runtime.
The shape of the directory
What does that structure look like? Two documents and five folders — laid out below. It begins in prose: an overview written first, so every later part traces to an agreed statement of what the system is. From it grow the schemas, tools, capabilities, and views — and, when the records live here rather than in the source system, the data. We didn't reason this set out from first principles; we arrived at it by building. It has turned out to be a good set of primitives: provided and kept current, they give the agent everything it needs to act while holding its degrees of freedom exactly where they belong — enabling and bounding it in the same move — and every one is a plain file a person can read, own, and co-author.
Two disciplines keep it honest, and both fall straight out of the two bars. First, every rule is factored, never duplicated. The part a machine can check with no judgment goes into a tool that refuses violations — enforcement that holds when nobody, human or model, is paying attention — and only the part that genuinely needs a reader stays in language. Second, there is one definition of every number. Every surface — a live board, an assembled report — computes from the same source, so nothing can quietly disagree with the substrate underneath it. Between them, these two make the guarantees structural rather than hopeful: a report literally cannot cite a record the rules exclude, because the tool that assembles it refuses.
Why it's living
One property makes it living, in a specific and mechanical sense: there is no line between using the workspace and extending it. The operating rule is five words — do it, or grow it. If a want is reachable with what's already there, the agent does it. If it's blocked on something missing — access, understanding, or a way to see — then growing that capability is the next move, deposited permanently as a file every later move reads. Every move pays twice: the task done, and the capability that remains. Wants recur; gaps don't. That is the whole engine of the compounding — the same request gets more powerful over time because it lands on everything the earlier moves left behind.
And it is never deployed and never finished — by design. Deploy is software's certificate of occupancy: the paperwork that exists only because the people who build a thing and the people who live in it are different parties. In a living workspace they are the same, working in the same place, and no one ever moves in. The workspace is in use from the first move and under construction forever; the balance between using it and building it starts near all-building and drifts toward all-using, and never quite arrives.
A reference architecture
We offer this as a reference architecture — a worked, general design to adopt, adapt, or improve on, not a claim to the one true way. We've built several real ones in exactly this shape and made them open: a client-commissioned literature review, an AI table-builder, a weekly research newsletter, a personal life-infrastructure tracker, and a manager for a coding agent's own sessions. Different domains, one structure — you can read them, and see the same skeleton under each.
Step back, and the whole thing sits squarely inside what Andrej Karpathy calls Software 3.0 — the shift to a new kind of computer you program in plain English. The open question that framing leaves is what an application looks like on that computer. This is our answer, offered in the same spirit the promise was made: you already have the substrates and the users. A living workspace is just the directory in the middle, where an agent finds the access and the understanding to stand between them — the governed source of truth you should have kept all along, finally in a form that runs.