Agents in Microsoft Foundry

What an agent is

A plain chat completion is one stateless request and one response. Your app sends a prompt to a deployed model, receives text back, and the service does not automatically keep the larger task, tool choices, or prior turns unless your app sends that context again. An agent is different. It pairs a model with persistent instructions, tools it may call, optional knowledge, and conversation state. It can run multiple steps toward a goal: reason, call a tool, read the result, call another tool, and answer with evidence.

The exam name you need is Foundry Agent Service. It is part of Microsoft Foundry, the current platform name. You may still see older documentation say Azure AI Foundry; treat it as the same product, but use current names on this site. For AI-901, assume prompt agents are the default answer unless the question says you must write orchestration code, package it, or expose a managed custom endpoint.

An agent does not automatically mean a large application. Sometimes the correct implementation is a declarative prompt agent with the right grounding or action tool attached. That is a major difference from older study habits: AI-901 expects you to think like a builder using Foundry, not just name a workload.

Anatomy of a Foundry agent

An agent is built from a small set of pieces. The model is the deployed Foundry Models deployment that generates and reasons. The instructions are durable system-level guidance. Tools are capabilities the agent may call. A toolbox groups managed tools behind one MCP endpoint. Conversations hold persistent multi-turn state. Identity controls what the agent can access, often through Entra-based authorization.

Good instructions are specific. State the role, the scope, the tone, and the refusal boundaries. Tell the agent what sources to trust, when to call tools, when to ask for missing information, and when to say it cannot answer. Do not bury critical rules in a long personality paragraph. AI-901 questions often reward the candidate who separates model choice from instruction design and tool grounding.

A conversation is the durable state for a multi-turn exchange. Reusing the same conversation id is what makes the next turn a follow-up instead of a brand-new question. If the app creates a new conversation for every user turn, the agent loses the prior context unless the app restates it.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition
from azure.identity import DefaultAzureCredential

project = AIProjectClient(
    endpoint="https://<resource>.services.ai.azure.com/api/projects/<project>",
    credential=DefaultAzureCredential(),
)

agent = project.agents.create_version(
    agent_name="PolicyHelper",
    definition=PromptAgentDefinition(
        model="gpt-5-mini",
        instructions="You answer policy questions from trusted sources and refuse unsupported claims.",
    ),
)

openai = project.get_openai_client(agent_name="PolicyHelper")
conversation = openai.conversations.create()

first = openai.responses.create(
    conversation=conversation.id,
    input="What is the travel meal policy?",
)
print(first.output_text)

follow_up = openai.responses.create(
    conversation=conversation.id,
    input="Does that also apply to international trips?",
)
print(follow_up.output_text)

The SDK package to recognize is azure-ai-projects 2.x. In examples, the project endpoint points to a Foundry project, authentication commonly uses DefaultAzureCredential, and the model value is the deployment name your project can use.

Tools: the highest-value agent decision

Tools are where agents become useful. A model can write language, but tools let the agent retrieve grounded information, execute deterministic code, call existing systems, use a browser, create images, or coordinate with other agents. On the exam, many questions are really tool-selection questions.

Grounding an agent

Grounding means giving the model relevant source content at answer time. It is usually the answer before fine-tuning. If the question says the model is wrong because it does not know private or current facts, attach a retrieval tool instead of changing the model weights.

Do not choose Grounding with Bing for internal documents. Do not choose file search when the organization already invested in a controlled Azure AI Search index. Match the tool to the content location and governance need.

Single-agent versus multi-agent

A single agent is easier to build and easier to test. Use it when one instruction set and one tool set can handle the task. A multi-agent design adds an orchestrator. The orchestrator receives the goal, decides which specialist should act, and routes work through A2A. That is useful when the work naturally splits into specialist responsibilities, not just because the scenario sounds important.

A toolbox is different from a multi-agent team. A toolbox is a managed group of tools exposed behind one MCP endpoint. It simplifies how agents discover and call a related set of tools. Think: many tools, one managed MCP doorway.

Building a single agent

“Create and test a single-agent solution in the Foundry portal” is an exam objective in its own words. Do this once and every agent question gets easier, because you will have seen where each concept actually lives.

1. Pick a model deployment. The agent needs a deployed model to think with. A small, fast general chat model is fine to start.
2. Write the instructions. State the role, the scope, the tone, and what to refuse. This is the agent’s persistent system prompt.
3. Attach a tool. Start with one. File search over a handful of uploaded documents is the clearest first tool because you can see grounding working.
4. Test it in the playground. Ask something answerable only from your files, then something that is not, and watch the difference.
5. Call it from a client. Create a conversation, send a turn, then send a follow-up on the same conversation id.

openai = project.get_openai_client(agent_name="MyAgent")

conversation = openai.conversations.create()

r1 = openai.responses.create(
    conversation=conversation.id,
    input="What does our refund policy say about damaged goods?")
print(r1.output_text)

r2 = openai.responses.create(
    conversation=conversation.id,
    input="And how long do customers have?")
print(r2.output_text)

The second call carries no restatement of the first question, yet the agent still understands “how long do customers have.” That is the conversation doing the work. Drop the conversation argument and the follow-up becomes a fresh, contextless question.

Where people lose points

The night-before cheat sheet