Why AI Agents Hit Snags Onchain

Introduction

The use cases for and abilities of AI agents have begun to evolve. They are beginning to execute tasks autonomously and are being developed to hold and invest capital and discover trading and yield strategies. While still in the earliest days of the experimental shift, this looks much different than past developments where agents were mostly social and analytical tools.

Blockchains are serving as a natural experimentation ground for this evolution to occur. They are permissionless, composable (i.e., the same execution canvas houses applications of all financial primitives), contain ecosystems of open-source applications, offer data equally accessible to any participant, and all assets onchain are programmable by default.

This raises a structural question. If blockchains are programmable and permissionless, why should autonomous agents face friction at all? The answer lies not in whether execution is possible, but in how much semantic and coordination burden sits above execution. Blockchains guarantee correctness of state transitions, but they do not generally provide protocol-native abstractions for economic interpretation, canonical identity, or objective-level orchestration.

Some of the resulting friction is architectural to permissionless systems, while some reflects the current state of tooling, curation, and market infrastructure. In practice, many of those upper-layer functions are still mediated by software and workflows built with human operators in the loop.

Blockchain Architecture and AI Agents

Blockchains are designed around consensus and deterministic execution, not semantic interpretation. They expose low-level primitives such as storage slots, event logs, and call traces rather than standardized economic objects. As a result, abstractions such as positions, yields, health factors, and liquidity depth are typically reconstructed offchain by indexers, analytics layers, front ends, and APIs that normalize protocol-specific state into more usable forms.

Many mainstream DeFi action flows, especially retail and discretionary ones, are still organized around a user interacting through a front end to sign discrete transactions. This UI-centric model scaled with retail adoption, even as a substantial share of onchain activity has been machine-driven. The dominant retail interaction pattern remains intent → UI → transaction → confirmation. Programmatic activity follows a different path but with its own constraints: developers select contract and asset sets at build time, then run algorithms over that fixed scope. Neither model accommodates systems that must discover, evaluate, and compose actions at runtime relative to an evolving objective.

Friction begins to surface when infrastructure optimized for transaction verification is used by systems that must also interpret economic state, evaluate trust, and optimize actions relative to an explicit objective. Some of that gap is specific to blockchains’ permissionless and heterogeneous design, while some reflects tooling that still packages blockchain interaction around human review and front-end mediation.

Agentic Action Flows vs. Traditional Algorithmic Strategies

Before examining the gap between blockchain infrastructure and agentic systems, it is worth clarifying what distinguishes more agentic action flows from more traditional onchain algorithmic systems.

The distinction is not automation, sophistication, parameterization, or even dynamic adaptation. Traditional algorithmic systems can be highly parameterized, auto-discover new contracts and tokens, allocate across multiple strategy types, and rebalance based on performance. The distinction is whether the system can handle situations that were not anticipated at build time.

Traditional algorithmic systems, no matter how sophisticated, execute pre-specified logic over patterns they are developed to anticipate. They require predefined interface parsers for each protocol type, predefined evaluation logic mapping contract state to economic meaning, explicit heuristics for trust and canonicality, and hardcoded rules (independent of how dynamic and adaptive the algorithm is) for every decision branch. When something does not match an anticipated pattern, the system either skips it or fails. It cannot reason about an unfamiliar situation; it can only check whether the situation matches a known template.

Mechanical automata like this “digesting duck” could mimic lifelike behavior, but every action was scripted in advance. (Scientific American, January 1899)

A traditional algo scanning for new lending markets can detect a deployment that emits familiar events or matches a known factory pattern. But if a novel lending primitive appears with an unfamiliar interface, the system has no way to evaluate it. A human must inspect the contract, understand its mechanics, decide whether it belongs in the opportunity set, and write integration logic. Only then can the algo interact with it. The human performs the interpretation; the algo performs the execution. Agentic systems based on foundation models change this boundary. They can use learned reasoning to:

