How It Works
In the demo above, imagine a documentation site for a writing tool people love.
Users search. Click. Browse. Scroll through articles. Hit 404s. Rage-click on text that doesn’t respond.
On the right, an agent interprets what they’re trying to do.
Press Play to see how users interact.
Agents notice. Log behavior. Interpret intent. Maintain a manifest.
When a signal crosses a threshold, the agent makes a call:
Pave — “Users’ desire is real and the path is right.” The feature exists but was never documented. The agent decides to build the page. You watch it happen: a title appears with a blinking cursor, paragraphs fade in line by line, code blocks slide into place. The sidebar grows a new entry.
Redirect — “The desire is real, but the path is wrong.” In the demo, users search for "dark mode,” but the app follows the system theme by design. The agent doesn’t build a dark mode page. It builds an appearance guide that explains the design decision and shows how to change your OS theme. A different path than the one they walked, but it goes where they needed.
Refuse — “The desire is real, but the path would damage what the product is.” A strong cluster of searches for "AI writing" triggers a decision. But agent says no. It knows this a writing tool built around focus and doesn’t add AI generation just because people asked. The refusal defines the product.
By the end, seven articles have become fourteen. Five paved, two redirected, one refused.
Notes from Building
Demand isn’t direction, it’s information. “Desire paths,” as we’re defining them, are easy to detect. Searches, 404s, dead clicks, scroll depth. Most products already have this data. It’s logged and sitting in dashboards. What’s missing isn’t visibility. It’s interpretation. The signal tells you something is happening. It doesn’t tell you what to do about it.
Desire paths don’t just show intent, they create pressure. A few people hit a dead end. Then a few more. Then it keeps happening. The signal builds across searches, 404s, and dead clicks. Over time, it starts to feel like direction. But it’s not direction, it’s a question: “Is this something the product should do?” That question doesn’t have a universal answer. It depends on the product.
The system needs judgment, not just response. In the demo, a pattern emerges around AI writing. Strong signal, clear demand. But this is a writing tool built around focus and quiet. The absence of suggestions is the feature. Adding autocomplete because people asked doesn’t improve the product, it breaks it. A system that responds to every signal ends up with no point of view. Every path gets paved and the product becomes a reflection of demand instead of a shaped thing.
Sometimes the signal is right, but the words are wrong. People search for “API.” The system could generate API docs. But the agent looks closer. These users are coming from the Notebooks page and are trying to get their data out. The product doesn’t have an API and shouldn’t pretend it does, but it does have export and a CLI sync tool. So the system responds to the intent, not the query, and builds a page about data portability instead.
And sometimes, the signal isn’t a decision, it’s a miss. Users keep looking for collaboration features that already exist: real-time editing, shared notebooks, link sharing. All shipped, none documented. That’s not a judgment call, that’s a gap. The system doesn’t debate it, it fixes it.
Every product is shaped by what it chooses not to build. Desire paths will always surface things users want that the product doesn’t do. The work is deciding which ones reveal a gap, which ones need translation, and which ones should be refused.
The page that doesn’t exist defines the product more than the ones that do.
