Amikor valaki meglátja, hogy több különálló AI-folyamat dolgozik nálam egymás mellett, szinte mindig ugyanaz az első kérdés: „hány agented van?” Értem, miért ez a reflex — látványos szám, könnyű vele büszkélkedni. De ez a rossz kérdés. A számnál sokkal jobban számít egy másik: mi történik, ha az egyik rosszul dönt — van-e, ami ezt megállítja, mielőtt kárt okoz?
Ezt a cikket azért írom meg elsőnek a Playbook-ban, mert ez az az elv, ami az összes többi mögött ott van. Ha ezt megérted, a többi gyakorlat — az auditnapló, a kapuk, a mérés — mind ebből a logikából következik.
A szám becsapós
Egy 20 különálló AI-folyamatból álló rendszer rosszabb, mint egy 3-ügynökös, ha az előbbinek nincs semmi, ami megfogja a hibás lépéseket, az utóbbinak pedig van. A darabszám csak azt mutatja, mennyi munkát bíztál ki. Azt nem mutatja, hogy mennyire bízol meg abban, amit kiadtál a kezedből — és jogosan bízol-e.
A saját rendszeremben jelenleg 16 önálló, specializált munkafolyamat dolgozik, mindegyik szűk feladatkörrel. De ami tényleg tartja az egészet, az nem ez a 16, hanem egy külön elv: van egy döntéshozó réteg, ami soha nem végez munkát saját kézzel. Nem olvas fájlt, nem ír, nem futtat parancsot, nem küld emailt — mindent egy-egy szűkebb jogosultságú végrehajtóra bíz, egy konkrét, körülhatárolt feladattal. Ez elsőre formalitásnak tűnik. Valójában biztonsági határ: a döntéshozó soha nem keveredhet bele közvetlenül egy elrontott művelet felelősségébe, mert soha nem ő az, aki ténylegesen megnyomja a gombot.
A szabály, aminek van neve és gazdája
A második elem, ami tényleg számít: minden komolyabb szabály explicit, azonosítható, és van forrása. Nálam jelenleg 130 ilyen szabály fut, mindegyiknek van azonosítója, van egy súlyossági szintje (kritikus vagy csak ajánlott konvenció), van gazdája, és — ez a legfontosabb — van egy forrás-hivatkozása egy konkrét, valós esetre, ahol kiderült, hogy a szabály nélkül baj lett volna. Nem elméletből született egyik sem. Mindegyik egy tényleges hibából vagy majdnem-hibából.
Ez a rész az, ami a legtöbb AI-bevezetésből hiányzik. Az emberek megírnak egy szép promptot, ami elmondja az AI-nak, hogy „légy óvatos” — de ez nem szabály, ez jó szándék. A szabály az, amit ki lehet kényszeríteni, nem csak leírni.
Két kapu, de nem mindenre
Minden kritikus szabálynál van egy kettős ellenőrzés: egy a művelet előtt (megnézi, hogy a tervezett lépés sért-e valami visszavonhatatlant), és egy a művelet után (ellenőrzi, hogy tényleg az történt-e, amit vártál). Ha az előzetes ellenőrzés elutasít valamit, a kérést újra kell fogalmazni — nem ismételheted ugyanazt vég nélkül.
De itt jön a gyakorlati csapda, amibe könnyű beleesni: ha mindenre kapu épül, agyonlassítod magad, és senki nem veszi komolyan a folyamatot — ez tényleg megtörtént nálam egy korábbi verzióban, ahol minden egyes apró lépés előtt lefutott egy teljes ellenőrzés, és két hónap alatt kiderült, hogy ez tiszta overhead volt ott, ahol a kockázat elhanyagolható. A megoldás nem a kapuk eltörlése volt, hanem a szelektivitás: csak azok a lépések mennek kötelezően kapun át, amik visszavonhatatlanok, külső felet érintenek, vagy pénzügyi/jogi vonzatuk van. A 130 szabályból körülbelül 29 esik ebbe a „mindig kapun át” kategóriába. A többi utólagos, összesített ellenőrzésbe kerül — hetente egyszer átfut rajta valaki (vagy valami), és ha rendszeresen ugyanaz a minta jön elő, az jelzi, hogy talán mégis kritikussá kellene léptetni.
A konszolidáció, ami megtanított valamire
Volt egy időszakom, amikor jóval több, kisebb, egymást részben átfedő folyamatom futott, mint ma. Idővel kettőt is összevontam néhány jól körülhatárolt, szélesebb hatáskörű egységbe — nem mert a darabszám önmagában baj lett volna, hanem mert az átfedések miatt ugyanazt a szabályt több helyen kellett karbantartani, és ez pont ott vezetett hibához, ahol a legkevésbé engedhetted volna meg. A tanulság, amit ebből levontam, megerősítette a fenti tézist: maga az összevonás nem hozott biztonságot. A biztonságot az hozta, hogy a régi, szétszórt szabályokat egyetlen, konzisztens szabálykönyvbe rendeztem, ahol minden szabálynak pontosan egy helye van, nem több. Ha csak összevontam volna a folyamatokat, de a szabályok szétszórtan maradnak, semmit nem nyertem volna — sőt, nehezebb lett volna átlátni, mert több minden lapult volna kevesebb helyen.
A hibaarány nem szégyen — a mérés hiánya az
Volt egy hetem, amikor a fő döntéshozó folyamat 141-szer futott le, ebből 104 sikeresen, 36-szor hibával, egyszer pedig megszakadt. Ha ezt egy sales-oldalon mutatnám be, valószínűleg kihagynám. De pont ez a lényeg: a 36 hiba nem azt jelenti, hogy a rendszer rossz — azt jelenti, hogy van, ami méri, mikor rossz. Egy rendszer, ami sosem hibázik a naplója szerint, kétféle lehet: vagy tényleg tökéletes (valószínűtlen), vagy nem mér semmit, és a hibák csendben elsüllyednek. Az utóbbi sokkal veszélyesebb, és sokkal gyakoribb, mint gondolnád.
Mit vigyél el ebből, ha most kezded
Nem kell 130 szabállyal indulnod — az én rendszerem is fokozatosan nőtt idáig, minden szabály egy konkrét tapasztalatból született, nem egyszerre írtam le mind. De három lépés, amivel érdemes kezdeni:
- Írd le azt az 5-10 dolgot, amit az AI-rendszered soha nem tehet meg autonóm módon — pl. ne küldjön ki emailt jóváhagyás nélkül, ne törölhessen visszavonhatatlanul adatot, ne élesítsen kódot ellenőrzés nélkül. Ez a te „kritikus” listád.
- Tedd ezt kikényszeríthetővé, ne csak leírttá. Egy prompt-instrukció, amit az AI „figyelembe vesz”, nem szabály — az egy kérés. A szabály az, aminek van egy ellenőrzési pontja, ahol tényleg megáll a folyamat, ha sérül.
- Mérd a saját hibaarányodat, és ne szégyelld. Ha a rendszered soha nem mutat hibát, az nem azt jelenti, hogy jól megy — azt jelenti, hogy vaksötétben vagy.
A darabszám látványos, de nem véd meg semmitől. A szabályréteg az, ami miatt egyáltalán mersz autonómiát adni valaminek — és ami miatt, ha mégis elromlik valami, pontosan tudod, hol és miért.
Ha ez a réteg — a szabályok szerkezete, a kapu-logika, a súlyossági szintek — érdekel mélyebben, a Blueprint-ek között van néhány, ami a technikai vázat is megmutatja.