How we think about agentic demos
Not a list of fabricated papers. This page is our actual engineering approach, written plainly, with a link to the real technical writeup behind it.
Interaction
A demo agent is only useful if it responds the moment a visitor has a question, in the moment their interest is highest. That's why the agent speaks whatever it has to say before executing any browser action, since a visitor should never sit in silence while the system "thinks." Latency budget is treated as a first-class constraint, not an afterthought.
Grounded knowledge
The agent only ever answers from what it can see on the page plus an explicit product-knowledge file, never from general model knowledge about what a product "probably" does. This is a deliberate constraint: a fluent wrong answer about pricing or a feature that doesn't exist is worse than the agent saying "I don't know."
What we've actually learned building this
Real notes from building the product, not marketing copy. Longer writeups live on the blog.
Numbered-element navigation beats raw selectors
Why we hand the model a plain numbered list of clickable elements instead of asking it to write CSS selectors.
The screenshot feedback loop matters more than the reasoning loop
Why we spent more engineering effort on re-orienting the agent after every action than on the decision logic itself.
Voice latency is a three-vendor problem
Speech-to-text, the language model, and text-to-speech are three independent points of failure. Each is designed to degrade independently.