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
Modern knowledge workers often act as manual infrastructure between disconnected tools: moving information across apps, re-entering context, checking updates, and translating intent into app-specific actions.
AI assistants are becoming more capable, but delegation still feels unreliable when users cannot see what the system is doing, why it is doing it, what information it is using, or when it needs help.
This creates a trust gap. The more invisible the execution becomes, the more important it is for the system to communicate state, uncertainty, and control clearly.
Faro explores how an AI system could execute across devices while preserving visibility, restraint, and user trust.
Design principle: trusting the invisible
Because much of Faro’s execution happens in the background, trust could not depend on constant screen attention.
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 consequence was high.
Users needed to understand:
- What Faro is doing
- Why it is doing it
- What information it is using
- Where uncertainty exists
- When intervention is required
- How to approve, cancel, or roll back an action
The execution architecture became a trust model: delegation, orchestration, confirmation, execution, and recovery.
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 responded often, explained too much, and made the experience feel chat-heavy rather than execution-focused.
I moved toward operational feedback instead: short confirmations, visible system states, interruption only when necessary, and a clearer distinction between low-risk automation and high-risk decisions.
The biggest design shift was treating silence as part of the experience. Faro should not narrate everything. It should communicate when 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 schedule-conflict scenario.
Faro has to interpret a broad goal, review context, detect ambiguity, ask before changing a high-impact commitment, and then execute the low-risk steps while leaving final communication under user control.
User intent - a broad scheduling goal is delegated.
Context review: Faro checks calendar, messages, travel time, and commitments.
Clarification: ambiguous or high-impact changes require confirmation.
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 simulated execution flows.
I prototyped task scenarios, mapped system states, and stress-tested moments where the system needed to ask for clarification, request approval, show progress, handle latency, or recover from failure.
The strongest pattern was 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 taught me that AI interaction design is less about making systems feel autonomous and more about making them 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 recover when they are wrong.
Faro became less about designing an assistant and more about designing the relationship between human attention and machine execution.