Agentic solution architecture for Microsoft AB-100 Agentic AI Business Solutions Architect: Concepts, Scenarios, and Study Priorities

 

Agentic architecture is not the act of adding an agent to an existing application. It is the design of a system in which models can interpret intent, retrieve information, choose tools, coordinate work, maintain context, and sometimes act with limited autonomy—while remaining inside explicit business, security, and operational boundaries.

That distinction is central to Microsoft AB-100. The current September 2026 blueprint expects candidates to design agentic-first solutions, multi-agent orchestrations, secure cross-platform AI architectures, integrations across Microsoft 365 Copilot, Copilot Studio, Microsoft Foundry, Dynamics 365, and Power Platform, and the lifecycle controls required to operate them responsibly.

If you are reviewing the AB-100 exam, treat “agentic solution architecture” as a set of responsibility decisions. What does the agent decide? What does a tool decide? What remains deterministic? What requires a human? Which identity acts? Which data is available? Which component records evidence? Those questions are more useful than memorizing an agent definition.

Start with work, not with agents

A sound agentic architecture begins by decomposing the business process.

Write the process as triggers, information, decisions, actions, exceptions, and outcomes. Then mark which parts are deterministic and which require flexible interpretation or reasoning.

For example, consider a customer-renewal process. The system may need to detect an approaching renewal, summarize account history, identify usage trends, recommend an offer, draft an outreach message, update CRM, and escalate discounts above a threshold.

Not every step needs an agent. Date detection and discount thresholds are deterministic. Summarization and recommendation may benefit from generative AI. CRM updates should be executed through controlled tools. Large discounts may require a human approval workflow.

This decomposition prevents a common architecture anti-pattern: using the model as a universal process engine when normal software controls are safer and easier to test.

Define the agent’s responsibility boundary

Every agent should have a clear purpose that can be expressed without naming a product.

“Help sellers” is vague. “Summarize customer and opportunity context, recommend the next sales action, and draft supporting content without modifying commercial terms” is a responsibility boundary.

The boundary should include:

• the agent’s goal;
• the inputs it can receive;
• the knowledge it can access;
• the tools it may invoke;
• the actions it may perform autonomously;
• the actions requiring approval;
• the conditions that require escalation;
• the evidence used to evaluate success.

A precise boundary improves instructions, tool permissions, evaluation, and ownership simultaneously.

If one agent has too many unrelated responsibilities, you may need to split it. If several agents have nearly identical knowledge, permissions, and evaluation criteria, you may be overengineering a multi-agent solution.

Single-agent architecture is often the right default

A single orchestrating agent with well-defined tools can handle surprisingly complex work. It can retrieve information, call APIs, ask for missing details, invoke workflows, and route exceptions to people.

The advantages are important: fewer handoffs, simpler context management, lower latency, easier tracing, less duplicated prompt/instruction logic, and fewer identities to govern.

Use a single-agent design when responsibilities are closely related and the same security boundary can apply across the work.

For example, an internal HR assistant might answer policy questions, create a service ticket, and check ticket status through one agent if all three tasks use the same user context and low-risk tools.

Multi-agent architecture should therefore earn its complexity.

When multi-agent architecture is justified

Separate agents can be valuable when there is a meaningful boundary.

Different permissions: A research agent can read broad data, while a transaction agent has a narrowly scoped permission to create a record.

Different owners: Finance and HR may need independent policy ownership even when one workflow spans both.

Different evaluation criteria: A summarization agent and an approval recommendation agent may require different quality and safety measures.

Different knowledge domains: Specialization can improve clarity when each agent needs distinct instructions and evidence.

Different risk levels: A customer-facing response agent and a privileged operational agent should not necessarily share the same autonomy or tool set.

Independent scaling or runtime needs: A specialized code-first agent may require a different platform or model than the business-facing orchestrator.

The AB-100 mistake is to interpret “design a multi-agent solution” as “prefer many agents.” The architecture skill is knowing when separation reduces risk or improves ownership enough to justify orchestration overhead.

Orchestration is a control plane, not a magic layer

Once several agents exist, the system needs a clear way to decide who handles what.

The orchestrator may use intent, tool descriptions, agent descriptions, workflow rules, or a combination. Whichever method is chosen, define how context is passed, how results return, how errors propagate, and how loops are prevented.

