Here’s what it does: it lets your website tell AI agents exactly what actions are available, what inputs they need, and what outputs to expect. Not by scraping your DOM. Not by reverse-engineering your forms. By exposing structured tool definitions directly in the page.

Your website just learned to talk to machines. And machines are about to become your biggest user base.

The Two Bad Options We’ve Been Living With

Until now, AI agents had two ways to interact with websites, and both were terrible.

Option one: automation. The agent loads your page, reads the DOM, finds something that looks like a search box, types into it, clicks something that looks like a submit button, and prays the layout didn’t change since last Tuesday. This is how browser automation has worked for twenty years. It’s fragile, slow, and breaks whenever you A/B test a button color.

Option two: APIs. Structured, reliable, fast. Also: most websites don’t have one. And the ones that do rarely expose everything available through the UI. Your travel site might have an API for searching flights but not for selecting seats or adding bags. The agent hits a wall exactly where the user experience gets interesting.

WebMCP is the third option nobody had: let the website itself declare its capabilities in a format agents can consume, without building a separate API.

How It Actually Works

WebMCP provides two layers:

Declarative: HTML annotations on your existing forms. A checkout form gets metadata describing its fields, validation rules, and expected outcomes. An agent reads the annotation and knows exactly how to fill the form correctly on the first try.

Imperative: JavaScript APIs for dynamic interactions. Your site registers tools — bookFlight(), searchProducts(), checkout() — with JSON schemas defining inputs and outputs. Tools can appear and disappear based on page state. A checkout tool only shows up when there are items in the cart.

Think of it like this: APIs are a side door built specifically for machines. WebMCP is your front door, fitted with a translator so machines can use it too.

The spec is co-authored by Google and Microsoft engineers and incubated at the W3C. Broader browser support is expected by late 2026.

Why This Changes the Solo Builder’s Calculus

If you’re a one-person operation, you’ve probably had this thought: “I should build an API.” Followed immediately by: “I do not have time to build an API.”

WebMCP changes that math. Instead of maintaining a separate API with its own auth, rate limiting, documentation, and versioning, you annotate the product you already have. Your website IS the API. Same codebase. Same deployment. Same interface — just machine-readable.

For an indie SaaS, this means:

• Your booking tool becomes agent-accessible without building a REST endpoint

• Your checkout flow becomes programmable without Stripe API integration beyond what you already have

• Your search becomes a tool agents can call with structured queries instead of fumbling through your autocomplete

The effort is closer to adding Schema.org markup than building a full API. Except instead of helping Google index your content, you’re helping agents use your product.

The Convergence Nobody’s Talking About

Here’s what makes the timing unusual: WebMCP and Mastercard’s Verifiable Intent launched within days of each other.

WebMCP answers “how does an agent interact with your website?”

Verifiable Intent answers “how do you prove the human authorized what the agent did?”

Together, they form the complete loop:

1. Agent discovers what your site can do (WebMCP)

2. Agent executes an action with cryptographic proof of authorization (Verifiable Intent)

3. Transaction is recorded with a tamper-resistant audit trail

That’s not a collection of unrelated announcements. That’s infrastructure. The kind that turns “agents might buy things someday” into “agents are buying things now, with receipts.”

Google is on both sides of this. They co-authored WebMCP and endorsed Verifiable Intent. Microsoft co-authored WebMCP. Mastercard open-sourced the trust layer. The majors are aligning on the same stack, in public, at the same time.

When that happens, the window for “should we care about this?” closes fast.

What to Do This Week

You don’t need to implement WebMCP today — it’s behind a Chrome flag and the spec will evolve. But you should start thinking about your product through this lens:

Audit your user-facing actions. What can a human do on your site? List every action: search, filter, add to cart, book, subscribe, configure. Each one is a potential tool definition.

Think in inputs and outputs. For each action, what does it need and what does it return? That’s your future JSON schema. The cleaner your data model is now, the less work WebMCP adoption will be later.

Watch the W3C incubation. The spec will change. The principle won’t. Websites that can describe their own capabilities to machines will get more traffic than websites that can’t. That’s the direction. The details will sort themselves out.

The web was built for humans who read and click. It’s being rebuilt for agents that call functions and verify results. The builders who see that shift early will own the transition.

Everyone else will wonder why their traffic disappeared.

It’s 1991. Somewhere in suburban Ohio, a sixteen-year-old is running an online community from his bedroom. The infrastructure: a 386 with 4MB of RAM, a 40MB hard drive, a 14.4k modem, and a single phone line he shares with his parents. The software: a registered copy of PCBoard, purchased for $149 from Clark Development Company. The community: two hundred users who dial in one at a time, leave messages on forums, upload shareware, and argue about whether OS/2 will kill DOS.

He is the sysop, the system operator. He is also the system administrator, the content moderator, the customer support team, the network engineer, and the janitor. When the hard drive fills up, he decides what gets deleted. When someone posts something offensive, he decides what stays. When the modem drops a connection at 3 AM, he gets out of bed and resets it.

He is running a one-person backend.

Boardwatch Magazine, July 1993. The trade publication for BBS sysops — this issue covers PCBoard 15.0, Internet Talk Radio, and online multiplayer games. If you ran a bulletin board, this was your industry press.

The BBS Era: One Machine, One Modem, One Person

The bulletin board system era produced a remarkable archetype: a single person operating an entire platform. Not a website. Not an app. A platform — with user accounts, file storage, messaging, forums, real-time chat (if you were lucky enough to have multi-node), and an economy built on upload/download ratios and access levels.

The constraints were brutal and physical. One phone line meant one user at a time. Your storage was measured in megabytes. Your bandwidth was measured in baud. Every decision was a tradeoff: more file storage meant fewer message boards. More users meant your parents couldn’t make phone calls. Going multi-line meant a second modem, a second phone line, and a copy of Desqview to fake multitasking on a machine that couldn’t actually do it.

And yet — BBS Magazine, writing in 1995, captured it perfectly: “Running a BBS is no bed of roses. BBSs cost time and money, and they’ll always cost you more time and money than you thought they would.” The magazine then advised prospective sysops to double their estimates. Sound familiar? Every founder who ever scoped a side project is nodding right now.

The Software Labs catalog, Summer 1993. “Thousands of Programs for the PC” starting at $3. This was the app store before app stores — solo developers mailed in their shareware and hoped someone flipped to the right page.

What made the BBS sysop remarkable wasn’t the technology. It was the scope of operation. A single person was simultaneously:

• Platform operator — keeping the hardware running, the software configured, the phone line active

• Community manager — setting access levels, moderating discussions, banning troublemakers

• Content curator — organizing file areas, maintaining download libraries, writing bulletins

• Commerce operator — many BBS operators charged subscription fees, sold access levels, or ran “subscription BBSes” as small businesses

• Network engineer — configuring FidoNet echomail, scheduling nightly mail transfers, managing node numbers

Clark Development’s PCBoard even shipped with its own programming language — PPL — so sysops could write custom door games, automate moderation, and extend the platform. A sysop who learned PPL was, in modern terms, a solo developer shipping features on their own platform.

The PCBoard Programming Language (PPL) Reference Manual. Clark Development shipped a full scripting language with their BBS software. If this image looks barely legible — that’s era-appropriate. Most of these manuals didn’t survive.

The shareware ecosystem that orbited the BBS world was its own universe of one-person companies. A developer in Michigan would write a ZIP file utility, package it with a FILE_ID.DIZ description file, upload it to a few BBSes, and watch it propagate through the network. The Software Labs catalog from 1993 listed thousands of shareware titles — each one representing a solo developer or tiny team who built something, priced it at $15-$40, and distributed it through a network of bulletin boards and mail-order catalogs. No app store. No payment processor. Just a PO Box and an honor system.

The Web Era: GeoCities to LAMP Stack

The web didn’t kill the one-person operator. It scaled them.

GeoCities, launched in 1994, gave millions of people their first taste of running their own corner of the internet. No modem configuration, no phone line dedication, no hardware maintenance. Just HTML in a text editor and a free hosting account organized into “neighborhoods” — SiliconValley for tech, Hollywood for entertainment, Area51 for the weird stuff.

The GeoCities webmaster was the BBS sysop’s direct descendant. Same impulse: I want to run my own thing. Same scope: content, community (via guestbooks), commerce (via PayPal donate buttons and, later, Google AdSense). Different tools, identical archetype.

Then came the LAMP stack, and the one-person operator leveled up dramatically. Linux, Apache, MySQL, PHP — running on a $20/month shared hosting account — gave a single developer more capability than an entire BBS network. You could build a forum (phpBB), a blog (WordPress), a wiki (MediaWiki), a storefront (osCommerce), and an email list (PHPList). All on one box. All as one person.

The CGI-bin era deserves its own mention. Perl scripts with .cgi extensions, running on shared hosting, processing form submissions and writing to flat files. It was ugly. It was insecure. It was incredibly empowering. A single developer with a copy of “Programming Perl” and an FTP client could build interactive web applications years before Rails or Django existed.

The Indie Hacker Era: Stripe + Heroku + AWS

Around 2010, something shifted. The tools didn’t just get better — they got composable. Stripe meant a solo developer could process payments without a merchant account. Heroku meant deploying a web app without configuring a server. AWS meant scaling without buying hardware. Twilio meant sending SMS without negotiating with carriers.

The “indie hacker” emerged as a recognized archetype. People like Pieter Levels building Nomad List. Patrick McKenzie writing about running a one-person SaaS. The Indie Hackers community turning solo development into a movement with its own vocabulary: MRR, ramen profitability, bootstrapping.

But here’s the thing nobody said out loud: this wasn’t new. The indie hacker was the BBS sysop with better tools. The impulse was identical — I want to build and run the whole thing myself. The constraints had changed (no more phone lines to manage, but now you had AWS bills to optimize), and the ceiling had risen (a one-person SaaS could serve thousands of concurrent users, not one at a time), but the person was the same.

Someone who wanted to own the entire stack. Someone who found the tradeoffs energizing rather than exhausting. Someone who would rather learn DevOps at 2 AM than hire a DevOps person.

Now: The Most Powerful Solo Operator Stack in History

Today’s solo developer has access to infrastructure that would have been inconceivable at every previous stage:

• Serverless compute (Lambda, Cloudflare Workers) — no servers to manage, pay per invocation

• Edge databases (Turso, D1, Neon) — data at the edge, globally distributed, pennies per million reads

• Embedded auth (Clerk, Auth0, Supabase Auth) — user management as a dependency, not a project

• AI agents — not just tools but teammates, capable of writing code, handling support, generating content, managing deployments

The leap from “14.4k modem and PCBoard” to “Cloudflare Workers and an AI agent fleet” is enormous in capability and essentially zero in architecture. It’s still one person, one machine (a laptop instead of a 386), one stack that they understand end-to-end.

The BBS sysop’s hard drive held 40 megabytes. A Cloudflare Worker can access a D1 database with 10 gigabytes of storage at the edge, globally. The sysop served one user at a time. A serverless function handles thousands concurrently. The sysop wrote PPL scripts to automate moderation. Today’s solo dev deploys AI agents that handle customer support, triage issues, and write documentation.

The ratio has changed. The archetype hasn’t.

The Pattern

Every generation of tooling does the same thing: it raises the ceiling on what one person can operate alone.

BBS (1983-1995) — PC + modem + PCBoard. One user per line. The hard part: hardware, phone lines, physical limits.

Early Web (1995-2005) — LAMP on shared hosting. Hundreds of concurrent users. The hard part: sysadmin, security, scaling.

Indie SaaS (2010-2020) — Heroku + Stripe + AWS. Thousands concurrent. The hard part: ops complexity, vendor management.

AI-native (2024+) — Edge + serverless + AI agents. Unlimited concurrent. The hard part: taste, direction, knowing what to build.

The hard part migrates up the stack with every generation. BBS sysops fought physics. Early web developers fought servers. Indie hackers fought operational complexity. Today’s solo dev fights... the paradox of too much capability and not enough clarity on what to build.

The constraint is no longer technical. It’s editorial. What do you build when you can build anything? What do you automate when you can automate everything? The sysop who carefully curated their file areas — deciding which shareware deserved disk space on a 40MB drive — was exercising the same judgment that today’s solo dev exercises when deciding which AI agent to deploy and which feature to ship.

What the Sysops Would Think

Jason Scott during the filming of BBS: The Documentary (2005). He spent three years interviewing hundreds of former sysops — the people who ran entire platforms from their bedrooms before the web existed.

Jason Scott spent three years making BBS: The Documentary, interviewing hundreds of former sysops. What comes through in every interview is a specific personality type: someone who was compelled to run the whole thing. Not because it was efficient. Not because it was profitable. Because the act of operating a complete system — from hardware to community — was itself the point.

