Intent-Based Architecture

What are the specific differences between intent-based and traditional 'instruction-based' architecture? What criteria determine which is more appropriate for your scenario?

The clearest approach is a concrete example comparison:

Traditional Instruction-Based: the user (or upper-layer of the Agent) specifies details of each operation:

1. approve(Aave, USDC, 5000)
2. swap(USDC→ETH, amount=5000, slippage=0.5%, dex=Uniswap)
3. deposit(ETH, Aave, amount=all)

Each step is a clear command; the system only needs to execute.

Intent-Based: the user just says: 'I want to exchange my 5000 USDC for ETH, deposit it in Aave to earn interest, hoping to minimize fees.' The system handles: finding the optimal USDC→ETH path (considering prices across multiple DEXs), calculating whether batch execution is needed to reduce slippage, choosing the best Aave deposit timing (when Gas fees are lowest), executing the complete operation sequence.

Selection criteria:

• Use instruction-based: task logic is fixed, no optimization needed, and the user (or Agent developer) clearly knows the optimal execution path; e.g., fixed arbitrage strategies, automated known workflows.
• Use intent-based: task objective is clear but optimal path isn't fixed (affected by market conditions), and the user wants the system to automatically find the best solution; e.g., optimal rate seeking, cross-protocol routing optimization.

The cost of intent-based architecture is 'uncertainty in execution path' — you know what you want but don't fully control how the system achieves it. This brings additional safety design requirements for Onchain Agents: you need to explicitly set 'boundary conditions for intent execution' (e.g., maximum acceptable slippage, Gas fee ceiling) to prevent the system from 'fulfilling' your intent in ways you wouldn't accept.

What is DeFi's 'Solver' mechanism? How does it combine with AI Agents?

The Solver mechanism is a concrete implementation of intent-based architecture in DeFi scenarios, represented by protocols like CoW Protocol (Coincidence of Wants) and UniswapX:

Solver mechanism workflow:

1. User submits an intent ('exchange USDC for ETH at the best rate') and signs an 'intent order' (not directly broadcasting a transaction, but signing an authorization message describing the intent)
2. Multiple Solvers (can be automated programs or institutions) compete to provide the optimal execution plan satisfying the user's intent — they can use DEXs, OTC trades, or match complementary intents from multiple users together (Coincidence of Wants)
3. The best plan is selected; the Solver executes and settles on-chain; the user receives the promised optimal result

AI Agent + Solver combination: Solvers themselves are a role that can be driven by AI Agents — an AI Agent can act as a Solver, analyzing all pending user intents in real-time, calculating optimal matching schemes or execution paths, submitting solutions on-chain and earning Solver fees. On the other side, AI Agents can also act as 'intent submitters' — the Agent analyzes market conditions on behalf of users, decides when and under what conditions to submit intents, and lets the Solver ecosystem find optimal execution for those intents.

Practical significance for Onchain Agent developers: if your DeFi Agent needs to do large token swaps, using Solver-mechanism-based DEXs (CoW Protocol, UniswapX) typically achieves better exchange rates than directly executing on AMMs, while reducing MEV attack risk (because intent orders aren't immediately broadcast on-chain, reducing the chance of being front-run by MEV bots).

What are the most common design pitfalls when implementing intent-based architecture in Onchain Agents?

Intent-based architecture sounds elegant, but there are several common design pitfalls in implementation:

Pitfall 1: Intent description not precise enough, leading to 'valid but unacceptable' execution results The intent 'exchange USDC for ETH at the best rate' lacks boundary conditions. If a Solver or Agent, in pursuit of 'best rate,' chooses a plan that takes 3 days to complete, or puts your USDC into a liquidity pool you don't trust, this may technically 'satisfy' your intent but the result is unacceptable. Solution: intent descriptions must include boundary conditions — 'within 30 minutes, slippage not exceeding 0.5%, execute only on Uniswap or Curve, Gas fees not exceeding $X.' The clearer the boundary conditions, the higher the security of intent-based architecture.

Pitfall 2: Passing 'high-level intent' directly to the LLM and letting the LLM decide the execution path If the intent 'move funds into the optimal protocol at the best rate' is given directly to the LLM to plan the execution path, the LLM may hallucinate (cite wrong APY numbers) or choose an execution path that sounds reasonable but doesn't actually exist. Correct design: the LLM handles decomposing intent into subtask specifications ('Step 1: query APY for target protocol list; Step 2: select highest APY protocol; Step 3: calculate whether rebalancing is worthwhile; Step 4: if worthwhile, generate rebalancing instructions'), but each subtask's execution is completed by deterministic code logic, not letting the LLM directly decide specific parameter values.

Pitfall 3: Ignoring intent 'expiration' design A user expresses an intent under certain market conditions ('rebalance if APY exceeds 5% now'), but if the Agent encounters delays in execution (waiting for Gas fees, retrying failed tool calls), by the time execution actually happens market conditions may have changed and the original intent may no longer be valid. Design point: intents should include expiration ('this intent is only valid for the next 2 hours; after timeout, re-evaluation is required'), ensuring the Agent doesn't execute based on outdated judgment after the intent has expired.

What's the difference between intent-based architecture and the ReAct (Reason + Act) framework? Are they competing or complementary?

These two concepts are often confused in AI Agent design, but they actually describe different levels of architectural design and can be complementary rather than competing:

ReAct framework describes the Agent's reasoning-action cycle: ReAct is the Agent's working mode in each reasoning cycle — Thought (reasoning) → Action (tool call) → Observation (observe result) → Thought again. It describes 'how an Agent makes step-by-step decisions within a single task' — the microscopic execution mode of an Agent.

Intent-based architecture describes how tasks are expressed and assigned: intent-based architecture focuses on 'how the user (or upper-level system) tells the Agent what to do' and 'how the Agent decomposes high-level intent into executable subtasks.' It describes the macroscopic task assignment and planning layer of the Agent system.

How to combine them: a typical intent-driven Onchain Agent design: user (or upper-level Orchestrator) submits intent (macro level: intent-based architecture) → Agent's Planner decomposes intent into subtask sequence (still within the scope of intent-based architecture) → each subtask executed by a Sub-agent using the ReAct framework (micro level: ReAct). Intent-based architecture and ReAct framework work separately at different levels; combined use lets the Agent system both handle high-level task descriptions (intent) and have flexible reasoning-action loops at the execution level (ReAct).