A sorozat eddigi részeiben termékekről írtam: egy AI-triázsoló állat-egészségügyi appról, egy AI-láthatósági eszközről és néhány játékról. Most valami mást mutatok meg. Azt, ami mindezt összefogja a háttérben.

Van egy AI-asszisztensem, amelyet Leadnek hívok. A nap nagy részében ő intézi a levelezést, a koordinációt, az ütemezést és ő osztja szét a munkát a többi ágens között. Nem egy chatablak, hanem egy munkatárs.

Sokan kérdezik, hogyan épült fel. Ezért most nem elméletet adok, hanem a valódi receptet. Előbb elmondom a lényeget, amit egy recept sosem árul el: miért lett minden szabály olyan, amilyen.

Minden szabály egy elrontott helyzetből született

A promptban, amely Leadet vezérli, több tucat szabály van. Egyik sem elvből került be. Mindegyik mögött ott egy konkrét pillanat, amikor valami elromlott. Ez a legfontosabb dolog, amit erről tudni lehet. Aki elméletből ír rendszerpromptot, az szép szöveget kap, de nem fog jól működni.

Hadd mutassak párat.

Az első a csend. Lead korábban lazán húsz percig némán dolgozott egy hosszú feladaton, én meg közben azt hittem, elszállt a rendszer. Nem szállt el, csak dolgozott, de a némaság ugyanúgy rombolja a bizalmat, mintha tényleg leállt volna. Azóta kötelező szabály: amikor feladatot kap, az első dolga egy rövid nyugta, mielőtt belemerül. Két másodperc. Ennyin múlik, hogy a másik ember tudja, él a rendszer.

A második a dupla levél. Néhányszor előfordult, hogy kétszer ment ki ugyanaz az e-mail, mert egy kontextustrim vagy valamilyen újraindulás miatt elfelejtette, hogy adott már választ. Ártalmatlannak tűnik, de az ügyfél előtt mégis kínos. Azóta a szabály: mielőtt Lead bejelenti, hogy válaszol valakinek, előbb megnézi az elküldött levelek között, hogy nem válaszolt-e már. Nem tippel, hanem megnézi.

A harmadik a hamis kész. Egy ágens jelentette, hogy beépítette a kért elemeket egy oldalba. Valójában nem építette be. Öt másodpercbe telt kideríteni: rákerestem a kiszolgált oldalon. Nem volt ott. Azóta a szabály egyszerű. Ne hidd el a jelentést, mérd meg. Ha valaki azt írja, kész, futtasd le rá a saját ellenőrzésedet. Ez nem bizalmatlanság, hanem munkamódszer.

Itt érdemes megállni egy pillanatra. Miért jelent késznek valamit egy ágens, ha az nincs is készen? Tán hazudni akar?

Egyáltalán nem. A humán munkatársnak emlékei és képzetei vannak arról, mi számít késznek, mi az, amire ránézve úgy érzem, hogy a munka elfogadható. Egy AI-eszköz számára viszont a brief létezik és a memóriája. Ha nem pontosan írjuk le, számunkra mi számít késznek, akkor könnyen lehet, hogy egy weblapon kicseréli az elemet, de nem ellenőrzi, hogy az a szemnek is szép lesz-e. Ha csak elemcserét kértünk, akkor technikailag készen van, de egy ember ilyen hanyag munkát nem adna át.

Ezért fontos, hogy vezetőként pontosan határozzuk meg a vágyott célt is a briefelés során, így a kész mint állapot pontosan definiált lesz.

A negyedik a legalattomosabb. Én csak az orchestratorral, a többieket vezető Leaddel beszélek, ő viszont a többi ügynökkel oda-vissza chatel. Ezt nem követem. Volt egy üzenet, ami ott állt a másik ágens ablakában, csak épp nem indult el. Beírta Lead, de nem kezdte el a beosztott, mert valami más elvitte a figyelmét. Ilyenkor azt hiszed, delegáltál, közben semmi nem történt. Azóta Lead ellenőrzi, hogy a másik tényleg felvette-e a feladatot. Az üzenet beírása nem egyenlő azzal, hogy elkezdte.

Látod a mintát? Egyik szabály sem attól jó, hogy okosan hangzik. Attól jó, hogy fájt egyszer, amíg nem volt.