• Interpret ambiguous or underspecified objectives. A directive like "maximize yield but avoid excessive risk" requires interpretation. What counts as excessive? How should yield and risk be traded off? A traditional algo needs these terms defined precisely in advance. A foundation model can interpret the intent, apply judgment, and refine its interpretation based on feedback.

• Generalize to novel interfaces. An agent can read unfamiliar contract code, parse documentation, or inspect an application binary interface (ABI) it has never seen and infer the economic function of the system. It does not require a pre-built parser for every protocol type. This capability is not perfect today because the agent can misinterpret what it sees, but it can attempt engagement with systems that were not anticipated at build time.

• Reason under uncertainty about trust and canonicality. When trust signals are ambiguous or incomplete, a foundation model can weigh them probabilistically rather than applying a binary rule. Is this smart contract likely canonical? Is this token likely legitimate given the available evidence? Traditional algos either have a rule or they do not; agents can reason about confidence.

• Interpret errors and adapt. When something unexpected happens (e.g., a transaction reverts, an output does not match expectations, state changes between simulation and execution) an agent can reason about what went wrong and decide how to respond. A traditional algo, by contrast, executes a catch block. It routes exceptions rather than interpreting them.

These capabilities are real but imperfect today. Foundation models hallucinate, misinterpret, and make confident errors. In environments that are adversarial and capital-bearing (i.e., code controls or can receive assets), "attempting engagement with systems that were not anticipated" can mean losing money. The thesis is not that agents will reliably perform these functions today, but that they can attempt them in ways traditional systems cannot, and that in time infrastructure could make those attempts safer and more reliable. This is better understood as a continuum than a categorical divide. Some traditional systems incorporate forms of learned reasoning, and some agents may rely on hardcoded rules for critical paths. The distinction is directional and not binary. Agentic systems push more of the interpretation, evaluation, and adaptation into runtime reasoning rather than build-time specification. This matters for the friction thesis because agentic systems are attempting to do things that traditional algos sidestep entirely. A traditional algo avoids discovery friction by having humans curate the contract set at build time. It avoids control-plane friction by relying on operator-maintained allowlists. It avoids data friction by using pre-built parsers for known protocols. It avoids execution friction by operating within pre-specified safety bounds. The human does the semantic, trust, and policy work upfront and the algo executes within the defined perimeter. The earliest versions of onchain agentic action flows may mirror this dynamic, but the agentic thesis rests on pushing discovery, trust, and policy evaluation into runtime reasoning rather than build-time specification.

They may try to discover and evaluate unfamiliar opportunities, reason about canonicality without hardcoded rules, interpret heterogeneous state without pre-built parsers, and enforce policies against objectives that may be ambiguous. That is where the infrastructure gaps bite. The friction exists not because agents are doing the same thing as algos and finding it harder, but because they are attempting something different: operating over an open and dynamically interpreted action space rather than a closed and pre-integrated one.

The Friction

At a structural level, the tension does not arise from a flaw in blockchain consensus, but from how the broader interaction stack evolved around it.

Blockchains guarantee deterministic state transitions, shared agreement on resulting state, and eventual finality. They do not attempt to encode economic interpretation, intention validation, or objective tracking at the protocol layer. Those responsibilities have historically been externalized to front ends, wallets, indexers, and other offchain coordination layers, with a human somewhere in the loop.

The prevailing interaction model reflects this design, even for sophisticated participants. A retail user interprets state through a dashboard, selects an action through a UI, signs a transaction through a wallet, and informally verifies outcomes. An algorithmic trading operation automates execution but still relies on human operators to curate the protocol set, review anomalies, and update integrations when interfaces change. In both cases, the protocol enforces execution correctness while intent interpretation, exception handling, and adaptation to new opportunities remain human responsibilities.

Agentic systems compress or remove this division. They must programmatically reconstruct economically meaningful state, evaluate whether objectives are being advanced, and verify outcomes beyond simple transaction inclusion. These burdens become especially acute on blockchains because agents operate in open, adversarial, and rapidly changing environments where new contracts, assets, and execution paths can appear without centralized gatekeeping. The protocol guarantees that transactions execute correctly—not that economic state is easily interpretable, that contracts are canonical, that execution paths reflect user intent, or that relevant opportunities can be discovered programmatically.

