Skip to content
Everything Agents

Lesson 14 of 14 · 2 min

Sticky-note appendix

The seven things that change how you read every harness paper afterward.

The seven that keep showing up. Stick them somewhere visible.

1. Six components, six failure modes

H = (E, T, C, S, L, V). When something goes wrong, the question to ask first is which of the six. Most agent debugging gets faster once you can name the component.

2. Deterministic shell · soft model core · deterministic shell

The most useful pattern in harness design. Almost every win is some variation of "move this from the prompt to the shell." Prompts are suggestions; shell code is guarantees.

3. State that needs to survive should be in files

Compaction may eat conversational state. A reset definitely will. If losing it would break the task, write it down on disk before the turn ends. JSON > Markdown for things the agent must not casually overwrite.

4. Re-test the harness on every model release

Every component encodes an assumption about what the model can't do on its own. Those assumptions go stale. Sonnet 4.5 needed context resets; Opus 4.6 didn't. The next model will move other things.

5. Raw traces beat summaries

Two independent papers found this in 2026. A fault at step 200 may be attributable to a decision at step 5; compression severs the link. Whatever's downstream (your eyes, an evaluator, an automated optimizer) wants to navigate the trace, not consume a digest.

6. Evaluator > self-critique, when the task is beyond solo

Self-evaluation is unreliable in the same predictable ways every time. Tuning a separate skeptical evaluator is far more tractable. Stop using the evaluator when the model can do the task solo; at that point it becomes pure overhead.

7. Factual harness structure transfers; prose strategy doesn't

AHE's ablation: tools, middleware, and long-term memory each carry positive gains alone; system-prompt-only regresses by 2.3 pp. Invest engineering effort in durable structured components, not in tuning the system prompt.

8. Pass is evidence, not truth

Every check has blind spots. A green test means this layer didn't catch a bug, not this code is correct. Build a verification stack with explicit scope: which layer caught what, what each layer cannot prove, and what remains unverified. Approvals work the same way: a "yes" was scoped to specific evidence, not a standing permission. Record both as harness state, not as ephemeral facts.


That's the topic. From here, the natural directions are:

  • The Testing Agents topic, when it lands: how to write specs that exercise these components.
  • The Observing Agents topic: pulling trajectories and turning them into actionable diagnostics.
  • The Autotuning Agents topic: closing the loop with the meta-harness ideas from lesson 12.

Each one assumes the vocabulary you just learned.