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
Windmill Keeps the State You Save by Hand. Your Scheduled AI Steps Still Run Stateless.

Windmill Keeps the State You Save by Hand. Your Scheduled AI Steps Still Run Stateless. Windmill is very good at making a job repeatable. A script becomes a flow, a flow gets a schedule, and the same work runs at the same time without anyone pressing a button. Repeatable, however, is not the same as remembering. A scheduled job can execute perfectly every morning and still have no idea what it concluded the morning before. That sounds like a contradiction until you separate the three kinds of

VectorShift Remembers the Chat. Your Scheduled Pipelines Still Start Each Run Blank.

VectorShift Remembers the Chat. Your Scheduled Pipelines Still Start Each Run Blank. A VectorShift chatbot can feel like it knows you. Ask it a question, then ask a follow up that only makes sense in light of the first answer, and it responds as if the conversation never broke. That experience is real, and it leads to a reasonable assumption: a platform that remembers a conversation that well must also remember what its automations did on previous runs. It does not, and the distance between th

IFTTT Applets Remember the Trigger. Your AI Steps Start Every Run Blank.

IFTTT Applets Remember the Trigger. Your AI Steps Start Every Run Blank. An IFTTT applet feels aware while you build it. You pick a trigger, watch its sample data flow into the action, add a line of filter code, and the test run behaves like a small, attentive assistant that knows your setup. Then the applet goes live and fires two hundred times, and a simple question exposes the gap: which of those runs can see what the others did? The answer is none of them. Every run is a sealed envelope tha