Foundry Agent Service

Already creating Foundry agents and running them on threads? Skip to the next lesson.

You built the loop yourself in Module 2. Azure will now run that loop for you. This lesson is about seeing exactly what you are handing over, so that a managed service is a choice rather than a mystery.

Four things, and what they used to be

Foundry Agent Service hosts your agent. Instead of your program looping, Azure loops.

An agent gets an id beginning asst_. A thread is why you stop resending the whole history yourself. Note the last row: even here, tools run on your side. That never changes.

What you gain and what you keep

You stop writing the loop and the message plumbing. You keep owning the tools, the instructions and whether the answer is any good.

You also keep owning tracing and evaluation from Module 12. Hosting the loop does not watch it for you, and a hosted agent can ignore a tool result exactly like a hand-written one.

What to write

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

1. Build an AIProjectClient with an endpoint and a credential
2. create_agent(...) with the model, a name, instructions and tools
3. Create a thread, then post the question to it
4. runs.create_and_process(...) and read the answer

model= takes the deployment name. Module 6's trap does not disappear because a service is holding the loop.

Watch the trace while it runs. You will see tool_requested and tool_executed in the same order as Module 2. Nothing new happened. Something you wrote is running somewhere else.

The point

You now know exactly what the service is doing for you, and what it costs.

Break it on purpose

Pass model="gpt-4o" and read the error. Then start a run before posting a message to the thread and read that one. A hosted loop still needs the input you used to append yourself.