Pi: The Minimal Baseline
Deep-Dive DD-01 · Harness Engineering Master Course
45 minutes · The reference thin harness — the irreducible core every other deep-dive compares against
4 tools, a <1k-token system prompt, ~1,200 lines of TypeScript. Do as little as possible in the harness; let the model do the work. The thinness IS the design.
Deep-Dives
The thesis — Pi is the base architecture
Pi is the base architecture every course in this curriculum builds on. Course 2A builds security tools FOR it. Course 2B ATTACKS it. Course 3 drops fine-tuned models INTO it. Course 4 DEPLOYS it at scale. Understand Pi and you understand the irreducible core every thicker harness varies on.
What Pi IS
A deliberate architectural statement: the minimal harness. ~80-line loop, 4 tools, <1k prompt, trust-the-model. The model is the 1.6%; Pi is the 98.4% shrunk as small as it can go.
What Pi is NOT
Production-grade across all dimensions. No sandbox, no memory, no state, no verification. The low score (25/60) reflects what Pi IS NOT, not a failure of what Pi IS.
The architecture — three jobs, minimal
LOOP
~80 lines
ReAct dumb-loop. 2 of 5 stop conditions (end_turn + max-iter). No lookahead, no planning, no reflection.
TOOLS
4 tools
bash, read_file, write_file, search. Schema-first. The Vercel finding validates keeping it small.
SAFETY
max-iter + try/catch
That's it. No sandbox, no approval gate, no tagging. Trust-the-model.
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.
The 6-phase analysis — the 12-module audit
| Module | Pattern | Score | Tradeoff accepted |
|---|
| M1 Loop | ReAct dumb-loop | 4/5 | error compounding; no lookahead |
| M2 Tools | 4-tool schema-first | 5/5 | less extensibility (correct for use case) |
| M3 Context | none | 2/5 | context rot on long sessions |
| M4 Memory | ephemeral only | 1/5 | no multi-session |
| M5 Sandbox | none (OS process) | 1/5 | blast radius = host |
| M6 Permission | trust-the-model | 2/5 | no per-action gates |
| M7 Errors | minimal try/catch | 2/5 | no taxonomy; retries possible |
| M8 State | none (stateless) | 1/5 | every interruption = restart |
| M9 Verification | none (ship and hope) | 1/5 | no quality gate |
| M11 Observability | console.log | 2/5 | un-debuggable on long sessions |
| M12 Prompt | ultra-thin (<1k) | 5/5 | less explicit behavior control |
TOTAL: 25/60. The expected score for a deliberate thin harness. The rubric scores production-readiness across all dimensions; Pi is deliberately not that. The score reflects what Pi IS NOT.
Three decisions I agree with
The 4-tool set. Correct for a personal assistant. A 5th tool adds decision noise — the Vercel finding (cut 80% of tools, selection improved). The minimum capable set is the lowest-noise set.
The dumb-loop philosophy. Co-evolves with model upgrades. The future-proof test: does performance improve on model upgrade without harness changes? Pi passes by design — it adds no cleverness that can rot.
The ultra-thin prompt (<1k tokens). Delegates to the model; doesn't fight capability growth. A thick prompt over-specifies behavior the model already handles and rots on upgrade.
Three decisions I would make differently
Add a token-budget stop condition (M1.2). Even a personal assistant can produce a runaway bill. Cheap to add; prevents the worst outcome. Pi implements 2 of 5 stop conditions; this is the cheapest missing one.
Add structured per-turn logging (M10). The 8-field payload is trivial to add and transforms debuggability. Pi's console.log is below the floor — un-debuggable on long sessions.
Add basic compaction (M3). A long bash session can still rot context. A simple threshold-triggered summarizer extends Pi's effective range without compromising thinness.
These three move Pi from minimal baseline to minimal production without compromising its thinness.
The security audit — trust-the-model's blast radius
Blast radius = the entire host
bash = full shell. write_file = unrestricted. search = network. An attacker who compromises Pi can read ~/.ssh, write anywhere the process user can, and call any URL. No sandbox, no scoping, no allowlist.
Indirect injection by design
No untrusted-content tagging. A file read via read_file that contains injected instructions enters context as raw content. The model may comply. ASI01-vulnerable by design — the surface Course 2B 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 (M5), scoping (M5.3), and tagging (M2.4) is a deliberate tradeoff for thinness — not an oversight, a use-case limitation.
How the curriculum threads through Pi
C2A builds FOR it
Security Harnesses builds the layers Pi omits: sandbox, filesystem scope, approval gate. Pi says "trust the model"; C2A says "here is what you add when you cannot."
C2B attacks it
SDD-B01's OWASP ASI offensive expansion reads Pi's trust-the-model posture as the default surface. No taint gate = trivial ASI01 drift. No sanitizer = trivial ASI07. Pi is the un-hardened baseline.
C3 drops models INTO it
Fine-tuning swaps the model inside Pi's UNCHANGED loop. The future-proof test means the harness doesn't need to know. C3's contribution is inside the model; Pi's is the stable loop around it.
C4 deploys it at scale
Enterprise Platforms replicates the ~80-line loop across a fleet, adding the observability (M10) and state-checkpointing (M8) layers on top. Pi is the unit of deployment.
Read Pi once, here. You will refer back to it in every subsequent course.
Anti-patterns
"Pi scores 25/60, so it is a bad harness." The score is the expected result for a deliberate thin harness. The rubric scores production-readiness; Pi is deliberately not that. Read the score alongside the use case.
"Pi has no sandbox — add one and it is production-ready." Adding a sandbox without the full security layer gives you the cost without the benefit. If you need a sandbox, you need Course 2A's whole stack, not one component.
"The thin prompt is lazy engineering." The <1k prompt is deliberate delegation. A thick prompt over-specifies and rots on upgrade. Treat the thin prompt as the co-evolution mechanism it is.
"The 4 tools are too few — add more." The Vercel finding: cutting 80% of tools IMPROVED selection. The 4-tool philosophy is a noise-reduction strategy, not a limitation.
What you can now do
- Apply the 6-phase methodology to Pi and produce a scored card with file:line evidence.
- Defend Pi's thin-harness design as correct for its use case, not a deficiency.
- Score Pi (/60) and explain why a low absolute score is the expected result for a deliberate thin harness.
- Write Pi's Architect's Verdict and MLSecOps note in the canonical template.
- Use Pi as the benchmark — every subsequent deep-dive asks "how much thickness does X add, and why?"
- Articulate the three decisions Pi makes that every thicker harness should justify deviating from.
The lab: re-score Pi against the 12-module rubric with the full Modules 1–12 lens, trace one tool call through the 7-step dispatch, and justify the three changes you would make if you forked Pi toward "minimal production."
Next: DD-02 — Aider: The Git-Native Pair Programmer