User intent
“Faro, help me sort out tomorrow.”
Faro
AI interfaces · Voice UX · Systems design
Exploring how AI systems can coordinate work across devices while preserving visibility, restraint, and user trust.
What I designed
Faro is a conceptual AI execution layer for coordinating tasks across devices.
I designed the interaction model around five core pieces:
- Voice and text-based delegation
- Asynchronous execution states
- Ambiguity detection and clarification
- Human-in-the-loop confirmation
- Failure recovery and rollback paths
The goal was not to design a more conversational assistant. It was to design a system that could act in the background while still making its actions inspectable, interruptible, and reversible.
The problem
AI tools can get things done for us, but in mobile and laptop tasks, users still need visibility into what is happening, what changed, and where they can intervene.
Multistep knowledge workers often act across information between different devices, messaging threads, calendars, and documents. Existing assistants tend to either stay conversational or disappear into automation.
Faro explores how an AI system could execute across devices while preserving user awareness, confirmation, and control.
Design principle: trusting the invisible
Because much of Faro’s execution happens in the background, trust could not be generated through a chat conversation.
The system needed to make invisible work feel inspectable through lightweight feedback: what is happening, what changed, what is uncertain, and when the user needs to intervene.
I treated trust as a system behavior rather than a feature.
Designing the system
Instead of designing a chatbot, I approached Faro as an execution system.
The product needed to balance autonomy with reassurance: acting when the task was low-risk, asking when intent was unclear, and pausing when the consequences were high.
User control is embedded in:
- What Faro is doing
- Why it is doing it
- What information it is using
- Where uncertainty exists
- What confirmation is required
- How to intervene, undo, or redirect an action
1 - Delegation
Context gathering
Calendar, unread messages, travel time, existing commitments.
Confidence estimation
What can be automated, what needs clarification, what is risky.
2 - Orchestration
Ambiguity detection
Two overlapping priorities detected.
Clarification request
Faro asks before changing a high-impact commitment.
User confirmation
User selects intent, timing, or preferred action.
3 - Execution
Drafted recommendation
Proposed schedule change appears before execution.
Async execution
Calendar update and message draft are prepared.
Visible outcome
User sees what changed and why.
Review or rollback
User can approve, edit, cancel, or undo.
What changed during the process
My first version of Faro behaved too much like a conversational assistant. It accepted tasks, generated too much text, and made the experience feel like another chat interface layered over work.
I moved toward operational feedback instead: confirmation, visible system states, lightweight action surfaces, and a clearer distinction between low-risk automation and high-risk decisions.
The biggest shift was from designing dialogue to designing system behavior. Faro should not explain everything. It should communicate what the user needs: awareness, confirmation, or control.
Core interaction behaviors
1 - Delegation across voice and text
Faro supports both voice and silent text input because delegation depends on context. Voice works when users are mobile or hands-free. Terminal Mode supports public, focused, or quiet environments without changing the underlying execution model.
2 - Adaptive Focus Area
One issue I noticed in existing AI assistant patterns was that dialogue overlays can block the interface users are trying to act on. In noisy or hands-busy contexts, users still need to see what the assistant heard, but that feedback should not cover buttons, app content, or the next action.
Faro uses an adaptive focus area: the assistant response gets a reserved system-level space while the active app canvas shifts or compresses below it.
This keeps the conversation visible without turning the assistant into an obstruction, allowing the user and Faro to work in parallel instead of competing for the same screen space.
3 - Asynchronous execution feedback
Faro runs tasks in the background and communicates through lightweight states: listening, reviewing, working, needs confirmation, completed, failed, and rolled back. The interface is designed to reduce attention switching while keeping the user aware of meaningful state changes.
4 - Restraint and recovery
Faro treats uncertainty as a UX state.
Low-risk actions can proceed with lightweight confirmation. Ambiguous or high-risk actions require clarification, preview, approval, or rollback. The system is designed to feel useful without pretending to be certain when it is not.
Demo: resolving an ambiguous schedule conflict
To make the interaction model concrete, I prototyped a task that requires several context switches.
Faro has to interpret a broad goal, notice context, detect ambiguity, and surface a lightweight approval checkpoint, then execute the task in the right setting without turning that communication into another user control.
1. User intent — A broad scheduling goal is delegated.
2. Context review — Faro checks calendar, messages, travel time, and commitments.
3. Clarification — Ambiguous or high-impact changes require confirmation.
4. Controlled execution — Faro acts after approval and keeps review, send, and undo available.
Prototype evaluation
Because a fully functional multi-device agent was outside the scope, I evaluated Faro through structured scenario flows.
I prototyped task scenarios, mapped system states, and stress-tested moments where the system needed to act in the background, request approval, or recover from ambiguity.
The strongest patterns were that trust depended less on how powerful Faro appeared and more on how clearly it communicated uncertainty and restraint.
Reflection
I started Faro focused on capability and ended focused on trust.
The project helped me see that emerging interfaces are less about adding more fluid automation and more about making things legible, interruptible, and reversible.
The strongest AI products may not be the ones that do the most. They may be the ones that know when to act, when to ask, when to stay quiet, and how to give users their agency back.
Faro became less about designing an assistant and more about designing the relationship between human attention and machine execution.