Clean Your AI Harness Before Better Prompts
Summary of the video “Fable 5 And GPT-5.6 Don't Need Better Prompts. They Need A Clean Setup.” by AI News & Strategy Daily | Nate B Jones.
Most AI users accidentally build bloated harnesses—layers of rules, files, and instructions that accumulate over time and degrade performance. Rather than adding more prompts, map your harness, consolidate duplicate rules, load specialist knowledge on-demand, and enforce hard requirements with schema checks. Fable 5 and GPT-5.6 behave differently under bloat, but both benefit from intentional, lightweight setup.
What Is a Harness and Why It Matters
A harness is everything wrapped around the model
A harness includes custom instructions, project files, saved prompts, memory, skills, tools, permissions, and checks. It shapes every answer before you type anything into the prompt window. Most people build harnesses accidentally, one correction at a time, without ever seeing the full system.
The car chassis analogy
Just as a car's chassis, drive shaft, and suspension transfer engine force to the wheels, a harness transfers the model's capabilities into actual work. The harness makes the work possible and should be designed intentionally, not assembled by throwing bolts randomly.
Model changes don't rebuild the harness automatically
When ChatGPT or Claude retires an older model or switches models mid-conversation, the old harness stays in place. The new model may behave very differently with the old setup, leading users to blame the model and add more instructions—creating a vicious cycle of bloat.
The Bloat Problem: A Real Audit
Speaker's harness inventory revealed massive accumulation
An audit of the speaker's setup found 66 reusable skills and 172 instruction-related files. One normal writing job pulled in an 18,000-word file before adjusting the prompt. The provenance governance rule (ensuring proper sourcing) was duplicated across 15 different skills.
Not all bloat is obvious—some rules protect important work
Some instructions legitimately protect critical work: they specify which sources matter for research, prevent the AI from inventing false opinions, and define what the AI can do without asking. The problem is distinguishing protective rules from overlaps, copies, or rules that no longer fit the new models.
Six Principles for a Clean Harness
Principle 1: Map the harness before you clean it
Create a complete inventory showing where each control lives, when it loads, what job it does, who owns it, whether there is evidence it still helps, and what problems it could create if misused. This reveals the full system in one place and exposes the difference between soft instructions and hard locks (permissions, schemas, task checks).
Principle 2: Blame the right layer—model or harness
The speaker tested the same job with Fable 5 in two setups: a compact setup (goal, facts, permission, finish line) and a thicker setup (plus full method, scoring, eval plan, classification). The compact setup delivered correctly 3 of 3 times; the thicker setup produced richer analysis but failed delivery requirements twice (broken JSON, broken word limit). This proves the harness, not the model, often causes failure.
Principle 3: One rule, one home, one owner
Duplicate rules drift over time. The speaker had 15 versions of a sourcing rule across different skills. When one version gets fixed after a failure, the other 14 don't, creating out-of-sync versions and multiple truths for the model. Each rule should have a single home and a single owner responsible for updates.
Principle 4: Load specialist knowledge when work needs it
The speaker had six editorial guides loading whenever one writing skill ran. Loading all context upfront creates cognitive noise—the AI thinks about YouTube examples when it should focus on research. Keep the library large but change when each part appears, loading specialist knowledge at the phase when work actually needs it.
Principle 5: Hard requirements need hard checks
Soft instructions like 'write in my voice' should be distinguished from hard requirements like 'output must be under 500 words' or 'JSON must be valid.' Hard requirements should be encoded in schemas that the system can verify automatically, making the harness lighter and safer while letting machines enforce what machines can verify.
Principle 6: Build for the specific model and product
Fable 5 in Claude.ai has a different harness than Fable 5 in Claude Code or via API. ChatGPT 5.6 in ChatGPT Work differs from Codex or API. The model and product determine how skills load, which tools exist, what can be checked, and what proof returns. Core rules stay the same, but harness structure must match the actual deployment.
How Fable 5 and ChatGPT 5.6 Fail Differently
Fable 5 fails when the harness becomes too heavy for delivery
Fable 5 sorts through heavy context and tries to do the best job, but overloads itself. When given a thick skill file with full method, scoring, and eval plan before seeing the job, Fable produces richer analysis but cannot meet output constraints (JSON breaks, word limits break). The solution: give Fable the outcome, context it can't infer, room to inspect the problem, and let it plan its approach—then bring in specialist material when that work phase arrives.
ChatGPT 5.6 in Codex fails earlier while routing across bloat
ChatGPT 5.6's failure mode appears much earlier than Fable's—while the system is still trying to find the right method. A huge harness layer confuses routing before the model even starts working. Both models benefit from selective loading and hard checks, but for different immediate reasons rooted in how each model processes context.
Codex cleanup requires right routing and depth at the right point
For ChatGPT 5.6 in Codex, cleanup is not just making prompts shorter—it is making the right route to the skill easy to find, then loading depth at the right point. A receipt records the model, reasoning setting, tools, skills, fallbacks, and checks that ran, acting as a diagnostic for the engine to identify where problems occur.
Audit Findings and Codex-Specific Issues
Description bloat exceeded Codex discovery budget
The speaker's harness had 27,000 description characters against an 8,000-character Codex discovery budget—a major problem because Codex cannot read it. This prevents the model from properly routing and discovering the right skills.
Most skills lacked local evals
Only 6 of the 66 root skills had a detected local eval. The other 60 had no evaluation mechanism. Consistency across skills requires schemas, tool restrictions, file checks, and run receipts to carry the same requirements from skill to skill so Codex can operate reliably.
The Cleaner Skill and Practical Application
The cleaner skill maps and cleans harnesses automatically
The speaker built a skill that makes the harness visible and executable. It maps every control, generates a plain-English before-and-after, and produces a receipt showing what ran. Users can install it once, point it at any AI setup or project, review changes before they take effect, and discover accumulated bloat.
Benefits vary by role: product manager, developer, end user
Product managers get a clean, simple note that loads the right PRD skills at the right time. Developers get one source of truth instead of several instruction files arguing about repository work. End users stop old memories, project files, examples, and corrections from quietly shaping answers in unintended ways.
Old corrections can over-apply with new models
A correction given six months ago—like 'always show me step-by-step'—may still be remembered and over-applied by a new model even though it is no longer necessary. The cleaner skill catches these kinds of outdated rules that no longer serve the current work.
Why This Matters Now
Harnesses grow barnacles like ships
Over time, harnesses accumulate extra point solutions, random additions, and text files found on the internet. Without intentional maintenance, they become unmanageable. The goal is a system that helps work happen efficiently by staying clean and not collecting unnecessary layers.
Visibility enables ownership
Once you can see your harness system, you can own it. You can tell which controls protect you, which need one single home, which should arrive later in the process, and which should become real locks instead of polite reminders. Understanding the system makes it possible to manage it.
Notable quotes
Every rule ended up fixing a real problem at the time, but over time, I didn't realize how bloated my harness had become. — Nate B Jones
If you blame the model for everything, you will keep adding instructions to solve problems created by instructions, not by the model. — Nate B Jones
Your AI should become easier to use to do useful work because the system around it should become easier to understand. — Nate B Jones
Action items
- Audit your current AI harness: count your custom instructions, project files, saved prompts, skills, and tools. Look for duplicates and overlaps.
- Map your harness using the cleaner skill or manually: document where each control lives, when it loads, what job it does, and who owns it.
- Consolidate duplicate rules: identify rules that appear in multiple places (e.g., sourcing, authorship, formatting) and merge them into a single home with one owner.
- Separate hard requirements from soft instructions: move hard requirements (word count, JSON format, output schema) into schema checks and let the system enforce them automatically.
- Audit your specialist knowledge loading: identify which editorial guides, examples, or context files load by default and move them to load only when the work phase needs them.
- Test your setup with both compact and thick harnesses: compare performance of a minimal setup versus your current setup to identify whether failures are model-based or harness-based.
- Install and run the cleaner skill on your setup: generate a map of your harness, review the before-and-after recommendations, and apply changes incrementally.