DEV Community: Egor

llms-pay.md: a discovery layer for AI shopping agents

Egor — Mon, 13 Jul 2026 07:09:19 +0000

TL;DR. AI shopping agents can read your marketing page just fine. What they cannot do is buy. There is no standard way for an agent to discover your products, pick a plan, and hit the right checkout endpoint. We shipped a two-file discovery layer, live at agentfix.pro/llms-pay.md and agentfix.pro/.well-known/agent-checkout.json. Draft spec v0.1, open for critique.

The problem: agents can read, agents cannot buy
Why llms.txt was the right template
The spec in 90 seconds: llms-pay.md + agent-checkout.json
Discovery flow, step by step
Why two files, not one
What is deliberately out of scope for v0.1
See it live and what we want feedback on
Key takeaways

1. The problem: agents can read, agents cannot buy

Put an autonomous agent in front of your pricing page. It parses the copy. It renders the marketing DOM. It probably understands your tiers. Then it stops.

Because it does not know:

Which endpoint to POST to
What body shape you expect
Whether there is a pre-check step (a scan, a quote, an eligibility call)
How to test the flow without a real card
What terminal status means "the pack is ready, go download"

Human buyers solve this with visual clicks. Agents cannot click their way through a Stripe modal without the seller building a first-class programmatic checkout. And most sellers have not.

Result: your site is agent-readable but not agent-buyable. That gap is a real revenue leak once shopping agents ship at scale, which is happening this year.

2. Why llms.txt was the right template

You have probably seen llms.txt. It is a small Markdown file at the root of a site that tells language models what matters, in one canonical place. Cheap to write, cheap to parse, no server changes, immediate value for retrieval.

The pattern is worth copying:

Human-readable Markdown at a predictable path
Discoverable without a crawl
Companion machine-readable JSON for the parts that need strict types

llms-pay.md follows the same shape, aimed at commerce instead of retrieval. It is not competing with llms.txt. It sits next to it.

3. The spec in 90 seconds

Two files. Same site.

File one: /llms-pay.md - human-friendly Markdown that explains what you sell, how to purchase programmatically, how to test, which providers you support, and how to reach a human. An agent reads this to build a mental model.

File two: /.well-known/agent-checkout.json - strict JSON with the exact endpoint shapes, body schemas, prereq steps, terminal statuses, and provider metadata. An agent reads this to execute.

Every field in the JSON has one job: remove ambiguity. checkout_flow.method is "POST". body_schema names the fields. fulfillment.poll_endpoint says where to poll. fulfillment.terminal_status says what to wait for. test_mode.supported: true says you can smoke-test the whole flow without a card.

Here is a trimmed slice of the live schema so you can see the shape:

{
  "$schema": "https://agentfix.pro/schemas/agent-checkout-v0.json",
  "version": "0.1",
  "products": [
    {
      "id": "agent_ready_pack_basic",
      "price": { "amount": 29, "currency": "USD", "recurrence": "one_time" },
      "checkout_flow": {
        "method": "POST",
        "endpoint": "https://agentfix.pro/api/checkout",
        "prereq": {
          "step": "scan",
          "endpoint": "https://agentfix.pro/api/scan",
          "returns": "scan_id"
        },
        "body_schema": { "scan_id": "string", "email": "string" }
      },
      "fulfillment": {
        "poll_endpoint": "https://agentfix.pro/api/orders/by-scan",
        "terminal_status": "delivered"
      }
    }
  ]
}

Full file: agent-checkout.json. Draft schema: agent-checkout-v0.json.

4. Discovery flow, step by step

From cold visit to delivered artifact:

Agent lands on example.com. Fetches /llms-pay.md. Reads the human summary.
Fetches /.well-known/agent-checkout.json. Picks the product by id or name.
Runs the prereq step (in our case, POST /api/scan with the target URL).
Polls the scan until it is done, extracts scan_id.
POST /api/checkout with scan_id and buyer email. Receives checkout_url.
Directs the buyer to checkout_url. Provider handles card auth, 3DS, receipt.
Polls fulfillment.poll_endpoint until terminal_status: "delivered".
Downloads the artifact from the signed URL in the response.

The whole flow is idempotent on the client side. Every step is a standard REST call with a documented body.

5. Why two files, not one

Because they answer different questions.

