Skip to specification

Evolution

Failures become infrastructure: a missed context becomes a retrieval rule, a dangerous command becomes a permission gate, a repeated workflow becomes a skill. The harness compounds.

Evolution is where failures become infrastructure. Every other primitive handles the current run; this one makes sure the next run starts from a better place.

The post-mortem loop, for agents

In mature engineering orgs, an incident doesn't end with an explanation — it ends with a system change that makes the same class of failure harder to repeat. Harness engineering applies the identical discipline:

observed failure                      →  becomes harness infrastructure
──────────────────────────────────────────────────────────────────────
a repeated context miss               →  a retrieval rule
a bad tool result                     →  a stricter schema
a dangerous command in the trace      →  a permission gate
a missed edge case                    →  a test
a recurring correction from the user  →  a memory
a repeated workflow                   →  a skill

Each row starts in observability — you saw it in a trace — and ends as a permanent upgrade to a different primitive. That's the loop: verification and observability catch the failure; evolution routes it back into instructions, schemas, gates, tests, memories, and skills.

In the wild

The everyday version: after an agent repeats a mistake, you add a line to CLAUDE.md — that's failure → instruction. You notice a risky rm -rf in a log and add a permission rule — failure → gate. You catch yourself explaining the same workflow twice and write it as a skill — repetition → capability. Harness evolution isn't exotic; it's the habit of never fixing anything only once.

The whole machine, assembled

Put all eleven primitives together and look back at any architecture diagram of Claude Code, Codex, or Gemini CLI — it stops looking like a random complex box-diagram. Every component has a reason to exist, and you now know each one.

Which leaves the practical test to carry with you. When an agent fails, don't only ask was the model good enough? Ask:

Was the instruction missing? Was the context wrong? Was the tool schema vague? Did the command run in the wrong environment? Did the workflow need durable state? Orchestration? Should it have been delegated? Was there no skill? No verification? No trace to look inside? And did we learn nothing from the last failure?

That is the shift. Harness engineering is how clever agents become dependable systems. The model still matters — but reliability is built in the system around the model.