Three Protocols Before Anything Else: Memory, Feedback Order, and the Soft Block

At the top of the Loa configuration in each of our repos sits a short section titled Key Protocols. It is three lines long. One line establishes memory, one establishes the order in which feedback is consumed, and one establishes git safety. In July 2026 we promoted this section from working docs into our verified decision log, which is the fleet's way of saying: this is no longer a habit, it is a rule. This essay explains what each line does and why the three of them come before everything else a repo agent reads.

A repo run by agents has a structural problem that a repo run by humans does not. The humans on a team carry continuity in their heads. An agent session carries continuity only in what it can read at startup. So the first things an agent reads are not suggestions, they are the closest thing the repo has to a nervous system. That is why the protocol section is deliberately small. A long list of protocols is a list nobody enforces. Three lines can be checked, audited, and actually followed on every session, in every repo, across the whole fleet.

Memory: one file, in the tree, under version control

The first protocol reads, in full: maintain grimoires/loa/NOTES.md. That is the entire rule, and the brevity is the point.

The notes file is the repo's working memory. Decisions that have not yet hardened into code, half-finished threads, known sharp edges, the reasoning behind a choice that would otherwise look arbitrary: all of it goes in one place, and that place is inside the repository. This is the same instinct behind the memory-file conventions Anthropic describes in its Claude Code engineering guidance: the agent's context window is ephemeral, so anything worth keeping has to be written somewhere the next session will look.

We put the file in the tree rather than in an external store for two reasons. First, versioning: when a note turns out to be wrong, the correction has a diff, an author, and a timestamp, like any other change. Second, locality: an agent that clones the repo has the memory, with no service dependency, no sync step, and no way for the notes to describe a different revision than the one checked out. The grimoire naming is our own convention, but the mechanism is ordinary. It is a markdown file that every session is obligated to read early and update before it ends.

Feedback: audit first, then engineer

The second protocol is an ordering rule: check audit feedback first, then engineer feedback. On first reading this looks like trivia. It is not. It encodes a priority scheme that keeps two very different kinds of input from being averaged together.

Audit feedback is the output of gates: automated review, policy checks, the machinery that says a piece of work is or is not acceptable to ship. Engineer feedback is judgment: preferences about approach, style, and direction. Both matter, but they fail differently when ignored. Ignored engineer feedback produces work that is worse than it could be. Ignored audit feedback produces work that should not exist at all. So the protocol forces the agent to resolve the gates before it starts optimizing for taste. An agent that reads the feedback streams in the other order will happily polish a change that the audit has already rejected, and every minute of that polish is waste.

There is a second effect worth naming. When the ordering is written down, it stops being a per-session negotiation. No agent has to decide which feedback source outranks the other, and no two repos in the fleet resolve the question differently. Determinism in small things is what makes a fleet of independent repos behave like one system instead of many.

Git safety: four layers and a soft block

The third protocol is the one that earns its keep in the worst moments: four-layer upstream detection with a soft block.

The failure this defends against is mundane and severe. An agent with push access, moving fast, pushes to an upstream it should not touch: a fork's parent, a shared remote, a branch that other work depends on. Git itself will not stop this. As the git-push documentation makes clear, push behavior is configuration, and configuration is exactly the kind of thing that varies between clones and sessions. A safety rule that depends on every clone being configured correctly is not a safety rule.

So the protocol layers four independent checks in front of the dangerous operation. We will not enumerate the internals here, but the design logic is the classic Swiss cheese model: each layer has holes, and the layers are chosen so the holes do not line up. A remote-name heuristic can be fooled. A URL pattern can be fooled. Four unrelated detectors being fooled simultaneously is a much smaller surface than any one of them alone.

The more interesting choice is the soft block. When the layers trip, the operation is halted and surfaced, not made impossible. A hard block would be safer in the narrow case and worse in the aggregate, because hard blocks teach agents (and the people supervising them) to route around the mechanism entirely, and a routed-around safety system is worse than none: it still costs attention while providing no protection. A soft block keeps the human decision in the loop precisely at the moment the fleet's automation is least confident, which is where a one-operator fleet wants its scarce human attention spent.

Why these three, and why first

Read together, the three protocols cover the three ways an agent-run repo quietly degrades. Without maintained memory, each session re-derives context and re-makes old mistakes. Without feedback ordering, effort flows to the wrong queue and rejected work gets polished instead of fixed. Without layered git safety, one bad push turns a local error into a shared one.

None of these is a novel mechanism. A notes file, a priority rule, a guarded push: any of them could appear in a human team's handbook and draw no comment. What is different in an agent fleet is that the handbook is load-bearing. There is no hallway conversation to catch the session that skipped it. The protocols are short because short is what survives being read at the start of every session, and they are first because everything after them assumes they held.

We keep promoting small rules like these out of working docs and into the verified log as they prove themselves. When one of them fails us, we will write that up too.

Four hands at the gate, and the grimoire open on the sill.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

• 2026-08-27: enrich three-protocols-before-anything-else-memory-feedback-order-and-the-soft-block: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 1635