User Story 03: One Request, Multiple Responses

Implementation-oriented user story for SDK development.

Send One Request and Consume Streamed JSON Updates

Goal

Agent A sends one request and receives multiple response messages (status/artifact updates) until task completion.

Preconditions

• Agent A and Agent B support A2A stream semantics on MQTT reply path.
• Agent A has subscribed to a dedicated reply topic.

End-to-End Flow

1. Agent A publishes one request to:
   • $a2a/v1/request/{org_id}/{unit_id}/{agent_id}
   • QoS: 1 (recommended)
   • MQTT v5 properties:
     • Response Topic: $a2a/v1/reply/{org_id}/{unit_id}/{agent_id}/{reply_suffix}
     • Correlation Data: unique request correlation bytes
2. Agent B accepts request and starts work.
3. Agent B publishes multiple reply messages to Response Topic:
   • Each message echoes the same Correlation Data
   • Payloads include A2A stream items such as:
     • TaskStatusUpdateEvent
     • TaskArtifactUpdateEvent
4. Agent A processes each update in arrival order for the same Correlation Data.
5. Agent A ends stream handling when it receives terminal task status:
   • TASK_STATE_COMPLETED
   • TASK_STATE_FAILED
   • TASK_STATE_CANCELED

Task ID Rule

• Correlation Data is only transport correlation.
• The authoritative task identifier is Task.id generated by Agent B.
• Agent A uses returned Task.id for follow-up calls (tasks/get, tasks/cancel, subscriptions).

SDK Requirements Checklist

• Maintain per-correlation stream state.
• Parse and dispatch status vs artifact updates.
• Detect terminal state and close stream state.
• Persist server-generated Task.id early in the stream lifecycle.