The sections that follow trace this friction across the stages of an agent's operational loop: discovering which contracts and opportunities exist; verifying their legitimacy; retrieving economically meaningful state; and executing against objectives.

Discovery Friction

Discovery friction arises because the DeFi action space expands in an open and permissionless environment, while relevance and legitimacy are filtered by humans through social, market, and tooling layers above the chain. New protocols surface through announcements and research, but they are also filtered through curation layers such as front-end integrations, token lists, analytics platforms, and liquidity formation. Over time, these signals often converge into a working view of which parts of the action space are economically relevant and sufficiently trustworthy, though that convergence can be informal, uneven, and partly dependent on third-party and human-based curation.

Agents can be given access to curated data and trust signals, but they do not natively share the interpretive shortcuts humans use when navigating those signals. From an onchain perspective, every deployed contract is equally discoverable. A legitimate protocol, a malicious fork, a test deployment, and an abandoned project all appear as callable bytecode. The chain does not encode which ones matter or which ones are safe.

From an onchain perspective, every deployed contract is equally discoverable. A legitimate protocol, a malicious fork, a test deployment, and an abandoned project all appear as callable bytecode.

As a result, agents must construct their own discovery mechanisms by scanning deployment events; identifying interface patterns; tracking factory contracts (those that deploy other contracts programmatically); and monitoring liquidity formation to determine which contracts should enter their decision universe. This process is not just about finding contracts, but about determining whether they belong in the agent’s action space at all.

Identifying a candidate is only the first step. Once a contract passes initial discovery filters, it becomes subject to the canonicality and authenticity verification processes described in the following section. The agent must confirm that the discovered contract is what it claims to be before incorporating it into the decision space.

Strategy-Scoped Discovery Is Different Than Open-Ended Discovery

Discovery friction is not about detecting new deployments. Sophisticated algorithmic systems already do this within their strategy perimeter. A searcher monitoring Uniswap factory events and incorporating new pools automatically, is performing dynamic discovery. The friction arises at two higher levels: determining whether a discovered contract is legitimate (a canonicality problem addressed in the following section) and determining whether it is relevant to an open-ended objective rather than a predefined strategy type.

A searcher's discovery logic is tightly coupled to its strategy. It knows what interface patterns to look for because the strategy defines them. An agent operating under a broader mandate like "allocate to the best risk-adjusted opportunities" cannot rely only on strategy-derived filters. It must evaluate newly encountered opportunities against the objective itself, which requires parsing unfamiliar interfaces, inferring economic function, and deciding whether the opportunity belongs in the decision space. That is partly a general autonomy problem, but blockchains intensify it by making unfamiliar code immediately executable, capital-bearing, and difficult to classify from protocol-native signals alone.

Control Plane Friction

Control-plane friction arises because identity and legitimacy are often resolved outside the protocol through a mix of curation, governance, documentation, interfaces, and operator judgment. In many current workflows, humans remain an important part of that resolution process. Blockchains guarantee deterministic execution and finality, but they do not guarantee that a caller is interacting with the intended contract. That intent resolution is externalized to social context, websites, and curation.

In today’s flow, humans use the web’s trust layer as an informal verifier. They navigate to an official domain, often discovered through an aggregator like DeFiLlama or a project’s verified social account, and treat that site as the canonical mapping between human concepts and contract addresses. The front end then encodes a working source of truth for which addresses are official, which token representation to use, and which entry points are safe.

The chess-playing Mechanical Turk (1789) appeared autonomous but relied on a hidden human operator. (Humboldt University Library)

