Your Pipedream Workflow Remembers. Your AI Agent Still Wakes Up Blank.

A Pipedream workflow watches a shared inbox, and every morning an AI step inside it drafts replies to partner emails. On Monday the agent learns the partner's new procurement contact and addresses the draft correctly. On Tuesday it drafts to the old contact again, as if Monday never happened. The workflow ran fine both days. The data is all still there. The agent simply never looks at it.

This is the split most Pipedream operators discover the hard way: the workflow has memory, the AI step does not, and nothing connects the two unless you build the connection yourself.

The straight answer

Do Pipedream workflows remember between runs? They can, through two built-in mechanisms. Neither one gives your AI step memory automatically. Keep that distinction in mind and the rest of this post is straightforward.

What a run knows when it starts: nothing

Every Pipedream execution begins with a blank slate. Local variables, assembled objects, the previous run's model output, all gone. The next run cannot see any of it. That default is sensible for moving data from A to B. It is the wrong default the moment a model inside the workflow is supposed to learn from experience.

$checkpoint, the single sticky note

The simplest persistence Pipedream offers is $checkpoint: one value per workflow that survives between executions. Read it, change it, write it back. The textbook use is a counter, or remembering the last ID you processed so the next run picks up where this one stopped.

It is deliberately small, and it has one sharp edge worth knowing. When two events fire the workflow at once, both executions run in parallel, and the last one to finish wins, silently overwriting what the other saved. Pipedream documents this race condition and recommends serializing execution when state matters. A scheduled AI step that runs long is exactly how you get overlapping runs without noticing, and the symptom, a counter that jumps backward or a "last processed" marker that regresses, looks like a model problem when it is really a storage problem.

Data Stores, the filing cabinet

For anything bigger than a sticky note there are Data Stores: Pipedream's native key-value storage, no external database required. Values persist across workflow executions, stores can be shared between workflows, and the dashboard lets you inspect and edit the contents directly. Records can expire automatically via TTL, handy for rate limits and short-lived caches. The catch on format is narrow but real: only JSON-serializable data, strings, numbers, lists, dictionaries. Richer objects do not survive the trip.

A good Data Store use looks like this: a workflow that enriches new signups caches API lookup results by domain, so the second signup from the same company costs nothing. Or two workflows share one blocklist, updated by either, respected by both. These are excellent uses of persisted state. They are not agent memory, and the difference matters more than it sounds.

The missing half: nobody reads the cabinet to the agent

A Data Store can hold the fact that the partner's procurement contact changed. It cannot make the AI step read that fact before drafting. The model action inside your workflow receives exactly what the prompt contains, nothing more. Yesterday's learning reaches today's run only if you fetch it, format it, and inject it yourself, and today's learning reaches tomorrow only if you decide what to keep, summarize it, and write it back.

That loop is manual, and manual loops degrade in familiar ways. The fetch step gets commented out during debugging and never restored. The store accumulates raw run transcripts instead of conclusions, and the prompt balloons until the context window or the invoice complains. Key names multiply without an owner, stale entries linger, and the agent starts quoting decisions the team reversed weeks ago. The workflow remembers everything and the agent benefits from none of it, which is arguably worse than having no memory at all, because now there is a false sense of continuity.

There is one more structural point: Pipedream has no notion of a session spanning executions. You design the key scheme, the namespacing, the eviction policy. The platform keeps bytes durable. Deciding what the agent should remember, and proving it actually recalled it, is engineering you own end to end.

A quick decision test: plumbing or judgment?

Before reaching for heavier machinery, ask what the workflow actually does. If it moves, transforms, or dedupes data, Data Stores plus $checkpoint are the right tools and probably all you will ever need. If a model inside the workflow makes judgment calls, drafts text, scores leads, triages tickets, and those judgments should improve with experience, then you have a memory problem, not a storage problem. Storage answers "where do I keep this." Memory answers "what does the agent know when it wakes up."

When the filing should not be your job

Vilix AI exists for the second case. It is cloud-hosted, so there is zero infrastructure to run. The scheduled agent connects over MCP, or with an API key for headless setups, and consults the same shared memory at the start of every run, regardless of which platform or tool triggered it. Recall is semantic combined with keyword search, so the agent finds what it meant and still matches exact strings like order IDs and contact names. It stores full conversation history rather than just extracted facts, so a previous run can genuinely be revisited. The free plan is free forever, the Pro trial runs 7 days with no credit card, and everything can be exported or deleted instantly, in a portable format, at any time.

In Pipedream terms: instead of hand-rolling a fetch-format-inject-write loop around a Data Store and maintaining it forever, the agent gets a memory it reads on its own, every run, as part of how it starts work.

What to do Monday morning

Audit one scheduled workflow that contains an AI step and ask three questions. First, what does the agent demonstrably know at the start of a run that it did not know last month? Second, who owns the schema of whatever you store between runs, and when was it last cleaned? Third, what happens when two runs overlap? If the answers are uncomfortable, you have found the gap this post describes. Close it with owned, distilled state and serialized writes, or close it with a memory layer, but do not leave the AI step waking up blank while the workflow around it remembers everything.