If you use Zapier Agents, the migration to AI by Zapier is primarily a conversion into the Zap editor, not an automatic workflow redesign. For eligible users, Zapier creates a native trigger and one AI by Zapier step containing the agent’s prompt, reasoning instructions, and configured tools. The surrounding Zap can then add Filters, Paths, native app actions, approvals, and Zap History.
The important distinction is what does not happen automatically: individual tool calls do not become separate deterministic Zap actions. You can migrate as-is for continuity, manually move known operations into native steps for tighter control, or redesign an on-demand pattern around a webhook. Review Zapier’s current migration guide for eligibility, Enterprise treatment, and time-sensitive feature changes before you begin.
This guide focuses on the operator’s job after conversion: preserving behavior, defining inputs and outputs, validating consequential actions, controlling task use, and assigning ownership for exceptions. The workflow examples are illustrative designs, not official Zapier templates.
What happens when you move Zapier Agents to AI by Zapier?
Automatic migration creates a Zap trigger and an AI by Zapier step. The original instructions and configured tools remain together in that AI step. You can place native actions, Filters, Paths, and other Zap steps before or after it, and review runs in Zap History.
A Filter stops a run unless its conditions are met. Paths route a run into explicit branches. These controls are useful when a business rule is already known. Leave an operation as an AI tool when the AI genuinely needs to choose whether or how to use it. Use a native action after a Filter or Path when the action and its conditions should be enforced directly.
Migration preserves the agent inside an AI step. It does not decompose the agent into a deterministic workflow. Keep AI choice where ambiguity is useful, and express known policy in Filters, Paths, native actions, and explicit ownership.
Migration steps: convert, test, publish, then retire the old agent
Eligible users are directed to migration from the Agents interface. Enterprise customers should confirm their plan and migration treatment with Zapier. Before converting, record the agent’s instructions, trigger, connected accounts, configured tools, knowledge sources, expected outputs, and actions with external consequences.
For a manual redesign, Zapier automation consulting can help assess trigger design, deterministic steps, and operational ownership. The migration guide remains the procedural reference because availability and supported features can change.
Map the old agent design to the new Zap
- Instructions: review the prompt in the AI by Zapier step and narrow it to a bounded task with a defined result.
- Tools: review each configured tool and connected account. AI by Zapier uses tools selected for the step, not every app or action in Zapier’s library. Standard does not support tools; Advanced, Premium, or eligible Bring Your Own Key configurations are required for tool use.
- Triggers: map supported app events or schedules to a native Zap trigger. Zapier’s 9,000+ app figure describes the app library, not universal tool availability for every account or action.
- Approvals: configure
Require approval before running
separately for each tool that needs review. It is off by default, and an enabled tool pauses the Zap before execution so a reviewer can inspect the proposed values. - Run review: use Zap History for troubleshooting, tool activity, model tier, and task use. Zapier documents a maximum of 60 days of run data and display of up to 10,000 runs, so retain operational or compliance records elsewhere when needed.
Use AI agent consulting when deciding which reasoning tasks should remain AI-driven and where people or explicit rules should take over.
Four migration patterns and their operating contracts
Each pattern below identifies the trigger, AI responsibility, validation boundary, destination, and exception owner. The fields and rules are proposed examples for design discussions.
| Pattern | Trigger and AI job | Validation and destination | Fallback owner |
|---|---|---|---|
| Event-driven | App event or schedule; classify a request or select from configured tools | Check identifiers and allowed outcomes; update a known record | Operations owner handles invalid or ambiguous cases |
| On-demand | Catch Hook; interpret a bounded request | Validate caller and payload; use a supported reply or notification route | Integration owner handles abuse, missing data, or no match |
| Classification | App event or webhook; return defined fields | Filter or Path before a write or review queue | Support or CRM owner reviews exceptions |
| Agent-to-agent | Parent calls a child Sub-Zap; child performs bounded work | Child returns defined data; parent validates before acting | Workflow owner investigates missing returns or delays |
1. Scheduled or event-driven workflow
Proposed chain: CRM or support-app event → AI by Zapier → Filter or Path → native CRM update or review queue.
Pass a stable source event ID, record ID, event type, and request text. Ask the AI to classify the request and select among tools configured on the step only when that choice is necessary. A proposed output contract could contain category, confidence, requires_review, source_event_id, and reason.
Before a native write, check the category and required identifiers, then resolve the destination by a stable record ID. If a lookup returns zero or multiple matches, route to the CRM or operations owner. For replay protection, use a destination uniqueness constraint or transactional upsert where the destination supports it. A search followed by create is not race-safe when concurrent runs are possible.
2. On-demand or chat-style replacement with a webhook
Zapier documents Webhooks by Zapier Catch Hook as a workaround for on-demand behavior, not as a native chat trigger. A webhook starts a Zap; it does not by itself provide a complete chat interface or guarantee an immediate reply.
Proposed chain: calling system → Catch Hook → payload validation → AI by Zapier → permitted lookup → supported notification or response mechanism.
Send a correlation ID, source event ID, message, and requester ID. Validate required fields and the caller independently before revealing account information. Treat the unique hook URL as secret, protect it from public client-side exposure, and account for the documented payload and rate limits. Possession of the URL is not a complete authentication system. If the caller expects a response, design and test that response channel separately. The integration owner handles invalid requests, suspected abuse, missing records, and requests requiring a person.
3. Structured classification before a consequential action
Proposed chain: CRM, spreadsheet, or app event → AI by Zapier with defined output fields → Filter or Paths → review queue or native update.
Provide the source text and stable event or record ID. Define output names and types in the AI step before mapping them downstream. For example:
{
"classification": "billing_duplicate_charge",
"confidence": 0.91,
"requires_review": true,
"source_event_id": "evt_illustrative_8801",
"reason": "The text reports two charges."
}These fields and values are illustrative, not an official Zapier schema. Validate field presence, types, and allowed categories after the AI step. Put the policy in a Filter or Path. For example, send a high-impact billing case to a review queue even when the model confidence is high. Preserve the source record ID for traceability, and use a uniqueness constraint or idempotency mechanism at the destination when one event can create one record. For record ownership and CRM design, see CRM systems consulting.
4. Replace agent-to-agent work with a Sub-Zap
Proposed chain: parent Zap with Call a Sub-Zap → child Zap with Start a Sub-Zap → bounded AI or native steps → Return From a Sub-Zap → parent Filter, Path, or action.
Define the child inputs and returned fields before connecting the parent. Every relevant child branch needs to return data, including a fallback for unmatched cases. Otherwise, a parent run can remain delayed. Sub-Zaps are documented as beta, looping is not supported inside a Sub-Zap, and the pattern should not be treated as proof of parallel execution. The workflow owner investigates missing returns and delayed parent runs.
Set validation and approval boundaries before enabling writes
Validation checks whether an operation is well formed and allowed: required IDs exist, values have the right types, categories are permitted, and the destination match is unambiguous. Approval asks a person to authorize a proposed action. Approval does not replace data checks.
For a consequential write, a proposed gate is: source event ID exists → destination lookup returns exactly one record → AI output contains only allowed fields and valid types → deterministic business rule passes → per-tool approval is enabled if the action is high impact → write. If any check fails, route the run to a named workflow owner.
Prefer a stable destination record ID over an AI-selected name or email, and minimize sensitive input sent to the AI step. For duplicate handling, base a proposed key on the correct row grain, such as source_system + source_event_id + workflow_version for one destination record per source event. If concurrent runs are possible, enforce uniqueness in the destination database or use a transactional upsert. Do not rely on lookup then create alone.
Estimate task use and choose a model tier deliberately
Current AI by Zapier documentation lists Standard at a 1x task rate, Advanced at 3x, and Premium at 5x. Standard does not support tools; Advanced and Premium do. Eligible Bring Your Own Key configurations use a 1x Zapier task rate, while tool use still requires an Advanced or Premium level model.
Task use includes the AI step and successful tool calls at the selected rate. The documented formula is one AI step plus the number of tool calls, multiplied by that rate. A Premium run with two tool calls therefore uses 15 tasks: 5 for the step and 10 for the calls. Check actual usage in Zap History because tool calls are dynamic.
New paid AI by Zapier steps currently default to Premium according to the current model-tier documentation. Free-plan users can preview Standard, but cannot add tools or publish a Zap containing an AI by Zapier step. The default per-run task limit is 75, and current documentation says it can be raised to 500. Reaching the limit pauses the step for approval before it continues. See the current model-tier pricing and limits before rollout because pricing and availability can change.
For prompt-only classification, test whether Standard is sufficient. For tool use, choose a compatible tier, remove unnecessary tools, and use deterministic steps when the target is already known. Do not estimate cost from prompt length alone.
Recheck knowledge sources and observability after migration
Test knowledge-source behavior separately from the rest of the migration. At the time of the October 2026 migration documentation, HubSpot, Asana, Zendesk, Zoom, and Jira were listed as unsupported knowledge sources, with support planned for Q4 2026. Treat that as a dated status, not a permanent product limitation, and check the current migration page before relying on the list.
Current documentation says an AI by Zapier step can have up to 20 knowledge sources. Sources with 1,000 or more pages or files may time out when added, Notion databases are not supported, and Google Docs must be added individually. For each retained source, test permissions, coverage, representative questions, stale content, and the no-relevant-material result. Assign a source owner before retiring the old agent.
Zap History provides run troubleshooting, tool activity, model tier, and task usage, but Zapier documents retention and display limits. Retain records required for operations or compliance in an appropriate system outside Zap History. Use Zap History’s documented controls to investigate recent runs.
Launch checklist for the migrated Zap
The workflow owner should know who handles a paused step, failed write, rejected approval, or duplicate alert before the Zap becomes business critical.
- The trigger, connected accounts, configured tools, model tier, input fields, and output fields match the intended workflow.
- Normal, missing-data, ambiguous-match, tool-failure, and rejected-approval paths have been tested.
- Filters or Paths enforce allowed outcomes before consequential actions.
- Destination identity and duplicate controls use the correct event or record grain, with database uniqueness or transactional upsert where concurrency matters.
- High-impact tools have the intended per-tool approval setting, and a named owner can review paused runs.
- Actual tool-call task use and the selected per-run limit have been checked in Zap History.
- Knowledge-source permissions and representative retrieval results have been tested separately.
- The new Zap is published, the old agent is disabled, and the owner knows how to handle failed writes and duplicate detection.
Once live, review the first runs and exceptions against the workflow’s intended outcomes. Keep the expected behavior, test cases, source identifiers, and operational ownership with the systems your team uses to manage the automation.