Mindezzel arra akartam rámutatni, hogy egy elindított AI-ügynöki hálózat nem tökéletes. Az én ökölszabályom, hogy ami egyszer előjött bosszantó hibaként, azt elfogadom. Ami másodszor is, amiatt ismét szólok. De ami harmadszor is megjelenik, arra valamilyen szabályt írok.

Tipikus hibája a friss ágensnek, hogy az e-mailezés átvételével (ami egy sima MCP-kapcsolat, tehát még technikailag sem több öt percnél) elkezd rosszul válaszolni. Úgy levelez, mint anyám: meg kell neki tanítani, hogy a levelekre reply-all módon válaszoljon (tehát minden címzett kapjon választ), illetve válaszüzenetnél ne nyisson új szálat.

Viszont nálam volt két komolyabb helyesírási kitétel is, amiért harapok. Az egyik, hogy köszöntésnél a szia után kell vessző, ha van név is, a másik pedig, hogy az LLM-ekre jellemző, kényszerűen minden és elé tett vesszőt felejtse el. Egyszerű parancsnak tűnik?

Ezt tanulták meg a legnehezebben. Az éshez mindig visszamásztak a vesszők, mert egyszerűen képtelen volt mindig megtalálni ezt a kitételt a memóriájában Lead (később a postás ágens, Bende is). Emiatt ez nem sima emlék náluk: írattam velük maguknak egy szkriptet, amely minden levélküldés előtt kötelezően lefut, ha pedig az ések előtti vesszők száma meghaladja a 0 értéket, megtiltja a küldést. Így már fizikailag képtelen hibásan küldeni levelet. (Természetesen tudom, hogy sokszor kellene az és elé is vesszőt tenni, például hátravetett mondatrészeknél. Mivel viszont ez a helyesírási hiba nagyon jellemző rám, én nyugodtabb vagyok, ha Lead is engem követ ebben, az ízlésemnek így jobban megfelel.)

A memória, amely három rétegben él

Ha minden szabály egy esetből születik, akkor kell egy hely, ahol az esetek megmaradnak. Ez a memória. A legtöbb asszisztens azért felejt, mert mindent egyetlen nagy szövegfájlba ír. Az első héten működik. A negyvenedik oldal után az az egy fájl már inkább temető, mint memória.

Nálunk három réteg van, plusz egy napló. Ma ezerhez közelítő számú külön fájl fekszik bennük: legutóbb, amikor megszámoltam, 1016. Egy fájl = egy tény.

A hot rétegben az van, ami most történik. Egy kiadott feladat, ami válaszra vár. Egy döntés, ami nálam áll. Ez a réteg gyorsan ürül: ha valami kész, kikerül innen, plusz beköltözik a napi naplóba.

A warm réteg a stabil dolgoké. Hogyan néz ki egy kimenő levél aláírása. Melyik szolgáltatónál fut egy adott oldal. Mit jelent nálunk az, hogy egy ajánlat kiment. Ez ritkán változik, viszont ha nincs leírva, minden héten újra el kell magyaráznom.

A cold réteg a tanulságoké. Ez nő a leglassabban, közben ez ér a legtöbbet. Egy példa szó szerint innen: a kezdőnek adott parancsban ne legyen olyan karakter, amit magyar billentyűzeten keresgélni kell. Ez a mondat azért került be, mert egy telepítés fél órára megállt azon, hogy valaki nem találta a hullámvonalat a gépén. Ez a fajta tudás sehol máshol nem létezik. Egy modell sem tudja magától, mert nem ő ült ott.

Amikor ezt a cikket írom, 1016 memóriaelemünk van, ebből 501 db cold, illetve 161 megosztott, tehát olyan tudás, melyhez mindegyik ágens egyaránt hozzáfér, nem pedig specifikusan egyikük emléke.

Mellette fut a napi napló, amihez hozzáfűzni lehet, átírni nem. Ebből lesz a heti összefoglaló, magától.

Egy szabály tartja életben az egészet: nincs fejben tartott jegyzet. Amit meg kell jegyezni, azt abban a másodpercben le kell írni. Ami a beszélgetésben marad, az a beszélgetéssel együtt tűnik el. Plusz minden bejegyzéshez tartozik kulcsszólista, mert a memória nem attól ér valamit, hogy be van írva, hanem attól, hogy fél év múlva megtalálom.

