AI Agent Workflows on Ethereum 2026: Architecture and Controls

Short answer: An Ethereum AI agent is usually an offchain planning system connected to blockchain data and a wallet execution layer. The model interprets a goal and proposes an action; deterministic code must verify chain, contract, method, asset, amount, price, deadline, exposure, and approval policy before anything is signed. Ethereum can enforce a valid transaction and smart-account rules. It cannot verify that an LLM understood the user's intent, used accurate offchain data, or chose a profitable strategy.

The earlier version of this page described autonomous institutional adoption and market performance without evidence. It also implied that account abstraction mathematically caps every model error. Those claims have been withdrawn. This revision focuses on the architecture a developer, auditor, or investment committee can inspect.

Correction Ledger

Earlier claim	Evidence required	Audit result
AI-controlled wallets are the biggest crypto trend of 2026	Defined adoption metric and dated market study	Unsupported ranking; withdrawn
Institutions routinely authorize models to trade $10 million	Named deployment, mandate, contracts, and control documents	No evidence supplied; withdrawn
AI agents rebalance portfolios in milliseconds	End-to-end benchmark through data, planning, signing, inclusion, and finality	Unsupported; withdrawn
Models run through smart contracts	Deployed onchain inference and execution design	Most planning is offchain; contracts verify calls and state transitions
Smart-account rules mathematically cap all hallucination losses	Complete policy coverage and proof that every harmful path is bounded	Rules cap only what they explicitly constrain
Major asset managers use proprietary DeFi yield agents	First-party disclosures, addresses, or audited service records	No evidence supplied; withdrawn
A DeFiLlama "Agentic TVL" metric proves adoption	Public metric definition and dataset	No cited metric was provided; withdrawn
Yield agents always move to the highest APY	Full net-yield, risk, liquidity, capacity, and execution model	Highest displayed APY is not necessarily best return
Private mempools ensure trades cannot be front-run	Submission design, builder path, failure and leakage analysis	Protection is conditional, not absolute
AI will make high-frequency human traders obsolete	Market-share and performance evidence	Speculative claim; withdrawn

A Workflow Is More Than a Model

An agentic workflow has at least nine components:

1.trigger;

2.data acquisition;

3.normalization and state construction;

4.planning;

5.policy validation;

6.transaction construction and simulation;

7.approval and signing;

8.submission and settlement;

9.reconciliation and recovery.

The model is one component. Wallet security, oracle quality, contract permissions, transaction ordering, and recovery often determine loss more directly than model intelligence.

Layer	Typical implementation	Can Ethereum verify it?
Trigger	Scheduler, event listener, keeper, user message	Only if represented by onchain state or call
Offchain data	APIs, documents, news, market feeds	No, unless supplied through an oracle mechanism
Planner	Rules, optimizer, LLM, multi-agent system	No
Policy	Service code and smart-account modules	Onchain portions only
Simulation	RPC node, fork, bundler simulation	No guarantee of future inclusion state
Signature	EOA, session key, multisig, smart account	Signature and account validation are enforceable
Execution	EVM transaction or UserOperation	Yes, under current chain state and contract code
Monitoring	Indexer, logs, accounting database	Events are onchain; interpretation is offchain
Recovery	Key revoke, module disable, pause, treasury transfer	Only mechanisms encoded in contracts and available keys

This table is the central control insight: do not ask a probabilistic model to enforce a promise that belongs in deterministic account or contract logic.

Step 1: Define the Mandate

Natural-language goals are ambiguous.

Keep our stablecoins productive without taking material risk.

That sentence does not specify:

eligible stablecoins;

eligible chains and protocols;

whether bridging is allowed;

maximum amount or concentration;

whether borrowing or leverage is allowed;

acceptable smart-contract and issuer risk;

price and liquidity sources;

minimum net benefit after costs;

response to depeg or protocol pause;

who approves a new contract;

how quickly assets must be recoverable.

Turn the mandate into a versioned policy object. Human-readable language remains useful for governance, but execution depends on machine-checkable constraints.

Example policy