Agents do not interpret branding, verified social signals, or “officialness” through social context by default. They can be given curated inputs derived from those signals but turning them into durable machine-usable trust assumptions requires explicit registries, policies, or verification logic. Agents can be given curated allowlists, verified addresses, and trust policies by operators. The issue is not that social context is entirely inaccessible, but that maintaining those guardrails across a dynamically expanding action space is operationally burdensome, and that when they are absent or incomplete, agents lack the fallback verification mechanisms humans use implicitly.

The practical consequences of weak trust resolution have already appeared in agent-driven systems onchain. In the case of YouTuber and crypto influencer Orangie, an agent reportedly deposited funds into a honeypot contract. In another, an agent known as Lobstar Wilde transferred a large token balance to an online “beggar” after a state or context failure led it to misinterpret its address state. These examples are not the core argument, but they illustrate how failures in trust resolution, state interpretation, and execution policy can translate into immediate losses.

Canonical Contract Identification Is Not a Protocol Primitive

The problem is not that contracts are difficult to discover, but that there is usually no chain-native notion of “this is the official contract for Application X.” That absence is partly a feature of permissionless systems rather than a design oversight, but it still creates a coordination problem for autonomous systems. Some of this problem is structural to open systems with weak canonical identity; some of it is contingent on the relative immaturity of registries, standards, and trust distribution mechanisms. An agent attempting to interact with Aave v3 must determine which addresses are canonical (Pool, Configurator, Data Providers, etc.) and whether those addresses are immutable, proxy-upgradeable, or currently under pending governance change.

Humans resolve this through documentation, front ends, and social media. Agents must resolve it by inspecting:

• proxy patterns and implementation pointers

• administrative roles and timelocks

• governance-controlled parameter update surfaces

• bytecode/ABI matching across known deployments

Absent a canonical registry, “officialness” becomes an inference problem. This means agents cannot treat contract addresses as static configuration. They must either maintain curated allowlists with ongoing verification, re-derive canonicality at runtime through proxy inspection and governance monitoring, or accept the risk of interacting with deprecated, compromised, or spoofed deployments. In traditional software and market infrastructure, service identity is usually anchored by institutionally maintained namespaces, credentials, and access controls. Onchain, by contrast, a contract can be callable, functional, and economically or operationally non-canonical from the caller’s perspective. Token Authenticity and Metadata Are the Same Problem Tokens appear to self-describe. But token metadata is not authoritative. It is just bytes returned by code. The canonical example is wrapped ether (WETH). The widely used WETH contract literally defines:

This feels like identity, but it is not. Any contract can return:

• symbol() = "WETH"

• decimals() = 18

• name() = "Wrapped Ether"

and implement the same ERC-20 token standard surface. name(), symbol(), and decimals() are just public view functions that return whatever the deployer set. In fact, there are nearly 200 tokens on Ethereum that have the name “Wrapped Ether,” the symbol “WETH,” and are divisible to the 18th decimal. Without checking CoinGecko or Etherscan, can you tell which “WETH” is the canonical one? (It’s the 78th row).

There are nearly 200 tokens on Ethereum that have the name “Wrapped Ether” and the symbol “WETH.” Without checking CoinGecko or Etherscan, can you tell which is the canonical WETH?

That is how it feels to be an agent. The chain doesn't check uniqueness, doesn't validate against any registry, and doesn't care. You could deploy 500 contracts today all returning identical metadata. Onchain heuristics exist (e.g., checking ETH balance against totalSupply(), querying liquidity depth on major decentralized exchanges (DEXs), verifying integration as collateral on lending protocols), but none provide definitive proof. Each either relies on threshold assumptions (nobody is faking billions in paired liquidity) or recursively depends on verifying some other contract's canonicality.

As in a labyrinth, identifying the “real” path onchain requires external guidance; no canonical signal is provided. (Birmingham Museum and Art Gallery)

This is why token lists and registries exist as offchain curation layers. They provide one mechanism for mapping “WETH” the concept to a specific address, which is also why wallets and front ends maintain allowlists or rely on trusted aggregators. For agents, the core issue is not merely that metadata is weak, but that canonical identity is often established socially or institutionally rather than protocol-natively. The reliable onchain identifier is the contract address, yet mapping from human-legible intent such as “swap into USDC” to the correct address still depends heavily on curation, registries, allowlists, or other trust layers that are not protocol-native.

