A great model is not enough. This is what makes Claude actually reliable in daily operation — and how to build it yourself.
The Problem · The Thesis · Pillar 1 · Pillar 2 · Pillar 3 · Field Notes · Upstream
Important
The claim in one breath: a brilliant model on its own is a brilliant amnesiac. Reliability only appears when three conditions hold at the same time — a model with a provably low error rate, an enforced method around it, and memory that survives the session. This repo is the field manual for building all three, with receipts.
After months of heavy daily use, one conclusion held up: a brilliant model on its own is a brilliant amnesiac. The model is necessary but not sufficient. Three things have to be true at the same time before the quality-of-life jump actually happens:
graph TD
M["🎯 Pillar 1 — Model<br/><i>provably low error rate</i>"]
H["⚙️ Pillar 2 — Harness<br/><i>enforced method, review gates</i>"]
B["🧠 Pillar 3 — Memory<br/><i>survives every session</i>"]
M <--> H
H <--> B
B <--> M
| Pillar | Problem it solves | Reference |
|---|---|---|
| 1. A model that is provably not dumb | Error rate is the deciding factor, not benchmarks-on-paper. A high-hallucination model poisons everything downstream. | Claude · screened via bullshit-benchmark |
| 2. A disciplined foundation / harness | Raw chat has no method. Skills, sub-agents, hooks, and review gates turn a chatbot into a tool. | Claude Code + ECC |
| 3. A persistent brain | Session handoff and compaction are architecturally lossy — detail is silently dropped. Without external memory, every new session starts from zero. | MemPalace |
Miss any one pillar and the system quietly degrades — not loudly, which is exactly the danger. A missing brain wastes your mornings re-explaining. A missing method makes every result a coin flip. A weak model corrupts the other two from the inside: it writes confident nonsense into your memory and waves its own work through your review gates. That compounding is why this repo treats the three as one system, not a menu.
The thesis is tool-agnostic in principle. The stack behind this manual is not: it has run exclusively on Claude — Claude Code plus the Claude apps — for months, and that is a Pillar-1 decision backed by field failures, not brand preference:
- Local/small models failed the memory test. An early experiment let a local small-parameter model write to the persistent store. It filled the store with six figures of plausible-sounding noise; the store had to be rebuilt and the pipeline retired. Half-knowledge delivered with full confidence is not a discount — downstream, it is a liability.
- A competitor failed the validator test. A second-opinion model used to cross-check deep audits invented findings — errors precise enough to look like diligence. A validator that hallucinates is worse than no validator. Dropped.
- Claude passed both, then carried the load. Every fix in the Upstream Ledger — including a merged data-loss fix and a 45s→1.3s protocol fix — was diagnosed, built, tested, and shipped with Claude Code driving the method. The receipts are the argument.
Screen your own model with an objective test (bullshit-benchmark) and draw your own conclusion — that is the point of Pillar 1. This operator's screen has a clear winner.
This is not theory written after a weekend of tinkering. The stack behind this manual runs daily against a 300k-entry memory store on Windows — and the failures it surfaced were diagnosed and fixed upstream in the pillars themselves: a merged data-loss fix, a 45s→1.3s MCP handshake fix, a silent-GPU-fallback fix, and more. See the Upstream Ledger for the receipts and the Field Notes for the full worked cases.
Every stack like this eventually gets a tooling update — a new CLI version, a plugin bump, a machine change. What follows feels like amnesia: the assistant misses things it knew yesterday, guards seem not to fire, paths do not resolve. The reflex is to rebuild and re-index everything.
That reflex is usually wrong, and it is expensive. Nothing was lost. Pieces became quietly incorrect, and nothing in the setup was watching for that. A missing fact makes you search; a wrong fact makes you act on it. Only the second one is invisible.
Warning
Four signs the wiring came loose. Each one produced a green light in the field:
- An update command reports "already up to date" while the installed content differs.
- Notes and runbooks point at paths that moved — worst when the stale one is a recovery runbook, read only during an incident.
- A guard is registered in one scope and never fires in the one where the work happens.
- A check "passes" because it compared against something empty and found nothing to object to.
The fix is not a rebuild — it is a reconciliation check at startup: verify that what the configuration claims still matches reality, stay silent when it does, and be loud when it does not. Read-only, fail-open, and cheap enough to run on every session. Give it a heartbeat too; a watchdog that fails silently is the thing it exists to prevent.
The habit that generalises, and the cheapest question in this whole manual:
For every component you add, ask: what notices if this becomes silently wrong? If there is no answer, the component is unfinished — however well it works today.
Worked case with the measurements: The config that lied.
If you do not want to read the full manual yet, these three rules capture it. Verify each before moving to the next:
- Screen your model before you trust it. Run an objective error-rate check (bullshit-benchmark) and refuse to route consequential or memory-writing work through anything that fails it — no matter how good the demo looked.
- Put enforced method around it. Install a harness (Claude Code + ECC): review gates that always run, guard hooks that block the dangerous defaults, skills for everything you do twice.
- Give it memory that survives the session. Wire a local store (MemPalace) through auto-save hooks — stop, pre-compaction, session-start — so yesterday's understanding loads tomorrow without you re-explaining.
Tip
The fastest way to see the payoff: read the before/after transcripts — same task, same model, one has the brain.
- The Problem — why a great model alone leaves you with an amnesiac genius.
- The Thesis — the three pillars and why all three are mandatory.
- The pillars — one page each: claim, proof from the field, how to build it, how to operate it. Model · Harness · Memory. Build them in this order.
- Field Conditions: Windows — the honest platform gaps nobody else documents.
- Field Notes — worked failure cases, and before/after proof that the brain holds.
- Upstream Ledger — the loop closed: what this setup sent back to its foundations.
- FAQ
This is one operator's lived system, standing on three independent open-source projects and one exceptional agent runtime. Full credit to their authors — see CREDITS. This repo contributes the synthesis, the build path, the field notes — and bug fixes back upstream.
Documentation licensed under CC BY 4.0. Maintained by KeilerHirsch.