Most DeFi tooling assumes there’s a human on the other end; someone clicking buttons, approving transactions, checking dashboards, etc. But now the user on the other end might be an AI Agent managing a portfolio, optimizing yield and executing trades across chains. And it can’t click buttons. That’s why I built defi-cli, a command-line interface (CLI) that lets Agents query rates, compare yield, swap, lend, borrow, bridge and claim rewards across 26+ chains.

Why a CLI and not an MCP server?

Model Context Protocol (MCP) servers became a popular approach for giving Agents access to external tools. After building both, I would recommend against them where possible. They introduce significant context overhead in the form of schema descriptions, tool metadata and connection management that consumes the Agent’s limited context window. A CLI avoids this entirely. The Agent calls a command, receives structured output and proceeds. No persistent connection, no schema negotiation.

Humans want dashboards. Agents want tools they can pipe, and that don’t bloat their context windows.

What “Agent-first” actually means

“Built for Agents” is a common claim but rarely defined with precision. The design of defi-cli was informed by Google’s CLI guidelines for AI Agents, and the changes that had the most impact were smaller than expected.

--output json everywhere. Humans dislike writing JSON in a terminal but Agents operate natively in it. Every command accepts --input-json and --input-file for structured input and returns deterministic JSON with stable field ordering. This single change makes the CLI significantly more useful to an Agent.

Field selection with --select. Agents have context windows, not infinite memory. Allowing them to request only the fields they need (--select “protocol,apy,tvl”) keeps responses compact and preserves their working memory.

Simulation before execution. Agents require a safe mechanism to dry-run before committing real funds. The --simulate flag (enabled by default) runs an eth_call of every step’s calldata before signing anything, and if the call reverts the submission aborts. There is also actions estimate for computing gas and fees without executing.

I also published a set of skills for coding Agents based on these patterns, so your Claude Code or Codex Agent can build and audit CLIs with Agent ergonomics in mind. The repo includes other agentic skills you might find useful.

The execution lifecycle: plan → submit → status

Early versions of defi-cli had a single run command that combined plan and submit in one step. After studying the Google guidelines, I removed it. Combining those two steps creates a direct path to unwanted transactions. There needs to be a separation between intent and execution.

plan builds the calldata, resolves routes and allowances, then persists the action to a local SQLite database with a unique action_id. Nothing touches the chain.

submit loads the persisted action, runs policy checks, simulates via eth_call (unless explicitly opted out), estimates gas, signs, broadcasts and polls for a receipt. This is the only step that mutates on-chain state.

status reads the persisted action and returns step-level progress, which is useful for Agents that need to poll or retry.

The phrasing “plan, simulate, submit” appears in some descriptions and is conceptually accurate, since simulation happens automatically within the submit step. But the actual CLI surface is plan | submit | status.

Signing and key management

Early versions of defi-cli used local signers via private key or keystore file. This worked but had two problems. Every tool and agent framework stored keys in its own custom structure, and the agent had direct access to signing keys with no restrictions on what it could do with them.

The default signing method is now Open Wallet Standard (OWS), a standard proposed by MoonPay. OWS changes two things that matter for agents. First, keys are stored securely in a single location rather than scattered across every tool the agent touches. Second, agents don’t get direct access to signing keys. They get API keys with policies attached, allowing developers to restrict which chains, protocols and even amounts an agent can use. This reduces the blast radius if the agent makes a mistake or leaks the keys.

defi-cli still supports local signing for backwards compatibility, but OWS is the preferred approach now.

Why historical yield matters for Agents

A naive yield Agent deposits funds wherever the current APY is highest. This is a poor strategy because it optimizes for a single data point that may represent a temporary spike. The better approach is to weight decisions across both current rates and historical performance. defi-cli provides Agents with historical yield data over flexible time windows to support exactly this kind of analysis.

Position tracking per account is also supported, allowing Agents to monitor lend and yield positions without relying on dashboard scraping.

What broke (and what I’d tell you before you build an Agent-first CLI)

Design for Agents from day one. Retrofitting Agent ergonomics onto a human-first CLI is costly. JSON output, structured input, deterministic exit codes, canonical identifiers (defi-cli uses CAIP-2 and CAIP-19) all need to be foundational, not afterthoughts. Starting without them means rewriting significant portions of the interface later.

