Build: Turn the Design Into a Working System

In Brief

Build is the stage where the locked Design Brief becomes a working, deployed system. Two instruments carry it: an eight-section Build Spec, audited against seven common failures before anything gets built, and a seven-question Guardrails Checklist, answered in writing before anything goes live. Build also makes the one decision Design left open: the environment, picked inside the category Design locked. Build is done when the system handles real inputs in production, supervised by the named Human Orchestrator. If Build feels slow or chaotic, the problem is almost never in Build. It’s upstream.

We built the project management agent team, the five agents that replaced our $24,000-a-year coordinator role. We locked the Hybrid Accountability Chart entry before we built a single workflow step: Sofia as Human Orchestrator, every agent starting AI-Assisted, her sign-off on every output in Sprint one. We derived the access boundaries, the failure modes, and the environment from that one accountability decision.

One agent handled client-facing task updates, with read/write access to our project management system. Another compiled internal performance reports: billable hours, delivery velocity, resource allocation. That one could see data the first agent had no business touching. A third routed subcontractor communications. Five agents, five access levels, every boundary decided in Design before Build executed any of them.

Sofia reviewed every output in those first weeks. The agents drafted. She approved. The judgment calls they couldn’t make stayed with her.

Every Build runs the same fixed sequence. The Design Brief comes in. You write the eight-section Build Spec from it, audit the spec against the seven failures that end builds early, and answer the seven guardrails questions in writing. You pick the environment inside the category Design locked; this chapter gives you enough technology vocabulary to make that call without deferring to a vendor. Then the build executes and the five-question Done test runs against real inputs. The locked spec, the written guardrails answers, the environment pick, and the test results fill in the Build row of your Sprint Planning Canvas and hand off to Deliver.

The Build sequence: Design Brief → Build Spec → failure audit → Guardrails Checklist → environment pick → build → Done test → handoff to Deliver.

Build produces one deployed working system.

Build is the most variable stage in the Sequence: the problem, the systems, the team’s technical comfort, and the data all shape what it looks like in practice. So this chapter teaches the constant: every build starts from a complete specification and ends with a deployed system doing real work.

The deliverable is a working, deployed solution to the validated constraint, and both words carry weight.

Working means the solution produces outputs the Human Orchestrator can review and trust, evaluated the same way they’d evaluate a person’s work.

Deployed means the solution is running inside the actual business: connected to the systems it needs, wired into the places where the work already lives, producing outputs that flow into the next handoff.

Build is done when the designed system handles real inputs in production, supervised by the Human Orchestrator the Hybrid Accountability Chart names. What Build doesn’t own is adoption: briefing the team, changing the handoffs around the new workflow, retiring the old way. That’s Deliver’s job, and the handoff at the end of this chapter includes what Deliver needs to do it.

Build stays scoped to the designed workflow.

The agents we designed in the last chapter took on the bulk of the workflow the Human Orchestrator used to run alone. This is where they get built, to the shape Design specified.

The single most common Build failure is scope drift, and it usually isn’t the builder who drifts. It’s the process owner: the person who scoped the workflow watches it take shape, their eyes get bigger, and they want more than they scoped. Another feature. Another connected system. The workflow generalized into a platform. If you ran the Design process from the last two chapters, this mostly doesn’t come up; a locked Design Brief leaves little to renegotiate. When it comes up anyway, the ask goes on the backlog and waits for the next Sprint’s Signal session. It’s a different project, not this Build.

Build is fast because it’s scoped this narrowly. Meridian built its entire quoting workflow in three and a half weeks because Design handed Build a workflow narrow enough to build in three and a half weeks.

Pro Tip

If your Build is running past the time box, the instinct is to extend the deadline. The right move is to cut scope: ship the version that handles 80% of inputs and build the remaining 20% in the next Sprint. A deployed system that handles most of the work beats a perfect system that’s still in development.

The other source of mid-Build negotiation is a design gap: a decision that belonged in Design but wasn’t made there, now surfacing where it costs more to resolve. Two moves. If the gap makes the current build impossible to complete correctly, stop, go back to Design, fix it, and resume. If the build can proceed safely without it, log it as a Signal item for the next Sprint, with enough context to pick up later. Don’t absorb an unlogged gap into the current build; that turns a defined gap into an invisible one.

Pro Tip

Favor the smallest possible solution that satisfies the spec. A skill is one packaged capability an agent runs: a defined instruction set plus its reference material. The team that ships a Claude project with three skills in a week beats the team that spends six weeks architecting an agentic pipeline, if the design only called for a skill. Build what the design calls for, nothing more elaborate.

Build belongs to the person closest to the work.

Build doesn’t require developers.

