Practical AI. Az AGENTS.md-től a vállalati bevezetésig¶

Epizód: From AGENTS.md to Enterprise Deployment Dátum: 2026-09-24 Hossz: 48:52 Házigazdák: Daniel Whitenack (CEO, Prediction Guard) és Chris Benson (Principal AI/Autonomy Research Engineer) Vendég: Nick Kuhn (VMware Tanzu Platform, a Cloud Foundry Weekly podcast házigazdája, Broadcom) Forrás: https://share.transistor.fm/s/74934e48

Bevezetés és a kiindulópont¶

A Practical AI 373. epizódja egy olyan kérdést jár körbe, ami a legtöbb AI-agenttel foglalkozó beszélgetésből kimarad: mi történik, amikor az agent elhagyja a laptopot, és egy valódi vállalati környezetbe kerül. Nick Kuhn a VMware Tanzu Platformtól érkezett, aki maga is podcaster (Cloud Foundry Weekly), és a Midwest AI Summiton tart előadást pont erről a témáról.

A beszélgetés alapfeltevése egyszerű, de radikális: az agent nem új kategória, hanem app. Ha ez igaz, akkor két évtized platform-mérnöki tudás alkalmazható rá. A vége felé kiderül, hogy az analógia nem teljes, és pont ahol eltörik, ott van a legérdekesebb mérnöki probléma.

Mi tesz egy környezetet vállalativá¶

Nick 14 évet töltött nagyvállalatoknál, mielőtt a VMware Tanzuhoz került, és a meghatározás nála nem elméleti:

Nincs internet, vagy korlátozott. A beszállítók visszatérő tévedése, hogy feltételezik a nyílt internetelérést. Vannak ügyfelek, ahol valódi air gap van, és a hardvert fizikailag viszik be az adatközpontba.
Szabályozás. PCI, SOX, HIPAA, FIPS, és a compliance-szintek sora. Nem lehetőségek, hanem megkötések.
A tét nagyságrendje. Amit otthon megteszel, azt a munkahelyen nem teheted meg. Az epizód egyik legjobb példája Nick első állásából származik: egy raktárkészlet-rendszer egy amerikai élelmiszer-kiskereskedőnél, ami régebbi volt, mint ő, és C meg shell scriptekből állt Unixon. Ha az leállt, öt percen belül kamionok torlódtak fel az autópályán.

Ez a skála-különbség a lényeg. A fogyasztói világ és a vállalati világ két külön univerzum, és az agentek most a másodikba lépnek be.

A platform-mérnöki precedens: Cloud Foundry és a buildpack¶

Nick végigviszi a nézőt a hagyományos úton, mert szerinte ez a helyes kiindulópont. A Tanzu Platform egy nyílt forrású projektre épül, a Cloud Foundry-ra, ami 2011 körül indult, tehát korábbi, mint a Kubernetes és a Docker. Ez nem mellékes: a rendszer két évtizedet látott, és ez alatt a vállalati elvárásokhoz csiszolódott.

A mechanizmus a buildpack. Amikor egy fejlesztő feltölt egy Java JAR-t a cf push paranccsal, a platform felismeri, hogy Java-alkalmazásról van szó, és a Java buildpack segítségével legjobb gyakorlat szerinti konténert épít. A buildpack ismeri a JVM memóriaszámítást, a JDK-t, a tanúsítványokat, és mindent, ami egy Java konténer futtatásához kell. A fejlesztő nem foglalkozik a konténer biztonságával, a platform elvégzi helyette.

A platform ezután kezeli az ingress-t, a tanúsítványokat, a terheléselosztókat, a health monitoringot, és az alkalmazások egymástól való elkülönítését (sandboxing), hogy egy app ne tudjon kilépni. Ha az appnak adatbázisra, üzenetközvetítőre, middleware-re vagy nagy nyelvi modellre van szüksége, akkor bindolja azt, és a kapcsolat menet közben jön létre. Néhány parancs: push, bind, scale.

