On-Chain AI Agents: Architecture and Tradeoffs

“On-chain AI agent” is an overloaded term. For founders, it often means an autonomous actor that can hold funds and execute strategies. For developers, it usually means a smart-contract-controlled workflow that calls AI off-chain. In practice, almost nobody runs large models fully on-chain—because the economics and execution model don’t allow it.

The interesting work is in designing agent systems that are verifiable enough to be trusted, yet cheap and fast enough to ship. This post breaks down the core architectures and the tradeoffs you can’t avoid.

What we mean by “on-chain AI agent”

An on-chain AI agent is best defined by where authority lives, not where “intelligence” runs.

An agent is “on-chain” if:

  • Funds and permissions are controlled by smart contracts (not a single server wallet).
  • State and decision context are auditable (at least in summary form).
  • Actions are enforced by on-chain rules (spend limits, whitelists, timelocks, veto windows, etc.).

The model inference, embeddings, web browsing, and long-horizon planning may happen off-chain—but the right to act is governed on-chain.

Reference architecture: the minimum viable on-chain agent

Most production-grade designs converge on a layered architecture:

  1. On-chain Agent Controller (smart contract)
    Holds funds (or controls a Safe), defines permissions, validates signed intents, enforces policies (limits, allowlists), and emits events for transparency.

  2. Off-chain Agent Runtime (service/worker network)
    Runs the model, tools, memory store, and planners. Watches chain events, maintains off-chain context, proposes actions.

  3. Oracle / Attestation Layer
    Bridges off-chain claims to on-chain verification: signatures, threshold committees, TEEs (e.g., SGX), zkML proofs (rare in production), or optimistic challenges.

  4. Execution Layer (protocol integrations)
    The actual action targets: DEX swaps, lending markets, NFT bids, payroll, DAO ops.

The design question is: how much of (2) you can trust, and how much of (3) you can afford.

Architectural pattern #1: “Policy on-chain, intelligence off-chain”

This is the dominant pattern and the one we recommend by default.

How it works:

  • The AI runtime proposes an “intent” like: swap 50,000 USDC to ETH on Uniswap v3, max slippage 30 bps, deadline 5 min.
  • The runtime signs it (or multiple parties sign it).
  • The on-chain controller checks policy constraints and executes the call.

Why it’s good:

  • Cheap and fast (no expensive verification).
  • Easy to iterate on models/tools.
  • You can harden risk with strict guardrails.

What can go wrong:

  • If the runtime is compromised, it can propose malicious actions within the allowed policy.
  • “Model risk” becomes “policy design risk.” Your contract is only as safe as your constraints.

Practical guardrails that actually work:

  • Spend limits per epoch (hour/day/week).
  • Destination allowlists (only certain protocols/pools).
  • Price sanity checks via TWAP or oracle bounds.
  • Timelocks for large moves + optional human/DAO veto.
  • Circuit breakers keyed to drawdown, volatility, or oracle deviation.

This pattern is ideal for treasury ops, automated market making parameters, liquidation bots with capped exposure, and “autopilot” DeFi strategies.

Architectural pattern #2: Multi-sig / committee-controlled agents

Instead of trusting one runtime, you require threshold approvals:

  • N-of-M signers can be humans, bots, or independent operators.
  • Each signer validates the proposed intent (some using AI, some using deterministic checks).

Tradeoff: higher trust and resilience, but slower and more complex operations.

Where it shines:

  • DAO treasury actions.
  • Market-moving trades.
  • Governance execution (proposal batching, parameter updates).

Opinionated take: committees are underrated. If you can tolerate latency, an N-of-M signer design often beats fancy cryptography in real-world reliability.

Architectural pattern #3: Optimistic execution with on-chain challenge

This mirrors optimistic rollup thinking:

  • The agent executes actions immediately.
  • A challenge window allows watchers to dispute if constraints were violated (e.g., wrong oracle price, disallowed pool, exceeded limit).
  • If challenged, the action is reversed (when possible) or the agent is penalized via bonded stake.

Core benefit: you get speed most of the time, with an enforcement backstop.

Hard truth: reversal is not always feasible in DeFi. Many actions are irreversible (AMM swaps), so you’re really relying on bonded penalties and ex-ante constraints.

Architectural pattern #4: Verifiable inference (zkML / TEEs)

This is the “full verification” direction:

  • TEEs attest that inference ran on a specific model and code, producing a specific output.
  • zkML generates a proof that a model produced an output for a given input.

Reality check on tradeoffs:

  • TEEs are practical today but introduce hardware trust assumptions and operational complexity.
  • zkML is improving rapidly, but for non-trivial models it’s still expensive and slow for many use cases.

Where verifiable inference makes sense:

  • High-value decisions where the integrity of the output matters more than latency.
  • Compliance-heavy flows (e.g., policy enforcement, risk scoring) where you must prove the process.

For most on-chain agents, verifiable inference is best used selectively: prove a risk check, not the whole LLM conversation.

The key tradeoffs (and how to choose)

1) Cost vs. verifiability

On-chain compute is expensive and constrained. Verification layers add cost:

  • Pure off-chain intelligence: cheapest.
  • Committee signatures: moderate.
  • Optimistic with bonds: moderate + operational load.
  • TEE/zk proofs: highest.

A pragmatic approach: spend verification budget where the blast radius is largest (large trades, governance actions, irreversible moves).

2) Latency vs. autonomy

Agents that wait for confirmations, multiple signatures, or proofs will be slower.

If your strategy depends on sub-minute execution (liquidations, MEV-sensitive rebalances), you’ll typically accept less verification and compensate with tighter policy limits.

3) Transparency vs. privacy

On-chain state is public. If your agent’s edge depends on proprietary signals, posting raw prompts or features on-chain is self-sabotage.

Use patterns like:

  • Commit-reveal for sensitive parameters.
  • Store detailed traces off-chain; publish hashes on-chain.
  • Prove constraints satisfied rather than revealing full inputs.

4) Determinism vs. model behavior

Smart contracts require deterministic execution; LLMs are probabilistic.

A solid pattern is to force the agent to output structured intents (EIP-712 typed data) and reject anything outside a strict schema. Treat free-form text as untrusted.

A concrete example: a DeFi “treasury steward” agent

A realistic on-chain agent for a protocol treasury might:

  • Monitor stablecoin yield markets off-chain.
  • Propose reallocations (e.g., move 5% from Aave to Maker’s DSR-equivalent).
  • Enforce on-chain rules: max 2% per day, only whitelisted venues, oracle-based rate comparisons, and a 6-hour timelock for moves above $250k.
  • Use a 2-of-3 committee: the AI runtime + an independent risk bot + a human ops signer for large moves.

This achieves meaningful autonomy while keeping failure modes bounded.

Conclusion: “On-chain” is about control, not compute

The winning architecture for on-chain AI agents is rarely “run the model on-chain.” It’s put the money and permissions on-chain, run intelligence where it’s efficient, and use cryptography, committees, and constraints to make the system trustworthy.

If you’re building an on-chain agent, start by answering three questions:

  1. What actions can the agent take, and what’s the maximum acceptable loss?
  2. What constraints can be enforced deterministically on-chain?
  3. Where do you need stronger guarantees: signatures, optimistic challenges, or verifiable inference?

Get those right, and you’ll ship something that survives real markets—not just demos.