A modell nem azonos az ügynökkel
Egy AI ügynök két részből áll. Az egyik a modell, amit a szállító ad, és amire a cégnek alig van ráhatása. A másik minden egyéb, vagyis a ciklus, ami újra és újra meghívja, az eszközök, amiket használni tud, a kontextus, amit lát, a jogosultság, ami megállítja, és a napló, ami rögzíti, mit csinált. Ezt a második részt hívja a szakirodalom harnessnek, és az esetek nagy részében itt dől el, hogy az ügynök hasznos vagy veszélyes.
Amikor egy ügynök rosszul viselkedik, az ok többnyire nem a modellben van, hanem abban, amit köré építettek.
Ez a megkülönböztetés azért fontos, mert a modellt cserélni egy konfigurációs sor, a köré épített réteget viszont valaki megtervezte vagy éppen nem tervezte meg. Az átvilágítás ezt a réteget nézi, forráskód és működés szintjén, nem a demót.
A hét pont, amit végignézünk
A sorrend nem véletlen, ebben a sorrendben szokott elromlani.
A ciklus. Mi állítja meg az ügynököt. Hány fordulót futhat, mennyi pénzt költhet, mi történik, ha ugyanazt a lépést harmadszor próbálja. Olyan rendszert is láttam már, ahol erre a kérdésre nem volt válasz, csak egy várakozás, hogy a modell majd abbahagyja.
A modellhívás. Hány helyen hívják közvetlenül a szolgáltatót, van-e közös belépési pont, mi történik kimaradásnál, és mi a tartalék. Ha a hívás húsz fájlban szét van szórva, a szolgáltatóváltás hónapokba kerül.
Az eszközök. Mit tud ténylegesen csinálni az ügynök, milyen sémával, és mi történik rossz bemenetnél. Tizenöt eszköz fölött a leírásuk már komoly helyet foglal a modell figyelméből, ott halasztott betöltés kell.
A kontextus és a memória. Mi kerül be minden híváskor, mi tömörítődik, mi marad meg két munkamenet között. Itt szokott kiderülni, hogy a rendszer olyan adatot visz be, aminek nem kellene ott lennie.
A jogosultság. Melyik lépéshez kell emberi jóváhagyás, és mi az, amit a futtatókörnyezet tilt, nem pedig a prompt kér szépen. A kettő között az a különbség, hogy az egyiket egy ügyes bemenet nem tudja átbillenteni.
Az orkesztráció. Indít-e az ügynök további ügynököket, és indokolt-e. A több ügynökös futás nagyságrenddel több tokent fogyaszt, és a legtöbb üzleti feladatban nincs igazán párhuzamosítható rész.
A bővíthetőség. Hogyan lehet új képességet adni hozzá a cégen belül, kód nélkül. Ha erre nincs válasz, minden új igény fejlesztői feladat lesz, és a rendszer megáll a szállító kapacitásánál.
Két kérdés, ami egy ajánlatban rögtön látszik
2026 nyarán négy kutató elolvasta tizenegy éles AI kódoló ügynök teljes forráskódját, nagyjából négymillió sort, köztük a Claude Code, a Codex, a Gemini CLI és az OpenHands kódját. Két dolog hiányzott mindegyikből, amit a piac alapfelszerelésként árul.
Az egyik az ügynök keretrendszer. A vizsgált tizenegy rendszerből egy sem használ ilyet a futásidejében, a Google saját eszköze a Google két keretrendszerét sem. Ha egy ajánlatban keretrendszer szerepel, az nem automatikusan rossz, de magyarázatot kíván, mert a piacvezető termékek egyike sem így készült.
A másik a vektoros keresés a kód fölött. Ebből nulla volt a tizenegyből, helyette szöveges keresés és szerkezeti elemzés megy. A vektoros megoldásnak máshol van helye, például dokumentumtárban vagy ügyfélszolgálati tudásbázisban, kódkeresésre viszont pénzbe kerül, karbantartást kíván, és a bizonyíték ellene szól.
Ez a két kérdés egy ajánlatbeszélgetésen öt percet vesz igénybe, és sok hónapnyi felesleges fejlesztést takaríthat meg.
Amit a megbízás tartalmaz
Állapotfelmérés a hét alrendszer mentén. Minden pontnál leírom, mi van ma, hol van a kockázat, és mi a legkisebb beavatkozás, ami megszünteti. Fájl és sor szinten hivatkozva, hogy a fejlesztő másnap neki tudjon állni.
A korlátok megírása. Nem javaslatként, hanem működő konfigurációként. Lépés és költségkorlát, tiltólista, jóváhagyási pontok, és egy olyan alsó korlát, ami a legengedékenyebb üzemmódban is érvényben marad.
Naplózási terv. Mi kerüljön rögzítésre ahhoz, hogy egy vitás esetnél utólag rekonstruálható legyen, mit csinált az ügynök és minek a hatására. Ugyanez a nyom lesz a bizonyíték egy megfelelési vizsgálatnál.
Vezetői összefoglaló. Két oldal arról, mit vállal a cég ezzel a rendszerrel, mi az a három dolog, ami élesben elromolhat, és mi a költsége annak, hogy ne romoljon el.
Amikor ez a jó választás
Akkor éri meg, ha az ügynök már létezik vagy épp most készül, és valódi dolgokhoz nyúl. Levelet küld, rendelést rögzít, adatot ír, ügyféllel beszél. Amíg csak szöveget fogalmaz egy ember mellett, a tét kicsi.
Szintén jó időzítés, amikor a cég külső szállítótól vesz ügynököt, és az ajánlatokat össze kell hasonlítani. A hét alrendszer ilyenkor közös mérce, amivel két eltérő felépítésű ajánlat egymás mellé tehető.
Nem éri meg akkor, ha a cégnél még nincs eldöntve, melyik folyamatot akarják az ügynökre bízni. Azzal kell kezdeni, és erre a bevezetési programom való.
Hogyan zajlik
Az első beszélgetés egy óra, ezen eldől, van-e egyáltalán mit átvilágítani. Utána kapok hozzáférést a kódhoz vagy a konfigurációhoz, és a felmérés jellemzően egy hét alatt elkészül. A zárás egy közös átnézés a fejlesztőkkel és a döntéshozóval, ahol a három legfontosabb beavatkozás határidőt és gazdát kap.
Az elszámolás óradíjas, a hatókör és az ár az első beszélgetés után, ajánlatban. Ha a cég kéri, a javasolt korlátokat meg is írom, nem csak leírom.
Gyakori kérdések
Mi az a harness? Minden, ami az ügynökben nem a modell. A ciklus, az eszközök, a kontextuskezelés, a jogosultság, a napló és a bővítési felület. A modellt a szállító adja, ezt a réteget a cég vagy a fejlesztője építi.
Akkor is van értelme, ha a rendszer még nem él? Igen, sőt olcsóbb. A korlátokat és a naplózást a bevezetés előtt beépíteni néhány nap, utólag visszabontani hetek.
Mi kell hozzá a cég oldaláról? Hozzáférés a kódhoz vagy a konfigurációhoz, egy fejlesztő két rövid beszélgetésre, és annak tisztázása, mit vállal az ügynök az ügyfél felé.
Mi a különbség ez és egy biztonsági audit között? A biztonsági audit a rendszer egészét nézi, ez kifejezetten az ügynök működési rétegét. A kettő kiegészíti egymást, és a megfelelési anyagok is erre a nyomra épülnek.