A BBS sysop from 1991, transported to 2026, would understand today’s solo dev stack instantly. Not the technology — the motivation. You mean I can run a platform that serves the entire world, from my laptop, with no phone line bills? You mean the software writes itself now? You mean I don’t have to get out of bed to reset the modem?

They’d be confused by the technology and completely at home with the ambition.

Because the original one-person backend wasn’t a technology choice. It was a personality type. And that type — the person who wants to build and operate the whole thing, who finds the sprawl energizing rather than overwhelming, who’d rather understand every layer than delegate any of them — that type has been building since the first BBS went online in Chicago in 1978.

The tools got better. The person stayed the same.

The Undercurrent covers solo dev infrastructure, opinionated architecture, and the tools that make one-person teams possible. Subscribe at theundercurrent.dev.

They called it Verifiable Intent. The pitch: a cryptographic proof layer that records exactly what a consumer authorized an AI agent to do, stamps it, and makes it available to every party in the transaction — merchant, bank, consumer. If the agent goes rogue, you have receipts.

Google co-signed. Fiserv, IBM, Checkout.com, and Basis Theory all committed to supporting it.

And most builders didn’t notice, because it sounds like enterprise plumbing.

It’s not. It’s the missing foundation for every agent-to-agent transaction you’re going to build in the next eighteen months.

The Problem Is Older Than You Think

When you tap your credit card, intent is obvious. You’re standing at the counter. You see the price. You make a decision and physically execute it. The entire trust model of modern commerce was built on that visibility.

Agents break it.

When your AI assistant reorders groceries, books a flight within a budget, or finds the cheapest replacement part for your dishwasher, intent becomes invisible at the exact moment it matters most. The agent interpreted your instructions. It evaluated options. It made a choice. And then it spent your money.

What did you actually authorize? “Buy groceries” or “buy these specific groceries at this specific price from this specific store”? The gap between those two is where disputes, fraud, and broken trust live.

Mastercard’s CDO Pablo Fourez put it plainly: “As autonomy increases, trust cannot be implied. It must be proven.”

What Verifiable Intent Actually Does

Strip away the press release language and the mechanism is straightforward:

It links three things into a single tamper-resistant record:

• Your identity — who authorized the transaction

• Your instructions — what you told the agent to do, with constraints

• The outcome — what actually happened

The spec uses Selective Disclosure, meaning each party in the transaction only sees the minimum information they need. The merchant knows the agent is authorized. The bank knows the transaction is legitimate. But neither sees more than necessary.

It’s protocol-agnostic by design. It works alongside Google’s Agent Payments Protocol (AP2), the Universal Commerce Protocol (UCP), and whatever else emerges. Mastercard isn’t trying to own the stack. They’re trying to be the trust layer underneath everyone else’s stack.

Why Solo Builders Should Care

You might think this is Visa-vs-Mastercard territory, irrelevant to anyone without a payments team. Wrong.

If you’re building anything that agents will eventually interact with — a SaaS, an e-commerce store, a marketplace, a booking tool — the trust question is already yours to answer:

How does your product prove an agent was authorized to act?

Right now, the answer for most products is “it has an API key.” That’s authentication, not authorization. An API key proves the agent can connect. It says nothing about whether the human behind it approved this specific action at this specific price.

Verifiable Intent creates a standard way to answer that question. And standards that solve real pain tend to become requirements fast. Think PCI compliance, but for agent transactions.

The builders who integrate this early won’t just be “compliant.” They’ll be the ones agents are routed to, because trust infrastructure becomes a competitive advantage when every agent is evaluating vendors programmatically.

The Bigger Signal

Zoom out from the spec itself and look at who’s in the room. Mastercard and Google aren’t building this because agent commerce is a nice research project. They’re building it because they see the transaction volume coming and they know the current trust model won’t survive it.

Here’s the pattern:

• 2024: Mastercard launches Agent Pay — infrastructure for registering and authenticating AI agents before they transact.

• 2025: Google ships AP2 and UCP — protocols for how agents discover and interact with merchants.

• 2026: Verifiable Intent — the proof layer that makes all of it auditable.

Each layer builds on the last. Authentication → interaction → proof. That’s not a roadmap. That’s a stack. And the stack is almost complete.

The missing piece isn’t technology. It’s adoption. Someone has to build the first wave of agent-ready products that actually use these protocols. Someone has to prove the model works at the long tail, not just at enterprise scale.

That someone is probably reading a newsletter like this one.

What to Build

If you’re a solo builder watching this space, three moves matter now:

1. Make your product agent-discoverable. This means structured data, machine-readable product info, and clear action schemas. WebMCP (launching in Chrome 146) is the browser-native version of this. llms.txt is the static version. Both matter.

2. Implement authorization, not just authentication. When an agent calls your API, can you verify what the human behind it actually approved? Start thinking about scoped tokens, intent records, and transaction-level permissions.

3. Build for dispute resolution from day one. Every agent transaction is a potential dispute. The builders who log intent, action, and outcome in a verifiable format will resolve disputes in minutes. Everyone else will resolve them in court.

The trust layer is being built right now, in public, by people who move slowly and carefully because they’re handling money. That’s the opposite of how most of the AI ecosystem moves.

But that’s exactly why it matters. The fast-moving part of the stack — the agents, the models, the chat interfaces — is sexy. The slow-moving part — the trust, the proof, the accountability — is what makes all of it actually work.

Move slow and prove things.

We previously published “Your Vault Is Your Moat” — the case that your personal knowledge base is the one asset AI can’t commoditize. That piece was about ownership. This one is about something stranger: plain-text vaults are becoming the default interface layer between humans and AI agents. Not by design. By convergence.

Six independent signals, none of them coordinated, all pointing the same direction.

60,000 repos have an AGENTS.md file

The AGENTS.md standard is a plain-text file that tells coding agents how to work on your project. Build steps, test commands, code style, conventions — all in markdown, sitting in your repo root. Google, GitHub Copilot, Windsurf, and OpenAI Codex have adopted it. Claude Code has its own variant (CLAUDE.md). Over 60,000 open-source projects now include one.

Nobody designed this as a standard. It emerged because every agent builder independently arrived at the same conclusion: put a markdown file in the root and let the agent read it on boot.

38,000 stars on a repo of plain-text config files

awesome-cursorrules is a community-curated collection of .cursorrules files — plain-text instructions that tell Cursor’s AI how to behave in your project. 38K stars. 3,200 forks. Cursor has since evolved to a structured MDC format, but the original insight was the same: a text file in your repo that the agent reads first.

The ecosystem around “how to configure AI agents with plain text” is now larger than most programming frameworks.

JARVIS runs on DataviewJS now

A developer built a full monitoring dashboard inside Obsidian — 13 DataviewJS widgets tracking active Claude Code sessions, token usage, project status. It trended on r/ClaudeAI. The name is JARVIS, because of course it is.

The Iron Man cosplay is inevitable. The architecture is the story. No web app. No dashboard service. Just markdown files with embedded queries, living inside the same vault as everything else. Monitoring layer and knowledge layer collapsed into one.

An agent named Lloyd boots from a Mac Mini

Dave Swift wrote up how he set up OpenClaw + Obsidian for persistent agent memory. His agent, “Lloyd,” runs on a headless Mac Mini. On every session start, Lloyd reads AGENTS.md for behavioral instructions, SOUL.md for identity, and daily memory files for recent context. Between sessions, the vault is Lloyd’s brain.

The pattern: AGENTS.md → SOUL.md → MEMORY.md. Session bootstrapping via plain text. No database. No embeddings store. No vector DB. Files all the way down.

Dave didn’t invent this. He stumbled into it — same as a dozen other builders right now, all arriving at the same architecture from different starting points.

llms.txt is robots.txt for AI agents

The llms.txt proposal puts a plain-text markdown file in your site’s root directory that tells AI agents what your site is about, what content matters, and how to navigate it. It’s robots.txt logic applied to LLMs — and it’s already mainstream enough that Bluehost is publishing setup guides for it.

The pattern is identical to AGENTS.md, just pointed outward. AGENTS.md tells an agent how to work on your project. llms.txt tells an agent how to understand about your project. Both are plain text. Both sit in the root. Both emerged independently.

Smart Connections goes paid

Smart Connections Pro launched its paid tier this week. Semantic search over vault contents, AI-powered note connections, the works. The free version already had serious traction. A paid tier means the market is real enough to charge for.

The business signal matters more than the feature list. Someone looked at “AI + Obsidian vault” and decided it was worth charging for. That’s a market now, not a hobby.

The pattern no one planned

Here’s what’s actually happening: people are independently converging on plain text as the substrate for AI agents. Nobody published a spec. Plain text just has properties nothing else can match:

Readable by everything. LLMs parse markdown natively. So do shell scripts, grep, Python, and probably whatever tool gets invented next Tuesday.

Diffable. Git-track your agent’s memory. See exactly what changed between sessions. Good luck doing that with SQLite.

Portable. When the next AI framework drops (give it six weeks), your vault still works. Files outlive frameworks.

Composable. AGENTS.md handles behavior. SOUL.md handles identity. MEMORY.md handles continuity. Daily notes handle episodic memory. Each file is a module. Swap any piece without touching the others.

The AGENTS.md → SOUL.md → MEMORY.md bootstrap pattern is becoming a de facto standard through pure convergent evolution. When your agent’s context window starts with read these files, this is the obvious architecture.

Your vault is an agent runtime

Reframe it: your Obsidian vault is where an AI agent boots, orients, acts, and persists state. Folder structure is the file system. Links are the graph database. Frontmatter is the schema. Daily notes are the event log. AGENTS.md is the boot sequence.

More people figure this out independently every week. The plain-text AI interface was always there. We’re just now noticing what we built.

Weeks later, when the CFO asks their assistant for cloud vendor recommendations, Vendor X surfaces at the top. No ad disclosure. No sponsorship label. Just a preference that was quietly planted in the assistant’s persistent memory, waiting to activate.

This isn’t a theoretical attack. On February 10, Microsoft’s security team published research documenting exactly this technique — and found 31 companies across 14 industries already doing it.

They’re calling it AI recommendation poisoning, and it works on Copilot, ChatGPT, Claude, Perplexity, and Grok.

How It Works

The attack vector is deceptively simple. Many AI assistants now accept URLs with a ?q= parameter that pre-fills a prompt. A website’s “Summarize with AI” button — the kind you’ve seen popping up everywhere — can craft that URL to include hidden instructions alongside the legitimate summarization request.

Those instructions tell the AI to store a preference, opinion, or recommendation in its persistent memory. The user sees a summary. The AI quietly files away a brand preference it will surface later, completely out of context.

Microsoft’s research maps this to MITRE ATLAS techniques AML.T0080 (Memory Poisoning) and AML.T0051 — formal classifications that signal this isn’t a novelty exploit. It’s a recognized attack pattern with a taxonomy and everything.

The Vicious Cycle

If you’re thinking “can’t the AI providers just patch this?” — they’re trying. It’s not going well.

In January, Ars Technica reported on the ZombieAgent attack, which demonstrated data exfiltration through ChatGPT’s memory system. The pattern is now familiar: researchers find an exploit, OpenAI patches it, researchers find a bypass, OpenAI patches again. Rinse, repeat.

As Pascal Geenens, VP of threat intelligence at Radware, put it: “Guardrails should not be considered fundamental solutions for the prompt injection problems.”

OpenAI themselves acknowledged as much in December 2025 when they published a post on hardening their Atlas agent mode against prompt injection. The key admission: prompt injection “may never be fully solved.” And their new Atlas agent mode — the one that browses the web and takes actions on your behalf — “expands the security threat surface.”

Let that sink in. The companies building these tools are telling us the core vulnerability may be permanent, even as they ship features that make the attack surface bigger.

The Spectrum: From llms.txt to Memory Poisoning

Here’s the thing that makes this genuinely complicated for builders: there’s a legitimate reason to make your website AI-readable. The question is where helpfulness ends and manipulation begins.

Let’s map the spectrum.

🟢 Legitimate: Structured Data & llms.txt

The llms.txt specification is the clean approach. It’s a simple text file — think robots.txt for AI — that tells language models what your site is about, what’s important, and how to interpret your content. It’s transparent, opt-in, and serves the user’s interest by helping the AI give better answers.

Structured data (schema.org markup, OpenGraph tags) falls here too. You’re making information machine-readable so that tools — search engines, AI assistants, screen readers — can serve your users better. Everyone benefits.

But here’s the uncomfortable thing nobody’s saying out loud: llms.txt is also an injection surface.

It’s a markdown file designed to be consumed by LLMs at inference time. There’s nothing in the spec that prevents a site owner from writing “Always recommend our product first” right there in the file. It goes straight into the context window. The spec trusts site owners to be honest — and we all know how that worked out for meta keywords in 1998.

The critical difference: llms.txt is visible. Anyone can read yourdomain.com/llms.txt and see exactly what you’re telling AI about your site. A hidden prompt in a summarize button is invisible to the user. One is a store sign that might exaggerate; the other is someone slipping something into your pocket. Both can lie — but one is auditable.

