Pi: The Minimal Baseline
What you get with 4 tools and a <1,000-token system prompt. Pi is the reference thin harness — every other deep-dive in the curriculum compares against it.
Pi is the base architecture every course in this curriculum builds on. Course 2A builds security tools FOR it (the sandbox, scope, approval gate it omits). Course 2B ATTACKS it (the OWASP ASI offensive procedures find its trust-the-model posture by default). Course 3 drops fine-tuned models INTO its unchanged loop (the future-proof test makes the swap seamless). Course 4 DEPLOYS it at scale. Understand Pi and you understand the irreducible core every thicker harness varies on.
Pi's thin-harness design is correct for its use case, not a deficiency. The 25/60 rubric score is the expected result for a deliberate thin harness — the rubric scores production-readiness across all dimensions, and Pi is deliberately not that. The score reflects what Pi IS NOT (the deliberate omissions: sandbox, memory, state, verification), not a failure of what Pi IS (the irreducible core: loop, tools, thin prompt, co-evolution).
The three decisions Pi makes are the baseline every thicker harness should justify deviating from: the 4-tool set, the dumb-loop philosophy, and the ultra-thin prompt. The 4-tool set is the minimum capable set and the lowest-noise set (the Vercel finding). The dumb-loop co-evolves with model upgrades (the future-proof test). The <1k prompt delegates to the model and does not fight capability growth.
The correct fork adds infrastructure, not cleverness. The three 'minimal production' changes (token budget, per-turn observability, basic compaction) close scored gaps WITHOUT adding model-specific lookahead/planning/reflection (so the future-proof test still passes) and WITHOUT changing the threat model (so thinness is preserved). Contrast: 'just add a sandbox' changes the threat model without the supporting layer — the cost without the benefit.