Let's invent the wheel: an agentic store

"Don't reinvent the wheel" is good advice when you need to ship. I'm less sure it applies when you want to learn. In this series, I want to try small UI ideas, see where they work, and write about where they don't.

What if a store showed you one thing?

I started with a question: what would shopping look like if an assistant could understand what you need and already knew your preferences? You might ask for headphones, see one suggestion, ask about the details, and decide whether to buy. No catalogue to work through first.

Show the answer, then let me ask

The demo shows one pair of headphones: name, price and rating. Ask for specs and numbered markers appear on a rotatable CSS illustration. Reviews bring a sample summary. The video option opens fictional review notes, not a player.

One result is easy to read, but it gives the store a lot of power. Why this product? What else fits? A useful assistant would let you question and compare, not hide the alternatives.

The controls still matter

The conversation looks like voice, but every reply is a button. On a train, you may not want to speak; some people can't, others prefer a keyboard. If I add speech input, it should remain a choice.

Who builds the interface?

Here the page and its answers are written in advance. What if a store supplied products and permitted actions, while an assistant chose what to show as you ask? This demo does not build the interface on demand.

I'd want to continue shopping on a phone, or any other smart device. That would require compatible product data, permissions and a safe purchase handoff. This prototype solves none of that.

The interface should belong to the person using it. They choose where the answer appears, see why an item was suggested, and approve the purchase. That still leaves questions: how do you discover new products, where does the brand belong, and who checks an interface assembled on the fly?

What can be ready before checkout?

The sample profile has an address, a card description and a preferred colour. You choose delivery and confirm. No order is placed or card charged.

Saved details might reduce typing, but a real purchase still needs identity, payment and consent checks. A passkey can help sign someone in without giving the website the credential's private key. It does not approve payment on its own.

The Web Crypto API signs and verifies sample data with a temporary key in your browser. That is real cryptography, not proof of identity or permission to pay. The story continues even if this step is unavailable.

The Model Context Protocol connects AI applications with tools and data. WebMCP is an experimental proposal for exposing page functions to browser agents. Neither powers this demo or makes every store work with every assistant. WebMCP keeps human control in the picture, which feels right for a purchase.

Before trusting a real version, I'd ask: why this item, what am I approving, and where can I see or correct what happened?

What I take from this

Starting with one answer and revealing details on request feels promising. But earning trust in that answer and the final confirmation is harder than drawing a clean screen.

That's the point of this series: try an idea, keep what works, and say what is missing. It returns to my question in Bringing value now matters more than ever: just because we can build something, should we?