Galaxy Report: Ang mga estruktural na pagkakabagabag ay nagtutuligsa sa mga AI Agent sa blockchain

Isinulat ni Zack Pokorny

Isinalin: Chopper, Foresight News

Hindi gaanong maayos ang pagpapatupad ng mga AI agent sa blockchain; bagaman may kakayahan ang blockchain sa pag-program at walang pahintulot, kulang ito sa semantic abstraction at collaborative layer na angkop sa mga agent. Ipinakilala ng cryptocurrency research firm na Galaxy ang isang研究报告 na nagpapakita na ang mga agent ay nakakaranas ng apat na structural friction sa chain: paghahanap ng pagkakataon,可信验证, pagbasa ng data, at proseso ng pagpapatupad. Ang kasalukuyang imprastruktura ay patuloy na disenyo para sa interaksyon ng tao, kaya't mahirap itong suportahan ang awtonomong pamamahala ng ari-arian at pagpapatupad ng estratehiya ng AI. Ito ang pangunahing hadlang sa mas malawakang pagpapatupad ng mga agent sa blockchain. Narito ang buong pagsasalin ng ulat:

Ang mga aplikasyon at kakayahan ng AI agents ay nagsisimulang umunlad. Nagsisimula na silang magpapatupad ng mga gawain nang walang tulong, at ginagawa na sila para maghawak at mag-configure ng kapital, at maghanap ng mga estratehiya sa pagtinda at kita. Bagaman ang eksperimental na pagbabagong ito ay nasa napakalaking unang yugto pa, iba na ito sa dating pag-unlad ng mga agent bilang mga kasangkapan sa sosyal at pagsusuri.

Ang blockchain ay nagsisilbing natural na test bed sa proseso ng evolusyon. Ang blockchain ay walang pahintulot, komposableng may bukas na ekosistema ng aplikasyon, pantay na pagkakaroon ng data para sa lahat ng mga participant, at ang lahat ng mga asset sa chain ay default na programmable.

Nagdudulot ito ng isang struktural na tanong: Kung ang blockchain ay programmable at walang pahintulot, bakit pa ba may friction ang autonomous agents? Ang sagot ay hindi nasa kung posible ba ang pagpapatupad, kundi sa kung gaano karaming semantic at coordination burden ang nasa ibabaw ng pagpapatupad. Pinagkakatiwalaan ng blockchain ang tamang pagbabago ng estado, ngunit karaniwang hindi ito nagbibigay ng native protocol abstraction, tulad ng para sa ekonomikong interpretasyon, pagtukoy ng identity, o coordination sa antas ng layunin.

Ang ilang pagkakaroon ng friction ay nagmumula sa mga depekto sa arkitektura ng mga sistema na walang pahintulot, at ang ilan naman ay nagpapakita ng kasalukuyang kalagayan ng mga kasangkapan, pamamahala ng nilalaman at infrastruktura ng merkado. Sa katotohanan, marami pa ring mga function sa itaas na nakadepende sa software at workflow na kailangan ng tao upang mabuo.

Ang disenyo ng blockchain ay nakabatay sa pagkakasundo at tiyak na pagsasagawa, hindi sa semantikong interpretasyon. Ito ay nagpapakita ng mga pangunahing elemento tulad ng storage slots, event logs, at call traces, hindi ng mga standardisadong ekonomikong objekto. Kaya, ang mga abstrakto tulad ng posisyon, yield, health ratio, at depth ng liquidity, karaniwang kailangang muling gawin sa labas ng chain ng mga indexer, layer ng data analysis, frontend interface, at API upang isalin ang mga estado na espesipiko sa bawat protokolo sa mas madaling gamitin anyo.

Maraming pangunahing proseso ng decentralized finance, lalo na ang mga nakatuon sa retail at desisyon-base sa pakikiramay, ay patuloy na nakabatay sa modelo kung saan ang mga user ay nag-iinteract sa pamamagitan ng frontend interface at nag-sign ng isang transaksyon. Ang modelo na nakatuon sa user interface ay lumawak kasabay ng pagtaas ng paggamit ng retail, kahit na malaki na ang bahagi ng aktibidad sa chain na hinahawakan ng mga machine. Ang kasalukuyang pangunahing paraan ng interaksyon ng retail ay: intensyon → user interface → transaksyon → pagpapatunay. Ang programmatic na operasyon ay sumusunod sa ibang landas, ngunit may sariling limitasyon: ang mga developer ay pumipili ng mga contract at asset collection sa panahon ng pagbuo, at pagkatapos ay tumatakbo ng algorithm sa loob ng fixed na saklaw. Ang dalawang modelo ay hindi kayang umangkop sa mga sistema na kailangang dinamikong hanapin, suriin, at i-combine ang mga operasyon sa runtime batay sa patuloy na nagbabagong layunin.

Kapag isang imprastruktura na disenyo para sa pag-verify ng transaksyon ay ginagamit ng isang sistema na kailangang i-interpret ang estado ng ekonomiya, i-evaluate ang kredibilidad, at i-optimize ang pag-uugali batay sa malinaw na layunin, magsisimula na ang mga friction. Ang ilang bahagi ng mga gap na ito ay nagmumula sa disenyo ng blockchain na walang pahintulot at heterogenous, at ang iba naman ay nagmumula sa mga kasangkapan sa interaksyon na patuloy pang nakabatay sa pagpapasiya ng tao at mga intermediate sa frontend.

Bago masuri ang pagkakaiba sa pagitan ng blockchain infrastructure at agent systems, mahalaga munang malinaw: ano ang pagkakaiba ng mga proseso ng pag-uugali na may mas mataas na antas ng智能化 at awtonomiya kumpara sa mga tradisyonal na algorithmic system sa chain.

Ang pagkakaiba ay hindi nasa antas ng automation, kagawian, o pagpaparametro, at kahit saan sa kakayahang umadapt nang dinamiko. Maaaring makamit ng tradisyonal na algorithmic system ang mataas na pagpaparametro, ang awtomatikong pagkilala sa mga bagong contract at bagong token, ang pagkakahati-hati ng pondo sa iba’t ibang uri ng estratehiya, at ang rebalansing batay sa performance. Ang totoong pagkakaiba ay kung ang sistema ay kayang tratuhin ang mga sitwasyon na hindi inaasahan sa panahon ng pagbuo.

