Coinbase AgentKit: Giving AI Agents a Wallet Without Locking Them to One Framework

The gap AgentKit fills: an agent that can only talk cannot pay

Most agent frameworks give a model tools that read and write text. AgentKit starts from the observation that an agent which can only talk cannot settle anything, and it supplies the missing half: a wallet and a set of onchain actions the model can call. The README frames this as framework-agnostic and wallet-agnostic, which is a claim about interfaces, not about features. The project is maintained by Coinbase Developer Platform, and the quickstart requires a CDP Secret API Key and an OpenAI API key, so the default path runs through Coinbase's own infrastructure even though the interfaces are meant to be swappable. The audience is narrow on purpose: developers building agents that hold funds, pay for things, or interact with contracts, and who already accept that the agent needs signing authority. If your agent never touches a chain, nothing here applies to you.

Three layers: wallet providers, action providers, framework extensions

The repository layout is the clearest statement of the architecture. Under typescript/agentkit/src there are two sibling directories: action-providers, described in the tree as holding 50+ actions, and wallet-providers, containing cdp, privy and viem. The Python tree mirrors this with action_providers (30+ actions) and wallet_providers (cdp, privy, viem). A third layer sits outside the core package: framework-extensions, which in TypeScript covers langchain, vercel-ai-sdk and model-context-protocol, and in Python covers autogen, langchain, openai-agents-sdk, pydantic-ai and strands-agents. The data flow implied by that split is: a framework extension adapts AgentKit's action surface into whatever tool-calling shape the framework expects, the action providers define what the agent can do, and the wallet provider holds the keys and signs. Because the wallet provider is a separate package rather than a hardcoded signer, swapping cdp for viem should not require touching action code. That is the design bet, and it is a reasonable one. Note the asymmetry between the two languages: Python lists five framework extensions and TypeScript lists three, so the framework you use may decide which language you write the agent in.

Getting a first agent running in Node.js or Python

Both quickstarts are scaffolders rather than library installs. For Node.js the prerequisites are Node.js 22+, a CDP Secret API Key and an OpenAI API key. The README gives this sequence: npm create onchain-agent@latest, then cd onchain-agent, then fill in the CDP API key id and secret plus the OpenAI key in .env.local, then mv .env.local .env, then npm install, then npm run dev, and finally open http://localhost:3000. For Python the prerequisites are Python 3.10+, Poetry, and the same two API keys. The sequence is pipx run create-onchain-agent, cd onchain-agent, fill in .env.local, mv .env.local .env, poetry install, then poetry run python chatbot.py, and at the prompt select "1. chat mode". The README's own example interaction is a prompt of "Fund my wallet with some testnet ETH", and the sample output shows a wallet UUID, a network of base-sepolia, a default address, and a transaction link on sepolia.basescan.org. Two details are worth flagging. First, the rename step from .env.local to .env is manual and easy to skip, and the scaffold will not work until you do it. Second, the sample output is from the README's example session, not a benchmark; the interesting part is that a faucet action is exposed to the model as a callable tool at all.

The action provider generator is the part that decides whether this scales for you

The TypeScript tree includes typescript/agentkit/scripts/generate-action-provider/, annotated in the README's directory listing with the comment "use this to create new actions". That is the extension point for anything the built-in 50+ TypeScript actions or 30+ Python actions do not cover. The practical question for a team is whether adding a proprietary action means writing a provider that conforms to an existing interface, or forking the core package. The repository structure suggests the former, since action-providers is a directory of independent modules rather than one monolith. What the supplied material does not show is the generated provider's shape: the README does not print the scaffold output, the interface an action must implement, or how an action declares its parameters to the model. You will have to read the generated files to learn that. Treat the generator as a real affordance and an undocumented one at the same time.

Nightly builds and a NOASSERTION licence are the two adoption risks