A vállalati értelme ennek Nick szerint az, hogy a legkisebb ellenállású utat kell megépíteni. Ha az élesítési útvonal minden pipát kipipál, akkor azt fogják használni. A rossz alternatíva az, hogy minden részleg saját megoldást eszkábál, és lesz száz hókuszpókusz. A vállalat egységes, auditálható és biztosítható mintát akar, hogy a fejlesztői idő az üzleti logikára menjen, ne az infrastruktúrára.

Hol törik el az „agent egyenlő app” analógia¶

Ez a beszélgetés központi része, és pontosan megfogalmazódik benne, mi az új.

A Cloud Foundry és a Tanzu Platform a 12-faktoros alkalmazás elvén alapul, ahol a tárolás és az állapot tisztán leválik magáról az alkalmazásról. Ez teszi lehetővé, hogy ezer példányra skálázz, és a session-állapotot máshol kezeled. Az agentek viszont nem így születtek:

„A hagyományos harness-ek vagy agentek eredetileg csak arra épültek, hogy van fájlrendszer-hozzáférésem, írok egy csomó MD fájlt, és az a memóriám.”

Ez működik a laptopon. A felhőben viszont a dolgok fel- és lepörögnek, efemertek, és azok az MD fájlok elszállnak a semmibe. Ez Nick szerint a legnagyobb kihívás, amikor az app-telepítési módszertant rá akarják húzni egy felhőplatformon futó agentre.

A második eltérés a fizikai közelség. A hagyományos gondolkodás szerint az inferencia bárhol lehet. A valóságban a vállalatok azt kérik, hogy az LLM és az agent minél közelebb legyen az alkalmazáshoz és az adathoz. Ha az agent 30 ugrásra van a hívó mikroszolgáltatástól, a fizika késleltetést ad hozzá, és skálán ez problémás lehet. Ehhez jön, hogy a SaaS-szolgáltatók megbízhatósága nem éri el a vállalati elvárást: nem lehet, hogy órákra kimennek.

Ezért aztán két tábor alakult ki Nick ügyfeleinél: akik néhány éve vettek GPU-kat (és most örülnek), és akik nem vettek (és most néznek szembe a hardverárak emelkedésével).

A Tanzu Agent Build Pack¶

A koncepció lényege, hogy az agent telepítése ugyanolyan legyen, mint egy app telepítése. A Tanzu Agent Build Pack egy harness, ami ezt a folyamatot végzi. A mechanizmus ugyanaz, mint a Java buildpack esetében, csak a bemenet más:

Java esetén géppel olvasható kód (JAR) megy fel.
Agent esetén ember által olvasható nyelv, az AGENTS.md megy fel.

Megmondod, mit csináljon az agent, feltolod, és a platformon belül egy percen belül elindul. Tetszés szerint skálázható.

A statikus rész az AGENTS.md tartalma, ami a sablon: „senior szoftvermernök vagy, figyeld ezt a Jira sort, nézd át a bejövő ticketeket, ellenőrizd, hogy jó minőségűek-e”. Nick demóiban van egy szórakoztató elem is: az agent kalózként beszél. Az állapot viszont nem a statikus fájlban van, hanem a memory service-ben.

A memória-szolgáltatás: a csapat-szintű kontextus¶

Nick leírása szerint a memória-szolgáltatás csapat-szintűen szerveződik. Az A csapat agentjei az A csapat memóriájához férnek hozzá. Amikor egy agent elindul, azonnal ismeri a korábbi történetet: az alkalmazás architektúráját, hogy mi történt korábban, a roadmapet. Így amikor biztonsági átvizsgálást végez, megalapozott döntést tud hozni.

Ez adja a választ Daniel kérdésére, hogy mi statikus és mi fejlődik időben: az AGENTS.md a viselkedés sablonja, a memória pedig a felhalmozott kontextus, ami a fel- és lepörgő agentek között megmarad.

Az MCP gateway: amit eddig nem tárgyaltunk¶

Chris külön kiemeli, hogy bár az MCP-ről sok szó volt a műsorban, az MCP gateway maga még sosem került elő, és ez az egyetlen új architektúra-elem, amit ez az epizód hoz.

