On-chain AI agents: architecture and tradeoffs

AI agents are moving from “chatbots with tools” to autonomous systems that route tasks, execute transactions, and manage capital. In Web3, the obvious next step is to put more of that agent lifecycle on-chain—so actions are transparent, auditable, composable, and enforceable.

But “on-chain AI agent” is overloaded. The model rarely runs on-chain (for cost and performance reasons). What’s really on-chain is: identity, permissions, state, commitments, and settlement. The design space is mostly about where you place trust and how you prove what the agent did.

Below are the dominant architecture patterns, the tradeoffs that matter in production, and practical guidance for choosing the right level of “on-chain.”

What makes an agent “on-chain” (and what doesn’t)

An on-chain agent typically includes:

  • Agent identity: a smart contract wallet or account (EOA, multisig, or account abstraction) that can sign/execute.
  • Policy & permissions: constraints like spend limits, allowed protocols, risk parameters, or time locks.
  • State & memory anchors: a minimal on-chain record of decisions, commitments, or checkpoints (not full chat logs).
  • Settlement: the agent’s actions finalize on-chain—swaps, lending, NFT mints, governance votes, etc.

What usually stays off-chain:

  • Model inference (LLM calls, tool planning, embeddings).
  • Large memory (vector DBs, transcripts).
  • High-frequency computation (risk sims, route optimization).

So the core question is not “can we run the model on-chain?” but “what must be on-chain to make the agent trustworthy and composable?”

Architecture pattern 1: Off-chain brain, on-chain hands (most common)

Flow: Off-chain agent (LLM + tools) decides → submits a transaction → contract executes.

On-chain components:

  • A contract wallet (often ERC-4337 account abstraction)
  • Permission modules (spend caps, allowlists)
  • A minimal state machine (nonce, task IDs, replay protection)

Pros:

  • Fast iteration and cheap inference
  • Best UX (near-real-time responses)
  • Works with existing LLM stacks

Cons:

  • Users must trust the off-chain operator not to deviate from intent
  • Hard to prove why a trade happened
  • Key management and signing become the security boundary

When to use: consumer agents (portfolio rebalancing, yield routing), internal ops agents (treasury automation), anything where speed > perfect verifiability.

Concrete example: a DeFi “rebalance agent” that periodically moves funds between Aave/Compound based on utilization. The policy contract enforces max LTV and approved markets; the off-chain brain chooses timing and routing.

Architecture pattern 2: On-chain policy + off-chain execution (defense-in-depth)

Here you treat the model as untrusted and constrain it with a formal on-chain policy.

Flow: Agent proposes an action → policy contract validates constraints → execution contract performs the action.

Common policy primitives:

  • Max slippage, max position size, max daily spend
  • Allowed contract list (and specific method selectors)
  • Circuit breakers (pause on volatility, oracle anomalies)
  • Role separation (proposer vs executor)

Pros:

  • Strong protection against prompt injection and tool misuse
  • Easy audits: the “rules” live on-chain
  • Modular: swap LLM/provider without changing trust model

Cons:

  • Policies are brittle if you overconstrain them
  • Writing good policy code is non-trivial (and can become your product)

When to use: agents touching significant funds, B2B treasury automation, DAOs.

Opinionated take: if your agent can move meaningful money, your policy contract is more important than your model choice.

Architecture pattern 3: Commit–reveal / intent-based execution (MEV-aware)

Agents get sandwiched. If an agent is predictably trading based on public mempool transactions, it will bleed value.

Flow: agent commits hash(action) → later reveals details → executes, or routes via private orderflow.

Variations:

  • Commit–reveal on L1
  • Use a private relay / encrypted mempool
  • Use intent solvers: agent posts “desired outcome,” solvers compete to fill

Pros:

  • Better execution quality
  • Reduces copy-trading and sandwich attacks

Cons:

  • Added latency and complexity
  • Harder debugging and poorer UX in some cases

When to use: any agent doing frequent swaps or liquidations where execution quality matters.

Architecture pattern 4: Verifiable off-chain compute (the “proof” route)

If you need to prove the agent followed a process (or ran a specific model), you can anchor computation with:

  • TEE attestations (e.g., secure enclave proves code ran as expected)
  • ZK proofs (prove a computation was executed correctly)
  • Optimistic verification (anyone can challenge within a window)

Pros:

  • Stronger guarantees for compliance, fairness, or shared agents
  • Enables multi-party trust (DAOs, marketplaces of agents)

Cons:

  • Cost/complexity overhead is real
  • ZK for modern LLM inference is still expensive and workflow-heavy
  • TEEs introduce hardware trust assumptions

When to use: high-stakes shared infrastructure (agent marketplaces), regulated workflows, or agents with adversarial environments.

Practical reality: today, TEEs are often the pragmatic step before full ZK verifiability.

Architecture pattern 5: Fully on-chain inference (rare, niche)

Running meaningful inference fully on-chain is usually impractical. You may see:

  • Tiny models / linear predictors for simple scoring
  • Game agents with minimal state
  • Deterministic rule-based “agents” marketed as AI

Pros: maximally transparent and censorship-resistant.

Cons: expensive, slow, and typically not very “AI.”

When to use: niche cases where determinism and composability beat intelligence.

Key tradeoffs founders and engineers should price in

1) Cost vs. auditability

Putting more logic on-chain raises gas costs but improves auditability and composability. A good compromise: keep inference off-chain, but put policy, permissions, and checkpoints on-chain.

2) Autonomy vs. safety

Autonomous agents fail in surprising ways—especially when prompted by untrusted inputs (Discord, governance forums, arbitrary webpages). Use:

  • Strict allowlists for contracts and function selectors
  • Spend limits and time-based cooldowns
  • Human-in-the-loop for new protocols or large moves
  • Emergency pause + escape hatches

3) UX vs. MEV resistance

Private orderflow, commit–reveal, and solver-based intents improve execution but add latency and reduce “chatty” responsiveness. Decide what your users value: immediacy or best price.

4) Upgradability vs. credibility

Agents evolve weekly; on-chain contracts should not. If you must upgrade:

  • Use modular architecture (policy module, execution module, registry)
  • Version policies and publish diffs
  • Prefer “upgrade by adding modules” over mutable core logic

5) Data availability and memory integrity

If your agent’s “memory” influences financial decisions, you need integrity:

  • Store hashes of transcripts/plans on-chain (or in a DA layer)
  • Use content-addressed storage for full logs
  • Track provenance: which tools, which oracles, which model version

A pragmatic reference architecture (what we recommend)

For most teams shipping in the next 6–12 months:

  1. ERC-4337 smart account as the agent identity (session keys, paymasters).
  2. Policy contract enforcing spend limits, allowlists, slippage, risk parameters.
  3. Execution router that calls vetted protocol adapters (no arbitrary external calls).
  4. Off-chain agent service that plans actions, simulates, and proposes transactions.
  5. Observability: on-chain event logs + off-chain signed decision records (hash-anchored).
  6. MEV strategy: private relay or intents for trades.

This gives you credible safety and composability without pretending LLMs are verifiable on-chain today.

Conclusion

On-chain AI agents aren’t about running GPT inside a smart contract. They’re about where you draw the trust boundary: put identity, policy, and settlement on-chain; keep heavy cognition off-chain; and add verifiability where the business demands it.

If you’re building an agent that can move money, the winning architecture is usually conservative: a constrained on-chain policy engine, modular execution, and an off-chain planner that’s treated as fallible. The product isn’t the model—it’s the system that makes the model safe.