Does Hatchet Remember Between Runs? Durable Steps, Yes. Agent Memory, No.

Short answer: Hatchet remembers a workflow while that workflow is running, and it keeps a record of runs after they finish. It does not give a scheduled agent a memory that carries from one separate run to the next. A cron-triggered run that starts on Tuesday does not automatically know what Monday's run learned, decided, or promised, unless that information was stored somewhere and loaded back in on purpose.

That distinction matters because Hatchet is genuinely strong on durability. Confusing durable execution with agent memory is how a reliable pipeline still ends up repeating finished work.

What Hatchet actually persists

Hatchet is an open-source orchestration engine built on Postgres. Postgres is its durability layer for both the task runtime and observability, which shapes everything it keeps.

Every workflow run is persisted. Workflows are predefined steps stored in PostgreSQL. If a worker dies or stops heartbeating mid-run, Hatchet can reassign the task, apply retries and timeouts tracked in the database, and continue the run instead of losing it.

Step inputs and outputs are stored. Hatchet stores the input and output of each workflow step in the database. Resuming a multi-step workflow is therefore straightforward: a later step, or a retried step, can work from what an earlier step produced inside that same run.

Durable tasks can pause and resume. A durable task can wait through a durable sleep, wait for an event, or pause for a long-running operation and then resume. That pause lives inside one workflow run. It is continuity within a job, not learning across jobs.

Run history is kept for inspection. Hatchet persists the history of executions up to a defined retention period, so operators can monitor, debug, and audit what happened. A history you can open in a dashboard is useful for people. It is not automatically context an agent reads before it acts on the next run.

Schedules create new runs. Hatchet supports cron scheduling and one-time scheduling. Each trigger starts a fresh workflow run with the input that run was given. The schedule remembers when to fire. It does not brief the new run on the last run's conclusions.

Where the boundary sits

Think of two different questions an operator asks about a nightly agent that reviews support escalations, drafts replies, and updates a tracker.

The first question is reliability: if the worker crashes halfway through tonight's list, does the work survive? Hatchet answers that well. The run is durable, steps are tracked, retries are managed, and nothing silently vanishes.

The second question is continuity: when tonight's run starts, does the agent know which escalations were already answered yesterday, which customer was told to wait until Friday, and which draft a human already edited and approved? That is a different kind of memory. It lives across separate runs, across days, and often across tools. Hatchet's run store was not built to answer it. Yesterday's run is a completed record. Tonight's run does not search it, reason over it, and apply its lessons unless a developer builds that retrieval by hand.

The gap shows up in predictable places:

• A scheduled agent re-contacts a customer because the note that the customer already replied lives only in a previous run's output.
• A daily summary repeats the same warning because the new run cannot tell what was already reported, and what changed since.
• Two workflows that touch the same customer keep separate histories, so neither one knows what the other already did.
• A person continues the work in a chat assistant, and that assistant has no access to what the Hatchet workflow concluded the night before.

None of that is a failure of orchestration. It is the normal boundary of an execution engine: it guarantees the work runs, retries, and finishes. Remembering what the work meant is a separate job.

The usual workaround, and its cost

Teams that hit this boundary usually add storage next to Hatchet: a Postgres table for run state, a file for the last summary, or a key that holds the items already processed. That can work for one narrow check, like a list of processed IDs. It gets heavier when the thing that needs to carry over is not an ID but a judgment: why an item was held, what a customer actually asked for, which exception was approved, and what the next step was supposed to be.

Hand-built state also stays tied to that one workflow. Another agent, another platform, or a teammate's assistant cannot easily read it, search it, or add to it. Over time the state store becomes a small memory system that the team has to design, secure, clean up, and explain, on top of the orchestration it already runs.

The layer built for the part Hatchet does not cover

Vilix AI is a hosted memory layer for exactly that cross-run part. Agents connect to it over MCP, check what earlier runs recorded before acting, and save what the current run decided so the next run starts with context instead of a blank slate.

It fits scheduled work in four specific ways:

Cloud-hosted, with zero infrastructure to run. There is no extra database, server, or cache to provision and maintain. The memory is hosted, and an agent connects to it.

The same memory everywhere. Because the memory is reached over MCP, it is not locked inside one workflow engine. A Hatchet workflow, an agent in another automation tool, and an assistant on a phone or laptop can all read and write the same shared memory.

Full conversation history, not just facts. Vilix AI stores the actual history, including decisions and the reasoning around them, so a later run can revisit what was said and why, not only a shortened status line.

Free to start, clean to leave. The free plan is free forever. The Pro trial runs for 7 days with no credit card required. Data can be exported or deleted at any time, so trying the layer does not trap the history inside it.

How the two fit together in practice

Keep Hatchet for what it does best: queuing, scheduling, durable steps, retries, and observable execution. Add a memory check around the parts of the workflow where judgment needs to survive the run boundary. Before the agent acts on an item, it looks up what previous runs recorded about that item. After it acts, it writes back what it sent, decided, deferred, or is still waiting on.

So, does Hatchet remember between runs? It remembers a run while it runs, and it keeps run history after. It does not carry an agent's learning from one scheduled run into the next. Give those runs one shared memory outside the engine, and Tuesday's run can finally start where Monday's run left off.