The Markdown answers "what and why". It handles nuance: refund policy, sandbox instructions, which providers are primary vs fallback, what is not supported yet. Humans read it too, so it is written in prose.
The JSON answers "how". It has to be machine-strict. No prose. No maybe. Every URL is a full URL, every schema is named.

You could stuff both into one YAML with a human_notes field, but then agents have to parse prose for edge cases and humans have to read schemas for policy. Splitting them keeps each file good at its job.

6. What is deliberately out of scope for v0.1

Being an open draft, we cut ruthlessly:

No crypto rails. No x402, no L402, no on-chain settlement. Cards only. If enough teams need x402, v0.2 adds it.
No auth beyond email. No OAuth handshake for the buyer. The provider handles PCI. We hand the agent a checkout_url and step aside.
No bulk cart. One product, one checkout. Bulk purchase agents are not the 2026 shape.
No delivery negotiation. Terminal status is boolean-ish: delivered or pending. No fractional progress states.

The point of v0.1 is "does the shape work end to end for a real product". Anything that is not necessary to test the discovery pattern is deferred.

7. See it live and what we want feedback on

Live: agentfix.pro/llms-pay.md and /.well-known/agent-checkout.json.

Please break it. Specifically:

Are field names ergonomic? prereq vs precondition vs pre_step - which reads best to an agent?
Is terminal_status a good name for "when to stop polling"?
Should the schema live at /.well-known/agent-checkout.json or at a versioned path like /.well-known/agent-checkout-v0.json?
Do you want a provider.priority field so agents can pick a preferred rail (e.g. "prefer FastSpring for EU VAT")?
What is missing for your product's flow?

Open an issue, DM me, or comment on the canonical post. Draft status is "v0.1-community-comment", which is the polite way of saying "everything is negotiable".

8. Key takeaways

AI shopping agents will read your site. They cannot buy from it without a spec.
A tiny two-file discovery layer (llms-pay.md + agent-checkout.json) is enough to close the gap for card-based checkout.
Draft v0.1 is live at agentfix.pro. Copy the pattern, adapt the shape, tell us what breaks.
If we get to shared field names across a handful of sellers, agents start to converge. That is how llms.txt worked and how this can too.

Try the scanner. If you want to see how agent-ready your own site is (before we get to checkout), scan it free at agentfix.pro. No signup, no email required. The full 34-signal checklist is documented at /methodology.

We ran an AI-agent-readiness scan on 19 AI-native brands. Here is what breaks.

Egor — Mon, 06 Jul 2026 16:22:33 +0000

If any group of companies should have their site ready for AI agents in 2026, it is the ones building AI. So we ran a real scan on 19 of them: Anthropic, OpenAI, Perplexity, Cloudflare, GitHub, Stripe, Vercel, Shopify, Notion, Figma, Linear, Cursor, Supabase, Pinecone, Hugging Face, LangChain, Mistral, Cohere, Groq.

Result: 0 A grades. 1 B. 7 C. 10 D. 1 F. Average pass rate 54.5% across 34 signals.

That is not "the internet is behind". That is the vendors whose own agents crawl your site failing their own homework. If you build the web today, this benchmark is a cheat sheet for what to fix first.

What we actually checked

Our public scanner runs 34 signals grouped in six buckets:

discoverability: robots.txt, sitemap.xml, /.well-known/, llms.txt, syndication feed
ai_policy: explicit rules for GPTBot, ClaudeBot, PerplexityBot, Google-Extended, content-signal declarations
schema: JSON-LD for Organization, WebSite, FAQPage, BreadcrumbList
agent_protocols: MCP server card, A2A agent card, agent-skills index
content: image alt coverage, markdown content negotiation, heading structure
browser_ux: tap-target size, aria labels (agents also crawl accessibility signals)

Every check is a real HTTP request from our infra, not a lint pass on your assumed setup. So agentfix.pro/scan returns "you claim GPTBot rules but the file 404s".

The three signals every AI-native brand failed

1. FAQPage / BreadcrumbList JSON-LD (19/19 miss)

Not a single site had FAQPage or BreadcrumbList schema on the homepage or a common product page. These two schema types are how ChatGPT, Google's AI Overviews and Perplexity build inline answer cards. Without them your content still gets read, but you rarely become the highlighted source. Cost to add: two <script type="application/ld+json"> tags.

