I have already violated my own rule about great ideas that I posted about last week. But that is how it goes! Although I haven’t told the team, they probably have already noticed this and wonder, is this the next item on the Kanban board? So I need to be careful. After playing around with clawd.bot over the weekend it struck me how insanely convenient a Agent-Driven User Interface would be to the clawd.bot wizard.
We have spent the last several months obsessing over NFC technology for Trevean Spice. The idea: you tap your phone to the lid of a spice jar lid, and information appears. Recipes. Origin stories. Pairing suggestions. Simple enough.
Except it’s not simple. Because every piece of information requires a screen. And every screen requires a decision about what users want to see at that moment. Do they want the recipe? The farmer’s story? The substitution guide because they’re out of cumin?
I was three wireframes deep into a “recipe discovery flow” when I stumbled across something Google quietly released a few weeks ago. They’re calling it A2UI—Agent-driven User Interface.
Here’s the premise: instead of designing screens that anticipate user needs, you design components that an AI agent assembles on demand based on what the user actually wants.
My first reaction? This sounds like vaporware. Another “the future is coming” prediction from someone who doesn’t have to ship product this quarter.
Then I realized: I’ve been designing screens for months. What if I should have been designing building blocks? Anyone rember object code programming?
What A2UI Actually Means (Without the Hype)
Google’s former CEO Eric Schmidt has been saying that “user interfaces as we know them are going to go away.” Users will express intent conversationally, and UIs will be generated on the fly.
That’s the vision. Here’s what’s actually happening right now.
A2UI is a protocol that enables an AI agent to determine when a user needs an interactive interface and what that interface should contain. Instead of a predetermined screen, the agent assembles components based on context.
The classic example: booking a restaurant.
A text-only chatbot would ask you a dozen questions. “What day?” “What time?” “How many people?” You already said 5 pm tomorrow for four people, but it didn’t catch that.
An A2UI-enabled agent recognizes that this task is better handled with a form. It generates a booking interface with a date picker, time selector, and party size—pre-filled based on your request. You tap submit. Done.
This isn’t theoretical. Google says they’re already using A2UI across products, including Opal, their mini-app platform.
What This Means for Product Leaders (The Trade-offs Nobody’s Talking About)
Here’s the thing about agent-driven interfaces: they shift the design burden, but they don’t eliminate it.
The old model: you predict what users need, design a screen for that need, and hope you guessed right.
The new model: you create components with clear semantic purposes, and an agent assembles them based on real-time context.
That sounds like less work. It’s not. It’s different work.
What you gain: You stop guessing. The agent figures out what to show based on what users actually ask for. For small teams, this is huge—you can offer personalization that used to require massive data science investments.
What you lose: Control over the narrative. If you’ve carefully crafted a user journey that tells a story—origin first, then recipes, then pairings—the agent might skip straight to the utilitarian answer. “Here’s a recipe. Bye.”
For Trevean Spice, this trade-off hit me hard.
The Gaming Industry Already Figured This Out
Here’s the thing—this isn’t actually new thinking. The gaming industry has been doing this for years.
Think about Mass Effect. The entire trilogy is built on a simple premise: your choices create your experience. You make a decision in the first game—save a character, betray an ally, romance someone—and the consequences ripple through sixty hours of gameplay across three titles.
BioWare didn’t design one story. They designed components of a story—characters, dialogue branches, plot beats—and the game assembled your personal narrative based on decisions you actually made.
Or take Baldur’s Gate 3, which came out in 2023 and broke everyone’s brain. The game is absurdly reactive. You can kill a major NPC in the first hour, and the game doesn’t break. It adapts. Different characters step into different roles. Quests resolve through alternate paths. The system has enough well-defined components that it can assemble a coherent experience even when players do things the designers never predicted.
The contrast with traditional game design is instructive.
Old model: designers create a linear experience. Players follow the path. Deviation is punished with invisible walls or “you can’t do that.”
New model: designers create building blocks with clear purposes. The system assembles them based on player behavior. Deviation becomes a feature, not a bug.
Sound familiar?
That’s exactly what A2UI does for product interfaces. Instead of predetermined screens that assume user intent, you create components that the system can assemble based on actual context.
The gaming industry learned something product teams are just starting to understand: you can’t predict what users want in the moment. But you can give the system enough well-designed pieces that it can respond intelligently to whatever they throw at it.
The trade-off in games is the same trade-off in product: you lose authorial control. The carefully crafted narrative moment you designed might be skipped if the player makes different choices. In Baldur’s Gate 3, you can miss entire companion storylines based on early decisions. That’s the cost of responsiveness.
For games, players have decided the trade-off is worth it. The personalized experience beats the perfectly authored one.
I’m betting the same will be true for product interfaces.
The Trevean Spice Problem (And Why I’m Rethinking My Approach)
My NFC strategy has been: tap the jar, see a screen I designed, experience the story I want to tell.
But let me be honest about what that actually requires.
I need a recipe lookup screen. A substitution guide screen. An origin story screen. A pairing recommendation screen. A “what goes with this spice” screen. A “I’m out of this, what can I use instead?” screen.
That’s six predetermined flows. Each one assumes I know what the user wants at the moment of tap. I don’t.
Here’s what an agent-driven approach would look like instead.
User taps the jar. A conversational prompt appears: “What are you making tonight?”
User says: “Chicken curry, but I’m out of garam masala.”
The agent assembles a response: a substitution guide showing which spices to combine, a related recipe, and a one-tap option to add garam masala to their next order.
I didn’t design that screen. The agent assembled it from components I created: a substitution database, a recipe library, and a commerce module.
The user got exactly what they needed. Fast.
But here’s what bothers me: they never saw the origin story. They never learned about the farmer in Kerala who grew the cardamom in that jar. The agent optimized for task completion, not for the experience I wanted to create.
The Real Question: What Are You Actually Designing For?
This is where it gets uncomfortable.
If I’m honest, I’ve been designing for me. For the story I want to tell. For the journey I think users should take.
Agent-driven interfaces force a different question: what do users actually want in the moment?
Sometimes they want the story. More often, they want the answer.
The shift isn’t just technical. It’s philosophical. You stop being the author of a fixed experience and start being the curator of components that can be assembled in ways you didn’t predict.
For product leaders, this means:
Your design system matters more than your screens. If your components don’t have clear semantic purposes—if they’re just visual elements without meaning—an agent can’t assemble them intelligently.
Your content strategy becomes as important as your visual design. The agent needs structured information to work with. Unstructured content is useless.
Your “optimal flow” is a fiction. Users don’t follow paths. They have tasks. Build for tasks, not paths.
“What I’m Actually Going to Do”
Confession time: I’m not abandoning my NFC screens. Not yet.
A2UI is real, but it’s not ubiquitous. Most users still expect to tap something and see a familiar interface. The hybrid approach makes sense for now.
But here’s what’s actually changing in my Figma files this week.
I used to have a document called “Recipe Discovery Flow.” Seven screens. Entry points, filters, results, and detail views. Beautiful predetermined journey.
I’ve renamed it “Recipe Component Library.” Same information, different structure. Each element now has two descriptions: what it looks like (visual spec) and what it does (semantic purpose). The “cooking time badge” isn’t just a UI element—it’s a filter criterion, a sort option, and a decision-support tool depending on context.
That sounds like a small change. It’s not. It means my designer and I now talk about components in terms of jobs-to-be-done, not screen placement. When an agent eventually assembles these pieces, it’ll know that the cooking time badge is useful when a user says, “I only have 20 minutes.”
The trade-off I’m accepting: the agent might never show users my carefully sequenced origin-to-recipe-to-pairing journey. They might get the answer and leave. That bothers me. But it bothers me less than building six screens nobody uses because I guessed wrong about what they wanted.