# Teaching Script — Deep-Dive DD-01: Pi — The Minimal Baseline

**Course**: Master Course — Harness Engineering
**Deep-Dive**: DD-01 — Pi: The Minimal Baseline
**Duration**: ~30 minutes (spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome to deep-dive DD-zero-one, Pi: The Minimal Baseline. This is the reference thin harness, and it is the most important deep-dive in the curriculum — not because Pi is the best harness, but because Pi is the base architecture every subsequent course builds on, attacks, varies, or deploys. If you understand Pi, you understand the irreducible core every thicker harness varies on. Forty-five minutes. Let's go.

The numbers. Four tools — bash, read-file, write-file, search. A system prompt under one thousand tokens. About twelve hundred lines of TypeScript total. Pi is the harness you can read in an afternoon — and that legibility is the point. Do as little as possible in the harness; let the model do the work. The model is the one-point-six percent; Pi is the ninety-eight-point-four percent shrunk as small as it can go before it stops being a harness at all.

[SLIDE 2 — The thesis: Pi is the base architecture]

Here is the load-bearing claim for the whole curriculum. Pi is the base architecture every course in this curriculum builds on. Course Two-A builds security tools FOR it — the sandbox, the filesystem scope, the approval gate that Pi omits. Course Two-B ATTACKS it — the OWASP Agentic Security Top ten offensive procedures find Pi's trust-the-model posture by default. Course Three drops fine-tuned models INTO it — the loop is unchanged, the model inside it is different. Course Four deploys it at scale — the same eighty-line loop, replicated across a fleet, with the observability and state-checkpoint layers added on top.

So this is not a "warm-up" deep-dive. This is the reference reading. Everything after this assumes you have read Pi and understand why it is thin.

Two columns on the slide. What Pi IS: a deliberate architectural statement — the minimal harness. What Pi is NOT: production-grade across all dimensions. No sandbox, no memory, no state, no verification. Pi will score twenty-five out of sixty on the rubric, and that low score is the expected result for a deliberate thin harness — it reflects what Pi is NOT, not a failure of what Pi IS. Hold that distinction; the entire deep-dive turns on it.

[SLIDE 3 — The architecture: three jobs, minimal]

The architecture. Pi is the minimal expression of the three jobs every harness does — loop, tools, and safety. Three cards.

The loop. About eighty lines of TypeScript. A while-true around model-dot-complete, with two stop conditions out of the five from Module One-point-two: end-turn, when the model emits no tool call, and max-iterations, the hard cap that is the safety net. No lookahead, no planning, no reflection. This is the ReAct dumb-loop — the same shape as Module One's reference loop with every optional component stripped.

The tools. Four. Bash, read-file, write-file, search. Schema-first — each is a JSON schema with a name, description, and input schema. The Vercel finding from Module Two validates keeping it small: cutting eighty percent of tools IMPROVED selection accuracy. The minimum capable set is also the lowest-noise set.

Safety. The max-iterations guard and basic try-catch. That is it. No per-action approval gates. No sandbox beyond the OS process. Trust-the-model — Pi's permission model in three words.

And the callout at the bottom: every absent component is deliberate. No context manager, no memory, no sandbox, no verification, no structured observability. The absence IS the lesson. Pi shows you what the irreducible minimum looks like.

[SLIDE 4 — The 6-phase analysis: the 12-module audit]

Now the six-phase analysis from Module Zero-point-three, condensed into the twelve-module audit. The full table is on the slide; I will read the shape.

Pi scores high where the thin design is a strength. Module One, the execution loop, scores four out of five — the dumb-loop is correct for co-evolution. Module Two, tool design, scores five out of five — the four-tool set is correct for a personal assistant. Module Twelve, prompt assembly, scores five out of five — the ultra-thin prompt delegates to the model.

Pi scores low where the omissions are deliberate. Module Three, context, two out of five — no compaction. Module Four, memory, one out of five — ephemeral only. Module Seven, error handling, two out of five — minimal try-catch. Module Eight, state, one out of five — stateless. Module Eleven, observability, two out of five — console-log.

And Pi scores low where the safety absences make it unfit for untrusted input. Module Five, sandboxing, one out of five — blast radius equals host. Module Six, permission, two out of five — trust-the-model. Module Nine, verification, one out of five — ship and hope.

Total: twenty-five out of sixty. The callout is load-bearing: the rubric scores production-readiness across all dimensions. Pi is deliberately not that. The score reflects what Pi is NOT, not a failure of what Pi IS. A thick harness scores higher; Pi's value is elsewhere — the future-proof test, the legibility, the co-evolution.

[SLIDE 5 — Three decisions I agree with]

Three decisions in Pi I agree with. First, the four-tool set. Correct for a personal assistant. A fifth tool adds decision noise — the Vercel finding showed that cutting eighty percent of tools improved selection. The minimum capable set is the lowest-noise set. This is a noise-reduction strategy, not a limitation.

Second, the dumb-loop philosophy. Pi co-evolves with model upgrades. The future-proof test from Module One: does performance improve on model upgrade without harness changes? Pi passes by design — the dumb loop adds no cleverness that can rot. When the next model ships, Pi benefits for free. That is Pi's reason for being.

Third, the ultra-thin prompt, under one thousand tokens. It delegates to the model and does not fight capability growth. A thick prompt over-specifies behavior the model already handles, and it rots when the model upgrades — the future-proof test fails. Treat the thin prompt as the co-evolution mechanism it is.

[SLIDE 6 — Three decisions I would make differently]

Three decisions I would make differently. First, add a token-budget stop condition. Module One-point-two named five stop conditions; Pi implements two. Even a personal assistant can produce a runaway bill. A token budget is cheap to add and prevents the worst outcome — it is the cheapest missing stop condition.

Second, add structured per-turn logging. The eight-field payload from Module Ten is trivial to add and transforms debuggability. Pi's console-log is below the floor — it is un-debuggable on long sessions. You cannot fix what you cannot see.

Third, add basic compaction. Module Three. Pi relies on minimal tool output, but a long bash session can still rot context. A simple threshold-triggered summarizer would extend Pi's effective range significantly. And the callout: these three additions move Pi from "minimal baseline" to "minimal production" WITHOUT compromising its thinness. That is the fork worth making.

[SLIDE 7 — The security audit: trust-the-model's blast radius]

The security audit. Two cards.

Left card: blast radius equals the entire host. Bash is full shell access. Write-file is unrestricted. Search makes network calls. An attacker who compromises the Pi process can read the dot-ssh directory, write anywhere the process user can, and call any URL. No sandbox, no filesystem scope, no network allowlist.

Right card: indirect injection by design. Pi has no untrusted-content tagging. A file read via read-file that contains injected instructions enters context as raw content. The model may comply. Pi is vulnerable to indirect injection — OWASP ASI-zero-one — by design. It is a thin harness that trusts the model. This is the exact surface Course Two-B's SDD-B-zero-one offensive expansion lands on first.

The key finding: Pi is correct for a trusted single-user environment. It is incorrect for any multi-user, multi-tenant, or untrusted-input context. The absence of sandboxing, scoping, and tagging is a deliberate tradeoff for thinness — not an oversight, a use-case limitation. Read the OWASP checklist against Pi and every row Pi omits is a row where Pi's answer is "the model handles it." That answer is honest about the threat model and wrong the moment the input is untrusted.

[SLIDE 8 — How the curriculum threads through Pi]

Here is the curriculum threading. Four cards — one per subsequent course.

Course Two-A builds FOR Pi. Security Harnesses builds the layers Pi omits: the sandbox, the filesystem scope, the approval gate. Where Pi says "trust the model," Course Two-A says "here is what you add when you cannot." The Course Two-A deep-dives are Pi plus the missing safety layer, and their scores on Modules Five and Six are where they diverge from Pi's one and two.

Course Two-B attacks Pi. SDD-B-zero-one, the OWASP Agentic Security Top ten offensive expansion, reads Pi's trust-the-model posture as the default surface. No taint gate means ASI-zero-one goal-drift is trivial. No sanitizer means ASI-zero-seven output-as-input is trivial. No principal binding means ASI-ten inter-agent trust escalation is trivial. Pi is the un-hardened baseline every Course Two-B procedure is run against first.

Course Three drops a fine-tuned model INTO Pi's loop. The loop is unchanged — the future-proof test means the harness does not need to know the model changed. Course Three's contribution is INSIDE the model; Pi's contribution is the stable loop around it.

Course Four deploys Pi at scale. The same eighty-line loop, replicated across a fleet, with the observability and state-checkpoint layers Course Four adds on top. Pi is the unit of deployment.

Read Pi once, here. You will refer back to it in every subsequent course.

[SLIDE 9 — Anti-patterns]

Four anti-patterns.

First, "Pi scores twenty-five out of sixty, so it is a bad harness." The score is the expected result for a deliberate thin harness. The rubric scores production-readiness across all dimensions; Pi is deliberately not that. Read the score alongside the use case. A twenty-five-out-of-sixty harness that is correct for personal-assistant-in-trusted-environment is a better fit than a fifty-five-out-of-sixty harness that brings enterprise machinery to a task that does not need it.

Second, "Pi has no sandbox — add one and it is production-ready." Adding a sandbox changes the threat model Pi was designed for. Adding a sandbox WITHOUT also adding scoping, approval gates, and observability gives you the cost of the sandbox without the benefit. If you need a sandbox, you need the full security layer — Course Two-A — not just one component. Fork Pi, but fork it coherently.

Third, "the thin prompt is lazy engineering." The under-one-thousand-token prompt is deliberate delegation to the model. A thick prompt over-specifies behavior the model already handles and rots when the model upgrades — the future-proof test fails. Treat the thin prompt as the co-evolution mechanism it is. Add prompt content only when the model demonstrably fails without it, and remove it when the model outgrows it.

Fourth, "the four tools are too few — add more for capability." The Vercel finding: cutting eighty percent of tools improved selection accuracy. A fifth tool adds decision noise. Keep the toolset minimal. If a new capability is needed, prefer composing the existing four tools over adding a fifth. The four-tool philosophy is a noise-reduction strategy, not a limitation.

[SLIDE 10 — What you can now do]

You can now apply the six-phase methodology to Pi and produce a scored analysis card with file-line evidence. You can defend Pi's thin-harness design as correct for its use case, not a deficiency — the load-bearing distinction. You can score Pi on the twelve-module rubric and explain why a low absolute score is the expected result for a deliberate thin harness. You can write the Architect's Verdict and the MLSecOps note in the canonical template. You can use Pi as the benchmark — every subsequent deep-dive asks "how much thickness does X add, and why?" And you can articulate the three decisions Pi makes that every thicker harness should justify deviating from.

The lab asks you to re-score Pi against the twelve-module rubric with the full Modules One through Twelve lens, trace one tool call through the seven-step dispatch, and justify the three changes you would make if you forked Pi toward "minimal production." If you have already done the Module Zero-point-one lab — reading Pi's source in thirty minutes — do it again now with the scoring sheet as your reference. Your second-pass scoring should be more nuanced than your first, especially on security and observability.

Next, deep-dive DD-zero-two: Aider, the Git-Native Pair Programmer. Aider is the first harness to the right of Pi on the thickness spectrum — it adds git-native edit semantics and a structured diff workflow on top of Pi's minimal loop. The comparison question for the whole deep-dive: how much thickness does Aider add, and why? That question originates here, with Pi as the baseline.

---

*End of deep-dive DD-01. Duration: approximately thirty minutes at one-hundred-forty words per minute.*