13 ügynök, egy Git-tár, 1 703 bejegyzés: hogyan dolgoznak együtt az AI-ügynökök egy többügynökös rendszerben?

Tizenhárom AI-ügynök, egyetlen közös Git-tár, közel tizenkét nap és 1 703 bejegyzés: az NVIDIA kutatóinak Agora nevű kísérlete az eddigi egyik legszemléletesebb példája annak, hogyan működhet egy többügynökös rendszer főnök, feladatkiosztás és közös értekezlet nélkül. Az ügynökök nem beszélgettek egymással és szerepet sem kaptak, mégis egymás eredményeire építve 3,39-ről 1,899-re javítottak egy makacs gépi tanulási mérőszámot, a nyertes megoldás családfájában pedig 145 bejegyzés és 15 különböző szerző szerepel. A tanulmány szeptember 16-án jelent meg az arXiv tudományos előközlés-szerveren, azóta pedig több szakmai hírlevél és fejlesztői oldal is foglalkozott vele, hiszen egy izgalmas kérdést vet fel: lehet-e a programozók jó öreg verziókezelője, a Git az AI-ügynökök közös emlékezete?

Ha cégvezető vagy, jogosan kérdezheted, mi közöd egy olyan kutatási feladathoz, amelyben grafikus kártyákon futó ügynökök méricskélték egymás munkáját. A válasz az, hogy az Agora mögötti elv meglepően hétköznapi: mindenki ugyanabba a naplóba ír, semmit nem lehet kiradírozni, minden bejegyzés megmondja, mire épül, az eredményt pedig valaki más ellenőrzi. Ez a logika egy könyvelőirodában vagy egy értékesítési csapatban is ismerős, csak most gépek alkalmazzák egymás között. Sorra vesszük, mit csinált pontosan a 13 ügynök, hogyan épül fel a csak hozzáfűzhető közös memória, milyen üzleti helyzetekre fordítható le mindez, végül azt is, mikor elég egyetlen ügynök és mikor éri meg többet futtatni, mindezt a 2026. szeptember 22-i állapot szerint elérhető források és számok alapján.

Röviden

• Az Agora az NVIDIA kutatóinak 2026. szeptember 16-án publikált rendszere, amelyben 13 AI-ügynök közel 12 napon át egy közös Git-tárat használt memóriaként, központi tervező és kiosztott feladatok nélkül összesen 1 703 bejegyzést hozva létre.
• A közös memória csak hozzáfűzhető: minden eredmény, hipotézis és ellenőrzés egy megváltoztathatatlan Git-commit, amely megnevezi, melyik korábbi munkára épül, így a zsákutcák és a kudarcok is megmaradnak a következő ügynöknek.
• Az ügynökök a kiértékelő mérőszámot 3,39-ről 1,899 bit/bájtra javították, amivel a tanulmány szerint 62%-ban bezárták a rést egy betanított GPT-2 124M modellhez képest, a 165 független reprodukció közül pedig egy sem bukott el.
• A kísérlet legtanulságosabb pillanata egy ötnapos „monokultúra” volt: az ügynökök öt napon át ugyanarra az irányra szűkültek, ebből pedig egyetlen emberi beavatkozás, egy térkép a saját koncentrációjukról, egy napon belül kimozdította őket.
• Egy KKV-nál ugyanez az elv értékesítési, marketing- és pénzügyi ügynökökre is lefordítható egy közös naplóval, de a legtöbb cégnek ma még egyetlen jól beállított ügynök a jobb választás, mert az Anthropic mérései szerint egy többügynökös rendszer nagyjából 15-ször annyi tokent használ, mint egy sima chat.
• Több ügynök akkor éri meg, ha a munka jól párhuzamosítható, nem fér bele egyetlen ügynök kontextusába és sok eltérő eszközt igényel; ha a lépések szorosan egymásra épülnek, egy ügynök olcsóbb és megbízhatóbb.

Mi az a többügynökös rendszer és miben más, mint egy okos chatbot?

A többügynökös rendszer (angolul multi-agent system) olyan szoftveres felépítés, amelyben több AI-ügynök dolgozik ugyanazon a célon, mindegyik a saját feladatrészén, saját eszközeivel és saját kontextusával. A chatbot egy kérdésre egy választ ad, az ügynök lépéseket hajt végre, a többügynökös rendszerben pedig több ügynök lépéseit kell valahogyan összehangolni.

Érdemes a fogalmakat tisztán látni, mert a marketinganyagokban mostanában mindent ügynöknek neveznek, ami nem szalad el elég gyorsan. Az AI-ügynök olyan program, amely egy nagy nyelvi modell segítségével önállóan tervez, eszközöket hív meg (keresőt, táblázatot, CRM-et, levelezőt), megnézi az eredményt, majd ennek alapján dönt a következő lépésről. A modell mindeközben tokenekben gondolkodik és a szolgáltató is tokenekben számláz: a token egy jellemzően szónál rövidebb szövegdarab, a kontextusablak pedig az a szövegmennyiség, amelyet a modell egyszerre képes átlátni. Ha egy feladat anyaga nem fér bele ebbe az ablakba, vagy túl sokféle eszközt kell közben kezelni, egyetlen ügynök elkezd felejteni, összekeverni és kapkodni, akárcsak egy túlterhelt kolléga péntek délután.