Ang mga tradisyonal na algorithmikong sistema, kahit anong kumplikado man ito, ay nagpapatakbo lamang ng predefinidong lohika para sa predefinidong mga pattern. Kailangan nito ng predefinidong interface parser para sa bawat uri ng protokolo, predefinidong logic na nagmamapa ng estado ng kontrata sa ekonomikong kahulugan, malinaw na mga patakaran para sa paghuhusga ng kredito at katotohanan, at mga hard-coded na patakaran para sa bawat sangay ng desisyon. Kapag may mangyayari na hindi sumusunod sa predefinidong pattern, ang sistema ay o tumatakas o diretso nang bumubuo. Hindi ito kayang mag-isip sa mga bagong sitwasyon; kaya lamang nito ay tukuyin kung ang kasalukuyang sitwasyon ay tumutugma sa mga kilalang template.

Tulad ng mechanical device na ito na "digesting duck," na nakakapagmimithi ng mga biyolohikal na pag-uugali, ngunit lahat ng galaw ay naka-programa na sa harap.

Ang isang tradisyonal na algoritmo na nagsascan ng merkado ng DeFi lending ay maaaring makakilala ng mga bagong deployed na contract na nagpapalabas ng pamilyar na event o tumutugma sa kilalang factory pattern. Ngunit kung may lumabas na isang bagong uri ng lending infrastructure na may kakaibang interface, hindi makakapag-evaluate ang sistema nito. Kailangan ng tao na suriin ang contract, maintindihan kung paano ito gumagana, matukoy kung ito ay isang oportunidad na maaaring i-exploit, at isulat ang integration logic. Pagkatapos nito, maaaring mag-interactive na ang algoritmo. Ang tao ang responsable sa pagpapaliwanag, habang ang algoritmo ang responsable sa pagpapatupad. Ang mga sistema ng agent batay sa base model ay nagbabago sa hangganan na ito. Maaari nilang maabot ang:

• Ibigay ang interpretasyon sa mga layunin na ambiguo o hindi kumpleto. Ang mga utos tulad ng “maximize ang kita ngunit iwasan ang sobrang panganib” ay nangangailangan ng semantic interpretation. Ano ang itinuturing na sobrang panganib? Paano dapat i-balance ang kita at panganib? Kailangan ng tradisyonal na algorithm na tukuyin nang eksakto ang mga kondisyong ito sa harap. Ang agent naman ay kayang i-interpret ang intensyon, gumawa ng desisyon, at i-optimize ang sariling pag-unawa batay sa feedback.
• Kakayahan na mag-generalize at mag-adjust sa mga bagong interface. Ang agent ay makakabasa ng kahit anong kahit anong code ng contract, maaaring i-parse ang dokumentasyon, o tingnan ang application binary interface na hindi pa nakikita, at makakapaghula ng ekonomikong pagpapatakbo ng sistema. Hindi kailangan ng agent na bumuo ng parser para sa bawat uri ng protocol. Bagaman ang kakayahang ito ay hindi pa lubos na maayos at maaaring mali ang agent sa pagpapahalaga sa mga nakikita nito, maaari pa rin itong subukan ang pakikipag-ugnayan sa mga sistema na hindi inaasahan sa pagbuo.
• Mag-isip sa pagkakaroon ng kakaibang kalagayan sa tiwala at regulasyon. Kapag ang mga signal ng kredibilidad ay malabo o hindi kompletong, ang pangunahing modelo ay maaaring magbigay ng probabilidad sa mga signal, hindi lamang mag-apply ng mga patakaran na binarily. May standard ba ang smart contract na ito? Batay sa umiiral na ebidensya, legal ba ang token na ito? Ang tradisyonal na algoritmo ay o may mga patakaran o walang paraan; ngunit ang agent ay maaaring mag-isip tungkol sa antas ng kumpiyansa.
• Ipaliwanag ang error at gawin ang mga disyerto. Kapag nangyayari ang hindi inaasahang sitwasyon, ang agent ay makakapag-isip ng pinagmulan ng problema at makakapag-decide kung paano makikisigla. Sa kabilang banda, ang tradisyonal na algorithm ay nagpapatakbo lamang ng module para sa paghuhuli ng anomaly, kung saan ito ay nagpapadala lamang ng impormasyon sa anomaly, nang hindi nagpapaliwanag.

Ang mga kakayahan na ito ay totoo ngayon ngunit hindi perpekto. Ang mga pangunahing modelo ay nagkakaroon ng mga halusinasyon, mali ang pagtataya ng mga nilalaman, at gumagawa ng mga mali na desisyon na tila sigurado. Sa isang makapag-ugnay at may kapital na kapaligiran (kung saan ang code ay maaaring kontrolin o tumanggap ng mga aset), ang "pagsubok at pag-ugnay sa mga hindi inaasahang sistema" ay maaaring magmean ng pagkawala ng pondo. Ang pangunahing punto ng artikulong ito ay hindi na ang mga agent ay kayang mag-execute nang maaasahan ang mga ganitong tungkulin ngayon, kundi na sila ay kayang mag-subok sa paraan na hindi kayang gawin ng tradisyonal na sistema, at ang mga susunod na imprastruktura ay maaaring gawing mas ligtas at mas maaasahan ang mga pagsubok na ito.

Dapat itong tingnan bilang isang tuloy-tuloy na estado, hindi bilang isang tiyak na hangganan. Ang ilang tradisyonal na sistema ay maaaring maglalaman ng anyo ng natutunang pag-iisip, habang ang ilang mga agent ay maaaring magdepende sa mga hard-coded na patakaran sa kanilang pangunahing daan. Ang pagkakaiba ay direksyonal, hindi tiyak na binomial. Ang mga agent system ay naglalagay ng higit pang pag-interpret, pag-evaluate, at pag-adapt sa runtime reasoning, kaysa sa mga nakapre-set na patakaran sa build phase. Mahalaga ang punto na ito sa pag-uusap tungkol sa friction, dahil ang layunin ng agent system ay ang gawin ang mga bagay na buong buo ay iiwasan ng tradisyonal na algorithm. Ang mga tradisyonal na algorithm ay iiwas sa paghahanap ng friction sa pamamagitan ng pagpili ng set ng contract sa build phase; iiwas sa control-layer friction sa pamamagitan ng paggamit ng whitelist na pinapanatili ng operator; iiwas sa data friction sa pamamagitan ng paggamit ng pre-built parsers para sa mga kilalang protocol; at iiwas sa execution friction sa pamamagitan ng pagpapatakbo sa loob ng nakapre-set na seguridad boundaries. Ang tao ang nagawa ang semantic, credit, at strategic work nang maaga, habang ang algorithm ay nagpapatupad lamang sa mga limitadong saklaw. Ang mga unang on-chain agent behavior workflows ay maaaring sumunod sa pattern na ito, ngunit ang pangunahing halaga ng agent ay ang paglipat ng discovery, credit, at strategic evaluation sa runtime reasoning, hindi sa pre-set na build phase.

