Microsoft Foundry: building agents until they are production-ready

“We built something with AI.” In customer meetings I hear this sentence more often now than “We have a Teams problem”. Then comes the demo: an agent answers questions about internal policies. It works. It looks good. And then I ask my favourite question: “Who is actually allowed to use it, and who notices when it tells nonsense?” Silence. Somebody pours more coffee.

This is exactly where this article starts. “Can I build an agent?” is not the interesting question anymore. With Microsoft Foundry you do that in one afternoon. The interesting question is: How does it become something that stays secure, traceable and maintainable?

1. What Foundry is actually meant to do

Foundry is not just another AI playground. At its core sits Foundry Agent Service, which brings models, tools, knowledge and frameworks together in one shared, observable runtime. For you this means: one place to build, test, run and monitor.

You can choose between three agent types:

Agent type	How it works	Good fit for
Prompt agent · starting point, pure configuration	You define instructions, model and tools. Foundry runs the agent in a fully managed runtime.	Getting started and most Modern Workplace scenarios
Workflow · multi-step processes	Orchestration of several steps, agent-to-agent coordination and approval processes, without own code.	Repeatable processes with approvals
Hosted agent · partly preview, your own code	You build with Agent Framework, LangGraph, the OpenAI Agents SDK or other frameworks. Foundry runs the code as a container.	Scenarios where configuration is not enough anymore

My rule of thumb: start with a prompt agent. Write code only when configuration really hits its limits.

2. The quickstart: fast in, fast stumbling

For the code path you use the Azure Developer CLI with the agent extension. Alternatively, you can do everything with the Foundry Toolkit in VS Code.

azd ai agent init     # create the agent project
azd ai agent run      # test locally on your own machine
# then: deploy to Foundry Agent Service and test in the playground
azd down              # clean up after testing

Sounds like a walk in the park. It is, until you trip over these four stones.

Pitfall 1: Roles

To create a new Foundry project, you need the Owner role on resource group level. For hosted agents you additionally need the Azure AI Project Manager role on project level. In the German Mittelstand, the developer rarely has Owner rights. Result: ticket ping-pong with IT. Clarify this before the workshop, not during it.

Pitfall 2: Costs

After testing you clean up with azd down. But watch out: if you selected an existing project during initialisation, the project, resource group, hosted agent and other quickstart resources stay in place. So: check yourself what is still running.

Pitfall 3: Identity in dev and prod

All unpublished agents in a project share one common agent identity. Only when you publish does the agent get its own, unique identity. In practice this means: permissions that worked in testing do not automatically apply to the published agent. Jannik Reinhard therefore recommends putting the RBAC re-assignment to the published identity into your release checklist. Otherwise the agent runs in dev and fails in production.

Pitfall 4: The wrong docs

Foundry moves fast. Microsoft now explicitly marks older quickstarts as guides for the previous agents version. That is fair and transparent. Still, search engines often send you to the old variant. So always check at the top of the page which version the guide is for.

3. Guardrails from day one

“Et kütt wie et kütt”, Cologne dialect for “whatever happens, happens”, is a nice life motto. As a governance strategy it is useless. Set these three guardrails right with your first project.

Separate roles cleanly

Not everybody in the team needs Owner. Far-reaching rights belong to the IaC pipeline and to a break-glass account. The team works with the narrower Foundry roles. Sounds bureaucratic, but it saves you the big clean-up later.

Access only via Entra ID

Foundry relies on keyless authentication with Microsoft Entra ID for all end users who access agents. Go one step further and disable local authentication:

disableLocalAuth: true   // API keys stop working, only Entra ID counts

Entra Agent ID fits perfectly here: according to Jannik Reinhard it is generally available since April 2026 and makes agents in Entra visible, governable and revocable, exactly like users and service principals. For admins this is real progress: you see your agents in the Entra admin center and manage them like you are used to.

Control and observe behaviour

The former content filters are now called guardrails in Foundry. If you need finer control, you create custom guardrails. For operations, Foundry Control Plane comes on top. It bundles observability, guardrails, policies and security, including continuous evaluation on production traffic and an AI Red Teaming Agent. Important for the big picture: Control Plane is aimed at developers and AI engineers. Agent 365 plays a different role in the organisation.

4. From prototype to production, without rebuilding everything

The most common mistake I see: the prototype goes live “just quickly”. Or it gets thrown away and rebuilt from scratch. Both hurt. Here is the better way:

And if you already start with code: the same Agent Framework code can call the Responses API from your own process today and be packaged later as a hosted agent in a container, as soon as you want an endpoint managed by Foundry. That is exactly what I mean with “without rebuilding”.

Honestly: this is not trivial. But the effort at the beginning is a fraction of what an agent without guardrails will cost you later.

Are you testing Foundry right now or do you have to evaluate internally if the topic is relevant for your team? Tell me on LinkedIn where it gets stuck for you. I am curious about your experiences.