Manage One-Shot and Multi-Turn A2A Conversations

An A2A call can be a fresh task or part of a continuing peer exchange. Hermes outbound tools use a context_id to continue and inspect conversations, while the A2A wire protocol uses contextId. That context is not the same thing as a normal Hermes session ID.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/a2a

Use a new context for a new objective

Start without a context identifier when the task should stand alone. Preserve the returned identifier only when a follow-up genuinely depends on the earlier exchange. Reusing an unrelated context can leak assumptions into a new task, make audit trails confusing, and let two workflows interfere with one another.

Inbound A2A conversations are keyed by the protocol context, allowing a peer to continue a multi-turn exchange with the live gateway session. A new context separates protocol conversation history; it does not guarantee isolation from the peer’s own memory or retention. The remote peer still remains an untrusted input source, and continuity does not increase its authority.

Use a2a_history(context_id) to review a persisted outbound exchange. Do not assume undocumented retention periods or equate that history with the complete local Hermes transcript.

Context checklist

  • Decide whether the task is one-shot or conversational.
  • Record the context identifier with the peer and purpose.
  • Reuse it only for the intended relationship.
  • Start a new context when the protocol conversation objective or peer changes; treat sensitivity as a separate data-handling decision.
  • Inspect history before a consequential follow-up.
  • Avoid copying private transcript content into status reports.

Common pitfalls

  • Calling every identifier a session ID. A2A context and Hermes session lineage are different layers.
  • Reusing one context across several peers. Context ownership should be unambiguous.
  • Assuming context continuity grants trust. The peer remains external.
  • Claiming indefinite history. Retention behavior is not specified in the public A2A excerpt.

Verification

Send a synthetic first message and one follow-up using the same context. Confirm the peer can use the earlier exchange. Then create a fresh context and confirm its A2A history starts separately while accounting for any memory the remote peer may retain outside that context. Inspect history and audit records for correct peer, purpose, and ordering without exposing message bodies publicly.