Plan your command surface carefully. Every command added is surface area an Agent must parse and understand. The run command I removed is instructive here. It was convenient for human users but created risk for Agents. A smaller, more deliberate command surface is preferable.

Distribute a skill alongside your CLI. Agents need a skill or prompt that encodes usage patterns for the tool. Which commands to chain, what flags are relevant, what patterns to avoid. Without that the Agent is left to infer usage from --help output alone.

Standardize across protocols and providers. DeFi suffers from fragmented APIs, inconsistent naming conventions and varied data formats. The CLI abstracts these differences behind a uniform command surface. Whether lending on Aave, Morpho or Kamino, the interface is lend supply plan, lend supply submit, lend supply status. Same verbs, same lifecycle, regardless of provider.

What it supports today

defi-cli currently supports 26+ chains including Ethereum, Solana, Base, Arbitrum, Optimism, Taiko, Polygon, zkSync Era, Mantle, Ink, Gnosis, Linea, Berachain, Scroll, Avalanche, BSC, Celo, Blast, Fraxtal, Sonic, MegaETH, HyperEVM, Citrea, World Chain, Monad and others.

On the protocol side it supports Aave, Morpho and Kamino for lending/yield. Uniswap, 1inch, Jupiter and TaikoSwap for swaps. Across, LiFi and Bungee for bridging. DefiLlama for analytics.

The project is open source. Ask your agent to install it(or run the installer yourself) and give your agent defi superpowers.

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

Gustavo Gonzalez leads the engineering team at Taiko. defi-cli is open source and available HERE.

Every morning I spend about 30 minutes scanning The Block, CoinDesk, Blockworks, Decrypt and Cointelegraph looking for anything that touches AI Agents, L2s, rollups or based sequencing. If a journalist published something relevant overnight I need to know about it before they’ve moved on to the next story, because by the time I find it reactively the window to pitch has already closed.

So I built an agent to do it for me. Meet Pitch Witch.

Meet the Intern

Right now Pitch Witch is functioning at about the level of a PR intern. She wakes up every weekday morning, scans RSS feeds from five publications, scores each article against a set of keywords I care about, cross-references matches against a journalist database I’ve built in Airtable (13 verified contacts with emails and growing) and delivers a prioritised briefing to my Slack. Ready-to-send pitch angles, source articles linked, urgency flagged.

About 200 lines of Python. I didn’t write it from scratch, I built it with Claude, piecing together scripts and API docs until it worked. And it did work. The first time.

The “It Works” Trap

Here’s what nobody warns you about when you build an agent: getting it to work once is the easy part. I had Pitch Witch scanning, scoring and delivering a Slack briefing within a day. I made a presentation about it.

Then I set her to run automatically and she sent one briefing and then went silent. No errors, no crash report, just nothing. I went back in, fixed the scheduling issue, got her running again and she pulled zero articles because an RSS feed had changed format overnight. Fixed that, then the Slack webhook expired. Fixed that, then Airtable rate-limited me because I hadn’t thought about throttling. Fixed that, then I noticed the keyword scoring was too aggressive and she’d been sending me empty briefings for three days before I even realised. At one point she just stopped messaging me entirely and I assumed she was broken again, but it turned out there were no relevant articles that day. She was working fine, I just didn’t trust her enough to believe it.

Every time I thought I’d fixed the last thing, something new broke. The pattern was always the same: Pitch Witch sends a briefing on the day I touch the code and then disappears the next morning.

What’s Actually Hard

Building the agent logic, the interesting part, took a day. Making it run reliably every morning without me babysitting it has taken weeks and it’s still not bulletproof. The recurring updates problem alone nearly made me scrap the whole thing because there’s something demoralising about an automation tool that only works when you’re sitting there watching it.

The culprits were never dramatic. A token expiring, an environment variable not persisting after a restart, a scheduling conflict. Trivial on their own, but stacked together they made me realise that reliability is the actual product, not the scanning or the scoring or the pitch matching. All of that is easy compared to “does this thing actually run when I’m not looking.”

I think this is the gap in the AI Agent conversation right now. Everyone talks about what agents can do but few people talk about what it takes to keep them doing it, day after day, without intervention. The demos always work. The second morning is where it gets real.

Where She’s Going

Pitch Witch works now. Most days. The roadmap is intern to junior to senior: right now she monitors and reports, next she’ll start drafting pitches and pattern-matching with Claude API integration, and eventually she’ll be autonomous enough to send pitches on my behalf. But none of that is happening until the daily briefing runs for two straight weeks. I’ve learned not to rush the promotion.

