Agents | The .NET Blog

NL2SQL ist die SQL-Injection des agentischen Zeitalters

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Es gibt eine Version des NL2SQL-Versprechens, die perfekt klingt: Benutzer stellen Fragen in natürlicher Sprache, Agenten generieren SQL, Daten kommen zurück. Weniger Bildschirme, weniger Abfragen, weniger Code. Einfach.

Dann denken Sie fünf weitere Minuten darüber nach.

Die Probleme, über die niemand in der Demo spricht

Schemas wurden nicht dafür entworfen, Dinge zu erklären. Kryptische Tabellennamen, inkonsistente Spaltennamen, technisch gültige Beziehungen, die ohne zusätzliche Prädikate semantisch ungültig sind — das ist normal bei Unternehmensdatenbanken. Das sind keine Bugs, das ist einfach die angesammelte Geschichte von Geschäftsänderungen. Aber wenn Sie ein Modell bitten, Absicht aus einem Schema abzuleiten, das nicht dafür entworfen wurde, Absicht zu kommunizieren, wird das Modell es trotzdem versuchen. Es gibt nicht auf. Es generiert seine bestmögliche Abfrage und gibt Ergebnisse mit Zuversicht zurück.

Modelle sind nicht deterministisch. Stellen Sie dieselbe Frage zur gleichen Datenbank zweimal und Sie könnten unterschiedliches SQL erhalten. Das Modell berechnet Wahrscheinlichkeiten, und leichte Kontextvariationen treiben unterschiedliche Ausgaben. Sie können sich nicht durch Tests zu einer Garantie vorarbeiten, dass der Agent immer die richtige Abfrage generiert.

Benutzerüberprüfung skaliert nicht. “Überprüfen Sie einfach jede Abfrage vor der Ausführung” klingt sicher. Aber das setzt voraus, dass Benutzer sowohl im Datenmodell als auch in SQL Experten sind — genau die Menschen, die die natürlichsprachliche Schnittstelle nicht brauchten. Es führt auch zu kognitiver Überlastung und einer neuen Klasse von Bestätigungsverzerrung, bei der Benutzer, die von der Abfragekomplexität überwältigt sind, ungültige Abfragen genehmigen, anstatt sie zu untersuchen.

Und dann gibt es Injection. In der traditionellen SQL-Entwicklung löste Parametrisierung Injection, weil Benutzereingaben Parameter füllten, nicht die SQL-Struktur. Mit NL2SQL generiert das Modell das SQL selbst. Der Prompt, der Schema-Kontext, der Konversationsverlauf und abgerufene Daten beeinflussen alle, was ausgeführt wird. Wenn jemand einen Prompt erstellt, der ändert, was das Modell generiert, das ist Injection — nicht auf Parameterebene, sondern auf der Ebene der Abfragegenerierung. Und anders als das Löschen einer Tabelle (offensichtlich, wiederherstellbar) erzeugt NL2SQL-Injection Abfragen, die falsche Ergebnisse ohne sichtbaren Fehler zurückgeben. Geschäftsentscheidungen werden auf falschen Daten getroffen.

Was SQL MCP Server tatsächlich löst

Hier macht der Artikel seinen nützlichsten praktischen Punkt. Anstatt einem Agenten beliebigen Schema-Zugriff zu geben und das Beste zu hoffen, stellt SQL MCP Server eine kuratierte API-Oberfläche auf Basis von Data API builder bereit.

Der Unterschied ist wichtig: Der Agent generiert kein SQL. Er ruft benannte Endpunkte auf, die vordefinierte Ergebnisformen zurückgeben. Das SQL wird einmal von einem Entwickler geschrieben und ist deterministisch. Das Nicht-Determinismus des Agenten ist auf die Auswahl welches Endpunkt aufgerufen wird, nicht auf das Konstruieren beliebiger Abfragen beschränkt.

Das ist analog zu dem, was Parametrisierung bei der SQL-Injection im traditionellen App-Modell getan hat — Sie entfernen die Fähigkeit, beliebige Abfragen aus nicht vertrauenswürdiger Eingabe zu konstruieren.

