Microsoft Foundry: Agenten bauen, bis sie produktionsreif sind

„Wir haben da mal was mit KI gebaut.” Diesen Satz höre ich in Kundenterminen inzwischen öfter als „Wir haben ein Teams-Problem”. Dann kommt die Demo: Ein Agent beantwortet Fragen zu internen Richtlinien. Läuft. Sieht gut aus. Und dann stelle ich meine Lieblingsfrage: „Wer darf den eigentlich benutzen, und wer merkt es, wenn er Mist erzählt?” Stille. Jemand schenkt Kaffee nach.

Genau hier setzt dieser Artikel an. „Kann ich einen Agenten bauen?” ist nicht mehr die spannende Frage. Dat kriegst du mit Microsoft Foundry an einem Nachmittag hin. Die spannende Frage lautet: Wie wird daraus etwas, das sicher, nachvollziehbar und wartbar bleibt?

1. Was Foundry eigentlich leisten soll

Foundry ist kein weiterer KI-Spielplatz. Den Kern bildet der Foundry Agent Service, der Modelle, Tools, Wissen und Frameworks in einer gemeinsamen, beobachtbaren Runtime zusammenführt. Für dich heißt das: ein Ort für Bauen, Testen, Betreiben und Überwachen.

Du hast dabei drei Agententypen zur Auswahl:

Agententyp	So funktioniert er	Passt für
Prompt Agent · Startpunkt, reine Konfiguration	Du definierst Instructions, Modell und Tools. Foundry betreibt den Agenten in einer vollständig verwalteten Runtime.	Den Einstieg und die meisten Szenarien im Modern Workplace
Workflow · mehrstufige Abläufe	Orchestrierung mehrerer Schritte, Agent-zu-Agent-Koordination und Freigabeprozesse, ohne eigenen Code.	Wiederholbare Prozesse mit Freigaben
Hosted Agent · teilweise Preview, eigener Code	Du baust mit Agent Framework, LangGraph, dem OpenAI Agents SDK oder anderen Frameworks. Foundry führt den Code als Container aus.	Szenarien, in denen Konfiguration nicht mehr reicht

Meine Faustregel: Starte mit einem Prompt Agent. Code schreibst du erst, wenn die Konfiguration wirklich an ihre Grenzen stößt.

2. Der Quickstart: schnell drin, schnell gestolpert

Für den Code-Weg nutzt du die Azure Developer CLI mit der Agent-Extension. Alternativ geht das komplett über das Foundry Toolkit in VS Code.

azd ai agent init     # Agent-Projekt anlegen
azd ai agent run      # lokal auf deinem Rechner testen
# danach: in den Foundry Agent Service deployen und im Playground testen
azd down              # nach dem Test wieder aufräumen

Klingt nach Spaziergang. Ist es auch, bis du über diese vier Steine stolperst.

Stolperfalle 1: Rollen

Für ein neues Foundry-Projekt brauchst du die Owner-Rolle auf Ressourcengruppenebene. Für Hosted Agents brauchst du zusätzlich die Rolle Azure AI Project Manager auf Projektebene. Im Mittelstand hat der Entwickler selten Owner-Rechte. Ergebnis: Ticket-Pingpong mit der IT. Klär das vor dem Workshop, nicht währenddessen.

Stolperfalle 2: Kosten

Nach dem Test räumst du mit azd down auf. Aber Achtung: Hast du beim Initialisieren ein bestehendes Projekt gewählt, bleiben Projekt, Ressourcengruppe, Hosted Agent und weitere Quickstart-Ressourcen stehen. Also: selbst nachschauen, was noch läuft.

Stolperfalle 3: Identität in Dev und Prod

Alle unveröffentlichten Agents eines Projekts teilen sich eine gemeinsame Agent-Identität. Erst beim Veröffentlichen bekommt der Agent eine eigene, eindeutige Identität. Heißt praktisch: Berechtigungen, die im Test funktioniert haben, gelten für den veröffentlichten Agenten nicht automatisch. Jannik Reinhard empfiehlt deshalb, die RBAC-Neuzuweisung an die veröffentlichte Identität fest in die Release-Checkliste aufzunehmen. Sonst läuft der Agent in Dev und scheitert in Produktion.

Stolperfalle 4: Die falsche Doku

Foundry entwickelt sich schnell. Microsoft markiert ältere Quickstarts inzwischen ausdrücklich als Anleitung für die vorherige Agents-Version. Das ist fair und transparent. Trotzdem landest du über Suchmaschinen oft auf der alten Variante. Schau also immer oben auf der Seite, für welche Version die Anleitung gilt.

3. Leitplanken ab Tag 1

„Et kütt wie et kütt” ist ein schönes Lebensmotto. Als Governance-Strategie taugt es nichts. Diese drei Leitplanken setzt du am besten direkt beim ersten Projekt.

Rollen sauber trennen

Nicht jeder im Team braucht Owner. Weitreichende Rechte gehören an die IaC-Pipeline und an einen Break-Glass-Zugang. Das Team arbeitet mit den schmaleren Foundry-Rollen. Klingt bürokratisch, spart dir aber später das große Aufräumen.

Zugriff nur über Entra ID

Foundry setzt für alle Endnutzer, die auf Agents zugreifen, auf schlüssellose Authentifizierung über Microsoft Entra ID. Geh einen Schritt weiter und deaktiviere die lokale Authentifizierung:

disableLocalAuth: true   // API-Keys funktionieren nicht mehr, nur Entra ID zählt

Dazu passt die Entra Agent ID: Laut Jannik Reinhard ist sie seit April 2026 allgemein verfügbar und macht Agents in Entra sichtbar, steuerbar und widerrufbar, genau wie Benutzer und Service Principals. Für Admins ist das ein echter Fortschritt: Du siehst deine Agents im Entra Admin Center und verwaltest sie wie gewohnt.

Verhalten steuern und beobachten

Die bisherigen Content-Filter heißen in Foundry jetzt Guardrails. Wer feinere Kontrolle braucht, legt eigene Guardrails an. Für den Betrieb kommt die Foundry Control Plane dazu. Sie bündelt Observability, Guardrails, Richtlinien und Sicherheit, inklusive kontinuierlicher Evaluierung auf Produktiv-Traffic und einem AI Red Teaming Agent. Wichtig für die Einordnung: Die Control Plane richtet sich an Entwickler und AI Engineers. Agent 365 erfüllt in der Organisation eine andere Rolle.

4. Vom Prototyp zur Produktion, ohne alles neu zu bauen

Der häufigste Fehler, den ich sehe: Der Prototyp wird „mal eben” produktiv geschaltet. Oder er wird weggeworfen und komplett neu gebaut. Beides tut weh. So geht es besser:

Und falls du schon mit Code startest: Derselbe Agent-Framework-Code kann heute aus deinem eigenen Prozess die Responses API aufrufen und später als Hosted Agent im Container verpackt werden, sobald du einen von Foundry verwalteten Endpunkt willst. Genau das meine ich mit „ohne Neubau”.

Ehrlich gesagt: Das ist nicht trivial. Aber der Aufwand am Anfang ist ein Bruchteil dessen, was dich ein Agent ohne Leitplanken später kostet.

Testest du Foundry gerade oder musst intern bewerten, ob das Thema für euer Team relevant ist? Schreib mir auf LinkedIn, wo es bei euch hakt. Ich bin gespannt auf eure Erfahrungen.