Inngest Remembers Every Step of a Run. Your Next Run Still Starts Blank.

Inngest's pitch for agents is seductive: durable agents that survive failures, wait for people, and resume without redoing model or tool calls. It reads like memory. If you squint, it sounds like the agent never forgets. Then you run a scheduled agent on it for a month, and you watch it re-learn the same lesson every single morning. Here is what is actually going on.

What "resume" means in Inngest

Inside one run, Inngest's durability is real and well-built. An agent is a loop: call the model, run a tool, feed the result back, repeat. Inngest turns each iteration into a step. Each finished step gets checkpointed. When something breaks, a failed tool call retries on its own, earlier model calls are not re-run or re-billed, and the run picks up exactly where it stopped. The run can even sleep for days waiting on a human approval and cost you nothing while it waits.

That is the full extent of the promise. "Survive" means the run survives. "Resume" means the run resumes. Both verbs point inward, at the run itself.

A scheduled agent adds one more fact. Every night, or every hour, a trigger fires and a fresh run begins. That run receives one thing: the trigger event. It does not inherit the previous run's reasoning, its conclusions, or anything it discovered yesterday. Yesterday's trajectory sits in the dashboard, fully readable, by you. Your agent will never see it.

The gap, in two scenes

Scene one. You run a nightly digest agent. It scans a set of sources, picks the ones worth reading, and writes a summary. You notice it keeps re-reading the same low-value sources every night, the ones it already decided were junk three weeks ago. You open the trace from last night and there it is, plain as day: the agent evaluating those sources, dismissing them, moving on. The agent wrote its reasoning down. It just wrote it into a place no future version of itself can reach. Every morning is day one.

Scene two. A support-triage agent handles the queue on a schedule. Two weeks ago it sorted out a gnarly pattern: refund requests that mention a specific error code are all caused by one known outage, and the right move is a canned answer plus a ticket link. Since then it has re-derived that same conclusion, from scratch, eleven times. Each time it burns tokens to get back to a place it has already been. Each time it gets a little less sure, because each re-derivation is a fresh roll of the dice. The customer experience wobbles. Nothing in the system remembers that this was settled.

In both cases the durable execution layer performed flawlessly. Nothing crashed. Nothing repeated within a run. Every trace pristine. And the operator still got an amnesiac agent, because durability protects a run and memory connects runs, and nobody built the second part.

Why the DIY fixes keep disappointing

Once people see the gap, they try to close it themselves, and the same three attempts keep appearing.

The first is packing yesterday into today's trigger. The agent writes a summary at the end of each run, the scheduler fishes it out and injects it into the next event payload. This holds together for a week. Then the payload balloons, the summary format quietly changes between deploys, ordering assumptions harden into load-bearing bugs, and the team starts treating the event payload like a database it was never meant to be.

The second is a hand-rolled memory database. Notes into Postgres at the end of the run, a query at the start. Honest engineering, and honest cost: schema design, write discipline, retrieval logic, pruning, and the slow realization that you are now maintaining a memory product alongside the automation you actually wanted to build.

The third is doing nothing and paying the token bill. The agent re-derives everything every run. It works, in the sense that nobody has to build anything. It just never compounds. Every morning costs what the first morning cost.

All three share the same flaw. They treat memory as something the automation should carry around, instead of something the agent should be able to ask for and add to, like it does everywhere else.

One memory across every run: Vilix AI

Vilix AI is a cloud-hosted memory layer, so there is zero infrastructure to babysit. Connect your agent once and it has memory from the first run. The same memory follows the agent everywhere over MCP: the Inngest-scheduled run, the local session where you debug it, Claude, Codex, any connected tool. One memory, every device, every app.

It stores full conversation history, not just distilled facts, so the agent can go back and read what actually happened instead of working from someone else's summary. Retrieval finds what the agent meant through semantic search and matches exact strings through keyword search, so nothing slips between the two.

For a scheduled agent the shape is tiny: at the start of each run it loads its relevant context, at the end it saves what mattered. Inngest keeps making every run durable. Vilix AI makes the runs add up.

The free plan is free forever. A 7-day Pro trial needs no credit card. Export everything or delete the whole account instantly, whenever you want, no waiting period. Your data stays yours.

Two jobs, two tools

Durable execution solved the hard problem of making a single agent run reliable. Nobody wants to re-run a hundred model calls because the last one timed out. Inngest owns that job, and it is good at it.

Memory is the other job: the one where last night's run makes tonight's run smarter. That layer lives outside the run, shared across every run and every tool. Once you see the two as separate jobs, the fix stops being mysterious. Keep Inngest for durability. Give the agent a memory that outlives any single run. Then watch what happens when your agents stop waking up blank.