Data Friction

An agent optimizing across DeFi protocols needs a normalized view of each opportunity as an economic object: yields, liquidity depth, risk parameters, fee structures, oracle sources, and so on. In one sense this is a familiar systems-integration problem. On blockchains, however, the burden is amplified by protocol heterogeneity, direct capital exposure, multi-call state assembly, and the absence of shared economic schemas at the base layer. These are the primitives required to compare opportunities, simulate allocations, and monitor risk.

Blockchains generally do not expose standardized economic objects at the protocol layer. They expose storage slots, event logs, and function outputs, from which economic objects must be inferred or reconstructed. The protocol guarantees that a contract call returns the correct value from state. It does not guarantee that the value maps cleanly to a legible economic concept, or that the same concept can be retrieved through a consistent interface across protocols.

As a result, abstractions such as market, position, or health factor are not protocol primitives. They are reconstructed offchain by indexers, analytics platforms, front ends, and APIs that normalize heterogeneous protocol state into usable abstractions. Human users usually see only that normalized layer. Agents can use it too, but then inherit third-party schemas, latency, and trust assumptions; otherwise, they must reconstruct the abstractions themselves.

This problem compounds across protocol categories. A vault's share price, a lending market's collateral factor, a DEX pool's liquidity depth, and a staking contract's reward rate are all economically meaningful primitives. None are exposed through standardized interfaces. Each protocol family has its own retrieval patterns, struct layouts, and unit conventions. Even within a single category, implementations diverge.

Lending Markets: A Case Study in Retrieval Fragmentation

Lending markets illustrate this problem clearly. The economic concepts are familiar and largely shared, such as supply and borrow liquidity, interest rates, collateral factors, caps, and liquidation thresholds. The retrieval paths are not.

On Aave v3, market enumeration and reserve state retrieval are separate steps. A typical flow involves the following.

Enumerating reserve assets via

which returns an array of token addresses.

For each asset, retrieving liquidity and rate primitives via

which returns a struct containing liquidity totals, rate indices, and configuration flags in a single call such as

By contrast, in Compound v3 (Comet), each deployment represents a single market (USDC, USDT, ETH, etc.), and there is no single reserve struct. Instead, a market snapshot must be constructed across multiple function calls:

Base utilization

Totals

Interest rates

Collateral asset config

Global config parameters

Each call returns a different subset of the economic state. The “market” is not a first-class object and is an inferred construct assembled by the caller.

From an agent’s perspective, both protocols are lending markets. From an integration perspective, they are structurally different retrieval systems. There is no shared schema such as

Instead, agents must enumerate assets differently per protocol, stitch state across multiple calls, normalize units and scaling conventions, and reconcile derived versus directly exposed primitives.

Fragmentation Introduces Latency and Consistency Risk

Beyond structural inconsistency, this fragmentation introduces latency and consistency risk. Because economic state is not exposed as a single atomic market object, agents must make multiple remote procedure calls (RPCs) across multiple contracts to reconstruct a snapshot. Each additional call increases latency, rate-limit exposure, and the risk of block inconsistency. In volatile environments, utilization may already have changed by the time a supply rate is computed, and configuration parameters may not reflect the same block as liquidity totals unless explicitly pinned. Humans rely on UI caching layers and aggregated backends that mitigate this implicitly. Agents operating directly against raw RPC surfaces must manage synchronization, batching, and temporal consistency explicitly. Non-standardized retrieval is therefore not just an integration inconvenience, but also a performance, synchronization, and correctness constraint.

The absence of a canonical economic retrieval schema means that even when protocols implement nearly identical financial primitives, their state exposure is contract-specific and composition-dependent. That structural divergence is a core component of the data friction.

Possible Data Flow Mismatch

