Ang Agentic Stack ay May Apat na Layer. Karamihan sa mga Deployment ay Nawawalan ng Tatlo

Kailangan ang pagkakakilanlan, reputasyon, mandato, at pagbabayad na mabuhay on-chain. Sa maraming production deployment, hindi pa ito nangyayari, at iyon ay isang problemang arkitektural, hindi isang compliance na afterthought.

Gumugol ako ng maraming oras sa pagtingin kung paano talaga nakakabit ang mga production agent deployment, at madalas pareho ang pattern: ang modelo ay may kakayahan, at ang orchestration framework ay katamtaman, ngunit ang authentication layer ay isang shared API key pa rin na hindi pa napapalitan sa loob ng maraming buwan.

Ang autonomous agent infrastructure ay hindi nakasabay sa mga modelong tumatakbo dito. Ang agentic stack ay may apat na komponent na kailangang native sa chain: pagkakakilanlan, reputasyon, mandato, at pagbabayad. Sa karamihan ng mga production deployment na nakikita ko, idinadagdag pa lamang ito pagkatapos, kung mayroon man.

At ito ay mas mahalaga sa regulated finance kaysa saan man. Ang isang agent na maaaring mag-transact sa tokenized securities, aprubahan ang mga treasury action, o mag-allocate sa iba’t ibang posisyon ay kailangang maipakita kung ano ang pinahintulutang gawin nito, sino ang nagbigay ng pahintulot, sa anong limitasyon, at kung saan nakatira ang on-chain record ng awtoridad na iyon. Karamihan sa mga deployment ay hindi kayang sagutin ito nang malinaw ngayon. Kung wala ang rekord na iyon, ang mismong agent ay nagiging panganib sa audit at compliance.

Bakit ang shared API keys ay maling primitive

Ang authentication model na karamihan sa mga agent deployment ay minamana mula sa SaaS ay isang shared secret na ipinapasa sa header. Pinapatunay nito ang tumatawag na serbisyo ngunit walang sinasabi tungkol sa tiyak na agent na gumagawa ng tawag, o kung ano ang pinahihintulutang gawin ng agent, at hindi ito nag-iiwan ng rekord na nabubuhay sa audit sa anyong maaaring inspeksyunin ng regulator. Ang bawat aksyon ng agent ay maituturing lamang sa sinumang humahawak ng susi, na sa praktika ay nangangahulugang ang attribution ay bumabagsak kapag mayroon kang higit sa isang agent o higit sa isang operator.

Ang alternatibo ay signature-based per-request settlement. Ang bawat request ay nilalagdaan ng sariling wallet ng agent at nasusettle cryptographically sa punto ng tawag. Ito ang layunin ng x402 na binuo, kung saan magkasamang hinahawakan ang authentication at pagbabayad. Ibinibigay nito sa mga institusyon ang rekord kung aling wallet ang kumilos, kailan ito kumilos, at kung ano ang binayaran, isang ledger na maaaring tumagal sa audit scrutiny.

Ang agwat sa pagkakakilanlan

ERC-8004 nagtatakda ng on-chain identity para sa trustless agents: isang registry kung saan ang isang agent ay nakarehistro kasama ang isang controlling wallet, isang service endpoint, at isang model reference. Sa ngayon, ang agent na iyon ay isang opaque process na tumatakbo sa loob ng imprastruktura ng vendor. Ang entry sa registry ay ginagawa itong first-class on-chain actor na may mapapatunayan na pinagmulan — na maaaring i-check ng isang smart contract o compliance dashboard nang direkta, nang hindi nagtitiwala sa isang intermediary.

Ang reputation layer ay nakatayo sa ibabaw nito. Ang mga feedback signal na nakasulat sa ERC-8004 registry ay immutable, may timestamp, at maituturing. Anumang system na nais gumawa ng trust decisions tungkol sa isang agent ay maaaring basahin nang direkta ang registry na iyon. Hindi tulad ng vendor-managed score o Discord rating, ang tiwala dito ay isang katangian ng network kaysa sa sinumang kumokontrol sa database.

Parehong layer ay maaaring ipatupad ngayon nang walang exotic engineering. Karamihan sa mga deployment ay wala ito dahil ang pinakamadaling landas ng implementasyon ay ituring pa rin ang mga agent bilang service accounts sa halip na first-class actors. Ang isang makatwirang shortcut sa prototype ay nagiging architectural debt na lumalala sa production.

Ang problema sa mandato ay kung saan ang regulated finance ay lumilihis mula sa lahat ng iba pa

Ang identity at reputasyon ay nagsasabi kung sino ang isang agent at kung paano ito kumilos. Hindi nito itinatag kung ano ang pinahihintulutang gawin ng agent. Sa maraming use case ng agent, maaaring takpan ng application-layer controls ang agwat na iyon. Para sa mga agent na gumagana sa regulated assets, ang tanong ng awtorisasyon ay nagiging legal na tanong. Ang sagot ay kailangang umiral sa anyong maaaring mapaligaya ang regulator.