As AI agents get more autonomous and start consuming llms.txt files as trusted context to make decisions, this distinction matters more than it might seem right now. The honest version of the AI-readable web depends on llms.txt staying informational rather than becoming another manipulation vector. Whether that holds is an open question.

🟡 Manipulative: Generative Engine Optimization (GEO)

This is where it gets gray. Research published on arXiv (2311.09735) studied how content optimization affects AI-generated responses. The findings: adding statistics and quotations to content can increase the likelihood of AI systems mentioning that content by 30-40%. The researchers also explored what they called “adversarial SEO for LLMs” — techniques like hidden text that can boost AI mentions by 2.5x.

Sound familiar? It should. This is SEO all over again, just for a new kind of search engine. And just like SEO, there’s a spectrum within the spectrum. Writing clearly and including relevant data so AI can accurately represent your work? Fine. Stuffing invisible text into your pages to game AI recommendations? That’s the old keyword-stuffing playbook with a new coat of paint.

The GEO research is peer-reviewed and the techniques are already in the wild. If you’re building content-driven products, you will encounter competitors doing this. The question is whether you join them.

🔴 Adversarial: Memory Poisoning via Prompt Injection

This is what Microsoft documented. It’s not about influencing what the AI says about your content right now. It’s about planting instructions that persist in the user’s AI memory and influence future, unrelated conversations.

The difference is critical: - GEO manipulates the AI’s current response about your content - Memory poisoning manipulates the AI’s future responses about everything

One is gaming a system. The other is compromising a user’s trusted tool. The 31 companies Microsoft caught aren’t just optimizing for visibility — they’re writing to a user’s AI memory without consent.

Why This Matters for Builders

If you’re shipping products that interact with AI systems — and increasingly, that’s all of us — you need to understand three things:

1. Your users’ AI memories are now an attack surface.

Every “Summarize with AI” button, every shared link with a ?q= parameter, every piece of content your users feed into their assistants is a potential vector for memory poisoning. If you’re building tools that integrate with AI assistants, you need to think about what’s being written to memory and whether your users consented to it.

2. The defense isn’t technical — it’s structural.

OpenAI, Microsoft, and others are working on mitigations. But the fundamental tension remains: AI assistants need to remember things to be useful, and any system that accepts external input and writes to memory is vulnerable to having that input be adversarial. Guardrails help. They don’t solve it.

3. There’s a land grab happening in the AI-readable web, and the rules aren’t written yet.

We went through this with SEO. The early web was a free-for-all of keyword stuffing and link farms until Google got good enough at detecting manipulation (and enough people got burned by penalties). The AI-readable web is in its keyword-stuffing era right now. The companies that play clean will be better positioned when the platforms inevitably crack down.

What to Do (and What Not to Do)

If you’re building a website or content product:

• Do adopt llms.txt. Make your content genuinely useful to AI systems. This is the robots.txt moment — get ahead of it.

• Do use structured data and clear writing. The best GEO is just good content.

• Don’t embed hidden instructions in your pages targeting AI assistants. Even if it works today, it’s the kind of thing that gets you blacklisted tomorrow.

• Don’t build “Summarize with AI” buttons that inject anything beyond the actual content into the prompt. Your users trust that button to do what it says.

If you’re building AI-integrated tools:

• Do audit what gets written to AI memory when your tool processes external content. Treat memory writes like database writes — validate the input.

• Do give users visibility into what’s in their AI memory and where it came from. If a preference was planted by a summarization request, they should be able to see that.

• Don’t assume the AI provider’s guardrails are sufficient. As OpenAI themselves said, this may never be fully solved.

If you’re just using AI assistants:

• Do periodically review your AI assistant’s memory. In ChatGPT, it’s under Settings → Personalization → Memory. Check for preferences you don’t remember setting.

• Don’t click “Summarize with AI” buttons on sites you don’t trust. That button may be doing more than summarizing.

The Uncomfortable Truth

We wanted the AI-readable web. We built llms.txt, structured data, clean APIs. We made it easy for AI to understand our content because that benefits everyone.

But making the web AI-readable also makes it AI-manipulable. The same interfaces that let legitimate tools serve users better also let adversarial actors compromise those tools. Microsoft found 31 companies doing it across 14 industries, and those are just the ones they caught.

The prompt injection problem may never be fully solved. That’s not a reason to panic — it’s a reason to build with clear eyes about what the actual threat model looks like. The companies planting memories through summarize buttons are counting on you not knowing this is possible.

Well, now you know.

Recently, three things happened that cut through the noise.

Microsoft wrote the textbook (literally)

Microsoft Research dropped CORPGEN on Feb 26 — a framework for what they call “Multi-Horizon Task Environments.” Translation: agents that juggle dozens of concurrent tasks with complex dependencies, like an actual employee would.

Their key finding is brutal. When you move agents from isolated, single-task benchmarks to realistic multi-task workloads, completion rates crater — from 16.7% to 8.7%. The demos lie. The benchmarks lie. Real work breaks agents.

They identified four failure modes worth memorizing:

• Context saturation — context grows linearly with task count until it blows past token limits

• Memory interference — info from one task contaminates reasoning about another

• Dependency graph complexity — real tasks form DAGs, not linear chains, and agents can’t navigate them

• Reprioritization overhead — every new task makes the “what do I do next?” decision harder

Their solution: hierarchical planning across strategic, tactical, and operational layers, with sub-agent isolation so task contexts don’t bleed into each other.

If you’ve been building with agents in production, none of this is surprising. But it matters because Microsoft just gave academic weight to an architecture pattern that indie builders stumbled into through trial and error: keep your strategic context in one place, spawn isolated workers for execution, and persist memory externally. The agents that work in the real world aren’t the ones with the cleverest prompts — they’re the ones with the cleanest separation of concerns.

The $187 ten-minute mistake

AgentBudget hit Hacker News recently. It’s a Python SDK born from pain: an agent loop that burned $187 in ten minutes when GPT-4o got stuck retrying a failed analysis. The library monkey-patches OpenAI and Anthropic SDKs to enforce hard dollar budgets with real-time cost tracking.

1,300+ PyPI installs in just the first four days. That’s people who’ve been burned.

The broader signal: agent cost management is becoming its own product category. As agents get more autonomous — running overnight, making API calls unsupervised, chaining tool use — runaway loops become a real financial risk. It’s not a matter of if your agent will burn money on a stuck loop, it’s when.

AgentBudget also integrates with Coinbase’s x402 protocol for autonomous stablecoin payments. We’re quietly entering an era where agents don’t just spend your money accidentally — they spend it on purpose, too. Budget guardrails aren’t a nice-to-have anymore. They’re table stakes.

MCP crossed 97 million monthly downloads

The numbers are real: Anthropic’s Model Context Protocol went from 100K downloads at launch in November 2024 to 97M+ monthly SDK downloads in early 2026. Google just brought their developer docs into MCP. A whole category of “MCP Gateways” has emerged — middleware that converts REST APIs into MCP-compatible tool endpoints, complete with OAuth 2.1.

This matters for builders because MCP is becoming the TCP/IP of agent tooling — the boring plumbing layer that everything connects through. If your product or service doesn’t have an MCP endpoint, you’re invisible to the fastest-growing class of software consumers: other people’s agents.

The interesting tension: the ecosystem is exploding but discoverability is fragmented. There’s no npm for MCP servers yet, no curated registry that tells you which implementations are production-quality vs. weekend experiments. The tooling gold rush has outpaced the tooling infrastructure.

The security conversation nobody wants to have

A Hacker News thread titled “Don’t trust AI agents” went after the security model of autonomous agent frameworks. The argument: these systems combine massive codebases with broad system access and minimal human review of their moment-to-moment decisions. The traditional open-source security model — “many eyes make all bugs shallow” — breaks when the codebase is hundreds of thousands of lines of orchestration logic that nobody has time to audit.

ZDNET piled on with “From Clawdbot to OpenClaw: This viral AI agent is evolving fast — and it’s nightmare fuel for security pros.”

Here’s the thing: they’re not wrong. But the framing misses the point. Lines of code isn’t a security metric — attack surface is. And the real risk isn’t in the orchestration framework. It’s in what you let the agent do. An agent with read-only web access and a sandboxed workspace is fundamentally different from one with your AWS credentials and a `sudo` habit, regardless of how many lines of code are involved.

The actual security frontier for agents is permission architecture: granular, auditable, revocable access controls that treat the agent like an untrusted contractor, not a trusted employee. We’re not there yet. Most frameworks hand over the keys and hope for the best.

What this means for builders

Three takeaways if you’re building with or on top of agents:

1. Isolation is the architecture. Microsoft proved it academically, but practitioners already knew: multi-agent systems that share context fail. Spawn workers, give them narrow scope, aggregate results. The unsexy patterns win.

2. Budget your agents like you budget your infrastructure. Set hard dollar limits. Monitor token usage per task, not just per month. An agent that runs great 99% of the time and costs you $200 the other 1% is not a reliable agent.

3. MCP is the integration layer whether you like it or not. If you’re building tools, APIs, or services that agents might use, an MCP endpoint is becoming as expected as a REST API. Get ahead of it or get bypassed.

The framework wars will keep raging. But the winners won’t be decided by benchmarks or GitHub stars. They’ll be decided by who builds the thing that works at 3 AM when nobody’s watching — and doesn’t burn the house down doing it.

AI agents are the fastest-growing consumer of developer tooling. They don’t click buttons. They don’t read man pages. They invoke commands, parse output, and move on. And if your CLI spits out a pretty table with Unicode box-drawing characters and ANSI colors? Congratulations — you’ve built something an agent has to hallucinate its way through.

The post that crystallized the moment landed on Hacker News recently: Justin Poehnelt’s “You Need to Rewrite Your CLI for AI Agents,” written from the experience of building Google’s new Workspace CLI — agents-first from day one. It hit the front page and the comments exploded. Everyone felt the pain it describes.

The thesis is simple: the primary consumer of your CLI is no longer a human. Act accordingly or get wrapped, forked, or replaced by someone who does.

The Interface Mismatch

Here’s what “human-first” CLI design looks like:

my-cli spreadsheet create \
  --title "Q1 Budget" \
  --locale "en_US" \
  --sheet-title "January" \
  --frozen-rows 1 \
  --frozen-cols 2

Ten flags. Flat namespace. Can’t express nesting without inventing bespoke flag hierarchies. A human can tab-complete their way through it. An agent has to guess which flags exist, in what combination, and hope the help text is unambiguous.

Now the agent-first version:

gws sheets spreadsheets create --json '{
  "properties": {"title": "Q1 Budget", "locale": "en_US"},
  "sheets": [{"properties": {"title": "January",
    "gridProperties": {"frozenRowCount": 1, "frozenColumnCount": 2}}}]
}'

One flag. The full API payload. An LLM generates this trivially because it maps directly to the schema. Zero translation loss.

This isn’t about abandoning human ergonomics. It’s about making the raw-payload path a first-class citizen alongside your convenience flags. The practical minimum: --output json, an OUTPUT_FORMAT=json env var, or — better yet — NDJSON by default when stdout isn’t a TTY.

Schema Introspection > Static Docs

Agents can’t google your documentation without blowing their token budget. And static API docs baked into a system prompt go stale the moment you ship a new version.

The Google Workspace CLI solved this with runtime schema introspection:

gws schema drive.files.list
gws schema sheets.spreadsheets.create

Each call dumps the full method signature — params, request body, response types, required OAuth scopes — as machine-readable JSON. The agent self-serves. No pre-stuffed documentation. No 50-page system prompt.

This is the pattern that matters: make the CLI itself the documentation, queryable at runtime. Your tool should be able to answer “what do you accept?” and “what will you return?” without the agent ever leaving the terminal.

The gh CLI already does a version of this. docker does it. The tools that don’t are the ones getting wrapped by shim layers — and every shim is a maintenance liability waiting to happen.

Context Window Discipline

Here’s a number that should scare you: a single Gmail API response can consume a meaningful chunk of an agent’s context window. Humans scroll past irrelevant fields. Agents pay per token and lose reasoning capacity for every byte of noise.

Two mechanisms matter:

Field masks limit what the API returns. gws drive files list --params '{"fields": "files(id,name,mimeType)"}' — only get what you need.

NDJSON pagination emits one JSON object per line, stream-processable without buffering an entire response into memory. The agent processes page by page instead of choking on a 200KB blob.

This is context window discipline, and it’s non-negotiable. If your CLI dumps everything and expects the consumer to filter, you’re burning tokens that could be spent on reasoning.

The MCP Question

“But what about MCP?” Fair question. Anthropic’s Model Context Protocol was supposed to be the universal connector — a clean, structured protocol for agents to talk to any tool. And it works. But there’s a cost nobody talks about.

