Build.

Build is the stage where the locked design becomes a working, deployed system. It is the narrowest stage of the Sequence — and the fastest, when the diagnostic work was done properly. If Build feels slow or chaotic, the problem is almost never in Build. It is upstream.

This chapter is about what Build actually produces, what the team is choosing between when they build, and why this stage is short when the four previous stages were honest.

What Build produces.

Build produces one thing: a working, deployed solution to the validated constraint.

Working means the solution has been tested against real inputs and produces outputs the human supervisor can review and trust. Not synthetic inputs. Not a demo dataset. The actual records, emails, quote requests, customer files — whatever the design specified as input. The outputs land in a form the supervisor can evaluate the same way they would evaluate a person’s work.

Deployed means the solution is operating inside the actual business environment — connected to the systems it needs, used by the people who need to use it, producing outputs that flow into the next handoff. A demo in a sandbox is not the deliverable. A working system that the team is using on real work is the deliverable.

That bar is deliberately high, because anything less than that leaks back into the we’ll roll it out next quarter limbo that swallowed the last AI initiative. Build is done when work the team used to do is being done by the designed system, supervised by the human the Hybrid Accountability Chart names.

Build is scoped to the designed workflow.

The single most common Build failure is scope drift — the moment the engineer or vendor or low-code builder looks at the spec and starts to “improve” it. Add a feature. Connect another system. Generalize the workflow into a platform. Use the constraint as an excuse to rebuild a tool the company should have replaced anyway.

That is not Build. That is a different project pretending to be Build.

The Build phase is scoped exactly — and only — to the workflow the Design phase produced. Not the surrounding workflow. Not the system of record it integrates with. Not the team’s other AI ambitions. The solution for the validated constraint, built to the specifications the Design phase committed to, and nothing else.

This is not a limitation. It is the structural reason Build is fast. A team that built a quoting workflow in three weeks did not do it because they were clever. They did it because Design gave them a workflow narrow enough to build in three weeks. The discipline of scope is upstream of the speed of execution.

If, mid-Build, the team finds themselves negotiating new requirements, that is a Design-debt conversation, not a Build conversation. The right move is to stop, go back, fix the design, and resume — not to absorb the ambiguity into Build and hope it works out. It will not work out.

Build is fast when Design was thorough.

Read this as the gate-discipline payoff.

The teams who run Build cleanly are the teams who refused to advance past Signal until they had one constraint with a dollar number on it. Who refused to advance past Source until they had a Knowledge Map that named what the work actually requires. Who refused to advance past Design until the Hybrid Accountability Chart specified who owns what, what the handoffs are, where the human supervisor enters, and what the agent does inside the bounds the supervisor has set.

When all of that is true, Build is mostly translation work. The specification already exists; Build encodes it.

When any of that is not true, Build is where the unresolved questions surface — usually at the worst possible moment, usually expensive, usually disguised as a technical problem when they are actually a design problem. The mid-build “wait, we didn’t decide that” conversation is not a Build problem. It is Design debt arriving on the worst possible balance sheet.

The Diagnose half of the Sequence — Signal and Source — and the gate at the end of Design exist to prevent that conversation from ever happening. Teams that internalize this stop experiencing Build as a struggle. They experience it as the short, mechanical stage between deciding and shipping.

The build paths.

The team enters Build with a designed workflow. They exit Build with that workflow operating in production. Between those two points is a choice — but the choice is not which technology is exciting this quarter. The choice is which path fits the design.

Three paths cover almost every Compound sprint:

• Off-the-shelf tool. Existing software that maps cleanly to the designed workflow with light configuration. The work is selection, configuration, and integration into the team’s existing flow — not building from scratch. This is the right path when the workflow is well-served by a mature product category and the design does not require anything the product does not already do.

• Low-code or no-code build. A workflow assembled in something like Zapier, Make, Airtable, n8n, or a Claude project with skills and connectors. No external engineering. The team owns it directly — they can see how it works, change it, and extend it. This is the right path when the workflow is custom enough that no off-the-shelf product fits, but is composed of standard primitives — pulling from a system, transforming with an agent, writing back to a system, notifying a person.

• Hand-built integration. Custom code, usually involving an API to a system of record, often with an engineer in the loop. Slower than low-code, higher return, harder to change later. This is the right path when the workflow runs at a scale or against a system that low-code tools cannot reach — or when the integration touches data the company will not put through a third-party automation platform.