Consider a sales workflow with a research agent, pricing agent, and order agent. If the research agent hands unstructured text to pricing, and pricing hands another free-form response to order entry, ambiguity accumulates. Structured contracts between components can reduce that risk.

Treat agent-to-agent handoffs like service interfaces. Define input, output, error, and authorization expectations. Natural language can remain part of the payload without becoming the only contract.

In architectures using open protocols such as A2A or MCP, the same principle applies: standardization helps interoperability, but governance is still required.

Knowledge is evidence; tools are capability

A strong agent architecture separates knowledge and tools.

Knowledge helps the agent understand facts, policy, procedures, documents, or context. A tool lets the agent perform or retrieve something through an explicit operation.

A current account balance belongs behind a structured query tool because freshness and accuracy matter. A policy manual may be appropriate for governed retrieval. A refund should be an action tool, not a prompt that asks the model to “update the system somehow.”

This distinction also improves security. Tool permissions can be limited. Inputs can be validated. Outputs can be logged. Sensitive actions can require approval. Knowledge retrieval can apply source permissions independently.

When an architecture puts everything into a vector index, it often loses transactional freshness and control. When everything becomes an API call, it may lose the flexibility of semantic grounding. Use each mechanism for the responsibility it handles best.

Grounding architecture begins with source authority

Retrieval-augmented generation is useful only if the architecture knows which sources are trustworthy.

Enterprise data often exists in multiple places: official policy repositories, copied PDFs, email attachments, Teams conversations, CRM notes, SharePoint sites, line-of-business applications, and local exports. Indexing all of them can increase recall while reducing trust.

Define authoritative sources, ownership, refresh, and retirement. Decide how the retrieval system reacts when a document is superseded. Preserve authorization boundaries. Determine whether retrieved content should include provenance or citations in the user experience.

Then design for missing evidence. A reliable agent should be able to say that it lacks enough authoritative information rather than fill the gap with a plausible answer.

AB-100 scenarios involving grounding often become easier when you ask whether the design preserves authority, freshness, and access—not merely whether retrieval is technically possible.

Tools need contracts and least privilege

A tool description is part of orchestration quality. The agent needs to understand when a tool is appropriate, what inputs it requires, what it changes, and what it returns.

A weak tool called `UpdateCustomer` with broad permissions creates ambiguity. A stronger design may expose narrower operations such as `UpdatePreferredContactMethod` or `CreateServiceCase`, each with validated parameters and least-privilege authorization.

High-risk tools require additional control. The model should not be the only component deciding whether the action is authorized. Approval workflows, deterministic business rules, role checks, transaction limits, or policy engines can create a boundary the model cannot override.

Design idempotency where actions may be retried. If an agent times out after submitting an order, a blind retry can create duplicates. The tool should support a correlation or request identifier and a way to check outcome before repeating the operation.

These details are not implementation trivia; they define whether an agentic workflow can be trusted.

Identity is part of the architecture diagram

Every important arrow should have an identity.

A user asks the agent a question. Does retrieval occur under the user’s identity, an agent identity, or an application identity? A tool updates Dynamics 365. Which identity performs the update? A Foundry agent calls Azure Search. Which role has been assigned?

The identity decision affects data access, auditing, ownership, and blast radius.

Modern Microsoft Foundry agent applications can receive dedicated identities when published. A capability that works during development may fail in production if RBAC is not assigned to the published identity. That is exactly the kind of lifecycle detail an architecture must anticipate.

Avoid embedding shared credentials in agent configuration where managed identity, federated credentials, or governed connection mechanisms are available. Credential lifecycle is part of system lifecycle.

Copilot Studio is an orchestration option, not just a bot builder

Copilot Studio can provide the user-facing agent, generative orchestration, knowledge, tools, agent flows, autonomous triggers, topics, prompts, MCP integrations, computer use, and Microsoft business application connectivity.

It is especially strong when the business process already lives in Microsoft 365, Dynamics 365, Power Platform, or governed enterprise workflows.

Generative orchestration allows the runtime to dynamically choose among tools, knowledge, topics, and other components. That increases the importance of high-quality descriptions and bounded capabilities. If several tools have overlapping descriptions, the model may choose inconsistently.

Autonomous operation adds another risk dimension because no interactive user request initiates every action. Event triggers, approval, action limits, identity, and observability become critical.

Computer use can bridge legacy interfaces that lack APIs. Use it deliberately, recognizing that GUI-based automation has different failure modes from an API contract.