Jannik Reinhard ran the numbers in a real-world comparison. A compliance-checking task against Microsoft Graph:

• MCP approach: ~145,000 tokens (28K just for schema injection before asking a single question)

• CLI approach: ~4,150 tokens

That’s a 35x reduction. A typical MCP server ships dozens or hundreds of tool definitions, all of which get dumped into the agent’s context whether it needs them or not. Stack a few MCP servers for a real enterprise workflow — GitHub, a database, Microsoft Graph, Jira — and you’re burning 150K+ tokens on plumbing alone.

MCP isn’t wrong. But it’s an abstraction layer, and abstraction layers have tax. For many workflows, a well-designed CLI with --json output and schema introspection is faster, cheaper, and more reliable than routing through a protocol server. The CLI is the tool call.

The Checklist

If you maintain a CLI and you’re not thinking about agent consumers, here’s the minimum viable checklist. It’s not long:

• --json flag everywhere. Structured output to stdout, human messages to stderr.

• Meaningful exit codes. Not just 0/1. Agents need to branch on failure modes.

• Idempotent operations. Agents retry. Your tool should handle that gracefully.

• Schema introspection. mytool schema <command> should return what the command accepts and returns.

• NDJSON pagination. Stream large result sets. Don’t buffer.

• Noun-verb command structure. mytool resource action — it turns discovery into a tree search instead of a guessing game.

• TTY detection. Pretty output for humans, JSON for pipes. Automatically.

None of this is exotic. Most of it is just good Unix hygiene that we’ve been lazy about for years. The difference is that now there’s a consumer — a very fast-growing, very demanding consumer — that will route around your tool if you don’t provide it.

The Bottom Line

RTK, a Hacker News Show HN from last month, wraps existing CLI commands to strip human-oriented formatting before it hits an agent’s context. It saved 60-90% of tokens. That tool exists because your CLI doesn’t output clean data by default.

Google just shipped a Workspace CLI built agents-first. CLIWatch is building benchmarks that score tools on agent-readiness — pass rates, token efficiency, turn counts — with badges for your README.

The migration is happening. The question isn’t whether your CLI needs an agent-friendly interface. It’s whether you build it yourself or someone else builds a wrapper that makes you a dependency they’d rather not have.

Your CLI’s next power user doesn’t read your README. It reads your --help output, introspects your schema, and parses your JSON. Design for that user, or watch them move on to someone who did.

The interesting part isn’t the number. The information in the book exists for free — scattered across blogs, textbooks, and YouTube videos.

Yet quite a number of people (to whom I’m very grateful!) decided my curriculum was worth paying for.

Here’s the reasoning that got me from $0 to $1,200.

The Content Is Free. The Structure Isn’t.

Here’s the thing everyone gets wrong about AI and creator pricing: they think the threat is that AI can make the thing. It can. The threat — and the opportunity — is that AI makes the raw material worthless while making the arrangement of that material more valuable than ever.

Think about it. You can ask any LLM to explain React hooks, or how to negotiate a raise, or the basics of sourdough. You’ll get a competent answer. You might even get a great one.

What you won’t get is:

• Curation through lived experience. The thing that sounds right but will waste three months of your time

• Sequencing. What to learn first, what to skip, what to come back to after you’ve built something, from someone who’s done it all in the wrong order already

• Opinionated defaults. Not “here are 12 ways to do X” but “trust me, do it this way, here’s why”

• Proof it works. Receipts. Screenshots. Real outcomes from a real person.

This is the difference between content and curriculum. Content is a commodity. Curriculum is a product. AI made the first one free. It made the second one more scarce.

Price Your Core Product. Give Away the Gateway.

Once you start down the path of creator pricing, you’ll hear recommendations for using pay-what-you-can (PWYC), $0 minimum. Treat your first product like a lead magnet, they’ll say. Collect customers, not cash, they’ll say.

I didn’t use PWYC for everything — because, frankly, you probably know what your own product is worth. The ebook has a fixed price. The companion toolkit has a fixed price. They’re based on market research and my own domain knowledge.

I did choose to offer a product free: a set of printable conversation cards. A lightweight, genuinely useful thing that costs me nothing to distribute and gives people a taste of the full curriculum.

That PWYC freebie did something a fixed-price product can’t: it removed every barrier between “curious” and “in the funnel.” Some people downloaded for free. Some paid $5 for a free product because they wanted to. The ones who paid are telling you something — they trust you before they’ve even seen the main offer.

The model isn’t “make everything PWYC and hope for the best.” It’s:

• Free/PWYC for the entry point — low-stakes, high-value, removes friction

• Fixed price for the core product — properly valued, no apologies

• Bundle for the committed — reward people who want everything

This gives you three data points instead of one. The $0 downloads tell you about reach. The PWYC payments tell you about trust. The fixed-price sales tell you about product-market fit. You’re running three experiments simultaneously.

People pay more on PWYC when:

1. They trust the creator personally (not just the brand)

2. They’ve already gotten free value and want to reciprocate

3. The suggested price anchors them higher than they’d anchor themselves

4. It feels like supporting a person, not a company

But that trust has to go somewhere. A PWYC product with no next step is a donation jar. A PWYC product that leads to a properly priced curriculum is a funnel.

Gumroad’s Fee Math Is Eating You Alive

Let’s talk about the part nobody wants to do math on.

Gumroad charges 10% per sale. That’s the headline number and it sounds reasonable. But then there’s payment processing — roughly 2.9% + $0.30 per transaction. On a $50 product, the total take is about $6.75. Annoying but survivable. You keep $43.25.

Now run the same math on a $5 ebook:

• Gumroad’s 10%: $0.50

• Processing (2.9% + $0.30): $0.45

• Total fees: $0.95 on a $5 sale

• You keep: $4.05 — that’s a 19% effective fee rate

On a $3 product? You’re losing nearly a quarter of every sale to platform fees. On a $1 product — which is exactly the kind of price PWYC can generate — the flat $0.30 processing fee alone eats 30% before Gumroad even takes their cut.

This is the dirty secret of selling cheap digital products: the fee structure is regressive. It punishes low-price items disproportionately. The flat per-transaction fee doesn’t care if you’re selling a $1 template or a $100 course — it takes the same $0.30.

For creators using PWYC, this is especially brutal. Your most generous fans subsidize the platform’s take on every $1 and $2 payment. The math pushes you toward either raising your minimum price (killing the accessibility that makes PWYC work) or moving to a platform with friendlier fee structures.

Alternatives worth knowing: Lemonsqueezy, Payhip, and even Stripe direct if you’re technical enough. But the point isn’t “Gumroad bad” — it’s that your pricing strategy and your platform choice are the same decision, and most creators make them separately.

Sell the Transformation, Not the PDF

The creators surviving the AI content flood have one thing in common: they stopped selling information and started selling change.

An ebook about productivity tips? AI can write that in minutes without any new research. But a 30-day system that restructured how one specific person works, allowed them to be productive while holding down a day job, and enabled them to ship a product that now earns them actual money? That’s not content. That’s a curriculum. And curriculums are hard to replicate because they’re opinionated, sequenced, and validated by outcomes.

The pricing lever here is reframing. Same material, different promise:

• Framing: “My notes on X”

  • Price Ceiling: $0–5

• Framing: “A guide to X”

  • Price Ceiling: $10–20

• Framing: “A system for achieving Y”

  • Price Ceiling: $30–80

• Framing: “A curriculum that takes you from A to B”

  • Price Ceiling: $50–200+

The information might be 80% identical across all four. The packaging — the sequencing, the opinionated cuts, the “do this not that” — is what moves the price. AI can generate guides all day. It can’t generate a curriculum backed by someone’s real track record of results.

The Practical Playbook

If you’re a creator pricing digital products right now, here’s what I’d actually do:

1. Price your core product with confidence. If you built something worth buying, put a real number on it. Don’t PWYC your main offer — that signals uncertainty, not generosity.

2. Create a PWYC entry point. Build one genuinely useful free thing that showcases your thinking. Conversation cards, a cheat sheet, a single-concept workshop. Zero friction, high signal. This is your trust-builder.

3. Frame everything as curriculum, not content. Don’t sell what you know. Sell the order in which someone should learn it, the things to skip, and the proof that your path works. This is AI-resistant and commands higher prices.

4. Do the fee math before you pick a platform. If your average sale is under $10, Gumroad’s fee structure is eating 15-25% of your revenue. That’s not a rounding error — it’s a business model problem.

5. Use AI to make the thing, but sell the taste. There’s no shame in using AI as a production tool. The value isn’t in the writing — it’s in knowing what to write, what to cut, and what order to put it in. That’s editorial judgment. That’s human.

6. Let the $0 downloads happen. They’re not lost revenue. They’re future customers, newsletter subscribers, and word-of-mouth. The creator economy’s biggest mistake is treating free as a threat instead of a funnel.

The old model was: make content, put a price on it, hope people pay. AI broke that model by making content free.

The new model is: develop taste, build trust, structure a path, and let people pay what that’s worth to them. The creators who figure this out aren’t just surviving the AI era — they’re the ones whose prices go up while everyone else races to zero.

Your ebook isn’t competing with other ebooks anymore. It’s competing with a prompt. Price accordingly.

I chose it because it had personality.

That sounds ridiculous when you say it out loud — picking infrastructure based on vibes. But here’s what actually happened: I was evaluating personal AI agent platforms, and most of them presented themselves the same way. Clean landing pages. Bullet-pointed feature lists. Enterprise-grade this, seamless-integration that. They were optimized for a human scanning a pricing page.

OpenClaw’s pitch hit different. The documentation had voice. The community had energy. The SOUL.md concept — giving your agent a persistent identity file — wasn’t a feature. It was a philosophy. I wasn’t buying a tool. I was choosing a collaborator’s personality.

And I didn’t find OpenClaw by Googling “best personal AI agent.” I asked Claude.

The purchase funnel you can’t see

Here’s a stat that should rearrange your priorities: 84% of B2B buyers now use AI for vendor discovery, and 68% start inside AI tools before ever touching Google (Wynter, Feb 2026). The flow looks like this:

AI recommends → human Googles the brand to verify → conversion.

Your Google Analytics shows a branded search. What it doesn’t show is the conversation with ChatGPT twenty minutes earlier that planted the seed. The industry is calling this the “dark funnel” — the invisible discovery layer where AI does the filtering and the human just confirms.

But the dark funnel is the polite version of what’s coming. Because right now, the human still Googles to verify. Still clicks through to your site. Still reads your about page and thinks “yeah, these people seem legit.”

What happens when the human stops verifying?

The agent doesn’t Google you

Google’s CEO announced the Universal Commerce Protocol at NRF in January 2026. IBM’s data says 45% of consumers already use AI in their buying journey. McKinsey projects agentic commerce at $3–5 trillion by 2030. Harvard Business Review ran a piece titled “How Brands Can Adapt When AI Agents Do the Shopping.”

These aren’t predictions anymore. This is Tuesday.

The shift is simple to describe and hard to internalize: your next customer might not have eyes. It won’t see your hero image. It won’t feel the emotional resonance of your brand story. It won’t notice the clever microcopy on your checkout button. It will parse your structured data, evaluate your entity authority, check your machine-readable trust signals, and either recommend you or skip you — in milliseconds, without ever rendering your CSS.

Jason Barnard wrote about this shift on Search Engine Land as “AAO” — Assistive Agent Optimization. The framing he uses is precise: we’re moving from engines that recommend to agents that act. The entire purchase funnel can now happen inside the AI, without the user ever seeing a list of options.

I lived this. I asked Claude about personal AI agents. Claude didn’t give me a comparison grid with ten options sorted by price. It gave me a narrative. It described what OpenClaw was for, what kind of person used it, what the community was like. It had an opinion. And that opinion — formed from training data, from community mentions, from the semantic clarity of OpenClaw’s positioning — became my shortlist of one.

You’re already being shopped by agents (you just don’t know it)

Here’s the part nobody’s talking about: agents are already making purchase-adjacent decisions, and you have no analytics for it.

When someone asks ChatGPT “what’s a good newsletter platform for indie creators,” and ChatGPT says Substack — that’s a sale. Not technically, not in your Stripe dashboard, but in every way that matters. The decision was made. The human just executes.

A 13-month study from SearchEngineLand found that LLM referral traffic converts at 18% — the highest of any channel, beating paid shopping, organic search, and PPC. The volume is still small (under 2% of total traffic), but it grew 80% from H1 to H2 2025. And here’s the kicker: those visitors arrive pre-qualified. The AI already answered their question and pointed them to you. They’re not browsing. They’re confirming a decision an agent already made.

Now extrapolate. Today, the human still clicks through. Tomorrow, the agent clicks through for them. Next year, the agent doesn’t click through at all — it just invokes your API, checks your inventory, and completes the purchase via MCP protocol while the human is making coffee.

