The fastest way to waste an agent project is to begin with the agent. A team sees a capable model, imagines automation everywhere, and then searches for a process that might justify the technology. Strong business-process discovery works in the opposite direction: it identifies a real operational problem, understands how the work actually flows, and only then decides whether an agent adds enough value to justify its complexity.
This discovery discipline belongs directly in the current AB-100 architecture scope. Microsoft’s agent-adoption guidance likewise starts with business problems and use cases before platform selection. That sequencing matters because agentic systems are best suited to ambiguity, context, and adaptive decisions; they are not automatically better than deterministic automation.
The objective of discovery is therefore not to maximize the number of agent opportunities. It is to classify work accurately enough that the organization invests in the right problems and knows how success will be measured before implementation begins.
Observe the real process, not the official process map
Documented procedures often show an ideal sequence. Actual work contains inboxes, spreadsheets, side conversations, manual reconciliations, judgment calls, workarounds, and escalation habits that never made it into the process diagram. Agent design based only on official documentation risks automating a fiction.
Discovery should follow cases end to end. Interview people who perform the work, inspect artifacts and handoffs, identify where they wait for information, and note where experienced employees make decisions that novices find difficult. Those moments reveal whether the process is deterministic, knowledge-intensive, or genuinely ambiguous.
Separate high-volume repetition from high-value ambiguity
A task can be repetitive without needing an AI agent. Copying structured values between systems may be better handled by integration or workflow automation. An agent becomes more interesting when each case requires interpreting language, gathering context from several sources, reasoning over incomplete information, or deciding which tool to use next.
Volume still matters because a rare task may not justify the engineering and governance overhead. The strongest candidates often combine repeated demand with meaningful judgment cost: support triage, case summarization, proposal preparation, research assistance, exception analysis, or coordination across semi-structured systems.
Map decisions, inputs, actions, and consequences separately
A useful process model distinguishes four things. Inputs are the information available. Decisions are judgments made from those inputs. Actions are changes made in systems. Consequences are what happens if the decision or action is wrong. This structure makes agent boundaries easier to see.
For example, classifying a support case may be low consequence and highly reversible. Issuing a refund is higher consequence. An agent might make the first decision autonomously while preparing the second action for approval. Treating the entire process as one automation decision would hide that difference.
Look for information friction before automation friction
Many processes feel slow because people cannot find trustworthy context, not because the click sequence is difficult. Before adding tools that act, ask whether retrieval and summarization alone would remove the main bottleneck. A read-oriented agent can deliver value with a smaller risk surface than one that modifies production systems.
The internal article on contextual generative AI assistants is relevant because context quality often determines practical usefulness. If the business data is stale, contradictory, inaccessible, or poorly classified, the agent problem is partly a data-governance problem and should be treated that way.
Identify the rules that must remain deterministic
Every process contains constraints that should not be left to probabilistic interpretation. Regulatory thresholds, segregation-of-duties requirements, approval limits, required fields, financial controls, and contractual conditions are examples. Discovery should label these rules explicitly so that the eventual architecture can enforce them deterministically.
This also clarifies where an agent can help. The agent might interpret a request, collect evidence, or recommend a path, while a rule engine or workflow validates whether the requested action is permissible. Good agent design often surrounds flexible reasoning with rigid guardrails.
Measure reversibility before granting autonomy
Autonomy should increase as actions become easier to reverse and the system becomes easier to observe. Drafting a response is reversible. Sending the response is less reversible. Updating a customer record may be reversible with audit history. Moving money or deleting production data may require explicit human approval.
Discovery should score actions by consequence, reversibility, latency tolerance, and ability to detect error. That produces a more useful automation boundary than a generic “human in the loop” label. Some steps need prior approval; others can be allowed automatically and reviewed afterward.
Process ownership must exist before agent ownership can exist
An agent cannot fix a process that has no accountable owner. If nobody can decide which outcome matters, which exceptions are acceptable, or which data source is authoritative, the agent team will make business-policy decisions by accident. Discovery should identify the process owner and the people who own critical resources before implementation starts.
The Power Platform architecture perspective can be useful adjacent context because many agent projects cross existing business applications and automation platforms. Technical ownership and process ownership are not the same; both need to be represented when an agent can affect production workflows.
Success metrics should describe the business result
A pilot that measures only answer quality or model latency can look successful while the business process remains unchanged. Discovery should establish baseline measures such as cycle time, backlog, error rate, escalation frequency, resolution quality, customer effort, employee effort, or cost per case. The chosen metrics should match the reason the process was selected.
Agent-specific metrics can then explain the business result: tool failure rate, handoff rate, grounded-answer quality, approval rate, correction rate, and cost per completed task. Those are diagnostic measures, not substitutes for business outcomes.
A practical discovery program starts broad and becomes selective. Capture candidate pain points, classify the work, estimate volume and value, identify data and integration prerequisites, evaluate consequence and reversibility, and eliminate cases that are better solved with conventional automation or process redesign. Only the survivors deserve architecture work.
The generative AI and foundation models helps explain why this discipline matters: generative systems are flexible precisely because they are not fixed rule engines. That flexibility is valuable when the process contains language and ambiguity, but it introduces uncertainty that should be purchased only where the business benefit justifies it.
Discovery should also surface organizational readiness. A process may be technically suitable for an agent but operationally unready because teams disagree about policy, data owners cannot provide reliable access, or no one is prepared to own exceptions. Building the agent first does not remove those disagreements; it encodes them into software and makes later correction more expensive.
Small pilots are useful when they test the riskiest assumption rather than merely demonstrate a chat interface. If the uncertainty is whether the agent can retrieve enough context, test retrieval quality. If the uncertainty is tool safety, test constrained actions. If the uncertainty is user trust, put the agent in front of representative users. The pilot should reduce a specific decision risk.
Discovery also benefits from comparing the agent opportunity with a non-agent baseline. Ask what would happen if the organization improved search, standardized forms, added an integration, or simplified the process instead. An agent earns its place when adaptive reasoning adds value after simpler interventions are considered, not because generative AI was the first idea in the room.
Process variability should be measured, not guessed. If ninety percent of cases follow a stable rule and ten percent require nuanced judgment, the architecture might automate the stable majority conventionally and route only exceptions to an agent. That can reduce cost and uncertainty while preserving the value of adaptive reasoning where it is actually needed.
Teams should also note where the process depends on tacit expertise. Experienced employees often recognize patterns that are absent from documentation. Capturing those cues as examples, evaluation cases, or structured policy can improve an agent, but the discovery team should be careful not to assume that every expert intuition can be safely automated. Some judgment is valuable precisely because it includes accountability and context outside the available data.
A final discovery artifact should record assumptions explicitly. Teams should note which data is believed to be trustworthy, which exceptions are expected, what volume is forecast, which actions require approval, and what performance would count as success. Those assumptions become the first regression tests for the architecture. When reality changes, the organization can tell whether the agent should be tuned, redesigned, or retired instead of treating every outcome problem as a prompt problem.
The best agent opportunity is usually narrower than the first idea
Business-process discovery should make the eventual agent implementation easier because it gives builders a bounded problem: clear users, inputs, decisions, tools, consequences, owners, and measures. It also gives the architect a reason to say no when a fashionable agent idea is really a workflow, integration, search, or data-quality problem.
The result should not be a giant automation backlog. It should be a small set of opportunities where adaptive reasoning can remove real friction without creating disproportionate operational risk. That is the difference between deploying agents because the technology is available and designing agentic systems because the business process genuinely benefits from them.