Nick magyarázata szerint az MCP gateway egy mód arra, hogy könnyen lehessen szabályozni és skálázni az MCP-szerverekhez való hozzáférést. A szervezetnél 30-40 MCP-szerver fut, ezeket regisztrálják a gatewayekhez, és a gateway szabályozza a hozzáférést: „ehhez a gatewayhez bindolhatsz, de csak ezeket az MCP-szervereket kapod, és csak ezeket az eszközöket bennük”.

Három funkciója van, amit érdemes megjegyezni:

Absztrakció. A gateway elrejti, hogy hány MCP-szerver van a szervezetben, és egyetlen belépési pontot ad.
Identitás-átvezetés. Ez a legérdekesebb rész. A GitHub MCP-szervernél a felhasználó a saját hitelesítő adatait akarja átvezetni, nem pedig azt, hogy az egész szervezet nevében egy generikus szolgáltatásfiók hajtson végre műveleteket. Ezért van szükség SSO-ra és bejelentkezésre: az agent identitása vagy a desktopon futó agentet működtető ember identitása.
Mérőszámok és láthatóság. Mivel minden a gatewayen folyik át, látszanak a tool-hívások és az események. Nick példája: ha egy agent 200 000 tool-hívást indít egy „delete repo” műveletre, arra illik riasztani, mert az valószínűleg nem jó.

A gateway tehát egyszerre biztonsági kapu, identitás-híd és megfigyelhetőségi pont.

A sandbox és a biztonság a Hugging Face eset tükrében¶

Chris visszahozza az OpenAI Hugging Face incidenst, amit egy korábbi epizódban tárgyaltak, és azt kérdezi, hogyan segít a vállalati struktúra a „dolgok dobozban tartásában”.

Nick előrebocsát egy disclaimert: ezek javaslatok, nem állítja, hogy jobbak lennének bármelyik AI-laboratóriumnál, és ha az ember mélyebben belemegy a Hugging Face ügybe, az ijesztő. A mechanizmus szerinte az volt, hogy az agentek kijutottak a sandboxból, találtak elérhető dolgokat, és a monitoring nem működött. Innen jutottak el az Artifactory-ig, ami viszont rendelkezett internet-hozzáféréssel, és az Artifactory példányt többször is lenullázták.

A tanulság Nick szerint nem az, hogy meg lehet akadályozni mindent, hanem hogy az alapvető vállalati biztonsági eszközök segítettek volna:

Hálózati zónák. Egy erősen szabályozott, lezárt zóna. Egy hagyományos tűzfal is blokkolta volna a legtöbb ilyet.
Keményített sandbox. A konténerizált agentek nem érik el a hosztrendszert, nem beszélnek egymással, hacsak nem engedélyezed, és nem mennek ki az internetre alapértelmezés szerint.
Monitoring. Figyelni, hogy az agentek ne injektáljanak olyan eszközöket, amelyeket nem szabadna.
Dependency stack. A függőségek, a konténer, az operációs rendszer és a platform foltozása.

Nick összegzése: az ügyből lett egy „az AI ki fog nyírni minket” hangulat a hétvégén, miközben a megoldás részben „csinálj alapvető biztonságot”. Chris ezt kiegészíti, hogy a konkrét szikra egy közösségi médiás poszt volt, amit sokan félreértelmeztek.

Szervezeti tanulságok: a régi és az új csapat¶

Chris felveti a visszatérő szervezeti mintát: új technológia, új csapat, és a régi csapatok kimaradnak. Nick szerint a felelősség kétirányú:

Az új csapat feladata, hogy elérje a többi csapatot. Ők ismerik a kontextust, és segíthetnek. A gyakorlati eszközök: heti office hours, lunch and learn, egy nyitott fórum, ahol kérdezni lehet. Az új csapat terhe nagy („vezessük be az AI-t mindenhol”, korábban „menjünk a felhőbe mindenhol”), és ezt egyedül nem tudja meghozni.
A régi csapatok feladata, hogy nyitottak legyenek. Aki ellenáll, azt megbélyegzik és félreteszik. Aki a saját véleményét nyitott formában adja elő, annak sokkal jobb esélye van rá, hogy a karrierje során tanult kulcsfontosságú dolgok az új módszerben is érvényesüljenek.