Die richtige Frage

Der Artikel sagt nicht “benutze NL2SQL nie.” Er sagt: Sei bewusst darüber, wo du es anwendest und was du exponierst. Für explorative Analyse in einer kontrollierten Umgebung, mit einem begrenzten Schema und Nur-Lese-Zugriff, könnte NL2SQL in Ordnung sein. Für Produktionssysteme, bei denen Geschäftsentscheidungen von den Ergebnissen abhängen, ist eine kuratierte API-Schicht deutlich sicherer.

Ehrlichkeit: Manche Probleme werden wirklich besser mit strukturierten Abfragen hinter benannten Endpunkten gelöst als mit natürlicher Sprache zu SQL. SQL MCP Server gibt Ihnen diese Option, ohne die agentische Schnittstelle vollständig aufzugeben.

Originalbeitrag: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

CodeAct im Agent Framework: Wie du die Latenz deines Agenten halbierst

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

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

Es gibt diesen Moment in jedem Agenten-Projekt, wo man auf den Trace schaut und denkt: „Warum dauert das so lange?" Das Modell ist gut. Die Tools funktionieren. Aber es gibt sieben Round Trips für ein Ergebnis, das man in einem Schritt berechnen könnte.

Genau dieses Problem löst CodeAct — und das Agent Framework Team hat soeben Alpha-Unterstützung dafür veröffentlicht mit dem neuen Paket agent-framework-hyperlight.

Was ist CodeAct?

Das CodeAct-Muster ist elegant einfach: Statt dem Modell eine Liste von Tools zu geben und sie einzeln aufrufen zu lassen, gibst du ihm ein einziges execute_code-Tool und lässt es den gesamten Plan als kurzes Python-Programm ausdrücken. Der Agent schreibt den Code einmal, die Sandbox führt ihn aus, und du erhältst ein einziges konsolidiertes Ergebnis zurück.

Ein Fünf-Schritte-Plan, der früher fünf Modell-Turns benötigte, wird zu einem einzigen execute_code-Turn mit einem Python-Script, das deine Tools über call_tool(...) aufruft.

Verdrahtung	Zeit	Tokens
Traditionell	27,81s	6.890
CodeAct	13,23s	2.489
Verbesserung	52,4%	63,9%

Die Sicherheitskomponente: Hyperlight Micro-VMs

Das Paket agent-framework-hyperlight verwendet Hyperlight Micro-VMs. Jeder execute_code-Aufruf erhält eine eigene frisch erstellte Micro-VM — mit eigenem Speicher, ohne Zugriff auf das Host-Dateisystem außer dem, was du explizit mountest. Der Start wird in Millisekunden gemessen. Die Isolierung ist im Grunde kostenlos.

Deine Tools laufen weiterhin auf dem Host. Der modellgenerierte Klebecode läuft in der Sandbox. Das ist die richtige Aufteilung.

Einrichtung

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Wann CodeAct verwenden (und wann nicht)

CodeAct verwenden, wenn:

Die Aufgabe viele kleine Tool-Aufrufe verkettet (Lookups, Joins, Berechnungen)
Latenz und Token-Kosten wichtig sind
Du starke Isolierung für modellgenerierten Code willst

Beim traditionellen Tool-Calling bleiben, wenn:

Der Agent nur ein oder zwei Tool-Aufrufe pro Turn macht
Jeder Aufruf Nebeneffekte hat, die einzeln genehmigt werden sollen
Tool-Beschreibungen spärlich oder mehrdeutig sind

Jetzt ausprobieren

pip install agent-framework-hyperlight --pre

Den vollständigen Beitrag findest du im Agent Framework Blog.

Wo Erinnert sich dein Agent an Dinge? Ein Praxisleitfaden zur Chat-Verlauf-Speicherung

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

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

Beim Aufbau eines KI-Agenten investierst du die meiste Energie in Modell, Tools und Prompts. Die Frage, wo der Gesprächsverlauf lebt, scheint ein Implementierungsdetail — ist aber eine der wichtigsten Architekturentscheidungen, die du treffen wirst.