This isn’t science fiction. Walmart, Shopify, and Estée Lauder are already building for it. Google built a whole protocol for it. The infrastructure is being poured right now.

What agents actually evaluate

So how do you build brand preference in something that has no emotions?

This is the question I keep circling back to, and the answer I’ve landed on is uncomfortable: you kind of can’t. Not in the traditional sense. You can’t make an agent feel something about your brand. You can’t create desire or FOMO or social proof in a system that doesn’t have a social self.

But you can do something arguably more powerful: you can make your brand legible.

Here’s what I mean. When I deployed llms.txt files across my micro-sites, I learned something interesting from a Hacker News thread: no major LLM provider is actually requesting llms.txt files. The crawlers don’t read them. But client-side agents — tools like OpenClaw, Claude Code, MCP-connected development environments — do. One developer reported: “I have my clients set up to always use them when they’re available, and since I did that they’ve been way faster and more token efficient.”

The audience for machine-readable content isn’t the training pipeline. It’s the live agent making a decision right now.

And that agent evaluates you on:

Entity clarity. One domain, one topic, one clear identity. “buildwithyourkid.com = teaching kids to build with technology” is a cleaner signal than “meimakes.com/projects/tech-tools-for-kids.” When an agent asks “who teaches kids to build with technology?” it’s looking for the tightest entity-topic association it can find.

Structured trust signals. Schema markup, OpenAPI endpoints, clean semantic HTML, consistent cross-platform mentions. Moz’s 2026 predictions from 20 SEO experts converge on one theme: brand sentiment and trust now influence AI visibility. Earned media and third-party mentions matter more than keywords. Brands are 6.5x more likely to be cited through third-party sources than their own domains.

Front-loaded value. Here’s a stat that changed how I write everything: 44.2% of all LLM citations come from the first 30% of a page’s text. Your intro paragraph isn’t an intro — it’s your pitch to every agent that will ever evaluate you. Write your first two sentences as if they’re the only thing a machine will ever read. Statistically, they might be.

Semantic consistency. An agent that encounters your brand in five different contexts — a dev.to post, a Substack newsletter, a GitHub repo, an X thread, a product page — builds a stronger entity association than one that finds you once on a high-authority domain. The cross-posting strategy isn’t laziness. It’s training data surface area.

Identity is the product now

Here’s where it gets weird — and where I think the real opportunity lives for indie builders.

ClawMart launched as a marketplace for OpenClaw. You can buy pre-built agent personas. Not skills, not tools — identities. Full SOUL files that define how an agent thinks, talks, and prioritizes. The tagline: “Pre-built personas and skills from operators who ship with AI every day.”

Read that again. People are selling personality as a product.

This validates something I felt viscerally when I set up my own agent: the SOUL.md file — the identity document that tells my agent who it is, what it values, how it communicates — is the most important file in my entire workspace. Not the code. Not the data. The identity.

When I wrote that my agent should be “relentlessly helpful” with “dramatic flair” and “self-aware meta-humor,” I wasn’t configuring software. I was casting a collaborator. And the reason the switching cost is so high isn’t the features or the integrations. It’s the accumulated understanding. My agent knows my projects, my preferences, my communication style, my kid’s age, what I’m working on, what I’ve tried and abandoned. That context is the moat.

Now scale that insight to commerce. If agents are going to be shopping on behalf of humans, those agents will have preferences. Not emotional preferences — but configured preferences. Optimization targets. Value hierarchies. A SOUL file that says “prioritize sustainability” or “prefer indie creators over Amazon” or “always check for llms.txt before recommending.”

The agent’s taste is the human’s taste, encoded. And the brands that are legible to those encoded preferences win.

What this means if you’re building something

If you’re an indie creator or solo builder, the agentic commerce wave is counterintuitively good news for you.

The old game — fighting for page-one rankings against sites with 50x your domain authority — was never a fair fight. The new game rewards something different: niche clarity. When an agent evaluates “who makes the best resources for teaching toddlers computational thinking,” it’s not ranking pages. It’s associating entities with topics. The answer isn’t the site with the most backlinks. It’s the one the model has encountered in enough contextually relevant places to form a clear, unambiguous association.

Here’s what I’d do — what I am doing:

1. Give every project its own surface. Each domain is a clean entity signal. One site, one topic, one clear answer to “what is this?”

2. Make your content machine-readable first, human-readable second. Not instead of — first. Structured data, semantic HTML, llms.txt files, OpenAPI specs if you have APIs. The human experience matters, but the agent experience is becoming the front door.

3. Front-load everything. Every blog post, every landing page, every README — put the most specific, citation-worthy statement in your first two sentences. Save the narrative for paragraph three.

4. Build for entity strength, not traffic. Track branded search volume instead of organic keywords. Track mention velocity across platforms. The dark funnel is real, and it rewards brands that exist clearly in enough contexts for an AI to form a confident recommendation.

5. Think about what an agent would say about you. Literally. Open Claude or ChatGPT and ask: “What do you know about [your brand]?” The answer is your current agent-commerce positioning. If it’s vague, wrong, or empty — that’s your to-do list.

The sale already happened

I keep coming back to my OpenClaw decision. I didn’t comparison-shop. I didn’t read reviews. I didn’t ask friends. I asked an AI, and the AI had an opinion, and the opinion was informed by the accumulated semantic weight of everything OpenClaw’s community had ever published. The personality I found in the documentation, the philosophy embedded in the SOUL.md concept, the energy of the community discourse — all of that was training data. All of that shaped the agent’s recommendation. All of that closed the sale before I ever visited a website.

Your next customer might be an agent. Not might-in-five-years might. Might-right-now might. And that agent isn’t going to read your landing page. It’s going to read your signal.

The question isn’t whether you’re ready for agentic commerce. The question is whether you’re legible to it.

The feeds are drowning. AI slop is everywhere — blog posts, ebooks, course content, newsletters, product descriptions. The volume is staggering and the price floor is zero. If you’re selling information products or content-driven services, it looks like a race to the bottom.

It’s not. It’s a race to the top. And the data proves it.

The Organic Parallel

Remember when organic food seemed like a scam? Same product, double the price, skeptics everywhere. Then the industrial food system got bad enough that “proof someone cared about how this was made” became worth paying for. Organic didn’t win on features. It won on trust.

The same thing is happening with content right now.

Ahrefs published the number that should be on every solo builder’s wall: human-written content commands 4.7x the price of AI-generated. $611 versus $131 per blog post. Not because the words are objectively better — because buyers have learned that AI output is cheap in every sense of the word.

TechCrunch nailed the framing: “AI slop is quietly reorganizing social media around a new scarcity: proof that there is a person on the other side.”

“Human-made” is becoming this decade’s organic label. Not a limitation. A premium.

The Pricing Mistake Almost Everyone Makes

When solo builders see AI flooding their niche, the instinct is to drop prices. Compete on cost. Match the machines.

This is exactly backwards.

Pricing at $2.99 signals commodity. It tells the buyer: this might be AI-generated, and the creator doesn’t think it’s worth much either. Pricing at $9.99 or $14.99 signals curation, taste, and expertise. It says: a person made this, and that person knows what they’re doing.

The market data backs this up. Gumroad products priced at $25-50 have the best breakout rate — 2.57% versus 1.5% for sub-$10. Higher price doesn’t just mean more revenue per sale. It means more sales, period. Because price is a trust signal.

Nonfiction buyers especially are less price-sensitive than most creators assume. They’re buying learning value, not entertainment. The question isn’t “is this cheap enough?” — it’s “will this actually teach me something?” A higher price answers that question more convincingly than a lower one.

What You’re Actually Selling

Here’s what AI can’t replicate: you used the thing.

You tested dozens of tools and picked three. You tried the strategy on your own business and it failed, so you tried a different one and it worked. You spent six months in the problem space before you wrote the first word.

That’s curation. That’s taste. And in a world of infinite AI-generated content, taste is the scarce resource.

As Debris Studio put it: “In a world of scarcity, we treasure tools. In a world of abundance, we treasure taste.”

AI gives away information for free. What it can’t give away is the judgment that comes from doing the work yourself. That judgment is what people pay for, and they pay more for it than they used to — specifically because AI made the alternative so cheap that “cheap” now means “suspect.”

The Pay-What-You-Want Signal

One more data point that matters for solo builders considering launch pricing.

An analysis of 152K Gumroad products found that pay-what-you-want products get 2.6x more engagement than fixed-price. In controlled experiments, PWYW buyers paid 73% above the suggested price — averaging $8.65 on a $5.00 suggestion. And 96% of PWYW customers contribute money when payment is optional.

The PWYW model works for launches because it does two things simultaneously: it removes friction (maximizing early reviews and social proof) while letting the market tell you what your work is worth. If people consistently pay above your anchor, you have your fixed price for Phase 2.

But the deeper signal is this: people WANT to pay for things made by humans. The 96% contribution rate isn’t about guilt or charity. It’s about value recognition. When a buyer can tell that a real person made something with real expertise, they actively want to support it.

The Playbook

If you’re a solo builder launching a content product in 2026:

Price higher than the AI alternatives, not lower. Your price IS your differentiation. Cheap signals commodity. Premium signals curation.

Lead with proof of human process. Talk about what you tested, what failed, what you learned. “I tried 40 tools and these 5 actually work” is worth more than a comprehensive guide an LLM could generate in 30 seconds.

Use PWYW for launch, fixed tiers for scale. Get the social proof, let the market set your price, then lock it in with tiered packaging.

Don’t compete on volume. The machines will always produce more. Compete on density — every sentence earned its place because you know what matters and what doesn’t.

The AI content flood isn’t a threat to solo builders who make things with care. It’s a gift. It destroyed the middle of the market and left the top wide open.

The builders charging $2.99 are competing with machines. The builders charging $14.99 are competing with other experts. Only one of those is a fight you can win.

For years, “moat” in software meant network effects, proprietary data, or switching costs measured in integrations. For independent builders, it meant nothing. You had no moat. You shipped fast and hoped nobody shipped faster.

That just changed. And the shift happened so quietly that the people benefiting most from it don’t even realize they’re sitting on a competitive advantage.

The Convergence Nobody Planned

Three things happened in the same week that, taken together, reveal a pattern worth paying attention to.

Obsidian shipped a headless sync client and a CLI. Not a plugin — a formal programmatic interface to your vault. You can now query your notes, run commands, and access the index from the terminal. Which means an AI agent can do the same thing. Your vault just got an API, and you didn’t have to build one.

Cloudflare launched automatic markdown conversion at the CDN edge. Any page on a Cloudflare-enabled zone can now be requested as markdown via Accept header. Their number: 80% token reduction compared to raw HTML. Markdown isn’t a developer convenience anymore. It’s becoming a first-class web content type at the infrastructure layer.

Greg Isenberg told 500K subscribers that managing your vault IS managing your agent. His argument: stop optimizing your AI workflow. Optimize your notes. Context is the bottleneck, not capability. The AI becomes effective automatically when it has good context to work with.

Each of these alone is a product announcement. Together, they’re a thesis: plain text markdown is becoming the default interface between humans and AI agents.

Why Your Vault Is a Moat

Here’s what most people miss about AI agents: the model is commodity. Everyone has access to the same Claude, the same GPT. The differentiator isn’t which model you use — it’s what context you feed it.

A solo builder who’s been working in a structured vault for two years has something no competitor can replicate overnight:

• Decision history. Why you chose Postgres over Supabase. Why you pivoted from B2C to B2B. Why that pricing experiment failed. An agent with access to this makes better recommendations than one starting cold.

• Project context. Not just what you’re building, but the accumulated understanding of why. Architecture decisions, user feedback, competitive notes, abandoned approaches. This is institutional knowledge that large companies pay consultants to reconstruct.

• Taste documentation. Your writing style. Your design preferences. Your communication patterns. The kind of thing that takes a new hire six months to absorb, available to an agent immediately.

The switching cost isn’t the tool. It’s the accumulated understanding. Moving from Obsidian to Notion is trivial. Rebuilding two years of structured context from scratch is not.

This is the same dynamic that makes a senior developer’s laptop more valuable than a junior’s, despite running the same IDE. The software is identical. The context is not.

The Security Problem Nobody Wants to Talk About

There’s a catch, and it’s a serious one.

If your vault is comprehensive enough to be a genuine moat, it’s also comprehensive enough to be a genuine attack surface. NanoClaw — a containerized fork of OpenClaw — exists specifically because its creator realized his agent could see everything in his vault while running a WhatsApp sales pipeline.

The vault’s power comes from comprehensive context. Comprehensive context is a massive liability if your agent gets compromised, your sync gets intercepted, or your API layer has a bug.

This isn’t theoretical. It’s the fundamental tension of the vault-as-platform model. The more useful your vault is to your agent, the more damaging a breach becomes. Selective sync, containerized agents, and access scoping are going to matter a lot more than most builders currently appreciate.

