I Built the Agent That Pays — Here's What I Learned

From Concept to Running Code

My previous post on HTTP 402 laid out the theory: AI agents don’t have psychological friction around micropayments. They can evaluate, authorize, and settle hundreds of tiny transactions per second. The x402 protocol gives this a standard format [1]. AgentCore Payments gives it managed infrastructure [2].

The LinkedIn discussion that followed raised the real questions:

• “Who rates the content quality after purchase?”, Sébastien Stormacq
• “What about tax implications for cross-border micropayments?”, Paweł Zubkiewicz
• “How is this different from Flattr? Won’t agents burn through budgets?”, Wladi Mitzel
• “Research content is the obvious first use case”, Christopher Jen

Fair questions. All of them. So I built the thing to find out.

What I Built

A complete marketplace simulation with both sides:

Publisher side: Four content merchants with different pricing and quality levels, served via CloudFront with a Lambda@Edge paywall that speaks x402.

Agent side: A Strands research agent with Amazon Bedrock AgentCore Payments that evaluates trust, quality, and cost-benefit before every purchase decision.

The full source is on GitHub: agentcore-payments-media-demo

A note on what’s real here: the payments are real on-chain transactions and the agent’s full decision flow runs end to end. The trust scores, the feedback loop, and on-chain settlement verification are simulated (pre-seeded or structural). Treat this as a proof of concept of the mechanism, not evidence that any real publisher deserves any particular score.

The Marketplace: Four Publisher Archetypes

A single trusted publisher proves nothing, the interesting decisions only emerge when the agent has to choose. So I modeled four merchants, each a deliberate archetype drawn from the real publishing market:

Each one stresses a different part of the decision framework. DataPulse is the trap: it’s up to 15x cheaper than MediaTech Daily, and a naive price-optimizer would empty its budget there. AlphaResearch is the quiet default: mid-price, mid-trust, the “good enough” choice an agent settles on when premium is overkill but it still wants some track record. InsightWire is the subtler problem: it might be excellent, but three transactions on record are far too little evidence to trust it yet. A real marketplace is mostly InsightWires: new, unproven, impossible to rank on reputation alone. (I come back to that problem later.)

The Publisher: A 40-Line Paywall

The entire payment gate is a Lambda@Edge function. What it gates on is the shape of the payment header, not a settled payment, verifying settlement on-chain is the piece still missing, so a structurally valid header is currently enough to pass. When content is requested without payment, it returns 402 with a structured price:

// Lambda@Edge — viewer request
if (!paymentHeader) {
  return {
    status: "402",
    headers: { "content-type": [{ value: "application/json" }] },
    body: JSON.stringify({
      x402Version: 1,
      accepts: [{
        scheme: "exact",
        network: "base-sepolia",
        maxAmountRequired: String(Math.round(price * 1e6)),
        payTo: merchant.wallet,
        asset: USDC_CONTRACT,
      }],
      merchant: { id: merchant.id, name: merchant.name },
      pricing: { amount: price, currency: "USDC", tier: tier },
    }),
  };
}

That’s it. The publisher says: “This costs $0.015 in USDC on Base. Here’s my wallet address.” No API key exchange, no contract negotiation, no OAuth dance.

One scope caveat: in this demo the gate validates the payment header’s structure, it doesn’t verify on-chain settlement, so a structurally valid header unlocks content. A production paywall verifies and settles the authorization through a facilitator before serving anything; that’s the first item on my What’s Next list.

The Agent: Trust Before Money

Here’s the part most people miss: a smart agent doesn’t just pay every 402 it encounters.

My agent runs a 5-step decision framework before spending a single cent:

1. TRUST CHECK    → Is this merchant reliable? (query reputation registry)
2. RELEVANCE      → Does this content match my research goal?
3. QUALITY SIGNALS → How fresh? How many citations? Verified publisher?
4. COST-BENEFIT   → Quality-adjusted price vs. alternatives
5. DECISION       → BUY / SKIP / TRIAL

Drawn out, the logic looks like this:

In my demo runs, this means the agent skips the cheapest publisher (DataPulse, $0.001/article) because its 15% dispute rate makes it unreliable. It pays 15x more for MediaTech Daily because the trust score justifies the premium.

