Zapier Agents are becoming Zaps. A map for moving yours without sending everything twice

What's changing

Zapier's Agents product used to live on its own, at a separate address, outside the regular Zap editor. That meant an agent couldn't easily use the triggers, filters, branching and history that ordinary Zaps have. Zapier is now folding it into AI by Zapier, a step you add inside a normal Zap.

The good news is that you don't have to rebuild anything. According to Zapier's migration guide, each agent is converted automatically into a Zap with two parts: a native trigger, such as a schedule or a webhook, and a single AI by Zapier step that holds your original prompt, tools and reasoning. Agents that called other agents become sub-Zaps. On-demand chat agents get a webhook trigger.

There's no deadline yet. Zapier says it hasn't set a date to turn Agents off and will email affected users with enough notice. That's a reason to plan the move, not to wait for the email. A migration you do on your own schedule is much calmer than one you do in the final week.

The map: what moves where

Here's how the pieces of an old agent show up in the new setup, based on Zapier's guide.

The prompt, tools and reasoning go into the AI by Zapier step, unchanged. The tools aren't split into separate Zap steps. If you want parts of the work to be fixed rules rather than AI decisions, you restructure that by hand later.

The way it starts becomes a native trigger. A scheduled agent gets a schedule, a chat agent gets a webhook.

Agents calling agents become sub-Zaps. Zapier's guide reminds you to update any parent Zap that called the old agent so it points to the new sub-Zap.

Billing moves to normal Zapier tasks. There's no separate Agents subscription, and Zap history breaks down each run's tasks by tool call, model tier and step.

Knowledge sources mostly carry over, with gaps. HubSpot, Asana, Zendesk, Zoom and Jira knowledge sources aren't supported in AI by Zapier yet. Zapier says support is planned for the fourth quarter of 2026. If an agent depends on one, talk to Zapier before moving it.

Five checks before you switch

The conversion is automatic. The decisions around it aren't. These are the five we'd make for every agent.

Turn on approval for tools that write. AI by Zapier lets you set "require approval" on each tool, which pauses the run and asks before using it. Zapier suggests leaving it off for low-risk reads and turning it on for sensitive writes. Do that now, while you're reviewing each agent anyway. Sending email, updating a CRM record or posting to a customer channel all count as writes.

Set the task limit on purpose. A single run that goes over its task limit pauses for review. The default is 75 and you can raise it to 500. Look at what each agent actually used in a normal run before you raise anything. A higher limit makes sense for a long research job. For something that drafts one reply, it mainly raises the cost of a loop going wrong.

Budget for testing. Zapier's guide says full-Zap tests currently use tasks the same way production runs do, and that it's working on a fix. Test each migrated Zap on a small sample instead of a full batch.

Check knowledge sources at the edges. Zapier notes that adding a knowledge source with 1,000 or more pages or files can time out, while Agents handled up to 1,500 pages. It also says a missing Notion permission can show up as "page not found" rather than a clear permission error. If a migrated Zap suddenly can't find a page, check access before rewriting the prompt.

Decide whose accounts it runs on. This one catches teams out. Super admins can publish migrated Zaps on behalf of other users, which saves a lot of clicking. But Zapier's guide is explicit: a Zap published on someone's behalf runs on their connected accounts, like their Gmail or Slack, and acts as them. Confirm with each person before switching on anything that sends email or messages. If several automations depend on one person's login, now is a good time to fix that too. We wrote about it in Our automations all run on one person's login.

The switchover, in order

Most problems in a move like this happen in the hour between the new Zap going live and the old agent being turned off. Until you turn the old agent off, you have two automations doing the same job. Zapier's guide says that if you don't turn the original off, both can run at the same time and may cause duplicate actions. For a support agent, that means two replies to the same customer.

Our suggested order for each agent:

1. Review the converted Zap: prompt, tools, approvals and task limit.
2. Test on a small sample and check which tools ran and what they did in the test panel.
3. Repoint any parent Zap that called this agent.
4. Publish the Zap and turn the old agent off immediately. Zapier offers that choice in a dialog when you publish.
5. Watch Zap history for the first full day of runs.

Do the low-risk agents first, the ones that only read or summarize. Move the ones that send messages to customers last, once you've seen the process work a few times.

For admins

Two organization-level settings are worth a look. Admins can require Zaps that contain AI steps to go through an approval process before they're published. If your team doesn't already review automations before they go live, this is an easy place to start, since every migrated agent will need publishing anyway.

Model choice is the other. Zapier offers model tiers, and the guide notes that individual users can connect their own API key to lower the task multiplier on their runs, but organization-wide model configuration isn't available yet. If cost control matters, decide which tier each kind of work should use and write it down until admins can enforce it.

If you'd like help untangling agents, Zaps and the accounts they run on, that's what our business automation team does. Talk to us.

Related work: Sutton Place.