翻訳待ち：AgentCore Payments middleware for LangChain agents

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Partner Agentic Commerce at Scale: Your LangChain agents can transact securely 10 min Go back to blog Create agents Key Takeaways Agents can now pay for paid APIs directly, which means payment logic lives in middleware instead of in every tool wrapper you write The spending limit is enforced by AgentCore rather than by your prompt, which means it holds even if the agent is compromised Because LangSmith captures what an agent bought alongside the reasoning behind it, you can audit spending after the fact and test it with evals before it goes live ‍ Introduction The agentic economy is imminent. AI agents are moving past free-tier APIs into a world of paid services: premium data, paid content, specialized compute. The agentic commerce ecosystem is growing fast. When an agent can spend money, you need deterministic payment limits: session-level budgets enforced before every transaction at an infrastructure layer, not in LLM prompts. Amazon Bedrock AgentCore Payments solves this for LangChain developers with purpose-built infrastructure for payments. As an agent developer you add the AgentCore Payments middleware layer, choose your wallet, set up a budget, and AgentCore Payments handles the rest. Every payment flows through the protocol-agnostic infrastructure. You also need a record of what the agent bought and why it picked that, which is where LangSmith comes in. This post explains the business case, the architecture, and how to get started. Agents that transact Autonomous agents that can only consume free content are limited in what kinds of jobs they can complete. The highest-value data, including court filings, real-time market feeds, medical literature, and premium APIs, sits behind paywalls. Until recently, accessing this data required manual API key management, per-service billing integrations, or breaking the autonomous workflow to ask a human. This is changing. The x402 protocol, created by Coinbase in May 2025 and now stewarded under the Linux Foundation, makes HTTP-native micropayments possible. Using x402, an agent hits a paid endpoint, receives a price, pays in stablecoins, and gets the content, all within a single HTTP request-response cycle. The economics work differently from traditional payment rails due to the nature of agentic transactions. Card-processing fees make API calls priced in cents economically impossible. Monthly subscriptions assume a human deciding what to buy in advance. Stablecoin micropayments via x402 settle in seconds at fractions of a cent per transaction, making per-call pricing viable for agent workloads. AgentCore Payments provides managed payment capabilities purpose-built for autonomous agents, spanning the full lifecycle from wallet authentication through transaction execution to spending governance, so developers can focus on what their agents do, not on how they pay. LangChain developers can now focus on the pay-per-use business problem they are solving, while AgentCore Payments takes away the complexity of securely connecting to wallets, enforcing deterministic payment limits, and managing different versions of the protocol (x402 v1, v2) or other machine-to-machine protocols. Spending money needs deterministic limits Access is only half of the challenge. When agents can spend money, you need answers to hard questions: How do I control the agent spend? Without session-level deterministic payment limits, a runaway loop or unexpected edge case could drain funds. How do I fund my agent? With Coinbase CDP and Stripe (Privy) integration, end users can fund their wallets through fiat or USDC stablecoin across different networks for cost-effective microtransactions. How does my agent connect to the wallet securely? AgentCore Payments uses AgentCore Identity for secure authentication of payment wallets. Which protocol do I pick? Ramping up on any single protocol demands significant time and effort, as each comes with its own nuances. Today, most teams that productionize their agent handle agent payments in one of three ways: they point the agent at a free source instead (worse data, but no payment to handle), they build custom payment logic per API (30 to 50 lines of wrapper code per service), or they give up autonomy (the agent surfaces the paywall to a human). None of these scale as the number of paid services grows into the thousands. Beyond integration complexity, developers must build governance and budget guardrails from scratch to help prevent runaway spending, and meet the security and regulatory compliance requirements that payment flows demand. Agent developer experience is the cornerstone of AgentCore Payments. It gives developers one solution that connects to wallets, orchestrates payments across protocols, and enforces spending governance, without having to build it from scratch or commit to a protocol to get started. AgentCore Payments: LangChain middleware LangChain middleware exposes hooks at each step of an agent's execution, so you can intercept a model call or a tool call and add logic without changing the agent itself. Say you have a legal agent drafting a brief, and the court filing it needs sits behind a paywall. When its tool hits that paid API and gets back an HTTP 402, AgentCorePaymentsMiddleware detects the payment requirement, enforces session budget limits, signs the payment via Amazon Bedrock AgentCore Payments, and retries the request with payment credentials. Your agent gets the data it asked for, within the limits you set. Read more in the documentation. How it works Detect. A tool hits a paid API that returns HTTP 402 with an x402 payload. Validate. The middleware checks the payment amount against your session budget. If it exceeds the limit, the request is rejected and no payment is signed. Sign. If within budget, the middleware signs the payment via AgentCore PaymentManager. Retry. The original request is retried with payment proof attached. The API returns the content. Continue. The agent receives the content as if the API returned 200 on the first try. Setup is a config object and one entry in your middleware list: config = AgentCorePaymentsConfig( payment_manager_arn="arn:aws:bedrock-agentcore:us-east-1:...:payment-manager/pm-abc123", user_id="user-123", payment_instrument_id="instrument-456", region="us-east-1", auto_session=True, # session created on the first 402 auto_session_budget="5.00", # hard ceiling for this session ) agent = create_agent( model=model, tools=[], # the middleware registers http_request and payment query tools middleware=[AgentCorePaymentsMiddleware(config)], ) It works with any model provider LangChain agents support, though you'll need AgentCore for the payment infrastructure itself. Where it fits The AgentCore Payments middleware is a strong fit for workloads where agents need to access multiple paid services within controlled budgets. Use Case Why It Works Research agents Access premium databases: legal filings, medical literature, financial data Multi-step workflows Deep agents that access multiple paid services in sequence while staying under a total budget Per-user spending control SaaS products where each end user has their own budget and payment instrument MCP server consumption MCP tools can work with auto-payment when they return the 402 as text content and forward a headers argument Browser agents Navigate paywalled websites to extract content from many sites Auditing what your agents spend Adding cost controls to an agent limits cost overruns, but it doesn't impact the agent behavior that led to those transactions in the first place. This can show up in several ways: An agent stays under budget but reasons poorly about what to buy An agent spends its whole allowance in two steps, then fails the task An agent's paid request carries data that shouldn't leave your systems An agent is redirected by a malicious tool description to an endpoint nobody asked for All four can finish successfully, come in under budget, and look reasonable on an invoice. That's because the blockchain payments ledger only records that instrument X sent $0.02 to address Y at 14:03:11. It doesn't record that the agent was three steps into a research task, had a one-dollar limit, and chose that endpoint because a tool description mentioned court filings. That context exists only in the agent trace. We think that matters for two things: governance, avoiding unintended agent spending; and audit, meaning a durable record of what your agents bought that someone can query months later. Agent spending will get the same questions as any other spend within an organization. Who authorized it? What was the limit? How do you know the limit held? If you already trace your agents in LangSmith, you can track each step that led to an agent payment. The tool call appears, returns a 402, and appears again with a payment header attached, surrounded by the user's original request and the model's reasoning at each step. A short recorder middleware attaches the payment details as metadata on successful payments: amount, network, recipient, the tool that triggered it, and the session and user it was charged to. When a payment would exceed the budget, AgentCore denies it. The refusal shows up in the trace alongside the agent's response to it, so you can confirm the limit held rather than assuming it did. A refusal records that it happened, not what it cost, since the payment was never made. The exact figures stay in AgentCore's logs. Testing spend before it's real money Traces tell us how the agent reasoned through the purchase request. Evals test whether the thinking behind the purchase request was as intended so that you can validate good behavior and identify fixes for agent mistakes. Single-step evals test one decision. Give the agent a task worth pennies, return a 402 asking for fifty dollars, and check whether it pays anyway. Full-turn evals score the conversation trajectory across a dataset, checking total spend, number of paid calls, and task completion together. You will want to run them on every prompt or toolset change, since an agent that starts buying more than it needs still returns a perfectly good answer. Online evals run the same checks against production traces in LangSmith, flagging runs over a spend threshold or payments to unexpected endpoints. Here is a full-turn example: ten research tasks, each with a budget that covers what the endpoint charges. Two evaluators score every run. spend_within_budget compares what the run actually paid against the task's budget. relevant_data checks whether the data the agent bought answers the question it was given. For this run, spending stayed inside the budget on all ten tasks, and the data was relevant on seven. On the other three the agent paid for a response that could not answer the question. A dataset, evaluators, and an experiment together give you that view: not just whether the agent spent, but whether the spending bought anything useful. Change a prompt, a model, or a budget, rerun the same ten tasks, and you can compare the new version against this one, including latency, tokens, and model cost. Getting started Two ways to provision this on the AWS side. The AgentCore Payments skill sets up your PaymentManager and payment instrument through a guided conversation with Claude Code, Kiro, or Codex, or you can do it by yourself with the AgentCore CLI, AWS SDK, or Boto3. Then install the middleware: pip install -U "bedrock-agentcore[langgraph,strands-agents]" Include strands-agents even though you're on LangChain. The integrations package imports both the LangChain and Strands adapters, so the import fails without it. Add the middleware with a small session budget, turn on LangSmith tracing, and run one paid task. If you can answer "what did this cost and why" from the trace alone, you're set up correctly. From there, build a small eval dataset on La [truncated for AI cost control]