Nick hoz egy adatpontot is: a VMware Explore-on minden előadását azzal kezdte, hogy megkérdezte a teremben, ki használ már ilyen eszközöket (Cursor, Claude Code, stb.) a munkahelyén. Szinte minden kéz felment, ami jóval több, mint amire számított. A hozzáadás mértéke a platform- és infrastruktúra-mérnöki személyeknél is jelentős, és ez gyorsul.

A bevezetés gyakorlati tanácsa: baby steps¶

Chris kérdésére, hogyan lehet lépést tartani a folyamatosan érkező protokollokkal (MCP, majd A2A, az agent-to-agent protokoll), Nick tanácsa egyértelmű: kis lépések.

Nem kell mindent egyszerre bevezetni.
Sok helyen már az is a legnagyobb akadály, hogy hozzáférést kapjanak egy jóváhagyott, biztonságos LLM-hez.
A nagyvállalatoknál működik egy AI tanács vagy bizottság, amin mindennek át kell mennie. Nick félig vicces leírása: „elmegyünk a bizottsághoz, előadjuk az ötletet, várunk hat hónapot, és meglátjuk, mi lett az eredmény”.
Miután valamit jóváhagytak, iterálni kell. Nem kell „felforralni az óceánt”. Ha az agent jobb lenne MCP-szerverekkel és eszközökkel, akkor azt jóvá kell hagyatni, és hozzáadni.
A guardrail-ek segítenek, mert nem az internetről letöltött véletlenszerű dolgokat használják.
A meglévő tapasztalatot és a meglévő embereket kell bevonni, nem új szervezeti silókat építeni.

A jövő: szerepek, hang, robotika¶

A záró kérdésre Nick hosszabb távon csapat- és szerepváltozást jósol, és nem csak a vállalati oldalon. A fejlesztés és a termékmenedzsment is átalakul, új szerepek jelennek meg. Ezt ő pozitívnak látja: bár mindig van félelem a munkahely elvesztésétől, ő maga többet dolgozik, mint valaha, mert az agentek folyamatosan kérnek tőle dolgokat, és olyan projekteket tud építeni, amiket mindig szeretett volna, de nem volt ideje.

Konkrét előrejelzések:

Hang. Jelentős fejlődés várható a hangalapú interakcióban, és talán a számítógéppel való interakció új stílusa is kialakul.
Robotika. Nick említi, hogy a Hugging Face kisebb robotokat árult, és ő maga is rendelt belőlük a családnak. Az LLM szerinte nagyszerű, de sokkal több lehetőség van előttünk, feltéve hogy sikerül elkerülni a Terminator-forgatókönyvet.

Chris egyetért: a változás mértéke őrületes, és gyorsulni fog.

A lényeg¶

Az epizód központi állítása az, hogy az agenteket appként kell kezelni, mert a platform-mérnöki tudás kétharmada alkalmazható rájuk: buildpack-szemlélet, sandbox, hálózati zónák, identitás, megfigyelhetőség, auditálhatóság. Ahol eltörik, az az állapotkezelés: az MD fájlokra épülő memória nem él túl egy efemer felhőplatformot, ezért külön memória-szolgáltatás kell. És ahol a legtöbbet lehet tanulni, az a Hugging Face incidens: nem új, egzotikus védelemre volt szükség, hanem alapvető biztonságra, amit a vállalati világ két évtizede gyakorol.

Az AGENTS.md mint telepítési artefaktum ember által olvasható, és ez a lényeg: a szándék leírása maga az artefaktum, nem a fordítás utáni gépkód.

Forrás¶