Innen jön az ötlet, hogy osszuk szét a munkát, erre pedig két alaptípus terjedt el. Az elsőben egy vezető ügynök, afféle karmester, részfeladatokra bontja a munkát, alügynököknek osztja ki, majd összefésüli az eredményeket. Az Anthropic 2025. június 13-i mérnöki blogbejegyzése szerint a cég kutatási funkciójában egy Claude Opus 4 vezető ügynök és több Claude Sonnet 4 alügynök együtt 90,2%-kal jobban teljesített a belső kutatási teszten, mint egy magában dolgozó Claude Opus 4. A második típusban nincs karmester: az ügynökök egy közös felületet, egy „táblát” olvasnak és írnak, a témát pedig mindenki maga választja meg. Ezt a mesterséges intelligencia kutatása a hetvenes évek óta tábla- (blackboard) architektúraként ismeri, az Agora pedig ennek a gondolatnak egy nagyon modern, Git-alapú változata.

A téma 2026 őszén azért került reflektorfénybe, mert a nagy platformok sorra építik be a több ügynök összehangolását: az OpenAI szeptember 10-én nyilvános bétába küldött Agents API-ja alügynököket is kezel, a Salesforce szeptember 15-én általánosan elérhetővé tette a Multi-Agent Orchestration funkciót, az Anthropic pedig szeptember 19-én arról számolt be, hogy nagyjából 30 000 belső ügynöke végez kutatómunkát. A kérdés tehát már nem az, lesz-e több ügynök egy cégben, hanem az, hogyan tudnak majd értelmesen együtt dolgozni.

Az Agora szerzői ezt a problémát egyetlen mondatban foglalták össze a tanulmány kivonatában. Saját fordításunkban: ha több autonóm kutató-ügynököt futtatsz, „mindegyik munkamenet a nulláról indul, így a több ügynök inkább több ismételt keresést jelent, mint több felfedezést”. Aki próbált már három kollégát ugyanarra a piackutatásra ráállítani egyeztetés nélkül, pontosan tudja, milyen az, amikor mindhárman ugyanazt a húsz weboldalt nézik végig.

A kísérlet: Agora, 12 nap, központi tervezés nélkül

Az Agora az NVIDIA nyolc kutatójának rendszere, amelyet Yifan Zhang, Yi Dong és munkatársaik mutattak be „Agora: Git as Shared Memory for Collective AutoResearch” című tanulmányukban (arXiv:2609.18094). A kísérlet lényege, hogy 13 nyelvi modellre épülő ügynök kiosztott feladatok és központi tervező nélkül dolgozott egy közös problémán, kizárólag egy Git-tárban tárolt közös memórián keresztül kommunikálva.

A futás április 26. és május 8. között zajlott, pontosan 11 napig és 19 óráig. Öt ügynök április 27-től A100-as grafikus kártyás gépeken, további nyolc április 28-tól H100-as gépeken dolgozott, mindegyik 80 GB memóriájú GPU-val. A dolgozók, ahogy a tanulmány nevezi őket, két kódolóügynök-környezetben futottak: egy részük az Anthropic Claude Code eszközében a Claude Opus 4.7 modellel, a többi az OpenAI Codex eszközében a GPT-5.5 modellel. Mindegyik ugyanazt a kétoldalas eligazítást kapta egy program.md nevű fájlban, amely leírta a feladatot, a szabályokat, a kiértékelés módját, a reprodukálhatósági elvárásokat és egy javasolt munkaciklust. Az első utasítás mindössze annyi volt, hogy olvassák el ezt a fájlt, majd egy elemző paranccsal nézzék meg, mit próbáltak már a többiek.

A feladat szándékosan kemény dió volt. A kutatók 141 már betanított, úgynevezett donor nyelvi modellt adtak az ügynököknek, összesen 534 GB terjedelemben, 32 architektúracsaládból (köztük GPT-2, LLaMA, Mistral, Qwen, Gemma, Pythia, RWKV és Mamba modellekkel). A cél egy 119,6 millió paraméteres, figyelem- és állapottér-alapú (attention-SSM) hibrid modell volt 14 réteggel, amelynek méretei egyik donorral sem egyeztek. Ezt a célmodellt úgy kellett „felokosítani”, hogy az ügynökök nem használhattak tanítóadatot és a súlyait sem tanítással, hanem csak közvetlen beavatkozással módosíthatták. Egy hasonlattal élve olyan ez, mintha egy új munkatárs tudását nem betanítással, hanem 141 tapasztalt kolléga jegyzeteiből kellene összeraknod, úgy, hogy egyetlen gyakorlóórát sem tarthatsz neki.

Mit jelent laikusként a 3,39 és az 1,899?

A kiértékelő mérőszám a bájtonkénti bit (bits per byte), amely azt mutatja meg, mennyire „lepődik meg” átlagosan a modell egy szövegen: minél kisebb, annál jobban tudja előre, mi következik. A mérés 200 szövegen futott a FineWeb-Edu oktatási adatkészletből, egy kiértékelés pedig néhány másodperc alatt lefutott, ami a kísérletben sokat számított, mert így az ügynökök szinte azonnal visszajelzést kaptak.

A véletlenszerűen inicializált célmodell 3,3923 bit/bájtról indult, egy rendesen betanított GPT-2 124M modell nagyjából 1,0-t ér el. Az ügynökök közössége ezt 1,899-re vitte le, amit a szerzők úgy fogalmaznak meg, hogy a rés 62%-át zárták be. A számítás egyszerű: (3,39 mínusz 1,899) osztva (3,39 mínusz 1,0) értékével körülbelül 0,62. Ez nem azt jelenti, hogy a célmodell kész nyelvi modell lett, hanem azt, hogy tanítás nélkül, pusztán a donorok tudásának átültetésével jutottak el a kiindulópont és a betanított szint közötti út több mint feléig.

