Immutable sources
Raw material — transcripts, specs, references. Captured verbatim and never edited. The ground truth an agent can always fall back to.
Reference / How It Works
How It Works
The workflow tells you what the agents do and the council tells you who. This page is the why — the six design choices underneath. None of them are clever. They're the opposite: deliberately small, deliberately plain, and aimed squarely at the two things that make AI agents unreliable — they forget, and they inflate "done." Fix the structure, not the symptom.
1 · The Living Wiki
A plain-text knowledge base the agents tend like a garden — so the same battle is never fought twice.
Most agent setups treat memory as a transcript: a flat log that grows until it's useless. Becky treats memory as a codebase. The knowledge base is a folder of plain Markdown, structured in three tiers that never blur together:
Agent-written pages
Distilled, cross-linked notes the agents author and maintain. This is where understanding accumulates — the part that compounds.
Human-owned schema
The shape of the garden — how pages are named, linked, and graded — stays a human decision. Agents fill the structure; they don't redefine it.
The frame: Obsidian is the IDE; the agent is the programmer; the wiki is the codebase. You don't ask the model to "remember" — you ask it to write down what it learned, where the next reader will look.
Pages grow the way a digital garden does, with an honest maturity label so a reader knows how much to trust a note before they lean on it:
Garage door up: an agent is required to be epistemically honest. When a topic is thin, the page literally says "my notes here are sparse — verify before relying on this" rather than confabulating a confident answer. Admitting a gap is a feature, not a failure — it tells the next agent exactly where to dig.
2 · One Program Per Agent
Each agent is a single English spec with one owned output and one outcome. The orchestration is prose, not plumbing.
Every agent ships as one file: a program.md written in plain English. It defines exactly one job, names exactly one artifact that agent owns, and states the single metric that tells you whether the job is done. Nothing is hidden in framework glue — if you want to know what an agent does, you read its program, top to bottom, like a story.
Writing the orchestration in English instead of code buys three properties that matter when the system runs unattended:
Auditable
A non-programmer can read a program and tell you what it'll do. The behaviour isn't buried three call-stacks deep — it's a paragraph.
Reversible
Don't like a behaviour? Edit a sentence. There's no recompile, no migration — the spec is the implementation.
Forkable
Copy a program, change a verb, and you have a new agent. Specialization is a text edit, not a class hierarchy.
The discipline: one owned file, one metric, and deletion is a win. If an agent's output no longer earns its keep, the right move is to delete the program — fewer moving parts is a feature, not a regression.
3 · Generation, then Verification
Models are great at generating and fast to fool themselves. So the builder never grades its own work.
There's an asymmetry at the heart of working with language models: they're strong generators and unreliable self-graders. A model will happily declare its own output finished — it has every incentive to and no independent way to check. Humans, and a dedicated verifier agent, are the reverse: slow to generate, but fast and skeptical when checking. Becky designs around that asymmetry. The agent that builds a thing is never the agent that signs off on it.
The line that drives it: a demo is
works.any() — it passed once, on the happy path, while you watched. A product is works.all() — it holds on the empty state, the error path, the second user, the slow network. Verification is what closes the gap between the two.To stop "done" from quietly inflating, the verifier reports in three tiers — and they are never collapsed into one number. A pile of AUDITED files is not a working feature, and saying so out loud is the whole point:
DONE means runtime evidence. Not "the tests pass." Not "the file exists." The feature was exercised against a real system and produced a real result. Anything short of that gets the honest, lower label — because a verifier you can't talk out of the truth is the only one worth having.
4 · Rules Compound, Mistakes Don't Repeat
Every serious incident leaves behind a rule — and, where it can, an automated guard that makes the same mistake impossible.
An agent that forgets will re-make the same expensive mistake on a Tuesday three weeks from now. The fix isn't a better memory of the incident — it's turning the incident into a rule. Each P0 produces one: a short, specific statement of what went wrong and what's now forbidden. Wherever possible the rule is backed by automation — a lint check, a gate, a test — so it's enforced by the machine, not by an agent's good intentions.
Incident
Something breaks in a way that cost real time or trust. The failure is named, not smoothed over.
Rule
One precise sentence goes into core/rules/ — the single source of truth for "never again."
Guard
Where it can be, the rule becomes a check that fails loudly — enforcement that doesn't depend on memory.
Edit the rules, not the outputs:
core/rules/ is the source; it compiles into the files the agents actually read — CLAUDE.md and AGENTS.md. You never hand-edit the compiled output. Change the rule once, and every agent inherits it on the next run. That's how rules compound while the surface stays small.5 · The LLM-as-OS Framing
Treat the model like a computer: the context window is RAM, the filesystem is disk, and agents are processes.
The mental model that makes the whole thing coherent is to stop thinking of the model as a chatbot and start thinking of it as the CPU of a small operating system. Once you do, a lot of decisions answer themselves — what to keep in front of the model, what to write down, and how work gets scheduled.
Context = RAM
Small, fast, expensive, and wiped between runs. You fill it deliberately — hot memory that the current task actually needs, nothing more.
Filesystem = Disk
Big, durable, cheap. The living wiki and the rules live here — cold memory that survives every reset and gets paged in on demand.
Agents = Processes
Each agent is a process with one job, reading inputs from a known place and writing outputs to another. Self-contained, schedulable, restartable.
Hot vs cold memory: the skill isn't having a lot of context — it's choosing what to load. Page the right pages of the wiki into RAM for this task; leave the rest on disk. A focused context window beats a full one every time.
Dual-runtime: because rules are plain text compiled per target, the same source set produces guidance for more than one model —
CLAUDE.md and AGENTS.md from one core/rules/. Swap the runtime underneath; the operating system stays the same.6 · Forkable by Design
Zero dependencies. No plugin framework. The whole thing fits in your head — so you can copy it and own it.
The last pillar is a constraint that keeps the other five honest: no lock-in. There's no runtime to install, no plugin API to learn, no service to subscribe to. It's plain files — Markdown rules, English programs, a wiki — that you clone, read in an afternoon, and modify with a text editor. If you can read it, you can own it.
Zero dependencies
Nothing to npm install, nothing to break on upgrade. The system is text and the conventions around it.
Fits in your head
Few enough moving parts that one person can hold the whole model at once — the prerequisite for trusting it unattended.
No plugin framework
Extension is forking a file, not implementing an interface. Less ceremony, less surface to maintain.
Clean files you own
Copy what fits your work, delete what doesn't. Your fork is yours — no upstream can take it away.
That's the philosophy. Six small choices that add up to a system you can audit, reverse, and own. See how they play out phase by phase in the Workflow Map →, or meet the specialists who carry each one in The Council →.