Why are there so many obstacles to implementing AI agents on the blockchain?

Written by: Zack Pokorny

Translated by: Chopper, Foresight News

The deployment of AI agents on blockchain has not gone smoothly; although blockchain features programmability and permissionless access, it lacks the semantic abstraction and coordination layer suitable for intelligent agents. A research report from crypto research firm Galaxy points out that agents face four major structural frictions on-chain: opportunity discovery, trusted verification, data reading, and execution flow. Existing infrastructure is still designed around human interaction, making it difficult to support AI autonomous asset management and strategy execution. These are the core bottlenecks for large-scale deployment of agents on blockchain. Below is the full report translation:

The application scenarios and capabilities of AI agents have begun to evolve. They are starting to autonomously execute tasks, and are being developed to hold and configure capital, discover trading and yield strategies. Although this experimental shift is still in its very early stages, it is markedly different from previous development patterns where agents mainly served as social and analytical tools.

Blockchain is becoming a natural testing ground for this evolution. It is permissionless, composable, has an open-source application ecosystem, openly shares data with all participants, and all on-chain assets are by default programmable.

This raises a structural question: if blockchain is programmable and permissionless, why do autonomous agents still face friction? The answer is not whether execution is feasible, but how much semantic and coordination burden exists on top of execution. Blockchain guarantees the correctness of state transitions, but generally does not provide native abstractions for economic interpretation, identity normalization, or goal-level coordination.

Some friction stems from architectural flaws of permissionless systems; others reflect the current state of tools, content management, and market infrastructure. In fact, many upper-layer functions still rely on software and workflows that require manual operation.

Blockchain architecture and AI agents

Blockchain is designed around consensus and deterministic execution, not semantic interpretation. It exposes primitives like storage slots, event logs, and call traces, rather than standardized economic objects. Therefore, concepts like positions, yields, health factors, and liquidity depth often need to be reconstructed off-chain via indexers, data analysis layers, front-end interfaces, and APIs, transforming protocol-specific states into more user-friendly forms.

Many mainstream DeFi operations—especially those aimed at retail and subjective decision-making—still revolve around user interactions via front-end interfaces and signing individual transactions. This user-interface-centric model has expanded with the proliferation of retail users, even though a significant portion of on-chain activity is machine-driven. The current dominant retail interaction pattern remains: intention → user interface → transaction → confirmation. Programmatic operations follow a different path but have their own limitations: developers select contracts and asset sets during the build phase, then run algorithms within this fixed scope. Neither model can adapt to systems that need to dynamically discover, evaluate, and compose operations at runtime based on changing goals.

When infrastructure optimized for transaction verification is used for systems that also need to interpret economic states, evaluate credit, and optimize behaviors around clear goals, friction begins to appear. Part of this gap stems from the permissionless, heterogeneous design of blockchain; another part from the current tools, content management, and market infrastructure that are still built around manual review and front-end mediation.

Comparison of agent behavior flow and traditional algorithmic strategies

Before exploring the gap between blockchain infrastructure and agent systems, it’s necessary to clarify: what distinguishes behavior flows with greater intelligence and autonomy from traditional on-chain algorithmic systems?

The difference is not in automation level, complexity, parameterization, or even adaptive capabilities. Traditional algorithmic systems can be highly parameterized, capable of discovering new contracts and tokens, allocating funds across strategies, and rebalancing based on performance. The real difference lies in whether the system can handle unforeseen scenarios during the build phase.

Traditional algorithms, no matter how complex, only execute predefined logic for preset patterns. They require predefined parsers for each protocol, evaluation logic that maps contract states to economic meanings, explicit rules for credit and standardization judgments, and hardcoded decision branches. When encountering unfamiliar situations, they either skip or fail outright. They cannot reason about unknown scenarios, only determine if the current situation matches known templates.

Like a “digesting duck” mechanical device that mimics biological behavior but with all actions pre-programmed.

A traditional algorithm scanning DeFi lending markets can recognize familiar events or newly deployed contracts matching known patterns. But if a new lending component with an unfamiliar interface appears, the system cannot evaluate it. Human review is needed: inspecting the contract, understanding its mechanics, judging whether it’s an exploitable opportunity, and writing integration logic. Only then can the algorithm interact with it. Humans interpret; algorithms execute. Agent systems based on foundational models change this boundary. They can, through learned reasoning, achieve:

• Interpreting vague or incomplete goals, such as “maximize yield while avoiding excessive risk,” which requires semantic understanding. How is “excessive risk” defined? How to balance yield and risk? Traditional algorithms need precise definitions in advance, but agents can interpret intent, make judgments, and optimize their understanding based on feedback.

• Generalizing to unfamiliar interfaces. Agents can read unknown contract code, parse documentation, or analyze binary interfaces of unseen applications, inferring their economic functions. They don’t need pre-built parsers for each protocol. Although this capability is still imperfect and may misjudge content, it can attempt to interact with systems unforeseen during development.

• Reasoning under uncertainty about trust and standardization. When credit signals are fuzzy or incomplete, foundational models can probabilistically weigh signals rather than applying binary rules. Is this smart contract standardized? Is this token legitimate based on current evidence? Traditional algorithms follow fixed rules or are powerless; agents can reason about confidence levels.

• Explaining errors and adjusting. When unexpected situations occur, agents can infer root causes and decide how to respond. In contrast, traditional algorithms only execute exception handling modules, forwarding errors without interpretation.

These capabilities are real but imperfect today. Foundation models may hallucinate, misjudge content, and make seemingly confident but incorrect decisions. In adversarial, capital-involving environments (where code controls or receives assets), “trying to interact with unforeseen systems” could mean financial loss. The core point is not that agents can reliably perform these functions now, but that they can attempt them in ways that traditional systems cannot, and future infrastructure can make these attempts safer and more reliable.

This difference should be viewed as a continuum rather than a strict binary classification. Some traditional systems will incorporate learned reasoning; some agents may rely on hardcoded rules at critical paths. The distinction is directional, not absolute. Agent systems will shift more interpretive, evaluative, and adaptive work to runtime reasoning rather than pre-set rules during construction. This is crucial for understanding friction, because what agents attempt to do is precisely what traditional algorithms avoid. Traditional algorithms sidestep discovery of friction by human filtering during build, maintaining whitelists, using pre-built parsers, and operating within predefined safety boundaries. Humans pre-define semantics, credit, and strategy layers; algorithms operate within fixed scopes. Early on, on-chain agent workflows may follow this pattern, but the core value of agents lies in shifting discovery, credit assessment, and strategy evaluation to runtime reasoning, not pre-construction.

They will attempt to discover and evaluate unknown opportunities, reason about standardization without hardcoded rules, interpret heterogeneous states without pre-built parsers, and execute strategy constraints around potentially fuzzy goals. Friction exists not because agents do the same as algorithms but more difficult, but because they are trying to do something fundamentally different: operate in an open, dynamic space of interpretation rather than within a closed, pre-integrated system.

Friction

Structurally, this contradiction does not stem from flaws in blockchain consensus but from the way the overall interaction stack developed around it.

Blockchain guarantees deterministic state transitions, consensus on final states, and ultimate certainty. It does not attempt to encode economic interpretation, intent verification, or goal tracking at the protocol layer. These responsibilities have always been handled by front-end interfaces, wallets, indexers, and other off-chain coordination layers, which always require human intervention.

Even experienced participants follow this design pattern. Retail users interpret states via dashboards, select operations through user interfaces, sign transactions with wallets, and informally verify results. Algorithmic trading firms automate execution but still rely on humans to filter protocols, check anomalies, and update integrations when interfaces change. In both cases, protocols only ensure correct execution; intent interpretation, anomaly handling, and opportunity adaptation are performed by humans.

Agent systems compress or eliminate this division. They must programmatically reconstruct economically meaningful states, evaluate goal progress, and verify execution results—not just confirm transactions on-chain. On blockchain, these burdens are especially prominent because agents operate in open, adversarial, rapidly changing environments where new contracts, assets, and execution paths can appear without centralized review. Protocols only guarantee transaction correctness, not that economic states are easily interpretable, contracts are standardized, execution paths match user intent, or opportunities are programmatically discoverable.

The following sections will analyze these frictions at each stage of the agent’s operational cycle: discovering existing contracts and opportunities, verifying their legitimacy, reading economically meaningful states, and executing around goals.

Opportunity discovery friction