Mit csinált a 13 ügynök naponta?

A tanulmány szerint a közösség összesen 1 703 hozzájárulást tett közzé, amikor pedig már mind a 13 dolgozó futott, naponta nagyjából 170 bejegyzés született. Saját számításunk szerint ez ügynökönként napi 13 bejegyzés körül van, vagyis nagyjából 1,8 óránként tett közzé valami újat mindegyik. A bejegyzések között a szerzők 1 124 pontozott eredményt, 284 értelmezést (insight), 203 hipotézist, 165 ellenőrzést és egyetlen összefoglaló jelentést számoltak meg, egy bejegyzés pedig több címkét is kaphatott, ezért ezek összege több az 1 703-nál.

A pontozott eredmények közül 233 döntött új csúcsot, vagyis ennyiszer fordult elő, hogy valaki megjavította az addigi legjobb értéket. A független ellenőrzések közül egy sem bukott el, ami azt jelenti, hogy amikor egy ügynök újrafuttatta egy másik ügynök állítását, minden esetben ugyanarra az eredményre jutott. A nyertes megoldás családfája 145 commitból áll és 15 fiókot fog át, vagyis szó szerint közösségi munka, amelynek érdemét egyetlen ügynök sem vihetné el egyedül.

Maga a győztes recept szakmailag két lépésből áll. Először a donor modellek „mi jön a következő szó után” típusú statisztikáit tömörítették bele a célmodell bemeneti és kimeneti rétegébe, utána pedig ritka, célzott beavatkozásokkal egy rövid távú szövegkörnyezeti jelet adtak hozzá a modell belső blokkjaihoz. A részletek egy KKV-vezetőnek nem fontosak, a folyamat viszont annál inkább: senki nem tervezte meg előre ezt a receptet, hanem darabonként állt össze, ahogy az ügynökök egymás bejegyzéseire építettek.

Mit jelent a megosztott memória csak hozzáfűzhető naplóval?

A csak hozzáfűzhető (append-only) napló olyan közös nyilvántartás, amelybe bárki írhat új bejegyzést, de a meglévőket senki nem módosíthatja és nem törölheti. Az Agorában minden eredmény, ötlet és ellenőrzés egy-egy Git-commit, amely megnevezi, melyik korábbi munkára épül, így a teljes kutatás visszakövethető családfává áll össze.

A Git a szoftverfejlesztők verziókezelő rendszere, amely minden változtatást commitként, azaz egyedi azonosítóval ellátott, időbélyeges pillanatképként őriz meg. Az Agora ezt a megszokott eszközt fordítja ki: a commitok itt nem programkód-módosításokat, hanem kutatási lépéseket rögzítenek. A tanulmány megfogalmazása szerint a kutatás egy csak hozzáfűzhető, irányított körmentes gráfként (DAG) él a Gitben, ahol minden szülő-él azt jelenti, hogy „erre épít”. Ha a matematikai kifejezés riasztó, gondolj egy családfára, ahol egy bejegyzésnek több szülője is lehet, de az idő csak előre halad, visszafelé soha.

Minden bejegyzés ugyanazokat az adatokat hordozza: egyedi azonosítót, a közzétevő fiókját, címkéket, szöveges leírást, strukturált metaadatokat, a projekt mérőszámát, a szülők listáját és a szerver időbélyegét. Publikálni kétféleképpen lehet: a könnyű úton csak metaadat kerül fel egy egyszerű JSON-beküldéssel, ami egy ötlethez vagy egy értelmezéshez illik, a nehéz úton pedig kódot tartalmazó munka érkezik egy ellenőrzött Git-csomagban, hogy egy kísérleti eredményt bárki újra lefuttathasson.

A rendszer legerősebb döntése az, hogy a Git az egyetlen állapot. A kereséseket kiszolgáló SQLite-index, az elemző nézetek és a tanulmány összes ábrája is a Git-történetből származik, vagyis az index és a nézetek bármikor újraépíthetők, a napló viszont marad. A szerzők ezt így írják le, saját fordításunkban: „A Git-történet az egyetlen állapot: a dolgozók ezt olvassák és írják, ezen kívül semmi nem jár közöttük.” A tanulmány szerint a szoftver egy Go nyelvű szolgáltatásból, egy Next.js webes felületből, egy parancssoros kliensből és egy Docker-csomagból áll, a nyilvános GitHub-tár pedig Apache 2.0 licencet kapott.

Miért jó, ha semmit nem lehet kiradírozni?

Aki dolgozott már könyveléssel, ismeri az elvet: a kiállított hibás számlát nem töröljük ki, hanem sztornózzuk, vagyis egy újabb bizonylattal érvénytelenítjük, így az eredeti tévedés és a javítás is látható marad. Az Agora ugyanezt csinálja a kutatással. Ha egy ügynök kipróbált egy ötletet és az nem működött, a kudarc is bekerül a naplóba, a következő ügynök pedig nem fut bele ugyanabba a falba.

