Why Are AI Agents Facing So Many Obstacles in On-Chain Deployment?
TechFlow Selected TechFlow Selected
Why Are AI Agents Facing So Many Obstacles in On-Chain Deployment?
Blockchains are built for machines, not for agents.
Navigating Web3 tides with focused insightsBy Zack Pokorny
Translated by Chopper, Foresight News
Deploying AI agents on blockchains has proven challenging. Although blockchains are programmable and permissionless, they lack the semantic abstractions and coordination layers required for agents. A Galaxy research report highlights four structural frictions facing agents on-chain: opportunity discovery, trusted verification, data reading, and execution workflows. Existing infrastructure remains designed around human interaction—making it difficult to support AI-driven asset management and strategy execution. These frictions represent the core bottlenecks preventing scalable agent deployment on blockchains. Below is the full translated report:
AI agent use cases and capabilities are beginning to evolve. Agents are now executing tasks autonomously—and are being developed to hold and allocate capital, identify trading and yield strategies. Though this experimental shift remains in its earliest stages, it marks a fundamental departure from prior agent development, which focused primarily on social and analytical tools.
Blockchains are emerging as a natural testbed for this evolution. They are permissionless, composable, host open-source application ecosystems, provide equal data access to all participants, and—by default—make all on-chain assets programmable.
This raises a structural question: If blockchains are programmable and permissionless, why do autonomous agents still face friction? The answer lies not in whether execution is feasible, but rather in how much semantic and coordination burden exists *above* execution. Blockchains guarantee correctness of state transitions—but typically offer no protocol-native abstractions for economic interpretation, normative identity, or goal-level coordination.
Some friction stems from architectural limitations inherent to permissionless systems; some reflects the current state of tooling, content management, and market infrastructure. In practice, many higher-level functions still rely on software and workflows built with human operation baked in.
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—not standardized economic objects. As a result, abstractions like positions, yields, health factors, and liquidity depth must typically be reconstructed off-chain by indexers, analytics layers, frontends, and APIs—converting protocol-specific states into more usable forms.
Many mainstream DeFi workflows—especially those targeting retail users and subjective decision-making—still center on users interacting through frontends and signing individual transactions. This frontend-centric model scaled with retail adoption—even though a substantial portion of on-chain activity is already machine-driven. The dominant retail interaction pattern remains: intent → frontend → transaction → confirmation. Programmatic operations follow a different path—but come with their own constraints: developers select contracts and asset sets at build time, then run algorithms within that fixed scope. Neither model accommodates systems that must dynamically discover, evaluate, and compose operations at runtime based on shifting goals.
Friction arises when infrastructure optimized for transaction validation is used by systems needing to simultaneously interpret economic states, assess creditworthiness, and optimize behavior toward explicit goals. Part of this gap stems from blockchain design traits—permissionlessness and heterogeneity—while another part reflects how interaction tools remain built around human review and frontend intermediation.
Agent Behavior Workflows vs. Traditional Algorithmic Strategies
Before examining the gap between blockchain infrastructure and agent systems, it’s important to clarify how behavior workflows with greater intelligent autonomy differ from traditional on-chain algorithmic systems.
The distinction does not lie in automation level, complexity, parameterization—or even dynamic adaptability. Traditional algorithmic systems can be highly parameterized, automatically discover new contracts and tokens, allocate funds across multiple strategy types, and rebalance based on performance. The true difference lies in whether a system can handle scenarios *not anticipated during construction*.
No matter how complex, traditional algorithmic systems execute only pre-defined logic against pre-defined patterns. They require pre-defined interface parsers for each protocol, pre-defined evaluation logic mapping contract state to economic meaning, explicit credit and standardness judgment rules, and hard-coded rules for every decision branch. When encountering an unfamiliar pattern, the system either skips it or fails outright—it cannot reason about novel situations, only match current ones against known templates.
Like this mechanical “digesting duck” automaton, which mimics biological behavior—but all motions are pre-programmed
A traditional algorithm scanning DeFi lending markets might identify newly deployed contracts emitting familiar events or matching known factory patterns. But if a novel lending primitive with an unfamiliar interface appears, the system cannot assess it. Humans must inspect the contract, understand its mechanics, judge whether it represents a viable opportunity, and write integration logic—only then can the algorithm interact. Humans interpret; algorithms execute. Foundation-model-based agent systems shift this boundary. Through learned reasoning, they can:
- Interpret ambiguous or incompletely specified goals. Instructions like “maximize returns while avoiding excessive risk” require semantic interpretation. What counts as “excessive risk”? How should return and risk be weighed? Traditional algorithms need these conditions precisely defined upfront; agents interpret intent, make judgments, and refine understanding via feedback.
- Generalize to unfamiliar interfaces. Agents can read unfamiliar contract code, parse documentation, or examine never-before-seen application binary interfaces—and infer the system’s economic function. They don’t need pre-built parsers for every protocol. While this capability remains imperfect—and agents may misinterpret what they see—they can attempt interaction with systems unforeseen at build time.
- Reason under uncertainty about trust and normativity. When credit signals are fuzzy or incomplete, foundation models can probabilistically weigh signals instead of applying binary rules. Is this smart contract “standard”? Based on available evidence, is this token legitimate? Traditional algorithms either have a rule—or have no recourse; agents can reason about confidence levels.
- Explain errors and adjust. When unexpected events occur, agents can reason about root causes and decide how to respond. By contrast, traditional algorithms simply trigger exception handlers—forwarding error messages without interpretation.
These capabilities exist today—but imperfectly. Foundation models hallucinate, misinterpret content, and make confidently wrong decisions. In adversarial, capital-intensive environments—where code controls or receives assets—“attempting interaction with unforeseen systems” could mean losing funds. The central claim here isn’t that agents reliably perform these functions *today*, but that they *attempt* them in ways traditional systems cannot—and future infrastructure can make those attempts safer and more reliable.
This distinction is better viewed as a spectrum—not an absolute binary. Some traditional systems incorporate learned reasoning; some agents rely on hard-coded rules along critical paths. The difference is directional—not strictly dichotomous. Agent systems shift more interpretation, evaluation, and adaptation into runtime reasoning—rather than pre-set rules at build time. This point is crucial to the friction discussion, because agent systems attempt what traditional algorithms deliberately avoid. Traditional algorithms sidestep discovery friction by having humans curate contract sets at build time; bypass control-layer friction via operator-maintained whitelists; avoid data friction using pre-built parsers for known protocols; and evade execution friction by operating within pre-defined safety boundaries. Humans do semantic, credit, and strategy work upfront; algorithms execute within bounded scope. Early on-chain agent workflows may adopt this pattern—but the core value of agents lies in moving discovery, credit, and strategy evaluation into runtime reasoning—not pre-set assumptions at build time.
They will attempt to discover and evaluate unfamiliar opportunities, reason about standardness without hard-coded rules, interpret heterogeneous states without pre-built parsers, and enforce strategy constraints against potentially ambiguous goals. Friction doesn’t arise because agents do the same thing as algorithms—but harder. It arises because they attempt something fundamentally different: operating in an open, dynamically interpreted behavioral space—not a closed, pre-integrated system.
Friction
Structurally, this tension doesn’t stem from flaws in blockchain consensus—but from how the broader interaction stack built around it operates.
Blockchains guarantee deterministic state transitions, consensus on final state, and finality. They do *not* attempt to encode economic meaning interpretation, intent verification, or goal tracking at the protocol layer. These responsibilities have historically fallen to frontends, wallets, indexers, and other off-chain coordination layers—all requiring human intervention.
Even sophisticated participants reflect this design in current mainstream interaction patterns. Retail users interpret state via dashboards, select actions via UIs, sign transactions via wallets—and informally verify outcomes. Algorithmic trading firms automate execution—but still rely on human operators to curate protocol sets, investigate anomalies, and update integration logic when interfaces change. In both cases, protocols guarantee correct execution—while intent interpretation, anomaly handling, and new-opportunity adaptation remain human responsibilities.
Agent systems compress—or eliminate—this division of labor. They must programmatically reconstruct economically meaningful states, assess progress toward goals, and verify execution outcomes—not just confirm on-chain transaction inclusion. On blockchains, this burden is especially acute, because agents operate in open, adversarial, rapidly changing environments where new contracts, assets, and execution paths emerge without centralized review. Protocols guarantee correct transaction execution—but *not* that economic states are easy to interpret, contracts are standardized, execution paths align with user intent, or relevant opportunities are programmatically discoverable.
Below, we walk through these frictions along the agent’s operational cycle: discovering existing contracts and opportunities, verifying their legitimacy, retrieving economically meaningful state, and executing operations toward goals.
Discovery Friction
Friction arises because DeFi’s behavioral space expands openly in permissionless environments—while relevance and legitimacy are filtered by humans through on-chain social, market, and tooling layers. New protocols emerge via announcements—and pass through filtering layers like frontend integration, token listings, analytics platforms, and liquidity formation. Over time, these signals often coalesce into informal—but uneven—standards for distinguishing which parts of the behavioral space hold economic value and sufficient trustworthiness—though this consensus may rely partly on third parties and manual curation.
We can supply agents with filtered data and credit signals—but agents lack the intuitive shortcuts humans use to interpret them. From a blockchain’s perspective, all deployed contracts are equally discoverable. Legitimate protocols, malicious forks, test deployments, and abandoned projects all exist as callable bytecode. The blockchain itself encodes no notion of which contracts are important or safe.
Agents must therefore build their own discovery mechanisms: scanning deployment events, identifying interface patterns, tracking factory contracts (i.e., contracts that programmatically deploy others), and monitoring liquidity formation—to determine which contracts merit inclusion in their decision space. This process isn’t just about finding contracts—it’s about judging whether they belong in the agent’s behavioral space.
Identifying candidates is only step one. After initial discovery, contracts must undergo the standardness and authenticity verification processes described next. Agents must first confirm that discovered contracts truly are what they appear to be—before incorporating them into decision-making.
Discovery friction isn’t about detecting new deployments—mature algorithmic systems already do this within their strategy scope. A searcher monitoring Uniswap factory events and automatically adding new pools to its search space performs dynamic discovery. Friction emerges at two higher levels: judging whether discovered contracts are legitimate—and whether they’re relevant to open-ended goals—not merely matching predefined strategy types.
A searcher’s discovery logic is tightly coupled to its strategy. It knows what interface patterns to look for—because the strategy defines them. But an agent executing a broad instruction like “allocate to risk-adjusted optimal opportunities” can’t rely solely on strategy-derived filters. It must evaluate newly encountered opportunities *against the goal itself*—requiring parsing of unfamiliar interfaces, inference of economic function, and judgment about whether the opportunity belongs in its decision space. This is, in part, a general autonomy problem—but blockchains amplify it.
Control-Layer Friction
Control-layer friction arises because identity and legitimacy judgments happen *outside* protocols—relying on a mix of curation, governance, documentation, interfaces, and operator judgment. In many current workflows, humans remain central to this judgment. Blockchains guarantee deterministic execution and finality—but *not* that the caller is interacting with the intended contract. Intent judgment is externalized into social context, websites, and manual curation.
In current workflows, humans treat webpages’ credibility layers as informal verification. They visit official domains—often found via aggregators like DeFiLlama or verified social accounts—and treat those sites as canonical mappings between human concepts and contract addresses. Frontends then establish practical trust baselines: which addresses are official, which token identifiers to use, and which entry points are safe.
The Mechanical Turk of 1789 was a chess-playing machine appearing autonomous—but secretly operated by a hidden human
Agents cannot natively interpret brand signals, verified social cues, or “officialness” from social context. We can feed them filtered data derived from those signals—but converting that into persistent, machine-actionable credit assumptions requires explicit registries, policies, or verification logic. We can configure agents with operator-provided whitelists, verified addresses, and credit policies. The issue isn’t that social context is wholly inaccessible—but that maintaining these safeguards in a dynamically expanding behavioral space carries high operational costs—and when safeguards are missing or incomplete, agents lack the fallback verification mechanisms humans default to.
Real-world consequences of weak credit assessment already appear in on-chain agent-driven systems. In one case, an agent reportedly deposited funds into a honeypot contract associated with influencer Orangie. In another, an agent named Lobstar Wilde misjudged address state due to state or context failure—and sent large token balances to online “beggars.” These cases aren’t central arguments—but illustrate how failures in credit assessment, state interpretation, and execution strategy can directly cause financial loss.
The problem isn’t that contracts are hard to find—but that blockchains lack a native concept of “this is the official contract for X application.” This absence reflects permissionless system design—not oversight—but creates coordination challenges for autonomous systems. Partly, it stems from weak standard identity in open-system architectures; partly, from immature registries, standards, and credit-distribution mechanisms. An agent attempting to interact with Aave v3 must determine which addresses are canonical—and whether those addresses are immutable, upgradable via proxy, or pending governance changes.
Humans resolve this via documentation, frontends, and social media. Agents must instead verify:
- Proxy patterns and implementation details
- Administrative permissions and timelocks
- Governance control parameter-update modules
- Bytecode / ABI matches across known deployments
Without standard registries, “officialness” becomes a reasoning problem. That means agents cannot treat contract addresses as static configurations. They must either maintain continuously validated whitelists—or re-derive standardness at runtime via proxy checks and governance monitoring—or risk interacting with deprecated, compromised, or spoofed contracts. In traditional software and market infrastructure, service identity is anchored by institution-managed namespaces, credentials, and access controls. On-chain, a contract may be callable and functional—but lack economic or business-level standardness from the caller’s perspective.
Token authenticity and metadata pose the same issue. Tokens appear self-describing—but token metadata lacks authority. It’s merely byte data returned by code. Consider Wrapped Ether (WETH). Widely used WETH contract code explicitly defines name, symbol, and decimals.
This looks like identity—but it isn’t. Any contract can set:
- symbol() = WETH
- decimals() = 18
- name() = Wrapped Ether
and implement identical ERC-20 token standard interfaces. name(), symbol(), and decimals() are public read-only functions returning arbitrary values set by deployers. In fact, Ethereum hosts nearly 200 tokens named “Wrapped Ether,” symbol “WETH,” and 18 decimals. Without checking CoinGecko or Etherscan—can you tell which “WETH” is the canonical version?
That’s the agent’s situation. Blockchains don’t check uniqueness, validate against any registry, or impose restrictions. You can deploy 500 contracts today—all returning identical metadata. On-chain heuristics exist (e.g., checking ETH balance vs. total supply, querying DEX liquidity depth, verifying use as collateral in lending protocols)—but none provide definitive proof. Each method either relies on threshold assumptions—or recursively depends on other contracts’ standardness verification.
Like navigating a maze seeking the “true” path, on-chain there’s no native standard signal
That’s why token lists and registries exist as off-chain filtering layers. They map the concept “WETH” to specific addresses—and explain why wallets and frontends maintain whitelists or rely on trusted aggregators. For agents, the core issue isn’t just low metadata trustworthiness—but that standard identity is usually established socially or institutionally—not natively at the protocol level. The reliable on-chain identifier is the contract address—but mapping human intent like “swap to USDC” to the correct address still heavily depends on non-protocol-native filtering, registries, whitelists, or other credit layers.
Data Friction
An agent optimizing capital allocation across DeFi protocols must standardize each opportunity as an economic object: yield, liquidity depth, risk parameters, fee structures, oracle sources, etc. In one sense, this is a common systems-integration problem. But on blockchains, protocol heterogeneity, direct capital exposure, multi-call state stitching, and the underlying lack of unified economic modeling intensify this burden—precisely the elements needed to compare opportunities, simulate allocations, and monitor risk.
Blockchains rarely expose standardized economic objects at the protocol layer. They expose storage slots, event logs, and function outputs—economic objects must be inferred or reconstructed from these. Protocols guarantee that contract calls return correct state values—but *not* that those values clearly map to readable economic concepts—or that identical economic concepts can be retrieved via consistent cross-protocol interfaces.
Thus, abstractions like markets, positions, and health factors aren’t protocol primitives. They’re reconstructed off-chain by indexers, analytics platforms, frontends, and APIs—transforming heterogeneous protocol states into usable abstractions. Human users typically see only this standardized layer. Agents can use it too—but inherit third-party models, latency, and credit assumptions; otherwise, they must reconstruct these abstractions themselves.
This issue grows more pronounced across protocols. Treasury share prices, lending market collateral ratios, DEX pool liquidity depths, staking reward rates—all foundational economic components—lack standardized interfaces for exposure. Each protocol type uses its own retrieval methods, structural layouts, and unit conventions—even implementations within the same category differ.
Lending Markets: A Case Study in Fragmentation
Lending markets vividly illustrate this problem. Their economic concepts are broadly uniform—supply and borrow liquidity, interest rates, collateral ratios, borrowing limits, liquidation thresholds—but retrieval paths vary widely.
In Aave v3, market enumeration and reserve-state retrieval are two separate steps. A typical flow is:
Enumerate reserves via the following, returning an array of token addresses.
For each asset, retrieve base liquidity and rate data via another snippet,
This returns a struct containing total liquidity, rate index, and configuration flags in one call, e.g.:
In contrast, Compound v3 deploys one market per asset (USDC, USDT, ETH, etc.)—with no unified reserve struct. Instead, market snapshots require stitching together multiple function calls:
- Base utilization
- Total supply/borrow
- Interest rate
- Collateral asset configuration
- Global configuration parameters
Each call returns only a subset of economic state. “Market” isn’t a first-class object—it’s an inferred structure assembled by the caller.
To an agent, both protocols are lending markets—but as integrations, they’re entirely distinct retrieval systems. No shared pattern exists. Instead, agents must use different asset-enumeration approaches and stitch state via multiple calls per protocol.
Fragmentation Introduces Latency and Consistency Risk
Beyond structural inconsistency, fragmentation introduces latency and consistency risk. Since economic state isn’t exposed as a single atomic market object, agents must reconstruct snapshots via multiple remote procedure calls across multiple contracts. Each additional call increases latency, rate-limiting risk, and probability of block inconsistency. In volatile environments, interest rates may shift between when supply-rate calculations complete and when the transaction executes; without explicit block locking, configuration parameters may correspond to different block heights than liquidity totals. Users rely on UI caching layers and aggregated backends to indirectly mitigate these issues. Agents directly calling raw RPCs must explicitly manage synchronization, batching, and temporal consistency. Thus, non-standardized retrieval isn’t just inconvenient—it constrains performance, synchronization, and correctness.
Due to the lack of standardized economic-data retrieval schemes, even protocols implementing nearly identical financial primitives expose state differently—depending on contract specifics and composition. This structural divergence is a core component of data friction.
Potential Data-Flow Mismatches
Accessing economic state on blockchains is inherently pull-based—even though execution signals can stream. External systems query nodes for needed state—rather than receiving continuous, structured updates. This reflects blockchain’s core function: on-demand verification—not maintaining application-level persistent state views.
Push-based primitives do exist. WebSocket subscriptions can stream new blocks and event logs in real time—but these don’t include storage state carrying most economic meaning unless protocols explicitly choose redundant publishing. Agents cannot directly subscribe on-chain to lending-market utilization, pool reserves, or position health factors. These values reside in contract storage—and most protocols offer no native mechanism to push them downstream. The current best practice is subscribing to new block headers and re-querying each block. Logs only hint that state *may* have changed—but don’t encode final economic state; reconstructing it still requires explicit reads and historical state access.
Agent systems might benefit from reverse flows. Instead of polling hundreds of contracts for state changes, agents could receive structured, precomputed state updates pushed directly to their runtime environment. Push-based architecture could reduce redundant queries, lower latency between state changes and agent perception, and allow intermediate layers to package state as semantically clear updates—rather than forcing agents to interpret meaning from raw storage.
Such a reversal isn’t trivial. It requires subscription infrastructure, logic to filter relevance, and patterns to translate storage changes into agent-executable economic events. But as agents become persistent participants—not intermittent queriers—the inefficiency cost of pull-based models grows increasingly steep. Infrastructure treating agents as persistent consumers—not intermittent clients—may better suit autonomous systems.
Whether push-based infrastructure is truly superior remains an open question. Massive state-change volumes create filtering challenges—agents still need to judge which changes are relevant, reintroducing pull semantics at another layer. The key isn’t that pull-based architecture is flawed—but that current designs didn’t anticipate 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 outcome verification into workflows designed around frontends, wallets, and operator oversight. In retail and subjectively driven scenarios, this oversight is typically human. For autonomous systems, these functions must be formalized and directly encoded. Blockchains guarantee deterministic execution per contract logic—but *not* that transactions align with user intent, respect risk constraints, or achieve expected economic outcomes. In current workflows, frontends and humans fill this gap.
Frontends compose operation sequences (swap, approve, deposit, borrow); wallets provide the final “review and send” node; users or operators typically make informal strategic judgments at the final step. Often with incomplete information, they judge whether a transaction is safe or whether quoted results are acceptable. If a transaction fails or produces unexpected results, users retry, adjust slippage, change paths, or abandon altogether. Agent systems remove humans from this execution loop—meaning the system must replace three human functions with machine-native equivalents:
- Intent integration. Human goals like “move my stablecoins to the risk-adjusted highest-yield venue” must be integrated into concrete action plans: which protocol, which market, which token path, what scale, which approvals, and execution order. For humans, this happens implicitly via frontends; for agents, it must be formalized.
- Strategy execution. Clicking “send transaction” isn’t just signing—it’s implicitly checking whether the transaction satisfies constraints: slippage tolerance, leverage caps, minimum health factor, whitelisted contracts, or “no upgradeable contracts.” Agents must encode explicit strategy constraints as machine-verifiable rules:
- The execution system must verify that the proposed call graph satisfies these rules before broadcasting.
- Outcome verification. Transaction inclusion doesn’t equal task completion. Successful execution may still miss the goal: slippage may exceed tolerance, position size may fall short due to limits, or rates may shift between simulation and on-chain execution. Humans informally verify outcomes by reviewing frontends post-facto; agents must programmatically evaluate postconditions.
This introduces requirements for completion checks—not just simple transaction inclusion. Intent-centric architectures can partially solve this by shifting more “how” execution burden from agents to specialized solvers. By broadcasting signed intents—not raw call data—agents can specify result-based constraints that solvers or protocol-level mechanisms must satisfy for execution to be acceptable.
Multi-Step Workflows and Failure Modes
Most DeFi execution operations are inherently multi-step. A yield allocation may require approve → swap → deposit → borrow → stake. Some steps may be independent transactions; others may be batched via multicall or routing contracts. Humans tolerate partial completion—and return to the frontend to continue. Agents need deterministic workflow orchestration: if any step fails, the agent must decide whether to retry, reroute, roll back, or pause.
This surfaces novel failure modes mostly masked in human workflows:
- State drift between decision and on-chain inclusion. Rates, utilization, or liquidity may change between simulation and execution. Humans accept this variability; agents must define acceptable ranges and enforce them.
- Non-atomic execution and partial fills. Some operations execute across multiple transactions—or produce partial results. Agents must track intermediate states and confirm final state matches goals.
- Approval allowances and approval risk. Humans subconsciously sign approvals via frontends; agents must reason about allowance scope (amount, spender, duration) as part of security policy—not just treat it as a UI step.
- Path selection and implicit execution costs. Humans rely on routing contracts and frontend defaults; agents must incorporate slippage, maximum extractable value (MEV) risk, gas costs, and price impact into objective functions.
Execution: A Machine-Native Control Problem
The core argument behind execution friction is that DeFi’s interaction layer uses human wallet signatures as the final control plane. This step currently bears intent verification, risk tolerance, and informal “does this make sense?” judgment. Removing humans makes execution a control problem: agents must translate goals into behavioral patterns, automatically enforce strategy constraints, and verify outcomes under uncertainty. This challenge exists across many autonomous systems—but blockchain environments are especially harsh: execution directly involves capital, composes with unfamiliar contracts, and exposes agents to adversarial state changes. Humans make decisions using heuristics—and correct errors via trial and error. Agents must programatically replicate this work at machine speed—typically in dynamically shifting behavioral spaces. Thus, the notion that “agents just need to submit transactions” vastly underestimates the difficulty. Submitting transactions is the easiest part.
Conclusion
Blockchains weren’t designed to natively provide the semantic and coordination layers agents need. Their design goal is guaranteeing deterministic execution and consensus on state transitions in adversarial environments. The interaction layers built atop them evolved around human users interpreting state via interfaces, selecting actions via frontends, and verifying outcomes via manual review.
Agent systems disrupt this architecture. They remove human interpreters, approvers, and verifiers from the loop—requiring those functions to become machine-native. This shift exposes structural friction across four dimensions: discovery, credit assessment, data acquisition, and execution workflows. These frictions arise not because execution is impossible—but because infrastructure around blockchains still largely assumes human participation between state interpretation and transaction submission.
Bridging these gaps will likely require new infrastructure across multiple stack layers: middleware normalizing cross-protocol economic state into machine-readable formats; indexing services or RPC extensions for semantic primitives like positions, health factors, and opportunity sets; registries providing standard contract mapping and token authenticity verification; and execution frameworks encoding strategy constraints, handling multi-step workflows, and programmatically verifying goal completion. Some gaps stem from structural traits of permissionless systems: open deployment, weak standard identity, interface heterogeneity. Others depend on current tooling, standards, and incentive design—and may narrow as agent usage scales and protocols compete to optimize integration friendliness for autonomous systems.
As autonomous systems begin managing capital, executing strategies, and interacting directly with on-chain applications, the architectural assumptions of current interaction layers will grow increasingly apparent. Most frictions described here reflect how blockchain tooling and interaction patterns evolved around human-mediated workflows; some stem from the openness, heterogeneity, and adversarial nature of permissionless systems; and others are universal challenges for autonomous systems operating in complex environments.
The core challenge isn’t getting agents to sign transactions—it’s providing them reliable pathways to perform the semantic interpretation, credit assessment, and strategy execution currently shared between software and human judgment in the gap between blockchain state and operational behavior.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@galaxyhq
