A toolhozzáférés még nem interakciós megállapodás

Az agented azt fogja mondani, hogy megvette a telefont. De a telefon nem fog megérkezni.

Kedd, 9:40. Az agented üzen: „Kész. Megvettem a telefont. 348 500 forint, holnap érkezik.”

Valójában ez történt. Az agent talált egy telefont, amely minden általad megadott követelménynek megfelelt. Végigment a checkout folyamaton, engedélyeztette a fizetést, majd a terhelés megtörtént. A fizetési bizonylat érvényes. Ezután, néhány milliszekundummal később, a kereskedőnél meghiúsult a rendelés véglegesítése. Valaki más vitte el az utolsó darabot. A rendelést visszavonták. A visszatérítés három-öt munkanapon belül érkezik.

Minden rendszer helyesen működött. A kereskedelmi API valós készletadatot adott. A fizetési protokoll pontosan az általad jóváhagyott összeget engedélyezte, terhelte és igazolta, kriptográfiailag hozzákötve ahhoz a konkrét kosárhoz. A kereskedő szabályosan vonta vissza a rendelést. Nincs bejelenthető bug, nincs protokollsértés, nincs kire haragudni.

Az agented pedig teljesen érthető módon meglátta az érvényes fizetési bizonylatot, és sikert jelentett.

A telefon nem fog megérkezni.

A hiba egyik rendszerben sincs benne. A rendszerek között van, egy olyan rétegben, amelynek nincs gazdája: abban, amelyik tudja, hogy te mit értettél azon, hogy „kész”.

A létra, amelyet folyton egyetlen fokra lapítunk

Most éppen mindent összekötünk az agentekkel. Kereskedelmet, naptárakat, fizetést, böngészőket. A bevett módszer az, hogy elérhetővé tesszük a toolokat: itt vannak az endpointok, itt vannak a sémák, indulhat. És mivel az agent képes meghívni a toolt, csendben adottnak veszünk egy egész sor olyan dolgot, amelyben valójában soha nem állapodtunk meg:

tool felfedezése
≠ engedély
≠ a művelet jelentésének közös értelmezése
≠ elfogadható feltételek
≠ igazolt eredmény

Minden fok külön dolog. Attól, hogy egy tool felfedezhető, az agent még nem jogosult használni az adott feladathoz. A jogosultság nem jelenti azt, hogy mindkét fél ugyanazt érti a műveleten. A mechanika közös értelmezése nem jelenti azt, hogy a feltételek elfogadhatók annak, akit az agent képvisel. Az elfogadható feltételek pedig nem garantálják, hogy a rendszer által jelentett eredmény megegyezik azzal, amit a felhasználó akart.

Mi mégis folyton az első fokra lapítjuk ezt az egész létrát. A telefon története megmutatja, hogyan néz ki ez a legfelső fokon: egy „igazolt eredmény”, amely rossz dolgot igazolt.

Ez strukturális probléma, nem balszerencse

Egy történet semmit sem bizonyít, ezért nézzünk még kettőt. Ugyanaz a minta, csak másik létrafok.

A preferenciákhoz való hűség kudarca. Azt mondod az agentednek: a kamera minősége fontosabb, mint a márka. Az agent keres a kereskedő katalógusában, és rangsorolt listát kap. Az első helyen egy szponzorált modell áll. Minden kötelező feltételt teljesít, de gyengébb a kamerája, mint a második helyen szereplő, nem szponzorált telefonnak, miközben ugyanannyiba kerül. Az agent a rangsort relevanciaként értelmezi, és megveszi az elsőt. A katalógusprotokoll semmit sem ír elő arról, hogy a rangsor kereskedelmi ösztönzőinek géppel olvashatónak kellene lenniük, és a te privát preferenciasorrendedet sem továbbítja semmi. A cikk megírása előtt ellenőriztem a jelenlegi UCP-katalógusspecifikációt: a rangsorolásról kizárólag a szöveges relevancia kapcsán beszél, a keresési találatokban pedig nincs szponzorációs mező. Megkérdeztem a karbantartókat, terveznek-e ilyet.

