Summary

A solo episode in which Greg Isenberg reads Cloudflare's agent-payments announcement as the beginning of a new business model for the internet, then proposes three businesses built on that thesis. It is explicitly an argument and a pitch, not reporting: the Cloudflare mechanics are described second-hand from the announcement, and everything after that is the presenter's forecast and his own startup ideas, complete with pricing he suggests founders charge. He states he has no affiliation with Cloudflare, and separately discloses that one of the three ideas describes a product he already runs. The structural observation about how agents consume the web is the part worth keeping; the predictions and the revenue figures are speculation and are presented as such. Posted 10 August 2026, roughly six weeks before the rest of this batch.

• The framing he opens with is the clearest part of the argument. The old bargain was that site owners let search engines crawl because crawling sent visitors, and the visit was what got monetised through ads, email capture, affiliate clicks or subscriptions. An agent reads the page, extracts the answer and hands it to the user, so the content still creates value but the site may lose the visit and everything that depended on it.
• His extension of that — and the actual thesis — is that publisher complaints are 'only the first inning', because agents will use the internet the way software uses infrastructure: requesting things, calling tools, comparing products, retrieving data, buying access and taking action. That implies pricing for machine usage rather than for attention.
• The pricing argument rests on an asymmetry he states well: a human would not pay a fraction of a cent to read a page and would resent being asked, but a machine does not care if the payment is tiny and automatic. His summary is that 'the human web monetized attention, and the agent web monetizes useful resources'.
• The Cloudflare components as he describes them, reported from the announcement rather than tested. AI Crawl Control gives site owners visibility of crawler activity with the ability to allow or block specific crawlers. Pay Per Crawl lets a site charge AI crawlers for access. A monetization gateway extends the same idea to any resource behind Cloudflare — a page, a dataset, an API, an MCP tool call, a file or a search index.
• The payment mechanism he names is x402, built on the HTTP 402 Payment Required status code: the agent requests a resource, the server responds with the price, and the agent pays and retries with proof of payment, which Cloudflare can verify at the edge before the request reaches the origin. He says the amounts are usually a fraction of a penny.
• The phrase he uses for why this matters — 'the request becomes the transaction' — captures the mechanical claim: paid access without a checkout flow, an account, a sales call or procurement. Whether it works at scale is untested and he does not claim otherwise.
• He raises and answers the obvious objection himself rather than ducking it: that agents do not have wallets. His response is that they will, that it is 'already starting to happen', and that this is an assumption his whole thesis rests on. That is an honest statement of the load-bearing uncertainty and should be preserved as such.
• A structural point about formats: humans tolerate messy websites — he describes clicking around, reading a FAQ from 2019, opening a PDF, and says 'we're good at suffering' — while agents need clean, trustworthy structure. He names MCP, llms.txt, search APIs and bulk data APIs as the access points involved.
• The layered stack he sketches is the reusable frame in this entry: a messy internet, cleaned into structured data, made agent-readable through an access point, with payment rules applied selectively — some free for distribution, some paid because valuable, some blocked because private — and then a trust and analytics layer asking whether data is fresh, which sources are reliable and which requests are worth money.
• His filter for whether data can be sold to agents is a compact test: the data must be valuable, repeated, changing, fragmented and annoying. Valuable means better decisions that make or save money; repeated means the customer needs it again; changing means freshness matters; fragmented means one person cannot easily gather it; annoying is where the margin comes from.
• A go-to-market observation that generalises beyond this topic: the first customer is usually not the end business but whoever already sells into that niche — agencies, consultants, freelancers and implementation people — because they understand the value and are an easier sale. His example figures, presented as illustration only, are an agency on a $5,000-a-month retainer paying $300 to $800 for the underlying data.
• The second idea is making companies legible to agents, which he distinguishes from the 'buzzy fuzzy phrase' AI SEO. His sales method is the memorable part: run twenty to fifty buyer-intent prompts across the major AI tools for a company's category, then show the founder what comes back — that they do not appear, that their pricing is quoted wrong, that a competitor is recommended because its documentation is cleaner, or that their answer exists but is buried in an old PDF. His phrasing is 'you're not selling the future, you're selling the screenshot'.
• The fixes he lists for that are concrete and mostly mundane: an llms.txt file, better documentation structure, a pricing page an agent can parse, honest comparison pages, plain-language use cases, customer proof organised by segment, structured FAQs, schema markup, a product feed, a change log, and a lightweight MCP server or search endpoint where there is enough content to justify one. He is clear the recurring product is the monthly measurement loop, not the one-off cleanup.
• His suggested service pricing — $3,000 to $10,000 for an audit and cleanup, more for larger B2B companies — is a founder's recommendation about what to charge, not observed market data.
• The third idea turns an expert's archive of videos, podcasts and newsletters into a job-specific agent tool. He argues explicitly against the broad version, saying 'chat with an expert' products are too vague and that the value is in one specific workflow with an outcome. He also warns against the lazy implementation of throwing everything into a vector database, which he says 'gives you a search box with confidence' rather than a product, and insists on structured tagging by job, topic, audience, framework and outcome.
• He discloses that this third idea describes something he already operates, naming his own product and its MCP integration, and says he is 'practicing what I'm preaching'. The disclosure is voluntary and worth noting when weighing his enthusiasm for the category.
• He references a well-known indie developer arguing publicly that building has got harder — traffic and revenue down, partly attributed to AI overviews and partly to people building simple software themselves. Isenberg disagrees, calling it 'the best time ever' to build, on the grounds that the businesses worth starting are no longer the small tools that can be self-built. Both positions are opinion; recording that they conflict is the point.

Why it matters