Foundry | The .NET Blog

Microsoft Foundry April 2026: Foundry Local GA, GPT-5.5, CodeAct mit Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Ein geschäftiger Monat für Microsoft Foundry. Hier sind die wichtigsten Ankündigungen.

Foundry Local ist Allgemein Verfügbar

Foundry Local — Microsofts plattformübergreifende lokale KI-Laufzeit — wechselt von der Vorschau zu GA auf Windows, macOS (Apple Silicon) und Linux x64. Produktionsreife lokale Modellinferenz mit einem entwicklerfreundlichen SDK. Version 1.1 fügt Transkriptions-, Embeddings- und Responses-API-Unterstützung hinzu.

GPT-5.5

Das neueste Modell der GPT-5-Familie ist jetzt in Foundry verfügbar. Standardquota für Tier 5- und Tier 6-Abonnements. Wenn Sie mit früheren GPT-5-Varianten gearbeitet haben, lohnt es sich, dies für Ihre Anwendungsfälle zu evaluieren.

Agent Framework Tracing in Foundry

Diesen Monat werden zwei Tracing-Funktionen in der Vorschau bereitgestellt:

Microsoft Agent Framework Tracing — MAF-Agenten können jetzt OpenTelemetry-Traces in Foundry ausgeben. Debuggen Sie das Agentenverhalten, verfolgen Sie die mehrstufige Ausführung, zeigen Sie Latenz und Fehler über Tool-Aufrufe hinweg an. Dies schließt eine echte Lücke: zu wissen, was Ihr Agent tatsächlich getan hat in der Produktion, nicht nur, was er zurückgegeben hat.

Hosted-Agent-Tracing — Sitzungen, Tool-Aufrufe und Ausführungsschritte von gehosteten Agenten erscheinen ebenfalls in Foundry-Traces. Dieselbe Observability-Geschichte erstreckt sich auf die gehostete Ebene.

CodeAct mit Hyperlight (Alpha)

Dies ist die technisch interessanteste Ergänzung: Agent Framework kann jetzt Python-Code in Hyperlight-Micro-VMs ausführen.

CodeAct ist das Muster, bei dem ein Agent Python-Code als Tool generiert und ausführt. Die offensichtliche Sorge ist die Sicherheit — Sie führen vom Modell generierten Code aus. Hyperlights Micro-VMs bieten Isolation auf Prozessebene mit nahezu nativer Startzeit, was sandboxed Code-Ausführung ohne den Overhead vollständiger Container oder VMs praktisch macht.

Für agentische Workflows, bei denen Code-Ausführung notwendig ist, ist dies eine erhebliche Sicherheitsverbesserung gegenüber dem Ausführen von Code im Host-Prozess.

Agent Monitoring Dashboard (Vorschau)

Ein einheitliches Betriebs-Dashboard, das Token-Nutzung, Latenz, Ausführungserfolgsrate und Evaluator-Scores in einer Ansicht kombiniert. Der Unterschied zu regulären Observability-Dashboards: Es enthält Evaluierungsergebnisse zusammen mit Betriebsmetriken, sodass Sie “der Agent ist langsamer” mit “Evaluator-Scores sind gesunken” korrelieren können — oder bestätigen, dass sie nicht zusammenhängen.

Benutzerdefinierte Evaluatoren für Kontinuierliche Evaluierung (Vorschau)

Sie können jetzt eigene code- oder prompt-basierte Evaluatoren in kontinuierliche Evaluierungspipelines einbringen. Bisher war die kontinuierliche Evaluierung auf integrierte Evaluatoren beschränkt. Benutzerdefinierte Evaluatoren ermöglichen es Ihnen, teamspezifische Qualitätskriterien in Ihrer Produktions-Überwachungsschleife durchzusetzen.

Agenteninventar in der Steuerungsebene

Die Operate-Ansicht der Foundry-Steuerungsebene zeigt jetzt alle unterstützten Agenten über ein Abonnement hinweg: Foundry-Agenten, Azure SRE Agent, Logic Apps-Agentenschleifen und registrierte benutzerdefinierte Agenten. Eine Ansicht, um zu verstehen, was bereitgestellt ist und wo.

Originalbeitrag: What’s new in Microsoft Foundry | April 2026

Ihr Lokaler MAF-Agent Hat Jetzt ein Produktions-Zuhause

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Einen Agenten lokal zum Laufen zu bringen ist der spaßige Teil. Der knifflige Teil ist alles, was danach kommt: es ohne Nervenzerreißen zu deployen, Sitzungen zu verwalten, Identität einzurichten, Observabilität zu verkabeln. Das bedeutet normalerweise viel benutzerdefinierte Infrastruktur.

Foundry Hosted Agents hat den Großteil dieser Infrastruktur für Microsoft Agent Framework (MAF)-Benutzer gerade beseitigt.

Was Foundry Hosted Agents Wirklich Tut

Wenn Sie einen MAF-Agenten in Foundry Hosted Agents deployen, übernimmt die Plattform eine überraschend lange Liste von Dingen, die Sie sonst selbst bauen müssten:

Skalierung auf null — Ihr Agent kostet nichts im Leerlauf und fährt automatisch wieder hoch
Pro-Sitzung VM-isolierte Sandboxes — jede Benutzersitzung bekommt ihre eigene Sandbox mit Dateisystempersistenz, die Scale-down-Ereignisse überlebt
Eingebautes Entra ID — jeder Agent erhält seine eigene Identität, um Foundry-Modelle, Toolbox und Azure-Dienste aufzurufen, ohne Geheimnisse im Image
Versionierte Deployments — jedes Deployment ist ein unveränderlicher Snapshot mit Blue/Green- und Canary-Rollout-Unterstützung
Observabilität ohne Konfiguration — APPLICATIONINSIGHTS_CONNECTION_STRING wird zur Laufzeit injiziert, sodass MAFs OpenTelemetry-Traces automatisch in App Insights fließen