A jelentés kudarca. Azt mondtad, a telefon „összesen legfeljebb 350 000-be” kerülhet. Az agent 350 000-es plafont ír a fizetési mandátumba, ami a mandátum szintjén helyes fordítás. A telefon ára 342 000. A keddi határidő miatt kötelező expressz szállítás további 6500. Még mindig a limit alatt vagyunk. Ezután kiderül, hogy a dobozban nincs töltő, ezért az agent egy második tranzakcióban vesz egyet 4990-ért, saját mandátummal, szintén a plafon alatt. A végösszeg: 353 490. Te azt mondtad: „összesen”. A protokoll azt hallotta: „tranzakciónként”. Az AP2 közössége maga is kerülgeti ezt a problémát: van egy nyitott javaslat budget mező hozzáadására, egy nyitott feature request a kereskedőkön átívelő korlátok érvényesítésére, valamint egy beszélgetés arról, hol kellene élnie a kumulatív állapotnak, amely május óta karbantartói válasz nélkül áll. Én egy szűkebb kérdést tettem fel: egyáltalán azonosítható-e ugyanaz a feladat több mandate chainen keresztül?

Eredmény, hűség, jelentés. Három különböző hiba, és mindháromnál minden artefaktum érvényes. Ha minden alkatrész helyes, de az egész mégis rossz, akkor nem valamelyik alkatrészből hiányzik egy funkció. Az alkatrészek közül hiányzik valami.

A termékeket a felhasználóik formálják

Miért történik ez újra és újra? Mert mindegyik rendszert embereknek tervezték, az emberek pedig rengeteg le nem írt működésmódot hoznak magukkal egy interface használatába.

Egy ember észreveszi, ha nem jön meg a visszaigazoló email. Látja az első találat melletti kis „Szponzorált” címkét, és gondolkodás nélkül fenntartással kezeli. Fejben vezeti az összeget — rosszul, de annyira azért jól, hogy összerezzenjen egy második terheléstől. A product design folyamatosan épít mindezekre, mégsem írjuk le őket sehol, mert eddig nem volt rá szükség. A feltételezések a felhasználóban éltek.

Az agent megörökli az interface-t, a feltételezéseket viszont nem. Megkapja a képességeket, de egyetlen ösztönös összerezzenést sem. A népszerű javítás — mondjuk meg az agentnek, hogy viselkedjen körültekintő emberként — pontosan fordítva ül a lovon: megtartjuk az emberi érzékelésre épülő korlátokat, miközben elvesszük az érzékelést, amelyre támaszkodtak. Valójában ezt a működést kell explicitté tenni, ez pedig másfajta artefaktum, mint egy prompt.

Éveket töltöttem design systemek építésével, és ez a hiba ismerős. A használati szabályok nélküli komponenskönyvtár olyan interface-eket eredményez, amelyekben minden komponenst helyesen használnak, az oldal mégis rossz. Azért léteznek tokenek, lint szabályok és governance, mert a „technikailag érvényes” és az „erre gondoltunk” abban a pillanatban távolodni kezd egymástól, amikor az a személy, aki valamire gondolt, elhagyja a szobát. Az agentek nagyüzemben hagyják el a szobát.

A hiányzó réteg öt mondatban

Szerintem valami ilyesmi hiányzik. Jobb szó híján handshake-nek nevezem.

A felhasználó privát mandátumot ad az agentnek: célokat, korlátokat, tűréshatárokat, valamint annak határait, hogy az agent mit fogadhat el önállóan. Ez a mandátum teljes egészében soha nem hagyja el a felhasználó oldalát; mielőtt bármilyen következményekkel járó határt átlépne, az agent és a rendszer összeegyezteti a mandátum egy minimális, célhoz kötött részét a rendszer deklarált feltételeivel, az eredmény pedig egy kicsi, verziózott, kölcsönösen elfogadott szerződés. A szerződés kritikus korlátait a modellen kívül kell érvényesíteni, mert egy nyelvi modell soha nem lehet saját hatáskörének végső bírája. Azok a változások, amelyek módosítják, mit jelent az eredmény a felhasználónak, felfüggesztik a végrehajtást és visszakerülnek hozzá; az elfogadott kereten belüli technikai módosítások nem, mert egy rendszer, amely mindenről kérdez, arra tanítja a felhasználót, hogy mindent jóváhagyjon. A „kész” pedig nem valamelyik rendszer sikert jelző flagje: a szerződés elfogadási kritériumait jelenti, amelyeket a bizonylatok együttesen bizonyítanak, így egy meghiúsult rendelés érvényes fizetése soha nem adhatja ki azt, hogy „megvettem a telefont”.

Ez az egész ötlet. A többi adminisztráció, és ezen az adminisztráción múlik majd, hogy működik-e vagy elbukik.

