Agentic AI Prototype Templates: Stage 5 Pipeline Kit

An agentic AI prototype that ships to production looks almost identical to one that quietly dies in a Slack channel — until you inspect the eval harness. Stage 5 of the agentic AI implementation pipeline is the line where the program either becomes measurable and inheritable or stays a demo nobody wants to maintain. This kit ships the templates that keep prototypes on the production side of that line.

The default Stage 5 failure mode is recognisable: a small team builds a working prototype in two weeks, runs a slick demo for leadership, hears applause, and then watches the project drift for three months because nobody can answer the question is it actually good enough to ship. Evals were never written, success criteria were never defined, and the demo evidence was vibes. By the time the next quarterly review lands, the prototype is forgotten — or worse, in production without measurement, accumulating regressions silently.

This guide covers the five Stage 5 artifacts in order: the prototype brief, the eval harness, the success criteria framework, the prototype-to-production gate checklist, and the demo script. Every section ships a template. The pipeline hand-off to Stage 6 (production deploy) closes the kit. Read it once; reuse the templates for every prototype your team builds.

Stage 5 is the most consequential stage in the pipeline because it is the first stage where the program produces a concrete artifact that either survives or doesn't. Stages 1 through 4 deliver documents — readiness scores, roadmaps, data audits, vendor scorecards. Stage 5 delivers software. The transition from paper to code is where many programs discover that the previous four stages described a different problem than the one the prototype is now trying to solve.

The right framing for Stage 5 is not "build a prototype." It is "build an eval harness and a prototype that runs against it." That single inversion changes every downstream decision. When the eval harness comes first, the prototype builds toward a measurable target rather than a felt sense of completion. When the success criteria are written before the build, mid-build scope creep becomes visible rather than invisible. When the gate checklist is agreed in advance, the deploy decision is data-driven rather than political.

The cost of getting Stage 5 wrong is not a wasted prototype — it is a prototype that ships into production without measurement, accumulating quality debt for the next twelve months. Every audit we run finds at least one such system: a prototype that became production because the demo went well, with no eval rails, no success-criteria tracking, and an owner who has since moved teams. The Stage 5 templates exist to prevent that pattern, not to slow the prototype down.

The five artifacts in this kit are sequenced deliberately. The brief defines the problem and the hypothesis. The eval harness makes the hypothesis testable. The success criteria define what passing looks like. The gate checklist makes the production hand-off measurable. The demo script makes the evidence narratable. Skip any one of the five and the prototype is structurally weaker — most often, teams skip the eval harness because it feels slow, and then spend the next quarter recovering from that decision.

The prototype brief is the artifact that prevents Stage 5 from inheriting a fuzzy mandate from Stages 1 through 4. It is a single page — deliberately short — that names the problem the prototype addresses, the scope boundaries, the hypothesis the prototype is testing, and the explicit non-goals. The brief is signed off by the business owner, the technical owner, and the AI lead before any code is written.

The hypothesis is the part teams skip the most. A prototype without a hypothesis is a feature build; a prototype with a hypothesis is a test. The difference matters because tests have outcomes — they pass or fail against the eval harness — whereas feature builds only have completion states. The hypothesis should be specific enough that the eval harness can measure whether it held, and falsifiable enough that the team agrees in advance what disconfirmation looks like.

Two operational discipline points are worth flagging. First, the brief lists the eval-harness readiness date beforethe prototype-freeze date — the eval comes first, not last. Second, the brief explicitly names a Stage 6 hand-off date that is conditional on the gate passing. Naming the conditional from the start prevents the political hand-wave where the prototype "ships" without ever passing the gate.

For the briefing template at scale, our AI transformation engagements embed this artifact as the first deliverable of every Stage 5 engagement, with the eval harness and success criteria sequenced as the next two. The pattern is reproducible across archetypes — agentic SDR, document agent, customer-support copilot — with the archetype-specific differences handled inside the eval harness, not the brief.

The eval harness is the single highest-leverage artifact in the entire Stage 5 kit. It is the contract the prototype builds against and the line that separates a measurable system from a vibes-driven one. The harness must be runnable before the first prompt is written; the test cases drive the prompt design, not the other way around.

Three open-source frameworks cover the majority of agentic AI prototypes. The choice is driven by the prototype archetype, not personal preference. Pick the wrong framework and the harness still works, but the team spends extra effort fighting the tool instead of measuring the system.

The number of test cases per prompt at the prototype stage is modest — twenty to fifty per critical path, covering happy path, known edge cases, and at least three deliberately adversarial inputs designed to stress the hypothesis. The point is not exhaustive coverage; the point is enough coverage to detect regression. Coverage breadth is a Stage 6 concern, not a Stage 5 one.