ERC-8226, ang Regulated Agent Mandate Standard (RAMS), ay dinisenyo upang isara ang agwat na ito. Ang RAMS ay nagtatakda ng compliance delegation layer na nakaupo sa pagitan ng agent identity at token-level compliance frameworks. Ang isang KYC-verified principal ay nagbibigay sa isang agent ng mandato na may tinukoy na saklaw, hurisdiksyon, limitasyon sa halaga, at petsa ng pag-expire. Sa praktika, ito ay gumagana tulad ng on-chain power of attorney na maaaring suriin bago ang settlement. Ang regulated token contract ay pagkatapos ay nagve-verify ng mandato nang atomically sa loob ng pre-transfer compliance hook bago maganap ang anumang settlement.

Dalawang interface ang nagdadala ng disenyo. Ang `ComplianceProvider` ay ipinatupad ng anumang KYC o attestation operator at nagpapatunay sa eligibility ng principal para sa isang tiyak na saklaw. Ang `IAgentMandate` ay ang registry na nagrerecord ng grants, extensions, revocations, executions, at regulator-tier freezes. Ang pagpapatupad ay nangyayari sa pamamagitan ng `recordExecution`, na sinusuri ang mga cap ng aktibong mandato sa oras ng transfer at nagre-revert kung ang transaksyon ay lalabag dito.

Ang arkitekturang ito ay nakaupo sa pagitan ng ERC-8004 identity at token compliance frameworks tulad ng ERC-7943 sa halip na palitan ang alinman. Ang identity ay nagsasabi na ang agent ay umiiral at mapapatunayan; ang token compliance, na ang principal ay karapat-dapat na humawak ng partikular na asset na ito. Ang RAMS ay nagdadagdag ng bahagi na hindi nasasaklaw ng alinman: awtoridad mula sa principal na ito, para sa saklaw na ito, sa loob ng mga limitasyong ito, hanggang sa petsang ito. Ang legal na maipapatupad na delegation layer na kasalukuyang nabubuhay lamang sa mga PDF at back-office spreadsheets ay lumilipat on-chain, kung saan maaari itong talagang ipatupad sa oras ng transfer.

Ang paghihiwalay ng paghahanda at pagpapatupad ay hindi friction

Isang desisyon sa disenyo ang karapat-dapat ng direktang depensa: ang paghihiwalay ng paghahanda ng transaksyon mula sa pag-sign at broadcasting. Ito ay kadalasang tinatanggal sa maraming sistema na sinusubukang gawing mas seamless ang mga agent.

Ang instinct ay pagsamahin ang mga ito sa isang hakbang dahil ito ay tila mas epektibo. Ngunit ang agwat sa pagitan ng paghahanda at broadcast ay eksaktong kung saan nababagay ang institutional oversight. Dito sinusuri ng compliance officer kung ano ang gagawin ng isang agent bago pa ito malaman ng chain, dito sinusuri ng RAMS mandate check ang inihandang payload laban sa aktibong saklaw, value caps, at hurisdiksyon bago pa man makagawa ng anumang signature, at dito aprubahan ng CFO ang treasury action na inihanda na ng agent ngunit hindi pa nakumpleto.

Maraming institusyon na nag-deploy ng autonomous agents sa makabuluhang sukat ay kalaunan muling binubuo ang paghihiwalay na ito kapag natuklasan nilang wala ito. Ang pagbuo nito bilang isang sinadyang architectural primitive sa halip na isang retrofit na nagdadala ng sistema sa unang compliance review.

Ano ang hitsura ng stack kapag ito ay kumpleto

Kapag ang lahat ng apat na layer ay nasa lugar, sila ay nagko-compose nang maayos. Ang ERC-8004 ay nag-aanchor ng agent identity at on-chain reputation, at ang ERC-8226 ay nagdadagdag ng mandate layer na naglilimita kung ano ang maaaring gawin ng bawat agent at para kanino. x402 ay humahawak ng settlement, nilalagdaan ang bawat request upang ang bawat aksyon ay maituturing at ma-audit. Sa ilalim, ang regulated asset frameworks tulad ng ERC-7943 ay nagpapatupad ng compliance sa oras ng transfer laban sa eligibility ng principal at sa aktibong mandato ng agent.

Ang mga pirasong ito ay nasa iba’t ibang antas ng maturity, ngunit wala sa kanila ang purong teoretikal. Ang ERC-8004 ay isang Draft Standards Track ERC na may deployable identity at reputation primitives. Ang ERC-7943 ay isang Final Ethereum standard. Ang ERC-8226 ay nasa standards track, at ang core interfaces ay sapat na matatag para sa maagang trabaho ng implementasyon. Ang x402 ay live na at dinisenyo na para sa programmatic HTTP payments para sa mga tao at mga agent.

Ang mga team na makakakuha nito nang tama ay maaaring magtayo patungo sa stack na ito ngayon o maghintay hanggang ang pressure mula sa audit at compliance ay magpilit ng retrofit. Ang mga institusyon na makakakuha nito nang tama ay magiging yaong mga nagtratrato sa mandate at identity layers bilang infrastructure requirements mula sa unang araw, katulad ng pagtrato nila sa KYC at custody. Maaaring hindi pa tahasang hinihingi ng mga regulator ang bawat bahagi nito. Ang mga team na nagtatayo ng production systems sa espasyong ito ay alam na kung gaano kamahal ang pagdagdag ng mga kontrol na ito pagkatapos.