Sie bestimmt, ob Nutzer Gespräche verzweigen, Antworten rückgängig machen, Sitzungen nach einem Neustart fortsetzen können und ob deine Daten deine Infrastruktur jemals verlassen.

Zwei grundlegende Muster

Service-managed: Der KI-Dienst speichert den Gesprächszustand. Deine App hält eine Referenz und der Dienst fügt automatisch den relevanten Verlauf in jede Anfrage ein.

Client-managed: Deine App verwaltet den vollständigen Verlauf und sendet relevante Nachrichten mit jeder Anfrage. Der Dienst ist zustandslos. Du kontrollierst alles.

Wie Agent Framework das abstrahiert

// C# — funktioniert gleich, unabhängig vom Provider
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mein Name ist Alice.", session);
var second = await agent.RunAsync("Wie ist mein Name?", session);

# Python
session = agent.create_session()
first = await agent.run("Mein Name ist Alice.", session=session)
second = await agent.run("Wie ist mein Name?", session=session)

Provider-Schnellreferenz

Provider	Speicherort	Modell	Komprimierung
OpenAI/Azure Chat Completions	Client	N/A	Du
Foundry Agent Service	Service	Linear	Service
Responses API (Standard)	Service	Verzweigend	Service
Anthropic Claude, Ollama	Client	N/A	Du

Wie du die Wahl triffst

Brauchst du Verzweigung oder „Rückgängig"? → Responses API service-managed
Brauchst du vollständige Datensouveränität? → Client-managed mit datenbankgestütztem Provider
Ist es ein einfacher Chatbot? → Service-managed linear reicht
Brauchst du Portabilität zwischen Providern? → Client-managed bietet Portabilität

Lies den vollständigen Beitrag für den vollständigen Entscheidungsbaum.

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.

VS Code 1.117: Agents Bekommen Eigene Git-Branches und Ich Bin Voll Dabei

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

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

Die Grenze zwischen „KI-Assistent" und „KI-Teamkollege" wird immer dünner. VS Code 1.117 ist gerade erschienen und die vollständigen Release Notes sind vollgepackt, aber die Geschichte ist klar: Agents werden zu erstklassigen Bürgern in deinem Entwicklungs-Workflow.

Hier ist, was wirklich zählt.

Autopilot-Modus merkt sich endlich deine Einstellung

Bisher musstest du Autopilot bei jeder neuen Session neu aktivieren. Nervig. Jetzt bleibt dein Berechtigungsmodus über Sessions hinweg bestehen, und du kannst den Standard konfigurieren.

Der Agent Host unterstützt drei Session-Konfigurationen:

Default — Tools fragen vor der Ausführung nach Bestätigung
Bypass — genehmigt alles automatisch
Autopilot — vollständig autonom, beantwortet eigene Fragen und macht weiter

Wenn du ein neues .NET-Projekt mit Migrationen, Docker und CI aufbaust — stell es einmal auf Autopilot und vergiss es. Diese Einstellung bleibt.

Worktree- und Git-Isolation für Agent-Sessions

Das ist der große Wurf. Agent-Sessions unterstützen jetzt volle Worktree- und Git-Isolation. Das bedeutet: Wenn ein Agent an einer Aufgabe arbeitet, bekommt er seinen eigenen Branch und sein eigenes Arbeitsverzeichnis. Dein Hauptbranch bleibt unangetastet.

Noch besser — Copilot CLI generiert aussagekräftige Branch-Namen für diese Worktree-Sessions. Kein agent-session-abc123 mehr. Du bekommst etwas, das tatsächlich beschreibt, was der Agent tut.

Für .NET-Entwickler, die mehrere Feature-Branches verwalten oder Bugs fixen, während eine lange Scaffolding-Aufgabe läuft, ist das ein Game Changer. Du kannst einen Agent deine API-Controller in einem Worktree aufbauen lassen, während du ein Problem in der Service-Schicht in einem anderen debuggst. Keine Konflikte. Kein Stashing. Kein Chaos.

Subagents und Agent-Teams

