AB-100: Business Process Discovery for AI Agents

The most expensive AI-agent mistake often happens before anyone chooses a model or opens Copilot Studio: the team automates the wrong process. A workflow can be technically feasible and still be a poor agent candidate because its inputs are unreliable, its exceptions dominate the happy path, its decisions require authority the agent should not have, or its business value is too small to justify the operating burden. Business process discovery is therefore the discipline that turns an attractive AI idea into an evidence-based architecture decision.

For Microsoft AB-100, this skill sits upstream of detailed agent design. Microsoft’s revised English blueprint takes effect on October 14, 2026; before then, candidates should treat those published changes as upcoming rather than already active. Across versions, however, solution architects still need to understand how work really happens before proposing AI. The goal is not to draw a perfect flowchart. It is to expose actors, decisions, data, exceptions, handoffs, controls, and measurable friction so the team can decide what should be automated, assisted, redesigned, or left human.

Discover the outcome before documenting the workflow

A process is not simply a sequence of steps. It exists to produce an outcome for a customer, employee, regulator, or business function. Begin discovery by defining that outcome and the measures that indicate success. For customer onboarding, success may mean a verified account opened within a target time without creating compliance risk. For invoice exception handling, it may mean resolving mismatches quickly while preserving approval controls. For employee support, it may mean answering routine questions without exposing restricted HR information.

Once the outcome is clear, the team can ask whether each step contributes to it. This prevents automating legacy friction just because “that is how we have always done it.” Some steps exist because of an old system limitation. Others are duplicated checks that can be consolidated. Some approvals are legally or financially meaningful and must remain. Process discovery should distinguish necessary controls from accidental complexity before AI is introduced.

Map actors, systems, and authority—not only boxes and arrows

Agents operate inside organizations, not abstract diagrams. A useful process map identifies who performs each task, which system contains the relevant state, what permissions are required, and who is accountable for a decision. A process that looks linear may cross five teams and three systems of record. An “approve request” box may hide several different authorities depending on value, geography, customer type, or exception reason.

Document the human role as carefully as the system integration. Is the person supplying judgment, verifying evidence, applying policy, negotiating with another party, or simply copying data between systems? Repetitive transcription is a good automation candidate. High-consequence judgment may be better supported by an agent that gathers evidence and recommends an action while leaving the decision with a human. The architecture should preserve meaningful accountability instead of confusing automation with ownership.

Capture the real process, including exceptions

Workshops often produce an idealized happy path. Production failures live in the exceptions. Ask what happens when required data is missing, a customer does not respond, two records conflict, an approval exceeds a threshold, a downstream API is unavailable, or a case falls outside policy. Review actual tickets, escalations, process logs, and operator notes rather than relying only on how managers believe the process works.

Exception frequency changes the design. If 80 percent of cases are routine and 20 percent require specialized judgment, an agent can automate or assist the common path and route the remainder. If exceptions are 60 percent of the workload and each is materially different, forcing a general-purpose agent into the center may create more complexity than it removes. Discovery should quantify exception classes and identify which can be handled deterministically, which need clarification, and which must escalate.

Separate information work from action authority

Many processes combine understanding and execution. An agent may summarize a case, find relevant policy, compare options, draft a response, and then perform an action such as updating a record or sending a message. These are different risk levels. Discovery should mark where the workflow moves from information assistance into state-changing operations.

That boundary informs tool permissions, confirmation requirements, and human approval. An agent can often be allowed to read broadly before it is allowed to write. A recommendation can be generated automatically while a payment, access grant, customer commitment, or legal status change requires explicit approval. In agentic workflow design, the safest architecture grants autonomy in proportion to the reversibility and consequence of the action. The general patterns in agentic workflow architecture become concrete only after discovery shows where those boundaries belong.

Assess data readiness before promising automation

Agents are sensitive to information quality because their decisions and responses are built from context. During discovery, list the data needed at each step and classify its source, owner, quality, freshness, and accessibility. If operators routinely fix missing fields from memory, the agent will face the same gap. If the true process relies on a spreadsheet that is not governed, that dependency must be addressed rather than hidden behind natural-language interaction.

Grounding is therefore a process-design issue as much as an AI issue. A task may appear suitable for automation until the team discovers that no authoritative source exists for the rule being applied. Conversely, a seemingly complex task may become straightforward once the relevant data is normalized and the decision can be expressed clearly. Process discovery and business readiness and grounding data are tightly connected because reliable automation starts with reliable evidence.

Decompose the process into agent-sized responsibilities

Do not assume that one agent should own the entire end-to-end process. After mapping the workflow, divide it into responsibilities with clear inputs, outputs, and failure behavior. One component may classify an incoming request, another retrieve account context, another compare the situation against policy, and a deterministic service may calculate a value. A coordinator can then sequence those capabilities while preserving approval points.