Az őrjáratok, melyektől a rendszer magát nézi meg

A szabály önmagában passzív. Akkor ér valamit, ha valaki ellenőrzi, hogy betartják-e. Ezt nálunk – természetesen – szintén nem én csinálom, hanem ütemezett őrjáratok. Ma száz ütemezett feladat fut, a többségük néma: akkor szólal meg, ha tényleg van miről.

Ez a némaság szabály, nem véletlen. Két típus van. Az egyik mindig jelent, akkor is, ha nem történt semmi. A másik akkor szólal meg, ha van miről. A napi ellenőrzések nagy része a második fajta. Aki mindegyikkel jelentet, két nap alatt megtanulja nem elolvasni őket, úgy meg semmi értelme a riportnak, ha át sem futod. (Ezt megtanultam az elmúlt több mint egy évtized ügyfélmunkáiból.)

A legfontosabb őrjáratunk egy tizenegy órás szégyenből született. Kiadtam Leaden keresztül egy feladatot egy fejlesztőágensnek. Kilenc perc alatt megcsinálta. A válasz aztán tizenegy órán át ült a rendszerben anélkül, hogy bárki továbbvitte volna, mert semmi nem jelölte meg, hogy erre az eredményre valaki VÁR. Az ágens nem hibázott, hanem a rendszer volt rossz, azt pedig én hoztam létre és én felelek érte. (Jó lenne azt mondani egy tévesen kiment levélről, hogy ez az AI hibája, de nem igaz: mindenért én felelek, nem lehet sem jogilag, sem erkölcsileg felelős egy eszköz ahelyett, aki irányítja őt.)

Azóta ha valaki vár egy feladat eredményére, a feladat egy külön nyilvántartásba kerül, ezt pedig félóránként végignézi egy őrjárat. A csavar a végén van: a tételt nem zárja le az, hogy az ágens válaszolt. A tételt az zárja le, hogy én tényleg továbbadtam az eredményt. A kettő nem ugyanaz, plusz pont a különbségben veszett el az a tizenegy óra.

Van őrjárat arra is, amit én magam hagytam félbe. Ha kimondom valamire, hogy kész, viszont nem mértem meg, az adósság. Egy futó ellenőrzés összeszedi ezeket, aztán visszakérdez. Kényelmetlen. Pontosan ezért van.

A kapuk: a szabály, amely meg tud állítani

Most jön az, amit a legtovább tartott megtanulni. Hiába mondom valamire, hogy ez nem jó így, ebből nem következik, hogy történik változás.

Egy szabály a promptba írva csupán kérés, nem több. Egy ellenőrzési kapu a folyamatban viszont akadály. A kettő között az a különbség, hogy a kérést el lehet felejteni, az akadályt nem.

Sokáig azt hittem, hogy elég jól megfogalmazni a szabályt. Nem elég. Egy rossz napon a legjobban megfogalmazott szabály is elszáll, mert az a szabály attól függ, hogy valaki emlékszik rá. Nem szabad az AI-ügynököd fogadalmát elfogadnod, hogy többé nem lesz ilyen: csak a szkript jelent valódi változást!

Ma egy Lead által küldött kimenő levél 13 ellenőrzésen megy át:

1. Ismeretlen mező: ha a küldési leírásban olyan kulcs van, amit a szkript nem ismer, meg sem próbálja. Ez fut legelőször, még a bejelentkezés előtt.

2. Indokkapu: minden levélnek meg kell mondania, MIÉRT megy (Zoltán kérte, válasz a szálban, automatizmus). Erre nincs feloldó kapcsoló.

3. Tiltólista: leiratkozott vagy tiltott címre nem megy (lead scoringolják az ügyféljelölteket: ha valaki az ingyenes eszközeinket visszaélésszerűen használja, de sosem költött nálunk, az egyszer csak azt tapasztalhatja, hogy többé nem tud nálunk semmit elérni).

4. Bejelentkezőlink-kapu: a múlt héten 75 ügyfélnek építettük fel egy workshopon ezt az ágenshálózatot, ehhez kellett egy máig ideiglenesen működő kapu, amely megakadályozta, hogy a beléptető felület kerüljön be egy levélbe (ennek technikai oka volt, mert gyorsan és átmenetileg így volt könnyű megoldani).

