Beleške s terena

Agentska plaćanja pod ljudskim pravilima

Agentska plaćanja su plaćanja koja pokreće softver, a ne osoba na checkout-u. AI agent drži kredencijale, odlučuje da kupovina treba da se desi i sam prebacuje novac — plaća fakturu, obnavlja pretplatu, rezerviše čarter — bez ljudskog klika na poslednje dugme. Presudna je činjenica ko pokreće. Osoba koja klikne kupi je obično kartično plaćanje sa chatbotom ispred; agentsko plaćanje je softver koji odlučuje, odobrava i poravnava u trenutku kad novac zaista krene. Sve što je teško u ovoj kategoriji proizlazi iz te jedne osobine: ono što troši nije osoba i ne umara se, ne postaje sumnjičavo niti nervozno kao čovek pre nego što uplati novac strancu.

Zato zanimljivo pitanje nikada nije bilo hoće li agenti trošiti novac — već mogu. Pitanje je ko postavlja pravila pod kojima troše i sprovodi li ih platforma ili ih agent samo obećava.

Scenario otkaza je očigledan, i u tome je poenta

Dajte agentu aktivan platni kredencijal bez ikakvog plafona i napravili ste incident prevare sa uplatama koji se još nije dogodio. Način na koji puca nije egzotičan. Prompt injection skriven na veb stranici nalaže agentu da plati napadaču. Neispravan opis alata usmeri legitimnu kupovinu pogrešnom primaocu. Petlja ponovnih pokušaja pokuša istu naplatu hiljadu puta jer signal o uspehu nikad nije stigao. Nijedno od toga ne traži genijalnog napadača — to su obične greške autonomnog softvera, samo što je rezultat novac koji napušta vaš račun.

Primamljivo rešenje je da agent bude pažljiviji: bolji sistemski prompt, strožije uputstvo, model koji dublje razmišlja o trošenju. Time se kontrola stavlja na najnepouzdanije mesto u sistemu — u agentovo sopstveno rasuđivanje, upravo ono što se može nagovoriti da popusti. Budžet koji agent može da nadgovori nije budžet. Kontrola mora da živi tamo gde agent ne dopire, a to znači potpuno izvan agenta.

Pravila su proizvod, a ne prompt

Model obuzdavanja je pravilo koje platforma sprovodi pre nego što novac krene, a ne nakon što je agent odlučio. Svaki agent dobija limit po transakciji i dnevni limit — €150.00 po plaćanju, €500.00 dnevno u našem demo pravilu — a povrh toga mesečni plafon od €6,000.00. To su čvrsti zidovi koje proverava platforma, a ne obećanja koja agent drži. Kada je demo agent za putovanja pokušao da plati čarter od €640.00, plaćanje je odmah odbijeno: preko limita, pre nego što je ijedan cent krenuo. Agent koji se savršeno ponaša svakog dana ipak ne može da pređe ono što mesec dozvoljava.

Budžet kaže koliko; lista dozvoljenih kaže kome. Agenti plaćaju samo trgovcima koje ste unapred imenovali. Demo Ops Agent zna tačno četiri, a pokušaj od €180.00 kod dobavljača koji nije na listi odbijen je kao not-listed. Zajedno, to crta okvir: ovoliko novca, samo ovim primaocima. Unutar okvira agent radi punom brzinom i nikad ne mora da pita; okvir je ono čime upravlja čovek.

Pitanje nikada nije hoće li AI agent trošiti novac. Pitanje je ko je napisao pravila pod kojima troši — a odgovor uvek treba da bude čovek, unapred, u pisanoj formi.
— Protocore · Agents inženjering

Čovek iznad linije

Neke odluke su prevelike za okvir. Zato pravila nose prag: utvrđen iznos iznad kog čovek mora da odobri pre nego što plaćanje prođe. U demou linija je na €100.00. Kada je Ops Agent označio fakturu #088 od Nord Logistics — €120.00, bezbedno unutar dnevnog budžeta od €500.00, ali iznad linije odobrenja — nije platio. Zastao je, stavio predlog pred osobu i čekao. Odgovor od jednog reda ga je odobrio; plaćanje je poravnato kao referenca 9F21-0716 i upisano u audit log u 09:41. Ispod linije agent radi sam; iznad nje prvo odgovara čovek.

Odobrenje nije polje za potvrdu koje nestane. Beleži ko je odobrio, na kom uređaju, u koje vreme i uz priloženi potpis — odobreno u aplikaciji, ključ telefona, 09:41:12. Kada neko kasnije pita zašto je do plaćanja došlo, odgovor je imenovana osoba i vremenska oznaka, a ne slegnuće ramenima.

Kill-switch i log koji se ne može neprimetno menjati