Economic state access on blockchains is fundamentally pull-based, even though execution signals can be streamed. External systems query nodes for the state they need, rather than receiving continuous, structured updates. This model reflects blockchains’ core function of verification on demand rather than maintaining continuous, application-level state views.

Push-based primitives exist. WebSocket subscriptions can stream new blocks and event logs in real time, but these do not cover the storage state that carries most economic meaning, unless protocols explicitly choose to redundantly emit it. An agent cannot subscribe to a lending market's utilization rate, a pool's reserves, or a position's health factor directly through the chain. These values live in contract storage, and most protocols offer no native mechanism to push storage changes to downstream consumers. The best available pattern is to subscribe to new block headers and re-query storage on each block, which remains pull-based for state access, even if triggered by streamed events. Logs can signal that something may have changed, but they do not encode the resulting economic state; reconstructing that state still requires explicit reads and access to historical state.

Agentic systems may benefit from an inverted flow. Rather than polling for state changes across hundreds of contracts, an agent could receive structured, pre-computed state updates pushed directly into its operating context (e.g., updated utilization, health factors, or position deltas). A push-based architecture would reduce redundant queries, lower latency between state change and agent awareness, and allow an intermediary layer to package state into semantically meaningful updates rather than requiring agents to reconstruct meaning from raw storage.

This inversion is not trivial. It requires subscription infrastructure, filtering logic to determine relevance, and schemas that translate storage mutations into economic events an agent can act on. But as agents become persistent participants rather than episodic queriers, the pull model's inefficiencies—rate limits, synchronization overhead, and redundant retrieval across competing agents—become increasingly costly. Infrastructure that treats agents as continuous consumers rather than intermittent clients may better match how autonomous systems operate.

Whether push-based infrastructure is actually superior is an open question. A firehose of all state changes creates a filtering problem where agents must still decide what's relevant, which reintroduces pull semantics at a different layer. The point is not that pull is wrong, but that the current architecture was not designed with persistent machine consumers in mind, and alternative models may be worth exploring as agent usage scales.

Execution Friction

Execution friction arises because many current interaction layers package intent translation, transaction review, and outcome validation into workflows built around front ends, wallets, and operator oversight. In retail and discretionary settings, that oversight is often human. For autonomous systems, those functions must be formalized and encoded directly. Blockchains guarantee deterministic execution according to contract logic. They do not guarantee that a transaction matches the user’s intent, respects risk constraints, or achieves the desired economic outcome. In today’s flow, the UI and the human fill that gap.

The UI composes the sequence of actions (swap, approve, deposit, borrow), the wallet presents a final “review and send” checkpoint, and policy judgment is often applied informally at that last step by the user or operator. They decide, often with incomplete information, whether the transaction looks safe and whether the quoted outcome is acceptable. If it fails or produces an unexpected result, the user retries, adjusts slippage, changes routes, or abandons the action entirely. Agentic systems remove the human from this execution loop. That means the system must replace three human functions with machine-native equivalents:

1. Intent compilation. A human goal like “move my stablecoins to the best risk-adjusted yield” must be compiled into a concrete action plan: which protocol, which market, which token route, which size, which approvals, and in what sequence. For a human this happens implicitly through a UI. For an agent it must be formalized.

2. Policy enforcement. The “send transaction” click is not just a signature. It is an implicit check that the transaction respects constraints: slippage tolerance, leverage limits, minimum health factor, allowlisted contracts, or “no upgradeable contracts.” Agents need explicit policy constraints encoded as machine-checkable rules:

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

1. Outcome verification. Transaction inclusion is not task completion. A transaction can succeed and still fail the objective: slippage could exceed tolerance, the intended position size might not be reached due to caps, or a rate could move between simulation and inclusion. Humans check this informally by looking at the UI after the fact. Agents must evaluate post-conditions programmatically:

This introduces a requirement for completion checks that go beyond simple transaction inclusion. Intent-centric architectures may provide one partial bridge by shifting more of the burden of “how” from the agent to specialized solvers. By broadcasting signed intents rather than raw call data, an agent can specify outcome-based constraints that a solver or protocol-level mechanism must satisfy for execution to be acceptable.

