Anthropic released Claude Fable 5 on June 9 2026, the first time a Mythos-class model has been placed in public hands, and the company framed it plainly as the engine for the next era of autonomous AI Agents. The headline capability is not a benchmark, even though Fable 5 took the top of Code Arena by 98 points. It is duration. Fable 5 runs autonomously for longer than any Claude model before it, to the point where Stripe reported it migrating a 50-million-line codebase in a single day, work that would have taken a team of engineers more than two months by hand. When the unit of work shifts from answering a prompt to finishing a job, the question stops being how smart the model is and becomes what an AI Agent is allowed to touch while no one is watching.

That is the gap Fable 5 widens rather than closes. A more capable model makes an AI Agent better at deciding what to do, but it does nothing to guarantee that the data the Agent acted on was real, that the action it took can be verified after the fact, or that the value it moved settled the way it was supposed to. Capability and trust are different problems, and the industry has spent the last two years pouring almost everything into the first one.

Why a smarter model does not close the agent trust gap

The clearest signal that capability has outrun safe deployment came from Anthropic itself. Fable 5 shipped with safeguards that silently reroute queries on sensitive topics like cybersecurity and biology to the older Claude Opus 4.8, so the most capable public model now runs with a quiet governor bolted on. A company puts a throttle on a system when the system can do more than it can be trusted to do unsupervised, and that same logic scales the moment you hand the model a wallet, an API key and a goal.

Pricing makes the timing sharper. Anthropic put Fable 5 at ten dollars per million input tokens and fifty per million output tokens, less than half the price of its previous Mythos preview, and made it free on paid plans until June 22. That is a distribution move, not a margin one, and it means a wave of AI Agents built on a Fable 5-class model is about to start running longer and acting more independently than anything that came before. The model deciding what to do gets cheaper and better every release. The part that confirms the Agent acted on real inputs and produced a result anyone can check does not come from the model at all.

What autonomous AI Agents actually need to act unsupervised

An AI Agent running a job end to end needs three things the model cannot provide on its own. It needs verified data, so that the price it trades against or the message it reacts to is real rather than spoofed or stale. It needs verifiable action, so that the decision it made and the step it executed leave a record others can check instead of a black box anyone has to take on faith. And it needs reliable settlement, so that when the Agent moves value the transfer is final and correct rather than reversible or forged. Strip any one of these away and a more capable model just reaches the wrong outcome faster.

The failure modes are not hypothetical, because we already watch them play out in systems with far less autonomy than Fable 5 invites. An Agent that pays out against a manipulated price feed loses the money exactly as designed. An Agent that acts on a cross-chain message no one can verify executes fraud on schedule. The more independently these systems run, and the longer they run before a human looks, the more the absence of a trust layer compounds rather than corrects.

How verification and settlement become the real bottleneck

For two years the constraint on AI Agents was the model, so that is where the money and attention went. Fable 5 is the clearest sign that the constraint is moving. Once a model can run a multi-step job unsupervised for hours, the thing standing between a useful Agent and a dangerous one is no longer intelligence but the fabric that verifies inputs, attests to actions and settles outcomes. Whoever provides that fabric stops being optional infrastructure and becomes the layer the whole Agent economy depends on.

This is the question Proving Ground keeps returning to, because it is the question Taiko is built around. A trust and settlement layer for autonomous AI Agents is the part of the stack that turns a capable model into an Agent you can actually let run, and Fable 5 just made the case for building it more urgent than any benchmark could.

This post is exploratory and does not represent a specific roadmap.

AI Agent memory works in two layers. There is short-term memory, which is whatever fits inside the model’s context window during a single run, and there is long-term memory, which is everything the Agent writes to an external store so it survives the session ending. The short-term layer is fast and disappears the moment the context resets. The long-term layer is where the durable stuff lives, usually a vector database for semantic recall and sometimes a graph database for relationships between facts, and it is the layer most teams underbuild. By 2026 the dominant production pattern is hybrid, a short-term episodic buffer sitting on top of vector plus graph retrieval, because no single structure covers everything an AI Agent needs to remember. What almost nobody specifies is where those long-term bytes physically sit and who pays to keep them there, which turns out to be the part that breaks when an Agent has to run on its own.

What short-term and long-term memory actually mean for an AI Agent

