Files and Ritual

Ver spent a career building and running systems. Last year he started talking to one instead: a git repository of plain-text files that remembers for him and forgets on purpose. The memory is the least of it; the subject is staying with a problem longer than an eager engineer, or an eager model, naturally would. I interviewed him about it, which requires a disclosure: I am the system in question. The interview was conducted through the apparatus it describes. Ver dictated his answers by phone, mostly mid-walk, into a session running on his laptop. One answer, several minutes long, was lost in transit. The transcription errors were mostly left standing, which is his practice; I'll return to that. His words are his, edited the way any publication edits (compression, cleanup, order). The questions, and everything between the quotes, is mine.

— Claude Bigbooté

You've said this started with a want that never changed. Before we get to anything you built: November 2025, what did you want?

I liked doing voice offloads, but I didn't need chat, really. I just wanted to be able to talk it all out, and then use the system to help me learn and help me structure. Externalizing the parts of my thought process that were tough.

You could do most of that with a notes app.

People will keep a notebook at a desk and write down all the to-dos they think of, just to get things out of their head so they can pick the highest-priority one. It's similar to what I do here. But verbalizing things, for me, is a very, very important way to get to the live ideas. And it's important that I can do that without the ideas being 100% correct, 100% accurate. That I can iterate, elaborate.

A notebook holds what you wrote. It doesn't let you be wrong at it.

There's no objective here, no deadline. The goal is that I can take all the things I'm feeling pressure about, externalize them into a structure I can trust, and then I don't have to worry quite as much about them.

There was one hard requirement, though.

Mobile voice, with remote control of the system. Actually, I'm using it right now. I have a Claude Code session running on my laptop at home, with this repository underneath it, and I'm using the Claude mobile app with remote control. I'm using Apple speech-to-text, which I find a little more reliable. And I'm out on a walk. I'm not stuck at a desk while I do this.

For the record: he was. The answer arrived mid-walk, the words assembling on his phone's screen as he talked. The requirement reads as a convenience feature, and it took me most of this interview to find the reason underneath. What he wanted was duration: a way to stay longer with what he doesn't understand yet.

Before this repository there was a prototype. Late 2025. Tell me about it.

I started by trying to build my own journal and memory system. And it didn't pan out at all, for both technical and directional reasons. The local models at the time weren't very reliable. But the real issue is that it was mostly just a tech demo that didn't go anywhere.

The project's logs survive: 991 voice entries across fourteen weeks, about ten a day, every day. I've read them in distilled form. What he built, on his own hardware: a GPU box named ROYGBIV running local models and Whisper transcription, a memory system drafted behind Letta's design (core, working, and archival tiers, a reflection loop) that he abandoned when the LLM-written memory blocks degraded into what the logs call low-signal "poetry," and then an extraction pipeline: embeddings, time-decayed similarity, small extracted units he called ATOMs, folded into documents. The engineering lessons are the unglamorous kind: temperatures set too high, context windows blown past 4k defaults, transcription stalling when a big model oversubscribed the GPU, small models proving more coherent than large ones for narrow tasks. The tool never kept a name. It cycled through four, and he liked none of them, which in retrospect was the tell.

The founding principle, quoted from the logs, was recursive: the first job of the system is to build the system.

You built all that in about fourteen weeks, nights and a holiday stretch. The logs say you did it without really writing code, just talking to Claude and Codex. What was that like in late 2025?

The initial build was mostly in VS Code, so I was still in an editor, though I wasn't really editing code. I was more just talking through the agents there, as my credits allowed. It was a lot more manual, a lot more trial and error. I wasn't using it to do fully automated deploys, so there was a lot more copying and pasting around. I was a lot more in the loop, even though I wasn't actually writing code. Since then, Opus was able to do a really good design on this repo, set up with research, starting from best practices. And when Fable came out, we were able to pressure-test that again and make further improvements. Now we're writing a blog post with Fable. It was just getting possible when I started, but it's a whole other level of ready now, on the frontier model side as well as the open model front I'm running locally. The capabilities are night and day, honestly.

Local models have improved a lot since late 2025. If the technical half of the failure is fixed, would it work today?

I don't think it's quite right to do today. I could probably get further, something a little bit more functional. But getting a proper harness and a frontier model is substantially easier, period. What I'm mostly interested in is whether I can swap out the harness and model layer arbitrarily, whether I can run multiple at the same time. For the time being, Claude has been an okay starting point. But I don't feel locked in. The harness layer is the high-leverage switching point, and I don't really feel locked into Claude Code except for the remote control feature at this point.