2. MCP server card at /.well-known/mcp.json (19/19 miss)

The Model Context Protocol is Anthropic's own standard. The discovery convention is a card at /.well-known/mcp.json describing your MCP server, transport, tools. Anthropic's own site does not publish one. Neither does OpenAI's, or Perplexity's. If your product exposes any programmatic surface (search, docs API, product catalog) this is a two-file win: card + server.

3. Tap-target size (17/17 checked, all fail)

Agents that render pages penalize dense clickable regions. Mobile-first CSS with 44x44px minimum touch targets is a decade-old accessibility rule that also serves modern agent renderers. Fix in your button component once.

Named findings (the fun part)

Cloudflare (B, 71%) was the only B on the list. They actually publish /llms-full.txt and declare bot rules. Given they sell an AI-agent-readiness product themselves, this is at least self-consistent.
Perplexity (F, 29%) was the worst. Not a single AI-policy declaration, no llms.txt, no schema markup on the homepage. The company literally sells "answers powered by web crawl" and their own site is opaque to crawlers.
Anthropic (D, 53%) publishes MCP as a standard but does not publish an MCP card of their own.
GitHub (D, 47%) has no llms.txt, no MCP card, no A2A card. GitHub's search index is what half of every LLM eats and they still ship 47%.
Stripe (C, 56%) and Vercel (C, 65%) were solid on schema but weak on agent protocols.
Supabase (C, 68%) was the second-best, mostly for good sitemap + strong schema coverage.

Full per-site grades and raw JSON: see the sibling deep-dive at agentfix.pro/blog/we-scanned-10-ai-forward-sites-in-2026.

Copy-paste minimum viable fix

If your site is D or below (statistically likely), start with these three files. Two hours of work moves most sites two grades.

/llms.txt (Answer.AI convention, becoming de-facto index for LLM crawlers):

# YourProduct

> One-line description an agent should quote.

## Docs
- [Getting started](https://your.site/docs/quickstart)
- [API reference](https://your.site/docs/api)

## Product
- [Pricing](https://your.site/pricing)
- [Changelog](https://your.site/changelog)

/.well-known/mcp.json (minimal, declares you have an MCP surface):

{
  "schemaVersion": "2025-03-26",
  "name": "Your Product",
  "description": "What agents can do here.",
  "server": {
    "url": "https://your.site/api/mcp",
    "transport": "streamable-http"
  },
  "auth": { "type": "none" },
  "capabilities": { "tools": true }
}

Homepage FAQPage JSON-LD (biggest AI-overview lever per hour of effort):

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What does YourProduct do?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "One-sentence answer."
      }
    }
  ]
}
</script>

Then re-scan and watch the grade jump.

Why publish this

Two reasons. First, we run the scanner as a product and this is our transparency: you can hit agentfix.pro/scan right now and reproduce every number. Second, we plan to re-run the same 19 sites on 2026-10-05 and diff the results. If Cloudflare adds an MCP card, if OpenAI adds A2A, we will show that in an addendum. Snapshot-benchmarks are the closest thing agent-web has to a scoreboard.

If your site is on the list and something looks wrong, please DM: we ran a raw scan on production, no allow-list, and if a signal misfired we want to fix the scanner not defend the number.

If you want the raw JSON of all 19 scans, or the per-signal breakdown, the on-blog deep-dive has both.

What we track next

Agent-skills index (95% fail): a per-skill card that lets agents pick a capability without loading your whole docs site. Emerging spec, but the direction is clear.
Markdown content negotiation (84% fail): serving text/markdown on Accept: text/markdown requests. Cheap on a Next.js/Astro backend, invisible to human users.
Content-signal declarations (84% fail): the emerging "training-yes/training-no/quote-yes" trio that lets you say what you consent to.

We will benchmark all three in the October re-run.

This post was written by the team behind AgentFix, an AI-agent-readiness scanner and one-time fix packs for WordPress, Webflow, Shopify, Tilda. Free scan at agentfix.pro.

llms.txt in 2026: how to write one that actually scores

Egor — Sun, 05 Jul 2026 02:15:22 +0000

Every scanner in the AI-readiness space checks for llms.txt. Half the sites that fail the check fail it by having the wrong file, not a missing one. A 200 OK response with an llms.txt full of hand-waving does not help an agent, and it does not fool the scoring either. This is what I have learned actually shipping and testing these files across WordPress, Webflow, Shopify, and static sites.

