# P2 Build & Prove: How to Build an AI Agent in Proven Slices
Build the exact parts first, measure the guessing parts by slice, and let a harness, not a meeting, decide what merges.
8 min read · Intermediate · Lesson 6 of 9 in Agentic PDLC fundamentals · Updated 2026-09-24 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/p2-build-and-prove/
> **In short.** P2 Build & Prove builds the agent in **bolts** (slices of hours or days, one risk
> each) and puts every exact step in tested code. It measures every best-guess step against its bar
> on a golden set in CI, so that a merge dropping any slice below its bar is blocked. It ends with a
> **shadow run** in which the agent works beside the live process without acting.
**In this lesson** you'll learn:
- how to cut the build into bolts and why the first one has no model in it;
- how to wire a harness that blocks a merge when any slice falls below its bar;
- what a shadow run proves that a golden set cannot.
## Sound familiar?
- The sprint demo is on day fourteen, and nobody knows until then whether the hard part works.
- The overall score went up after a prompt change, and so did the complaints about refunds.
- The evaluation runs on every pull request, posts a comment, and can be clicked past.
P2 replaces all three with evidence that arrives daily and a check that can actually say no.
## What is P2 Build & Prove?
P2 is the third phase of the [agentic PDLC](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/what-is-the-agentic-pdlc/), and it opens only
after the [hard gate](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/the-hard-gate/): a signed spec, a bar for each slice and an authority
budget. The **engineering lead** is accountable. QA owns the golden set, the checkers and the shadow
comparison; DevOps owns the pipeline, the environments and the flags.
P2 ends when **the golden set clears the bar for every slice and a shadow run agrees with the people
doing the job**.
## P2, step by step
### Step 1 · Cut the build into bolts
When building is fast, the unit of planning shrinks to match. A **bolt** is a thin, shippable slice,
built and integrated the same day, carrying **one unknown**. The cut is by dependency, not by
priority: a walking skeleton that runs end to end with no model in it goes first, exact code goes
early because it never blocks, and a gated write goes only after the control it needs exists.
At SkyWays a two-week sprint with five stories and a demo became ten one-day bolts. Day one's
skeleton (read a booking, display it, no model) took half a day and found a credentials problem in
the reservation adapter that would otherwise have surfaced in week two.
### Step 2 · Build the exact floor, then the gates, in code
Every number the feature computes and then acts on is a function with a unit test, never a prompt.
A model doing arithmetic fails **fluently**: at SkyWays it returned $80 where the ledger said $62,
with no error. Then put each boundary in the tool itself (a typed, bounded parameter that raises)
with two tests that were seen failing before they passed: one over the cap, one without the
confirmation the model cannot create for itself.
### Step 3 · Measure every slice against its bar
The golden set is the acceptance bar made executable: real past cases, each with the expected
outcome and a slice tag. Fifty to start, five hundred to trust. A harness runs it in CI as a
required check, in cost order, so the cheap definitive checks reject before you pay for a judge:
Two rules make it honest. **Report per slice, never overall**: SkyWays' prompt v7 lifted same-day
cases by three points and dropped refunds by four, the overall number rose, and the per-slice gate
rejected it. **Report the lower bound, never the score**: codeshare scored 412 of 500, 82.4% against a
bar of 80, but the lower bound was 79.1%, so the slice was not yet proven and owed more cases.
### Step 4 · Put an independent checker after the risky steps
Chained steps multiply: four steps at 90% each are right 66% of the time end to end. Keep the chain
short, then put a checker after each step where a wrong answer is expensive, and make it
**independent**: a different model or a fresh context with an adversarial brief. At SkyWays a
"review your answer before returning it" step changed no scores and raised the bill by a fifth,
because the model was grading its own work with its own reasoning still in view.
### Step 5 · Run the shadow before you run instead of it
The golden set proves the agent is right about cases *you chose*. A **shadow run** proves it agrees
with the live desk on *today's* traffic (the storm day, the partner outage) by deciding every case
and acting on none, for a window fixed in advance. Report agreement per slice, keep money actions
separate, and read every disagreement.
SkyWays cleared its threshold with 96% agreement over fourteen days against a 95% default. Inside
that 96%, the agent had disagreed with the desk on four of eleven refunds, which is why money
actions are never averaged into the headline.
## Where you'll use it
- **Every day of the build.** One bolt a day, integrated the same day, with the harness result for
its slice in the build log.
- **On every prompt, model or tool change** after launch: the harness is how a prompt edit is
reviewed, because a prompt is a deployable artefact.
- **Before any live traffic.** No agent switches on with nothing to compare against.
## Why it matters
P2 is where "it works" becomes a number someone can defend. Without the harness, a regression that
lifts the average ships; without the lower bound, a slice that merely got lucky ships; without the
shadow, the first real storm day is also the first test.
## Try it
A pull request changes the drafting prompt. The harness reports: same-day **88% → 90%** (n = 500,
bar 50%), codeshare **86% → 80%** (n = 500, bar 80%), refunds unchanged. The overall score rose.
**Should it merge?**
Show the answer
**No.** Codeshare was proven before (the lower bound of 86% on 500 cases is about 83%) and now it is
not: 80% sits exactly on the bar as a point estimate, but its lower bound on 500 cases is about 76%. The harness should reject the merge regardless of the rise in the overall score,
which is the easy, high-volume slice lifting the average over the hard one.