Zapier moves agents into workflows: migration, approvals and the cost of finished work

An agent that handles a sales enquiry looks impressive in a demo. In production, you need to know why it selected a company, what it changed in your CRM, and whether a retry will send the same email twice. Putting the agent inside an ordinary workflow gives you a place to enforce rules around its decisions.

Zapier's October 6, 2026 product announcement describes moving standalone Agents into AI by Zapier within the Zap editor. This is a migration story: AI steps already had a July guide, and the migration documentation is dated October 1. The useful change is managing the agent alongside the rest of the process.

Conversion does not design your process

The migration guide describes automatic conversion into a trigger and one AI step, not separate native actions for each tool. No Agents shutdown date is set. Unsupported knowledge sources include HubSpot, Asana, Zendesk, Zoom and Jira; that does not mean ordinary actions for those apps are unavailable.

Before migrating, I would map what the agent reads, where it makes decisions, and what it writes. A classifier does not need unrestricted CRM access. An agent researching missing information needs a small set of read tools and a way to report that it could not find an answer.

A pilot: trace every enquiry back to its evidence

This is a proposed pilot, not a tested integration or a customer deployment result. I would use the same division of responsibilities when designing a workflow in n8n or Make.

1. Receive and deduplicate. Keep the original enquiry ID. Redelivery should find the existing work item instead of creating another deal.
2. Resolve known data first. Handle email addresses, domains and existing CRM IDs with ordinary steps. Do not ask a model to guess which contact you mean when the identifier is already available.
3. Give AI a narrow decision. Supply the enquiry and approved evidence. Ask for a category, a short reason and missing information. Require a source for every enrichment claim.
4. Validate outside the model. Check required fields and allowed values downstream. An unknown company or conflicting evidence should enter a human queue rather than trigger invented enrichment.
5. Control writes. Start by saving proposals in a test environment. Separate sending an offer or changing a deal owner from classification itself.

A simple output contract is enough: enquiry ID, category, reason, source, missing information and a status of “ready” or “manual review”. This is easier to inspect than a paragraph whose meaning the next automation must guess.

Configure approval on the tool

The tool documentation provides Require approval before running per action. It is off by default for new tools. Writing “ask before changing anything” in the prompt is no substitute. Tools and knowledge sources require Advanced or Premium models.

For the pilot, I would allow reads only from relevant records. Before a write, the reviewer should see the exact contact, the old and proposed values, and the reason. A vague “continue” button is insufficient. Test rejection as well: the system should not try another tool to make the same rejected change.

One AI step can consume several tasks

The pricing documentation calculates usage as (1 + tool calls) × model multiplier: Standard 1×, Advanced 3×, Premium 5×. With three tool calls, that gives 12 tasks on Advanced or 20 on Premium.

That is arithmetic, not a measured cost per completed enquiry. Add downstream work and manual corrections. The task accounting rules say replaying successful actions can consume tasks again.

There is also a documentation mismatch: the October 6 announcement says the 75-task limit will become adjustable; the tool guide already describes a default of 75, adjustable up to 500. Check what your account's editor actually offers.

I would build a test set of 50 historical enquiries: ordinary, incomplete and duplicate requests, Czech and Slovak text, plus a few contradictory cases. Have a sales colleague label them first. Then compare routing accuracy, unsupported claims, manual corrections and total usage per correctly completed case. A smaller model or fewer tools wins only if quality remains acceptable.

At cutover, verify that exactly one production system processes each event. Two individually correct automations can still create two identical deals. The practical opportunity is to break the agent's job into inspectable pieces and reserve expensive reasoning for the decisions that need it.