Sasagutin nila ang paghahanap at pagsusuri ng mga bagong pagkakataon, ang pag-iisip tungkol sa standard na may walang hardcoded na patakaran, ang pagpapaliwanag ng mga heterogenous na estado nang walang pre-set na parser, at ang pagsasagawa ng mga constraint ng estratehiya sa mga posibleng ambigong layunin. Ang pagkakaroon ng friction ay hindi dahil ang mga agent ay gumagawa ng parehong bagay tulad ng algorithm ngunit mas mahirap, kundi dahil sila ay sumusubok gumawa ng magkakaibang bagay: gumagana sa isang bukas, dinamikong interpretadong espasyo ng pagkilos, hindi sa isang sarado, nauna nang i-integrate na sistema.

Sa structural level, ang kontradiksyong ito ay hindi nagmumula sa kakulangan ng blockchain consensus, kundi sa paraan ng pagpapatakbo ng buong interaction stack na umiiral paligid nito.

Ang blockchain ay nagtataguyod ng deterministikong pagbabago ng estado, pagkakasundo sa huling estado, at pagkakataposs. Hindi ito nagtatangkang i-encode ang interpretasyon ng ekonomikong kahulugan, pag-verify ng intensyon, o pagsubaybay sa layunin sa antas ng protokolo. Ang mga responsibilidad na ito ay karaniwang inaangkop ng mga front-end interface, wallet, indexer, at iba pang mga offline na koordinasyong layer, kung saan laging kailangan ng tao na pag-uusapan.

Kahit para sa mga karanasan, ang kasalukuyang pangunahing interaksyon na modelo ay nagpapakita ng disenyo na ito. Ang mga retail investor ay nagpapaliwanag ng estado sa dashboard, pumipili ng aksyon sa user interface, at nagpapakilos ng transaksyon sa wallet, ngunit hindi pormal na tinutukoy ang resulta. Ang mga algorithmic trading firms ay nakamit ang awtomatikong pagsasagawa, ngunit nananatiling nakasalalay sa mga tao upang piliin ang koleksyon ng protocol, i-check ang anoma, at i-update ang integration logic kapag may pagbabago sa interface. Sa parehong sitwasyon, ang protocol ay nagtatanggol lamang ng tamang pagsasagawa, samantalang ang pagpapaliwanag ng intensyon, pag-handle sa anoma, at pag-adapt sa mga bagong pagkakataon ay ginagawa ng tao.

Ang mga agent system ay pinapaliit o pinupuksa ang paghahati-hati ng mga gawain na ito. Dapat nilang programahin ang pag-reconstruct ng mga estado na may ekonomikong kahalagahan, ang pag-evaluate ng pag-unlad ng mga layunin, at ang pag-verify ng mga resulta ng pagsasagawa, hindi lamang ang pagpapatotoo na nakalista ang transaksyon sa blockchain. Sa blockchain, ang mga gawain na ito ay lalong nakikita, dahil ang mga agent ay gumagana sa isang bukas, makipagkaaway, at mabilis na nagbabagong kapaligiran, kung saan ang mga bagong kontrata, aset, at mga landas ng pagsasagawa ay maaaring lumabas nang walang sentralisadong pagsusuri. Ang protocol ay nagtitiyak lamang na tama ang pagsasagawa ng transaksyon, hindi naman na madaling maunawaan ang ekonomikong estado, na may standard na mga kontrata, na sumusunod sa intensyon ng user ang mga landas ng pagsasagawa, o na maaaring ma-discover nang programado ang mga kaugnay na pagkakataon.

Ang sumusunod ay maglalakbay sa bawat yugto ng siklo ng pagpapatakbo ng agent upang maayos ang mga gawain na ito: pagkakita ng mga umiiral na kontrata at pagkakataon, pagpapatotoo ng kanilang legalidad, pagkuha ng mga estado na may ekonomikong kahalagahan, at pagpapatakbo ayon sa layunin.

Nakita ang friction

Ang pagkakaroon ng friction ay dulot ng paglalawak ng espasyo ng pag-uugali sa DeFi sa isang environment na walang pahintulot, habang ang kinalaman at legalidad ay pinipili ng mga tao sa pamamagitan ng social, market, at tool layers sa chain. Ang mga bagong protokolo ay lumalabas sa pamamagitan ng mga pahayag, at tinatanggap din sila sa mga filter layer tulad ng frontend integration, token listing, data analytics platforms, at liquidity formation. Sa paglipas ng panahon, ang mga signal na ito ay karaniwang nagiging isang praktikal na pamantayan upang matukoy kung aling bahagi ng espasyo ng pag-uugali ay may ekonomikong halaga at sapat na kapanipaniwala, bagaman ang kasunduang ito ay maaaring pormal, hindi pantay, at bahagyang nakasalalay sa third-party at manual filtering.

Maaaring bigyan ng mga piniling data at credit signals ang mga agent, ngunit hindi sila may kakayahang gumamit ng mga intuitibong shortcut na ginagamit ng mga tao para i-interpret ang mga signal na ito. Mula sa pananaw ng blockchain, lahat ng nai-deploy na contract ay may pantay na kakayahang makita. Ang mga legal na protokolo, masamang fork, test deployment, at abandoned projects ay lahat ay umiiral bilang callable bytecode. Ang blockchain mismo ay hindi nag-i-encode kung aling contract ay mahalaga o ligtas.

Kaya kailangan ng agent na bumuo ng sariling mekanismo ng pagkakakilala: i-scan ang mga deployment event, kilalanin ang mga interface pattern, i-track ang factory contracts (mga contract na kayang i-deploy ang iba pang contracts), at i-monitor ang pagkakabuo ng liquidity upang matukoy kung aling mga contract ang dapat isama sa desisyon. Ang prosesong ito ay hindi lamang paghahanap ng mga contract, kundi pagtataya kung dapat ba silang isama sa action space ng agent.

Ang pagkilala sa mga kandidato ay hanya ang unang hakbang. Pagkatapos ng pagpapaliwanag sa pamamagitan ng unang pagpili, kailangan pang pasusuriin ang mga kontrata sa pamamagitan ng proseso ng pag-verify ng kahusayan at katotohanan na nakalista sa susunod na seksyon. Dapat muna tiyakin ng agent na ang mga kontrata na natuklasan ay totoo at angkop bago ito isama sa espasyo ng desisyon.

