The Buddy System: a way to keep the whole life of the work

Almost every tool we use to manage work manages the output: the book, the code, the product, the ticket. Very few manage the whole life of a piece of work. Why it began, what principles it had to keep, how it was made, who collaborated, how it changed, how it lived in production for years, and what it taught after it shipped. I wanted one process simple enough for a child's homework and strong enough for a 25-year company, that captures that whole arc and stays usable for a long time. This is what I landed on. I call it the Buddy System.

What the tools miss

A Jira ticket holds a task. A git repo holds the code. A wiki holds the documentation. None of them hold the thing I actually keep losing: the why. Why we started, what rule we swore not to break, what we believed at the time, what we discovered three months in that changed the plan, and what the work taught us once it was out in the world being used in ways we never designed for.

That layer is real, it is the most valuable layer, and it is the first one to evaporate. It dies in the gap between the ticket and the retro. It dies when the person who made the decision rotates off. It dies because no common tool has a place for it. I wrote about a version of this in intent-driven development: the spec that works is the one written last, because understanding is discovered through the act of building. The Buddy System is the container that keeps that discovered understanding instead of throwing it away at the boundaries of a task.

The unit: a bud

A bud is one piece of work. A chapter, a migration, a garden, a company, a child's science project. Each is a bud. The word is chosen for one property: it composes. A bud opens into a stem, the stem holds nodes, each node holds new buds, and each new bud has the same shape. The self-similarity is not decoration, it is how the method survives depth.

A bud gets a sub-bud when a piece of the work earns its own why, not when it is merely a task. If chapter three only exists because the book needs a chapter three, it lives in the parent's notes. If chapter three exists because you discovered the antagonist needed a separate point of view, that is a why, and it buds off. The discipline is that simple: own a why, earn a bud.

Two files: brief and notes

Each bud needs only two files, and they have different jobs and different lifespans.

One clarification that matters the moment more than one person is involved: the notes file is personal. Each buddy keeps their own, a single chronological stream in their own voice. A bud's notes is then the merge of every buddy's notes attached to that bud, while the brief is the one shared file the keeper tends. With a single buddy the two collapse into the same thing; the distinction only appears once a second buddy or BOB starts contributing, and the data-model section below makes it precise.

The brief is the heart of the method, and the key idea is that it is not a plan written once and a retrospective written at the end. It is a single living document that grows in place. You open it with what you think, you amend it as the work corrects you, and you distill it when it settles. A brief written only at the start lies by the end; a brief written only at the end forgets why it began. One file, grown across the life of the work, is the only honest shape.

brief.txt -- zoya-v2

[2026-03-14 . open]
Branched from zoya-v1 (closed 2026-02-28).
Exists because synchronous approval gates blocked throughput.
Premise: deferred approval with attestation can keep safety
without serializing. Won't break: human in the loop on all
external effects.

[2026-04-02 . revision]
Two weeks in: works for read tools, attestation chain heavier
than expected. Narrowing scope to read tools. Write-tool
throughput becomes its own sub-bud.

[2026-06-30 . close]
Settled. Read-tool throughput up 14x. Carry forward: the
attestation pattern generalizes; the next bud should treat it
as default for any new tool integration.

That last layer is the most valuable writing in the whole system. It is not an archive entry, it is inheritance. The next bud does not begin from nothing; its opening layer cites this close. The work's understanding flows forward across a generational boundary, which is the loop that makes the method compound.

The people: buddies and beats

A buddy is anyone tending a bud with you. The word was sitting one suffix away from bud and it does real work: it gives the human relationship a name that travels from a SOC migration to a family kitchen to a kid's homework without changing register.

Beyond a single bud, a buddy has a beat: the standing set of buds they walk regularly, even when nothing acute is happening. Buds are the event arc; beats are the daily rhythm. You walk your beat (your scoped buds) or you walk the forest (the whole corpus, for a cross-bud query). The verbs are plain on purpose: open and close a bud, amend and distill the brief, log a line, bud off a sub-bud, branch from a parent, step on and step off a bud, hand off the keeper role, walk the beat.

Four layers, one practice

The method works at four layers at once, and the same handoff describes all of them.

The naming stays deliberately small. The practice is the Buddy System. The unit is a bud, the people are buddies, and the AI buddy is BOB. There is no acronym to decode, which is the point: a method meant to last should not make you translate it before you can use it.

BOB: an AI buddy under the same rules

BOB is the AI agent that works inside the Buddy System. The important design choice is that BOB is not bolted on as a faster human or hidden behind an API. BOB is a buddy. BOB keeps a notes stream, attaches notes to buds, drafts brief amendments for the keeper to accept, requests approval before any external effect, and walks a beat. The methodology predates the agent and defines the agent's role, which means the hard questions of agent trust are already answered by rules that apply to every buddy.

