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 \u201cwhich model should we use?\u201d The real design work is deciding what the system is allowed to know, decide, and do.<\/p>\n
That is the useful way to approach the Microsoft AB-100<\/a> exam. Microsoft\u2019s 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<\/a> documents the updated objectives; older July 22 summaries should not be mistaken for the current scope.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n A useful agent has a purpose that can be expressed without naming a Microsoft product. \u201cHelp the sales team\u201d is vague. \u201cSummarize customer context, recommend the next sales action, and draft outreach without changing commercial terms\u201d is architectural.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Agentic workflow architecture<\/a> 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.<\/p>\n Knowledge answers \u201cwhat does the system know?\u201d Tools answer \u201cwhat can the system do?\u201d Combining those concepts carelessly is a major source of risk.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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?<\/p>\n 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<\/a>, governed connections, narrowly scoped roles, and explicit transaction limits make the system safer to operate.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/a> become much easier to reason about when platform choice follows the operating model rather than product preference.<\/p>\n Agent memory<\/a> 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\u2014if any\u2014the agent should retain between interactions.<\/p>\n 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.<\/p>\n 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.<\/p>\n \u201cHuman in the loop\u201d 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.<\/p>\n 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<\/a> leave \u201cAsk the end user before running\u201d 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.<\/p>\nStart by deciding where reasoning belongs<\/h2>\n
Give every agent a responsibility boundary<\/h2>\n
Use multi-agent designs only when the boundary is real<\/h2>\n
Separate knowledge from tools<\/h2>\n
Design identity and least privilege before autonomy<\/h2>\n
Choose Copilot Studio and Foundry by operating model<\/h2>\n
Treat state and memory as governed data<\/h2>\n
Put human oversight at specific decision boundaries<\/h2>\n