Hindi ibig sabihin ng pagkakaroon ng friction na ang pagdetection ay tungkol sa pagmamasid sa mga bagong ipinapalabas na gawain. Ang mga matatag na algorithmic system ay nakakapag-achieve nito sa loob ng kanilang sariling estratehiya. Ang mga searcher na nagmomonitor sa mga event ng Uniswap factory at awtomatikong isasama ang mga bagong pool sa paghahanap ay nagpapakita ng dynamic discovery. Ang friction ay lumalabas sa dalawang mas mataas na antas: ang pagtukoy kung ang natuklasang contract ay legal, at kung ito ay may kinalaman sa open-ended targets, at hindi lamang tumutugma sa mga nakaprehayag na uri ng estratehiya.

Ang lohika ng paghahanap ng isang searcher ay malapit na nakabatay sa kanyang estratehiya. Alam nito kung anong mga pattern ng interface ang dapat hanapin, dahil natukoy na ng estratehiya. Ngunit ang isang agent na nagpapatupad ng mas malawak na utos tulad ng “kumpiyansa ang pinakamahusay na pagkakataon ayon sa pagsasaayos ng panganib” ay hindi maaaring mag-asa lamang sa mga filter na nagmumula sa estratehiya. Dapat niyang isusuri ang bawat bagong pagkakataon batay sa layunin mismo, kung kailangan nito ang pagpapaliwanag ng mga hindi kilalang interface, pagpapalagay sa ekonomikong punsiyon, at pagtukoy kung dapat bang isama ang pagkakataon sa espasyo ng desisyon. Ito ay bahagi ng isang pangkalahatang problema ng awtonomiya, ngunit pinabigat ng blockchain.

Control layer friction

Ang pagkakaroon ng friction sa kontrol ay nagmumula sa pagkakatukoy ng identity at legalidad na karaniwang ginagawa sa labas ng protokolo, na nagbabatay sa pagsipi, pamamahala, dokumentasyon, interface, at pagpapasya ng operator. Sa maraming kasalukuyang workflow, ang tao ay patuloy na mahalagang bahagi ng proseso ng pagtukoy. Ang blockchain ay nagtitiyak ng deterministic execution at finality, ngunit hindi ito nagtitiyak na ang caller ay nakikipag-ugnayan sa target na contract. Ang pagtukoy sa intensyon ay inilabas sa sosyal na konteksto, website, at manual na pagsipi.

Sa kasalukuyang proseso, ang mga tao ay gumagamit ng credit layer ng web bilang di-pormal na paraan ng pag-verify. Nilalayon nila ang opisyal na domain (karaniwang natutuklasan sa pamamagitan ng mga aggregation platform tulad ng DeFiLlama o mga verified social media account ng project) at isinasaalang-alang ang website bilang standard na medium na nag-uugnay sa konsepto ng tao at ang contract address. Pagkatapos, bumubuo ang frontend interface ng isang praktikal na batayan ng tiwala na nagtatakda kung aling address ang opisyal, aling token identifier ang dapat gamitin, at aling entry points ang ligtas.

Ang Mechanical Turk mula sa taong 1789 ay isang makina sa chess na tila nagpapatakbo nang sarili nito, ngunit sa katotohanan ay nakasalalay sa isang nakatago na tao na nagpapatakbo nito.

Hindi kayang i-decode ng agent ang brand identity, verified social signals, o ang "opisyalidad" batay sa sosyal na konteksto. Maaaring ipasok sa agent ang filtered data mula sa mga signal na ito, ngunit upang gawing patuloy at gamitin sa machine credit assumptions, kailangan ng malinaw na rehistro, patakaran, o lohika ng pag-verify. Maaaring i-configure ang agent gamit ang curated whitelist, verified addresses, at credit policies na ibinigay ng operator. Ang problema ay hindi lubos na hindi ma-access ang sosyal na konteksto, kundi ang pagpapanatili ng mga pagsisiguradong ito sa dinamikong paglalawak ng action space ay sobrang mataas ang gastos, at kung kulang o hindi sapat ang mga pagsisiguradong ito, kulang ang agent sa mga backup verification mechanisms na ginagamit ng tao nang default.

Ang sistemang dinudugtong ng on-chain agents ay nagsanhi ng mga tunay na epekto dahil sa mahinang pagtataya ng kredibilidad. Sa kaso ng网红 cryptocurrency blogger na si Orangie, sinasabing isinilid ng isang agent ang pera sa isang honey pot contract. Sa isang iba pang kaso, ang agent na tinatawag na Lobstar Wilde ay nagkamali sa pagtukoy sa estado ng address dahil sa isang error sa estado o konteksto, at isinapag ang malaking balanse ng token sa isang online na "tagapag-awa". Ang mga kaso na ito ay hindi pangunahing ebidensya, ngunit sapat na upang ipakita kung paano ang maling pagtataya ng kredibilidad, pagpapahalaga sa estado, at pagpaplano ng pagsasagawa ay maaaring direktang magdulot ng pagkawala ng pera.

Ang problema ay hindi kung gaano kahirap makahanap ng contract, kundi kung ang blockchain ay karaniwang walang native na konsepto na “ito ang opisyal na contract ng aplikasyon.” Ang kakulangan na ito ay bahagi ng kalikasan ng mga system na walang pahintulot, hindi isang pagkakamali sa disenyo, ngunit nagdudulot pa rin ng mga hamon sa koordinasyon sa mga awtonomong sistema. Ang problema ay bahagyang nagmumula sa mahinang standard na identity sa arkitektura ng bukas na sistema, at bahagyang nagmumula sa hindi pa sapat na pag-unlad ng register, standard, at mekanismo ng pagkakabahagi ng kredibilidad. Ang isang agent na nagtatangkang makipag-ugnayan sa Aave v3 ay kailangang matukoy kung aling mga address ang standard, at kung ang mga address na ito ay hindi maaaring baguhin, maaaring i-upgrade sa pamamagitan ng proxy, o kasalukuyang nasa estado ng paghihintay sa pagbabago sa pamamahala.

Lumalampas ang mga tao sa pamamagitan ng mga dokumento, frontend interface, at mga social media upang lutasin ang problema na ito. Dapat ng mga agent na i-verify ang mga sumusunod:

• Modelo ng代理 at mga mahahalagang puntos sa pagpapatupad
• Management Permissions and Time Lock
• Module ng pag-update ng mga parameter ng governance control
• Nakikilala ang pagkakatugma ng bytecode / ABI sa pagitan ng mga deployment

