Does Amazon SQS Remember Between Runs? A Queue Keeps Your Message for Up to 14 Days. The Next Run Still Starts With Only That Message.

Amazon SQS remembers a message extremely well, for a short and strictly defined window. It stores that message redundantly across Availability Zones, hides it while a consumer works on it, brings it back if the consumer never deletes it, and moves it to a dead-letter queue after repeated failures. What SQS never remembers is anything the consumer learned while processing the message. Understanding that split, between a queue that keeps the work item and a run that keeps nothing, is the fastest way to see why scheduled agents built on SQS still repeat finished work, re-ask settled questions, and start every run briefed only by the next message in line.

Retention is a countdown, not a memory

Every SQS message lives under a retention period. The default is four days, and the setting can run from sixty seconds up to fourteen days. Inside that window, an unprocessed message waits safely: a consumer can be down for a weekend and the work is still there on Monday. Outside that window, SQS deletes the message automatically, even if no consumer ever received it. Retention is generous for a delivery system and absolute as a storage policy. Nothing in a queue is designed to be consulted next month.

That design is correct for what a queue is. SQS exists to move a unit of work from a producer to a consumer reliably, not to build a record of what the work produced. The message body, up to 1 MiB, plus up to ten message attributes, is the entire payload. When a scheduled automation sends a nightly job through SQS, the queue faithfully preserves the instruction. It preserves nothing about the outcome, because the outcome was never sent to the queue. It happened inside the consumer, and when that consumer process ends, the outcome ends with it unless something else was asked to keep it.

Receiving hides a message. It does not record a result.

The visibility timeout is the mechanism operators feel most directly. When a consumer receives a message, SQS does not remove it. It hides it for the visibility timeout, thirty seconds by default and twelve hours at most. If the consumer finishes and deletes the message in that window, the work is done and gone. If the consumer crashes, hangs, or runs long, the timeout expires, the message becomes visible again, and another consumer picks it up and starts the same work from the beginning.

Read that behavior as a memory statement. The queue tracks exactly three states for a message: sent, received, deleted. It counts receives, and after the count passes the maxReceiveCount in a redrive policy, it moves the message to a dead-letter queue for investigation. A dead-letter queue is a pile of messages that failed, with the original payload intact. It is not a log of what each attempt found. A run that spent twenty minutes checking a customer's history, reached a conclusion, and then timed out leaves the queue exactly as informed as a run that never started. The next consumer receives the same bytes and repeats the same twenty minutes.

Standard and FIFO queues change delivery, not memory. Standard queues deliver at least once, with best-effort ordering, so a message can arrive twice. FIFO queues preserve order and deduplicate sends inside a five-minute deduplication window. Both are valuable guarantees about the message. Neither one adds a field for a finding, a decision, or a reason. The most carefully configured queue in an account still hands the next run a payload and nothing else.

What a scheduled SQS consumer actually needs

A scheduled agent behind a queue usually needs four things on its next run. It needs to know which messages it already finished, so completed work is not repeated when a duplicate arrives. It needs the conclusions from earlier runs, so a question settled last week is not investigated again from zero. It needs the context that surrounded a decision, so a later run can tell why a step was skipped rather than simply that it was. And it needs all of that to be shared, so a different agent, in a different tool, picking up related work reads the same past instead of a private one.

A queue provides none of those four, because none of them are messages. They are memory, and memory belongs in a layer built for it.

That memory is what Vilix AI provides as a shared memory layer. Vilix AI is cloud-hosted, so there is zero infrastructure to run or maintain: no extra store to provision and no memory service to deploy next to the queues. The same memory is available everywhere over MCP, so the worker that consumes the queue, the chat tool used to review its output, and every other connected agent read and write one shared memory instead of separate local notes. And Vilix AI stores full conversation history, not just extracted facts, so a run can revisit what was actually said and decided, in context, rather than working from a compressed summary.

The practical split is simple. Let SQS do the job it is excellent at: delivering each unit of work at least once, surviving consumer failures, and holding a backlog safely for up to fourteen days. Let the memory layer hold what the queue was never shaped to hold: the finished-work record, the conclusions, and the reasoning, written by each run as it completes and read by the next run before it starts. A message that arrives for the second time then meets an agent that can check its own history first, see that the work is already done, and move on instead of repeating it.

Getting started costs nothing to test. Vilix AI has a free plan that stays free forever, and the Pro plan comes with a 7-day trial with no credit card required. The memory stays portable the whole time: export everything or delete it anytime, on demand. The queue keeps the next message safe until a consumer is ready for it. The memory makes sure the consumer is ready for the message, with every earlier run behind it instead of a blank start and a payload.