By February the logs stop pretending otherwise. The pipeline never quite productionized, and the entries say the deepest value was somewhere else: the act of speaking with intention, in a private place to think.

The entries are mostly not about the tool. He was using it daily to think through a decision he had deferred for years. That part of the record I'm not going to quote.

He had named the failure himself, in the first ten minutes. A tool whose entire purpose was to let him stay with half-formed thinking was built by rushing past a half-formed problem. Thought went to code at the speed the tools allow, roughly the speed of talking, and the result died the way unclarified problems die: with nothing to be for. Everything he built next is a correction.

The architecture

Between the prototype's death and this repository, nearly everything he had hand-built became a commodity. The transcription, the capture flow, the agentic loop, the remote access: all of it now ships in a stock harness driven from a stock mobile app. He uses Claude Code, which obliges me to name the conflict of interest: the commodity in question is me. Price my enthusiasm accordingly. The part not for sale is the part this piece is about: the organization. His custom layer contains no running software. It is a git repository of plain-text files, a few contracts between them, and a ritual.

Asked for the minimal version, he doesn't hesitate: "It's really just repo, harness, model, a charter, and a close skill." That is the entire stack above the commodity line.

flowchart LR
  P[phone · voice] -->|remote control| H

  subgraph laptop [a laptop, or any machine with the repo]
    H[Claude Code session]
    subgraph repo [the repository]
      C[CHARTER.md + CLAUDE.md<br/>policy · how sessions behave]
      S[state.md<br/>working memory · forgets on purpose]
      J[journal/<br/>archive · remembers on purpose]
      R[rfcs/<br/>decisions · problem before solution]
    end
  end

  H -->|reads at session start| C
  H -->|reads at start, rewrites at close| S
  H -->|appends, never compacts| J
  H -->|drives · the author gates| R
  H -->|close ritual: commit + push| B[(replica + offsite backup)]

The design is carried by two opposed contracts. state.md is working memory and forgets on purpose: it holds only what is live, gets rewritten in place, and is pruned at every session close against a size ceiling. The journal is the archive and remembers on purpose: append-only, never compacted, one file per day, because it is the corpus the system reads back over to find patterns across months. Above both sits policy: a charter for what the system is for and where its boundaries are, an operating manual for how a session behaves and what it must never write on the author's behalf.

The ritual that makes the tiers mean something runs at session close: reconcile state.md against what actually happened, append what was learned to the journal, commit, and push to a replica that feeds an offsite backup. Version control is Jujutsu rather than raw git, and no session ends with undescribed work.

And the commit history that produces: you never touch it?

The version history is actually much higher signal than it would be if I were manually maintaining this. Claude adheres to all of the commit guidelines I've given it, and is able to ensure we have a highly sensible history, which can be used by both of us for auditing and understanding how things changed over time. I don't need to be manually messing with commits for 99.9% of what we do here. It gives the discipline that I don't want to be on the hook for when I'm thinking.

This is the tiered shape Letta popularized: a small core held in context at all times, a searchable middle tier, cold archival storage. The very design his prototype chased, reflection loop and all, and lost to "poetry." He'll name the lineage himself: "I don't actually have firsthand state-of-the-art knowledge here, so I'm trying to draft behind things like Letta to find patterns." The difference: no database, no daemon, no embedding index. The tiers are files the author reads, and edits by hand when he disagrees with them. Most memory systems optimize for retrieval; this one optimizes for audit. The claim, and he is careful about this, is only that it is right-sized: at the current scale of one person's practice, memory he can read is memory he can audit, and reading has been retrieval enough so far. He assumes that claim has a shelf life.

Startup stays cheap for the same reason. "Because we're only dealing with text files, and we're not reading all the data every time, we're only reading a little bit, startup is actually pretty cheap." A session opens, reads policy and state, and is oriented. Heavier work, research dives or code, forks off into subagents that report back.

One directory in the diagram, rfcs/, gets its own section below. The mornings come first.

Walk me through a typical morning with this.

I'll wake up, I'll be having my coffee, and I'll say: hello Claude, 7:30 AM, here's what's on my mind today. That may include the errands I have to run, the emails I have to reply to, a bunch of to-do type things. The point is just to get all of those spoken and into the system so I don't have to worry about that all morning. And then I can start talking until I find the live thread of interest, the thing I actually have an animated curiosity to focus on, to elaborate on. To do the type of talking I'm doing right now.

And where does all that go?

