Microsoft · Dynamics 365 sales
Autonomous Sales Agents
Designing the first autonomous agent in Dynamics 365 Sales end to end, and the framework that now governs every agent that follows.
ROLE
Lead UX Designer
YEAR
2025
COMPANY
Microsoft
Scope
Agent design and framework, end to end
The two-column configuration framework that became the governing pattern for every autonomous agent in Dynamics 365.
Lead qualification conversion
8 months
Concept to General Availability
3 agents
Built on the same foundation
Dynamics 365 Sales platform
At a glance
Lead UX Designer
Role
Mar – Oct 2025 · Concept to GA
Timeline
Five agent squads · Eng & PM
Team
Dynamics 365 Sales · 3M+ MAU
Platform
What I did
Designed the Sales Qualification Agent end to end, the first autonomous agent on the platform.
Defined the agent framework and trust patterns every later agent now reuses.
Drove the core structural decisions and aligned five squads around one model.
Lead qualification conversion 10% →80%
overview
A case study about trust.
This is a case study about designing trust in software that acts on its own. An autonomous agent researches, messages, qualifies, and hands over real leads with little human input. The hard part was never the automation. It was getting a person to believe in it enough to switch it on, and to feel in control once they had.
I designed the Sales Qualification Agent end to end: the first autonomous agent in Dynamics 365 Sales, from how it presents itself and communicates its reasoning to how it is configured, supervised, and trusted. Because it was the first agent on the platform, the work was two jobs at once. The framework and trust patterns that made this one agent believable had to work for every agent that would follow, so what I designed here became the foundation that now powers multiple autonomous agents across Dynamics 365.
context
The 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. My first assignment was to explore how sales workflows could evolve with AI and machine learning, drawing on my SAP Business AI background. I built an early proof of concept showing how intelligence could move beyond assistance toward autonomy: systems that reason, act, and learn with minimal human intervention, while staying controllable.
That vision was presented to senior US leadership and became a catalyst for investment in an agent-first direction. By early 2025, market pressure accelerated everything. The challenge was no longer enhancing a CRM. It was redefining how sales could operate with AI at scale.
The ambition was explicit: build for agent-first teams with human oversight, not just human teams with AI assistance. Productivity gains alone were not enough.
The frame
Levels of AI operations.
The work was grounded in a clear maturity model for how AI shows up inside a sales team. It set the ambition and shaped every decision that followed, especially around trust, control, and scale.
Level 1 — human-first, with light AI augmentation
Level 2 — human-led teams supported by autonomous agents
Level 3 — agent-first teams with human oversight
Level 4 — fully autonomous operations
The point was blunt. A product built only for Level 2 risks being disrupted by anyone delivering Level 3 or 4. Autonomous agent teams change the economics of selling: more revenue per seller without growing headcount in step. So this could not be a productivity feature bolted onto a CRM. It had to be designed as a new way of operating.
The problem
Powerful enough to automate, approachable enough to trust.
Traditional qualification leans heavily on human effort, which makes it costly, inconsistent, and slow to scale. Roles like sales development reps are hard to hire and retain, and they bottleneck the top of the funnel.
From a UX angle the problem went deeper. No administrator had ever configured a fully autonomous sales agent before. The system had to be powerful enough to support genuinely complex automation, yet approachable enough that a person would set it loose on real customers and trust it to act on their behalf. Holding both at once, power and confidence, was the design problem underneath everything that followed.
my role
Designing the first agent, and the system behind it.
My title was Senior UX Designer, but the work spanned two levels at once. First, I designed the Sales Qualification Agent itself, end to end: the first autonomous agent in Dynamics 365 Sales, from how it presents and reasons to how it is configured, supervised, and trusted. Second, because it was the first, I had to define the agent framework and cognitive model beneath it, how agents are configured, how they reason, how they operate over time, and how people supervise them, and design it for this agent while keeping every future agent in mind.
That was the hard part. I was shaping a real, shipping product and, in the same strokes, the shared foundation it would all sit on. It forced me to think in systems and at scale from day one, while several teams built individual capabilities like outreach, research, and assignment logic in parallel and I kept the whole experience coherent.
Specifically, I was responsible for:
The end-to-end Sales Qualification Agent experience: presentation, reasoning, configuration, supervision, and trust
The agent profile, prerequisites, and automation levels
How agents reason about customer context and value propositions
How agents explain decisions and background actions
Knowledge retrieval and grounding via Microsoft Copilot Studio
Interaction patterns for long-running, asynchronous processes
Guardrails for running multiple agents without conflict
I also designed and shipped the critical surfaces where these principles had to become tangible, including simulation and conversational interactions.
The core of the work
Designing a complex system into something simple to run.
The hardest part was never a single screen. It was the complexity behind all of them. My job was to take a genuinely complex piece of software and make it something an administrator could understand, control, and trust, without dumbing it down. Here is what I was designing for, and how I reduced it.
The complexity I was designing for
No precedent. No mental model existed for configuring an autonomous agent in Dynamics 365. The structure had to be invented.
Deep, hidden machinery. Research, engagement, reasoning, grounding, supervision, and multi-agent guardrails, all of which users had to control without seeing the internals.
Many states, much of it asynchronous. Partial configuration, errors, readiness, and long-running background processes that change over time.
Built by many hands. Five squads shipping capabilities in parallel, with no shared model to hold them together.
Two audiences at once. First-time admins who need guidance, and power users who need speed.
It all had to scale. Whatever I designed became the foundation for every future agent.
How I made it simple to run
One mental model. A two-column structure around three human ideas, Workflow, Guidance, and Knowledge, instead of mirroring the system's architecture.
Progressive depth. The essentials to launch up front, advanced tuning tucked away until needed, so complexity never blocked a start.
State made legible. Persistent complete, partial, and error indicators, so people always knew where they stood and when it was safe to start.
The hidden step made obvious. Knowledge grounding turned from a silent skip into a clear, confirmable action.
Explanation on demand. Complex behaviour explained only when asked for, never cluttering the screen.
One reusable framework. The same patterns across every agent, so the platform grew simpler, not more tangled.
I never tried to hide the complexity. I made it legible, and surfaced depth only when someone needed it.
design challenge 1
The right mental model for configuring an autonomous agent.
The trust question: can someone understand and control an agent without seeing its internals?
This was the most consequential decision in the project. No mental model existed for configuring autonomous agents inside Dynamics 365. Whatever structure we introduced would not just shape this agent. It would become the foundation for every future agent on the platform. The task was to expose complex agent behaviour in a way administrators could understand, control, and trust, without overwhelming them or leaking internal system architecture.
Agent Architecture
What we tried
We started from the minimum technical building blocks, which produced a stacked, capability-grouped model. It validated feasibility and aligned teams, but usability problems surfaced fast: long vertical flows, unclear completion states, and internal micro-agent architecture exposed straight to users. The structure mirrored how the system was built, not how administrators think.
We explored grid-based configuration, prompt-driven setup, and a wizard. Each solved part of the problem and broke something else, usually guidance, scalability, or editability.
1.Stacked configuration
2.Grid configuration
3.Prompt configuration
4.Wizard configuration
Where we landed
A two-column layout: persistent navigation on the left, contextual configuration on the right, organised around three concepts that map to how people actually think about an agent.
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
It balanced clarity with flexibility, supported first-time setup and frequent iteration, and absorbed new features without structural redesign. This layout became the governing pattern for all autonomous agents in Dynamics 365.
Why it mattered: autonomous agents are a new interaction paradigm. Get the mental model wrong and every feature built on top compounds the error. Getting it right early prevented UX debt across future agents, repeated redesigns as capabilities grew, and a lasting mismatch between what users expected and how agents behaved.
Four configuration models were prototyped and tested before the two-column framework won on scalability.
design challenge 2
Holding navigational clarity as the system grew.
The trust question: does the system stay legible as it keeps growing?
As capabilities were added rapidly, the early skill-based categorisation started to break down. Unrelated settings clustered together, sections overloaded, and the lifecycle logic weakened. The experience began to reflect feature accumulation rather than a coherent system.
I introduced progressive depth: basic settings needed to launch an agent, and advanced settings for fine-tuning. Administrators could get an agent running quickly and return later to optimise, without being blocked by optional complexity, and the structure could keep absorbing new capability gracefully.
Why it mattered: autonomous systems never stop evolving. Without a way to absorb new capability gracefully, the admin experience would have grown brittle, harder to learn, and harder to maintain. Progressive depth kept it approachable for newcomers while preserving the depth and control that power users rely on.
Progressive depth: launch on the essentials, return for advanced tuning, without being blocked by optional complexity.
design challenge 3
Signalling completion, errors, and readiness.
The trust question: can I tell when it is safe to let the agent loose?
An agent could only start once its required settings were complete, but the interface gave people no real sense of where they stood. They could not tell what was done, what was missing, or why an action was blocked, so they fell back on trial and error. For a system about to act autonomously on real customers, that uncertainty was corrosive to trust.
I introduced subtle but persistent indicators inside the navigation itself: completed sections, partially complete sections, and errors that needed attention, all visible at a glance and without interrupting the flow. People always knew the system's state and exactly what stood between them and a confident launch.
Why it mattered: autonomous agents demand a higher level of confidence before activation. Clear signalling cut confusion and retries, raised confidence during setup, and prevented premature or incorrect activation. It was foundational to trust and adoption.
State indicators live inside the navigation, so people always know what is done, what is missing, and when it is safe to start.
design challenge 4
Making knowledge grounding impossible to miss.
The trust question: is the agent actually grounded in my business, or just running?
Grounding is what gives an agent business-specific context. Without it the agent still runs, but its output is weak. Research surfaced a quiet, damaging pattern: administrators were skipping the knowledge step entirely and proceeding straight to launch.
It was not a matter of intent, but of discoverability. The section looked almost identical to read-only content, gave little confirmation that anything had been added, and required a detour into Microsoft Copilot Studio that broke the flow. I redesigned it to clearly signal that action was required, separate the action from the explanatory copy, and surface added source names directly in the UI as confirmation.
Why it mattered: making the step explicit improved setup quality, removed a silent failure mode, and increased trust in what the agent produced. It made sure agents were not just active, but actually effective.
Grounding moved from a silent skip to a visible, confirmed step, with source names surfaced directly in the UI.
design challenge 5
Explaining complex behaviour without overwhelming.
The trust question: do I understand what it will do, without being buried in text?
Many configuration areas involved genuinely complex, multi-step logic that first-time users needed explained. An early approach dropped large blocks of static help text straight into the interface. It helped beginners, but it cluttered the screen for everyone else and did not scale as features multiplied.
I redesigned this into an on-demand "how it works" interaction. A clearly labelled control signalled that help was available; opening it revealed a concise, structured explanation broken into a few clear steps, with a link to documentation for anyone who wanted to go deeper. The explanation appeared only when asked for, preserving focus and space.
Why it mattered: autonomous systems need to be understandable, but not constantly explained. The pattern respected different experience levels, scaled across features and agents, and stopped the interface from drowning in help text as complexity grew. It became a reusable approach to explainability.
deep dive
Explainability for long-running, autonomous work.
The trust question: can I rely on it while it works out of sight?
Agents lean on asynchronous operations: starting up, validating configuration, fetching knowledge, generating outreach drafts. Blocking people through those waits would erode both trust and productivity. The governing principle became simple: never block users for background intelligence.
"Start agent" created anxiety. Some assumed emails went out instantly; others were unsure anything happened at all. So we set expectations explicitly. Agents generated outreach drafts first, and no customer communication happened without explicit approval. That built trust gradually instead of assuming it.
Where a full simulation model was not yet possible, I introduced an interim trust mechanism: people reviewed drafts before anything activated. Errors were classified and written in plain language with clear next steps, and the experience was validated at 400% zoom, with contrast and state fixes wherever designs broke down. Clear messaging and visible background-execution states kept people confident even through the waits.
Explainability became an ecosystem of interaction, copy, system state, and constraint, not a single feature.
Leadership
Leading the call under disagreement.
The wizard model was popular early because it looked simple. I pushed back on long-term risk: setup is rarely linear, edits are frequent, and feature growth would make it brittle. By prototyping the alternatives and framing the discussion around scalability rather than preference, the team aligned on the two-column framework and avoided years of future UX debt.
Later, settings were organised around internal micro-agents. As standalone agents emerged, that structure stopped matching how users understood the system. I proposed reorganising around user mental models, tested the alternatives with real users, showed the usability gain, and the framework was restructured accordingly.
impact
From zero to a platform capability.
From March to October 2025 we moved from early exploration to General Availability. In that window I designed and shipped the Sales Qualification Agent from zero to production and, with it, a complete agent framework: reusable patterns for autonomy, explainability, error handling, and supervision. Three further autonomous agents now run on that foundation, reusing the same setup, navigation, and trust patterns, which validates the system-level approach.
Before autonomous agents, human-led qualification conversion averaged around 10%. With the Autonomous Sales Qualification Agent, conversion rose to roughly 70–80%, driven by better fit detection, consistent engagement, and timely follow-up. Autonomous agents in Dynamics 365 are no longer bespoke projects. They are a scalable platform capability, and this work is the reference implementation.
Reflection
The 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. The constraints were real, but the decisions were deliberate, grounded in research, and oriented toward long-term platform health over short-term delivery.
What it taught me
Principles for designing autonomous AI.
The same few ideas surfaced again and again. They now shape how I approach any system that acts on a person's behalf.
Earn trust before you ask for it.
Show the system's state, its reasoning, and its limits before expecting anyone to hand over control.
Never block a person for background intelligence.
Let people act, move on, and stay informed. Autonomy should remove waiting, not add it.
Make the invisible step impossible to skip.
If a hidden action decides whether the system works, the interface has to insist on it.
When you build the first, design the system, not the screen.
The real deliverable is the pattern every later thing will inherit, so it has to be right before it is reused.
Platform thinking
From one agent to a platform capability.
The Sales Qualification Agent became the reference implementation for autonomous agents in Dynamics 365. Because its framework was designed for scale from the start, new teams can now build faster, stay consistent, and introduce new agents without fragmenting the admin experience. Autonomous agents stopped being bespoke, one-off projects and became a repeatable platform capability. That was the real goal all along, and designing the first agent and its framework together is what made it possible.
next