These are not a hierarchy. None of them is better than the others. The right path is the one that matches the design — the workflow’s shape, the systems it touches, the data sensitivity, the team’s ability to own it, the volume it will run at, and the speed the constraint demands.

The Design phase determines the path. Build executes it. A team that picks a path because of a vendor relationship, an internal preference, or a fashion in the market is making a Design decision under the cover of Build — and they will pay for it.

Sprint · the three-week quoting workflow.

A 60-person professional services firm came into a sprint with a Signal that was almost embarrassing in its clarity — quotes were taking five business days, the principal was the bottleneck on every one, and the constraint was costing them roughly $200K a year in lost or stale deals. Source mapped the inputs: the inbound brief, the historical quote library, the rate card, the scoping checklist. Design produced a workflow where an agent drafted the quote, the project lead reviewed and edited it, and the principal signed off only on the final number.

The build path was low-code. No engineer needed. The team assembled the workflow themselves in three weeks, using tools they already had licenses for. Quotes started going out the same day they came in. The principal got their week back. The cost of the build was a rounding error against what the constraint had been costing.

The story isn’t that low-code is magic. The story is that Design gave them a workflow simple enough to build in low-code in three weeks. That is what a thorough diagnose produces.

The two instruments — Build Spec Writer and Guardrails Checklist.

Build is supported by two instruments in the Skills Library.

Build Spec Writer translates the designed workflow into a developer-ready specification. What the workflow does, end to end. What tools and systems it integrates with. What the inputs are and where they come from. What the outputs are and where they go. What the agent does. What the human supervisor reviews. Where the handoffs sit. What the failure modes are and how the system surfaces them.

The spec is the artifact a builder — engineer, vendor, low-code assembler — works from. Its job is to remove ambiguity. If the spec is right, the build is mostly execution. If the spec is wrong, the build is mostly negotiation. Build Spec Writer is the instrument that gets the spec right.

Guardrails Checklist is the set of quality, privacy, and oversight decisions that must be locked before the solution goes live. Who reviews what. How often. How errors are caught. What happens when the agent produces output that requires escalation — who it goes to, in what form, on what timeline. What data the system is permitted to touch and what it is not. What gets logged and where. What the rollback looks like if something fails.

Guardrails Checklist is not bureaucracy. It is the difference between an AI solution your company can stand behind and an AI solution your company is one mistake away from regretting publicly. The work of completing it is small. The work of skipping it is enormous and arrives late.

The two instruments produce a build that is specified clearly and constrained safely. Both have to be done before the build path executes — not after.

The Build Agent.

The Compound Bench provides a Build Agent for this stage.

You hand it the designed workflow and the Hybrid Accountability Chart entry from Design. It produces the developer-ready specification — the same artifact a Compound member would otherwise hand to an engineer or vendor or low-code lead. It surfaces the Guardrails Checklist questions and walks the team through answering them.

The Build Agent is not the builder. It is the specifier. It produces the document the builder works from.

This matters because, for most Compound members, Compound is not the builder either. The build is done by the company’s own people, by their existing vendor, by a contract engineer they already have a relationship with, or — on the low-code path — by the team themselves. The Build Agent’s job is to give those people a spec clear enough that they can execute against it without inventing the design on the fly.

Some members prefer to bring Compound in to manage the build. That is available. Most do not need it. Most have technical resources that work fine — they just have never had a clean spec to work from. The Build Agent solves that.

What done looks like.

Build is done when there is a deployed solution producing outputs against real inputs, reviewed by the human supervisor named in the Hybrid Accountability Chart. The supervisor is using it. The team is using it. The work the constraint named is being done, by the system the design specified, inside the operating environment of the business.

Not a demo. Not a pilot in a sandbox. Not a working prototype the team is waiting to “really roll out” after some unspecified additional work. Deployed and producing against real work.

If the team is uncertain whether Build is done, the test is simple. Pull the last week of inputs the workflow was supposed to handle. Did the system handle them? Did the supervisor review the outputs? Did the work move forward? If yes, Build is done. If no, the team is not in Deliver yet.

Hand off to Deliver.

Build makes it work. Deliver puts it into the company’s actual operating rhythm — trains the people who need to use it, changes the handoffs that need to change around it, measures the result against the dollar cost Signal put on the constraint, and makes sure the system is owned, not orphaned. A solution that runs is not yet a solution the business has absorbed. That is the next stage.