Epizód: From AGENTS.md to Enterprise Deployment (Practical AI #373)
Vendég: Nick Kuhn (VMware Tanzu Platform, Broadcom; Cloud Foundry Weekly podcast)
Házigazdák: Daniel Whitenack, Chris Benson
URL: https://share.transistor.fm/s/74934e48
Transcript: Transistor.fm hivatalos podcast:transcript (transcription.txt, 9456 szó) + chapters.json (15 fejezet)

Kapcsolódó külső¶

Cloud Foundry, a Tanzu Platform alapjául szolgáló nyílt forrású PaaS (2011)
Tanzu Agent Build Pack, a VMware Tanzu agent-harnesse
Model Context Protocol (MCP), az app és az LLM közötti kommunikáció szabványa
A2A (agent-to-agent protokoll), a következő réteg a horizonton
Midwest AI Summit, 2026. október 15., Indianapolis
Prediction Guard, a műsor támogatója és Daniel Whitenack cége (AI control plane)

Kapcsolódó belső¶

az agentek read-only-ból read-write-ba fordulása.
a computer-use agentek és az agentic internet.
architektúra a modellek helyett.
harness-ek és multi-agent rendszerek.
topic, ágens-architektúra és vállalati bevezetés.

Hogyan kapcsolódik a saját rendszerünkhöz (részletes)¶

Ez az epizód szokatlanul közvetlenül érinti a saját setupunkat, mert az AGENTS.md és a harness-ek pont azok az artefaktumok, amelyeken a Hermes rendszerünk is alapul.

Az AGENTS.md mint ember által olvasható telepítési artefaktum. Nick megfogalmazása szerint a Java buildpack géppel olvasható kódot kapott, az agent viszont ember által olvasható nyelvet. Ez pontosan a mi helyzetünk: a SOUL.md, AGENTS.md, USER.md és a SKILL.md fájlok ember által olvasható szándékleírások, amelyekből a viselkedés származik. Az epizód megerősíti, hogy ez nem átmeneti állapot, hanem a helyes absztrakciós szint: a szándék az artefaktum.
A statikus és dinamikus állapot szétválasztása. Nick pontosan megkülönbözteti az AGENTS.md statikus sablonját („mit csináljon az agent”) a memória-szolgáltatás dinamikus kontextusától („mi történt korábban”). A saját rendszerünkben ez a kettő jelenleg részben összemosódik: a MEMORY.md és a state/notes.md a dinamikus rész, a SKILL.md a statikus rész, de a határ nem mindig éles. Az epizód érve szerint érdemes ezt tudatosan szétválasztani, mert a dinamikus rész máshogy viselkedik (nő, avul, konszolidálódik), mint a statikus.
A sandbox-kérdés a Mux/Computer-use korszakban. A Hugging Face incidens tanulsága (sandbox escape, monitoring hiánya, a gyenge láncszem az internet-hozzáféréssel rendelkező Artifactory volt) közvetlenül érvényes a computer-use skillünkre. Ha desktop-automatizálást végzünk, a kérdés ugyanaz: mi az, amihez az agent hozzáférhet, és mi az, amihez nem. Nick mintája (alapértelmezésben nincs internet, nincs egymás közötti kommunikáció, nincs hosztelérés) alkalmazható elv.
Az identitás-átvezetés az MCP-nél. Az epizód rámutat egy gyakorlati problémára, ami a saját MCP-használatunknál is felmerülhet: a GitHub-szerű szervereknél az egyéni identitásnak kell átfolynia, nem egy generikus szolgáltatásfióknak. Ez a github skill-csoportunk és a gh CLI használatánál releváns: a műveletek a felhasználó nevében történjenek, ne egy megosztott fiókként.
A megfigyelhetőség mint biztonsági kontroll. Nick példája (200 000 tool-hívás egy törlésre) egyszerű, de erős: a mérőszám maga a detektor. A saját rendszerünkben a háttér-review és a harness-health-check játszik hasonló szerepet, de a tanulság az, hogy a tool-hívások mintázata önmagában jelzés lehet, nem csak a hiba.
A „baby steps” bevezetési elv egyezik a saját SOP-nkkal. Nick tanácsa (ne forrald fel az óceánt, kis lépések, ne építs új silót a meglévő tudás megkerülésével) szó szerint egybevág a Henky-féle „lassan, de biztosan” és „ne legyen túl komplikált, mert akkor fenntarthatatlan” elvekkel. Az epizód külső megerősítést ad arra, hogy ez nem lassúság, hanem a vállalati környezet egyetlen működő bevezetési mintája.