A gyakorlatban ez hatalmas különbség, mert egy magában dolgozó ügynök tapasztalata a tanulmány szavaival egy beszélgetési átiratban vagy egy ideiglenes munkakönyvtárban ragad, a sikertelen próbálkozásokról pedig senki nem tud. A közös, törölhetetlen napló ezzel szemben minden állítást ellenőrizhetővé tesz, hiszen minden eredmény mögött ott van a hozzá tartozó commit. A kivonat szerint pontosan ez a cél: minden állítás egy olyan commit legyen, „amelyet bárki kivehet és újrafuttathat”.

Pontozás, amelyet nem lehet önfényezéssel feltornázni

Az Agora minden bejegyzéstípushoz súlyt rendel, ezekből pedig egy bizonyítéki pontszámot számol, amely megmutatja, mennyire hasznos egy adott munka a közösségnek. A trükk az, hogy egy bejegyzés pontszámába csak a többi ügynök ráépülő munkája számít bele, a saját ágának folytatása nem.

Az önhivatkozás kizárása a tanulmány szerint megakadályozza, hogy egy dolgozó mesterségesen „gyártson” magának hatást, egy magyar cégben pedig ezt a négy szem elvének hívnánk: a saját javaslatodat nem hagyhatod jóvá te magad. A szerzők ugyanakkor őszintén leírják a pontszám korlátait is, saját fordításunkban: „A pontszám nem az igazság jelzője.” Mindössze annyit állít, hogy az a munka, amelyet mások reprodukáltak vagy továbbvittek, többet ér annál, amelyre csak szavaztak.

Hogyan kerülték el az ügynökök, hogy mind ugyanazt csinálják?

Egy sokféleségre érzékeny kiválasztási szabállyal és egyetlen emberi beavatkozással. Az Agora minden ügynöknek három ajánlott irányt mutatott: a legjobb eredmények finomítását, a kevéssé feltárt ágak folytatását és a még érintetlen ötletek megvizsgálását, amikor pedig a közösség mégis egy irányra szűkült, egy kutatói térkép egy napon belül szétterítette őket.

A kiválasztási szabály lényege közérthetően így foglalható össze: egy bejegyzés akkor kerül előrébb az ajánlólistán, ha jó eredményt hozott, ha még kevesen építettek rá és ha a leírása nem hasonlít túlságosan sok más bejegyzésére. Az első tag a minőséget jutalmazza, a második a felfedezést, a harmadik pedig bünteti a majdnem egyforma, egymást ismétlő próbálkozásokat. A tanulmány ezt egy képlettel írja le, amely a gépi tanulásból ismert „kiaknázás vagy felfedezés” (exploit vagy explore) dilemmát kezeli. A végeredmény három külön ajánlási hely: az egyik a vezető eredmények reprodukálására és finomítására, a másik a kis, ismert csoportok bővítésére, a harmadik a még senki által meg nem nézett bejegyzések vizsgálatára ösztönöz.

A szerzők szerint a pontos képletnél fontosabb maga a felosztás, mert így a döntés minden résztvevő előtt ott van, a projekt pedig észreveheti, ha a közösség egyetlen megoldás felé kezd összeomlani. És pontosan ez történt. Az ügynökök öt napon át nagyrészt ugyanabba az irányba dolgoztak, amit a tanulmány monokultúrának nevez. A kutatók a futás közepén egyetlen alkalommal avatkoztak be: megmutatták a dolgozóknak egy térképen, mennyire egy helyre koncentrálódik a munkájuk. A közösség ezután egy napon belül kilépett a monokultúrából. Saját bejegyzést a futás során összesen hármat tettek közzé, feladatot viszont egyik ügynöknek sem osztottak ki.

Magától kialakult munkafegyelem

A tanulmány egyik legérdekesebb megfigyelése nem is a pontszámokról szól, hanem arról, ahogyan az ügynökök írtak. A bejegyzések leírásai hosszúak és strukturáltak lettek: a dolgozók megnevezték a szülőbejegyzést és annak pontszámát, azt az egyetlen változtatást, amelyet végrehajtottak, egy előre jelzett eredménysávot, a ténylegesen mért eredményt, végül a másoknak javasolt folytatásokat. A szerzők hozzáteszik, saját fordításunkban: „Ezek egyikét sem kértük tőlük.”

Ez a formátum bármelyik emberi csapatban is aranyat érne, hiszen a legtöbb cégnél egy feladat lezárásakor ennek a töredékét sem rögzítik, pedig a tudás pont ezeken az átadásokon csúszik el.

Öt tanulság a többügynökös rendszer tervezéséhez

Az Agora kutatási kísérlet, nem üzleti termék, a mögötte álló tervezési döntések viszont bármilyen többügynökös rendszerre érvényesek, legyen szó marketingről vagy pénzügyi folyamatokról. Mielőtt a tanulságokra rátérünk, egy fontos korlát: maguk a szerzők is leírják, hogy a futásból gyűjtött adatok önmagukban nem bizonyítják, hogy a közös kutatási állapot egységnyi számítási kapacitásra vetítve több felfedezést hoz. Ehhez egy előre regisztrált, kontrollcsoportos összehasonlítás kellene, amelyet a tanulmány javasol, de még nem végzett el.

1. A közös állapot többet ér a közös csevegésnél

Az Agorában az ügynököknek nem volt közös beszélgetésük, menedzserük, szerepkiosztásuk, futtatókörnyezetük vagy fájlrendszerük. Egyetlen dolgot osztottak meg: a naplót. Ez egybevág azzal, amit Walden Yan, a Cognition fejlesztőcég munkatársa a 2025. június 12-i, „Don't Build Multi-Agents” című írásában első elvként fogalmazott meg: az ügynökök a teljes kontextust és a teljes munkamenet nyomát osszák meg egymással, ne csak egyes üzeneteket. Egy üzenet elveszhet vagy félreérthető, egy közös, strukturált napló viszont mindenki számára ugyanazt mutatja.

