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.<\/p>\n
For Microsoft AB-100<\/a>, this skill sits upstream of detailed agent design. Microsoft\u2019s 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.<\/p>\n 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.<\/p>\n Once the outcome is clear, the team can ask whether each step contributes to it. This prevents automating legacy friction just because \u201cthat is how we have always done it.\u201d 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.<\/p>\n 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 \u201capprove request\u201d box may hide several different authorities depending on value, geography, customer type, or exception reason.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/a> become concrete only after discovery shows where those boundaries belong.<\/p>\n 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.<\/p>\n 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<\/a> are tightly connected because reliable automation starts with reliable evidence.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\nDiscover the outcome before documenting the workflow<\/h2>\n
Map actors, systems, and authority\u2014not only boxes and arrows<\/h2>\n
Capture the real process, including exceptions<\/h2>\n
Separate information work from action authority<\/h2>\n
Assess data readiness before promising automation<\/h2>\n
Decompose the process into agent-sized responsibilities<\/h2>\n
Use value, volume, variability, and risk to prioritize opportunities<\/h2>\n