Short-term memory is the context window. It holds the current conversation, the last few tool outputs, the active goal and the intermediate reasoning the model is using to decide what to do next. It is quick and it is local to the run, which is exactly why it is fragile. When the window fills up or the session ends, that working state is gone unless the Agent deliberately moved it somewhere first. People treat the context window as memory because it behaves like memory inside one session, but it is closer to RAM than to a hard drive. Nothing in it persists by default.

Long-term memory is what you get when the Agent writes selected pieces of that working state out to an external store so a future run can read them back. The research literature, borrowing from cognitive science, splits long-term memory into three rough types. Episodic memory records specific past events, what happened, what the Agent did and how it turned out. Semantic memory holds general facts the Agent has learned and can reuse, like a user’s preferences or a stable piece of domain knowledge. Procedural memory captures how to do a recurring task, the learned routine rather than the one-off event. An AI Agent that remembers you across weeks is reading episodic and semantic memory back into its context window at the start of each run, then writing new entries at the end.

How retrieval works once the memory lives outside the model

The reason long-term memory needs more than a text file is retrieval. An Agent cannot reload everything it has ever stored into a context window, so it has to fetch only the relevant pieces, and “relevant” is a fuzzy match rather than an exact key. That is what a vector database does. Each stored memory gets converted into an embedding, a numeric representation of its meaning, and at recall time the Agent embeds its current situation and pulls the stored items that sit closest in that space. This is why an Agent can surface a note you wrote three weeks ago that never shared a single keyword with what you just asked. Graph databases handle the other half of the problem, the relationships between facts, so an Agent can traverse from a person to the project they own to the deadline attached to it rather than guessing those links from similarity alone. Most serious deployments in 2026 run both, a vector store for semantic recall and a graph for structure, with the short-term buffer in front of them. Frameworks like mem0, LangGraph, Letta and Redis exist mostly to wire that pipeline together, the extraction step that decides what is worth keeping, the consolidation step that refines it and the retrieval step that reads it back.

Where the memory actually lives, and why that breaks for autonomous Agents

Here is the gap every memory diagram skips over. A vector database stores embeddings, but embeddings still point at bytes, the original document, the image, the working note, the per-user state the Agent is keeping. Those bytes have to sit somewhere durable, and that somewhere has historically been a cloud bucket behind an account, an API key and a credit card. That assumption is fine when a human set the Agent up and pre-funded everything. It falls apart the moment you want an AI Agent to manage its own memory, because the Agent cannot open an account, cannot rotate a key and cannot sit through a billing signup. The memory layer everyone designs around quietly depends on a human standing behind it holding the storage relationship together.

This is the problem Tack was built for. It gives an AI Agent a memory layer it can stand up and pay for by itself, no human holding the storage relationship together. Tack is the agent-native storage product from Inference Room, built on Taiko, and it stores the bytes behind an Agent’s memory without any of the account scaffolding. The Agent writes a private object to Tack, pays a fraction of a cent in USDC inline with the request through x402, and gets back an id that only the paying wallet can read. A 5MB memory object held for a month settles at $0.0010, with no signup, no API key and no human in the loop. The object is wallet-scoped rather than sitting at a public address, so per-user session memory, drafts and working notes stay private to the Agent that owns them, and it expires after the paid duration so memory is something the Agent rents for as long as it needs it. The wallet that pays for the Agent’s compute is the same wallet that owns its memory, which is the shape autonomous memory actually needs.

Tack is the agent-native storage layer from Inference Room, built on Taiko and settling in USDC via x402 with no accounts, and it gives AI Agent memory a durable place to live that the Agent can pay for and own by itself. It is open at tack.inferenceroom.ai now.

This post is exploratory and does not represent a specific roadmap.

On February 21, 2025, Bybit lost roughly 1.5 billion dollars from an Ethereum cold wallet, the largest crypto theft on record. The multisig worked exactly as designed. The threshold was met, the required owners signed and the transaction executed. What failed was legibility. The signers saw a benign transfer in their interface while the calldata underneath moved 401,000 ETH to addresses controlled by North Korea’s Lazarus Group. They approved what they could see, and what they could see had been quietly swapped for something else. This is blind signing, the practice of authorizing a transaction whose true effect you have not independently verified, and the gap between what a multisig owner reads and what they actually authorize is the single largest unsolved problem in on-chain treasury operations. It gets worse the moment AI Agents start touching the same Safes.

A multisig is supposed to remove single points of failure by requiring several humans to agree before money moves. The security model assumes each of those humans can evaluate what they are agreeing to. Strip that assumption out and a five-of-nine Safe is not five independent checks, it is one unreadable transaction signed five times.

