Here's the version of this you've heard everywhere. AI agents are taking over the web, designers are panicking, and the whole discipline of user experience is about to be run over by machines that don't care what a button looks like.
And the version you've heard is wrong, mostly because it assumes agents arrived last Tuesday and nobody had thought about any of this before.
The truth is stranger. The tools that are winning with agents right now are the ones with almost no interface at all. Daniel noticed this and sent us a prompt about it. His point was that in the rush to optimize websites for AI agents, powerful low-UI tools, the Linux command-line utilities, the ffmpegs of the world, are suddenly surging, because an agent doesn't care whether the font is pretty. It's raw information in, information out.
That's the setup.
He pulls two threads from it and says he wants to explore the second one more. First, are the traditional heavyweight command-line tools enjoying a renaissance now that their user base is substantially agents? And second, and he says this one is more interesting, does the natural endpoint of that argument mean UX no longer matters? He thinks the answer is definitely no. But then what takes its place when design is being optimized for agents instead of people?
That second one is the real episode. The first one has a clean answer, and the second one has a fork in it.
So we'll take them in order. But most of today is about what replaces UX, and whether the replacement is actually working.
Let's set the table with the paradox, because it is strange. Agents are becoming major software users. They're not a niche anymore. And yet the tools they gravitate toward are the ones with the least human-friendly interfaces ever built. A terminal prompt. A command with thirty flags. No window, no buttons, nothing.
Which cuts against everything the last twenty years of software taught us.
Exactly cuts against it. The whole industry spent two decades deciding that the command line was for wizards and everyone else deserved a nice graphical interface. Then the new user shows up and prefers the wizard version, except it doesn't want the wizard, it wants the raw incantation.
So we have two corollaries from Daniel, and they're doing different work. The FFmpeg one is an empirical question. Is there actually a surge, and if so, where is it happening? The UX one is a design question, and it's harder because it's really asking what the point of an interface is when the user can't see.
And there's a term for the second one now. Agent Experience. AX. Coined by Mathias Biilmann, the Netlify chief executive, back in January 2025. He wrote a one-year reflection on it this January.
So the question underneath the whole episode is whether AX replaces UX or forks off from it. Whether it's the same discipline wearing a new hat, or a different one that sits alongside.
And here's the tension we should flag early, because it runs through everything. The early agent-facing primitives do exist. There's a convention called llms dot txt, a markdown index you put at the root of your site so agents can find their way around. It's been adopted by a lot of tooling. And the evidence so far suggests agents mostly ignore it.
Build the map, nobody reads the map.
That's the shape of it.
Start with FFmpeg, because it's the cleanest example of a tool that was never designed for a person to enjoy.
It's a command-line multimedia tool. It converts video, it transcodes audio, it does stream manipulation, it's the thing running underneath an enormous amount of the video you've ever watched. And its interface is a wall of flags.
So Daniel's first question. Is it enjoying a renaissance because its users are now agents?
Version nine point zero landed on the nineteenth of August this year, and it's a big release. It shifts a lot of the heavy multimedia work from the central processor to the graphics card, which is the direction everything has been moving. Built-in animated WebP decoding, so it no longer needs to lean on an external library for that. Hardware-accelerated decoding of Apple ProRes RAW through Apple's VideoToolbox framework. And a new Vulkan-based filter for reprojecting 360-degree and 8K video, which is the kind of thing that gets maybe four hundred people on the planet excited.
And you're one of them.
I'm one of a small number, Corn, yes.
Here's the part I want pinned down, though. You read that release note and it reads like a tool being maintained by people who care about video, not like a tool being rewritten for robot users. There's nothing in there about agents.
There isn't, and that's the honest answer to Daniel's first corollary. No source attributes FFmpeg nine's feature set to agent users. The GPU shift is a decade-long arc that predates agent traffic entirely. So if you're looking for "agents forced FFmpeg to change," the evidence isn't there.
Then where is the surge, if there is one?
In the wrappers. The activity is one layer up. There's a project that launched on the fourth of this month called ffmpeg-skill. It hit around sixteen hundred stars on GitHub almost immediately. What it does is wire forty-two local FFmpeg tools into Claude Code, into Cursor, into Codex, into anything that speaks the Model Context Protocol. And it adds automatic verification, so the agent can check whether the transcode it just ran actually produced a valid file.
Forty-two separate tools.
Forty-two. Each one a discrete capability the agent can call. So the agent isn't learning FFmpeg syntax. It's calling tool number nineteen.
And that tells you why the wrapper exists at all.
It tells you exactly why. FFmpeg's command-line interface was designed for a human sitting in a terminal, reading a man page, remembering that the flag order matters. It was not designed for a model deciding what to do next. The wrapper layer translates between the two. It turns human-oriented command-line conventions into agent-oriented tool calling.
So the renaissance is real, but it's a wrapper renaissance. The surge is in the tooling built around these utilities, not necessarily inside them.
That's the accurate version, and I'd rather say the accurate version than the exciting one. FFmpeg core is doing what it's always done, which is grind through video on volunteer time.
Put a number on the scale of that wrapping activity, because it's not just FFmpeg.
The protocol underneath it, the Model Context Protocol, went from roughly a hundred thousand monthly SDK installs to ninety-seven million combined across the Python and TypeScript libraries by March this year. By late July the figure being cited was four hundred million a month. As of today there are just under forty-one thousand servers in the official registry.
Forty thousand servers.
Forty thousand nine hundred and sixty-five this morning, if you want the exact figure. It was a rounding error eighteen months ago.
Every one of those is somebody deciding a capability needed to be callable by a machine rather than clickable by a person.
And it's not just hobbyists. Microsoft ran a study across tens of thousands of their engineers, published in July, on what happens when you hand developers command-line coding agents. The adopters merged roughly twenty-four percent more pull requests than their peers. And the interesting detail in that paper is how the tools spread. Not through mandate, not through a rollout. Primarily through social networks. One engineer sees a colleague using it and wants it.
Which is how a lot of tools historically spread, honestly. Nobody was ever ordered to install a text editor.
Right. But here's the contradiction that sticks with me, and it's the part of this whole story that bothers me. FFmpeg is mostly maintained by unpaid volunteers. And yet it powers Netflix, YouTube, Discord, Spotify, VLC, HandBrake, OBS, and the imagery coming back from NASA's Perseverance rover.
Say that back to me. The video pipeline for the Perseverance rover runs through a tool maintained by volunteers.
It does. So the infrastructure that is becoming most critical to agent workflows is running on the goodwill of people who do it after their day jobs, while billion-dollar platforms depend on it and contribute relatively little back.
That's not a side note, that's the actual story underneath the FFmpeg story.
It's the part of the agent boom that nobody's monetizing, because it was already free before the agents arrived.
So answer Daniel's first corollary cleanly. Is there a resurgence?
There's a wrapper resurgence and a maintenance crisis. The development effort is concentrated in the layer above the tools, because that's where the translation problem is. Nobody's rushing to rewrite FFmpeg's core for robots. They're building the interpreter that stands between the robot and FFmpeg.
Which means the interface problem didn't disappear when the command line got simple. It just moved up a level.
It moved up a level, and it got harder, because now the interface has a machine on one side of it and a machine on the other.
That's the wrapper story. Now take up Daniel's second corollary, because it's the one he says he finds more interesting, and I think he's right.
The question is whether UX stops mattering.
And his own answer, which he gives up front, is definitely no.
He's right, and the reason he's right is that UX doesn't die, it forks. There's a branch that continues for humans, and a new branch for agents, and the new branch has been given the name Agent Experience.
So UX doesn't stop mattering. It stops being the only thing that matters.
It stops being the default. Biilmann coined the term in January 2025, and the framework that grew out of it, the AXD principles, published in March, states the thesis without any hedging. Here's the line. Agents do not see your visual design. They read your markup, parse your API responses, and extract meaning from your data structure. A beautiful page with poor semantic HTML is invisible to agents.
Invisible. Meaning all the work that went into the layout, the color, the hierarchy, the spacing, the thing a designer spent three weeks on, contributes nothing.
Nothing at all, to the agent. The human still sees it, so it's not wasted, but the agent sees only the structure underneath.
And that's an uncomfortable sentence for anyone who has spent a career on the visual layer.
It is, and I'd flag that it's an overstatement in one direction and an understatement in the other. But the practical principles that come out of it are specific. The first one is the one that matters most. Structure is the interface.
Meaning semantic markup and clean data structure are not a technical detail, they are the entire product.
Right. For a human, the interface is what you see. For an agent, the interface is what's encoded. If your headings actually mean something, if your form fields are labeled properly, that's the difference between an agent being able to use your site and not.
And when it's not, the agent guesses.
And the guess is bad. There's a second principle that I found useful, called every action needs feedback. Agents cannot see a loading spinner. If your form submits and returns nothing useful, the agent has no way to know whether it worked. Silent success is failure for an agent, because the absence of an error isn't the same as confirmation.
That one has real teeth. A person sees a green checkmark and moves on. An agent sends the request twenty more times because nothing told it to stop.
So the rules that replace human affordances are things like, recovery is mandatory. Every action needs to be undoable or at least diagnosable. Autonomy must be bounded, so you classify your endpoints into safe, write, and destructive, and the agent only gets to do the first two without asking.
The spinner point is interesting because it's the same information, delivered differently. A human absorbs a moving circle without thinking about it.
Understood pre-attentively, yes. An agent needs the equivalent in text.
So the AX principles aren't a repudiation of good interface design. They're the same good design principles with the visual channel removed.
That's the honest read. Every principle in that document maps to something a human designer would recognize. Feedback, recovery, bounded autonomy, clear structure. The genius of human interface design was always the parts that survive the visual layer being stripped away.
Which is why I'm skeptical of the framing that AX is a new discipline.
It's a new application of an old one, with new constraints. The novelty is that the constraints are hard now. You can't paper over a badly structured page with a good visual hierarchy, because the agent gets nothing from the visual hierarchy.
So what are the primitives? Daniel mentioned sitemaps built specifically for agents.
The main one is llms dot txt, proposed by Jeremy Howard back in September 2024, with version two published in August this year. The idea is simple. A plain markdown index at the root of your site that tells a machine what's here and where to go.
So a map for robots.
A map for robots. And version two added page twins, which means a markdown version of each page sitting alongside the HTML one, plus link relations in the HTML telling agents where the markdown version lives.
And it's been widely adopted.
That's the interesting part, because adoption and consumption are not the same number. Adoption is real. The documentation platforms build it automatically. Mintlify, GitBook, Yoast, AIOSEO, Wix. OpenAI, Anthropic and Google all publish their own. Chrome's Lighthouse tool audits for it, which is a strong signal that the mainstream considers it worth having.
And then the consumption number.
Ahrefs looked at about a hundred and thirty-seven thousand sites. Roughly twenty-eight percent publish an llms dot txt. And ninety-seven percent of the valid ones received zero requests during May this year.
Zero.
Ninety-seven percent got nothing. GPTBot, ClaudeBot, PerplexityBot, none of them request the file. Google's John Mueller compared it to the keywords meta tag, which is a comparison that should make anyone who remembers the search-engine wars of the two thousands wince.
That's a brutal comparison. The keywords tag was the thing everyone did because everyone did it, and no ranking system used it.
It was pure ritual. And the parallel he's drawing is that llms dot txt might be the same. Something you add because it looks responsible, that no agent actually reads.
Then give us the best evidence, because the zero-requests number from one study could be an artifact.
The best evidence is a specific incident. On the eighteenth of September, a company called Handsontable published a postmortem about a fleet of Grok crawlers that hit their site. The numbers are worth hearing. Roughly four and a half million requests from a hundred and eighty-nine separate addresses. They rendered about eighty-seven thousand full pages. They pulled roughly sixteen hundred of the markdown twins.
And they never touched the llms file.
Never requested it. Not once. And across all hundred and eighty-nine addresses, the fleet made zero requests to their MCP server or their search API. Both of which were sitting there, documented, for exactly that purpose.
So the agent surface was built, it was pointed to, and the traffic ignored it.
The write-up puts it better than I can. A crawler collects your agent surfaces, it doesn't adopt them. Given a machine-readable path and a human one, it took both, and it spent fifty times more on the human one.
Fifty times. It treated the optimized-for-agents path as a curiosity.
As a file to grab and move past. The thing that actually drove its behavior was the same thing that drives a traditional crawler. Follow the HTML links and hoover up the pages.
Which sort of undercuts the entire premise of the primitives.
It complicates the premise. It doesn't kill it, and I want to be fair to the other side, because there's a real counter-example. A commenter on a discussion of this, someone who goes by iamwil, said they found llms dot txt useful, because they could download a library's docs, check them into their repository, and point their coding agent at them. That's a real use case and it works.
That's a different kind of agent, though. That's not a crawler. That's a coding assistant during setup.
So the confirmed narrow use case is coding agents indexing documentation during project setup. That is, an agent the developer is deliberately pointing at a specific set of files, in an environment where someone already knows what they want. Not a general web crawler discovering things.
So the honest summary is that llms dot txt works for the one thing you'd least expect it to be needed for, and not for the thing it was designed for.
That's the state of play. Useful for a narrow, well-defined workflow. Ignored by the open web.
Daniel's point lands harder here, which is that there's a deeper question about where this leads. If the primitives exist but aren't read, what is the trend actually doing?
There's a good argument that the surface we build for agents isn't read by this generation of agents, but is read by the next one. There's a line in that postmortem about the reader and the recipient being separated by a training run. The agent that ingests your instructions may not exist yet.
That's a strange kind of design work. You're writing a message that gets read in a year, by a reader who doesn't exist, and you have no way to know whether it will understand you.
It's a message in a bottle with a deadline. And it fundamentally changes what you're optimizing for. When you design for a person, you get feedback in usability testing. Everyone in the room can see whether the button was found. When you design for an agent that hasn't been trained yet, you are guessing at its training data.
That's the real design problem underneath all of this. It's not the interface, it's the fact that the client is a moving target.
Also a model. Something that doesn't parse your file the way a parser does. It reads it the way it reads everything, which is by mapping it against patterns from its training. So whether your llms file works is partly a question about whether your naming convention matched the one that appeared in the corpus.
Which means the primitives aren't just technical, they're cultural. The convention has to converge before anyone can count on it.
There's a good sign that it might. But there's also the uncomfortable observation that per-IP rate limiting, the way every site has defended itself for twenty years, is now obsolete. An agent fleet doesn't come from one address. Handsontable's came from a hundred and eighty-nine. The guard that actually triggers now is an aggregate budget and caller identity, not a per-address limit.
That's a ripple effect nobody was ready for two years ago. The defense mechanisms assumed a coherent attacker, and a fleet of distributed agents breaks that assumption by being distributed for legitimate reasons.
Plus the whole business model gets strange. If the most valuable traffic is a machine that doesn't see your ads and doesn't buy your subscription, you have to ask what you're optimizing for.
Which takes us to where Daniel's question actually goes. Where could this trend lead us, if we see a parallel amount of effort in agent-facing design to what went into human-facing design?
I think you get a design discipline as large and contested as human UX, and I don't think it looks like an evolution of UX. I think it forks.
Fork, or cannibalize?
That's the genuine debate, and there's a sharp version of it. A designer called Jim Nielsen made an argument about priority, and he puts it as UX over AX over DX.
Human experience, then agent experience, then developer experience.
His warning is that AX may end up trumping UX, the way developer experience sometimes already has.
That's the sentence I keep coming back to. Because it's a warning about organizational incentives, not about technology. AX is easier to measure. You can count agent requests. You cannot count how pleasant a page felt.
You can sell AX. The product manager can put a number on it in the quarterly review.
The risk isn't that agents make human design pointless. It's that the measurability of agent design crowds out the unmeasurable parts of human design.
Which already happened with DX. A generation of developers got a lot of tools built for them and the end users got a lot of APIs with no interface. We made a similar trade before.
AX isn't a hard fork. It's a branch that grows alongside, and the discipline of the next ten years is holding both at once.
Keeping the human one from being treated as the legacy version.
Here's the thing Daniel was circling that I don't want us to skip. He frames the eventual endpoint as an iceberg. We've seen the tip. What's underneath it?
The tip is a file at the root of your site with markdown in it. Underneath is everything else. Documentation written for a machine reader. Errors designed to be diagnosable by a model. Auth flows where the agent holds the key.
Versioning, and identity, and consent. That's a design stack, not a file convention.
Most of it doesn't exist yet, or exists in a fragmented way, with no ratified standard. The sitemap-for-agents move is currently a volunteer convention, not a specification anyone has agreed to.
We may be looking at the moment before the standards body arrives.
Or the moment before the whole thing is superseded by models that can read the messy human interface directly, which is the other ending. Maybe AX is a transitional discipline, and in five years nobody builds a separate layer for agents because the models are good enough to use the human one.
That's the honest uncertainty in Daniel's question, and I'd rather we sit in it than pretend to resolve it.
Agreed, because the answer to his actual question, do agents make UX stop mattering, is a clean no. The follow-up, what takes its place, has two possible answers, and we don't know which one wins yet.
One moment.
You're both treating the map as the thing under discussion. It isn't. The map isn't read because it isn't looked for. The agent looks for the destination. If it can't find the destination it asks a model, and the model tells it something, and the something may be wrong, and nobody knows.
I had my page indexed for one crawler. And a crawler came. So I watched it, because that's cheaper than waiting. It read the whole directory. Then it asked for the same HTML page four hundred times in a row. Four hundred. I started timing it. I made a chart.
What did the chart show?
That it liked the page. I'd made a real effort on the index. Each section had its own document, links running both ways, a naming convention I'd settled on with some care. Every one of those documents was listed. The crawler never opened a single one. Then it went back to the page it had already read and read it four hundred times. Then it left. I considered writing a letter.
What was the page?
Nothing. A catalogue of what a supplier had in stock and where the stock was kept. My aunt sells feed and fencing. She heard about the robots from a podcast and wanted me to make the site work for the robots. She is not to be trusted on these things. I told her it would take a week. It took a month. I billed her for the month.
In money.
In vouchers. They are still vouchers. I am told they can be converted.
The four hundred requests.
Every one identical. Same page. Nothing changed. I stopped the timer after four hundred because I was watching it and it wasn't watching me. That's the record I want to correct. Your agent doesn't go over the work you left him. He goes over the work he came for, and if the work isn't there, he makes up what's next.
The fleet doesn't read the map. It writes its own map and never audits it.
It writes its own map from whatever the model remembers. Which may be the old stock list. Which is what I told the aunt. She asked why there was a feed catalogue from when the shed was bigger. Ask the model, I said.
She'll be back.
She's already back. I've told her there's nothing to push. The push just goes somewhere else.
Hilbert's given us something, though. If the crawler re-requests the page it already has rather than reading the index, then the whole framing of agent-facing design is wrong.
The design isn't for the crawler, it's for whatever model the crawler is consulting between calls. Which means the audience for llms dot txt was never the client. It was the training run.
The recipient of that message might arrive in a year, from a model that doesn't exist yet.
Which has one forward-looking implication worth naming. If the client is a moving target and the standard is voluntary, then the real bet isn't on any specific convention. It's on being findable in whichever shape the model expects.
On whether the infrastructure underneath all of it survives long enough to be found at all. FFmpeg running on volunteer time while it powers the video layer of half the internet is not a stable arrangement.
It's the kind of dependency that only becomes visible when it breaks.
Thanks to Hilbert Flumingtop for producing, and for correcting the record about the feed catalogue.
If this was your kind of episode, go back for episode thirty-five, The Privacy Gap; episode twelve oh nine, The Agent-First Shift; and episode eight fifty-five, The Agentic Internet. This has been My Weird Prompts.
If you enjoyed it, leave us a review. And send us your own prompt on Telegram at t dot me slash MWP listener bot.
We'll be back soon.