Čak i unutar dobrih zidova agenti greše, a pravila se pokažu pogrešnim. Za to postoje dve kontrole. Prva je kill-switch: jedan dodir pauzira agenta i trenutno zaustavlja svako plaćanje koje bi mogao da pokrene. Ključevi ostaju važeći da se ništa drugo ne pokvari — agent jednostavno ne može da troši dok ga čovek ponovo ne uključi, a njegovi predlozi na čekanju ostaju zamrznuti umesto da nestanu. U demo floti agent za putovanja stoji pauziran sa €0.00 potrošenog, a red mu je netaknut.

Drugi element je audit log samo za dodavanje (append-only). Svaka odluka je zabeležena: šta je agent pokušao, koja je provera politike prošla ili pala, ko je šta odobrio, sve do rotacija ključeva. Jedan zapis rekonstruiše celo plaćanje — odluka DEC-4471 prikazuje zahtev, svaku proveru politike sa rezultatom (allowlist prolazi, limit prolazi, prag eskalira), potpis osobe i namirenu sumu sa railom i referencom. Svaki unos nosi sopstveni hash, hash prethodnog unosa i svoju poziciju u lancu — #4,471 u demou — pa izmena bilo kog polja prekida sve zapise posle njega. Log se izvozi kao JSON, zajedno sa hashem: vaš je da ga predate revizoru, a ne naš da ga čuvamo.

Neka poravnanje bude dosadno; novinu ostavite za autorizaciju

Postoji iskušenje da se agentska plaćanja naprave novim do poslednjeg sloja — novi rail, novi instrument, nov način da novac putuje. Odolite mu. Zaista nov deo je autorizacija: kako agent dokazuje da sme da plaća, po čijoj politici i uz kakvo odobrenje. Kada plaćanje prođe tu kapiju, treba da se namiri na railovima koji su godinama dosadni. U demou, odobren predlog od €120.00 postaje obično SEPA kreditno plaćanje — namireno putem SEPA Instant nekoliko minuta nakon odobrenja — i nizvodno se ne razlikuje od plaćanja koje je izvršila osoba. Banka ne zna, niti je briga, da ga je pokrenuo agent.

Ova podela je namerna. Dosadni railovi su predvidivi, povratni gde to šema dozvoljava, i razumeju ih svi trezori i revizori sa kojima ćete ikada raditi. Kada se novina smesti u politiku, a plaćanje na utvrđen rail, rizičan i brz deo je upravo onaj koji u potpunosti kontrolišete, a deo koji dodiruje tuđe banke je onaj koji niko ne mora iznova da uči. Agenti troše iz istog jezgra na kojem radi ostatak Pay porodice — opisanog na /products/pay — a ne iz paralelnog sveta napravljenog za robote.

Pejzaž protokola još nije utvrđen — gradite u skladu s tim

Kako agent treba da predstavi svoj identitet i svoj mandat trgovcu, otvoreno je pitanje. Nekoliko predloga se nadmeće oko toga kako agent dokazuje ko je, šta sme da kupi i kako trgovac to proverava pre prihvatanja novca. Nijedan nije pobedio, a kladiti se na bilo koji od njih danas bilo bi preuranjeno. Odbrambeni pristup je da se protokol autorizacije tretira kao zamenljiv, a sve iza njega drži stabilnim: policy engine, audit model i rail poravnanja ne menjaju se kad se promeni format poruka sa prednje strane.

U praksi to znači malu, dosadnu površinu integracije. Agenti se povezuju preko MCP-a na mcp.protocore.io/agents; svaki framework koji govori taj protokol može da drži novčanik. Interfejs je namerno uzak — predloži plaćanje, primi odluku — jer se zanimljiva logika nalazi na platformi, a ne u promptu. Kada industrija utvrdi kako agenti dokazuju identitet trgovcima, promeniće se prednja strana, a zidovi iza nje ostaće tačno tamo gde jesu.

Gde ovo staje

Agentska plaćanja nisu opklada da autonomni softver treba da troši bez ograničenja. Upravo suprotno: opklada su da će softver trošiti, pa je bolje da ograničenja budu stvarna, spoljna i čitljiva. Budžeti i allowlist-e povlače okvir, prag usmerava velike odluke ka osobi, kill-switch zaustavlja sve, a append-only log znači da se svako plaćanje može naknadno rekonstruisati. Stranica proizvoda na /products/agents prolazi kroz ceo ciklus na demo podacima korišćenim ovde — kreirate agenta, postavite mu politiku, gledate kako plaćanje eskalira i biva namireno — a /products/pay je jezgro na kojem ta plaćanja rade. Autonomija je stvarna; stvaran je i povodac, a drži ga čovek.

Imate sistem za izgradnju?

Opišite nam problem. Vratićemo se sa arhitekturom i planom.