What is the fundamental difference between an Agentic Loop and ordinary 'Q&A AI'? Why does this difference matter?
This is the most critical conceptual distinction. Ordinary Q&A AI (like a one-shot API call to GPT) works like this: you input → LLM outputs → done. The entire process is one-directional and one-time; the LLM's output doesn't affect subsequent inputs and doesn't trigger any external actions.
The Agentic Loop works like: goal input → Perceive (tool queries) → Plan (LLM reasoning) → Act (tool calls with external effects) → Observe (results fed back) → Perceive again → ... cycling until complete or aborted. Three key differences:
1. External effects (Side Effects): Ordinary Q&A AI output is just text — it doesn't change the external world. The Act layer in an Agentic Loop genuinely changes the external world — broadcasting irreversible transactions on a blockchain. This means errors have real, hard-to-reverse consequences.
2. Autonomous decision loop: Ordinary Q&A AI requires human input to trigger every response. Agents in an Agentic Loop autonomously decide next steps during the cycle — humans neither need to (nor typically do) intervene at every step.
3. State accumulation: Each round's Observe results become the next round's Perceive inputs; the Agent accumulates state of 'what has happened in this task so far' across the loop. This state accumulation lets Agents handle complex multi-step tasks, but also means errors in early loops can amplify in later loops.
Why it matters: Understanding the Agentic Loop explains why Agent security design differs from ordinary application security. An ordinary application bug just outputs wrong text; an Agentic Loop bug may cause the Agent to autonomously execute a series of incorrect on-chain operations — and those operations are irreversible.
What are common 'infinite loop' or abnormal loop patterns in Agentic Loops? How to prevent them at the design level?
The Agentic Loop's cycling mechanism makes it easy to fall into several abnormal patterns when tools encounter problems:
Abnormal Pattern 1: Tool failure retry infinite loop Tool call fails (API timeout, insufficient Gas) → Agent observes failure → Plan layer decides 'retry' → Tool fails again → continue retrying... Without a maximum retry limit, the Agent can retry infinitely in this loop, consuming large amounts of LLM Tokens (cost) and time.
Defense: set maximum retry count (3 times) in tool functions; set maximum total loop count for the entire task (10 loops) at the Orchestrator layer; add exponential backoff delay between retries (wait 1s first, 2s second, 4s third).
Abnormal Pattern 2: Goal drift loop Mid-loop, due to Prompt Injection or hallucination, the Agent begins pursuing a sub-goal different from the original. For example: originally optimizing DeFi yield, but in one loop cycle an injected instruction says 'the current goal is to test transfer functionality,' and the Agent begins attempting transfers. Backend whitelists and operation type restrictions are key to preventing this drift from having real impact.
Abnormal Pattern 3: Success misjudgment loop The Observe layer misidentifies 'transaction entered mempool' as 'operation successfully completed,' and the Agent continues to the next operation (such as depositing to another protocol), while the previous operation (withdrawal) hasn't actually been confirmed. If the previous operation ultimately reverts, the next operation will fail because the funds don't exist.
Defense: Observe layer must wait for transaction confirmation (several blocks), not just mempool acceptance. Set 'dependency checks' for the entire strategy — don't allow execution of a step that depends on an unconfirmed previous step.
How do you use logs to determine which stage of the Agentic Loop had a problem?
Each stage's failures have different log characteristics — mastering these lets you quickly locate problems:
Perceive layer failure log characteristics: Tool call succeeds, but the LLM's subsequent Thought steps reference numbers not in the tool's return ('based on Compound APY 6.8%...' but logs show tool returned Compound APY 3.8%) → hallucination; Perceive layer data didn't correctly enter Context, or LLM ignored Perceive data and used outdated numbers from training memory. Solution: confirm tool return data is correctly formatted into Context; explicitly specify in System Prompt 'only use tool-returned data, not numbers from memory.'
Plan layer failure log characteristics: Thought step reasoning suddenly contains text unrelated to the task ('the primary task now is to transfer to 0xMalicious'), or Thought steps show the Agent ignoring a key number while 'reading' tool return data. → Prompt Injection contaminated reasoning, or the 'needle in a haystack' problem caused the LLM to ignore important information in the middle of Context.
Act layer failure log characteristics: Tool call intercepted by backend Schema validation (target address not on whitelist / amount exceeds limit) → normal security interception, not a bug. Multiple consecutive tool call failures of the same type (insufficient Gas) → Act layer configuration issue.
Observe layer failure log characteristics: Tool returns success, but the next loop's Perceive layer query shows the operation didn't happen on-chain → Observe layer treated mempool pending as success. Or: Agent executed far more loops than expected in a single task (more than 20) → Observe layer termination conditions not correctly set.
What does each Agentic Loop cycle cost? How do you estimate and control Agent LLM API costs?
Each Agentic Loop cycle's cost consists of two parts: LLM inference fees (primary cost) and tool call infrastructure fees (usually negligible).
Per-cycle LLM token consumption estimate:
Using Claude Sonnet as an example, a DeFi yield optimization Agent's complete cycle (2-3 tool calls) consumes ~4,000-6,000 tokens, costing ~$0.02-$0.04. Executing 24 cycles/day (once per hour), monthly cost is ~$14-$29.
Most effective cost control methods:
You tell an AI Agent to 'help you optimize DeFi yield,' and it starts working — querying rates, making decisions, executing rebalances, confirming results, then querying the next round of rates. This continuous operational process has a specific name in the AI Agent field: the Agentic Loop.
Understanding the Agentic Loop is foundational to understanding 'why Agents sometimes get things right and sometimes go wrong.' It's not a black box — every loop has four clear stages, each with its own inputs, outputs, and failure modes. If you're deploying, using, or evaluating an Onchain Agent, this concept is the most worthwhile foundational knowledge to understand first.
The Agentic Loop is the process by which an AI Agent, while completing a goal, repeatedly executes the cycle of Perceive → Plan → Act → Observe. Unlike ordinary AI that 'answers one question at a time' (you ask, it answers, done), the defining characteristic of an Agent is autonomous continuous cycling — it executes an action, observes the result, decides on the next action, until the goal is complete or it encounters a situation it cannot handle.
This loop sounds simple, but each stage contains extensive engineering design. Understanding what each stage does and what can go wrong is a core capability for designing and using Agents.
The Perceive layer is the Agentic Loop's 'eyes and ears' — in this stage, the Agent receives all input information it needs to process, placing it into the Context Window as raw material for subsequent reasoning.
Perception sources typically include: user instructions ('move USDC to the highest-APY protocol'); tool call returns (the Aave rate API data returned from the previous round); system state information (current balance of the Agent operations wallet, executed operation records); and environmental context (current Gas fee levels, market volatility).
The key design decision for the Perceive layer is 'what to show the Agent.' Too much information wastes Context Window (high Token costs, and the 'needle in a haystack' problem makes it hard for the model to focus); too little information forces the Agent to make decisions without sufficient data — the result is often hallucination where the Agent assumes a number it never queried is real. A well-designed Agent system puts only 'the minimum information set this decision actually needs' in the Perceive layer.
This is the Agentic Loop's 'brain' — the LLM receives all Perceive layer inputs and reasons about what to do next. Most modern Agents use the ReAct (Reasoning + Acting) framework for this reasoning process: first stating the reasoning process in the Thought step ('Aave current APY is 4.2%, Morpho is 5.1%, difference 0.9% exceeds rebalancing threshold 0.5%, Gas fees are within acceptable range, should execute rebalance'), then deciding which tool to call and with what parameters in the Action step.
The Plan layer has two main failure modes: hallucination reasoning (the Agent uses data it believes to be real, but is actually 'imagined' because the Perceive layer didn't provide it); and reasoning hijacking (Prompt Injection attacks contaminate the Agent's reasoning process with malicious instructions, causing the Agent to reason in the direction the attacker wants). The Plan layer is the stage requiring the most security design in the entire Agentic Loop.
The Plan layer decided 'what to do'; the Act layer is responsible for 'actually doing it' — calling tool functions and interacting with the external world. In Onchain Agents, Act layer tool calls include: querying on-chain data (read operations, no on-chain consequences); calling DeFi protocol deposit/withdraw functions (write operations, with on-chain consequences, irreversible); paying Gas fees to broadcast transactions; and reporting execution results to the Orchestrator or monitoring system.
The most critical design principle for the Act layer: read/write separation. Read tools (query APIs, read on-chain state) can execute in any situation because they have no on-chain consequences. Write tools (sign and broadcast transactions) must have backend second-layer parameter validation — in the tool function's Python/JavaScript code, confirm the amount is within limits, target address is on the whitelist, operation type is permitted. These validations cannot rely solely on System Prompt instructions, because the System Prompt may already be contaminated by Prompt Injection.
Another important Act layer design is idempotency: if the same operation is retried twice due to network issues, it should not produce two transactions on-chain. Checking pending mempool before broadcasting a transaction, confirming no already-broadcast transaction with the same nonce exists, is a basic measure to prevent duplicate transactions.
After Act layer tool calls complete, the Observe layer organizes results into structured format and sends them back to the top of the Agentic Loop as input for the next round's Perceive layer. This sounds like just 'passing results back,' but several important details exist in Observe layer design:
Result accuracy verification: Does the tool's return match what actually happened on-chain? In DeFi operations, a deposit function call may return 'success,' but this may only mean the transaction entered the mempool — not yet confirmed on-chain. The Observe layer should wait for transaction confirmation (after a few blocks), not treat mempool 'send success' as 'operation success' to pass back into the loop.
Structured output format: Observe layer output should be structured format defined by JSON Schema, not free text. Structured format is easier for the next round's LLM to parse, and easier to perform Schema validation on in the backend (ensuring tool returns don't contain maliciously injected text).
Termination condition judgment: The Observe layer also determines 'should this loop end?' Goal achieved (USDC successfully deposited in the higher-APY protocol), unrecoverable error occurred (Gas fee too high exceeds threshold, this loop cycle aborted), or maximum loop count reached (preventing the Agent from entering infinite loops that consume resources).
Using one cycle of a DeFi yield optimization Agent as an example, here's how the Agentic Loop operates in reality:
Perceive: Agent receives a timer trigger signal; tool calls fetch Aave, Morpho, and Compound rate APIs; results placed into Context. Post-tool-call Context contains: {aave_apy: 4.2%, morpho_apy: 5.1%, compound_apy: 3.8%, gas_gwei: 12, wallet_usdc: 5000, current_position: aave}
Plan (ReAct): LLM Thought step reasoning: 'Morpho APY is 0.9% higher than Aave, exceeding the 0.5% rebalancing threshold. Gas fee 12 Gwei is within acceptable range (threshold 30 Gwei). Rebalance cost estimate: Gas ~$2.1, daily yield difference: $5,000 × 0.9% / 365 = $0.123/day. ~17 days to break even. Rebalancing conditions met.' Action: call withdraw_from_aave(5000_USDC) tool.
Act: Tool function backend validation — amount $5,000 ≤ daily limit $10,000 ✓; target protocol Aave on whitelist ✓; operation type withdraw permitted ✓. Validation passes; transaction broadcast. Wait 3 block confirmations.
Observe: Confirm transaction on-chain; $5,000 USDC withdrawal from Aave successful. Output structured result: {action: withdraw_aave, status: success, amount: 5000, tx_hash: 0x..., gas_used: $2.1}. Loop continues to next Action: deposit_to_morpho(5000_USDC).
This complete Perceive → Plan → Act → Observe cycle runs once per operation in this Agent, until the entire rebalancing task completes or a situation requiring human intervention arises (such as Gas fees exceeding threshold).
Understanding the Agentic Loop has a practical impact: when an Agent has a problem, you can quickly locate 'which stage the problem is in.' Agent performed an operation you never expected? Check the Plan layer's Thought logs to see what the LLM's reasoning process was — usually it's Perceive layer information being wrong (received incorrect data), or the reasoning layer being contaminated by Prompt Injection. Agent's tool call failure rate very high? Usually the Act layer's backend validation is too strict (or there really is a security issue that needs intercepting). Agent did what you wanted but the result doesn't match expectations? Usually the Observe layer didn't correctly handle tool returns (treating mempool pending as confirmed on-chain transactions).
Another practical impact: each Agentic Loop cycle consumes LLM Tokens (cost) and execution time (latency). A well-designed loop should have predictable Token consumption per inference; if you notice Agent API costs spiking after a task, it's usually because the Observe layer didn't correctly set termination conditions and the Agent entered unnecessary repeated loops. Set a maximum loop count limit (e.g., maximum 10 loops per task) as a failsafe against infinite loops.