Does RQ Remember Between Runs? Jobs Are Stored in Redis. The Next Job Still Starts With Only Its Arguments.

RQ stores a surprising amount in Redis. A job keeps its function name, its arguments, its status, its timestamps, and, for a while, its result. A failed job can stay on record for a year. None of that storage briefs the next job. A new job arrives with the function and arguments it was enqueued with, and nothing the previous job learned is added to it.

What RQ actually keeps in Redis

Enqueueing a function creates a Job and pushes its ID onto a queue. The queue itself is a Redis list, and each job is stored as a Redis hash under a key built from its job ID. That hash holds the job's origin queue, its function name, its args and kwargs, its status, and its timing fields, including when it was enqueued, started, and ended.

Status moves through a clear lifecycle: queued, started, then finished or failed, with deferred for jobs waiting on a dependency, scheduled for jobs set for a future time or a retry, and canceled for jobs stopped by hand. Registries in Redis track those states per queue, including the started, finished, failed, deferred, scheduled, and canceled registries, so an operator can inspect what ran and what did not.

Scheduling is stored the same way. A job can be enqueued for a specific time or after a delay, and it sits in the scheduled registry until it is due. Dependencies work through depends_on: a job stays deferred until the job it depends on finishes, then it moves to the queue. Callbacks such as on_success and on_failure can run a function inside that planned chain. All of that connects jobs that were planned together.

Results are kept on a short clock. When a job finishes, a Result object holds its return value, and both the job and the result persist in Redis until result_ttl runs out. That value defaults to 500 seconds. Failed jobs are kept much longer: failure_ttl defaults to one year, and the job record holds exception information for inspection. A job also has a meta dictionary where code can store custom data on the job itself and save it back.

What the next job starts with

A worker picks up a job, reads its function and arguments, and runs it. If a scheduler enqueues the same function every morning with the same arguments, every run receives the same starting point, whatever yesterday's run discovered, corrected, or promised.

There is no step where RQ reads yesterday's finished jobs and briefs today's. A completed job does not leave a summary attached to its queue for the next job to retrieve. Its result sits in Redis for about eight minutes by default and then expires. Its meta belongs to that one job record. Its failure record, if it failed, is there for a person to inspect, not for the next job to learn from automatically.

Take a scheduled job that reviews new support messages each morning and drafts replies with an AI model. Tomorrow's job starts from its arguments again. It does not know that one customer already sent the missing screenshot, that a person edited a draft and explained the correction, or that another thread was promised an answer today. It can ask for the same screenshot 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, and extra keys hold open items and flags for work already done. Code at the top of the job 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.

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 behind it.

Scope narrows it further. The table belongs to that one Python 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 job unless someone copies it across by hand.

A memory that lives outside the job

The cleaner shape is to keep execution in RQ and give the agent a memory outside any single job 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 an RQ 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 an RQ setup the pattern stays small. Before the job calls the model, it retrieves the relevant history for that customer or workflow, does the work with the past in view, and saves the new exchange and outcome back before it finishes. RQ keeps enqueueing, scheduling, and retrying, 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 RQ remember between runs? In the storage sense, yes: jobs are stored as Redis hashes, finished results are kept until result_ttl expires, and failed jobs are kept for a year by default. In the working sense an AI agent needs, no: the next job receives only its function and arguments and starts fresh, unless code you write fetches the past and rebuilds a briefing for it.

Let RQ do queueing, scheduling, and dependencies. Give the agents inside those jobs a shared memory outside them, and each run can start where the last one left off.

Start at Vilix AI.