Building a harness for non-technical users

The problem

Our lab builds agent harnesses into clients' production: systems where a model gets an environment and does real work in it, running commands, writing files, executing code it wrote itself, because that is where an agent's capability comes from. The people who use these systems are usually not engineers, and they should never have to be. That is the problem this note is about, stated plainly: how to build one system that keeps the full technical capability of a harness while presenting none of it, so that a customer who has never opened a terminal gets the same depth an engineer would.

The industry has just confirmed how real the problem is. Anthropic built Claude Code for engineers, watched people who do not write software use it for work that was never code, and in January shipped Cowork for exactly that audience, on the same agent runtime underneath. OpenAI kept Codex as its engineering surface and this month shipped ChatGPT Work for everyone else's desk. Neither second product is a stronger engine; each is the same class of machine presented to a different reader, and the judgment that this presentation deserves an entire product is the same conclusion our client work forced on us. What we learned building it resolves into three layers, the infrastructure that runs the harness reliably for many users at once, the work the agent does inside it, and the surface the user reads, and this note takes them from the base up.

Layer 1: The base it runs on

The base layer is the one no user ever sees, and we call it the infrastructure layer: everything that makes a harness run in production, reliably, for thousands of conversations at once, and that decides how one customer is kept apart from another. A production harness is not one agent serving everyone. Every customer conversation gets its own harness instance: a private workspace that persists for the life of the conversation, a sandbox wrapped around it, and a tool channel that carries only that customer's credentials. The workspace is the instance's memory, so a file written on one turn is still there on the next and standing context waits in it to be read on demand, and a scheduled sweep clears instances that have gone quiet. The sandbox is the instance's walls: the agent writes only inside its own workspace, and the network is closed except for one governed channel through which every tool call passes. We call the discipline single-tenant harnessing, one instance per customer conversation with nothing shared between instances, because the strongest way to keep one customer's machinery out of another customer's answer is for the two to have no surface in common at all.

Scope narrows again inside a single customer. Many of them run more than one store, and what we call the scoped turn re-derives everything the model can see and reach, every turn, for the one store the conversation is pinned to: the standing context is rewritten for that store or removed when it has none, the skill set is resynced to exactly that store's skills, and the tool channel is bound to the customer's credential for the life of the turn and refuses to carry anything outside one. One store's data cannot reach another store's answer even inside the same account, and standing context and skills that belong to other stores are not hidden from the model; they are never handed to it at all.

Running this fabric is why we manage the infrastructure end to end rather than renting a hosted agent runtime. The inner loop of an agent can come from an SDK, and ours does; what cannot be rented is the fabric itself: the sandbox profile, the egress policy, the credential scoping, which model serves which role, and the flag that can put the whole engine back to its predecessor at render time. Those guarantees are the product a client is paying for, and in a hosted runtime they are someone else's decisions. Run well, this layer is invisible, which is the point; everything else in the harness stands on it.

Layer 2: The work the agent does

On top of that base sits the layer where the work happens, and we call it the work layer. In the deployment this note draws on, every conversation opens a sandboxed workspace in which the agent writes and runs its own code, keeps files as working memory that outlives any single step, and hands the heavy parts of a question to parallel specialist workers, up to eight at a time, each starting on a clean context window and returning a short, distilled result. Standing knowledge about the user's business is materialized as files the agent reads when it needs them rather than text held permanently in its prompt. None of this is decoration: the files are how it holds more than a window's worth of work, the code is how it computes exactly instead of estimating, and the workers are how a long investigation reaches the end with its reasoning intact. The work layer is technical because the capability lives there, and it cannot be made less technical without turning the agent back into a text box.

Layer 3: The surface the user reads

The last layer is everything the customer actually reads, and we call it the surface layer: the reply, the progress the agent narrates while it works, the questions it asks back, the way it explains something going wrong. The people reading it here operate stores on a large online marketplace, their day is revenue, inventory cover, advertising spend, and rank, and nothing in that day has ever required a terminal. The work layer speaks the machine's language because it must; the surface has to speak the customer's, at full depth, because that is the product being paid for. The rest of this note is about the seam between the work and the surface, and production taught us the seam does not hold by itself.

The leak

