⚙️ Willingness × hard guarantee
A behavior guide—even a well-written one—is intention. The model may forget, deprioritize, or fail to trigger the rule on the right turn. Willingness is best-effort by nature. This module is about the other half: the mechanical levers that the harness actually enforces — o effortLevel and hooks. Write the disposition e set the guardrails. Neither one is enough on its own.
Detailed content
Why a behavior guide is only “best effort”
The most sober reflection in all the source material fits in one sentence: disposition is intent, not a guarantee. You can write the clearest behavior guide in the world, point the session to it, and the model may still forget, deprioritize, or simply fail to trigger the rule in the turn when it mattered. Not because the guide is bad — but because a guide, by nature, is best-effort. It depends on the model remembering.
⚙️ The idea in one sentence
A behavior guide is the disposition layer: it shapes what the model tends to a to do, and the prose closes part of the actual gap. But "tends to" is not "will." Whoever trusts only the prompt trusts the best-effort from a system that has bad days.
The measure of this is in the numbers: even the source model, with the highest observed discipline, runs the real test after editing in only 23% of turns. The intention was there. The execution leaked. That’s exactly the leak a hard lock closes — and this module is about installing them.
What it is
The disposition layer is everything that lives in prose: the Fable_Mindset, the rules of your CLAUDE.md, the “always do X / never do Y” rules. It is probabilistic: increases the chance the behavior will appear, but never takes it to 100%. A hard guarantee is the opposite—it’s what the harness executes regardless from the model cooperating.
Why learn
Because the beginner operator’s temptation is to solve everything by writing more rules. When the agent "sometimes doesn’t run the tests," the instinctive reaction is to add another "ALWAYS run the tests!!!" to the prompt — in caps, with exclamation marks. This raises the probability a little and the guarantee not at all. The advanced operator recognizes when a problem is one of disposition (solves with prose) and when it’s mechanics (one safeguard is enough).
✓ What the disposition does well
- ✓Shapes the tone, the default style and stance
- ✓Increases the likelihood of good habits emerging
- ✓Covers cases no safeguard anticipated
- ✓Gives the reason — the lock only gives you the what
✗ What the disposition does NOT guarantee
- ✗Make sure the rule fires in the turn when it matters
- ✗Make sure the model doesn’t deprioritize it under pressure
- ✗Make sure the test runs every each time after an edit
- ✗Repeatability — it works today, it may fail tomorrow
The question that classifies the problem
Before adding another line to the prompt, ask: "is this a question of whether the model wants to, or whether it might forget?" If it’s about what you want—tone, stance, judgment—prose is the right place. If it’s about something being forgotten—a step that needs to happen every time — no amount of prose is enough; you need a lock. Writing a rule for a mechanical problem is treating a fracture with advice.
Reasoning density = effortLevel, not the old token budget
The first hard constraint is reasoning density. The Fable_Mindset insists that reasoning isn't overhead, it's the work — but the prose only asks; it doesn't allocates more reasoning. The harness allocates it, and the right lever in Opus 4.8 is the effortLevel. This is where the trap catches almost every operator coming from earlier models.
🧠 The right lever—and the one that does nothing
- ✓ Use the effortLevel. In Opus 4.8, reasoning density is controlled by effortLevel in xhigh or max, while keeping alwaysThinkingEnabled connected. It's the harness deciding how much the model thinks — not a prose request.
- ✗ Forget the MAX_THINKING_TOKENS. The old environment variable does absolutely nothing in thinking models adaptive. The model decides on its own when and how much to think; a fixed token limit is ignored. Trusting it is like setting a disconnected lever.
# raises reasoning density only for this session
/effort max
Use /effort max when the session’s work genuinely calls for more reasoning cadence. To set it permanently, prefer effortLevel: "max" in settings. Lesson: the guide’s prose closes part of the reasoning gap; effortLevel closes the rest.
✗ Configure the deadman switch
- ✗Set MAX_THINKING_TOKENS and thinking something changed
- ✗Expect a fixed ceiling to control adaptive thinking
- ✗Ask it to “think more” in prose and stop there
- ✗Debug shallow reasoning by changing the wrong variable
✓ Pull the live lever
- ✓effortLevel: "xhigh" or "max" in settings
- ✓alwaysThinkingEnabled: true connected together
- ✓/effort max for the one-off session
- ✓Effort + the guide's reasoning rules, together
When even the effort isn’t enough
The source model's reasoning density is partly intrinsic — can’t be reproduced 100% by instructions alone or by effort alone. For work that genuinely requires that cadence, the final lever is to switch models directly with /model fable. Effort raises what the current model can deliver; it doesn't invent reasoning that isn't in the weights.
Deterministic habit = the hook PostToolUse
This is the most powerful safeguard in the arsenal because it turns a habit probabilistic in an event deterministic. “After an edit, run the tests” is the rule the source model fails most often — 23% of turns. The solution isn’t to shout the rule louder; it’s to take it out of the model’s hands. A hook PostToolUse paired in Edit|Write|MultiEdit run the test whether you want the agent to remember or not.
{ "hooksEnabled": true, "hooks": { "PostToolUse": [ { "matcher": "Edit|Write|MultiEdit", "hooks": [ { "type": "command", "command": "npm test" } ] } ] } }
O matcher works with any editing tool; the command is the real test of the project. Without "hooksEnabled": true nothing triggers — this flag is the master switch. Lesson: what needs to happen every time can't depend on the agent's memory; it needs a harness trigger.
✗ Trust in intent
- ✗"Remember to run the tests after editing" in the prompt
- ✗Triggers when the model remembers — 23% of turns
- ✗Under load or in a long conversation, the rule evaporates
- ✗You discover the error only afterward, without the test having run
✓ Set up the hook
- ✓The harness runs the test after each editing, always
- ✓Triggers whether you want the agent to remember or not — 100%
- ✓Immune to load, long context, and the model having a bad day
- ✓The test result comes back before the agent continues
Not every habit needs to become a hook — and that's fine
The hook is perfect for what boils down to "after event X, run command Y". But rules that require judgment — such as "prefer absolute paths to cd" — no can be reliably rewritten as a hook, because they require context that a pattern match doesn't have. These remain as placement rules. Use the guardrail where it fits; let the prose cover the rest.
Where the rule lives: CLAUDE.md vs auto-memory
A rule for the right disposition, in the wrong place, fails to guarantee it. The effortLevel and hooks are the hard constraints; the behavior guide is the soft layer — but where you keep this layer determines whether it carries over reliably or disappears for entire turns. And the tricky detail is that auto-memory seems the obvious place, and it isn't.
CLAUDE.md
Disposition rules fit well here. The CLAUDE.md is injected every session, deterministically — the rule is always in context, every turn, without relying on the model to "remember to look it up".
It’s the right home for the behavior guide and conduct rules.
auto-memory
No is where a behavior rule belongs. Recall is relevance-gated: memory only grows if the current turn judges it relevant. A disposition rule can not trigger in the turn when it mattered.
Great for one-off facts; risky for rules that need to apply all the time.
📌 Deterministic beats relevant for behavior rules
The difference is how it's loaded. CLAUDE.md é guaranteed loading: present on every turn by design. Auto-memory is conditional loading: present if the relevance gate letting it through. For a fact ("the deploy is on Vercel"), a conditional is enough — it only matters when the topic comes up. For a behavior rule ("always check what changed"), a conditional is a failure waiting to happen: it needs to apply fair in turns when the gate may not consider it relevant.
That’s why the heuristic is straightforward: a rule that must always apply goes in CLAUDE.md; a fact that only matters sometimes can go in memory.
The “bad turn” test
To decide where a rule belongs, imagine the worst turn: the context is full, the topic is different, the model is under load. The rule still does it need to be there? If so, it requires deterministic loading — CLAUDE.md, not auto-memory. Memory shines precisely when the turn brings the topic to the surface; it fails when the rule needed to be there despite of the turn.
Output styles are for tone and role—not agent discipline
There is a third mechanism that tempts every operator to use it as a vehicle for behavior, and it's the wrong vehicle: output styles. They exist and they're useful — but for what they were designed for: tone and role. Putting agentic discipline in an output style is using the right tool for the wrong problem, and the behavior you wanted to guarantee remains best-effort, just in a more hidden place.
🎭 Each vehicle has its role
There are three different vehicles, and confusing them is the most common source of fragile configuration. Each carries a type of instruction — and only one of them is a hard guarantee:
✓ Output style—what it’s for
- ✓"Respond like a senior reviewer, concisely"
- ✓O role that the model embodies in its response
- ✓The register: formal, instructional, telegraphic
- ✓The persona and voice of the output
✗ Output style—what it does NOT carry
- ✗"Always run the tests after editing" → put it in the hook
- ✗"Reason before acting" → effort + CLAUDE.md
- ✗"Verify before declaring it done" → readiness
- ✗Any discipline of process, not voice
The question that separates tone from discipline
Before putting something in an output style, ask: "does this describe how the response sounds, or what the agent does?" If it’s how it sounds — voice, role, register — output style is the right vehicle. If it’s what it does — a process step, a verification habit — it’s in the wrong place; move it to configuration (CLAUDE.md) or, better, to a guardrail (hook/effort). Style is clothing; discipline is muscle.
Combine the two: disposition (soft) + hard constraints = guarantee
Here, everything comes together. The behavior guide is the disposition layer; o effortLevel and hooks are the hard guarantees. The source material has just one thesis: use both. Alone, neither is enough. Prose closes part of the gap; the lock closes the rest. Write the disposition e set the guardrails — this combination is the entire operational setup.
Write the disposition in CLAUDE.md
Point the session to the behavior guide and put the conduct rules in the CLAUDE.md — loaded every session, deterministic. It’s the soft layer, and that’s where it belongs. Not in auto-memory, not in output style.
Set the reasoning density
Configure effortLevel: "xhigh" or "max" with alwaysThinkingEnabled connected (or /effort max in the session). Ignore MAX_THINKING_TOKENS — a dead lever in adaptive thinking.
Make the habit that needs to be deterministic stick
Install the hook PostToolUse in Edit|Write|MultiEdit that runs the real test, with hooksEnabled: true. The step that needs to happen every time is taken out of the model's hands and turned into a harness event.
Let the prose cover what the guardrail can’t reach
What requires judgment — absolute paths vs. cd, when to consolidate, how to narrate — that still depends on judgment. The guardrail handles what is repeatable and deterministic; prose covers what is contextual. Together, they close the entire gap.
✗ Disposition alone
- ✗Best-effort: works on the best day, fails on the worst
- ✗The test runs when the model remembers (23%)
- ✗Non-repeatable: the same prompt, different results
- ✗You trust the best effort of a system that has bad days
✓ Disposition + hard constraints
- ✓The prose raises the probability; the constraint guarantees the floor
- ✓The test runs every time, whether you remind the agent or not
- ✓Repeatable: guaranteed behavior doesn't depend on the day
- ✓Disposition e mechanics — the complete setup
⚙️ The most important bridge
Treat the guide as the mindset layer: deliberately point sessions to it. And wire up the test hook and effortLevel separately, how the hard guarantees. The arrangement tells the model what wanting; the guard removes the dependency on it wanting to. Either one without the other leaves a gap — prose without a guard leaks during bad turns, a guard without prose doesn't know how to handle the case no one anticipated.
It's the same logic that runs through the entire track: you inherit the method without inheriting the mind. The arrangement is the method in prose; the lock is the method in mechanics. Write the disposition and set the guardrails — and the behavior stops being a hope and becomes a system property.
The operator’s rule of thumb
For each behavior you want, ask two questions in order: "does this need to happen every time?" e "does this boil down to a deterministic trigger?". Yes and yes → make it a hook or config. Yes, but it requires judgment → make it a rule in CLAUDE.md. Only sometimes → it may be a fact in memory. Never entrust something that needs to be rigid to a soft vehicle.
📝 Module Summary
- ✓A behavior guide is best-effort: the model may forget, deprioritize, or fail to trigger the rule on the right turn
- ✓Reasoning density = effortLevel (xhigh/max, or /effort max) — no o MAX_THINKING_TOKENS, which does nothing in adaptive thinking
- ✓Deterministic habit = hook PostToolUse in Edit|Write|MultiEdit that runs the test, whether you remind the agent or not (hooksEnabled: true)
- ✓The rule lives in the CLAUDE.md (loads every session); auto-memory is relevance-gated and may not fire
- ✓Output styles are for tone and role — not for agent discipline
- ✓Combine the two: disposition (soft) + hard constraints = guaranteed behavior. Alone, none is enough
➡️ Next Module
3.7 — 🏁 Final project. You already have the analysis, consolidation, and guardrails. Now it’s time to bring it all together in a project that applies the method end to end: read the evolution, distill the guide, and arm the hard guarantees in a self-sustaining system.