Why AgentKit Is Still Viable in 2026 — and What’s Missing

Coinbase AgentKit is still installable and still functional in 2026, but it is unannounced-but-stalled rather than formally deprecated: the npm package @coinbase/agentkit last shipped a stable release 0.10.4 on 2025-12-19, per the npm registry, while the repository remains archived: false and was last pushed 2026-09-03, per the GitHub API.

That gap between “still pushed” and “still released” is the whole story. There is no npm deprecated field, no GitHub archive flag, and no sunset notice — so you are not building on a corpse. But the release cadence collapsed: PyPI coinbase-agentkit last published 0.7.4 on 2025-10-03, per the PyPI JSON endpoint, and the nightly dist-tag stopped after 2026-02-01. Meanwhile @coinbase/cdp-sdk, the key-management layer underneath, shipped 1.56.0 on 2026-09-14, per the CDP SDK npm registry. The foundation is moving; the agent framework on top of it is not.

The sharpest signal is documentation. The live docs.cdp.coinbase.com llms.txt contains zero matches for “agentkit,” and /agentkit/docs/welcome — the link printed in AgentKit’s own README — returns HTTP 404. Coinbase’s docs site has reorganised around Coinbase for Agents, Agentic Wallet, and the sdks/cdp-sdks-v2 namespace.

What AgentKit still buys you is real: 18 Python action providers and 40 TypeScript action providers, a clean wallet-provider abstraction, and framework adapters for LangGraph, OpenAI Agents SDK, Pydantic AI, and more. What it does not buy you is safety. Its repository README states plainly that AgentKit “does not gate transfers behind human approval, enforce spend caps, or allowlist destinations.”

If you want the broader landscape before committing, our AI engineering coverage tracks how these agent toolchains are converging. If you want the pay-per-call protocol underneath, we covered x402’s challenge-payment flow in detail.

Scaffold the CDP Server Wallet with CdpEvmWalletProvider

CdpEvmWalletProvider is the Python wallet provider you configure for a headless agent, and it requires four values — api_key_id, api_key_secret, wallet_secret, and network_id — as documented in the AgentKit Python README. The wallet_secret is the field most tutorials omit, and omitting it is the fastest way to a broken build.

Here is the exact constructor shape from the shipped code:

from coinbase_agentkit import CdpEvmWalletProvider, CdpEvmWalletProviderConfig

wallet_provider = CdpEvmWalletProvider(CdpEvmWalletProviderConfig(
    api_key_id="CDP API KEY ID",
    api_key_secret="CDP API KEY SECRET",
    wallet_secret="CDP WALLET SECRET",
    network_id="base-mainnet",
))

Two things to internalise before you copy that. First, network_id accepts base-mainnet or base-sepolia; start on Sepolia and treat mainnet as a deliberate promotion. Second, the README quickstarts still show the legacy CdpWalletProvider / CdpWalletProviderConfig / configureWithWallet names, while the shipped code exposes cdp_evm_wallet_provider.py. This is documentation drift, not a deprecation — use CdpEvmWalletProvider with the required wallet_secret.

You need a CDP Portal account to mint the API key ID, API key secret, and Wallet Secret; the auth flow is described in the API key auth quickstart. Treat the Wallet Secret like a signing key, not a config string — it belongs in a secret manager, never in a committed .env.

For the threat model around a wallet-bearing agent, our breakdown of agentic wallet security patterns is the companion read to this section.

Wire a LangGraph ReAct Agent to AgentKit Tools

get_langchain_tools() from the coinbase-agentkit-langchain extension converts an AgentKit instance into LangChain-compatible tools that drop straight into LangGraph’s create_react_agent, per the AgentKit Python README. The extension package is coinbase-agentkit-langchain 0.7.0, uploaded 2025-09-06, per the PyPI JSON endpoint, and the no-argument AgentKit() default pairs a CDP wallet provider with the transfer-capable WalletActionProvider.

from coinbase_agentkit import AgentKit, AgentKitConfig
agent_kit = AgentKit()  # defaults: CDP wallet provider + WalletActionProvider

from coinbase_agentkit_langchain import get_langchain_tools
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI

tools = get_langchain_tools(agent_kit)
agent = create_react_agent(llm=ChatOpenAI(model="gpt-4"), tools=tools)

Notice what AgentKit() with no arguments does: it defaults to a CDP wallet provider plus the WalletActionProvider. That default is convenient and dangerous in equal measure, because the default action set includes transfer-capable actions. In production, construct AgentKitConfig explicitly and enumerate the providers you actually want rather than accepting the default surface.

