Chat to Command
An Intent-to-Action Framework for Conversational Settings
Challenge
As Copilot expanded into Outlook, conversational interaction moved beyond generating content to changing persistent product settings. The design challenge was to define a consistent model for translating open-ended user intent into reliable system behavior across ambiguity, varying capabilities, and existing product boundaries—rather than solving each setting as an isolated conversational flow.
Tension
How could the experience feel like one coherent system when the user's intent crossed different product and capability boundaries?
One experience, multiple capability and product boundaries
There was no existing model for how much a conversational agent should be trusted to change: act directly, confirm first, or hand off entirely.
That question had to be answered as a system, not settled feature-by-feature.
The work spanned multiple product surfaces and engineering boundaries, requiring us to define a coherent experience despite different capability and ownership constraints.
The chat panel was built for a narrow, reversible action — editing text that only existed in that conversation. Settings are the opposite: persistent, account-level state that other surfaces also read and write. There was no existing pattern for what a conversational agent is allowed to do to state it doesn't fully own — act directly, ask first, or step aside. That ambiguity had to be resolved before any single scenario (like signatures) could ship.
From Example to Pattern
Turned an open-ended AI problem into buildable system behavior.
Managing inbox rules through Copilot
One prompt ≠ one task
Before defining responses, the team needed a shared model for the different levels of conversational complexity the system had to handle.
“Turn on X for my work account.”
Single task Multiple tasks
Context sufficient
Direct
Decompose
Context unresolved
Clarify
Decompose + Resolve
From open-ended language to system decisions
Representative requests were expanded into decision trees to make the system's hidden decisions explicit.
—————-
Option 1:
For example:
“Move emails from my manager into Project A.”
↓
Identify
Intent: Create rule
↓
Decompose
Condition: Sender
Action: Move
Destination: Project A
↓
Enough context?
No → Clarify
Yes ↓
Capability available?
No → Handoff
Yes ↓
Confirm → Execute
———
Option 2
Identify intent
Create an inbox rule.
↓
Decompose the task
Condition: sender
Action: move
Destination: folder
↓
Resolve missing context
Which manager? Which folder?
↓
Evaluate capability
Can Copilot perform the requested operation?
↓
Handle
Act conversationally, clarify, or transition to the appropriate Outlook surface.
Judgment:
Understanding ≠ permission to act
Three questions decided the path for any request:
Could Copilot reach the account?
Was the change reversible?
Did other surfaces depend on the resulting state?
—> scope, reversibility, persistence.
System / Public Example — consolidate the duplicate heading into one clean pass: intent → decompose → resolve context → evaluate capability → handling path → confirm/continue/recover, illustrated with the rules-via-chat flow.
From a prompt to executable behavior
I mapped representative requests into decision trees that made the system's hidden decisions explicit: intent, task structure, missing context, capability, handling path, and follow-up behavior.
Identify Intent
→ Decompose Task
→ Resolve Context
→ Evaluate Capability
→ Select Handling Path
→ Confirm / Continue / Recover
04 Engineering Translation
From UX scenarios to behavioral specifications
Capability boundary contract
In close collaboration with engineering, conversational intent was translated into implementable system behavior. The scenario maps made explicit the boundary between what Copilot could understand and what Outlook could actually execute, turning capability checks, missing context, clarification, execution, and UI handoff into deliberate decision points rather than edge cases discovered during implementation. This provided engineering with a clearer behavioral contract and concrete criteria to build against.
Reusable framework
As the same logic repeated across scenarios, the work evolved into a reusable Task Identification & Handling Framework: resolve scope → gather missing information → evaluate capability → execute or hand off. This shifted the experience from feature-specific conversation flows toward a shared orchestration model that could be applied consistently across additional Settings scenarios, reducing one-off design and implementation decisions.
Once patterns repeated across scenarios, I consolidated them into the Task Identification & Handling Framework, so later settings features could inherit the logic instead of engineering re-deriving it each time.
Scale
Cross-product Influence
The framework became a recurring reference in weekly engineering syncs, and was later extended into a joint prioritization exercise with product — mapping settings features by interaction complexity and engineering cost to sequence what shipped first. The underlying pattern outlived the project: chat-based configuration of settings like automatic replies and mail rules is now a standard capability in this product category, validating the direction the framework pointed toward.
————
option 2
Framework applied across a broader set of conversational configuration scenarios — without naming confidential ones
The framework became a recurring reference in weekly engineering syncs, and was later extended into a joint prioritization exercise with product — mapping settings features by interaction complexity and engineering cost to sequence what shipped first. The underlying pattern outlived the project: chat-based configuration of settings like automatic replies and mail rules is now a standard capability in this product category, validating the direction the framework pointed toward.
Pair with a redrawn, generic complexity × engineering-cost matrix (not the real Excel sheet).
Designing an Intent-to-Action Framework for Conversational AI
I worked on a conversational experience within a large productivity application, exploring how natural-language requests could translate into product actions. My focus was defining how the system should identify intent, resolve missing context, evaluate capability, and determine whether to act or hand control back to the UI.