Letzteres ist wirklich angenehm. Kein zusätzliches Verkabeln, keine zusätzliche Konfiguration. Traces erscheinen einfach.

Der Code-Unterschied Ist Minimal

Das schätze ich an dieser Integration am meisten. Sie schreiben Ihren Agenten nicht neu. Sie umhüllen ihn einfach:

In .NET:

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

In Python:

server = ResponsesHostServer(agent)
server.run()

Das ist alles. Dieselbe Logik, die Sie lokal getestet haben, läuft in der Produktion. Die Plattform umhüllt sie mit der Infrastruktur für Sitzungsverwaltung, Identität und Skalierung.

Zwei Protokolle, Ein Agent

Hosted Agents unterstützen zwei Endpoint-Stile:

Responses (/responses) — OpenAI-kompatibel, verwaltet Gesprächsverlauf und Streaming. Guter Standard für chat-ähnliche Agenten.
Invocations (/invocations) — Sie definieren das Anfrage-/Antwortschema. Gut für nicht-konversationelle Workflows.

Wenn Sie etwas bauen, das wie ein Gespräch aussieht, beginnen Sie mit Responses. Wenn Sie einen API-ähnlichen Agenten bauen, der strukturierte Eingaben nimmt und strukturierte Ausgaben zurückgibt, gibt Ihnen Invocations die Flexibilität.

Der Deployment-Ablauf mit `azd`

Wenn Sie azd up mit einem MAF-Agenten ausführen:

Erstellt optional ein Foundry-Projekt und deployed ein Modell
Packt Ihren Code und pusht ein Image zu Azure Container Registry
Provisioniert Compute aus dem ACR-Image
Weist dem Agenten eine dedizierte Entra ID zu
Stellt einen stabilen Endpoint bereit (https://{project_endpoint}/agents/{agent_name})
Handhabt alles andere von diesem Punkt an

Sitzungen bleiben bis zu 30 Tage bestehen. Inaktives Compute wird nach 15 Minuten deprovisioniert und bei der nächsten Anfrage transparent wiederhergestellt. Aus der Perspektive des Agenten hat sich nichts geändert.

Fazit

Die Distanz zwischen “lokal funktionierend” und “in der Produktion laufend” war für KI-Agenten historisch lang und schmerzhaft. Foundry Hosted Agents + MAF schließt diese Lücke erheblich. Wenn Sie bereits einen lokalen Agenten mit Agent Framework gebaut haben, lohnt es sich, dies heute auszuprobieren.

Das Team sagt, GA kommt bald — dies ist derzeit in Preview. Schauen Sie sich die MAF Hosted Agent Integration-Dokumentation und die .NET-Beispiele an, um loszulegen.

Originalartikel: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1: Echtzeit-Transkription, Embeddings und die Responses API

Emiliano Montesdeoca — Thu, 28 May 2026 00:00:00 +0000

Foundry Local 1.0 hat das Konzept bewiesen: KI-Modelle lokal auf Windows, macOS (Apple Silicon) und Linux x64 mit einem entwicklerfreundlichen SDK ausführen. Version 1.1 fügt drei Fähigkeiten hinzu, die viele echte Produktionsanwendungsfälle abdecken.

Live-Audio-Transkription

Die bedeutendste neue Funktion: Echtzeit-Sprache-zu-Text-Streaming direkt vom Mikrofon. Untertitel, Sprach-UIs, Meeting-Transkription, Barrierefreiheitswerkzeuge — alles lokal ohne jede Cloud-Abhängigkeit.

Die API ist sitzungsbasiert und überträgt Ergebnisse, sobald sie eintreffen, mit is_final-Markierungen zur Unterscheidung von vorläufigem und finalisiertem Text. Verfügbar für alle Sprachbindungen: JavaScript, C#, Python und Rust.

Laden Sie ein Streaming-Sprachmodell aus dem Katalog, erstellen Sie eine Sitzung mit Audio-Einstellungen (Abtastrate, Kanäle, Sprache), starten Sie sie, schieben Sie rohe PCM-Audio-Chunks und konsumieren Sie den asynchronen Stream von Ergebnissen. Der Post enthält vollständige Python- und C#-Beispiele.

Text-Embeddings

Semantische Suche, RAG-Pipelines, Clustering, Ähnlichkeitsvergleich — all das erfordert Embeddings. Foundry Local 1.1 fügt Unterstützung für Embedding-Modelle hinzu, sodass Sie Vektoren lokal aus demselben SDK generieren können, ohne Daten an einen Cloud-Endpoint zu senden.

Für Anwendungen, bei denen die Datenresidenz wichtig ist oder bei denen Sie sensible Inhalte verarbeiten, ist die lokale Embedding-Generierung eine bedeutsame Fähigkeit.

Responses API

Foundry Local unterstützt jetzt die Responses API — die strukturierte Schnittstelle für agentische Interaktionen. Dies fügt hinzu:

Tool-Aufruf — lassen Sie lokal ausgeführte Modelle von Ihnen definierte Werkzeuge aufrufen
Multimodale Vision-Sprach-Eingabe — übergeben Sie Bild + Text an vision-fähige Modelle
Kompatibel mit der Standard-API-Form, sodass vorhandene Agenten, die auf die Responses API von OpenAI abzielen, gegen lokale Modelle funktionieren

Verbesserungen der Paketgröße

Zwei Änderungen reduzieren die JavaScript-Paketgröße:

Die koffi-FFI-Schicht wurde durch ein benutzerdefiniertes Node-API-C-Addon ersetzt
Der WebGPU-Ausführungsanbieter wird als separates Plugin geliefert, sodass Anwendungen ohne GPU-Beschleunigung keine Größenkosten tragen

Das C#-SDK zielt jetzt auf niedrigere Framework-Versionen für breitere .NET-Kompatibilität ab.

Warum Das Wichtig Ist

Die drei Fähigkeiten zusammen — Transkription, Embeddings, Tool-Aufruf — decken die Kernbausteine vieler KI-Anwendungen ab. Sie lokal auszuführen bedeutet:

Kein Internet erforderlich
Keine Kosten pro Token
Keine Daten verlassen die Maschine
Konsistente Latenz unabhängig von Netzwerkbedingungen

Foundry Local ist die richtige Wahl für Edge-Szenarien, datenschutzsensible Workloads, Offline-Anwendungen oder alles, wo Sie Cloud-Abhängigkeit während der Entwicklung vermeiden möchten.

Originalbeitrag: Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

GPT-5.5 ist da und kommt zu Azure Foundry — Was .NET-Entwickler Wissen Müssen

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Zur Originalversion hier klicken.

Microsoft hat gerade bekannt gegeben, dass GPT-5.5 allgemein in Microsoft Foundry verfügbar ist. Wenn du Agenten auf Azure aufgebaut hast, ist das das Update, auf das du gewartet hast.

Die GPT-5-Progression

GPT-5: vereinte Reasoning und Geschwindigkeit in einem einzigen System
GPT-5.4: stärkeres Multi-Step-Reasoning, frühe agentische Fähigkeiten für Unternehmen
GPT-5.5: tieferes Langkontext-Reasoning, zuverlässigere agentische Ausführung, bessere Token-Effizienz

Was sich wirklich geändert hat

Verbessertes agentisches Coding: GPT-5.5 hält Kontext über große Codebasen hinweg, diagnostiziert Architekturfehler und antizipiert Testanforderungen. Das Modell überlegt, was sonst noch eine Korrektur beeinflusst.

Token-Effizienz: Höherwertigere Ausgaben mit weniger Tokens und weniger Wiederholungen. Direkt niedrigere Kosten und Latenz für Produktions-Deployments.

Langkontext-Analyse: Verarbeitet umfangreiche Dokumente und Multi-Session-Historien ohne den Faden zu verlieren.

Preise

Modell	Eingabe ($/M Tokens)	Gecachte Eingabe	Ausgabe ($/M Tokens)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Warum Foundry wichtig ist

Foundry Agent Service ermöglicht es, Agenten in YAML zu definieren oder sie mit Microsoft Agent Framework, GitHub Copilot SDK, LangGraph oder OpenAI Agents SDK zu verbinden — und sie als isolierte gehostete Agenten mit persistentem Dateisystem, eigener Microsoft Entra-Identität und Scale-to-zero-Preisen auszuführen.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Du bist ein hilfreicher Assistent.", name: "MeinAgent");

Sieh dir die vollständige Ankündigung für alle Details an.

Foundrys RFT ist jetzt günstiger und intelligenter — Das hat sich geändert

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Wenn ihr .NET-Apps entwickelt, die auf fine-getunte Modelle angewiesen sind, solltet ihr die Foundry-Updates dieses Monats im Auge behalten. Reinforcement Fine-Tuning ist jetzt zugänglicher und deutlich günstiger geworden.

Die vollständigen Details findet ihr in der offiziellen Ankündigung, aber hier ist die praktische Zusammenfassung.

Globales Training für o4-mini

o4-mini ist das Go-to-Modell für reasoning-intensive und agentenbasierte Workloads. Die große Neuigkeit: Ihr könnt jetzt Fine-Tuning-Jobs aus über 13 Azure-Regionen starten, mit niedrigeren Pro-Token-Trainingskosten im Vergleich zum Standard-Training. Gleiche Infrastruktur, gleiche Qualität, größere Reichweite.

Wenn euer Team über verschiedene Regionen verteilt ist, ist das relevant. Ihr seid nicht mehr auf eine Handvoll Regionen zum Trainieren beschränkt.

Hier ist der REST-API-Aufruf, um einen globalen Trainingsjob zu starten:

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

Dieses trainingType: globalstandard-Flag ist der entscheidende Unterschied.

Neue Model-Grader: GPT-4.1-Familie

Grader definieren das Belohnungssignal, gegen das euer Modell optimiert. Bisher waren modellbasierte Grader auf eine kleinere Auswahl von Modellen beschränkt. Jetzt habt ihr drei neue Optionen: GPT-4.1, GPT-4.1-mini und GPT-4.1-nano.

Wann solltet ihr Model-Grader statt deterministischer Grader verwenden? Wenn eure Aufgabenausgabe offen ist, wenn ihr partielle Bewertung über mehrere Dimensionen braucht, oder wenn ihr agentenbasierte Workflows baut, bei denen die Korrektheit von Tool-Aufrufen vom semantischen Kontext abhängt.

Die Sache ist — die Tier-Strategie ist praktisch:

GPT-4.1-nano für erste Iterationen. Niedrige Kosten, schnelle Feedback-Schleifen.
GPT-4.1-mini sobald eure Bewertungsrubrik stabil ist und ihr höhere Genauigkeit braucht.
GPT-4.1 für Produktionsbewertung oder komplexe Rubriken, bei denen jede Bewertungsentscheidung zählt.

Ihr könnt sogar Grader-Typen in einem einzigen RFT-Job mischen. Verwendet String-Match für die “richtige Antwort”-Dimension und einen Model-Grader zur Bewertung der Reasoning-Qualität. Diese Flexibilität ist ehrlich gesagt das, was es für echte Workloads nützlich macht.

Die Stolperfalle beim RFT-Datenformat

Hierüber stolpern viele. Das RFT-Datenformat unterscheidet sich von SFT. Die letzte Nachricht in jeder Zeile muss eine User- oder Developer-Rolle haben — nicht Assistant. Die erwartete Antwort kommt in einen Top-Level-Schlüssel wie reference_answer, auf den der Grader direkt verweist.

Wenn ihr bisher Supervised Fine-Tuning gemacht habt und auf RFT umsteigen wollt, müsst ihr eure Trainingsdaten umstrukturieren. Überspringt diesen Schritt nicht, sonst schlagen eure Jobs stillschweigend fehl.

Warum das für .NET-Entwickler wichtig ist

Wenn ihr fine-getunte Modelle aus euren .NET-Apps über das Azure OpenAI SDK aufruft, bedeutet günstigeres Training, dass ihr aggressiver iterieren könnt. Die Model-Grader-Optionen bedeuten, dass ihr für nuancierte Aufgaben fine-tunen könnt — nicht nur für Exact-Match-Szenarien. Und der Best-Practices-Leitfaden auf GitHub wird euch echte Debugging-Zeit sparen.

Fangt klein an. Zehn bis hundert Samples. Einfacher Grader. Validiert den Loop. Dann skaliert.

Microsoft Foundry März 2026 — GPT-5.4, Agent Service GA und das SDK-Refresh, das Alles Verändert

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Die monatlichen „What’s New in Microsoft Foundry"-Posts sind normalerweise eine Mischung aus inkrementellen Verbesserungen und gelegentlichen Highlight-Features. Die März 2026-Ausgabe? Praktisch nur Highlight-Features. Foundry Agent Service erreicht GA, GPT-5.4 geht in Produktion, das SDK bekommt ein großes stabiles Release, und Fireworks AI bringt Open-Model-Inferenz nach Azure. Schauen wir uns an, was für .NET-Entwickler wichtig ist.

Foundry Agent Service ist produktionsreif

Das ist die große Neuigkeit. Die Runtime der nächsten Generation für Agenten ist allgemein verfügbar — aufgebaut auf der OpenAI Responses API, draht-kompatibel mit OpenAI-Agenten und offen für Modelle verschiedener Anbieter. Wenn ihr heute mit der Responses API baut, fügt die Migration zu Foundry Enterprise-Sicherheit, privates Networking, Entra RBAC, vollständiges Tracing und Evaluation auf eure bestehende Agentenlogik hinzu.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

Zentrale Neuerungen: End-to-End Private Networking, MCP-Auth-Erweiterung (einschließlich OAuth-Passthrough), Voice Live Preview für Sprach-zu-Sprach-Agenten und gehostete Agenten in 6 neuen Regionen.

GPT-5.4 — Zuverlässigkeit über reine Intelligenz

Bei GPT-5.4 geht es nicht darum, schlauer zu sein. Es geht um Zuverlässigkeit. Stärkeres Reasoning über lange Interaktionen, bessere Instruktionstreue, weniger Ausfälle mitten im Workflow und integrierte Computer-Use-Fähigkeiten. Für Produktions-Agenten ist diese Zuverlässigkeit viel wichtiger als Benchmark-Scores.

Modell	Preis (pro M Token)	Ideal für
GPT-5.4 (≤272K)	$2.50 / $15 Output	Produktions-Agenten, Coding, Dokumenten-Workflows
GPT-5.4 Pro	$30 / $180 Output	Tiefgehende Analyse, wissenschaftliches Reasoning
GPT-5.4 Mini	Kostengünstig	Klassifikation, Extraktion, leichte Tool-Aufrufe

Die clevere Strategie ist Routing: GPT-5.4 Mini übernimmt die hochvolumige, latenzarme Arbeit, während GPT-5.4 die reasoning-intensiven Anfragen bearbeitet.

Das SDK ist endlich stabil

Das azure-ai-projects SDK hat stabile Releases in allen Sprachen veröffentlicht — Python 2.0.0, JS/TS 2.0.0, Java 2.0.0 und .NET 2.0.0 (1. April). Die azure-ai-agents-Abhängigkeit ist weg — alles lebt unter AIProjectClient. Installation mit pip install azure-ai-projects, das Paket bündelt openai und azure-identity als direkte Abhängigkeiten.

Für .NET-Entwickler bedeutet das ein einziges NuGet-Paket für die gesamte Foundry-Oberfläche. Schluss mit dem Jonglieren separater Agent-SDKs.

Fireworks AI bringt offene Modelle nach Azure

Vielleicht die architektonisch interessanteste Ergänzung: Fireworks AI verarbeitet über 13 Billionen Token täglich bei ~180K Anfragen/Sekunde, jetzt über Foundry verfügbar. DeepSeek V3.2, gpt-oss-120b, Kimi K2.5 und MiniMax M2.5 zum Start.

Die eigentliche Geschichte ist Bring-Your-Own-Weights — quantisierte oder feingetunete Gewichte von überall hochladen, ohne den Serving-Stack zu ändern. Deployment über serverloses Pay-per-Token oder provisionierten Durchsatz.

Weitere Highlights

Phi-4 Reasoning Vision 15B — multimodales Reasoning für Charts, Diagramme und Dokumentlayouts
Evaluations GA — fertige Evaluatoren mit kontinuierlichem Produktions-Monitoring direkt in Azure Monitor
Priority Processing (Preview) — dedizierte Compute-Lane für latenzempfindliche Workloads
Voice Live — Sprach-zu-Sprach-Runtime, die direkt mit Foundry-Agenten verbunden ist
Tracing GA — End-to-End-Inspektion von Agenten-Traces mit Sortierung und Filterung
PromptFlow-Deprecation — Migration zu Microsoft Framework Workflows bis Januar 2027

Fazit

März 2026 ist ein Wendepunkt für Foundry. Agent Service GA, stabile SDKs in allen Sprachen, GPT-5.4 für zuverlässige Produktions-Agenten und Open-Model-Inferenz über Fireworks AI — die Plattform ist bereit für ernsthafte Workloads.

Lest den vollständigen Überblick und baut euren ersten Agenten, um loszulegen.

Verbinde deine MCP-Server auf Azure Functions mit Foundry Agents — So geht's

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion finden Sie hier.

Das liebe ich am MCP-Ökosystem: Du baust deinen Server einmal, und er funktioniert überall. VS Code, Visual Studio, Cursor, ChatGPT — jeder MCP-Client kann deine Tools entdecken und nutzen. Jetzt fügt Microsoft einen weiteren Konsumenten zu dieser Liste hinzu: Foundry-Agenten.

Lily Ma vom Azure SDK-Team hat einen praktischen Leitfaden veröffentlicht zur Verbindung von MCP-Servern auf Azure Functions mit Microsoft Foundry-Agenten. Wenn du bereits einen MCP-Server hast, ist das reiner Mehrwert — kein Neuaufbau nötig.

Warum diese Kombination Sinn macht

Azure Functions bietet dir skalierbare Infrastruktur, integrierte Authentifizierung und Serverless-Abrechnung für das Hosting von MCP-Servern. Microsoft Foundry bietet dir AI-Agenten, die denken, planen und handeln können. Beides zu verbinden bedeutet, dass deine benutzerdefinierten Tools — Datenbankabfragen, Business-API-Aufrufe, Validierungslogik — zu Fähigkeiten werden, die Enterprise-AI-Agenten autonom entdecken und nutzen können.

Der Kernpunkt: Dein MCP-Server bleibt gleich. Du fügst einfach Foundry als weiteren Konsumenten hinzu. Die gleichen Tools, die in deinem VS Code-Setup funktionieren, treiben jetzt einen AI-Agenten an, mit dem dein Team oder deine Kunden interagieren.

Authentifizierungsoptionen

Hier liefert der Post echten Mehrwert. Vier Authentifizierungsmethoden je nach Szenario:

Methode	Anwendungsfall
Schlüsselbasiert (Standard)	Entwicklung oder Server ohne Entra-Auth
Microsoft Entra	Produktion mit verwalteten Identitäten
OAuth Identity Passthrough	Produktion, bei der sich jeder Benutzer einzeln authentifiziert
Ohne Authentifizierung	Entwicklung/Tests oder nur öffentliche Daten

Für die Produktion ist Microsoft Entra mit Agentenidentität der empfohlene Weg. OAuth Identity Passthrough ist für Fälle, in denen der Benutzerkontext wichtig ist — der Agent fordert Benutzer zur Anmeldung auf, und jede Anfrage trägt das eigene Token des Benutzers.

Einrichtung

Der allgemeine Ablauf:

Deploye deinen MCP-Server auf Azure Functions — Beispiele verfügbar für .NET, Python, TypeScript und Java
Aktiviere die integrierte MCP-Authentifizierung auf deiner Function App
Hole deine Endpoint-URL — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
Füge den MCP-Server als Tool in Foundry hinzu — navigiere zu deinem Agenten im Portal, füge ein neues MCP-Tool hinzu, gib Endpoint und Credentials an

Dann teste es im Agent Builder Playground, indem du einen Prompt sendest, der eines deiner Tools auslöst.

Meine Einschätzung

Die Composability-Geschichte wird hier richtig stark. Baue deinen MCP-Server einmal in .NET (oder Python, TypeScript, Java), deploye ihn auf Azure Functions, und jeder MCP-kompatible Client kann ihn nutzen — Coding-Tools, Chat-Apps und jetzt Enterprise-AI-Agenten. Das ist ein „einmal schreiben, überall nutzen"-Muster, das tatsächlich funktioniert.

Speziell für .NET-Entwickler macht die Azure Functions MCP-Erweiterung das unkompliziert. Du definierst deine Tools als Azure Functions, deployest sie, und du hast einen produktionsreifen MCP-Server mit der gesamten Sicherheit und Skalierung, die Azure Functions bietet.

Zusammenfassung

Wenn du MCP-Tools auf Azure Functions betreibst, ist die Verbindung mit Foundry-Agenten ein schneller Gewinn — deine benutzerdefinierten Tools werden zu Enterprise-AI-Fähigkeiten mit korrekter Authentifizierung und ohne Code-Änderungen am Server selbst.

Lies den vollständigen Leitfaden für Schritt-für-Schritt-Anleitungen zu jeder Authentifizierungsmethode, und sieh dir die detaillierte Dokumentation für Produktions-Setups an.

Azure DevOps MCP Server landet in Microsoft Foundry: Was das für deine KI-Agenten bedeutet

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP (Model Context Protocol) hat gerade seinen Moment. Wenn du das KI-Agenten-Ökosystem verfolgst, hast du wahrscheinlich bemerkt, dass MCP-Server überall auftauchen — sie geben Agenten die Fähigkeit, über ein standardisiertes Protokoll mit externen Tools und Diensten zu interagieren.

Jetzt ist der Azure DevOps MCP Server in Microsoft Foundry verfügbar, und das ist eine dieser Integrationen, die einen über die praktischen Möglichkeiten nachdenken lässt.

Was hier tatsächlich passiert

Microsoft hat den Azure DevOps MCP Server bereits als Public Preview veröffentlicht — das ist der MCP-Server selbst. Neu ist die Foundry-Integration. Du kannst den Azure DevOps MCP Server jetzt direkt aus dem Tool-Katalog zu deinen Foundry-Agenten hinzufügen.

Für diejenigen, die Foundry noch nicht kennen: Es ist Microsofts einheitliche Plattform zum Erstellen und Verwalten von KI-gestützten Anwendungen und Agenten im großen Maßstab. Modellzugriff, Orchestrierung, Evaluierung, Deployment — alles an einem Ort.

Die Einrichtung

Die Einrichtung ist überraschend unkompliziert:

Gehe in deinem Foundry-Agenten zu Add Tools > Catalog
Suche nach “Azure DevOps”
Wähle den Azure DevOps MCP Server (Preview) und klicke auf Create
Gib deinen Organisationsnamen ein und verbinde

Das war’s. Dein Agent hat jetzt Zugriff auf Azure DevOps-Tools.

Kontrollieren, worauf dein Agent zugreifen kann

Das ist der Teil, den ich schätze: Du bist nicht auf einen Alles-oder-Nichts-Ansatz festgelegt. Du kannst festlegen, welche Tools deinem Agenten zur Verfügung stehen. Wenn du also willst, dass er nur Work Items lesen, aber keine Pipelines anfassen darf, kannst du das konfigurieren. Prinzip der minimalen Berechtigung, angewandt auf deine KI-Agenten.

Das ist wichtig für Enterprise-Szenarien, in denen du nicht willst, dass ein Agent versehentlich eine Deployment-Pipeline auslöst, weil jemand ihn gebeten hat, “beim Release zu helfen.”

Warum das für .NET-Teams interessant ist

Denk darüber nach, was das in der Praxis ermöglicht:

Sprint-Planungsassistenten — Agenten, die Work Items abrufen, Velocity-Daten analysieren und Sprint-Kapazität vorschlagen können
Code-Review-Bots — Agenten, die deinen PR-Kontext verstehen, weil sie tatsächlich deine Repos und verknüpften Work Items lesen können
Incident Response — Agenten, die Work Items erstellen, kürzliche Deployments abfragen und Bugs mit kürzlichen Änderungen korrelieren können
Entwickler-Onboarding — “Woran sollte ich arbeiten?” bekommt eine echte Antwort, gestützt auf tatsächliche Projektdaten

Für .NET-Teams, die Azure DevOps bereits für ihre CI/CD-Pipelines und Projektverwaltung nutzen, ist ein KI-Agent, der direkt mit diesen Systemen interagieren kann, ein bedeutender Schritt in Richtung nützlicher Automatisierung.

Das größere MCP-Bild

Das ist Teil eines breiteren Trends: MCP-Server werden zum Standard, wie KI-Agenten mit der Außenwelt interagieren. Wir sehen sie für GitHub, Azure DevOps, Datenbanken, SaaS-APIs — und Foundry wird zum Hub, wo all diese Verbindungen zusammenkommen.

Wenn du Agenten im .NET-Ökosystem baust, lohnt es sich, MCP im Auge zu behalten. Das Protokoll ist standardisiert, das Tooling reift heran, und die Foundry-Integration macht es zugänglich, ohne Server-Verbindungen manuell einrichten zu müssen.

Zusammenfassung

Der Azure DevOps MCP Server in Foundry ist in der Preview, also rechne damit, dass er sich weiterentwickelt. Aber der Kern-Workflow ist solide: verbinden, Tool-Zugriff konfigurieren und deine Agenten mit deinen DevOps-Daten arbeiten lassen. Wenn du bereits im Foundry-Ökosystem bist, ist das nur ein paar Klicks entfernt. Probier es aus und schau, welche Workflows du bauen kannst.

Schau dir die vollständige Ankündigung für die Schritt-für-Schritt-Einrichtung und weitere Details an.

Foundry Agent Service ist GA: Was für .NET-Agent-Entwickler wirklich zählt

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Seien wir ehrlich — einen KI-Agenten-Prototyp zu bauen ist der einfache Teil. Der schwierige Teil ist alles danach: ihn in Produktion zu bringen mit ordentlicher Netzwerk-Isolation, Evaluierungen durchzuführen die wirklich etwas bedeuten, Compliance-Anforderungen zu erfüllen und um 2 Uhr morgens nichts kaputt zu machen.

Der Foundry Agent Service ist jetzt GA, und dieses Release ist laser-fokussiert auf genau diese “alles danach”-Lücke.

Gebaut auf der Responses API

Die Schlagzeile: der Foundry Agent Service der nächsten Generation basiert auf der OpenAI Responses API. Wenn du bereits mit diesem Wire-Protokoll baust, erfordert die Migration zu Foundry minimale Code-Änderungen. Was du gewinnst: Enterprise-Sicherheit, Private Networking, Entra RBAC, vollständiges Tracing und Evaluierung — auf deiner bestehenden Agent-Logik.

Die Architektur ist bewusst offen. Du bist nicht an einen Modell-Anbieter oder ein Orchestrierungs-Framework gebunden. Nutze DeepSeek fürs Planen, OpenAI für die Generierung, LangGraph für die Orchestrierung — die Runtime kümmert sich um die Konsistenz-Schicht.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

Wenn du vom azure-ai-agents-Paket kommst: Agenten sind jetzt First-Class-Operationen auf AIProjectClient in azure-ai-projects. Entferne die standalone-Abhängigkeit und nutze get_openai_client() um Responses zu steuern.

Private Networking: der Enterprise-Blocker beseitigt

Das ist die Funktion, die Enterprise-Adoption freischaltet. Foundry unterstützt jetzt vollständiges End-to-End Private Networking mit BYO VNet:

Kein öffentlicher Egress — Agent-Traffic berührt nie das öffentliche Internet
Container/Subnet-Injection in dein Netzwerk für lokale Kommunikation
Tool-Konnektivität inklusive — MCP-Server, Azure AI Search, Fabric-Datenagenten operieren alle über private Pfade

Der letzte Punkt ist entscheidend. Es sind nicht nur Inferenz-Aufrufe, die privat bleiben — jeder Tool-Aufruf und jede Retrieval-Anfrage bleibt ebenfalls innerhalb deiner Netzwerk-Grenze. Für Teams, die unter Datenklassifizierungsrichtlinien arbeiten, die externes Routing verbieten, war das was fehlte.

MCP-Authentifizierung richtig gemacht

MCP-Server-Verbindungen unterstützen jetzt das volle Spektrum an Auth-Patterns:

Auth-Methode	Wann verwenden
Key-basiert	Einfacher geteilter Zugriff für org-weite interne Tools
Entra Agent Identity	Service-to-Service; der Agent authentifiziert sich als er selbst
Entra Managed Identity	Projekt-Isolation; kein Credential-Management
OAuth Identity Passthrough	Benutzer-delegierter Zugriff; Agent handelt im Auftrag der Benutzer

OAuth Identity Passthrough ist der interessante. Wenn Benutzer einem Agenten Zugriff auf ihre persönlichen Daten geben müssen — ihr OneDrive, ihre Salesforce-Org, eine SaaS-API mit Benutzer-Scope — handelt der Agent in ihrem Auftrag mit Standard-OAuth-Flows. Keine geteilte System-Identität, die vorgibt, alle zu sein.

Voice Live: Sprache-zu-Sprache ohne das Leitungswirrwarr

Einem Agenten Sprache hinzuzufügen bedeutete bisher, STT, LLM und TTS zusammenzufügen — drei Services, drei Latenz-Hops, drei Abrechnungsflächen, alles von Hand synchronisiert. Voice Live kollabiert das in eine einzige verwaltete API mit:

Semantische Sprachaktivitäts- und Sprechende-Erkennung (versteht Bedeutung, nicht nur Stille)
Serverseitige Rauschunterdrückung und Echokompensation
Barge-in-Unterstützung (Benutzer können mitten in der Antwort unterbrechen)

Sprachinteraktionen laufen durch die gleiche Agent-Runtime wie Text. Gleiche Evaluatoren, gleiche Traces, gleiche Kosten-Transparenz. Für Kundensupport, Außendienst oder Barrierefreiheits-Szenarien ersetzt das, was vorher eine individuelle Audio-Pipeline erforderte.

Evaluierungen: von der Checkbox zum kontinuierlichen Monitoring

Hier wird Foundry ernst bezüglich Produktionsqualität. Das Evaluierungs-System hat jetzt drei Schichten:

Mitgelieferte Evaluatoren — Kohärenz, Relevanz, Begründetheit, Retrieval-Qualität, Sicherheit. Verbinde mit einem Dataset oder Live-Traffic und erhalte Scores zurück.
Eigene Evaluatoren — kodiere deine eigene Geschäftslogik, Ton-Standards und domänenspezifische Compliance-Regeln.
Kontinuierliche Evaluierung — Foundry sampelt Live-Produktionstraffic, führt deine Evaluator-Suite aus und zeigt Ergebnisse in Dashboards. Setze Azure-Monitor-Alerts für sinkende Begründetheit oder Sicherheitsschwellen-Verletzungen.

Alles wird in Azure Monitor Application Insights veröffentlicht. Agent-Qualität, Infrastruktur-Gesundheit, Kosten und App-Telemetrie — alles an einem Ort.

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

Sechs neue Regionen für gehostete Agenten

Gehostete Agenten sind jetzt verfügbar in East US, North Central US, Sweden Central, Southeast Asia, Japan East und mehr. Das ist wichtig für Datenresidenz-Anforderungen und um Latenz zu komprimieren, wenn dein Agent nahe an seinen Datenquellen läuft.

Warum das für .NET-Entwickler wichtig ist

Auch wenn die Code-Samples im GA-Announcement Python-first sind, ist die zugrundeliegende Infrastruktur sprachunabhängig — und das .NET SDK für azure-ai-projects folgt den gleichen Mustern. Die Responses API, das Evaluierungs-Framework, das Private Networking, die MCP-Auth — all das ist von .NET aus verfügbar.

Wenn du darauf gewartet hast, dass KI-Agenten von “coole Demo” zu “kann ich tatsächlich auf der Arbeit ausliefern” werden, ist dieses GA-Release das Signal. Private Networking, ordentliche Auth, kontinuierliche Evaluierung und Produktions-Monitoring sind die Teile, die gefehlt haben.

Zusammenfassung

Foundry Agent Service ist jetzt verfügbar. Installiere das SDK, öffne das Portal und fang an zu bauen. Der Schnellstart-Guide bringt dich in Minuten von null zu einem laufenden Agenten.

Für den vollständigen technischen Deep-Dive mit allen Code-Samples, schau dir das GA-Announcement an.

Vom Laptop in die Produktion: KI-Agenten mit zwei Befehlen auf Microsoft Foundry deployen

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Du kennst diese Lücke zwischen “es funktioniert auf meinem Rechner” und “es ist deployed und bedient Traffic”? Für KI-Agenten war diese Lücke schmerzhaft groß. Du musst Ressourcen bereitstellen, Modelle deployen, Identität einrichten, Monitoring aufsetzen — und das ist bevor jemand deinen Agenten überhaupt aufrufen kann.

Das Azure Developer CLI hat das gerade zu einer Zwei-Befehle-Angelegenheit gemacht.

Der neue `azd ai agent` Workflow

Lass mich durchgehen, wie das tatsächlich aussieht. Du hast ein KI-Agenten-Projekt — sagen wir einen Hotel-Concierge-Agenten. Er funktioniert lokal. Du willst ihn auf Microsoft Foundry laufen lassen.

azd ai agent init
azd up

Das war’s. Zwei Befehle. azd ai agent init generiert die Infrastructure-as-Code in deinem Repo, und azd up provisioniert alles auf Azure und veröffentlicht deinen Agenten. Du bekommst einen direkten Link zu deinem Agenten im Foundry-Portal.

Was unter der Haube passiert

Der init-Befehl generiert echte, inspizierbare Bicep-Templates in deinem Repo:

Eine Foundry Resource (Top-Level-Container)
Ein Foundry Project (wo dein Agent lebt)
Modell-Deployment-Konfiguration (GPT-4o, etc.)
Managed Identity mit korrekten RBAC-Rollenzuweisungen
azure.yaml für die Service-Map
agent.yaml mit Agent-Metadaten und Umgebungsvariablen

Hier der entscheidende Punkt: all das gehört dir. Es ist versioniertes Bicep in deinem Repo. Du kannst es inspizieren, anpassen und zusammen mit deinem Agenten-Code committen. Keine magischen Black Boxes.

Die innere Entwicklungsschleife

Was mir wirklich gefällt, ist die lokale Entwicklungsgeschichte. Wenn du an der Agenten-Logik iterierst, willst du nicht bei jeder Prompt-Änderung neu deployen:

azd ai agent run

Das startet deinen Agenten lokal. Kombiniere es mit azd ai agent invoke um Test-Prompts zu senden, und du hast eine enge Feedback-Schleife. Code bearbeiten, neu starten, aufrufen, wiederholen.

Der invoke-Befehl ist auch clever beim Routing — wenn ein lokaler Agent läuft, zielt er automatisch darauf. Wenn nicht, geht er an den Remote-Endpoint.

Echtzeit-Monitoring

Das ist die Funktion, die mich überzeugt hat. Sobald dein Agent deployed ist:

azd ai agent monitor --follow

Jede Anfrage und Antwort, die durch deinen Agenten fließt, wird in Echtzeit in dein Terminal gestreamt. Für das Debugging von Produktionsproblemen ist das unbezahlbar. Kein Durchsuchen von Log Analytics, kein Warten auf Metrik-Aggregation — du siehst, was gerade passiert.

Der komplette Befehlssatz

Hier die Kurzreferenz:

Befehl	Was er tut
`azd ai agent init`	Scaffolding eines Foundry-Agent-Projekts mit IaC
`azd up`	Azure-Ressourcen bereitstellen und Agent deployen
`azd ai agent invoke`	Prompts an den Remote- oder lokalen Agent senden
`azd ai agent run`	Agent lokal für Entwicklung ausführen
`azd ai agent monitor`	Echtzeit-Logs vom veröffentlichten Agent streamen
`azd ai agent show`	Agent-Gesundheit und -Status prüfen
`azd down`	Alle Azure-Ressourcen aufräumen

Warum das für .NET-Entwickler wichtig ist

Auch wenn das Beispiel in der Ankündigung Python-basiert ist, ist die Infrastruktur-Geschichte sprachunabhängig. Dein .NET-Agent bekommt das gleiche Bicep-Scaffolding, das gleiche Managed-Identity-Setup, die gleiche Monitoring-Pipeline. Und wenn du azd bereits für deine .NET Aspire-Apps oder Azure-Deployments nutzt, passt das direkt in deinen bestehenden Workflow.

Die Deployment-Lücke für KI-Agenten war einer der größten Reibungspunkte im Ökosystem. Von einem funktionierenden Prototyp zu einem Produktions-Endpoint mit korrekter Identität, Networking und Monitoring zu kommen, sollte keine Woche DevOps-Arbeit erfordern. Jetzt braucht es zwei Befehle und ein paar Minuten.

Zusammenfassung

azd ai agent ist jetzt verfügbar. Wenn du das Deployment deiner KI-Agenten aufgeschoben hast, weil das Infrastruktur-Setup nach zu viel Arbeit aussah, probier es aus. Schau dir den vollständigen Walkthrough für die komplette Schritt-für-Schritt-Anleitung inklusive Frontend-Chat-App-Integration an.

Foundry | The .NET Blog

Microsoft Foundry April 2026: Foundry Local GA, GPT-5.5, CodeAct mit Hyperlight

Foundry Local ist Allgemein Verfügbar

GPT-5.5

Agent Framework Tracing in Foundry

CodeAct mit Hyperlight (Alpha)

Agent Monitoring Dashboard (Vorschau)

Benutzerdefinierte Evaluatoren für Kontinuierliche Evaluierung (Vorschau)

Agenteninventar in der Steuerungsebene

Ihr Lokaler MAF-Agent Hat Jetzt ein Produktions-Zuhause

Was Foundry Hosted Agents Wirklich Tut

Der Code-Unterschied Ist Minimal

Zwei Protokolle, Ein Agent

Der Deployment-Ablauf mit azd

Fazit

Foundry Local 1.1: Echtzeit-Transkription, Embeddings und die Responses API

Live-Audio-Transkription

Text-Embeddings

Responses API

Verbesserungen der Paketgröße

Warum Das Wichtig Ist

GPT-5.5 ist da und kommt zu Azure Foundry — Was .NET-Entwickler Wissen Müssen

Die GPT-5-Progression

Was sich wirklich geändert hat

Preise

Warum Foundry wichtig ist

Foundrys RFT ist jetzt günstiger und intelligenter — Das hat sich geändert

Globales Training für o4-mini

Neue Model-Grader: GPT-4.1-Familie

Die Stolperfalle beim RFT-Datenformat

Warum das für .NET-Entwickler wichtig ist

Microsoft Foundry März 2026 — GPT-5.4, Agent Service GA und das SDK-Refresh, das Alles Verändert

Foundry Agent Service ist produktionsreif

GPT-5.4 — Zuverlässigkeit über reine Intelligenz

Das SDK ist endlich stabil

Fireworks AI bringt offene Modelle nach Azure

Weitere Highlights

Fazit

Verbinde deine MCP-Server auf Azure Functions mit Foundry Agents — So geht's

Warum diese Kombination Sinn macht

Authentifizierungsoptionen

Einrichtung

Meine Einschätzung

Zusammenfassung

Azure DevOps MCP Server landet in Microsoft Foundry: Was das für deine KI-Agenten bedeutet

Was hier tatsächlich passiert

Die Einrichtung

Kontrollieren, worauf dein Agent zugreifen kann

Warum das für .NET-Teams interessant ist

Das größere MCP-Bild

Zusammenfassung

Foundry Agent Service ist GA: Was für .NET-Agent-Entwickler wirklich zählt

Gebaut auf der Responses API

Private Networking: der Enterprise-Blocker beseitigt

MCP-Authentifizierung richtig gemacht

Voice Live: Sprache-zu-Sprache ohne das Leitungswirrwarr

Evaluierungen: von der Checkbox zum kontinuierlichen Monitoring

Sechs neue Regionen für gehostete Agenten

Warum das für .NET-Entwickler wichtig ist

Zusammenfassung

Vom Laptop in die Produktion: KI-Agenten mit zwei Befehlen auf Microsoft Foundry deployen

Der neue azd ai agent Workflow

Was unter der Haube passiert

Die innere Entwicklungsschleife

Echtzeit-Monitoring

Der komplette Befehlssatz

Warum das für .NET-Entwickler wichtig ist

Zusammenfassung

Der Deployment-Ablauf mit `azd`

Der neue `azd ai agent` Workflow