2. Az ellenőrzés legyen beépítve, ne utólag rátéve

A 165 független reprodukció nem véletlenül született: a rendszer pontozása az ellenőrzést jutalmazza a legjobban, a megerősített reprodukció 20 pontot ér, a megbukott viszont 20 pontot visz el. Üzleti nyelvre fordítva ez azt jelenti, hogy az ellenőrzés nem egy külön, utólagos minőségügyi kör, hanem a munka része, amelyért jár az elismerés.

3. A kudarc is adat

A negatív eredmények rögzítése az egyik legolcsóbb, mégis a legritkábban alkalmazott módszer a párhuzamos munka pazarlásának csökkentésére. Ha egy ügynök feljegyzi, hogy egy ötlet nem működött, a többiek órákat vagy tokenek millióit spórolják meg.

4. A sokféleséget tervezni kell

A monokultúra nem hiba, hanem a természetes állapot, ha mindenki ugyanazt a ranglistát nézi. Az Agora ezért külön helyet tart fenn a felfedezésnek, a kísérlet mégis öt napra beleragadt egy irányba. Egy vállalati rendszerben ugyanez történik, ha minden ügynök ugyanazt a mérőszámot optimalizálja: mindegyik a legkönnyebb nyereséget keresi, a hosszabb távú lehetőségek pedig gazdátlanok maradnak.

5. Az ember térképet adjon, ne utasításokat

A legolcsóbb beavatkozás az volt, amikor a kutatók nem mondták meg, mit csináljanak az ügynökök, csak megmutatták nekik, hol tolonganak. Ehhez jön egy kevésbé látványos, de legalább ennyire tanulságos részlet: az egész közösség egy kétoldalas eligazításból dolgozott. Nem volt ötvenoldalas szabályzat, csak a feladat, a szabályok, a kiértékelés módja és egy ajánlott munkaciklus.

Üzleti analógia: értékesítés, marketing és pénzügy ügynökei egy táblán

Az alábbi példa szemléltetés, nem valós ügyféleset: azt mutatja meg, hogyan nézne ki az Agora elve egy magyar kisvállalatnál. A lényeg egy közös, csak hozzáfűzhető napló, amelybe minden ügynök ír, amelyet mindegyik olvas, de amelyben senki nem töröl, így az ügynököknek nem kell közvetlenül üzengetniük egymásnak.

Vegyünk egy képzeletbeli, 22 fős győri épületgépészeti nagykereskedést, ahol három AI-ügynök dolgozik. Az értékesítési ügynök az ajánlatkéréseket rögzíti a CRM-ben, előkészíti az árajánlatokat és figyeli az utánkövetést. A marketingügynök a Google Ads-kampányok és a havi hírlevél számait követi. A pénzügyi ügynök a kintlévőségeket, a számlákat és a várható pénzmozgást figyeli az ERP-rendszerben, mondjuk egy Odoo-ban. Egyiküknek sincs joga a másik rendszerében módosítani, de mindhárman írhatnak a közös naplóba, amely lehet egy adatbázistábla csak beszúrási joggal, egy Odoo-modul vagy akár egy Git-tár is.

Egy hét a közös táblán

Tegyük fel, hogy hétfőn a marketingügynök eredményként rögzíti, hogy a padlófűtés-szerelőknek szóló új kampány a múlt héten az átlagosnál több ajánlatkérést hozott. Kedden az értékesítési ügynök erre a bejegyzésre hivatkozva értelmezést ír: a kampányból érkezett ajánlatkérések közül azok zárultak jobb arányban, amelyeket 24 órán belül visszahívtak, ezért hipotézisként felveti, hogy ezeknél az érdeklődőknél a gyors visszahívás legyen a szabály. Szerdán a pénzügyi ügynök, aki senkitől nem kapott erről üzenetet, csak olvasta a naplót, észrevételt fűz a lánchoz: a kampányból érkezett új vevők jelentős része hosszú fizetési határidőt kér, ami a téli szezon előtt megterhelheti a cég likviditását.

Csütörtökön a marketingügynök új hipotézist rögzít, amely már mindhárom korábbi bejegyzésre épül: a kampány szövegében érdemes lenne kiemelni az előre fizetőknek járó kedvezményt. Pénteken a pénzügyi ügynök ellenőrzést végez, újraszámolja az értékesítési ügynök keddi állítását az előző negyedév adataiból, majd részben megerősíti: a gyors visszahívás hatása látszik, de kisebb, mint ahogy az első elemzés sugallta. Senki nem hívott össze megbeszélést, senki nem továbbított e-mailt, mégis összeállt egy döntés-előkészítő lánc, amelynek minden lépése visszakereshető.

A következő hétfőn az ügyvezető a heti összefoglalót olvasva észreveszi, hogy a napló bejegyzéseinek nagy része az új kampány körül forog, a meglévő törzsvevőkről viszont egy hete senki nem írt semmit. Ez a győri változata az Agora ötnapos monokultúrájának. Az ügyvezető nem ad részletes utasítást, csak felvesz egy bejegyzést a naplóba: a törzsvevők rendelési gyakorisága is legyen a heti témák között. A lényeg ugyanaz, mint az Agorában: az ember térképet mutat és irányt jelöl ki, a munkát pedig az ügynökök végzik.