The Copilot Studio deep dive is useful when you want to explore those mechanics in more detail.

Microsoft Foundry supports code-first and managed agent architectures

Microsoft Foundry is appropriate when the solution needs model flexibility, code-first control, managed agent runtime, custom tools, enterprise Azure integration, deeper evaluation, or a development lifecycle that sits closer to software engineering.

Current Foundry Agent Service supports prompt agents, hosted code-based agents, tool integration, tracing, evaluation, model choice, and enterprise identity controls. The platform has changed significantly from older Azure AI Foundry and Assistants API patterns, so current terminology matters in 2026.

Foundry projects also create an isolation boundary. Agents within a project can share certain project resources, while projects separate data and access. Use that boundary intentionally for environment, ownership, or workload isolation.

A hybrid architecture may expose a specialized Foundry capability to a Copilot Studio or Microsoft 365-facing agent. In that case, define the interface and identity between platforms clearly. Do not allow “hybrid” to become an excuse for vague responsibility.

MCP can standardize a shared tool layer

Model Context Protocol is valuable when several agents need access to reusable tools or resources. A centrally managed MCP server can publish tool names, descriptions, inputs, and resources so multiple agents discover a consistent interface.

This can improve maintainability. If an underlying API changes, the organization may update the MCP implementation rather than editing every consuming agent.

But MCP does not eliminate normal integration concerns. The server must authenticate callers, enforce authorization, protect secrets, expose safe schemas, version or deprecate tools, and log usage. Third-party MCP servers require additional trust review.

Use MCP where a shared tool ecosystem creates value. A single simple API call may not justify an extra protocol and governance layer.

State and memory must have an explicit purpose

Agents can maintain conversation context or longer-term state, but storing more memory is not automatically better.

Separate short-lived conversational state from durable business state. The system of record should remain authoritative for transactions and important business facts. Agent memory may improve continuity, but it should not become a hidden database of decisions that other systems cannot see.

Define what is stored, retention, privacy, user control, and how stale or incorrect memory is corrected. Sensitive memory can create compliance risk. Persistent personalization can create unexpected behavior if users share contexts or roles change.

A good architecture stores only the state needed to deliver the approved experience and keeps critical business data in governed systems.

Human oversight should be placed at decision boundaries

“Human in the loop” is too vague to be an architecture.

Identify exactly where human approval is required. It may be before a high-value transaction, before external communication, when confidence falls below a threshold, when policy conflicts exist, or when the agent encounters a novel case.

Then define what the person sees. A supervisor reviewing a refund should receive relevant evidence, customer context, reason for the proposed action, and the exact transaction to approve. Approval should be enforced by the workflow or tool rather than by a prompt instruction.

Human review also needs an operating model. Who owns the queue? What is the SLA? What happens if nobody responds? How is the decision logged? Architecture includes the human process surrounding the AI.

Responsible AI changes the system structure

Responsible AI is not a slide at the end of the design.

Reliability influences fallback and evaluation. Privacy affects what data enters prompts, traces, memory, and model tuning. Transparency affects user disclosure and provenance. Accountability affects ownership and approvals. Inclusiveness affects interface and accessibility. Fairness affects representative testing and outcome review.

High-impact decisions may need deterministic policy gates. An agent can summarize or recommend, while a rules engine enforces non-negotiable limits.

Prompt injection and indirect prompt injection are especially relevant to agentic systems because the model can call tools. Treat retrieved content as untrusted data. Restrict tool permissions, validate inputs, isolate high-risk actions, and test adversarial cases.

Observability must reconstruct the chain of action

For a simple chatbot, logs may focus on requests and responses. For an agentic system, operators need to understand the entire plan.

Useful telemetry can include user or trigger context, selected agent, retrieved evidence, model, tool choices, arguments, tool results, approvals, latency, errors, safety signals, and final business outcome.

Distributed traces become valuable in multi-agent or multi-tool systems. Without them, a failed transaction can be difficult to attribute to retrieval, reasoning, tool selection, permissions, or a downstream system.

Observability should also support business analysis. A technically healthy agent that increases rework is failing.

Evaluation should test architecture behaviors

Evaluation is stronger when it maps to responsibilities.

If the agent is responsible for selecting a tool, measure tool-selection accuracy. If it generates structured arguments, validate those arguments. If it retrieves policy, evaluate grounding and authority. If it decides when to escalate, test escalation behavior. If it coordinates multiple agents, test handoff quality and loop prevention.

