Obyčejné chatovací okno je univerzální. Zeptáte se na cokoli a ono se pokusí odpovědět; to se hodí na zkoumání a jednorázové otázky, ale není to infrastruktura. Infrastruktura je to, co spolehlivě běží na pozadí, dělá dobře jednu věc a dává předvídatelné výstupy. „Připrav týdenní přehled prodejů.“ „Zařaď tuhle fakturu podle typu a naléhavosti.“ „Projdi příchozí tickety podpory a označ ty, co vypadají naléhavě.“ To jsou opakovatelné úlohy. Každé prospěje pevné zadání, pevná sada nástrojů, jasně vymezené znalosti a výstupy, které zapadnou do navazujícího workflow. Nejsou to konverzace, jsou to specialisté. Platforma, která umožní zabalit chování AI do pojmenovaných, verzovaných a oprávněními omezených agentů – a provozovatelům umožní dodávat hotové balíčky agentů na běžné firemní úlohy – dělá z AI běžnou součást nástrojů implementace, ne jen novinku.
Agent je plnohodnotný objekt platformy. Má jméno, historii verzí, model oprávnění, protokol a své místo v implementaci stejně jako dotaz, pohled nebo automatizace. Upravuje se ve stejném editoru v prohlížeči jako vše ostatní. Exportuje se ve stejném formátu jako zbytek datového modelu. Agent, který funguje v testovacím prostředí, se dá spolu se zbytkem implementace přenést do produkce; agent, který se má změnit, se verzuje, jak se vyvíjí jeho zadání a nástroje. Právě tohle propojení dělá z agentů udržitelnou součást implementace, ne roztroušenou sbírku pokusných skriptů.
Pevné zadání a sada nástrojů jsou to, co z agenta dělá specialistu. Zadání je součástí definice agenta – promyšlené, otestované a vyladěné pro konkrétní úlohu, kvůli které agent existuje. Sada nástrojů je seznam operací, které agent smí použít: číst záznamy určitých typů, zapisovat do určitých vlastností, posílat e-maily přes engine prostředí, volat konkrétní HTTP koncové body, spouštět konkrétní skripty. To omezení je záměrné. Agent bez omezení umí cokoli, a proto mu nelze svěřit nic; omezený agent dělá přesně to, na co je nastavený, a proto se na něj dá spolehnout. Pro opakovanou práci, ze které se skládá běžný provoz, jsou specialisté lepší než všeumělové.
Nástroje, které agent volá, pokrývají operace, jimiž se z úvah AI stane skutečný účinek v platformě. Operace nad modelem – přečíst záznam, upravit vlastnost, vytvořit související záznam – umožňují agentovi jednat s daty, o kterých uvažuje. HTTP nástroje mu dovolí sáhnout na externí služby pro doplnění nebo odeslání dat. Nástroj pro odesílání e-mailů mu umožní komunikovat přes e-mailový engine prostředí. Nástroj pro spuštění skriptu mu dovolí předat složitější výpočet kódu na straně serveru, kde se to hodí. Každé volání nástroje je zaznamenané, přiřaditelné a řídí se rozsahem oprávnění agenta. Agent je vlastně krok automatizace, který před akcí přemýšlí – se vším řízením, které k tomu patří.
Zdroje znalostí jsou vymezené pro každého agenta zvlášť. Agent pro zařazování faktur vidí šablony faktur a dřívější zařazení prostředí, ale mzdová data nepotřebuje. Agent pro týdenní přehled vidí prodejní záznamy a vedení firmy, ale tickety podpory vidět nemusí. Užší vymezení zlepšuje přesnost (agent se prodírá menším šumem) i bezpečnost (nemůže vynést data, která nikdy neviděl). Agenti dostávají jen ty znalosti, které pro svou konkrétní práci potřebují.
Volání z automatizací je nejběžnější způsob zapojení. Automatizace, která se spustí při příchodu faktury, může obsahovat krok s agentem, který fakturu zařadí, a zařazení pak využít v dalších krocích ke správnému směrování. Automatizace, která se spustí při vytvoření ticketu podpory, se může zeptat třídicího agenta, jestli ticket vyžaduje rychlou reakci, a když ano, upozornit pohotovostní tým. Agent žije uvnitř automatizace stejně jako kterákoli jiná akce – se vstupy z předchozích kroků a výstupy dostupnými pro kroky další.
Volání z rozhraní zpřístupňuje agenty jako akce spouštěné uživatelem. Tlačítko u záznamu – „vytvoř návrh odpovědi“ – spustí agenta, který návrh připraví podle kontextu daného záznamu. Tlačítko u pohledu – „shrň tuto skupinu“ – spustí agenta, který přečte vyfiltrovanou množinu a vytvoří shrnutí. Uživatel vidí tlačítko; za ním je agent; co se stane, určuje jeho nastavené zadání, nástroje a znalosti. Pro situaci „proveď tuhle akci s AI hned“ je tohle ta správná podoba.
Naplánovaní agenti běží podle plánu (jako cron) a zvládají opakující se úlohy, kterým víc než spontánnost prospívá spolehlivost. Agent pro týdenní report se spustí každé pondělí ráno, vytvoří shrnutí, pošle ho vedení a kopii uloží do úložiště souborů. Agent pro noční párování se spustí po pracovní době, projde nespárované transakce dne, pokusí se je spárovat a označí ty, které spárovat nedokázal. Právě tenhle chod bez dohledu mění agenta z nástroje, který se občas použije, ve stálou součást provozu prostředí.
Balíčky jsou způsob, jak se hotová funkcionalita agentů dostane do prostředí, aniž by ji každý stavěl znovu. Balíček je předpřipravená sada agentů spolu s typy, pohledy, automatizacemi a šablonami, na kterých závisí – instalovatelný celek, který jednou operací přidá do prostředí ucelenou schopnost. Provozovatel, který obsluhuje zákazníky v určitém oboru, může vydat balíček s agenty vyladěnými na běžné procesy toho oboru; zákazníci si balíček nainstalují a hned mají funkční řešení těch procesů, s agenty připravenými k běhu.
Tvorba balíčků je práce na straně provozovatele. Provozovatelé sestaví balíčky ve vzorovém prostředí, otestují je na reprezentativních datech, zverzují a vydají je do sítě prostředí. Prostředí vidí dostupné balíčky, projdou si, co každý z nich nainstaluje, a rozhodnou se je přijmout. Vydané balíčky lze aktualizovat – vylepšení agenta pro zařazování faktur ve verzi 2.1 dorazí do každé instalace, jakmile ho provozovatel vydá – se stejnou správou verzí jako zbytek platformy. Balíčky jsou způsob, jak provozovatelé promění vlastní zkušenost z implementací v přenositelnou hodnotu pro svou zákaznickou základnu.
Přehled o využití a nákladech brání tomu, aby se AI infrastruktura stala finančním překvapením. Každý běh agenta se zaznamená s náklady a dobou trvání; prostředí vidí své využití agentů v dashboardu, provozovatelé vidí využití napříč sítí pro plánování kapacity. Nákladové limity lze nastavit pro jednotlivé agenty i pro celé prostředí, aby výdaje neutekly. Vůči oprávněné obavě, že AI funkce mohou být bez omezení nákladné, mění tenhle přehled nejistotu v řízený provozní náklad.
S chybovými stavy se počítá. Agent, který narazí na chybu, ji strukturovaně zaznamená do protokolu událostí. Agent, jehož výstup neprojde následnou kontrolou, na problém upozorní a data nepoškodí. Agent, který překročí svůj časový nebo nákladový limit, se čistě zastaví. Vůči tomu, že AI služby občas vrátí špatný výstup, přistupuje platforma k těmto selháním stejně jako ke kterýmkoli jiným – jsou vidět, dají se napravit a jejich dopad je omezený.
Od chatu k agentům je přirozený vývoj, ke kterému AI funkce vedou. Zkoumání probíhá v AI asistentovi. Opakovaná práce se zabalí do agenta. Přenositelná práce se dodá v balíčku. Každá vrstva staví na té pod sebou a každá je vhodná pro jiný druh využití AI. Pro toho, kdo si teprve buduje cit pro to, kdy po čem sáhnout, je tenhle sled vodítkem; v praxi vyzrálá implementace používá všechny tři.
Související témata: článek o AI asistentovi popisuje konverzační rozhraní pro zkoumání, článek o AI v datovém modelu a automatizacích se věnuje AI funkcím, které urychlují implementační práci, článek o propojení s AI popisuje, jak se platforma napojuje na externí AI služby, a článek o automatizacích popisuje vrstvu workflow, do které se agenti zapojují. Opakovaně použitelní pomocníci pro vaše procesy – přesně na to jsou agenti a balíčky, a takhle si AI zaslouží místo v dlouhodobé infrastruktuře platformy, ne jen roli efektní funkce, která nikdy neopustila ukázku.