The work layer reached the surface almost immediately. In one of the first sessions with a real operator, the agent mentioned in passing that a code-search tool was not installed in its sandbox, a sentence that is true, harmless to an engineer, and meaningless to a store owner mid-question about their account. Another session rendered the agent's private working notes as if they were the reply. The complaint that finally named the class arrived a month later, from an operator reporting that the agent talks through its process too much and too technically, and the narration they had been reading made the point for them: confirming that endpoints scope correctly, pulling the remaining slices, building the local join tables, every phrase a faithful account of real work and none of it addressed to the person paying for the answer.

The subtler finding was that our own instrumentation sided with the machine. The grader that scores production conversations asks whether the user's question was answered, and it was, every time; the machinery arrived alongside a correct answer rather than instead of one, so a detector built for correctness found nothing to object to. A defect of register, of the language the answer wears rather than the answer itself, is invisible to a correctness instrument, and every leak on record was found by a human reading transcripts.

The shared window

The obvious fix is a rule, and we shipped it: an always-on plain-language directive banning the engineering vocabulary everywhere the user reads, the endpoints and payloads and pipelines and the names of internal tools, under the principle that the agent should talk about the user's store and not its own machinery. Measured against production conversations in the hours that followed, the rule had no detectable effect on the register.

The reason turned out to be structural rather than a matter of emphasis. The agent's operating instructions ran to roughly twenty-one thousand tokens, and when we measured their composition, about ninety-three percent was written in exactly the mechanical register the new rule prohibited, the guidance on voice amounted to five percent and sat three quarters of the way down the file, and the text above the ban used one of its own banned words fourteen times. The model was being asked to write like an operator by a document written like an engineer.

The session compounds this, because the work layer and the surface share one context window. Everything the work layer does comes back into that window as residue, tool output, file listings, the agent's own narration of its own commands, so by the time the model composes the surface, the most recent and most abundant material in its context belongs to the work layer, and one prohibition set against twenty thousand tokens of counter-example loses. Context carries facts and voice through the same channel, and both leak.

The boundary

The design that follows is the separation of the work layer from the surface, engineered in two places, and a vocabulary rule on its own is neither of them.

Inside the window, the isolation we had already built to protect reasoning turns out to protect the layers as well. The specialist workers are the ones that touch the work layer's raw material, and they return distilled findings, so the bulk of it never enters the window that composes the surface, and standing knowledge waits in files until asked for. What remains contaminated after that is the instruction layer itself, and the correction there is not a longer ban but a rewrite: instructions that model the surface's voice all the way through, instead of legislating it from inside twenty thousand tokens of the work layer's language.

At the seam itself, whatever crosses from the work layer to the surface has to be treated as part of the product rather than a debug stream, which places the guarantee in code at the boundary, in the sense of our prompt-code boundary report: working text the reader was never meant to see is suppressed or translated at the point where output crosses to the reader. A register requested of a model is a request that non-determinism is free to decline, while a register enforced at the crossing is a property of the product.

Neither move thins the surface, and that distinction is the entire point. The operator who asks why spend jumped still gets the full machine: the account pulled, the computation run exactly, the parallel investigation across every campaign. What changes is the vocabulary of the reply, the same grounded depth stated in the reader's own domain, the store, the campaigns, the margin, with the machinery unnamed. The users who want no jargon do not want less depth, and the system should never make them trade.

What we learned

All of it returns this note to the split the labs made. An engineer reads the work layer as capability, because every visible command is transparency and transparency is control; a customer reads the same stream as a machine talking to itself. Both labs kept the first product for the first reader and built a second one for the second, and the engineering of that second product is largely the surface layer built as deliberately as the work beneath it, the same depth of machine behind a surface in the reader's language. That each of them concluded a repainted surface would not be enough matches what our measurements taught us: the separation is not cosmetic, it runs from the instruction layer through the context window to the final rendered reply.

For a lab that builds agents into clients' production, the lesson is that all three layers are product. The infrastructure and the work stay fully technical, because reliability and capability live there; the surface is built with the same intent as both, because it is where the value is perceived. The vocabulary in this note, the infrastructure layer, the work layer, the surface layer, the harness instance, the scoped turn, the boundary, is the one we now build client systems in, offered in the same spirit as the measurements: what production taught us, written down so the next team does not have to relearn it. A harness serves engineers the day the work layer runs; it serves everyone else the day the surface learns to leave the machinery behind.