Skip to content

10.4 The Agentic Harness, Assembled

Step back and look at what's accumulated: CLAUDE.md and a second brain, Skills, connections, hooks, validation, permission policy, roles, and team templates. Together they form an agentic harness — part repository files, part user/machine/service environment. This lesson assembles the view, finds gaps, and separates what travels with the repo from what must be rebuilt safely.

What you will learn

  • See the harness as one system: what each layer contributes and how they interlock.
  • Audit any project's harness for gaps with the layer checklist.
  • Bootstrap a small harness onto a new project and measure the effort.

Builder principle

The model is rented; the harness is owned. Everything you've built since Chapter 5 is equity — this lesson is where you count it.

The full stack, one diagram

       THE AGENTIC HARNESS  (repo files + environment boundaries)
┌─────────────────────────────────────────────────────────────┐
│ KNOWLEDGE   CLAUDE.md · second brain · memory layers   (Ch.5)│  what's true here
│ CAPABILITY  Skills · commands                        (Ch.6-7)│  how we do things
│ REACH       MCP servers · CLIs · connection postures   (Ch.8)│  what we can touch
│ VALIDATION  harness checks · hooks at the seams        (Ch.9)│  what good means, enforced
│ POLICY      allow/ask/deny · trust boundaries      (Ch.8-9)  │  what's permitted
│ CREW        agent roles · team templates · contracts  (Ch.10)│  who does what
└─────────────────────────────────────────────────────────────┘
                            ▲
     repo layers travel; environment boundaries are reprovisioned

The property that makes this an architecture rather than a pile: reviewable policy and knowledge live in files, while environment boundaries are documented and provisioned separately. That yields three payoffs:

  1. Consistency — repository-scoped instructions and checks can be shared across sessions and lanes, while ports, data, credentials, user settings, and MCP state still need setup.
  2. Portability — clone the repo and its reviewed files travel. Credentials, sandboxes, service policy, user memory, and machine configuration deliberately do not.
  3. Reuse — reviewed corrections, checks, and contracts can help later tasks that share the same conditions. Measure reuse and maintenance cost rather than assuming compounding returns.

The audit

Grade any project — including today, yours — one question per layer:

Layer The question Red flag
Knowledge Would a fresh session know what's true here without being told? You're re-explaining in briefs
Capability Are the recurring processes packaged and firing? Same corrections, different sessions
Reach Does the agent touch what the work actually needs — no more? You're the courier again (8.1) — or ALLOW sprawl
Validation Can the agent catch its own defects in-loop? "Done!" without receipts
Policy Is your attention spent only on sharp gates? Rubber-stamping — or a DENY list still in your head
Crew Can work parallelize today if the task warrants? Every job runs single-lane by default

Score honestly: most projects are strong in two layers and hollow in two — usually whichever chapters were skimmed. The audit output is a punch list, and the punch list is this lesson's exercise.

Bootstrapping: a one-hour timebox

The real test of owning a system is standing it up fresh. New project, empty folder — the bootstrap sequence, and note that every step is a lesson you've done:

0-10 min   git init, README, CLAUDE.md v1 (5.2's five sections)
10-20      second-brain skeleton: docs/decisions.md, log.md (5.4)
20-30      harness tier 1 + the after-edit and session-end hooks (9.2-9.3)
30-40      policy: your standard three bands, copied from your last
           project and trimmed to this one (9.4)
40-50      connections this project needs, three-step check each (8.3)
50-60      crew: reviewer role in, team templates copied (10.1, 10.3)

This repeatable process is a candidate for a project-init Skill. Package it, test it on another throwaway project, and compare setup time and defects against the manual run. Keep the Skill only if the measured result justifies its maintenance.

Open your main project and walk the diagram. Two moves this week: run the audit and fix the weakest evidenced layer; then bootstrap a fresh throwaway project with the timebox. Record elapsed time, corrections, and anything that still required manual setup. Chapter 11 will show how to describe that evidence without promising a business outcome.

The work-relevant frame is: the harness is part of your team's agentic platform. Version repository pieces, provision environment controls, measure outcomes, and treat improvements as reviewed infrastructure work. Test whether it reduces rework and risk on your team's tasks rather than assuming the return.

Try it now

  1. Run the six-question audit on your main project. Write the scores in docs/log.md — a dated harness health check, the first of many.
  2. Fix the weakest layer this week (you have the exact lesson number to revisit — that's what the diagram's chapter tags are for).
  3. Bootstrap a fresh throwaway project with the hour sequence, then package it: the project-init Skill, tested 7.3-style.
  4. Journal the capability statement, one paragraph: what reviewed knowledge, checks, and connections does your harness add beyond a fresh tool installation?

Check your understanding

  • Name the six layers and each one's contribution, from memory.
  • Which harness layers travel in the repo, and which environment boundaries must be provisioned separately?
  • What's your project's weakest layer per the audit, and which chapter rebuilds it?
  • Why is project-init the "most meta" Skill?