Deliver: Ship It Into How the Work Runs
Build deployed the workflow. Deliver makes the organization actually use it. The difference between “deployed” and “delivered” is whether people’s work changed — and whether you can prove it with a number tied to the constraint Signal named. This stage has five parts: a readiness audit, per-role runbooks, an operational log, a Sprint outcome measurement, and a delivery test. Skip none.
We flip the switch on a Wednesday.
The workflow goes live. The agent starts pulling tickets from the queue, routing them, logging its decisions. I’m watching the dashboard with Sofia, our VP of Operations, reviewing with me in real time. Left side: everything working the way we designed it. Right side: flags. The agent is handling a category of inputs we didn’t map fully in Source, and it’s doing things we didn’t expect.
I tell her: “Pretty buggy over here. But it’s doing a great job over there.”
She nods. We’re both looking at the same screen.
“Live” is a technical claim. The agent is running. The workflow is in production. The ticket is about to get closed. None of that means the Sprint produced.
The Sprint produces on Monday. The operator whose week was supposed to change sits down, opens their queue, and the eight hours of routing work they used to do is gone. They have something different to do instead. If that happens, the Sprint produced. If they’re still routing manually and sending work to the old inbox, still working the system we were supposed to replace, then we deployed a tool and didn’t deliver anything. How much you delivered is a number, and it comes later in this chapter.
Deployed is not the same as delivered.
Build ends with a working agent running in production. That is a real milestone. It is also incomplete. The agent is doing the work it was designed to do; the organization around it has not yet adjusted to receive what the agent now produces.
Operators skip Deliver’s work more often than any other stage’s. The technology side is built; the organizational side is assumed. Three things have to be true before the go-live date:
- Everyone affected is named, with how their daily work changes stated.
- Those people are trained on the new handoffs before they meet them in production.
- A measurement baseline exists against the cost Signal identified.
Skip one and you discover the gap in production, where fixing it is expensive. The Deploy Readiness Audit below turns all three into gates.
The person whose week used to include four hours of manual routing now has those four hours back — but only if their calendar, their queue, and their handoffs have been re-set to reflect that. The colleague who used to send them tickets needs to know to send the tickets somewhere else. The manager who used to see the weekly summary needs the new reporting wired up. The escalation path for the exceptions the agent flags needs to land on a human who has been told it will land on them.
If you skip that work, the deployed system still functions — but the organization continues to behave as if the old workflow is in place. People route around the new system because they were never told to route through it. The agent does its job. The hours don’t come back. The cost Signal quantified doesn’t get recovered. The Sprint produced less than it could have.
I learned this in my own shop before I understood it as a principle. We finished a Sprint, deployed a workflow, wrote the runbook. Two weeks later I watched a teammate do the task manually, the exact task the agent now handles, because she’d never been explicitly told to stop. The workflow was in production. The old inbox was still open. She was routing to both, hedging, not sure which one was “real.” I asked her why she was still doing it the old way when we’d built the tool to do it. But I was the one who never closed the old inbox.
This wasn’t resistance. Nobody told her to stop. That’s Deliver’s job. The technology was done; what wasn’t done was the operational work: closing the old inbox, redirecting the upstream handoff, making the new workflow the only workflow. Until that happens, you have two systems running in parallel, one of them invisible, and people will choose the one they know.
If the old system is still accessible, people will use it. Close the old path. The new workflow replaces the old one; it doesn’t run alongside it.
This chapter fills in the Deliver row of the Sequence first-pass on your Sprint Planning Canvas. Deliver runs in five parts, in order. The Deploy Readiness Audit proves the organization is ready before the switch flips. The per-role runbook makes the change explicit for every person whose handoffs moved. The operational log captures what production reveals that the design didn’t. The Sprint outcome measurement puts two numbers on what the Sprint produced. And the delivery test is the gate that says whether you delivered or just deployed.
The Deploy Readiness Audit.
Before your team flips the switch, you run a pre-flight check. Four binary gates. Every gate must pass. If any answer is “no,” you stop, fix it, and re-run.
The Audit is a check on prior work, not new authoring. Every question points to something that should already exist: a trained person, a documented path, a tested input, a scheduled review. The inputs arrive from upstream. The Design Brief’s Stakeholders section named every role whose job changes, and Build’s Done test packaged that list forward with the working system. What Build didn’t do is brief those people — that’s Deliver’s first job, and the Human Orchestrator is accountable for the briefing having happened before Gate 1 gets answered. Most failed deploys trace back to a question nobody asked at this gate.
How to run the Deploy Readiness Audit
- Gate 1 — Confirm hands-on training
- Gate 2 — Document the escalation path
- Gate 3 — Test against real data
- Gate 4 — Book the Human Orchestrator review cadence
- Resolve every Fail before deploying
Gate 1 — how much practice is enough
Scheduled training doesn’t clear Gate 1. What clears it is every affected person having run real inputs through the new workflow with their own hands. How much practice that takes scales with how often the role touches the workflow:
- A claims processor who’ll touch the new flow forty times a day needs a supervised morning on live claims, not a demo.
- A scheduler who’ll touch it a few times a week needs three or four real bookings run end to end, with someone watching.
- An account manager who only receives the workflow’s output needs one walkthrough of a real deliverable, plus the escalation rule for when it looks wrong.
“Practiced” means the person has hit the workflow’s normal case and at least one exception. If they haven’t seen an exception yet, they’ve watched, not practiced.
Gate 2 — verify the escalation path is live
Gate 2 doesn’t author the escalation path. The Guardrails Checklist in Build already named it: judgment-requiring output goes to a specific person, in a specific form, on a specific timeline. What this gate verifies is that the answer left the checklist: it’s published where the team works, and the named humans have been told the escalations land on them. A person who discovers they’re the escalation path when the first exception arrives is a Fail, even if the document was perfect.
The response window is the part operators guess at. Set it by the cost of a wrong output escaping, not by the volume of escalations you expect:
- Customer-facing output (a quote, a support reply, a proposal): hours, because someone is waiting on it.
- Internal batch work (a weekly report, a reconciliation run): next business day is defensible.
- Anything touching money or compliance: before the output leaves the building, whatever that takes.
Gate 3 — test on the inputs your team dreads
Synthetic tests confirm the workflow does what you designed. Real inputs surface what you didn’t design. The last two weeks matter not because two weeks is magic, but because recent inputs carry your current customers, current formats, and current mess.
Volume matters less than selection. Don’t pick the clean ones:
- For an intake workflow: the rambling email with the attachment missing.
- For a bookkeeping workflow: the vendor who invoices in a different format every month.
- For a scheduling workflow: the client who calls in changes an hour before the appointment.
If nothing in the test set makes your best person wince, you tested the demo, not the operation.
Gate 4 — verify the oversight cadence is on the calendar
Gate 4 doesn’t decide how much oversight the workflow needs. Designing the Work already set the oversight load for every agent in the spec (Low, Medium, or High), and every new agent starts at High. This gate checks that the calendar matches the level: a High-oversight agent with no recurring review event is a Fail, however good the intentions.
The cadence tapers on evidence, not on time. The target Designing the Work set is to earn Medium through demonstrated accuracy over multiple Sprints, and the operational log below is where that evidence accumulates. The review never comes off the calendar entirely, even at Low.
| # | Gate | Pass / Fail |
|---|---|---|
| 1 | Has every person whose work changes been trained on the new flow, with hands-on practice on actual inputs? | Pass / Fail |
| 2 | Is the escalation path from the Guardrails Checklist published where the team works, and have its named people been told the escalations land on them? | Pass / Fail |
| 3 | Has the workflow been tested against real data from the last two weeks, using actual inputs from your operation? | Pass / Fail |
| 4 | Is the oversight level set in Designing the Work on the Human Orchestrator’s calendar as a recurring review? Non-negotiable. | Pass / Fail |
Meridian Manufacturing.
Elena ran real quotes through the pipeline herself while Dave sat with the agent’s historical job matching, checking its picks against specs he knew by heart. That was Gate 1: live work, not a walkthrough. The rest of the audit was verification. The escalation path was already written and published, non-standard materials routing to Dave and low-confidence quotes to Elena. The workflow ran against two weeks of real RFQs pulled from HubSpot, with the 112 validated pricing rules loaded into the pricing project’s context. Elena’s review went on the calendar as Monday and Thursday mornings, recurring. Four gates, four passes. Clear to deploy.
Pull up your Hybrid Accountability Chart from Designing the System. Set it next to the Design Brief’s role-change list and confirm every person whose daily work changes has completed hands-on training that meets Gate 1’s bar. If anyone hasn’t, that’s your first task before deploy.
The per-role runbook.
Deliver training is different from technology training. Most technology training covers how to use the new system. The training that prevents adoption failure covers the handoff: where the human’s work ends and the agent’s work begins. The handoff is where the work breaks. It’s where the human either completes the output correctly and passes it to the agent, or does it incorrectly and compromises everything the agent produces downstream. Every person whose handoff changes should be able to answer two questions before go-live: what do I do differently now, and what does the agent do that I used to do? The per-role runbook is the document that makes both answers explicit, one page per role.
You’re not discovering who those people are. The Design Brief’s role-change list named them; the list arrived in Build’s handoff package. The runbook turns each name on it into a page: what changed, in writing, so the answer doesn’t live only in whoever ran the training.
How to write the per-role runbook
- Identify affected roles from the Hybrid Accountability Chart
- For each role, answer the four change questions
- Write the three-column entry (input / output / escalation)
- Apply the vacation test
- Publish the runbook in the team’s live tool before go-live
For every role affected by the Sprint, document three things: what they receive, what they produce, and when they escalate.
| Role | Input (what they receive) | Output (what they produce) | Escalation (when and how) |
|---|---|---|---|
For each role, answer four questions:
- What does this person do differently than before the Sprint?
- What does the agent handle that this person used to handle?
- How does this person review agent output?
- What triggers an escalation?
“Reviews output” is not an entry
The runbook’s failure mode is the entry a manager could have written without knowing the job. “Reviews output” describes half the roles in your company; it tells the person on the page nothing about Monday morning. “Opens the quote draft in the shared folder, checks unit costs against the rate card, approves or flags within 4 hours” is an entry: it names the artifact, the check, and the clock. The same bar holds for a bookkeeper: “Reviews the coded invoices” fails; “Opens the agent’s coded invoice batch each morning, checks vendor and GL code against the coding rules, approves or flags by noon” passes.
If the sentence could be pasted into another role’s row without anyone noticing, it isn’t concrete enough.
Meridian’s runbook, role by role.
At Meridian, three roles changed handoffs — the three names on the role-change list. What changed:
- Dave used to give Elena verbal labor-hour estimates when she asked. Now he reviews the agent’s historical matching weekly and gets pulled in only for non-standard materials — the work that actually requires thirty-one years of fabrication knowledge.
- Elena used to build every quote from scratch, fifteen hours a week. Now she reviews agent-generated drafts in fifteen to twenty minutes each, spending the recovered hours on production planning and supplier negotiations.
- Ty used to wait three to five days for Elena to produce a quote, then forward it to the customer. Now he receives approved quotes same-day for standard work and can see every quote’s status in the CRM pipeline.
The runbook made each change explicit:
| Role | Input | Output | Escalation |
|---|---|---|---|
| Dave Kowalski (Sr. Design Engineer) | Specs flagged by the Quote Research Agent for non-standard materials or tight tolerances | Manual pricing for flagged line items; confirmation or correction of agent’s historical job match | Consulted on any quote involving Inconel, titanium, or exotic alloys. Receives Claude Team notifications when the agent flags a match it cannot confirm. |
| Elena Ruiz (VP Ops) | Agent-assembled draft quote in her CRM review queue, with confidence score and historical matches | Approved quote (or edited and approved), updated Customer Notes.xlsx when new exceptions arise | Reviews every assembled quote. Monitors confidence score distribution. Updates pricing rules for new exceptions. Works from Claude Team workspace and JobBOSS. |
| Ty Banfield (Sales) | Approved quote delivered via HubSpot notification | Customer-facing proposal sent same-day for standard work | Reports customer feedback to Elena. Flags any quote that does not match what the customer requested. Submits all RFQs through the standardized intake form — no email forwards. |
The runbook test: could someone who was on vacation during the entire Sprint sit down with this document and know exactly what changed about their job? If not, the runbook isn’t done.
Pick one role from your Hybrid Accountability Chart whose handoffs changed. Write the three-column entry (input, output, escalation), one sentence per column. Then apply the paste test: if any sentence could sit in another role’s row unnoticed, sharpen it until it can’t. Publish the page where the team already works (the project management system, the shared doc, the Slack channel).
What gets logged.
Deliver also surfaces what did not work. The full retrospective belongs to Compound, in the next chapter. This is the operational log that captures, in real time, the gaps between what was designed and what production actually revealed.
How to build and maintain the operational log
- Create the four-column log template before deploy
- Assign a single named owner
- Run daily check-ins for the first two weeks
- Categorize every entry (Unplanned intervention / Data gap / Edge case / User confusion)
- Tally by category at end of week two and surface the top category as the next Sprint signal
| Date | What happened | Category | What it signals |
|---|---|---|---|
Four categories. Use exactly these:
- Unplanned intervention — a human had to step in where the agent was supposed to handle it.
- Data gap — the workflow needed information that doesn’t exist or wasn’t connected.
- Edge case — an input the design didn’t account for.
- User confusion — a person whose work changed didn’t know what to do.
Some entries fit two categories. A human steps in because the design missed an input type: that’s an unplanned intervention and an edge case at once. File it by what happened, not by what caused it: if a person had to step in, it’s an unplanned intervention, and the cause goes in the signals column, where it becomes the fix. The category column counts what production cost your people; the signal column says what to change. And if two categories tie at the week-two tally, you usually don’t have two problems — you have one problem surfacing two ways. Read the signal column across both categories and look for the single design change that clears entries in each. That’s the candidate constraint the tally hands forward.
In Source, we described how our own agents kept surfacing expired information because nobody audited the knowledge base before indexing it. That’s what Deliver’s logging phase catches — the gaps that Source couldn’t see because they only become visible in production.
Meridian’s first two weeks.
Meridian’s log filled fast. Four entries in ten days, three of them the kind of gap no test catches until real work hits the system:
| Date | What happened | Category | What it signals |
|---|---|---|---|
| Day 2 | Agent hit an Inconel 718 specification not in Customer Notes.xlsx. It flagged low confidence and escalated to Dave — but also attempted to estimate using 316 stainless as the closest match, producing a price 40% below actual Inconel cost. Elena caught it in review. | Edge case | Agent must produce no price estimate for unknown materials — flag as “manual pricing required” and stop. Guardrail added same day. |
| Day 4 | Ty submitted an RFQ without the customer’s drawing attached. Agent produced an estimate based on the text description alone, which was too vague to be usable. Elena rejected it. | User confusion | Intake form needs a required field for drawings on custom fabrication work. Ty pushed back (“sometimes the customer calls in a description over the phone”); Elena held the line: “If there’s no drawing, you sketch what they described and attach it.” Required field added. |
| Day 7 | Dave sat in on Elena’s review and challenged the agent’s historical matching on a weldment quote. The agent matched on material and dimensions but missed that the tolerances were tighter, which doubled the labor. Side-by-side comparison showed the agent was correct on four of five specs — Dave caught the one tolerance error that mattered. | Unplanned intervention | Tolerance class needs to be a matching criterion, not just material and dimensions. Design task for next Sprint. |
| Day 10 | Ty reported that a customer praised Meridian’s same-day turnaround on a standard bracket quote — first time Meridian had ever delivered a quote that fast. Customer submitted a second RFQ the same afternoon. | — (positive signal) | Speed is producing repeat inbound. Track whether faster turnaround correlates with increased RFQ volume from existing customers. |
The Day 7 entry is the ambiguous case in the wild: the tolerance miss was an edge case, but Dave had to step in, so it’s filed as an unplanned intervention with the design fix carried in the signals column.
Create the log template in whatever tool your team already uses, with four columns: Date, What happened, Category, What it signals. Name the person who owns it, and put a daily review on their calendar for the first two weeks. Do this before you flip the switch, not after.
The measurement question.
Deliver’s last instrument produces the Sprint Outcome Record: five fields that put the cost Signal named next to what production actually delivered, capped by the outcome in one sentence. The Record is the artifact Compound works against; if you can’t produce it, stop and diagnose before declaring the Sprint done. Filling it honestly takes two numbers — the operational number (what moved against the constraint) and the adoption number (how many of the affected people actually run the new workflow). One number alone is incomplete.
How to measure the Sprint outcome
- Pull the Signal statement and quantified cost
- Measure the same metric in production (result after Sprint)
- Compute the delta
- Write the outcome in one sentence
- Calculate and report adoption rate (week-two window)
The operational number
Deliver’s first responsibility is to measure the Sprint against Signal’s quantified cost: same metric, same unit, so the comparison holds. When Signal put a number on the constraint and Deliver can show what that number is now, the math is legible and the next Sprint earns the right to start.
That’s the clean case. The harder cases are the ones where the measurement is harder. The Sprint clearly changed the work. The operator’s week looks different, the bottleneck is gone, and the log shows unplanned interventions dropping week over week. But the dollar figure is hard to pin down because the original Signal quantification was looser than it should have been. That’s a Signal lesson, not a Deliver failure, and it goes into the Compound stage as an input to how the next Sprint gets framed.
The discipline is to write the number down anyway. If the constraint cost was estimated at “around 8 hours a week” and Deliver shows the work now takes 30 minutes a week, the recovery is real and the math is good enough to report. Refuse the trap of declaring victory without evidence, and the equally bad trap of letting imperfect evidence become an excuse to claim nothing happened. The leadership team needs to know what changed; they don’t need a three-decimal-place ROI.
The Record itself is five fields:
| Field | Entry |
|---|---|
| Signal statement | [the one-sentence constraint from Signal] |
| Cost at start | [the quantified cost — dollars, hours, or margin] |
| Result after Sprint | [what actually happened — same metric, same unit] |
| Delta | [the change — quantified] |
| Outcome in one sentence | [what this Sprint produced, stated plainly] |
What Meridian could prove
Meridian’s Record is what the baseline discipline buys you. Signal wrote the constraint down with a number. Deliver measured the same metric in production. The delta needed no narrative:
| Field | Entry |
|---|---|
| Signal statement | Elena Ruiz is the sole quoting bottleneck. Every quote runs through her — $558K/year in lost revenue, misallocated time, and shop floor underutilization. |
| Cost at start | 3.8-day average turnaround; ~15 hrs/week of Elena’s time; capacity capped at 8–10 quotes/week. |
| Result after Sprint | 4.2-hour average turnaround on standard work; ~5 hrs/week of Elena’s time; 18–22 quotes/week. |
| Delta | Turnaround reduced 89%. Elena recovered 10 hrs/week. Quote volume doubled. First-month revenue recovery: $47K. |
| Outcome in one sentence | Three-agent quoting pipeline removed Elena as the bottleneck on standard work, cut turnaround from 3.8 days to 4.2 hours, and produced $47K in new revenue in month one, by letting Meridian quote fast enough to win jobs they used to lose. |
The team tracked three leading indicators weekly:
- Quote volume per week.
- Confidence score distribution across the agent pipeline.
- Escalation frequency to Dave on non-standard materials.
Those leading indicators matter because the outcome sentence is a trailing measurement — it tells you what happened. The leading indicators tell you whether it will keep happening.
The adoption number
The Record’s operational fields capture the cost Signal named against the result Deliver produced. That’s one of the two numbers the Sprint outcome requires. The second is adoption rate: what percentage of the affected roles are using the new workflow as designed, not the old workflow out of habit. A workflow that works technically but that half the affected people route around is delivering a fraction of what the Sprint was designed to produce.
Adoption rate is countable at the scale most operators run. The denominator is the named roles from the Hybrid Accountability Chart whose handoffs changed in this Sprint — not enterprise-wide users, not licensed seats, but the specific people whose work changed. The numerator is the named people observably running their work through the designed workflow, visible in the operational log. “Use” means the affected person’s work went through the designed path, not around it. Report the number as of week two after launch, the same window the operational log’s first review cadence closes on.
At Meridian the denominator was three: Dave, Elena, and Ty, the three roles on the runbook. Week one’s count was two of three: Ty had forwarded three RFQs to Elena the old way, out of habit. By week two the count was three of three. That week-one miss isn’t a failure story. It’s what the adoption number exists to catch while it’s still one person and one habit, not a workflow quietly dying.
The two numbers together tell the story. High adoption with modest operational improvement is a Design problem: the constraint was named correctly but the workflow wasn’t built to solve it at the projected cost. Low adoption with strong operational improvement on the work that did flow through is a change-management problem: the design works, but the organization hasn’t adopted it yet. The next Sprint adjusts accordingly — either the workflow design or the change-management approach, depending on which number is low. Meridian’s quadrant was the one you want: high adoption, strong improvement.
Go back to your Signal instrument. Copy the Constraint Statement and quantified cost exactly as written. Measure the same metric now — same unit, same timeframe, same source. Calculate the delta. Write the outcome in one sentence. No spin.
The delivery test.
The delivery test is a checklist. Run it before you declare the Sprint complete:
Every unchecked box is a task, not a judgment call. Check them all and the Sprint delivered. Leave any unchecked and you deployed a tool — the organization hasn’t changed yet.
If you can’t fill in the “Result After Sprint” line with a number, go back to the operational log and figure out what you need to measure.
End of the Sprint as a project. Start of it as infrastructure.
Deliver is where the Sprint stops being a project and becomes infrastructure. The workflow is live and the team runs it. The hours it recovered either get reinvested in the higher-return work Design identified or come out of the org over time as the headcount math gets rerun. Depending on the Sprint, the constraint Signal named is either resolved, materially reduced, or honestly described in terms of how much of it the Sprint moved and how much remains.
That artifact set is the work behind the Deliver row on your Sprint Planning Canvas, and it’s what the next stage works against: the Sprint Outcome Record, the log, the runbook, the updated Hybrid Accountability Chart entry. Compound is where the team turns it into the inputs that accelerate the next Sprint. That’s the next chapter.
Reflection Questions
- Run the Deploy Readiness Audit on your current Sprint before you flip the switch. Which of the four gates — training, escalation path, real-data testing, Human Orchestrator cadence on calendar — is the hardest to confirm as Pass? What specific task would close it?
- Write the per-role runbook entry for the person whose daily work changes most because of this Sprint. Does the runbook pass the vacation test — could someone who missed the entire Sprint sit down with that document and know exactly what changed about their job?
- The chapter describes a teammate who kept routing to the old inbox because nobody explicitly told her to stop. Is there an old inbox, old process, or old system in your Sprint that will stay open after deploy unless someone actively closes it? Who closes it, and when?
- Fill in the Sprint Outcome Record: Signal statement, cost at start, result after Sprint, delta, outcome in one sentence. If you can’t fill in “result after Sprint” with a real number, what measurement do you need to set up before Deliver begins — not after?