An AI agent in Web3 is a system that takes a defined input, reasons about it using a language model, and performs a bounded action against wallets, contracts, or on-chain data, with the limits of that action written down and enforced.

The three parts, and which one people forget

There are three parts: an input, a reasoning step, and an action. Most conversation about agents focuses on the reasoning, because that is the new and interesting part. The part that decides whether an agent is usable in Web3 is the action, and specifically how narrow it is.

A bounded action means the agent does one defined thing with a defined range of acceptable outcomes, and refuses everything else. In most software a wrong action is annoying. In Web3 a wrong action can move value that cannot be recovered, which is why the boundary is the engineering work and the model is the easy part.

How an agent differs from a bot

A bot responds to a trigger with a fixed response. An agent reasons over messy input and decides what to do. That difference is real, and it is also smaller than it sounds. Many things sold as agents are triggers with extra steps, and many things that genuinely need reasoning get built as bots and fail on the inputs nobody anticipated.

The practical test is what happens with an input the designer did not expect. A bot does something unhelpful and predictable. An agent invents a plausible response, which is either the value or the danger depending on how the boundary was set.

What an AI agent in Web3 is not

  • A chatbot with a personality. Conversation is an interface, not a capability. An agent that chats and does nothing is a support widget.
  • A smart contract. Contracts execute deterministic rules on-chain. An agent reasons off-chain and may call a contract. They solve different problems.
  • Autonomous by default. Autonomy is a design choice you grant, action by action. Where an action is irreversible, the correct design is a person approving it.
  • Something that needs a token. A token changes the economics and the regulatory picture. It does not make the agent work better.

Where one actually earns its place

Agents are worth building where a task needs interpretation and happens often enough that a human doing it is expensive. In Web3 that tends to be support and community questions, monitoring that turns a firehose into a small number of signals, analysis that points at a specific next action, and developer or operations tooling that holds context across a long task.

Two of my projects are working examples. Valor runs inside Telegram and is constrained by an explicit system boundary rather than allowed to improvise. AgentHub is the permission layer that decides what an agent is allowed to reach, with human approval for high-risk operations.

The five questions that decide whether it is worth building

Most agent projects fail at the specification stage rather than the build stage, and the specification is usually one paragraph long. These are the five questions I write down before anything else.

  1. What triggers it? If the answer is that a person asks it something, you are building a search box with an ongoing bill attached.
  2. What is the one action it takes? One. An agent with three actions has three failure modes and usually no single owner for any of them.
  3. What happens when it is wrong? If the answer is that value moves and cannot be moved back, the design needs a human gate rather than a better prompt.
  4. How often does the task happen? An agent that runs twice a week has to be simpler than one that runs two thousand times a day, because nobody will notice the slow one drifting.
  5. What does it cost to run? Every message it reads and every chain call it makes is a line on a bill. If that cost scales with the noisiest thing your users do, the economics will decide the product whether or not you do.

Where the running cost actually goes

An agent that touches Web3 has two meters running: model calls and chain data. Model calls are cheap individually and expensive in volume. Chain reads are cheap individually and expensive the moment a provider rate limits you and the retries begin.

The design move that matters most is putting cheap logic in front of the expensive step. Valor discards the majority of messages using filters written in plain code, before a single model call happens. That is not an optimisation added afterwards. It is the reason the economics work at all.

The design question I start with is not what the agent should do. It is what the agent should refuse to do. That reasoning is written up in how to use AI in Web3 without blindly trusting it.