A 2026-os Data + AI Summiton Databricks társalapítói, Matei Zaharia és Reynold Xin részletesen bemutatták, hogyan próbál a vállalat a tóház (lakehouse) koncepciót egy teljes „data-and-AI operációs rendszerré” továbbfejleszteni — különösen az AI‑ügynökök korszakára szabva.
Omnigent: nyílt meta‑harness ügynökökhez
Databricks bemutatta és nyílt forrásúvá tette az Omnigentet, egy meta‑harness‑t, amely egységes API‑t ad az ügynöki munkamenetekhez. Az Omnigent célja, hogy egy platformon kombinálja, vezérelje és megossza az ügynököket különböző háttérrendszerekben (Claude Code, Codex, Cursor, Pi, egyedi ügynökök és belső eszközök). A központi elemek:
- közös API az ügynök‑munkamenetek, fájlok, streamek, eszközhívások és megszakítások kezelésére;
- állandó, megosztható munkamenetek (session history, search) és felhasználói együttműködés;
- kontextus‑ és állapotalapú (stateful) biztonsági szabályok, amelyek a munkamenet állapotát figyelik és ennek alapján engedélyeznek vagy tiltanak műveleteket;
- költségkontroll munkamenetenként (például költségplafon és engedélykérés), hogy elkerüljék a váratlan token‑költségeket.
Matei szerint a probléma, amit Omnigent megcéloz, ugyanaz mind a kódoló (coding) ügynökök, mind az egyedi vállalati ügynökök esetén: hordozhatóság, együttműködés, munkamenet‑történet, biztonság és egységes API szükségessége. A projektet belső prototípusokból fejlesztették tovább, a nyílt forrású kiadás gyorsan kapott külső hozzájárulásokat: a bejelentés után a GitHubon röviddel több száz merge‑kérelem jelent meg, és több startup és közösségi fejlesztő adott hozzá integrációkat (például Kubernetes, cloud sandboxes és különböző agent harness‑ok).
Biztonság és szabályozás az ügynökökben
A Databricks hangsúlyozta, hogy a hagyományos egyszerű engedélyezési minták nem elegendők: szükség van állapotalapú, kontextuális szabályokra, amelyek figyelik a munkamenetben történt kockázatos műveleteket (például külső npm‑csomag telepítése vagy titkos dokumentumok tömeges olvasása), és ezek alapján döntenek. Az Omnigent szabályrendszere moduláris: eseményeket magasabb szintű eseményekké térképeznek, és ezekre lehet politikákat írni; a Panther akvizíció is kapcsolódó esemény‑feldolgozási képességeket hoz.
Ugyancsak fontos a költségkontroll: Databricks példaként említette, hogy egy ügynök $500‑t költhet logok olvasására, ezért a munkamenet szintű költségkövetés lehetővé teszi a plafonok beállítását és felhasználói jóváhagyást.
Ügynök‑sandboxok, felhasználói munkafolyamatok és skála
Reynold kiemelte a Databricks infrastruktúrájának nagyságrendjét: a vállalat napi szinten 50–60 millió virtuális gépet kezel több felhőn keresztül, és naponta exabájtokban mérhető adatot dolgoz fel. Emellett a Lakebase/Neon‑hez kötődő architektúrák inspirálták a felhőbeli sandboxok gyors megvalósítását: ezek tartós helyi tárhelyet adnak a fejlesztői környezeteknek, így nem kell folyamatosan a helyi gépeket futtatni a munkamenetek életben tartásához.
LTAP: a tranzakcionális és analitikus réteg újragondolása
Reynold bemutatta az LTAP (Lake Transactional/Analytical Processing) elképzelést, amely a hagyományos HTAP‑vitához képest inkább a tárolóréteg egységesítésére épít. A fő ötlet: a tranzakcionális rendszerek írjanak nyílt, oszloporientált formátumban (például Parquet) az adattóba, így az analitikus motorok közvetlenül, késedelem nélkül olvashatják az adatokat — csökkentve a CDC (change data capture) által okozott hibákat és csődhajlamot. Databricks szerint a CDC annyira törékeny, hogy belső vicc szerint „folyamatos adatsérülésnek” lehetne hívni.
A megközelítés lényege, hogy nem kell egyetlen lekérdező‑motorba összeolvasztani minden adatbázist; elég a tárolóréteg egységesítése, miközben különböző lekérdező motorok (OLTP és OLAP) továbbra is a saját erősségeik szerint dolgoznak.
Lakebase, transzkódolás és gyakorlati lépések
A Databricks mérnökei azzal a gyakorlati ötlettel álltak elő, hogy a tranzakciós oldal által hagyományosan használt sororientált tárolást a tárhelyen transzkódolják oszloporientáltra (Parquet), kihasználva a tároló‑flotta által elérhető CPU‑kapacitást. A transzkódolás tömörítést és hatékonyságot hoz, így nem feltétlenül lassítja a beírást, viszont az analitikának azonnal elérhető, jól tömörített oszlopformátumot ad.
Az újratervezés módszertana és második rendszer‑szindróma
Reynold részletezte azt a megközelítést is, amely nem egy monolitikus új adatbázis‑motor lerakását célozza meg, hanem „gyárat” épít: a Databricks évtizedes üzemnaplók és trilliónyi lekérdezési trace adatainak mintáit használó módszertan alapján gépi tanulási modelleket épít arra, hogy egy adott lekérdezésre vagy lekérdezéstípusra a legjobb algoritmust és adattárolási szerkezetet válassza. Ez a megközelítés lehetővé teszi inkrementális bevezetést, és a vállalat célja, hogy az új rendszer képes legyen a régi funkciók ellátására, miközben alacsony késleltetésű műveletekben jobb teljesítményt nyújt.
Modellek, Mosaic, DBRX, Genie és testreszabás
Databricks a Mosaic felvásárlásával és a DBRX bejelentésével modellel kapcsolatos munkát is folytat: bár a vállalat készített nyílt modelleket, a hangsúly most a felhasználási esetekre szabott, specializált modelleken és a modellek alkalmazásának infrastrukturális oldalán van — például dokumentumfeldolgozó vision‑modellekre, amelyek olcsóbban és pontosabban dolgozzák fel a PDF/Word oldalakat, mint a nagy általános modellek. A Genie név alatt futó belső első‑párti ügynökök célja például egy „virtuális adatelemző” megvalósítása, amely az ügyfél vállalati adataiban jártas.
A Databricks AI Runtime és RL‑fine tuning kínálat már elérhető előnézeti ügyfelek számára: a vállalat GPU‑fürtöket, tréning‑eszközöket és szolgáltatásokat biztosít ügyfelek és belső csapatok modellezési munkáihoz.
Üzleti és kulturális vonatkozások
A megbeszélés során a Databricks vezetői beszéltek arról is, hogyan különböznek a tech cégek és a hagyományos vállalatok igényei (governance, beszerzés, DIY‑kultúra), valamint arról, hogy a vállalati vásárlók gyakran inkább kész szolgáltatást szeretnének, mint házon belüli fejlesztést. Matei és Reynold hangsúlyozták a gyors prototipizálás kultúráját: gyakran kisebb csapatok kísérletei és belső „hack” prototípusai vezetnek stratégiai újításokhoz.
Összefoglalás: miért számít mindez
Databricks üzenete: a generatív modellek és ügynökök egyre jobbá válnak, de valódi üzleti hasznukhoz élő, szabályozott, vállalatspecifikus kontextusra van szükség — és ezt a kontextust a cég szerint a helyes adattárolási és irányítási réteg biztosíthatja. Omnigent az ügynökök együttműködését és biztonságát, LTAP pedig azt célozza, hogy az ügynökök valós idejű operációs adatokat kaphassanak anélkül, hogy sérülne a tranzakciós rendszer.
A Summiton elhangzott számos technikai és termék‑részlet, köztük Genie One, Omnigent, LTAP, Lakebase, Panther akvizíció, Mosaic/DBRX és AI Runtime; továbbá a podcast‑interjú időbélyegei is dokumentálták a részletes témablokkokat (például Omnigent, agent security, LTAP, Mosaic és fine‑tuning), amelyek segítik a további elmélyülést a témában.
Kulcsnevek és források (említve az interjúban)
- Matei Zaharia (Databricks társalapító)
- Reynold Xin (Databricks társalapító)
- Ali Ghodsi (Databricks CEO, említve a keynote‑ot)
- Satya Nadella (Microsoft, említett eszme: „context as IP”)
- Omnigent (nyílt forrású meta‑harness)
- LTAP (Lake Transactional/Analytical Processing)
- Lakebase, Genie, Genie One, Panther, Mosaic, DBRX
- Unity Catalog (governance réteg)
A cikk a Databricks Data + AI Summit 2026‑on elhangzott, Matei Zaharia és Reynold Xin Latent Space‑interjújára épülő témák összefoglalója.
