Clarify Prompt Turn failure semantics for safe retry

[thezzisu]

I think ACP should clarify the recovery semantics of session/prompt, specifically around whether a failed or uncertain prompt submission is safe to retry. From a client point of view, the key question after a session/prompt failure is:

Can the original prompt be safely resent, or might it already have been incorporated into the current turn?

This matters in cases like:

• transport interruption before the client receives a response
• server timeout
• internal failure during prompt handling
• reconnect / crash recovery when the final outcome of a prior session/prompt is unclear

In these situations, the client does not necessarily need visibility into agent-internal stages or implementation details. What it needs is a protocol-level answer to one recovery question, Is resending the same prompt safe?

That seems to divide failures into two categories:

• failures where the prompt is definitely not part of the turn, so resending is safe
• failures where the prompt may already be part of the turn, so resending is not safe

Right now, I do not think Prompt Turn makes this distinction clear enough.

I think ACP would benefit from clarifying session/prompt so that, after a failure or uncertain outcome, a client can determine whether the original prompt may be retried safely.

Without this distinction, clients are forced to invent heuristics, and those heuristics can lead to either unintended re-submission of the same user input or failure to recover a prompt that never actually became part of the turn.

Questions:

1. Is there already an intended interpretation of session/prompt failures in terms of retry safety?
2. Should ACP explicitly distinguish between “safe to resend” and “unsafe to resend” outcomes?
3. If so, should that distinction be expressed through existing error semantics, additional error typing, or another recovery-oriented mechanism?

---

Motivation: I am currently implementing a client that's used in automation pipeline, and in my situiation I need to ensure at-least-once inbox delivery gurantee while avoiding send duplicate messages to the agent to prevent it act twice for some non-idempotent operation. Currently, the only way to determine whether a prompt is considered "need to be resend" is to wait for complete agent idle and replay a session.

[benbrandt]

This will be solved I think in #954 where we will replay prompts after they are accepted