The release list is the most concrete warning in the material. The recent releases are nightly-20250311, nightly-20250310 and nightly-20250309, all labelled "Nightly Build". There is no tagged stable release in the supplied data. A project that ships nightlies may still have stable tags elsewhere, but nothing here confirms one, so the honest position is that you should pin a specific commit or nightly identifier and expect to re-verify on upgrade rather than assume semantic versioning. The licence field reads NOASSERTION, which means the repository's licence could not be classified automatically. The README has a License section and a separate Legal and Privacy section, so the terms exist; they are just not summarized in the material available. Read the LICENSE file and the legal section yourself before shipping anything that moves real funds. There is also an operational cost that the README does not quantify: the CDP path depends on Coinbase Developer Platform API keys, and the default examples depend on an OpenAI key, so you are maintaining credentials for at least two third parties. The README does point to a Security and Bug Reports section, which is the right channel if you find something in the signing path.

Where AgentKit is the wrong tool

AgentKit is not a wallet. It is a connector layer that assumes a wallet provider already exists for your custody model, and in both language trees the shipped options are cdp, privy and viem. If you custody keys with an internal HSM, a hardware signer, or a provider outside that list, you are writing a wallet provider before you write a single action, and the README does not walk through that interface. Second, the framing is onchain and stablecoin payments on Base and similar networks; if your agent needs to move money through card rails, bank transfers or an internal ledger, the action providers are the wrong vocabulary. Third, the examples lean on testnets (base-sepolia appears in the sample output), which is friendly for evaluation and tells you nothing about mainnet failure modes: nonce management under concurrency, gas spikes, reverted transactions the model then retries. Fourth, if your agent's authority should be bounded, note that the design gives the agent a wallet and a set of callable actions, and the README's own risk section is titled "Managing Risk" without the supplied text spelling out the controls. Budget time to read it before granting a model signing authority.

How AgentKit differs from wiring tools into a framework directly

The obvious alternative is to skip AgentKit and register chain actions as tools inside your framework of choice, using something like viem or an equivalent client directly. That approach is not wrong, and for a single agent on a single chain it is less machinery. The difference is where the abstraction lives. Wiring directly means your tool definitions, your signer and your framework's tool schema are one body of code, and moving from one framework to another means rewriting the tool layer. AgentKit inserts two seams: the wallet provider, so the signer is a package rather than a call site, and the framework extension, so the same action set is exposed to LangChain, the Vercel AI SDK, the Model Context Protocol, AutoGen, the OpenAI Agents SDK, Pydantic AI or Strands Agents depending on which tree you are in. You pay for those seams with a dependency on Coinbase's toolkit and its release cadence. If you are prototyping one agent against one chain, the direct route is faster. If you expect the wallet or the framework to change, the seams are the reason to take the dependency.

What to check before you commit

Read the generated action provider from scripts/generate-action-provider/ and confirm you can express your own action without patching the core package. Confirm which wallet provider matches your custody model and whether the interface in wallet-providers/cdp, wallet-providers/privy or wallet-providers/viem is documented well enough to implement a fourth. Check the LICENSE file and the Legal and Privacy section, since the licence is recorded as NOASSERTION. Pin a commit rather than tracking main, given that the only releases listed are nightlies. Then run the scaffold end to end on a testnet and watch what the agent actually does when a transaction reverts, because that behaviour is not described in the material available and it is the behaviour that will matter in production.

Editorial conclusion

Adopt AgentKit if you are building an agent that needs to sign and send onchain transactions and you want the wallet layer and the framework layer to remain independently replaceable. Do not adopt it if you need a stable tagged release: the only recent releases listed are nightly-20250309, nightly-20250310 and nightly-20250311, so pin a commit and read the licence text before you build a product on it. Verify first that a wallet provider exists for your custody model (cdp, privy or viem in the TypeScript tree), that the action providers you need are among the 50+ TypeScript or 30+ Python actions, and that your framework has an extension under framework-extensions rather than an example you would have to adapt yourself.

Official sources

1. coinbase/agentkit on GitHub
2. Issues
3. README
4. Releases