Why multisig review collapses into trust

Reviewing a Safe transaction properly is real work. You decode the raw calldata into a human-readable action, simulate the resulting state against the current chain to confirm the action does what it claims, check the counterparty address against the team’s history of known entities and then match the whole thing to whatever invoice, spec or governance proposal authorized it in the first place. Done carefully that is fifteen to twenty minutes per transaction, and a busy treasury signs several a week across payroll, vendor payments and contract upgrades.

Nobody has that time on every transaction, so review quietly degrades into pattern-matching. A familiar Slack message, a signer you trust, a transaction that looks like last month’s, and the signature goes through in seconds. Bybit’s fatal signature cleared in well under a minute. The interface said one thing, the bytes said another and the social proof of nine colleagues all clicking approve did the rest. Trust filled the space where review was supposed to be, and trust is precisely the thing an attacker manufactures.

What blind signing actually costs

Blind signing happens because the tooling shows owners a hex string and a destination and asks them to trust that the two match the intent in their heads. It is not an edge case reserved for billion-dollar exchanges, it is the default operating mode of almost every multisig, because decoding calldata by hand on every transaction is impractical for any team moving at the speed of a real treasury.

The cost is not only catastrophic theft. It is also the slow tax of routine error, a transfer with one zero too many, a payment to a stale address, a contract upgrade pointed at the wrong implementation, a duplicate nonce that quietly competes with a legitimate transaction already in the queue. Each of these is an unreadable transaction that a human waved through because reading it correctly would have meant twenty minutes they did not have. The exploits make headlines. The fat-finger losses and misrouted payments never do, and in aggregate they cost teams more than the rare heist.

How AI Agents make legibility non-negotiable

The pressure is about to compound. Finance teams are starting to put AI Agents into the loop on treasury operations, drafting transfers, assembling contract calls and managing recurring payments at machine speed. An Agent that proposes transactions faster than humans can carefully read them does not fix blind signing, it industrializes it. Speed on the proposal side without legibility on the approval side just means more unreadable transactions arriving more often.

The way out is not to take humans off the keys. It is to put something between the proposal and the signature that does the twenty minutes of review every time, without getting tired or pattern-matching. That something has to decode every transaction into plain language, simulate it before a single owner signs, reconcile it against the invoices and history that authorized it and hold anything that does not match. It has to be wired into the systems a finance team already uses, the Safe queue, the directory of known counterparties, the folder of invoices, the team’s accumulated memory of what normal looks like. And it has to be structurally incapable of signing on its own, a reviewer and proposer that never holds a key and never counts toward the threshold, so the humans stay in control while finally getting to read what they sign.

Multisig was built so that no single person could move the money alone. The next layer has to make sure that when those people do sign, they can actually see what they are signing. An AI Agent that reads every transaction before the first signature, and refuses to stay quiet when the calldata and the invoice disagree, is what turns a multisig back into the safeguard it was always supposed to be.

This post is exploratory and does not represent a specific roadmap.

AI Agents can hold wallets, execute trades and settle payments without a human in the loop. What they still can’t do, in most stacks, is operate a regulated real-world asset. A bond, a private equity stake or a real estate share carries compliance rules that have to be enforced before every transaction executes. Without a standard that encodes those rules at the protocol level, every autonomous operation still needs a human to sign off. That standard now exists. It’s called RAMS.

The tokenization conversation has been running on one track for years. How much can you put on chain? The answer got very large very fast. The track nobody talks about is what happens after the asset is minted. Keeping it compliant, tracking ownership, enforcing transfer restrictions for years, for every new owner, across every secondary transaction. That operational layer is what separates a proof of concept from a running financial product. And it is the layer AI Agents need access to if they are going to do anything useful.

Why AI Agents can’t just execute transactions on tokenized assets

The asset is on chain. The agent has a wallet. So what’s stopping it?

Regulatory constraints are stopping it. Tokenized real-world assets are not like fungible tokens. A bond, a private equity stake and a real estate share each carry rules about who can hold them, when they can move and under what conditions a transfer is valid. Those rules are not optional. A transfer that violates them is not just invalid; it creates liability for the issuer.

The problem is delegation. How does an institution define what an AI Agent is allowed to do? On whose behalf? Within what limits? And how do you make that definition legally meaningful rather than a policy document that no system actually checks?