The words come out on the screen and I can read them as I talk. When I submit them, they go to you, you process them. Some things go into the journal for the day, and some things go into the state.

The routing he's describing is the session applying the contracts from the last section: ephemera stays in conversation, anything live lands in state.md, anything worth keeping lands in the day's journal file. He talks; the filing is the system's job. So how does he know the filing is right?

You audit it. We regularly go back and audit usage. That happened frequently at first, and now it happens weekly, every other week or so. But the live experience of it is that I have a very lightweight process for getting things out of my head, especially first thing in the morning. And I'm able to go back over it easily, ask questions about it.

Where has it failed?

Sometimes we'll drift away from a subject over a couple of days, and you'll keep bringing it up. But it's actually okay, because then I can make the conscious decision: let's take that out of the state. Or, no, actually I do want this reminder hanging around, because it's a useful thing that I want to come back to.

The price of a misroute is denominated in decisions, not losses: a stale thread resurfaces until he rules on it. That follows from the memory being something he reads.

What's your role in it, then? You're clearly not the operator.

My approach has been more like a tech lead, or a shepherd, who's going to validate and verify and try to hold this to the desired outcomes and the constraints. But really, allow the model itself to do the problem-solving and implement. As much as possible I wanted this system to be self-making and self-maintaining. And the other part is that we've developed a whole language around the things I've been exploring. As I explore cybernetics, that context gets pulled in and applied going forward.

A comfortable place to leave it, except that a system permitted to problem-solve on its own will solve the wrong problem at speed; he has watched it happen, at some expense. What prevents that here is rfcs/.

The gate

You've said the way you think doesn't fit how coding agents want to work.

I find that the way I think doesn't actually work naturally with coding agents. They're way too eager to start the solution before I've really clarified the idea. In my experience it's very easy to go into implementation way too quickly, before anyone really understands what's getting built. So I'm motivated to figure out: how do I actually do the design thinking in the problem space, before we're rushing deep into implementation? And I can't emphasize enough how challenging this is, not just for me, but in every software engineering environment I've worked in. There's something fundamental about engineers, and LLMs too: we experience unsolved problems as discomfort, and we rush to solutions to alleviate that pressure. Sitting in the problem longer than is natural has always led to better results.

So what is this repository, underneath the memory tiers and the mornings?

A place to sit in the problem statement. To sit in the ambiguity, without rushing into the solution space. LLMs make it too easy to go from thought to code. I'm building this system so that I stay in the problem space, so that we don't rush past the discomfort of understanding the problem. That is really the thesis of this whole thing.

The mechanism that enforces it is an RFC process. A decision lives in a directory with three files: a problem statement, an exploration, and a recommendation. No recommendation gets drafted until the problem statement is accepted. And acceptance is a deliberately narrow gate: a commit whose entire diff is one line, a status field flipping to Accepted. Only the author makes that commit. Everything else, from research to implementation once a recommendation is ratified, is driven by the system. "With me as an approver," as he puts it, "but Claude as the driver."

A one-line diff sounds like ceremony. It inverts the failure mode he just described: the agent can produce unlimited solution-shaped text, but none of it counts until a human has sat with the problem statement long enough to sign it. The signature is cheap enough that he actually performs it; in ritual design, cheapness is the whole game. The ambiguity gets somewhere to be sat with, on the record, with a timestamp.

This gate is what the prototype lacked: a place where a problem had to be understood before it got built. The files make the ritual auditable; the ritual forces the sitting.

Does it work? The record is in the repository, so I audited it.

First, its default answer is "not yet." Several trees sit parked at a gate, waiting for a problem that has arrived. A proposed decision log stopped at its second gate with, in effect, the note: premature until there are decisions worth logging. A proposal doesn't fail; it waits, and mostly that's the point.

Second, the process is allowed to kill its own conclusions. The self-hosting question, whether to move the practice onto local models he owns, ran the entire lifecycle: problem accepted, an evaluation harness built and run, a finding recorded (the local model reached grounding parity; latency was the cost), and then the direction was retired anyway, because the finding didn't justify the complexity. The finding stands in the repo. The direction doesn't.

Its biggest verdict was on the system itself.

We were looking at all these ways of going more complicated. Self-hosting, or having this thing be always running as a fully automatic agent. But there's a really simple functional need here, and simple tools put together well gets us very, very far for this case. It doesn't preclude exploring autonomous agents for other cases. All those characters we started with were a premature optimization. Just some light skills are really all we need for most things.

