Does Sidekiq Remember Between Runs? Jobs Live in Redis. The Next Job Still Starts With Only Its Arguments.

Sidekiq stores every job in Redis before any worker touches it. That storage is real and durable: queues, scheduled jobs, retries, and dead jobs all survive a worker restart. None of that storage is a briefing for the next job. A new job arrives with the class name and arguments it was enqueued with, and nothing the previous job learned is added to it.

What Sidekiq actually keeps in Redis

Enqueueing a job serializes a small JSON payload and pushes it into Redis. The payload holds the job class, its arguments, its queue, a unique job ID, and options such as retry. Because arguments go through JSON, Sidekiq guidance is to pass small, plain values: pass an ID and look the record up fresh inside perform, instead of passing a whole object.

Delayed work is stored too. A job sent with perform_in or perform_at waits in a scheduled sorted set in Redis, scored by the time it should run, and moves to its queue when due. The Web UI reflects the same storage: queues, retries, scheduled jobs, and the Dead set are all views over what Redis holds.

Failure leaves a record as well. A job that raises is retried with exponential backoff, by default up to 25 attempts spread over about three weeks. A job that exhausts its retries moves to the Dead set, where it can be inspected and retried by hand.

Two narrower features keep state inside a single job's life. Iterable jobs, available since Sidekiq 7.3, store a cursor in Redis under a key tied to the job ID, so an interrupted long job can resume where it stopped; that cursor data is removed when the job completes. Batches group jobs and fire callbacks when the group succeeds, completes, or a job dies. Both help one job or one batch finish. Neither passes context to the next independent job.

Recurring schedules work the same way. Periodic jobs in Sidekiq Enterprise, and scheduler gems in the open-source setup, register a cron expression and a job class, and each firing creates a fresh job with the registered arguments.

What the next job starts with

A worker pulls the payload, runs perform with the stored arguments, and that is the whole starting context. If a recurring job fires every morning with the same arguments, every morning's perform receives the same starting point, whatever yesterday's job discovered, decided, or promised.

There is no step where Sidekiq reads yesterday's job and briefs today's. A completed job does not leave a retrievable summary attached to its class or queue for the next run to pick up. Its arguments and its failure history, if it failed, stay inspectable in Redis or the Web UI, but an operator or a dashboard reads those records. The next job does not.

The schedule proves even less. Knowing that a periodic job fired at 7 a.m. proves the clock worked. It says nothing about what the job found, what a customer replied overnight, or which follow-up is now due.

Take a scheduled job that checks new support requests each morning and drafts replies with an AI model. Sidekiq holds the job, runs it, and counts it as processed. Tomorrow's job starts from its arguments again. It does not know that one requester already answered the clarifying question, that a person edited a draft and explained the correction, or that another thread was promised an update today. It can draft the same question again, neatly worded, with complete confidence.

The store operators end up building by hand

The usual fix is a second store next to Redis. A table holds the last summary per customer. Extra Redis keys hold open items, last-seen IDs, and flags for work already done. Code before perform reads those stores, assembles a briefing, and hands it to the AI step. The memory becomes a side system to design, test, and keep correct as jobs and prompts change.

That side store also keeps less than the agent needs. A summary row is a run compressed to its ending. The next decision often turns on the middle: the original request, the option that was rejected, the correction a person gave, and the reason the decision went one way instead of another. If only the final status was saved, the next run inherits the conclusion with none of the exchange that produced it.

Scope narrows it further. The table belongs to that one Ruby service. The same operator usually runs agents elsewhere too: another queue, an n8n or Make scenario, and AI tools used directly in chat. Each place keeps its own partial record, and a decision made in one never reaches the morning Sidekiq job unless someone copies it across by hand.

A memory that lives outside the job

The cleaner shape is to keep execution in Sidekiq and give the agent a memory that lives outside any single job, service, or tool, which every run reads at the start and updates at the end.

Vilix AI is built for that layer. It is cloud-hosted with zero infrastructure to run, so there is no extra store to provision, secure, or keep alive between schedules. It is available over MCP, so the same memory follows the agent across a Sidekiq worker, another automation platform, and the AI tools used directly. One memory, reachable everywhere the work happens.

Vilix AI stores full conversation history, not just facts or final results. A scheduled agent can revisit the actual exchange: what was asked, what was tried, what a person corrected, and what was settled. That history is what stops a second run from asking a settled question again, repeating a follow-up that already went out, or drafting against an instruction that changed in conversation yesterday.

In a Sidekiq setup the pattern stays small. Before the job calls the model, it retrieves the relevant history for that customer, project, or workflow, does the work with the past in view, and saves the new exchange and outcome back before it finishes. Sidekiq keeps scheduling and retrying, Redis keeps holding job payloads, and the continuing story lives in the memory layer, where the next run in any tool can find it.

Data in Vilix AI can be exported or deleted at any time. The free plan is free forever, and Pro offers a 7-day trial with no credit card required, so the pattern can be tested on one recurring job first.

The short answer

Does Sidekiq remember between runs? In the storage sense, yes: queued and scheduled payloads, retries, dead jobs, and an iterable job's cursor all persist in Redis. In the working sense an AI agent needs, no: the next job receives only the arguments it was enqueued with and starts fresh, unless code you write fetches the past and rebuilds a briefing for it.

Let Sidekiq do queuing, scheduling, and retries. Give the agents inside those jobs a shared memory outside them, and each run can start where the last one actually left off.

Start at Vilix AI and connect one recurring job first.