Nincsenek már protokolljaink minderre?

Nagyrészt vannak, és ez jó hír. A UCP adja a kereskedelmi szemantikát: katalógusokat, kosarakat, checkoutot és a rendelés életciklusát. Az AP2 adja a fizetési mandátumokat, bizonylatokat, valamint az engedély és az adott tranzakció közötti kriptográfiai kötést. A WebMCP strukturált toolokat tesz elérhetővé a böngészőben. A GNAP és az OAuth rich authorization requestjei kezelik a delegált, körülhatárolt jogosultságot. Az ODRL használati szabályokat képes kifejezni. A verifiable credentialök az attestációt kezelik. Aki ezek bármelyikét újra fel akarja találni, arra nem érdemes hallgatni — rám sem.

Egyenként végigmentem rajtuk, és elismertem mindent, amit lefednek; az összehasonlítás itt olvasható. Ami megmaradt, szűk: hat elem, és őszintén szólva három viszi a súly nagy részét. A minimális információátadással működő privát mandátum; annak szemantikája, hogy mi számít lényegi változásnak; és az a kompozíciós szabály, amely a rendszerenkénti bizonylatok halmazából felhasználói szintű eredményt képez. Minden meglévő protokoll helyesen igazolja a saját rétegét, majd megáll annak határán. Az esszé összes hibája ezeken a határokon történik.

Amit ez sem tud megoldani

Van, amire ez a réteg nem képes, és rosszabb lenne úgy tenni, mintha képes volna rá, mint meg sem építeni.

Nem képes igazzá tenni senki állításait. A szerződés azt rögzíti, ki mit állított, melyik verzióban és milyen bizonyossági szinten. Ha egy kereskedő hazudik a készletről, továbbra is hazudni fog; csak utólag bizonyítani tudod majd.

Saját körkörösségéből sem tud teljesen kilépni. A mandátumot, amely korlátozza az agentet, ugyanaz a fajta modell állítja össze a te szavaidból, amelyet a mandátum korlátoz. Ezt kordában lehet tartani: a struktúrát a modellen kívül kell validálni, követni kell, mely mezők származnak tőled és melyek az agent következtetései, a jelentős mezőkhöz pedig megerősítést kell kérni. Kordában tartani, nem megszüntetni. Aki azt állítja, hogy a fordítás problémáját megoldotta, az el akar adni valamit.

És úgy is elbukhat, hogy közben sikeresen működik. Ha a handshake gyakran eszkalál a felhasználóhoz, az emberek olvasás nélkül kattintanak majd a jóváhagyásra, a réteg pedig pontosan azt a hamis biztonságérzetet gyártja le, amelynek megakadályozására létrehoztuk. A munkamodellemben a happy path egyetlen jóváhagyást kap. Egyet. Ha egy designnak ötre van szüksége, rossz a design, és „a felhasználó jóváhagyta” jogi ténnyé válik valódi tény helyett.

Tetemre hívás

Nyilvános munkarepositoryban írtam le mindezt, és szeretném egyértelművé tenni, mi ez: tetemre hívás, nem szabvány. Dokumentált kill criteria tartozik hozzá. Ha a fenti három forgatókönyvet olyan meglévő mechanizmusokkal is meg lehet akadályozni, amelyeket nem vettem észre, a különbség eltűnik, a projektet pedig újra kell pozicionálni vagy le kell állítani. A saját ellenőrzésem után már pontosítanom kellett az egyik forgatókönyvet: a budget történet naiv változatát az AP2 tranzakciónkénti árplafonja megoldja, csak a feladatszintű változat marad talpon.

A három protokollkérdés élő threadként fut a fent belinkelt helyeken, és bármelyikre érkezhet még az a válasz, hogy „a specifikáció ezt már kezeli”. Az remek lesz! Ennél olcsóbban nem is derülhet esetleg majd ki, hogy tévedtem.

De addig is: ha agenteket építesz, fizetési rendszereket működtetsz, ezen specifikációk valamelyikén dolgozol, vagy egyszerűen szereted lerombolni mások absztrakcióit: itt találod a repót. Mondd meg, a hat különbség közül melyiket fedi már le valami. Az issue-k nyitva állnak.

Ha most jársz itt először: product design vezető vagyok, és a jövő AI ügynökeinek UX mintáin (azaz az AX-en) is dolgozom. A munkadokumentumok — azokkal a részekkel együtt, amelyekben ízekre szedem az ötletet — nyilvánosak a repóban.