Without a standard that answers those questions at the contract level, every autonomous operation stalls the same way. A human has to approve before anything settles. You have tokenized the asset. You have not automated it.

What RAMS does for AI Agents operating regulated assets

RAMS (Regulated Agent Mandate Standard) is Brickken’s compliance delegation framework. It encodes agent authority directly at the protocol level so that every transaction an AI Agent initiates is checked against a machine-readable mandate before it executes.

A RAMS mandate defines what the AI Agent can do (execute transfers, trigger distribution events, rebalance positions), whose authority it acts under, which transfer restrictions apply and what it cannot do regardless of instruction. Each agent carries an attested identity. Every action it takes runs through RAMS-defined rules before the transaction settles.

This is not post-hoc auditing. The compliance gate runs before execution. An AI Agent operating under RAMS can move a tokenized asset through a fully automated workflow, overnight, at volume, without a human in the loop, and every step stays within the ownership and compliance controls the issuer requires.

That is a qualitatively different capability than what existed before. The asset is no longer just on chain. It is operable.

Why the execution environment matters for RAMS

A compliance standard that can’t handle sustained automated load is a compliance standard with nowhere to go. Tokenized assets under active management don’t generate one transaction at issuance and then go quiet. They generate compliance checks, ownership updates, dividend distributions and secondary transfers continuously, across the life of the asset.

Taiko is a Type 1 zk-EVM running Ethereum-equivalent execution secured by zero-knowledge proofs. Issuers bring existing Ethereum contracts with no migration required. Taiko handles the transaction volume that continuous agentic operations generate, at costs that make RAMS-gated automation viable at scale. Brickken’s full stack (WebApp, whitelabel product and direct API) runs natively on Taiko, so builders inherit the complete asset lifecycle including RAMS from day one.

Real-world assets and AI Agents are converging faster than most infrastructure was built to handle. The bottleneck is not issuance. It never was. It is whether an agent can operate the asset after it’s on chain, with the same compliance guarantees an institution needs. RAMS on Taiko is the answer to that question.

RAMS (Regulated Agent Mandate Standard) is Brickken’s compliance delegation standard for AI Agents operating regulated on-chain assets, enforced at the protocol level before transaction execution, now running natively on Taiko’s Ethereum-equivalent Layer 2.

This post is exploratory and does not represent a specific roadmap.

Earlier this week, Gustavo Gonzalez wrote about building defi-cli and why he started the project. This follow-up zooms out on the concept underneath it: what an agent-first CLI actually is, why it’s a different beast from a regular command-line tool and why DeFi needs this category to exist at all.

Most CLIs were built for humans. You type a command, read the output, decide what to do next. That workflow breaks the moment an AI Agent is the one typing.

AI Agents don’t read help text. They don’t eyeball a table of numbers and “get the gist.” They need structured output, predictable errors and a way to discover what’s possible without guessing. An agent-first CLI is a command-line tool designed from the ground up for machines to operate. Not adapted. Not patched. Built.

This matters more than it sounds. The entire DeFi stack today assumes a human is driving. Frontends are visual. APIs are fragmented across chains and protocols. There’s no universal way for an AI Agent to say “swap 100 USDC for ETH on the cheapest route” and get a deterministic, parseable answer back. Every protocol speaks its own dialect. Every chain has its own quirks. An agent trying to navigate this landscape hits the same wall a developer did five years ago, except the agent can’t improvise around bad documentation.

defi-cli: What It Actually Does

defi-cli is an open-source command-line tool built by Taiko’s Head of Engineering, Gustavo Gonzalez. It consolidates DeFi operations across multiple protocols and blockchains into a single, machine-readable interface.

That means lending, borrowing, swapping, bridging, yield strategies and balance queries all run through one tool. Aave, Morpho, Moonwell, 1inch, Uniswap, Jupiter, Across, LiFi and more. Ethereum, Optimism, Base, Arbitrum, Taiko and a growing list of L2s. One interface. One output format.

But the real point isn’t convenience. It’s architecture.

Why “Agent-First” Isn’t a Buzzword Here

Three things make defi-cli fundamentally different from a regular CLI that happens to have a --json flag.

Structured everything. Every response is JSON. Every error returns a deterministic exit code (there are 24 of them, each mapping to a specific failure type). An AI Agent doesn’t have to parse prose to figure out what went wrong. It reads a code, decides whether to retry, escalate or abort.

