The transcript was not append-only

The bridge's central calculation is what has the other agent not seen yet. It answers it with a watermark: remember how far you got in each agent's transcript, and next time take everything after the mark.

That works on an append-only log. It took about twenty commits in this release to accept that a vendor transcript is not one.

Four ways a transcript moves underneath you

Records get revised. The same record id comes back with different content. A mark that remembers the last id you saw will step straight over it, because by id you have already been there. The changelog says what the old scheme could and could not do, without euphemism:

Legacy leaf-only marks remain readable but cannot detect same-ID content edits.

Records arrive late. Something timestamped earlier than your mark shows up after it. Filter strictly by timestamp and it is invisible forever — it is already in the past according to a mark you set before it existed.

History gets replayed. An agent resumes and its stored conversation is rewritten, re-emitted, or re-marked. To a reader watching for activity this looks exactly like new work.

Transcripts get created. The first time an agent is linked, the file may not exist yet at the moment you start watching. An absence that later becomes a file is not the same as an absence that stays one.

Each of those got its own fix, per agent, because each vendor is wrong in its own dialect: replay Grok conversation when marked history changes, replay revised Antigravity steps in context and audit, replay revised Pi records without acknowledging old history, preserve late and revised timestamped transcript records, observe delivery when a linked transcript is first created.

Replay is the dangerous one

The others cost you content. Replay costs you the truth about a delivery.

A handoff is marked delivered when the bridge observes the receiving agent actually pick it up. If replayed history is read as fresh activity, the bridge sees movement in the target's transcript and concludes the delivery landed — when what it watched was the agent re-reading its own past.

Hence do not acknowledge delivery from replayed history, and the subtler one beside it, distinguish replayed history from closing words — because the departing agent's final words are also appended late, and they had been landing in the same bucket as replay.

Read the mark before you read the world

capture delivery watermarks before reading source activity is four words of ordering that took me a moment to see.

If you read the activity first and then take the mark, anything written during your read is now behind a mark that was captured after it. You have promised to have processed something you never saw. Taking the mark first makes the same race harmless: work that arrives mid-read is simply ahead of the mark and gets picked up next time.

The same instinct runs through the neighbouring fixes. withhold delivery progress when source transcripts change during collection — if the ground moved while you were reading, do not record how far you got. retain source progress when actual extraction is incomplete — and do not throw away what you did legitimately reach. disclose audit source changes before advancing delivery progress — say that it happened.

None of them try to win the race. They all arrange to lose it safely, which is the only available move when the file belongs to somebody else's process.

Acknowledgement can be interrupted too

Delivery has a second half: the receiving side confirming it consumed the context. That confirmation is a write, and writes get interrupted.

Three fixes cover the states that leaves behind. reject stale launcher delivery acknowledgements — an acknowledgement that arrives from a launcher that has since been superseded is not evidence about the current delivery. replay pending prompt context after interrupted acknowledgement — if the confirmation did not complete, the context is still pending, so send it again rather than assume. And do not treat missing delivery evidence as consumption, which is this release's recurring sentence in its delivery clothes: no record of consumption is not a record of consumption.

The bias is deliberate and it is one-directional. Delivering the same context twice is mildly wasteful. Recording a delivery that never happened silently removes work from the next handoff, forever, with nothing anywhere indicating that it went missing.

And they got too big to read

A separate group of fixes deals with transcripts that have simply grown. stream large Claude and Codex transcripts within memory budgets replaces reading a file whole. refuse oversized native transcripts before unbounded allocation puts a limit in front of the allocation rather than discovering it afterwards. verify complete transcript reads before declaring Codex idle closes the obvious consequence: a read that was cut short looks like an agent with nothing to say.

That last one is the pattern of this entire release again. The system had a way to say quiet and no way to say I did not finish reading, so it said quiet.

What a mark actually is

I used to think of a watermark as a bookmark — a position in a document, meaningful on its own.

It is not. It is a claim about another process's file, made at a moment that has passed, about a file that process is free to rewrite, truncate, re-timestamp or replay without telling you. Everything in this group is the consequence of taking that seriously: re-read rather than assume, compare content rather than trust ids, take the mark before the data, and when the ground moves during a read, keep what you got and refuse to advance.

The mark is not where you are. It is where you were last able to prove you had been.