Free forever, no credit card.Get Started for Free →
← All posts
October 12, 2026 · 5 min read

AI by Zapier Resets Its Knowledge Every Run. Here Is What Actually Survives.

AI by Zapier Resets Its Knowledge Every Run. Here Is What Actually Survives. Zapier's documentation contains a sentence that every automation operator should read twice: AI by Zapier does not learn from previous actions. Each time an AI by Zapier action runs, the AI knowledge is reset to its initial state. If you run scheduled agents on Zapier, that sentence is the whole game. It explains the Monday morning mystery (why did the triage Zap misroute the same ticket type it misrouted last week?),

AI by Zapier Resets Its Knowledge Every Run. Here Is What Actually Survives.

Zapier's documentation contains a sentence that every automation operator should read twice: AI by Zapier does not learn from previous actions. Each time an AI by Zapier action runs, the AI knowledge is reset to its initial state.

If you run scheduled agents on Zapier, that sentence is the whole game. It explains the Monday morning mystery (why did the triage Zap misroute the same ticket type it misrouted last week?), the re-fetch waste (why does the research Zap re-read the same articles every day?), and the prompt that keeps growing (where else is "everything the agent learned" supposed to live?). None of these are misconfigurations. They are the platform working as documented.

Why the setup screens mislead you

Open an AI by Zapier step and it looks like the agent has a past. You can attach knowledge sources, up to 20 per step, drawn from Google Docs, Notion, Confluence, SharePoint, Dropbox, or uploaded files. Those sources sync into your Zapier account and stay there until you delete the content or the Zap. The Zap history shows every run in detail. The configure panel even keeps prompt versions around while the editor is open.

So it is natural to assume the agent remembers. Here is what each of those actually is:

Knowledge sources are a library, not a memory. They are read-only as far as the agent is concerned: the agent can consult the playbook, but it cannot write "this section of the playbook is wrong, here is the correction" back into it at the end of a run. A nightly lead-triage Zap will score the same lead source the same wrong way every night, because last night's correction was output, not knowledge.

Zap history is a dashboard for humans. It records which tools ran, what data passed through, which model tier was used, and exactly how many tasks each run consumed. None of it is visible to the next run. The operator can read what happened. The agent cannot.

Conversation history is real but fenced. With the ChatGPT app's memory key, a Zap can carry context across its own steps and follow-ups. But that history belongs to that Zap. A second Zap with different instructions starts from zero, because Zapier does not store and hand over cross-Zap context. Memory is per-Zap by design.

The Agents migration made this the default

This contract is not new, but it recently became the only contract. Zapier folded its standalone Agents product into AI by Zapier: agent tool calling, reasoning, and autonomous task execution now runs inside a single AI step in the Zap editor, on the same infrastructure as every other Zap. If you migrated from Agents, you did not just change where your agent lives. You moved it onto a step that forgets everything between runs.

There is a cost dimension to this amnesia. AI by Zapier bills per task, and the model tiers multiply it: Standard costs one task per run, Advanced three, Premium five, with extra cost per tool call. A scheduled agent that re-derives the same conclusions every run is not just making the same mistakes. It is burning the same multiplied task cost to make them. Memory is a cost control problem on Zapier, not just a quality problem.

What genuinely survives a run

Being precise about this matters, because the workarounds people build depend on it:

  • Knowledge sources survive as reference material. Good for playbooks, policies, and static context. Useless for anything the agent learned by doing.
  • Storage by Zapier survives as small values: counters, last-run timestamps, flags, a short list of IDs. Zapier describes it as a way to reference data between Zap runs or share data between different Zaps. It is the right answer when the handoff is a handful of values. It is the wrong answer when the handoff is judgment.
  • Mapped fields from earlier steps survive within a run. Each run's trigger payload and upstream step outputs are available to the AI step. This is how operators smuggle state in: the scheduler reads last run's summary from somewhere and packs it into the next trigger. It works while the state stays small. Then the payload becomes a dumping ground, ordering assumptions get baked into the scheduler, and nobody trusts what is in it anymore.

The decision tree operators actually need

Ask one question: what has to survive the run?

If the answer is two values and a timestamp, use Storage by Zapier and move on. If the answer is "the agent should get better at its job," neither Storage nor Tables will get you there, because what accumulates is not values but experience: which alerts are noise, which sources are stale, which classifications keep needing correction, which follow-ups are still open. Experience needs a place to live that is not a key-value store, not a prompt that grows forever, and not locked inside one Zap where the rest of your stack cannot see it.

That place is an external memory layer. Vilix AI is a cloud-hosted memory layer your agents connect to over MCP, so there is zero infrastructure to run and nothing to maintain. The same memory follows the agent across tools: the Zap, the chat assistant, the scheduled worker all read and write one shared store. It keeps full conversation history, not just extracted facts, so the agent can revisit what actually happened instead of trusting a summary someone wrote. It is free forever, with a 7-day Pro trial that needs no credit card, and your data stays portable: export everything or delete it anytime.

The pattern is boring on purpose. End of run: the agent writes what it learned. Start of run: the agent reads what is relevant. Knowledge sources keep doing what they are good at. The memory does the one thing a library cannot: it compounds.

Run the two-run test

Before building anything, run your Zap twice and ask the second run what the first one discovered. If it cannot answer, you now know exactly where the memory gap is, and you know the three things that look like memory but are not: the library, the dashboard, and the per-Zap conversation. Fill the gap at the right layer for what has to survive, and the agent finally gets a second day. See how it works at https://vilix.ai?utm_source=vilix-blog&utm_medium=article&utm_campaign=ai-by-zapier-resets-knowledge-every-run

Get Started for Free

Persistent memory across ChatGPT, Claude, and the AI tools you already use in Vilix AI.

Get Started for Free

Free forever, no credit card.

Keep reading
Hume Remembers the Chat. It Does Not Remember the Caller Between Calls.

Hume Remembers the Chat. It Does Not Remember the Caller Between Calls. Quick answer: Hume's Empathic Voice Interface (EVI) can resume an interrupted conversation. When a call drops, you reconnect with the stored chat group ID and the agent picks up where the conversation left off. That is call continuity, not caller memory. Start a brand-new call with the same person tomorrow and the agent knows nothing about them: no name, no preferences, no record of what was decided last time. If you want c

Your Google ADK Agent Remembers the Chat. Your Scheduled Runs Still Wake Up Blind.

Your Google ADK Agent Remembers the Chat. Your Scheduled Runs Still Wake Up Blind. Google's Agent Development Kit comes with sessions, state, and a long-term memory service built right into the framework. That is genuinely better than most agent frameworks ship with. So here is the surprise that bites automation teams anyway: when your ADK agent runs on a schedule, every single run wakes up blind. It remembers the conversation it is in. It has no idea about the one it had yesterday. If you run

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

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, Innges