Microsoft AB-100: Microsoft Foundry Architecture

Microsoft Foundry matters to AB-100, but the exam is not asking architects to put every AI workload there. The harder skill is deciding where Foundry belongs inside a business solution that may also include Copilot Studio, Microsoft 365, Dynamics 365, Power Platform, data platforms, custom applications, and external systems.

The AB-100 exam targets experienced solution architects. As of October 3, 2026, Microsoft’s current blueprint remains centered on planning, designing, and deploying AI-powered business solutions. The English exam update announced for October 14 is not yet the version candidates face today, even though Microsoft has already published the upcoming study-guide changes.

For preparation, treat Foundry as one architectural capability in a broader system. The right answer is rarely “use Foundry because the requirement mentions AI.” The right answer explains why a Foundry model, agent, tool, or evaluation capability is justified and how it connects to the rest of the business platform.

Start from the business process, not the AI service

AB-100 scenarios often contain a tempting technical detail that can distract from the real requirement. Before choosing a model or agent platform, map the business process: who starts it, which systems hold authoritative data, where judgment is needed, what can be automated, what must be approved, and how success will be measured.

This is the same discipline used in good cloud architecture. A technology choice should follow workload characteristics and organizational constraints. If the process is already well served by a Microsoft 365 or Dynamics capability, a large custom Foundry build may increase cost and support burden without improving the outcome.

Foundry becomes most compelling when the solution needs code-first AI components, broader model choice, custom retrieval, specialized agents, application integration, or evaluation and observability that sit outside a low-code business application.

A useful architecture pattern is to ask where users interact and where AI reasoning occurs. The experience might live in Teams, a Dynamics app, a Power App, a web application, or another channel. The intelligence layer may use Copilot Studio, Foundry, or a combination.

Keeping those layers conceptually separate prevents the interface from dictating the entire architecture. A Teams experience can still call a custom service. A Power Platform process can delegate specialized reasoning to a Foundry-backed component. A Foundry agent can surface through a business application without becoming the system of record.

This also improves lifecycle design. The UI can evolve without forcing every model and orchestration component to move with it.

Use Foundry when custom model behavior is part of the requirement

Foundry gives architects access to a broad model catalog, model deployment choices, agent capabilities, evaluation, tracing, and programmatic integration. That makes it appropriate when the solution needs control over model selection, routing, grounding, custom tools, or application-level orchestration.

But model choice should be evidence-driven. The principles in foundation-model evaluation are directly relevant: define representative tasks, quality thresholds, latency expectations, and cost constraints before standardizing on a model.

An architect who cannot describe how model quality will be measured is making a platform decision too early.

Grounding architecture begins with data ownership

Business AI is often only as useful as the proprietary information it can safely reach. Before designing retrieval, identify the system of record, data owner, classification, freshness requirement, authorization model, and whether the information can leave its current boundary.

Retrieval-augmented generation can connect AI to enterprise knowledge, but retrieval is not a license to copy all content into one index. The architecture should preserve meaningful permissions, refresh data at the right cadence, and prevent the model from surfacing information the user could not access through the source system.

That makes grounding a governance problem as well as a relevance problem.

Identity determines whether integration is trustworthy

Foundry solutions often connect to search, storage, APIs, databases, Microsoft 365 services, or business applications. Each connection needs an identity and an authorization boundary. Long-lived shared credentials make ownership and audit difficult.

Use Microsoft Entra ID and Azure RBAC as the conceptual foundation for Azure-side access. Workload identities, managed identities, least-privilege roles, and scoped permissions reduce the blast radius of a compromised component.

For cross-platform architecture, also ask whether the agent should act as itself, on behalf of the user, or through a service identity. Those choices produce different security and audit outcomes.

Agents should be introduced where reasoning changes the path

Not every automated business process needs an agent. A fixed sequence of validations and API calls is often more reliable as conventional workflow automation. Agents are more valuable when the system must interpret ambiguous input, choose among actions, use tools conditionally, or adapt the sequence to context.