Das Agent Host Protocol unterstützt jetzt Subagents. Ein Agent kann andere Agents starten, um Teile einer Aufgabe zu übernehmen. Stell dir das als Delegieren vor — dein Haupt-Agent koordiniert, und spezialisierte Agents kümmern sich um die einzelnen Teile.

Das ist noch früh, aber das Potenzial für .NET-Workflows ist offensichtlich. Stell dir vor, ein Agent kümmert sich um deine EF Core-Migrationen, während ein anderer deine Integrationstests einrichtet. Wir sind noch nicht ganz da, aber dass der Protokoll-Support jetzt landet, bedeutet, dass die Tools schnell folgen werden.

Terminal-Output wird automatisch mitgeliefert, wenn Agents Input senden

Klein aber bedeutsam. Wenn ein Agent Input an das Terminal sendet, wird der Terminal-Output jetzt automatisch in den Kontext einbezogen. Vorher musste der Agent eine extra Runde drehen, nur um zu lesen, was passiert ist.

Wenn du jemals einem Agent zugesehen hast, wie er dotnet build ausführt, scheitert und dann noch einen Roundtrip braucht, nur um den Fehler zu sehen — diese Reibung ist weg. Er sieht den Output sofort und reagiert.

Die Agents-App auf macOS aktualisiert sich selbst

Die eigenständige Agents-App auf macOS aktualisiert sich jetzt selbst. Kein manuelles Herunterladen neuer Versionen mehr. Sie bleibt einfach aktuell.

Die kleineren Dinge, die es wert sind zu wissen

package.json-Hovers zeigen jetzt sowohl die installierte Version als auch die neueste verfügbare. Nützlich, wenn du npm-Tooling neben deinen .NET-Projekten verwaltest.
Bilder in JSDoc-Kommentaren werden in Hovers und Completions korrekt gerendert.
Copilot CLI-Sessions zeigen jetzt an, ob sie von VS Code oder extern erstellt wurden — praktisch, wenn du zwischen Terminals springst.
Copilot CLI, Claude Code und Gemini CLI werden als Shell-Typen erkannt. Der Editor weiß, was du ausführst.

Das Fazit

VS Code 1.117 ist kein auffälliger Feature-Dump. Es ist Infrastruktur. Worktree-Isolation, persistente Berechtigungen, Subagent-Protokolle — das sind die Bausteine für einen Workflow, in dem Agents echte, parallele Aufgaben erledigen, ohne deinen Code zu beeinträchtigen.

Wenn du mit .NET baust und dich noch nicht auf den agentischen Workflow eingelassen hast, ehrlich gesagt, jetzt ist der richtige Zeitpunkt.

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.

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.

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.

VS Code 1.116 — Agents App Bekommt Tastaturnavigation und Dateikontext-Vervollständigungen

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

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

VS Code 1.116 ist das April 2026-Release, und obwohl es leichter ausfällt als einige neuere Updates, sind die Änderungen fokussiert und bedeutsam — besonders wenn ihr die Agents App täglich nutzt.

Hier ist, was gelandet ist, basierend auf den offiziellen Release Notes.

Verbesserungen der Agents App

Die Agents App reift weiter mit Usability-Verfeinerungen, die im täglichen Workflow einen echten Unterschied machen:

Dedizierte Tastenkürzel — ihr könnt jetzt die Changes-Ansicht, den Dateibaum innerhalb von Changes und die Chat-Personalisierungsansicht mit dedizierten Befehlen und Tastenkürzeln fokussieren. Wenn ihr bisher in der Agents App herumgeklickt habt, bringt das vollständig tastaturgesteuerte Workflows.

Barrierefreiheits-Hilfedialog — das Drücken von Alt+F1 im Chat-Eingabefeld öffnet jetzt einen Barrierefreiheits-Hilfedialog, der verfügbare Befehle und Tastenkürzel anzeigt. Screenreader-Nutzer können auch die Ausführlichkeit der Ansagen steuern. Gute Barrierefreiheit nützt allen.

