Base64 uploads past 6,000 characters decode cleanly but with wrong content inside

The reason this class of failure is invisible sits in the encoding. A corrupted base64 string still decodes successfully and produces a valid file with the wrong bytes inside, so nothing in the pipeline raises anything ^[5]. What you get instead is a spreadsheet that opens to a blank grid, or an invoice whose header is crisp and whose body below it is grey mush ^[6].

Take the reliable ceiling at face value and price it. Base64 spends four characters on every three bytes, so about 6,000 characters buys roughly 4,500 bytes of payload, call it 4.4 KiB ^[3]. That is smaller than a typical xlsx, zip or PDF, which is why the remedy in the notes is to stop the model reproducing long base64 at all and decode the platform's saved local copy programmatically ^[7].

I would not copy 6,000 into your own guard rail. The lowest observed corruption came in at just under twice that figure ^[4], and nothing between the two was tested. For the number to transfer you would need the same per-response output cap and the same platform file handling. Treat it as a bound to measure on your stack.

The notes are worth stealing for their verification discipline. Defining the word per file type is dull and it works: read text back and diff against the source, export a spreadsheet to CSV and compare totals, render an image and check that named fields are legible ^[11]. The enforcement clause does the real work, and it is one line: do not write "verified" unless you state what you compared ^[10]. That turns an adjective into a claim somebody else can check. Text needs it too, not just binaries. A plain Hebrew document came back containing a word that was not in the source, and on another run a single word arrived with Hebrew and Latin characters mixed inside it, neither flagged ^[14]. For long content the fallback is a byte-for-byte comparison or a hash ^[15].

Some of the log is empirically fixed rather than understood. The author's reading of the voucher swap is that both files shared a long identical byte prefix, and the workaround was to inject a unique marker early, before the point where the documents diverge ^[13]. That fix works, but it rests on a hypothesis about the cause rather than a confirmed one.

Then the money. One line before the recommendation, the agent's own log recorded that the attachment had not been read ^[17]. It summed the figures it could see anyway. The understatement works out at a factor of about 17.4 ^[1], and the notes call it the most dangerous item in the set because the output was fluent and confident ^[18].

That log line is the argument for verification-first. The trace already held the disqualifying fact, but the agent had no rule that converts a known gap in its own inputs into a refusal: never infer from a source you did not read, and report what is known, what is not, and why it could not be read, rather than a number ^[20]. The pressure to break that rule is structural, because the capability underneath is absent. According to the same field notes, no available tool downloads attachment content from Gmail; the tools return metadata such as filenames ^[19]. An agent with a hole in its inputs will fill the hole with whatever is in front of it, so the guard has to live in the harness.