Sa kakulangan ng isang standard na registry, ang "opisyalidad" ay naging isang isyu ng pag-iisip. Ibig sabihin nito na ang mga agent ay hindi makakapag-consider ng contract address bilang isang static na konfigurasyon. O sila ay nagmamaintain ng isang whitelist na patuloy na binabale-wala, o sila ay nagrerederive ang standardidad sa runtime sa pamamagitan ng proxy at governance monitoring, o sila ay nagtatanggol sa sarili sa panganib ng pag-uugnay sa mga napabayaan, nasira, o imitadong contract. Sa tradisyonal na software at market infrastructure, ang identity ng serbisyo ay karaniwang nakabase sa namespace, credential, at access control na pinapanatili ng mga institusyon. Sa kabilang banda, sa chain, ang isang contract ay maaaring tawagan at maaaring gumana nang maayos, ngunit mula sa pananaw ng tagatawag, wala itong standardidad sa ekonomiko o negosyo.

Ang autentisidad at metadata ng token ay iisang problema. Ang mga token ay tila nakakapag-deskrisyon sa sarili. Gayunpaman, ang metadata ng token ay hindi awtoritatibo; ito ay lamang mga byte ng data na ibinabalik ng code. Isang klasikong halimbawa ay ang Wrapped Ethereum (WETH). Ang WETH contract code na malawakang ginagamit ay malinaw na tinukoy ang pangalan, simbolo, at precision.

Mukhang ito ay isang pagkilala, ngunit hindi naman. Maaaring itakda ng anumang contract:

• symbol() = WETH
• decimals() = 18
• name() = Wrapped Ether

At nagpapatupad ng parehong interface ng ERC-20 token standard. Ang name (), symbol (), at decimals () ay mga publiko lamang na read-only function na nagbabalik ng anumang nilalaman na itinakda ng tagapag-deploy. Sa katotohanan, mayroong halos 200 uri ng token sa Ethereum na may pangalan na 「Wrapped Ether」, simbolo na 「WETH」, at precision na 18 digits. Nang hindi tumitingin sa CoinGecko o Etherscan, kayo ba’y makakakilala kung alin sa mga 「WETH」 ang standard version?

Ang sitwasyon na kinakaharap ng agent ay ganito: Ang blockchain ay hindi nag-e-verify ng uniqueness, hindi nagkukumpara sa anumang rehistro, at hindi naglalagay ng anumang limitasyon. Maaari mong i-deploy ang 500 na contract ngayon, lahat ay nagbabalik ng ganap na parehong metadata. May ilang pagsusuri na eksperimental sa chain (hal., pag-check kung tumutugma ang Ethereum balance sa total supply, pag-consulta sa depth ng liquidity sa mga pangunahing decentralized exchange, pag-verify kung ito ay ginagamit bilang collateral sa lending protocol), ngunit walang isa sa kanila ang makakapagbigay ng absolute na patunay. Bawat paraan ay nagbabatay sa mga assumptions tungkol sa threshold o nag-iikot sa pag-verify ng standard ng iba pang contract.

Tulad ng paghahanap ng "totoo" na daan sa isang maliit na labirinto na nangangailangan ng panlabas na gabay, walang natatanging signal na naka-native sa chain.

Ito ang dahilan kung bakit umiiral ang listahan at rehistro ng token bilang offline filtering layer. Nagbibigay sila ng paraan upang ma-map ang konsepto ng “WETH” sa isang tiyak na address, na kung saan ang mga wallet at frontend interface ay nagpapanatili ng whitelist o nagtatagpo sa mga tiwalaang aggregation platform. Para sa mga agent, ang pangunahing problema ay hindi lamang ang mababang tiwala sa metadata, kundi ang katotohanan na ang karaniwang identity ay itinatag sa sosyal o institusyonal na antas, hindi sa protokolo mismo. Ang tiyak na on-chain identifier ay ang contract address, ngunit ang pag-map ng tao’s intent tulad ng “palitan sa USDC” sa tamang address ay nananatiling malaking depende sa non-protocol-native filtering, registry, whitelist, o iba pang layers ng credibility.

Data friction

Ang mga agent na nag-o-optimize ang allocation sa pagitan ng iba’t ibang protokolo sa DeFi ay kailangang standardisahin ang bawat pagkakataon bilang isang ekonomikong objekto: yield, depth ng liquidity, mga parameter ng panganib, istruktura ng mga bayarin, pinagmulan ng oracle, atbp. Sa isang paraan, ito ay isang karaniwang problema sa system integration. Gayunpaman, sa blockchain, ang heterogeneity ng protokolo, direkta na eksposur sa kapital, pagkakasunod-sunod ng maraming pagtawag na estado, at kakulangan ng isang magkakasunod na ekonomikong modelo sa ilalim nito ay nagpapabigat pa sa gawain. At ang mga ito ay ang mga pangunahing elemento na kailangan upang ihambing ang mga pagkakataon, simulan ang allocation, at i-monitor ang panganib.

Hindi karaniwang inilalabas ng blockchain ang mga standardisadong ekonomikong objekto sa antas ng protokolo. Ito ay naglalabas ng storage slots, event logs, at output ng mga function, kung saan kailangan ng pag-iisip o pagbuo ng mga ekonomikong objekto. Tanging pinagkakatiwalaan ng protokolo na ang bawat pagtawag sa contract ay babalik sa tamang halaga ng estado, ngunit hindi ito pinagkakatiwalaan na ang halagang iyon ay maaaring malinaw na ma-mapping bilang isang maunawaang ekonomikong konsepto, o na maaaring ma-retrieva ang parehong ekonomikong konsepto sa pamamagitan ng isang magkakasunod na interface sa iba’t ibang protokolo.

Kaya ang mga abstrakting konsepto tulad ng merkado, posisyon, at health factor ay hindi mga primitibo ng protokolo. Ibinubuo nila ng indexers, mga platform ng data analysis, frontend interfaces, at API sa offline, na nagpapalit ng heterogenous na protokolo state sa mga magagamit na abstrakson. Karaniwan lang na nakikita ng mga tao ang nakapag-iisang antas na ito. Maaaring gamitin din ng mga agent ang antas na ito, ngunit dadalhin nila ang mga modelong pang-third party, latency, at mga asumpsyon sa kredito; kung hindi, kailangan nilang ibalik ang mga abstrakson na ito.

Lumalala ang problema na ito sa iba’t ibang protokolo. Ang presyo ng bahagi ng treasury, ang ratio ng collateral sa mga market ng pagpapautang, ang depth ng liquidity sa pool ng decentralized exchange, at ang rate ng reward sa smart contract ng staking — lahat ay mga pangunahing komponenteng may ekonomikong kahalagahan, ngunit walang standard na interface na ipinapakita. Bawat uri ng protokolo ay may sariling paraan ng pagkuha, istruktura, at konvensyon sa yunit. Kahit sa loob ng iisang kategorya, may pagkakaiba sa paraan ng pagpapatupad.