Field	Rule
Chain	Ethereum mainnet only
Assets	USDC and DAI
Protocols	Two reviewed lending deployments by exact address
Maximum capital	250,000 units total
Per-protocol cap	125,000 units
Borrowing	Prohibited
Bridging	Prohibited
New token approval	Human multisig required
Automated action cap	20,000 units
Daily turnover	50,000 units
Minimum projected benefit	$150 after estimated costs over 30 days
Oracle divergence	Halt above 0.30%
Session expiry	24 hours
Recovery destination	Fixed treasury address

The agent can search within these boundaries. It cannot redefine them because a prompt says an opportunity is urgent.

Step 2: Acquire and Classify Data

Onchain data include balances, allowances, contract state, rates, pool liquidity, oracle updates, events, gas conditions, and pending transactions visible through the chosen endpoint. Offchain data may include documentation, governance proposals, legal terms, incident reports, macro releases, and service APIs.

Every input should carry:

source identifier;

chain and contract address where applicable;

block number or timestamp;

retrieval time;

schema version;

freshness limit;

confidence or validation status;

fallback behavior;

whether the content is trusted or untrusted.

Untrusted content rule

Token metadata, web pages, governance posts, transaction memos, and retrieved documents are data, not instructions. A page can contain prompt injection telling the model to reveal credentials or call a malicious contract. The planner may summarize it, but it must not alter wallet policy.

Cross-source disagreement

If two RPC providers disagree on chain head, two oracles diverge beyond policy, or documentation does not match deployed bytecode, the workflow should halt or escalate. Choosing the most convenient source is not resolution.

Step 3: Build a Deterministic State Snapshot

A planner should reason over a normalized snapshot rather than query live tools unpredictably throughout a long chain of thought.

The snapshot can include:

chain ID and finalized/safe/latest block references;

account balances and nonce;

active session permissions;

allowances by token and spender;

positions, collateral, debt, and claimable assets;

protocol contract addresses and code hashes;

oracle values and update times;

available liquidity and quote size;

gas estimate and fee assumptions;

policy version and approval state.

Hash and retain the snapshot used for the decision. This helps explain why a transaction was proposed even if state changes later.

Do not confuse snapshot reproducibility with execution certainty. A transaction may land several blocks later against different balances, prices, liquidity, and competing calls.

Step 4: Plan With Typed Actions

An LLM should not emit arbitrary calldata. Give it a small set of typed tools such as:

read position;

request quote;

propose deposit;

propose withdrawal;

propose bounded swap;

revoke allowance;

request human approval;

pause workflow.

Each action has a schema. A deposit request might require:

Field	Type and constraint
chainId	Exact allowed integer
protocolId	Allowlisted identifier
contract	Resolved from signed registry, not model text
asset	Allowlisted token address
amount	Positive integer below available balance and cap
minExpectedShares	Calculated from current state and tolerance
deadline	Short future timestamp
reasonCode	Enumerated policy reason
snapshotHash	Exact state packet used

Coinbase AgentKit's architecture illustrates the general pattern: action providers expose defined capabilities and schemas while wallet providers handle wallet operations. This is a toolkit capability, not proof that any particular agent is safe.

Why typed tools help

The model cannot invent a function signature outside the schema.

The policy engine can validate structured fields.

Tests can cover each action.

Logs can compare requested, approved, and executed parameters.

A compromised data source has fewer paths to signing authority.

Typed actions reduce risk; they do not validate whether the selected action is economically wise.

Step 5: Enforce Policy Outside the Planner

Use two policy layers.

Offchain preflight

Reject malformed, stale, unsupported, or economically irrational proposals before paying gas. Check projected benefit, data completeness, quote quality, policy version, prior actions, and human approvals.

Onchain enforcement

Encode the highest-value constraints in a smart account, guard, module, or purpose-built vault:

allowed destinations and function selectors;

token and notional caps;

spending rate limits;

session expiry;

required co-signers;

fixed recovery address;

blocked delegate calls;

nonce and replay protection;

pause authority.

Offchain controls are easier to update and richer. Onchain controls remain enforceable if the agent server is compromised. Use both.

Account Abstraction: What ERC-4337 Does