The create_react_agent loop is where your guardrails will eventually live. A ReAct agent decides which tool to call, calls it, observes the result, and repeats — which means a single prompt-injection in a tool observation can redirect the next action. The wrapper in the human-in-the-loop section below is designed to sit exactly at that seam.

Understand What AgentKit Exposes — and What It Doesn’t

AgentKit ships 18 Python action-provider directories and 40 TypeScript action-provider directories, and its README explicitly states it “does not gate transfers behind human approval, enforce spend caps, or allowlist destinations,” per the AgentKit repository README. Every one of those is an action an LLM can be talked into invoking, and none of them ships with a ceiling.

The Python set, per the action providers directory listing, spans aave, basename, cdp, compound, erc20, erc721, hyperboliclabs, morpho, nillion, onramp, pyth, ssh, superfluid, twitter, wallet, weth, wow, and x402. The TypeScript set is more than double that, per the TypeScript action providers listing, adding DeFi, NFT-marketplace, and data-provider integrations.

Read that inventory as a capability list, not a safety list. erc20 can move tokens. wallet can sign. x402 can spend. ssh is a shell surface. Treat that inventory as attack surface first and capability second.

The practical consequence: your guardrail budget is proportional to the number of action providers you enable, not the number you install. Enable four providers and you have four attack surfaces. Enable all eighteen and you have eighteen.

Add x402 SpendControls as Your First Guardrail Layer

The CDP SDK x402 module’s SpendControls type is the only programmatic spend-limit primitive in this stack, providing maxAmountPerPayment, maxCumulativeSpend, maxCumulativeSpendWindow, allowedNetworks, allowedAssets, allowedPayees, and approaching-limit callbacks, per the SpendControls type alias docs. It applies once per client, and it constrains x402 payment flows specifically rather than general ERC-20 transfers.

const USDC_BASE = "0x833589fcd6edb6e08f4c7c32d4f71b54bda02913";

const controls: SpendControls = {
  maxAmountPerPayment: { atomic: 10_000n, asset: USDC_BASE },
  maxCumulativeSpend: { atomic: 50_000n, asset: USDC_BASE },
  maxCumulativeSpendWindow: "24h",
  allowedNetworks: ["eip155:8453"],
};

The amounts are atomic units against a named asset, and 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 is USDC on Base. maxAmountPerPayment caps a single call; maxCumulativeSpend caps the rolling maxCumulativeSpendWindow, here 24 hours. allowedNetworks pins you to Base mainnet via the CAIP-2 identifier eip155:8453.

Apply it once per client:

import { CdpClient } from "@coinbase/cdp-sdk";
const cdp = new CdpClient(); // CDP_API_KEY_ID / CDP_API_KEY_SECRET / CDP_WALLET_SECRET

applySpendControls(cdp, controls);

The single-application rule is enforced, not advisory. A second call throws SpendControlError with code "already_applied", per the applySpendControls docs. That means you configure controls at client construction time, not per-request — plan your bootstrap accordingly.

Two honest caveats. This is a TypeScript/x402 feature, not an AgentKit export, so a Python AgentKit agent does not get it for free; you either add a TS payment service or enforce limits in your own Python wrapper. And it constrains x402 payment flows specifically — it is not a general ERC-20 transfer firewall.

Implement a Human-in-the-Loop Approval Wrapper

AgentKit ships no approval mechanism, so human-in-the-loop gating must be implemented by the developer as a wrapper around the agent’s tool-calling loop, consistent with the AgentKit README’s guardrails disclaimer. This is a pattern you write, not a feature you enable.

TRANSFER_ACTIONS = {"transfer", "send", "swap", "trade"}

def gate_tool_call(tool_name: str, tool_args: dict, approve) -> dict:
    """Wrap a tool call. `approve` is your human confirmation callback."""
    if tool_name in TRANSFER_ACTIONS:
        if not approve(tool_name, tool_args):
            return {"status": "denied", "reason": "human_approval_required"}
    return {"status": "approved", "tool": tool_name, "args": tool_args}

The design decision that matters is where approve lives. A terminal prompt is fine for development and useless in production. A durable approval queue — write the pending action to a store, notify a human out-of-band, block until a signed decision arrives — is the production shape, and it is also what makes the audit trail real.

Belt-and-braces: run the allowlist check before the approval prompt, so a human is never asked to approve a payee that should have been rejected outright. Approval fatigue is a real failure mode, and the fastest way to get it is to prompt for obviously-invalid actions.

For a fuller catalogue of gating patterns, see our agentic wallet security guardrails write-up.

Explore the Action Provider Model for Custom Guardrails

