Coinbase AgentKit vs Alchemy for Building Onchain AI Agents: What Each Does and When to Use Both

AgentKit and Alchemy are not really competitors. They solve different halves of the same problem.

Coinbase AgentKit is an agent toolkit. It gives a language-model agent a wallet and a library of onchain actions (transfer, swap, deploy, interact with protocols) and plugs those actions into agent frameworks as tools. It answers: how does my agent act onchain?

Alchemy is blockchain infrastructure. It gives you node access (RPC), indexed data APIs (balances, transfers, token prices, NFTs), webhooks, smart-wallet tooling and, more recently, an MCP server that exposes those APIs to AI clients. It answers: how does my agent read the chain reliably, and how do transactions get to it?

Most production onchain agents end up using something from both categories. The real decision is which one is the backbone of your stack, and what you add on top that neither provides.

AgentKit is open source, published by the Coinbase Developer Platform (CDP), with TypeScript and Python packages. Its architecture has three parts.

Wallet providers. The agent needs keys to sign. The default is a CDP server wallet, so private keys are held by Coinbase's infrastructure rather than in your agent's environment. Other providers, such as Viem or Privy, and custom ones are supported.

Action providers. Actions are the unit of capability: send a token, swap, check a balance, call a contract, use a specific protocol. There are dozens of providers, some of which need their own API keys.

Framework extensions. AgentKit turns its actions into tools for agent frameworks, with official extensions such as LangChain and the OpenAI Agents SDK, so the model can call 'swap 0.1 ETH for USDC' as a function.

It is Base-first, since it comes from Coinbase, but covers other EVM chains and Solana. The pitch is speed: from zero to an agent that holds funds and transacts in an afternoon.

Alchemy is the layer underneath. Its core products for agent builders are:

Node and RPC access across many chains, with the reliability and rate limits a long-running agent needs. A public RPC endpoint is fine for a demo and a liability for a bot that runs every minute.

Data APIs that save you from indexing the chain yourself: token balances, transfer history, token metadata and prices, NFT data. An agent that reasons about a wallet needs this, and raw RPC calls are a slow way to get it.

Webhooks, so the agent can react to onchain events (a deposit arrives, a position changes) instead of polling.

Smart-wallet tooling (Account Kit), with gas sponsorship, which matters if your agent acts on behalf of users who should not need ETH for gas.

Agent-specific access. Alchemy runs an MCP server so MCP clients such as Claude Code or Cursor can call its blockchain APIs as tools, and it has added agent wallets and pay-as-you-go access for agents.

Alchemy is therefore broader and lower in the stack. It is what you would build on even if you were not building an agent.

Primary job. AgentKit: let an agent take onchain actions. Alchemy: give any application, agent or not, reliable chain access and data.

Layer. AgentKit: agent tooling, sits next to your LLM framework. Alchemy: infrastructure, sits under everything.

Wallets. AgentKit: wallet providers are central, with a managed CDP wallet by default. Alchemy: smart-wallet SDKs and agent wallets, but wallets are one product among many.

Data. AgentKit: reads what its actions need, often through other providers. Alchemy: indexed data is a core product.

LLM integration. AgentKit: native, actions are tools in agent frameworks. Alchemy: through its MCP server and APIs you wrap yourself.

Best fit. AgentKit: you want an agent that transacts, quickly, especially on Base. Alchemy: you need production-grade reads, multi-chain coverage, events and gas abstraction.

Choose AgentKit as the backbone if the agent's job is to act: rebalance a wallet, execute swaps, pay for things, manage a treasury. You get wallet custody and a tested action library without writing signing code, which is where most security mistakes happen.

Choose Alchemy as the backbone if the agent's job is mostly to observe and reason: monitor wallets, track flows, answer questions about onchain state, or if you already run a dapp on Alchemy and are adding an agent to it.

Use both, which is the common case, when the agent needs to read a lot and act sometimes. A typical split: Alchemy supplies RPC, balances, history and event webhooks, and AgentKit supplies the wallet and the action tools the model calls. AgentKit can run on top of whatever RPC provider you configure, so the two coexist naturally.

Here is the part neither comparison table usually mentions. AgentKit makes it easy for an agent to do something. Alchemy makes it easy for it to know what is onchain. Neither tells the agent how much it is allowed to do right now.

That is not a criticism; it is outside their scope. But it is where agents lose money. A model that can call swap will call swap. If the market is in a liquidation cascade, volatility has doubled, or leverage is crowded, nothing in the wallet or the data layer stops a full-size position. Prompting 'be careful' is not a control.

The missing piece is a risk layer between the decision and the action: a deterministic check that takes current market state and returns limits, such as maximum position size, whether leverage is allowed, and which actions are blocked, which the agent must respect before it calls the action tool. It should be outside the model, so the model cannot argue its way past it, and auditable, so you can prove after the fact which limits applied.

A minimal governed onchain agent looks like this.

1. Read. Alchemy supplies balances, positions and recent transfers for the agent's wallet.

2. Decide. The LLM proposes an action, for example 'move 40% of the wallet into ETH'.

3. Check. Before executing, the agent calls a risk engine with the asset and gets back the current limits. With RiskState that is one call to POST https://api.riskstate.ai/v1/risk-state, which returns max_size_fraction, allowed_actions, blocked_actions and a policy_hash for the audit log.

4. Clip or block. If the proposal exceeds max_size_fraction, it is resized. If the action is in blocked_actions, it does not happen.

5. Act. Only then does the agent call the AgentKit action, signed by its wallet provider.

We publish this exact setup, with TypeScript code, at riskstate.ai/setup/agentkit-alchemy-riskstate.

If you are asking 'AgentKit or Alchemy?', the honest answer is usually 'AgentKit for actions and wallets, Alchemy for data and infrastructure, often both'. Pick by what your agent mostly does: act or observe.

Then add the piece neither provides: a risk limit the agent cannot override. Onchain agents fail less often from bad code than from doing the right action at the wrong size at the wrong time.