Azure | 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

Cosmos DB Shell Ist in der Öffentlichen Vorschau — Und Es Hat einen Integrierten MCP-Server

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

Wenn Sie jemals zwischen einem Portal-Tab, einem SDK-Beispiel und einem halbfertigen Skript hin- und herspringen mussten, nur um eine Cosmos DB-Frage zu beantworten, kennen Sie bereits die Reibung, die dieses Projekt zu beseitigen versucht.

Azure Cosmos DB Shell ist gerade in die öffentliche Vorschau gestartet. Es ist ein Open-Source-CLI mit bash-ähnlicher Syntax und — der Teil, der es interessant macht — einem integrierten MCP-Server.

Was Es von Anderen Datenbank-CLIs Unterscheidet

Das CLI selbst ist nützlich: vertraute Befehle, Skript-Unterstützung, CI/CD-Integration. Dieser Teil ist das Mindestmaß für ein entwicklerorientiertes Datenbank-Tool.

Der interessante Teil ist die MCP-Server-Integration. Jeder Befehl, den das CLI bereitstellt, wird als MCP-Tool verfügbar, das Ihre KI-Agenten aufrufen können. Es gibt keine benutzerdefinierte API-Schicht, keinen Integrationscode zu schreiben. Ihr Agent kann:

Datenbankhierarchien mit cd, ls, pwd navigieren
SQL-Abfragen mit query ausführen und strukturierte Ergebnisse zurückbekommen
Elemente mit create item, update, rm erstellen und ändern
Datenbanken und Container mit mkdb, mkcon, rmdb, rmcon verwalten
Den aktuellen Kontext mit endpoint, pwd inspizieren

Die wichtigste Verschiebung: Ihr Agent spricht nicht mit einer Cosmos DB-API — er spricht mit derselben Shell-Schnittstelle, die Sie verwenden. Die Befehle sind deterministisch, prüfbar und Open Source, sodass Sie genau sehen können, was passiert.

Die Open-Source-Grundlage Ist Wichtig

Dies ist kein verwalteter Black-Box-Dienst. Die Shell ist Open Source, was bedeutet:

Sicherheitsteams können die Implementierung prüfen
Plattformteams können sie forken und für ihre spezifischen Standards erweitern
Entwickler können Verbesserungen beitragen, die allen zugutekommen

Für Unternehmens-Teams, die KI-Tools einsetzen, ist “können wir genau sehen, wie es funktioniert” zunehmend keine optionale Anforderung. Open Source ist hier ein bedeutsames Unterscheidungsmerkmal.

Drei Szenarien, Die Einfacher Werden

Intelligente Datenanalyse — verbinden Sie einen Agenten mit der Shell, stellen Sie Fragen in natürlicher Sprache, erhalten Sie strukturierte Abfrageergebnisse. Der Agent übernimmt die Abfragekonstruktion; die Shell übernimmt die Ausführung.

Autonomes Datenmanagement — Workflows, die Daten in Cosmos DB erstellen, aktualisieren oder entfernen müssen, können dies über die MCP-Tools tun, ohne eine benutzerdefinierte Integration zu benötigen.

Echtzeit-Überwachung und Warnungen — ein Agent kann Container periodisch abfragen, Ergebnisse vergleichen und Anomalien über den passenden Benachrichtigungskanal melden.

Die MCP-Schnittstelle macht diese Szenarien mit jeder KI-Plattform, die MCP spricht, kombinierbar — nicht nur mit Microsofts Tools.

Erste Schritte

Die Shell ist in der öffentlichen Vorschau. Installieren Sie sie, konfigurieren Sie Ihre Cosmos DB-Verbindung und aktivieren Sie den MCP-Server. Von dort aus kann jeder MCP-kompatible Agent-Host die Tools entdecken und verwenden.

Originalbeitrag: Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Ihr KI-Agent Hat ein Identitätsproblem (Und Hier ist die Vorlage, die Es Löst)

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

Es gibt einen Moment in jedem KI-Agenten-Projekt, der ungefähr so läuft: Die Demo funktioniert perfekt, der Agent interpretiert natürliche Sprache, ruft die richtigen APIs auf, gibt die richtigen Daten zurück. Dann fangen Sie an, über echte Benutzer nachzudenken.

Was hindert die Agenten-Session eines Benutzers daran, die Daten eines anderen Benutzers zu sehen? Was passiert, wenn der Agent durch Prompt-Injektion ausgetrickst wird? Was passiert, wenn er ein Tool auf unerwartete Weise aufruft?

Das sind keine Randfälle. Das sind Designentscheidungen, die Sie vor dem Deployment treffen müssen.

Eine neue azd-Vorlage von Curity und Microsoft gibt Ihnen eine funktionsfähige Referenz für genau dieses Problem.

Das Kernproblem: Authentifizierung ≠ Autorisierung

Die meisten Agenten-Beispiele behandeln die Benutzerauthentifizierung gut. Sie behandeln die Autorisierung schlecht. Zu wissen, wer der Benutzer ist, sagt Ihnen nicht, welche Daten er sehen sollte.

Eine traditionelle Client-Anwendung macht vorhersehbare API-Aufrufe. Ein KI-Agent ist nicht-deterministisch — er interpretiert natürliche Sprache und entscheidet, was er aufruft. Er kann kreativ sein. Er kann auch falsch liegen. Und wenn er durch Prompt-Injektion manipuliert wird, brauchen Sie Regeln, die nicht davon abhängen, dass die KI sich gut verhält.

Die Lösung, die diese Vorlage demonstriert: Kurzlebige Token, die genau die richtigen Informationen für jeden Hop tragen.

Wie die Token-Kette Funktioniert

Die Vorlage verwendet OAuth 2.0-Zugriffstoken mit Token-Austausch, um Berechtigungen bei jedem Schritt einzuschränken. Ein Benutzer-Token wird zweimal ausgetauscht, bevor es den MCP-Server erreicht:

Erster Austausch — schränkt den Scope ein und konvertiert das opake Token in ein JWT
Zweiter Austausch — fügt die Agenten-Identität und eine neue Zielgruppe für den MCP-Server-Hop hinzu

So sieht das MCP-Server-Token aus:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

Die customer_id ist vom Autorisierungsserver in das Token eingebettet, nicht als Parameter übergeben, den der Agent kontrolliert. Die API prüft das Token, nicht die Anweisungen des Agenten.

Das bedeutet: Selbst wenn jemand den Agenten dazu verleitet, die Daten eines anderen Kunden abzurufen, wird das Token dies nicht autorisieren.

Was die Vorlage Deployt

Mit ein paar azd-Befehlen erhalten Sie:

Einen Backend-Agenten auf Microsoft Foundry (C#, Microsoft A2A und MCP SDKs)
Einen MCP-Server, der eine Beispiel-Portfolio-API exponiert
Curity Identity Server als Autorisierungsserver, zusammen mit Entra ID für die Authentifizierung
Externe und interne API-Gateways, die Token-Austausch und Audit-Logging verwalten
Bicep für die gesamte Azure-Infrastruktur: Container Apps, VNet, ACR, Azure AI Foundry, Key Vault, Azure SQL Database, Speicher

Das gesamte Muster ist inspizierbar und anpassbar.

Das Designprinzip, das Es Wert Ist, Übernommen zu Werden

Auch wenn Sie Curity nicht verwenden, ist das Muster übertragbar: Agenten sollten niemals permanenten API-Zugriff haben. Jede Aktion sollte ein kurzlebiges Token mit dem minimalen Scope verwenden, der für diesen spezifischen Aufruf benötigt wird, ausgestellt für die spezifische Agenten-Identität, mit den Claims, die die API benötigt, um Autorisierungsentscheidungen zu treffen.

Das hält gegen kreative Agenten, Fehler und Prompt-Injektion stand, wie es “Stellen Sie einfach sicher, dass der Agent keine schlechten Dinge tut” niemals tun wird.

Fazit

Sicherheitsmuster für KI-Agenten werden in der Industrie noch ausgearbeitet. Diese Vorlage ist eine der vollständigsten Referenzimplementierungen, die ich gesehen habe — sie deckt den tatsächlichen Autorisierungsfluss ab, nicht nur die Authentifizierung.

Originalbeitrag: Least privilege AI agents: A new azd template from Curity and Microsoft

Private Endpoints, VNets, NSGs — Aspire übernimmt jetzt das Netzwerk

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Ich habe dieses Szenario zu oft gesehen. Die App ist fertig. Die Demo ist großartig. Dann erscheint die Sicherheits-Checkliste: Speicher aus dem öffentlichen Internet nehmen, innerhalb eines VNets ausführen, ausgehende IPs für die Allowlist des Partners bereitstellen, nachweisen, dass nur die richtigen Subnetze mit den richtigen Diensten kommunizieren.

An diesem Punkt beginnen das Anwendungsmodell und das Infrastrukturmodell auseinanderzudriften, auf eine Art, die schmerzhaft zu pflegen ist.

Der neue Azure-Unternehmensnetzwerk-Support für Aspire adressiert dies direkt. Sie beschreiben die Netzwerkstruktur neben den Ressourcen, die sie verwenden, in Ihrem AppHost.

Die Bausteine

Hier ist, wofür jedes Azure-Netzwerkkonzept verwendet wird, destilliert:

Funktion	Verwenden Sie es wenn	Warum es wichtig ist
Virtuelles Netzwerk	Sie einen privaten Adressraum benötigen	Die Netzwerkgrenze für Subnetze, private Endpoints und Routing
Subnetz	Sie Workloads innerhalb des VNets trennen müssen	Jeder Teil des Systems erhält seinen eigenen Adressbereich und seine eigene Richtlinienoberfläche
Delegiertes Subnetz	Ein Plattformdienst (wie ACA) ein Subnetz verwalten muss	Ermöglicht dem Dienst, verwaltete Infrastruktur sicher in Ihrem VNet zu platzieren
NAT-Gateway	Sie vorhersagbare ausgehende öffentliche IPs benötigen	Stabile Adresse für Allowlists und Auditing
Privater Endpoint	Sie eine PaaS-Ressource privat erreichbar haben möchten	Platziert eine private IP für diesen Dienst in Ihrem VNet, entfernt öffentliche Exposition
NSG	Sie Regeln für Datenverkehr auf Subnetz-Ebene benötigen	Explizites Erlauben/Ablehnen für eingehenden und ausgehenden Datenverkehr pro Subnetz

Beschreibung im AppHost

Die wichtigste Änderung hier ist, dass Sie das Netzwerk zusammen mit den Ressourcen modellieren, die es verwenden, nicht in einer separaten Bicep-Datei, die mit der Zeit vom Anwendungsmodell abweicht.

Vom AppHost aus können Sie:

VNets und Subnetze mit AddVirtualNetwork() und AddSubnet() erstellen
Ein NAT-Gateway an Subnetze für stabile ausgehende IPs anhängen
Private Endpoints für Speicher, Key Vault, SQL und andere PaaS-Dienste erstellen
NSGs mit eingehenden und ausgehenden Sicherheitsregeln definieren
Netzwerksicherheitsperimeter für ressourcenübergreifende Richtlinien konfigurieren

Das Ergebnis ist, dass wenn Sie azd up ausführen, die Infrastruktur mit dem übereinstimmt, was das Anwendungsmodell sagt, dass es benötigt. Nicht das, was eine manuell gepflegte Vorlage sagt.

Warum das für echte Anwendungen wichtig ist

Einige Dinge, die erheblich einfacher werden, sobald das Netzwerk in Aspire modelliert ist:

Private Endpoints für Key Vault und Speicher — Sie beschreiben WithPrivateEndpoint() auf diesen Ressourcen, und Aspire übernimmt die DNS-Zonenkonfiguration und das Endpoint-Anhängen. Die App ändert sich nie.

Konsistente ausgehende IPs — fügen Sie ein NAT-Gateway zum entsprechenden Subnetz hinzu, und jede ausgehende Anfrage Ihrer App geht durch eine bekannte, stabile IP. Partner können sie allowlisten. Auditoren können sie nachverfolgen.

NSG-Regeln aus Code — anstatt durch das Portal zu klicken oder ein Bicep-Snippet zu pflegen, leben Ihre Sicherheitsregeln im AppHost neben den Ressourcen, die sie schützen.

Dies ist die Art von Integration, die Demos nicht aufregend macht, aber Produktionssysteme wartbar macht.

Fazit

Netzwerksicherheit, die spät im Projektlebenszyklus auftaucht, ist ein gelöstes Problem, wenn Sie sie von Anfang an zusammen mit der App modellieren. Der Unternehmensnetzwerk-Support von Aspire macht das möglich, ohne eine separate Infrastruktur-Spur zu benötigen.

Vollständige Details im ursprünglichen Beitrag: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Kubernetes-Unterstützung, Browser-Logs und die Aspireify-Funktion

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Fünf Wochen sind keine lange Zeit für ein Release, aber Aspire 13.3 fühlt sich nicht so an. Die Hauptpunkte sind bedeutsam: erstklassiges Kubernetes- und AKS-Deployment mit Helm, eine agentengestützte Onboarding-Funktion namens Aspireify, Browser-Log-Erfassung direkt im Dashboard und strukturierte Befehlsergebnisse. Dazu 45 neue Features, 134 Verbesserungen und 93 Fehlerbehebungen.

Kommen wir zu den Highlights.

Aspireify: Agentengestütztes Onboarding

Aspire zu einem bestehenden Projekt hinzuzufügen klingt einfach — AppHost einfügen, fertig. In der Praxis erfordert es viel Recherche: welche Ports wichtig sind, welche Umgebungsvariablen echte Abhängigkeiten sind, welche Docker-Compose-Dienste zu Aspire-Integrationen zugeordnet werden sollen.

Die neue Aspireify-Funktion gibt Ihrem Coding-Agenten einen geführten Workflow genau dafür. Wenn aspire init einen Skelett-AppHost erstellt, hilft die Aspireify-Funktion dem Agenten, das Repository zu inspizieren, zu verstehen, wie es bereits funktioniert, und den AppHost so zu verdrahten, dass er zur App passt — nicht umgekehrt.

Die Standardhaltung ist “Änderungen an Ihrem Code minimieren.” Wenn Ihre App bereits DATABASE_URL liest, mappt der Agent das mit WithEnvironment() anstatt Sie zu bitten, Ihre Konfiguration neu zu schreiben. Wenn ein Port fest codiert ist, teilt die Funktion dem Agenten mit, wann er ihn beibehalten soll.

Das ist die Art von KI-Tooling, die wirklich Zeit spart, anstatt mehr Arbeit zum Überprüfen zu generieren.

Erstklassiges Kubernetes- und AKS-Deployment

Dies stand schon eine Weile auf der Wunschliste. Aspire 13.3 liefert erstklassige Kubernetes- und AKS-Deployment-Unterstützung mit Helm. Sie können jetzt AKS direkt aus den Aspire-Tools als Deployment-Ziel wählen.

Für Teams, die bereits Produktionsworkloads auf AKS betreiben, schließt dies eine bedeutende Lücke. Ihr Aspire-App-Modell hat jetzt einen sauberen Weg von der lokalen Entwicklung zu Kubernetes ohne manuelle Helm-Chart-Erstellung.

Browser-Logs im Dashboard

Das ist eine jener Funktionen, die klein erscheinen, bis man ein Frontend-Problem debuggt.

Die neue WithBrowserLogs() API hängt eine verfolgte Browser-Ressource an jede endpoint-fähige Ressource an. Aspire startet Chromium mit einer privaten CDP-Pipe und streamt Konsolen-Logs, Netzwerkanfragen und Fehler direkt in den Ressourcen-Log-Stream:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

Der TypeScript AppHost unterstützt dasselbe:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Konsolen-Fehler, fehlgeschlagene Netzwerkanfragen, clientseitige Ausnahmen — alles im selben Dashboard sichtbar, wo Sie bereits Traces und Metriken beobachten. Kein Tab-Wechsel zu Browser DevTools mehr für die Grundlagen.

Strukturierte Befehlsergebnisse

Ressourcenbefehle haben ein bedeutsames Upgrade erhalten. Bisher gaben Befehle Erfolg/Misserfolg zurück. Jetzt geben sie strukturierte Ergebnisse zurück: Text, JSON oder Markdown, das durch das Modell, die Dashboard-Benutzeroberfläche, die CLI und die MCP-Tools fließt.

Das Dashboard verbindet all das mit einem neuen Benachrichtigungscenter im Header. Befehlsergebnisse erscheinen als zeitgestempelte Benachrichtigungen mit Markdown-Rendering und einer “Antwort anzeigen”-Aktion.

Das macht Ressourcenbefehle wirklich komposierbar. Eine Integration kann jetzt einen Befehl exponieren, der eine bedeutsame Ausgabe zurückgibt — wie eine Tunnel-URL — anstatt nur irgendwo den Zustand zu ändern.

Fazit

Aspire 13.3 ist das Upgrade wert, allein schon für die Kubernetes-Unterstützung. Die Browser-Logs und strukturierten Befehlsergebnisse fühlen sich wie die Art von Verbesserungen der Lebensqualität an, die sich in einem alltäglichen Entwicklungsworkflow schnell ansammeln.

Vollständige Versionshinweise: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 findet vom 11. bis 15. Mai 2026 im Barbican Centre in London statt. Die 3-tägige Kernkonferenz läuft von Dienstag bis Donnerstag, mit optionalen Ganztags-Workshops am Montag und Freitag.

Mit 78 Sessions und 14 Workshops ist dies eine der umfangreichsten Entwicklerkonferenzen in Europa.

Themen

Architektonisches Denken
Funktionaler Code in C# 13
Serverless-Design
Semantische KI
Azure Kubernetes Services
Lean DevOps Strategien
The Model Context Protocol (MCP)
Agentische KI in .NET
Refactoring des Monolithen
Schneller programmieren mit LLMs
Kryptographie in einer Post-Quanten-Welt
Local-First-Entwicklung

Speaker

Weltklasse-Lineup mit Kevlin Henney, Neal Ford, Sander Hoogendoorn, Andrew Clymer, Jacqui Read, Christian Weyer, Jeff Prosise, Jules May, Oliver Sturm und Raju Gandhi.

Tickets und Infos

98 % der SDD 2025-Teilnehmer bewerteten das Gesamterlebnis als gut, sehr gut oder exzellent.

Die Monkey Work der Migration mit Agentic Platform Engineering beseitigen

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

Removing the Monkey Work of Migration with Agentic Platform Engineering — eine Schritt-für-Schritt-Anleitung von Git-Ape (git agentic platform engineering tool), das ein echtes AWS-Terraform-Repo zu Azure migriert, mit Fokus auf Intent-Extraktion statt zeilenweiser Konvertierung.

Die Eingabe: contoso-migration

Die Quelle ist ein echtes Terraform-Projekt (contoso-migration), das eine Next.js-App auf AWS bereitstellt — EC2 für Compute, ALB für Load Balancing, S3 für Artefakte und IAM-Schlüssel für Identität. Kosten: ~34 $/Monat. Das Ziel ist nicht, dieselbe Infrastruktur auf Azure zu reproduzieren; es geht darum herauszufinden, was das Deployment eigentlich tun soll, und das mit nativen Azure-Diensten neu aufzubauen.

Schritt 1: Validierung und Authentifizierung

Git-Ape beginnt damit, alle erforderlichen CLI-Tools zu validieren — az, aws, gh, jq, git — und aktive Auth-Sessions zu bestätigen, bevor etwas angerührt wird. Keine Teilausführungen.

Schritt 2: Intent-Extraktion

Der Agent liest das gesamte Quell-Repository über die GitHub API und extrahiert den Deployment-Intent: Laufzeit (Node.js), Compute-Typ, Ingress-Muster, Artefakt-Handling, Identitätsmodell, Netzwerk und Monitoring. Dies ist der entscheidende Schritt — es wird ein semantisches Modell dessen erstellt, was das Deployment tut, nicht welche Terraform-Keywords es verwendet.

Schritt 3: Service-Mapping

AWS-Dienste werden auf Azure-Äquivalente abgebildet:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Integriertes App Service Load Balancing
IAM-Rollen/Schlüssel → Managed Identity
Terraform → Bicep + GitHub Actions

Schritt 4: Kritik-Agent

Vor der Ausgabegenerierung läuft ein Kritik-Agent und erkennt zwei blockierende Probleme:

Build-on-Startup-Antimuster — das ursprüngliche Terraform führte npm install && npm run build auf EC2 beim Start aus. Fix: In CI bauen, ein fertiges Artefakt deployen.
Unnötiger Blob Storage — S3 wurde für Artefakt-Staging verwendet, das mit korrektem CI/CD eliminiert werden könnte. Der Kritik-Agent hat es vollständig entfernt.

Schritt 5: Generierte Ausgabe

Das Ergebnis sind ~80 Zeilen Bicep statt der ursprünglichen 200+ Zeilen Terraform. Der Agent erstellte ein neues GitHub-Repo mit infra/main.bicep und .github/workflows/deploy.yml und entfernte alle AWS-spezifischen Dateien.

Vergleich der Sicherheitslage

Die Migration ergab auch eine bedeutende Sicherheitsverbesserung:

AWS-Original	Azure-Ausgabe
Nur HTTP	Nur HTTPS, TLS 1.2
SSH offen für 0.0.0.0/0	Keine SSH-Exposition
IAM-Zugriffsschlüssel	OIDC + Managed Identity
Kein Monitoring	Application Insights

Kosten: ~13 $/Monat vs. ursprüngliche 34 $/Monat.

Was dies von einem Syntax-Konverter unterscheidet

Der Kritik-Agent-Schritt ist das, was dies von einer mechanischen Übersetzung trennt. Er erkannte Muster, die auf AWS funktioniert hätten, aber auf Azure falsch wären — und korrigierte sie, anstatt sie zu replizieren. Die Ausgabe ist kein “AWS in Azure-Syntax”; es ist ein Azure-natives Deployment, das dasselbe Ziel sauberer erreicht.

Siehe die vollständige Anleitung für die vollständige Agent-Ablaufverfolgung und generierte Dateien.

SQL MCP Server auf Azure App Service — Ohne Container

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die Originalversion findest du hier.

Ehrlich gesagt: Jedes Mal, wenn ich “erfordert einen Container” in einem Tutorial lese, seufze ich innerlich. Container sind großartig — bis dein Team keine Container-Strategie hat und eine scheinbar einfache Funktion hinter Orchestrierungsaufwand steckt, den niemand eingeplant hatte.

Deshalb hat mich das hier aufhorchen lassen. Der SQL MCP Server läuft jetzt auf Azure App Service — ohne Docker, ohne Kubernetes, nur mit derselben Data API Builder (DAB)-Konfiguration, die deine SQL-Datenbank über MCP, REST und GraphQL bereitstellt.

Was ist der SQL MCP Server?

Kurzer Kontext, falls du ihn noch nicht kennst. Der SQL MCP Server sitzt zwischen deinem KI-Agenten und deiner SQL-Datenbank. Statt dem Agenten direkten Datenbankzugriff zu geben (was eine schreckliche Idee wäre), stellt er Tabellen und Views als Abstraktionsschicht bereit — Entitäten mit definierten Berechtigungen.

Er basiert auf Data API Builder, was bedeutet, dass eine einzige Konfigurationsdatei MCP und REST und GraphQL gleichzeitig bereitstellt. Dein Agent spricht mit dem MCP-Endpoint. Deine klassische Anwendung spricht mit REST oder GraphQL. Gleiche Config, gleiche Runtime, unterschiedliche Oberflächen.

Das ist wirklich nützlich. Du pflegst nicht zwei separate API-Schichten.

Das Container-Problem (und die Lösung)

Das ursprüngliche Bereitstellungsmodell für den SQL MCP Server waren Container. Das funktioniert in vielen Teams gut — aber nicht in allen. Viele .NET-Teams standardisieren auf Azure App Service oder VMs. Einen Container-Runtime nur für einen SQL-Endpoint zu benötigen, fügt Reibung hinzu, die niemand angefordert hat.

Das neue Walkthrough zeigt, wie man den Container komplett überspringt. Alles läuft mit einem dab start-Befehl, gehostet auf App Service als standardmäßiger .NET 8-Webprozess.

# Data API Builder installieren
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Konfiguration initialisieren
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Eine Entität hinzufügen
dab add products --source dbo.products --permissions "authenticated:*"

# App Service Auth-Provider konfigurieren
dab configure --runtime.host.authentication.provider AppService

# Server starten
dab start

Jetzt hast du MCP unter /mcp, REST und GraphQL aus demselben Prozess, und nichts läuft in einem Container.

Authentifizierung ohne geteilte API-Schlüssel

Das ist der Teil, den ich am meisten schätze. Bei der Bereitstellung auf App Service konfigurierst du Microsoft Entra ID als Authentifizierungsanbieter. Keine geteilten Geheimnisse in Konfigurationsdateien, keine API-Schlüssel, die rotiert werden müssen.

Der Connection String bleibt in einer App Service-Umgebungsvariable (nicht in dab-config.json), und der MCP-Endpoint ist durch Plattform-Authentifizierung geschützt. Wenn du bereits auf Entra ID in deinen Azure-Workloads ausgerichtet bist, fügt sich das natürlich ein.

Für die lokale Entwicklung wechselst du in den Simulator-Modus und STDIO-Transport. Vor dem Deployment wechselst du zurück in den AppService-Modus. Klar und explizit.

Bereitstellung auf App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Dann deployst du dein DAB-Projekt über deinen bevorzugten Code-Deployment-Weg. Das Entscheidende: Es ist ein Code-Deployment, kein Container-Deployment.

Warum das für .NET-Entwickler wichtig ist

Wenn du KI-Agenten in .NET baust, wird dein Agent irgendwann mit einer Datenbank kommunizieren müssen. Der SQL MCP Server bietet eine strukturierte Möglichkeit, das zu tun, ohne rohe Connection Strings preiszugeben.

Das vollständige Walkthrough findest du im Originalbeitrag und im Beispiel-Repository auf GitHub.

Fazit

Der SQL MCP Server auf App Service ist eine solide pragmatische Option für .NET-Teams, die ihren Agenten strukturierten SQL-Datenzugriff geben möchten, ohne eine Container-Strategie zu benötigen. Probier es aus — deine Agenten werden die saubere API-Oberfläche zu schätzen wissen.

SQL Server 2025 als Agent-Ready Datenbank: Sicherheit, Backup und MCP in einer Engine

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

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

Ich habe die Polyglot Tax Serie von Aditya Badramraju mit großem Interesse verfolgt. Teile 1-3 lieferten den Beweis für SQL Server 2025 als echte Multi-Modell-Datenbank. Teil 4 schließt die Serie mit den Teilen, die wirklich bestimmen, ob du dieser Architektur in Produktion vertrauen würdest.

Ein Sicherheitsmodell für alle Datenmodelle

Eine Row-Level Security Policy, die alle Datenmodelle abdeckt — relationale Tabellen, JSON-Events, Graph-Edges, Vektoren. Eine Policy, ein Audit, ein Nachweis.

Einheitliches Backup = Atomare Wiederherstellung

In einem polyglottes Stack bedeutet Point-in-Time Recovery fünf koordinierte Restore-Operationen und die Hoffnung, dass die Timestamps übereinstimmen. Mit einer Datenbank ist die Wiederherstellung per Definition atomar.

MCP-Integration: Agenten Ohne Hand-codierten Middleware

SQL Server 2025 unterstützt den SQL MCP Server direkt. Agenten rufen Tools auf, die Engine erzwingt Tenant-Isolierung und Column-Masking automatisch.

Fazit

Für .NET-Entwickler, die agenten-first Anwendungen auf Azure SQL bauen, verdient diese Architektur ernsthafte Überlegung. Originalpost von Aditya Badramraju: The Polyglot Tax – Part 4.

Azure SDK April 2026: AI Foundry 2.0 und Was .NET-Entwickler Wissen Sollten

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

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

Das April SDK-Release hat einiges, das Beachtung verdient — besonders wenn du mit AI Foundry, Cosmos DB in Java oder Infrastructure Provisioning aus .NET-Code arbeitest.

Azure.AI.Projects 2.0.0 — Breaking Changes, die Sinn machen

Das Azure.AI.Projects NuGet-Paket erreicht stabile 2.0.0 mit significanten Änderungen: Namespace-Splits für Evaluations und Memory, umbenannte Typen und konsistente Is*-Konvention für Booleans.

Cosmos DB Java: Kritischer Sicherheitsfix (RCE)

Der Java Cosmos DB Library 4.79.0 enthält einen kritischen Fix für eine Remote Code Execution Schwachstelle (CWE-502). Sofort updaten.

Neue Provisioning-Bibliotheken für .NET

Fazit

Das Highlight für .NET-Entwickler diesen Monat: Azure.AI.Projects 2.0.0 ist stabil. Originalpost: Azure SDK Release (April 2026).

Der Azure MCP Server ist jetzt ein .mcpb — Ohne Runtime Installieren

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

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

Weißt du, was an der Einrichtung von MCP-Servern lästig war? Du brauchtest eine Runtime. Node.js für die npm-Version, Python für pip/uvx, .NET SDK für die dotnet-Variante.

Der Azure MCP Server hat das gerade geändert. Er ist jetzt als .mcpb — ein MCP Bundle — verfügbar, und die Einrichtung ist Drag-and-Drop.

Was ist ein MCP Bundle?

Denk daran wie an eine VS Code-Erweiterung (.vsix) oder eine Browser-Erweiterung (.crx), aber für MCP-Server. Eine .mcpb-Datei ist ein eigenständiges ZIP-Archiv mit dem Server-Binary und allen Abhängigkeiten.

Installation

1. Bundle für deine Plattform herunterladen

Gehe auf die GitHub Releases-Seite und lade die .mcpb-Datei für dein OS und deine Architektur herunter. Stelle sicher, dass du die richtige wählst — osx-arm64 für Apple Silicon, win-x64 für Windows, usw.

2. In Claude Desktop installieren

Am einfachsten: Ziehe die .mcpb-Datei in das Claude Desktop-Fenster während du auf der Erweiterungsseite bist (☰ → Datei → Einstellungen → Erweiterungen). Serverdetails überprüfen, Installieren klicken, bestätigen. Fertig.

3. Bei Azure authentifizieren

az login

Das war’s. Der Azure MCP Server nutzt deine vorhandenen Azure-Anmeldeinformationen.

Was du damit machen kannst

Über 100 Azure-Service-Tools direkt von deinem KI-Client:

Cosmos DB, Storage, Key Vault, App Service, Foundry abfragen und verwalten
az CLI-Befehle für beliebige Aufgaben generieren
Bicep- und Terraform-Vorlagen erstellen

Erste Schritte

Download: GitHub Releases
Repository: aka.ms/azmcp
Docs: aka.ms/azmcp/docs

Siehe den vollständigen Beitrag.

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.

Foundry Toolboxes: Ein einziger Endpunkt für alle Agent-Tools

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion hier klicken.

Hier ist ein Problem, das banal klingt, bis man es selbst erlebt: Die Organisation baut mehrere KI-Agenten, jeder braucht Tools, und jedes Team verkabelt sie von Grund auf neu. Dieselbe Web-Search-Integration, dieselbe Azure AI Search-Konfiguration, dieselbe GitHub-MCP-Server-Verbindung — aber in einem anderen Repository, von einem anderen Team, mit anderen Credentials und ohne gemeinsame Governance.

Microsoft Foundry hat soeben Toolboxes in der Public Preview veröffentlicht — eine direkte Antwort auf dieses Problem.

Was ist eine Toolbox?

Eine Toolbox ist ein benanntes, wiederverwendbares Tool-Bundle, das man einmal in Foundry definiert und über einen einzigen MCP-kompatiblen Endpunkt bereitstellt. Jede Agent-Runtime, die MCP spricht, kann sie konsumieren — kein Lock-in bei Foundry Agents.

Das Versprechen ist einfach: build once, consume anywhere. Tools definieren, Authentifizierung zentral konfigurieren (OAuth passthrough, Entra Managed Identity), Endpunkt veröffentlichen. Jeder Agent, der diese Tools braucht, verbindet sich einmal und bekommt sie alle.

Die vier Säulen (zwei davon heute verfügbar)

Säule	Status	Was sie tut
Discover	Demnächst	Genehmigte Tools finden ohne manuelle Suche
Build	Heute verfügbar	Tools in ein wiederverwendbares Bundle kuratieren
Consume	Heute verfügbar	Ein MCP-Endpunkt stellt alle Tools bereit
Govern	Demnächst	Zentrale Auth + Observability für alle Tool-Calls

Praktisches Beispiel

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Dokumentation durchsuchen und auf GitHub-Issues reagieren.",
 tools=[
 {"type": "web_search", "description": "Öffentliche Dokumentation suchen"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Nach der Veröffentlichung liefert Foundry einen einheitlichen Endpunkt. Eine Verbindung, alle Tools.

Kein Lock-in bei Foundry Agents

Toolboxes werden in Foundry erstellt und verwaltet, aber die Konsumfläche ist das offene MCP-Protokoll. Sie können von Custom Agents mit Microsoft Agent Framework oder LangGraph, GitHub Copilot und anderen MCP-fähigen IDEs sowie jeder anderen MCP-Runtime genutzt werden.

Warum das jetzt wichtig ist

Die Multi-Agenten-Welle kommt in der Produktion an. Jeder neue Agent ist eine neue Fläche für duplizierte Konfiguration, veraltete Credentials und inkonsistentes Verhalten. Die Build + Consume-Grundlage reicht aus, um mit der Zentralisierung zu beginnen. Wenn die Govern-Säule kommt, hat man eine vollständig beobachtbare, zentral gesteuerte Tool-Schicht für die gesamte Agent-Flotte.

Fazit

Das ist noch früh — Public Preview, Python SDK zuerst, mit Discover und Govern noch ausstehend. Aber das Modell ist solide und das MCP-native Design bedeutet, dass es mit den Tools funktioniert, die man bereits aufbaut. Details im offiziellen Announcement.

azd + GitHub Copilot: KI-gestütztes Projekt-Setup und intelligente Fehlerbehandlung

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Die englische Originalversion findest du hier.

Du kennst diesen Moment, wenn du eine bestehende App in Azure deployen möchtest und plötzlich auf eine leere azure.yaml starrst und versuchst zu erinnern, ob deine Express-API Container Apps oder App Service verwenden sollte? Genau dieser Moment wird jetzt deutlich kürzer.

Die Azure Developer CLI (azd) integriert sich jetzt mit GitHub Copilot auf zwei sinnvolle Arten: KI-gestütztes Projekt-Scaffolding während azd init und intelligente Fehlerbehebung, wenn Deployments schiefgehen. Beide Funktionen bleiben vollständig im Terminal — genau dort, wo ich sie haben möchte.

Setup mit Copilot während azd init

Wenn du azd init ausführst, gibt es jetzt die Option “Set up with GitHub Copilot (Preview)”. Wähle sie aus, und Copilot analysiert deine Codebasis, um die azure.yaml, Infrastruktur-Templates und Bicep-Module zu generieren — basierend auf deinem tatsächlichen Code.

azd init
# Wähle: "Set up with GitHub Copilot (Preview)"

Voraussetzungen:

azd 1.23.11 oder neuer — prüfe mit azd version oder aktualisiere mit azd update
Aktives GitHub Copilot-Abonnement (Individual, Business oder Enterprise)
GitHub CLI (gh) — azd fragt bei Bedarf nach dem Login

Was ich dabei wirklich nützlich finde: Es funktioniert in beide Richtungen. Baust du von Grund auf neu? Copilot hilft dir, von Anfang an die richtigen Azure-Services einzurichten. Hast du eine bestehende App, die du schon länger deployen wolltest? Zeig Copilot auf sie, und er generiert die Konfiguration, ohne dass du irgendetwas umstrukturieren musst.

Was es wirklich macht

Angenommen, du hast eine Node.js Express-API mit PostgreSQL-Abhängigkeit. Statt manuell zwischen Container Apps und App Service zu entscheiden und dann Bicep von Grund auf zu schreiben, erkennt Copilot deinen Stack und generiert:

Eine azure.yaml mit den richtigen language-, host- und build-Einstellungen
Ein Bicep-Modul für Azure Container Apps
Ein Bicep-Modul für Azure Database for PostgreSQL

Vor jeder Änderung werden Vorab-Prüfungen durchgeführt — das Git-Arbeitsverzeichnis wird auf Sauberkeit geprüft, und MCP-Server-Tool-Zustimmung wird im Voraus eingeholt. Nichts passiert, ohne dass du genau weißt, was sich ändert.

Copilot-gestützte Fehlerbehebung

Deployment-Fehler sind unvermeidlich. Fehlende Parameter, Berechtigungsprobleme, SKU-Verfügbarkeitsprobleme — und die Fehlermeldung sagt dir selten das eine, was du wirklich wissen musst: wie du es behebst.

Ohne Copilot sieht die Schleife so aus: Fehler kopieren → Docs durchsuchen → drei irrelevante Stack-Overflow-Antworten lesen → einige az-CLI-Befehle ausführen → nochmal versuchen und hoffen. Mit Copilot, der in azd integriert ist, kollabiert diese Schleife. Wenn ein azd-Befehl fehlschlägt, bietet er sofort vier Optionen an:

Explain — Klartextbeschreibung, was schiefgelaufen ist
Guidance — Schritt-für-Schritt-Anweisungen zur Behebung
Diagnose and Guide — vollständige Analyse + Copilot wendet die Lösung an (mit deiner Genehmigung) + optionaler Retry
Skip — selbst lösen

Das Entscheidende: Copilot hat bereits Kontext über dein Projekt, den fehlgeschlagenen Befehl und die Fehlerausgabe. Seine Vorschläge sind spezifisch für deine Situation, keine generischen Docs.

Typische Fehler, bei denen das glänzt

Ressourcenanbieter nicht registriert:

ERROR: deployment failed: MissingSubscriptionRegistration:
The subscription is not registered to use namespace 'Microsoft.App'.

Das trifft jeden bei einem ersten Deployment in einem neuen Abonnement. Copilot kann den Provider registrieren und das Deployment automatisch neu starten.

SKU nicht verfügbar:

ERROR: deployment failed: SkuNotAvailable:
The requested VM size 'Standard_D2s_v3' is not available in location 'westus'.

Copilot erklärt, welche VM-Größe oder Region blockiert ist, und schlägt verfügbare Alternativen vor.

Speicherkontoname bereits vergeben:

ERROR: deployment failed: StorageAccountAlreadyTaken:
The storage account named 'myappstorage' is already taken.

Globale Eindeutigkeit erwischt jeden mindestens einmal. Copilot schlägt vor, deinen Umgebungsnamen oder ein zufälliges Suffix zu deinen Bicep-Parametern hinzuzufügen.

Standardverhalten konfigurieren

Wenn du immer die gleiche Option willst, überspringe den interaktiven Prompt:

azd config set copilot.errorHandling.category troubleshoot

Werte: explain, guidance, troubleshoot, fix, skip. Du kannst auch Auto-Fix und Retry aktivieren:

azd config set copilot.errorHandling.fix allow

Zurück zum interaktiven Modus jederzeit:

azd config unset copilot.errorHandling.category

Fazit

Das ist genau die Art von Copilot-Integration, die echten Mehrwert bringt. Probiere es aus, indem du azd update für die neueste Version ausführst, und verwende dann azd init für dein nächstes Projekt.

Den originalen Ankündigungsbeitrag findest du hier.

Deine KI-Experimente auf Azure verbrennen Geld — So behebst du das

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

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

Wenn du gerade KI-gestützte Apps auf Azure baust, ist dir wahrscheinlich etwas aufgefallen: Deine Cloud-Rechnung sieht anders aus als früher. Nicht nur höher — seltsamer. Sprunghaft. Schwer vorhersagbar.

Microsoft hat gerade einen großartigen Beitrag über Cloud-Kostenoptimierungsprinzipien, die immer noch wichtig sind veröffentlicht, und ehrlich gesagt könnte das Timing nicht besser sein. Denn KI-Workloads haben die Spielregeln bei den Kosten verändert.

Warum KI-Workloads anders zuschlagen

Hier ist die Sache. Traditionelle .NET-Workloads sind relativ vorhersagbar. Du kennst deinen App-Service-Tier, du kennst deine SQL-DTUs, du kannst die monatlichen Ausgaben ziemlich genau abschätzen. KI-Workloads? Nicht so sehr.

Du testest mehrere Modelle, um zu sehen, welches passt. Du fährst GPU-gestützte Infrastruktur für Fine-Tuning hoch. Du machst API-Aufrufe an Azure OpenAI, bei denen der Token-Verbrauch je nach Prompt-Länge und Benutzerverhalten stark variiert. Jedes Experiment kostet echtes Geld, und du führst vielleicht Dutzende durch, bevor du den richtigen Ansatz findest.

Diese Unvorhersehbarkeit macht Kostenoptimierung kritisch — nicht als Nachgedanke, sondern von Tag eins an.

Management vs. Optimierung — kenne den Unterschied

Eine Unterscheidung aus dem Artikel, die Entwickler meiner Meinung nach übersehen: Es gibt einen Unterschied zwischen Kosten-Management und Kosten-Optimierung.

Management bedeutet Tracking und Reporting. Du richtest Budgets in Azure Cost Management ein, bekommst Benachrichtigungen, siehst Dashboards. Das ist die Grundlage.

Optimierung ist da, wo du tatsächlich Entscheidungen triffst. Brauchst du wirklich diesen S3-Tier, oder würde S1 deine Last bewältigen? Steht diese Always-on-Compute-Instanz am Wochenende untätig herum? Könntest du Spot-Instanzen für deine Trainingsjobs verwenden?

Als .NET-Entwickler neigen wir dazu, uns auf den Code zu konzentrieren und die Infrastrukturentscheidungen dem „Ops-Team" zu überlassen. Aber wenn du auf Azure deployst, sind diese Entscheidungen auch deine Entscheidungen.

Was wirklich funktioniert

Basierend auf dem Artikel und meiner eigenen Erfahrung — das macht den Unterschied:

Wisse, was du ausgibst und wofür. Tagge deine Ressourcen. Im Ernst. Wenn du nicht erkennen kannst, welches Projekt oder Experiment dein Budget auffrisst, kannst du nichts optimieren. Azure Cost Management mit ordentlichem Tagging ist dein bester Freund.

Setze Leitplanken, bevor du experimentierst. Nutze Azure Policy, um teure SKUs in Dev/Test-Umgebungen einzuschränken. Setze Ausgabenlimits für deine Azure-OpenAI-Deployments. Warte nicht, bis die Rechnung kommt, um festzustellen, dass jemand ein GPU-Cluster über das Wochenende laufen gelassen hat.

Dimensioniere kontinuierlich richtig. Die VM, die du beim Prototyping ausgewählt hast? Die ist wahrscheinlich falsch für die Produktion. Azure Advisor gibt dir Empfehlungen — schau sie dir tatsächlich an. Überprüfe monatlich, nicht jährlich.

Denke an den Lebenszyklus. Entwicklungsressourcen sollten heruntergefahren werden. Testumgebungen müssen nicht 24/7 laufen. Nutze Auto-Shutdown-Richtlinien. Für KI-Workloads im Speziellen solltest du Serverless-Optionen in Betracht ziehen, bei denen du pro Ausführung zahlst, statt Compute warmzuhalten.

Miss den Wert, nicht nur die Kosten. Das vergisst man leicht. Ein Modell, das mehr kostet, aber deutlich bessere Ergebnisse liefert, könnte die richtige Wahl sein. Das Ziel ist nicht, am wenigsten auszugeben — sondern klug auszugeben.

Das Fazit

Cloud-Kostenoptimierung ist kein einmaliges Aufräumen. Es ist eine Gewohnheit. Und da KI-Workloads die Ausgaben unvorhersehbarer machen als je zuvor, erspart dir der frühe Aufbau dieser Gewohnheit schmerzhafte Überraschungen später.

Wenn du ein .NET-Entwickler bist, der auf Azure baut, fang an, deine Cloud-Rechnung wie deinen Code zu behandeln — überprüfe sie regelmäßig, refaktoriere, wenn es unordentlich wird, und deploye nie, ohne zu verstehen, was es dich kosten wird.

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.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 findet am 18. April 2026 im Kinépolis Diversia in Alcobendas, Madrid statt. Es ist das größte Community-Azure-Event in Spanien, mit 38 Speakern auf 3 parallelen Tracks zu KI-Agenten, Azure-Netzwerken, Cosmos DB, Fabric, IoT, Sicherheit und vielem mehr.

Das Event läuft von 08:30 bis 18:30 und beinhaltet Keynote, Kaffeepausen, Mittagessen und eine Abschluss-Q&A-Session.

Highlights der Agenda

Domando Agentes de IA: Governance, Tools und APIs mit Azure AI Foundry und Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: Multi-Agenten-Systeme in Aktion
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Tickets

Die Anmeldung erfolgt als symbolische Spende — der gesamte Ticketpreis geht direkt an Plan International für Kinderrechte und Gleichstellung weltweit. Begrenzte Kapazität, also sicher dir rechtzeitig einen Platz.

Azure Tour 2026

Neben Madrid umfasst die Global Azure Tour 2026 auch Stationen in Zaragoza, Teneriffa und Sevilla.

Azure MCP Tools sind jetzt in Visual Studio 2022 integriert — Keine Erweiterung erforderlich

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion hier klicken.

Wenn du die Azure MCP Tools in Visual Studio über die separate Erweiterung benutzt hast, kennst du das Spiel — VSIX installieren, neustarten, hoffen dass nichts kaputtgeht, Versionskonflikte managen. Diese Reibung ist vorbei.

Yun Jung Choi hat angekündigt, dass Azure MCP Tools jetzt direkt als Teil der Azure-Entwicklungsworkload in Visual Studio 2022 ausgeliefert werden. Keine Erweiterung. Kein VSIX. Kein Neustart-Tanz.

Was das konkret bedeutet

Ab Visual Studio 2022 Version 17.14.30 ist der Azure MCP Server in der Azure-Entwicklungsworkload enthalten. Wenn du diese Workload bereits installiert hast, musst du ihn nur in GitHub Copilot Chat aktivieren und fertig.

Über 230 Tools für 45 Azure-Dienste — direkt aus dem Chat-Fenster zugänglich. Storage Accounts auflisten, eine ASP.NET Core App deployen, App Service Probleme diagnostizieren, Log Analytics abfragen — alles ohne einen Browser-Tab zu öffnen.

Warum das wichtiger ist als es klingt

Die Sache mit Entwickler-Tooling ist: Jeder zusätzliche Schritt ist Reibung, und Reibung tötet die Akzeptanz. MCP als separate Erweiterung bedeutete Versionskonflikte, Installationsfehler und eine weitere Sache, die aktuell gehalten werden musste. Die Integration in die Workload bedeutet:

Ein einziger Update-Pfad über den Visual Studio Installer
Kein Versionsabweichung zwischen der Erweiterung und der IDE
Immer aktuell — der MCP Server wird mit den regulären VS-Releases aktualisiert

Für Teams, die auf Azure standardisieren, ist das ein großer Gewinn. Du installierst die Workload einmal, aktivierst die Tools, und sie sind in jeder Sitzung verfügbar.

Was du damit machen kannst

Die Tools decken den gesamten Entwicklungslebenszyklus über Copilot Chat ab:

Lernen — frage nach Azure-Diensten, Best Practices, Architekturmustern
Entwerfen & Entwickeln — erhalte Service-Empfehlungen, konfiguriere App-Code
Deployen — provisioniere Ressourcen und deploye direkt aus der IDE
Fehlerbehebung — frage Logs ab, prüfe den Ressourcenzustand, diagnostiziere Produktionsprobleme

Ein schnelles Beispiel — tippe das in Copilot Chat:

List my storage accounts in my current subscription.

Copilot ruft die Azure MCP Tools im Hintergrund auf, fragt deine Subscriptions ab und liefert eine formatierte Liste mit Namen, Standorten und SKUs. Kein Portal nötig.

So aktivierst du es

Update auf Visual Studio 2022 17.14.30 oder höher
Stelle sicher, dass die Azure development Workload installiert ist
Öffne GitHub Copilot Chat
Klicke auf den Select tools Button (das Schraubenschlüssel-Symbol)
Schalte Azure MCP Server ein

Das war’s. Es bleibt über Sitzungen hinweg aktiviert.

Ein Hinweis

Die Tools sind standardmäßig deaktiviert — du musst sie manuell einschalten. Und VS 2026-spezifische Tools sind in VS 2022 nicht verfügbar. Die Verfügbarkeit der Tools hängt auch von deinen Azure-Subscription-Berechtigungen ab, genau wie im Portal.

Das große Bild

Das ist Teil eines klaren Trends: MCP wird zum Standard, um Cloud-Tools in Entwickler-IDEs verfügbar zu machen. Wir haben bereits das stabile Release von Azure MCP Server 2.0 und MCP-Integrationen in VS Code und anderen Editoren gesehen. Die Integration in Visual Studios Workload-System ist die natürliche Weiterentwicklung.

Für uns .NET-Entwickler, die in Visual Studio leben, entfällt damit ein weiterer Grund, zum Azure Portal zu wechseln. Und ehrlich gesagt, je weniger Tab-Wechsel, desto besser.

Aspire 13.2 bringt MongoDB EF Core und Azure Data Lake — Zwei Integrationen, die einen Blick wert sind

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Aspire 13.2 ist gerade erschienen mit zwei neuen Datenbank-Integrationen, die eure Aufmerksamkeit verdienen: MongoDB Entity Framework Core und Azure Data Lake Storage. Wenn ihr EF Core mit MongoDB in einer Aspire-App nutzen wolltet, oder Data-Lake-Workloads mit ordentlichem Service Discovery anbinden müsst, liefert dieses Release beides.

MongoDB trifft EF Core in Aspire

Das ist die Integration, auf die ich mich am meisten freue. Aspire hat MongoDB schon länger unterstützt, aber es war immer der rohe Treiber — kein EF Core, kein DbContext, keine LINQ-Abfragen gegen eure Dokumente. Jetzt bekommt ihr die volle EF-Core-Erfahrung mit MongoDB, plus Aspires automatische Health Checks und Service Discovery.

Die Einrichtung folgt dem typischen Aspire-Muster. Im AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Dann fügt ihr in eurem konsumierenden Projekt die EF Core Integration hinzu:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Und registriert euren DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Ab da ist es Standard-EF-Core. Definiert eure Entities, nutzt euren DbContext wie mit jedem anderen Provider. Die Integration übernimmt Connection Pooling, OpenTelemetry-Traces und Health Checks im Hintergrund.

Für .NET-Entwickler, die MongoDB mit dem rohen Treiber genutzt und Connection Strings manuell verdrahtet haben, ist das ein schönes Upgrade. Ihr bekommt die volle EF-Core-Abstraktion, ohne Aspires Service Discovery zu verlieren.

Azure Data Lake Storage ist mit dabei

Die zweite große Neuerung ist eine Azure Data Lake Storage (ADLS) Integration. Wenn ihr Datenpipelines, ETL-Prozesse oder Analyseplattformen baut, könnt ihr Data-Lake-Ressourcen jetzt genauso anbinden wie jede andere Aspire-Abhängigkeit.

Im AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Im konsumierenden Projekt:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Keine manuelle Connection-String-Verwaltung, keine Credential-Suche. Aspire provisioniert Ressourcen und injiziert sie. Für diejenigen von uns, die cloud-native .NET-Apps bauen, die sowohl operative Daten als auch Analyse-Workloads berühren, fühlt sich der Data Lake damit wie ein erstklassiger Bürger im Aspire-Modell an.

Die kleinen Verbesserungen, die zählen

Neben den Hauptfeatures gibt es ein paar Verbesserungen, die erwähnenswert sind:

MongoDB Connection String Fix — der Schrägstrich vor dem Datenbanknamen wird jetzt korrekt behandelt. Falls ihr einen Workaround dafür hattet, könnt ihr ihn entfernen
SQL Server Exports — Aspire.Hosting.SqlServer exportiert jetzt zusätzliche Serverkonfigurationsoptionen für feingranulare Kontrolle
Emulator-Updates — ServiceBus Emulator 2.0.0, App Configuration Emulator 1.0.2, und der Preview-Emulator von CosmosDB enthält jetzt einen Readiness Check
Azure Managed Redis — nutzt jetzt standardmäßig rediss:// (Redis Secure), sodass Verbindungen von Haus aus verschlüsselt sind

Der letzte Punkt ist subtil, aber wichtig — verschlüsseltes Redis als Standard bedeutet eine Sache weniger, die man in Produktion konfigurieren muss.

Fazit

Aspire 13.2 ist ein inkrementelles Release, aber die MongoDB EF Core und Data Lake Integrationen füllen echte Lücken. Wenn ihr auf ordentlichen EF-Core-Support mit MongoDB in Aspire gewartet habt, oder Data Lake als erstklassige Abhängigkeit braucht, upgradet auf 13.2 und probiert es aus. Der aspire add Befehl erstellt alles, was ihr braucht.

Lest die vollständigen Release Notes für mehr Details und schaut euch die Integrationsgalerie für die komplette Liste an.

azd update — Ein Befehl für alle deine Paketmanager

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Kennst du diese Meldung „Eine neue Version von azd ist verfügbar", die alle paar Wochen auftaucht? Die, die du wegklickst, weil du dich nicht mehr erinnerst, ob du azd über winget, Homebrew oder dieses curl-Skript installiert hast, das du vor sechs Monaten ausgeführt hast? Ja, das ist jetzt endlich gelöst.

Microsoft hat azd update veröffentlicht — ein einziger Befehl, der die Azure Developer CLI auf die neueste Version aktualisiert, unabhängig davon, wie du sie ursprünglich installiert hast. Windows, macOS, Linux — egal. Ein Befehl.

So funktioniert’s

azd update

Das war’s. Wenn du frühen Zugang zu neuen Features möchtest, kannst du auf den täglichen Insiders-Build wechseln:

azd update --channel daily
azd update --channel stable

Der Befehl erkennt deine aktuelle Installationsmethode und nutzt im Hintergrund den passenden Update-Mechanismus. Kein „Moment, habe ich auf diesem Rechner winget oder choco benutzt?" mehr.

Der kleine Haken

azd update ist ab Version 1.23.x verfügbar. Wenn du eine ältere Version hast, musst du ein letztes manuelles Update mit deiner ursprünglichen Installationsmethode durchführen. Danach übernimmt azd update alles Weitere.

Prüfe deine aktuelle Version mit azd version. Falls du eine Neuinstallation brauchst, hilft dir die Installationsdokumentation weiter.

Warum das wichtig ist

Es ist eine kleine Verbesserung der Lebensqualität, aber für diejenigen von uns, die azd täglich zum Deployen von KI-Agenten und Aspire-Apps auf Azure nutzen, bedeutet auf dem neuesten Stand zu sein weniger „dieser Bug war schon in der letzten Version behoben"-Momente. Eine Sache weniger, über die man nachdenken muss.

Lies die vollständige Ankündigung und Jon Gallants tiefergehende Analyse für mehr Kontext.

Azure Smart Tier ist GA — Automatische Kostenoptimierung für Blob Storage ohne Lifecycle-Regeln

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du jemals Zeit damit verbracht hast, Azure Blob Storage Lifecycle-Richtlinien zu optimieren und dann zugesehen hast, wie sie auseinanderfallen, sobald sich die Zugriffsmuster geändert haben, ist das hier für dich. Microsoft hat gerade die allgemeine Verfügbarkeit von Smart Tier für Azure Blob und Data Lake Storage angekündigt — eine vollständig verwaltete Tiering-Funktion, die Objekte automatisch zwischen Hot-, Cool- und Cold-Tiers basierend auf der tatsächlichen Nutzung verschiebt.

Was Smart Tier tatsächlich macht

Das Konzept ist einfach: Smart Tier wertet kontinuierlich die letzte Zugriffszeit jedes Objekts in deinem Speicherkonto aus. Häufig abgerufene Daten bleiben in Hot, inaktive Daten werden nach 30 Tagen nach Cool verschoben und nach weiteren 60 Tagen nach Cold. Wenn auf die Daten erneut zugegriffen wird, werden sie sofort wieder auf Hot hochgestuft. Der Zyklus beginnt von vorne.

Keine Lifecycle-Regeln zu konfigurieren. Keine Vorhersagen von Zugriffsmustern. Kein manuelles Tuning.

Während der Preview berichtete Microsoft, dass über 50% der von Smart Tier verwalteten Kapazität automatisch in kühlere Tiers verschoben wurde — basierend auf tatsächlichen Zugriffsmustern. Das ist eine deutliche Kostenreduzierung für große Speicherkonten.

Warum das für .NET-Entwickler wichtig ist

Wenn du Anwendungen baust, die Logs, Telemetrie, Analysedaten oder irgendeine Art von wachsendem Datenbestand erzeugen — und mal ehrlich, wer tut das nicht? — summieren sich die Speicherkosten schnell. Der traditionelle Ansatz war, Lifecycle-Management-Richtlinien zu schreiben, sie zu testen und dann neu anzupassen, wenn sich die Zugriffsmuster deiner App geändert haben. Smart Tier eliminiert diesen gesamten Workflow.

Einige praktische Szenarien, in denen das hilft:

Anwendungstelemetrie und Logs — Hot beim Debuggen, nach ein paar Wochen kaum noch abgerufen
Datenpipelines und ETL-Ausgaben — während der Verarbeitung stark genutzt, danach meistens Cold
Benutzergenerierte Inhalte — aktuelle Uploads sind Hot, ältere Inhalte kühlen allmählich ab
Backup- und Archivdaten — gelegentlich für Compliance abgerufen, meistens inaktiv

Einrichtung

Smart Tier zu aktivieren ist eine einmalige Konfiguration:

Neue Konten: Wähle Smart Tier als Standard-Zugangstier während der Erstellung des Speicherkontos (zonale Redundanz erforderlich)
Bestehende Konten: Wechsle den Blob-Zugangstier von deiner aktuellen Standardeinstellung zu Smart Tier

Objekte kleiner als 128 KiB bleiben in Hot und verursachen keine Überwachungsgebühr. Für alles andere zahlst du die Standard-Kapazitätstarife für Hot/Cool/Cold — ohne Tier-Übergangsgebühren, ohne Gebühren für vorzeitige Löschung und ohne Datenabrufkosten. Eine monatliche Überwachungsgebühr pro Objekt deckt die Orchestrierung ab.

Der Kompromiss, den du kennen solltest

Die Tiering-Regeln von Smart Tier sind statisch (30 Tage → Cool, 90 Tage → Cold). Wenn du benutzerdefinierte Schwellenwerte brauchst — zum Beispiel nach 7 Tagen für eine bestimmte Workload nach Cool verschieben — sind Lifecycle-Regeln weiterhin der richtige Weg. Und mische nicht beides: Vermeide es, Lifecycle-Regeln auf von Smart Tier verwaltete Objekte anzuwenden, da sie in Konflikt geraten können.

Fazit

Das ist nicht revolutionär, aber es löst ein echtes operatives Problem. Wenn du wachsende Blob-Storage-Konten verwaltest und es leid bist, Lifecycle-Richtlinien zu pflegen, aktiviere Smart Tier und lass Azure sich darum kümmern. Es ist heute in fast allen zonalen Public-Cloud-Regionen verfügbar.

Wo solltest du deine KI-Agenten auf Azure hosten? Ein praktischer Entscheidungsleitfaden

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Wenn du gerade KI-Agenten mit .NET baust, hast du wahrscheinlich etwas bemerkt: Es gibt viele Möglichkeiten, sie auf Azure zu hosten. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — und alle klingen vernünftig, bis du tatsächlich einen auswählen musst. Microsoft hat gerade einen umfassenden Leitfaden zum Azure KI-Agenten-Hosting veröffentlicht, der das klärt, und ich möchte ihn aus der praktischen Perspektive eines .NET-Entwicklers aufschlüsseln.

Die sechs Optionen auf einen Blick

So würde ich die Landschaft zusammenfassen:

Option	Am besten für	Du verwaltest
Container Apps	Volle Container-Kontrolle ohne K8s-Komplexität	Observability, State, Lifecycle
AKS	Enterprise-Compliance, Multi-Cluster, Custom Networking	Alles (das ist der Punkt)
Azure Functions	Event-getriebene, kurzlebige Agenten-Tasks	Kaum etwas — echtes Serverless
App Service	Einfache HTTP-Agenten, vorhersehbarer Traffic	Deployment, Scaling-Config
Foundry Agents	Code-optionale Agenten über Portal/SDK	Fast nichts
Foundry Hosted Agents	Custom-Framework-Agenten mit verwalteter Infra	Nur dein Agenten-Code

Die ersten vier sind General-Purpose Compute — du kannst Agenten darauf ausführen, aber sie wurden nicht dafür entwickelt. Die letzten zwei sind agenten-nativ: Sie verstehen Konversationen, Tool-Aufrufe und Agenten-Lifecycles als First-Class-Konzepte.

Foundry Hosted Agents — der Sweet Spot für .NET-Agenten-Entwickler

Das hat meine Aufmerksamkeit geweckt. Foundry Hosted Agents sitzen genau in der Mitte: Du bekommst die Flexibilität, deinen eigenen Code auszuführen (Semantic Kernel, Agent Framework, LangGraph — was auch immer), aber die Plattform kümmert sich um Infrastruktur, Observability und Konversationsmanagement.

Das Schlüsselstück ist der Hosting Adapter — eine dünne Abstraktionsschicht, die dein Agenten-Framework mit der Foundry-Plattform verbindet. Für Microsoft Agent Framework sieht das so aus:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Das ist deine gesamte Hosting-Geschichte. Der Adapter übernimmt Protokollübersetzung, Streaming über Server-Sent Events, Konversationsverlauf und OpenTelemetry-Tracing — alles automatisch. Keine Custom Middleware, kein manuelles Plumbing.

Deployment ist wirklich einfach

Ich habe vorher Agenten auf Container Apps deployed und es funktioniert, aber man schreibt am Ende viel Glue-Code für State Management und Observability. Mit Hosted Agents und azd sieht das Deployment so aus:

# KI-Agenten-Extension installieren
azd ext install azure.ai.agents

# Von einer Vorlage initialisieren
azd ai agent init

# Bauen, pushen, deployen — fertig
azd up

Dieses einzelne azd up baut deinen Container, pusht ihn zu ACR, provisioniert das Foundry-Projekt, deployed Model-Endpoints und startet deinen Agenten. Fünf Schritte in einem Befehl zusammengefasst.

Integriertes Konversationsmanagement

Das ist der Teil, der in der Produktion am meisten Zeit spart. Anstatt deinen eigenen Konversations-State-Store zu bauen, handhaben Hosted Agents das nativ:

# Eine persistente Konversation erstellen
conversation = openai_client.conversations.create()

# Erste Runde
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Zweite Runde — Kontext bleibt erhalten
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Kein Redis. Kein Cosmos DB Session Store. Keine Custom Middleware für Nachrichtenserialisierung. Die Plattform kümmert sich einfach darum.

Mein Entscheidungsframework

Nachdem ich alle sechs Optionen durchgegangen bin, hier mein schnelles mentales Modell:

Brauchst du null Infrastruktur? → Foundry Agents (Portal/SDK, keine Container)
Hast du Custom-Agenten-Code, willst aber verwaltetes Hosting? → Foundry Hosted Agents
Brauchst du event-getriebene, kurzlebige Agenten-Tasks? → Azure Functions
Brauchst du maximale Container-Kontrolle ohne K8s? → Container Apps
Brauchst du strikte Compliance und Multi-Cluster? → AKS
Hast du einen einfachen HTTP-Agenten mit vorhersehbarem Traffic? → App Service

Für die meisten .NET-Entwickler, die mit Semantic Kernel oder Microsoft Agent Framework bauen, sind Hosted Agents wahrscheinlich der richtige Startpunkt. Du bekommst Scale-to-Zero, integriertes OpenTelemetry, Konversationsmanagement und Framework-Flexibilität — ohne Kubernetes zu verwalten oder deinen eigenen Observability-Stack aufzubauen.

Zum Abschluss

Die Agenten-Hosting-Landschaft auf Azure reift schnell. Wenn du heute ein neues KI-Agenten-Projekt startest, würde ich Foundry Hosted Agents ernsthaft in Betracht ziehen, bevor du aus Gewohnheit zu Container Apps oder AKS greifst. Die verwaltete Infrastruktur spart echte Zeit, und das Hosting-Adapter-Pattern lässt dich deine Framework-Wahl behalten.

Schau dir den vollständigen Leitfaden von Microsoft und das Foundry Samples Repo für funktionierende Beispiele an.

Agent Skills in .NET sind jetzt richtig flexibel

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion hier klicken.

Wenn ihr Agenten mit dem Microsoft Agent Framework baut, kennt ihr den Ablauf: Skills definieren, in einen Provider einbinden und den Agenten entscheiden lassen, welchen er aufruft. Neu ist wie ihr diese Skills erstellt — und der Flexibilitätssprung ist erheblich.

Das neueste Update führt drei verschiedene Authoring-Patterns für Agent Skills ein: dateibasiert, klassenbasiert und inline-codedefiniert. Alle drei werden über einen einzigen AgentSkillsProviderBuilder verbunden, sodass ihr sie ohne Routing-Logik oder speziellen Glue-Code mischen könnt. Ich zeige euch jedes Pattern und wann ihr es einsetzen solltet.

Dateibasierte Skills: der Einstiegspunkt

Dateibasierte Skills sind genau das, wonach sie klingen — ein Verzeichnis auf der Festplatte mit einer SKILL.md-Datei, optionalen Scripts und Referenzdokumenten. Die einfachste Art, eurem Agenten neue Fähigkeiten zu geben:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

Das SKILL.md-Frontmatter deklariert den Skill-Namen und die Beschreibung, und der Instruktionsabschnitt sagt dem Agenten, wie er Scripts und Referenzen nutzen soll:

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Dann verbindet ihr es mit SubprocessScriptRunner.RunAsync für die Script-Ausführung:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

Der Agent entdeckt den Skill automatisch und ruft das Provisioning-Script auf, wenn er den Kontostatus prüfen muss. Sauber und einfach.

Klassenbasierte Skills: per NuGet ausliefern

Hier wird es für Teams interessant. Klassenbasierte Skills leiten von AgentClassSkill<T> ab und verwenden Attribute wie [AgentSkillResource] und [AgentSkillScript], damit das Framework alles per Reflection entdeckt:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Das Schöne daran: Ein Team kann das als NuGet-Paket verpacken. Ihr fügt es eurem Projekt hinzu, steckt es in den Builder und es funktioniert neben euren dateibasierten Skills ohne Koordination:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Beide Skills erscheinen im System-Prompt des Agenten. Der Agent entscheidet basierend auf dem Gespräch, welchen er nutzt — kein Routing-Code nötig.

Inline Skills: die schnelle Brücke

Kennt ihr das, wenn ein anderes Team genau den Skill baut, den ihr braucht, aber erst im nächsten Sprint fertig wird? AgentInlineSkill ist eure Brücke:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Fügt ihn genauso wie die anderen zum Builder hinzu:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

Wenn das NuGet-Paket irgendwann erscheint, tauscht ihr den Inline-Skill gegen die klassenbasierte Version aus. Der Agent merkt den Unterschied nicht.

Inline Skills sind aber nicht nur für Brücken. Sie sind auch die richtige Wahl, wenn ihr Skills dynamisch zur Laufzeit generieren müsst — denkt an einen Skill pro Geschäftsbereich aus einer Konfiguration geladen — oder wenn ein Script lokalen State erfassen muss, der nicht in einen DI-Container gehört.

Script-Genehmigung: Mensch in der Schleife

Für uns .NET-Entwickler, die Produktionsagenten bauen, ist das der Teil, der Deployment-Gespräche wirklich freischaltet. Manche Scripts haben echte Konsequenzen — jemanden in Benefits einschreiben, Produktionsinfrastruktur abfragen. Aktiviert UseScriptApproval und der Agent pausiert vor jeder Script-Ausführung:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Wenn der Agent ein Script ausführen will, gibt er stattdessen eine Genehmigungsanfrage zurück. Eure App sammelt die Entscheidung — genehmigen oder ablehnen — und der Agent fährt entsprechend fort. In regulierten Umgebungen ist das der Unterschied zwischen “wir können das deployen” und “die Rechtsabteilung sagt nein.”

Warum diese Kombination wichtig ist

Die echte Stärke liegt nicht in einem einzelnen Authoring-Pattern — sondern in der Komposition. Ihr könnt:

Klein anfangen mit einem dateibasierten Skill, die Instruktionen iterieren und ohne C# veröffentlichen
Wiederverwendbare Skills als NuGet-Pakete ausliefern, die andere Teams mit einer Zeile hinzufügen können
Lücken überbrücken mit Inline Skills, wenn ihr etwas jetzt braucht
Gemeinsame Skill-Verzeichnisse filtern mit Predicates, damit euer Agent nur das lädt, was er soll
Menschliche Aufsicht hinzufügen für Scripts, die Produktionssysteme berühren

All das wird über AgentSkillsProviderBuilder zusammengesetzt. Kein spezielles Routing, keine bedingte Logik, keine Skill-Typ-Prüfungen.

Zum Abschluss

Agent Skills in .NET haben jetzt ein wirklich flexibles Authoring-Modell. Ob ihr ein Solo-Entwickler seid, der mit dateibasierten Skills einen Prototyp skizziert, oder ein Enterprise-Team, das verpackte Fähigkeiten per NuGet ausliefert — die Patterns passen. Und der Script-Genehmigungsmechanismus macht es produktionsreif für Umgebungen, in denen ihr diesen menschlichen Checkpoint braucht.

Schaut euch die Original-Ankündigung an, die Agent Skills Dokumentation auf Microsoft Learn und die .NET-Beispiele auf GitHub zum Loslegen.

Azure MCP Server 2.0 ist da — Self-Hosted Agentic Cloud Automation ist Realität

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

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Falls du in letzter Zeit mit MCP und Azure etwas aufgebaut hast, weißt du wahrscheinlich schon, dass die lokale Erfahrung gut funktioniert. MCP-Server einstöpseln, deinen KI-Agenten mit Azure-Ressourcen kommunizieren lassen, weitermachen. Aber sobald du diese Einrichtung teamübergreifend teilen musst? Da wird es kompliziert.

Nicht mehr. Azure MCP Server hat gerade 2.0 Stable erreicht, und die Hauptfunktion ist genau das, wofür Enterprise-Teams gefragt haben: Self-Hosted Remote MCP Server Support.

Was ist Azure MCP Server?

Kleine Auffrischung. Azure MCP Server implementiert die Model Context Protocol-Spezifikation und macht Azure-Funktionen als strukturierte, auffindbare Tools verfügbar, die KI-Agenten aufrufen können. Denk daran als standardisierte Brücke zwischen deinem Agenten und Azure — Bereitstellung, Deployment, Monitoring, Diagnostik, alles über eine einheitliche Schnittstelle.

Die Zahlen sprechen für sich: 276 MCP Tools über 57 Azure-Dienste. Das ist umfangreiche Unterstützung.

Das Wichtigste: Self-Hosted Remote Deployments

Hier ist die Sache. MCP lokal auf deiner Maschine zu betreiben ist okay für Entwicklung und Experimente. Aber in einem echten Team-Szenario brauchst du:

Gemeinsamer Zugriff für Entwickler und interne Agent-Systeme
Zentralisierte Konfiguration (Mandantenkontext, Abonnement-Standards, Telemetrie)
Enterprise-Netzwerk- und Richtliniengrenzen
Integration in CI/CD-Pipelines

Azure MCP Server 2.0 adressiert das alles. Du kannst es als zentral verwalteten internen Service mit HTTP-basiertem Transport, ordentlicher Authentifizierung und konsistenter Governance bereitstellen.

Für die Authentifizierung hast du zwei solide Optionen:

Managed Identity — wenn neben Microsoft Foundry betrieben
On-Behalf-Of (OBO) Flow — OpenID Connect Delegation, die Azure APIs mit dem Kontext des angemeldeten Benutzers aufruft

Dieser OBO-Flow ist besonders interessant für uns .NET-Entwickler. Das bedeutet, dass deine Agentic Workflows mit den eigentlichen Berechtigungen des Benutzers arbeiten können, nicht mit einem überberechtigten Service-Account. Principle of Least Privilege, gleich eingebaut.

Security Hardening

Das ist nicht nur ein Feature-Release — es ist auch eines für Sicherheit. Das 2.0-Release fügt hinzu:

Stärkere Endpoint-Validierung
Schutz gegen Injection-Muster in Query-orientierten Tools
Strengere Isolationskontrollen für Dev-Umgebungen

Falls du MCP als gemeinsamen Service bereitstellen willst, zählen diese Schutzmaßnahmen. Eine Menge.

Wo kannst du es verwenden?

Die Client-Kompatibilität ist breit. Azure MCP Server 2.0 funktioniert mit:

IDEs: VS Code, Visual Studio, IntelliJ, Eclipse, Cursor
CLI Agents: GitHub Copilot CLI, Claude Code
Standalone: lokaler Server für einfache Setups
Self-Hosted Remote: der neue Star von 2.0

Zusätzlich gibt es Sovereign Cloud Support für Azure US Government und Azure von 21Vianet betrieben, was für regulierte Deployments entscheidend ist.

Warum das für .NET-Entwickler wichtig ist

Falls du Agentic Anwendungen mit .NET aufbaust — ob das Semantic Kernel, Microsoft Agent Framework oder deine eigene Orchestrierung ist — gibt dir Azure MCP Server 2.0 eine produktionsreife Möglichkeit, deinen Agenten mit Azure-Infrastruktur zu interagieren. Keine benutzerdefinierten REST-Wrapper. Keine Service-spezifischen Integrationsmuster. Einfach MCP.

Kombiniert mit der Fluent API für MCP Apps, die vor ein paar Tagen kam, reift das .NET MCP-Ökosystem schnell.

Erste Schritte

Wähle deinen Weg:

GitHub Repo — Quellcode, Docs, alles
Docker Image — containerisiertes Deployment
VS Code Extension — IDE-Integration
Self-Hosting Guide — das Flaggschiff-Feature von 2.0

Zusammenfassung

Azure MCP Server 2.0 ist genau die Art von Infrastruktur-Upgrade, das in einer Demo nicht glamourös aussieht, aber in der Praxis alles verändert. Self-Hosted Remote MCP mit ordnungsgemäßer Authentifizierung, Security Hardening und Sovereign Cloud Support bedeutet, dass MCP bereit für echte Teams ist, die echte Agentic Workflows auf Azure aufbauen. Falls du auf das „Enterprise-Ready"-Signal gewartet hast — das ist es.

Agentisches Platform Engineering Wird Realität — Git-APE Zeigt Wie

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

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

Platform Engineering war einer dieser Begriffe, die auf Konferenzen toll klingen, aber normalerweise bedeuten: „Wir haben ein internes Portal und einen Terraform-Wrapper gebaut." Das eigentliche Versprechen — Self-Service-Infrastruktur, die wirklich sicher, kontrolliert und schnell ist — war immer noch ein paar Schritte entfernt.

Das Azure-Team hat gerade Teil 2 ihrer Serie über agentisches Platform Engineering veröffentlicht, und in diesem Teil geht es um die praktische Umsetzung. Sie nennen es Git-APE (ja, das Akronym ist beabsichtigt), und es ist ein Open-Source-Projekt, das GitHub Copilot Agents plus Azure MCP Server nutzt, um natürlichsprachliche Anfragen in validierte, deployed Infrastruktur umzuwandeln.

Was Git-APE tatsächlich macht

Die Kernidee: Anstatt dass Entwickler Terraform-Module lernen, durch Portal-UIs navigieren oder Tickets beim Platform-Team einreichen, sprechen sie mit einem Copilot-Agenten. Der Agent interpretiert die Absicht, generiert Infrastructure-as-Code, validiert sie gegen Richtlinien und deployt — alles innerhalb von VS Code.

Hier ist das Setup:

git clone https://github.com/Azure/git-ape
cd git-ape

Öffne den Workspace in VS Code, und die Agent-Konfigurationsdateien werden automatisch von GitHub Copilot erkannt. Du interagierst direkt mit dem Agenten:

@git-ape deploy a function app with storage in West Europe

Der Agent nutzt Azure MCP Server unter der Haube, um mit Azure-Diensten zu interagieren. Die MCP-Konfiguration in den VS Code-Einstellungen aktiviert spezifische Fähigkeiten:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Warum das wichtig ist

Für diejenigen von uns, die auf Azure bauen, verschiebt dies die Platform-Engineering-Diskussion von „wie bauen wir ein Portal" zu „wie beschreiben wir unsere Leitplanken als APIs." Wenn die Schnittstelle deiner Plattform ein KI-Agent ist, wird die Qualität deiner Einschränkungen und Richtlinien zum Produkt.

Der Blog von Teil 1 legte die Theorie dar: gut beschriebene APIs, Kontrollschemata und explizite Leitplanken machen Plattformen agent-ready. Teil 2 beweist, dass es funktioniert, indem tatsächliche Werkzeuge ausgeliefert werden. Der Agent generiert nicht blind Ressourcen — er validiert gegen Best Practices, respektiert Namenskonventionen und wendet die Richtlinien deiner Organisation an.

Das Aufräumen ist genauso einfach:

@git-ape destroy my-resource-group

Meine Einschätzung

Ich bin ehrlich — hier geht es mehr um das Muster als um das spezifische Tool. Git-APE selbst ist eine Demo/Referenzarchitektur. Aber die zugrundeliegende Idee — Agenten als Interface zu deiner Plattform, MCP als Protokoll, GitHub Copilot als Host — ist die Richtung, in die sich die Enterprise-Developer-Experience bewegt.

Wenn du ein Platform-Team bist, das darüber nachdenkt, wie man interne Werkzeuge agent-freundlich macht, gibt es keinen besseren Startpunkt. Und wenn du ein .NET-Entwickler bist, der sich fragt, wie das mit deiner Welt zusammenhängt: Der Azure MCP Server und GitHub Copilot Agents funktionieren mit jedem Azure-Workload. Deine ASP.NET Core API, dein .NET Aspire Stack, deine containerisierten Microservices — all das kann Ziel eines agentischen Deployment-Flows sein.

Zusammenfassung

Git-APE ist ein früher, aber konkreter Blick auf agentisches Platform Engineering in der Praxis. Klone das Repo, probiere die Demo aus und fange an darüber nachzudenken, wie die APIs und Richtlinien deiner Plattform aussehen müssten, damit ein Agent sie sicher nutzen kann.

Lies den vollständigen Post für den Walkthrough und Video-Demos.

Echtzeit-Multi-Agent-UIs Bauen, Die Sich Nicht Wie eine Black Box Anfühlen

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

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

Hier ist das Ding mit Multi-Agent-Systemen: Sie sehen in Demos unglaublich aus. Drei Agenten, die Arbeit weiterreichen, Probleme lösen, Entscheidungen treffen. Dann versuchst du es echten Benutzern zu zeigen und… Stille. Ein drehender Ladeindikator. Keine Ahnung, welcher Agent was macht oder warum das System pausiert ist. Das ist kein Produkt — das ist ein Vertrauensproblem.

Das Microsoft Agent Framework Team hat gerade einen fantastischen Walkthrough veröffentlicht, wie man MAF-Workflows mit AG-UI kombiniert — einem offenen Protokoll zum Streamen von Agent-Ausführungsereignissen an ein Frontend über Server-Sent Events. Und ehrlich gesagt? Das ist genau die Brücke, die uns gefehlt hat.

Warum das für .NET-Entwickler wichtig ist

Wenn du KI-gestützte Apps baust, bist du wahrscheinlich schon an diese Wand gestoßen. Deine Backend-Orchestrierung funktioniert super — Agenten übergeben aneinander, Tools feuern, Entscheidungen werden getroffen. Aber das Frontend hat keine Ahnung, was hinter den Kulissen passiert. AG-UI löst das, indem es ein Standardprotokoll zum Streamen von Agent-Events definiert (denk an RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) direkt an deine UI-Schicht über SSE.

Die Demo ist ein Kundenservice-Workflow mit drei Agenten: ein Triage-Agent, der Anfragen weiterleitet, ein Erstattungs-Agent für Geldangelegenheiten, und ein Bestell-Agent für Austauschvorgänge. Jeder Agent hat seine eigenen Tools, und die Handoff-Topologie ist explizit definiert — kein “finde es aus dem Prompt heraus”-Vibe.

Die Handoff-Topologie ist der eigentliche Star

Was mir aufgefallen ist, ist wie HandoffBuilder dir erlaubt, einen gerichteten Routing-Graphen zwischen Agenten zu deklarieren:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Jedes add_handoff erstellt eine gerichtete Kante mit einer natürlichsprachlichen Beschreibung. Das Framework generiert Handoff-Tools für jeden Agenten basierend auf dieser Topologie. Routing-Entscheidungen basieren also auf deiner Orchestrierungsstruktur, nicht nur darauf, was das LLM gerade für richtig hält. Das ist ein riesiger Gewinn für die Produktionszuverlässigkeit.

Human-in-the-Loop, das tatsächlich funktioniert

Die Demo zeigt zwei Unterbrechungsmuster, die jede echte Agent-App braucht:

Tool-Genehmigungs-Unterbrechungen — wenn ein Agent ein Tool aufruft, das mit approval_mode="always_require" markiert ist, pausiert der Workflow und sendet ein Event. Das Frontend rendert ein Genehmigungs-Modal mit dem Tool-Namen und den Argumenten. Keine Token-verbrennenden Retry-Schleifen — einfach ein sauberer Pause-Genehmigung-Fortsetzen-Ablauf.

Informationsanfrage-Unterbrechungen — wenn ein Agent mehr Kontext vom Benutzer braucht (wie eine Bestell-ID), pausiert er und fragt nach. Das Frontend zeigt die Frage an, der Benutzer antwortet, und die Ausführung wird genau dort fortgesetzt, wo sie aufgehört hat.

Beide Muster werden als Standard-AG-UI-Events gestreamt, sodass dein Frontend keine agenten-spezifische Logik braucht — es rendert einfach jedes Event, das über die SSE-Verbindung kommt.

Die Anbindung ist überraschend einfach

Die Integration zwischen MAF und AG-UI ist ein einziger Funktionsaufruf:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

Die workflow_factory erstellt einen frischen Workflow pro Thread, sodass jede Konversation isolierten State bekommt. Der Endpoint übernimmt die gesamte SSE-Verkabelung automatisch. Wenn du bereits FastAPI nutzt (oder es als leichte Schicht hinzufügen kannst), ist das praktisch ohne Reibungsverluste.

Meine Einschätzung

Für uns .NET-Entwickler ist die sofortige Frage: „Geht das auch in C#?" Das Agent Framework ist für .NET und Python verfügbar, und das AG-UI-Protokoll ist sprachunabhängig (es ist nur SSE). Obwohl diese spezifische Demo Python und FastAPI verwendet, lässt sich das Muster direkt übertragen. Du könntest eine ASP.NET Core Minimal API mit SSE-Endpoints nach dem gleichen AG-UI-Event-Schema aufbauen.

Die wichtigere Erkenntnis ist, dass Multi-Agent-UIs zu einem erstklassigen Thema werden — nicht mehr nur ein Nachgedanke. Wenn du irgendetwas baust, wo Agenten mit Menschen interagieren — Kundenservice, Genehmigungs-Workflows, Dokumentenverarbeitung — dann ist diese Kombination aus MAF-Orchestrierung und AG-UI-Transparenz das Muster, dem man folgen sollte.

Zusammenfassung

AG-UI + Microsoft Agent Framework gibt dir das Beste aus beiden Welten: robuste Multi-Agent-Orchestrierung im Backend und Echtzeit-Transparenz im Frontend. Keine Black-Box-Agent-Interaktionen mehr.

Schau dir den vollständigen Walkthrough und das AG-UI-Protokoll-Repository an, um tiefer einzutauchen.

GitHub Copilots Modernisierungs-Assessment ist das beste Migrationstool, das du noch nicht nutzt

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

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

Eine Legacy-.NET-Framework-App auf modernes .NET zu migrieren ist eine dieser Aufgaben, von der jeder weiß, dass sie erledigt werden sollte, die aber niemand anfangen will. Es ist nie nur „ändere das Ziel-Framework." Es sind APIs, die verschwunden sind, Pakete, die nicht mehr existieren, Hosting-Modelle, die völlig anders funktionieren, und eine Million kleiner Entscheidungen darüber, was containerisiert, was umgeschrieben und was in Ruhe gelassen werden soll.

Jeffrey Fritz hat gerade einen tiefen Einblick in GitHub Copilots Modernisierungs-Assessment veröffentlicht, und ehrlich? Das ist das beste Migrationstooling, das ich für .NET gesehen habe. Nicht wegen der Code-Generierung — das ist mittlerweile Standard. Wegen des Assessment-Dokuments, das es erstellt.

Es ist nicht nur eine Code-Vorschlagsmaschine

Die VS Code-Erweiterung folgt einem Bewerten → Planen → Ausführen-Modell. Die Bewertungsphase analysiert deine gesamte Codebase und erstellt ein strukturiertes Dokument, das alles erfasst: was sich ändern muss, welche Azure-Ressourcen provisioniert werden müssen, welches Deployment-Modell verwendet werden soll. Alles Nachfolgende — Infrastructure as Code, Containerisierung, Deployment-Manifeste — leitet sich aus den Ergebnissen des Assessments ab.

Das Assessment wird unter .github/modernize/assessment/ in deinem Projekt gespeichert. Jeder Durchlauf erzeugt einen unabhängigen Report, sodass du eine Historie aufbaust und verfolgen kannst, wie sich deine Migrationsposition entwickelt, wenn du Issues behebst.

Zwei Wege zum Start

Empfohlenes Assessment — der schnelle Weg. Wähle aus kuratierten Domains (Java/.NET Upgrade, Cloud Readiness, Sicherheit) und erhalte aussagekräftige Ergebnisse ohne Konfigurationsaufwand. Ideal für einen ersten Blick, wo deine App steht.

Benutzerdefiniertes Assessment — der gezielte Weg. Konfiguriere genau, was analysiert werden soll: Ziel-Compute (App Service, AKS, Container Apps), Ziel-OS, Containerisierungsanalyse. Wähle mehrere Azure-Ziele, um Migrationsansätze nebeneinander zu vergleichen.

Diese Vergleichsansicht ist wirklich nützlich. Eine App mit 3 obligatorischen Issues für App Service könnte 7 für AKS haben. Beides zu sehen hilft bei der Hosting-Entscheidung, bevor man sich auf einen Migrationspfad festlegt.

Die Issue-Aufschlüsselung ist umsetzbar

Jedes Issue kommt mit einem Kritikalitätslevel:

Obligatorisch — muss behoben werden, sonst scheitert die Migration
Potenziell — könnte die Migration beeinflussen, braucht menschliche Beurteilung
Optional — empfohlene Verbesserungen, blockiert die Migration nicht

Und jedes Issue verlinkt zu betroffenen Dateien und Zeilennummern, liefert eine detaillierte Beschreibung dessen, was falsch ist und warum es für deine Zielplattform wichtig ist, gibt konkrete Behebungsschritte (nicht nur „repariere das") und enthält Links zur offiziellen Dokumentation.

Du kannst einzelne Issues an Entwickler weitergeben, und sie haben alles, was sie zum Handeln brauchen. Das ist der Unterschied zwischen einem Tool, das dir sagt „es gibt ein Problem" und einem, das dir sagt, wie du es löst.

Die abgedeckten Upgrade-Pfade

Für .NET spezifisch:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Jeder Upgrade-Pfad hat Erkennungsregeln, die wissen, welche APIs entfernt wurden, welche Patterns kein direktes Äquivalent haben und welche Sicherheitsprobleme Aufmerksamkeit erfordern.

Für Teams, die mehrere Apps verwalten, gibt es auch ein CLI, das Multi-Repo-Batch-Assessments unterstützt — alle Repos klonen, alle bewerten, App-spezifische Reports plus eine aggregierte Portfolio-Ansicht bekommen.

Meine Einschätzung

Wenn du auf Legacy-.NET-Framework-Apps sitzt (und seien wir ehrlich, die meisten Enterprise-Teams tun das), ist dies das Tool zum Starten. Allein das Assessment-Dokument ist die Zeit wert — es verwandelt ein vages „wir sollten modernisieren" in eine konkrete, priorisierte Liste von Arbeitspaketen mit klaren Wegen nach vorn.

Der kollaborative Workflow ist auch clever: Assessments exportieren, mit deinem Team teilen, importieren ohne erneut auszuführen. Architektur-Reviews, bei denen die Entscheider nicht diejenigen sind, die die Tools ausführen? Abgedeckt.

Zusammenfassung

GitHub Copilots Modernisierungs-Assessment verwandelt .NET-Migration von einem beängstigenden, undefinierten Projekt in einen strukturierten, nachverfolgbaren Prozess. Starte mit einem empfohlenen Assessment, um zu sehen, wo du stehst, und nutze dann benutzerdefinierte Assessments, um Azure-Ziele zu vergleichen und deinen Migrationsplan zu erstellen.

Lies den vollständigen Walkthrough und hole dir die VS Code-Erweiterung, um es an deinem eigenen Code auszuprobieren.

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.

SQL MCP Server — Der richtige Weg, AI-Agenten Datenbankzugriff zu geben

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

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

Seien wir ehrlich: Die meisten heute verfügbaren Datenbank-MCP-Server sind beängstigend. Sie nehmen eine natürlichsprachliche Abfrage, generieren SQL im laufenden Betrieb und führen es gegen Ihre Produktionsdaten aus. Was könnte schiefgehen? (Alles. Alles könnte schiefgehen.)

Das Azure SQL-Team hat gerade den SQL MCP Server vorgestellt, und er verfolgt einen grundlegend anderen Ansatz. Als Feature von Data API builder (DAB) 2.0 gebaut, gibt er AI-Agenten strukturierten, deterministischen Zugriff auf Datenbankoperationen — ohne NL2SQL, ohne Schema-Exposition und mit vollständigem RBAC bei jedem Schritt.

Warum kein NL2SQL?

Das ist die interessanteste Design-Entscheidung. Modelle sind nicht deterministisch, und komplexe Abfragen produzieren am wahrscheinlichsten subtile Fehler. Genau die Abfragen, von denen Benutzer hoffen, dass AI sie generieren kann, sind auch diejenigen, die die meiste Prüfung erfordern, wenn sie nicht-deterministisch erzeugt werden.

Stattdessen verwendet SQL MCP Server einen NL2DAB-Ansatz. Der Agent arbeitet mit der Entitäts-Abstraktionsschicht von Data API builder und dem integrierten Query Builder, um akkurates, wohlgeformtes T-SQL deterministisch zu produzieren. Gleiches Ergebnis für den Benutzer, aber ohne das Risiko halluzinierter JOINs oder versehentlicher Datenexposition.

Sieben Tools, nicht siebenhundert

SQL MCP Server exponiert genau sieben DML-Tools, unabhängig von der Datenbankgröße:

describe_entities — verfügbare Entitäten und Operationen entdecken
create_record — Zeilen einfügen
read_records — Tabellen und Views abfragen
update_record — Zeilen ändern
delete_record — Zeilen entfernen
execute_entity — gespeicherte Prozeduren ausführen
aggregate_records — Aggregationsabfragen

Das ist clever, weil Context Windows der Denkraum des Agenten sind. Sie mit Hunderten von Tool-Definitionen zu überfluten lässt weniger Raum für das Denken. Sieben feste Tools halten den Agenten auf Denken statt Navigieren fokussiert.

Jedes Tool kann einzeln aktiviert oder deaktiviert werden:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

In drei Befehlen starten

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

Das ist ein laufender SQL MCP Server, der Ihre Customers-Tabelle exponiert. Die Entitäts-Abstraktionsschicht bedeutet, dass Sie Namen und Spalten aliasieren, Felder pro Rolle beschränken und genau kontrollieren können, was Agenten sehen — ohne interne Schema-Details preiszugeben.

Die Sicherheitsgeschichte überzeugt

Hier zahlt sich die Reife von Data API builder aus:

RBAC auf jeder Ebene — jede Entität definiert, welche Rollen lesen, erstellen, aktualisieren oder löschen können, und welche Felder sichtbar sind
Azure Key Vault-Integration — Connection Strings und Secrets sicher verwaltet
Microsoft Entra + Custom OAuth — Authentifizierung auf Produktionsniveau
Content Security Policy — Agenten interagieren über einen kontrollierten Vertrag, nicht über rohes SQL

Die Schema-Abstraktion ist besonders wichtig. Ihre internen Tabellen- und Spaltennamen werden niemals dem Agenten exponiert. Sie definieren Entitäten, Aliase und Beschreibungen, die für die AI-Interaktion sinnvoll sind — nicht Ihr Datenbank-ERD.

Multi-Datenbank und Multi-Protokoll

SQL MCP Server unterstützt Microsoft SQL, PostgreSQL, Azure Cosmos DB und MySQL. Und da es ein DAB-Feature ist, bekommen Sie REST-, GraphQL- und MCP-Endpoints gleichzeitig aus derselben Konfiguration. Gleiche Entitätsdefinitionen, gleiche RBAC-Regeln, gleiche Sicherheit — über alle drei Protokolle.

Die Auto-Konfiguration in DAB 2.0 kann sogar Ihre Datenbank inspizieren und die Konfiguration dynamisch aufbauen, wenn Sie für schnelles Prototyping mit weniger Abstraktion arbeiten möchten.

Meine Einschätzung

So sollte Enterprise-Datenbankzugriff für AI-Agenten funktionieren. Nicht „Hey LLM, schreib mir SQL und YOLO es gegen Produktion." Stattdessen: eine wohldefinierte Entitätsschicht, deterministische Abfragegenerierung, RBAC bei jedem Schritt, Caching, Monitoring und Telemetrie. Es ist langweilig auf die bestmögliche Art.

Für .NET-Entwickler ist die Integrationsgeschichte sauber — DAB ist ein .NET-Tool, der MCP Server läuft als Container, und er funktioniert mit Azure SQL, das die meisten von uns bereits verwenden. Wenn Sie AI-Agenten bauen, die Datenzugriff brauchen, starten Sie hier.

Zusammenfassung

SQL MCP Server ist kostenlos, Open Source und läuft überall. Es ist der präskriptive Ansatz von Microsoft, um AI-Agenten sicheren Datenbankzugriff zu geben. Lesen Sie den vollständigen Beitrag und die Dokumentation für den Einstieg.

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.

azd ermöglicht jetzt lokales Ausführen und Debuggen von KI-Agenten — Das hat sich im März 2026 geändert

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Sieben Releases in einem Monat. Das hat das Azure Developer CLI (azd)-Team im März 2026 veröffentlicht, und das Hauptfeature ist genau das, worauf ich gewartet habe: ein lokaler Run-and-Debug-Loop für KI-Agenten.

PC Chan hat die vollständige Zusammenfassung veröffentlicht, und obwohl es viel gibt, lass mich das auf das filtern, was für .NET-Entwickler, die KI-gestützte Apps bauen, wirklich wichtig ist.

KI-Agenten ausführen und debuggen ohne Deployment

Das ist das große Ding. Die neue azure.ai.agents-Extension fügt Befehle hinzu, die dir eine ordentliche Inner-Loop-Erfahrung für KI-Agenten geben:

azd ai agent run — startet deinen Agenten lokal
azd ai agent invoke — sendet Nachrichten (lokal oder deployed)
azd ai agent show — zeigt Container-Status und Health
azd ai agent monitor — streamt Container-Logs in Echtzeit

Vorher bedeutete das Testen eines KI-Agenten jedes Mal ein Deployment zu Microsoft Foundry. Jetzt kannst du lokal iterieren, das Verhalten testen und erst deployen, wenn du bereit bist. Wenn du Agenten mit dem Microsoft Agent Framework oder Semantic Kernel baust, ändert das deinen täglichen Workflow.

Der invoke-Befehl funktioniert sowohl gegen lokale als auch deployed Agenten, was bedeutet, dass du den gleichen Test-Workflow verwenden kannst, egal wo der Agent läuft.

GitHub Copilot richtet dein azd-Projekt ein

azd init bietet jetzt eine “Set up with GitHub Copilot (Preview)"-Option. Statt manuell Prompts über deine Projektstruktur zu beantworten, scaffoldet ein Copilot-Agent die Konfiguration für dich. Wenn ein Befehl fehlschlägt, bietet azd jetzt KI-gestützte Fehlerbehebung: Kategorie wählen, den Agenten einen Fix vorschlagen lassen und wiederholen — alles ohne das Terminal zu verlassen.

Container App Jobs und Deployment-Verbesserungen

Container App Jobs: azd deployed jetzt Microsoft.App/jobs über die bestehende host: containerapp-Konfiguration.
Konfigurierbare Deployment-Timeouts: Neues --timeout-Flag und deployTimeout-Feld in azure.yaml.
Remote-Build-Fallback: Bei fehlgeschlagenem ACR-Build fällt azd automatisch auf lokalen Docker/Podman-Build zurück.
Lokale Preflight-Validierung: Bicep-Parameter werden lokal validiert, bevor deployed wird.

DX-Verbesserungen

Automatische pnpm/yarn-Erkennung für JS/TS-Projekte
pyproject.toml-Unterstützung für Python
Lokale Template-Verzeichnisse — azd init --template akzeptiert jetzt Dateisystem-Pfade
Bessere Fehlermeldungen im --no-prompt-Modus
Build-Umgebungsvariablen in alle Framework-Build-Subprozesse injiziert (.NET, Node.js, Java, Python)

Zusammenfassung

Der lokale KI-Agenten-Debug-Loop ist der Star dieses Releases, aber die Gesamtheit an Deployment-Verbesserungen und DX-Polish macht azd reifer als je zuvor. Wenn du .NET-Apps auf Azure deployst — besonders KI-Agenten — lohnt sich dieses Update.

Schau dir die vollständigen Release Notes für alle Details an.

KubeCon Europe 2026: Was .NET-Entwickler wirklich wissen sollten

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Dieser Beitrag wurde automatisch übersetzt. Für die Originalversion klicke hier.

Kennst du das Gefühl, wenn ein riesiger Ankündigungs-Post erscheint und du durchscrollst und denkst: „Cool, aber was ändert das jetzt tatsächlich für mich"? So geht es mir jede KubeCon-Saison.

Microsoft hat gerade ihren vollständigen KubeCon Europe 2026 Überblick veröffentlicht — geschrieben von Brendan Burns persönlich — und ehrlich gesagt steckt hier echte Substanz drin. Nicht nur Feature-Checklisten, sondern operative Verbesserungen, die ändern, wie du Dinge in Produktion betreibst.

Lass mich aufschlüsseln, was für uns .NET-Entwickler wirklich zählt.

mTLS ohne die Service-Mesh-Steuer

Hier ist die Sache mit Service Meshes: Jeder will die Sicherheitsgarantien, niemand will den operativen Overhead. AKS schließt diese Lücke endlich.

Azure Kubernetes Application Network gibt dir Mutual TLS, anwendungsbewusste Autorisierung und Traffic-Telemetrie — ohne ein volles Sidecar-lastiges Mesh zu deployen. In Kombination mit Cilium mTLS in Advanced Container Networking Services bekommst du verschlüsselte Pod-zu-Pod-Kommunikation mit X.509-Zertifikaten und SPIRE für Identity Management.

Was das in der Praxis bedeutet: Deine ASP.NET Core APIs, die mit Background-Workern kommunizieren, deine gRPC-Services, die sich gegenseitig aufrufen — alles verschlüsselt und identitätsverifiziert auf Netzwerkebene, ohne eine einzige Code-Änderung. Das ist gewaltig.

Für Teams, die von ingress-nginx migrieren, gibt es außerdem Application Routing mit Meshless Istio mit vollem Kubernetes Gateway API Support. Keine Sidecars. Standardbasiert. Und sie haben ingress2gateway-Tools für inkrementelle Migration mitgeliefert.

GPU-Observability, die kein Nachgedanke ist

Wenn du KI-Inferenz neben deinen .NET-Services ausführst (und seien wir ehrlich, wer fängt nicht langsam damit an?), bist du wahrscheinlich auf den GPU-Monitoring-Blindspot gestoßen. Du hattest großartige CPU/Memory-Dashboards und dann… nichts für GPUs ohne manuelle Exporter-Konfiguration.

AKS zeigt GPU-Metriken jetzt nativ in Managed Prometheus und Grafana an. Gleicher Stack, gleiche Dashboards, gleiche Alerting-Pipeline. Keine Custom-Exporter, keine Third-Party-Agents.

Auf der Netzwerkseite wurde Per-Flow-Visibilität für HTTP-, gRPC- und Kafka-Traffic mit einer One-Click Azure Monitor-Erfahrung hinzugefügt. IPs, Ports, Workloads, Flow-Richtung, Policy-Entscheidungen — alles in eingebauten Dashboards.

Und hier kommt die, bei der ich zweimal hingeschaut habe: Agentic Container Networking fügt eine Web-UI hinzu, in der du natürlichsprachliche Fragen zum Netzwerkzustand deines Clusters stellen kannst. „Warum erreicht Pod X Service Y nicht?" → Read-Only-Diagnose aus Live-Telemetrie. Das ist um 2 Uhr nachts wirklich nützlich.

Cross-Cluster-Networking ohne Doktortitel

Multi-Cluster Kubernetes war historisch eine „Bring deinen eigenen Netzwerk-Kleber mit"-Erfahrung. Azure Kubernetes Fleet Manager liefert jetzt Cross-Cluster-Networking über Managed Cilium Cluster Mesh:

Einheitliche Konnektivität über AKS-Cluster hinweg
Globale Service-Registry für Cross-Cluster-Discovery
Zentral verwaltete Konfiguration statt pro Cluster wiederholt

Wenn du .NET-Microservices über Regionen hinweg für Resilienz oder Compliance betreibst, ersetzt das eine Menge fragilen Custom-Kleber. Service A in West Europe kann Service B in East US über das Mesh entdecken und aufrufen, mit konsistenten Routing- und Sicherheitsrichtlinien.

Upgrades, die keinen Mut erfordern

Seien wir ehrlich — Kubernetes-Upgrades in Produktion sind stressig. „Upgraden und hoffen" war die De-facto-Strategie für zu viele Teams und der Hauptgrund, warum Cluster bei Versionen hinterherhinken.

Zwei neue Fähigkeiten ändern das:

Blue-Green Agent Pool Upgrades erstellen einen parallelen Node-Pool mit der neuen Konfiguration. Verhalten validieren, Traffic schrittweise verlagern und einen sauberen Rollback-Pfad behalten. Keine In-Place-Mutationen auf Produktions-Nodes mehr.

Agent Pool Rollback ermöglicht es, einen Node-Pool auf seine vorherige Kubernetes-Version und Node-Image zurückzusetzen, wenn ein Upgrade schiefgeht — ohne den Cluster neu aufzubauen.

Zusammen geben sie Operatoren endlich echte Kontrolle über den Upgrade-Lebenszyklus. Für .NET-Teams ist das wichtig, weil Plattform-Geschwindigkeit direkt steuert, wie schnell du neue Runtimes, Sicherheitspatches und Netzwerk-Fähigkeiten einsetzen kannst.

KI-Workloads werden zu First-Class Kubernetes-Bürgern

Die Upstream-Open-Source-Arbeit ist gleichermaßen wichtig. Dynamic Resource Allocation (DRA) ist gerade in Kubernetes 1.36 GA geworden und macht GPU-Scheduling zu einem echten First-Class-Feature statt eines Workarounds.

Einige Projekte, die es wert sind beobachtet zu werden:

Projekt	Was es macht
AI Runway	Gemeinsame Kubernetes-API für Inferenz — Models deployen ohne K8s-Kenntnisse, mit HuggingFace-Discovery und Kostenschätzungen
HolmesGPT	Agentisches Troubleshooting für Cloud-Native — jetzt ein CNCF-Sandbox-Projekt
Dalec	Deklarative Container-Image-Builds mit SBOM-Generierung — weniger CVEs in der Build-Phase

Die Richtung ist klar: Deine .NET-API, deine Semantic-Kernel-Orchestrierungsschicht und deine Inferenz-Workloads sollten alle auf einem konsistenten Plattformmodell laufen. Wir kommen dahin.

Wo ich diese Woche anfangen würde

Wenn du diese Änderungen für dein Team evaluierst, hier meine ehrliche Prioritätenliste:

Observability zuerst — GPU-Metriken und Netzwerk-Flow-Logs in einem Nicht-Prod-Cluster aktivieren. Schau dir an, was du verpasst hast.
Blue-Green-Upgrades testen — den Rollback-Workflow vor deinem nächsten Produktions-Cluster-Upgrade ausprobieren. Vertrauen in den Prozess aufbauen.
Identity-Aware Networking pilotieren — einen internen Service-Pfad wählen und mTLS mit Cilium aktivieren. Den Overhead messen (Spoiler: er ist minimal).
Fleet Manager evaluieren — wenn du mehr als zwei Cluster betreibst, zahlt sich Cross-Cluster-Networking durch weniger Custom-Kleber von selbst.

Kleine Experimente, schnelles Feedback. Das ist immer der richtige Zug.

Zum Schluss

KubeCon-Ankündigungen können überwältigend sein, aber diese Runde bewegt wirklich etwas für .NET-Teams auf AKS. Bessere Netzwerksicherheit ohne Mesh-Overhead, echte GPU-Observability, sicherere Upgrades und stärkere KI-Infrastruktur-Grundlagen.

Wenn du bereits auf AKS bist, ist jetzt ein großartiger Moment, deine operative Baseline zu verbessern. Und wenn du planst, .NET-Workloads auf Kubernetes zu verlagern — die Plattform ist gerade deutlich produktionsreifer geworden.

SQL MCP Server, Copilot in SSMS und ein Database Hub mit KI-Agenten: Was von der SQLCon 2026 wirklich zählt

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft hat gerade die SQLCon 2026 zusammen mit der FabCon in Atlanta eröffnet, und es gibt eine Menge zu besprechen. Die ursprüngliche Ankündigung deckt alles ab, von Sparplänen bis hin zu Enterprise-Compliance-Features. Ich werde die Enterprise-Preisfolien überspringen und mich auf die Dinge konzentrieren, die wichtig sind, wenn du als Entwickler mit Azure SQL und KI arbeitest.

SQL MCP Server ist in der Public Preview

Das ist für mich die Hauptnachricht. Azure SQL Database Hyperscale hat jetzt einen SQL MCP Server in der Public Preview, mit dem du deine SQL-Daten sicher mit KI-Agenten und Copilots über das Model Context Protocol verbinden kannst.

Wenn du die MCP-Welle verfolgt hast — und ehrlich gesagt, man kann sie gerade kaum übersehen — dann ist das eine große Sache. Statt eigene Datenpipelines zu bauen, um deinen KI-Agenten Kontext aus der Datenbank zu liefern, bekommst du ein standardisiertes Protokoll, um SQL-Daten direkt zur Verfügung zu stellen. Deine Agenten können live Datenbankinformationen abfragen, darüber nachdenken und darauf reagieren.

Für diejenigen von uns, die KI-Agenten mit Semantic Kernel oder dem Microsoft Agent Framework bauen, eröffnet das einen sauberen Integrationspfad. Dein Agent muss den Lagerbestand prüfen? Einen Kundendatensatz nachschlagen? Eine Bestellung validieren? MCP gibt ihm einen strukturierten Weg, das zu tun, ohne dass du für jedes Szenario maßgeschneiderten Datenabruf-Code schreiben musst.

GitHub Copilot in SSMS 22 ist jetzt GA

Wenn du Zeit in SQL Server Management Studio verbringst — und seien wir ehrlich, die meisten von uns tun das immer noch — GitHub Copilot ist jetzt in SSMS 22 allgemein verfügbar. Dieselbe Copilot-Erfahrung, die du bereits in VS Code und Visual Studio nutzt, aber für T-SQL.

Der praktische Nutzen ist klar: Chat-basierte Unterstützung beim Schreiben von Abfragen, Refactoring von Stored Procedures, Fehlerbehebung bei Performance-Problemen und Verwaltungsaufgaben. Konzeptionell nichts Revolutionäres, aber es direkt in SSMS zu haben bedeutet, dass du nicht zu einem anderen Editor wechseln musst, nur um KI-Hilfe für deine Datenbankarbeit zu bekommen.

Vector Indexes haben ein ernsthaftes Upgrade bekommen

Azure SQL Database hat jetzt schnellere, leistungsfähigere Vector Indexes mit voller Unterstützung für Insert, Update und Delete. Das bedeutet, deine Vektordaten bleiben in Echtzeit aktuell — kein Batch-Reindexing mehr nötig.

Das ist neu:

Quantisierung für kleinere Indexgrößen ohne zu viel Genauigkeit zu verlieren
Iteratives Filtering für präzisere Ergebnisse
Engere Integration mit dem Query Optimizer für vorhersagbare Performance

Wenn du Retrieval-Augmented Generation (RAG) mit Azure SQL als Vector Store machst, sind diese Verbesserungen direkt nützlich. Du kannst deine Vektoren zusammen mit deinen relationalen Daten in derselben Datenbank halten, was deine Architektur im Vergleich zum Betrieb einer separaten Vektordatenbank erheblich vereinfacht.

Dieselben Vektor-Verbesserungen sind auch in SQL Database in Fabric verfügbar, da beide unter der Haube auf derselben SQL-Engine laufen.

Database Hub in Fabric: Agentisches Management

Dieser Punkt ist eher zukunftsorientiert, aber er ist interessant. Microsoft hat den Database Hub in Microsoft Fabric (Early Access) angekündigt, der dir eine einheitliche Ansicht über Azure SQL, Cosmos DB, PostgreSQL, MySQL und SQL Server via Arc bietet.

Der interessante Aspekt ist nicht nur die einheitliche Ansicht — es ist der agentische Ansatz beim Management. KI-Agenten überwachen kontinuierlich dein Datenbankökosystem, zeigen auf, was sich geändert hat, erklären, warum es wichtig ist, und schlagen vor, was als nächstes zu tun ist. Es ist ein Human-in-the-Loop-Modell, bei dem der Agent die Vorarbeit leistet und du die Entscheidungen triffst.

Für Teams, die mehr als eine Handvoll Datenbanken verwalten, könnte das den operativen Lärm wirklich reduzieren. Statt zwischen Portalen zu wechseln und manuell Metriken zu prüfen, bringt der Agent das Signal zu dir.

Was das für .NET-Entwickler bedeutet

Der rote Faden, der all diese Ankündigungen verbindet, ist klar: Microsoft bettet KI-Agenten in jede Schicht des Datenbank-Stacks ein. Nicht als Spielerei, sondern als praktische Werkzeugebene.

Wenn du .NET-Apps baust, die auf Azure SQL basieren, hier ist, was ich tatsächlich tun würde:

Probier den SQL MCP Server aus, wenn du KI-Agenten baust. Es ist der sauberste Weg, deinen Agenten Datenbankzugriff zu geben, ohne eigene Plumbing zu bauen.
Aktiviere Copilot in SSMS, falls du es noch nicht getan hast — ein kostenloser Produktivitätsgewinn für die tägliche SQL-Arbeit.
Schau dir Vector Indexes an, wenn du RAG machst und derzeit einen separaten Vector Store betreibst. Die Konsolidierung auf Azure SQL bedeutet einen Service weniger zu verwalten.

Zusammenfassung

Die vollständige Ankündigung enthält mehr — Sparpläne, Migrationsassistenten, Compliance-Features — aber die Developer-Story liegt im MCP Server, den Vektor-Verbesserungen und der agentischen Management-Schicht. Das sind die Dinge, die verändern, wie du baust, nicht nur wie du budgetierst.

Schau dir die vollständige Ankündigung von Shireesh Thota für das komplette Bild an, und melde dich für den Database Hub Early Access an, wenn du die neue Management-Erfahrung ausprobieren möchtest.

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.

Background Responses im Microsoft Agent Framework: Keine Timeout-Angst mehr

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

Wenn du irgendetwas mit Reasoning-Modellen wie o3 oder GPT-5.2 gebaut hast, kennst du den Schmerz. Dein Agent fängt an, über eine komplexe Aufgabe nachzudenken, der Client wartet, und irgendwo zwischen “das ist okay” und “ist das abgestürzt?” bricht deine Verbindung wegen Timeout ab. Die ganze Arbeit? Weg.

Das Microsoft Agent Framework hat gerade Background Responses ausgeliefert — und ehrlich gesagt, das ist eine dieser Funktionen, die von Anfang an hätte existieren sollen.

Das Problem mit blockierenden Aufrufen

In einem traditionellen Request-Response-Muster blockiert dein Client, bis der Agent fertig ist. Das funktioniert gut für schnelle Aufgaben. Aber wenn du ein Reasoning-Modell bittest, tiefgehende Recherche, mehrstufige Analyse oder einen 20-seitigen Bericht zu erstellen? Da schaust du auf Minuten realer Wartezeit. Während dieses Zeitfensters:

HTTP-Verbindungen können ablaufen
Netzwerkunterbrechungen zerstören die gesamte Operation
Dein Benutzer starrt auf einen Spinner und fragt sich, ob irgendetwas passiert

Background Responses drehen das Ganze um.

Wie Continuation Tokens funktionieren

Anstatt zu blockieren, startest du die Agent-Aufgabe und bekommst ein Continuation Token zurück. Denk daran wie an einen Abholschein in einer Werkstatt — du stehst nicht an der Theke und wartest, du kommst zurück, wenn es fertig ist.

Der Ablauf ist unkompliziert:

Sende deine Anfrage mit AllowBackgroundResponses = true
Wenn der Agent Hintergrundverarbeitung unterstützt, bekommst du ein Continuation Token
Polle nach deinem Zeitplan, bis das Token null zurückgibt — das bedeutet, das Ergebnis ist fertig

Hier ist die .NET-Version:

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// Pollen bis fertig
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Wenn der Agent sofort fertig wird (einfache Aufgaben, Modelle die keine Hintergrundverarbeitung brauchen), wird kein Continuation Token zurückgegeben. Dein Code funktioniert einfach — keine spezielle Behandlung nötig.

Streaming mit Wiederaufnahme: die echte Magie

Polling ist gut für Fire-and-Forget-Szenarien, aber was, wenn du Echtzeit-Fortschritt willst? Background Responses unterstützen auch Streaming mit eingebauter Wiederaufnahme.

Jedes gestreamte Update trägt sein eigenes Continuation Token. Wenn deine Verbindung mitten im Stream abbricht, setzt du genau dort fort, wo du aufgehört hast:

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simuliere eine Netzwerkunterbrechung
}

// Genau dort fortsetzen, wo wir aufgehört haben
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

Der Agent verarbeitet serverseitig weiter, unabhängig davon, was mit deinem Client passiert. Das ist eingebaute Fehlertoleranz, ohne dass du Retry-Logik oder Circuit Breaker schreiben musst.

Wann man das tatsächlich verwenden sollte

Nicht jeder Agent-Aufruf braucht Background Responses. Für schnelle Completions fügst du Komplexität ohne Grund hinzu. Aber hier glänzen sie:

Komplexe Reasoning-Aufgaben — mehrstufige Analyse, tiefgehende Recherche, alles was ein Reasoning-Modell wirklich zum Nachdenken bringt
Lange Content-Generierung — detaillierte Berichte, mehrteilige Dokumente, ausführliche Analysen
Unzuverlässige Netzwerke — mobile Clients, Edge-Deployments, instabile Firmen-VPNs
Asynchrone UX-Muster — Aufgabe absenden, etwas anderes machen, Ergebnisse abholen

Für uns .NET-Entwickler, die Enterprise-Apps bauen, ist der letzte Punkt besonders interessant. Denk an eine Blazor-App, in der ein Benutzer einen komplexen Bericht anfordert — du startest die Agent-Aufgabe, zeigst einen Fortschrittsindikator und lässt sie weiterarbeiten. Keine WebSocket-Akrobatik, keine selbstgebaute Queue-Infrastruktur, nur ein Token und eine Poll-Schleife.

Zusammenfassung

Background Responses sind jetzt sowohl in .NET als auch in Python über das Microsoft Agent Framework verfügbar. Wenn du Agenten baust, die mehr als einfaches Q&A machen, lohnt es sich, das in dein Toolkit aufzunehmen. Das Continuation-Token-Muster hält die Dinge einfach und löst gleichzeitig ein sehr reales Produktionsproblem.

Schau dir die vollständige Dokumentation für die komplette API-Referenz und weitere Beispiele 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.

Azure | 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

Cosmos DB Shell Ist in der Öffentlichen Vorschau — Und Es Hat einen Integrierten MCP-Server

Was Es von Anderen Datenbank-CLIs Unterscheidet

Die Open-Source-Grundlage Ist Wichtig

Drei Szenarien, Die Einfacher Werden

Erste Schritte

Ihr KI-Agent Hat ein Identitätsproblem (Und Hier ist die Vorlage, die Es Löst)

Das Kernproblem: Authentifizierung ≠ Autorisierung

Wie die Token-Kette Funktioniert

Was die Vorlage Deployt

Das Designprinzip, das Es Wert Ist, Übernommen zu Werden

Fazit

Private Endpoints, VNets, NSGs — Aspire übernimmt jetzt das Netzwerk

Die Bausteine

Beschreibung im AppHost

Warum das für echte Anwendungen wichtig ist

Fazit

Aspire 13.3: Kubernetes-Unterstützung, Browser-Logs und die Aspireify-Funktion

Aspireify: Agentengestütztes Onboarding

Erstklassiges Kubernetes- und AKS-Deployment

Browser-Logs im Dashboard

Strukturierte Befehlsergebnisse

Fazit

SDD Conference 2026

Themen

Speaker

Tickets und Infos

Die Monkey Work der Migration mit Agentic Platform Engineering beseitigen

Die Eingabe: contoso-migration

Schritt 1: Validierung und Authentifizierung

Schritt 2: Intent-Extraktion

Schritt 3: Service-Mapping

Schritt 4: Kritik-Agent

Schritt 5: Generierte Ausgabe

Vergleich der Sicherheitslage

Was dies von einem Syntax-Konverter unterscheidet

SQL MCP Server auf Azure App Service — Ohne Container

Was ist der SQL MCP Server?

Das Container-Problem (und die Lösung)

Authentifizierung ohne geteilte API-Schlüssel

Bereitstellung auf App Service

Warum das für .NET-Entwickler wichtig ist

Fazit

SQL Server 2025 als Agent-Ready Datenbank: Sicherheit, Backup und MCP in einer Engine

Ein Sicherheitsmodell für alle Datenmodelle

Einheitliches Backup = Atomare Wiederherstellung

MCP-Integration: Agenten Ohne Hand-codierten Middleware

Fazit

Azure SDK April 2026: AI Foundry 2.0 und Was .NET-Entwickler Wissen Sollten

Azure.AI.Projects 2.0.0 — Breaking Changes, die Sinn machen

Cosmos DB Java: Kritischer Sicherheitsfix (RCE)

Neue Provisioning-Bibliotheken für .NET

Fazit

Der Azure MCP Server ist jetzt ein .mcpb — Ohne Runtime Installieren

Was ist ein MCP Bundle?

Installation

Was du damit machen kannst

Erste Schritte

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

Die GPT-5-Progression

Der Deployment-Ablauf mit `azd`