Not always. Not for every path. But most teams assume Build means “hand it to engineering,” and then the Sprint waits. The developer is three projects deep. The constraint keeps costing what it costs.

The real requirement is curiosity and systems thinking. Jesse teaches psychology, economics, and criminal justice majors at Michigan State, not engineers or computer scientists. Within a semester, those students are building functional data pipelines: pulling data from APIs, processing it through agents, writing it back to systems. Your team will have to learn new tools, and some of them will have to start thinking in systems. That’s the bar. A computer science degree isn’t.

Anyone on your team who is smart and diligent can learn to make a skill. Claude’s project interface lets you build a working skill in a conversation. Replit lets a non-developer ship a working app by describing what they want. n8n is a low-code workflow tool: instead of writing code, you connect systems by dragging and linking blocks on a screen, where each block reads from a system, runs a step, or writes a result back. The barrier to building this way is lower than most leadership teams realize.

The developer-free claim applies to the design and configuration work in this book. When the workflow needs system-to-system wiring, hiring a freelancer for a few days is normal; that’s how Meridian wired its quoting workflow.

IT’s role is real, and it’s different from what most teams assume. IT controls the keys: permissions, access, security policies, system credentials. When Build needs a CRM connection or ERP read access, IT gates that. But IT doesn’t need to be the one prototyping the workflow or writing the skill. The person closest to the work builds it. IT makes sure it’s safe. If you have no IT department, you’re the person who controls the keys, and the same split holds.

Action Step

Before your next Build, ask: does the builder need to be a developer, or does the builder need to be the person who knows the work? If it’s the second, expect them to learn the tool as part of the build, and budget the first days of the time box for it. The Sprint makes that learnable: one workflow, one environment, and a spec that has already removed the ambiguity. Pair them with whoever controls access and security, not with someone you expect to do the construction.

Write the eight-section Build Spec.

Build runs on two instruments, and both derive from the Design Brief. The Build Spec says what gets built. The Guardrails Checklist says what it’s allowed to do. Neither reopens the design conversation, and on any disagreement, the Design Brief wins.