The eval harness output feeds two artifacts directly: the success criteria (Section 04, where the numeric thresholds come from) and the demo script (Section 06, where the eval evidence becomes the demo's narrative spine). Without a working harness, the downstream artifacts cannot exist in usable form. This is why the sequencing matters — the harness is dependency for everything else.

For a deeper treatment of eval framework selection and 100-point library audits, our prompt library audit framework covers the institutional discipline that grows out of one good eval harness. Stage 5 plants the seed; the audit framework grows the forest.

Success criteria are what turn a prototype from a feature into a test. They are written before the build, signed off by the business owner, and locked for the duration of the prototype. Mid-build redefinition is allowed exactly once and requires a written rationale; uncontrolled drift in success criteria is the single most reliable predictor of a Stage 5 program that never reaches a clean go/no-go decision.

The criteria split into two halves. Quantitative criteria are measured directly by the eval harness — accuracy, precision, recall, latency, cost per call, faithfulness score, refusal rate. Qualitative criteria are graded by a small panel of humans on a small rubric — usability, tone, trust, escalation behavior, failure-mode acceptability. Both halves are required; neither is sufficient alone.

The two-threshold model — target plus floor — is what makes the criteria operationally useful. A single threshold creates a binary outcome; a target-plus-floor creates a three-zone outcome (clearly passing, conditionally passing with remediation, failing). The floor row is what prevents a prototype from sneaking through with one excellent metric covering several mediocre ones.

The hard-fail rule deserves explicit attention. Most prototype programs allow individual metric failures to be argued away in the gate meeting ("the trust score is low but the usability is great"). The hard-fail rule short-circuits that argument — any metric below its floor blocks the gate regardless of the others. The rule exists to protect the program against its own optimism.

The prototype-to-production gate checklist is the artifact that makes the Stage 5 to Stage 6 hand-off measurable rather than political. Twenty checks split across five axes — four each. A prototype passes the gate when at least sixteen of twenty are green and zero are blocked. Anything below that returns to the team with a numeric target rather than a negotiation.

The five axes mirror the structure of the prompt library audit framework, deliberately. Stage 5 is where the institutional discipline of evals, observability, and ownership starts; the gate is the first inflection point where that discipline becomes visible. Skipping the gate is how teams end up at Stage 1 of the audit framework instead of Stage 3.

The gate score is reported as a single number — 17 of 20, 19 of 20 — alongside the per-axis breakdown. Reporting the breakdown matters because the same total can hide very different shapes; a prototype that scores 17/20 with zero in observability is a very different artifact from one that scores 17/20 evenly. The production-deploy team in Stage 6 reads both numbers, not just the total.

For programs that want a deeper treatment of the deploy-side mechanics — feature flags, kill-switches, canary releases — our companion Stage 6 production deploy kit picks up exactly where this gate ends. The two stages are designed to compose: Stage 5 produces a gated artifact, Stage 6 ships it under measurement.

The demo script is the artifact that turns the eval evidence into something a non-engineering executive can act on. The hard rule: three minutes, eval-evidence-driven, no curated happy path. The soft rule: the script is rehearsed at least twice before it is performed, and rehearsed against the real eval harness, not a mocked-up version.

Most prototype demos fail one of three ways. They are too long and lose the room. They are happy-path-only and trigger the executive's "what could go wrong" reflex without answering it. Or they show enthusiasm without evidence — the presenter is excited, the screens look good, but no measurable claim is made. The three-minute structure below addresses all three failure modes by design.

The discipline of running an adversarial case live, alongside a happy-path case, is what separates the eval-driven demo from every demo the audience has seen before. Executives learn quickly that a demo that includes its own failure modes is substantially more trustworthy than one that doesn't. The paradox is that showing failure increases the probability of green-lighting the next stage, because the trust premium outweighs the embarrassment of the failed case.

Three anti-patterns account for most Stage 5 failures. They are recognisable in retrospect and avoidable in advance, but each one requires deliberate counter-discipline. The templates in this kit exist to make the counter-discipline default rather than heroic.

The demo-first anti-pattern is the most common and the most insidious because each individual decision looks reasonable at the time. Skipping the eval harness saves a week. Pushing it to Stage 6 sounds like a sensible deferral. The accumulated cost only becomes visible three to six months later, when the production system has shifted underneath the prototype and nobody can tell whether quality has degraded or whether it was always this way.

The criteria-drift anti-pattern is the most politically sensitive. Renegotiating thresholds mid-build feels like healthy pragmatism — the team is learning what is achievable and updating the targets accordingly. The problem is that updates always trend in one direction (down), and the gate review becomes a performance rather than a test. The counter-discipline is procedural: criteria changes require written rationale and re-signoff from the business owner. That small friction is enough to stop the silent drift.

The owner-less anti-pattern is the most expensive to fix because it requires retroactively recruiting an owner for something that may already be in production. The right time to address it is at brief signoff; the second-best time is at the gate review; the worst time is six months later when the production system needs an upgrade and no one knows the prototype well enough to make the call.

A prototype that passes the gate is not ready for production — it is ready for Stage 6. The distinction matters. Stage 6 converts the gated artifact into a deployed system under measurement, behind a feature flag, with the rollback and kill-switch rails wired live rather than tested in staging. What Stage 5 delivers is the right thing to deploy; Stage 6 delivers the right way to deploy it.

The five Stage 5 artifacts become the five Stage 6 inputs. The brief informs the rollout communication. The eval harness becomes the nightly cron and the regression dashboard. The success criteria become the production SLOs. The gate checklist becomes the deploy-readiness rubric. The demo script becomes the rollout announcement. Every artifact compounds; nothing is thrown away at the stage boundary.

For programs ready to make the hand-off, our Stage 6 production deploy templates cover the deploy-side mechanics in the same template-driven shape. The two kits are designed to be used together — independently usable, but most powerful in sequence.