What Is Harness Engineering?

What is it

A harness is everything that surrounds a language model to turn it into a reliable collaborator inside a real process: the rules it always has present, the reusable procedures it can trigger, the memory that persists across sessions, and the decisions about when to delegate a task to another agent. Harness engineering is the discipline of designing and tuning that environment.

The distinction matters because a more capable model doesn't solve inconsistency by itself: two different sessions with the same model can behave differently if they don't share the same rules, the same memory, or the same procedures. The harness is what makes an agent's behavior reproducible instead of depending on the mood of each conversation.

Mental model

Think of the model as a very talented new hire, and the harness as the company handbook, the documented processes, and access to internal systems. A brilliant employee with no handbook improvises every time context is missing; the same employee with clear processes produces consistent results, even across shift changes or project switches.

How it's used

A typical harness combines several pieces, each solving a different problem:

• Rules (e.g., a CLAUDE.md file): context loaded in full every session, without the agent deciding whether it needs it.
• Skills: procedures the agent triggers on demand, when a task matches their description — not loaded in full until triggered.
• Persistent memory: decisions, patterns, and discoveries that survive across sessions and context compactions, instead of getting lost when a conversation ends.
• Orchestration: explicit rules about when the agent should delegate a task to a sub-agent instead of handling it itself, to avoid flooding its own context.

A minimal example of the first piece (rules) in practice:

# CLAUDE.md
 
## Commands
- `npm test` — runs the test suite
 
## Conventions
- Components in PascalCase, hooks in camelCase with a `use` prefix
 
## Architecture
- Business logic lives in `src/domain/`, never in UI components

This file loads in full every session — it's the simplest piece of the harness, and almost always the one worth setting up first.

No single piece solves the whole problem — a well-designed harness combines whichever ones the process actually needs, without adding the ones it doesn't.

When to use it / when not to

Worth investing in a harness when:

• The same agent will repeat a type of task many times (e.g., generating technical documents, reviewing code).
• Multiple people or sessions need the agent to behave predictably.
• The project is long enough that memory across sessions actually matters.

It's overkill when:

• It's a one-off task with no expected repetition.
• The project is small enough that documenting rules costs more than just explaining them each time.
• You're still exploring what process to follow — a rigid harness too early works against you.