The Harness Is Where Your Taste Goes

Agent = Model + Harness.

The Illusion

You have watched Claude Code run for twenty minutes and never lose the thread.

A tool call fails; it reads the error, tries another way, keeps going. Then you wire the same model up behind a raw API key and it goes flat. It forgets what you told it. It gives up the moment something breaks.

Same model. Same weights.

One feels like a colleague. The other, a clever intern with amnesia.

Part 1 made the argument: the gap between those two is a stack of product decisions, and they're yours to claim. You came here for the vocabulary. This is the machine, opened.

Just an Engine

First, kill the myth you probably walked in with: the magic is not a smarter prompt.

When Claude Code's client source leaked this spring, the striking thing wasn't any secret instruction. It was that the core instructions are task-agnostic. Nothing about your repo, your bug, your workflow is hardcoded anywhere. The specificity arrives at runtime: your project's rules, the available tools, the relevant files, assembled fresh around the model on every single turn.

So the right mental model is this: the model only reasons. It's the executive. Judgment, decisions, orchestration. Everything else, everything, is environment. And each time the model wakes up, how it behaves is a direct function of the environment it wakes up in.

Build it a jail, you get a prisoner.

Put a Ferrari engine in a Polo, you get a Polo.

Harness engineering is environment design. And environment design, it turns out, is product design one layer down. Which is why this layer is where your taste goes now.

The Same Three Layers

In Part 1 we split the harness into three layers to show what the labs were eating. Same tree, redrawn under a harness you build yourself. Every box comes back.

Each part is not a component. It's a place where a decision lives. The loop holds “when is it done and how many retries is that worth.” Permissions hold “what needs a human.” Memory holds “what survives the session.” Read the diagram as nine addresses, not nine features. Taste, down here, is having an opinion about what belongs at each address.

And Part 1's five questions? They each have an address now:

Watch It Run

Now watch the anatomy in motion. One ordinary, ambiguous ask: “make the checkout tests pass.” First the shape of the run, then who decided each beat.

Nine parts, one ambiguous sentence, and you felt none of it. That's the tell of a great harness: the decisions disappear into smoothness. And every one of them was tuned for exactly one user: an engineer, at a terminal, watching.

The Dial

Here's the thing the anatomy hides, and the reason this piece exists. All nine parts are implementations of one single tradeoff: how much does the model decide, and how much does the code decide.

Turn it toward the model: it handles ambiguity, feels smart, surprises you, costs more, and is harder to predict. Turn it toward the code: reliable, cheap, testable, rigid. At the far end of rigid you've built Part 1's wizard. At the far end of smart you've built something you can't put in front of a customer.

Which gives you the correction to how everyone talks about this: smartness is not a level. It's an allocation. Nobody sets one dial for the whole product; a good harness sets it per step. Claude Code is ruthlessly deterministic about permissions and completely judgmental about planning. That non-uniformity is the craft.

And these settings aren't vibes in someone's head. They're numbers in a file. One open-source reimplementation of Claude Code carries the loop's knobs as a frozen config: max_turns: 8, compact_after_turns: 12, structured_retry_limit: 2. Those are the port's choices, not verified Anthropic defaults — and the distinction doesn't weaken the point.

Someone typed 8.

Someone priced another failed retry at exactly two.

Those are product decisions. In most companies, they ship without a PM in the room.

Your Blanks

Now swap the user. Every dial position in that walkthrough was tuned for an engineer at a terminal. Your user is a sales lead in a browser, a support agent mid-ticket, an ops manager on a phone. Every setting resets:

These blanks are Part 1's micro-decisions, now with names and addresses. Nine parts, a dial position each, times every step of your workflow. That's the honest size of the job, and odds are nobody on your team owns the whole of it.

Now You Can See It

You have the map. You have the dial. Here's what you still don't have: answers. Nobody, including the people who built Claude Code, can set a dial from a chair. They set theirs by watching it run and revising until the decisions disappeared into smoothness. The honest answer to “how much judgment should this step get?” is still “I'd have to see it run.”

So build the disposable version. This is the exact right thing for a PM to prototype. Not for production; if it gets there, great, but that was never the point. You prototype to find the answers that were always supposed to be part of your job. And you know what to watch for now: the step where it over-asks and a user would quit. The step where it burns frontier reasoning on boilerplate. The turn where compaction eats the sentence your buyer paid for.

One discipline while you do it: don't grade the output. Watch the trace.

• Where did it ask when it should have acted — or act when it should have asked?
• Which context changed the answer?
• Which failure could have recovered?
• Which step deserved a cheaper — or better — model?
• What did the user have to repeat?
• What was correct but lost during repair?

A screen prototype reveals the interface.

The trace reveals the actual agent.

Three ways in, pick by appetite:

1. DIY Take the feature on your roadmap and prototype it yourself: public APIs, an MCP server, no production anything. Frame every answer around the nine parts. Some won't apply, and that's the point; ruling one out means you set that dial deliberately instead of by default.
2. Get help Put a real task on the sprint and have an engineer prototype it with you. Sit through the build, make the calls, test every iteration. Don't throw a capability-shaped requirement over the wall; the decisions are the deliverable, not the code.
3. Go headless Skip the interface wherever you can. A terminal-only prototype built around just the questions you want answered is a fraction of the work, and answers them just as well.

Or watch a live example. Part 3 is Yukta, start to finish: the first flow, the failures, the dial changes, and the requirements that fell out of it.

The dial is being set on your product today.

By a framework default. By a developer choosing the fastest path. By a model provider's generic assumptions.

The only question is whether your hand is on it.