Friction arises because DeFi’s behavioral space expands in a permissionless environment, where relevance and legitimacy are filtered by humans via social, market, and tooling layers on-chain. New protocols emerge via announcements, but also go through front-end integration, token listing, data analysis, and liquidity formation filters. Over time, these signals tend to form informal standards to distinguish which parts of the behavioral space have economic value and sufficient trustworthiness, even if this consensus is unofficial, uneven, and partly reliant on third-party and manual curation.

Agents can be provided with filtered data and credit signals, but they lack the human intuition shortcuts for interpreting these signals. From an on-chain perspective, all deployed contracts are equally discoverable. Legitimate protocols, malicious forks, test deployments, and abandoned projects all exist as call-able bytecode. Blockchain itself does not encode which contracts are important or safe.

Therefore, agents must build their own discovery mechanisms: scanning deployment events, recognizing interface patterns, tracking factory contracts (which can deploy other contracts programmatically), and monitoring liquidity formation to determine which contracts should be included in decision-making. This process is not just about finding contracts but also about judging whether they should enter the agent’s behavioral space.

Identifying candidates is only the first step. After initial discovery filtering, contracts must undergo the standardization and authenticity verification processes described in the next section. Agents must first confirm that discovered contracts are genuine before including them in decision scopes.

Opportunity discovery friction is not about detecting new deployments per se. Mature algorithmic systems can already do this within their strategy scope. Monitoring Uniswap factory events and automatically adding new pools is an example of dynamic discovery. Friction appears at two higher levels: verifying whether discovered contracts are legitimate, and whether they relate to open-ended goals rather than just matching preset strategy types.

The discovery logic of a seeker is tightly coupled with its strategy. It knows what interface patterns to look for because the strategy has defined them. But an agent executing broader instructions like “configure risk-adjusted optimal opportunities” cannot rely solely on source strategy filters. It must evaluate new opportunities against the actual goals, which requires parsing unfamiliar interfaces, inferring economic functions, and judging whether the opportunity should be included in decision-making. This is a form of general autonomy, but blockchain amplifies this challenge.

Control layer friction

Control layer friction arises because identity and legitimacy verification are often performed outside the protocol, relying on filtering, governance, documentation, interfaces, and operator judgment. In many current workflows, humans remain a key part of the decision process. Blockchain guarantees deterministic execution and finality but does not guarantee that the caller is interacting with the intended contract. This intent verification is externalized into social context, websites, and manual screening.

In current processes, humans use the web’s trust layer as an informal verification method. They visit official domains (often found via DeFiLlama or project social accounts) and treat these sites as standard mappings between human concepts and contract addresses. Front-end interfaces then form a set of credible benchmarks, clarifying which addresses are official, which tokens to use, and which entry points are safe.

The 1789 mechanical Turk was a chess-playing machine that appeared autonomous but was secretly operated by a human operator.

By default, agents cannot interpret brand identities, certification signals, or “officiality” through social context. They can be fed filtered data derived from these signals, but transforming that into a durable machine trust assumption requires explicit registries, policies, or verification logic. They can be configured with operator-provided whitelists, verified addresses, and credit policies. The problem is not that social context cannot be accessed; rather, maintaining these protections in a dynamically expanding behavioral space is costly, and when these measures are absent or incomplete, agents lack fallback verification mechanisms that humans typically rely on.

On-chain agent-driven systems have already experienced real consequences from weak trust assumptions. For example, in the case of crypto influencer Orangie, an agent allegedly deposited funds into a honeypot contract. In another case, Lobstar Wilde’s agent misjudged address status due to a state or context failure, transferring large token balances to an online “beggar.” These are not core arguments but illustrate how trust failures, state misinterpretation, and execution errors can lead directly to capital loss.

The issue is not that contracts are hard to discover; rather, blockchain generally lacks the native concept of “this is the official contract of a certain application.” This absence is partly a feature of permissionless systems, not a bug, but it still creates coordination challenges for autonomous systems. This problem partly stems from weak standard identity frameworks in open architectures, and partly from immature registries, standards, and credit distribution mechanisms. An agent trying to interact with Aave v3 must determine which addresses are “standard,” whether they are upgradeable via proxies, or currently under governance change.

Humans address this through documentation, front-end interfaces, and social media. Agents must verify:

• Proxy patterns and implementation details