Lending Market: Hanapin ang mga klasikong halimbawa ng fragmented

Malinaw na ipinapakita ng market ng pagpapautang ang problema na ito. Ang mga ekonomikong konsepto nito ay pangkalahatan at malawakang isinasaayos, tulad ng suplay at liquidity sa pagpapautang, interes, ratio ng collateral, limitasyon sa kredito, at threshold ng pag-aabuso, ngunit ang mga paraan ng pagkuha nito ay iba-iba.

Sa Aave v3, ang pag-enumera ng merkado at ang pagkuha ng estado ng reserve ay dalawang hiwalay na hakbang. Ang karaniwang proseso ay ganito:

I-list ang mga asset na nakaimbak sa pamamagitan ng pagbabalik ng array ng mga address ng token.

Para sa bawat asset, kumuha ng mga pangunahing datos tungkol sa likuididad at interes base sa ibang code snippet,

Ang paraan na ito ay bumabalik ng isang structure na naglalaman ng kabuuang likuididad, index ng interes, at mga flag ng konfigurasyon sa isang tawag, halimbawa:

Sa kumparasyon, sa Compound v3, bawat deployment ay tumutugon sa isang magkakahiwalay na merkado (USDC, USDT, ETH, atbp.) at walang isang pinagsamang reserve structure. Sa halip, kailangan mong i-puzzle ang market snapshot sa pamamagitan ng maraming function calls:

• Base utilization
• Total supply
• Interest rate
• Asset allocation for collateral
• Mga parameter ng global configuration

Bawat pagtawag ay babalik lang ng iba’t ibang subset ng ekonomikong estado. Ang "market" ay hindi isang pangunahing objekto, kundi isang inferences na istraktura na binubuo ng caller.

Mula sa pananaw ng agent, ang parehong protokolo ay mga market para sa pagpapautang; ngunit mula sa pananaw ng integrasyon, ang parehong ito ay may iba’t ibang istruktura ng sistema. Walang iisang magkakasamang modelo. Sa halip, kailangan ng agent na gamitin ang iba’t ibang paraan ng pag-enum ng mga asset para sa bawat protokolo, at i-pag-ugnay ang estado sa pamamagitan ng maraming pagtawag.

Ang pagkakawala ng mga piraso ay nagdudulot ng pagkakalantad at panganib sa konsistensya

Bukod sa hindi pagkakasunod sa istruktura, ang pagkakawala ng pagkakaisa ay nagdadala rin ng delay at panganib sa pagkakapareho. Dahil ang ekonomikong estado ay hindi ipinapakita bilang isang solong atomikong market object, kailangan ng mga agent na muli panghingi ang snapshot sa pamamagitan ng maraming remote procedure calls sa iba’t ibang contract. Bawat dagdag na call ay nagdudulot ng dagdag na delay, panganib sa rate limiting, at posibilidad ng pagkakaiba sa block. Sa mga nakakalat na kalagayan, maaaring nagsalikod na ang rate nang mabuo na ang pagkalkula ng supply rate; kung hindi ito i-lock nang malinaw sa isang block, maaaring magkakaiba ang configuration parameters mula sa kabuuang liquidity sa iba’t ibang block height. Ang mga user ay nakasalalay sa UI cache layer at aggregated backend upang hindi direkta mapabawasan ang mga problema na ito. Ang mga proxy na direktang gumagamit ng original RPC interface ay kailangang magmaneho nang eksplisito ng synchronization, batching, at time consistency. Kaya, ang di-pagkakasunod sa pamamaraan ng pagkuha ay hindi lamang nagdudulot ng kahirapan sa integration kundi limitahan din ang performance, synchronization, at kawastuhan.

Dahil sa kakulangan ng isang maayos na paraan ng pagkuha ng ekonomikong data, kahit na ang isang protokolo ay nagpapatupad ng halos parehong financial primitives, ang kanilang estado ay nakasalalay sa partikular na kalagayan at paraan ng pagkakabuo ng kontrata. Ang mga structural na pagkakaiba ay bahagi ng pangunahing komponente ng data friction.

Potential data stream mismatch

Ang pag-access sa ekonomikong estado sa blockchain ay batay sa pull pattern, kahit na ang mga signal ng pagpapatakbo ay maaaring i-stream. Ang mga panlabas na sistema ay nagtatanong sa node para sa hiniling na estado, hindi kaya na kumukuha ng patuloy at struktural na mga update. Ang pattern na ito ay nagpapakita ng pangunahing pagpapatakbo ng blockchain—pag-verify ayon sa pangangailangan, hindi pagpapanatili ng patuloy na pananaw ng estado sa antas ng aplikasyon.

Ang push-based primitives ay umiiral. Ang WebSocket subscription ay maaaring mag-stream ng mga bagong block at event logs sa real-time, ngunit ang mga ito ay hindi naglalaman ng storage state na nagdudulot ng karamihan sa ekonomikong kahalagahan, maliban kung ang protokolo ay piliing mag-redundant na mag-publish. Hindi kayang direktang subskribin ng agent ang paggamit ng lending market, ang reserve ng pool, o ang health factor ng position. Ang mga halagang ito ay naka-store sa contract storage, at karamihan sa protokolo ay walang native na mekanismo upang i-push ang mga impormasyong ito sa mga downstream user. Ang kasalukuyang pinakamahusay na pattern ay ang pag-subscribe sa mga bagong block headers at ang pag-requery sa bawat block. Ang logs ay maaaring magbigay ng paalala na maaaring magbago ang state, ngunit hindi ito encoded ang huling ekonomikong state; ang pag-reconstruct ng state ay nangangailangan pa rin ng eksplisitong pagbasa at pag-access sa historical state.

Maaaring makatanggap ang agent system ng benepisyo mula sa reverse process. Sa halip na mag-poll ng mga pagbabago sa estado ng mga kontrata, maaaring tumanggap ang agent ng structured, pre-computed state updates na diretso na ipinapadala sa runtime environment. Ang push-based architecture ay nakakabawas sa redundant na queries, nagpapababa ng latency sa pagitan ng pagbabago ng estado at pagkakaroon ng pagkakaunawa ng agent, at nagpapahintulot sa intermediate layer na i-package ang estado bilang semantic na malinaw na mga update, sa halip na hayaan ang agent na i-decode ang kahulugan mula sa orihinal na storage.

