Minden általam használt ügynök egy modell építésén dolgozik rólam. Claude megtanulta, hogyan szeretek írni; ChatGPT emlékszik, min dolgozom. Ezt nem zavarónak találom — emberek fejében és cégek profiljaiban mindig is volt valamilyen képemről. De az ügynök más szerepet tölt be: az írásomhoz, preferenciáimhoz és életformámhoz igazodva segít a munkámban. Ha azonban váltok, elölről kell kezdeni: minden ügynök külön építi fel ugyanazt a tudást, és az, amit megtanul, a vendornál marad.
Nem kell ennek így lennie. Mi lenne, ha minden embernek lenne egy kanonikus, a felhasználó által irányított kontextustárháza, amelyhez bármely ügynök engedélyt kérhetne? Mi van, ha a kontextusom nemcsak az ügynököt szolgáltató cégnél létezne, hanem egy, az én irányításom alatt álló "otthonban"? És mi van, ha egy ügynök által rögzített megfigyelést fel lehetne ajánlani a tárháznak, és ha elfogadom, az más, általam választott ügynökök számára is elérhetővé válik?
Amikor azt mondom, hogy felhasználó által irányított, nem feltétlenül ön-hostolt rendszert értek. Arra gondolok, hogy meg tudom nézni, mi van benne, dönthetek arról, ki olvashatja vagy módosíthatja, értem honnan származik egy-egy tétel, és ki tudom exportálni az egészet olyan formában, amit magammal vihetek. A tárolást, az identitást és a szinkronizációt más is nyújthatja; a kontrollhoz nem kell nekem üzemeltetnem az infrastruktúrát, csak azt kell biztosítani, hogy sem egy ügynök, sem egy platform ne legyen az egyetlen be- vagy kivezető út.
A tárház nem egy ügynök belső modelljének hordozható másolata lenne. Inkább emberi olvashatóságú nyilvántartás arról, amit én írtam, a megtartani kívánt tényekről és preferenciákról, valamint azokról a megfigyelésekről, amelyeket ügynökök javasoltak és én elfogadtam — mindegyikhez kapcsolódó eredetiségi adatokkal, hatókörrel és történettel. Az ügynökök a jogosultságaik szerint olvashatják vagy bővíthetik ezt a nyilvántartást; a saját, privát következtetéseik továbbra is az övék maradnának.
Ez az álom nem új. Tim Berners-Lee Solid projektje hosszú ideje érvel amellett, hogy a személyes adatoknak a felhasználók által irányított „pod”-okban kell élniük, és Doc Searls VRM (Vendor Relationship Management) kezdeményezése is régóta a vásárló-vezérelt kapcsolatok mellett áll. Ezeknek a mozgalmaknak azonban sosem volt meg a mainstream keresletük — mostanáig. Az ügynökök igénye: egy asszisztens csak gazdag személyes kontextussal lehet igazán hasznos, és minden vendor a saját falaiban építi azt. Ez most hétköznapi emberek számára is indokot teremt egy személyes adatboltra, még ha nem is így nevezik.
A nehéz kérdés nem a tárolás vagy a szinkronizáció. A nehézség a tárgyalás: ki láthatja a kontextus egy részét? Ki adhatja hozzá, módosíthatja vagy törölheti? Melyik ügynök melyik életem részét láthatja? Hogyan hozom meg ezeket a döntéseket policy-alapú módon, és hogyan menedzselem őket bárhonnan?
Először azonban meg kellett határoznom, hol éljen maga a kontextus. Ezen a kérdésen dolgoztam az elmúlt egy évben, és három választ próbáltam ki.
Első válasz: a laptop
2025 elején, miután hozzáférést kaptam a Claude Code-hoz, egy Obsidian-vaultot (Markdown fájlokból álló személyes wiki) csatlakoztattam hozzá. Nem volt különösen új ötlet; sok ismerősöm hasonlóan járt el, és a minta több formában elterjedt. A legismertebb példa talán Karpathy LLM Wiki-je: leírást adsz az ügynöknek, az pedig a te igényeidre szabott verziót épít.
Egy évnyi Markdown-fájlokkal való ügynökkal való használat öt fontos tanulságra tanított meg, ami egy személyes kontextusrendszernek helyesnek kell lennie:
-
Lokális első megközelítés számít. A szövegfájlok olvashatók, hordozhatók, és könnyen tarthatók olyan helyen, amit én kontrollálok. A Git mozgatja őket és megjegyzi a változásokat. Ugyanakkor ez a megoldás laptop- vagy asztali-központú, feltételezi, hogy a felhasználó jártas a sima szövegben és verziókezelésben. A legbosszantóbb: a kontextus így nem áll kézre a telefonomon — pedig az visz mindig magammal — és nem érhető el távoli ügynökök számára.
-
Proveniencia és javaslatok fontosak. Karpathy Wiki-je egy LLM által írt és átírt tartalom. Az én rendszeremben én írok a legtöbbet, és ügynököket szeretek szerkesztésre vagy megfigyelés-felajánlásra használni. Fontos tudni, mi az enyém, mi az ügynöké, és mi közös eredmény. Ezért az ügynök-javaslatok ne kerüljenek automatikusan a tárházba: alapértelmezettként javaslatként kell megjelenniük, amelyet én vagy egy általam irányított policy elfogadhat, módosíthat vagy elutasíthat. A közvetlen írási jogot egy megbízható ügynöknek ki kell érdemelnie.
-
Kronológia számít. A wiki-linkek nem fedik le az élet minden szerkezetét. Sok rögzített gondolat és ügynöki megfigyelés időben rögzül; a gondolatok egymásra épülnek, megfigyelések találkozóról találkozóra gyűlnek. Egyes tények elhalványulnak az idővel. Az időnek elsődleges tengelynek kell lennie, nem valaminek, amit a fájlok történetéből kell visszaépíteni.
-
Hatókörök (scopes) számítanak. A kontextusom munkára, személyes életre, családra és nyilvános tartalmakra kiterjed. Egyesült, egységes nézetet szeretnék: egy munkáltatói fiókon keresztül csatlakozó ügynök csak a munkához és a nyilvános részhez férjen hozzá — a családhoz ne. A teljesen különálló silók megvédenék a határokat, de széttépnék azt az egységes történetet, amelyet évtizedeken át építeni szeretnék.
-
Identitás és típus fontos. Az LLM-ek sokféle jelentést tudnak kinyerni sima szövegből, de személyek, cégek, helyek jobban járnak típusos rekordokkal, nem csak említésekkel. Egy állandó identitás ankert ad a megfigyeléseknek és kapcsolatoknak, segít becenevek feloldásában és szerepek változásának követésében. Az ügynök ezután egy személyre vonatkozóan tud cselekedni anélkül, hogy minden alkalommal újra fel kellene építenie azt a prózából.
Ezeket a leckéket eszközökkel és konvenciókkal egészítettem ki a személyes kontextustáramban. Meglepő, mennyire messzire el lehet juttatni egy Markdown-könyvtárat. Minden új affordancia azonban specializáltabb rendszerré formálta a mappát, ami végül csak olyan geekeknek működik, mint én. A családom tagjai használják az ügynököket, de sosem fognak egy Git-repozitórium életével foglalkozni. Számukra a kontextus legyen velük, könnyen használható és átlátható.
Összefoglalva: ezek a tanulságok megmondják, mit kell tudnia egy kontextusrendszernek, de nem válaszolják meg, hol kell élnie, ha /home/$USER nem a személyes számítástechnikai élet középpontja.
Második válasz: a web
A következő lépés az volt, hogy hozzáférhetővé tegyem a kontextust akkor is, ha nem a laptopomnál vagyok — nekem és az ügynököknek egyaránt. Nyilvánvaló megoldás: szerver és URL. Telepítettem egy Cloudflare Worker-t, feltöltöttem a kontextust, és REST API-t illetve MCP szervert állítottam fel. A javulás azonnali volt: a kontextus elérhetővé vált a telefonomról és bármely csatlakoztatott ügynöknek engedélyezhető volt.
Ugyanakkor új problémák is megjelentek. Új bizalmi határt hoztam létre saját hozzáférés-vezérlővel, és önként kineveztem magam a biztonsági csapatának: egy egyszemélyes SaaS üzemeltetője lettem, felelős rendelkezésre állásért és mentésekért. Emellett feladtam a lokális első, offline szerkesztés élményét.
Ezek megoldhatók: az iparágunk két évtizede tanulta meg a szolgáltatások üzemeltetését, és a CRDT-k valószínűleg visszaadhatják az offline szerkesztést. De ahogy az ügynökök érzékenyebb adatokhoz és nagyobb cselekvési jogkörökhöz férnek hozzá, a rossz határ megválasztásának ára nő.
Még ha ezeket technikailag megoldjuk is, egy mélyebb probléma marad: egy önálló szolgáltatás kívül esik a személyes számítástechnikai "otthonomon", távol a névjegyektől, naptáraktól, üzenetektől, fájloktól és a platformszintű ügynököktől, amelyek már eleve benne vannak. Az Apple Siri és a Google Gemini integrációk jól megmutatták, hogy egy ökoszisztémába ágyazott ügynök hozzáfér mindennek azon belül; egy külső workernek újra kellene építenie ezeket a kapcsolatokat.
Harmadik válasz: a zsebemben
Gondolkodás közben mindig visszatértem egy egyszerű mentális képhez: a kontextus ott él a zsebemben lévő eszközön, amely mindig velem van. Nem szó szerint minden bájt, hanem azon személyes számítástechnikai ökoszisztéma közepén, amelyet a telefon jelent: az, ami már most meghatározza az identitásomat, szinkronizálja az eszközeimet, tárolja személyes adataim nagy részét, és közvetítési pontként működik az alkalmazások számára. Ebben az értelemben az otthon nem fizikai hely, hanem bizalmi határ.
Az, hogy a kontextus a határon belül éljen, nem jelenti azt, hogy minden alkalmazás azonnal hozzáfér. A határ identitást, biztonságos tárolást, szinkronizációt és natív integrációt ad; a kontextusréteg dönti el, mit olvashat, javasolhat, módosíthat vagy törölhet egy kapcsolat. A natív ügynökök a platform saját képességein keresztül működnek; külső vállalati ügynökök explicit, visszavonható jogosultságokkal csatlakoznak.
Számomra ez a zsebbeli otthon az Apple ökoszisztéma, iCloud-dal a középpontban. Neked lehet, hogy a Google vagy a Microsoft az otthonod. A lényeg nem az, hogy egyetlen ökoszisztéma a helyes mindenkinek, hanem hogy a legtöbb embernek már van egy elsődleges digitális otthona, és ez a legpraktikusabb alapértelmezett hely a személyes kontextus számára. Nem kell külön szolgáltatást létrehozni saját identitással: az ügynököknek közös, permission-vezérelt felületet kell kapniuk a kontextus eléréséhez ott, ahol az már létezik.
Nyilvánvaló kockázat: a vendor-alapú otthon zárolást (lock-in) eredményezhet. A mérséklés egyszerű: a teljes tárháznak — entitásokkal, provenienciával és történettel együtt — exportálhatónak kell lennie bármikor, például egyszerű, szövegalapú fájlok könyvtáraként, amit bárhová vihetünk. Egy mappa fájlokból talán nem a legjobb élmény élő kontextusnak, de tökéletes menekülési út.
Kis prototípusokat építettem SwiftUI-ban, és az első tapasztalatok azt mutatják, működőképes az architektúra: iCloud kezeli a szinkronizációt, és MCP-n keresztül kiválasztott kontextust adhatok oda hitelesített ügynököknek. Az Apple fejlesztői ökoszisztémában való dolgozás azonban kényelmetlenebb, mint egy webalkalmazás telepítése. A hátralévő munka azonban világos: az otthon kiválasztása csak az egyik feladat; a valódi nehézség a tárgyalás — a jogosultságok kezelése, a több ügynöktől érkező javaslatok felülvizsgálata és összeegyeztetése.
Egy minta, sok otthon
Mások különböző irányokból érkeznek ugyanarra a mintára. A Bear jegyzetalkalmazás, amely helyben tárolja a jegyzeteket Apple eszközökön és iCloudon szinkronizál, most helyi ügynököknek MCP-n keresztül elérhetővé teszi a jegyzeteket; a felhasználó címkék szerint kiválaszthatja, mit ad ki engedélyezésre. A Craft MCP-kapcsolatai lehetővé teszik, hogy a felhasználó kiválassza, mely dokumentumok vagy terek legyenek elérhetők egy ügynök számára, és hogy az csak olvasni vagy írni is tudjon. A Reflect pedig egy nyílt forráskódú klienssel dolgozik Markdown-fájlokkal, és iOS-támogatást tervez.
Ezek csak példák; még nem láttam azonban elterjedni azt a megközelítést, amely tartalmazza az ügynökök által hozzájárult vagy szerkesztett tételek attribúcióját és provenienciáját — pedig ez tartós személyes kontextus esetén fontos.
Alapelvek, amelyeket minden rendszernek követnie kell
A következő elveket tartom szükségesnek bármilyen ilyen rendszerben, bárhol is legyen az otthona:
- A kontextus ne legyen fogoly egyetlen ügynöknél. A felhasználó bármikor válthasson vagy kombinálhasson ügynököket anélkül, hogy újból kezdje.
- A kontextus legyen elérhető helyi és távoli ügynökök számára is, megfelelő autentikációval és autorizációval.
- A jogosultságok legyenek hatókör-specifikusak és visszavonhatók. Az engedély egy adott ügynök-kapcsolatra szóljon, korlátozott részhalmazra, és különböztesse meg az olvasást, javaslatot, módosítást és törlést.
- A proveniencia maradjon fenn. Minden elem rögzítse, honnan származik, ki vagy mi hozta létre, és hogyan változott; az emberi írás, az ügynöki rögzítés és az együttműködés közti különbség túlélje az eredeti beszélgetést.
- Az idő legyen a kontextus része. A rendszer őrizze meg, mikor volt valami megfigyelve, mikor volt érvényes, és hogyan változott — ne írja folyamatosan felül a múltat a jelennel. (A bitemporalitás fogalmát használják erre az adatbázisok.)
- Az entitások legyenek elsőrendűek. A személyek, cégek, helyek és ismétlődő fogalmak maradjanak felismerhetőek, ahogy a nevek és szerepek változnak.
- Az interoperabilitás ne követelje meg az uniformitást. Különböző emberek és cégek építhetnek eltérő kontextusrendszereket különböző ökoszisztémákban; amire szükségük van, az a megállapodás identitásban, jogosultságokban, provenienciában és cserében. A cseréhez a sima szöveges fájlok strukturált metaadattal jó jelöltek.
Ezen elvek mentén a személyes kontextus olyanná válhat, amit a felhasználó birtokol: meg tudja nézni, adh at és vonhat vissza hozzáférést, nyomon tudja követni forrását, és bárhová elviheti. Minden ügynök továbbra is kialakíthat saját, privát megértést rólunk, de mi magunk is hordozhatunk egy tartós kontextust, amely részt vesz az ügynöki ökoszisztémában anélkül, hogy bármely vendor alá rendelt lenne.
Karpathy LLM Wiki-je leírás, nem eszköz; bárki megvalósíthatja a maga formájában. Ezt az esszét ugyanebben a szellemben írtam. Nem az a fontos, hogy az általam kísérletezett alkalmazás valaha is túlmenjen-e a saját eszközeimen. Sokkal érdekesebb a párbeszéd, amely mindenkinek elhozza a számára működő személyes kontextust: a saját ökoszisztémájában, a kívánt ügynökökkel. Ha jól értjük meg a mintát, az ügynökök váltása nem jelenti majd az otthonok váltását — a kontextus, amit segítenek építeni, a miénk marad.
