AI agents and autonomous smart contracts: what works, how to build it, and what can go wrong

Smart contracts can't think, and AI models can't be trusted with unlimited keys. The useful designs put an AI agent off-chain to decide what to do, and use smart contracts to strictly limit what it is allowed to do.

"Autonomous smart contracts" is a phrase that promises more than the technology delivers. A smart contract is deterministic code that runs only when a transaction calls it; it can't call an AI model, browse the web or wake itself up. An AI agent, on the other hand, can reason over messy inputs but is probabilistic and manipulable. Combining them well means assigning each the job it's good at.

What an "AI agent" means on-chain

In practice, an on-chain AI agent is a program that:

• observes state (balances, prices, governance proposals, messages from users);
• uses a language model or other model to decide on an action;
• calls tools, such as an RPC node, a DEX router or a lending protocol, to carry it out;
• signs and submits transactions from a wallet it controls.

The last step is what makes blockchain agents different from ordinary AI assistants. A mistaken email can be apologized for. A mistaken transaction is usually final.

Use cases that hold up

The pattern is clear: the more an agent's authority is bounded by on-chain rules, the more practical it is. Wallet copilots and DAO assistants deliver value with little risk because a human or a vote stays in the loop.

A reference architecture

A safe agent system has five layers. Keeping them separate is the most important design decision you will make.

1. Perception and data

Indexers, RPC calls and oracle feeds supply facts. Treat everything here as untrusted: token names, NFT metadata, governance proposal text and web pages can all carry hidden instructions.

2. Reasoning

The language model plans an action. It should output a structured proposal (target contract, function, arguments, expected outcome), not raw signed bytes.

3. Policy engine

Deterministic code, outside the model, checks every proposal against rules: allowlisted contracts and functions, maximum amounts, slippage bounds, daily limits, known-bad addresses. The model can't talk its way past code it doesn't control.

4. Simulation

Before signing, simulate the transaction against current state (for example with eth_call or a forked node) and compare the resulting balance changes with what the agent claimed would happen. Abort on any mismatch.

5. Constrained signer

Keys live in an HSM, a secure enclave or an MPC service, never in the agent's prompt or environment variables in plain text. Better still, the agent signs as a limited "session key" on a smart contract account.

Smart accounts are the real enabler

Account abstraction turned this from fragile to workable. With an ERC-4337 smart account (or an externally owned account upgraded through EIP-7702, introduced in Ethereum's 2025 Pectra upgrade), the wallet itself is a contract that can enforce rules. You can grant an agent a session key that:

• only calls specific contracts and functions;
• spends at most a set amount per day;
• expires after a fixed time;
• requires a human co-signature above a threshold.

Even if the model is fully compromised, the damage is capped by the account's rules. This is the closest thing to an "autonomous smart contract" that is safe today: the contract defines the envelope, and the agent acts inside it. The Web3 wallet development guide covers smart account design in more depth.

Can the AI run on-chain?

Not in any practical sense. Model inference is far too expensive for an EVM. Three approaches try to make off-chain inference verifiable:

• Trusted execution environments (TEEs). The model runs in a hardware enclave that produces an attestation. Practical today, but you trust the chip vendor and enclaves have had side-channel vulnerabilities.
• zkML. A zero-knowledge proof shows a specific model produced a specific output. Strong guarantees, but proving costs are still high for large models.
• Optimistic verification. Results are accepted unless challenged and re-executed. Cheaper, but needs deterministic inference and a challenge window.

For most products, verifiable inference is less important than bounded authority. Proving that a model produced an output doesn't prove the output was wise.

The risks specific to on-chain agents

• Prompt injection. An attacker plants instructions in data the agent reads: a token's name, a message, an NFT description. In the public "Freysa" experiment in late 2024, an AI agent instructed never to release a prize pool was eventually talked into transferring it. Policy code, not the system prompt, must be the final gate.
• Key exposure. Agents often run on servers with broad access. A compromised host or leaked API credentials can be as damaging as a compromised model.
• Hallucinated parameters. Wrong token addresses, wrong decimals or invented contract functions. Resolve addresses from a verified registry, never from model output.
• MEV and adversarial markets. Predictable agents are easy to front-run or sandwich. Use private transaction submission and tight slippage limits.
• Feedback loops. Many agents reacting to the same signals can amplify volatility, the on-chain version of a flash crash.
• Accountability and regulation. If an agent manages other people's money, the operator may be acting as an investment adviser or money transmitter. "The AI did it" is not a legal defense.

Building one: a staged approach

1. Start read-only. Build the agent as an analyst that explains and recommends. Measure how often its recommendations would have been right.
2. Add human-approved execution. The agent proposes transactions; a person signs. Log every proposal and outcome.
3. Write the policy first. Before granting any autonomy, codify allowlists, caps and kill switches in the smart account and the off-chain policy engine.
4. Grant narrow session keys. Small budgets, short expiry, one protocol at a time.
5. Red-team it. Attempt prompt injection through every input channel, test with adversarial market conditions on a fork, and have the account contracts audited.
6. Monitor and widen slowly. Alert on unusual behavior, keep a pause function, and expand limits only with evidence.

Operating an agent in production

Most of the engineering effort in a live agent goes into operations, not prompts. A few practices separate systems that survive from ones that end in a post-mortem.

Log decisions, not just transactions

The chain already records what the agent did. What you need off-chain is why: the inputs it saw, the model version, the proposal it produced, which policy checks passed and the simulation result. Without that trail you can't debug a bad trade or show a regulator or user what happened.

Pin model versions

Hosted models change behavior between versions. Treat a model upgrade like a code deployment: test it against recorded scenarios on a forked chain, compare decisions with the previous version, and roll out with reduced limits first.

Monitor outcomes against expectations

Alert when realized slippage, gas spend, trade frequency or counterparties drift from normal ranges. Many failures look like a slow leak rather than a single large loss, for example an agent repeatedly paying high fees because a price feed went stale.

Rehearse the kill switch

Every agent should have a pause path that doesn't depend on the agent: revoking its session key from the smart account, or a guardian role that freezes the account. Test it on a schedule, the same way you would test backups.

Measure whether autonomy pays

Compare the agent with a simple rules-based bot doing the same job. If deterministic rules achieve similar results, they are cheaper, easier to audit and immune to prompt injection. Use a model only where judgment over unstructured inputs adds measurable value.

Emerging standards worth watching

Several efforts aim to give agents identity and payment rails: draft proposals such as ERC-8004 for agent identity and reputation registries, HTTP-based payment schemes that let an API request carry a stablecoin payment, and session-key and permission standards for smart accounts. They are early; design so you can swap components as standards settle.

Related reading: the smart contract development guide, why audits matter, and evaluating an AI development partner.

Frequently asked questions