Build adversarial and failure cases into evaluation, not only happy-path questions. Test missing knowledge, conflicting sources, tool failure, slow dependencies, unauthorized users, injection attempts, and requests outside the approved scope.

Use evaluation as a release gate. A change to model, prompt, tool, or knowledge should rerun relevant tests.

Architecture scenario: service agent with refunds

A service agent answers questions, summarizes cases, suggests resolutions, updates case fields, and can issue small credits. Credits above a threshold require manager approval.

A sound design might use one customer-service agent for interaction and bounded tools for case lookup and updates. The credit tool can enforce the amount threshold and route higher amounts through approval. Knowledge comes from governed policy sources. User and agent permissions are limited. Telemetry connects the conversational decision to the transaction. Evaluation includes policy grounding, correct use of the credit tool, and approval behavior.

A separate “refund agent” may be unnecessary unless it has a distinct owner, permission boundary, or operating model.

Architecture scenario: multi-agent procurement

A procurement process needs supplier research, risk analysis, and purchase-request creation.

Supplier research may use broad external and internal knowledge. Risk analysis may require controlled data and a separate policy. Purchase creation is a transaction with narrow permissions and approval.

Here, multiple agents or specialized components may be justified because responsibilities and access differ. The orchestrator still needs clear handoffs and evidence. If the risk component fails, the transaction should not proceed by default.

The design should also define idempotency so a retry does not create multiple purchase requests.

Architecture scenario: Foundry capability behind Copilot Studio

A business wants a Copilot Studio agent for employee interaction but needs a specialized code-first document reasoning component.

A hybrid design can keep the conversational experience, business tools, and Power Platform governance in Copilot Studio while exposing the specialized reasoning capability through a governed service built in Microsoft Foundry.

The architecture must define authentication, data passed to the service, result schema, timeout, telemetry correlation, error behavior, and release ownership on both sides.

The lesson is that platform boundaries can be productive if responsibilities are explicit.

Study priorities for AB-100

Do not study agentic architecture as a list of patterns. Build and critique designs.

For every scenario, draw responsibility, identity, data, and action boundaries. Label where the model is allowed to choose and where deterministic controls enforce policy. Include observability and ALM on the same diagram.

Then simplify. Remove an agent, index, or custom component and ask whether the architecture still meets the requirement. Simplicity is an important design skill because every component creates security, testing, deployment, and support obligations.

Use the AB-100 objectives guide to ensure your scenarios cover the official planning, design, and deployment scope rather than drifting into generic AI architecture.

The architecture test

A mature agentic design should let you answer these questions clearly:

What business outcome justifies the solution? Which components reason, retrieve, and act? Why are responsibilities split the way they are? Which identity performs each important operation? Which data is authoritative? Where is autonomy limited? How are tools validated? How are failures recovered? How is behavior evaluated? What evidence exists in production? How is the solution promoted, versioned, and rolled back?

If those answers are clear, the product selection usually becomes easier. If they are not clear, adding another agent or model will not fix the architecture.

That is the core AB-100 lesson: agentic systems become enterprise systems only when their reasoning capability is surrounded by explicit boundaries, governed data, trustworthy actions, measurable quality, and an operating model that can explain what happened after the model made a decision.

Event-driven autonomy requires a stronger control model

Autonomous agents introduce a different architecture problem from conversational agents because work can begin without a person explicitly initiating each interaction. A trigger may come from a record change, scheduled event, incoming message, operational condition, or external system.

That changes the questions an architect should ask. Who authorized the class of actions the agent may take? Can a bad trigger create a burst of repeated work? What limits prevent one event from cascading into many actions? How are duplicate events detected? What stops the agent if a downstream dependency begins returning unexpected data?

A production design should include trigger validation, rate or concurrency limits where appropriate, correlation identifiers, idempotent actions, and an emergency disable path. The agent’s authority should remain narrower than the business process it observes.

Consider a collections agent triggered when invoices become overdue. It can summarize account history, draft outreach, and create follow-up tasks. Automatically changing credit status or initiating legal escalation may require deterministic policy and approval. The fact that the agent runs autonomously does not justify broader business authority.

Agent-to-agent communication needs contracts

When one agent delegates to another, the handoff should be treated with the same seriousness as an API boundary.

