What I actually built

A memory
that survives the
context window.

Every Claude Code session starts blank. So I built the layer that makes it not start blank — a curated brain of facts, scars, rules, and narratives that loads at the right time, in the right amount, so each session opens already knowing my repos, my voice, my landmines, and how I like to work.

5
Layers
7
Always-on rule files
40+
Skills / slash cmds
4
Obsidian vaults
6
Self-logging CLIs
1
Governing law
claude — new session

The five layers

Think of it as a stack. The top layers are always loaded (cheap, tripwire-dense). The bottom layers are loaded on demand (deep, narrative). The whole design is a fight against one enemy: context is finite, so what's always-on must stay small.

▲ ALWAYS LOADED — every session · cheap · tripwire-dense MEMORY.md the index — one line per fact ⚠ invariants · 🔓 open items → pointers to everything deep ~/.claude/rules/ ×7 collaboration · code-workflow voice · notion · harness · llm-pair how I act, every session pitfalls_general.md the scar tissue — headlines only git auth · agent collisions terminal death · stale origin THE LOAD-COST BOUNDARY ▼ LOADED ON DEMAND — pulled in only when the topic is relevant memory/*.md facts project_ · reference_ feedback · user · one fact/file *_detail.md forensics pitfalls_general_detail one scar file per client Obsidian ×4 vaults one vault per client + the business & projects /recall tiered retrieval — grabs the ## Current View first memory-lint.sh deterministic hygiene — broken pointers, dead links project_*.md deep files the long story behind each ongoing thread → AUTOMATION spends the accumulated brain outward, on a schedule /nektar-drafts · /pb-newsletter · cos-agent · client reports · newsletters
The whole architecture on one line: a small always-loaded ceiling points down into a deep on-demand corpus — and the boundary between them is defended by The One Law.
Where the context window goes illustrative — the point is the shape
0the finite context window100%
always-on (index + rules + scars) — kept small on purpose on-demand (wiki + detail + deep files) headroom for the actual work
Layer 1 · always-on

Memory Index

MEMORY.md — the headline map. One line per fact, invariants (⚠) and open items (🔓) only. Pointers to everything deeper.

Layer 2 · always-on

Rules

Behavioral law in ~/.claude/rules/*.md. How responses get shaped, how git is handled, my voice, the delegation policy.

Layer 3 · always-on

Pitfalls

Scar tissue. pitfalls_general.md — the mistakes made once, encoded so they're never made twice.

Layer 4 · on-demand

Obsidian Wiki

The narrative long-form. Per-client vaults with the why and the story, pulled in via /recall.

Layer 5 · on cadence

Automation

Scheduled jobs that turn the brain outward — weekly drafts, newsletters, client marketing reports, a daily brief.

The one-sentence version

A tiny always-loaded index points to a large on-demand corpus; strict rules keep the always-on part small; automation spends the accumulated knowledge on a schedule. That's the whole system.

01 · How a fact lives and dies

The capture → recall loop

Nothing here is magic. It's a plumbing loop: something happens in a session, it gets classified, written to the right home, and then surfaced again the next time it's relevant.

1 · HappensSessionA bug bites, I correct the model, a decision lands, something ships.
2 · ClassifyWhich kind?Fact? Feedback? Scar? Narrative? Task? Each has one correct home.
3 · WriteRoute itMemory file · rule · pitfall · Obsidian · Notion. One write path each.
4 · IndexPointerA one-line hook lands in MEMORY.md so it's findable later.
5 · RecallNext timeLoads automatically (always-on) or via /recall (on-demand).

Where each thing goes

When this happens…It becomes a…Written toLoaded
You correct me / give guidancefeedbackmemory/feedback.mdalways-on
A durable fact (schema, path, naming)project / referencememory file + MEMORY.md lineindex always, detail on-demand
A mistake that cost timepitfallpitfalls_*.mdgeneral always, detail on-demand
The story / why behind worknarrativeObsidian vault (/obsidian write)on-demand via /recall
Work to be trackedtaskNotion Work Trackerqueried on request
A behavioral norm ("always do X")rule~/.claude/rules/*.mdalways-on (or paths-scoped)
The controls that keep it honest

/wrap sweeps a session for anything that slipped through · /recall <topic> pulls the right narrative efficiently · memory-lint.sh catches broken pointers and dead links. The old weekly-cron "audit → queue → maintain" machinery was retired — it manufactured busywork and drained nothing. Prompt-level discipline + these three deterministic checks replaced ~1,200 lines of shell.

02 · Layer 1

Memory — the index & the facts

One fact per file. A tiny always-loaded index (MEMORY.md) holds only headlines, invariants, and open items — and points to the deep files that load only when relevant.

The index — always loaded

MEMORY.md

Legend-driven shorthand keeps it dense. Each line is headline + invariant + open item + pointer. The full story lives in the pointer target, never in the index itself.

The corpus — loaded on demand

One-fact files

project_*.md · reference_*.md · feedback.md · user.md. Frontmatter tags each: user / feedback / project / reference. Linked to each other with [[wikilinks]].

The legend — reading the shorthand

invariant — obey, don't relitigate
🔓 open item — has a task / date
shipped — don't redo
pointer — detail lives here

This is why the index can carry an entire client's state in a few lines. = a tripwire that must stay always-on. = "the rest is one Read away, don't load it until you need it."

Why one fact per file

Granularity is what makes recall cheap. A big blob file forces a full read to check one detail; a per-fact file lets the description in frontmatter decide relevance before anything is loaded. It also makes deletion safe — a wrong fact is one file to remove, not a paragraph to surgically excise.

Hygiene, not bureaucracy

03 · Layer 2

Rules — the always-on behavior

Memory is what I know. Rules are how I act. A handful of files in ~/.claude/rules/ load every session and shape everything from response format to git safety to my voice.

collaboration-rules.md

How to talk to me

Punch line → table → code. Estimates as Low / Realistic / High. Mirror my vocabulary. Preempt the "what about X." Audit before fixing.

code-workflow-rules.md

How to write & run code

One cleanup branch. Inspect stash before dropping. Grep read-sites before renaming keys. Verify infra before recommending teardown. Delegate by default.

voice-and-content-rules.md

My voice & brands

Typos are misses, not texture. Each client's outputs use that client's design system. Personal tools stay unbranded & gated. Source files for image work, not prompts.

notion-workspace.md

Canonical Notion structure

The five real databases, exact IDs, the 6-state status workflow, task-creation API shapes. Stops drift and ghost-DB mistakes.

roadmap-harness.md

Phased execution

The /execute-roadmap-phase machinery — parallel implementer + Codex verifier, score-gated auto-advance.

local-llm-pair.md

Free second opinions

Worker → checker adversarial review on local Ollama models. The /local-llm-review path.

Always-on vs paths-scoped

The files above load every session — that's the expensive tier. Repo-specific rules (one per project) are paths-scoped: they only load when I'm actually working in that repo. New rules default to scoped. Adding to the always-on tier requires shrinking it elsewhere first — see The One Law.

04 · Layer 3

Pitfalls — the scar tissue

A pitfall is a mistake that cost time once, written down so it never costs time again. This is arguably the highest-leverage layer — each entry is a bug you'll never re-hit.

Always-on · headline + tripwire

pitfalls_general.md

Git multi-account auth (token-leak traps), concurrent-agent worktree collisions, terminal-host death orphaning sessions, shell/zsh traps, stale-origin false negatives. The lines you must never trip.

On-demand · the forensics

pitfalls_general_detail.md

The dated incident write-ups — what happened, why, how it was recovered. Read only when you touch that surface. Keeps the always-on file short.

Per-project scars

a scar file per client
plus per-domain detail files

The pattern every pitfall follows

FieldPurpose
The tripwireWhat goes wrong, stated as a warning (⚠ X silently no-ops when…)
WhyThe mechanism — so it generalizes to new cases, not just the one that bit
How to applyThe concrete defense: the exact command, the check to run, the thing to never do
→ forensicsPointer to the dated incident, kept out of the always-on tier
Split by load-cost, always

Headline + invariant stays always-on (small, dense). The story moves to a _detail file behind a pointer. This is the same headline/detail split as memory — because the constraint is the same: what's always loaded must stay cheap.

05 · Layer 4

Obsidian — the narrative wiki

Memory is terse facts. Obsidian is the long-form story — the why behind a decision, the shape of a domain, the running history of a client. Too big and prose-heavy to ever be always-on, so it's pulled in surgically.

Each note links to others with [[wikilinks]]. Recall walks the graph — grabbing the ## Current View first, drilling deeper only when needed.
vault

Client — finance

A specialty-finance engagement — performance, pipeline, reporting narratives.

vault

Client — operations

An operations-heavy business — records, costs, planning narratives.

vault

The business

Nektar itself — voice corpus, prospecting rules, tech stack.

vault

Side projects

Sports-analytics lab, editorial, newsletter voice.

write/obsidian writeRoute-on-write policy decides which vault & page a narrative belongs to.
store## Current ViewEach page keeps a compact top section — the recall target, so I don't read the whole page.
read/recall <topic>Tiered retrieval — grabs the Current View first, drills deeper only if needed.
Why a separate system from memory

Memory answers "what's the invariant?" in one line. Obsidian answers "walk me through how this client's reporting evolved" in five paragraphs. Different questions, different cost profiles, different homes. The ## Current View convention is the bridge — it lets recall be cheap even when the underlying page is long.

06 · Layer 5

Automation — spending the brain

The first four layers accumulate knowledge. This layer turns it outward on a schedule — scheduled jobs and skills that produce real output from everything the brain knows about me and my clients.

Job / skillCadenceProduces
/nektar-draftsweekly · scheduled~4 LinkedIn drafts/wk in my voice, on-brand ICP
/pb-newsletter2×/wk · scheduledNewsletter drafts, emailed for redline
cos-agentdaily · scheduledTasks → vault-grounded triage → ranked daily brief
/client-reportmonthlyA client's website + social marketing report
/wiki-insightson demandCross-vault insight synthesis
The redline firewall

Everything outbound is drafted, never auto-sent. Content lands as a draft for me to redline; email goes only on an explicit go. The automation spends the brain's knowledge — it doesn't spend my reputation without a human gate.

The ergonomics layer — self-logging CLI wrappers

Newer than the rest of this page: six thin command wrappers that each do one repetitive thing correctly and log their own usage, so the brain can measure how much friction it actually removes.

ToolFreezes the repeated…
ghxmulti-account git-auth incantation — org-aware token injection, so plain git push just works
secret / gsecretshell-meta-safe env / GCP Secret Manager value reads (never source a creds file)
bqxdata-warehouse schema lookup + query, one wrapper
test-runnerproject-aware test run
nextfreshclean Next.js dev restart
The system now measures its own value

A demand audit found the same fragile incantations being hand-rebuilt hundreds of times across a few weeks — each wrapper freezes the correct form once. mem-eventmem-value.sh then logs the payoff on a ledger, so the brain measures the friction it removes instead of assuming it. It's the same instinct as The One Law: don't trust that a control works — instrument it.

There's also a growing terminal cockpit — the ai-assistant / cos-agent life-OS, now with a ⌘J chief-of-staff dock and the NektarBee living-presence layer — which is where this whole brain is increasingly getting a face. That's a project in its own right; here it's just the newest consumer of the same underlying memory.

07 · The routing brain

Delegation — advisor / orchestrator / laborer

The system doesn't just remember — it routes work by judgment vs labor, not by "smart model vs dumb model." The failure mode being corrected: burning the most capable model as a bulk file-reader instead of as the judge.

Advisor
Fable 5
The judge.

Consulted only at the hard nodes — plan critique, "should we even do this," adjudicating the survivors of a review. Sees the distilled question, never the repo.

Orchestrator
Opus
Holds the thread.

Decomposes, routes, cite-verifies what delegates claim, synthesizes the final answer. The only tier that talks to me.

Laborer
Sonnet →…
The doers.

Code-gen, file reads, mechanical fixes, repo-scale scans. Fallback chain: Sonnet → Codex → Antigravity → Haiku → local Ollama.

manycheap finders fan out wide
fewOpus dedups + cite-verifies
1Fable adjudicates the survivors
The shape that matters

Cheap laborers fan out wide to find → Opus dedups & cite-verifies → Fable adjudicates the survivors. Same coverage, but the expensive judge sees a short candidate list, not the codebase. One caveat baked in: on money-path / correctness-critical code the finder floor is Sonnet — a cheap finder that misses a bug class means Fable never gets to judge it.

This is why the rules insist Claude delegates repo-scale reads to Codex and routes second opinions through /local-llm-review — it keeps the orchestrator's context clean for the one thing only it can do: hold the whole picture and synthesize.

New axis — tools, not just models

Routing used to be model-only. Now the brain also exposes domain data as first-class tools: a read-only MCP server over one client's domain — 17 tools spanning records, lineage, and transaction history — registered to both Claude and Codex. A cross-app "which line actually outperforms?" question now reaches for a purpose-built tool before anyone hand-writes a database query. Same read, verified, every session — a capability that enters the always-on tier as a tool registration, not another rules file.

08 · The governing principle

The write-side growth cap

Every layer above wants to grow. Left alone, the always-on tier balloons until it eats the context window it was meant to preserve. One law holds the whole thing in check.

Chart corpus grows every session; the always-on tier is held flat under the cap — illustrative
The law

New knowledge lands paths-scoped or skill-loaded by default. Adding to the always-on tier — unscoped rules, MEMORY.md, pitfalls_general.md — requires shrinking something else in that tier by at least as much. Compress opportunistically when you're already editing a file; never as a batch maintenance pass.

Why this is the keystone

What proved it works

Retired machinery

The /memory-audit → queue → maintain cron (~1,200 lines) was killed after a review found its queue 60 entries deep, never drained, 43% reject rate. It manufactured labor and shipped nothing.

What replaced it

Three deterministic checks

/wrap classifier sweep · /recall tiered retrieval · memory-lint.sh. On-demand, no queue, no busywork.

The honest caveat

Prompt discipline decays

The docs say it plainly: prompt-level rules are not a primary control across thousands of turns. That's why the cap is a default, not a hope.

If it's working, you'll see it

Diffs contain only what was asked for · bug fixes ship with a reproducing test · repo-scale reads go to Codex, not the orchestrator · first diagnoses land · wrap-up never sweeps dirty state. If a session ends without those signals, the rules became decorative — and the system says to flag that in-session and tighten the offending section.