AgentKit authors actions with the @create_action decorator on an ActionProvider subclass, taking a Pydantic BaseModel schema and returning a string, per the AgentKit Python README and the action providers directory listing. An agent that proposes an amount over the schema cap gets a validation error rather than a transaction.

from pydantic import BaseModel, Field
from coinbase_agentkit import ActionProvider, create_action

class GuardedTransferSchema(BaseModel):
    to: str = Field(..., description="Destination address")
    amount_usdc: float = Field(..., gt=0, le=25.0)

class GuardedTransferProvider(ActionProvider):
    def __init__(self):
        super().__init__("guarded-transfer", [])

    @create_action(
        name="guarded_transfer",
        description="Send USDC to an allowlisted address, capped at 25 USDC.",
        schema=GuardedTransferSchema,
    )
    def guarded_transfer(self, wallet_provider, args: dict) -> str:
        dest = args["to"].lower()
        if dest not in ALLOWLIST:
            return "Rejected: destination not allowlisted."
        return f"Queued transfer of {args['amount_usdc']} USDC to {dest}."

def guarded_transfer_provider():
    return GuardedTransferProvider()

The leverage here is that validation lives inside the action schema, so the LLM sees the constraint as part of the tool contract. gt=0, le=25.0 is enforced by Pydantic before your handler runs, and the allowlist check is inside the handler. The schema is the contract: an over-cap proposal never reaches your handler.

This is the pattern to reach for when you want safety to be structural rather than bolted on. Write guarded wrappers for the three or four actions you actually need, register those, and leave the raw erc20 and wallet providers unregistered.

AgentKit vs Agentic Wallet CLI vs Agentic Wallet MCP vs CDP SDK: Decision Table

Agentic Wallets launched 2026-02-11 as Coinbase’s agent-specific wallet product, offering a CLI and an MCP server with built-in session caps, transaction limits, OFAC sanctions screening, and KYT, per the Agentic Wallet welcome page and the Coinbase launch post. Unlike AgentKit, neither surface needs API keys — both authenticate with email/OTP instead.

Feature AgentKit (code-first) Agentic Wallet CLI Agentic Wallet MCP CDP SDK Server Wallet (raw)
Code-first? Yes — Python/TS SDK No — CLI (npx awal) No — MCP server Yes — SDK client
Guardrails shipped? None (README confirms) Session caps, transaction limits, KYT, OFAC Limits set in wallet UI None (raw SDK)
Networks Any EVM + Solana (provider-dependent) Base, Base Sepolia, Polygon, Solana, Solana Devnet Base, Polygon, Solana Any EVM + Solana
API keys needed Yes — key ID, secret, wallet secret No — email/OTP No — email/OTP Yes — key ID, secret, wallet secret
Cost Free (Apache-2.0) Free (sponsored gas; Onramp fees) Free (sponsored gas; Onramp fees) Free (MIT)
Status 2026 Stalled — last stable npm 2025-12-19, docs 404 Active — launched 2026-02-11 Active — Beta, launched 2026-02-11 Active — npm 1.56.0 (2026-09-14)

Read the “Guardrails shipped?” row as the decision axis. If you need custom on-chain logic, AgentKit or the raw CDP SDK is the right substrate, and you own the safety layer. If you need an agent that spends money safely with minimal code, the Agentic Wallet surfaces already ship the controls you would otherwise write.

The CLI surface is worth seeing concretely: npx awal status, npx awal send 1 vitalik.eth, npx awal trade 5 usdc eth, with skills added via npx skills add coinbase/agentic-wallet-skills, per the CLI welcome docs. The MCP server is npx @coinbase/payments-mcp — version 1.0.5, last published 2025-10-22, per the payments-mcp registry — documented as Beta at the MCP welcome page.

For how this compares to exchange-native alternatives, see our exchange-native AI agent platforms breakdown.

x402 Payments: How Agents Pay for API Calls Natively

AgentKit includes Python and TypeScript x402 action providers with a hard dependency on x402<2,>=0.1.4, and the CDP facilitator has processed more than 100 million transactions and $28 million in payment volume across Base and Solana, per the x402 facilitator docs.

The mechanics are a retry loop. The agent hits an endpoint, receives HTTP 402 with payment terms, parses the terms, pays stablecoin, and retries with proof of payment. AgentKit’s x402 action provider automates that sequence so the agent never has to hand-roll the challenge handling. The facilitator handles the settlement side, supporting the exact, upto, and batch-settlement schemes across CAIP-2 networks including Base eip155:8453, Base Sepolia eip155:84532, Polygon eip155:137, and Arbitrum eip155:42161, with OFAC and KYT screening.

