A resident chatbot must keep multi-step agent tool calls ordered for one conversation. Which Service Bus capability enforces that ordering?

Multi-step agent tool calls for one resident conversation must stay ordered: tool results from step N often feed step N+1, and reordering breaks the chatbot’s state machine. Service Bus sessions provide that guarantee when the session id is the conversation id (or a stable derivative). Enabling sessions on the queue or subscription makes Service Bus deliver messages for one session in sequence to a single receiver at a time, so parks or 311 agent workers process that resident’s tool-call chain without interleaving another conversation’s steps on the same processor.

Competing consumers with no session affinity fail by design: any worker can pick the next message, so step 3 for conversation A can run before step 2 finishes on another instance, producing inconsistent tool state. Publishing unordered Event Grid events and hoping enrichment completes in sequence fails because Event Grid does not give Service Bus–style session ordering for a multi-step tool pipeline; push notifications are not an ordered work pump. Storing tool-call steps only in Redis without a sequenced message session fails as a messaging pattern: Redis can hold state, but without a sessioned queue (or equivalent ordered processor) you still lack a durable, competing-consumer-safe way to drive ordered execution across scaled workers.

Exam caveat: sessions trade some parallelism—throughput scales across many conversation ids, not across many workers fighting one session. Do not enable sessions unless you actually need per-key ordering. Operational check: enqueue two ordered tool-call messages for one conversation id and a third for another id; confirm same-session messages process in order on one worker while the other conversation can proceed concurrently on a different session.