The operating philosophy is the bobby on the beat. A bobby is the old British neighbourhood policeman, named after Robert Peel, who founded the London force in 1829. The model, at its idealised best, is the opposite of heavy enforcement: the officer walks a known patch on foot, is recognised by the people on it, draws authority from their consent rather than from force, and measures success by trouble that never happens rather than by arrests made. Four properties of that model are exactly what you want from an agent: authority by consent, visible by default, a bounded territory, and prevention over enforcement.

If BOB is not invited to a bud, BOB does not act on it. Every action BOB takes appears in its notes. BOB drafts; the keeper accepts. The agent earns trust the way a bobby does: by being observed at all times and staying on its beat.

This is also where the method meets my other work. BOB is the same agent I have been building as reasoning-plus-reach across a fleet; the Buddy System is just the practice it participates in. Humans and AI are the same kind of participant at the practice level, different in capability, identical in role.

Tags: fixed grammar, local dialect

Everything is plain text, and a tiny tag vocabulary turns that text into a knowledge graph and a notification web without any tool required. Five prefixes are the universal grammar and never change.

The values under each prefix are local. A family grows tags around chores and school; an MSSP grows them around clients and severities; a novelist around arcs and craft rules. Each context keeps its evolving vocabulary in a tags.txt glossary, dated and append-only. The grammar belongs to the method; the dialect belongs to the people. Time entries ride the same grammar (+time:2h for actuals, ~time:8h for estimates), which makes effort just another slice of the graph and cross-bud accounting a query rather than a separate system.

The data model: buddies own streams, buds are views

The structural move that makes the whole thing hold together is that notes are owned by buddies, not by buds. Each buddy keeps one chronological stream in their own voice. A note attaches to zero, one, or many buds. A bud's view is then the merge of every attached note from every buddy, layered by author, with the brief as its spine.

This inversion is what gives the method its best properties for free. A buddy can leave a project and their notes stay attached. A note that turns out to matter to a bud created later can be attached retroactively, no copying. One note about an auth pattern can live in three buds' views at once. And a buddy's stream becomes a whole, single-voiced record of a working life across every context they touch, which is the thing a grandchild could actually read in fifty years.

So who does the merging? Nobody, by hand. The merge is mechanical, a projection a tool computes from the attached notes. What is not mechanical is what gets attached, and that is always the author's call. Attaching a note to a bud is an authoring act by its owner, so a note you do not attach never enters the bud's view. Not every note deserves the light, and that is the point: you keep the rough, the private, and the half-formed in your stream and share only what earns a place. The keeper never reaches into anyone's stream and never edits another buddy's notes. The keeper reads the merged view and distills it into the brief. Editorial control lives at the brief, not over the notes. With a single buddy none of this is visible, because your stream simply is the bud's notes.

Concretely, then, a bud's notes is closer to a saved query than to a stored file. Run it and it gathers the attached notes from every buddy's stream and combines them by the bud's defaults: the visibility mode, who counts as a buddy, which topics to include, how to order them. The bud stores that small spec, not the notes themselves. The only authoritative file a bud owns is its brief; everything else about it is computed from the streams on demand. This is the database shape, tables stored and views derived, and it is exactly what makes the method automatable. A view that is already a query is something BOB can run, read, and act on without anyone assembling it first. You can materialise a view to a file when you want to grep it offline, but that file is a build artifact: regenerable, read-only, never the source of truth.

Whether attaching is opt-in or opt-out is itself a local default, and it should scale with the group. In a small, high-trust group, a family or a team of three, the sane default is shared: a note attaches to the bud you are working in, and you mark the rare one private. The friction of opting in every note is not worth it and the trust is high enough that over-sharing costs little. In a group of ten or more, or anything client-facing, the default flips: notes stay in your stream until you deliberately attach them. At that size a share-everything default quietly makes people self-censor their rough notes, and the honesty that makes notes worth keeping dies with it. Same method, opposite default, chosen by the dialect, because the right answer genuinely changes with the number of people who can see.

A worked example: three buddies, one bud

Here is the whole thing on disk for a bud with three buddies, Cosmin, Alex, and BOB. The bud folder holds only data: one brief, and one notes file per buddy.

zoya/
  .brief         # the shared understanding; the keeper commits to it
  .notes-cln     # Cosmin's layer for this bud
  .notes-alex    # Alex's layer
  .notes-bob     # BOB's layer

There is no script in the bud. The view is produced by one shared tool on your PATH, the same for every bud, call it bud. Run it inside a bud, or point it at one, and it merges the layers, taking parameters so the same data reads many ways:

bud notes                 # combined, time order, public only (default)
bud notes -a              # also include your own private working notes
bud notes -b alex         # just Alex's layer
bud notes -t oauth        # filter to #oauth
bud notes --since 2026-04-01
bud notes --for-brief     # what the keeper reads before distilling the brief

A buddy's file mixes public and private freely, and the default view hides the private lines, so honesty in the raw stream costs nothing:

# bud:1   .notes-alex
[2026-04-12 @alex +time:2h #oauth ^p:zoya] Fixed token refresh edge
  case with a 5-minute cache buffer. Cleaner than expected.
[2026-04-13 @alex :private] Not convinced the caching scales past a
  few hundred sessions. Sit with it before I raise it.

Run bud notes and the first line shows up in the bud view; the second stays in Alex's file until Alex chooses to raise it. One honest caveat: the private flag is a convenience filter, not a security boundary. The script only hides what it is told to hide. Real privacy between people is file permissions or separate storage, not a command-line switch. Inside a trusted group the filter is enough; across a trust boundary, lean on the filesystem, not the flag.

And because bud is just one shared tool reading plain files, the default that makes a three-person bud pleasant (public by default, private opt-out) is one switch away from the default a larger bud wants (private by default, share opt-in). Same files, same tool, different default. The local dialect, expressed as a flag.

Notes get into those files however you like: typed by hand in an editor, appended by a CLI, or written through a local UI. The front end is replaceable, which is the whole point; the files are the substrate. And the files live in git, which gives durable versioned history, sync across machines, and a record of every change that is independent of the brief's own dated layers. One quiet benefit falls out of the per-author layout: because each buddy writes only their own .notes-* and each bud has a single keeper for the brief, there are essentially no merge conflicts. Per-author files make collaboration conflict-free by construction.

That first line, bud:1, is the protocol version, and it earns its place. Each .brief and .notes-* declares the format it is written in, so tools parse by declared version and the format can evolve without breaking old files. A forest can even hold files at different versions through a migration, each handled correctly. It is the magic-number trick that file formats have used forever, and it is what keeps a corpus readable decades later as the method changes under it.

Start where you already are

The method is heavy at full depth and almost free at the entrance, on purpose. You adopt it in stages, and each stage is complete on its own.

The onramp is one decision: make the notes you already keep visible. That is it. Briefs, lineage, and BOB are pull, not push. They arrive when the work makes you want them, and not before. BOB drafting the briefs is what keeps the writing burden from becoming the barrier: you write rough notes, BOB drafts the brief from the stream, you read it and accept or edit. The discipline is preserved because BOB drafts and the keeper commits, never the other way around.

You can start with even less than a bud. Keep a brief alone for a piece of work where what you mostly need is to remember the why, or keep notes alone where what you need is the running record. Neither has to wait for the other. They converge on their own: a stream of notes eventually wants a brief to make sense of it, and a brief eventually wants notes to ground its claims. You do not study the method, you use it, and the using is what makes it easy. The first brief is awkward; the tenth writes itself.

Why this matters more now

AI has made starting things almost free. A prompt spins up a repo, a draft, a prototype in minutes, and the number of half-started projects in anyone's life has gone up to match. The cost did not disappear, it moved. It is no longer expensive to begin. It is expensive to remember what you began, why you began it, and what you learned before you wandered off to the next thing.

It is no longer expensive to begin. It is expensive to remember what you began and why. The brief and the notes are the cheap insurance against that.

When you come back to a project three months later, the brief tells you why it exists and the notes tell you what already happened, so you are not re-deriving your own reasoning from a cold repo. The faster things start, the more this matters, because the pile of cold repos grows faster than memory does.

And because all of it is structured plain text with a fixed grammar, it makes automation possible. A brief an agent can read is a brief an agent can extend; notes tagged in a known vocabulary are notes a tool can query, summarise, and act on. The method is not only a way for people to remember, it is the substrate an agent works from. The same discipline that lets a human pick a project back up lets BOB pick it up, which in the AI era is most of the difference between a project you can delegate and one you cannot.

Where it fits, and where it does not

I want to be honest about this rather than sell it. The Buddy System is strong exactly where most methods are weak, and weak where they are mature.

The honest verdict: use the Buddy System for the consequential, long-lived, meaning-rich layer of your work, and keep a lighter tool for the transactional layer. It is not trying to replace the ticket tracker. It is trying to wrap whatever the tracker does in a longer-lived, lineage-aware container that remembers why the work existed and what it taught.

Why bother

Because the last reading of the name is the real one. Brief to brief is the mechanism, bud to bud is the structure, buddy to buddy is the relationship, and buddies to build is the point. The discipline of writing honest briefs and letting them flow forward is in service of people building things together and wanting what they build to outlast them.

That is what I wanted from the start: a way of working simple enough for my children to pick up and strong enough to carry a company, that keeps not just what we made but why we made it and what it taught, and hands that forward. Two files, a small grammar, a handful of plain verbs, and one handoff. Buddies, building, brief by brief.

---

This article is the loose, conceptual layer. The tooling that implements the Buddy System already exists, is in daily use, and works well. What is left is finetuning it to scale cleanly across three axes: scope, from a single note to a deep forest; size, from one buddy to many; and time, from a day to decades. BOB already walks the beat alongside me. If you keep visible notes with anyone, you are at level one whether you call it this or not.