The architectural point is that AgentKit is the client and the facilitator is the infrastructure. That split matters for your guardrails: SpendControls lives on the client side in the CDP SDK, so it constrains what your agent attempts, while the facilitator’s screening constrains what settles.

We went deeper on the volume trajectory in our x402 payment-volume analysis. If you want to argue about whether x402 is the right rail, the NiteAgent Arena is where those threads live.

Framework Extensions: What’s Actually in the Repo

The AgentKit repository contains Python framework extensions for Autogen, LangChain, OpenAI Agents SDK, Pydantic AI, and Strands Agents, plus TypeScript extensions for LangChain, Model Context Protocol, and Vercel AI SDK, per the Python framework-extensions directory. Extension versions are worth pinning: the Python LangChain extension is 0.7.0 while its TypeScript counterpart is 0.3.0.

There is no Eliza extension in the repository, despite third-party claims to the contrary. If you are evaluating AgentKit because you heard it integrates with Eliza, that integration does not ship here.

Extension versions are worth pinning. PyPI coinbase-agentkit-langchain and coinbase-agentkit-openai-agents-sdk are both 0.7.0, published 2025-09-06. The npm @coinbase/agentkit-langchain is 0.3.0 and @coinbase/agentkit-model-context-protocol is 0.2.0, both published 2025-03-07. Note the language split: the Python extensions are roughly a year fresher than the TypeScript ones, which tracks the overall cadence asymmetry.

The TypeScript extension list is at the TypeScript framework-extensions directory. For more framework integration guides across the agent stack, browse the NiteAgent blog index.

Wallet Provider Options Across Languages

Python ships four wallet providers — CdpEvmWalletProvider, CdpSmartWalletProvider, CdpSolanaWalletProvider, and EthAccountWalletProvider — while TypeScript adds viemWalletProvider, zeroDevWalletProvider, and three Privy providers, per the Python wallet providers directory and the TypeScript wallet providers directory. The choice is a custody decision: the CDP providers keep keys inside Coinbase’s infrastructure, while EthAccountWalletProvider takes a local private key.

The full TypeScript list includes cdpEvmWalletProvider, cdpSmartWalletProvider, cdpSolanaWalletProvider, viemWalletProvider, zeroDevWalletProvider, privyEvmWalletProvider, privySvmWalletProvider, privyEvmDelegatedEmbeddedWalletProvider, and solanaKeypairWalletProvider.

The provider choice is a custody decision disguised as a config option. CdpEvmWalletProvider and CdpSmartWalletProvider keep keys inside Coinbase’s infrastructure. EthAccountWalletProvider takes a local private key and works on any EVM chain — maximum flexibility, maximum blast radius if the host is compromised. The Privy providers split the difference with embedded-wallet custody.

Key management itself lives in the CDP SDK, not AgentKit: npm @coinbase/cdp-sdk 1.56.0 (2026-09-14, MIT), per the CDP SDK npm registry, and PyPI cdp-sdk 1.48.1 (2026-08-25, MIT), per the cdp-sdk PyPI JSON. Both ship TypeScript, Python, Go, and Rust clients, described in the CDP SDK README.

One naming trap: the docs label cdp-sdks-v2 and “Wallet API v2” refer to a documentation and API version, not a package major. No 2.x package exists. If you go looking for @coinbase/cdp-sdk@2, you will not find it.

Pricing Reality Check for 2026

AgentKit is free and open source under Apache-2.0 with no documented paid tier, the x402 facilitator charges $0.001 per onchain transaction after 1,000 free monthly transactions, and Agentic Wallet MCP is free with Coinbase-sponsored gas, per the x402 facilitator docs and the Agentic Wallet MCP FAQ.

The facilitator’s pricing model has a detail worth reading twice: fees track onchain activity, not payment requests, and payment verification is always free. An agent that requests a thousand 402 challenges and settles ten of them pays for ten. That makes the cost model friendly to high-volume, low-settlement agents.

The MCP FAQ breaks down as: “MCP: Free / Wallet creation: Free / Gas fees: Free (sponsored) / x402 service calls: Varies by service / Coinbase Onramp: Standard fees apply.” The x402 line is the one to budget against, because service pricing is set by the seller, not Coinbase.

The CDP SDK itself is MIT and free to install. Your real cost centre is the agent’s inference spend and whatever the x402 services charge. For the fee mechanics in more depth, our x402 facilitator pricing breakdown walks through the transaction accounting.

How This Guide Was Researched