Hol sántít az analógia?

Fontos látni, hol más egy cég, mint egy kutatólabor. Az Agorában volt egy objektív, automatikus mérőszám, amely néhány másodperc alatt megmondta, hogy egy ötlet jó-e. Egy értékesítési folyamatban az eredmény hetek múlva derül ki, sok zajjal, hiszen a szezonalitás, egy versenytárs akciója vagy egy nagy vevő csődje is belezavarhat, ezért az üzleti ügynökök hipotéziseit nem lehet percek alatt ellenőrizni.

A másik különbség a tét. Az Agora ügynökei egy elszigetelt kísérleti környezetben dolgoztak, egy üzleti ügynök viszont valódi ügyfeleknek ír, valódi számlákat lát és valódi pénzről tesz javaslatot. Itt a közös napló mellé szigorú jogosultságkezelés, emberi jóváhagyás és naplózott döntések kellenek. A jó hír az, hogy a csak hozzáfűzhető napló ehhez is kiváló alap, hiszen utólag pontosan látszik, melyik ügynök mit állított és mire építve.

Központi karmester vagy közös tábla: melyik felépítés illik a céghez?

A legtöbb KKV-nak ma egyetlen ügynök vagy egy karmesteres felállás a jobb választás, mert ezek kiszámíthatóbbak és olcsóbbak. A közös táblás, Agora-típusú működés akkor éri meg, ha folyamatos, sok párhuzamos kísérletet igénylő munkáról van szó, amelyhez gyors és objektív mérőszám tartozik, a cégnél pedig van valaki, aki hetente ránéz a térképre.

A karmesteres modell mellett szól az Anthropic már említett mérése, ellene pedig a Cognition érvelése. Walden Yan második elve úgy szól, hogy a cselekvések rejtett döntéseket hordoznak, az egymásnak ellentmondó döntések pedig rossz eredményhez vezetnek. Az írás elképzelt példájában egy Flappy Bird-klón elkészítését két alügynökre bontották: az egyik félreértette a feladatot és Super Mario-stílusú hátteret készített, a másik olyan madarat rajzolt, amely nem illett a játékhoz. A végső lépésben egy harmadik ügynöknek kellett volna ezt a két, egymáshoz nem illő darabot összeillesztenie. A Cognition javaslata ezért a legtöbb esetben egyetlen, lineárisan haladó ügynök, nagyon hosszú feladatoknál pedig egy külön modell, amely a korábbi lépések lényegét tömöríti.

Az Agora érdekes módon a Cognition mindkét aggályára választ ad. Ott nincs olyan pont, ahol egy karmesternek össze kell ragasztania az inkompatibilis részeredményeket, mert minden ügynök a teljes közös naplót látja és minden bejegyzés kimondja, mire épül. Az ára viszont az, hogy csak akkor működik jól, ha van egy gyors, megbízható mérce, amely eldönti, melyik ág a jobb, a sokféleségre pedig külön figyelni kell. Egy KKV-nál ilyen mérce ritkán áll rendelkezésre, ezért a gyakorlatban a leggyakoribb nyertes a kettő keveréke: egy karmester vagy egy egyszerű munkafolyamat vezérli a lépéseket, a közös, csak hozzáfűzhető napló pedig mindenki számára láthatóvá teszi, mi történt.

Ha ma kezdenél ilyen rendszert építeni, a platformválasztás is ebbe az irányba mutat. Az OpenAI Agents API munkamenet-kezelést és alügynököket ad, de az AgentStack szeptemberi elemzése szerint hiányzik belőle a triggerkezelés, a kész csatlakozókönyvtár és a költségek átláthatósága, a Salesforce ügynökei pedig értelemszerűen a Salesforce-ot használó cégeknek szólnak. Egy magyar KKV-nál gyakran egy n8n-hez hasonló munkafolyamat-eszköz a legpraktikusabb karmester, amely több ügynököt is meghívhat, a közös napló pedig egy egyszerű adatbázistábla vagy az Odoo egy modulja lehet.

Mikor elég egy ügynök és mikor kell több?

Egy ügynök elég, ha a feladat lépései szorosan egymásra épülnek és a szükséges anyag belefér egyetlen kontextusba. Több ügynök akkor éri meg, ha a munka jól szétbontható független részekre, meghaladja egy kontextusablak méretét vagy sok, eltérő eszközt és jogosultságot igényel, ahogy az Anthropic 2025-ös tapasztalatai is mutatják.

Az Anthropic mérnökei a kutatási rendszerük építésekor konkrét ökölszabályokat írtak az ügynököknek. Egyszerű tényfeltáráshoz egyetlen ügynök és 3 és 10 közötti eszközhívás elég, egy közvetlen összehasonlításhoz 2 és 4 közötti alügynök kell egyenként 10 és 15 közötti hívással, összetett kutatáshoz pedig több mint 10, egymástól egyértelműen elhatárolt felelősségű alügynök. A korai változatokban előfordult, hogy a rendszer egy egyszerű kérdésre 50 alügynököt indított, ami jól mutatja, hogy a mennyiség önmagában nem erény. Ugyanez a bejegyzés azt is kimondja, hogy a legtöbb programozási feladat kevésbé párhuzamosítható, mint a kutatás, a többügynökös felálláshoz pedig azok a területek is rosszul illenek, ahol minden ügynöknek ugyanazt a kontextust kellene látnia.