Good decomposition reduces ambiguity. Each tool or subagent has a narrower contract and can be tested independently. It also limits blast radius: a component that only retrieves knowledge cannot accidentally modify records. When the process crosses departments or security domains, separate agents may reflect real organizational boundaries better than one over-privileged agent. The design should follow the discovered process and authority model, not a desire to maximize the number of autonomous steps.

Use value, volume, variability, and risk to prioritize opportunities

A useful discovery backlog needs more than enthusiasm. Score candidate processes across dimensions that matter: transaction volume, manual effort, delay, error cost, customer impact, data readiness, decision clarity, integration complexity, and risk. High-volume repetitive work with clear rules and good data is usually easier to justify than a rare executive decision with ambiguous inputs.

Value should be measurable after launch. Define the baseline before automation: average handling time, escalation rate, first-contact resolution, error rate, abandonment, revenue leakage, compliance findings, or employee effort. Then define the expected mechanism of improvement. An agent that merely makes a process feel modern is not a business case. AB-100 business cases, sourcing, and model economics connect discovery evidence to the investment decision that follows.

Design human handoffs as part of the process, not as failure

A human handoff is often the correct result. Discovery should identify cases that require empathy, negotiation, formal accountability, specialist knowledge, or access the agent should not possess. The handoff should carry context: the user’s request, verified facts, attempted steps, retrieved evidence, tool results, and the reason escalation occurred. A human should not have to reconstruct the entire case from scratch.

Define who receives each escalation and how urgency is expressed. A compliance exception and a technical outage may require different queues. If the agent is uncertain, the process can allow clarification before escalation. If a safety or authorization condition fails, escalation may be immediate. Treating handoffs as first-class process nodes produces more reliable operations than pretending autonomy is the goal in every scenario.

Validate the discovered process with operators and evidence

Before designing the final solution, play the proposed process back to the people who perform it. Use real cases, including failures and edge conditions. Ask operators where the map is wrong, which data they distrust, which shortcuts they use, and which decisions cannot be reduced to the stated rule. Compare workshop descriptions with logs and actual case histories.

Then prototype the smallest useful slice. A discovery hypothesis can be tested with a read-only assistant before write permissions are introduced. The team can measure whether the agent retrieves the right information, identifies the correct next step, and recognizes when the case is outside scope. This approach turns process discovery into an iterative engineering activity rather than a one-time requirements meeting. For AB-100, the key habit is to connect business-process understanding to architecture: the process tells you what the agent should do, the data tells you what it can know, and the risk model tells you how much autonomy it should receive.

Discovery should also capture temporal behavior. Some processes are synchronous conversations; others wait hours or days for approvals, files, customer responses, or external events. An agent architecture that works in a five-minute demo can fail when it must resume after a long pause with changed data. Record what state must persist, which facts must be refreshed after waiting, and what should happen if the original approver or resource is no longer available.

Another useful lens is reversibility. Classify each step by how easy it is to undo. Drafting a message is reversible; sending it to a customer is less so. Recommending an account change is reversible; deleting data or transferring funds may not be. Reversibility can guide where autonomy is appropriate. Low-risk reversible actions can be automated earlier, while irreversible or high-impact steps retain stronger confirmation, approval, or segregation-of-duties controls.

Process discovery should produce an explicit “not for the agent” list as well. Some tasks may remain manual because policy forbids automation, data is too sensitive, judgment is legally reserved for a human, or the process changes too rapidly to justify integration. Recording these exclusions prevents scope creep during implementation. It also gives stakeholders confidence that the project is optimizing the process deliberately rather than assuming every human action is inefficiency.

After a pilot, revisit the process map with observed data. Compare predicted and actual exception rates, handoff volumes, tool failures, and user corrections. An agent may expose a hidden bottleneck that discovery missed—for example, a policy approval rather than the data-entry step may be the real delay. Treat the map as a living architecture artifact. Business processes evolve, and the automation boundary should evolve with them.

Discovery artifacts should be usable by engineers after the workshops end. Keep a process inventory with owners, systems, inputs, outputs, exception classes, metrics, and the proposed automation boundary. Link decisions back to evidence such as ticket volumes or cycle-time data. When requirements change later, the team can revisit why a step was automated instead of relying on memory.

For exam scenarios, beware options that jump directly from “a process is repetitive” to “deploy an autonomous agent.” Repetition is only one factor. Data quality, exception complexity, consequence, permissions, and measurable business value determine the appropriate pattern. A copiloted human workflow may be the right architecture even when full automation is technically possible.