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