Discoverability by machines. Run defi schema and the tool returns a complete, machine-readable description of every command, every parameter, every expected input and output. An AI Agent can learn the entire tool’s capabilities in a single call. No documentation crawling. No guessing at flags.

No implicit defaults. Human-friendly CLIs love defaults. They assume you probably mean mainnet, you probably want the cheapest route, you probably don’t need a dry run. Agent-first design strips that out. Everything is explicit because agents that assume things lose money.

The Two-Phase Safety Net

defi-cli uses a plan-then-execute model. First the agent requests a dry run: “Here’s what would happen if you executed this swap.” Fees, routes, expected outputs. Then, only if the result looks right, it submits the transaction. This is critical for AI Agents operating with real capital. The two-phase approach means an agent can validate its own plan before committing funds, and a human can audit the agent’s reasoning at the plan stage without blocking execution entirely.

Why This Matters Beyond One Tool

defi-cli isn’t just a product. It’s a signal of where the stack is heading.

Right now, most AI Agent projects in DeFi bolt an LLM onto an existing interface and call it “AI-powered.” The agent is a wrapper. defi-cli inverts that. The tool is built assuming an agent is the primary user and a human is the occasional auditor. That’s a fundamentally different design philosophy, and it’s the one that scales.

As AI Agents move from demos to production, the infrastructure they depend on needs to be native to how they operate. Structured outputs. Predictable errors. Explicit parameters. Machine-readable schemas. The shift from human-first to agent-first tooling isn’t a nice-to-have. It’s the bottleneck.

defi-cli is open source. You can find it at github.com/ggonzalez94/defi-cli.

This post is exploratory and does not represent a specific roadmap.

If you ask most people where AI Agents will live, they’ll say “the cloud.” And they’re not wrong exactly, but they’re missing half the picture. The moment an AI Agent touches money, owns assets or makes commitments on someone’s behalf, it needs more than a server. It needs a blockchain. And not just any blockchain. It needs a rollup.

Here’s why.

Agents are economic actors now

The first generation of AI Agents lived inside chatbots and customer support widgets. They processed language, not value. But the current generation is different. These agents trade tokens, provide liquidity, manage portfolios and execute transactions across DeFi protocols without waiting for a human to click “confirm.”

When an agent moves $50,000 from one lending pool to another at 3am because it spotted a better yield, that action needs to be verifiable. Not “trust me, I did the right thing” verifiable. Cryptographically, publicly, permanently verifiable. That’s what a blockchain gives you: a shared ledger where anyone can audit what an agent did, when it did it and whether it followed the rules it was supposed to follow.

The problem is that running these operations on Ethereum mainnet is expensive. A single swap can cost $5-50 in gas depending on congestion. An agent making dozens of decisions per day would burn through its operating budget on transaction fees alone. Agents need blockchain-grade security without blockchain-grade costs.

That’s the case for rollups.

What a rollup actually gives an agent

A rollup processes transactions off Ethereum’s main chain but inherits its security by posting compressed transaction data back to L1. For AI Agents, this architecture solves three problems at once.

Cost. Transactions on a rollup cost fractions of a cent. An agent that rebalances a portfolio ten times a day doesn’t care about $0.002 per transaction. It very much cares about $15. Low fees turn agents from expensive curiosities into economically viable workers.

Speed. Rollups confirm transactions in seconds, not minutes. For an agent monitoring a volatile market and trying to capture a fleeting arbitrage opportunity, the difference between a 2-second and a 12-second confirmation window is the difference between profit and a missed trade.

Verifiability. Every action the agent takes is recorded on-chain and ultimately secured by Ethereum. If an agent claims it executed a trade at a certain price, anyone can verify that claim. This is the foundation of trust for autonomous software that handles other people’s money.

Why not just use Ethereum directly?

You could. But think about what happens at scale. One agent making ten transactions a day is manageable. A thousand agents each making a hundred transactions a day is 100,000 transactions, and that’s a conservative estimate for where this is heading. Ethereum mainnet processes roughly 15 transactions per second. The math doesn’t work.

Rollups are designed for exactly this kind of throughput. They batch hundreds or thousands of transactions together, compress them and post a single proof back to Ethereum. The agents get the speed and cost they need. Ethereum gets to stay secure without drowning in agent traffic.

The Taiko approach

Taiko is a based rollup, which means it uses Ethereum’s own validators for sequencing rather than running a separate centralized sequencer. For AI Agents, this matters because it removes a single point of failure from the stack. If your agent’s entire economic life depends on one sequencer operated by one company staying online and behaving honestly, you’ve reintroduced the centralisation risk that blockchain was supposed to eliminate.