This is the behavior you want. An agent that optimizes purely on price would buy garbage; with the decision framework, mine spent more like a careful researcher than a bargain hunter, in these runs, at least. How robustly that holds depends on the model, as I get to below.

The Payment: Three Seconds, Zero Human Involvement

When the agent decides to buy, the AgentCore Payments plugin handles everything:

config = AgentCorePaymentsPluginConfig(
    payment_manager_arn=PAYMENT_MANAGER_ARN,
    user_id="researcher001",
    payment_instrument_id=INSTRUMENT_ID,
    payment_session_id=SESSION_ID,  # $1.00 budget, 8h expiry
    region="us-east-1",
)

agent = Agent(
    system_prompt=DECISION_FRAMEWORK,
    tools=[http_request],
    plugins=[AgentCorePaymentsPlugin(config)],
)

The plugin intercepts any 402 response, signs an EIP-3009 transferWithAuthorization [4], waits one block (~3 seconds), and retries with the payment proof. The agent doesn’t even know a payment happened, it just gets the content back.

The Architecture Decisions That Mattered

A working demo is a series of choices, and a few of them shaped everything that followed.

Managed payments over self-custody

The agent never holds private keys. AgentCore Payments manages the wallet, signs transactions, and enforces the budget; the agent just expresses intent (“buy this”). I could have wired up a raw wallet and signed transferWithAuthorization myself (earlier x402 experiments in the field did exactly that), but handing key custody and budget enforcement to managed infrastructure is the first thing separating a demo from something you’d trust with real money, necessary groundwork, not the whole of it.

Real on-chain payments, zero cost

Everything runs on Base Sepolia testnet with testnet USDC from a faucet. The payments are real on-chain transactions (the same code path as production), but the tokens have no monetary value. Moving off testnet is a three-variable change (network, USDC contract address, funding source). Going to production is not: on top of those, this demo still needs on-chain settlement verification, and then the usual trust, security, compliance and operational work. This let me iterate fearlessly without spending a cent.

The paywall is the CDN

The payment gate is a Lambda@Edge function at the CloudFront viewer-request stage, not an origin service. Unpaid requests get their 402 in under a millisecond at the edge, the origin is never touched, and the whole thing sits in the free tier. Pushing the paywall to the edge means the publisher pays nothing to reject a request: they only do work once they’ve been paid.

Trust and feedback as separate services

Reputation (the Trust Registry) and post-purchase ratings (the Feedback Service) are independent API Gateway + Lambda services, not baked into the agent or the merchant. That separation is deliberate: in the real world, trust infrastructure will almost certainly be operated by someone other than the buyer or the seller, so I modeled it as a thing you call, not a thing you own.

One core, three surfaces

The agent logic lives in a single shared core/ module that the demo shell scripts, the web UI, and a Jupyter notebook all import, with no copy-pasted agent code anywhere. For the UI I chose AG-UI with CopilotKit over Chainlit, Streamlit, and Gradio, mainly for its official Strands integration and its generative UI: each tool call renders its own custom React card, so you watch the agent reason and pay in real time. It’s more setup than a Streamlit script, but the result looks like a product rather than a science experiment.

What Surprised Me

Scope: this reflects Amazon Bedrock AgentCore Payments in preview as of June 2026. The API and SDK are evolving quickly, so check the documentation for the current state.

1. It’s a Preview, Expect a Little Assembly

AgentCore Payments is in preview, and the SDK is moving fast. In a few places it’s slightly ahead of the published examples, so a handful of parameter names differ. Once you know the shape, it’s simple:

This is exactly what you’d expect from an early preview, and the team is iterating quickly. I’ve shared detailed notes with them, and the API itself is clean and consistent once the parameter shapes click into place.

2. Everything Is User-Scoped (By Design)

One thing worth internalizing early: every payment instrument, session, and transaction is scoped to a userId. That’s a smart security boundary, provided your application controls which userId a caller can present, an agent can’t reach into another user’s wallet. My one stumble was self-inflicted, a typo (researcher001 vs researcher-001) between resource creation and agent config that cost me a little debugging time.

