Szeptember 10-én az OpenAI nyilvános betában kiadta az Agents API-t, és ezzel ajánlatot tett minden csapatnak, amely eddig maga tartotta fenn az agentek körüli gépezetet: a session-kezelést, a kontextus tömörítését, a hibák utáni helyreállítást és a subagentek koordinálását. A legtöbb magyar és közép-európai fejlesztőcsapatnál a helyes lépés egy szűk, mérhető összehasonlító pilot, mert a tesztelés csak a felhasznált tokeneket viszi, a migráció viszont az egész agent-architektúrát érinti. Aki még nem üzemeltet éles agentet, annak a beta alatt más a feladata.
Mit vesz át az OpenAI, és mi marad a csapatnál
Az Agents API bejelentése szerint egy production agent egyetlen API-hívással létrehozható: a fejlesztő megadja a feladatot, a modellt (a példakódban a gpt-6-astra), az eszközöket és a végrehajtási környezetet. A fejlesztői changelog ugyanezt a napot rögzíti, és pontosan megnevezi, mi kerül a szolgáltató oldalára: a session-orchesztráció, a kontextus tömörítése és a helyreállítás. A dokumentáció szerint a rendszer automatikusan tömöríti a korábbi kontextust, amikor a session a kontextusablak határához közelít, így a több kontextusablakon átívelő munkafolyamathoz nem kell saját tömörítő logikát írni.
A multi-agent támogatás a feladatot független részekre vágja, és subagentekre osztja. Minden subagent a saját kontextusát viszi, a fő agent koordinál, a párhuzamosság pedig beállítható; a bejelentés példájában legfeljebb három egyidejű subagent fut. Az OpenAI szerint a harness verziózottan követi a modellkiadásokat, vagyis a modellváltásnál nem a hívó csapatnak kell újraírnia a scaffoldingot.
Ami a csapatnál marad, az továbbra is a nehezebb rész: az eszközök, a belső tudás, a jogosultságok, a kivételkezelés és az eval-készlet. Erről a munkáról a multi-agent rendszerek éles tapasztalatait összefoglaló cikkünkben részletesen írtunk, és ezen a frissítés nem változtat.
A harness a szállítói kötődés, a sandbox az adatkérdés
Egy közép-európai vásárlónak érdemes két döntésre szétszedni a bejelentést. A harness az a felület, amelyre a kód ráépül, tehát ott keletkezik szállítói kötődés. A végrehajtási környezet ettől független: az agent futhat OpenAI által üzemeltetett sandboxban, a cég saját infrastruktúráján vagy egy támogatott szolgáltatónál. Az OpenAI kilenc partnert nevez meg, köztük a Blaxelt, a Cloudflare-t, a Daytonát, a DigitalOceant, az E2B-t, a Modalt, az Oracle-t, a Runloopot és a Vercelt, és külön kiemeli a saját VPC-n belüli telepítés lehetőségét.
Ez a szétválasztás az érdemi mozgástér. Egy csapat használhatja a menedzselt harnesst úgy, hogy a kód, a fájlok és a köztes eredmények a saját környezetében maradnak, ami más kockázati profil, mint a hosztolt sandbox alapértelmezett bekapcsolása. Ha az ügyfélszerződés vagy a kiírás megkötést tartalmaz arra, hol futhat a kód és hol tárolódhatnak a köztes fájlok, akkor a sandbox helye az első eldöntendő kérdés; a szempontokat az on-premise vagy felhő alapú AI cikkünkben szedtük össze. A bejelentés és a changelog EU-adattelepítésről, GDPR-feldolgozási feltételekről és AI Act-kötelezettségekről nem nyilatkozik, ezért ezt a részt a saját beszerzési dossziéban kell tisztázni.
A harness nyílt forráskódú: az OpenAI szerint az Agents API a nyilvános Codex harnessre épül, és a fejlesztő átnézheti azt a logikát, amely a modellhívásokat, az eszközöket és a kontextust koordinálja. Ez segít az auditban és a kilépési terv megírásában. Attól viszont nem lesz a menedzselt szolgáltatás máshol futtatható, hogy a kód olvasható.
Amit a bejelentés nem árazott be
Az OpenAI kijelenti, hogy az Agents API használatáért nincs külön díj, a vásárló a tokeneket és az eszközhasználatot fizeti. Ez nem azonos a költségsemlegességgel. Az automatikus tömörítés, az eszközkeresés és a párhuzamos subagentek mind tokent fogyasztanak, és minden subagent a saját kontextusát tartja fenn. Egy menedzselt harness tehát egyszerre csökkentheti a fejlesztői órákat és növelheti a tokenszámlát, ezért a pilotban egyetlen értelmes metrika van: a teljes, mindent tartalmazó költség egy lezárt esetre.
Érdemes a saját számaiddal számolni. Tegyük fel, hogy a csapat havi 24 órát tölt a saját tömörítő és újrapróbáló logikájának karbantartásával, és ezt 60 euró/óra belső költséggel számoljuk: ez havi 1 440 euró. A 24 óra és a 60 euró is feltételezés, cseréld ki a saját időnyilvántartásod adataira, majd állítsd szembe a megnövekvő tokenköltséggel. A bejelentés sem munkaszámot, sem korlátokat, sem tömörítési tokenbecslést nem közöl, tehát ezt a két oldalt csak méréssel lehet összehozni.
Teljesítményszámot egyetlen helyen közöl a bejelentés, és az egy megnevezett ügyfél nyilatkozata: a Ciridae vezetője szerint az értékelési pontszámuk 0,71-ről 0,85-re ment fel (kb. 20 százalékos relatív javulás), és a subagent-folyamatokon négyszeres késleltetéscsökkenést mértek. Feladatkészlet, kiindulási harness és mérési módszer nélkül ez nem benchmark, hanem egyetlen ügyfél tapasztalata, és nem helyettesíti a saját A/B-tesztet.
A pénzügyi átláthatóság termékenként ingadozik. Ugyanaznap a GPT-Live-1 általánosan elérhetővé vált, és az OpenAI kiírta a percdíjat: 0,05 dollár hangperc, másodpercre bontva számlázva, a backend modell és az eszközhasználat külön. Az Agents API mellé viszont semmilyen kiszámolt költségpélda nem került. Az Agents API a szeptember 10-i négy termékbejelentés egyike volt, egy nappal a GPT-6 Astra munkára szabott változata után.
Ha a saját orchesztráció és a menedzselt harness közötti döntést mérésekkel szeretnéd megalapozni, az agent tervezését, tesztelését és üzembe állítását projektként is visszük. AI agent fejlesztés
Ki mit tegyen most
| Helyzet | Mit tegyen most | Miért |
|---|---|---|
| Éles agent fut, saját tömörítő és újrapróbáló logikával | Párhuzamos pilot egyetlen munkafolyamaton a menedzselt harness-szel | Itt a legnagyobb a leszerelhető kódmennyiség, és van mihez mérni |
| Több subagentet koordinálna, de nincs rá fejlesztői kapacitás | A multi-agent beállítás tesztje legfeljebb három párhuzamos subagenttel | Az orchesztráció megírása kimarad, a párhuzamos kontextus viszont tokent fogyaszt |
| Csak prototípus van, éles agent még nincs | Először a folyamat, az eval-készlet és a kivételkezelés | Nyilvános beta fölé épített első rendszert kétszer kell újraírni |
| Kötött adattelepítés, szektorális vagy szerződéses megkötés | A sandbox helyének eldöntése és dokumentálása a harness kérdése előtt | A végrehajtási környezet saját infrastruktúrában vagy partnernél is tartható |
| SLA-hoz kötött szállítás vagy közbeszerzési vállalás | Kivárás a general availabilityig, közben zárt belső pilot | A kiadás nyilvános beta, GA-dátum és SLA nélkül |
Döntési helyzetek az OpenAI Agents API nyilvános betájához, 2026. szeptember 10-i állapot. Forrás: az OpenAI bejelentése és fejlesztői changelogja.
Mit mérj, mielőtt migrálsz
A teszt ára alacsony, a migráció ára magas, ezért a pilotot érdemes szűkre venni és pontosan instrumentálni.
- Egy valódi munkafolyamatot válassz, olyat, amelyre már van eval-készleted és hibastatisztikád.
- Mérd a lezárt esetenkénti teljes költséget, ne a hívásonkénti tokenszámot, és bontsd külön a tömörítés, az eszközkeresés és a subagentek fogyasztását.
- Mérd a hibás vagy félbehagyott esetek arányát a saját orchesztrációdhoz képest, ugyanazon a bemeneti készleten.
- Tartsd meg az absztrakciós határt, hogy a sessionöket mindkét harness vezérelhesse; ez a kilépési terved.
- Írd le külön döntésként, hol fut a sandbox, milyen fájlok maradnak ott, és ki fér hozzájuk.
- Jelöld ki, ki figyeli a harness verzióváltásait, és mi történik, ha a viselkedés egy modellkiadásnál megváltozik.
Ha a pilot két-három hét alatt nem tud különbséget kimutatni a költségben és a hibaarányban, akkor a saját orchesztráció megtartása a takarékosabb döntés, és a betából később is be lehet szállni.