Identifying AI Workloads and the Foundry Piece That Serves Them

One platform, three building blocks

Before you can identify an AI workload you need a vocabulary for what a workload is built from. In Microsoft Foundry that vocabulary is short: agents, models, and tools. Those three sit under a single management grouping, with role-based access control, networking and policy applied once across all of them, under one Azure resource provider namespace. Alongside them sit the capabilities that make a workload shippable — tracing, monitoring, evaluations, and configurable enterprise setup.

That structure is the answer key for most workload questions. A scenario describes something an organisation wants; your job is to say which block carries the weight, and what the other two contribute around it.

Models supply the raw capability

A model is where a capability such as generating text, reasoning over a question, understanding an image or producing an embedding comes from. Foundry gives access to a large catalogue spanning providers including Microsoft, OpenAI, Anthropic and Meta, browsed through Foundry Models.

The framing that matters here is that a model on its own is not a workload; it is a capability you call. If the scenario is a one-shot summary or a single classification, a model call may be the whole solution. If it involves several steps, a decision about what to do next, or access to data the model was never trained on, the model is one component and something has to orchestrate it.

Agents are the workload shape

An agent is that orchestration. In Foundry you can build declarative prompt agents, defined in the portal or through the SDK, where behaviour is described rather than coded. You can also deploy hosted agents that run your own code when the logic needs programming. Foundry Agent Service sits behind both.

The distinction to carry into the exam is between describing behaviour and writing it. A team that wants an assistant defined by instructions, a chosen model and a set of permitted tools does not need to write an application — that is a prompt agent. A team whose logic needs bespoke computation, private libraries or an existing codebase needs a hosted agent. Both are managed in the same place.

Tools and knowledge supply reach

The third block is what an agent is allowed to touch. Agents are extended with built-in tools, with memory, and with retrieval, drawn from a tool catalogue. Retrieval is the one that resolves the most common scenario in this topic: the organisation's answers depend on documents or records the model has never seen. The fix is not a different model and not fine-tuning by default — it is giving the agent a retrieval path to that content.

Memory covers the other frequent case, where the workload has to remember something across turns or sessions rather than treating each request as isolated.

Under the current naming, the broader set of task-specific capabilities is called Foundry Tools. When a workload needs a well-defined capability that already exists as a service — content processing or safety filtering, for instance — reaching for a Foundry Tool is usually a better answer than assembling it from a general model.

Enterprise readiness is part of the workload

Observability and governance look like operational trivia, but Foundry puts them in the platform description and workload questions do ask about them.

Observability means you can trace, monitor and evaluate both agents and models, with built-in dashboards. Evaluation belongs in the workload's design, not after it: if the team needs to know whether quality is holding up or whether a change made things worse, the answer is evaluation, not more prompt engineering.

Governance and security means Microsoft Entra identity, role-based access control, content filters, network isolation and Azure Policy — applied through the one management plane rather than per component. A scenario about restricting who can use which model, or keeping traffic off the public internet, is answered here.

The names changed, and the exam uses the new ones

Foundry consolidated several earlier Azure AI services and tools into one platform, and the renaming is examinable in itself because so much older material still circulates.

What was called Azure AI Studio, and then Azure AI Foundry, is now Microsoft Foundry. What was called Azure AI Services is now Foundry Tools. The older portal, which hosts hub-based projects, is Foundry classic; new investment goes to Foundry projects in the new portal. The old resource model — a hub plus an Azure OpenAI resource plus an Azure AI Services resource — is now a single Foundry resource containing projects. The Assistants API gave way to the Responses API, and the terminology moved with it: threads, messages, runs and assistants became conversations, items, responses and agent versions. Multiple SDK packages against several endpoints became one project client against one project endpoint, and monthly API version parameters became stable v1 routes. An existing Azure OpenAI resource can be upgraded to a Foundry resource while keeping its endpoint, keys and state.

How to answer a workload question

Read the scenario for three signals. Is a single capability enough, or must something decide and sequence? Does the answer depend on data the model cannot know? Does the requirement concern who may use it, where it runs, or how it is measured? Those map to models, to tools and knowledge, and to the enterprise plane — with agents tying them together.