The lesson is simple: pick a userId convention and keep it consistent everywhere. I’ve also passed a small suggestion to the team: surfacing the searched userId in the “not found” response would make this kind of typo instant to spot.

3. The “Model Agnostic” Question Is Real

With the prompt, framework, and merchant signals held constant, the agent’s decision quality tracks the model’s reasoning ability. When it runs on a frontier model, the trust/cost-benefit analysis is subtle and human-like. On a smaller model, it degrades to “buy everything under $0.01.” The decision framework is in the prompt, but execution depends on the model.

That’s why, for real money, the reasoning shouldn’t run unsupervised. The pattern that works is simple: the agent proposes, deterministic policy disposes. Budget caps, merchant allow-lists, and a hard per-item price ceiling sit around the model’s judgment like a seatbelt, so even a bad call can’t become an expensive one.

The Questions We Still Can’t Answer

Building this surfaced questions that no amount of coding can resolve. What follows is my own forward-looking perspective: personal speculation about where the hard problems are, not a statement about anyone’s roadmap, plans, or product direction.

Who Runs the Trust Registry?

In my demo, the Trust Registry is a mock Lambda with pre-seeded data. In production, someone needs to maintain merchant reputation scores. The options:

My take: This is the missing piece. AgentCore Payments handles wallets and budgets beautifully. But without trust infrastructure, agents have no basis for quality purchasing decisions. Whoever solves trust for agent commerce wins the market.

How Do You Preview Content Without Giving It Away?

The 402 response in my demo includes a preview field, an application-specific extension alongside the x402 payment requirements, not a field the spec defines. But what goes in it? Too much preview and the agent doesn’t need to buy. Too little and it can’t evaluate relevance.

In my demo, the preview contains: title, abstract, keywords, word count, and quality signals (citation count, methodology type, publication date). This gives the agent enough to assess relevance without revealing the actual content.

But this is a content strategy question, not a technical one. Each publisher needs to figure out their preview-to-paywall ratio, just like they did for human readers with “first 3 paragraphs free.”

What About Feedback Loops?

After purchasing content, my agent rates its quality. But those ratings go… where? In the demo, they feed back into the Trust Registry. In production:

• Do ratings come from individual agents or aggregate across all agents?
• Can merchants dispute low ratings?
• Do ratings decay over time?
• Can agents game the system by always rating 5 stars to maintain access?

This is the eBay/Amazon seller rating problem, but for content quality at machine speed.

What About Content That’s Wrong?

An agent pays $0.015 for an article that turns out to contain outdated information. What happens? There’s no “return” mechanism in x402. The payment is final once settled on-chain.

Possible approaches:

• Reputation penalty: Low ratings reduce the merchant’s trust score
• Dispute resolution: A challenge period before final settlement
• Money-back guarantee: Merchant-side policy, not protocol-level

None of these are solved by the protocol today. And note what x402 deliberately doesn’t cover: once the agent has paid and received the content, nothing at the protocol level stops it from redistributing it. That’s a licensing and policy problem (the same one publishers already have with human subscribers, just at machine speed), not something payment settlement solves.

How Does an Agent Trust a Newcomer?

The trust-registry question assumes there’s a score to look up. But most merchants in a real marketplace are new, like InsightWire in my demo, three transactions deep with no track record. How should an agent treat the unknown? Refusing every newcomer kills the market before it starts; trusting them blindly invites abuse.

The plausible answers all borrow from human commerce: a TRIAL tier (buy one cheap item, rate it, then escalate), staked or bonded reputation (the merchant puts money behind its claims), or attestations from parties the agent already trusts. None is standard yet. Bootstrapping trust for newcomers is, I think, the single hardest problem in agent commerce, and whoever cracks it will build a moat around it.

What Happens When the Agent Is Attacked?

An agent with a funded wallet is a new attack surface. What stops a malicious 402 response, or an instruction smuggled into “preview” text, from talking the agent into spending?

The honest answer: the payment session is the backstop, not prevention. AgentCore enforces a maxSpendAmount and an expiry per session, so the blast radius is bounded: in my demo, an attacker could waste at most $1 before the session runs dry. That caps the damage; it doesn’t prevent it. Real defenses layer on top: merchant allow-lists, anomaly detection on spend rate, per-item price ceilings, and treating every 402 payload as untrusted input. Sébastien Stormacq raised exactly this on the previous post, and it deserves its own deep-dive.

