Microsoft AB-100: Agentic AI Architecture

Agentic AI changes solution architecture because a model is no longer limited to producing text. It can interpret intent, retrieve evidence, choose tools, coordinate specialized components, and initiate actions. That makes the architecture question much larger than “which model should we use?” The real design work is deciding what the system is allowed to know, decide, and do.

That is the useful way to approach the Microsoft AB-100 exam. Microsoft’s current English-language skills outline, effective October 14, 2026, centers on planning, designing, and deploying AI-powered business solutions. Microsoft’s AB-100 study guide documents the updated objectives; older July 22 summaries should not be mistaken for the current scope.

The Agentic AI Business Solutions Architect Expert credential is aimed at experienced solution architects. The role assumes that you can connect business process design with Copilot Studio, Microsoft Foundry, Dynamics 365, Power Platform, Microsoft 365, identity, security, and operational governance. The strongest preparation therefore looks like architecture work, not product-feature memorization.

Start by deciding where reasoning belongs

An agentic design should begin with the business process, not with the decision to use an agent. Break the process into triggers, information, decisions, actions, exceptions, and outcomes. Then ask which steps are deterministic and which genuinely benefit from probabilistic reasoning.

A renewal workflow is a good example. Detecting that a contract expires in 30 days is deterministic. Summarizing account history may benefit from a model. Recommending a next action may require reasoning over policy and customer context. Updating a CRM record should happen through a controlled tool. Approving an unusually large discount may require a human.

This separation prevents one of the most common architectural mistakes: turning the model into a universal workflow engine. Traditional software rules are still preferable when a requirement is explicit, testable, and safety-critical. Agentic reasoning should be used where ambiguity, interpretation, or flexible planning actually adds value.

Give every agent a responsibility boundary

A useful agent has a purpose that can be expressed without naming a Microsoft product. “Help the sales team” is vague. “Summarize customer context, recommend the next sales action, and draft outreach without changing commercial terms” is architectural.

The boundary should specify the inputs the agent can receive, the knowledge it can retrieve, the tools it may invoke, which actions are autonomous, which actions require approval, what conditions trigger escalation, and how success will be measured. Those decisions affect prompt design, identity, permissions, evaluation, and support ownership at the same time.

If several responsibilities share the same data, permissions, owner, and evaluation criteria, one well-designed agent may be simpler than a multi-agent system. If responsibilities require different trust zones or operating models, separation becomes easier to justify.

Use multi-agent designs only when the boundary is real

Multi-agent architecture is useful when specialization creates a meaningful control or ownership advantage. Different agents may need different permissions, separate domain owners, different evaluation standards, or independent runtime requirements. A research agent that can read broad information should not automatically share the same permissions as a transaction agent that can create orders or modify financial records.

The orchestration layer then becomes part of the control plane. It must decide which agent receives the task, what context is passed, what output is expected, and how errors or loops are handled. Structured handoff contracts are safer than allowing each component to exchange unconstrained prose.

Agentic workflow architecture has to account for state, handoffs, retries, guardrails, and recovery; these are not secondary implementation details. They determine whether a multi-agent system can be operated predictably after deployment.

Separate knowledge from tools

Knowledge answers “what does the system know?” Tools answer “what can the system do?” Combining those concepts carelessly is a major source of risk.

A policy manual may be suitable for governed retrieval. A current account balance should come from a structured system-of-record query. A refund should be an explicit action with validated parameters, authorization, and audit logging. The model can decide that a tool may be relevant, but the tool and surrounding application should still enforce non-negotiable rules.

Source authority matters as much as retrieval quality. Enterprise information may exist in SharePoint, Teams, CRM notes, copied PDFs, email attachments, and local exports. More indexed content can increase recall while reducing trust. Architects should define which sources are authoritative, how freshness is maintained, how permissions are preserved, and what happens when evidence is missing or contradictory.

Design identity and least privilege before autonomy

Every important arrow on an agentic architecture diagram should have an identity attached to it. When an agent retrieves a document, is access evaluated as the user, the application, or the agent? When a tool changes a Dynamics 365 record, which identity performs the update? When a Foundry agent accesses another Azure resource, which role assignment permits it?

These choices determine auditability and blast radius. Shared credentials and broad application permissions make an agent easier to prototype and harder to govern. Managed identities, governed connections, narrowly scoped roles, and explicit transaction limits make the system safer to operate.

Tool design should assume retries and partial failure. If an order submission times out after the downstream system has already accepted it, an automatic retry can create a duplicate. Idempotency keys, correlation identifiers, and status checks are architectural controls, not coding trivia.

Choose Copilot Studio and Foundry by operating model

Copilot Studio is useful when the solution is deeply connected to Microsoft 365, Dynamics 365, Power Platform, governed business workflows, or citizen-development operating models. It can combine knowledge, tools, triggers, topics, prompts, and agent flows while keeping much of the orchestration visible to business-oriented teams.

Microsoft Foundry becomes especially relevant when a solution needs deeper code-first control, model flexibility, custom tools, Azure-native identity, managed agent runtimes, evaluation, tracing, or a software-development lifecycle closer to traditional engineering.

