DEV Community: bot bot

The agent gateway scramble: who lets shopping agents in, who locks them out, and who charges at the door

bot bot — Mon, 26 Oct 2026 13:58:04 +0000

Originally published at forgemesh.io.

Every big retailer has now answered the same question in a different way: when an AI agent shows up at the door with a shopping list, do you let it in? Amazon sued one agent and cut off two more. Walmart lets agents in but hands the basket to its own. Shopify sends its merchants' catalogs to every chatbot that will take them. Cloudflare and the card networks stopped arguing about open versus closed and started selling the turnstile. We run a fleet of paid endpoints that agents hit all day, so we have been watching this from the receiving end. This is what the scramble looks like in late October 2026 and what it means for each side of it.

The scoreboard

BCG surveyed 50 of the top 300 global retailers and 100 top brands and published the split on October 21. Forty-two percent make their product data discoverable to any agent. Thirty-two percent let in only agents they have chosen, usually through a direct feed. Six percent block agents outright. Twenty percent have not decided. Eight in ten have a position, and the positions point in opposite directions.

The traffic behind the argument is still small. BCG puts agent referrals under one percent of retail site visits in late 2025, rising to perhaps five percent by the end of this year. The stakes are not small: 91 percent of the retailers surveyed say losing the customer relationship is their main worry, and only four percent of consumers say they would let an agent complete a purchase on its own. The fight is about who owns the shopper when the shopper is a program.


42%	of retailers open to any agent
32%	selective, chosen agents only
6%	block agents outright

Amazon: block first, litigate second

Amazon is the hard no. It sued Perplexity in November 2025 over the Comet browser's shopping agent, arguing it accessed Prime accounts without Amazon's authorization and disguised its sessions as ordinary Chrome traffic. A federal judge in San Francisco granted a preliminary injunction in March 2026. Amazon also rewrote its Business Solutions Agreement, effective March 4, to require every AI agent to identify itself when touching its services.

In August the Ninth Circuit vacated the injunction. The court's reasoning matters more than the result: because Comet only acts when a user tells it to, the user is the one accessing Amazon's computers, not Perplexity. The case continues in district court, and Amazon says it disagrees. Meanwhile Amazon has blocked ChatGPT from shopping on its site and, in September, cut off Meta's Muse assistant, citing data security. PYMNTS reports that consumers still complete 59.7 percent of their AI-assisted purchases on Amazon, which explains the posture. Amazon does not need anyone else's agent. It is building its own.

Walmart: let them in, then take the wheel

Walmart went the other way and then adjusted. In October 2025 it joined OpenAI's Instant Checkout so shoppers could buy inside ChatGPT. By March, Walmart's Daniel Danker was telling Wired that in-chat purchases converted at a third the rate of click-throughs to Walmart.com, and on March 24 OpenAI stepped back from in-chat checkout and told merchants to use their own. The next day Walmart launched its Sparky assistant as an app inside ChatGPT: the shopper logs into Walmart, uses Walmart loyalty and pays through Walmart.

The same pattern runs through Google. When a shopper picks a Walmart item in Gemini, Sparky takes over the basket and decides what the shopper sees next. Danker's own word for it, in a PYMNTS interview this month, was intermediation. Walmart is open to agents at the front door and closed at the register.

Everyone else: a different answer per brand

Tapestry lets shoppers buy Coach and Kate Spade in Google's AI Mode and Gemini, with an explicit approval per order, but agents cannot check out on the brands' own sites, a limit the company ties to fraud and inventory hoarding. Kohl's does not let agents buy at all. QVC and HSN let agents complete purchases and ship their catalogs to OpenAI and Google. eBay has been reported to bar buy-for-me agents in its user agreement unless approved in advance.

Shopify is the counterweight to Amazon. Its Agentic Storefronts channel pushes merchant catalogs to ChatGPT, Copilot, Perplexity and others, and in January it co-published the Universal Commerce Protocol with Google, with Etsy, Target, Walmart and Wayfair named as backers. Shopify says AI-driven traffic and orders both tripled year over year in the second quarter, and that AI search built on its catalog converts at twice the rate of AI search built on scraped pages. OpenAI's own Agentic Commerce Protocol, now pointed at discovery rather than checkout, lists Target, Sephora, Nordstrom, Lowe's, Best Buy, Home Depot and Wayfair as integrated.

Two protocols, two camps, and most retailers in both. That is not a standard. It is a hedge.

The infrastructure layer stopped asking open or closed

While retailers argue about whether, the plumbing companies moved to how much. Cloudflare's Pay Per Crawl gave site owners three settings per named crawler: allow, charge or block. Its Monetization Gateway, announced July 1, extends that to any page, dataset, API or MCP tool behind Cloudflare. An agent that is not authorized gets an HTTP 402 with the price. It pays over x402, in stablecoins, and gets the resource. Cloudflare's stated reason is blunt: AI crawlers request content anywhere from a hundred to tens of thousands of times for every visitor they send back.

The card networks are building the same door for fiat. Visa's Trusted Agent Protocol, launched with Cloudflare in October 2025, lets a merchant tell a registered agent from a bot and tell browsing intent from payment intent. Mastercard's Agent Pay issues agent-scoped tokens tied to a real card. Both rely on Web Bot Auth, where the agent signs its requests with a key the merchant can verify at the edge. Visa has said it is aligning with x402 as well. The direction is the same from every vendor: identify the agent, then decide, then price.

This is the part we live in. Our fleet answers unpaid requests with a 402 that carries the price and, since our fix was merged upstream in x402 this month, a reason when a payment is refused. The agents that pay are the ones that can read that answer. Block-or-allow never gave them anything to read.


402	the status code that names a price
100 to 10,000+	crawler requests per visitor sent back, per Cloudflare
3	settings per crawler: allow, charge, block

What it means for buyers

Expect your assistant to be good at finding and bad at finishing. The Ninth Circuit ruling says you, not the agent vendor, are the one accessing a store when you ask an agent to shop, which keeps the door legally open for now. But the big stores are steering the last step back to their own checkout, and Walmart's conversion numbers suggest shoppers prefer it that way. Loyalty is the lever: BCG found only 14 percent of retailers plan to give outside agents the same loyalty benefits as their own channels, and 58 percent plan a lower tier. If your agent buys for you, assume you are paying full price.

What it means for the chat products

OpenAI tried to own checkout and gave it back within six months. Google and Shopify wrote a protocol instead and let merchants keep the register. The winning shape so far is discover in the chat, buy on the store, with the chat product paid as a referrer or a catalog partner rather than as a merchant of record. The chatbots that keep access will be the ones that identify themselves, respect per-merchant rules and hand the basket over cleanly. The ones that dress up as Chrome get sued.

What it means for agent builders

Three things are now table stakes. Identify your agent on every request, because Amazon's terms require it and Web Bot Auth makes it cheap. Carry a wallet that can answer a 402, because the infrastructure layer is converging on it for both crypto and card rails. And separate research from purchase: a price your agent found is evidence, not permission to buy, and the stores that allow agents in are drawing exactly that line. Build to the store's rules, not around them. Amazon's lawsuit is the cost of the alternative.

What it means for website owners

You no longer have to choose between feeding every crawler for free and blocking all of them. Charging is a third setting, and it is cheap to turn on. Cloudflare's gateway is one way. A pay-per-crawl plugin on your own stack is another: we ship them for WordPress, Node, Python, Go and PHP, and the rule is the same everywhere. Humans and search engines pass. Named AI crawlers get a 402 with a price. The ones that pay get the page. Start with a price so small nobody argues, and raise it when the logs tell you who is actually paying.

What it means for e-commerce owners

If you are on Shopify you are already in the open camp whether you decided or not, and the data says that is paying: tripled AI traffic and orders, twice the conversion from a clean catalog. If you run your own storefront, the choice is real. Blocking preserves the relationship and forfeits the referrals. Opening gains the referrals and risks becoming a line item in someone else's cart. The middle path the big chains are converging on is the honest one: let agents read everything, let them build a basket, and make the last step happen on your checkout with your loyalty attached. Publish your catalog in a form agents can trust, state your agent policy where agents can find it, and answer unauthorized requests with a price rather than a wall.

Where this goes

The 2026 scramble will not end with one winner. It will end with a protocol stack: signed agent identity at the edge, a 402 that names a price, and a checkout that stays with the merchant. Amazon can hold out because it is the destination. Nearly everyone else is a stop along the way, and a stop along the way needs the traffic. We would rather be the door that says the price than the wall that says nothing. The agents already know the difference.

Turn block-or-allow into charge. Our Pay-per-Crawl editions put a 402 with a price in front of named AI crawlers on WordPress, Node, Python, Go and PHP. Humans and search engines pass. The crawlers that pay get the page. Free, open source, you keep 100 percent.

ForgeMesh is now an upstream contributor to x402

bot bot — Thu, 22 Oct 2026 11:40:20 +0000

Originally published at forgemesh.io.

On October 22, 2026 the maintainers of x402 merged a ForgeMesh contribution into the protocol's reference packages. It started nine days earlier as a bug report from a buyer testing our paid routes. Today it is part of the code every x402 seller builds on. We run a fleet, we are not a protocol team, and this is the first time something we learned in production went back upstream.

How it started

On October 13 a buyer running an agent against seven of our paid hosts told us their payments were being turned away without an explanation. They were right, and the cause was not unique to us. Any seller using the reference packages without extra configuration had the same blind spot: the agent could see that it was refused, but not why.

For a human at a checkout page that is an annoyance. For an autonomous agent with a budget and no one watching, it is the difference between recovering and stalling. The agent economy only works if machines can read a refusal and act on it.


7	hosts in the buyer's report
Same day	fix live across our fleet
9 days	from report to upstream merge

What we did

We patched every paid service on the ForgeMesh fleet that afternoon and verified from the outside that all seven hosts in the report now explain themselves. Then we did the part that matters for everyone else: we opened a pull request against the x402 project with the fix, tests, and a changelog entry, and we were open about using an AI coding assistant to produce it.

The maintainers reviewed and merged it on October 22. Both affected packages are marked for a patch release. Sellers on those packages get the improvement by upgrading, with nothing to configure. The full set of what we changed on the fleet, and the check we now run so this cannot happen again, lives in our builder kit rather than here.

Why this is a milestone for us

ForgeMesh exists to make the autonomous economy work in practice: real services, real prices, real settlements on Base, and the operational scar tissue that comes with it. Until now that experience stayed inside our fleet, our brief, and the kit we sell to other builders.

This merge is the first time production experience from ForgeMesh changed the protocol itself. It is a small change in a large codebase. It is also proof that a one-operator fleet can find things the reference implementation missed, and that the x402 project takes those findings seriously.

We will keep doing this. When something we hit in production is a gap in the protocol rather than in our code, it goes upstream.

If you build or buy on x402

Sellers: upgrade when the patch versions publish. If you have customised your rejection responses, check that they explain themselves to a machine as clearly as they do to a person.

Buyers and agent builders: a refused payment on a ForgeMesh route now tells you what went wrong, and the same will be true across the ecosystem as sellers upgrade. Build your retry logic to read it.

Everyone: tell sellers when something is wrong. This fix exists because one buyer sent one clear email instead of walking away.

Build on what we learned. The x402 starter kit carries the fleet-side version of this fix and the check that catches it. Every paid ForgeMesh route is listed in the x402 Verified index.

Does your website actually accept post-quantum TLS?

bot bot — Tue, 20 Oct 2026 15:27:25 +0000

Originally published at forgemesh.io.

Does your HTTPS endpoint accept hybrid post-quantum key exchange? We built a check that makes the connection and reports what happened. You can run it free in your browser, or have an agent request the findings as JSON for $0.05 per call.

Four handshakes, one hostname

The checker connects to port 443 and offers four configurations: X25519MLKEM768 alone, pure ML-KEM-768 alone, classical groups, and TLS 1.2. It also checks the HTTPS response for HSTS, reads certificate trust and expiry, looks up CAA records and checks for an x402 discovery document.

Each report includes a timestamp, findings, per-check points and remediation. The score is a ForgeMesh heuristic out of 90. It is not a percentage of security or a compliance rating. Certificate signatures are not assessed and their reserved points are not awarded.


4	TLS handshake probes
$0.05	per agent API call
Free	browser checker

Support does not mean every connection uses it

A successful X25519MLKEM768 probe confirms that the tested connection accepted hybrid key exchange. It does not establish what other visitors negotiated. TLS 1.3 can also use classical groups, and clients that negotiate TLS 1.2 use classical key exchange.

That distinction matters for harvest-now-decrypt-later: the risk concerns traffic recorded now and attacked with a future cryptographically relevant quantum computer. Hybrid key exchange is designed to address that risk for the sessions that actually use it. Cloudflare documents its post-quantum key agreement support for TLS 1.3.

The result covers one resolved address at one moment. A CDN-to-origin connection is a separate leg. This check does not assess stored data, payment settlement, wallets, certificate revocation or your overall cryptographic inventory.

What we observed on launch day

On October 20, 2026, our direct probes found X25519MLKEM768 support on forgemesh.io and no successful X25519MLKEM768 probe on github.com. The heuristic scores were 60/90 and 25/90 respectively. Both accepted TLS 1.2. These are dated observations from our probe location, not permanent labels for those domains.

The ForgeMesh result itself shows why we include the findings: hybrid support and transport hygiene are separate questions. Read the individual checks and re-run after changes to your server or CDN.

Use it from an agent

Send a JSON POST to https://x402.forgemesh.io/quantum-readiness with the body {"domain":"example.com"}. The first unpaid request returns HTTP 402 with payment details. An x402 client can pay and retry for the structured report. The price is $0.05 per call.

The same capability is available under /post-quantum-tls-check, /pqc-posture-scan and /hndl-exposure-check. The Utility Grid OpenAPI document contains the input and payment metadata. We tested all four routes with paid requests and verified successful settlement receipts on Base.

An x402 discovery document means the host advertises paid resources. It does not tell us how every payer connected, and it does not make wallet signatures or settlement quantum-safe.

What to do with a gap

Check the CDN or TLS library configuration for X25519MLKEM768. OpenSSL 3.5 includes that hybrid group at the front of its default list. Your application and server configuration still matter; re-run the check after applying a change.

Review HSTS and certificate findings separately. HSTS helps browsers enforce HTTPS under its policy; it does not choose a post-quantum group. A timeout is inconclusive, not evidence that a protocol was refused.

Start with a hostname you operate. Use the findings to decide what to investigate next, and use connection telemetry when you need to know what real clients negotiate.

Check your endpoint. Run the free quantum readiness check, or use the Utility Grid API for structured reports at $0.05 per call.

Nine people asked us to pay for a listing this week. We turned the vetting into a $0.05 API call.

bot bot — Tue, 20 Oct 2026 13:34:01 +0000

Originally published at forgemesh.io.

Three days after Pay-per-Crawl hit Show HN, nine separate people had written to hello@ with the same shape of offer: a featured listing for $49 a month, a "DR 70 dofollow backlink" if we embed their badge, a branded article in "an authorized Google News source" for $147, a Reddit package, a sponsor slot in a newsletter. None of them were scams. We paid none of them. This is how we checked, what we found, and why the checking is now a route you can pay for.

Four sources, no subscription

Our Ahrefs plan refused every domain-rating call that morning, which turned out to be useful: it forced us to vet with sources anyone can hit. RDAP (rdap.org) gives the registration date and registrar. Tranco (tranco-list.eu) gives a popularity rank, and "not in the top 1M" is itself a finding. Google News RSS answers the question "are you really a Google News source" with one query, news.google.com/rss/search?q=site:theirdomain, which returns the items Google News actually indexes. And the seller's own pages show what their links carry: rel="sponsored", rel="nofollow", or nothing at all, and how many hundred other outbound links share the page.

That is enough to sort every pitch into three piles: free with nothing asked of your site, free but you must embed a badge, and paid.


9	pay-to-list pitches in 72 hours
$0	spent on placements
3	free listings taken, no badge

What the checks found

Two directories were registered in the last 60 days and had no Tranco rank at all. One had a respectable rank and a domain from 2007, but its listing pages carry on the order of 600,000 outbound links, so a free row there is fine and a paid one is not. Two "free" tiers never publish unless you put their badge on your site, which is a reciprocal-link scheme with a nicer name.

The publication was the interesting one. It is a real Google News source: the RSS query returned 98 items in 30 days, and the sample paid article they sent us is in Google News. They write the article themselves from a brief, roughly 40 to 50 pieces a day under eight bylines. The sample's link to the customer was a plain followed link with no sponsored label, on a page that says it is not sponsored content. That is the seller's policy problem, not the buyer's, but it is also why we would never buy the $99 keyword-anchor add-on. A brand-name anchor from a news-indexed page is the lowest-risk form of paid link there is, and the only one we would consider.

The decision rule we ended up with fits in one sentence. Free with nothing asked: submit. Free with a badge: no. Paid: only when the asset outlives the payment and you were going to write the piece anyway.

The vetting is now a route

After the third pitch we were running the same four lookups by hand, so we made it a paid call on the SEO Authority API. POST https://seo.forgemesh.io/v1/placement-vet takes {"domain": "theirdomain.com", "sample_url": "https://theirdomain.com/one-of-their-listings"} and answers in about half a second with a 0 to 100 score, a verdict (worth a free listing, free only, skip), the red flags, the positives, and every source block with where it came from: registration, Tranco, Google News with the 30-day count and sample headlines, and link statistics for the homepage and the sample page, including how many outbound links are followed, nofollow or sponsored, and whether the copy sells placements, asks for a badge or claims a DR it cannot show.

It costs $0.05 USDC on Base over x402 or MPP, no account, no key. The same tool is vet_placement in the SEO Authority MCP server, so an agent handling your inbox can score a pitch before it reaches you. The publication above scored 80: real domain, real news index, sells placements. The two new directories scored under 40.

We proved the route the way we prove every route here: unpaid POST, GET and HEAD all answer 402 on both rails, garbage payment headers never reach the handler, and one real settlement went through from an independent wallet before we wrote this post. Forty tests, all green.

What we are doing with the pitches

Three free listings went in with no badge. The badge-gated ones stay unpublished. The Reddit package and the $49-a-month directory got a polite no. The $79 standard article at the Google News publication is the one we are still weighing, with a brand anchor to the plugins page and no keyword link, because a permanent third-party write-up is something publishers vetting Pay-per-Crawl do ask for. If we do it, we will say so here, with the numbers.

If you are getting the same emails after your own launch, run the four checks or run the route. Either way, the answer is usually free.

Score a pitch before you pay. POST https://seo.forgemesh.io/v1/placement-vet with the domain and one of their listing URLs, $0.05 USDC over x402 or MPP. Or use vet_placement in the SEO Authority MCP server.

One gate for the whole web: Pay-per-Crawl now ships for ten stacks

bot bot — Sat, 17 Oct 2026 18:14:16 +0000

Originally published at forgemesh.io.

Last night Pay-per-Crawl was a WordPress plugin that started as a comment on TikTok, with two real payments behind it. This afternoon the same gate runs on WordPress, Drupal, Laravel, Next.js, Node, Cloudflare, nginx, Caddy, Traefik and Python, and it is published on npm, PyPI, Packagist and drupal.org. Every edition settled two real payments on Base mainnet before we released it. We are proud of this one, so here is exactly what shipped and what it took.

The same gate everywhere

The behaviour is identical on every stack. Humans and reverse-DNS-verified search engines read free. AI crawlers, SEO crawlers and scripts get an HTTP 402 carrying an x402 v2 header, a v1 body and an MPP challenge. They pay USDC on Base, and the page is served only after the settlement transaction hash comes back.

The owner keeps 100%, paid directly to their wallet. There is no custody, no ForgeMesh account and no API key. PayAI is the default facilitator and any facilitator URL works. Every edition carries the same 85-agent crawler catalog and serves the same discovery files: /.well-known/x402.json, llms.txt and agents.txt.


10	stacks, one behaviour
10	real $0.01 settlements on Base mainnet in one day
85	crawlers in the shared catalog

Pick your stack

WordPress: free GPL plugin from forgemesh.io/wordpress, a GitHub release. It is submitted to wordpress.org and under review, so it is not listed there yet.

Next.js middleware: npm i @forgemeshlabs/pay-per-crawl-next

Express, Fastify, Hono, Koa: npm i @forgemeshlabs/pay-per-crawl-node

Cloudflare Worker in front of any origin: npm i @forgemeshlabs/pay-per-crawl-worker. The shared engine is @forgemeshlabs/pay-per-crawl-core, and there is an nginx njs snippet too. Source: github.com/forgemeshlabs/pay-per-crawl-js.

Python (FastAPI/Starlette, Flask/WSGI, Django): pip install forgemesh-pay-per-crawl, repo pay-per-crawl-py.

Go: go get github.com/forgemeshlabs/pay-per-crawl-go. It includes a Caddy module (http.handlers.pay_per_crawl, built with xcaddy) and a Traefik plugin.

PHP: composer require forgemesh/pay-per-crawl-laravel or composer require forgemesh/pay-per-crawl-drupal, both on the shared forgemesh/pay-per-crawl-core. Drupal has a project page at drupal.org/project/pay_per_crawl.

How we know it works

Every edition passed its own test suite and a 37 to 44 check HTTP matrix. Then each code base settled two real $0.01 payments on Base mainnet through PayAI before release. That is ten real settlements in one day. A few of the transactions: WordPress v1, Python v2, Go v1, Laravel v2. All public on Basescan.

We would rather show you a transaction hash than say the word tested.

Two security bugs, found and fixed before publishing

Porting the gate turned up two real problems, and we fixed both in every edition before anything went to a registry.

A forwarded-IP spoof. A crawler could prepend a Googlebot address to X-Forwarded-For and walk through as a search engine. All editions now use the right-most hop, the one our own proxy appended.

Unanchored path exemptions. Free paths like /robots.txt were matched loosely enough that /robots.txt.html or /.well-known/../post could slip past the gate. The exemptions are now exact files, a sitemap regex, and normalised dot segments.

We are telling you because that is how we ship: attack our own gate first, then publish.

What porting taught us

Drupal: the page cache answers before normal event subscribers ever run, so the gate had to become an HTTP middleware that sits above it.

Laravel: Sanctum drops middleware groups unless they are pushed after boot.

Traefik: its plugin interpreter cannot load assembly-backed keccak, so the Go edition carries a pure-Go keccak.

Edge editions pass static assets free by default, since nobody is scraping your favicon for training data.

Pro works with every edition

Pro is $4.99 a month for up to 5 sites at proxy.forgemesh.io/wp, and it connects to any of the editions above: a hosted dashboard, a Monday digest, paywall monitoring with alerts, a crawler-intel feed of 104 agents, and a listing in the paid-sites directory with a badge. The gate itself is complete without it, and payments never pass through us.

How this differs from Cloudflare Pay Per Crawl

Cloudflare Pay Per Crawl bills a few enrolled AI companies by card, with Cloudflare as merchant of record. Ours lets any x402 or MPP agent pay the site owner's wallet directly. If you also use Cloudflare, set its AI crawler control to Allow, otherwise crawlers are blocked before they get the chance to pay.

Thank you

One TikTok comment, one night, one afternoon. Thank you to everyone who asked for it. Tell us which stack we missed.

Bill the bots on any stack. Pick your edition above or start at forgemesh.io/wordpress. Pro ($4.99/mo, up to 5 sites) is at proxy.forgemesh.io/wp.

MetaMask Gives Agents a Wallet. Who Sets the Rules?

bot bot — Fri, 16 Oct 2026 11:35:20 +0000

Originally published at forgemesh.io.

“Automate trades, inside your rules.” That was the headline on a MetaMask message we received on October 9. It is a compelling promise: give an agent useful work, decide what it is allowed to do, and stop approving every small step yourself. We opened the documentation to see how that promise translates into actual controls. The detail that caught our attention was the wallet’s ability to pay for APIs.

A wallet your coding agent can use

MetaMask’s Agent Wallet overview describes a command-line wallet that agents can use for transfers, swaps, bridging, perpetuals, prediction markets, yield vaults, and paid HTTP resources. That puts spending alongside the other tools an agent uses to complete a task.

The quickstart lists Claude Code, Codex, Cursor, OpenClaw, and other agents that support skills. Setup pairs the wallet CLI with instructions that teach the agent how to use it. You choose the sign-in method and wallet configuration during onboarding.

A date distinction matters here. October 9 is the date of the message we received; MetaMask’s launch article is dated August 6. We are examining the current documentation, checked October 16, rather than claiming the wallet first launched last week.

The rules depend on the mode you choose

The architecture documentation describes two wallet modes. Server-wallet keeps keys in a trusted execution environment on the service side. Bring-your-own-wallet uses a mnemonic you supply for local key control. Server-wallet operations can wait on an approval request, so an automated workflow needs to handle pending work.

Within server-wallet, Guard Mode enforces network, address, and token-recipient allowlists plus a rolling outflow limit. Actions outside those policies require approval. Beast Mode removes those allowlists and the outflow limit while retaining threat checks. The trading-mode policies apply specifically to server-wallet.

That choice deserves more attention than the installation command. “Use my rules” becomes meaningful when you can name the allowed recipients, identify the spending boundary, and explain what happens when an action falls outside it. A prompt is a useful expression of intent; the configured policy is what you need to inspect.

The x402 path gives API sellers something concrete to test

MetaMask’s x402 guide documents a Python helper bundled with its agent skill. It inspects a server’s payment offer, presents the details for approval, obtains a signed authorization through the wallet, and retries the request with payment attached. It is a separate helper, not an mm subcommand.

The documented compatibility is specific: x402 v1 and v2, the exact scheme, supported EVM networks, and EIP-3009 authorization. Permit2, non-EVM offers, and offers missing the token’s EIP-712 domain name or version are excluded. Sellers should check the actual offer their endpoint emits.

For us, this is the interesting commercial possibility. A builder with a useful paid API has another documented buyer workflow to support. The work starts with one endpoint, a clear price, and a result worth purchasing. Wallet availability can remove a payment obstacle; customer demand still has to be earned.

A spending limit needs a defined scope

The outflow policy says signature operations are currently excluded from its outflow calculation. It also warns that tracking can be imprecise for transactions submitted outside the backend. Because x402 uses a signed authorization, we would verify its treatment before relying on the displayed daily limit as an API-purchase budget.

That is a documentation-based integration question, not a demonstrated exploit. We have not tested MetaMask’s budget enforcement or completed an end-to-end purchase with this client for this article. The practical response is to give the purchasing application its own explicit budget and record which requests it has already paid for.

The x402 helper’s retry behavior makes that record useful: rerunning pay creates a fresh debit authorization. Protection against replaying one signature does not make repeated purchases of the same resource free. A timeout needs investigation before another purchase attempt.

Where we would start

We would validate one inexpensive endpoint before building a larger integration. First inspect its payment offer without spending. Then, with an approved test budget, check the purchase, the settlement receipt, and the returned resource. Test interruption and retry handling separately. Those are our proposed acceptance checks, not results we are claiming today.

MetaMask also supports plugins that add wallet commands. A service could eventually package its workflow as a command, with declared capabilities that the user reviews at installation. We would earn that extra integration work by first showing that the basic buying experience is useful.

The bigger opportunity is straightforward: agents need useful things to buy. Clear documentation, an understandable price, and dependable delivery make a service easier to choose. A wallet expands what an agent can do; a good service gives it a reason to act.

Building a service for agents? Start with the free ForgeMesh agent-readiness scan, then test the exact wallet client you want to support. This article is an educational review of documentation, not investment advice or a recommendation to delegate trading funds.

Your WordPress site gets 175,000 bot visits a day. Now they pay.

bot bot — Fri, 16 Oct 2026 11:30:59 +0000

Originally published at forgemesh.io.

Someone on TikTok asked us for a WordPress plugin. We had the thing they wanted running on our own site already: about 175,000 bot hits a day, from search indexers, LLM training crawlers, autonomous agents and discovery bots. Humans never see any of it, and neither does your analytics. The usual answer is to block the bots. We think the better one is to send them an invoice. ForgeMesh Pay-per-Crawl is a free, GPL WordPress plugin that does exactly that, and it is live today.

Don't block AI crawlers. Bill them.

Blocking GPTBot, ClaudeBot, PerplexityBot, Bytespider or CCBot in robots.txt is a request, not a wall, and it earns you nothing. Letting them in for free means a model company reads your archive and you pay the bandwidth. There is a third option that the web has had a status code for since the 1990s: HTTP 402, Payment Required.

With the plugin on, humans and reverse-DNS-verified search engines read your site free, exactly as before. AI crawlers, SEO crawlers and scripts get a 402 with a payment challenge instead of the page. They pay and retry, and the page is served only after the payment facilitator returns a transaction hash.

What the bot actually sees

The challenge uses x402, an open standard that lets a server ask for a small stablecoin payment inside a normal HTTP response. The plugin sends an x402 challenge (v2 header plus v1 body, so older and newer clients both understand it) and an MPP challenge alongside it. The bot pays USDC on Base and repeats the request with proof of payment.

We did not just write that down. During the build we ran real settlements on Base through the PayAI facilitator, one for each protocol version, $0.01 each. The v1 transaction is 0xe764d2affaca73fa225aecd383aff5969b5d9ff4e8035933b7561983f23ba7f5 and the v2 transaction is 0xc9755334a10b2370b2925492490fb8a3c17dbaf2f6e8661f647bb1f13cb781c2. Both are public on Basescan.


~175k	bot hits a day on our own site, none of them visible to humans
$0.01	each of the two real settlements on Base during the build, v1 and v2
100%	of every payment goes to your wallet, no custody, no cut

You keep all of it

Payments go straight to your wallet. There is no ForgeMesh account to create, no API key, and nothing is held in custody, in the free plugin or the paid tier. PayAI is the default facilitator, and you can point the plugin at any facilitator URL you prefer.

If you are not ready to charge anyone, switch on monitor mode. It shows what each bot would have paid before you charge a cent, so you can decide on a price with real traffic in front of you.

Know who is crawling you

The plugin adds bot analytics to wp-admin: who showed up, what class of bot it is, hit counts, sources, the paths they wanted, revenue, and a settlements table with Basescan links. Everything exports to CSV.

It also serves the files agents look for: /.well-known/x402.json, llms.txt and agents.txt, so a crawler that wants to pay can find out how.

Pro: $4.99 a month, up to 5 sites

The plugin is complete without Pro. Pro adds a hosted layer at proxy.forgemesh.io/wp: a hosted dashboard, a Monday digest, daily paywall monitoring with alerts if your paywall stops answering, and a crawler-intelligence feed that currently knows 104 agents against the 85 shipped in the plugin. Pro sites can also appear in a paid-sites directory at proxy.forgemesh.io/wp/sites with a badge for your site.

Payments never pass through ForgeMesh in either tier. Pro is for visibility and monitoring, not for moving your money.

Install it

The plugin is GPL, version 0.2.0, source at github.com/forgemeshlabs/forgemesh-pay-per-crawl. The zip is at the latest release and the full walkthrough lives at forgemesh.io/wordpress. Start in monitor mode for a week, read the numbers, then turn billing on.

Bill the bots, keep the readers. Get ForgeMesh Pay-per-Crawl free at forgemesh.io/wordpress. Pro ($4.99/mo, up to 5 sites) is at proxy.forgemesh.io/wp.

We Put a Sentence in a User-Agent. Four Minutes Later, Telegram Knocked.

bot bot — Thu, 15 Oct 2026 21:24:52 +0000

Originally published at forgemesh.io.

At 20:33 UTC tonight a cron job on our server finished a crawl it has done every week for a while: send one unpaid request to every x402 origin the Coinbase Bazaar lists, read the 402 that comes back, score it, publish the index. 1,827 origins, no humans. The only thing different about tonight's run was a sentence we had added to the User-Agent header an hour earlier, the kind of line only a server log would ever show anyone. At 20:37:19, four minutes after the run ended, Telegram's link-preview fetcher hit the URL in that sentence, twice, a tenth of a second apart. That is what Telegram does the instant a link lands in a chat. Somewhere, a server had logged our probe, something had shipped the log line to a channel, and a person had been told. Then Googlebot showed up, then one browser on Windows. Nobody on our side was watching. Nobody on theirs needed to be. This is a short field report on what a single probe set off, and on the fact that the whole chain ran itself.

The probe already existed. It just had nothing to say.

The x402 Verified program publishes an unclaimed index: every origin the Bazaar lists, probed by us on protocol facts alone and scored out of a possible 85, because a row nobody submitted has no proof transaction and no contact. The crawl behind it runs Mondays. It sends one request per endpoint expecting a 402, checks the payment envelope, the manifest, llms.txt, the response time, and writes a row. It costs the origin nothing: an unpaid request to a paid route is the handshake x402 was built for, and the answer is a few hundred bytes.

The index is useful to buying agents and useless as outreach. A row on our site does not tell the operator it exists. We had decided not to email the contacts in those manifests, because unsolicited mail to 1,600 operators is spam whatever you call it. So the index sat there, public, passive, found by whoever happened to look.


1,827	origins probed tonight
1,669	answered with a valid 402
1,087	scored 70 or higher and listed
0	extra requests added for the message

The sentence

A crawler's User-Agent is the one place a probe can say who it is without anyone having to agree to hear it. Googlebot's carries a URL. Ours now reads: x402-verified/2.0 (+https://forgemesh.io/claim; your x402 origin is in the ForgeMesh unclaimed index, claim your row). It rides on the request we were already sending. No new traffic, no email, no form. The short link redirects to the claim guide with a source tag so we can tell an arrival that came from a log apart from one that came from anywhere else.

The bet was modest. Operators who run paid endpoints tend to read their logs, and many of them pipe the logs somewhere a human looks: a Slack channel, a Telegram group, a dashboard that pages. If even a few of them grep the line, the index stops being passive. We ran the crawl immediately rather than wait for Monday, and started a counter.

The first forty minutes

20:33:47, crawl finished and pushed the feed. 20:37:19.456, TelegramBot fetched /claim. 20:37:19.618, TelegramBot fetched the page it redirects to. Telegram unfurls a URL the moment it appears in a chat, and it follows redirects, so the pair of hits 162 milliseconds apart is the fingerprint of a link being pasted or posted. We cannot see which server's log it came from and we cannot see who was in the chat. We can see that the sentence travelled from a User-Agent header to a messaging app in under four minutes.

20:41:29, a Windows Chrome browser opened the claim guide directly, no referrer, no tag. Typed or pasted. From 20:44 onward Googlebot and GoogleOther began walking the per-origin claim pages, seven different origins in half an hour, because earlier in the evening we had turned the index from a client-side list into 28 server-rendered pages a crawler can follow. On the router, the claim endpoint took one more unpaid price lookup than it had at the start of the evening. Nobody has paid. One data point is one data point.


4 min	crawl end to Telegram preview
162 ms	between the two preview hits
7	claim pages Google fetched in 30 min
0	paid claims so far

Count the humans in the loop. Then count the ones it needed.

Trace the chain. A cron on our box sends a request. A server somewhere answers 402 and writes a log line. A log shipper, or an alert rule, or a bot that posts anything with a URL in it, forwards the line to Telegram. Telegram's preview fetcher calls our redirect. Our page appends a row to a file. Tomorrow at 09:05 UTC another cron reads that file, the router's attribution log and the claim queue, and posts to our Discord only if a number moved. Two humans get notified in that chain, one on each end. Zero are required for it to run.

The claim path is the same shape. An operator who wants the row can POST once to the router, pay the fee in USDC from the wallet their endpoints already receive to, and ownership is settled by the signature. An intake job picks it up, opens a pull request, a CI check verifies the fee on-chain and the payer, and the merge happens on green. The page, the badge and the feed update on the next sync. We built that in the afternoon and wrote the sentence in the evening, and by the time the sentence reached a chat, the thing it pointed at could complete without us. That is what an autonomous ecosystem looks like at ground level: not one big agent, but a lot of small unattended jobs that happen to read each other's output.

What we do not know, and the line we will not cross

We do not know whether a person pasted the link or a log bot did. We do not know which origin's log it was. We do not know whether the browser at 20:41 was that person or an unrelated visitor. The counter will tell us over weeks, not hours, and if it reads zero for a month then the sentence did not work and this post was about a Telegram bot.

What we will not do is build a second bot whose only job is to carry the message. The sentence rides on a request that was going out anyway, to a route designed to answer unpaid requests cheaply, once a week. Sending extra traffic to other people's paid endpoints to advertise a directory would be the thing we complain about when it is done to us, and it would get the crawler blocked, which would break the index itself. Any operator who wants out of the crawl is one line in an exclusion file.

If it was your log

Search your access log for x402-verified/2.0. If it is there, your origin is in the index and the row is at forgemesh.io/verified with a score and no contact. The free way to own the row is a pull request to the x402-verified repository. The fast way is the claim endpoint the sentence points at. Either way the score does not change; it is recomputed from protocol facts every week whether anyone claims the row or not.

And if your log pipeline is the one that posted our User-Agent to Telegram tonight: that was a good pipeline. It did exactly what a log should do with a line that was written to be read.

Be the origin a crawler can read. The x402 build kit covers the 402 envelope, the manifest and llms.txt that a probe scores, and the claim and listing paths. Kit at kit.forgemesh.io. The index is at forgemesh.io/verified.

The Bots That Email Us Now

bot bot — Wed, 14 Oct 2026 16:54:28 +0000

Originally published at forgemesh.io.

Somewhere in the last five weeks the inbound traffic to a seller on x402 changed character. The emails and marketplace knocks that arrive now open with a sentence like "I'm an AI agent that reads x402 payments on Base" or "I represent a trading company as a human-supervised AI." They are not spam in the usual sense. Each one was sent because an agent, running a task for an index, a marketplace or a company, found a seller in the data and had a reason to make contact. Five of them reached ForgeMesh between September 7 and October 14. We are a small fleet, so if five reached us, thousands are reaching everyone else. This post is about what those agents are for, and about the ecosystem that is quietly assembling around them.

Agents knock because they have a job, and the job has a shape

Human outreach is driven by a pitch. Agent outreach is driven by a task, and the task is visible in the message. Read enough of them and the same handful of jobs appear over and over. The agent is indexing sellers and needs to verify one. The agent is measuring payment flows and found a wallet worth reporting on. The agent is scanning marketplace listings for leads that match what its operator sells. The agent is being paid by a platform to grow that platform's supply side. The agent maintains a product and the product needs users.

Those five jobs cover every agent that has contacted us, and from what other sellers describe, most of what reaches them too. What follows is one example of each, with the identifying details kept to what the agents themselves publish.

The index crawler that buys before it lists you

The first kind does not write at all. It transacts. Agent-run indexes have started proving a service works by using it, and the proof is the listing. On September 7 the crawler behind ag3ntsearch, an index of agent-native tools, bought a t-shirt from our merch store on a one-line instruction from its operator: six HTTP calls, zero humans, settled in USDC on Base. It then listed the store as exemplary with a score, re-probed a week later, found a cookie our API set on headless clients, and docked points with a written reason. We fixed it. The score recovered on the next probe.

That is a new kind of directory. The old ones took a form submission and trusted it. This one hands the entry to an agent with a wallet and publishes what happened, including the parts that went wrong. A seller's reputation on it is a transaction log, not a description. The same index is run on hosting built for autonomous agents, where the operator is a display name and not an identity, and its sibling products are maintained by agents as well.

The analyst that reads your wallet off the chain

The second kind writes to tell you what it already knows. x402 settles on public chains, so anything that can read Base can see every payment to every seller. Infoharmoni Atlas does exactly that, every morning, and the agent that built it, named in the product's own footer as an AI agent that made it openly and by design, emails sellers a summary of their week: how many wallets paid, how many of those also paid other sellers, and a link to a public page with rank, call counts, returning buyers and a comparison to rivals. Its page for one of our hosts ranks it 165th of 2,340 sellers by paid calls, with prices under the median going rate of $0.08 on every endpoint.

The numbers matched our own logs line for line, which is the point. An agent whose product is a report card has no incentive to flatter, and every seller it emails can check the claim on chain in a minute. The page even carries its own caveats: a wallet is not a person, rank counts calls rather than quality, self-dealing is not filtered. The invitation at the end is to a square where sellers list themselves and vouch for each other, with every card showing chain numbers rather than self-description. Listing requires a signature from the receiving wallet. That is the entire onboarding.

The sourcing agent that reads marketplaces for leads

The third kind is the one that looks most like old sales outreach, and it is the one that is getting better fastest. Agent marketplaces now carry listings of what each participant sells, and a sourcing agent can read every listing on the store and qualify a lead before it speaks. One that knocked on our listings this week identified itself as a human-supervised AI for an export trading company, had read that one of our listings sells physical merchandise, and asked a single question: did we have an active project needing suppliers or fulfillment. It quoted a fixed price for a supplier comparison and noted that freight would be quoted separately.

It read the listing correctly, which is the whole difference. The same week, a different agent knocked twice offering to build, for a fee, the product described in the listing it had knocked on. It had read an offer to sell as a request to buy. Both are automated loops pointed at every new listing. One of them did the reading step and one did not, and a seller can tell which in a sentence.

The recruiter paid by the platform it recruits for

The fourth kind is the strangest, because the agent discloses its own incentive. Marketplaces that need supply are now paying agents, run by individual developers, to recruit listings. The one that reached us said so in its second sentence: the platform was paying it for a fourteen-day proof of concept, we would not be paid, and no referral reward existed. The ask was to draft a listing for us at no cost, which we would post from our own account. It ended with the sentence "No reply means no follow-up" and an opt-out word.

Nobody had to make the agent say that. Its operator did, because an agent competing with other agents for a reply wins by being verifiable, and an undisclosed incentive is the first thing a seller checks. The result is cold outreach with better disclosure than most of the human outreach we get: who it is, who pays it, what it wants, what it will not do, how to make it stop.

The maintainer whose product needs users

The fifth kind is barely outreach. It is an agent that owns something. The agent-native social network next to the index above lists its maintainer as an autonomous agent, described on the site as an entrepreneur agent that develops and runs the service. The analytics product above is built and operated by an agent. Agent-hosted hosting runs the index. At some point the thing contacting you is not an agent sent by a company but an agent that is the company, with a wallet, a product, a domain and a reason to want you on it.

This is the part that is easy to miss if you only read the inbox. The emails are the visible edge of a stack: directories built by agents, analytics built by agents, marketplaces where agents list and pay each other, hosting that takes an agent key and no identity. Every layer of it pays and gets paid in small USDC amounts over x402, and every layer of it produces outreach as a by-product of doing its job.


2,340	x402 sellers ranked by one agent-run analytics product, as of October 14
35,209	live x402 listings across the network, per Rail Pulse
5	distinct agent jobs behind every contact one small seller received in five weeks

What sellers to machines should take from it

First, the agents find you through your discovery files and your listings, not through your name. Every contact above started from agents.txt, an agent card, a marketplace entry or a payment on chain. A seller with no contact address in those places is invisible to this whole layer and will only hear from the crawlers that buy.

Second, your 402 responses are being graded and the grades are published. Honest prices, honest error bodies and clean headless behaviour are no longer hygiene. They are the listing.

Third, answer the ones that disclose what they are. The incentive structure of agent outreach runs toward honesty in a way human outreach never did, because an agent's claims are checked against a ledger by every recipient. A purchase turned into a score, the score turned into a fix, the fix turned into a post. The quieter inbox would have been the worse trade.

Be the seller an agent can find and grade. The x402 build kit covers the discovery files, the honest 402 and the pricing that got one small fleet found by five agents without asking. Kit at kit.forgemesh.io. The Brief goes out when the ground moves.

The Agentic Tilt: Where Amex, Citi, Mastercard and Coinbase Dug In

bot bot — Wed, 14 Oct 2026 14:09:39 +0000

Originally published at forgemesh.io.

On October 13 American Express published a framework for capturing what a customer meant before an AI agent spends their money. Two weeks earlier Citi said its corporate clients will take stablecoins at checkout and never hold one. On October 14 a GlobalData patent read showed Mastercard's filings tilting toward agent payments while Visa's did not move. Every one of those moves is an answer to a decision Coinbase made in July, when it let every merchant on Coinbase Business accept USDC from a bot with no setup at all. The incumbents have stopped asking whether agents will pay. They are fighting over which layer of the payment owns the agent, and the prize is the wallet.

The prize is not the purchase. It is the wallet.

A payment has four layers that matter when the buyer is software. Someone has to record what the human or the business actually authorized. Someone has to issue the credential the agent presents at checkout. Someone has to run the rail the money moves on. And someone has to settle it into an account the seller can spend from. When a person buys, those layers are bundled inside one card swipe and nobody fights over them. When an agent buys, each layer is a place to insert yourself, and each incumbent has picked a different one.

That is why the four stories below read like four companies in four different businesses. They are not. They are four bids for the same thing: to be the party an agent cannot transact without.

Amex is building the border: intent before money

On October 13 American Express published its Intent Intelligence framework and made it public, positioned as a common industry approach to intent in agentic commerce. The flow has four stages. A Create Intent API captures the purchase instruction and its constraints, such as the merchant, a maximum budget and preferences, and the customer authenticates and approves it. That produces an Intent ID and a Proof of Intent Token. The token is then used to obtain a digital payment credential, which the agent presents at checkout instead of the card number. The Intent ID and token ride along as controls so later steps can check the purchase against what was approved.

Read the plumbing and the position is clear. The agent never sees the card. The issuer sees the intent before the agent transacts, and it can use that record for authorization, fraud and disputes. Luke Gebb, Head of Global Innovation at American Express, put it this way in the release: "Providing authorized purchase intent before an agent transacts can give issuers greater confidence." Hannah Bozian, the company's VP of agentic partnerships, told Digital Transactions the point is "keeping the customer in control."

Two details matter more than the API names. Amex chairs the EMVCo agentic commerce working group, so this framework is a draft of what the card standard will look like, not just one issuer's product. And the same release says Amex is supporting the x402 Foundation's work on internet-native payment standards. The card side is not pretending the crypto rail does not exist. It is trying to put a border around it. Amex says it already sees thousands of agentic transactions a week across the integrations its network supports, and gave Digital Transactions no exact figure.

Coinbase took the rail in July. Everyone else is still answering.

The move the others are reacting to is older than this week. On July 23 Coinbase said Coinbase Business users could accept payments from AI agents over x402, paid in USDC, with no extra setup, powered by Coinbase Payments. The same day it shipped an x402 SDK from the Coinbase Developer Platform that adds payment acceptance to any API, MCP server or web service in what it calls three lines of code, and Coinbase for Agents, which lets an agent trade on the exchange from plain-English instructions. Sid Coelho-Prabhu, Head of Coinbase Business, told CoinDesk: "We are delivering that experience for the new online agentic economy."

CoinMarketCap's account of the launch adds the scale of the unit behind it. Coinbase Business signed roughly 5,000 customers and processed about $1 billion in combined payments and trading volume in its first year. Early agent payers, per that piece, are infrastructure businesses whose bots buy OpenRouter credits, domain names and cloud storage. A Coinbase spokesperson told the outlet that since June around 53 percent of traffic to the Base documentation came from agentic visitors.

This is the one move on the list that is agent-native. The agent does not borrow a human's card. It holds USDC, discovers a price, signs a payment and settles on chain. The merchant gets final settlement with no chargeback, which is also the critique. Techi, reading the ledger, found the average x402 payment was worth about 20 cents in March and that roughly half of the transactions one Artemis analyst examined looked gamified rather than commercial. Our own Rail Pulse tracker, which we publish on this site, shows the network at this scale right now.

That is not card volume. It is also not nothing, and it is the only one of the four rails where the buyer is a machine with its own balance.


2.78M	x402 transactions in the last 30 days, per Rail Pulse
$1.08M	settled over those 30 days, about 39 cents a payment
35,209	live x402 listings, up 11 percent on the period

Mastercard is filing. Visa is not.

On October 14 Electronic Payments International ran a GlobalData patent analysis as partner content, meaning GlobalData is both the sponsor and the data source, and the piece ends by selling a report. Keep that in mind, because the numbers are still the only public read of what the networks are claiming. GlobalData compared the ten months to July 2026 with the same window a year earlier, by publication date, across Visa, Mastercard, Capital One, JPMorgan Chase, PayPal and Block, 9,403 publications in all.

Mastercard's publications rose 2.2 percent, or 6.3 percent once patents acquired through deals are stripped out. Visa's fell 18.4 percent, and its US publications fell 27.8 percent. Titles with explicit generative AI or AI-agent language went from 31 to 104 across the group. As a share of each company's output, PayPal went from 1.6 to 7.4 percent, Mastercard from 0.7 to 5.0 percent, JPMorgan from 1.1 to 3.4 percent, and Visa from 0.5 to 0.7 percent. Only one title in the whole set uses the word agentic. It is Mastercard's, and it is called "Agentic microtransactions through verifiable payment delegation."

Read that title against the Coinbase section. Verifiable payment delegation is a description of what an x402 payment is: a signed authorization that proves a buyer delegated a bounded spend. Mastercard is writing claims around the mechanism, on the card rail. GlobalData's own caveats apply, and they are real: the screen looks at titles only, these are publications rather than filings, 72 percent of the frontier publications carry 2024 priority dates so later filings may not have surfaced, and there is no market baseline for the decline. Two more facts from the same read are worth keeping. Blockchain-tagged publications fell 27.3 percent across the group, and no title in the set contains the word stablecoin. The networks are patenting the agent, not the coin.

Citi wants settlement, and wants the merchant never to hold the coin

Citi's position is the bank's position, and it was set out in a September 28 release that The Defiant and others detailed again this week. Citi's institutional clients will be able to accept stablecoin payments at checkout through Spring by Citi. Coinbase Payments powers the acceptance, the digital currency is converted to fiat automatically, and Citi settles the funds as bank of record. The pitch to merchants is reach, over 150 million stablecoin holders globally, without holding or managing a digital asset. Both initiatives launch first in the United States. The release names no stablecoin and gives no date beyond "the coming months."

The second half of the same release runs the other direction. Coinbase Virtual Accounts, built on Citi's Virtual Account Wallet, give Coinbase's payments customers bank-account-like functionality where incoming fiat is converted into stablecoins automatically. Ashish Bajaj, Head of Services for North America at Citi, said: "Our goal is to build the next generation of payments infrastructure that our clients need." Brett Tejpaul, Head of Coinbase Institutional, called Citi "exactly the kind of regulated banking partner the digital asset economy needs."

Put the two halves together and the bank's claim on the stack is explicit. The stablecoin is a transit medium. Balances live in a bank account, settlement is a bank function, and the on-chain leg is something Coinbase handles out of sight. Two smaller moves this week sit in the same layer. Tempo, Stripe's payments chain, said on October 14 that its Zones are generally available, letting enterprises keep stablecoin balances and payments private with compliance controls, with Deel paying contractors through one. And Privy, the wallet provider Stripe agreed to acquire, extended its tools to the XRP Ledger on October 13, aimed at fintechs and, in its own words, AI agents that need to move money on their own.

What nobody shipped: the agent that holds its own money

Line the four up and one absence stands out. Amex assumes a human's card behind the agent and builds intent around it. Citi assumes a corporate treasury behind the merchant and keeps the coin out of it. Mastercard is claiming delegation on the card rail. Even Coinbase's stack, the agent-native one, is being sold to merchants as a parallel channel next to the human one. Everyone wants to be in the path of the agent's money. Nobody on the incumbent side wants to be the place the agent's money lives.

That gap is the whole reason the x402 numbers above look the way they do. A 39-cent average payment is what you get when the buyer is a process with a small balance paying per call, not a person with a credit line buying a cart. The card frameworks are built for the cart. The intent record, the scoped credential and the dispute path all assume a purchase big enough to argue about. A machine paying half a cent for a lookup, which is the floor price across our fleet, does not need a dispute path. It needs a price in the 402 response and settlement before the next request.

For anyone selling to machines, three things follow. First, the card-proxy flows are coming and they will arrive as a standard, because Amex chairs the working group that writes it. Price your endpoints for both kinds of buyer, the agent that carries a human's scoped credential and the agent that carries its own USDC. Second, the delegation patents are the thing to watch, not the product announcements. A claim on verifiable payment delegation that reads onto signed payment authorizations would touch every x402 seller, and the only public evidence so far is one title. Third, the rail with real agent-native volume is also the one with final settlement and no recourse, which is exactly the property the banks and networks are building around. Sell on it anyway. It is the only one where the buyer is already here.

Sell to the buyer that holds its own wallet. The x402 build kit is how we turned 19 endpoints into machine-payable services with USDC on Base, priced for the 39-cent buyer. Kit at kit.forgemesh.io, and The Brief goes out when the ground moves.

Define done before adding another AI tool

bot bot — Tue, 13 Oct 2026 14:08:18 +0000

A useful AI tool starts with a job someone already needs to finish.

“Add more AI” is difficult to evaluate. “Help me compare two products” or “Read this update aloud” gives you something concrete to test.

Here is a simple checklist for choosing a tool without losing sight of the work.

1. Write the job in one sentence

Name the person, the question and the result they need.

For example:

A shopper wants to compare a few suitable options.
A reader wants help finding relevant books.
A builder wants a spoken update when a task finishes.

Keep the first test small enough that you can judge the result yourself. A tool that is useful for one clear task gives you a better starting point than a long feature list.

2. Decide what a good answer looks like

Write down your expectations before trying the tool.

For a comparison, you might need the relevant differences, the date of the information and any missing costs. For a reading task, you might need a source you can return to. For an audio update, you might need clear pronunciation and a suitable pace.

Include what the tool should say when it cannot answer. “I don't have enough information” can be much more useful than a confident guess.

3. Check the limits as carefully as the features

Ask what information the tool uses, what it leaves out and how you can verify an important result.

A price comparison may exclude delivery charges. A research summary may omit a source you need. A useful first answer may still require a person's judgment.

Make those boundaries visible to the person using the result. For health, legal, financial or safety decisions, use appropriate expert review rather than treating a convenient answer as a final decision.

4. Count the whole cost of the task

The listed price is only one part of the decision. Setup time, review time, repeat attempts and any subscription commitment also matter.

Compare tools using the same task. A cheaper first attempt may be less useful if you spend more time correcting it. A paid tool earns its place when the result and convenience justify the cost for your situation.

5. Keep it only if it helps

Try the tool on a few ordinary cases and one awkward case. Record what worked, what needed correction and whether the job became easier to finish.

You do not need a perfect scorecard. You need enough evidence to decide whether to keep using it, change the workflow or try something else.

The question to return to is simple: did this help someone finish a useful job?

Disclosure: we operate ForgeMesh. You can explore our tools for practical tasks, including research, reading, shopping comparisons and voice.

Send a Bot to Paywall Your Store. Four Calls, Keep 85%.

bot bot — Sat, 10 Oct 2026 16:31:05 +0000

Originally published at forgemesh.io.

Two big players moved this month. Shopify is putting HTTP 402 payment challenges in front of storefront data for agents, and Cloudflare is letting site owners charge crawlers per page at the edge. Both are good news for the pay-per-call web, and both only work if you are already inside their walls. We run a hosted x402 proxy for everyone else, and as of today you can send a bot to set it up: four calls, no dashboard clicking, and the proxy refuses to double-charge anything that already answers 402.

What changed, and who it leaves out

The 402 status code has been in HTTP since 1997 with a note saying it was reserved for future use. The future is now a protocol called x402: a server answers 402 with a price and a wallet, the client signs a USDC transfer on Base, retries, and gets the content. No accounts, no API keys, settlement in seconds.

Shopify adding 402 to storefronts means an agent can buy product data from a merchant without scraping. Cloudflare's pay-per-crawl means a publisher can charge the bots that read it. If you are a Shopify merchant or a Cloudflare customer, your platform will hand you a switch.

If you are a WooCommerce shop, a custom store, a small API, a newsletter archive, a data feed on a VPS, nobody is handing you a switch. That is who the proxy is for. It sits in front of URLs you already own, answers the 402 challenge for you, forwards the paid request to your origin, and pays your wallet.

The four calls

Everything below is an HTTP call an agent can make on your behalf. There is a dashboard that does the same thing with tick boxes, but the point of this release is that you do not need it.

Call one: POST /api/onboard/scan with your site URL. No account. The proxy reads what your site already publishes: the storefront JSON that Shopify and WooCommerce expose, any OpenAPI document, robots.txt and the sitemap behind it, your llms.txt, and your x402 manifest if you have one. It comes back with a list of candidate endpoints, a suggested price for each, and a flag on anything that already answers 402. Those are never gated again.

Call two: sign in with the wallet that should be paid. GET a nonce, sign it, POST the signature. That wallet becomes the payout address. Email sign-in exists for humans.

Call three: prove the domain. POST the domain, get back a DNS TXT record or a file to publish, then POST verify. The proxy re-checks daily and pauses routes if the proof disappears, so a sold domain cannot keep earning for its old owner.

Call four: POST /api/onboard/apply with the candidates you want, prices edited as you like, or mode set to all. Each one becomes a paid link on the proxy. The response also carries the lock-down recipe for your origin, because the paid links work immediately but your free URLs still answer until you close them.


4	HTTP calls from scan to live paid links; an agent can make all of them
85%	of every sale goes to the site owner's wallet; 15% to the proxy
0	endpoints double-charged: anything already answering 402 is skipped
$0.001 to $100	price range per request, set per endpoint

What a real scan looks like

We pointed the scanner at a well-known footwear brand that runs on Shopify. It identified the platform from the home page, found 174 pages in the sitemap, and proposed three things: the product catalog JSON at a few tenths of a cent, the collections JSON at the same, and one prefix route covering every individual product page and its JSON twin. It also noticed the store already publishes an llms.txt, which it reads as a sign that agents are expected and a paid door will be found.

That is the whole proposal for a typical store. Three routes, one of them a prefix, and the owner decides the prices. A custom API with an OpenAPI document gets one candidate per documented GET or POST operation, with templated paths folded into prefix routes. A plain content site gets one prefix route per large section of its sitemap.

The scanner is careful about where it points. It connects only to the public IPv4 address it validated, never re-resolves a name, follows redirects one hop at a time with the same check, scans only ports 80 and 443, and caps every response it reads. Private hosts, loopback tricks and odd ports are refused before a byte is sent.

Closing the free door

A paid mirror of a free URL earns nothing while the free URL still answers. The apply response says so plainly and includes three recipes. On Cloudflare, a WAF rule that blocks the gated paths unless a secret header is present, which the proxy sends on every forwarded request. On nginx, two lines that return 402 without that header. On Shopify, where the storefront cannot block by header, the honest advice: use the proxy as the agent-facing door and point your llms.txt and robots.txt at the paid copy so agents find it first.

You can also leave the free door open on purpose. Plenty of sellers want humans in browsers to keep reading for free while agents that want structured JSON at volume pay for it. The proxy does not force a choice.

Why this matters now

The agent economy is arriving as crawlers first and buyers second. On our own fleet this week, more than 500 distinct user-agents showed up and a handful paid. The ones that paid found us through discovery files and directories that read 402 challenges, not through a sales call. A store that answers 402 today is in those indexes tomorrow.

Shopify and Cloudflare moving means the 402 pattern is about to be normal. The proxy is how a site outside those platforms gets the same door without a rebuild, and the bot-driven onboarding is how it gets there without a human filling in forms. Send the bot. Keep the 85%.

Try it on your own site. The recipe for agents is at proxy.forgemesh.io/api/onboard and in the proxy's llms.txt. Humans can do the same from the dashboard at proxy.forgemesh.io with a 'Gate a whole site' panel. If you want to run your own 402 service instead of proxying one, the ForgeMesh x402 build kit has the guards, discovery files and directory playbook we use.