I built a harness around AI coding agents because better models weren’t fixing the problems I kept seeing
I’ve been experimenting pretty heavily with AI coding agents, and I kept running into the same pattern:
The model was often capable enough to do the actual coding.
The failures were happening around the model.
Things like:
- making important decisions without asking
- carrying too much irrelevant context
- forgetting decisions from previous sessions
- not using the right specialist capability
- modules working independently but breaking when integrated
- saying something is “done” without enough verification
So instead of trying to solve everything with a bigger prompt, I started building a system around the agent.
I called it Escapement.
The basic loop is:
Specify → Route → Execute → Verify → Persist
It’s a repository-native harness that sits around coding agents rather than replacing them.
The core idea is:
Don’t upgrade the model. Upgrade how the model works.
Current v1 is at v6.3.0 and includes:
- 35 native skills
- 58 specialist capability strengths
- 143/143 unit tests passing
- 22/22 routing evals passing
- 4 real-use case studies
- bounded, phase-specific context
- persistent project and multi-module state
- deterministic verification evidence
- security + UI quality gates
- observability
- harness ablation
One thing I’m actively trying to avoid is turning this into a giant framework full of rules nobody has evidence for.
The philosophy has gradually become:
Observed failure → smallest useful mechanism → regression evidence
If agents repeatedly ignore something that can be checked mechanically, I’d rather build a deterministic check than add another paragraph to the prompt.
I’ve also started removing parts of the harness and rerunning the eval corpus to see whether they actually matter.
One component dropped routing performance from 22/22 to 13/22 when removed.
Another produced no measurable difference in the current routing benchmark.
And I actually think the second result is just as useful.
Either the component isn’t helping, or the benchmark isn’t measuring what it is supposed to improve.
Both are things worth knowing.
The biggest current limitation is cross-host evidence.
The strongest real-use validation is still on Claude Code. Codex runtime packaging exists, but I don’t want to call it equivalent support until it has equivalent evidence.
What comes next: Continuum
I’m already working on the next-generation research architecture, Continuum.
A lot of its design is being inspired by ideas from physics, quantum theory, probability, information theory and decision science — not by trying to build a quantum computer, but by asking whether some of those scientific concepts can produce better execution systems.
For example:
superposition → preserve multiple plausible strategies
measurement → gather evidence before committing
contextuality → a capability’s value depends on the state around it
entanglement → coupled state across agents and modules
Value of Information → decide whether more information is worth acquiring
reversibility → govern exploration differently from irreversible action
The broader idea is to move from:
Task → Pick route → Execute
toward:
Intent → State → Alternatives → Observe → Update → Commit → Execute → Evidence
v1 stays independent and stable.
v1 is evidence, not baggage.
Continuum is where I’m testing what comes after it.
If anyone finds this area interesting and wants to contribute — whether through architecture, experiments, evaluations, agent memory, multi-agent systems, RLMs, context engineering or just trying to break the assumptions — I’d be very interested in collaborating.
A lot of the thinking behind this project has also come from researchers, open-source developers and AI creators who make their experiments and ideas public. That ecosystem has been incredibly useful.
I’m posting this mostly because I want criticism.
What feels over-engineered?
What would you remove?
What harness-level failure modes are you seeing that better models still don’t solve?
Repo: