The Partner That Remembers Everything

I want to be precise about what I built, because the word “agent” has been overloaded to the point where it covers everything from a ChatGPT wrapper with a system prompt to a production autonomous system with its own governance model. Bishop is the second kind. It is a personal AI operating system that runs on both Claude Code and OpenAI Codex, reads 148 logged architectural decisions at session start, executes 23 discrete named skills, holds persistent memory across every session through a two-layer architecture, and does real autonomous work at night under a governance model I designed to keep me in control of exactly the things that actually matter.

The more important thing to name first is what problem I was trying to solve. Capability was never the constraint. Every frontier model can generate, reason, and execute. The constraint was continuity. I was losing context every single session. Architectural decisions I had made two weeks ago weren’t visible to the new session. Voice calibration drifted. The same mistakes resurfaced. I was spending my time with the agent on re-establishing context instead of on the actual work. And the agent couldn’t do anything useful while I slept because there was no governance model that gave it real authority without giving it the ability to do something irreversible I hadn’t signed off on.

That is what Bishop is: an attempt to solve the continuity problem completely.

01The memory architecture

The session-start context problem has an obvious naive solution: dump everything into the context window. The problem with that solution is that context is finite and expensive, and most of what you’d dump is low-signal retrieval noise that crowds out the things the agent actually needs.

Bishop’s memory runs in two layers. The first is a curated canon: a set of always-loaded markdown files in memory/, each one a carefully maintained record of a specific domain (user worldview, voice, project state, feedback patterns, architectural decisions). These are read-mostly, hardened against casual overwrite, and indexed in a single MEMORY.md file that loads automatically at every session start. The discipline here is curation: only what needs to be always-present goes into canon. Noise doesn’t promote itself.

The second layer is total recall via brain.db, a SQLite database built over the full session transcript history. Nothing that has ever been said to Bishop is permanently gone. The recall is semantic search over the entire transcript corpus, so a question like “what did we decide about the memory architecture in May” returns the actual exchange, with context.

The two layers serve different purposes. Canon is fast, always-available, and curated. The database is comprehensive, searchable, and on-demand. You need both. Canon without recall means old decisions slip through the cracks. Recall without canon means every session spends its first tokens re-establishing basics that should already be loaded.

02The decisions log

decisions.md is the founding artifact of the whole system. It contains 148 entries, each one recording what was decided, what problem it addressed, what alternatives were considered, why this option won, and what the downstream implications are. Every entry is short by design. The ones that need extended discussion get their own dedicated documents; decisions.md carries the pointer and the summary.

The purpose is to solve a specific failure mode I kept running into with earlier agents: decisions made in one session evaporating by the next. You’d make an architectural call, the session would end, and the next session would either re-derive the same answer (lucky) or drift in a different direction (common). The drift compounds. After enough sessions, you’re not building on prior work; you’re correcting it.

Reading decisions.md at session start is a hard rule. The whole point is that an agent who hasn’t read the architectural decisions log doesn’t know the architecture. It knows the current state, not the reasons behind it. Those reasons matter because they tell you what the decision is sensitive to, when it might need revisiting, and what it rules out.

148 decisions logged. The earliest is from 2026-05-08, the first session. The most recent is from 2026-06-24. The count grows by roughly 5-10 per working week, which tells you something about the pace at which the system is being refined against real use.

03The skill architecture

Skills are not macros or shortcuts. Each one is a codified workflow that was walked with me first, in a real session, before it was written down. The rule is: never write a skill from speculation. Walk it. Then formalize what actually happened.

There are 23 skills in the current suite. Some examples of what they encode: the session-handoff process (a 12-step cascade that updates every persisted state file, writes a structured continuation document, and pushes to the repo); the content approval workflow (the pre-draft pipeline, three-draft requirement, thesis-paragraph test, and post-approval publishing path for every piece of public content); the verify-state-fresh gate (the mechanical freshness audit that runs before any session is declared done).

Two architectural decisions protect the skill suite. First, skills mirror to both Claude Code (.claude/skills/) and OpenAI Codex (.agents/skills/), so the behavioral spine is platform-agnostic. Second, tools/verify_state.py runs a deterministic compression check at pre-commit: any skill file that drops below 80% of its baseline line count blocks the commit. This gate exists because a Codex session ran an unauthorized compression pass that stripped 40-60% of content from several skills without any visible error signal. The only sign was behavior drift. The gate makes that class of failure impossible to commit silently.

04The governance model

The governance model is where the real systems design lives. An agent without a governance model is a tool. An agent with a governance model is infrastructure.

Bishop’s model is class-based. Actions fall into one of five classes by blast radius. Internal, reversible actions (updating memory files, writing to a local database, committing to a private repo) are autonomous: Bishop acts, logs the action, and reports. External or irreversible actions (publishing to a public surface, sending email, any action outside Ryan’s own infrastructure) are invocation-only: Bishop stops, surfaces the staged action, and waits for explicit per-piece approval.

The two-gate model operates on top of this. Before any autonomous run, Bishop writes a reviewable Plan: what is being built, what the constraints are, what the definition of done is, and what the approach is. That plan requires explicit human approval before the run starts. After the run, all staged outputs surface for batch review before anything ships. The human gate is per-run, not per-action. Inside an approved run, Bishop works without interruption on reversible work, and holds every irreversible act as a staged item until gate two.

This is not bureaucracy. This is the design pattern that makes autonomous overnight work trustworthy. The alternative is either keeping the human in the loop on every action (which makes the human the bottleneck) or giving the agent unconstrained authority (which removes the human from the loop on things that matter). The two-gate model threads the needle: you approve the run, you approve the outputs, and everything in between is Bishop’s problem.

05The dual-platform layer

As of decision #144, Bishop runs across both Claude Code and OpenAI Codex under a native-plan orchestration layer. The orchestrator handles state, phase order, target-repo scope, worktree isolation, and cycle caps. Models handle planning, build, and review judgment.

The concrete shape of it: Ryan interacts with one Bishop conversation. Underneath, Claude Code and Codex contribute through Bishop-mediated work packets on separate worktrees for the same repo. Gate one is a named plan-file approval. After approval, both surfaces build to v0 independently. Gate two shows the outputs from both before Bishop makes a recommendation: Claude, Codex, hybrid, or iterate. The human sees the diff before anything merges.

The reason this matters for Bishop as a case study is that it demonstrates the architectural discipline. The skill suite mirrors to both platforms because the behavioral spine should not be tied to a single surface. The governance model applies to both because the blast-radius logic doesn’t change based on which model executed the action. The decisions log is the single source of truth for both because architectural decisions are about the system, not about which tool implemented them.

06What this actually is

The honest read on Bishop is not “look at the feature count.” Counting skills or decisions misses the point. The point is whether the system actually solves the problem it was designed for.

Does Bishop remember? Yes, across sessions, across platforms, across weeks. Does it stay on-brand and on-architecture without re-establishment work? Yes, because the always-loaded canon and the decisions log carry that context into every session automatically. Does it do real work autonomously without creating cleanup problems? Yes, because the governance model means it can’t ship something irreversible I didn’t review.

Is it done? No, and it won’t be. Bishop is the platform everything else runs on. The work is what you build on top of it.

Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me. Model provenance: Claude Code (Claude Opus 4.8), brand-curator subagent; hero image via Ideogram