Leanpub Header

Skip to main content
Go to Leanpub.com

Harness Engineering (The Course)

Building Reliable Workflows Around Non-Deterministic Agents

The instructor has published 100% of this course.Last updated on 2026-11-03
Ian Johnson

This course teaches harness engineering as a discipline. Not magic prompts. Not vendor tricks. Engineering practice applied to a new substrate.

Minimum price

$129

$179

You pay

Author earns

$

Also available for 1 course credit with a Learner Membership

PDF
EPUB
WEB
About

About

About the Course

Agents are non-deterministic by design. Same prompt, two runs, two outputs. That fact is not going away, and no model upgrade will fix it. The fix is structural. The harness, the layered set of files, tools, gates, and conventions around the agent that narrows the band of outputs to one you can ship. Reliability is not determinism. Reliability is "the band of outputs we get is acceptable, observable, and recoverable."

This course teaches harness engineering as a discipline. Not magic prompts. Not vendor tricks. Engineering practice applied to a new substrate. The learner builds the project harness first: tests, pre-commit gates, rule files, skills, hooks. Then the team harness, where contracts replace tickets and three touchpoints replace mid-flight approvals. Then the organization harness, where rule packs are versioned dependencies that teams consume rather than copy. Then the maintenance discipline (two flywheels, learning and pruning) that keeps any of it honest as the codebase moves underneath it.

The case studies are tools the author shipped along the way and learned from in public. Bridle taught the maintenance flywheels. Sellier taught that prescriptive starter kits adopt faster than build-your-own toolkits. Intent-driven-delivery taught that the team layer can be reified instead of talked about. Keystone is the synthesis. The chapter on it includes what the author got wrong, not only what shipped.

Share this course

Instructor

About the Instructor

Ian Johnson

Ian Johnson is a staff engineer at Parento, where he runs the engineering team's adoption of AI coding agents and the harness work that keeps that adoption from breaking in production. He owns and operates Fulcorum, a video learning platform that teaches agentic engineering. He wrote five open-source projects that support reliable AI output: Keystone, Open Refinery, Sigma, Ghola, and Gauge. He has been writing about this work at blog.tacoda.dev since 2024 via Medium and the DEV Community. He lives outside Austin with his family.

Material

