From Design to Build

Most agent sessions start from a prompt, which means the first design decision gets made somewhere around the third file the model touches — by the model, silently, and usually in whatever direction the training data leaned. The Design agent pulls that decision forward into a document you can read and revise before any of it is binding.

It asks the questions a reviewer would: what problem is this solving, what is out of scope, what constraints does it have to live inside, and what did you reject on the way. You push back, it revises, and you do that until the document says what you meant. This is the cheapest place in the pipeline to change your mind.

It is also the place where the whole thing is most easily wasted. A vague design produces a vague plan, a vague plan produces a blueprint of vague phases, and a blueprint of vague phases produces an agent doing something adjacent to what you wanted for an hour. The time you spend here is the main lever you have on how the run turns out.

A design describes the destination; it doesn’t know that the thing it wants to extend is used in nine places, three of which are load-bearing. The Plan agent reads your design against your source — using the same code graph the rest of Konstruct runs on — and works out the route.

That means naming the files it expects to touch, the order that keeps the tree working, what the change puts at risk, and the questions worth settling now rather than discovering halfway through. Four questions answered here are four the Build agent doesn’t have to guess at later.

This is worth reading properly rather than skimming. The plan is most of what the Build agent will know about your intentions by the time it starts work, and a wrong assumption left standing here gets implemented faithfully, several phases deep, before anyone notices.

A plan is prose, and prose isn’t executable. The blueprint is that plan compiled into structure: ordered phases, the tasks inside each phase, and a written definition of done attached to every one of them.

Every one of them. Not a heading and a hope that the agent knows what you meant — each phase and each task carries a sentence saying what finishing it looks like, written before any of it runs and specific enough that something other than the agent that did the work can check it: this endpoint returns that shape, these tests run, this old call site is gone.

Those definitions are what the run is checked against. At the end of every phase the finished work is read back — task by task, against what each one was supposed to produce — before anything moves on. A phase that falls short is not marked failed and left behind: the agent is sent back into it with the specific items still outstanding, told what the previous attempt was told, and pointed at anything flagged twice running — so the next attempt fixes the gap rather than repeating the turn that missed it.

When a shortfall survives that — accepted rather than fixed, because the alternative is a run that grinds on one task forever — it is recorded against the phase and carried forward rather than quietly dropped. It turns up in the report at the end, next to the phase that produced it.

The effect is that a mistake gets caught and worked on at the boundary that introduced it, rather than nine phases downstream where nothing is recoverable.

It stays a proposal until you say otherwise, and you can iterate on it. Name a check you want a phase to have to pass. Add a step it missed. Drop a task, split a phase doing too much, tell it to leave the public API alone, tighten a definition of done vague enough to be satisfied by almost anything. It revises the draft each time. A phase gate is only ever as strict as the sentence you gave it, so this is where that gets fixed.

If the shape is wrong rather than the details — the phases carved up along the wrong seams, the ordering built on a bad assumption — you can throw the draft away and have it redrafted from the start, this time with the specific guidance it was missing. That is usually faster than talking a fundamentally wrong plan into being right one correction at a time.

Everything the agent does over the next several hours is set up here, so read the draft properly before you approve it: the order of the phases, what each one claims it will finish, and whether you would accept those definitions as done if someone handed you the result. A blueprint you have actually been through is the single biggest thing you can give the run.

The Build agent takes the approved blueprint and works it from one end to the other — features, fixes, refactors — clearing each phase’s checks before it moves on to the next. This is work measured in hours, not a single chat turn.

Each phase runs in its own session rather than one enormous conversation stretched over the whole run. A session that has been going for hours is a session whose early instructions have been buried under thousands of lines of tool output — so at every boundary the finished phase is summarized, that session is retired, and the next phase starts fresh, seeded with what the earlier phases established plus its own orientation from the blueprint. The agent gets the distilled version rather than the entire history.

Because the decomposition and the checks already exist, the agent is never improvising about what “done” means. It is working against targets you approved, and saying where it has got to as it goes.

Sometimes the problem is the plan. A phase turns out to depend on something that does not hold, an ordering that looked fine on paper does not survive contact with the code, and the work needs rearranging. That is a legitimate outcome, and it is treated as one: the run says so, loudly, with the phase and the reason attached, rather than improvising a way around it and leaving you to work out later why the thing you approved is not the thing that got built.

You aren’t locked out while that happens. Watch it, redirect it when you spot something going sideways, or stop it outright — the blueprint is still there, and so is everything it finished.

It will not always get the whole task right. That is worth saying plainly, because the failure mode is rarely catastrophe — it is quiet incompleteness. A task gets skipped, an edge case gets stubbed, a criterion gets satisfied in the narrowest possible reading, and the whole thing looks finished from the outside.

Which is what the report is for. It is not a victory lap — it exists to show you the gaps. A phase that could not satisfy its definition of done is recorded as such at the boundary that produced it, those findings are carried forward rather than forgotten, and the report is assembled on top of that trail: each phase’s verdict, each shortfall, and the files the run actually changed.

So you get what was delivered, what fell short and where, and which follow-ups are worth taking — assembled on top of the run’s own ledger, so a phase’s verdict, an accepted shortfall or a file the run touched still shows up whether or not the closing write-up thought to mention it. The aim was never a run that cannot go wrong. It is a run whose gaps are in front of you at the end, instead of in a merge three days later.