One Design Brief feeding two instruments: the eight-section Build Spec (what gets built) and the seven-question Guardrails Checklist (what it's allowed to do). Neither reopens the design conversation — on any disagreement, the Design Brief wins.

The Build Spec turns the Design Brief into a builder-ready specification. It restates the workflow, systems, and data sections precisely enough that a builder can start without asking questions. It adds three sections Design doesn’t own: agent scope, failure-mode behavior, and the environment with its constraints. And it shapes a fourth, the Human Orchestrator’s working day, around the person the Hybrid Accountability Chart names. If the spec is right, the build is mostly execution. If the spec is wrong, the build is mostly negotiation.

A complete spec covers eight sections:

How to write the eight-section Build Spec

Section 1: Write the workflow summary — Gives any builder a plain-language end-to-end picture of what they’re building before they touch anything.
Section 2: Define the inputs — Specifies exactly what triggers the workflow and what data enters it, so the builder knows where to reach and how to access it.
Section 3: Define the outputs — Locks the deliverable form, destination, and recipient so the build can’t drift toward something the Human Orchestrator can’t use.
Section 4: Set agent scope boundaries — States what the agent handles and what it cannot decide, preventing over-prescription that kills agent effectiveness.
Section 5: Name the Human Orchestrator role — Identifies who reviews, what they review for, and what the handoff looks like — the accountability anchor for the whole build.
Section 6: List every system and integration — Documents read/write access, authentication method, and data sensitivity for every system touched so nothing is wired by assumption.
Section 7: Document the failure modes — Pre-decides what happens on every edge case and outage so the builder wires escalation paths instead of improvising them under pressure.
Section 8: Specify the environment and constraints — Locks which specific platform within Design’s category the build runs on and any data residency, license, or security constraints.

Build Spec: eight sections with section name and a one-line description of what belongs in each.

Here is the blank eight-section Build Spec template. Fill in every row before anything ships to a builder. An empty section is a decision the builder will make under build pressure, and those decisions almost never match what Design intended.

Section	Your Sprint
1. Workflow summary	(one paragraph, plain language, end to end. A builder who knows nothing about your business should be able to read it and understand what they are building.)
2. Inputs	(what triggers the workflow, what data enters, in what form, from which systems, how the builder accesses it.)
3. Outputs	(what the workflow produces, what form it takes, where it goes, who receives it.)
4. Agent scope	(what the agent handles, what decisions it makes, what it is not permitted to decide. Scope boundaries, not procedural instructions.)
5. Human Orchestrator role	(who reviews, what they review for, what the handoff looks like, where the output lands, in what form, on what timeline.)
6. Systems and integrations	(every system touched, read or write access, authentication method, data sensitivity classification.)
7. Failure modes	(what happens when the agent produces output that needs escalation. Who it goes to, in what form, on what timeline.)
8. Environment and constraints	(specific environment within Design’s category, plus data residency, license, or security constraints the builder must observe.)

The worksheet walks the fill-in procedure section by section. The judgment isn’t spread evenly: four sections are transcription, four are decisions.

Sections 1–3 and 6: restated at builder precision.

The workflow summary, the inputs, the outputs, and the systems list carry no new decisions; those were made in Design. What changes is the detail. The Design Brief says the workflow pulls customer history from the CRM; the spec names the system, the fields, the access level, and how the builder authenticates. The builder needs that detail to execute without asking; the Design Brief never did. Where you can’t reach it from the Design artifacts, the gap is Design’s.

restated from the Design Brief — the Design Brief wins on conflict.

Section 4: agent scope is boundaries, not procedure.

The first section Build authors. Prescribe every step and the agent loses the flexibility that makes it worth deploying; state no limits and it wanders into decisions nobody gave it. A good Section 4 names what each agent handles, then draws the hard lines: the short list of things no agent is permitted to decide.

The hard lines follow the same pattern across functions:

A quoting agent can price against the rate card; it can’t set a final price or send anything to a customer.
A collections agent can draft reminders and flag overdue accounts; it can’t change payment terms.
A hiring agent can screen resumes against written criteria and schedule interviews; it can’t reject a candidate or extend an offer.
A support agent can answer from the documented knowledge base; it can’t issue refunds or make policy exceptions.

Anything irreversible, customer-facing, or precedent-setting sits outside agent scope in the first Sprint. You can loosen a boundary later, once the quality data says so. You can’t unsend a bad quote.

Section 5: the Human Orchestrator’s working day.

The Hybrid Accountability Chart names the person. This section adds the shape of their day: what they review for, how long a review should take, and where the outputs they don’t approve themselves go. The judgment call is specificity. “The ops manager reviews the output” isn’t a spec; a builder can’t wire a review queue from it, and the reviewer can’t tell in week one whether the system is saving time or costing it.

What a good answer looks like, across functions:

Operations: the ops manager reviews each generated work order for crew assignment and materials, ten minutes each, exceptions to the scheduler.
Finance: the controller reviews flagged reconciliation mismatches daily, inside the accounting system’s existing exceptions view, anything over $5K escalated the same day.
Marketing: the marketing lead reviews drafted campaign copy in the same approval doc the team already uses, brand-risk items routed to the CEO.

the accountability layer — sections 4 and 5 written, 7 and 8 still open

Section 7: pre-decide the failure modes.

The section builders need most and operators skip most. The happy path writes itself; the spec earns its keep on the inputs nobody wants to think about. Every workflow’s failure list draws from the same five families:

missing data
an unrecognized input
a system that’s down
low-confidence output
an out-of-range result

Walk each family and write what the agent does, where the case routes, and what the flag says:

An invoicing workflow: a PO number that matches nothing routes to the AR clerk flagged “no match found.” The agent never guesses the account.
A scheduling workflow: when the calendar system is down, requests queue. Nothing double-books.
A content workflow: any claim the agent can’t source from the approved library gets flagged, not published.

Name it, flag it, route it. The agent never guesses and never goes silent. If you can’t decide where a failure routes, you’ve found a design gap. Don’t leave it as a blank for the builder.

Section 8: the environment and its prerequisites.

This section locks where the build runs and what the builder must observe getting there. The category came from Design; the specific environment pick is taught later in this chapter, and the answer lands here. The judgment call is the prerequisites: the things that must be true before build begins. Prerequisites are where builds stall:

The pricing spreadsheet has to be cleaned and validated before anything gets wired to it.
The CRM’s duplicate records have to be merged before an agent starts matching against them.
IT has to provision API credentials before the freelancer’s clock starts, not during it.

Anything the builder would have to stop and wait for is a prerequisite. Name it with an owner and a date, or watch it consume the build from the inside.

Build Spec, stage 3 of 3: all eight sections filled, failure modes and environment now locked — the production layer.

Here is what those sections look like filled in, for Meridian Manufacturing, against the $558K quoting constraint. Section by section:

Section 1, Workflow Summary: A new RFQ arrives through the standardized intake form, creates a CRM record, and triggers the quoting workflow. The Quote Research Agent pulls customer history and matches the RFQ against three years of historical jobs in the ERP. The Quote Pricing Agent applies the rate card, the senior engineer’s labor estimate, and the applicable pricing exceptions. The Quote Assembly Agent formats the draft as a PDF and places it in the VP of Operations’ review queue. She reviews, edits if needed, and approves. The approved quote routes to the sales lead for customer delivery.

Section 2, Inputs: The trigger is an inbound RFQ, submitted via the standardized intake form and parsed into HubSpot CRM as a new deal record. The data sources:

ERP job costing history (three years, roughly 800 completed jobs)
Current rate card (maintained by finance in JobBOSS ERP)
Cleaned pricing exceptions database (112 validated customer-specific rules, sourced from the VP’s spreadsheet)
Senior engineer’s labor hour estimate (submitted via structured form)
CRM customer history, including win/loss records

Section 3, Outputs: A draft PDF quote in Meridian’s standard format, landing in the VP of Operations’ CRM review queue. It contains a line-item breakdown (materials, labor, overhead, margin), a confidence score (the agent’s own estimate of how sure it is about an output) reported as high/medium/low, the closest historical job matches with pricing, and any exception rules applied. Plus a flag for any input the agent could not resolve.

Section 4, Agent Scope: Quote Research matches the RFQ to historical jobs by spec, materials, and complexity, and surfaces customer context and pricing terms. Quote Pricing calculates the draft price using historical matches, rate card, labor estimates, and exception rules. Quote Assembly generates the formatted PDF. No agent sets a final price, overrides the rate card, applies undocumented exceptions, or sends anything to a customer.

Section 5, Human Orchestrator Role: Elena Ruiz, VP of Operations, reviews every draft quote. Reviews for scope interpretation, pricing accuracy, confidence score, and exception rule application. Expected review: fifteen to twenty minutes per quote, down from three hours when she built quotes from scratch. Escalation: low-confidence quotes get her full manual review; non-standard materials route to the senior engineer; strategic account pricing goes to the CEO.

Section 6, Systems and Integrations:

HubSpot CRM (read/write: customer records, RFQ intake, quote pipeline, delivery queue)
JobBOSS ERP (read: historical job costing, rate card, materials pricing)
Claude Team workspace (three projects, one per agent: Quote Research, Quote Pricing, Quote Assembly)
n8n (workflow orchestration and system connectors, moving work between the three projects)

Sensitivity: pricing data is medium; everything else is low.

Section 7, Failure Modes:

No similar historical jobs found: agent flags as “insufficient for rapid estimate” and routes to the VP for full manual review.
Unknown material (e.g., titanium): agent produces no price estimate for that line item and flags as “manual pricing required.”
ERP API down: RFQs queue in the CRM, and the agent processes them when the connection restores.
Confidence score below 60%: draft routes to the VP with a warning flag.
Pricing deviation greater than 15% from closest historical match: agent flags the deviation, and the VP investigates before approving.

Section 8, Environment and Constraints: Low-code category, run via n8n (existing license) and Claude Team. Freelance n8n developer for three days of API wiring to HubSpot and JobBOSS. All data stays in existing systems. The pricing exceptions spreadsheet must be cleaned and validated first. That’s a prerequisite. It happens before the build clock starts.

That spec gave Elena and the freelance developer everything. No ambiguity meetings. No mid-build design decisions.

Action Step

Open a document. Write the eight section headers. Fill in Sections 1–3 and 6 from your Design artifacts. If you can’t fill them without guessing, Design isn’t done. Then complete Sections 4, 5, 7, and 8 using the Hybrid Accountability Chart and Knowledge Map. Every section must have content before the spec goes to a builder.

Audit the spec against seven common failures.

Before building starts, audit the spec against seven failures. Each one has ended a Sprint early or produced a system that got shut down within weeks. The list is the checklist; the teaching follows.

How to audit the spec against seven common failures

Check 1: Search for existing capabilities before building — Prevents rebuilding what already exists — the most common implementation failure, which is a research gap, not a technical one.
Check 2: Confirm the environment matches Design’s category — Stops a builder from substituting a ‘cleaner’ architecture for the one the spec actually calls for.
Check 3: Verify the spec is complete before build starts — Every empty section becomes an on-the-fly decision that won’t match Design’s intent.
Check 4: Confirm the output lands where the work already lives — A workflow that outputs to a tool no one opens produces zero adoption regardless of technical quality.
Check 5: Verify Section 7 (failure modes) is populated — A build that only handles the happy path breaks on the first edge case.
Check 6: Confirm the build handles real-world edge cases, not just the demo path — A demo shows the happy path; the build must handle missing data, system outages, and off-script inputs.
Check 7: Require testing against real inputs before declaring done — Synthetic and cherry-picked examples are not tests; last week’s actual data is the only honest gate.

Check 1, existing capabilities. Somebody spends three weeks wiring document retrieval into an agent when the environment already searches uploaded files as a built-in feature, or builds a custom CRM connector their platform ships as standard. Fifteen minutes of searching is the cheapest insurance in this chapter, and only what’s genuinely missing goes into the build.

Check 2, environment matches category. This is where the builder’s taste shows up: the spec says low-code, and the developer proposes a custom-coded service instead because it’s “cleaner.” Route that disagreement back to Design; don’t let it get settled at the keyboard.

Check 3, spec completeness. Mechanical but non-negotiable. Walk all eight sections and confirm real content in each; the empty-section rule from the template above is the reason this check exists.

Check 4, output destination. One question: is this where the work already lives today? Meridian’s drafts landed in the CRM review queue Elena already worked from.

Check 5, failure modes populated. A spec that names no edge cases hasn’t looked.

Check 6, real-world behavior. Production sends missing data, a system outage, an off-script input, a Human Orchestrator on vacation. The check is whether the spec says what the build does in those moments.

Check 7, real inputs as the done gate. Naming that gate now, before the build starts, removes the temptation to declare done on a demo later.

How Meridian ran the audit.

Elena walked the seven checks with the freelance developer before his clock started. Check 1 saved the most money: n8n’s standard connectors already reached HubSpot and JobBOSS, so the build shrank to days of wiring instead of weeks of custom development. Check 3 caught the one gap that mattered: the pricing exceptions spreadsheet wasn’t clean yet, and the audit converted it from a mid-build surprise into a named prerequisite with Elena’s name on it. Everything else cleared.

Action Step

Walk through all seven items with the builder present. Check each one against the completed spec. Any item that can’t be checked off is a gap that must be resolved before build begins.

Answer the seven guardrails questions in writing.

The Guardrails Checklist is the second instrument: the quality, privacy, and oversight decisions, locked in writing before the solution goes live. It isn’t a second design conversation. Five of its seven answers are the governance answers the Designing the System chapter already locked (data access, permitted actions, escalation path, quality monitoring, kill switch); the sixth, the accountability owner, comes from the Hybrid Accountability Chart; the seventh, behavior on unrecognized inputs at production fidelity, is the one question Build authors. Answer all seven in writing before Build executes. If any question can’t be answered, the build isn’t ready.

Where the seven guardrails answers come from: five from the Design Brief, one from the Hybrid Accountability Chart, one authored in Build.

Guardrails Checklist: seven questions as a scannable pre-deploy gate.

How to answer the seven guardrails questions in writing

Question 1: Lock data access boundaries in writing — Documents exactly what data the system may touch and what is off-limits, with an owner for that decision.
Question 2: Define agent autonomy vs. human sign-off — Draws the exact line between what the agent can do unilaterally and what requires a human approval before action.
Question 3: Specify behavior on unrecognized inputs — Prevents the agent from guessing or going silent when it encounters something outside its design envelope.
Question 4: Define quality measurement and baseline — Makes ‘good enough’ measurable so the Human Orchestrator can calibrate review cadence and know when to trust the system more.
Question 5: Name the escalation path — Routes judgment-requiring outputs to a specific person, in a specific form, on a specific timeline — no ambiguity in the moment.
Question 6: Name the accountability owner — Establishes who owns a bad output the same way they’d own it if a person produced it — no diffuse responsibility.
Question 7: Define the kill switch condition — Pre-decides the specific failures that trigger immediate shutdown, so the decision isn’t made under pressure after something goes wrong.

Here is the blank seven-row Guardrails Checklist template.

Question	Your answer
1. Data access. What data is the system permitted to touch? What is explicitly off-limits? Who decided, and where is it documented?
2. Agent autonomy. What can the agent do without human approval? What requires human sign-off?
3. Unrecognized inputs. When the agent encounters an input it was not designed for, what does it do?
4. Quality measurement. What specific checks, against what baseline, measured how?
5. Escalation path. When the agent produces output that requires human judgment, who does it go to? In what form? On what timeline?
6. Accountability. Who is responsible when the agent produces a bad output?
7. Kill switch. What would cause you to shut down the agent workflow immediately?

Meridian’s guardrails, in writing.

Elena answered all seven questions before the build started, and most were ten-minute decisions: Design had already made them, and the checklist converted them into written commitments.

Question	Meridian’s answer
1. Data access. What data is the system permitted to touch? What is explicitly off-limits? Who decided, and where is it documented?	HubSpot CRM deal records (read/write), JobBOSS ERP job costing and rate card (read), cleaned pricing exceptions database (read). Off-limits: financial reporting, employee records, customer payment history, supplier contracts, or any system not listed.
2. Agent autonomy. What can the agent do without human approval? What requires human sign-off?	Can match RFQs to historical jobs, apply rate card pricing, apply documented exception rules, generate draft PDFs, assign confidence scores, place drafts in review queue. Cannot send anything to a customer, apply undocumented exceptions, override the rate card, or commit a quote.
3. Unrecognized inputs. When the agent encounters an input it wasn’t designed for, what does it do?	If the RFQ references a material not in the pricing exceptions database or ERP materials list, specialty alloys like titanium, the agent produces no price estimate for that line item, flags it as “manual pricing required,” and routes to the senior engineer. If the RFQ lacks sufficient spec detail, the agent flags it as “insufficient for rapid estimate” and routes to Elena.
4. Quality measurement. What specific checks, against what baseline, measured how?	Weekly comparison of agent-drafted prices to Elena’s final approved prices. Target: substantive corrections on fewer than 10% of drafts within eight weeks. Historical match accuracy tracked separately, target 95% before Elena reduces review cadence on the Research Agent.
5. Escalation path. When the agent produces output that requires human judgment, who does it go to? In what form? On what timeline?	Low-confidence quotes to Elena for full manual review. Non-standard materials to Dave Kowalski (senior engineer). Strategic account pricing to Mark Ellison (CEO). Any quote where the calculated price deviates more than 15% from the closest historical match gets flagged for Elena’s investigation before approval.
6. Accountability. Who is responsible when the agent produces a bad output?	Elena Ruiz, VP of Operations, owns every quote the agents produce, the same way she’d own it if she’d built it from scratch. She is the named Human Orchestrator in the Hybrid Accountability Chart.
7. Kill switch. What would cause you to shut down the agent workflow immediately?	Pricing errors exceeding 20% on three quotes in any week, any quote reaching a customer without Elena’s review, or any data access outside defined scope. Elena holds the switch.

Action Step

Answer all seven questions in writing. Attach the answers to the Build Spec as a companion document. If any question can’t be answered, the build isn’t ready to deploy. Resolve the gap before going live.

Know enough about the technology to hold your own.

This section exists for the decision that comes next: picking the environment, and making the model, data, and deployment calls without deferring to someone who doesn’t understand your constraint. Read the part that matches the decision in front of you.

The split that keeps you in control: you decide model, deployment, and data-access approach. The builder handles configuration, APIs, and the wiring underneath.

Models and providers.

An AI model is the engine. A provider is the company that built and hosts it. The major providers right now: Anthropic (Claude), OpenAI (GPT), Google (Gemini), Meta (Llama, open source), and smaller players like Groq and DeepSeek that compete on speed or cost. Each makes trade-offs. Claude is strong at reasoning and tool use. GPT is widely adopted with a large ecosystem. DeepSeek is cheap but raises data residency questions if you have compliance requirements.

You don’t pick a provider the way you pick a vendor for a five-year contract. You pick the model that fits the task in your spec, and some builds use one provider for drafting and a different one for classification.

Tokens and pricing.

Every prompt you send and every response the model generates consumes tokens, the units from the Source chapter. Tokens are to AI what minutes are to a phone plan; they’re what you’re billed on. A 1,000-word document is about 1,300 tokens. Input tokens and output tokens are priced differently, and output is usually more expensive.

Why it matters: a workflow that processes 500 documents a day at 2,000 tokens each consumes a million tokens daily. On a mid-tier model that’s manageable. At top-tier pricing it’s a line item. Jesse learned this the hard way: our Anthropic API usage hit four figures in days when we first started building production workflows, because we didn’t understand the meter.

The fix is simple. Use the most capable model where judgment matters, and a cheaper, faster model where it doesn’t: classification, summarization, routing. Your spec’s agent scope section tells you which is which.

Pro Tip

Ask your builder to estimate monthly token cost before the build starts, not after the first invoice arrives. The calculation is simple: average tokens per interaction, times interactions per day, times price per token, times 30.

Open source vs. proprietary.

Proprietary models (Claude, GPT, Gemini) run on the provider’s servers: the most capable models available, no infrastructure to manage, but your data travels through their systems and you’re subject to their pricing and terms. Open-source models (Llama, Mistral, and others) can run on your own servers: the data never leaves your environment and there are no per-token costs, but someone has to host, maintain, and update them.

For most Compound Sprints, proprietary models are the right call. The data sensitivity answer from the Guardrails Checklist determines the exception: if regulatory, contractual, or policy requirements mean the data can’t leave your environment, open source on your own infrastructure is the path.

Make AI work with your data.

Every team wants the same thing from AI: access to their data, with fewer made-up answers. Three approaches get there.

Large context window is the simplest: load your documents directly into the conversation. No infrastructure, no indexing. It works when the relevant material fits inside the model’s context window, and performance can degrade as you approach the limit.

RAG, or retrieval-augmented generation, gives the model access to your data at the moment it needs it, without changing the model itself. It’s cheap to update (you change the reference material, not the model) but requires some infrastructure: an indexed data store, a retrieval layer, and a way to keep the data current.

Fine-tuning retrains a model on your data so it behaves differently by default. It’s expensive, slow to set up, and hard to update: when your data changes, you retrain. It earns its cost only when the model must behave differently across thousands of interactions with the same specialized pattern.

Start with context windows for small, interactive datasets. Move to RAG when the data outgrows the window or changes frequently. Fine-tune as a last resort. Your quoting agent doesn’t need a fine-tuned model; it needs a general-purpose model with access to your historical quotes and rate card, and the Knowledge Map from Source already tells you what data that is.

Three approaches to AI data access: context window, RAG, and fine-tuning — with trade-offs and when to use each

Action Step

When a vendor or builder proposes fine-tuning, ask one question: “Could we get the same result by giving the model access to our data at query time?” If the answer is yes, skip the fine-tune.

Where the build runs.

Once you know what the build does and which model powers it, the next decision is where it runs. You decide which of three options the workflow needs; the builder handles hosting and monitoring once you pick.

Provider-hosted (API). Your build calls the model through the provider’s API. The default: simplest to set up, no infrastructure, and where most low-code platforms connect.
Your own server. You host the model (usually open source) on infrastructure you control. Full data control, higher setup cost, someone has to maintain it.
Serverless / edge (rented computing that expands and shrinks on demand). Scales automatically for high-volume workflows. Overkill for most first Sprints.

Start with provider-hosted unless the data-residency exception applies.

Pick the environment inside Design’s category.

With the spec, the guardrails, and the hosting decision settled, the last question is which product surface the workflow runs in. A surface is the place you actually work with the product: a website, a desktop app, a command line.

Design picked one of three categories: off-the-shelf, low-code, or hand-built (see the Designing the Work chapter). Build picks the specific environment inside that category. Environment options shift faster than workflow design principles do, so what’s named here is the logic; the current products are examples. Check the market when you’re running your Sprint, not when you read this.

The five environments bin by category. Off-the-shelf points to Claude Projects or Claude Team. Low-code points to n8n, Make, Zapier, and their peers. Hand-built points to Claude Code or a custom server.

Claude Projects fit skill-level work: a defined knowledge base, one person or a small team working with it. The “build” is configuration: the system prompt, uploaded context, defined scope, guardrails set in the project settings. A competent person does this in an afternoon.

One fit rule belongs to the surface, not the product: in the claude.ai web interface, one project holds one running process, so a multi-agent workflow on that surface means multiple projects. That’s the shape the marketing lead from the Co-Operating Model chapter ran: four agent workstreams, four tabs, her as the one read on all of them.

When the agents need to run concurrently, or the workflow starts itself on a schedule or trigger, you’ve outgrown the web surface. On a non-web surface like Cowork (Anthropic’s desktop agent workspace), a server, or Claude Code, one workspace runs several agents at once.

Claude Team (shared workspace, multiple projects) fits cross-team, skill-level work: several people share the same agent context, with the knowledge base and guardrails set once.

Claude Code fits multi-agent, programmatic, and tooling-heavy builds: agents calling other agents, running on triggers, writing back to systems. Our project management agent team lives here, running continuously across projects and communication channels. Claude Projects couldn’t have held that.

n8n, Make, Zapier, and similar workflow platforms fit data pipeline builds: pull from a system, run through an agent, write back, notify someone. Meridian’s quoting workflow used n8n alongside Claude Team: Claude Team held the agent projects; n8n handled the system connections and moved work between them.

Custom server and infrastructure fits workflows where control matters most: data residency requirements rule out third-party platforms, the volume exceeds what low-code tools handle, or the agent must integrate with a system of record through a proprietary API. Slower to build, harder to change, and someone has to maintain it. The return is full control: you’re not subject to a platform’s request caps or pricing shifts. Data sensitivity forces this path; elegance never should.

Environment	Fits	Doesn’t fit	Example
Claude Projects	One agent per project, one knowledge base, one Human Orchestrator; configuration in an afternoon	Agents that must run concurrently, or anything programmatic	Marketing lead’s four agent workstreams, one per project
Claude Team	Cross-team, AI-assisted work where several people share the same agent context	Workflows that run on a schedule without a human starting each run	Meridian’s Quote Agent Team: three projects in one workspace
Claude Code	Multi-agent, programmatic, tooling-heavy builds with triggers and write-back	Simple single-agent skill work that needs no infrastructure	Our PM agent team
n8n, Make, Zapier	Data pipelines: pull, run through an agent, write back, notify	Complex branching logic or large unstructured data	Meridian’s n8n connectors
Custom server	Data residency, extreme volume, or a proprietary system-of-record API	Anything a hosted or low-code path already handles	Forced only by the data sensitivity answer

Three questions route the pick inside your category: Does more than one agent run under one Human Orchestrator, and do they need to run concurrently? Does the workflow start itself, on a schedule or a trigger? Does the data have to stay inside your environment? Pick the least infrastructure that satisfies all three answers.

Category to environment: Design's three categories bin into five environments, Meridian's low-code + off-the-shelf pick marked, routed by three questions.

Verify span of control before you commit.

Before you finalize the environment decision, check the agent count. Julie Bedard and colleagues at BCG, writing in Harvard Business Review, found that productivity inverts past three concurrent agents per Human Orchestrator; that’s the span-of-control check from the Designing the Work chapter. If the design puts four or more agents under one Human Orchestrator, the environment decision won’t fix that. Go back to Design.

The escape hatch is architectural, and Design owns it: a coordinating agent that runs a team inside its own loop, with the human reviewing what the coordinating agent surfaces rather than every individual agent’s output. That’s the coordinating-agent pattern the Co-Operating Model chapter describes for our quote workflow. Build inherits that decision.

Action Step

Map your designed agent count against the Human Orchestrator named in the Hybrid Accountability Chart. If the count exceeds three, flag it as a design gap before Build proceeds.

The three-and-a-half-week quoting workflow.

Elena assembled the workflow herself. The freelancer came in only for the three days of API wiring the spec budgeted; everything else she built with tools Meridian already had. Cleaning the pricing exceptions spreadsheet took the most work. Thirty-one of the 147 rows had conflicting entries. Fourteen referenced customers Meridian hadn’t worked with in three years. Elena spent a full day reducing it to 112 validated rules.

The finished workflow is the three projects the spec named: Quote Research, Quote Pricing, and Quote Assembly drafting each Meridian quote, Elena reviewing every output before Ty, the sales lead, delivers it to the customer. That’s what Build produced against the same $558K constraint Signal named, the inputs Source mapped, and the workflow Design specified.

Low-code worked because the spec was clear enough that the freelance developer never had to invent anything. The build passed the five-question Done test on real RFQs from the prior two weeks, and the results went into the handoff to Deliver.

What done looks like: the five-question test.

The Done test is five questions. Pull the last week of actual inputs the workflow was supposed to handle and run them through the build:

Did it produce the expected outputs? Compare agent output to what a competent person would have produced. Not identical, but within the quality range the Human Orchestrator would accept from a team member.
Did it handle the edge cases? Every failure mode you named in Section 7 of the spec, did the build handle it as specified?
Did it escalate correctly? Feed it inputs that should trigger escalation. Did the right person get notified, in the right form, on the right timeline?
Could the Human Orchestrator understand the output without a walkthrough? Show the output to the named Human Orchestrator. No explanation. Can they evaluate it and make a decision?
Is the handoff package ready for Deliver? Build doesn’t brief the team; that’s Deliver’s first job. Build produces the list Deliver briefs from: every person whose handoff changes when the workflow goes live, and what changes for them. If that list doesn’t exist, Deliver starts blind.

If yes to all five: Build is done. Hand off to Deliver. If no to any: fix what failed, run the test again, and don’t advance past Build on a partial pass.

A solution that runs isn’t yet a solution the business has absorbed. That’s the next chapter’s work.

Action Step

Pull last week’s real inputs. Run the full five-question test. Document the results. Fix any failures and retest. The test results are part of the Build handoff to Deliver.

Reflection Questions

For your Sprint’s designed workflow, match the Design Brief’s category to the five environments in this chapter: Claude Projects, Claude Team, Claude Code, a workflow orchestration platform, or a custom server. Which environment fits the agent count, data sensitivity, and supervision model the design specified? Does that match where your team assumed you’d end up?
Before Build begins, fill in all seven Guardrails Checklist questions for your workflow. Which question is hardest to answer, and is that difficulty a sign that Design needs another session, or that you genuinely haven’t decided yet?
The chapter says the team that ships a Claude project with three skills in a week beats the team that spends six weeks architecting a pipeline, if the design only called for a skill. Where in your current build is scope creep already showing up? What does the spec say, versus what the builder is proposing, and which one wins?

Deliver is where the deployed system gets put in front of real work, and where the number Signal wrote down gets measured.