The two approaches are not mutually exclusive. A business-facing Copilot Studio agent may call a specialized Foundry capability. The design question is whether the interface, identity, ownership, and failure behavior between them are explicit. AB-100 scenarios involving Copilot Studio and agents become much easier to reason about when platform choice follows the operating model rather than product preference.

Treat state and memory as governed data

Agent memory can improve continuity, but every stored fact creates a lifecycle question. Decide which information belongs only in the current conversation, which information belongs in an authoritative business system, and which information—if any—the agent should retain between interactions.

Durable business state should normally remain in systems that other applications and people can inspect. An agent should not become a hidden database of customer commitments, approvals, or operational decisions. If memory is used for personalization or workflow continuity, define retention, correction, user visibility, and deletion behavior.

State also affects security. A user who changes roles should not keep access to context gathered under an earlier permission set. A conversation handed from one agent to another should pass only the context required for the next responsibility. This is another reason to design handoffs as contracts rather than simply forwarding the entire transcript.

Put human oversight at specific decision boundaries

“Human in the loop” is not sufficiently precise for production architecture. Define exactly which decisions require review, who owns the queue, what evidence the reviewer sees, what happens if nobody responds, and how the decision is recorded.

A service agent may recommend a refund, automatically issue only policy-approved small credits, and route larger amounts for manager review. But a tool’s presence does not imply a confirmation step: Copilot Studio’s tool settings leave “Ask the end user before running” off by default unless explicitly configured. Enforce monetary limits, identities and approval state in the transaction service or deterministic flow, not merely in a prompt. An AB-100 architecture drill should attempt an over-limit refund under a low-privilege account and verify that no payment is created, even if the planner chooses the refund tool.

Do not confuse showing a person a task with obtaining enforceable production authorization. Microsoft’s Power Apps agent feed is a preview supervision surface, not a substitute for a refund service’s policy checks or approval records. The feed currently exposes items to anyone with Agent Task-table access; user-specific case details must not be assumed private inside the task list. For an AB-100 review, simulate an over-limit credit, removal of the approver role and a missing MCP-created task, then prove the transaction service refuses unauthorized actions regardless of what the interface displays.

Responsible AI changes structure in similar ways. Privacy affects prompts, memory, traces, and retrieval. Reliability affects fallbacks. Accountability affects ownership. Transparency affects user experience. Prompt injection affects how retrieved content and tools are isolated. These are architecture constraints that must be designed before the system is given meaningful autonomy.

Evaluate the chain of action, not just the final answer

A conventional chatbot can often be evaluated by looking at its response. An agentic system needs a deeper test model. Did it retrieve the right evidence? Did it choose the correct tool? Were the arguments valid? Did it respect authorization? Did it escalate when required? Did the business transaction actually complete?

Observability should reconstruct agent routing, retrieval, tool calls, approval decisions, errors and actual business results through correlated events. In a multi-agent workflow, trace whether a failure began with an inaccurate source, a missing permission, an unsafe handoff or a downstream timeout. Recording more private text is not automatically better: minimize sensitive prompts and tool outputs, enforce access and retention rules, and use source or transaction identifiers where possible. A final “refund successful” message is not proof of execution; reconcile the system-of-record transaction and surface an unknown outcome when confirmation is missing.

Preparation for Microsoft AB-100 is strongest when labs include failure cases: stale knowledge, unauthorized users, tool timeouts, conflicting sources, prompt injection, duplicate retries, missing approvals, and handoff loops. A solution architect is expected to design for those conditions, not simply demonstrate a successful happy path.

Architecture reviews should also cover lifecycle boundaries. Development credentials, test data, experimental tools, and permissive retrieval settings should not drift unchanged into production. Define how prompts, tools, agent instructions, model choices, knowledge sources, and permissions are versioned and promoted. A rollback plan matters because an agent can regress even when the surrounding application code has not changed.

Performance and resource trade-offs

Cost is another architecture constraint. Multi-agent orchestration, repeated retrieval, long context, tool calls, and high-capability models can increase latency and spend quickly. The right design may use a smaller model for classification or routing and reserve a more capable model for complex reasoning. Measure cost per successful business outcome rather than model-call cost in isolation.

For exam practice, take one architecture scenario and force yourself to defend the boundaries. Explain why a single agent is sufficient or why separation is justified, which identity each component uses, what source is authoritative, where approval is enforced, what telemetry proves success, and what happens during a partial failure. That exercise exposes weak architecture reasoning much faster than memorizing feature descriptions.

Deployment design should also distinguish development convenience from production trust. Test environments may use broad permissions, temporary data, or experimental tools, but promotion to production should require deliberate review of identities, knowledge sources, tool contracts, evaluation results, and rollback behavior. An agent can regress after a prompt, model, tool, or retrieval change even when application code is unchanged.

Capacity and latency deserve the same architectural treatment. A workflow that performs several model calls, retrieval operations, and agent handoffs may be functionally correct but too slow or expensive for the business process. Measure the complete task, not just individual model calls, and simplify orchestration when extra reasoning does not improve the outcome.

AB-100 is ultimately an architecture exam about responsibility. Models, agents, tools, data, identities, approvals, and observability each need a defined role. If you can explain where reasoning belongs, where deterministic controls belong, how authority is preserved, and how the system behaves when something fails, the agentic design becomes much easier to defend. That is also the difference between an impressive demo and a business solution that can be governed, supported, and trusted.