update · TowCue Editorial Team
Zapier is folding Agents into AI by Zapier: why agentic and deterministic automation are converging
Zapier is migrating standalone Agents into AI by Zapier inside the Zap editor. Here is what changes for tool calling, approvals, observability, task costs, and production workflow design.
Quick answer
Zapier updated its migration guidance on September 7, 2026 to make a major product direction clear: the standalone Zapier Agents experience is being folded into AI by Zapier inside the normal Zap editor.
The important change is architectural, not cosmetic. Instead of keeping agentic reasoning in a separate product at agents.zapier.com, Zapier now wants AI reasoning, tool calling, deterministic automation, filters, branching, approvals, and run history to live in the same workflow.
A migrated agent becomes a Zap with a native trigger plus one AI by Zapier step containing the agent's prompt, instructions, reasoning, and connected tools. Teams can then decide which actions should stay agentic and which should be broken out into deterministic Zap steps for tighter control.
That makes this update relevant far beyond existing Zapier Agents users. It is a practical example of a broader pattern in AI automation: the best production workflow is often neither fully autonomous nor fully hard-coded. It is a controlled mix of both.
For related TowCue guidance, see the AI agent best-practices guide, the guide to choosing an AI tool for work, and the ChatGPT vs Claude comparison when deciding where reasoning should sit in a workflow.
What Zapier is changing
Zapier says standalone Agents could not fully participate in the same trigger, action, filter, path, and automation-history system used by regular Zaps. AI by Zapier is meant to remove that separation.
After migration, Zapier creates:
- a native Zap trigger, such as a schedule or webhook
- a single AI by Zapier step containing the existing agent prompt and instructions
- the agent's connected tools and tool calls inside that AI step
- the agent's reasoning behavior inside the same step
The migration does not automatically convert every tool call into a separate Zap action. That is an important detail. The migrated workflow initially behaves like the old agent, and the owner can later move selected actions into native deterministic steps when more control is needed.
This gives teams a useful design choice: keep ambiguity inside the AI step, while extracting predictable actions into normal automation steps.
Why this is a better production pattern than "agent everything"
Many agent demos assume the model should decide every step. That is convenient for prototyping, but it can be a poor fit for repeatable business processes.
Consider an inbound support workflow. An AI system may be good at:
- understanding the customer's intent
- classifying urgency
- deciding which knowledge is relevant
- drafting a response
But a deterministic automation step may be better for:
- writing a fixed field into a CRM
- routing a record to a known queue
- checking an exact status value
- sending a message only after an approval flag is true
Putting both styles in one Zap means the workflow can use reasoning where ambiguity exists and conventional automation where the rule is already known.
That is the core TowCue takeaway: use AI for interpretation; use deterministic steps for constraints you can already express clearly.
Per-tool approvals create a useful safety boundary
AI by Zapier allows users to require approval before an individual tool runs. Zapier explicitly suggests leaving low-risk actions such as reads autonomous while putting approval gates in front of more sensitive writes.
This is more practical than a single global "agent on/off" switch because risk is not evenly distributed across a workflow.
Reading a CRM record and deleting that record are both tool calls, but they should not have the same autonomy policy. The same is true for drafting an email versus actually sending it.
A sensible production pattern is:
- allow read-only tools without approval
- require approval for external communications or destructive writes
- move repeatable high-confidence actions into native Zap steps
- keep the AI step focused on decisions that genuinely require reasoning
Zapier also gives admins account-level controls to disable tool calling or agentic behavior and to restrict available models.
Observability is becoming part of the agent product
One advantage of moving agentic runs into normal Zaps is that their activity appears in Zap history alongside other automation runs.
Zapier says teams can inspect which tools were called, what data was passed, which model tier was used, and how many tasks the run consumed.
That matters because agent failures are often difficult to diagnose when the entire process is hidden behind one conversational interface. Production automation needs an answer to questions such as:
- Which tool did the model call?
- What data was passed into that call?
- Which model was running?
- How many tasks did the loop consume?
- Did a tool fail, or did the model make the wrong decision?
Moving these traces into the same history system used for other Zaps reduces the gap between AI experimentation and operations.
The cost model needs attention before teams migrate blindly
AI by Zapier uses task-based billing, and model choice changes the task multiplier.
Zapier currently documents three built-in tiers:
| Tier | Task multiplier | Tool support |
|---|---|---|
| Standard | 1x | No |
| Advanced | 3x | Yes |
| Premium | 5x | Yes |
New paid AI by Zapier steps default to Premium, according to Zapier's current documentation.
The task formula is also important:
tasks per run = (1 × model rate) + (tool calls × model rate)
So a Premium run with two tool calls uses 15 tasks: 5 for the AI step and 10 for the two tool calls. Zapier also pauses a single AI by Zapier run after it reaches 75 tasks, requiring review before it continues.
This is a useful runaway-cost guardrail, but teams should still model cost at the workflow level. An agent that loops through many tools can consume tasks much faster than a conventional Zap with a fixed number of actions.
What changes for existing Agents users
Zapier says existing agents can be automatically converted rather than rebuilt from scratch. The migrated Zap keeps the prompt, instructions, tools, and reasoning inside the AI step.
There are, however, workflow differences that need testing.
Agent-to-agent calls should be rebuilt around Sub-Zaps. Chat-triggered on-demand agents do not yet have a direct equivalent trigger in the Zap editor; Zapier suggests using a webhook from a chat surface or custom interface instead.
Two features are also still incomplete in the new setup according to Zapier's documentation:
- organization-level Bring Your Own Model configuration is still planned for a future release
- some Agents knowledge sources are not yet available in AI by Zapier
That means migration should be treated as a real workflow change, not a file-format conversion.
A low-risk migration checklist
TowCue would not migrate a production agent and immediately disable the old version without comparison.
Use this sequence instead:
- Let Zapier create the migrated Zap.
- Review the prompt, instructions, and every connected tool.
- Run the AI step with representative sample data.
- Inspect which tools it called and how many tasks were consumed.
- Test the entire Zap end to end.
- Put approval gates on sensitive writes and external messages.
- Move predictable actions into native Zap steps if that improves control.
- Compare output quality and task consumption with the original agent.
- Only then disable the original Agent to avoid duplicate actions.
Zapier specifically warns that leaving both versions published can cause both to run, producing duplicate actions.
Who should care about this update
Existing Zapier Agents users
You should review the migration path now, especially if your agent calls other agents, depends on knowledge sources, or uses chat as its trigger.
Operations and automation teams
This architecture is useful even if you never used standalone Agents. It creates a clearer way to combine fuzzy reasoning with precise workflow logic in one operational system.
Teams worried about AI governance
Per-tool approvals, admin model controls, publishing approval flows, and run history make this more relevant to controlled production use than a standalone autonomous-agent interface.
Cost-sensitive automation teams
Do not assume an agentic step costs the same as a conventional action. Model tiers and repeated tool calls can multiply task consumption quickly.
TowCue take
Zapier's move is a useful signal about where practical AI automation is heading.
The first wave of agent products tried to prove that a model could decide and execute many steps on its own. The next wave is starting to answer a more useful enterprise question:
Where should the model be allowed to decide, and where should the workflow remain explicit?
Putting AI by Zapier inside the core Zap editor makes that boundary easier to design. A team can keep classification, interpretation, and planning inside an agentic step, while moving permissions, irreversible actions, routing rules, and known business logic into deterministic steps.
That hybrid model is less glamorous than "fully autonomous," but it is probably closer to how reliable AI automation will actually be deployed.
Research sources
- Zapier — Migrating from Agents to AI by Zapier (updated September 7, 2026)
- Zapier — AI by Zapier model tier pricing (updated August 20, 2026)
- Zapier — How task usage is measured (updated August 21, 2026)
- Zapier — View and manage your Zap history