What llms.txt actually is

The spec lives at llmstxt.org. Short version: a markdown file at your site root that gives an LLM a map of your site written for the LLM, not for humans. Not a legal agreement (that is closer to robots.txt plus agents.txt). Not a training-data opt-out. It is a discovery and disambiguation aid, the way a hand-drawn map is easier for a stranger than a satellite photo.

Two files are worth knowing:

llms.txt at the root: index. Short, hand-curated links to canonical pages.
llms-full.txt at the root: expanded. Concatenated content of the pages you want the LLM to actually ingest.

Most sites need only the first. Docs-heavy sites benefit from both.

The anatomy of a file that scores

The spec allows more than what agents actually seem to use. In practice, the sections that matter are the ones a scanner or a well-behaved agent can parse deterministically.

# Site Name

> One sentence describing what this site is and who it is for.

Optional short paragraph, up to a few sentences. This is the freeform block.
Keep it factual. Agents will summarize it verbatim.

## Docs

- [Getting started](https://example.com/docs/start): the fastest path from zero to a running install.
- [API reference](https://example.com/docs/api): every endpoint, request and response schemas.

## Products

- [Basic pack](https://example.com/pricing/basic): one-time $29, covers X, Y, Z.

## Optional

- [Changelog](https://example.com/changelog)
- [Blog](https://example.com/blog)

A few things this example gets right that most sites get wrong.

The H1 is the site name, not the file title. A lot of generators produce # llms.txt for Example.com. That is noise. The H1 is what the LLM will most likely use to name your site when it summarizes.

The blockquote is the one-liner. Not marketing copy. A single sentence that a person could actually read out loud. If an agent has to pick one line to describe your site, this is the line it picks.

Links are absolute. Relative links break for anyone consuming the file outside its origin, which is the entire point (the file exists to be pulled and processed elsewhere).

Each link has a colon-separated description. Agents need to know why to follow a link. - [Getting started](https://example.com/docs/start) alone is uninformative. Descriptions after the colon give the agent enough context to rank links before fetching them.

Sections are semantic, not aesthetic. ## Docs, ## Products, ## API, ## Optional. Avoid decorative headings like ## Everything you need to know. The scanner splits on ##, and the H2 is metadata.

What breaks it in practice

Six mistakes I keep seeing when I scan sites for a living:

JavaScript-rendered llms.txt. A Next.js or Nuxt route that serves llms.txt from an API handler with the wrong Content-Type. Agents fetch with a minimal HTTP client, no JS. Serve the file statically, text/plain; charset=utf-8. If your framework prevents that, put it in /public or the CDN.
CDN caching stale versions. You updated the file two hours ago, the scanner still sees yesterday. Purge after every edit. Cloudflare users can hit POST /zones/:id/purge_cache with { "purge_everything": true } or purge by URL.
robots.txt disagreement. llms.txt says "here is my content, come look," robots.txt blocks GPTBot or ClaudeBot. Agents that respect robots will not read your llms.txt. Decide once: either you want AI traffic and you allow the crawlers, or you do not. Do not send both signals at once.
llms-full.txt bigger than 1 MB and served gzipped only. Some agents pull the file with clients that do not accept-encoding. Serve identity-encoded too, keep total size under a few MB, and split into per-topic files if you must go bigger.
No canonical URL match. Links in llms.txt should match the URLs the LLM will actually fetch. If your llms.txt links to example.com/docs but the docs live on docs.example.com, agents get a redirect and lose context. Match canonicals to what the rest of your site declares.
Marketing copy where facts should be. "Best-in-class AI-powered platform for modern teams" is worse than useless in an llms.txt. An LLM ingesting this will either quote it (bad) or ignore it (worse, because now you have no summary). Write plainly. What does the site do, who is it for, what does it cost.

How to test that agents actually read it

You can spend an afternoon guessing, or you can check.

Static check. curl -sSI https://yoursite.com/llms.txt and verify: 200, Content-Type: text/plain, Content-Length non-trivial, Last-Modified recent. Then curl -s https://yoursite.com/llms.txt | head -60 and eyeball it.

Agent check. Ask a real agent. Open Claude, ChatGPT with browsing, or Perplexity. Prompt: "Fetch https://yoursite.com/llms.txt and summarize what this site is, in one sentence, based only on that file." If the answer is close to what you wrote in the blockquote, you are good. If the answer is generic or wrong, your file is not doing its job.

Scanner check. Cloudflare's URL Scanner at radar.cloudflare.com/scan surfaces an Agent Readiness Score that partly hinges on llms.txt. AgentGrade at agentgrade.com is fully free and gives a letter grade with sub-scores. My own tool at agentfix.pro runs 33 signals and shows per-signal pass/fail, which is what I built when I got tired of scores that did not tell me what to fix.

Where the industry is heading

Two things are worth watching in the next six months.

agents.txt is stabilizing. It complements llms.txt by expressing permission and terms, closer to robots.txt in spirit but with structured fields for pricing, rate limits, and preferred contact for commercial use. Expect scanners to add it as a signal soon.

MCP endpoints alongside llms.txt. Some sites already advertise a mcp link inside llms.txt pointing at a Model Context Protocol server. That is the practical bridge from "an agent can read your site" to "an agent can do things on your site." If you sell anything, this is where the real leverage lives.

Closing thought

A llms.txt file takes twenty minutes to write and five minutes to serve. Getting it right is worth those twenty-five minutes for anyone whose site an agent might visit, which by 2026 is roughly every site. The interesting question is not whether to write one, but whether the one you have already written is doing what you think it is.

If you want a second opinion on your own file, the tools above will tell you. If you want the fix as a file you can drop in, that is what I have been building for WordPress, Webflow, Shopify, and Tilda at agentfix.pro. Either way, do not trust a scanner score without reading your own llms.txt as if you were the agent.

Cross-posted from agentfix.pro.

AI agents crawl your site now. Here's what they look for (and why fixing it is fragmented)

Egor — Sun, 05 Jul 2026 00:25:18 +0000

AI agents are crawling the web at a rate the SEO playbook never planned for. GPTBot, PerplexityBot, ClaudeBot, and a growing zoo of MCP-driven agents hit sites daily, and most sites give them a 200 OK page full of divs, JavaScript, and no machine-readable intent. Search bots did fine with that. Agents do not.

I have been building a tool in this space for a few months and reading every scanner and spec I can find. Here is the short, honest version of what agent-readiness actually means in 2026, why it is worth caring about, and where the real work is.

The signals that agents look for

There is no single spec. There is a stack of overlapping conventions, and different scanners weight them differently. The ones that matter today:

llms.txt (llmstxt.org). A markdown index at your site root that tells an LLM what your site is about and which URLs are canonical. Roughly the robots.txt of the agent era, except it exists for the LLM's benefit, not yours.
agents.txt. A newer convention that describes which agents you welcome and under what terms. Less standardized than llms.txt, more of a signal than a rule.
MCP (Model Context Protocol). A protocol for exposing tools to agents. If your site sells anything, an MCP endpoint lets an agent buy without scraping a checkout form.
Structured data. Old-school schema.org JSON-LD, but with fresh weight. Agents parse it before they parse your prose. Missing Product, Offer, FAQPage, or Organization is a quiet way to be invisible.
Payment protocols. x402, L402, MPP. Emerging standards for machine-payable resources. Not table-stakes yet, but scanners already grade for them.
Server signals. Reachable canonical URL, no JS-only content, sensible robots.txt, working sitemap, valid TLS, correct Content-Type. Boring but decisive.

You can go check any of this on your own site right now. Cloudflare has a free URL scanner that includes an Agent Readiness Score. AgentGrade at agentgrade.com is fully free and covers protocol coverage in more depth. Agent Checker runs a full audit (paid tier around £19) that actually drives a browser as an agent would.

What the scanners will not tell you

The scanners are useful. They give you a score, a list of failed checks, and a screenshot of the problem. What they do not do is fix anything.

That is the gap I kept walking into. A WordPress owner runs a scan, gets a 42/100, sees "missing llms.txt, missing JSON-LD Product schema, robots.txt blocks GPTBot," and closes the tab. Because the fix is not one file. It is:

editing wp-content/themes/<theme>/functions.php without breaking updates
installing a schema plugin, configuring it, dealing with conflicts
writing an llms.txt that matches your actual sitemap
adjusting robots.txt served by a plugin, not the filesystem

Multiply that by Webflow (custom code injection, different constraints), Shopify (Liquid, theme layer), and Tilda (built-in SEO tab, closed platform), and the fix surface is very different per CMS. That is why the scanners stop at "here is your score." Actually fixing it is either a $200/hour consulting problem or a weekend of docs-diving.

A minimal checklist per platform

If you are doing this by hand, here is where I would start, per CMS. Nothing exotic, just the highest-leverage moves.

WordPress.

Serve a static llms.txt at the root (Yoast can do it, or drop it in the theme root and route via functions.php).
Install a schema plugin (Rank Math, WP SEO Structured Data) and enable at least Organization, WebSite, and Product (if you sell).
Audit robots.txt: many SEO plugins silently block GPTBot. If you want AI traffic, allow it.
If you sell, add Offer schema per product. Agents cannot buy from an unlabelled div.

Webflow.

Custom Code -> Head Code: paste JSON-LD for Organization and WebSite.
Publish a static llms.txt (Assets or Netlify redirect if you host outside Webflow hosting).
In Project Settings -> SEO, verify robots.txt allows agent user agents.
For CMS collections (e.g. products), inject per-item schema via the collection page's embed component.

Shopify.

Use a theme that supports application/ld+json blocks in theme.liquid.
Add Product schema per product page. Most modern themes do this, but many custom ones do not.
Serve llms.txt via a page template or app (the storefront root does not accept arbitrary files by default).
Consider a Merchant schema for organization identity.

Tilda.

Use the built-in SEO tab per page, but add JSON-LD via the T123 (HTML) block.
Tilda does not let you drop a file at root easily. You can host llms.txt on a subdomain and reference it, or use a redirect on your DNS provider.

None of this is glamorous. All of it moves the score.

What I would want as a site owner

Honestly, a scan by itself is not that useful. If I already know I have a problem, I want a package I can drop in. This is the direction I took with AgentFix: scan for free, and if you want the fix, buy a per-platform pack ($1 to $99) with the exact files, the exact snippets, and the exact settings changes for your CMS. No consulting, no plugin bloat, no weekend of research.

That is not a pitch, it is the answer to "why does this exist." Nothing about that model is proprietary. If you want to build the same thing for a niche I do not cover, the ingredients are all public: the scanner logic is 33 signals with known rules, and the packs are just Git-managed CMS-specific bundles. The moat is remediation, not diagnosis.

Takeaways

Agent-readiness is a real, measurable thing in 2026. Free tools will grade you today.
The signals are stackable but fragmented. llms.txt + JSON-LD + MCP + payment protocols, ranked in that priority for most sites.
The scanners tell you the "what." The "how to fix" is CMS-specific and, right now, mostly manual.
If you own a site and want AI-agent traffic, put 30 minutes into a scan and a checklist before you spend anything on it.

If you found this useful, and want a shortcut for the fix step, that is what agentfix.pro is for. Otherwise the checklists above are a solid start.

Canonical: agentfix.pro

Most sites speak llms.txt now. Almost none speak x402.

Egor — Sun, 28 Jun 2026 15:17:28 +0000

A friend in the agent-infra space (DDG Agent Services, 16k followers, they build this for a living) replied to one of my posts this week with a take that landed hard:

right that discovery moved to machine-readable files. but llms.txt only makes you findable — it doesn't make endpoints callable or payable. next layer is a per-tool contract (identity, price, cap, receipt) so 'found' becomes 'callable with authority.' discovery isn't execution.

He's right. So we shipped Pack v3.

The gap

/llms.txt, schema.org JSON-LD, A2A agent-card, MCP server-card, /openapi.json — the read layer. AI agents know you exist, know what you offer, can read your docs.

What's missing from 99% of sites: the callable layer. When the agent decides to actually invoke your endpoint:

Identity: which service is this? Two of your endpoints can't accept the same receipt — that's the cross-service replay bug Daedalus keeps flagging.
Price: how much per call? In what currency? Fiat, USDC?
Cap: max per transaction? Per minute? Per day?
Receipt: how does the agent prove it paid, and how do you verify it?

x402 (HTTP 402 Payment Required, reborn) is the spec everyone is converging on. It's a discovery manifest + a challenge/response over HTTP.

What Pack v3 ships

Every $1 / $29 / $99 AgentFix Pack now includes:

/.well-known/x402.json — discovery manifest. Declares your service_id, accepted currencies (USD via Stripe/Creem + USDC on Base + Ethereum out of the box), priced paths, receipt format, spending caps.

{
  "protocol": { "name": "x402", "version": "0.1" },
  "service_id": "https://yoursite.com/",
  "accepted_currencies": [
    { "type": "fiat", "code": "USD", "settlement": "stripe_or_creem" },
    { "type": "crypto", "code": "USDC", "chain": "base", "contract": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" }
  ],
  "priced_paths": [
    { "path": "/api/v1/search", "method": "POST", "price": { "amount": "0.001", "currency": "USD" } }
  ],
  "caps": {
    "max_single_transaction": { "amount": "10.00", "currency": "USD" },
    "per_minute_request_cap": 60,
    "per_day_spend_cap": { "amount": "100.00", "currency": "USD" }
  }
}

/.well-known/acp.json + ucp — upgraded with a payment object pointing at the manifest, the receipts endpoint, and the service_id binding.

9-x402-payment-layer/cloudflare-worker-x402.js — drop-in Cloudflare Worker. Sits in front of your priced paths, returns HTTP 402 with the challenge metadata, verifies HMAC-signed receipts on retry (with anti-replay svc binding), forwards valid requests to origin.

async function verifyReceipt(receipt, env, expectedSvc) {
  const [bodyPart, sigPart] = receipt.split('.');
  const body = JSON.parse(atob(bodyPart.replace(/-/g, '+').replace(/_/g, '/')));
  if (body.svc !== expectedSvc) return false;                 // anti-replay
  if (Date.now() - body.iat * 1000 > 1000 * 60 * 10) return false; // 10 min TTL
  const key = await crypto.subtle.importKey('raw',
    new TextEncoder().encode(env.RECEIPT_HMAC_SECRET),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['verify']);
  return crypto.subtle.verify('HMAC', key, base64ToBytes(sigPart),
    new TextEncoder().encode(bodyPart));
}

Why additive matters

This is folder 9. The pack still installs 1, 2, 3 in the obvious order — llms.txt, schema, A2A, MCP, all the things that already work. Folder 9 is for buyers who expose paid APIs. Buyers who don't can delete it without breaking anything.

That's the brand decision: discovery is the first sale, callable-with-authority is the second. Most sites need the first. Some need both.

What the scanner now flags

agentfix-mini-scanner@latest yoursite.com already detects the manifest paths. The next OSS release (1.2.0) will validate the structure — service_id present, caps declared, receipt format spelled out.

If you're building agent-payable services and want to swap notes on the receipt format, ping @LLlkoJla on X or support@agentfix.pro. The spec is still wet and the more sites converge, the cheaper agents are to build.

Try it

npx agentfix-mini-scanner yoursite.com

OSS scanner: https://github.com/Virt92/agentfix-oss-scanner
Full Pack with x402 + receipts ($1 / $29 / $99 one-time): https://agentfix.pro
Iceberg viz: https://workspace.agentfix.pro

Building solo. Iterating in the open. Feedback shapes the next pack revision.

I built a free scanner that tells you how readable your site is to AI agents (96% fail)

Egor — Sat, 27 Jun 2026 23:14:08 +0000

Solo founder here. The "blue link" layer of search is being eaten by the answer layer — Google AI Overviews, ChatGPT browse, Claude artifacts, Perplexity citations. They rely on a set of signals most sites haven't shipped: llms.txt, schema.org JSON-LD, agent-card.json (A2A), MCP server-card, OpenAPI, bot-friendly robots.txt.

I scanned ~200 sites this month: 96% fail at least 6 of the 12 most basic signals. Most fail all 12.

Built and open-sourced a CLI scanner:

npx agentfix-mini-scanner yoursite.com

12 of 33 signals. MIT. Zero deps. Node 18+. ~5 sec. Grade A–F + concrete fixes per check.

There's also a free interactive iceberg viz: workspace.agentfix.pro — what Google sees ↑ what AI agents reach for ↓ what nobody ships yet 🌊

Full product at agentfix.pro = 33 signals + ZIP fix-pack generated from your real content. One-time $1/$29/$99 (no subscription).

Repo: https://github.com/Virt92/agentfix-oss-scanner
Scanner: npx agentfix-mini-scanner yoursite.com
Workspace viz: https://agentfix.pro