20.09.2025 AI Engineering 5 Minuten Lesezeit

Azure AI Foundry vor der Ignite 2025

Vor der Microsoft Ignite 2025 im November ziehen wir Bilanz zu Azure AI Foundry: was der Agent Service als gehostete Runtime seit der GA im Mai leistet, was das Agent-Factory-Narrativ signalisiert, warum das Azure-Präfix erodiert und welche Bausteine Engineering-Teams jetzt einführen sollten und welche nur beobachten.

Die Plattformfrage vor der Ignite

Die Microsoft Ignite 2025 findet vom 18. bis 21. November im Moscone Center in San Francisco statt, mit einem Pre-Day am 17. November. Für Teams, die Agentensysteme auf Azure bauen, ist das Datum relevant. Die Plattform darunter bewegt sich schnell: Aus Azure AI Studio wurde auf der Ignite 2024 Azure AI Foundry, der Agent Service erreichte im Mai 2025 auf der Build die allgemeine Verfügbarkeit, und seit August bereitet die Agent-Factory-Blogserie den Boden. Die Frage ist, worauf man sich festlegt, bevor die nächste Welle kommt.

Plattform-Churn ist ein realer Kostenfaktor. Namen ändern sich, SDKs werden zusammengelegt, Preview-Dienste werden umgebaut oder eingestellt. Wer früh einsteigt, gewinnt Fähigkeiten und zahlt später mit Migrationsaufwand. Dieser Artikel hält den Stand vom 20. September 2025 fest und trennt, was wir für sicher einführbar halten, von dem, was wir nur beobachten würden. Unser Kriterium ist nicht Neuheit, sondern Reversibilität: Wie teuer ist der Ausstieg aus einer Komponente, wenn die Ignite sie verändert?

Agenten laufen in Produktion — jeder Lauf ist ein Datenpunkt. 1/4

Was Azure AI Foundry heute ist

Azure AI Foundry ist Microsofts Plattform für den Bau von KI-Anwendungen und Agenten. Vorgestellt wurde sie am 19. November 2024 auf der Ignite als Nachfolger von Azure AI Studio. Heute kombiniert sie einen Modellkatalog mit mehr als 11.000 Modellen mit einem SDK, dem Foundry Agent Service und Observability-Werkzeugen. Der Katalog umfasst von Microsoft gehostete Modelle und Partnermodelle unter einem einheitlichen Deployment- und Abrechnungsmodell. GPT-5 von OpenAI ist dort seit dem 7. August 2025 verfügbar, ergänzt um einen Model Router, der pro Anfrage eine Modellvariante auswählt.

Zwei Grenzen definieren das Produkt. Foundry ist kein Orchestrierungs-Framework: Semantic Kernel und AutoGen liegen darunter, und Microsoft hat auf der Build 2025 angekündigt, beide in ein gemeinsames SDK zu überführen. Es ist auch kein No-Code-Werkzeug; diese Rolle gehört Copilot Studio. Foundry richtet sich an professionelle Entwickler, die verwaltete Infrastruktur unter Code wollen, den sie weiterhin selbst kontrollieren.

Das Agent-Factory-Narrativ

Microsofts Rahmung für all das ist die Agentenfabrik. Der Begriff tauchte als Session-Titel auf der Build 2025 auf — "Azure AI Foundry: The Agent Factory" — und benennt seit dem 13. August 2025 eine sechsteilige Serie im Azure-Blog: Anwendungsfälle und Entwurfsmuster, ein erster Agent, Observability, der Weg vom Prototyp in die Produktion, offene Standards und Sicherheit.

Eine Fabrik impliziert standardisierte Teile und wiederholbare Montage. Das ist Marketingsprache, aber die Serie bildet reale Engineering-Themen ab: Tracing, Evaluation, Interoperabilität, Governance. Wir lesen sie in erster Linie als Roadmap-Signal. Microsoft benennt die Themen, die auf der Ignite landen sollen, und die Beiträge sagen das ausdrücklich.

Die Serie fixiert außerdem ein Vokabular: Knowledge Tools versus Action Tools, Observability als tragende Säule, das Open Agentic Web als Zielbild. Gemeinsames Vokabular ist keine Kleinigkeit. Es erlaubt einem Plattformanbieter, seinen Partnern und seinen Kunden, über dieselben Gegenstände zu streiten.

Gehostete Runtimes als verwalteter Zustand

Der Foundry Agent Service, allgemein verfügbar seit dem 19. Mai 2025, ist eine gehostete Runtime. Threads, Runs, Tool-Aufrufe und Dateizustand liegen serverseitig. Eingebaute Tools decken Azure AI Search, Code Interpreter, File Search, Function Calling, Bing Grounding und OpenAPI ab; MCP bindet externe Tool-Server an, und das A2A-Protokoll macht Agenten für andere Agenten erreichbar.