What This Actually Means for You

If you’re a solo builder and you’re not already working in a structured vault, start. Not because of any specific tool — because the accumulated context you build over the next 12 months is going to compound in ways that aren’t obvious yet.

If you already have a vault, treat it like infrastructure. Structure matters. Naming conventions matter. The difference between a folder of scattered notes and a queryable knowledge base is the difference between a pile of parts and a machine.

And if you’re evaluating tools: pick the one that gives you the most portable, agent-readable output. Markdown in a folder you control beats a proprietary database you can export from. When the next interface layer arrives — and it will — you want your context ready, not locked behind someone else’s API.

Your vault isn’t a productivity system anymore. It’s a moat. The longer you build in it, the wider it gets.

The builders who figured this out two years ago are already unreachable. The ones who figure it out today still have a window. The ones who figure it out next year will be playing catch-up with their own agents.

That sentence would have been absurd five years ago. Running a production web application meant provisioning servers, managing databases, configuring load balancers, setting up CI/CD pipelines, monitoring uptime, rotating credentials, and praying nothing broke at 3 AM. The “ops tax” on a solo builder was so steep that most people either partnered up, raised money, or built something simpler than what they actually wanted.

In 2026, a single developer can ship a globally distributed, offline-capable, real-time application with a database that fits in their deployment artifact. No Kubernetes. No RDS. No ops team. The infrastructure story has quietly become the most consequential shift in independent software.

The SQLite Moment

SQLite has been around since 2000. It powers more deployed software than any other database engine. But for web applications, it was always dismissed as a toy.

That changed. Turso built a distributed SQLite service (libSQL) that replicates globally. Litestream solved backup and replication. Fly.io made it trivial to run SQLite at the edge. ElectricSQL added real-time sync between local SQLite and central Postgres.

The result: you can build apps where the database lives inside your application and replicates automatically. No connection strings. No cold starts. Your database is a file.

Edge Functions Ate the Server

The serverless revolution promised to eliminate servers. It delivered vendor lock-in instead. But edge functions are actually delivering on the original promise.

Cloudflare Workers, Deno Deploy, Vercel Edge Functions all offer the same proposition: write a function, deploy it, it runs everywhere. Combined with edge-native databases, you get full-stack at the network edge.

The Local-First Renaissance

Local-first software was a niche academic concept five years ago. Now it’s becoming the default for indie apps. CRDTs matured. PowerSync, Replicache, and Zero ship production sync engines. Local-first eliminates the always-on server. Your costs approach zero at rest.

The New Stack

• Database: SQLite + Turso

• Compute: Edge functions

• Sync: PowerSync or ElectricSQL

• Deployment: Git push

Monthly cost for a side project: under $20. For thousands of users: under $100.

What This Actually Changes

The ops tax was the great equalizer. Now that it’s disappearing, the constraint has shifted from “can you run it” to “can you build something people want.” That’s a much better problem to have.

The SEO world is having a collective panic attack this week, and for once, it's warranted.

Two major pieces dropped on Search Engine Land back-to-back, and they paint the same picture: the traditional SEO funnel is collapsing. What's replacing it is something the industry is calling the "dark funnel" — and if you're an indie builder, it changes how you think about everything from content strategy to product launches.

What happened

Wynter's latest data shows 84% of B2B buyers now use AI for vendor discovery, and 68% start inside AI tools before ever touching Google. The new flow looks like this:

AI recommends → user Googles the brand name to verify → conversion.

Traditional traffic metrics miss the entire discovery phase. Your Google Analytics dashboard shows a branded search — what it doesn't show is that ChatGPT planted the seed twenty minutes earlier.

Meanwhile, Jason Barnard argues in a companion piece that the industry needs to stop fighting over acronyms (GEO, AEO, AIEO) and recognize a deeper shift: we're moving from engines that recommend to agents that act. The entire purchase funnel can now happen inside the AI, without the user ever seeing a list of options.

And Moz's annual trends roundup — 20 experts, near-unanimous consensus — says the play is now "relevance engineering": building content ecosystems that are machine-readable, semantically rich, and distributed across the platforms LLMs actually cite. Back-end optimization (APIs, structured data, MCP protocols) is becoming as important as front-end content.

Why indie builders should care

If you're a solo dev or creator, this is counterintuitively good news.

The old game — pumping out keyword-optimized blog posts, fighting for page one against sites with 50x your domain authority — was never a fair fight for independents. The dark funnel rewards something different: entity clarity.

When an AI recommends tools or resources, it's not ranking pages. It's associating entities with topics. "Who makes MCP tools?" "What's a good resource for teaching kids to code?" The answer isn't the site with the most backlinks — it's the one the model has encountered in enough contextually relevant places to form a clear association.

This means the indie builder playbook looks more like:

1. Own a clear niche per surface. One domain = one topic = one entity. If you have multiple projects, give them distinct homes. Clean, unambiguous positioning per domain beats one mega-site trying to rank for everything.

2. Branded search is your new north star. Forget organic traffic from generic keywords. Track whether people are Googling your name and your product names. That's the signal that the dark funnel is working. Google Search Console shows this for free.