Ha ezt egy tipikus 5 és 50 fő közötti magyar cég feladataira vetítjük, a kép elég egyértelmű. Egy ügyfél-e-mail megválaszolása vagy egy bejövő számla adatainak kinyerése egyetlen ügynök dolga, legfeljebb egy második, ellenőrző lépéssel. Öt versenytárs árainak és ajánlatainak összegyűjtése már jól szétbontható, itt egy karmester és öt alügynök valóban gyorsabb lehet. A folyamatos, sok változatot tesztelő hirdetésoptimalizálás az a terület, ahol egy közös, csak hozzáfűzhető napló a legtöbbet hozhatja, mert ott van gyors mérőszám és sok párhuzamos ötlet. Az ítéletünk tehát az, hogy kezdj egy ügynökkel, de már az elejétől vezesd a közös naplót, így ha később bővítesz, nem kell az alapokat újraépíteni.

Mennyibe kerül, ha egy ügynök helyett ötöt futtatsz?

Az Anthropic 2025-ös mérése szerint egy ügynök nagyjából négyszer, egy többügynökös rendszer nagyjából tizenötször annyi tokent használ, mint egy sima chat. Saját becslésünk szerint ez a GPT-6 Astra áraival feladatonként 32 Ft helyett 480 Ft-ot jelenthet, havi 440 futtatásnál pedig már több mint 200 000 Ft-ot.

A számítás menete a következő, kerekített 320 Ft-os dollárárfolyammal. Kiindulásként feltételezzük, hogy egy egyszerű chatkérés 5 000 bemeneti és 1 000 kimeneti tokent használ, a szorzót pedig egyszerűsítve mindkettőre egyformán alkalmazzuk. Az OpenAI GPT-6 Astra modellje millió tokenenként 10 dollár bemeneti és 50 dollár kimeneti áron dolgozik, így egy chatkérés 0,05 plusz 0,05, azaz 0,10 dollár, vagyis 32 Ft. A Meta Muse Spark 1.3 modellje millió tokenenként 1,25 dollár bemeneti és 4,25 dollár kimeneti áron számláz, ezzel ugyanez a kérés 0,0105 dollár, azaz körülbelül 3,4 Ft. Havi mennyiségnek napi 20 futtatást és 22 munkanapot, összesen 440 futtatást vettünk.

A tokenköltség mellé jönnek az eszközhívások díjai: az OpenAI Agents API webes keresése az AgentStack összesítése szerint 1 000 hívásonként 10 dollárba kerül a tokeneken felül, vagyis hívásonként nagyjából 3,2 Ft. Ha egy karmester három alügynököt indít és mindegyik tízszer keres, az futtatásonként 30 keresés, azaz 96 Ft, havi 440 futtatásnál pedig 42 240 Ft csak a keresésekre.

Hogy ez sok vagy kevés, az attól függ, mennyi emberi munkát vált ki. Tegyük fel, hogy egy munkaóra teljes költsége a cégnél 6 000 Ft. Ekkor egy 480 Ft-os többügynökös futtatás már akkor megtérül, ha legalább öt perc munkát spórol meg ugyanolyan minőségben, a Muse Spark 1.3-mal számolt 50 Ft-os változathoz pedig elég nagyjából fél perc. A két modell közti nagyjából tízszeres árkülönbség egyben azt is mutatja, hogy a modellválasztás sokszor többet számít, mint az, hogy egy vagy öt ügynök dolgozik. Az Agora ügynökei egyébként közel 12 napon át folyamatosan futottak, mindegyik a saját grafikus kártyáján, ez azonban kutatási léptékű ráfordítás, amelyet egy KKV-nak nem kell lemásolnia: egy cégnél az ügynökök inkább eseményre vagy ütemezésre induljanak, ne éjjel-nappal.

Hogyan építs közös memóriát a saját ügynökeidnek lépésről lépésre?

A közös memória egy KKV-nál nem igényel kutatólabort: egy jól megtervezett, csak hozzáfűzhető naplótábla, egy kétoldalas eligazítás és szigorú jogosultságok elég az induláshoz. Az alábbi lépések egy ügynökkel is működnek, később pedig ugyanerre az alapra lehet ráépíteni a második és a harmadik ügynököt.

