Zapier presúva agentov do workflow: migrácia, schvaľovanie a cena hotovej práce

Agent, ktorý sám vybaví dopyt, vyzerá dobre na deme. V prevádzke však potrebujete vedieť, prečo vybral konkrétnu firmu, čo zapísal do CRM a či pri opakovanom spustení neodošle rovnaký e-mail druhýkrát. Presun agenta do bežného workflow umožňuje postaviť okolo jeho rozhodovania pevné pravidlá.

Zapier v produktovom oznámení zo 6. októbra 2026 opísal presun samostatných Agents do AI by Zapier v editore Zapov. Ide o migráciu: návod k AI krokom existoval už v júli a migračná dokumentácia nesie dátum 1. októbra. Podstatná je možnosť spravovať agenta spolu so zvyškom procesu.

Prevod nenavrhne proces za vás

Migračný návod opisuje automatický prevod na trigger a jediný AI krok. Nástroje sa samy nerozdelia na samostatné akcie. Dátum vypnutia pôvodných Agents zatiaľ nie je stanovený. Nepodporované znalostné zdroje zahŕňajú HubSpot, Asana, Zendesk, Zoom a Jira; nejde o zákaz bežných akcií týchto aplikácií.

Pred migráciou by som si preto spísal, čo agent číta, kde rozhoduje a kam zapisuje. Na určenie kategórie správy nepotrebuje voľný prístup do celého CRM. Pri dohľadávaní informácií potrebuje obmedzené čítacie nástroje a možnosť priznať, že odpoveď nenašiel.

Pilot: dopyt dohľadateľný až k zdroju

Nasledujúci postup je môj návrh pilotu, nie otestovaná integrácia ani výsledok nasadenia u klienta. Rovnaké rozdelenie zodpovedností by som použil aj pri návrhu v n8n alebo Make.

1. Príjem a deduplikácia. Uložte pôvodné ID dopytu. Opakované doručenie má nájsť rozpracovaný záznam, nie vytvoriť ďalší obchod.
2. Známe údaje pred AI. E-mail, doménu a existujúce CRM ID spracujte bežnými krokmi. Model nemá hádať kontakt, ktorý už poznáte jednoznačne.
3. Úzke rozhodnutie. AI dostane text dopytu a povolené podklady. Navrhne kategóriu, stručný dôvod a chýbajúce informácie. Ku každému doplnenému tvrdeniu žiadajte zdroj.
4. Kontrola mimo modelu. Ďalší krok overí povinné polia a povolené hodnoty. Neznáma firma či rozporné podklady patria človeku, nie k vymyslenému obohateniu.
5. Riadený zápis. Najprv ukladajte návrhy do testovacieho prostredia. Odoslanie ponuky a zmenu vlastníka obchodu oddeľte od samotnej klasifikácie.

Výstupné polia môžu byť jednoduché: ID dopytu, kategória, dôvod, zdroj, chýbajúci údaj a stav „pripravené / ručná kontrola“. Takýto návrh sa kontroluje ľahšie než dlhý odsek, z ktorého ďalšia automatizácia odhaduje význam.

Schválenie nastavte priamo v nástroji

Podľa návodu k nástrojom sa dá pre jednotlivú akciu zapnúť Require approval before running. Pri nových nástrojoch je táto voľba štandardne vypnutá. Prompt „pred zápisom sa opýtaj“ ju nenahrádza. Nástroje a znalostné zdroje vyžadujú modely Advanced alebo Premium.

V pilote by som povolil čítanie iba relevantných záznamov. Pred zápisom má človek vidieť presný kontakt, pôvodnú aj novú hodnotu a dôvod zmeny. Neurčité „pokračovať“ nestačí. Otestujte aj zamietnutie: systém sa nemá pokúsiť vykonať rovnaký zápis cez iný nástroj.

Jeden AI krok nemusí znamenať jednu účtovanú úlohu

Cenníková dokumentácia počíta spotrebu ako (1 + počet volaní nástrojov) × násobiteľ modelu: Standard 1×, Advanced 3×, Premium 5×. Pri troch volaniach teda vychádza 12 úloh na Advanced alebo 20 na Premium.

Je to výpočet, nie nameraná cena vybaveného dopytu. Pripočítajte ďalšie časti procesu a ručné opravy. Pravidlá účtovania upozorňujú, že opätovné vykonanie úspešných akcií pri replay môže znova spotrebovať úlohy.

Zdroje sa líšia pri limite: oznámenie zo 6. októbra označuje nastaviteľnosť 75-úlohového limitu za budúcu funkciu, no návod k nástrojom už uvádza predvolených 75 a zvýšenie do 500. Overte, čo ponúka editor vášho účtu.

Navrhol by som sadu 50 historických dopytov: bežné, neúplné, duplicitné, v češtine aj slovenčine a niekoľko s protichodnými údajmi. Najprv ich označí obchodník. Potom porovnajte správne smerovanie, nepodložené údaje, počet ručných opráv a celkovú spotrebu na správne dokončený prípad. Menší model alebo menej nástrojov vyhráva iba pri prijateľnej kvalite.

Pri prepnutí prevádzky overte aj to, že každú udalosť spracúva jediný aktívny systém. Dve samostatne správne automatizácie môžu spoločne vytvoriť dva rovnaké obchody. Prínos tejto zmeny vidím v rozdelení agenta na kontrolovateľné časti a v ponechaní drahého rozhodovania len tam, kde ho proces naozaj potrebuje.