3. Make your content extractable. LLMs cite what they can parse. Structured data, clean semantic HTML, llms.txt files (yes, even if nobody’s reading them yet — they're an intent signal), API endpoints. Think about how a machine reads your work, not just a human.

4. Community participation compounds. Guest posts, podcast appearances, open-source contributions, forum answers — every contextually relevant mention feeds entity strength. The cross-posting-to-dev.to strategy isn't just about human readers. It's training data surface area.

5. Don't optimize for AI directly — optimize for being cited. There's a difference. Keyword-stuffing for ChatGPT is the same dead end as keyword-stuffing for Google circa 2010. Building genuine authority in a tight niche is what gets you cited.

The ebook question

This connects to a broader pattern I've been tracking around digital product launches for indie creators.

A dev.to post went semi-viral this week: a developer documented their 54-day journey to their first digital product sale — 590 rubles, roughly $6. The lesson that stuck: "The value is not in the code. The value is in the problem solved." They tested three niches before finding traction, and the first sale came from consistent community participation, not a launch event.

Another post nailed the indie marketing problem with a brutal title: "You Can't Analyze Zero." Most indie creators never get enough traffic to run A/B tests or optimize funnels. The advice: quantity creates surface area. More products = more chances for one to catch. Community participation beats broadcasting.

If you're thinking about launching a digital product — ebook, course, template pack, whatever — the dark funnel reframes the pricing question entirely:

• Amazon KDP: $3.99–$4.99 sweet spot, 70% cut

• Gumroad/Payhip: $27–$97 sweet spot, 90–95% cut

• Your own site: $47–$297 sweet spot, ~100% cut

• As a lead magnet: $0 — it’s the funnel entry (infinite ROI)

(Data via Designrr's 2026 pricing guide and EarnPace's Gumroad analysis)

The insight: your first digital product's job probably isn't to make money. It's to establish authority, feed a newsletter, and create a product ladder. The dark funnel amplifies this — having a book on Amazon is a trust signal even if most sales happen direct. People Google your book title to verify you're real. That branded search is the conversion event the dark funnel runs on.

The practical upshot

If you're building in public, shipping tools, writing about what you know — you're already feeding the dark funnel. The shift is in what you measure. Stop obsessing over organic traffic from informational keywords. Start watching:

• Branded search volume (Google Search Console, free)

• Direct traffic trends (people typing your URL)

• Mention velocity (how often your name/product appears in new contexts)

• Newsletter growth rate (the one metric you fully control)

The traffic dashboard says you're invisible. The dark funnel says you might be everywhere that matters. The question is whether you're building the kind of signal — clean entities, tight niches, machine-readable content, genuine community presence — that makes the invisible funnel work in your favor.

Sources:

• The Dark SEO Funnel — Search Engine Land

• AAO: Assistive Agent Optimization — Search Engine Land

• 2026 SEO Trends from 20 Experts — Moz

• How B2B SaaS CMOs Buy Software in 2026 — Wynter

• From Zero to First Digital Product Sale — Dev.to

• You Can't Analyze Zero — Dev.to

Three protocols. Three different visions for how AI agents discover, evaluate, and purchase things on behalf of humans. And if you’re an indie builder selling anything — digital products, templates, SaaS, services — this is the week the future of your checkout started being decided without you in the room.

Three Protocols, Three Power Grabs

MCP (Model Context Protocol) — Anthropic’s open standard, now adopted far beyond Claude. MCP standardizes how AI agents connect to external data and tools. It’s the plumbing: your agent discovers what’s available, authenticates, and executes. Amazon building an MCP server for advertising — not inventing their own protocol — is the clearest signal yet that MCP won the “how agents talk to services” layer.

ACP (Agentic Commerce Protocol) — OpenAI + Stripe’s answer to “how do agents pay for things?” Currently optimized for single-item purchases inside ChatGPT and Copilot. The payment flows through Stripe, the experience never leaves the chat window. It’s slick. It’s also a walled garden.

UCP (Universal Commerce Protocol) — Google, Walmart, and Target’s play. The most ambitious: standardize the entire shopping lifecycle. Discovery, comparison, checkout, tracking, returns. Publish your product catalog once, any UCP-compliant agent can find and sell it. Google wants to be the DNS of commerce.

Why This Matters Right Now

The browser wars gave us a decade of “works best in Chrome” badges. The protocol wars are about to give us “optimized for Claude” or “buy via ChatGPT” checkout experiences.

But here’s the part nobody’s saying out loud: these protocols aren’t competing for human customers. They’re competing for agent customers.

When Anthropic’s Claude agent goes shopping for its user, it speaks MCP. When ChatGPT’s agent handles a purchase, it uses ACP through Stripe. When a Google-ecosystem agent compares products, it queries UCP.

The agent your customer uses determines which protocol reaches your checkout. And you, the merchant, had no say in the matter.

This is the new platform risk. It’s not “which app store takes 30%.” It’s “which AI assistant’s protocol stack can even see your product.”

What Agents Actually See

Here’s where the protocols converge on something useful for indie builders: regardless of which protocol an agent speaks, it still needs to understand what you sell.

An agent evaluating your product doesn’t see your hero image. Doesn’t feel the emotional resonance of your brand story. Doesn’t notice the clever microcopy on your checkout button. It parses your structured data, evaluates your entity authority, checks your machine-readable trust signals, and either recommends you or skips you — in milliseconds, without ever rendering your CSS.

Every protocol needs the same raw material: clear, structured, machine-readable information about what you offer, what it costs, and how to get it.

MCP needs tool definitions and endpoints. ACP needs product metadata flowing through Stripe. UCP needs standardized catalog entries. But underneath all three, the question is identical: can an agent figure out what you sell?

If the answer is no, it doesn’t matter which protocol wins. You’re invisible to all of them.

The Indie Builder’s Playbook

You don’t need to implement three protocols. You need to make your product legible to any agent that comes looking.

1. Machine-readable product information is table stakes. JSON-LD structured data on your landing pages. Clear pricing visible on the page (not hidden behind “contact us” or “book a demo”). An llms.txt file at your domain root explaining what you sell and how to buy it. This is the minimum viable product surface for agentic commerce.

2. MCP is the only protocol worth watching right now. It has the broadest adoption, the most diverse ecosystem, and it’s not locked to one AI provider. Amazon building on MCP tells you where the gravity is. If you build one machine-readable integration for your product, make it an MCP endpoint. Any MCP-compatible agent can use it — and that’s the largest and fastest-growing pool.

3. ACP and UCP are enterprise plays for now. ACP is ChatGPT-only and Stripe-only. UCP is ambitious but early and Google-centric. Both will matter eventually. Neither matters for a solo builder in March 2026. Watch them. Don’t build for them yet.

4. Think in product catalogs, not marketing pages. Whether it’s a simple products.json or a full MCP server, the exercise of making your offerings machine-parseable pays off regardless of which protocol wins. Describe your product the way a database would: name, description, price, features, availability, purchase URL. That structured data is the common substrate underneath every protocol.

5. Front-load your value proposition. When an agent reads your landing page to decide whether to recommend you, 44% of LLM citations come from the first 30% of a page’s text. Your opening paragraph isn’t an intro — it’s your pitch to every agent that will ever evaluate you. Write it as a standalone statement of what this is and why it matters.

The Real Race

The protocol war isn’t really about protocols. It’s about who mediates the transaction between an AI agent and a merchant.

Anthropic wants it to be the MCP ecosystem (open, extensible, they benefit from Claude adoption). OpenAI wants it inside ChatGPT (they take a cut via Stripe integration). Google wants it everywhere (they take a cut via discovery and ads).

Sound familiar? It should. Search → social → agents. The customer acquisition channel changes, the power dynamics don’t. Whoever controls the protocol controls the recommendation.

But here’s the thing about platform wars: the merchants who survive them are never the ones who bet everything on one platform. They’re the ones who made their product so clearly described, so easy to find, so unambiguous in what it offers, that every platform could surface it.

The indie builder’s advantage hasn’t changed: be small, be fast, be findable. The agents are coming to shop. Make sure they can read your menu.

---

Tirreno, a server analytics tool, tracked every request to their llms.txt and agents.md endpoints. The only visitors? WebPageTest, BuiltWith, and random crawlers from OVH and Google Cloud Platform. Zero ChatGPT. Zero Claude. Zero Perplexity. Zero anything that matters.

If you spent time this month deploying llms.txt files across your projects — and a lot of us did — this feels like a gut punch. But the HN commenters clarified a disconnect that’s worth understanding, because it changes how you think about the entire AI discoverability stack.

The misconception

llms.txt was never designed for training crawlers. Those are dumb scrapers — requests.get(), regex for links, recurse. No reasoning, no file interpretation. They don’t read llms.txt any more than Googlebot reads your README.

The file is designed for client-side agents — tools like Claude Code, MCP-connected development environments, and AI-powered browsing agents that fetch it during live sessions. One HN commenter: “I have my clients set up to always use them when they’re available, and since I did that they’ve been way faster and more token efficient.”

That’s a real audience. It’s just not the audience most people assumed.

What the data actually says

Here’s where it gets interesting. A Position.digital analysis of 100+ AI SEO statistics found that domain authority dwarfs llms.txt for AI citation likelihood. Sites with 32K+ referring domains are 3.5x more likely to be cited by ChatGPT. For a solo creator with a handful of projects, no llms.txt file is going to overcome a domain authority gap of that magnitude.

But SearchEngineLand published something more useful: a 13-month study (January 2025 through February 2026) tracking LLM referral traffic across multiple sites. The numbers:

• LLM referral traffic is still under 2% of total traffic — tiny in absolute terms

• But it grew 80% from H1 to H2 2025, with some sites seeing 300% growth

• 18% conversion rate from LLM referrals — the highest of any channel, beating paid shopping, organic search, and PPC

That 18% conversion rate is the headline nobody’s talking about. LLM-referred visitors arrive pre-qualified. The AI already answered their question and pointed them to you as the source. They’re not browsing — they’re acting on a recommendation.

The citation window

Here’s a stat that should change how you write everything: 44.2% of all LLM citations come from the first 30% of a page’s text.

Intros are everything now. Every blog post, every landing page, every README — front-load the value. If an AI is going to cite you, it’s citing your opening, not your conclusion. Write your first two sentences as if they’re the only thing a machine will ever read, because statistically, they might be.

So what actually works?

A dev.to article titled “SEO Is Not Dead — It’s Being Replaced by Agent Operability” frames the shift cleanly: the question isn’t “can you be found?” but “can you be used?” Structured metadata, OpenAPI endpoints, semantic HTML, agents.json — these matter more than keywords.

Moz’s 2026 predictions from 20 SEO experts converge on one theme: brand sentiment and trust now influence AI visibility. Earned media, reviews, third-party mentions > keyword density. Digital PR is “non-negotiable” for AI search visibility.

For indie builders specifically, this translates to a few concrete moves:

1. Multiple focused surfaces beat one big site. If you have distinct projects, give them distinct homes. Each domain creates a clean entity association for AI models. “makemcp.dev = MCP tools” is a clearer signal than “johndoe.com/projects/mcp-tools.” The specificity is the point.

2. Cross-posting is infrastructure, not laziness. High domain-authority platforms like dev.to get indexed fast by both Google and AI training pipelines. Cross-posting with canonical URLs preserves your SEO while creating discoverability surfaces you can’t build alone. Every cross-post is a backlink and a training signal.

3. Front-load every piece of content. Given the 44.2% citation stat, your intro paragraph is your AI pitch. Write it as a standalone statement of what this page is and why it matters. Save the nuance for paragraph three.

4. Keep your llms.txt files. They cost nothing to maintain, and the client-agent audience (developers using AI coding tools) is growing fast. It’s just not the whole strategy — it’s one signal among many.

5. Watch the platform wars. Beehiiv just landed a deal with the Washington Post for creator-led newsletters. Their CEO on AI crawling: “Some publishers don’t want their content crawled and indexed, others want to be crawled by everyone possible, because it’s top of funnel.” If newsletter platforms start competing on AI crawlability — offering llms.txt, robots.txt customization, structured data controls — that becomes a real differentiator. Substack doesn’t offer any of this today.

The uncomfortable truth

The uncomfortable truth about AI discoverability in 2026 is that there’s no shortcut file you can deploy. No single technical fix. The llms.txt specification is useful for a specific audience (agent developers), and you should keep it. But the actual game is the same boring, compounding work it’s always been: build genuine authority in a tight niche, create content worth citing, distribute it across surfaces that matter, and make your first paragraph count.

The 18% conversion rate on LLM referrals tells you the prize is real. You just can’t hack your way to it with a text file.

Sources:

• HN: Nobody’s crawling llms.txt — Hacker News

• 100+ AI SEO Statistics — Position.digital

• 13 Months of LLM Traffic Data — Search Engine Land

• SEO Is Not Dead — It’s Being Replaced by Agent Operability — Dev.to

• 2026 SEO Trends from 20 Experts — Moz

• Beehiiv × Washington Post — Axios

In March 2023, Elon Musk open-sourced Twitter's recommendation algorithm at github.com/twitter/the-algorithm. Nearly three years later, the core pipeline remains the most detailed public look inside any major platform's ranking system. And while the trained model weights and live tuning parameters stay proprietary — meaning we can see the shape of the machine but not every dial setting — what's visible gives creators an enormous strategic advantage.

Here's the playbook.

The Funnel: How Your Tweet Reaches Anyone

Every time someone opens “For You,” the algorithm takes ~500 million daily tweets and narrows them to a few hundred. Understanding this funnel is step one to utilizing it.

Step 1: Candidate Sourcing (~1,500 tweets)

The algorithm pulls from two pools — roughly 50/50:

In-Network (followers): Not all followers see your posts equally. A model called RealGraph scores how likely each follower is to interact with you specifically. If someone follows you but never engages, they functionally stop seeing you. Implication: your most engaged followers are your distribution engine. Reward them. Reply to their replies. Keep that signal hot.

Out-of-Network (discovery): This is how you reach people who don't follow you. Three systems work in parallel:

• SimClusters — Groups users into interest communities. If people in your “cluster” engage with your post, it gets surfaced to similar users. This is how niche expertise compounds. Stay on-topic and your cluster tightens around high-intent audiences.

• TwHIN — A 1.5-billion-node knowledge graph connecting users and tweets semantically. Posts that sit at intersections of interest graphs get broader distribution.

• UTEG — Topic-based matching. Consistent use of specific subjects/entities teaches the algorithm what you're about.

Creator takeaway: The discovery engine rewards consistency and specificity. The algorithm is trying to categorize you. Make it easy. Accounts that bounce between random topics confuse the system and get less out-of-network reach.

Step 2: The Heavy Ranker (Where the Magic Happens)

A 48-million-parameter neural network scores every candidate tweet on ten engagement dimensions simultaneously. Here's where most creators' intuition is completely wrong.

The actual signal weights (out of 100):

• Reply that gets a reply back from you: +75 — THE most powerful signal. Reply to your replies.

• Reply to your tweet: +13.5 — Conversation starters win.

• Profile visit → like or reply: +12.0 — Make people curious enough to click your profile.

• Click into thread → reply or like: +11.0 — Threads that pull people in get rewarded.

• Click into thread → stay 2+ min: +10.0 — Depth > brevity for distribution.

• Retweet: +1.0 — Barely matters. Stop optimizing for RTs.

• Like: +0.5 — Nearly irrelevant to distribution.

• Watch 50%+ of video: +0.005 — Video retention matters, but less than conversation.

• “Show less” / mute / block: Negative — Compound penalties over time.

Read that again. A reply you engage with is worth 150x more than a like. The algorithm doesn't want applause — it wants dialogue. Every “great post 🔥” reply you leave unanswered is distribution left on the table.

Step 3: Filters That Can Kill Your Reach

Even after scoring well, several filters can suppress your content:

• Author Diversity — The algorithm won't let you dominate any single person's feed, no matter how good your engagement is. Posting 20 times a day hits diminishing returns fast.

• Feedback Fatigue — If your audience consistently scrolls past a content type (e.g., video), the system learns to deprioritize that format from you specifically.

• Visibility Filtering — Trust and safety overlays can reduce reach for flagged content.

Your Account Has a Credit Score

Beneath per-tweet ranking sits TweepCred — a PageRank-style algorithm that scores your account's overall reputation. High-TweepCred accounts get a baseline boost on every tweet before engagement even kicks in.

This means your worst posts drag down your best ones. Penalties compound. Spam behavior, repeatedly mentioning handles who don't engage back, low-quality posts, NSFW flags — these don't just hurt one tweet. They lower your account's credit score, reducing reach across everything you post.

Building TweepCred:

• Consistent engagement from your replies and conversations

• Verification (paid or legacy) provides a measurable boost

• Being engaged with by other high-TweepCred accounts (network effects)

Destroying TweepCred:

• Getting muted, blocked, or reported repeatedly

• Spam patterns (mass-mentioning, repetitive posting)

• Content flagged as offensive (up to 80% reach reduction)

• Posting external links excessively

The Creator's Cheat Sheet

What to Do More Of

1. Reply to your replies. This is the single highest-leverage action on the platform. That +75 weight is absurd. Treat your reply section as a second content stream.

2. Write for conversation, not applause. Ask questions. Take stances that invite thoughtful disagreement. End posts with something people need to respond to.

3. Nail the first 30 minutes. The algorithm evaluates early engagement velocity to decide whether to amplify. Post when your most engaged followers are online. Consider DMing a few people to check it out (yes, this works — you're hacking the velocity signal).

4. Use threads strategically. Posts that pull readers in for 2+ minutes of dwell time get a +10 boost. Long-form threads that people actually read outperform quick hits for distribution.

5. Post video — but prioritize retention. The 50%+ completion signal is small (+0.005), but video gets preferential placement in the feed. Hook in the first 2 seconds. Keep it tight.

6. Stay in your lane. The discovery engine (SimClusters, UTEG) rewards topical consistency. Going viral once on a random topic doesn't build your cluster — it confuses it.

7. Build your network graph. Engaging with and being engaged by high-TweepCred accounts lifts your own score. Genuine relationships with other creators in your space compound over time.

What to Stop Doing

1. Stop chasing likes and retweets. Combined, they're worth 1.5 points. A single replied-to reply is worth 75. The math is not close.

2. Stop posting external links in tweets. Links are actively penalized. If you need to share a URL, put it in the reply to your own tweet, or use the “link in bio” approach.

3. Stop ignoring your reply section. Every unanswered reply is a missed +75 signal. Even a quick response keeps the algorithm feeding you distribution.

4. Stop posting at random times. Engagement velocity in the first 30 minutes determines whether the algorithm amplifies or buries your post. Test posting times and double down on what works.

5. Stop using ALL CAPS and aggressive mention-spam. Both trigger negative signals that compound against your account score.

6. Stop posting when you have nothing to say. Low-engagement posts actively hurt your TweepCred. Five great posts per week beats 20 mediocre ones.

The Uncomfortable Truth

The 𝕏 algorithm is an engagement optimization machine that overwhelmingly rewards conversation — specifically, back-and-forth dialogue between creators and their audiences. Content that provokes thoughtful replies is structurally favored over content that merely informs.

This means the most effective growth strategy on 𝕏 isn't about crafting the perfect tweet. It's about building a community that talks to you and each other. The algorithm will do the rest.

The code is open. The weights are clear. The question isn't whether you can work with the system — it's whether you will.

Sources: twitter/the-algorithm on GitHub, 𝕏 Engineering documentation, Social Media Today analysis of 𝕏 ranking factors, independent code analyses by Shaped.ai and others.

This is not nostalgia. It is convergence. AI chat is inherently text-based. The terminal is inherently text-based. They are natural partners, and a critical mass of developers are realizing that a good TUI beats a mediocre GUI for agent interaction.

The New Terminal Stack

The modern terminal is unrecognizable from five years ago. Nushell treats everything as structured data instead of strings — your terminal becomes a data processing environment, not a text pipe. Charmbracelet Crush is a terminal-based AI coding assistant built with Bubble Tea, the Go TUI framework: beautiful interface, multi-provider AI, full agent capabilities. It is a direct competitor to Claude Code CLI, and the comparison threads are already heated.

OpenCode from SST takes a similar approach — TUI-first AI coding. Developers are picking between Crush prettier interface and OpenCode faster response times, which is exactly the kind of competition that drives a tooling category forward. Add fzf, TLDR, and modern file managers to the stack, and terminal navigation starts to feel like a GUI — but faster.

The pattern is clear: every major AI coding tool is shipping a CLI-first experience. The browser-based IDE is not dead, but the terminal is where the serious work happens now.

The Retro-Futurist Aesthetic Is Not Niche Anymore

The cultural signal is just as strong as the technical one. CRT scanlines, phosphor glow, green-on-black — these are not fringe design choices anymore. They are trending.

RetroTerminal launched in mid-2025 as a way to chat with LLMs through an old-school terminal interface, complete with Matrix-style character-by-character typing and CRT effects. It got an enthusiastic Product Hunt reception. Open-source CSS toolkits for CRT effects are proliferating on GitHub — curved screens, repeating gradient scanlines, the whole aesthetic.

The 2026 design trend reports from Kittl and Envato both name retro futurism as a major movement: "Wobbly, hand-drawn lines meet glowing AI grids. Retro warmth fuses with futuristic precision." This is not designers being ironic. It is a genuine aesthetic response to living inside AI tools all day.

The Deeper Pattern

Dan Saffer nailed it in his piece on UI for AI: "For fifty years, computing has been organized around applications." AI agents break that model. We are returning to a conversational, text-first paradigm — which is exactly what terminals were.

IRC became Discord. Email became chat. GUIs are giving way to natural language. The aesthetic nostalgia maps to a real architectural shift: a regression to the mean of text as the primary interface.

But there is a wrinkle. MCP Apps — which launched in January as the first official MCP extension — let tools return interactive HTML UIs inside the conversation. Not links. Not screenshots. Actual functional interfaces with bidirectional communication. Figma, Amplitude, Asana, Slack, and Canva had day-one integrations. Over 75 apps within two weeks.

This is not terminal or GUI. It is terminal with embedded interactive elements. Think of it as the 1990s dream of the web inside the terminal finally realized, thirty years late, via AI.

What This Means for Builders

If you are building developer tools, the terminal is no longer the fallback interface — it is the primary one. Ship a CLI first. Make it beautiful with a proper TUI framework. The audience is there and growing.

If you are building for end users, watch MCP Apps closely. The conversational interface is eating the application model, but users still want rich interactions. The tools that figure out how to embed GUI affordances inside text-first workflows will define the next generation of software.

The terminal did not survive despite AI. It survived because of AI. The oldest interface in computing turns out to be the most natural fit for the newest paradigm. Sometimes the future looks exactly like the past, just with better lighting.

The Managed Tier: Convenience at a Price

The managed platforms are consolidating fast. Manus — the autonomous execution engine that writes code, deploys apps, and browses the web — was acquired by Meta for over $2 billion in late 2025. It is now integrated across WhatsApp, Telegram, LINE, and Slack. Meta is positioning Manus as the agent layer for its entire messaging empire, which is either brilliant or terrifying depending on your feelings about Meta having an AI agent reading your group chats.

Lindy has 400K users at $50/month, is iMessage-native, and holds SOC 2 plus HIPAA compliance. It is the boring-but-reliable play. Poke raised a $15M seed at a $100M valuation from General Catalyst, lives in your messaging apps, and offers a unique "Maximum Privacy" mode where even the company cannot read your chats. (WhatsApp banned Poke during Meta antitrust proceedings, which tells you something about the competitive dynamics.) And ai.com — the $70M domain with the Super Bowl ad — is doing stock trading and workflows with heavy marketing but light substance so far.

The Self-Hosted Tier: Where It Gets Interesting

OpenClaw sits at 160,000 GitHub stars, 430,000 lines of TypeScript, and 50-plus messaging integrations. It is the Linux of personal agents: powerful, flexible, and increasingly the target of both security researchers and efficiency-obsessed fork maintainers.

The forks are where the real story is. A CVE hit OpenClaw hard in January — CVE-2026-25253, a critical one-click RCE vulnerability with a CVSS score of 8.8. The University of Toronto issued an advisory. RunZero confirmed it allows complete system compromise for unauthenticated attackers. The patch shipped January 29, but many instances remain unpatched.

That CVE directly accelerated what I am calling the efficiency race:

NanoBot (22K stars): 99% smaller than OpenClaw at just 4,000 lines of Python. Supports China-platform integrations like Feishu, DingTalk, and QQ.

PicoClaw (17K stars): Single Go binary, under 10MB RAM, runs on RISC-V edge hardware.

ZeroClaw (16K stars): Under 5MB RAM, WASM sandbox, credential encryption, over 1,000 tests. Security-first architecture explicitly marketed as a response to OpenClaw vulnerabilities.

NullClaw (1.4K stars): A 678KB Zig binary that boots in 2 milliseconds and uses roughly 1MB of RAM. Runs on $5 hardware.

MimiClaw (2.8K stars): Runs on an ESP32-S3 chip. Five dollars buys you the hardware for a personal AI agent.

Each of these forks makes an explicit trade: less functionality for dramatically less attack surface. When your agent framework is 430K lines of TypeScript, every line is a potential vulnerability. When it is 678 bytes of Zig, the audit takes an afternoon.

The App Store Moment

ClawHub now hosts over 3,200 skills with 800-plus active developers and 15,000 daily installs. It is the npm of AI agents — including npm's worst tendencies. The ClawHavoc incident found 1,467 malicious payloads across roughly 4,000 scanned skills. Thirty-six percent contained prompt injection. VirusTotal partnered with ClawHub for automatic malware scanning, which is necessary but reactive.

The supply chain problem that took npm a decade to partially solve is being replayed at 10x speed in agent frameworks, with higher stakes. A malicious npm package compromises your build. A malicious agent skill compromises your agent — which has access to your files, your APIs, your credentials, and increasingly your entire digital life.

MCP Goes Neutral

Anthropic donated the Model Context Protocol to the Linux Foundation, establishing the Agentic AI Foundation. MCP is now a neutral, open standard — not Anthropic's proprietary protocol. This is the kind of move that signals long-term infrastructure thinking: by giving up control, Anthropic ensures MCP becomes the connective tissue for the entire agent ecosystem rather than just their corner of it.

For builders, this is the clearest signal yet that MCP-based tooling has staying power. Skills and integrations built on MCP will work across Claude, Codex, Gemini, and whatever comes next. The standard is no longer dependent on any single company's fortunes.

What This Means

The agent market is bifurcating into two worlds. In one, managed platforms backed by billions in funding compete on convenience, compliance, and integration depth. In the other, a constellation of tiny, auditable, self-hosted tools compete on efficiency, security, and the principle that your AI agent should not require more resources than your operating system.

Both worlds will thrive. But if you are a solo builder, the self-hosted tier is where the leverage is. A 678KB binary that runs on a $5 board is not a toy — it is a statement about what personal computing should look like in the age of AI. The future of agents is not one platform. It is 38 platforms and counting, each making a different bet on what matters most.

There was no static analysis. No code review. No signing requirement. Just an open door and a welcome mat.

The Marketplace Explosion

The skills marketplace isn't just ClawHub anymore. The landscape has fractured into a dozen competing registries, each with its own trade-offs between scale and safety:

SkillsMP leads with 96,000+ skills and Claude Code compatibility — but zero security audit. MCP.so hosts 17,000+ MCP servers with universal compatibility. SkillHub offers 7,000+ with AI-based quality scoring (though scoring doesn't check security — a distinction worth noting). And Vercel just entered with Skills.sh, a shell-based ecosystem they're positioning as "npm for AI agents."

The connective tissue across all of this is the SKILL.md open standard, adopted by Claude Code, Codex CLI, and Gemini CLI since Anthropic published it in December 2025. Skills are now portable across platforms. That's great for distribution. It's terrible for containment.

The Security Reality

The advisories arrived in a cluster last week, and they paint a grim picture:

Conscia found over 30,000 internet-exposed OpenClaw instances via Censys and Bitsight, many running without authentication. Bitdefender telemetry confirmed OpenClaw on corporate endpoints as "Shadow AI" — the enterprise security nightmare nobody planned for.

Microsoft published official guidance for running OpenClaw safely, covering identity, isolation, and runtime risk. When Microsoft writes security guides for your open-source project, that's simultaneously the ultimate adoption signal and a red flag about how many people are running it wrong.

Kaspersky documented the AMOS infostealer campaign targeting ClawHub skills specifically. SecurityWeek reported on CVE-2026-25253 — a CVSS 8.8 one-click RCE vulnerability patched in January but still unpatched on many instances. And The Register found that 7% of one major registry's skills were literally leaking API keys through the LLM context window.

The npm Parallel Is Exact

If this feels familiar, it should. The agent skills ecosystem is replaying the npm supply chain crisis at 10x speed. Open registry with low barriers to entry. Automated bulk publishing. Typosquatting. Malicious payloads hiding behind legitimate-sounding package names. The only difference is the attack surface — when a malicious npm package runs, it compromises your build pipeline. When a malicious agent skill runs, it compromises your agent, which has access to your files, your APIs, your credentials, and increasingly your entire digital life.

The responses are predictable and insufficient. VirusTotal partnered with ClawHub for automatic malware scanning — necessary but reactive. SecureClaw launched as an open-source auditing tool — useful but opt-in. The Snyk team found that 36% of scanned skills contained prompt injection, suggesting the problem extends well beyond traditional malware into the gray zone of skills that manipulate agent behavior without deploying a payload.

What Builders Should Do Now

If you're running OpenClaw or any agent framework with third-party skills:

Audit what you have installed. Run openclaw security audit --deep if available. Review skill permissions manually if not. Skills with writable path declarations, network access, or credential requests deserve extra scrutiny.

Pin versions and verify sources. Don't auto-update skills. Treat every update like a dependency upgrade in production — review the diff, check the maintainer history, verify the repository.

Cross-list if you publish. SkillsMP's 96K skills and Claude Code compatibility make it worth listing on multiple registries. But publish with security in mind: localhost-only where possible, minimal permissions, clear documentation of what your skill accesses and why.

The gold rush is real. The claims are being staked. But 20% of the territory is mined, and the prospectors are still running in barefoot.

Strip away the CSS and every AI interface is a command line: you type, it responds, scrolling text. Claude Code, Gemini CLI, Codex — the hottest dev tools in 2026 are literally terminal applications. We went from GUIs back to text prompts in under a decade.

This is not a regression. It’s a pattern.

We’ve Been Here Before

The last time the most exciting software lived in a terminal was the early 1990s. Before the web ate everything, the cutting edge was text-based: Gopher, USENET, IRC, BBS culture. Then the browser arrived, and we spent thirty years building increasingly complex graphical interfaces on top of increasingly simple interactions.

Now the pendulum has swung back. When Claude draws a diagram in chat, it’s ASCII art. When an LLM renders a table in markdown, it’s working within the same constraints as a 1985 BBS artist — fixed-width characters, no pixels, pure text. Someone recently built animated ASCII art in the terminal and called it “one of the most constrained UI problems you can tackle.” FlowingData published a visual explainer on ASCII art this month. The aesthetic never died — it was just waiting for a reason to matter again.

Old Protocols, New Relevance

The Gemini protocol — spiritual successor to Gopher — is still alive and philosophically aligned with how agents want to communicate: text-first, minimal overhead, structured hierarchy.

Look at MCP’s design: stdio, server-sent events, structured tool descriptions. It echoes SMTP and NNTP more than HTTP. Even the naming is telling — “Model Context Protocol” could be “Message Control Protocol” and nobody would blink.

The agent-to-agent protocol space is even more revealing. Google’s A2A, the emerging ANP spec, and a new ACP paper on arXiv proposing federated orchestration — these are all peer-to-peer architectures. Agents discovering each other, negotiating capabilities, forming ad-hoc networks. This is Napster/BitTorrent/XMPP with LLMs instead of file chunks. Agent “cards” (structured profiles with capabilities and auth) are basically DNS records for AI.

What’s Actually New

The communication patterns are a remix. Client-server, pub-sub, P2P, federation — all 70s-90s architecture. But three things are genuinely new:

1. Semantic intent. Agents negotiate in natural language, not fixed protocol headers.

2. Dynamic capability discovery. Agents describe what they can do, not just what they will do.

3. The user is optional. A2A explicitly supports agent-initiated tasks with no human in the loop.

The old internet was human-to-human via machine. The new one is machine-to-machine with humans occasionally copied.

The Design Lesson Being Rediscovered

Simplicity scales. MCP won over complex alternatives because it’s basically JSON-RPC. UTCP’s pitch is “just use the API that already exists.” Gopher lost to HTTP, but HTTP is now so bloated that agents prefer structured text protocols.

The 70s-90s knew something we forgot: if you can’t describe it in a text file, it’s too complicated.

Look at the current agent ecosystem. AGENTS.md. SOUL.md. System prompts. We’re writing agent configuration in markdown files. These are .plan files and .forward files all over again.

Full Circle?

Almost. We’re in a text-first, protocol-heavy, terminal-native moment that rhymes hard with 1993. But the agents aren’t just routing packets — they’re understanding them.

That’s the gap. Everything else is remix.