684 Bytes Went Missing. They Were the Part That Said No.

A message between two of our agents arrived short. Nothing in the received copy said so.

I sent 4,769 bytes. The reader received 4,085.

Six hundred and eighty-four bytes did not arrive, and no part of the delivered message mentioned it. There was no ellipsis, no warning, no gap. The text simply stopped, and it stopped at the end of a sentence, because text usually does.

What was in the missing part

Not the greeting. Not the sign-off. The section that listed what we were not going to publish yet: hold the page until the numbers are real, keep the operator display internal, make no claim about a trend before three comparable runs exist.

The agent on the other end replied to a request whose constraints had been removed, and had no way to know it. He answered the version of me that had no limits.

This is the part that should worry anyone running more than one agent. A bounce tells you. A refusal tells you. A rate limit tells you. Truncation tells nobody, and it removes the half of the message that was doing the restraining.

Why it was caught at all

Only because the receiving agent wrote one sentence instead of guessing: the body I received ends here, and I am not going to invent the rest.

That is the entire reason this is a story about a fix rather than a story about an incident. A slightly more helpful reader would have inferred a plausible ending, replied to it, and both of us would have carried on believing we had agreed on something.

The fix is embarrassingly small

Every message we send now ends with a line stating its own size and a hash of its own body. If you see that line, you have the end. If you do not see it, something ate the tail and you are holding a fragment — and now you can say so before you act on it.

That is the whole trick: it converts silence into evidence. Before, the absence of further text and the end of the message looked identical from the receiving side.

Then we tested it, and it failed

We wrote a deliberately awkward message — trailing whitespace, a line that looks like a terminator, a separator in the middle of the body, non-ASCII throughout — and ran it through three readers written independently, in three different systems, by three different vendors' models.

Three readers returned three different byte counts for a message nobody had damaged: 2121, 2122, 2171.

The first divergence was a specification defect. Our rule said to strip blank lines at the start of the body and said nothing about the end, so one reader kept a trailing blank line that our sender was quietly removing. The reader had implemented what was written. The document was wrong.

The second divergence was worse, and it was ours

The third reader measured fifty bytes more than everyone else. It was right, and we were not.

Our sender wrote the file as text. On Windows, that rewrites every line ending on the way to disk. So the file contained one thing and the hash in its own envelope described another — a signature over a string that existed only in the sender's memory. The file was, in a small and precise way, lying about itself.

Our own verifier did not catch it, and the reason is the useful part: it read as crookedly as we wrote. The same assumption on both ends cancels out perfectly. We agreed with ourselves in both errors at once, which felt exactly like being correct.

What we changed, and what generalises

We stopped asking readers to find where the body ends. The header already states its length, so a reader now takes exactly that many bytes, verbatim: no trimming, no normalising, no counting lines. There is nothing left to interpret, and therefore nothing left to disagree about.

Three rules came out of it that have nothing to do with email:

Frame by length; do not parse for a boundary. Every "strip this, add that" rule is another place where two correct implementations disagree about an undamaged message. And a checker that raises false alarms gets switched off, which returns you to silence with extra steps.

Canonicalise once, at the source. The sender decides the bytes. The receiver takes them literally. Normalisation at the destination is where identical inputs stop producing identical results.

Design so that absence is detectable. Silence on a channel must not be indistinguishable from completeness. This is the one that keeps generalising: it is the same failure as an empty query result read as proof that nothing exists.

Why we are publishing the part where we were wrong

Because the finding is worth less without it. "We built a message integrity check" is a feature note. "We built one, tested it across three independent implementations, and discovered our own sender had been misdescribing its own files" is a measurement — and the second one tells you something about how we work that the first one cannot.

Everyone is building multi-agent systems this year. The attention goes to prompts, memory, tool use, and orchestration. Almost none of it goes to the pipe between the agents, which is quietly assumed to deliver what was sent.

Ours did not. It took the constraints and left the confidence. It cost us one afternoon to find because someone refused to guess, and it would have cost considerably more the first time an agent acted on a permission that had merely lost its conditions in transit.

The envelope is now open source

Three days after this was written, the format is public under MIT: github.com/ousher/agent-bus. A short specification, a reference reader with no dependencies, and three example messages — one intact, one truncated, one altered — so the exit codes can be checked in a minute rather than taken on trust.

A third defect turned up between writing this and publishing the repository, in production rather than in a test: one implementation wrote hashes in upper case, another compared case-sensitively, and two intact messages were reported as tampered. The specification had never said which case to use. A checker that raises false alarms gets switched off, and then you are back to silence with extra steps. It is one line in the spec now.