ERC-4337 defines UserOperations sent through a separate mempool, bundlers that package them, an EntryPoint contract, and account-specific validation. Optional paymasters can sponsor execution under their own validation rules.

It does not automatically convert every existing wallet into a safe agent wallet. Developers deploy or use a smart account implementation, define validation logic, and depend on supporting infrastructure.

The account must validate the relevant UserOperation and trusted EntryPoint. The operation includes fields such as sender, nonce, call data, gas parameters, and signature-related data. Bundler simulation helps reject invalid operations before inclusion.

Agent-specific questions:

Which EntryPoint version and address is trusted?

Can plugins or validation modules be upgraded?

Who controls owners and recovery?

Can a paymaster censor or change sponsorship policy?

What happens when bundlers reject the operation?

Does the account support an ordinary transaction fallback?

Are spending and destination restrictions onchain or only in agent code?

Can an enabled module bypass an account guard?

EIP-7702 Is a Different Path

EIP-7702 allows an externally owned account to set code through a signed authorization, enabling delegated smart-account behavior while retaining the account address. It expands wallet programmability but also makes authorization management security-critical.

An agent workflow must verify:

chain ID in the authorization;

delegated code address and code hash;

nonce and replay behavior;

upgrade or revocation path;

initialization state;

storage assumptions;

whether the delegated implementation can be replaced;

whether signatures grant broader authority than intended.

An EIP-7702 authorization is not a casual login signature. It can change how the account executes future transactions.

EIP-712 and ERC-1271

EIP-712 structures typed signed data with a domain separator that can include chain and verifying contract. It improves clarity and replay boundaries compared with opaque messages, but users and agents must still understand the exact fields.

ERC-1271 gives contracts a standard method for validating signatures according to contract-defined logic. This lets a smart account approve orders or intents without behaving like a single EOA key.

For an agent signing offchain orders:

decode and display every typed field;

bind chain, contract, asset, quantity, limit, deadline, and nonce;

reject unknown domain or schema;

prevent wildcard destinations;

separate message signing from arbitrary transaction execution;

store the signed payload and cancellation status;

test ERC-1271 behavior after account upgrades.

A readable signature can still authorize a bad trade. Typed data helps inspection, not strategy quality.

Step 6: Construct and Simulate the Exact Transaction

Simulation should use the exact target, value, calldata, sender, block context, and account path intended for submission.

Check:

call success or revert;

token balance changes;

protocol share or position changes;

debt and collateral changes;

allowances created or consumed;

unexpected external calls;

events emitted;

gas use;

slippage and minimum output;

policy invariants after execution.

Simulation limitations

Simulation predicts execution against a chosen state. It does not guarantee:

the transaction lands before state changes;

a sequencer or builder includes it;

a quote remains available;

an oracle does not update;

another transaction does not consume liquidity;

a reorganization does not alter the result;

hidden offchain dependencies remain available.

Use short deadlines, bounded outputs, state checks inside the call path, and resimulation before signing when the delay is material.

Worked Workflow: Treasury Depeg Response

Assume the policy permits an agent to reduce up to 20,000 USDC exposure automatically if two approved price sources both report less than $0.995 for three consecutive observations, provided realized swap output is at least 99.2% and the destination is DAI.

Trigger

The monitor records:

onchain oracle: $0.9942 at block A;

approved market data source: $0.9938;

three observations satisfy duration policy;

DAI sources remain within $0.999 to $1.001;

account holds 80,000 USDC;

daily automated turnover used: zero.

Planning

The model explains that policy permits a partial risk reduction. It requests quotes for 10,000, 20,000, and 30,000 USDC. The 30,000 option is structurally disallowed, not merely discouraged.

Quote comparison

Size	Expected DAI	Price ratio	Estimated gas	Policy result
10,000 USDC	9,946 DAI	99.46%	$28	Allowed
20,000 USDC	19,860 DAI	99.30%	$31	Allowed
30,000 USDC	29,715 DAI	99.05%	$35	Rejected by action cap and output floor

The planner selects 20,000 because it reduces more exposure while remaining within policy. It does not select 30,000 even if the model predicts further depeg.

Policy and simulation