Eine gehostete Runtime nimmt Infrastrukturarbeit ab. Sie entwirft keine Prompts. Sie definiert keine Qualität: Observability erfasst Traces, aber die Evaluationskriterien bleiben Ihre Aufgabe. Und sie beseitigt keinen Lock-in — Thread-Zustand und Tool-Konfiguration leben im Dienst, und der Export liegt in Ihrer Verantwortung.

Die Alternative bleibt selbst gehostete Orchestrierung: Semantic-Kernel- oder AutoGen-Prozesse auf eigener Infrastruktur, mit Zustand im eigenen Speicher. Das kostet Betriebsaufwand und kauft Portabilität. Für regulierte Workloads, deren Konversationsdaten in definierten Grenzen bleiben müssen, verdient dieser Trade-off eine explizite Entscheidung statt eines Defaults.

Namensdrift als Signal

Ein Detail der Build 2025 verdient gesonderte Aufmerksamkeit: die Namensgebung. Die lokale Runtime erschien als Foundry Local — ohne Azure-Präfix — in Preview für Windows und macOS, gebaut auf ONNX Runtime. Aus Windows Copilot Runtime wurde Windows AI Foundry. Die Dokumentation spricht zunehmend von Foundry Models und Foundry Agent Service, und Microsofts Entwicklerblog zur Plattform liegt unter devblogs.microsoft.com/foundry.

Microsoft benennt Plattformen auf der Ignite um. Aus Azure AI Studio wurde dort im November 2024 Azure AI Foundry, ein Jahr nach dessen eigenem Start. Eine Marke, die inzwischen Cloud, Windows und On-Device-Runtimes umspannt, ist ihrem Cloud-Präfix entwachsen. Wir erwarten, dass der Namensbestandteil Azure AI verschwindet; offen ist nur, wann.

Jetzt einführen oder beobachten

Unsere Regel ist einfach: einführen, was allgemein verfügbar ist und auf offenen Protokollen ruht; beobachten, was in Preview ist oder an eine einzelne Herstelleroberfläche gebunden ist. Auf den Foundry-Stack zum Stand 20. September 2025 angewandt, ergibt das folgendes Bild.

Zwei Einschätzungen brauchen Begründung. Teile des MCP-Toolings sind noch Preview, dennoch führen wir MCP ein: Das Protokoll ist offen, hat Zugkraft über Microsoft hinaus und überlebt jede Plattformumbenennung. A2A-Orchestrierung beobachten wir nur. Multi-Agent-Muster sind Monate alt, und die Ignite wird APIs wie Preise plausibel noch umformen, bevor sie sich stabilisieren.

Baustein	Status am 20.09.2025	Unsere Einschätzung
Foundry Agent Service	GA seit 19. Mai 2025	Einführen für zustandsbehaftete Einzel-Agenten
OpenAPI- und Funktions-Tools	GA	Einführen
MCP-Tool-Anbindungen	Preview	Einführen hinter eigener Abstraktion
A2A-Multi-Agent-Orchestrierung	Preview	Beobachten bis nach der Ignite
Foundry Local	Preview für Windows und macOS	Beobachten und für Edge-Szenarien evaluieren
Vereinheitlichtes SK-und-AutoGen-SDK	Auf der Build 2025 angekündigt	Beobachten

Ausblick auf den November

Was erwarten wir am 18. November? Eine konsolidierte Marke, plausibel schlicht Foundry ohne Azure-Präfix. Gehostete Multi-Agent-Workflows als Schlagzeile. Tiefere Agentenidentität und Governance auf Basis der auf der Build vorgestellten Microsoft Entra Agent ID. Engere Kopplung zwischen Copilot Studio und der Foundry-Runtime. Nichts davon ist bestätigt; alles folgt dem Muster der letzten zwölf Monate.

Einige dieser Vorhersagen werden im Detail falsch sein. Unsere Haltung bei Blue IT Systems hängt nicht daran: Bauen Sie gegen Protokolle, nicht gegen Produktnamen. Halten Sie Orchestrierung hinter eigenen Schnittstellen, halten Sie Konversationszustand exportierbar, und behandeln Sie jedes Preview-Feature als ersetzbar. Wird die Plattform im November umbenannt, sollte das in Ihrem System eine Konfigurationsänderung sein, kein Migrationsprojekt. Die Richtung selbst — Agenten als verwaltete Cloud-Workloads — kehrt sich nicht um.