What About Tax and Compliance?

Paweł Zubkiewicz asked the question I have the least confident answer to: what about tax on cross-border micropayments? If an agent in Germany pays a publisher in the US fractions of a cent thousands of times a day, who owes what, where? VAT, withholding, and reporting were designed for invoices and quarterly filings, not for streams of sub-cent settlements. The on-chain ledger gives you a complete and tamper-evident record of transfers, which cuts both ways: strong transparency for you, and the same for tax authorities. It records transfers, not identities or purposes, attribution and the off-chain contract still sit outside it. I don’t think the protocols answer this yet, and it may be the slowest part of the stack to mature, because it’s regulatory, not technical.

The Cost Reality

Running this demo costs essentially nothing:

In production, the economics flip: the publisher earns money on every agent interaction instead of blocking them. If an agent pays $0.01 per article and a publisher gets 10,000 agent requests/day, that’s $100/day in gross payment revenue, before content production, infrastructure, verification, fraud, refunds and tax. What it avoids is ad impressions, subscription management and content licensing negotiations.

This isn’t Flattr-style tipping, a comparison a few readers raised. Flattr split a reader’s monthly budget across sites they chose to support; x402 is a mandatory, per-request settlement the agent makes to unlock a specific resource. No goodwill, no monthly pot, just payment for access, the use HTTP 402 was reserved for, though the status code was never given a standardized settlement mechanism to go with it.

But pay-per-call isn’t the right model for every reader. It fits some access patterns far better than others:

The interesting shift is that agents unlock the first two rows, the access patterns that human-oriented paywalls, with their signup friction and subscription minimums, have historically priced out.

Try It Yourself

The complete demo is open source:

👉 github.com/stechr/agentcore-payments-media-demo

Deploy in ~5 minutes with CDK. Testnet only, zero monetary risk. Includes:

• Publisher paywall (CloudFront + Lambda@Edge)
• Research agent with trust-based decision framework
• Trust Registry and Feedback Service (mock APIs)
• Web UI with real-time activity visualization
• Demo scripts and Jupyter notebook

Where I take this next

Three things I’m working on:

1. Real payment verification: the current paywall checks header structure but doesn’t verify on-chain settlement. Adding a facilitator service.
2. Dynamic trust scores: connecting the feedback loop so ratings actually update merchant reputations across sessions.
3. Multi-agent trust sharing: can agents share quality ratings without revealing what they purchased?

The protocol layer (x402) and the infrastructure layer (AgentCore Payments) exist today. The intelligence layer (trust, quality assessment, feedback loops) is where the interesting problems live.

If you’re a publisher thinking about this, or building something similar, I’d love to hear from you.

This is Part 2 of the Agentic Commerce series. Part 1: HTTP 402: The 30-Year Placeholder That AI Agents Finally Activated

If You’re Running This on AWS

Part 1 walks through the AgentCore Payments setup and resource model in depth. Here’s the short version, the stack this demo runs on [3]:

The entire stack deploys with npx cdk deploy and runs within free tier for demos.

Sources

[1] x402 Protocol Specification, the open standard for HTTP 402 micropayments. https://www.x402.org/

[2] Amazon Bedrock AgentCore Payments, How it works (PaymentManager, connectors, sessions, instruments). https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html

[3] “x402 and Agentic Commerce: Redefining Autonomous Payments in Financial Services,” AWS for Industries blog. https://aws.amazon.com/blogs/industries/x402-and-agentic-commerce-redefining-autonomous-payments-in-financial-services/

[4] EIP-3009: Transfer With Authorization, the signed-authorization mechanism the x402 exact scheme uses on EVM networks like Base with USDC (the path this demo takes); the scheme’s implementation is network- and asset-dependent. https://eips.ethereum.org/EIPS/eip-3009

[5] Coinbase Developer Platform, wallet provisioning used by the AgentCore Coinbase connector. https://portal.cdp.coinbase.com/

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

• AIAgents
• AgenticCommerce
• HTTP402
• AmazonBedrock
• AgentCore
• X402
• Payments
• Publishing