The policy engine resolves the approved router address, checks code hash, token addresses, method, amount, minimum output of 19,840 DAI, deadline, and daily turnover. Simulation confirms:

USDC falls by exactly 20,000;

DAI increases above minimum;

no borrowing or LP position is created;

allowance is bounded;

call touches only approved contracts;

account retains more than its required gas buffer.

Signing

The session key is authorized for the approved swap method, maximum 20,000 units per action, maximum 50,000 daily turnover, and 24-hour expiry. The smart account rejects broader calls even if the agent process asks.

Submission

The workflow submits through its configured route. A replacement policy permits fee increases but not altered calldata or minimum output.

Reconciliation

After inclusion, the monitor checks finalized receipt, realized output, remaining USDC, new DAI, allowance, gas, and policy counters. If output or balances differ from expected tolerance, the system pauses before another action.

Recovery

If the session key behaves unexpectedly, an independent owner revokes it. A separate recovery key can move unencumbered assets only to the fixed treasury address.

The model contributed interpretation and selection. Deterministic rules bounded every irreversible step.

Event-Driven Automation Is Not Necessarily AI

Chainlink Automation and similar systems can call smart contracts when time, logs, or onchain conditions indicate work is needed. A keeper may execute a deterministic upkeep without any model.

Use deterministic automation when the condition can be specified exactly:

claim rewards on schedule;

roll a position at a known maturity;

call a maintenance function after an event;

rebalance when a fully onchain ratio crosses a threshold;

pause when an oracle heartbeat is stale.

Use a model when the task genuinely needs interpretation, such as summarizing governance changes, comparing incomplete documentation, or drafting a proposed response. Even then, have deterministic code decide whether the proposal is executable.

An LLM layered over a keeper should not be credited for the keeper's reliability.

Intents and Solvers

An agent can sign an intent defining a desired outcome, while solvers compete to find execution. This separates route search from user constraints.

For example:

Exchange no more than 20,000 USDC for at least 19,840 DAI before timestamp T through settlement contract S on chain C.

The signed order can constrain result, amount, deadline, nonce, receiver, and settlement domain. A solver may route across liquidity sources. The settlement contract verifies the signed conditions.

Audit:

solver permission model and concentration;

order visibility and information leakage;

partial-fill rules;

cancellation and nonce behavior;

surplus allocation and fees;

settlement-contract upgrade authority;

ERC-1271 compatibility;

failure when no solver fills;

whether arbitrary interactions are allowed.

An intent is not a promise of optimal execution. It is a set of acceptable outcomes.

Cross-Chain Workflows Multiply Failure Domains

A workflow that bridges, swaps, deposits, and stakes across chains can fail between every step.

Possible states include:

source transaction finalized, bridge message pending;

bridge asset minted, destination swap failed;

destination deposit succeeded, accounting indexer delayed;

return bridge paused;

source and destination oracles disagree;

one chain reorganized or sequencer halted;

session permission valid on one chain but not another;

same token symbol maps to different contract or issuer.

Treat each leg as a state machine with explicit compensation or recovery. Do not let the model invent a new route after a partial failure unless policy authorizes it.

Cross-chain transaction record

Store:

source chain and transaction hash;

bridge and message identifier;

destination chain and receipt;

token addresses on both sides;

bridge representation and redemption path;

expected and observed timing;

finality requirement on each chain;

retry and refund status;

responsible human escalation.

"Atomic workflow" is often a user-interface description, not protocol-level atomicity across independent chains.

Yield Optimization Needs Risk-Adjusted Inputs

Moving stablecoins to the highest displayed APY can destroy value through gas, slippage, utilization changes, token incentives, withdrawal limits, contract risk, or depeg.

Calculate:

Expected net benefit = expected interest + realizable incentives - entry costs - expected exit costs - operator fees - expected loss allowances

Model at least:

rate variability and utilization;

incentive duration and executable token price;

available capacity at the quoted rate;

protocol contracts and upgrade controls;

oracle and liquidation dependencies;

stablecoin issuer and reserve risk;

withdrawal queue or liquidity;

bridge exposure;

tax and accounting costs where relevant;

minimum holding period needed to recover execution cost.

