What Coding Agents Ship When You Govern Their Context

Most of the coding-agent conversation is about the model and the prompt. Very little of it is about the thing I keep watching break in practice: what context each step of the work is allowed to see. A one-shot agent gets everything at once and no second look. A real engineering org does the opposite. It hands the designer a brief, the developer a spec, the reviewer a checklist, and it keeps those lanes separate on purpose.

A week ago I argued for strategic ignorance: that isolation, not more context, is the under-planned move in agent design. This is me testing that argument. I built a small lab to run the difference directly, and I ran the context distribution through ctx and ContextNest so it was governed, versioned, and reproducible instead of concatenated into one prompt.

One request, three context regimes

Each run gives three arms the identical one-line request and the identical model (Kimi-K2.7-Code). The only variable is context discipline.

• raw: one prompt, one shot. No stages, no standards, no review.
• leaky: a real multi-role pipeline, but every role runs in one shared directory and receives all context at once. Every standard, every prior file, unfiltered.
• tight: every role runs in its own directory and receives only the context it needs, pulled from the vault by name, plus two feedback loops (a design review, and an evaluation that actually runs the app).

The context path is the experiment

Here is the part that matters for anyone building agent systems. In the tight arm, the standards and the role briefs are not baked into a prompt. They live as versioned nodes in a ContextNest vault. Before a role runs, a deterministic ctx resolve selects the specific nodes that role is permitted to see, and ctx read pulls their governed bodies into its working directory. That selection is the isolation. The leaky arm skips the selection and does ctx list | ctx read across everything.

ContextNest is the layer deciding what each agent sees. The isolation is a governed selection, not a prompt convention, and it is reproducible because the nodes are typed, versioned, and hash-chained.

Minesweeper first, and a useful null result

The first task was "build a better Minesweeper that people love." Minesweeper fits in one context window, so a single shot can hold the whole thing. The arms barely separated, and that told me something worth keeping: process has nothing to save you from when the task is small. A one-shot was often fine. Governance earns its keep only when the work is too big to hold at once.

The model swap in that phase was cleaner. Same recipe, different model. A cheaper but code-tuned 30B model drove the whole pipeline and shipped a working game for about thirty cents. A cheaper general model talked instead of writing files, produced no game, and cost $1.85 for nothing, because it got no prompt caching. Tool-use decides whether a model can do this work. Price does not, and caching behavior swamps the per-token number.

Curious what "a working game" actually means here? Two live exhibits, both unedited output of the runs. Play the governed pipeline's Minesweeper, or see all three arms side by side: raw, tight, and leaky, on two different models, each running live in its own frame. Warts and all.

The real test: a service-company invoice app

The task that actually separated the arms was an invoice and quote builder for a flooring contractor. Measure the job, list materials with photos, add labor, produce a clean invoice. That is real software: money math with edge cases, photos, persistence, printable output. It does not fit in one shot.

raw reached for a React, TypeScript, Express, and SQLite monorepo. It needed an install, a compile, a build, and a running server just to open. It renders a handsome quotes table, and saving is broken. Nothing in a one-shot ever checks whether the thing works. It only has to look done.

tight reached the same conclusion, that the app should be dynamic, because a real invoice tool needs a backend for photos and shareable customer links. Then it right-sized that into a zero-dependency Node server plus a plain client. Its product-marketing role found a real insight, that homeowners approve faster when they can see a contractor's license and insurance, and turned it into the onboarding screen. Its evaluation role started the server and ran a scripted pass end to end: create a quote, a sixteen-by-twelve room at ten percent waste resolves to 212 square feet of material, capture a signature, apply the price list. The first pass failed, the developer fixed it, the second pass held. That loop is the difference between "loads" and "works."

leaky got the math right and shipped a broken surface. Correct totals, and a line-item section where the labels overlap and collide. Give every role every file and the concerns smear together.

What I would take away

The dollar cost of the governed run was about thirty cents more than the one-shot. The time cost was real, roughly fifty minutes against four, because seven roles and two review loops mean about eleven model calls. For a broken demo you pay four minutes. For a working, tested, reviewed app you pay an hour and a few dimes.

The mechanism is not complicated. Give each step only what it needs, and add a review that runs the software. ContextNest is what makes the first half governed and reproducible instead of a pile of string concatenation.

What this is not

This is a lab note, not a study, and I want to be precise about why. Every cell is a single run, and the one-shot's architecture is a coin flip: across three invoice runs it built a Vite monster, a tidy static app, and a client-server monorepo from the same prompt. The tight-versus-raw comparison changes more than one thing at once, so it cannot credit the win to isolation alone. The outcome grades are my eyes, not a blind rubric, and the objective scorer I built was not run. One model, one domain, and I tuned the recipe against the same tasks I then judged. None of that is evidence yet. It is a promising signal with a clear path to becoming one.

To turn it into a study I would run 30 to 50 times per arm per task, hold the pipeline fixed and vary only the context distribution, run an objective scorer graded blind, add maintenance tasks where the agent modifies an existing codebase rather than building greenfield, diversify across several models and app types, and evaluate on held-out tasks I did not tune against. Then freeze the harness and collect the data.

The takeaway I am comfortable with today is narrower and still useful. When the task is real, giving a coding agent only the context it needs, and reviewing what it produced by running it, turns "looks done" into "is done." That is the strategic imperative applied one layer down, and it is the same argument as governing the interaction rather than trusting the agent on top. We wrote the formal version of the governance case, with numbers, in the paper.