Define the task request, required context, expected output, failure response, authorization, and timeout. Avoid passing entire conversation histories if the downstream agent only needs a few structured fields. Excessive context increases privacy exposure, cost, and the chance that irrelevant instructions influence the next agent.

A useful design pattern is to separate natural-language explanation from structured control data. One agent can produce a human-readable rationale alongside a typed result such as a recommendation category, confidence, and identifiers needed by the next step. The receiving component can validate the structured portion before acting.

Agent2Agent standards can improve interoperability, but standards do not remove the need to define trust. An external agent may be technically reachable and still not be authorized to receive sensitive data or invoke internal tools.

Cost and latency are architecture constraints

Agentic systems can become expensive and slow because one user request may trigger several model calls, retrieval operations, tool invocations, agent handoffs, and evaluation or safety checks.

Map the call chain. Identify which steps can run in parallel, which require a premium model, which can use deterministic code, and which can be cached safely. Reduce context passed between agents. Use smaller or faster models for bounded tasks when evaluation supports the choice.

Do not optimize only for token price. A cheaper model that calls the wrong tool, requires repeated retries, or increases human escalation can increase end-to-end cost. Measure cost per successful business task rather than cost per model call.

Latency should also be tied to user expectation. An interactive sales assistant and an overnight reconciliation agent have different requirements. Architecture can trade speed for deeper reasoning when the process allows it.

Data ownership matters in multi-agent systems

When several agents use the same customer, employee, or operational data, avoid creating separate hidden copies of business truth in each agent’s memory or private store.

Keep authoritative state in governed systems of record. Agents can maintain temporary working context, but important decisions, approvals, and transactions should be persisted where the organization already manages ownership, access, retention, and audit.

This principle simplifies recovery. If an agent crashes halfway through a process, another worker should be able to reconstruct state from durable records rather than from an opaque model conversation.

It also reduces inconsistency. If two agents maintain different representations of the same customer status, orchestration can become nondeterministic. Shared access to a controlled source is usually safer than duplicated private memory.

ALM for agentic systems is broader than code deployment

A release may change agent instructions, prompt templates, tool schemas, knowledge configuration, model deployment, routing rules, connector versions, evaluation thresholds, environment variables, or access policies.

Track those artifacts as part of the release. Define which changes require regression evaluation and which require security review. A tool schema change may be as significant as a code change because it can alter how the model constructs actions.

For multi-agent systems, version compatibility becomes important. If the orchestrator expects an older downstream contract while one agent has already been updated, failures can appear as reasoning problems even though the root cause is release coordination.

A mature deployment strategy either releases compatible components together or supports explicit version negotiation. The exact implementation varies, but the architecture should recognize the dependency.

Common failure modes that reveal weak architecture

The super-agent: one agent has broad knowledge, broad tools, broad permissions, and vague instructions. It is difficult to evaluate and dangerous to compromise.

The agent swarm: the design creates many agents without clear boundaries, adding latency and debugging complexity with little governance benefit.

The prompt firewall: sensitive actions are “protected” only by instructions telling the model not to perform them without approval.

The stale knowledge trap: indexed content is treated as authoritative even after source permissions or documents change.

The invisible transaction: the agent performs an action but the system lacks correlation, idempotency, or evidence to reconcile retries.

The demo identity: development works under a privileged creator account, while production identity and permissions are never designed.

The unmeasured agent: launch criteria are based on a handful of manual conversations, with no repeatable evaluation set.

The telemetry gap: logs show model requests but cannot connect them to tool calls and business outcomes.

Being able to diagnose these patterns is useful for AB-100 because many exam distractors are not absurd. They are designs that can work but fail to satisfy one production responsibility.

Use architecture reviews as a study technique

Take one of your own diagrams and review it from six perspectives.

Business review: Does every component contribute to the stated outcome?

Security review: Are identities and permissions explicit? Can untrusted content influence high-risk tools?

Data review: Is every important data source authoritative, access-controlled, and lifecycle-managed?

Reliability review: What happens when a model, tool, agent, or downstream system fails?

Operations review: Can support teams trace, monitor, tune, and roll back the system?

Cost review: Are model, tool, and infrastructure choices proportional to the value and workload?

If you can perform those reviews quickly, you are developing the architecture reflex AB-100 requires. The exam may present one issue at a time, but real competence comes from seeing that the same design must satisfy all six views simultaneously.