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.