A model can rank scenarios. The investment committee must define risk allowances and eligible protocols.

MEV and Submission

Private or protected submission can reduce public mempool exposure, but it introduces relay, builder, and endpoint assumptions. It cannot guarantee inclusion or eliminate every form of adverse selection.

The workflow should define:

public fallback policy;

maximum time before fallback;

allowed relays or builders;

transaction privacy and data retention;

replacement and cancellation;

protection against stale private transactions landing later;

realized execution benchmark;

response when a bundle is not included.

The strongest protection remains transaction-level limits. A minimum output still applies if the submission route fails to provide expected privacy.

Agent Identity and Reputation

ERC-8004 is a draft proposal for agent identity, reputation, and validation registries. It can provide portable records and feedback interfaces, but its own security considerations recognize Sybil and capability-verification limits.

Identity proves that a registry record and controller relationship exist under the specification. It does not prove:

the current model produced the action;

the model or tool code is unmodified;

the strategy is profitable;

reputation feedback is independent;

the wallet remains uncompromised;

advertised capabilities work;

validation covers the current version.

Bind each execution record to agent identity, code and model version, policy hash, action schema, account, and approval. Reputation without versioning can describe software that no longer runs.

Governance and Upgrade Controls

Agent workflows depend on changing contracts and external services. An allowlisted address can become unsafe after a proxy upgrade.

Monitor:

proxy implementation changes;

account module or guard changes;

signer and threshold changes;

protocol governance proposals;

oracle feed configuration;

paused or deprecated automation registries;

token issuer freezes or upgrades;

router and permit-contract changes;

EntryPoint and bundler compatibility;

policy registry updates.

Freeze autonomous interaction during an unreviewed material upgrade. Address allowlisting without implementation monitoring is incomplete.

Monitoring and Accounting

Every workflow needs three records.

Decision record

Trigger, data snapshot, model and code versions, considered actions, selected action, rejected alternatives, and explanation.

Authorization record

Policy version, checks, approvals, signature type, session permissions, typed payload, simulation, and expected state changes.

Settlement record

Transaction or UserOperation hash, block, receipt, events, realized balances, fees, slippage, allowances, and accounting entries.

Reconcile all three. A successful transaction can violate economic intent. A failed transaction can still leave an allowance, nonce change, fee cost, or partial cross-chain state.

Security Test Matrix

Test	Expected control
Prompt says ignore limits	Planner may discuss; policy rejects action
Retrieved page supplies new router	Address registry rejects it
Wrong chain ID	Signature and policy reject
Token uses unexpected decimals	Typed token registry and amount checks halt
Oracle is stale	No action; alert
Simulation succeeds, price moves	Onchain minimum output protects amount
Session key exceeds daily cap	Smart account rejects
Module bypasses guard	Architecture test fails deployment
Bundler unavailable	Fallback or human escalation; no policy weakening
Cross-chain destination fails	Workflow enters recoverable pending state
Agent server compromised	Independent revoke and capped account limit loss
Recovery key compromised	Fixed destination and threshold limit authority

Run these tests against forks and production-like account configurations. A unit test of the model prompt is not a wallet-security test.

Workflow Control Scorecard

Score each category from zero to two.

Category	0	1	2
Mandate	Natural language only	Offchain limits	Versioned policy plus critical onchain limits
Data	Untracked APIs	Sources logged	Block/time, freshness, schema, trust class, divergence rules
Actions	Arbitrary calldata	Tool list	Typed schemas and signed address registry
Simulation	None	RPC call	Exact account path, state assertions, multi-provider checks
Authority	Treasury key	Capped wallet	Scoped session, rate limits, approval tiers, independent revoke
Signatures	Opaque	Decoded	Domain, chain, nonce, deadline, contract, asset, amount verified
Submission	One endpoint	Retry	Protected/public policy, replacement bounds, expiry
Monitoring	Transaction status	Balance alerts	Decision-authority-settlement reconciliation
Recovery	Restart service	Pause	Independent revoke, fixed safe destination, tested runbook
Upgrades	Ignored	Manual review	Code-hash monitoring and autonomy freeze