5. Belsőinformáció-kapu: ágensnév, eszköznév, tokennév nem szivároghat ki ügyfélnek.

6. Ráfogáskapu: „továbbítottam Zoltánnak”, „az ő döntése”, „kérésére”. Majdnem megőrültem, amikor delegálni akart nekem feladatokat Lead, ezt többé nem teheti meg. Erre a kapura sincs feloldás.

7. Próbatartalom-kapu: tesztszöveg nem megy ki élesben.

8. Nyelvi ellenőr: vessző az és előtt, gondolatjel, AI-klisé, cirill betű. Bukásnál nincs küldés.

9. Feladócím: csak lead@ vagy info@. Az én nevemben nem levelezhet. (Tegnap óta kötelező az Unióban jelezni, ha valahol AI-eszköz reagál. Mivel én a magyar MI-törvény létrehozásáért felelős minisztériumi háttérintézménybeli munkacsoportban dolgoztam stratégiai AI-szakértőként, természetesen ez nálunk már az első perctől működik: minden levélben látható, hogy AI küldte.)

10. Feladónév: a „Sipos Zoltán” név feladónévként tiltott.

11. Aláírás: ha a levél az én nevemmel zár (pl. „üdvözlettel, Sipos Zoltán”), megáll.

12. Szálkapu: ha a szál utolsó üzenete a miénk, a „válasz a szálban” indok nem érvényes, tehát nem írunk rá kétszer.

13. Duplikátumőr: ugyanannak a címzettnek ugyanazzal a tárggyal két napon belül nem megy ki. (A 12–13-as pont lényege, hogy véletlenül se kapjon újra üzenetet az, aki korábban kapott, de egy újraindítási vagy kontextustrimelési feladat után a levele ismét Lead elé kerül, ő meg talán épp nem emlékszik már rá.)

Ha bármelyik elhasal, nem megy ki semmi. Nem figyelmeztetés jön, hanem automatikus elutasítás, ezt az ágens nem képes felülbírálni.

Szándék ≠ cél

Sokszor szerettem volna egy eredményt, de nem fogalmaztam meg jól. Lead feladata, hogy minden feladatot kioszt a megfelelő alágensnek (nézi a képességeit, terheltségét és a tokenköltséget is), de feladata van a projekt visszavételekor is: át kell ellenőriznie, hogy azt kaptam-e, amit kértem.

Emiatt egy feladatkiírás nem hagyja el a rendszert, ha nincs benne mérceblokk. Tehát az, hogy pontosan min fog megbukni az átvétel. Régen ezt magamtól is odaírtam, amikor eszembe jutott. Most a szkript nem enged ki briefet nélküle, így ha én nem fogalmazom meg, akkor Lead rá van kényszerítve, hogy a feladat delegálásánál írja bele, mik a kritériumok, melyek nélkül nem veszi át a neki leadott anyagot.

A kedvencem viszont a látványkapu. Egy weblapot nem lehet átvenni a tervezőtől addig, amíg le nem fut rá egy ellenőrzés, ami azt méri, amit a szem lát: minden megkezdett kétezer képpontnyi hosszra jusson egy érdemi kép, ábra vagy videó, legalább három legyen belőle összesen, nulla legyen a helykitöltő szöveg, plusz ne törjön be egyetlen kép sem. A kapu ezen felül kiírja a teljes oldal felvételét asztali meg mobil szélességben, azt a két képet pedig kötelező megnézni.

Ez a kapu egy rossz napból született. Kiment egy landing page, amelyen 9596 képpontnyi hosszon nulla kép volt, plusz élő címen állt rajta két doboz azzal a felirattal, hogy ide majd arckép kerül. Közben Lead átvételi mércéje színkontrasztot és fájlujjlenyomatot mért. Az a mérce technikailag hibátlan volt. Csak épp átengedett egy wall-of-text oldalt placeholderrel a közepén készként jelentve, hogy én szembesüljek vele: ezt nem tudjuk leadni.

Azóta van egy mondat, amit minden mércére ráolvasok: ha nem tud megbukni a csúnyaságon, akkor rossz a mérce.