Does Beanstalkd Remember Between Runs? Jobs Live in Tubes. The Next Job Still Starts With Only Its Body.

Beanstalkd is a simple, fast work queue. A producer puts a job into a named tube, a worker reserves the next job, runs it, and deletes it. For a team whose jobs do AI work on a schedule, that raises a practical question: when the same job runs again tomorrow, does it know anything about today's run? No. Beanstalkd stores the job exactly as it was put, as an opaque body with a priority, a delay, and a time to run. The next job still starts with only its body. What the last run found is not passed along.

A job is an opaque body in a tube, and the server never reads it

The put command inserts a job into the tube a client is currently using. It carries a priority, a delay, a time to run, and the length of the body, followed by the body itself. The protocol is explicit about that body. Each job body is an opaque sequence of bytes. The server never inspects or modifies a job body and always sends it back in its original form. It is up to the clients to agree on a meaningful interpretation of job bodies.

That design is what makes Beanstalkd fast and general. The server does not need to understand JSON, a customer id, or a research question. It only needs to hold the bytes reliably and hand them to the next available worker. A worker reserves a job, receives exactly those bytes, and acts on them. If a previous run learned that the account was already reviewed or that a person had already explained an anomaly, none of that is in the body unless the producer already knew it at put time and wrote it in.

Tubes sharpen the same point. A tube is a named queue, created on demand when a client uses or watches it, and deleted when it is empty and no client refers to it. Tubes organize where jobs wait. They do not organize what jobs learned. There is no tube-level history a worker reads before reserving, and no shared note that accumulates across the jobs that passed through the same tube.

A finished job is deleted, and its findings leave with it

The typical job lifecycle is short on purpose: put, reserve, delete. After the put command, a job starts out ready. It waits in the ready queue until a worker reserves it. The worker runs it, and when the work is finished the worker sends delete, and the job is gone. That final step is the whole result handling Beanstalkd defines. There is no result store, no return value kept for the next job, and no summary merged into a future body.

The other states describe delivery problems, not learning. A job can be delayed, so it becomes ready later. A reserved job that is not deleted, released, or buried within its time to run is put back into the ready queue, so another worker can try it. A buried job is held aside for a person to inspect and later kick back or delete. Every one of those moves answers an execution question: should this exact job run now, later, again, or not until a person looks at it?

Statistics follow the same boundary. The stats-job command reports counters such as reserves, timeouts, releases, buries, and kicks, plus the job's age and time left. A peek command can show the body of a ready, delayed, reserved, or buried job. That body is still the original body, unchanged by whatever the last worker discovered while running it. The history Beanstalkd keeps is an operations history. It is not assembled into a handover that the next job reads before it starts.

Persistence protects the job itself, not what the job learned

Beanstalkd holds jobs in memory and offers persistence through a write-ahead log, often called the binlog, enabled with the -b directory option. When the server restarts, the log is read, jobs are restored, and their tubes are recreated as needed. With it, pending work survives a restart.

Either way, persistence answers a delivery question. A delayed job still arrives after a restart, a buried job is still waiting for inspection, and a ready job is still ready. Persistence does not add a memory of completed work. A job that was run to completion and deleted before the restart leaves no briefing behind for its successor. The log protects jobs that have not finished. It does not remember for jobs that have.

Consider a scheduled AI job running through Beanstalkd. On Monday the job checks a set of sources, flags two changes, and notes that a third change was already approved last week. On Tuesday a new job is put with the same shape of body. Without an outside memory, it checks the same sources from scratch, flags the same two changes again, and has no record that the third was already approved. The delivery is correct. The work is repeated, because each job arrives alone.

What a scheduled Beanstalkd job actually needs

The missing piece is not a better tube. Beanstalkd already does the queue job well: priority ordering, delays, time to run protection, bury and kick for problem jobs, and optional log-based persistence. The missing piece is a memory that sits outside any single job, that a job 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 database to provision and no memory service to deploy next to beanstalkd. The same memory is available everywhere over MCP, so the worker that reserves the job, 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 job changes shape. Before it checks anything, it loads what Monday's job saved: which sources were covered, which changes were flagged, and which one was already approved. It spends its time on what is new, then saves its own findings back, so Wednesday's job starts briefed as well. The tube still delivers the job. 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 job that redoes finished work, that is the simplest test: give the next job the last job's memory and watch repetition disappear.

Beanstalkd will keep handing each job to the next worker unchanged. The question is only whether the job arrives alone. With a shared memory layer beside the queue, it arrives knowing what the job before it learned.