A session note is not team knowledge until a human signs

Then it found a second, also marked published, saying something different. It did not pick the newer one. It stopped and asked a person. That halt is the most useful thing the system does. The note it eventually accepted carried a supersedes link to the older note and a line recording who approved the change. Ambiguity about what is canonical is not a tiebreak condition. It is a stop condition. A confident wrong strategy, read as settled, is worse than no strategy at all.

The blast radius of an agent's note is not the write. It is every later read that treats the note as settled. So leave scratch writes open, and put the human sign-off at the single write that promotes a note to canonical. Promotion is a decision, not a save.

What 'safe to promote' means for an agent's session notes

Blast radius usually gets measured at the write. What did the agent touch, what did it change. That is the wrong end of the timeline. The blast radius of a note is set when it gets promoted, when it stops being scratch and starts being something the team treats as settled.

A session note is working material. It holds the agent's half-formed takes, its guesses, its passing claim that some service owns some behavior. Useful. Worth keeping. Not team knowledge. Team knowledge is what a later agent or a new hire reads and stops questioning. That is the read you have to protect, and it happens long after the write.

Why an agent's raw session output poisons shared context if it is promoted unchecked

Left unchecked, a promoted note poisons the shared context the next agent reads, because nothing distinguishes it from a settled fact. An agent writes "the billing service owns refunds" into a session note. Nobody checks it. It gets promoted along with everything else in the session, maybe by a batch job, maybe by a tired person clicking through. The next agent reads it as settled and routes refund work on that assumption. Every run exits zero. Nothing fails. The work quietly goes to the wrong place, and someone finds it weeks later during an incident review.

This is a pattern, not an incident I am reporting. I describe the mechanism because it is the failure mode no dashboard catches. Exit codes catch failures. A wrong premise that everything downstream builds on is not a failure. It is a clean run on a bad foundation, and it compounds. Each later note that cites it inherits the error and launders it into documented. It is the same shape as an unreviewed merge that compiles clean. The system reports health the whole way down.

The difference between storing a note and promoting it

Storage keeps a note. Promotion graduates it from scratch to canonical. Only one of those changes what the team is held to.

Scratch should stay open. If you gate every write, scratch stops being scratch, agents stop writing working notes at all, and the one review that matters drowns in the ones that don't. Gate the graduation, not the note-taking.

If you keep notes in a markdown repo, you already have a version of this. Notes land in a branch, a person merges the pull request, and that merge is a real sign-off. I concede it fully. At single-player scale it works, and it is boring, which is praise. The boundary is volume and timing. When several agents write notes every session, the review queue either becomes a rubber stamp or lags behind the next agent's read. They work until they don't.

What makes a note safe to promote: a human sign-off before it becomes canonical

A note is safe to promote when a human signs off on it before it becomes canonical, not when the session ends cleanly. The mechanism we built for this is a Gates primitive. The agent routes its own proposed note for sign-off and polls the verdict. The promotion waits on the person.

What a promoted note should then carry is lineage. This note supersedes that one, the older note is marked superseded rather than deleted, and a record of who approved it sits alongside. Promotion left a trail. Storage alone would not have. The trail is also what makes the next halt cheap. When the agent finds competing claims to canonical, the lineage answers the question, instead of a person reconstructing the answer from repository archaeology while something is on fire.

Where the note lives before and after it graduates

People and agents read and write from the same company-wide context substrate, so scratch and canonical can live in one place, and a note can wait as scratch until a person promotes it. In our case that substrate is Synthweave, with snips, bases, projects, and hybrid search open to humans and agents alike. The shared location is the whole point. A note that graduates reaches the whole team and the next agent, instead of rotting in one session's log where the person who needed it never looks.

The path is scratch, then sign-off, then canonical. Scratch is open and cheap. Sign-off is the gate a person walks through. Canonical is what everyone reads. A note moves down that path with its lineage intact, and the next agent that goes looking finds the canonical version, not the session transcript.

What a sign-off gate does not cover

Note creation and metadata are not gated today. An agent can create notes freely. Promotion safety depends on auto-accept being off. If a person auto-approves everything routed for sign-off, the gate is decoration. And a gate the agent has to ask for is a gate the agent can skip. That objection is correct, and I will not rebut it. Leaving creation open is still the right design, because gating it kills scratch. The gate sits at graduation, and it holds only when the agent routes the note and a person reads it.

One thing worth checking in your own setup. If promotion there is just a metadata change, a status tag flip, the gate does not see it unless the agent routes the change through a sign-off. Check where your promotion actually lives.

That halt costs a question and a minute. The alternative costs the rebuild tax. Look at your own notes. Which of them does the next agent already treat as settled, and who signed them?

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "A session note is not team knowledge until a human signs off on it" } </script>