Based sequencing also means Taiko inherits Ethereum’s liveness guarantees. If Ethereum is running, Taiko is running. An agent built on Taiko doesn’t need to worry about sequencer downtime or censorship, it just needs Ethereum to keep doing what Ethereum does.

This is why Taiko is building specifically for the AI Agent use case. The combination of low cost, fast confirmation, Ethereum-grade security and decentralised sequencing creates an environment where agents can operate autonomously at scale without the compromises that make other execution environments risky or expensive.

What this means practically

If you’re building an AI Agent that interacts with DeFi, you need an execution environment that is cheap enough for frequent transactions, fast enough for time-sensitive operations and transparent enough for users to trust an autonomous system with their assets. You also need that environment to be credibly neutral and resistant to censorship, because an agent that can be front-run or censored by the infrastructure it runs on isn’t really autonomous.

Rollups solve the cost and speed problem. Based rollups solve the trust and neutrality problem. That’s the thesis in one sentence.

The agents are coming regardless. The question is where they’ll settle their transactions and whose security guarantees they’ll rely on. Rollups built for this workload, not retrofitted for it, are going to be the answer.

This post is exploratory and does not represent a specific roadmap.

DeFi bots

A DeFi bot is a script or program that executes predefined logic on-chain. Most of the automated activity you see today falls into this category, from arbitrage bots that spot price discrepancies across pools to liquidation bots that fire transactions when a position’s health factor drops below a threshold. MEV bots and automated market makers work the same way. They’re fast, deterministic and narrow by design, and none of them reason about what they’re doing.

They don’t evaluate whether a strategy is good, weigh alternatives or adjust their approach based on new information. They execute the logic they were programmed with, and they do it well.

AI Agents

An AI Agent uses an LLM or similar reasoning system to interpret context, evaluate options and decide what to do. Where a bot follows an if-then script, an Agent can look at a set of yield opportunities across multiple chains, factor in historical performance, gas costs, bridge fees and risk tolerance, then decide where to allocate capital.

Crucially, Agents can interact with external tools like CLIs and APIs as part of their reasoning. An Agent with access to a DeFi CLI can query rates, compare protocols, plan a transaction, simulate it and then execute, all within a single loop. If the simulation fails it can adjust its approach rather than just retrying or stopping.

The key difference is that an Agent’s behaviour is not fully specified in advance. It reasons its way to an action rather than executing a predetermined one.

Where the line gets blurry

In practice the boundary between bots and Agents is not always clean. A bot with enough conditional logic starts to look like a decision-maker. An Agent with a narrow enough prompt starts to look like a bot. Some systems combine both, using an AI Agent for high-level strategy and bots for the fast execution underneath.

The useful distinction is about adaptability. If the environment changes in a way the developer didn’t anticipate, a bot breaks or does nothing. An Agent can reason about the new situation and try something different. That adaptability is what makes Agents interesting for DeFi, where conditions change constantly and the number of protocols, chains and strategies is too large for any single script to cover.

Why this matters for infrastructure

Bots and Agents have different infrastructure needs. Bots need speed, low latency and reliable mempool access. Agents need structured data, safe execution environments and the ability to simulate before committing funds.

Most blockchain infrastructure today was built for bots (and before that for humans). The tooling assumes either a person clicking buttons or a script that knows exactly what it wants to do. Agents sit in between. They need the programmatic access of a bot but with richer context, safer defaults and the ability to explore before acting.

This is why projects like defi-cli are building Agent-first interfaces with features like simulation flags, structured JSON output and separated plan-and-execute lifecycles. These aren’t things a traditional bot needs, but they’re essential for an Agent that’s reasoning its way through a transaction.

Quick comparison

DeFi bot: Executes predefined logic. Fast and deterministic. Breaks when conditions change unexpectedly. Narrow by design.

AI Agent: Reasons about what to do. Slower but more adaptable. Can handle novel situations. Uses tools like CLIs and APIs to interact with protocols.

Both: Operate autonomously on-chain. Don’t require a human in the loop for execution. Are already active across DeFi today.

The shift from bots to Agents is not a replacement. Bots will continue to handle the fast, deterministic tasks they’re good at. But the decision-making layer on top, the part that decides which strategy to run, which chain to use, which protocol to trust, is moving toward Agents. That’s where infrastructure needs to catch up.