Zapier přesouvá agenty do workflow: migrace, schvalování a cena hotové práce

Agent, který sám vyřídí poptávku, vypadá dobře na demu. V provozu ale potřebujete vědět, proč vybral konkrétní firmu, co zapsal do CRM a zda po opakovaném spuštění neodešle stejný e-mail podruhé. Přesun agenta do běžného workflow je zajímavý právě tím, že kolem jeho rozhodování můžete postavit pevná pravidla.

Zapier v produktovém oznámení z 6. října 2026 popsal přesun samostatných Agents do AI by Zapier v editoru Zapů. Jde o migrační směr, nikoli první uvedení AI kroků: návod k produktu existoval už v červenci a migrační nápověda nese datum 1. října. Pro mě je podstatná možnost spravovat agenta společně se zbytkem procesu.

Převod není hotový návrh procesu

Migrační dokumentace popisuje automatický převod na trigger a jediný AI krok. Nástroje se samy nerozdělí do samostatných akcí. Datum vypnutí původních Agents zatím není stanovené. Mezi nepodporované znalostní zdroje patří HubSpot, Asana, Zendesk, Zoom a Jira; to neznamená zákaz běžných akcí těchto aplikací.

Před migrací bych proto sepsal tři věci: co agent čte, kde rozhoduje a kam zapisuje. Když je cílem jen určit kategorii příchozí zprávy, nepotřebuje volně obsluhovat celé CRM. Když má dohledat chybějící informaci, potřebuje omezené čtecí nástroje a možnost přiznat, že ji nenašel.

Pilot: poptávka, kterou lze dohledat až ke zdroji

Následující postup je můj návrh pilotu, nikoli otestovaná integrace nebo výsledek klientského nasazení. Stejné rozdělení odpovědností bych použil i při návrhu v n8n nebo Make.

1. Příjem a deduplikace. Uložte původní ID poptávky. Opakované doručení má dohledat rozpracovaný záznam, ne založit nový obchod.
2. Pevná data před AI. E-mail, doménu a již známé CRM ID zpracujte běžnými kroky. Nenechte model hádat kontakt, který už máte jednoznačně určený.
3. Úzké rozhodnutí. AI dostane text poptávky a povolené podklady. Navrhne kategorii, stručný důvod a chybějící informace. U každého doplněného tvrzení požadujte zdroj.
4. Kontrola mimo model. Další krok ověří povinná pole a povolené hodnoty. Neznámá firma nebo rozporné podklady vedou do fronty pro člověka, ne k vymyšlenému obohacení.
5. Řízený zápis. Nejprve ukládejte návrhy do testovacího prostředí. Odeslání nabídky a změnu vlastníka obchodu oddělte od samotné klasifikace.

Návrh výstupních polí může být jednoduchý: ID poptávky, kategorie, důvod, zdroj, chybějící údaj a stav „připraveno / ruční kontrola“. Je to srozumitelnější než jeden dlouhý odstavec, ze kterého další automatizace loví význam.

Schválení nastavte v nástroji

Podle návodu k nástrojům lze pro konkrétní akci zapnout Require approval before running. U nových nástrojů je tato volba standardně vypnutá. Prompt typu „před zápisem se zeptej“ proto nenahrazuje nastavení. Nástroje a znalostní zdroje vyžadují modely Advanced nebo Premium.

V pilotu bych agentovi povolil číst jen relevantní záznamy. Před zápisem by člověk viděl přesný cílový kontakt, původní a novou hodnotu i důvod změny. Schvalovat neurčité „pokračovat“ nestačí. Zvlášť vyzkoušejte odmítnutí akce: systém se nemá pokusit provést stejný zápis jiným nástrojem.

Jeden AI krok neznamená jednu účtovanou úlohu

Ceníková dokumentace počítá spotřebu jako (1 + počet volání nástrojů) × násobitel modelu: Standard 1×, Advanced 3×, Premium 5×. Při třech voláních tedy vychází 12 úloh na Advanced nebo 20 na Premium.

Je to výpočet, ne naměřená cena hotové poptávky. Připočtěte další části procesu a ruční opravy. Pravidla účtování uvádějí, že opětovné provedení úspěšných akcí při replay může znovu spotřebovat úlohy.

Zdroje se liší u limitu: blog z 6. října označuje nastavitelnost limitu 75 úloh za budoucí funkci, návod k nástrojům už uvádí výchozích 75 a zvýšení do 500. Ověřte, co nabízí editor vašeho účtu.

Navrhl bych sadu 50 historických poptávek: běžné, neúplné, duplicitní, v češtině i slovenštině a několik s protichůdnými údaji. Předem je označí obchodník. Pak porovnejte správné směrování, nepodložené údaje, počet ručních oprav a celkovou spotřebu na správně dokončený případ. Menší model nebo méně nástrojů vyhrává jen tehdy, když udrží přijatelnou kvalitu.

Při přepnutí provozu ověřte také jediného aktivního zpracovatele každé události. Dva správně fungující systémy mohou společně vytvořit dva stejné obchody. Přínos této změny vidím v možnosti agenta rozebrat na kontrolovatelné části — a drahé rozhodování nechat jen tam, kde ho proces skutečně potřebuje.