Dateikontext-Vervollständigungen — tippt # im Agents App Chat, um Dateikontext-Vervollständigungen für euren aktuellen Workspace auszulösen. Das ist eine dieser kleinen Quality-of-Life-Verbesserungen, die jede Interaktion beschleunigen — keine vollständigen Dateipfade mehr beim Verweisen auf Code.

CSS `@import` Link-Auflösung

Schön für Frontend-Entwickler: VS Code löst jetzt CSS @import-Referenzen auf, die node_modules-Pfade verwenden. Ihr könnt durch Imports wie @import "some-module/style.css" mit Ctrl+Klick navigieren, wenn ihr Bundler nutzt. Klein, aber es eliminiert einen Reibungspunkt in CSS-Workflows.

Fazit

VS Code 1.116 dreht sich um Verfeinerung — die Agents App navigierbarer, barrierefreier und tastaturfreundlicher zu machen. Wenn ihr viel Zeit in der Agents App verbringt (und ich vermute, das tun viele von uns), summieren sich diese Änderungen.

Schaut euch die vollständigen Release Notes für die komplette Liste 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.

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.

Agents | The .NET Blog

NL2SQL ist die SQL-Injection des agentischen Zeitalters

Die Probleme, über die niemand in der Demo spricht

Was SQL MCP Server tatsächlich löst

Die richtige Frage

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

CodeAct im Agent Framework: Wie du die Latenz deines Agenten halbierst

Was ist CodeAct?

Die Sicherheitskomponente: Hyperlight Micro-VMs

Einrichtung

Wann CodeAct verwenden (und wann nicht)

Jetzt ausprobieren

Wo Erinnert sich dein Agent an Dinge? Ein Praxisleitfaden zur Chat-Verlauf-Speicherung

Zwei grundlegende Muster

Wie Agent Framework das abstrahiert

Provider-Schnellreferenz

Wie du die Wahl triffst

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

Was ist eine Toolbox?

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

Praktisches Beispiel

Kein Lock-in bei Foundry Agents

Warum das jetzt wichtig ist

Fazit

VS Code 1.117: Agents Bekommen Eigene Git-Branches und Ich Bin Voll Dabei

Autopilot-Modus merkt sich endlich deine Einstellung

Worktree- und Git-Isolation für Agent-Sessions

Subagents und Agent-Teams

Terminal-Output wird automatisch mitgeliefert, wenn Agents Input senden

Die Agents-App auf macOS aktualisiert sich selbst

Die kleineren Dinge, die es wert sind zu wissen

Das Fazit

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

Die sechs Optionen auf einen Blick

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

Deployment ist wirklich einfach

Integriertes Konversationsmanagement

Mein Entscheidungsframework

Zum Abschluss

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

Was ist Azure MCP Server?

Das Wichtigste: Self-Hosted Remote Deployments

Security Hardening

Wo kannst du es verwenden?

Warum das für .NET-Entwickler wichtig ist

Erste Schritte

Zusammenfassung

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

Was Git-APE tatsächlich macht

Warum das wichtig ist

Meine Einschätzung

Zusammenfassung

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

Foundry Agent Service ist produktionsreif

GPT-5.4 — Zuverlässigkeit über reine Intelligenz

Das SDK ist endlich stabil

Fireworks AI bringt offene Modelle nach Azure

Weitere Highlights

Fazit

VS Code 1.116 — Agents App Bekommt Tastaturnavigation und Dateikontext-Vervollständigungen

Verbesserungen der Agents App

CSS @import Link-Auflösung

Fazit

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

KI-Agenten ausführen und debuggen ohne Deployment

GitHub Copilot richtet dein azd-Projekt ein

Container App Jobs und Deployment-Verbesserungen

DX-Verbesserungen

Zusammenfassung

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

Gebaut auf der Responses API

Private Networking: der Enterprise-Blocker beseitigt

MCP-Authentifizierung richtig gemacht

Voice Live: Sprache-zu-Sprache ohne das Leitungswirrwarr

Evaluierungen: von der Checkbox zum kontinuierlichen Monitoring

CSS `@import` Link-Auflösung