The architecture of an AI agent should therefore start with a bounded goal and clearly defined authority. Tools that only read data can often run automatically. Actions that change systems, spend money, approve requests, or communicate externally may need confirmation or human review.

AB-100-level reasoning explains both the benefit of autonomy and the point where autonomy stops.

Copilot Studio and Foundry can complement each other

Copilot Studio provides a managed environment close to Microsoft business applications and low-code workflows. Foundry supports more code-first AI engineering, broader model work, custom agents, and deeper evaluation and observability. The architecture can combine them when the boundaries are clear.

For example, a Copilot Studio agent might own the business-facing conversation while a specialized Foundry service performs complex retrieval or reasoning behind a controlled API. The reverse can also happen: a code-first application can call business-process capabilities exposed through managed integrations.

The point is not to maximize the number of platforms in the diagram. It is to put each responsibility where it is easiest to secure, operate, and evolve.

Agent architectures increasingly use standards such as Model Context Protocol to expose tools and context. Standardization can reduce one-off connector work and make capabilities portable across agent environments.

However, the architect still needs to approve the capability surface. An MCP server that exposes sensitive or overly broad tools can create the same risk as a poorly governed custom API. Authentication, authorization, data classification, versioning, logging, and ownership remain required.

Architecture should treat protocols as transport and discovery mechanisms, not as substitutes for trust decisions.

Observability must cover both systems and behavior

Traditional monitoring tells you whether services are available, how long requests take, and which dependencies fail. AI solutions need that plus behavioral evidence: answer quality, retrieval relevance, tool choice, model selection, safety events, escalation rates, and business outcomes.

The operational habits behind Azure monitoring and alerting remain important, but an AB-100 architecture should also define who reviews AI-quality signals and what happens when they cross a threshold.

If the system is technically healthy but users are receiving poor recommendations, the architecture is not healthy.

ALM has to include prompts, agents, models and data dependencies

Business AI changes in more ways than conventional application code. Prompts change. Knowledge sources change. Agent instructions change. Models are upgraded or retired. Tool schemas evolve. Evaluation criteria improve. All of those changes can alter production behavior.

That is why the DevOps lifecycle must be extended rather than abandoned. Version important assets, separate environments, automate repeatable deployment, validate dependencies, and preserve rollback.

For AB-100, ALM is not a deployment detail. It is part of whether the organization can safely own the solution after the architecture team leaves.

Use a decision record for every major Foundry component

A strong preparation method is to build a small architecture decision record for each Foundry choice. State the requirement, alternatives, selected option, identity model, data boundary, operational owner, success metric, and the condition that would cause you to revisit the decision.

Do this for the model, retrieval layer, agent, tool boundary, monitoring approach, and deployment model. The exercise forces you to connect technology to consequences.

AB-100 is ultimately testing that connection. Foundry is valuable when it solves the right part of the business problem and can be governed alongside the systems around it. Architecture is the discipline of making that fit explicit.

AI components often cache, index, summarize, or transform information from business systems. That can gradually blur ownership. An architect should define which platform remains authoritative and which AI stores are derived representations that can be rebuilt.

This is especially important for customer, financial, HR, or operational data. A vector index may be excellent for retrieval but should not quietly become the master record for the process. The architecture needs synchronization rules, deletion behavior, retention, and a way to handle conflicts between source data and derived AI context.

Models, agent frameworks, and AI platform features change quickly. A strong AB-100 design identifies which interfaces are stable business contracts and which are replaceable implementation details. Wrapping model calls, keeping tool contracts explicit, and separating business logic from prompt text can reduce migration cost.

This does not mean designing for every hypothetical future. It means avoiding unnecessary coupling. If the organization later changes model strategy, agent platform, or retrieval technology, the business process should not require a complete rewrite.

Cost ownership should be equally explicit. Model usage, retrieval infrastructure, logging, integration services, and human review may land in different cost centers. An architecture that does not identify who owns ongoing consumption can succeed technically and still fail organizationally. Include showback or chargeback assumptions when the solution will serve several business units.

• Category: All Certifications Certifications