Phase 4: Harness Engineering · 50 min · Claude Code · Python

Building a Harness for Your Product

The harness gets a spec too — the same discipline you applied to the product in Orbit 1, now applied to how the agent is allowed to build it.

Hiring signal: A written harness spec — not just an implemented harness — is evidence you can communicate agent-safety and reliability decisions to a team, which is exactly what a lead or senior engineer is expected to produce.

What you will learn

Distinguish a product spec (what the product does) from a harness spec (how the agent is allowed to build and maintain it)
Design concrete decisions for each of the six harness components for a real product
Justify a tool-access decision based on what the product actually touches (e.g. user-uploaded files, payment data)
Generate and validate a harness specification document for your course-long product

Introduction

Building a Harness for Your Product

Marcus's podcast show-notes tool now processes user-uploaded audio files, calls a third-party transcription API, and writes generated show notes back to a shared content database other tools also read from. He's implemented pieces of a harness — a CLAUDE.md, some tests — but when a teammate asks "can the agent delete an uploaded file if transcription fails, or does that need approval first?", Marcus realizes he never actually decided that. It was never written down, so it was never really decided — it just happened to work a certain way in the code, which is exactly the spec-versus-implementation problem from Orbit 1, showing up again one layer up: at the level of the harness itself, not the product.

The harness spec is a different document than the product spec

Your product spec, from c12-01, describes what the product does: acceptance criteria, constraints, test cases for the feature itself. The harness spec describes something different: how the agent is allowed to build and operate on it — which rules constrain its behavior, which skills it can draw on, which tools it can call and under what scope, which tests gate any change before it ships, and which actions require a human to say yes first. These aren't the same questions. "Stacked discounts must never produce a negative price" is a product-spec acceptance criterion. "The agent may modify pricing logic files but may not directly execute a database migration without approval" is a harness-spec decision. Confusing the two — writing tool-access rules into the product spec, or acceptance criteria into the harness spec — makes both documents harder to use for their actual purpose.

The harness spec answers a different "what if" than the product spec
Product spec: "what if a user stacks three discounts — what should the price be?" Harness spec: "what if the agent, mid-generation, decides deleting a file would fix a bug — is it allowed to, or does that need a human first?" Both are real questions a mature product needs answered. Only one of them belongs in the file describing product behavior.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Working through the six components for a real product, The harness spec as a living document, Avoiding generic policy language, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

Agent