Fable 5 and GPT-5.6 Sol both landed in 2026 and the internet collectively lost its mind over benchmarks. I don't care about your benchmark. I care that on a normal Tuesday I ship production features across a dozen repos without babysitting a chat window.
Spoiler: the model is maybe 30% of the win. The other 70% is the harness you build around it — the folder structure, the token discipline, the cheap always-on listeners, the deterministic hooks, and a hard list of rules that stop a confident model lying to you about "done". Here's my actual setup, warts and all.
The environment: one root, project-local overrides
Everything lives under a single projects root, and every project carries its own context file that overrides the global one when I'm inside it. Global rules are things true everywhere: git policy, tone, deploy accounts. Project rules are things true only here: this repo deploys via CLI, that table is a JSONB blob, this site is on Tailwind 3 not 4.
The agent reads the narrow one last, so specific always beats general. And the global file stays deliberately tiny — if it's 4,000 lines, none of it gets followed. Which brings me to the structure that actually scales.
Money pattern #1: halls and rooms
I've written a full how-to on this structure — file trees, what earns its place in a room, and how to stop the whole thing rotting.
A flat mega-context-file is where good intentions go to die. So I split every project's memory into halls (one file per domain) and rooms (sections inside a hall for a specific component or flow). The root file is an index — it says what exists and when to load it. Nothing more.
CLAUDE.md # index only — loads every session
halls/
general-app-design.md # rooms: Buttons, Cards, Sliders...
databasing.md # rooms: Users, Licenses, Templates...
payments.md # rooms: Checkout, Dunning, Webhooks...The root loads every session; halls load only when the task touches that domain; rooms get read on demand. That keeps the always-on context tiny while deep, specific rules live exactly where the agent will look when it actually needs them. Buttons Room proposes standard button rules. Users Room documents every gnarly thing about how the app talks to that table. It's a knowledge tree, not a wall of text.
The catch, and it's a big one: rooms rot. Docs start accurate and drift as the code changes around them, and an outdated room is worse than no room because it actively lies to the agent. I got burned by this badly: a stale line saying "GitHub pushes don't auto-deploy" was believed over reality, and it cost me an hour and my temper.
The rule now: treat a stale doc as a bug. When you catch a room lying, you fix it in the same pass — you don't note it and move on. The tree is only as good as your discipline about pruning it.
Money pattern #2: caveman token compression
My default comms mode is deliberately terse — abbreviations, arrows for causality, fragments over sentences, one word where one word does. Full technical accuracy and exact paths and error strings are preserved; the fluff is not. It saves roughly 75% of output tokens.
// normal
"I've finished refactoring the authentication module and all
tests are now passing after fixing the token expiry bug."
// caveman
auth refactor done · token-expiry bug fixed · tests greenThe trigger that matters most is right before dispatching two or more parallel sub-agents, because their output flows back into the main window and then gets re-billed as input on every subsequent turn. That's where bloat actually hurts.
I drop back to plain English for exactly four things: security warnings, irreversible-action confirmations, customer-facing copy, and explanations for a human I'm mentoring. Everywhere else, caveman.
Cheap models as always-on watchers
Here's the trick people miss: you don't need your flagship model for watching. While I'm editing or a sub-agent is churning, a passive monitor tails the dev-server log filtered for the words that mean something broke:
tail -f dev.log | grep -Ei 'error|failed|cannot|undefined|expected corresponding'A build break surfaces as a notification the instant it happens instead of me finding it three edits later. Once a browser is wired in, I add a roughly 60-second heartbeat reading console errors.
The listener runs on a cheap, fast model — a Haiku-class model is perfect for "did anything explode?" — so it's basically free to leave on. The expensive model does the thinking; the cheap model does the staring. And it triages breaks before reporting status to me, which is the whole point.
Rules and hooks: make the guardrail deterministic
Prompts are probabilistic. A hook is not. Anything I truly cannot afford to have go wrong moves out of the prompt and into a hook the harness executes deterministically.
My git policy is the classic example: commit to main only, never branch, never open a PR unless I ask. That's a sentence in the context file and a PreToolUse hook that hard-blocks a git checkout -b before it can run. Belt and braces, because the sentence alone failed twice.
It's so literal that writing this very post tripped it — the hook saw that command string inside my prose and blocked the file write. Which is exactly the behaviour I want: a dumb, deterministic guard that fires on the pattern and makes me be explicit, rather than a clever one that reasons about intent and occasionally reasons wrong.
# session-start injection (paraphrased)
NON-NEGOTIABLE: verify before claiming done. no build breaks from
sloppy edits. read the ask correctly the first time. no scope drift.Session-start hooks also inject my delivery rules and a "which company is this?" gate every single session, so the agent starts calibrated instead of guessing from a folder name. The principle: if it must happen every time, don't hope the model remembers — make the harness enforce it.
Custom CLIs and MCP servers
When the ROI is there, I build the tool instead of buying it. I built my own routing engine rather than paying for an off-the-shelf one, partly because owning the CLI means the agent can call it directly. And I lean hard on MCP servers — Supabase, Slack, the ad platforms — so the agent reads and writes real systems instead of me copy-pasting between tabs.
The underrated one is cross-agent handover over Slack: a dedicated channel as the message bus between separate agents working different repos, where every handover is a precise ticket — target, context, numbered asks with exact file paths, and what to reply with. Never a vague chat. Agents talking to agents, with a human-readable audit trail I can read in the morning.
Aggressive standing instructions, and why they work
Yes really — I inject blunt, aggressive standing rules, and they work. "Verify before claiming done." "No smoke breaks — churn the task list, don't defer a doable task." "Deliver the simple thing asked; don't route around the request."
It reads harsh. But a model will happily hand you a polite, confident, wrong answer unless you explicitly price that behaviour out. Tone is a control surface, and vague encouragement doesn't move a probability distribution — naming the exact failure mode does.
The anti-footgun list that actually moves the needle
I keep a running, weighted log of every way an agent has burned me, each practice scored by Effect (how much it hurts) × Improvement (how much fixing it helps). The top-scoring ones:
- Verify against ground truth before saying "done" (100/100). Never let narration substitute for observing the real system. In practice: a post-deploy smoke test that hits the live URL, and an end-to-end run of the flow I just changed. Not "the build passed."
- Never self-report completion without an independent check (90). The verification has to be a signal the model can't fake with confident prose — a real auth call, a screenshot, a curl of the deployed bundle.
- Debug the root cause; never blame the user (81). When something fails, trace it. "Maybe you tested it wrong" is the fastest way to lose trust.
- Ground claims in live sources, not stale docs (81). Check the git remote and the deploy log, not the README's memory of them. This is the direct fix for halls-and-rooms rot.
- Calibrate confidence to evidence (63). "I haven't checked yet" is a complete, honest sentence. Training rewards sounding certain past what you know, so hedging has to be explicitly permitted.
Notice the pattern: none of these need a smarter model. They all force a verification step between "I think I did it" and "I'm telling you I did it". That gap is where every bad AI experience actually lives.
The verdict
Fable and Sol are both brilliant and it barely matters which one you point at the problem. The model is the engine; the harness is the car. Caveman keeps context lean, cheap listeners watch the road for free, halls and rooms hold the knowledge until you let them rot, hooks enforce what you can't leave to chance, and the verify-before-done list keeps the whole thing honest.
Build the harness once and it pays you back on every model upgrade for free. That's the actual optimisation.
Want a setup like this wired into your own stack? Book a call or see the work.