A legtöbb agent-demó elvérzik egy valódi kódbázisban — mutatom, mi éli túl
A demó annyi, hogy az agent megválaszol egy kérdést. Az éles rendszer a gateway, a pipeline és az auth-szolgáltatás, amire senki nem számított — és ezen múlik, hogy egy AI-funkció életben marad-e.
Sok agent-demót láttam már. A legtöbbjük tényleg jó: egy chat-ablak, néhány tool-hívás, egy tiszta válasz, ami elsőre ül. A demóra emlékszik mindenki. Csakhogy ez a könnyű rész.
A nehéz rész ott kezdődik, amikor a dolgot be kell tenni egy valódi cég rendszereibe. Nem azért, mert a modell rosszabb lesz, hanem mert a demó egy olyan világban fut, amit teljes egészében te irányítasz — az éles környezet pedig nem ilyen. Íme három fal, aminek egy friss agent-projekt nekiment, mire élesbe került. Egyik sem az agentről szólt — mégis mindhárom azon döntött, hogy lesz-e belőle bármi.
Nem érte el az adatot
A demóban minden egy helyen volt: az agent, az adat, amit lekérdezett, a hozzáférések — egyetlen gépen, egymás mellett.
Az éles környezet ezt széthúzta. Az agent egy internetre néző szerveren futott. Az adat, ami kellett neki, egy belső API mögött élt, amely — szándékosan — nem fogad hívást a publikus internetről. Így amikor az agent először próbálta megcsinálni azt az egyetlen dolgot, amit a demó triviálisnak mutatott, nem kapott vissza semmit. A modellel nem volt semmi baj. Egyszerűen nem vezetett út az információhoz.
A megoldás nem egy jobb prompt volt, hanem egy API gateway: felállítani és úgy konfigurálni, hogy biztonságosan kösse össze a két hálózatot — hitelesítse az agent kéréseit, csak azt a néhány végpontot engedje, amihez tényleg hozzáférhet, és minden mást utasítson el. Ez infrastruktúra-munka, és egyetlen demó sem mutatja meg. Hagyd ki, és marad egy nagyon ékesszóló program, ami nem lát semmit.
Mivel ezt felállítani valódi munka, nem tartottuk meg magunknak: regisztráltunk a gateway-en egy közös szervezetet, amin más csapatok is átvihetik a saját szolgáltatásaikat, és dokumentáltuk a connectort, hogy a következő csapatnak, amelyiknek ugyanezek a belső rendszerek kellenek, ne kelljen mindezt újra kitalálnia.
Egyszer leszállítani nem leszállítás
Az első deploy kézzel ment. Ez pontosan egyszer működik. A harmadik változtatásnál már kimarad egy lépés, rossz config megy ki, vagy olyasmi kerül élesbe, amit senki nem tud reprodukálni — és onnantól a deployt debuggolod a funkció helyett. Az agentnek minden alkalommal ugyanúgy kellett kikerülnie élesbe.
A cégnél pontosan erre volt már pipeline, egy másik csapat építette. Ennek könnyű menetnek kellett volna lennie — nem az volt. Az eszközt nehéz volt használni és alig volt dokumentálva, úgyhogy ráállítani az agentünket azt jelentette, hogy megkerestük az építőit, és kiszedtük a fejükből a tudást, mert leírva szinte semmi nem volt. A deploy automatizálása végül kevésbé szólt pipeline-okról, mint régészetről.
Az ilyen munka — beilleszkedni abba a félig dokumentált platformba, amin a cég többi része már fut — sosem látszik egy demóban. Pedig egy valódi szervezetben nagyrészt ezt jelenti az, hogy „deployold az agentet”.
A felületnek tudnia kellett, ki kérdez
Az utolsó fal akkor jött, amikor egy chat-komponens bekerült egy alkalmazás felületébe. Egy doboz a képernyőn — az egész projekt legdemószerűbb darabja. Csakhogy egy valódi felület előtt valódi felhasználók ülnek, és a mögötte lévő agent nem válaszolhat akárkinek, aki beleír. Tudnia kell, ki kérdez, és hogy kérdezhet-e egyáltalán.
Ez azt jelentette, hogy a chat-komponensnek hitelesítenie kellett magát az agent felé, az agentnek pedig meg kellett bíznia ebben a hitelesítésben. Nem egyszer drótoztuk be, hogy aztán továbblépjünk: építettünk egy kis auth-szolgáltatást, ami ezt tisztán kezeli — és úgy, hogy a többi csapat, amelyik a saját felületét köti ugyanerre az agentre, újrahasználhassa, ne újra feltalálja. Ugyanaz a történet, mint a gateway-nél: a modell nem változott, a körülötte lévő rendszer nőtt.
Az agent volt a könnyű rész
Nézd meg a három falat egyben. Egy hálózati gateway, megosztva, hogy más csapatok is használhassák. Egy belső deploy-pipeline, amit vissza kellett fejteni, hogy használni tudjuk. Egy újrahasználható auth-szolgáltatás. Egyik sem „AI-munka”. Hétköznapi full-stack rendszermunka: hálózat, deploy, identitás. Pontosan az a fajta, amit a demó direkt elrejt — mert a demó dolga megmutatni azt a 20%-ot, ami látványos, és kihagyni azt a 80%-ot, ami a terhet viszi.
Ezért nem lesz semmi a sok lenyűgöző agent-demóból. A demó azt bizonyítja, hogy a modell képes a feladatra. Arról nem mond semmit, hogy a feladat túlél-e egy hálózati határt, egy második deployt vagy egy valódi felhasználót. Azok a funkciók jutnak el élesig, amelyeknél valaki az agentet egy nagyobb rendszer egyik komponenseként kezelte, és elvégezte a hálátlan munkát, hogy a helyére illessze.
Ha ilyet építesz: az agent-funkciót azon mérd, mekkora területet érint a rendszered többi részéből, ne azon, milyen szépen futott a demó. A demó egy hipotézis. Minden, ami körülötte van, a kísérlet, ami eldönti, hogy a hipotézis megáll-e.
És ha embert keresel AI-funkciók szállítására: ez a tényleges munka. A promptot bárki lemásolja. Az, aki az unalmas réteget is meg tudja építeni köré — ráadásul úgy, hogy a következő csapatnak már ne kelljen —, az az ember, akinek a munkája egy év múlva is futni fog.