Choose an A2A Delivery Path for Long-Running Tasks
A short A2A task can wait for a final response. Longer work may need streaming, task status, cancellation, or a signed push notification. Choose the lifecycle before sending the task so a timeout is not mistaken for failed work.
Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/messaging/a2a
Match delivery to duration
Use canonical SendMessage when the work should finish inside the agreed wait window. Use SendStreamingMessage when the caller benefits from Server-Sent Events while the task progresses. For longer work, the A2A server also exposes task retrieval, listing, cancellation, subscription, and push-notification configuration methods.
A2A_REPLY_TIMEOUT is the inbound server's wait for the local agent response. A configured outbound peer may have its own timeout. These are different controls and should not be described as one global A2A timeout.
Push notifications are HMAC-SHA256 signed using the configured push secret. The public excerpt does not specify header names or canonicalization details; use the current official protocol and Hermes documentation when implementing verification.
Lifecycle checklist
- Estimate whether the task is short, streaming, or asynchronous.
- Set bounded caller and server wait windows.
- Preserve task and context identifiers.
- Decide whether polling, subscription, or push delivery is required.
- Test cancellation behavior with a harmless job.
- Verify signatures using official wire-format guidance.
- Distinguish timeout from terminal task state.
Common pitfalls
- Calling every timeout a failure. The task may still be running or awaiting retrieval.
- Confusing SSE with durable delivery. A stream can disconnect.
- Inventing webhook signature headers. Follow the current protocol contract.
- Leaving uncapped ping-pong conversations. Keep the documented anti-loop limit.
Verification
Run one short synthetic task through SendMessage, one streaming task through SendStreamingMessage, and one bounded long task through status retrieval. Confirm identifiers remain stable, cancellation reaches a terminal state, and a deliberately invalid push signature is rejected by the receiving test service.