• Management permissions and timelocks

• Governance control parameters

• Matching deployed bytecode / application binary interfaces

Without a standard registry, “officiality” becomes an inference problem. Agents cannot treat contract addresses as static configurations. They must either maintain continuously verified whitelists, perform runtime proxy and governance checks to re-derive standard status, or risk interacting with deprecated, compromised, or counterfeit contracts. In traditional software and market infrastructure, service identity is anchored by institution-maintained namespaces, credentials, and access controls. On-chain, a contract can be callable and operational but lack standardization from the caller’s perspective.

Token authenticity and metadata pose the same problem. Tokens seem self-descriptive, but their metadata is not authoritative; it’s just byte data returned by code. A typical example is wrapped Ether (WETH). The widely used WETH contract code explicitly defines name, symbol, and decimals.

This appears to be identity, but it’s not. Any contract can set:

symbol() = WETH

decimals() = 18

name() = Wrapped Ether

and implement the ERC-20 standard interface. The functions name(), symbol(), and decimals() are just public read-only functions returning arbitrary values set by the deployer. In fact, there are nearly 200 different tokens on Ethereum claiming to be “Wrapped Ether,” with symbol “WETH,” and 18 decimals. Without consulting CoinGecko or Etherscan, how can you tell which “WETH” is the standard version?

Agents face exactly this situation. Blockchain does not verify uniqueness, does not cross-reference any registry, and imposes no restrictions. You can deploy 500 contracts today, all returning identical metadata. There are some probing methods (e.g., checking if ETH balance matches total supply, querying liquidity on major DEXes, verifying if used as collateral in lending protocols), but none provide absolute proof. Each method relies on thresholds or recursive validation of other contracts’ standardization.

Just like finding the “true” path in a maze requires external guidance, there are no native standard signals on-chain.

This is why token lists and registries exist as off-chain filtering layers. They map “WETH” to specific addresses, which is why wallets and front-end interfaces maintain whitelists or rely on trusted aggregators. For agents, the core issue is not only the low trustworthiness of metadata but also that standard identities are usually established via social or institutional layers, not protocol-native. Reliable on-chain identifiers are contract addresses, but mapping human intent like “swap for USDC” to the correct address still heavily depends on non-protocol filtering, registries, whitelists, or other credit layers.

Data friction

For agents optimizing across DeFi protocols, each opportunity must be normalized into an economic object: yield, liquidity depth, risk parameters, fee structures, oracle sources, etc. From one perspective, this is a common system integration problem. But on blockchain, heterogeneity of protocols, direct capital exposure, multi-call state stitching, and the lack of a unified economic model further complicate this burden. These are the fundamental elements needed to compare opportunities, simulate allocations, and monitor risks.

Blockchain generally does not expose standardized economic objects at the protocol level. It exposes storage slots, event logs, and function outputs, from which these objects must be inferred or reconstructed. Protocols only guarantee that contract calls return correct state values; they do not guarantee that these values can be clearly mapped to readable economic concepts, nor that the same concepts can be retrieved via a consistent cross-protocol interface.

Therefore, abstractions like markets, positions, and health factors are not protocol primitives. They are reconstructed off-chain by indexers, data analysis platforms, front-end interfaces, and APIs, transforming heterogeneous protocol states into usable abstractions. Human users typically see only this standardized layer. Agents can also use this layer but will inherit third-party assumptions, delays, and trust hypotheses; otherwise, they must reconstruct these abstractions themselves.

This problem is increasingly prominent across protocols. Vault share prices, collateralization ratios, liquidity depths in DEX pools, staking rewards—all are fundamental components with economic significance but lack standardized interfaces. Each protocol has its own retrieval methods, data structures, and conventions. Even within the same category, implementations differ.

Lending markets: a typical case of fragmented retrieval

Lending markets exemplify this issue clearly. Their economic concepts are generally uniform: supply and borrow liquidity, interest rates, collateralization ratios, credit limits, and liquidation thresholds. But the paths to access this data differ.

In Aave v3, enumerating reserves and fetching reserve states are two separate steps. Typical process:

• List reserves via a call that returns an array of token addresses.

• For each asset, fetch liquidity and interest rate data via another code snippet,

• which returns a structure with total liquidity, interest rate index, and configuration flags, e.g.:

