ExpertsFMHow Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director)
How I AI · October 12, 2026
5 Selected Lessons:
framework · 2 heuristic · 2 reasoning_pattern · 1
Design the agent as an entity you message, not a tool you operate
Source
How I AI — How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director) (October 12, 2026) · at 2:50 ▸
When this applies
when designing any interface for a system capable of autonomous, time-delayed action toward a user
The takeaway
When a system gains a new capability class (proactive, autonomous action), stop reusing conventions built for the old capability class and instead model the interaction on the closest real-world analog.
Why it works
Framing the product as an exchange between two entities (not a traditional software feature) resolves many micro-decisions at once — e.g., needing message bubbles to separate asynchronous messages in time — because you can ask 'how would a person handle this' instead of reinventing conventions.
One level up
Big capability jumps require a new reference frame, not incremental tweaks to the old one.
Where it stops holding
This stops working when the system's users actually want tool-like, deterministic control rather than a relationship-like interaction (e.g., expert engineers needing raw logs, not a persona).
Detail
procedure:
- Identify the new capability that breaks old assumptions (e.g., agent can message you proactively)
- Ask 'how would this work if you were speaking with another person' instead of referencing prior industry patterns
- Adopt messaging-app conventions (bubbles, embodied avatar) rather than dashboard/tool conventions
- Apply this reframing consistently across every design decision
rationale: A reframing to 'entity you talk to' was 'immensely clarifying' and resolved nearly every subsequent decision.
In their words
It was more like, how would you handle this if you were actually speaking with another person? You know? And that was immensely clarifying, I think, in almost every decision that we had to make.
Progressive disclosure of agent status, layered by user sophistication
Source
How I AI — How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director) (October 12, 2026) · at 0:00 ▸ · at 5:33 ▸ · at 8:51 ▸
When this applies
when a single interface must serve both expert and novice users who need different depths of system transparency
The takeaway
Default to the minimum information needed for trust, and make deeper detail available on demand rather than always-visible.
Why it works
Layering detail (simple status → short description → activity list → raw logs) lets each user stop at the depth they need, so novices aren't overwhelmed and experts can still audit.
One level up
Accessibility and power are not a tradeoff if detail is layered rather than flattened.
Where it stops holding
This stops working when users need to see failure/error detail immediately, since hiding it by default could delay trust-critical debugging.
Detail
procedure:
- Top level: single phrase status ('it's working')
- Next level: short description with emoji ('researching pumpkin patches')
- Next level: tap to see list of actions taken
- Deepest level: raw code/curl output for auditing
benchmarks: {}
rationale: If you are an engineer, you may want exact detail; if you're a normal person, you just want to know if it's doing something — so expose by default only what the average user needs.
In their words
But if you're a normal person, you maybe just want to know, like, is it doing something? So at the top, it'll tell you, it's working. Jolleyvot is working. And then your next question might be, what's it working on?
Design for nondeterministic, personalized systems by focusing on scaffolding, not screen-level outcomes
Source
How I AI — How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director) (October 12, 2026) · at 30:12 ▸
When this applies
when designing any system whose output is nondeterministic and highly personalized per user, as opposed to a fixed deterministic feature
The takeaway
Shift design effort from controlling specific instance outputs to designing the system/rules that govern the space of possible outputs.
Why it works
In deterministic software, a feature produces one fixed outcome per screen, so bugs are narrowly scoped; in a personalized AI system, outputs vary so much per user that reasoning about 'this one screen's exact look' is less useful than reasoning about the underlying architecture/scaffolding that governs all possible outputs.
One level up
As systems become more generative and personalized, designers must trade precise control for well-designed constraints/guardrails.
Where it stops holding
This stops working when exact visual/output precision is actually required (e.g., regulated or brand-critical surfaces) where variance itself is unacceptable.
Detail
approach: Accept that any given user's output/screen will differ from another's; focus design effort on the system, architecture, and scaffolding rather than pixel-perfect control of individual generated artifacts.
signals:
- Multiple users' setups look completely different from each other
- The same feature can't be fully specified by 'what will this screen look like'
- Temptation to perfect one generated artifact's exact look is less valuable than system-level design
rationale: I've come to view it a little bit more freely, and it's, I think, liberating in some ways to feel like, this is still just a very useful output for me, and maybe I will take the time to make the colors just so, but otherwise, it's good and it's fine.
In their words
I think really understanding that these systems usually do end up the way you think, but my Muse setup is completely different than yours, is completely different to somebody else's. They're so personal and they can do so many different things that you really have to think more about the underlying foundation and the system, the architecture, the scaffolding that's in place, and less about, well, what about this one little thing here?
Acknowledge immediately, then work — don't ghost during long tasks
Source
How I AI — How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director) (October 12, 2026) · at 8:51 ▸
When this applies
when any service or system has latency on a complex request and the user can't see progress
The takeaway
Perceived latency is driven less by actual wait time and more by uncertainty about whether progress is happening; resolve the uncertainty first, independent of resolving the task.
Why it works
An immediate acknowledgment (reaction or short message) signals the request was received and a plan exists, removing the ambiguity of 'is it stuck,' even before the real work is visible.
One level up
Manage the user's uncertainty as a first-class design problem, separate from managing the underlying task's speed.
Where it stops holding
This stops working when the acknowledgment itself is inaccurate or misleading (false confidence that work has started), which would damage trust more than silence.
Detail
rule: On complex requests, immediately acknowledge (reaction or message) before doing the real work, and keep a status display available throughout.
threshold: Applied whenever a request is 'somewhat complex' enough that there would otherwise be a silent gap.
rationale: Like a person, you wouldn't ghost someone who asked for something hard — you'd say 'here's the plan, I'll be back' or just react to show it's being handled.
In their words
I think like like a person, you know, if you ask for something hard, they're not gonna just ghost you until they're done. They'll usually just say like, okay, here's the plan. I'm gonna do this. I'll be back when I have it done, or even just a reaction is enough to let you know that it's doing it.
Keep generative UI 'on rails': fixed structure, personalized content
Source
How I AI — How Meta designed Muse: an AI agent people actually want to talk to | Alex Cornell (Design Director) (October 12, 2026) · at 11:06 ▸
When this applies
when deciding how much personalization/generativity to inject into any product surface
The takeaway
Constrain the variable surface area of generativity to content, not structure, so users retain a stable mental model while still getting personalized value.
Why it works
Keeping core surfaces (avatar, status, feed, ideas) structurally constant while varying only the generated content inside them preserves learnability (users know where things are) while still delivering personalization (what's inside differs by user).
One level up
Novel capabilities should be introduced inside familiar containers, not by making everything variable at once.
Where it stops holding
This stops working when the fixed structure itself becomes a constraint users outgrow, or when 'one day' models/interfaces can reliably generate fully bespoke structure without confusing users (which Alex suggests may come later).
Detail
rule: Fix the primitives (avatar, status, ideas, feed); generate only the content within them (personalized ideas, status emoji, avatar states).
threshold: Current state is 'a little bit more on the rails' — not yet a 'fully generative surface' even for the feed.
rationale: Full per-user structural variation isn't yet usable/understandable; content-level generativity captures most of the delight with far less confusion.
In their words
But yeah, I mean, it's still a native surface though. The feed unit that you're looking at is still one that we've designed, and it's being powered by the intelligence of