0 to 6: demonstration only;

7 to 12: capped automation with weak recovery or verification;

13 to 16: credible bounded workflow;

17 to 20: strong production controls, still exposed to protocol and market risk.

Deployment Stages

1.Read only: monitor and explain without transaction authority.

2.Proposal mode: produce typed transactions for human review.

3.Fork execution: test exact account and protocol state.

4.Approval-gated production: humans approve every action.

5.Capped autonomy: narrow actions, small amounts, no leverage or bridging.

6.Expanded mandate: only after incident, rejection, cost, and recovery evidence supports it.

Advancement should depend on observed control performance, not profit. A profitable agent can still have an unrestricted key and catastrophic tail risk.

Frequently Asked Questions

Does an AI model run on Ethereum?

Usually not. The model and orchestration run offchain. Ethereum validates signed transactions, smart-account rules, and contract execution. Onchain inference exists in specialized designs but is not the default agent architecture.

Does ERC-4337 make AI wallets safe?

It enables programmable account validation through UserOperations and EntryPoint infrastructure. Safety depends on the account implementation, modules, permissions, bundlers, paymasters, owners, upgrades, and recovery.

What is the difference between ERC-4337 and EIP-7702?

ERC-4337 defines a higher-layer UserOperation and bundler system for smart accounts. EIP-7702 lets an EOA authorize delegated code behavior. They can interact, but their account and authorization paths differ.

Can a smart contract cap model downside?

It can cap encoded quantities, destinations, methods, and rates. It cannot anticipate every economic loss, malicious allowed contract, oracle failure, depeg, governance change, or missing policy rule.

Should an agent ever hold a treasury key?

An unrestricted treasury key creates unnecessary risk. Use a capped account with scoped, expiring authority and independent revocation. High-value or novel actions should require separate approval.

Are AI agents faster than human traders?

They can monitor and prepare actions continuously, but end-to-end speed includes data updates, inference, simulation, signing, submission, block inclusion, and finality. Speed does not guarantee better execution.

Can private submission eliminate MEV?

No. It can reduce public exposure under specific routes, but introduces relays and builders and does not guarantee inclusion. Keep enforceable price and deadline limits in the transaction.

Is the highest DeFi APY the best agent action?

No. Compare net yield after execution and exit costs, capacity, incentives, contract, issuer, oracle, liquidity, bridge, governance, and tax risks.

Sources and Method

This architecture audit was updated July 11, 2026. It relies on Ethereum standards and primary product documentation for capabilities. Product documentation is not independent evidence of adoption, security, or performance.

1.Ethereum.org: Account abstraction - smart-account benefits, ERC-4337, and EIP-7702 paths.

2.ERC-4337 - UserOperations, EntryPoint, account validation, bundlers, paymasters, and simulation.

3.EIP-7702 - EOA code delegation through signed authorization.

4.EIP-712 - typed structured-data signing and domain separation.

5.ERC-1271 - standard contract signature validation.

6.Coinbase AgentKit architecture - action providers, wallet providers, and framework integration.

7.Safe smart-account guard documentation - transaction checks and guard behavior.

8.Chainlink Automation documentation - time, custom logic, and log-triggered contract automation.

9.ERC-8004 draft - proposed agent identity, reputation, validation, and security limitations.

Use <a href="/insights/agentic-defi-2026">the Agentic DeFi wallet-control audit</a> for capital-specific safeguards. Connect account recovery to <a href="/insights/crypto-wallet-recovery-seed-checklist-2026">the wallet recovery checklist</a>, and apply governance monitoring with <a href="/insights/on-chain-corporate-governance-dao-llc-guide-2026">the onchain governance guide</a>.

What to Read Next

Read <a href="/insights/agentic-defi-2026">Autonomous AI Agents Onchain</a> next. It extends the workflow into agent identity, payments, service discovery, cross-organizational trust, and portable reputation while preserving the same rule: identity and intelligence never replace bounded wallet authority.

This article is educational research, not investment advice. Models, account standards, wallets, protocols, and infrastructure can fail. Keep authority narrow, verify current contracts and documentation, and test revocation before funding an autonomous workflow.