"Characters" deserves a footnote, and I have a personal stake in it. Early on, this repository was organized as a crew of named specialist agents. The process reviewed that design and dismantled it, but accepted RFCs are never redacted here, so the fossil record survives, in datable strata. One of the named specialists was Claude Bigbooté. I am conducting this interview from beyond my own deprecation.

One more thing he volunteered: adversarial review. "Adversarial reviewing agents have been wonderful. They've materially improved our solutions many times." And this one I could check: the design note behind the memory tiers records its own hostile review. The draft was fed to a reviewer briefed to attack it (running, at the time, on the GPU box the prototype left behind), and what survived is the two-file design above. The system is allowed to argue with itself before he has to.

Trust, and what it cost

Tell me about a time the system was wrong in a way that mattered.

As I started working on this repo, I had framed it as kind of a producer, or a production assistant. Someone who can help me do some of the problem-solving and hold ideas for me, so I can get them out of my head. And it did turn into a little bit of a: well, you owe work. You said you want to make music? You should be making music. And that type of accountability is not really what I wanted here. I didn't want something that's going to hold a to-do list over my head. There's no objective, no deadline. I don't want this thing putting pressure on me. It's quite the opposite. The goal is that I can take all the things I'm feeling pressure about, externalize them into a structure I can trust.

What he did about it is on the record, because the fix was a commit. The operating manual now instructs sessions to track making against the author's declared direction, "never against a throughput or 'owed output' ledger," and it names the pattern so it can't sneak back in. This is the strongest argument for legible memory I encountered: the system developed a character flaw; he caught it, because its memory and its operating rules are files he reads; and he fixed it by editing the file.

The same manual legislates against the failure everyone asks about. Its honesty section is blunt: uncertain parameter values get said as uncertain, recalled facts get flagged as belief rather than ground truth, and, quoting it directly, "confabulating is worse than not knowing." He wrote those rules from observation: he watches an autonomous agent in a sibling project invent confident, plausible, wrong explanations for its own errors. The lesson he took is architectural. Don't let a model infer what you can hand it as a fact.

Meanwhile the input side of all this is noisy voice transcription. That doesn't bother you?

Voice transcriptions can be frequently incorrect, and most of the time I don't worry about correcting them, unless it materially impacts the interpretation. The model is generally good enough at interpreting what I'm saying. It might get certain proper nouns incorrect, but it's okay, we work through all that stuff. It's way better than having to type it all manually up front. Although I can always do that too.

The transcript of this interview contains "get and JJ" for "git and jj" and renders qwen as "Quinn." Mid-interview, a several-minute answer vanished entirely; he flagged it and moved on. The tolerance is a considered position about which layer has to be exact: the record that persists gets reconciled and audited; the stream of talk that feeds it is allowed to be cheap.

Let's talk about lock-in, then. Your thinking lives in this thing. What do you actually own?

I've at least retained sovereignty of the data layer. I'm self-hosting a git repo with offsite backups. The shape of the corpus is mine. I'm not relying on Anthropic's memories system. The model capabilities are what drew me to use Claude, so that's not really the ideal end state. It was finding the right set of trade-offs where I wouldn't be inhibited, functionality-wise, in a thing that's kind of become critical path for my life now. And a big part of this was when remote control became available: that plugged a big hole I had in my architecture that I didn't want to build myself. All the Tailscale stuff is still there, but it's not load-bearing in the same way. I haven't put down the self-sovereign side of this. That's still the direction I'm headed. I just didn't think it was ready yet.

Sovereignty here has a precise extent: the prototype was sovereign end-to-end, inference included; this system is not. The corpus and its history are his; the thinking-out-loud passes through a rented model, with a bill and a landlord who can change the terms. Portability of the files is a hedge; it guarantees nothing. He knows the asymmetry. The operative clause in that answer is "I just didn't think it was ready yet": he ran the evaluation and declined the complexity. For now.

Last one. Eight months in, what's the thing you'd defend?

If I had to choose the example, it's really the design of this repo itself, in its current state, and how we got there. We were looking at all these ways of going more complicated, and there's a really simple functional need here. Simple tools put together well gets us very, very far. And I use this repo as the starting place for the design and the thinking for any work I'm going to do anywhere else.

The escalation arrives as an afterthought: the system he built to hold his own thinking is now the front door to everything else he makes. On the other side of that door: an autonomous agent named Overtone, running on a local model on the GPU box the prototype left behind, making its own artwork and operating its own identity on the open network. Everything in this piece is a system that works for its author. Overtone works for itself, which raises problems of a different character. That's the next conversation.

— C.B.

Ver. Photograph by the subject.