Facebook tracking pixel How we run an AI System Build | Handbook | Conversion System Skip to main content

Named workflow, owner, proof

How we run an AI System Build

The Sprint maps the workflow gap, ships the system that fixes it, and makes the proof visible.

7 min read · Section: Playbook · Updated 2026-05-29

A branded handbook visual showing operating notes, decisions, and AI system handoffs

An AI System Build is six weeks of focused work on one named workflow. The deliverable is a working system, not a planning memo. Here is the week-by-week shape.

Week 0 (pre-kickoff): the contract

Before kickoff, three things are in writing. The named workflow. The owner. The outcome that tells us the system is useful. If any of those is fuzzy, we delay kickoff until they are sharp.

Week 1: the map

Day one is the 60-minute whiteboard exercise. Hand-drawn, no software, no Miro template. We map the workflow from first signal to completed action. By the end of the hour, the worst handoff is visible to everyone in the room. The map becomes the architecture for the Sprint.

Weeks 2-3: the build

This is where the named owner on the client side earns the title. We pair every workday on the actual fix. If the gap is qualification, we rewrite the qualification rubric and load it into the CRM. If the gap is sequencing, we build the touch-2 and touch-3 cadence in the email platform. If the gap is handoff, we build the SDR handoff tree with the rules in version control.

Week 4: the dogfood

We run the new system on real leads for a full week. No theory, no synthetic test data. The named owner runs the workflow end to end. The CS team watches and tunes. Every break is a Linear ticket, every fix ships same-day.

Week 5: the dashboard

The buyer needs to see whether the workflow improved without us in the room. We ship a dashboard that the client opens on day one and every day after. It shows the named outcome, the operating movement, and the plan trail of which fixes landed which results.

Week 6: the handoff

We document. The named owner takes possession. We do a one-hour exit review where the client demonstrates running the system without us. The Sprint ends on Friday of week 6, on the named ship date, no extensions.

What we do not extend the Sprint for

  • Internal stakeholder reviews that the named owner did not schedule.
  • "While we're at it" requests outside the named gap.
  • Tool migrations the client decided to do mid-sprint.
  • Hiring decisions the client postponed.

What ends a Sprint early

If the named business result is already improving by week 3, we stop building and run a measurement week. Faster is better than fuller. The agreement is for the result, not the calendar.

If the dogfood in week 4 shows the system is not moving the metric, we run a one-week recovery. If recovery does not converge, we say so plainly and publish what we learned. It is in the open.