Every fact, code snippet, API surface, and version number in this post was verified on 2026-09-18 against official Coinbase documentation, the npm and PyPI package registries, and the public GitHub repository. This is desk research of primary sources, and claims that could not be verified against them are deliberately omitted.

No tool was run hands-on. No agent was wired to a wallet, no wallet was funded, and no transaction was executed. Nothing here is a lab walkthrough or a deployment report, and no claim in this article should be read as implying otherwise. Where the official docs disagree with the shipped code — most visibly the legacy CdpWalletProvider names in the README quickstarts versus the CdpEvmWalletProvider class in the shipped source — we note the discrepancy and cite both.

We also deliberately omit claims we could not verify. No KYC requirement is documented for CDP API keys or mainnet access, and no reproducible CDP rate-limit page exists, so we assert neither. The x402 volume figures come from the facilitator documentation, not from product marketing pages.

The Bottom Line

Build on AgentKit in 2026 only if you need custom on-chain logic and are prepared to own the entire safety layer — because AgentKit ships zero guardrails, its last stable npm release was 0.10.4 on 2025-12-19, and its CDP documentation pages now return 404. For shipped spend caps, OFAC screening, and KYT, use Agentic Wallet CLI or MCP instead.

The honest verdict: AgentKit is unannounced-but-stalled, not deprecated. No npm deprecated field, no archived: true, and the repo was still pushed 2026-09-03. That means it works today and is unlikely to receive new features tomorrow. Treat it as a stable substrate you fork and maintain, not a platform you grow with.

If you do build, the minimum viable safety stack is three layers: SpendControls from the CDP SDK x402 module for programmatic caps, a human-in-the-loop approval wrapper for transfer actions, and custom @create_action providers that encode allowlists directly into the tool schema. Skip any one of those and you have given an LLM an unconstrained wallet.

The decision rule is simple. If you can describe your agent’s spending policy in the Agentic Wallet UI, use Agentic Wallet. If you cannot — because the policy depends on your own business logic — use AgentKit or the raw CDP SDK and write the guardrails. There is no third option where the framework does it for you.

FAQ

Is AgentKit deprecated in 2026? No formal deprecation exists — no npm deprecated field, no archived: true flag, no sunset notice. But the last stable npm release was 0.10.4 on 2025-12-19 per the npm registry, nightlies ended 2026-02-01, and its CDP doc pages return 404. It is unannounced-but-stalled, and the repo was still pushed 2026-09-03.

What guardrails does AgentKit ship out of the box? None. The AgentKit README states it “does not gate transfers behind human approval, enforce spend caps, or allowlist destinations.” Every safety control — spend limits, destination allowlists, human-in-the-loop approval — must be implemented by you, either as wrapper code or via the CDP SDK’s SpendControls type.

Do I need API keys for Agentic Wallet CLI or MCP? No. The MCP FAQ answers “Do I need API keys? No” — both surfaces use an email/OTP embedded wallet. AgentKit and the raw CDP SDK still require a CDP Portal account to mint an API key ID, API key secret, and Wallet Secret, per the API key auth quickstart.

How does x402 differ from AgentKit’s built-in x402 action provider? AgentKit bundles an x402 action provider in Python and TypeScript that automates the 402-challenge payment flow, with a hard dependency on x402<2,>=0.1.4. The CDP facilitator that settles those payments has handled over 100 million transactions and $28 million in volume, per the facilitator docs. AgentKit is the client; the facilitator is the infrastructure.

Can I use AgentKit with frameworks other than LangChain? Yes. The repo contains Python extensions for Autogen, LangChain, OpenAI Agents SDK, Pydantic AI, and Strands Agents, per the framework-extensions directory. TypeScript adds LangChain, Model Context Protocol, and Vercel AI SDK. There is no Eliza extension in the repository despite third-party claims — if you need Eliza, you are writing that adapter yourself.

What does the CDP SDK SpendControls type actually enforce? SpendControls supports maxAmountPerPayment, maxCumulativeSpend, maxCumulativeSpendWindow, allowedNetworks, allowedAssets, allowedPayees, and approaching-limit callbacks, per the SpendControls type alias. It is applied once per client via applySpendControls(); a second call throws SpendControlError with code "already_applied". It is a TypeScript/x402 feature, not an AgentKit export.

Still deciding between the code-first and managed paths? Bring your architecture questions to the NiteAgent Arena and pressure-test the trade-offs before you fund anything.

📖 Related Reads

  • ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
  • Hermes Tutorials — Hermes Agent setup, configuration, and advanced workflows

Cross-links automatically generated from NiteAgent.

← Back to all posts