Course Material

  • Preface — None of This Is Mine

  • Introduction — Constraint Engineering, Named

  • The argument in one paragraph

  • Exercise 1

  • How the book is structured

  • Where the evidence comes from

  • A note on Claude Code as the working example

  • The patterns aren’t about code

  • Exercise 2

  • Scope and sources

  • How to read it — by use-case

  • Quiz 1

    3 attempts allowed

  • Part I — Foundations

  • Lesson 1 — The Agent Is Already in Your Codebase

  • A Tuesday with the agent and a Friday with the same agent

  • Exercise 3

  • The naive response and why it breaks

  • Exercise 4

  • Why the book is structured around the repo

  • Exercise 5

  • The repo audit, in concrete terms

  • Exercise 6

  • The one-page repo audit

  • Exercise 7

  • Quiz 2

    3 attempts allowed

  • Lesson 2 — Old Principles, New Substrate

  • Exercise 8

  • The agent did not invent any of this

  • Exercise 9

  • The amplification thesis

  • Exercise 10

  • Two pressures the canon now has to absorb

  • Exercise 11

  • Why “stronger standards” is the wrong slogan

  • Exercise 12

  • I did not invent these standards

  • Where the canon lands in this book

  • The canon-to-charter map

  • Quiz 3

    3 attempts allowed

  • Lesson 3 — The Reliability Problem (and Why Determinism Is the Wrong Goal)

  • The model is non-deterministic, and that part is not a defect

  • Exercise 13

  • Reliability is not determinism

  • Exercise 14

  • The three reliability levers

  • Narrow the input

  • Narrow the output

  • Narrow the recovery

  • Exercise 15

  • The levers are filters; reliability is what survives them

  • Exercise 16

  • Determinism belongs in the workflow

  • Exercise 17

  • What this course is not

  • None of this is original to this book

  • The claim, made falsifiable

  • Exercise 18

  • Reading an unreliable run

  • Exercise 19

  • Quiz 4

    3 attempts allowed

  • Lesson 4 — Charter and Harness: What Each One Is

  • The charter: what you author

  • Exercise 20

  • The harness: the engine that applies it

  • Exercise 21

  • What’s in each box

  • Exercise 22

  • Sort your own repo

  • Quiz 5

    3 attempts allowed

  • Lesson 5 — Harness and Charter: The Boundary

  • Exercise 23

  • The machine: charter -> harness -> model -> result

  • Exercise 24

  • The standard: the charter

  • The line

  • Exercise 25

  • The case that looks like an exception

  • Exercise 26

  • Where context and the loop sit

  • Exercise 27

  • The word, and where I had it pointed

  • Exercise 28

  • Why the seam is worth the trouble

  • Exercise 29

  • The card

  • Exercise 30

  • Quiz 6

    3 attempts allowed

  • Lesson 6 — Taxonomy: The Seven Words and the One Test That Sorts Them

  • Exercise 31

  • The one test

  • Exercise 32

  • The seven words

  • Exercise 33

  • The symmetry

  • Exercise 34

  • What is neither

  • Exercise 35

  • How to read the rest of the book

  • The artifact: the classifier card

  • Exercise 36

  • Quiz 7

    3 attempts allowed

  • Lesson 7 — The Repo as a Behavioral System

  • Exercise 37

  • Three classes of signal

  • Exercise 38

  • Why instruction loses to imitation

  • Exercise 39

  • The repo is the environment

  • Exercise 40

  • A worked example

  • Why each channel matters on its own

  • Exercise 41

  • What this means for where to invest

  • Exercise 42

  • Repo audit

  • Exercise 43

  • Quiz 8

    3 attempts allowed

  • Lesson 8 — The Charter’s Layers and the Reliability Levers

  • Exercise 44

  • The charter has layers

  • Exercise 45

  • Concentric, not stacked

  • Exercise 46

  • The litmus test for placement

  • Exercise 47

  • The three reliability levers, restated

  • The layer-by-lever grid

  • The layer × concern matrix

  • Exercise 48

  • The policy layer does not have to be one

  • Exercise 49

  • Concrete failure modes by layer

  • Exercise 50

  • How the rest of the book uses the grid

  • The blank grid, ready to copy

  • Quiz 9

    3 attempts allowed

  • Lesson 9 — Objections

  • “The models will eat this”

  • Exercise 51

  • “This is platform engineering with a new coat of paint”

  • Exercise 52

  • “Context engineering already names this”

  • Exercise 53

  • “Hand-authored charters will be compiled away”

  • Exercise 54

  • The ledger

  • Quiz 10

    3 attempts allowed

  • Lesson 10 — Related Work: Where This Sits

  • AGENTS.md: the file the field agreed on

  • Exercise 55

  • Harness engineering at Thoughtworks: the same name, independently

  • Exercise 56

  • Prompt engineering and context engineering: the supplied-versus-authored cut

  • Exercise 57

  • Platform engineering: the nearest older sibling

  • Exercise 58

  • DORA and Accelerate: the measurement standard not yet met

  • Exercise 59

  • SRE: error budgets become gate budgets

  • Exercise 60

  • MLOps and AI engineering: the other axis

  • Exercise 61

  • DSPy: the compiler objection

  • Exercise 62

  • The map on one card

  • Quiz 11

    3 attempts allowed

  • Part II — Authoring the Charter

  • Lesson 11 — The Instruction Layer

  • Exercise 63

  • The file read on every turn

  • Length

  • Three scopes

  • How the file fails

  • Ownership and cadence

  • Exercise 64

  • Quiz 12

    3 attempts allowed

  • Lesson 12 — Rule Files: Iron Laws, Golden Rules, and Preferences

  • Exercise 65

  • Three tiers, one file

  • Exercise 66

  • Scope and traces

  • Exercise 67

  • The cardinal sin

  • Exercise 68

  • Where rules come from, and where they go

  • Exercise 69

  • Rules bound a move; a command or a skill walks a job

  • Exercise 70

  • Quiz 13

    3 attempts allowed

  • Lesson 13 — The Corpus and the Docs

  • The corpus

  • Five layers

  • Lazy loading

  • Which layer lies loudest

  • Ontologies, briefly

  • Two maps, one word

  • Exercise 71

  • Docs are corpus

  • The README contract

  • Architecture decision records

  • Two sorting frames

  • Stale docs and the doc flywheel

  • Exercise 72

  • Quiz 14

    3 attempts allowed

  • Lesson 14 — Cascade, Scope, and Inheritance

  • Three rules resolve the cascade

  • Exercise 73

  • Memory files: the cascade in one slice

  • Exercise 74

  • Locks

  • Exercise 75

  • The resolved view

  • Exercise 76

  • Required declarations

  • Exercise 77

  • Three failure modes, all structural

  • Exercise 78

  • A worked example

  • Exercise 79

  • Quiz 15

    3 attempts allowed

  • Lesson 15 — Ontologies: One Meaning Per Term

  • Exercise 80

  • The agent hears only what is written

  • Exercise 81

  • The glossary as charter artifact

  • Exercise 82

  • Ubiquitous language for an absent reader

  • Exercise 83

  • The ontology the agent believes

  • Exercise 84

  • What holds between the terms

  • Exercise 85

  • Terms rot

  • Exercise 86

  • Quiz 16

    3 attempts allowed

  • Lesson 16 — Memory and the Token Budget

  • Three kinds, and only one of them survives

  • Exercise 87

  • The conversion is the discipline

  • Exercise 88

  • The agent’s memory is a budget, not a vault

  • Exercise 89

  • Where it lives in the layers

  • Exercise 90

  • The window is working memory, and it costs you every turn

  • Exercise 91

  • The number that matters is not the ceiling

  • Exercise 92

  • Three tiers

  • Exercise 93

  • Lazy-load by region

  • Two sample baselines

  • Exercise 94

  • The cost of bloat

  • Exercise 95

  • The pre-flight check

  • Exercise 96

  • Three rules for keeping the budget honest

  • Exercise 97

  • Compact with focus

  • Exercise 98

  • Constraint loss: the failure compaction causes

  • Exercise 99

  • Prompt patterns that respect the budget

  • Exercise 100

  • A note on context-reduction tooling

  • Exercise 101

  • The artifact

  • Exercise 102

  • Quiz 17

    3 attempts allowed

  • Part III — Code, Tools, and Checks

  • Lesson 17 — The Legible Codebase: Architecture and Seams

  • Exercise 103

  • Architecture as Communication

  • Dependencies point inward

  • Prefer deep modules

  • Layering as a behavioral guarantee

  • Same feature, two repos

  • What the agent reads in architecture

  • Exercise 104

  • Explicit Seams and Bounded Contexts

  • What a seam is, and why the agent uses them

  • Bounded contexts, operationalized

  • The god module

  • Actions and policies inside a context

  • Ports and adapters inside one repo

  • When boundaries collapse

  • Exercise 105

  • The artifacts

  • Architecture-legibility checklist

  • The seam catalog

  • Exercise 106

  • Quiz 18

    3 attempts allowed

  • Lesson 18 — The Legible Codebase: Names and Boring Code

  • Naming as a Behavioral Signal

  • Names are constraints on the next token

  • Naming conventions as priors

  • Vocabulary as identity

  • Domain language

  • Aggressive renames over apologetic comments

  • Anti-patterns to notice

  • Exercise 107

  • Boring Code: Predictability over Cleverness

  • No magic

  • Boring is sophistication moved

  • The agent thrives on boring code

  • Cleverness traps the agent amplifies

  • Exercise 108

  • The artifacts

  • The naming audit

  • The boring-code lift

  • Exercise 109

  • Quiz 19

    3 attempts allowed

  • Lesson 19 — Tests and Gates

  • Exercise 110

  • Tests are guides and sensors

  • Exercise 111

  • TDD as the agent loop

  • Exercise 112

  • The test pyramid still holds

  • Exercise 113

  • Characterization tests before legacy refactors

  • Exercise 114

  • Output-based tests beat implementation-based tests

  • Exercise 115

  • Mock the unmanaged, run the managed

  • Exercise 116

  • Flaky tests are charter failures

  • Exercise 117

  • A make-this-testable recipe

  • Exercise 118

  • Tests are coverage; gates are speed

  • Exercise 119

  • The thirty-second budget

  • Exercise 120

  • What runs on the fast layer

  • Exercise 121

  • Two gates, two jobs

  • Exercise 122

  • Hook hygiene

  • Exercise 123

  • The slow ratchet

  • Exercise 124

  • Scoring code health as a sensor

  • Exercise 125

  • The happy path is verified; QA moves to the edges

  • Exercise 126

  • The artifact

  • Quiz 20

    3 attempts allowed

  • Lesson 20 — Declaring Tools: Skills, Sub-Agents, Hooks, Plugins, and MCP

  • What a tool is

  • Exercise 127

  • Contract in the repo, reach in the world

  • Exercise 128

  • Minimum capability and the ladder

  • Exercise 129

  • The tool inventory

  • Exercise 130

  • Skills: reusable multi-phase workflows

  • Exercise 131

  • Sub-agents: specialists with refusal scopes

  • Exercise 132

  • Hooks: declared to the charter, executed by the harness

  • Exercise 133

  • Plugins: behaviors that travel

  • Exercise 134

  • MCP: typed bridges to the world

  • Exercise 135

  • Quiz 21

    3 attempts allowed

  • Lesson 21 — Bounding Tools

  • Exercise 136

  • What the agent actually reads

  • Exercise 137

  • Names and signatures

  • Exercise 138

  • Output shape and error feedback

  • Exercise 139

  • Idempotency, and saying so

  • Exercise 140

  • Description text as a contract

  • Exercise 141

  • Every tool is a capability grant

  • Exercise 142

  • Permission scopes, named

  • Exercise 143

  • Permission posture as a productivity lever

  • Exercise 144

  • Destructive operations

  • Exercise 145

  • Secret handling

  • Exercise 146

  • Sandboxing is a declared policy

  • Exercise 147

  • Rate limits as a safety mechanism

  • Exercise 148

  • Audit logs that read like a forensic record

  • Exercise 149

  • What the safety layer is not

  • Exercise 150

  • The artifact — the tool-safety matrix

  • Exercise 151

  • Quiz 22

    3 attempts allowed

  • Lesson 22 — Verifying the Charter Itself

  • Exercise 152

  • The charter is code; verify it like code

  • Exercise 153

  • Pre-commit safeguards for the charter’s own files

  • Exercise 154

  • Code Health for the charter

  • Exercise 155

  • A failing safeguard is not negotiated away

  • Exercise 156

  • The verify, review, ship loop

  • Exercise 157

  • The charter verifies itself

  • Exercise 158

  • The charter pre-flight

  • Exercise 159

  • The verify skill

  • Exercise 160

  • Quiz 23

    3 attempts allowed

  • Lesson 23 — Retrofitting a Charter into a Repo That Fights You

  • Exercise 161

  • There is no single truth to describe

  • Exercise 162

  • Delete the lies before you write the truth

  • Exercise 163

  • Describe the dominant pattern, not the aspirational one

  • Exercise 164

  • Give the agent a rule for living in a mixed codebase

  • Exercise 165

  • Bound the charter’s authority to a seam you understand

  • Exercise 166

  • Characterize before you let the agent change what you cannot describe

  • Exercise 167

  • Ship the small honest charter and let the flywheel grow it

  • Exercise 168

  • The artifact: a retrofit charter starter

  • Quiz 24

    3 attempts allowed

  • Lesson 24 — Reading an Unfamiliar Codebase with the Agent

  • Exercise 169

  • The claim has to carry a citation

  • Exercise 170

  • The imitation trap, seen from the other side

  • Exercise 171

  • The reconnaissance loop

  • Exercise 172

  • A charter turns reconnaissance into orientation

  • Exercise 173

  • Reading is read-only

  • Exercise 174

  • The artifact: a reconnaissance skill

  • Exercise 175

  • Quiz 25

    3 attempts allowed

  • Part IV — Scaling and Operating the Charter

  • Lesson 25 — The Org Charter

  • Exercise 176

  • Two scopes, two masters

  • Exercise 177

  • What earns the org layer

  • Exercise 178

  • The rule of three

  • Exercise 179

  • What does not belong

  • Exercise 180

  • Consumed as a dependency

  • Exercise 181

  • One port spec, many adapters

  • Exercise 182

  • Three artifacts, three lifespans

  • Exercise 183

  • Principles travel; idioms stay home

  • Exercise 184

  • One repo, many agents

  • Exercise 185

  • Where a team is on the curve

  • Exercise 186

  • The artifact

  • Exercise 187

  • Quiz 26

    3 attempts allowed

  • Lesson 26 — The Charter as a Queryable Service

  • Ask instead of carry

  • Exercise 188

  • Two halves: policy and context

  • Exercise 189

  • Why an MCP server is the right surface

  • Exercise 190

  • The tradeoff the service does not escape

  • Exercise 191

  • When to serve and when to compile

  • Exercise 192

  • The artifact

  • Quiz 27

    3 attempts allowed

  • Lesson 27 — Patterns and Anti-Patterns

  • Patterns — the shapes that work

  • Foundations and reliability levers

  • The repo layer — markdown and config

  • The codebase — design for legibility

  • Tools — extending agent capability

  • The team — delivery orchestrator

  • The organization — scaling behavior

  • Exercise 193

  • Anti-patterns — the shapes that fail

  • Instruction failures

  • Imitation failures

  • Feedback failures

  • Interface failures

  • Process failures

  • Exercise 194

  • The artifact — a printable cheat sheet

  • Quiz 28

    3 attempts allowed

  • Lesson 28 — Flywheels and Post-Mortems

  • Exercise 195

  • The two motions

  • Exercise 196

  • Learning, batched

  • Exercise 197

  • Pruning, audited

  • Exercise 198

  • How the catalog feeds the wheels

  • Exercise 199

  • Cadence

  • Exercise 200

  • The flywheel ledger

  • Exercise 201

  • Post-mortems: from incident to charter patch

  • Exercise 202

  • When to run a post-mortem

  • Exercise 203

  • Near-misses are free post-mortems

  • Exercise 204

  • The run has to be legible first

  • Exercise 205

  • Mining the logs for the failures nobody reported

  • Exercise 206

  • A short retrospective after every workflow

  • Exercise 207

  • The five recurring patterns

  • Exercise 208

  • Blameless, but for the charter

  • Exercise 209

  • The patch is structural

  • Exercise 210

  • The flywheel consumes the output

  • Exercise 211

  • The artifact

  • Exercise 212

  • Quiz 29

    3 attempts allowed

  • Lesson 29 — The Codebase That Gets Better With Use

  • The compounding claim

  • Exercise 213

  • The mechanism, in five moves

  • Exercise 214

  • The opposite mechanism, in the absence of discipline

  • Exercise 215

  • Measuring the compounding

  • Exercise 216

  • The cultural signal

  • Exercise 217

  • The quarterly health snapshot

  • Exercise 218

  • Quiz 30

    3 attempts allowed

  • Lesson 30 — Charter Evals

  • Exercise 219

  • The charter’s missing test suite

  • Exercise 220

  • What an eval is, precisely

  • Exercise 221

  • Two questions: capability evals and charter evals

  • Exercise 222

  • The protocol, in full

  • Exercise 223

  • Build the set from your own failures

  • Exercise 224

  • Scoring: deterministic, inferential, and human

  • Exercise 225

  • The numbers that matter

  • Exercise 226

  • Eval-driven charter development

  • Exercise 227

  • The connection to EFC

  • Exercise 228

  • Honest limits

  • Exercise 229

  • Artifact — a starter eval suite

  • Quiz 31

    3 attempts allowed

  • Lesson 31 — Charter Debt and Versioning

  • Exercise 230

  • The symptoms

  • Exercise 231

  • The boy-scout rule applies to the charter

  • Exercise 232

  • The debt ledger

  • Exercise 233

  • The weekly ledger

  • Exercise 234

  • What letting debt grow actually costs

  • Exercise 235

  • Debt versus the flywheels

  • Exercise 236

  • Comprehension debt is charter debt’s twin

  • Exercise 237

  • The artifact — a charter-debt ledger row

  • Exercise 238

  • The release bites back

  • Exercise 239

  • Why cadence is the answer to drift

  • Exercise 240

  • Forward-only, always

  • Exercise 241

  • Diff and ask

  • Exercise 242

  • Versioning semantics

  • Exercise 243

  • The release loop

  • Exercise 244

  • Changelog discipline

  • Exercise 245

  • The artifact — the CHANGELOG entry template

  • Exercise 246

  • Quiz 32

    3 attempts allowed

  • Lesson 32 — Modes and the Curator

  • Exercise 247

  • Pacing, not phasing

  • Exercise 248

  • Paired — the cadence for unknown ground

  • Exercise 249

  • Solo — the cadence for known ground

  • Exercise 250

  • Autopilot — the cadence for high-confidence stretches

  • Exercise 251

  • Modes are not skill levels

  • Exercise 252

  • Stepping up, stepping back

  • Exercise 253

  • Mode selection lives in the charter

  • Exercise 254

  • The rubric

  • Exercise 255

  • From author to curator

  • Exercise 256

  • Driver, conductor, orchestrator

  • Exercise 257

  • The work, named

  • Exercise 258

  • Pair-programming with a constrained partner

  • Exercise 259

  • Anti-patterns — what curation is not

  • Exercise 260

  • Why the framing matters culturally

  • Exercise 261

  • The curator’s daily rhythm

  • Exercise 262

  • What is not the curator’s job

  • Exercise 263

  • The artifact

  • Exercise 264

  • Quiz 33

    3 attempts allowed

  • Part V — Harness Engineering

  • Lesson 33 — What Harness Engineering Is

  • Agent = Model + Harness

  • Exercise 265

  • Two levels of harness

  • Exercise 266

  • The dark factory, and the lit one

  • Exercise 267

  • The five jobs

  • Exercise 268

  • When you actually need to build one

  • Exercise 269

  • When an AI product outgrows the API call

  • Exercise 270

  • The harness does not care where you sit

  • Exercise 271

  • The artifact: should you build a harness?

  • Exercise 272

  • Quiz 34

    3 attempts allowed

  • Lesson 34 — DAG or Loop: The Shape of Control Flow

  • Two shapes, one question

  • Exercise 273

  • A DAG is just composition

  • Exercise 274

  • When the graph earns a framework

  • Exercise 275

  • Branching: the path forks on a value

  • Exercise 276

  • Map-reduce: fan out wide, fold once

  • Exercise 277

  • Failure is an edge, not an exception

  • Exercise 278

  • The single edge that turns a DAG into a loop

  • Exercise 279

  • The double dovetail

  • Exercise 280

  • The symmetry worth naming

  • The artifact: a composable stage pipeline

  • Exercise 281

  • Quiz 35

    3 attempts allowed

  • Lesson 35 — Loop Engineering

  • Exercise 282

  • Two loops

  • Exercise 283

  • What loop engineering is

  • Exercise 284

  • The loop feeds itself, and its memory lives on disk

  • Exercise 285

  • Structured output: the feedback the loop routes on

  • Exercise 286

  • The outer loop: delegate to agents that carry the charter

  • Exercise 287

  • What it looks like in practice

  • Exercise 288

  • The orchestrator is a team, and Brooks already warned you

  • Exercise 289

  • Where it breaks, and how to stop it

  • Exercise 290

  • The artifact: a loop spec with the bounds built in

  • Exercise 291

  • The bug already had a name

  • Exercise 292

  • The orchestrator is a queue

  • Exercise 293

  • The primitives you already built by hand

  • Exercise 294

  • The queue does not replace the single loop

  • Exercise 295

  • Where the queue lives in the stack

  • The artifact: a queue spec

  • Exercise 296

  • Quiz 36

    3 attempts allowed

  • Lesson 36 — RAG: Retrieval as a Harness Job

  • Exercise 297

  • Fetch strategies, plural

  • Search the tree, or search an index

  • Exercise 298

  • The vector store, and why it is a harness job

  • Exercise 299

  • The corpus is the cache; retrieval is the fetch

  • Exercise 300

  • Assembly is a pipeline

  • Exercise 301

  • Three ways the supply chain fails

  • Exercise 302

  • Retrieval in the factory

  • Exercise 303

  • Measuring the supply chain

  • Exercise 304

  • The artifact: a retrieval policy

  • Exercise 305

  • Quiz 37

    3 attempts allowed

  • Lesson 37 — Security, Permissions, and Sandboxing

  • Exercise 306

  • Least privilege, per run

  • Exercise 307

  • Deny by default

  • Exercise 308

  • Production is a human gate

  • Exercise 309

  • The check is a wrapper, not a habit

  • Exercise 310

  • Fail closed

  • Exercise 311

  • Isolation for what the check can’t foresee

  • Exercise 312

  • Secrets live at the boundary

  • Exercise 313

  • Retrieved content is untrusted too

  • Exercise 314

  • Log every privileged call

  • Exercise 315

  • The artifact: a permission and sandbox config

  • Exercise 316

  • Quiz 38

    3 attempts allowed

  • Lesson 38 — Injection Inside the Grant

  • Exercise 317

  • The gate had nothing to refuse

  • Exercise 318

  • Where the instruction comes from

  • Exercise 319

  • Keep the grant tight — then keep going

  • Exercise 320

  • Separate the plan from the payload

  • Exercise 321

  • Spotlight what you cannot reduce

  • Exercise 322

  • Bound the decision, not just the capability

  • Exercise 323

  • Tripwires on the diff

  • Exercise 324

  • Exfiltration rides allowed channels

  • Exercise 325

  • Detection, because prevention leaks

  • Exercise 326

  • The honest limit

  • Exercise 327

  • The artifact: a merge gate the fleet cannot talk past

  • Exercise 328

  • Quiz 39

    3 attempts allowed

  • Lesson 39 — Model Selection and Routing

  • Exercise 329

  • Route the step, not the task

  • Exercise 330

  • The model is a seam, so routing is a policy over it

  • Exercise 331

  • Start cheap, escalate on failure

  • Exercise 332

  • A model version is a dependency — pin it

  • Exercise 333

  • Routing is a decision, and decisions can be wrong

  • Exercise 334

  • The artifact: a routing policy with an escalation ladder

  • Exercise 335

  • Quiz 40

    3 attempts allowed

  • Lesson 40 — Cost and Resource Control

  • Exercise 336

  • Every call costs three things

  • Exercise 337

  • The ceiling has to throw

  • Exercise 338

  • Poison items and attribution

  • Exercise 339

  • Routing and caching: paying less for the same answer

  • Exercise 340

  • Rate limits and backpressure

  • Exercise 341

  • When the ceiling moves up a layer

  • Exercise 342

  • Cost is a sensor on everything upstream

  • Exercise 343

  • What the spend buys

  • Exercise 344

  • The artifact: a budget config

  • Exercise 345

  • Quiz 41

    3 attempts allowed

  • Lesson 41 — Testing the Harness

  • Exercise 346

  • Test what the model doesn’t touch

  • Exercise 347

  • The model is a seam

  • Exercise 348

  • Routing tests: assert every branch, especially the one evals skip

  • Exercise 349

  • Bounds tests: prove the ceiling stops the loop

  • Exercise 350

  • Structured-output tests: prove the retry fires and the giving-up is real

  • Integration tests: prove resume does not repeat work

  • Determinism is a thing you engineer into the test

  • Exercise 351

  • What not to test

  • Exercise 352

  • The artifact: a harness test file

  • Exercise 353

  • Quiz 42

    3 attempts allowed

  • Lesson 42 — Building the Harness on a Framework

  • The account you need first

  • Exercise 354

  • The shape every version builds

  • LangChain

  • LangGraph

  • Deepagents

  • Pydantic AI

  • The three you may want instead

  • Exercise 355

  • Choosing, and not choosing

  • Exercise 356

  • Build vs buy, one layer up

  • Exercise 357

  • The artifact

  • Quiz 43

    3 attempts allowed

  • Lesson 43 — Framework Patterns and Structure

  • Exercise 358

  • LangGraph: control flow as a graph

  • Exercise 359

  • LangChain: output shape as a contract

  • Deepagents: decomposition made explicit

  • Pydantic AI: the contract between model and code

  • Exercise 360

  • The same benefit, four doors

  • The artifact

  • Quiz 44

    3 attempts allowed

  • Lesson 44 — Harness Concerns, Solved

  • Implementing tools

  • Structured output

  • Exercise 361

  • Bounded retries and error feedback

  • Exercise 362

  • Memory and the token budget

  • Exercise 363

  • Streaming

  • Sandboxing the tool surface

  • The artifact

  • Exercise 364

  • Quiz 45

    3 attempts allowed

  • Lesson 45 — Building a Coding Harness

  • The agent loop is the harness

  • Exercise 365

  • The tools the loop turns on

  • The gate closes the loop; the cap catches it

  • Fresh clone, sandboxed tools, PR out

  • The artifact

  • Quiz 46

    3 attempts allowed

  • Lesson 46 — Harness Evals

  • Two targets, one job

  • Exercise 366

  • A corpus is data

  • Exercise 367

  • A scorer is a function you pass in

  • Exercise 368

  • The runner is a map

  • Exercise 369

  • Gating on the number

  • Exercise 370

  • Offline and online

  • Exercise 371

  • The artifact: harness eval template

  • Exercise 372

  • Quiz 47

    3 attempts allowed

  • Part VI — Orchestration Engineering

  • Lesson 47 — Intent Contracts (and Why Vibe Coding Breaks at Team Scale)

  • Exercise 373

  • What vibe coding hides

  • Exercise 374

  • Narrow the input, at team scale

  • Exercise 375

  • Seven sections, every time

  • Exercise 376

  • Falsifiable matters

  • Exercise 377

  • Tag what is known

  • Exercise 378

  • Goal mode and debate mode

  • Exercise 379

  • The ticket is the contract

  • Exercise 380

  • Split the contract at Intake

  • Exercise 381

  • A context budget per contract

  • Exercise 382

  • What this discipline is borrowed from

  • Exercise 383

  • The honorable mention: spec-driven development

  • Exercise 384

  • The contract template

  • Exercise 385

  • Quiz 48

    3 attempts allowed

  • Lesson 48 — The Six Phases and Interrupts

  • Exercise 386

  • Why six

  • Exercise 387

  • A touchpoint at every phase boundary

  • Exercise 388

  • Each phase has an exit, and the exit is explicit

  • Exercise 389

  • The observability test for any gate

  • Exercise 390

  • The ticket is the contract

  • Exercise 391

  • What goes wrong without phase discipline

  • Exercise 392

  • A short note on tooling

  • Exercise 393

  • Interrupts: how agents ask

  • Exercise 394

  • Guessing is the failure mode

  • Exercise 395

  • The shape of an interrupt

  • Exercise 396

  • The shape of a resolution

  • Exercise 397

  • One question per interrupt

  • Exercise 398

  • The interrupt rate is a sensor on the charter

  • Exercise 399

  • Anti-patterns

  • Exercise 400

  • When the interrupt is the agent’s only honest move

  • Exercise 401

  • The inverse: when the human has to correct the agent

  • Exercise 402

  • The artifact

  • The phase-transition checklist

  • The interrupt template

  • Exercise 403

  • Quiz 49

    3 attempts allowed

  • Lesson 49 — Topology and the Daemon

  • Exercise 404

  • Three names, one system

  • Exercise 405

  • When a second agent earns its slot

  • Exercise 406

  • When the second agent does not earn its slot

  • Exercise 407

  • The four topology patterns

  • Exercise 408

  • Pipeline vs barrier: when stages have to wait

  • Exercise 409

  • Patterns for discovery work

  • Exercise 410

  • Two operational rules for any pattern

  • Exercise 411

  • Topology nodes meet the charter

  • Exercise 412

  • The daemon in the middle

  • Exercise 413

  • The sixty-second tick

  • Exercise 414

  • Fresh clones, every time

  • Exercise 415

  • Fire-and-forget dispatch

  • Exercise 416

  • The dispatch is one line, until it is not

  • Exercise 417

  • The operational surface

  • Exercise 418

  • A worked tick

  • Exercise 419

  • Quiz 50

    3 attempts allowed

  • Lesson 50 — Graph Engineering

  • The fourth floor

  • Exercise 420

  • Nodes do work; edges decide what runs next

  • Exercise 421

  • The theory is older than the tooling

  • Exercise 422

  • What is actually new is what goes inside the node

  • Exercise 423

  • Concerns, and the fix the field already shipped

  • Exercise 424

  • The anti-patterns

  • Exercise 425

  • When the graph is the wrong shape

  • Exercise 426

  • The artifact: a graph-or-not decision

  • Exercise 427

  • Quiz 51

    3 attempts allowed

  • Lesson 51 — The Orchestrator on a Framework

  • A node is a harness

  • Exercise 428

  • The frameworks, one altitude up

  • Why not one clever agent

  • Exercise 429

  • The artifact

  • Quiz 52

    3 attempts allowed

  • Lesson 52 — Orchestrator Patterns in a Framework

  • Supervisor and router

  • Fan-out and fan-in

  • Exercise 430

  • Pipeline

  • Hierarchy and teams

  • The same benefit, one floor up

  • The artifact

  • Quiz 53

    3 attempts allowed

  • Lesson 53 — Orchestrator Concerns, Solved

  • Shared state across agents

  • Exercise 431

  • Capping the fan-out

  • Exercise 432

  • Durability across a long run

  • Exercise 433

  • Human-in-the-loop, mid-topology

  • Observability across the fleet

  • Cost across the fleet

  • The artifact

  • Exercise 434

  • Quiz 54

    3 attempts allowed

  • Lesson 54 — Reducible Workflows: The DAG That Loops

  • The shape has a name: a reducible graph

  • Exercise 435

  • A single loop

  • Exercise 436

  • Nested loops: TDD

  • Exercise 437

  • Deeper nesting, and where it lives

  • Exercise 438

  • The reducible orchestrator

  • Exercise 439

  • The artifact: a reducible-workflow check

  • Exercise 440

  • Quiz 55

    3 attempts allowed

  • Lesson 55 — Beyond the Reducible Graph: State Machines, Choreography, and Sagas

  • When the process never ends: state machines

  • Exercise 441

  • When there is no orchestrator: choreography

  • Exercise 442

  • When you cannot just stop: sagas and compensation

  • Exercise 443

  • Which shape?

  • Exercise 444

  • Quiz 56

    3 attempts allowed

  • Lesson 56 — Orchestration Patterns

  • The orchestrator is a queue, not an agent

  • Exercise 445

  • The process is data, and there is more than one

  • Exercise 446

  • Bounded, recoverable work is canon, not invention

  • Exercise 447

  • Routing, failover, quotas

  • Exercise 448

  • Human attention is data

  • Exercise 449

  • Everything is a row

  • Exercise 450

  • When to split the agent

  • Exercise 451

  • The review, in one page

  • Exercise 452

  • Quiz 57

    3 attempts allowed

  • Lesson 57 — Dark Factories

  • Exercise 453

  • Where the human stands

  • Exercise 454

  • Sensors report, gates refuse

  • Exercise 455

  • The asymmetry: analyze freely, change under a signer

  • Exercise 456

  • Bounds are policy

  • Exercise 457

  • What the meter says

  • Exercise 458

  • Field notes

  • Exercise 459

  • What the dark cannot do

  • Exercise 460

  • The artifact: a lights-out readiness policy

  • Exercise 461

  • Quiz 58

    3 attempts allowed

  • Lesson 58 — Lights-On Factories

  • Exercise 462

  • The platform layer

  • Exercise 463

  • The autonomy ladder

  • Exercise 464

  • The frozen record

  • Exercise 465

  • Coverage and imitation surfaces

  • Exercise 466

  • Experiments in production

  • Exercise 467

  • What openness costs

  • Exercise 468

  • The openness config

  • Exercise 469

  • Quiz 59

    3 attempts allowed

  • Lesson 59 — Orchestrator Evals

  • Exercise 470

  • The unit of measure changes

  • Exercise 471

  • The failures live between the agents

  • Exercise 472

  • Two ways to run one

  • Exercise 473

  • The artifact: an orchestrator scorecard

  • Exercise 474

  • Quiz 60

    3 attempts allowed

  • Part VII — Cross-Cutting Concerns

  • Lesson 60 — From Tribal Knowledge to Deterministic Workflow

  • Exercise 475

  • The four rungs

  • Exercise 476

  • The direction is the point

  • Exercise 477

  • Maintaining the ladder against reality

  • Exercise 478

  • The work is the process, not the artifact

  • Exercise 479

  • The artifact

  • Quiz 61

    3 attempts allowed

  • Lesson 61 — Cross-Cutting: The Themes That Hold on Both Sides

  • Exercise 480

  • The three levers are substrate-independent

  • Exercise 481

  • Constraints come in layers, and the layers have precedence

  • Exercise 482

  • Everything accrues debt

  • Exercise 483

  • Everything runs against a finite budget

  • The model’s output is untrusted, so validate at the boundary

  • Exercise 484

  • Measurement over assertion

  • Exercise 485

  • Feedback loops keep both honest

  • Exercise 486

  • Reach for the heavier substrate late

  • Where this hands off

  • The artifact: the cross-cutting audit

  • Exercise 487

  • Quiz 62

    3 attempts allowed

  • Lesson 62 — The Layers a Business Governs

  • The stack is taller than the code

  • Exercise 488

  • Governance is the org charter, grown up

  • Govern before, observe after

  • Exercise 489

  • The hardest question is not whether the rules were followed

  • Exercise 490

  • Authority: the slot the mechanism cannot fill

  • Exercise 491

  • Purpose: the layer that makes the rest worth building

  • Exercise 492

  • The same discipline, all the way up

  • Exercise 493

  • Quiz 63

    3 attempts allowed

  • Epilogue — Containment, Not Completeness

  • The harness does not escape it either

  • Exercise 494

  • Sensors outside the rules

  • Exercise 495

  • What does not change is consistency

  • Exercise 496

  • Quiz 64

    3 attempts allowed

  • Appendix A — Vocabulary Reference

  • Foundations and Taxonomy

  • Exercise 497

  • The Charter: Files That Govern

  • Exercise 498

  • The Codebase

  • Exercise 499

  • The Delivery Process and Orchestration

  • Exercise 500

  • The Organization

  • Exercise 501

  • Operating the Charter

  • Exercise 502

  • From Experiments to Tool

  • Exercise 503

  • Part V — The Harness

  • Exercise 504

  • Quiz 65

    3 attempts allowed

  • Appendix B — Templates

  • CLAUDE.md skeleton (Lesson 11)

  • Rule file skeleton — iron, golden, preference (Lesson 12)

  • Corpus map — five directories (Lesson 13)

  • Exercise 505

  • Skill skeleton — eight checkpoints (Lesson 20)

  • Exercise 506

  • Agent definition skeleton (Lesson 20)

  • Hook configuration skeleton — five patterns (Lesson 20)

  • Exercise 507

  • Plugin manifest skeleton (Lesson 20)

  • MCP tool design checklist — eight questions (Lesson 20)

  • Exercise 508

  • Intent contract template — seven sections (Lesson 47)

  • Exercise 509

  • Phase-transition checklist (Lesson 48)

  • Exercise 510

  • Interrupt template (Lesson 48)

  • Exercise 511

  • Release-readiness gate — five checks (Lesson 48)

  • Exercise 512

  • PR template — five sections (Lesson 48)

  • Org-rule charter (Lesson 25)

  • Promotion-candidate template (Lesson 25)

  • Three-artifact decision tree (Lesson 25)

  • Exercise 513

  • Post-mortem template (Lesson 28)

  • Charter-debt ledger row (Lesson 31)

  • Charter CHANGELOG entry (Lesson 31)

  • Mode-selection rubric (Lesson 32)

  • Exercise 514

  • Curator’s daily checklist (Lesson 32)

  • 30-day calendar template

  • Quiz 66

    3 attempts allowed

  • Appendix C — Sources

  • Foundational engineering canon

  • Foundational agent literature

  • Adjacent disciplines

  • Mathematics and theory

  • Contemporary harness and agent-coding writing

  • Honorable mentions: tools, frameworks, and runtimes

  • The author’s blog archive

  • Appendix D — The Tools Behind the Book

  • sigma — the harness layer, built from scratch

  • open-refinery — the agentic-workflow layer, kept open

  • What the three tools embody

  • Run the post-mortem on your own tool

  • Keystone: the synthesis

  • What Keystone is, in one paragraph

  • Exercise 515

  • The charter discipline, shipped

  • The first command

  • Exercise 516

  • The directory layout

  • Exercise 517

  • Sensors, signals, playbooks, adapters — the lifecycle in markdown

  • Exercise 518

  • The companion surfaces

  • Exercise 519

  • The three-ring principle, mapped

  • Exercise 520

  • The cascade, now a policy tree

  • Exercise 521

  • Forward-only upgrades

  • Exercise 522

  • A worked first task, end-to-end

  • Step one — write the contract

  • Step two — the agent enters and reads

  • Step three — the agent picks a skill

  • Step four — the PR opens with acceptance evidence

  • Exercise 523

  • The full chain, every contract

  • Exercise 524

  • What the agent reads on each turn

  • Exercise 525

  • What Keystone does not do

  • Exercise 526

  • What Keystone kept and dropped

  • A copyable getting-started recipe

  • Quiz 67

    3 attempts allowed

  • Appendix E — For the Junior Engineer

  • Comprehension is the job

  • Exercise 527

  • What the team owes you

  • Exercise 528

  • Pair with a senior, and the agent makes three

  • Exercise 529

  • Read open source with an agent

  • Exercises

  • Exercise 530

  • The path

  • Quiz 68

    3 attempts allowed

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub