Autonomous Sales Agents
Executive Summary
The Autonomous Sales Agent initiative for Dynamics 365 Sales reimagines how sales teams operate by introducing fully autonomous and human supervised intelligence into the qualification process. The project began in early twenty twenty five during a major shift in strategy, when the organization moved from traditional CRM enhancements to creating agents capable of researching, engaging, qualifying, and handing over leads without constant human intervention.
I was responsible for defining the complete framework that enables these agents to function at scale. This included the mental model, the information architecture, the interaction patterns, the explainability model, and the overall system that binds research, engagement, handoff, knowledge grounding, and supervision into a coherent experience. Multiple teams worked on individual agent capabilities, and my role was to bring them together under one unified structure that was usable, scalable, and aligned with future agent expansion.
The work established the foundation that now powers several autonomous agents across Dynamics 365. It transformed a complex and highly technical problem into a clear and approachable setup experience that administrators can understand and trust. The project moved from concept to General Availability in a fast paced eight month period and became a key driver of Microsoft’s investment in agent based systems. Early customer data shows a strong increase in lead conversion outcomes, validating both the design strategy and the product direction.
Executive Summary
The Autonomous Sales Agent initiative for Dynamics 365 Sales reimagines how sales teams operate by introducing fully autonomous and human supervised intelligence into the qualification process. The project began in early twenty twenty five during a major shift in strategy, when the organization moved from traditional CRM enhancements to creating agents capable of researching, engaging, qualifying, and handing over leads without constant human intervention.
I was responsible for defining the complete framework that enables these agents to function at scale. This included the mental model, the information architecture, the interaction patterns, the explainability model, and the overall system that binds research, engagement, handoff, knowledge grounding, and supervision into a coherent experience. Multiple teams worked on individual agent capabilities, and my role was to bring them together under one unified structure that was usable, scalable, and aligned with future agent expansion.
The work established the foundation that now powers several autonomous agents across Dynamics 365. It transformed a complex and highly technical problem into a clear and approachable setup experience that administrators can understand and trust. The project moved from concept to General Availability in a fast paced eight month period and became a key driver of Microsoft’s investment in agent based systems. Early customer data shows a strong increase in lead conversion outcomes, validating both the design strategy and the product direction.
Executive Summary
The Autonomous Sales Agent initiative for Dynamics 365 Sales reimagines how sales teams operate by introducing fully autonomous and human supervised intelligence into the qualification process. The project began in early twenty twenty five during a major shift in strategy, when the organization moved from traditional CRM enhancements to creating agents capable of researching, engaging, qualifying, and handing over leads without constant human intervention.
I was responsible for defining the complete framework that enables these agents to function at scale. This included the mental model, the information architecture, the interaction patterns, the explainability model, and the overall system that binds research, engagement, handoff, knowledge grounding, and supervision into a coherent experience. Multiple teams worked on individual agent capabilities, and my role was to bring them together under one unified structure that was usable, scalable, and aligned with future agent expansion.
The work established the foundation that now powers several autonomous agents across Dynamics 365. It transformed a complex and highly technical problem into a clear and approachable setup experience that administrators can understand and trust. The project moved from concept to General Availability in a fast paced eight month period and became a key driver of Microsoft’s investment in agent based systems. Early customer data shows a strong increase in lead conversion outcomes, validating both the design strategy and the product direction.
Overview
Sales teams struggle to process the full volume of inbound leads. Website sign-ups, event leads, and low-intent inquiries often remain untouched due to limited human capacity. This leads to missed opportunities, inconsistent qualification, and inefficient use of seller time.
To address this, Dynamics 365 Sales introduced the Autonomous Sales Qualification Agent, designed to research, engage, qualify, and hand over leads autonomously at scale. The goal was not incremental productivity, but a structural shift in how sales teams operate.
This case study focuses on designing the admin experience that enables these agents to be configured, trusted, supervised, and scaled. The work defined the foundational framework that now powers multiple autonomous agents across the platform.
Overview
Sales teams struggle to process the full volume of inbound leads. Website sign-ups, event leads, and low-intent inquiries often remain untouched due to limited human capacity. This leads to missed opportunities, inconsistent qualification, and inefficient use of seller time.
To address this, Dynamics 365 Sales introduced the Autonomous Sales Qualification Agent, designed to research, engage, qualify, and hand over leads autonomously at scale. The goal was not incremental productivity, but a structural shift in how sales teams operate.
This case study focuses on designing the admin experience that enables these agents to be configured, trusted, supervised, and scaled. The work defined the foundational framework that now powers multiple autonomous agents across the platform.
Overview
Sales teams struggle to process the full volume of inbound leads. Website sign-ups, event leads, and low-intent inquiries often remain untouched due to limited human capacity. This leads to missed opportunities, inconsistent qualification, and inefficient use of seller time.
To address this, Dynamics 365 Sales introduced the Autonomous Sales Qualification Agent, designed to research, engage, qualify, and hand over leads autonomously at scale. The goal was not incremental productivity, but a structural shift in how sales teams operate.
This case study focuses on designing the admin experience that enables these agents to be configured, trusted, supervised, and scaled. The work defined the foundational framework that now powers multiple autonomous agents across the platform.
Context and Strategic Shift
When I joined the Dynamics 365 Sales team in mid-2024, the product was fundamentally a traditional CRM. Automation existed, but AI played a supporting role rather than a transformative one. Most workflows were still human-driven, with limited intelligence layered on top.
My initial assignment was to explore how sales workflows could evolve using AI and machine learning, influenced by my prior experience in SAP Business AI. I created an early proof of concept that demonstrated how intelligence could move beyond assistance toward autonomy. This exploration focused on how systems could reason, act, and learn with minimal human intervention while still remaining controllable.
This vision was presented to senior leadership in the US and became a catalyst for significant investment to pursue an agent-first direction.
By early 2025, market pressure accelerated this shift dramatically. Several planned intelligent features were deprioritized, and the organization made a decisive move toward fully autonomous agents. At this point, the challenge was no longer enhancing a CRM. It was redefining how sales could operate with AI at scale.
Context and Strategic Shift
When I joined the Dynamics 365 Sales team in mid-2024, the product was fundamentally a traditional CRM. Automation existed, but AI played a supporting role rather than a transformative one. Most workflows were still human-driven, with limited intelligence layered on top.
My initial assignment was to explore how sales workflows could evolve using AI and machine learning, influenced by my prior experience in SAP Business AI. I created an early proof of concept that demonstrated how intelligence could move beyond assistance toward autonomy. This exploration focused on how systems could reason, act, and learn with minimal human intervention while still remaining controllable.
This vision was presented to senior leadership in the US and became a catalyst for significant investment to pursue an agent-first direction.
By early 2025, market pressure accelerated this shift dramatically. Several planned intelligent features were deprioritized, and the organization made a decisive move toward fully autonomous agents. At this point, the challenge was no longer enhancing a CRM. It was redefining how sales could operate with AI at scale.
Context and Strategic Shift
When I joined the Dynamics 365 Sales team in mid-2024, the product was fundamentally a traditional CRM. Automation existed, but AI played a supporting role rather than a transformative one. Most workflows were still human-driven, with limited intelligence layered on top.
My initial assignment was to explore how sales workflows could evolve using AI and machine learning, influenced by my prior experience in SAP Business AI. I created an early proof of concept that demonstrated how intelligence could move beyond assistance toward autonomy. This exploration focused on how systems could reason, act, and learn with minimal human intervention while still remaining controllable.
This vision was presented to senior leadership in the US and became a catalyst for significant investment to pursue an agent-first direction.
By early 2025, market pressure accelerated this shift dramatically. Several planned intelligent features were deprioritized, and the organization made a decisive move toward fully autonomous agents. At this point, the challenge was no longer enhancing a CRM. It was redefining how sales could operate with AI at scale.
project type
leap to fully autonomous agents that can research, engage and close deals
year
2025
my role
Lead UX Designer
Company
Microsoft
Levels of AI Operations
The project was grounded in a clear maturity model for AI systems:
Level 1: Human-first augmentation
Level 2: Human-led teams supported by autonomous agents
Level 3: Agent-first teams with human oversight
Level 4: Fully autonomous operations
The ambition was explicit. Products built only for Level 2 risk disruption by companies delivering Level 3–4 solutions. Productivity gains alone are insufficient. Autonomous agent teams fundamentally change revenue economics by increasing revenue per seller without proportional headcount growth.
This framing shaped every design decision, especially around trust, control, explainability, and scalability.
Levels of AI Operations
The project was grounded in a clear maturity model for AI systems:
Level 1: Human-first augmentation
Level 2: Human-led teams supported by autonomous agents
Level 3: Agent-first teams with human oversight
Level 4: Fully autonomous operations
The ambition was explicit. Products built only for Level 2 risk disruption by companies delivering Level 3–4 solutions. Productivity gains alone are insufficient. Autonomous agent teams fundamentally change revenue economics by increasing revenue per seller without proportional headcount growth.
This framing shaped every design decision, especially around trust, control, explainability, and scalability.
Levels of AI Operations
The project was grounded in a clear maturity model for AI systems:
Level 1: Human-first augmentation
Level 2: Human-led teams supported by autonomous agents
Level 3: Agent-first teams with human oversight
Level 4: Fully autonomous operations
The ambition was explicit. Products built only for Level 2 risk disruption by companies delivering Level 3–4 solutions. Productivity gains alone are insufficient. Autonomous agent teams fundamentally change revenue economics by increasing revenue per seller without proportional headcount growth.
This framing shaped every design decision, especially around trust, control, explainability, and scalability.
Problem
Traditional sales qualification relies heavily on human effort, leading to high costs, variability in outcomes, and slow adoption of advanced systems.
Key sales roles such as SDRs are difficult to scale and retain, creating bottlenecks in lead qualification and order fulfillment.
From a UX perspective, the problem was deeper. Administrators had never configured fully autonomous sales agents before. The system needed to be powerful enough to support complex automation, yet approachable enough to inspire confidence and adoption.
Problem
Traditional sales qualification relies heavily on human effort, leading to high costs, variability in outcomes, and slow adoption of advanced systems.
Key sales roles such as SDRs are difficult to scale and retain, creating bottlenecks in lead qualification and order fulfillment.
From a UX perspective, the problem was deeper. Administrators had never configured fully autonomous sales agents before. The system needed to be powerful enough to support complex automation, yet approachable enough to inspire confidence and adoption.
Problem
Traditional sales qualification relies heavily on human effort, leading to high costs, variability in outcomes, and slow adoption of advanced systems.
Key sales roles such as SDRs are difficult to scale and retain, creating bottlenecks in lead qualification and order fulfillment.
From a UX perspective, the problem was deeper. Administrators had never configured fully autonomous sales agents before. The system needed to be powerful enough to support complex automation, yet approachable enough to inspire confidence and adoption.
My Role
Although my title was Senior UX Designer, my responsibility extended beyond individual features.
I owned the agent framework and cognitive model, defining how autonomous agents are configured, how they reason, how they operate over time, and how humans understand and supervise their behavior.
Multiple teams worked in parallel on individual capabilities such as outreach, research, and assignment logic. My role was to bring these teams together under a shared mental model and ensure coherence, scalability, and consistency across all agent experiences.
Specifically, I was responsible for:
Defining the agent profile and prerequisites
Designing automation levels and control models
Shaping how agents reason about customer context and value propositions
Establishing how agents explain decisions and background actions
Integrating knowledge retrieval via Microsoft Copilot Studio
Designing interaction patterns for long-running processes
Defining guardrails for operating multiple agents without conflict
In addition, I directly designed and shipped critical surfaces where these principles had to be made tangible, including simulation and conversational interactions.
My Role
Although my title was Senior UX Designer, my responsibility extended beyond individual features.
I owned the agent framework and cognitive model, defining how autonomous agents are configured, how they reason, how they operate over time, and how humans understand and supervise their behavior.
Multiple teams worked in parallel on individual capabilities such as outreach, research, and assignment logic. My role was to bring these teams together under a shared mental model and ensure coherence, scalability, and consistency across all agent experiences.
Specifically, I was responsible for:
Defining the agent profile and prerequisites
Designing automation levels and control models
Shaping how agents reason about customer context and value propositions
Establishing how agents explain decisions and background actions
Integrating knowledge retrieval via Microsoft Copilot Studio
Designing interaction patterns for long-running processes
Defining guardrails for operating multiple agents without conflict
In addition, I directly designed and shipped critical surfaces where these principles had to be made tangible, including simulation and conversational interactions.
My Role
Although my title was Senior UX Designer, my responsibility extended beyond individual features.
I owned the agent framework and cognitive model, defining how autonomous agents are configured, how they reason, how they operate over time, and how humans understand and supervise their behavior.
Multiple teams worked in parallel on individual capabilities such as outreach, research, and assignment logic. My role was to bring these teams together under a shared mental model and ensure coherence, scalability, and consistency across all agent experiences.
Specifically, I was responsible for:
Defining the agent profile and prerequisites
Designing automation levels and control models
Shaping how agents reason about customer context and value propositions
Establishing how agents explain decisions and background actions
Integrating knowledge retrieval via Microsoft Copilot Studio
Designing interaction patterns for long-running processes
Defining guardrails for operating multiple agents without conflict
In addition, I directly designed and shipped critical surfaces where these principles had to be made tangible, including simulation and conversational interactions.
Design Challenge 1
Defining the right mental model for configuring autonomous agents
This was the most critical decision in the project. At the start, there was no existing mental model for configuring autonomous agents inside Dynamics 365. Whatever structure we introduced here would not only shape the Sales Qualification Agent, but become the foundation for all future agents across the platform.
The challenge was to expose complex agent behavior in a way that administrators could understand, control, and trust, without overwhelming them or leaking internal system architecture.
What we tried and learned
We began by identifying the minimum technical building blocks required for an agent to function. This resulted in a stacked configuration model grouped by capabilities such as research, engagement, and lead readiness.
This approach helped validate feasibility and align teams early. It clarified what inputs were required and revealed gaps where additional information was needed.
However, usability issues surfaced quickly:
Long vertical flows made navigation difficult
Expand and collapse patterns obscured progress
Completion states were unclear
Internal micro-agent architecture was exposed directly to users
The core issue was clear. The structure mirrored how the system was built, not how administrators think or work.
We explored alternatives, including grid-based layouts, prompt-driven configuration, and wizard-based setup. Each solved a subset of problems but introduced new limitations around guidance, scalability, or editability.
Exploring alternatives
Grid-based configuration
We explored several approaches in parallel.
Allowed non-linear setup and reduced cognitive load for repeat users, but lacked sufficient guidance for first-time users. It made scnability editing experience easier.
Prompt-based configuration
Aligned with long-term AI interaction paradigms, but feasibility and predictability were insufficient at the time for an admin-critical experience.
This concept was deferred and is now being revisited post-launch as platform capabilities mature.
Wizard-based setup
A wizard model simplified configuration into three steps and significantly reduced cognitive load for first-time users. However, user testing revealed fundamental flaws. Setup was rarely linear. Editing required excessive navigation. The overall structure was hidden, making long-term maintenance inefficient.
Final decision
Why this mattered
We ultimately landed on a two-column layout with persistent navigation on the left and contextual configuration on the right.
The framework was organized around three core concepts:
Workflow: How the agent operates and automates tasks
Guidance: How decisions, criteria, and handoffs are defined
Knowledge: What information the agent uses and how it is grounded
This approach balanced clarity and flexibility. It supported first-time setup, frequent iteration, and future feature expansion without requiring structural redesign.
This layout became the governing pattern for all autonomous agents in Dynamics 365.
Autonomous agents introduce a fundamentally new interaction paradigm. If the mental model is wrong, everything built on top of it compounds the error.
Getting this right early prevented:
UX debt across future agents
Repeated redesigns as capabilities expanded
Mismatches between user expectations and agent behavior
This decision established a durable foundation that could scale as the platform evolved.
Design Challenge 1
Defining the right mental model for configuring autonomous agents
This was the most critical decision in the project. At the start, there was no existing mental model for configuring autonomous agents inside Dynamics 365. Whatever structure we introduced here would not only shape the Sales Qualification Agent, but become the foundation for all future agents across the platform.
The challenge was to expose complex agent behavior in a way that administrators could understand, control, and trust, without overwhelming them or leaking internal system architecture.
What we tried and learned
We began by identifying the minimum technical building blocks required for an agent to function. This resulted in a stacked configuration model grouped by capabilities such as research, engagement, and lead readiness.
This approach helped validate feasibility and align teams early. It clarified what inputs were required and revealed gaps where additional information was needed.
However, usability issues surfaced quickly:
Long vertical flows made navigation difficult
Expand and collapse patterns obscured progress
Completion states were unclear
Internal micro-agent architecture was exposed directly to users
The core issue was clear. The structure mirrored how the system was built, not how administrators think or work.
We explored alternatives, including grid-based layouts, prompt-driven configuration, and wizard-based setup. Each solved a subset of problems but introduced new limitations around guidance, scalability, or editability.
Exploring alternatives
Grid-based configuration
We explored several approaches in parallel.
Allowed non-linear setup and reduced cognitive load for repeat users, but lacked sufficient guidance for first-time users. It made scnability editing experience easier.
Prompt-based configuration
Aligned with long-term AI interaction paradigms, but feasibility and predictability were insufficient at the time for an admin-critical experience.
This concept was deferred and is now being revisited post-launch as platform capabilities mature.
Wizard-based setup
A wizard model simplified configuration into three steps and significantly reduced cognitive load for first-time users. However, user testing revealed fundamental flaws. Setup was rarely linear. Editing required excessive navigation. The overall structure was hidden, making long-term maintenance inefficient.
Final decision
Why this mattered
We ultimately landed on a two-column layout with persistent navigation on the left and contextual configuration on the right.
The framework was organized around three core concepts:
Workflow: How the agent operates and automates tasks
Guidance: How decisions, criteria, and handoffs are defined
Knowledge: What information the agent uses and how it is grounded
This approach balanced clarity and flexibility. It supported first-time setup, frequent iteration, and future feature expansion without requiring structural redesign.
This layout became the governing pattern for all autonomous agents in Dynamics 365.
Autonomous agents introduce a fundamentally new interaction paradigm. If the mental model is wrong, everything built on top of it compounds the error.
Getting this right early prevented:
UX debt across future agents
Repeated redesigns as capabilities expanded
Mismatches between user expectations and agent behavior
This decision established a durable foundation that could scale as the platform evolved.
Design Challenge 1
Defining the right mental model for configuring autonomous agents
This was the most critical decision in the project. At the start, there was no existing mental model for configuring autonomous agents inside Dynamics 365. Whatever structure we introduced here would not only shape the Sales Qualification Agent, but become the foundation for all future agents across the platform.
The challenge was to expose complex agent behavior in a way that administrators could understand, control, and trust, without overwhelming them or leaking internal system architecture.
What we tried and learned
We began by identifying the minimum technical building blocks required for an agent to function. This resulted in a stacked configuration model grouped by capabilities such as research, engagement, and lead readiness.
This approach helped validate feasibility and align teams early. It clarified what inputs were required and revealed gaps where additional information was needed.
However, usability issues surfaced quickly:
Long vertical flows made navigation difficult
Expand and collapse patterns obscured progress
Completion states were unclear
Internal micro-agent architecture was exposed directly to users
The core issue was clear. The structure mirrored how the system was built, not how administrators think or work.
We explored alternatives, including grid-based layouts, prompt-driven configuration, and wizard-based setup. Each solved a subset of problems but introduced new limitations around guidance, scalability, or editability.
Exploring alternatives
Grid-based configuration
We explored several approaches in parallel.
Allowed non-linear setup and reduced cognitive load for repeat users, but lacked sufficient guidance for first-time users. It made scnability editing experience easier.
Prompt-based configuration
Aligned with long-term AI interaction paradigms, but feasibility and predictability were insufficient at the time for an admin-critical experience.
This concept was deferred and is now being revisited post-launch as platform capabilities mature.
Wizard-based setup
A wizard model simplified configuration into three steps and significantly reduced cognitive load for first-time users. However, user testing revealed fundamental flaws. Setup was rarely linear. Editing required excessive navigation. The overall structure was hidden, making long-term maintenance inefficient.
Final decision
Why this mattered
We ultimately landed on a two-column layout with persistent navigation on the left and contextual configuration on the right.
The framework was organized around three core concepts:
Workflow: How the agent operates and automates tasks
Guidance: How decisions, criteria, and handoffs are defined
Knowledge: What information the agent uses and how it is grounded
This approach balanced clarity and flexibility. It supported first-time setup, frequent iteration, and future feature expansion without requiring structural redesign.
This layout became the governing pattern for all autonomous agents in Dynamics 365.
Autonomous agents introduce a fundamentally new interaction paradigm. If the mental model is wrong, everything built on top of it compounds the error.
Getting this right early prevented:
UX debt across future agents
Repeated redesigns as capabilities expanded
Mismatches between user expectations and agent behavior
This decision established a durable foundation that could scale as the platform evolved.
Design Challenge 2
Maintaining navigational clarity as features expanded
What we observed
As development progressed, new agent capabilities were added rapidly. Early categorization based on agent skills began to break down, with unrelated settings clustering together under broad sections.
This drift made navigation harder to understand and weakened the original lifecycle-based logic of the setup experience.
Solution
Why this mattered
We introduced progressive depth in selected areas through:
Basic settings required to launch the agent
Advanced settings for fine-tuning behavior and outcomes
This allowed administrators to:
Get agents running quickly
Return later to optimize results
Avoid being blocked by optional complexity
Autonomous systems evolve continuously. Without a way to absorb new capabilities gracefully, the admin experience would become increasingly brittle.
This approach ensured:
Feature growth did not overwhelm users
The experience remained approachable for new users
Power users retained depth and control
It protected the system from becoming unmanageable over time.
As more features were introduced:
Sections became overloaded
Settings no longer aligned with how administrators thought about setup
Finding and editing specific configurations required unnecessary effort
The experience began to reflect feature accumulation rather than a coherent system.
Design Challenge 2
Maintaining navigational clarity as features expanded
What we observed
As development progressed, new agent capabilities were added rapidly. Early categorization based on agent skills began to break down, with unrelated settings clustering together under broad sections.
This drift made navigation harder to understand and weakened the original lifecycle-based logic of the setup experience.
Solution
Why this mattered
We introduced progressive depth in selected areas through:
Basic settings required to launch the agent
Advanced settings for fine-tuning behavior and outcomes
This allowed administrators to:
Get agents running quickly
Return later to optimize results
Avoid being blocked by optional complexity
Autonomous systems evolve continuously. Without a way to absorb new capabilities gracefully, the admin experience would become increasingly brittle.
This approach ensured:
Feature growth did not overwhelm users
The experience remained approachable for new users
Power users retained depth and control
It protected the system from becoming unmanageable over time.
As more features were introduced:
Sections became overloaded
Settings no longer aligned with how administrators thought about setup
Finding and editing specific configurations required unnecessary effort
The experience began to reflect feature accumulation rather than a coherent system.
Design Challenge 2
Maintaining navigational clarity as features expanded
What we observed
As development progressed, new agent capabilities were added rapidly. Early categorization based on agent skills began to break down, with unrelated settings clustering together under broad sections.
This drift made navigation harder to understand and weakened the original lifecycle-based logic of the setup experience.
Solution
Why this mattered
We introduced progressive depth in selected areas through:
Basic settings required to launch the agent
Advanced settings for fine-tuning behavior and outcomes
This allowed administrators to:
Get agents running quickly
Return later to optimize results
Avoid being blocked by optional complexity
Autonomous systems evolve continuously. Without a way to absorb new capabilities gracefully, the admin experience would become increasingly brittle.
This approach ensured:
Feature growth did not overwhelm users
The experience remained approachable for new users
Power users retained depth and control
It protected the system from becoming unmanageable over time.
As more features were introduced:
Sections became overloaded
Settings no longer aligned with how administrators thought about setup
Finding and editing specific configurations required unnecessary effort
The experience began to reflect feature accumulation rather than a coherent system.
Design Challenge 3
Signaling completion, errors, and readiness
What we addressed
Solution
Why this mattered
The interface lacked clear signals for:
Completion states
Partial configuration
Errors requiring attention
This increased frustration and reduced confidence, especially during first-time setup.
We introduced subtle but persistent indicators that showed:
Completed sections
Partially completed sections
Errors that needed resolution
These indicators were visible within the navigation itself, giving users continuous awareness without interrupting flow.
Autonomous agents require a higher level of confidence before activation. Users need to know when the system is ready and why it may not be.
Clear signaling:
Reduced confusion and retries
Increased confidence during setup
Prevented premature or incorrect activation
This was essential for trust and adoption.
Administrators could only start an agent once required settings were complete, but users struggled to understand:
What was done
What was missing
Why an action was blocked
Without clear feedback, users relied on trial and error.
Design Challenge 3
Signaling completion, errors, and readiness
What we addressed
Solution
Why this mattered
The interface lacked clear signals for:
Completion states
Partial configuration
Errors requiring attention
This increased frustration and reduced confidence, especially during first-time setup.
We introduced subtle but persistent indicators that showed:
Completed sections
Partially completed sections
Errors that needed resolution
These indicators were visible within the navigation itself, giving users continuous awareness without interrupting flow.
Autonomous agents require a higher level of confidence before activation. Users need to know when the system is ready and why it may not be.
Clear signaling:
Reduced confusion and retries
Increased confidence during setup
Prevented premature or incorrect activation
This was essential for trust and adoption.
Administrators could only start an agent once required settings were complete, but users struggled to understand:
What was done
What was missing
Why an action was blocked
Without clear feedback, users relied on trial and error.
Design Challenge 3
Signaling completion, errors, and readiness
What we addressed
Solution
Why this mattered
The interface lacked clear signals for:
Completion states
Partial configuration
Errors requiring attention
This increased frustration and reduced confidence, especially during first-time setup.
We introduced subtle but persistent indicators that showed:
Completed sections
Partially completed sections
Errors that needed resolution
These indicators were visible within the navigation itself, giving users continuous awareness without interrupting flow.
Autonomous agents require a higher level of confidence before activation. Users need to know when the system is ready and why it may not be.
Clear signaling:
Reduced confusion and retries
Increased confidence during setup
Prevented premature or incorrect activation
This was essential for trust and adoption.
Administrators could only start an agent once required settings were complete, but users struggled to understand:
What was done
What was missing
Why an action was blocked
Without clear feedback, users relied on trial and error.
Design Challenge 4
Making knowledge sources visible, understandable, and trustworthy
What we learned from research
Solution
Why this mattered
We redesigned the knowledge source section to:
Clearly signal that user action was required
Separate actions from explanatory content
Surface added source names directly in the UI as confirmation
Within the constraints of cross-product integration, this gave users confidence that their actions had been completed successfully.
Grounding is foundational to agent performance. If users skip this step, agents technically function but deliver poor outcomes.
Making this step explicit:
Improved setup quality
Reduced silent failure modes
Increased trust in agent outputs
This ensured agents were not just active, but effective.
The issue was not intent. It was discoverability.
In its earlier form:
The section appeared visually similar to read-only content
Users did not recognize it as an actionable step
There was little confirmation that an action had succeeded
This was especially problematic because adding knowledge sources required navigating to Microsoft Copilot Studio, creating a disconnect in the flow.
Knowledge sources are critical to grounding an agent’s behavior. Without them, the agent lacks business-specific context and produces weaker results.
However, user research revealed that many administrators were skipping the knowledge source step entirely and proceeding with setup.
Design Challenge 4
Making knowledge sources visible, understandable, and trustworthy
What we learned from research
Solution
Why this mattered
We redesigned the knowledge source section to:
Clearly signal that user action was required
Separate actions from explanatory content
Surface added source names directly in the UI as confirmation
Within the constraints of cross-product integration, this gave users confidence that their actions had been completed successfully.
Grounding is foundational to agent performance. If users skip this step, agents technically function but deliver poor outcomes.
Making this step explicit:
Improved setup quality
Reduced silent failure modes
Increased trust in agent outputs
This ensured agents were not just active, but effective.
The issue was not intent. It was discoverability.
In its earlier form:
The section appeared visually similar to read-only content
Users did not recognize it as an actionable step
There was little confirmation that an action had succeeded
This was especially problematic because adding knowledge sources required navigating to Microsoft Copilot Studio, creating a disconnect in the flow.
Knowledge sources are critical to grounding an agent’s behavior. Without them, the agent lacks business-specific context and produces weaker results.
However, user research revealed that many administrators were skipping the knowledge source step entirely and proceeding with setup.
Design Challenge 4
Making knowledge sources visible, understandable, and trustworthy
What we learned from research
Solution
Why this mattered
We redesigned the knowledge source section to:
Clearly signal that user action was required
Separate actions from explanatory content
Surface added source names directly in the UI as confirmation
Within the constraints of cross-product integration, this gave users confidence that their actions had been completed successfully.
Grounding is foundational to agent performance. If users skip this step, agents technically function but deliver poor outcomes.
Making this step explicit:
Improved setup quality
Reduced silent failure modes
Increased trust in agent outputs
This ensured agents were not just active, but effective.
The issue was not intent. It was discoverability.
In its earlier form:
The section appeared visually similar to read-only content
Users did not recognize it as an actionable step
There was little confirmation that an action had succeeded
This was especially problematic because adding knowledge sources required navigating to Microsoft Copilot Studio, creating a disconnect in the flow.
Knowledge sources are critical to grounding an agent’s behavior. Without them, the agent lacks business-specific context and produces weaker results.
However, user research revealed that many administrators were skipping the knowledge source step entirely and proceeding with setup.
Design Challenge 5
Explaining complex behavior without overwhelming users
Design tension
Solution
Why this mattered
I redesigned this pattern into an on-demand “How it works” interaction.
A clearly labeled button signaled that help was available
Clicking it revealed a concise, structured explanation
Complex behavior was broken into four to five clear steps
A link to documentation supported deeper exploration
The explanation appeared only when requested, preserving screen space and focus.
Autonomous systems demand understanding, but not constant explanation.
This pattern:
Respected different experience levels
Scaled across features and agents
Prevented UI clutter as complexity increased
It established a reusable approach to explainability that balanced clarity with efficiency.
Together, these five challenges addressed:
Mental models
Navigation and scale
System state and readiness
Knowledge grounding
Explainability
We needed to support:
First-time users who needed guidance
Returning users who valued efficiency
A permanent explanation optimized for one group at the expense of the other.
Many configuration areas involved complex, multi-step logic. These required explanation, particularly for first-time users.
An earlier approach placed large blocks of static explanatory text directly into the interface. While helpful initially, this created problems for experienced users and did not scale well.
Design Challenge 5
Explaining complex behavior without overwhelming users
Design tension
Solution
Why this mattered
I redesigned this pattern into an on-demand “How it works” interaction.
A clearly labeled button signaled that help was available
Clicking it revealed a concise, structured explanation
Complex behavior was broken into four to five clear steps
A link to documentation supported deeper exploration
The explanation appeared only when requested, preserving screen space and focus.
Autonomous systems demand understanding, but not constant explanation.
This pattern:
Respected different experience levels
Scaled across features and agents
Prevented UI clutter as complexity increased
It established a reusable approach to explainability that balanced clarity with efficiency.
Together, these five challenges addressed:
Mental models
Navigation and scale
System state and readiness
Knowledge grounding
Explainability
We needed to support:
First-time users who needed guidance
Returning users who valued efficiency
A permanent explanation optimized for one group at the expense of the other.
Many configuration areas involved complex, multi-step logic. These required explanation, particularly for first-time users.
An earlier approach placed large blocks of static explanatory text directly into the interface. While helpful initially, this created problems for experienced users and did not scale well.
Design Challenge 5
Explaining complex behavior without overwhelming users
Design tension
Solution
Why this mattered
I redesigned this pattern into an on-demand “How it works” interaction.
A clearly labeled button signaled that help was available
Clicking it revealed a concise, structured explanation
Complex behavior was broken into four to five clear steps
A link to documentation supported deeper exploration
The explanation appeared only when requested, preserving screen space and focus.
Autonomous systems demand understanding, but not constant explanation.
This pattern:
Respected different experience levels
Scaled across features and agents
Prevented UI clutter as complexity increased
It established a reusable approach to explainability that balanced clarity with efficiency.
Together, these five challenges addressed:
Mental models
Navigation and scale
System state and readiness
Knowledge grounding
Explainability
We needed to support:
First-time users who needed guidance
Returning users who valued efficiency
A permanent explanation optimized for one group at the expense of the other.
Many configuration areas involved complex, multi-step logic. These required explanation, particularly for first-time users.
An earlier approach placed large blocks of static explanatory text directly into the interface. While helpful initially, this created problems for experienced users and did not scale well.
Deep Dive
Designing explainability for long-running autonomous processes
Principle: Never block users for background intelligence
Working closely with engineering leadership, we mapped long-running processes, error types, and system limitations. We designed the experience so users could initiate actions, navigate away, continue working, and remain informed through clear system communication.
Expectation setting and trust
Working within constraints
The action “Start agent” created anxiety. Some users assumed emails would be sent immediately. Others were unsure if anything would happen at all.
We explicitly communicated what would and would not occur before and after critical actions. Agents generated outreach drafts first. No customer communication occurred without explicit approval. This built trust gradually rather than assuming it.
Error handling and accessibility
Without a full simulation model initially, we introduced an intermediate trust-building mechanism where users reviewed drafts before activation. Clear messaging, background execution states, and consistent language helped users remain confident despite delays.
Errors were classified and communicated in plain language with clear next steps. Accessibility was validated at 400% zoom, with contrast and state visibility adjustments made where designs broke down.
Explainability became an ecosystem of interaction, copy, system states, and constraints rather than a single feature.
Autonomous agents rely heavily on asynchronous, long-running operations such as starting agents, validating configurations, fetching knowledge, and generating outreach drafts.
Blocking users during these processes would erode trust and productivity.
Deep Dive
Designing explainability for long-running autonomous processes
Principle: Never block users for background intelligence
Working closely with engineering leadership, we mapped long-running processes, error types, and system limitations. We designed the experience so users could initiate actions, navigate away, continue working, and remain informed through clear system communication.
Expectation setting and trust
Working within constraints
The action “Start agent” created anxiety. Some users assumed emails would be sent immediately. Others were unsure if anything would happen at all.
We explicitly communicated what would and would not occur before and after critical actions. Agents generated outreach drafts first. No customer communication occurred without explicit approval. This built trust gradually rather than assuming it.
Error handling and accessibility
Without a full simulation model initially, we introduced an intermediate trust-building mechanism where users reviewed drafts before activation. Clear messaging, background execution states, and consistent language helped users remain confident despite delays.
Errors were classified and communicated in plain language with clear next steps. Accessibility was validated at 400% zoom, with contrast and state visibility adjustments made where designs broke down.
Explainability became an ecosystem of interaction, copy, system states, and constraints rather than a single feature.
Autonomous agents rely heavily on asynchronous, long-running operations such as starting agents, validating configurations, fetching knowledge, and generating outreach drafts.
Blocking users during these processes would erode trust and productivity.
Deep Dive
Designing explainability for long-running autonomous processes
Principle: Never block users for background intelligence
Working closely with engineering leadership, we mapped long-running processes, error types, and system limitations. We designed the experience so users could initiate actions, navigate away, continue working, and remain informed through clear system communication.
Expectation setting and trust
Working within constraints
The action “Start agent” created anxiety. Some users assumed emails would be sent immediately. Others were unsure if anything would happen at all.
We explicitly communicated what would and would not occur before and after critical actions. Agents generated outreach drafts first. No customer communication occurred without explicit approval. This built trust gradually rather than assuming it.
Error handling and accessibility
Without a full simulation model initially, we introduced an intermediate trust-building mechanism where users reviewed drafts before activation. Clear messaging, background execution states, and consistent language helped users remain confident despite delays.
Errors were classified and communicated in plain language with clear next steps. Accessibility was validated at 400% zoom, with contrast and state visibility adjustments made where designs broke down.
Explainability became an ecosystem of interaction, copy, system states, and constraints rather than a single feature.
Autonomous agents rely heavily on asynchronous, long-running operations such as starting agents, validating configurations, fetching knowledge, and generating outreach drafts.
Blocking users during these processes would erode trust and productivity.
Decision and Influence
Driving long-term decisions under disagreement
Conflict 1: Wizard vs scalable framework
The wizard model was widely favored early due to its simplicity. I pushed back based on long-term risks: non-linear setup, frequent edits, and feature expansion would make it brittle.
By prototyping alternatives and framing the discussion around scalability rather than preference, we aligned on the two-column framework, avoiding future UX debt.
Conflict 2: System architecture vs user mental models
Settings were initially organized around internal micro-agents. As standalone agents emerged, this structure no longer matched user understanding.
I proposed reorganizing around user mental models, tested alternatives with real users, and demonstrated improved usability. The framework was restructured accordingly, future-proofing the experience.
Decision and Influence
Driving long-term decisions under disagreement
Conflict 1: Wizard vs scalable framework
The wizard model was widely favored early due to its simplicity. I pushed back based on long-term risks: non-linear setup, frequent edits, and feature expansion would make it brittle.
By prototyping alternatives and framing the discussion around scalability rather than preference, we aligned on the two-column framework, avoiding future UX debt.
Conflict 2: System architecture vs user mental models
Settings were initially organized around internal micro-agents. As standalone agents emerged, this structure no longer matched user understanding.
I proposed reorganizing around user mental models, tested alternatives with real users, and demonstrated improved usability. The framework was restructured accordingly, future-proofing the experience.
Decision and Influence
Driving long-term decisions under disagreement
Conflict 1: Wizard vs scalable framework
The wizard model was widely favored early due to its simplicity. I pushed back based on long-term risks: non-linear setup, frequent edits, and feature expansion would make it brittle.
By prototyping alternatives and framing the discussion around scalability rather than preference, we aligned on the two-column framework, avoiding future UX debt.
Conflict 2: System architecture vs user mental models
Settings were initially organized around internal micro-agents. As standalone agents emerged, this structure no longer matched user understanding.
I proposed reorganizing around user mental models, tested alternatives with real users, and demonstrated improved usability. The framework was restructured accordingly, future-proofing the experience.
Impact and Outcomes
Business impact
From March to October 2025, we went from early exploration to General Availability.
Within this period, I defined a complete agent framework from zero to production, establishing reusable patterns for autonomy, explainability, error handling, and supervision.
Today, three to six autonomous agents already run on this foundation. New agents reuse the same setup, navigation, and trust patterns, validating the system-level approach.
Before autonomous agents, human-led qualification conversion averaged around 10%.
With the Autonomous Sales Qualification Agent, conversion increased to ~70–80%, driven by better fit detection, consistent engagement, and timely follow-up. The system continues to be refined, but early results confirm meaningful customer value.
Impact and Outcomes
Business impact
From March to October 2025, we went from early exploration to General Availability.
Within this period, I defined a complete agent framework from zero to production, establishing reusable patterns for autonomy, explainability, error handling, and supervision.
Today, three to six autonomous agents already run on this foundation. New agents reuse the same setup, navigation, and trust patterns, validating the system-level approach.
Before autonomous agents, human-led qualification conversion averaged around 10%.
With the Autonomous Sales Qualification Agent, conversion increased to ~70–80%, driven by better fit detection, consistent engagement, and timely follow-up. The system continues to be refined, but early results confirm meaningful customer value.
Impact and Outcomes
Business impact
From March to October 2025, we went from early exploration to General Availability.
Within this period, I defined a complete agent framework from zero to production, establishing reusable patterns for autonomy, explainability, error handling, and supervision.
Today, three to six autonomous agents already run on this foundation. New agents reuse the same setup, navigation, and trust patterns, validating the system-level approach.
Before autonomous agents, human-led qualification conversion averaged around 10%.
With the Autonomous Sales Qualification Agent, conversion increased to ~70–80%, driven by better fit detection, consistent engagement, and timely follow-up. The system continues to be refined, but early results confirm meaningful customer value.
Reflection
This project moved extremely fast. In hindsight, I would invest earlier in deeper cross-team journey alignment and stronger strategic guardrails to reduce rework under shifting priorities.
However, there were no major compromises in user experience. The constraints were real, but decisions were deliberate, grounded in research, and oriented toward long-term platform health rather than short-term delivery.
Reflection
This project moved extremely fast. In hindsight, I would invest earlier in deeper cross-team journey alignment and stronger strategic guardrails to reduce rework under shifting priorities.
However, there were no major compromises in user experience. The constraints were real, but decisions were deliberate, grounded in research, and oriented toward long-term platform health rather than short-term delivery.
Reflection
This project moved extremely fast. In hindsight, I would invest earlier in deeper cross-team journey alignment and stronger strategic guardrails to reduce rework under shifting priorities.
However, there were no major compromises in user experience. The constraints were real, but decisions were deliberate, grounded in research, and oriented toward long-term platform health rather than short-term delivery.
Platform Thinking
The Sales Qualification Agent became the reference implementation for autonomous agents in Dynamics 365.
The framework now enables teams to build faster, stay consistent, and introduce new agents without fragmenting the admin experience. Autonomous agents are no longer bespoke projects, but a scalable platform capability.
Platform Thinking
The Sales Qualification Agent became the reference implementation for autonomous agents in Dynamics 365.
The framework now enables teams to build faster, stay consistent, and introduce new agents without fragmenting the admin experience. Autonomous agents are no longer bespoke projects, but a scalable platform capability.
Platform Thinking
The Sales Qualification Agent became the reference implementation for autonomous agents in Dynamics 365.
The framework now enables teams to build faster, stay consistent, and introduce new agents without fragmenting the admin experience. Autonomous agents are no longer bespoke projects, but a scalable platform capability.