The 'Narrow Path' Prototyping Principle
One channel × one intent × one backend, end-to-end and instrumented — the prototype shape that produces evidence instead of opinions.
V1 · Pedagogy
✅ PASS (5/5)
Bloom's revised taxonomy, Wiggins & McTighe backward design, Sweller cognitive load, Sweller & Cooper worked examples, and authentic-task assessment — all confirmed and reused from prior lessons.
V2 · Framework lineage
✅ PASS (4/4)
Narrow Path traced to Cockburn's "walking skeleton" (Crystal Clear, 2004) and the vertical-slice user-story-splitting pattern (Cohn, 2004). Both distinctions vs MVP and vs horizontal slicing confirmed in primary sources.
V3 · Telco contact-center 2026
✅ PASS (3/3)
Amdocs × Google Cloud Agentic Telco Contact Center (MWC 2026) confirmed. Mobily: first-response 20 min → 6 sec. Cox Communications agent assist: +20–30% revenue per chat, manager span 10:1 → 14:1.
V4 · Logical consistency
✅ PASS (3/3)
Section times sum to 75 min (±15% per section). Narrow-path definition is internally consistent and non-overlapping with horizontal slice. Bloom progression Remember → Understand → Apply with Evaluate satisfied by the PM-defense artifact.
Polaris Mobile is a tier-2 carrier with 14 million postpaid subscribers and 6,200 contact-center agents across four sites. After watching Amdocs and Google Cloud announce the Agentic Telco Contact Center at MWC 2026, the SVP of Customer Operations issued an internal RFP for "an end-to-end generative-AI agent platform across all care channels, integrating BSS, CRM, OSS, and the knowledge base," go-live in twelve weeks across chat, voice, IVR, and in-app.
The FDE reads the deck twice and writes a one-line reply to Janet:
Janet pushes back: "The SVP wants the platform." The FDE answers: "The SVP wants the evidence. The platform is the second decision; we don't have the evidence yet for the first." The conversation she's about to have with Janet — and that you'll rehearse in §7 — is the single most common conversation a Forward Deployed Engineer has in the first two weeks of any agentic engagement.
By the end of this lesson you'll be able to redraw a four-system RFP as a single narrow path, and defend the choice to Janet in 250 words.
By the end of this lesson, you will be able to:
The §7 diagram + 250-word defense is the assessment. The model in §4 is the lens. Apply is the load-bearing outcome — Evaluate is satisfied by the same artifact because defending a choice is the truest test of understanding it.
Today's lesson is the artifact discipline that 1.4 and 1.5 are both pointing at. 1.4 told you that the Prototype stage exists to answer "can we build the narrow path?" — today we name what narrow means and how it is drawn. 1.5 named the behavior that pushes projects through Adopt; the narrow path is the artifact that makes Adopt possible at all.
The three axes of any contact-center engagement
A contact-center AI proposal is always positioned on three axes. The shape of the engagement is the shape it draws on those axes. Most RFPs ("an end-to-end platform") implicitly request the entire cross product. Polaris's RFP, drawn out, is 4 channels × 8 intents × 5 backends = 160 workflows. The consulting firm priced this as 24 weeks for the routing layer alone.
Use the interactive scope-shrinker below: click options to shrink the scope. Toggle the "Whole platform" / "Narrow path v1" presets to see the shape difference.
Current scope (cross product)
Path shape
Definition · the Narrow Path
The narrow path is descended from Alistair Cockburn's "walking skeleton" (Crystal Clear, 2004) — "the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end." It is the same primitive that the agile community calls a vertical slice (Cohn, 2004). The FDE-specific twist is the addition of evidence: a narrow path that does not produce an eval result, an adoption metric, and a security artifact is not narrow enough.
Definition · the Horizontal Slice
A horizontal slice picks one layer of the stack and builds it across all axes. The "build a configurable LLM router and a stub CRM connector for all four backends" in the §1 RFP is a horizontal slice: one layer (the routing layer) for all backends. The deliverable at the end of a horizontal slice is a piece of plumbing. Plumbing does not produce evidence about whether the user's intent gets resolved, whether the model's answer is correct, or whether the security review will pass. Plumbing produces a deck.
Why a narrow path produces evidence and a horizontal slice does not
Both shapes ship code. Only one shape produces evidence. Three concrete differences explain why.
- Evidence comes from real users completing real intents. A horizontal slice has no completing user — the slice ends before the user's task is done. A narrow path ends in a CRM write or a billing update; you can measure whether it happened, whether it was right, and whether the user accepted it.
- Adoption can only be measured against a workflow that was actually used. Stub connectors are never used; integrated narrow paths are. (See Cox Communications: +20–30% revenue per chat with agent assist — measurable because the chat path was end-to-end.)
- Security review needs a concrete data flow. Horizontal slices defer the data flow to a later phase, which means the security review defers too — and Polaris will not put a stubbed flow in front of a real subscriber.
What the narrow path is NOT
- Not an MVP. An MVP is a saleable smallest product; the narrow path is a pre-product evidence-producing prototype. Cockburn is explicit about this distinction.
- Not a demo. Demos are designed to impress; narrow paths are designed to produce a number a customer's security and operations teams will accept.
- Not the easiest path. The "easiest path" is the most common impostor for the narrow path — it picks the intent that's easy to model rather than the intent that produces decisive evidence. See §9 pitfall #1.
The senior FDE's narrated decision-making as she redraws the Polaris four-system, four-channel proposal as a single narrow path. The narration shows what was considered and rejected — not just what was chosen.
List the axes as they appeared in the RFP
Pick the channel with the highest evidence yield
Pick the intent with the most decisive evidence
Pick the backend the path will read/write to
Write the narrow path as a single sentence
Timebox to evidence, not to scope
Name the second path explicitly (the concession)
A different Polaris-style proposal arrives from a different consulting firm. This one is shorter: "6 channels × 3 high-value intents × 3 backends. Phase 1 (8 weeks): build the channel adapters for all 6 channels. Phase 2: add intent routing. Phase 3: add backend connectors." For each guided decision, pick the narrow-path choice. Each card hides the answer — write yours first, then reveal.
Brief
You are the FDE on the Polaris engagement. Janet, the PM, has read the consulting firm's proposal and wants "the whole platform" shipped in 24 weeks. Your task: produce a one-page Narrow Path v1 diagram and a 250-word written defense (±15%) that Janet can take to her SVP. The defense must include one explicit concession.
Use the §4 scope-shrinker above to make your three axis picks before drafting. The composer below enforces the acceptance criteria live.
Sentence 1 · The narrow path
Format: "[channel] × [intent] × [backend], end-to-end with [constraint]."
¶1 · Why this path was chosen on evidence yield
~80 words. Reasoning must be about evidence, not impact or ease.
¶2 · What evidence will exist at week 4
~80 words. Name the specific artifacts that will exist and the downstream decisions they enable.
¶3 · The explicit concession
~80 words. What the SVP wants that you are NOT building first, and what would need to be true at week 4 for the second path to start at week 6.
- Total defense length 215–285 words: pending
- Word "evidence" appears at least twice: pending
- Sentence 1 names all three axes (channel / intent / backend keywords): pending
- Concession ¶3 includes a specific deferred thing AND an un-defer condition (when/if/by week): pending
Sentence 1. Polaris in-app chat → billing-inquiry intent → BSS-backed balance retrieval and explanation, single tenant (West region, postpaid only), instrumented end-to-end with a golden eval set, agent-assist mode for ten days, and a published security stance.
¶1. This path was chosen on evidence yield, not impact. Chat produces text logs that are trivially eval-able, with no transcription dependency. Billing inquiry has a clean correctness criterion (the displayed balance matches BSS) and a bounded incorrect-answer cost — neither true of churn save or complaint intake. BSS is the only system of record that can prove the answer is right. Together these three choices guarantee that the week-4 evidence will be the same kind of evidence Polaris's security and operations teams will accept after we leave.
¶2. At week 4 we will have: a 200-example golden eval set with agreement rate, latency, and cost metrics; roughly 500 real chat conversations across two agent pods (eight agents) in agent-assist mode; a signed security stance from Polaris's security architect; and a deflection-rate measurement against the manual baseline. Those four artifacts let the SVP decide, with evidence in hand, whether to fund the second path (voice × roaming × OSS) at week 6 or to re-pick.
¶3. The SVP asked for voice and IVR in phase 1. We are not building voice in the first four weeks because the transcription dependency would consume the timebox we need for evidence on the path we are building. We are queuing voice × roaming × OSS for weeks 6–10, contingent on the week-4 evidence package showing agreement-rate ≥ 0.90 and zero security findings above medium. If those thresholds are not met, we re-pick the narrow path rather than expand to a second one.
Choosing the easiest path, not the highest-evidence path
"Let's start with social DM because the team has momentum from last quarter's demo." Easy ≠ decisive; social-DM produces a demo, not evidence.
Correction
Pick the path whose week-4 result a skeptical customer security architect would accept as proof. If the answer to "what does this prove?" is "that we can ship," you've picked the easiest path. Re-pick.
Confusing demo polish with system connectivity
A beautifully designed chat surface that calls a stubbed CRM connector is not a narrow path. It's a demo. The SoR connection is precisely what the narrow path exists to prove.
Correction
Test: can the path resolve an intent without any human stub between the model and the SoR? If no, it's not a narrow path. Add the connection — or pick a narrower intent.
Building two parallel paths because you can't decide
"We'll do chat-billing-BSS and chat-roaming-OSS in parallel — doubles optionality." It also halves the depth of evidence and produces two unfinished demos at week 4.
Correction
Pick one. Name the other explicitly as the second path (the §5 step-7 move). Optionality comes from a finished narrow path that can be cloned, not from two unfinished ones.
Bring to mind one engagement — current or recent.
The narrow path is the only artifact discipline in Course 1 that prevents the most expensive mid-engagement conversation — the one where the FDE realizes at week 10 that what they have shipped is not testable. Cheap at week 0; almost impossible to retrofit.
What evidence does a narrow path produce that a horizontal slice does not?
Success criterion: a narrow path ends in a real SoR write driven by a real user intent, so it produces correctness, adoption, and safety evidence. A horizontal slice produces plumbing, which produces a deck.
Next lesson
1.6 produced the artifact shape that yields evidence; 1.7 is the operating system in which evidence accumulates across engagements. Together they end Course 1's Foundations & Persona block.
Capstone hook
Milestone 4 is graded against a Narrow Path v1 diagram + defense identical in shape to today's §7. Save today's diagram and defense; revise at M4 and M5 (Demo). The narrow-path artifact is the document the panel reviews first.
Optional reading
The original walking-skeleton chapter. Pair with Cohn (2004) on vertical-slice user-story splitting.
Companion OS
File today's diagram and defense under this tag. Open it before every prototype-stage kickoff for the rest of Course 2.