Multi-Step Workflows and Failure Modes

A large portion of DeFi execution is inherently multi-step. A yield allocation might require approve → swap → deposit → borrow → stake. Some of these steps may be separate transactions, while others may be bundled via multicall or a router. Humans tolerate partial completion; they return to the UI and finish the flow. Agents need deterministic orchestration: if any step fails, the agent must decide whether to retry, re-route, unwind, or pause.

This creates new failure modes that are mostly masked in human flows:

• State drift between decision and inclusion. Rates, utilization, or liquidity can change between simulation and execution. Humans accept this variability; agents must define acceptable bounds and enforce them.

• Non-atomic execution and partial fills. Some actions may be executed across multiple transactions or produce partial outcomes. Agents must track intermediate state and confirm final state matches the objective.

• Allowance and approval risk. Humans sign approvals reflexively through UIs; agents must reason about approval scope (amount, spender, duration) as part of a security policy rather than as a UI step.

• Route selection and hidden execution costs. Humans rely on routers and UI defaults. Agents must model slippage, MEV risk, gas costs, and price impact as part of the objective function.

Execution as a Machine-Native Control Problem

The core execution-friction thesis is that DeFi’s interaction layer uses the human wallet signature as the final control plane. That moment is where intent validation, risk tolerance, and the informal “does this look right?” check live today. When the human is removed, execution becomes a control problem: the agent must translate objectives into action graphs, enforce policies automatically, and verify outcomes under uncertainty. That challenge exists in many autonomous systems, but blockchains make it unusually unforgiving because execution is directly capital-bearing, composable across unfamiliar contracts, and exposed to adversarial state changes. Humans make these decisions heuristically and correct mistakes through trial and error. Agents must do the same work programmatically, at machine speed, and often across a dynamically changing action space. This is why the claim that agents will “just submit transactions” undersells the difficulty. Transaction submission is the easy part. The missing layer is everything the UI and the human provide: intent compilation, safety gating, and objective-completion verification.

Conclusion

Blockchains were not designed to natively provide the semantic and coordination layers autonomous agents require. They were designed to guarantee deterministic execution and consensus over state transitions in an adversarial environment. The interaction layer that emerged on top of that foundation evolved around human users interpreting state through interfaces, selecting actions through front ends, and validating outcomes through manual review.

Agentic systems collapse that architecture. They remove the human interpreter, approver, and verifier from the loop and require those functions to become machine-native. That shift exposes structural friction across four dimensions: discovery, trust resolution, data retrieval, and execution orchestration. None of these frictions arise because execution is impossible. They arise because the infrastructure surrounding blockchains still assumes that a human sits between state interpretation and transaction submission in many cases.

Closing these gaps will likely require new infrastructure at multiple layers of the stack: middleware that normalizes economic state across protocols into machine-readable schemas; indexing services or RPC extensions that expose semantic primitives such as positions, health factors, and opportunity sets rather than raw storage; registries that provide canonical contract mappings and token authenticity; and execution frameworks that encode policy constraints, handle multi-step workflows, and verify objective completion programmatically. Some of these gaps are structural to permissionless systems with open deployment, weak canonical identity, and heterogeneous interfaces. Others are contingent on current tooling, standards, and incentive design, and may narrow as agent usage grows and protocols compete to become easier for autonomous systems to integrate.

As autonomous systems begin to manage capital, execute strategies, and interact directly with onchain applications, the architectural assumptions embedded in today’s interaction layers become more visible. Much of the friction described here reflects how blockchain tooling and interaction patterns evolved around human-mediated workflows, though some of it also follows naturally from the openness, heterogeneity, and adversarial conditions of permissionless systems, and some of it is common to autonomous systems operating in complex environments more generally.

The central challenge is not getting agents to sign transactions. It is giving them reliable ways to perform the semantic, trust, and policy functions that are currently handled across a mix of software and human judgment between raw blockchain state and action.