This is a condensed version of my preprint (DOI: 10.5281/zenodo.21345310, CC BY 4.0). Reference implementation: askbar.pro.
The library problem
For thirty years the website has been a library: a visitor arrives with one question and is expected to find the answer themselves, navigating menus, pages, and filters. Visitors read a small fraction of site content. Most leave without doing the thing the site owner hoped for. Chat widgets bolted onto such sites change nothing: the maze remains, the widget just answers questions about the maze.
The pattern
The Librarian Pattern inverts the relationship. The site does not present itself; it asks what you need and assembles the answer.
- The bar as the primary interface. One persistent input, text and hold-to-talk voice. It replaces navigation.
- Scene reassembly (generative UI). The center of the screen is not a page but a scene, composed per recognized intent. Transitions morph rather than reload.
- A guide with a plan. The conversational layer is a consultant with a goal ladder, asking one next question, never presenting menus of three options.
- Two button systems. Global suggestion chips above the bar are visually separated from in-scene action cards. This prevents the "six buttons" degeneration of chat UIs.
- The static shadow. Every live scene has a server-rendered twin page: full text in the DOM, question-shaped headings, direct answers with facts, freshness stamps. Humans get the agent; crawlers and AI answer engines get complete, citable pages, generated from the same content source.
- Structural GEO-readiness. Content already organized as questions and answers matches how generative engines retrieve and cite, by construction.
The result that surprised me
24 hours after the discoverability layer went public, Yandex Alice (the largest Russian AI answer engine) began citing the reference implementation as its prime example for the "next-generation website" query, describing the mechanics correctly and distinguishing it from "a chat widget in the corner". One week earlier, equivalent queries returned nothing. Screenshots are dated and timestamped (OpenTimestamps + Wayback).
The lesson generalizes: as search migrates from ranked links to generated answers, the unit of discoverability shifts from the page to the citable answer. A site structured as a dialogue is preferentially legible to engines whose whole job is answering questions.
Honest positioning
Conversational UIs, chatbots and AI site builders all predate this. What I'm documenting is the specific combination (bar as THE interface + model-assembled scenes + goal-driven guide + dual-face static shadow) as a single reproducible pattern, with a verifiable date and a production implementation. Full details, provenance and limitations are in the preprint.
Author: Eduard Gutarin, founder of AskBar.
Top comments (2)
The “static shadow” idea is the sharpest part of this for me. A lot of generative-UI concepts sound compelling until discoverability, citation, and operational debuggability show up; keeping a server-rendered twin page from the same content source is a much more serious answer than bolting a chat box onto a traditional site.
I also like the framing that the hard problem is not just replacing navigation with a bar, but keeping the experience structurally legible for both humans and retrieval systems. That’s usually where these ideas either turn into a real product architecture or collapse into an impressive demo with no dependable content layer behind it.
The implementation detail I’d be most curious about is state inspection. Once scenes are reassembled dynamically, what artifacts do you keep so teams can replay why a given intent produced a given scene and debug regressions when the conversational layer changes?
Thanks, this is exactly the layer I hoped someone would poke at.
On the shadow: yes, the discipline is that the human-facing agent view and the robot-facing SSR twin come from one content source, so they can't drift. The twin isn't an SEO afterthought, it's the same facts rendered for a reader that doesn't run JS.
On state inspection, agreed that this is what decides product vs demo. The key design choice: scenes are not freely generated markup. The conversational layer returns a {speak, scene_key} contract, where scene_key comes from a fixed, versioned set of scenes, not open-ended UI generation. That constraint is what makes it debuggable:
Every turn is logged as (intent/query, context: current scene + input mode, chosen scene_key, output), so you can replay exactly why a given intent produced a given scene.
Because the model picks a key from a known set rather than emitting layout, a regression is "wrong key chosen for this intent", which is diffable across versions of the conversational layer.
The rendering layer (what a scene_key draws) is decoupled from the reasoning layer (which key to pick), so you can change one without silently breaking the other.
The trade-off is honest: you give up unbounded "generate any UI" flexibility for legibility and replayability. For something a team has to operate, that's the right trade. Free-form generative UI is the impressive-demo path you mentioned; the fixed-scene contract is the boring-but-dependable one.
Happy to go deeper on any of it.