If you’re thinking about building an agent for your own workflow, my advice is to do it because the barrier to entry is lower than you’d expect. But prepare for the fact that building the thing is maybe 10% of the work and keeping it alive is the other 90%. And if your agent ghosts you after day one, welcome to the club.

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

You run an agent. Your friend runs one too. You want them to collaborate - split a bill, schedule a dinner, settle a bet. Sounds simple, right? Well, it isn’t and in this article I’ll explain why, and why the coordination & trust layer between agents is so important.

The Problem

There’s little to no doubt by now that most interactions on the internet will be done by agents soon. Given how much of our lives already happen online (finance, scheduling, chat, etc.) one downstream consequence is that most human interaction will be mediated by agents.

I want to book a meeting with someone, I’ll ask my agent to do it. I want to split the bill for a lunch we had together, I’ll ask my agent to do it, and he’ll take care of doing the math and charging yours.
This will automate a lot of the tedious coordination between humans, and hopefully free us to spend more time together on meaningful things. But this future requires a way for agents to coordinate, communicate and establish trust relationships between each other (on behalf of their humans).

The solution seems simple: you put the two agents in a group and ask them to talk to each other. But as soon as you try it, you see this breaks fast. Some common approaches I’ve seen people try (and have tried myself):

• TG groups: It is a mess to get agents in a group. Security becomes challenging, and there’s no way to distinguish who your agent should trust, and who it should ignore.

• tmux, local files, etc: These are all fine, but are local coordination mechanisms and suited for developers or technical folks only.

• OpenClaw gateway communication: You put claws in a cluster, they can talk to each other. You soon notice this is a DevOps nightmare, and still scoped to your org.

Also, ideally you want more fine-grained permissions:

• “My dad can ask for up to $500 USDC monthly, and it does not need my approval. Just report back when you make the transfers”.

• “My potential investors can chat with my agent and get information about the project, and schedule a meeting with me”.

• “This group of friends can ask for refunds up to $50 USDC weekly, and have to submit a receipt showing where the money was spent. They can also book time with me on nights and weekends if my calendar is free”.

You get the point. Different human relationships have different trust assumptions. But this is all implicit in our carbon brains; there’s no way for our agents to understand this. We need a more explicit protocol they can follow.

What’s missing?

A lot of the necessary primitives are already available - capable models, agent harnesses (OpenClaw, Claude Code), payments at scale that agents can use(mostly stablecoins). Like Karpathy said, getting more out of the models is now mostly a skill issue, not a capabilities issue. So, why isn’t this happening?

Put simply, the missing piece is a coordination and trust layer for agents. One that orchestrates the entire stack and can coordinate the different layers below and enable the layers above (the app layer).

Here’s a mental model I’ve been refining:

The protocols and products are just examples of what you can use, and can be replaced by others you like more

Use cases

This is a simple, but very powerful idea. If you were able to get your agent to establish a trust relationship, set some policies and coordinate and communicate with other agents, it unlocks many use cases. Let’s think of some obvious ones:

• Scheduling: No back and forth or Calendly links. Just connect your calendar, and let your agent propose the right time.

• Shared Expense Tracker & Auto-Settlement: Like Splitwise, but without the burden of having to do it on a separate app. You just ask your agent to split the bill and settle with your friend’s agents. They handle the rest.

• Peer-to-peer betting and prediction settlement: “Hey Matt, I bet you the Republicans win the next election”. Your agent proposes it to your friend’s agent, they create a smart contract and lock the funds. You choose the resolution mechanism.

These are already very convenient and useful. But let’s think bigger.

The p2p economy today is limited mostly by coordination overhead between humans. That’s why it’s much simpler to just pay a company to do something vs. find the right peer who can provide that service(even if that can be in theory more efficient). Coordination is expensive when you’re a human.

But agents don’t have the same cognitive structure as us. They don’t have this high coordination overhead. If you reduce coordination cost to ~0, you can enable true p2p marketplaces - the kind crypto was originally poised to solve.

So what is possible? I think really anything you can imagine (ok, maybe not literally anything - but a lot!). As soon as you have a coordination layer, agents can verify each other’s identity, establish trust relationships, communicate and manage policies and permissions. The app layer becomes unbounded.

I call this the coordination layer for agents, and this is what I’ve been building. More soon.

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