Zavádění AI agentů do firmy bez spálení IT rozpočtu

Každá firma, kterou potkám, má stejné ambice — agenta, který zvládne práci od začátku do konce — a stejný problém: nikdo neumí říct, co znamená „zpracováno“, takže nikdo neumí říct, kdy je hotovo.

Proč projekty s agenty váznou

Práce agentů selhává na třech předvídatelných místech. Požadavky se píší jako přání („zpracujte zákaznické požadavky“), takže nikdo neměří úspěch. První ukážku dělají lidé, kteří ji staví, na datech, která sami vybrali — a to vám o produkci neřekne nic. Potom se autonomie udělí najednou a první drahá chyba projektu sebere politický kapitál.

Nic z toho není o kvalitě modelu. Jde o to, jak je práce seřazena.

Začněte frontou, ne schopností

Nejužitečnější změnou, kterou dělám, je odmítnout začít schopností a trvat na začátku frontou. Ne „zákaznická podpora“ — ale „340 ticketů týdně, která přicházejí s fotkou poškozeného kusu a potřebují rozhodnutí o vrácení peněz“.

Fronta má objem, vzor příchodů, měřitelné současné náklady na zpracování a — co je zásadní — definici hotova. Také vám řekne, jaká data jsou potřeba, a to vám řekne, jaká oprávnění agent potřebuje, a tam leží většina skutečného inženýrství.

Vyberte frontu, kde je práce opakovaná, kontext je dostupný v systémech, které už máte, a chyba se dá napravit. Taková kombinace je vzácnější, než si lidé myslí. Třídění podpory je dobrý kandidát. Cokoli, co se dotýká právního závazku nebo nevratné platby, není — zatím.

Režim stínu před autonomií

Než agent něco udělá, udělá všechno.

Spusťte ho na reálném provozu, paralelně s lidmi, kteří práci dělají dnes, a výstup posílejte do fronty, kterou zatím nikdo nečte. To jsou nejhodnotnější dva týdny celého projektu, protože přinesou tři věci najednou:

• Číslo o přesnosti. Jaké procento rozhodnutí agenta by člověk přijal beze změny?
• Taxonomii chyb. Skoro nikdy nejsou náhodné. Seskupují se do chybějícího kontextu, nejasné politiky a případů, kdy správná odpověď byla zeptat se.
• Artefakt pro stakeholdery. Sledování dashboardu se skutečnými případy je to, co mění skepsi v rozhovor o rozpočtu.

Režim stínu je levný, trapně upřímný a pravidelně překvapuje lidi oběma směry.

Nejdřív návrh, potom čin

Většina projektů s agenty dodá svou hodnotu ve fázi pouhého návrhu a pak příliš brzy tlačí na autonomii.

Agent, který pouze navrhuje — vrácení peněz, odpověď, aktualizaci ticketu nebo vyznačení smluvního ustanovení v difu — to už je velký nárůst produktivity a nese to téměř žádné riziko, protože člověk pořád čte každé slovo. Míra eskalace klesá, čas kontroly klesá a kvalita agenta se zlepšuje s každou kontrolou, protože opravy jsou označená data.

Autonomii by se měla udělovat po akcích, ne po agentech. Čtení záznamu v CRM může být od prvního dne bez dohledu. Vytvoření záznamu může následovat. Vrácení peněz vyžaduje schválení, dokud evaluační data neřeknou jinak — a „jinak“ by mělo být číslo, ne pocit.

Co skutečně potřebuje člověka

Ponechte člověka ve smyčce, když je akce nevratná, viditelná pro zákazníka, právně závazná, nejasná podle vaší písemné politiky nebo bezprecedentní. Ten seznam je kratší, než se lidé bojí, a jeho zachování krátké je to, co dělá autonomii důvěryhodnou pro rizikovou nebo auditní funkci.

Všechno ostatní je kandidát — s limity. Omezte výdaje na spuštění, omezte počet kroků na spuštění, omezte souběžná spuštění. Spuštění, které narazí na limit, by se mělo zastavit a eskalovat, ne improvizovat, protože improvizace ve 40. kroku je místo, kde bydlí drahé incidenty.

Poctivé měření

Měřte čtyři věci, týdně, a odolejte pokušení přidat pátou:

• Vyřízený objem — případy dokončené od začátku do konce, aniž by se jich dotkl člověk.
• Kvalitu — odebranou lidským recenzentem podle rubriky domluvené v prvním týdnu.
• Náklady — na vyřízený případ, včetně tokenů, volání nástrojů a infrastruktury.
• Míru eskalace — podíl, který jde k člověku, a proč.

Počty konverzací a skóre spokojenosti uživatelů na tomhle seznamu záměrně nejsou. Obojí se snadno nafoukne a těžko interpretuje. Pokud vyřízený objem stagnuje a náklady na případ rostou, agent se zhoršuje, ne zlepšuje.

Multi-agent systémy: většinou ne

Většina firemních „multi-agent“ architektur, o které mě žádají postavit, je jeden agent s odolnou smyčkou a dvěma nebo třemi nástroji. Vzor vypadá v diagramech impozantně a obvykle je v produkci horší: víc kontextu k řízení, víc způsobů selhání, těžší ladění a latence vynásobená přes skoky.

Přidávejte agenty, jen když je k tomu skutečný důvod. Oddělená oprávnění, která nechcete spojovat. Rozpočty kontextu, které se skutečně nemohou dělit o okno. Práce, která je skutečně paralelní a samostatně hodnotná. Pokud je jediným důvodem, že „multi-agent“ zní pokročileji, ponechte smyčku.

Pořadí na 90 dní

Dny 1–30: vyberte frontu, napište rubriku, postavte režim stínu, zveřejněte číslo o přesnosti.

Dny 31–60: nasaďte režim pouhého návrhu do reálných front kontroly, změřte náklady na případ, opravte tři nejčastější třídy chyb.

Dny 61–90: udělte nehlídané provádění akci po akci, druhou frontu přidejte jen, když je ta první skutečně nudná.

Většina firem, které to udělají, skončí s jedním produkčním agentem, který jednu věc dělá dobře — a, co je zásadní, s upraveným přesvědčením organizace o tom, co agenti skutečně přinášejí. Tato úprava je skutečný návrat z prvního agenta a právě ona dělá toho druhého financovatelného.