Zavádzanie AI agentov do firmy bez spálenia IT rozpočtu

Každá firma, ktorú stretnem, má rovnakú ambíciu — agenta, ktorý vybaví prácu od začiatku do konca — a rovnaký problém: nikto nevie povedať, čo znamená „vybavené", takže nikto nevie povedať, kedy je to hotové.

Prečo projekty agentov váznu

Práca agentov zlyháva na troch predvídateľných miestach. Požiadavky sa píšu ako priania („vybaviť zákaznícke požiadavky"), takže nikto nevie merať úspech. Prvú ukážku robia ľudia, ktorí ju stavajú, na dátach, ktoré si sami vybrali, a to vám o produkcii nepovie nič. Potom sa autonómia udelí naraz a prvá drahá chyba projektu stojí politický kapitál.

Žiadna z týchto vecí nie je o kvalite modelu. Sú o tom, ako je práca usporiadaná do poradia.

Začnite frontou, nie schopnosťou

Najužitočnejšia zmena, ktorú robím, je odmietnuť začať schopnosťou a trvať na začatí frontou. Nie „zákaznícka podpora" — „340 ticketov týždenne, ktoré prichádzajú s fotografiou poškodeného kusu a potrebujú rozhodnutie o vrátení peňazí".

Fronta má objem, vzor príchodov, merateľnú súčasnú cenu spracovania a — čo je kľúčové — definíciu hotovo. Zároveň vám povie, aké dáta sú potrebné, čo vám povie, aké oprávnenia agent potrebuje, a tam je väčšina skutočného inžinierstva.

Vyberte frontu, kde je práca repetitívna, kontext je dostupný v systémoch, ktoré už máte, a chyba sa dá napraviť. Táto kombinácia je vzácnejšia, než si ľudia myslia. Triáž podpory je dobrý kandidát. Čokoľvek, čo sa týka právneho záväzku alebo nezvratnej platby, nie je — zatiaľ nie.

Shadow mode pred autonómiou

Skôr než agent niečo urobí, urobí všetko.

Spustite ho na reálnej prevádzke, paralelne s ľuďmi, ktorí prácu robia dnes, s výstupom do fronty, ktorú zatiaľ nikto nečíta. Toto sú najcennejšie dva týždne celého projektu, pretože naraz prinášajú tri veci:

• Číslo presnosti. Aké percento rozhodnutí agenta by človek prijal bez zmeny?
• Taxonómiu porúch. Takmer nikdy nie sú náhodné. Zoskupujú sa do chýbajúceho kontextu, nejasnej politiky a prípadov, kde bola správna odpoveď opýtať sa.
• Artefakt pre stakeholderov. Sledovanie dashboardu s reálnymi prípadmi je to, čo premení skepticizmus na rozhovor o rozpočte.

Shadow mode je lacný, trapne poctivý a pravidelne prekvapí ľudí v oboch smeroch.

Najprv návrh, potom konanie

Väčšina projektov agentov dodáva hodnotu vo fáze len-návrh a potom príliš skoro tlačí na autonómiu.

Agent, ktorý len pripravuje návrh — navrhne vrátenie peňazí, napíše odpoveď, pripraví aktualizáciu ticketu alebo označí zmluvné ustanovenie v diffe — to je už veľký nárast produktivity a nesie takmer žiadne riziko, pretože človek stále číta každé slovo. Miera eskalácie klesá, čas revízie klesá a kvalita agenta sa s každou revíziou zlepšuje, lebo opravy sú označenými dátami.

Autonómiu treba udeľovať po akciách, nie po agentoch. Čítanie záznamu v CRM môže byť od prvého dňa neobslužované. Vytvorenie záznamu môže nasledovať. Vrátenie peňazí vyžaduje schválenie, pokým evaluačné dáta nehovoria inak — a „inak" má byť číslo, nie pocit.

Čo vlastne potrebuje človeka

Nechajte človeka v slučke, keď je akcia nezvratná, viditeľná navonok pre zákazníka, právne následná, nejednoznačná podľa vašej písomnej politiky alebo bezprecedentná. Tento zoznam je kratší, než sa ľudia boja, a jeho udržanie krátkym je to, čo robí autonómiu uveriteľnou pre rizikovú alebo auditnú funkciu.

Všetko ostatné je kandidát — s limitami. Obmedzte výdavky na spustenie, obmedzte počet krokov na spustenie, obmedzte súbežné spustenia. Spustenie, ktoré narazí na limit, sa má zastaviť a eskalovať, nie improvizovať, pretože improvizácia na kroku 40 je miesto, kde žijú drahé incidenty.

Poctivé meranie

Merajte štyri veci, týždenne, a odolajte pokušeniu pridať piatu:

• Vybavený objem — prípady uzavreté od začiatku do konca bez zásahu človeka.
• Kvalita — vzorkovaná ľudským recenzentom podľa rubriky dohodnutej v prvom týždni.
• Náklady — na vybavený prípad, vrátane tokenov, volaní nástrojov a infraštruktúry.
• Miera eskalácie — podiel, ktorý ide človeku, a prečo.

Počty konverzácií a skóre spokojnosti používateľov v tomto zozname nie sú zámerne. Oboje sa ľahko nafúkne a ťažko interpretuje. Ak vybavený objem stagnuje a náklady na prípad rastú, agent sa zhoršuje, nie zlepšuje.

Multi-agent systémy: väčšinou nie

Väčšina firemných „multi-agent" architektúr, o ktoré ma žiadajú, je jeden agent s trvalou slučkou a dvoma alebo tromi nástrojmi. Vzor vyzerá na schéme impozantne a v produkcii je zvyčajne horší: viac kontextu na správu, viac režimov zlyhania, ťažší debug a latencia vynásobená naprieč hops.

Pridávajte agentov, keď je na to skutočný dôvod. Oddelené oprávnenia, ktoré nechcete kombinovať. Rozpočty kontextu, ktoré sa skutočne nemôžu deliť o jedno okno. Práca, ktorá je skutočne paralelná a samostatne hodnotná. Ak je jediným dôvodom to, že „multi-agent" znie pokročilejšie, nechajte slučku.

Postup na 90 dní

Dni 1–30: vyberte frontu, napíšte rubriku, postavte shadow mode, publikujte číslo presnosti.

Dni 31–60: dodajte verziu len s návrhmi do reálnych revíznych frontí, započítajte náklady na prípad, opravte tri najčastejšie triedy porúch.

Dni 61–90: povoľte neobslužované vykonávanie akciu po akcii, druhú frontu pridajte len ak je prvá skutočne nudná.

Väčšina firiem, ktoré to urobia, skončí s jedným produkčným agentom, ktorý jednu vec robí dobre — a, čo je kľúčové, s vyznaním organizácie upraveným podľa toho, čo agenti skutočne doručia. Táto úprava je skutočným návratom na prvom agentovi a je to to, čo robí druhého financovateľným.