20.09.2025 AI Engineering5 Minuten Lesezeit

Azure AI Foundry vor der Ignite 2025

Vor der Microsoft Ignite 2025 ziehen wir eine nüchterne Zwischenbilanz zu Azure AI Foundry: Was der Agent Service seit seiner GA als gehostete Runtime leistet, welche Roadmap-Signale im Agent-Factory-Narrativ stecken, warum das Azure-Präfix erodiert und welche Bausteine Engineering-Teams jetzt einführen oder vorerst nur beobachten sollten.

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, markiert dieses Datum einen Entscheidungspunkt. Die Plattform verändert sich schnell: Azure AI Studio wurde auf der Ignite 2024 zu 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 die nächste Welle vor. Entscheidend ist daher, welche Abhängigkeiten heute bereits vertretbar sind.

Plattform-Churn ist ein realer Kostenfaktor. Namen ändern sich, SDKs werden zusammengelegt, Preview-Dienste werden umgebaut oder eingestellt. Wer früh einsteigt, gewinnt früh neue Fähigkeiten, zahlt später aber möglicherweise mit Migrationsaufwand. Dieser Artikel hält den Stand vom 20. September 2025 fest und trennt sicher einführbare Bausteine von solchen, die wir vorerst 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 verspricht standardisierte Teile und wiederholbare Montage. Der Begriff ist Marketing, die behandelten Themen sind es nicht: Tracing, Evaluation, Interoperabilität und Governance bestimmen den Produktionsbetrieb. Wir lesen die Serie deshalb vor allem als Roadmap-Signal. Microsoft benennt darin ausdrücklich die Themen, die auf der Ignite konkret werden sollen.

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 reduziert Infrastrukturarbeit, übernimmt aber weder Prompt-Entwurf noch Qualitätsdefinition. Observability zeichnet Traces auf; die Evaluationskriterien müssen Sie weiterhin selbst festlegen. Auch Lock-in verschwindet nicht: Thread-Zustand und Tool-Konfiguration liegen im Dienst, während die Verantwortung für einen exportierbaren Zustand bei Ihnen bleibt.

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 Bewertungen verdienen eine Begründung. Obwohl Teile des MCP-Toolings noch Preview sind, führen wir MCP hinter einer eigenen Abstraktion ein: Das offene Protokoll hat Zugkraft über Microsoft hinaus und übersteht jede Plattformumbenennung. A2A-Orchestrierung beobachten wir dagegen nur. Die Multi-Agent-Muster sind wenige Monate alt, und die Ignite dürfte sowohl APIs als auch Preise noch verändern, bevor sich der Dienst stabilisiert.

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.

Einzelne Vorhersagen werden im Detail falsch sein; unsere Haltung bei Blue IT Systems hängt nicht von ihnen ab. Bauen Sie gegen Protokolle statt gegen Produktnamen, kapseln Sie Orchestrierung hinter eigenen Schnittstellen, halten Sie Konversationszustand exportierbar und behandeln Sie jedes Preview-Feature als ersetzbar. Eine Umbenennung im November sollte in Ihrem System eine Konfigurationsänderung auslösen, kein Migrationsprojekt. Die grundsätzlichere Richtung — Agenten als verwaltete Cloud-Workloads — bleibt davon unberührt.