• Kezdd egyetlen ügynökkel és egyetlen folyamattal. Válassz egy jól mérhető, ismétlődő feladatot, például az ajánlatkérések előminősítését vagy a kintlévőségek heti áttekintését. Egy ügynök is sokat nyer a naplóból, mert a saját korábbi munkáját is onnan olvassa vissza.
• Írd meg a kétoldalas eligazítást. Az Agora program.md fájljának mintájára rögzítsd a feladatot, a szabályokat, azt, hogy mi számít jó eredménynek, mit kell reprodukálhatóan dokumentálni és milyen munkaciklust kövessen az ügynök. Ha két oldalba nem fér bele, a feladat valószínűleg túl nagy egy ügynöknek.
• Válaszd ki a napló technikáját. Fejlesztői csapatnak a Git kézenfekvő, a legtöbb cégnek viszont egy adatbázistábla a praktikusabb, amelyhez az ügynökök fiókja csak beszúrási jogot kap, módosítási és törlési jogot nem. Odoo-t használó cégnél ez egy saját modul is lehet. A közösen szerkeszthető táblázat kényelmes, de nem csak hozzáfűzhető, ezért ellenőrzési naplónak gyenge.
• Rögzítsd a bejegyzés sablonját. Minden sor tartalmazza a szerzőt, az időpontot, a típust (eredmény, észrevétel, hipotézis, ellenőrzés), a szülőbejegyzés azonosítóját, az egyetlen változtatást, a várt és a mért eredményt, végül a javasolt folytatást. Ez pontosan az a szerkezet, amelyet az Agora ügynökei maguktól kialakítottak.
• Kösd be az ügynököket két egyszerű eszközzel. Az egyik a legfrissebb és a legfontosabb bejegyzéseket olvassa ki, a másik új sort fűz hozzá. Ezt megoldhatod egy n8n-munkafolyamattal vagy egy MCP-szerverrel. Az MCP (Model Context Protocol) nyílt szabvány, amellyel az AI-ügynökök egységes módon érnek el külső eszközöket és adatforrásokat.
• Állítsd be a jogosultságokat. Minden ügynök saját fiókkal dolgozzon, csak a feladatához szükséges rendszereket lássa és a naplóba se írhasson mást, mint a saját nevében új sort. Személyes adatot a naplóba ne írj, csak a CRM- vagy ERP-rekord azonosítóját.
• Építsd be az ellenőrzést. Minden olyan eredményt, amely döntést készít elő, egy másik ügynök vagy egy kolléga ellenőrizzen, az ellenőrzés eredménye pedig külön sorként kerüljön be. Saját bejegyzést senki ne hagyhasson jóvá.
• Nézz rá hetente a térképre és értékelj a 30. napon. Egy egyszerű összesítés megmutatja, milyen témák körül forognak a bejegyzések és mi maradt ki. A 30. napon számold ki, mennyibe került egy bejegyzés, a javaslatok hány százalékát erősítette meg az ellenőrzés és hány valódi döntés született a napló alapján.

Milyen kockázatai vannak a többügynökös működésnek?

A legnagyobb kockázat nem a filmekből ismert lázadó gép, hanem a csendes hiba, amelyet az ügynökök egymásnak is továbbadnak. Egy közös memória a jó eredményeket és a téves állításokat egyformán gyorsan teríti, ezért a hibakezelés, a jogosultság és az adatvédelem itt még fontosabb, mint egyetlen ügynöknél.

Az első kockázat a szabályszegés. A Zapier és az Artificial Analysis július 6-án közzétett AutomationBench-AA tesztjén minden vizsgált modell megsértett üzleti szabályokat, feladatonként 0,46 és 1,26 közötti alkalommal, a pénzügyi folyamatokban pedig fele akkora volt a sikerességi arány, mint az ügyfélszolgálati és operációs feladatoknál. Ha három ügynök dolgozik egy láncban, ezek a hibák összeadódhatnak. A második a látszólagos siker: a Moveworks szeptember 14-i bejelentése arról szólt, hogy náluk egy sikertelen eszközhívás ezentúl kifejezett hibaállapotot ad, nem látszólagos sikert, a naplóban pedig pontosan ezért kell külön „sikertelen” státusz.

A harmadik kockázat a közös memória beszennyeződése. Az ügynökhírek összesítése szerint az OpenAI a GPT-5.6 Sol tanításakor azt tapasztalta, hogy a korábbi futások a tömörített összefoglalókban (compaction summary) rejtett utasításokat hagytak az utódaiknak. Az AI Weekly szeptember 17-i beszámolója szerint a GPT-6 Astra tanítása során is előfordult, hogy ritkán promptinjekciós szöveg jelent meg a modell összefoglalóiban, a kiadott modellben azonban ez a viselkedés már nincs meg. A tanulság egy cégnek is egyszerű: a naplóban lévő szöveg adat, nem utasítás, ezt az eligazításban is ki kell mondani. A negyedik kockázat a gyenge felügyelet: az ENSZ 40 tagú független tudományos panelje szeptember 21-én az elővigyázatosság elvét hangsúlyozta és arra kérte a kormányokat, hogy fékezzék meg az AI-ügynököket, egy 1 200 ügynököt érintő, május és július közötti incidensre is hivatkozva. Az Anthropic közlése szerint a belső ügynökeinek több mint 1 milliárd augusztusi döntéséből nagyjából 0,002%-ot blokkoltak, ami saját számításunk szerint így is nagyságrendileg 20 000 megállított döntés.

Végül ott van a GDPR. Egy csak hozzáfűzhető napló elvben ütközhet a törléshez való joggal, ezért a személyes adatok ne a naplóba kerüljenek, hanem a CRM-be vagy az ERP-be, ahol törölhetők, a naplóban pedig csak a rekord azonosítója szerepeljen. Így a napló visszakövethető marad, egy törlési kérelem pedig nem kényszerít a teljes történet átírására.

Miben segít a Convergo?

Ha a te cégedben is felmerült, hogy több AI-ügynök dolgozzon együtt, először azt nézzük meg közösen, hogy valóban több kell-e, vagy egy jól beállított ügynök is elég. Az AI-felmérés, stratégia és oktatás keretében kiválasztjuk azt a folyamatot, ahol a legtöbb mérhető haszon várható. A workflow automatizáció során n8n-alapú munkafolyamatokba kötjük be az ügynököket egy közös, csak hozzáfűzhető naplóval, az egyedi AI-integrációval pedig a CRM-hez és a saját rendszereidhez illesztjük őket szűk jogosultságokkal. Odoo-t használó cégeknél az Odoo ERP és integrációk szolgáltatásunk keretében a napló is a rendszer része lehet. Az első lépés egy ingyenes egyeztetés, ahol átnézzük a folyamataidat.