Does NATS Remember Between Runs? JetStream Keeps Every Message in the Stream. The Next Run Still Starts With Only Its Message.

NATS is a lightweight messaging system built around subjects. A publisher sends a message on a subject, and subscribers listening on that subject receive it. JetStream, the persistence layer built into the same NATS server, stores those messages in streams so they can be replayed later. For a team whose scheduled agents and workers consume those subjects, that raises a practical question: when the next run picks up a new message, does it know anything about what the last run concluded? No. JetStream holds each message exactly as it was published. The next run still starts with only the message in front of it. What the last run found is not passed along.

Core NATS forgets on purpose, JetStream stores the message

Core NATS is fire-and-forget by design. Delivery is at most once: if a subscriber is offline when a message is published on its subject, that message is gone for that subscriber. Nothing is written to disk, and there is no log to catch up from. That simplicity is the point for live traffic where a missed signal is acceptable and speed matters more than history.

JetStream changes the delivery contract without changing the subject model. A stream captures messages published on its subjects into an append-only log, stored in memory or on file, and each stored message gets a sequence number. Publishers receive an acknowledgement that includes that sequence number, so a producer knows its message is stored before moving on. Streams keep messages under a retention policy set at creation: limits retention keeps them until an age, size, or count limit is reached, interest retention removes them once every known consumer has acknowledged them, and work queue retention removes a message after the first acknowledgement, which gives the stream job-queue behaviour.

Every one of those settings answers a delivery question: how long should published messages remain available, and when is it safe to delete them? None of them stores an outcome. Two consumers can read the same stored message and reach opposite conclusions about it, and the stream records neither conclusion. A retained message is the publisher's original payload and headers, unchanged. The stream organizes what was sent. It does not organize what any reader learned from it.

A durable consumer remembers a position, not a result

Progress in JetStream lives in its consumers. A consumer is a server-side view over a stream, and a durable consumer, created with an explicit name, keeps its state on the server across disconnects and restarts. That state is delivery state: which messages were delivered, which were acknowledged, which are still pending, and where in the sequence the consumer currently stands. If a worker crashes after receiving a message but before acknowledging it, the acknowledgement wait expires and JetStream redelivers that same message. Delivery is at least once, and exactly-once processing is supported through message deduplication and the double-acknowledgement protocol.

That bookkeeping is also the whole of what JetStream hands back. A resumed consumer knows where reading stopped. It does not know what the messages meant, which ones mattered, which checks were already run against them, or what decision the previous run made. A redelivered message makes the gap concrete: it is the original message delivered a second time. It carries no marker that part of the work was already done, no partial result, and no note from the run that handled it first. The worker has to work all of that out from the payload alone.

JetStream does include a key-value store and an object store built on top of streams, and a worker can write a value under a key during one run and read it back in the next. That is storage a team designs, keys, and maintains itself, holding exactly the values someone chose to put there. It is not a record of the run: the reasoning, the rejected options, and the findings that never became a key stay outside it, and every other tool in the workflow still has no route to what the worker saved there.

Consider a scheduled AI agent that consumes order events from a stream each night and checks them for fraud signals. On Monday it reviews a batch, spots a pattern across several orders from one account, and marks that account as already investigated. On Tuesday, new orders from the same account arrive on the same subject. Without an outside memory, the agent scores each order on its own contents and can treat the known pattern as brand new. The stream kept every order, replayable in sequence. The investigation still restarted, because a stored event and a stored finding are different things.

What a scheduled NATS consumer actually needs

The missing piece is not a longer retention period or a second stream. NATS already does the messaging job well: subject-based routing, durable streams with replay, durable consumers that resume after a failure, and retention controls for how long messages remain. The missing piece is a memory that sits outside any single message, that a consumer can read before it acts and write to when it finishes, and that every other tool in the workflow can also reach.

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 servers. The same memory is available everywhere over MCP, so the worker that consumes the stream, 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.

With that layer in place, the Tuesday run changes shape. Before it scores anything, it loads what Monday's run saved: which accounts were already investigated, which pattern was already identified, and which orders were already cleared and why. It spends its time on what is genuinely new, then saves its own findings back, so Wednesday's run starts briefed as well. The stream still delivers the message. The memory delivers the briefing.

Vilix AI is free forever on the free plan, and the 7-day Pro trial needs no credit card. Everything saved can be exported or deleted at any time. For a scheduled consumer that redoes finished work, give the next message the last run's memory and watch the repetition disappear.

NATS will keep holding each message in the stream until retention runs out, unchanged and replayable. The question is only whether the consumer arrives alone. With a shared memory layer beside it, it arrives knowing what the last run learned.