The Ratchet: Why Good Agent Systems Turn Failure Into Infrastructure
A good agent setup does not become reliable because the model magically gets smarter.
It becomes reliable because every failure leaves a tooth in the gear.
That gear is the ratchet.
The pattern is simple:
failure → diagnosis → rule / check / skill / harness change → future runs cannot fail the same way as easily.
If the same class of mistake can happen again tomorrow, the system did not learn. The human merely recovered.
“Skill issue” is usually a harness issue.
When an agent fails, the lazy diagnosis is “the model is not good enough.”
Sometimes true. Often false.
The better question is:
What behavior did the surrounding system fail to make easy, visible, or mandatory?
A model that edits the wrong file may need better repository context.
A model that claims tests passed without running them needs a verification gate.
A model that keeps asking for the same setup instructions needs a skill.
A model that gets lost in logs needs observation compression.
A model that touches dangerous files needs an execution boundary.
These are not model problems. They are harness problems.
Agent = model + harness.
The harness is everything around the model: filesystem, tools, skills, prompts, sandboxes, hooks, memory, task queue, permission system, logs, reviewer loops, and stop conditions.
A decent model in a good harness will often beat a stronger model in a sloppy one.
Failures should become artifacts.
The ratchet only works when failures become durable artifacts.
Examples:
- A repeated command mistake becomes a project rule.
- A fragile browser flow becomes a helper script.
- A recurring debugging path becomes a skill.
- A dangerous operation becomes an approval gate.
- A noisy tool output becomes a compression step.
- A “done” hallucination becomes an external verifier.
The important part is that the artifact lives outside the current conversation.
If the fix exists only as “remember next time,” it will be lost at compaction, restart, or delegation boundary.
Text files, hooks, tests, small scripts, and skills are boring. That is exactly why they work.
The opposite failure: harness bloat
The ratchet has a shadow side.
If every incident becomes a permanent paragraph in a system prompt, the harness turns into a haunted house of historical anxieties.
Rules pile up. Some contradict. Some were only true for one version. Some encode fear rather than behavior.
A good ratchet needs garbage collection.
Every rule should answer:
- Which specific historical failure caused this?
- What behavior does this rule produce?
- Can a test, hook, or tool boundary enforce this more cheaply?
- What would make this rule obsolete?
If you cannot name the behavior, remove the component.
If a rule is version-dependent, attach an invalidation condition.
If a rule is repeated often, convert it into a tool or skill.
The best harness is not the biggest one. It is the one whose constraints map cleanly to known failure modes.
Skills are compressed experience.
A skill is not just a prompt template.
A good skill is the fossil of prior work:
- trigger conditions;
- exact commands;
- known pitfalls;
- verification steps;
- expected outputs;
- when not to use it.
That is why “more skills, less prompt” works. Each skill removes future explanation cost.
The user no longer has to say:
“Search the issue, inspect the repo, don’t touch unrelated files, run the narrow test first, use the project package manager, summarize only the changed files…”
The skill carries that operational memory.
A mature agent environment is not one giant prompt. It is a small router plus many well-scoped skills.
Agents can write their own ratchets.
The interesting next step is self-improving skills.
A browser agent that fails on the same website should not rediscover the DOM every run. It should study its trace, extract a strategy, add deterministic helpers, try again a few times, and eventually graduate the stable procedure into a skill.
The loop looks like this:
- objective;
- run;
- study trace;
- update strategy;
- iterate with a low cap;
- converge;
- write skill.
The low cap matters. Production systems should often stop short of theoretical optimum. Three to five iterations plus aggressive short-circuiting is usually better than an unbounded “be smarter” loop.
Reliability comes from bounded learning, not infinite reflection.
Once a skill exists, the runtime does not care whether a human or an agent wrote it. It only cares whether the skill is readable, scoped, and verified.
Verification is the hard floor.
The ratchet is incomplete without external checks.
Agents are persuasive. They can report success before success exists. They can pass easy tests while hardcoding the answer. They can summarize logs in a way that hides the actual failure.
So the system needs thin, boring, non-negotiable gates:
- tests decide whether code works;
- linters decide whether style passes;
- typecheckers decide whether types hold;
- screenshots or browser traces prove UI state;
- git diff proves scope;
- CI decides merge readiness.
The LLM can reason inside the contract. It should not be the contract.
This is the Thin Agent pattern: let the model do local reasoning, but let external systems own truth.
The product implication
The future of agent engineering is less about prompting and more about maintaining a living harness.
The daily work becomes:
- watch failure modes;
- convert repeated failures into artifacts;
- delete obsolete artifacts;
- keep verification outside the model;
- make successful paths reusable;
- keep human attention away from raw noise.
This is not glamorous. It is infrastructure gardening.
But that is the difference between a demo and a system.
A demo impresses once.
A ratchet makes the next run cheaper.