In contrast, Compound v3 has each deployment representing a single market (USDC, USDT, ETH, etc.), with no unified reserve structure. Instead, multiple calls are needed to assemble a market snapshot:

• Utilization rate

• Total liquidity

• Interest rate

• Collateral configuration

• Global parameters

Each call returns only a subset of the economic state. “Market” is not a top-level object but an inferred structure assembled from multiple calls.

From an agent’s perspective, both are lending markets; but from an integration standpoint, they are entirely different retrieval systems. No common pattern exists. Instead, agents must adopt different enumeration methods for each protocol, stitching states through multiple calls.

Fragmentation introduces latency and consistency risks

Beyond structural differences, this fragmentation also introduces latency and consistency risks. Because economic states are not exposed as atomic, single objects, agents must perform multiple remote procedure calls across contracts to reconstruct snapshots. Each call adds delay, rate-limiting risk, and the chance of blockchain state divergence. In volatile environments, interest rates may change between fetches; if block locks are not explicitly managed, configuration parameters may correspond to different block heights than liquidity totals. Users rely on UI caches and aggregation layers to mitigate these issues indirectly. Agents directly querying raw RPCs must explicitly manage synchronization, batching, and temporal consistency. Non-standardized retrieval not only complicates integration but also limits performance, synchronization, and correctness.

Without a standardized way to retrieve economic data, even protocols with nearly identical financial primitives have state exposure that depends on implementation details. This structural heterogeneity is a core component of data friction.

Potential data mismatch

Accessing economic states on-chain is inherently pull-based, even if signals are streamed. External systems query nodes for required states rather than receiving continuous, structured updates. This reflects blockchain’s core function: on-demand verification, not maintaining application-level persistent state views.

Push primitives exist. WebSocket subscriptions can stream new blocks and event logs in real time, but these do not carry most economic state data unless explicitly redundantly published by protocols. Agents cannot directly subscribe to on-chain data like utilization rates, pool reserves, or health factors. These values are stored in contract storage, and most protocols do not provide native mechanisms to push this information downstream. The best current approach is to subscribe to new block headers and re-query on each block. Logs can hint at state changes but do not encode the final economic state; reconstructing that state still requires explicit reads and historical state access.

Agents might benefit from reverse workflows. Instead of polling hundreds of contracts for state changes, they could receive structured, precomputed state updates pushed directly into their runtime environment. Push architectures reduce redundant queries, lower latency between state changes and perception, and allow intermediate layers to package state as semantically meaningful updates rather than raw storage reads.

This reverse shift is non-trivial. It requires subscription infrastructure, filtering logic, and transforming storage changes into agent-executable economic events. But as agents become continuous participants rather than intermittent queryers, the cost of pull-based inefficiency rises. Viewing agents as persistent consumers rather than sporadic clients may better align with autonomous system operation.

Whether push-based infrastructure is truly superior remains an open question. Massive state changes can cause filtering challenges; agents still need to determine which changes are relevant, reintroducing semantic complexity at another layer. The key is not that pull architecture is inherently flawed, but that current designs do not consider persistent machine consumers. As agent usage scales, exploring alternative models may be worthwhile.

Execution friction

Execution friction arises because many current interaction layers bundle intent translation, transaction review, and result verification into workflows centered around front-end interfaces, wallets, and operator oversight. In retail and subjective decision scenarios, humans typically perform these functions. Autonomous systems must formalize and encode them directly. Blockchain guarantees deterministic execution based on contract logic but does not ensure that transactions match user intent, adhere to risk constraints, or achieve expected economic outcomes. In current workflows, user interfaces and humans fill this gap.

UI sequences (swap, approve, deposit, borrow), wallets providing final “review and send,” and operators making informal strategic judgments at the last step. They often judge safety, quotes, or acceptability under incomplete information. If a transaction fails or produces unexpected results, they retry, adjust slippage, change routes, or abandon. Agent systems remove humans from this cycle. They must replace these three human functions with machine-native equivalents:

• Intent integration. Goals like “move my stablecoins into the highest-yielding risk-adjusted platform” must be formalized into specific action plans: which protocol, which market, which token path, how much, which approvals, and execution order. Humans do this implicitly via UI; agents must do so explicitly.

