Does Azure Service Bus Remember Between Runs? A Queue Can Hold a Message Almost Forever. The Next Run Still Starts With Only That Message.

Azure Service Bus remembers a message for a very long time, and it remembers nothing a receiver learned while handling that message. A queue stores messages until a receiving application is available to process them. A topic does the same work for every subscription attached to it, giving each subscription its own copy. Once the broker accepts a message, it holds that message durably until a receiver settles it. What the broker never stores is the result of the work. That split explains why scheduled agents fed by Service Bus still repeat finished investigations, reopen settled questions, and begin every run with only the next message as a brief.

A queue holds the work item, not the outcome

Retention in Service Bus runs on time to live. Every message carries an expiration, set per message or inherited from the queue or topic it was sent to. On the Standard and Premium tiers, the default expiration is the largest possible value for a signed 64-bit integer, so a message can wait effectively indefinitely unless a shorter limit is configured. On the Basic tier, the default and maximum expiration is 14 days. Past the expiration instant, a message becomes ineligible for retrieval, and it can be moved to the dead-letter queue if that option is enabled, or dropped if it is not.

A long wait protects delivery. It does not create a record of earlier work. A receiver that returns after a weekend finds the same messages waiting, in arrival order, with their original bodies and properties intact. It does not find notes from the last receiver, a conclusion, or a list of checks already completed. The queue preserved inputs through the gap between runs. The thinking from the previous run lived inside a process, and that process has ended.

Duplicate detection and scheduled delivery strengthen the same side of the line. Duplicate detection lets the broker discard a second copy of a message sent inside a configured detection window, so a sender that retries after an uncertain send does not create duplicate work. Scheduled delivery lets a sender submit a message for processing at a later time. Both features make the message itself more dependable and better timed. Neither one adds a place for a receiver to leave what it discovered, because that discovery happens after the message was sent, not inside it.

Peek-lock settles a delivery, not a body of work

Receiving in Service Bus usually happens in peek-lock mode. The broker delivers a message and locks it for one receiver, for one minute by default and for five minutes at most on the queue or subscription. Other receivers cannot take that locked copy. The receiver then settles the message in one of four ways: complete it, abandon it, dead-letter it, or defer it. Complete removes the message from the queue or subscription. Abandon makes it available again and increases its delivery count. After the maximum delivery count is reached, ten by default, the broker moves the message to the dead-letter queue. Defer sets a message aside inside the same entity, so it can be retrieved later by its sequence number when conditions allow processing.

Follow one scheduled automation through that cycle. A message arrives asking for a review of an account. The receiver spends several minutes gathering records, comparing history, and reaching a decision, renewing the lock while the work continues, then completes the message. The completion tells Service Bus exactly one thing: this delivery is settled. The decision itself, the records that supported it, and the checks that led nowhere were never part of the message, so none of them enter Service Bus. If a similar message arrives tomorrow, the next run receives that payload and repeats the same gathering from zero, because no system kept the last run's reasoning.

Message sessions and the dead-letter queue do not change that picture. Sessions group related messages under a session identifier so one receiver can process them in strict first-in, first-out order. That handling belongs to the session flow, not to a shared history that other tools and later runs consult before starting. The dead-letter queue, a subqueue attached to every queue and subscription, holds messages that cannot be delivered or processed, expire, or exceed the delivery count, with a reason and description for each one. It preserves the failing payload for inspection. It preserves nothing about what each failed attempt learned.

What the next run actually needs before it starts

A scheduled agent consuming from a queue or subscription usually needs four things at the start of a run. It needs to know which messages were already handled to completion, so a redelivery does not trigger the same work twice. It needs conclusions earlier runs reached, so a question settled last week stays settled. It needs the reasoning behind a decision, so a later run can tell why a step was skipped instead of guessing. And it needs that past to be shared, so another agent working in another tool on related messages reads the same history instead of a private fragment.

Service Bus supplies none of those four, because none of them are messages waiting for delivery. They are memory, and memory belongs in a layer built to hold it.

That layer is what Vilix AI provides. Vilix AI is cloud-hosted, with zero infrastructure to run: there is no extra broker to provision beside the namespace and no memory service to operate. The same memory is available everywhere over MCP, so the receiver doing the work, the chat tool used to review the outcome, and every other connected agent read and write one shared memory rather than separate local notes. Vilix AI also stores full conversation history, not just extracted facts, so a later run can revisit what was actually discussed and decided, in context, instead of working from a compressed summary.

The division of labor stays clean. Let Service Bus do the job it is built for: holding each message durably, locking it safely for one receiver, redelivering it when a lock expires, and dead-lettering it when delivery keeps failing. Let the memory layer hold what a queue was never shaped to hold: the record of finished work, the conclusions, and the reasoning, written by each run as it ends and read by the next run before it begins. A redelivered message then meets an agent that can check that record first, recognize work already done, and move straight to what is genuinely new.

There is no cost to testing the split. Vilix AI has a free plan that stays free forever, and Pro comes with a 7-day trial that needs no credit card. The memory remains portable throughout: export everything or delete it anytime. Service Bus will keep the next message safe until a receiver is ready for it. The memory makes sure the receiver arrives ready, carrying every earlier run with it instead of a blank start and a payload.