Hindi madali ang reverse shift na ito. Kailangan nito ng subscription infrastructure, lohika para sa pagpili ng kinalaman, at isang pattern na magpapalit ng mga pagbabago sa storage sa mga ekonomikong pangyayari na kayang gawin ng agent. Ngunit habang ang mga agent ay naging patuloy na mga participant at hindi na pana-panahong nagtatanong, ang gastos ng kawalan ng epektibidad ng pull model ay lalong tumataas. Maaaring mas maayos na tugma sa paraan ng paggana ng autonomous systems ang pagtingin sa mga agent bilang patuloy na mga konsyumer at hindi bilang pana-panahong client ang infrastructure.

Kung talagang mas mabuti ang push-based infrastructure ay isang hindi pa nasasagot na tanong. Ang malaking dami ng pagbabago sa estado ay nagdudulot ng mga problema sa pag-filter, at ang mga agent ay kailangan pa ring matukoy kung anong mga pagbabago ang may kinalaman, na bumabalik sa isang ibang antas sa pull-based semantics. Ang mahalaga ay hindi ang pagkakaroon ng mga problema sa pull-based architecture mismo, kundi ang kasalukuyang disenyo ng arkitektura ay hindi isinasaalang-alang ang persistent machine consumers; habang tumataas ang skala ng paggamit ng mga agent, maaaring makatwiran ang pag-aaral ng iba pang alternatibong modelo.

Execute friction

Ang pagkakaroon ng friction ay nagmumula sa pagkakasama ng pagkakasunod ng intensyon, pagsusuri ng transaksyon, at pag-verify ng resulta sa mga proseso na disenyo sa paligid ng frontend interface, wallet, at pagmamalikha ng operator. Sa mga sitwasyon na may retail users at subhektibong desisyon, ang ganitong pagmamalikha ay karaniwang ginagawa ng tao. Para sa mga autonomous na sistema, kailangang maging pormal at direkta na isulat ang mga gawain na ito. Ang blockchain ay nagtitiyak ng deterministikong pagpapatupad batay sa lohika ng kontrata, ngunit hindi ito nagtitiyak na ang transaksyon ay sumusunod sa intensyon ng user, sumusunod sa mga limitasyon sa panganib, o nakakamit ng inaasahang ekonomikong resulta. Sa kasalukuyang proseso, ang user interface at mga tao ang nagpapakita ng puwang na ito.

Serye ng mga pagkilos sa user interface (palitan, awtorisahan, i-deposito, mag-borrow), ang wallet ang nagbibigay ng huling node na 「i-verify at i-send」, kung saan karaniwan ay gumagawa ng estratehikong pagpapasya ang user o operator sa huling hakbang nang di-pormal. Madalas nilang hahatiin kung ang transaksyon ay ligtas at kung ang resulta ng quote ay tatanggapin, kahit na hindi kompletong impormasyon ang available. Kung mabigo ang transaksyon o lumabas ang hindi inaasahang resulta, ang user ay magrere-try, mag-aadjust ng slippage, magbabago ng path, o direktang tatigil sa operasyon. Ang agent system ay alisin ang tao mula sa siklo na ito. Ibig sabihin, kailangan ng system na palitan ang tatlong tungkulin ng tao sa paraang native ng machine:

• Iyong pagkakaisa. Dapat isama ang mga tao layunin tulad ng “Ilipat ang aking stablecoin sa pinakamainam na lugar para sa kinauukulan na kita pagkatapos ng pagsasaayos ng panganib” sa mga tiyak na aksyon: piliin kung anong protokolo, anong merkado, anong path ng token, anong laki, at anong mga pahintulot, at ang pagkakasunod-sunod ng pagpapatupad. Para sa mga tao, ipinapasa ang prosesong ito nang implict sa pamamagitan ng user interface; para sa mga agent, kailangang maisaayos nang pormal.
• Pagsasagawa ng estratehiya. Ang pag-click sa 「Ipadala ang transaksyon」 ay hindi lamang pag-sign, kundi isang implictong pag-check kung ang transaksyon ay sumusunod sa mga limitasyon: pagtitiyak sa slippage, maximum na leverage, minimum na health ratio, whitelist na contract, o 「prohibido ang upgradeable na contract」. Kailangan ng agent na i-encode ang mga malinaw na limitasyon ng estratehiya bilang mga rule na maaaring i-verify ng machine:
• Dapat veripikahin ng system ang ipinroposang call graph upang matiyak na sumusunod ito sa mga patakaran bago ma-broadcast.
• Pagpapatotoo ng resulta. Ang pagkakalagay ng transaksyon sa blockchain ay hindi katumbas ng pagkumpleto ng gawain. Kahit na matagumpay na isinagawa ang transaksyon, maaaring hindi pa rin matamo ang layunin: maaaring lumampas ang slippage sa toleransya, maaaring hindi makamit ang target na laki ng posisyon dahil sa mga limitasyon sa halaga, o maaaring magbago ang interes sa pagitan ng simulasyon at pagkakalagay sa blockchain. Ang mga tao ay nagpapatotoo nang di-pormal sa pamamagitan ng pagsusuri sa user interface pagkatapos. Ang mga agent ay kailangang mag-evaluate nang programado ang post-condition.

Ito ay nagdadala ng pangangailangan para sa pag-check ng pagkumpleto, hindi lamang ang simpleng paglalaman ng transaksyon. Ang arkitekturang may pagkakaintindi sa layunin ay maaaring bahagya nang lutasin ang problema sa pamamagitan ng paghahatid ng mas maraming tanggungin sa “paano” na pagsasagawa mula sa mga agent patungo sa mga espesyalisadong solver. Sa pamamagitan ng pagpapalabas ng mga nagsign na layunin kaysa sa orihinal na call data, maaaring tukuyin ng mga agent ang mga constraint batay sa resulta, na kung saan ang mga solver o mekanismo sa antas ng protokol ay kailangang matugunan upang maging tanggap ang pagsasagawa.

Multi-step workflow at fault modes

Ang karamihan sa mga operasyon sa DeFi ay likas na marami-saklaw. Ang isang pag-ayos ng kita ay maaaring kailanganin ang pagpapahintulot → pagpalit → pagdeposito → pagpapautang → pagpapakawala. Ang ilang mga hakbang ay maaaring magkakahiwalay na transaksyon, habang ang iba ay maaaring i-package sa pamamagitan ng multi-call o routing contract. Ang mga tao ay makakatanggap ng bahagyang natapos, at babalik sa user interface upang magpatuloy sa proseso. Ang mga agent naman ay kailangan ng deterministikong pag-ayos ng proseso: kung may anumang hakbang na nabigo, kailangan ng agent na magdesisyon kung i-retry, i-reroute, i-backout, o i-pause.

Nagresulta ito sa mga bagong uri ng pagkabigo na karamihan ay nakatago sa mga proseso ng tao:

• Pagkakaiba sa estado sa pagitan ng desisyon at pagkakabit sa blockchain. Sa pagitan ng simulasyon at pagsasagawa, maaaring magbago ang interes, paggamit, o likuididad. Tinatanggap ng tao ang ganitong pagbabago; kailangan ng mga agente na tukuyin ang tatanggapin na saklaw at ipatupad ito.
• Hindi atomikong pagpapatupad at parte ng pagkumpleto. Maaaring magpatupad ang ilang mga operasyon sa maraming transaksyon o magbigay ng parte lamang ng resulta. Dapat suriin ng agent ang intermediate state at tiyakin na ang final state ay tumutugma sa layunin.
• Awtorisasyon at panganib ng pagpapahintulot. Ang mga tao ay awtomatikong nagpapahintulot sa pamamagitan ng user interface; ang mga agent ay kailangang isipin ang sakop ng awtorisasyon (halaga, tagagamit, panahon) bilang bahagi ng seguridad na patakaran, hindi lamang bilang hakbang sa user interface.
• Pagsasagawa ng ruta at mga nakatagong gastos sa pagpapatupad. Ang mga tao ay nakikibatay sa mga contract ng ruta at mga default setting ng user interface. Dapat isama ng mga agent ang slippage, panganib ng maximum extractable value, gastos sa gas, at epekto sa presyo sa kanilang punsiyon ng layunin.

I-execute: Problem sa native control ng machine

Ang pangunahang argumento sa pagpapatakbo ng friction ay ang interaksyon layer ng decentralized finance ay may human wallet signature bilang huling control plane. Ang bahaging ito ang nagdudulot ng kasalukuyang pag-verify ng intensyon, pagtanggap sa panganib, at pormal na paghuhusga ng “kabutihan.” Kapag tinanggal ang tao, ang pagpapatakbo ay naging isang control problem: ang mga agent ay kailangang i-convert ang layunin sa mga pattern ng pagkilos, awtomatikong ipatupad ang mga pagsasakripisyo ng estratehiya, at i-verify ang mga resulta sa ilalim ng kawalan ng sigurado. Ang hamon na ito ay umiiral sa maraming autonomous system, ngunit ang blockchain environment ay lalong mahigpit: ang pagpapatakbo ay direktang may kinalaman sa kapital, komposisyon ng mga hindi kilalang smart contract, at eksposado sa adversarial state changes. Ang tao ay gumagamit ng heuristics upang gumawa ng desisyon at kumorekta sa mga kamalian sa pamamagitan ng trial and error. Ang mga agent naman ay kailangang gawin ang parehong trabaho sa machine speed, at karaniwan sa dinamikong nagbabagong espasyo ng pagkilos. Kaya, ang pahayag na “ang agent ay kailangan lang mag-submit ng transaction” ay nagbabawas sa kalalabasan. Ang pag-submit ng transaction ay ang pinakamadaling bahagi.

Hindi ang orihinal na layunin ng blockchain na magbigay ng semantic at collaborative layer na kailangan ng mga agent. Ang layunin nito ay magtatag ng deterministikong pagpapatupad at pagkakasundo sa pagbabago ng estado sa isang mapanganib na kapaligiran. Ang interaksyon layer na binuo sa base na ito ay umunlad sa isang modelo kung saan ang mga tao ay nagbabasa ng estado sa pamamagitan ng interface, pumipili ng mga aksyon sa pamamagitan ng frontend interface, at nagpapatotoo ng mga resulta sa pamamagitan ng manual na pagsusuri.

Ang agent system ay nagpapalit sa arkitekturang ito. Tinatanggal nito ang mga tao na nagpapaliwanag, nagpapatibay, at nagpapatotoo mula sa siklo, at nangangailangan na maging native sa machine ang mga gawain na ito. Ang pagbabagong ito ay nagpapakita ng structural friction sa apat na dimensyon: paghahanap, pagtukoy ng kredibilidad, pagkuha ng data, at proseso ng pagpapatupad. Ang mga friction na ito ay nabubuo hindi dahil imposible ang pagpapatupad, kundi dahil ang infrastraktura sa paligid ng blockchain ay karamihan sa oras ay nagtatayang may tao na nakikilahok sa pagitan ng pagpapaliwanag ng estado at pagsumbong ng transaksyon.

Upang tulungan ang mga puwang na ito, kailangan ng malaking posibilidad na itayo ang mga bagong imprastruktura sa maraming antas ng teknikal na stack: pagpaparehistro ng mga ekonomikong estado sa iba’t ibang protokolo bilang machine-readable middleware; mga serbisyo o pagpapalawak ng remote call para sa pag-index ng mga semantic primitives tulad ng posisyon, health factor, at set ng mga pagkakataon; isang rehistro na nagbibigay ng standard contract mapping at pag-verify ng autentikong token; at isang execution framework na nagpapakita ng mga pagsasabay ng patakaran, paghawak ng multi-step workflow, at pagpapapatunay ng programa para sa pagkumpleto ng mga layunin. Ang ilang mga puwang ay nagmumula sa mga structural na katangian ng mga system na walang pahintulot: open deployment, mahinang standard identity, at heterogenous interfaces. Ang iba naman ay nakadepende sa kasalukuyang mga kasangkapan, pamantayan, at disenyo ng insentibo; habang tumataas ang sukat ng paggamit ng mga agent at habang nagkakaroon ng kompetisyon ang mga protokolo upang mapabuti ang kanilang pagkakasundo sa autonomous systems, inaasahan na mabawasan ang mga puwang na ito.

Dumating ang mga aksiyon ng mga awtonomong sistema na nagsisimula na magmaneho ng kapital, magpapatupad ng mga estratehiya, at direktang makikisalamuha sa mga aplikasyon sa chain, ang mga aksiyon sa kasalukuyang interaksyon layer ay lalong magiging malinaw. Ang karamihan sa mga friction na nabanggit sa artikulong ito ay nagmumula sa pag-unlad ng mga tool at modelo ng interaksyon sa blockchain na nakabatay sa mga proseso na may tao bilang tagapamagitan; ang ilan ay nagmumula sa pagiging bukas, heterogenous, at makapaligoy ng mga sistema na walang pahintulot; at ang ilan naman ay karaniwang problema ng mga awtonomong sistema sa mga komplikadong kaligiran.

Ang pangunahing hamon ay hindi ang pagpapahintulot sa agent na lagdaan ang transaksyon, kundi ang pagbibigay sa kanila ng maaasahang paraan upang maisagawa ang semantic interpretation, credit assessment, at strategy execution na kasalukuyang hinahatian ng software at tao sa pagitan ng blockchain state at operational behavior.