Design & ProductARTICLE

How Meta designed Muse to not feel like an AI app

In an interview with the How I AI podcast, Muse's design director explains why he avoided the AI-assistant aesthetic and built an interface that serves the same screen to his mother and to an engineer.

Alex Cornell is design director at Muse, Meta's consumer AI agent. In an interview with the How I AI podcast, hosted by journalist Claire Vo, published on October 12, 2026, he detailed the decisions behind the product's interface, something he has also been sharing publicly on Threads. The conversation isn't about a new feature: it's about the product reasoning that underlies every visible piece of Muse.

The decision behind the design: avoiding the look of an AI app

Cornell's first choice was structural: Muse should behave like a messaging conversation, not like an assistant dashboard. That means a customizable avatar instead of a generic robot icon, and a conversation surface that resembles WhatsApp more than a command console.

The logic behind this is about product, not aesthetics. A messaging app is already a mental model everyone carries: type, wait for a reply, keep the thread going. By inheriting that grammar, Muse reduces the cognitive cost of learning "how to talk to an AI," a problem that still trips up most consumer agents launched in recent years.

Three-layer status: the same screen for mom and for the engineer

The biggest design challenge Cornell cites is serving audiences with very different levels of technical fluency within the same interface, without creating two products. The answer was a three-layer status system: one layer shows the essentials (what's happening right now), another details the process underway, and a third exposes more granular information for those who want to understand what the model is doing under the hood.

This layering is a design response to a problem every generative AI product team faces: the same output can feel magical to a layperson and insufficient to an advanced user who wants to audit the reasoning. Instead of picking one audience, Muse leaves the depth of information as something navigable, not fixed.

In short: the trick wasn't simplifying the interface down to the lowest common denominator, but designing layers that each type of user chooses (or doesn't even notice they're choosing) how much they want to see.

Generative UI, in practice

Cornell uses the term generative UI to describe screens that the model itself assembles on demand, instead of fixed screens designed in advance for each use case. In Muse, this shows up in a personalized ideas surface and a generative feed: instead of a single layout for everyone, what appears is assembled from each person's history and context.

For product designers, the practical difference is huge. Testing a fixed component is relatively simple: there's an error state, a loading state, an end state. Testing a UI that the model composes differently every session requires a different kind of rigor, and this is the point Cornell highlights as the biggest mindset shift for designers working with AI.

From a forgotten Instagram to a SkyMall-style catalog

The most concrete example in the interview is a live demonstration: Cornell connected years of saved Instagram posts, things saved and never revisited, and Muse turned that collection into a shopping catalog with the aesthetic of a SkyMall or Sharper Image magazine, with organized items, prices, and a monitoring option.

From there, Muse starts working as a price watcher: the user can ask to be notified when a specific item drops in price. This function is powered by connectors to Instagram and Pinterest, which makes the AI less of a question-and-answer chatbot and more of an agent that works on visual data the user has already accumulated but never organized.

The design point here isn't the e-commerce function itself. It's the decision that dead data (saved and forgotten photos) can become reusable structure without the user having to manually organize anything: the curation work belongs to the agent, not the human.

Golf, chess, and the limits between the main chat and side chats

Cornell uses Muse itself to track his golf game, shot by shot, while working to lower his handicap, and to analyze chess games from Chess.com with a coach that has a "sarcastic" tone. These two cases appear in the interview as examples of ongoing-use personalization, unlike the one-off shopping catalog demonstration.

This kind of use raises an architecture question: when should a conversation live in Muse's main chat, and when does it deserve a dedicated side chat (like a golf or chess project that accumulates its own history)? Cornell acknowledges, in the interview itself, that this division is still a weak point of the product: it isn't clear to the user when a topic should "leave" the main thread.

It's a problem familiar to anyone who designs products: the information structure that makes sense to the team that built the system isn't always obvious to those who use it.

A twenty-year-old blog became a morning podcast

Another case shown in the conversation: Cornell fed Muse twenty years of posts from a personal blog, retrieved via the Wayback Machine, and asked the agent to turn that history into a morning podcast. The result is a use of generative AI that doesn't create content from scratch, but reprocesses a forgotten personal archive into another consumption format.

The pattern repeats: saved Instagram becomes a catalog, an old blog becomes a podcast. The design thesis behind Muse seems to be the same across all three cases (shopping, golf, blog): the value isn't in generating something new, it's in putting to use data the person already had and never looked at again.

When mom apologizes to Muse

A small detail from the interview says a lot about the product's tone: Cornell's mother, at some point, caught herself apologizing to Muse itself, as if she were talking to a person. For him, this isn't an expectation bug, it's a sign that the conversational interface is working as intended, to the point of triggering automatic social reflexes.

This behavior also supports the interview's central argument: when the interface mimics human convention (avatar, message tone, response pauses), the user treats the system with the same social norms they would treat a person, for better and for worse. It's a qualitative data point, an observation of real use reported by the designer himself, not formal research, but one that guides decisions about the agent's tone and personality.

What still doesn't work

Cornell is direct about Muse's current limits. Beyond the unclear division between main chat and side chats, he describes specific prompting strategies for when the agent gets "stubborn," that is, insisting on a wrong answer or stuck on a path that doesn't serve the user. This indicates that, despite the friendly interface, the model behind it still requires some user knowledge of how to "unstick it," the opposite of the goal of feeling like a simple conversation.

For digital product designers, Cornell's interview leaves a concrete question to apply to their own work: is there any layer of complexity in your product that you're hiding behind a simple interface, but that still requires the user to know how to work around the system from the outside?

Translated from the Brazilian Portuguese original · Read the original

View profile →