Does Agenda Remember Between Runs? Jobs Are Stored in MongoDB. The Next Job Still Starts With Only Its Data.

Agenda remembers jobs very well. Every job is written to MongoDB before it runs, so schedules survive restarts, crashes, and deploys. That persistence is real, and it is also easy to misread. When a job runs, Agenda hands the handler one job document: a name, a schedule, and the data object that was saved with that job. What the last run figured out is not in that document unless the last run deliberately wrote it there.

A job is a stored document, not a continuing conversation

The model is simple. Code defines a processor with agenda.define, giving a job name and a handler function. Code then creates jobs with agenda.schedule for a single future run, agenda.now for an immediate run, or agenda.every and repeatEvery for a recurring schedule. Agenda stores each job as a document in a MongoDB collection, by default called agendaJobs, and a processor polls that collection, locks a due job, and runs its handler.

Open that document and the memory question answers itself. The fields describe an instruction and its bookkeeping: the job name, the data payload, nextRunAt, lastRunAt, the repeat interval for recurring jobs, a lock timestamp while a job is being processed, and failure details when a run fails. The data field is the payload supplied at creation time, such as a customer ID, a list ID, or a report type. It is an input. It is not a running record of what previous executions learned.

The handler receives a fresh job object for each execution. Code can read job.attrs.data, change fields on the job, and call job.save to write those changes back to MongoDB. That save step is the whole bridge between runs, and it is manual. If the handler finishes without saving new state into the job document or into some other store, the next execution starts from the same stored input as the last one. Fields set in memory during a run, local variables, intermediate results, and the reasoning behind a choice all end when the process moves on.

What MongoDB actually keeps between runs

Agenda does keep a durable record, and naming it exactly matters. The collection holds every pending job with its schedule, so a restart loses nothing that was due later. Recurring jobs keep their registration: one document carries the repeat interval, and Agenda advances nextRunAt after each run so the same job fires again on schedule. Locking keeps two processors from running the same job at the same time, and failed jobs keep their error information so the failure can be inspected and the job can be retried or rescheduled.

That is a scheduler's memory, and it is good at its job. It answers operational questions: what is due, what ran last, what failed, and what runs next. It does not answer working questions: what did the last run find, which items did it already handle, and what did it decide? A completed one-time job is removed or left as a finished record depending on configuration, and a recurring job's document still holds the same original data payload, updated only where code explicitly saved a change. Checking the collection after a week of runs shows a healthy schedule. It does not show a week of accumulated understanding.

There is also no built-in handoff between different jobs. A morning job and an afternoon job, even in the same Agenda instance and the same collection, share nothing by default. Each handler starts from its own document. Any continuity between them has to be built by hand: a shared collection, a state file, or a summary document that every handler knows to read first and update last.

Where this leaves scheduled AI work

Add an AI step inside an Agenda job and the gap becomes practical. Consider a job that runs every morning, reviews new signups, enriches each record, and drafts a follow-up message matched to what each signup actually did in the product. Agenda guarantees the timing, the locking, and the retry behavior. The schedule is dependable.

The memory questions sit one level up. Which signups did yesterday's run already contact, so nobody gets a second first message? Which draft wording did a human edit before sending, so today's drafts start from the corrected version? Which account was marked as needing a slower, more careful follow-up, and why? The job document answers none of these. Its data says which segment to process. Its timestamps say the run happened. Everything the next run needs to do the work well sits between those two facts, and teams typically end up assembling it themselves: an extra collection for results, a notes field stretched past its purpose, and a prompt rebuilt from fragments at the start of every run.

A memory layer the next run can actually read

Vilix AI is built for that missing layer. It is cloud-hosted with zero infrastructure to manage, so an Agenda job, a standalone script, and a chat tool can all reach the same memory without another database to provision, secure, or maintain. The memory follows over MCP, which means the same memory is available everywhere the work happens, not locked inside one scheduler's collection or one application's tables.

What is stored matters as much as where it lives. Vilix AI keeps full conversation history, not just extracted facts, so a later run can revisit what was actually decided, drafted, and corrected, in context. The morning job can save its working history at the end of a run, and the next run can load the relevant part at the start: signups already contacted, wording already approved, accounts already flagged and the reasons behind each flag. Agenda keeps doing what it is good at, durable scheduling in MongoDB, while the working memory lives in a layer designed to hold it.

Getting started is kept deliberately light. Vilix AI has a free plan forever, and Pro offers a 7-day trial with no credit card required. Data stays under the user's control, with the ability to export everything or delete it anytime. One recurring job is enough to test the pattern: save the run's history at the end, read it back at the start of the next run, and compare the drafts.

The short answer

Does Agenda remember between runs? It remembers the job: the stored document, its data payload, its schedule, its locks, and its failure record, all persisted in MongoDB across restarts. It does not remember the run: what the job found, decided, or produced, beyond what code manually saved back into a document. For scheduling and delivery, the stored job is enough. For scheduled AI work that needs its own history back, the memory needs to live outside the job document, in a shared layer like Vilix AI that every run and every tool can read.