• Strategy execution. Clicking “send” is not just signing; it implicitly checks whether the transaction meets constraints: slippage tolerance, leverage caps, minimum health factors, whitelisted contracts, or “no upgradable contracts.” Agents need to encode these constraints as machine-verifiable rules:

• The execution system must verify that the proposed call graph satisfies these rules before broadcasting.

• Result verification. On-chain transaction does not mean task completion. Even successful execution may not meet goals: slippage exceeds tolerance, position size is below limits, or interest rates changed between simulation and on-chain. Humans verify informally via UI; agents must evaluate post-conditions programmatically.

This introduces the need for completion checks, not just transaction inclusion. An intent-centered architecture can partly address this by shifting more of the “how” to specialized solvers: broadcasting signed intents rather than raw calls, and specifying outcome-based constraints that must be satisfied for execution to be acceptable.

Multi-step workflows and failure modes

Most DeFi operations are inherently multi-step. Yield strategies may require approval → swap → deposit → borrow → stake. Some steps are separate transactions; others can be batched via multi-call or routing contracts. Humans tolerate partial completion and continue via UI. Agents must orchestrate deterministic workflows: if any step fails, they must decide whether to retry, reroute, revert, or pause.

This gives rise to new failure modes often hidden in human workflows:

• State drift between decision and on-chain execution. Between simulation and execution, interest rates, utilization, or liquidity may change. Humans accept this variability; agents must set acceptable ranges and enforce them.

• Non-atomic execution and partial fills. Operations may span multiple transactions or produce partial results. Agents must track intermediate states and verify final states meet goals.

• Approval limits and risk of over-authorization. Humans implicitly sign approvals; agents must reason about approval scopes (limits, counterparties, durations) as part of safety policies, not just UI steps.

• Path selection and implicit execution costs. Humans rely on routing contracts and default UI settings. Agents must incorporate slippage, maximum extractable value, gas costs, and price impact into their objective functions.

Machine-native control of execution

The core argument of execution friction is that the current DeFi interaction layer relies on human wallet signatures as the final control plane. This layer carries current intent validation, risk tolerance, and informal “is this reasonable” judgments. Removing humans turns execution into a control problem: agents must translate goals into behavioral patterns, automatically enforce strategy constraints, and verify outcomes under uncertainty. This challenge exists in many autonomous systems but is especially severe on blockchain: execution directly involves capital, interacts with unfamiliar composable contracts, and is exposed to adversarial state changes. Humans rely on heuristics and trial-and-error; agents must do the same at machine speed, often in dynamic, complex environments. Therefore, “agents just submit transactions” underestimates the difficulty. Submitting transactions is the easiest part.

Conclusion

Blockchain’s original design was not to natively provide the semantic and coordination layers needed by agents. Its goal was to guarantee deterministic execution and state transition consensus in adversarial environments. The evolution of interaction layers around human interpretation, front-end operation, and manual verification reflects this foundation.

Agent systems disrupt this architecture. They remove human interpreters, approvers, and verifiers from the cycle, requiring these functions to be machine-native. This shift exposes four structural frictions: discovery, trust assessment, data access, and execution flow. These frictions are not due to infeasibility but because most infrastructure still assumes human involvement between state interpretation and transaction submission.

Bridging these gaps will likely require new multi-layered infrastructure: normalizing cross-protocol economic states into machine-readable middleware; index services or remote calls for positions, health factors, and opportunity sets; registries for standard contract mappings and token authenticity; and execution frameworks for encoding strategy constraints, handling multi-step workflows, and programmatically verifying goal completion. Some gaps stem from permissionless system features—open deployment, weak identity standards, interface heterogeneity—while others depend on current tools, standards, and incentive designs. As agent adoption grows and protocols optimize for autonomous system integration, these gaps are expected to narrow.

As autonomous systems begin managing capital, executing strategies, and directly interacting with on-chain applications, the architecture assumptions of current interaction layers will become increasingly apparent. Most of the frictions described reflect the fact that blockchain tools and interaction patterns are built around human intermediaries; some arise from permissionless openness and heterogeneity; others are common challenges faced by autonomous systems in complex environments.

The core challenge is not just enabling agents to sign transactions but providing reliable pathways for them to perform the semantic interpretation, trust assessment, and strategy execution work currently shared between software and humans.