What Breaks When You Switch a Layer Off

The Wrenfold team reviewed the double-booking postmortem and created a reference document for the agent.

The document grew to six hundred lines. It covered the domain model, naming conventions, review process, three deployment environments, and the history of an unused database column. Two team members spent a week producing it. By documentation standards, it was thorough and well structured.

The next long session still failed. The document scrolled out of context. It did not seed the test database. It could explain the overlap rule, but it could not stop an agent from violating it. Wrenfold had made the repository more readable and mistaken that for the whole harness.

That mistake is easy to make because a document is visible. The other parts of a harness look like setup scripts, command permissions, progress files, and failure messages. They do less explaining and more controlling.

Why isn’t a prompt file enough?

A prompt file answers one question: what should the agent know?

OpenAI draws the larger boundary this way:

A document can state that appointments must not overlap. It cannot seed the clinic database, execute the end-to-end route, preserve a decision after compaction, or reject a bad booking. Those jobs belong to four other layers.

Before naming them, diagnose one failure:

The command ran, so Power was present. The database contained Dr. Reyes's appointment, so Ground was ready. The weak assertion failed to tell the agent which booking conflicted or what rule it violated. The missing layer was Verdict.

What is actually in a harness?

A harness has five layers. Each sits on the reliability side of the distinction we just drew, and each answers a different question about one run.

The rows are not interchangeable. A shell is not a seeded database. A test command is not the message produced by its failed assertion. Keeping those boundaries clear tells you which artifact to repair.

What has to be reachable?

Reach is whether a session can find what matters before it acts: the system’s boundary, its invariants, and the commands that count as verification. At Wrenfold, AGENTS.md routes the agent, and docs/domain.md states that two appointments for the same provider must never overlap.

Reach is not the same as writing something down. The overlap rule can sit in a six-hundred-line document and still be out of reach, because the agent never gets to line 418. What counts is whether a session that needs the rule arrives at it.

Remove Reach and the agent still writes coherent code. It adds the recurring route and never learns that src/availability/ already owns overlap checks. That makes it more dangerous than a clean stop.

What must the agent be able to do?

Power turns a request into action. Search and file access let the agent locate and edit the route. A shell lets it type-check. The end-to-end runner lets it send two requests toward Dr. Reyes’s 3:00 PM slot.

Reach can put npm run test:e2e in front of the agent. Power decides whether it can run it. Remove Power and the session ends at a proposal, a pasted code block, or an untested edit.

Power is also the layer you deliberately narrow later. An agent that can run any command can run the one that drops the appointments table.

What does the ground have to be?

Ground is the machine state before the task begins: installed dependencies, running services, configuration, permissions, and test data. Wrenfold’s init.sh creates the clinic database, seeds existing appointments, and proves that the end-to-end suite starts.

This is the boundary people collapse most often. Power gives the agent a way to run npm run test:e2e. Ground decides whether that command reaches a seeded clinic or dies against an empty database. One is an ability. The other is the condition under which the ability means anything.

A green command on bad ground is worse than a red one, because it looks like evidence.

Who gets to say it failed?

Verdict is the judgment the agent does not get to make about its own work. Tests, linters, runtime logs, evaluator comments, and review findings can all supply it. A useful verdict names the failed condition in terms the agent can act on.

The test runner belongs to Power. The assertion and its message belong to Verdict. Expected 201 to be 409 identifies a mismatch. Dr. Reyes already has an appointment from 15:00 to 15:30 identifies the violated invariant and the conflicting record.

What has to survive the session?

Carry is what remains when the context does not. claude-progress.md records what changed and what stays uncertain. feature_list.json records which agreed features may move and which have passing evidence.

Carry should hold decisions a later run cannot safely infer. It should not copy architecture already visible in the code. If session one discovered that recurring bookings must call the existing availability module, session two needs that decision and its reason. Without it, the second session builds the duplicate check the first session avoided.

Reach puts the rule in front of the agent. Power runs the check. Ground supplies the collision. Verdict rejects the booking. Carry records the result for the next session.

Can you find all five inside real code?

The boundaries stick better when attached to executable artifacts. Classify each line of a small CLIN-482 verification script. Every layer appears exactly once.

Notice that no single line is "the harness." The harness is the relationship between the route, the ability to run, the prepared world, the disagreement, and the durable record.

What breaks when you remove one?

Now test the relationships. The simulator runs ticket CLIN-482 against the same Wrenfold repository in thirty-two configurations. Switch off any combination and follow the first stage that can no longer continue.

Try Power and Verdict together. With both off, the session stalls before verification. Verdict appears to cost nothing because an earlier failure prevented it from acting. Turn Power back on and Verdict becomes the only layer stopping the double-booking claim.

A layer has no fixed value in isolation. Its value depends on the task, the model, and the other layers around it.

What did switching things off prove?

That is an ablation test: remove one component and measure what changes. It proves less than it first appears to.

Switching off one layer tells you what it contributes to this run with this harness. It does not identify a permanent bottleneck. One missing layer can hide another, and a late evaluator can spend all its time catching defects a reachable rule should have prevented.

Anthropic found the same thing after removing components from a working three-agent harness:

Without the planner, the generator under-scoped the application and built too early. The evaluator cut both ways. Moving it from every sprint to one final pass removed needless work on tasks within the model's range, while it still helped on edge cases.

The component did not change. The work asking for it did.

What happens when the model improves?

The harness may need to shrink.

Anthropic built its original harness around Claude Opus 4.5. Long builds needed short sprints and full context resets because compaction did not stop the model from wrapping up early.

Opus 4.6 planned more carefully, worked for longer, and caught more of its own mistakes. Anthropic removed the sprint construct and ran one continuous session. Their explanation was direct: “the model’s raw capability increased, so the boundary moved outward.”

That boundary will move again. A rule that once prevented drift can become context the model has to carry. An evaluator that caught bad edge cases can become repeated expense. Keep the five questions, but retest the machinery answering them.

Which layer should you fix first?

Start with the first missing artifact you can prove, not the layer that is easiest to describe.

At Wrenfold, the immediate gap is Verdict. The route exists, Power runs, and the unit suite is green. Nothing checks the full booking flow against existing appointments. Four lines in AGENTS.md make completion depend on that evidence:

The third command catches the 3:00 PM collision. It also needs an assertion that names the provider, time, and conflict. Evidence outside the agent's judgment must be able to say no and explain why.

The check also has to disagree clearly. Expected 201 to be 409 tells the agent that one assertion failed. Dr. Reyes already has an appointment from 15:00 to 15:30 tells it which invariant the change violated and where to look.

What’s next?

You now have five places to look when a session fails. The next lesson starts with Reach.

You will give a cold agent the Wrenfold repository and ask what the system is, where the task belongs, how it starts, what must never break, and what proves the change is done. Missing answers reveal whether the repository can explain itself.