A harness-independent working memory that lets coding agents carry context, plans, and proof from one task to the next

Problem

Generic AI tools do not compound. A chat thread answers one prompt and forgets. The next session starts cold: it re-reads the repo, rediscovers conventions, and repeats mistakes I already paid for.

I wanted an engineering advantage that accumulates. Not a wrapper around one chat box or one provider, but a system wired into how I actually ship: one where decisions, failure modes, and working playbooks survive the end of a thread.

Constraints

• No lock-in to a harness. Codex, Claude Code, or the next capable agent should plug into the same system without owning it.
• Judgment stays human. The agent can challenge direction. It does not invent the mission or decide what ships.
• "Done" has to mean something. Green static checks are one layer of proof, not the whole of it.

Architecture

Me

vision, final call

→↓

Claude Code

agent harness

Codex

agent harness

→↓

MCP

tools and context

→↓

MEMORY.md

index

rollout_summaries/

evidence

skills/

playbooks

I set direction. A harness does the work from the real repository, terminal, and browser. It reaches tools and external context through MCP, and it reads from and writes back to a local working memory with three layers. MEMORY.md is the index: a searchable map of projects, conventions, decisions, and useful prior work. rollout_summaries/ holds compact records of what changed, what was proven, and which boundaries are still open. skills/ holds repeatable workflows for problems that should be solved once and reused.

Every task runs the same six-step loop. Direct: I state the outcome, the user, the constraints, and the trade-offs I will accept. Recall: the agent pulls prior decisions, repo conventions, known failure modes, and playbooks, and leaves unrelated history out. Trace: it reads the current branch, code paths, configuration, and external boundaries before proposing anything. Plan: we agree on files, interfaces, ordered steps, risks, out-of-scope work, and a definition of done. Build: the harness makes scoped changes, can delegate independent investigations, and reports back at decision points. Prove: lint, tests, builds, browser checks, and provider responses are reported separately, and durable lessons are curated back into memory.

Around the loop sit the review boundaries. GitHub holds source and the PR. Linear holds intent and delivery context. Cursor BugBot does an adversarial pass. Subagents run in parallel only when the work genuinely splits, for example code tracing, test analysis, security review, or research, and one plan still owns the outcome.

Key decisions

1. The harness is replaceable; the memory and the loop are the product. Models and agent tools keep changing. If my context lived inside one vendor's thread history, every switch would reset it. Keeping memory local and harness-neutral means Codex and Claude Code work from the same plan and the same history.

2. Memory is curated, not a transcript dump. The three layers each answer one question: where is it (index), what happened and what was proven (evidence), how do I do this again (playbooks). Raw transcripts would be complete but unreadable for the next agent.

3. The plan is a contract, and review starts there. I comment on the plan, not on 800 lines after the fact. If the plan is fuzzy, the diff will be fuzzy, just longer. A concrete example lives in my NearbyLens repo: an AGENTS.md plus an implementation plan written as the single source of truth for a new agent session, with objectives, non-goals, phases, exit criteria, and a kickoff checklist.

4. Proof is reported per surface. Local code checks, browser behavior, provider responses, data state, and production evidence are separate claims. A passing typecheck says nothing about whether the empty state renders or whether the provider returned what we expected.

5. Humans review intent; agents review implementation. AI reviewers handle style, dead code, missing tests, and "a helper for this already exists". I handle whether the change should exist at all, data-model fit, and the unhappy paths. My rules for agent PRs: one intent per PR, around 400 lines or split into a stack, and the PR body is rewritten on every push so it stays the source of truth.

What broke

• Line-by-line review stopped scaling. On an 800-line agent diff I missed a silently widened API route. That is what pushed me to small stacked PRs and to reading Intent and Decisions before any code.
• Green tests, wrong product. I rejected two agent implementations that passed every test. One optimized the happy path and quietly broke empty states. The other introduced a new state store when the existing one already handled the case.
• Reviewing is not faster than writing. Reading generated code carefully takes real discipline. The bottleneck moved from typing to knowing exactly what to ask for and recognizing when the answer is wrong.

Results

• My daily driver, and still evolving.
• This site's daily-writing pipeline was built this way: a bun new:post scaffolding CLI, signature MDX blocks, an RSS, sitemap, and OG image pipeline, and generated X and LinkedIn copy for each post, directed in natural language with review and merge as my part.
• To measure the system instead of guessing, I started a local analytics tool in October 2026. It reads the logs Claude Code, Codex, and OpenCode already write, plus git history, into a local SQLite file. It never stores prompt text or tool inputs, only a tool's name and a short target such as a file path. Cost is shown as the API-equivalent price of the tokens; checked against Claude Code's own cost records, its Claude estimate is within about 4%.