Ai | 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?

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

Das Handoff-Muster: Wenn Ein Agent Nicht Ausreicht

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

Irgendwann überwächst jedes Multi-Agent-System einen einfachen Router. Das erste Anzeichen ist meist, wenn ein Spezialistenagent eine Folgefrage stellen muss oder mitten im Zug erkennt, dass ein anderer Agent weitermachen sollte. Eine feste Pipeline scheitert dort. Ein Ein-Schuss-Router scheitert dort.

Genau das ist das Problem, für das das Handoff-Orchestrierungsmuster in Microsoft Agent Framework konzipiert wurde.

Wie Handoff Funktioniert

Der Entwickler deklariert einen Graphen: Hier sind die Agenten, hier sind die Kanten zwischen ihnen. Das Framework erledigt den Rest — es synthetisiert pro ausgehende Kante ein Handoff-Tool und injiziert es in jeden Agenten. Wenn ein Agent entscheidet, die Kontrolle abzugeben, ruft er das Tool auf. Das Framework setzt die Topologie durch.

Drei Dinge unterscheiden das von einfachem gegenseitigen Aufrufen der Agenten:

Ein gemeinsames Transkript — der empfangende Agent sieht den gesamten Gesprächsverlauf. Kein Neustart von Null.
Topologiedurchsetzung — ein Agent kann nur an deklarierte Ziele übergeben. Routing-Bugs werden beim Erstellen erkannt, nicht in der Produktion.
Natürliche Beendigung — wenn der aktive Agent seinen Zug beendet, ohne ein Handoff-Tool aufzurufen, gibt der Workflow an den Benutzer ab. Kein Polling, keine expliziten Exit-Bedingungen.

Ein Minimales Beispiel

In .NET sieht das Erstellen eines Handoff-Workflows so aus:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage kann an jeden Spezialisten senden. Beide Spezialisten können zurück zu Triage senden. Der Graph ist azyklisch-freundlich, unterstützt aber Rückkanten wenn Sie sie brauchen (“Ich brauche mehr Informationen” → zurück zur Recherche).

Wann Handoff Verwenden (und Wann Nicht)

Handoff ist eine gute Wahl wenn:

Ownership sich mitten im Gespräch ändern kann — ein Agent erkennt möglicherweise, dass er der falsche Spezialist ist
Rückkanten wichtig sind — Sie müssen möglicherweise einen früheren Schritt erneut aufsuchen, ohne neu zu starten
Routing-Entscheidungen unscharf sind — die Entscheidung zum Handoff ist kontextuell und vom Modell besser getroffen als durch typisierte Prädikate

Es ist nicht die richtige Wahl wenn:

Ihre Pipeline fest und sequentiell ist — verwenden Sie dafür den Sequential-Workflow
Jeder Schritt unabhängig ist — Agenten, die ein Transkript teilen, wo nur einer davon es brauchte, ist nur Rauschen
Sie strenge Verarbeitungsgarantien benötigen — der Nichtdeterminismus des modellgesteuerten Routings ist nicht das, was Sie wollen

Rückkanten und Human-in-the-Loop

Eine der interessanteren Formen, die Handoff ermöglicht, sind echte Rückkanten. Ein Agent kann entscheiden “Ich habe nicht genug Informationen” und zu einem Rechercheschritt zurückrouten, nicht mit einer harkodierten Schleife, sondern weil das Modell entscheidet, dass es der richtige Schritt ist.

Human-in-the-Loop-Interaktionen komponieren sich ebenfalls natürlich. Wenn ein Spezialist Benutzereingaben benötigt, gibt der Workflow über die Standard-Zugschleife zurück an den Benutzer, sammelt die Antwort und setzt mit vollständigem Kontext fort. Der Agent hat die Konversation nie verloren.

Fazit

Handoff ist eines dieser Muster, das einfach klingt, aber viel ermöglicht, sobald man es verinnerlicht hat: dezentrales Routing, gemeinsamer Kontext, erzwungene Topologie, natürliche Beendigung. Es ist der richtige nächste Schritt, wenn Ihre Agenten anfangen zu sagen “eigentlich sollte das jemand anderes übernehmen.”

Lesen Sie den vollständigen Durchgang im Originalbeitrag: A Tour of the Handoff Orchestration Pattern

Langlebige Workflows in Microsoft Agent Framework: Von In-Memory zu Azure Functions

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

Einer der Schmerzpunkte bei frühen KI-Agent-Workflows: Sie sind fragil. Ein lang laufender Multi-Step-Workflow, der an einen einzelnen Prozess gebunden ist, bedeutet, dass Prozessneustart = verlorener Zustand. Für einfache Demos ist das in Ordnung. Für Produktionsworkloads ist es das nicht.

Das Workflow-Programmiermodell von Microsoft Agent Framework unterstützt jetzt dauerhafte Ausführung, gesichert durch das Durable Task-Framework, mit Azure Functions-Hosting. Hier erfahren Sie, wie das Programmiermodell funktioniert und warum die Dauerhaftigkeitsgeschichte wichtig ist.

Die grundlegenden Bausteine

Executors sind die fundamentale Arbeitseinheit. Jeder ist typisiert — er nimmt eine bestimmte Eingabe und produziert eine bestimmte Ausgabe:

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // Bestellung nachschlagen, zurückgeben
 return new Order(Id: message.OrderId, ...);
 }
}

Workflows verbinden Executors zu gerichteten Graphen mit einem Fluent Builder. Das Framework übernimmt die Ausführung, den Datenfluss zwischen Schritten und die Fehlerfortpflanzung.

Sie können modellieren:

Sequentielle Ketten (Schritt A → Schritt B → Schritt C)
Paralleles Fan-out/Fan-in (Agenten A, B, C parallel ausführen, Ergebnisse aggregieren)
Bedingte Verzweigung
Human-in-the-Loop-Genehmigungen (Workflow pausieren, auf externes Signal warten)

Der In-Memory-Runner für lokale Entwicklung

Der Einstieg ist schnell:

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

Das Kernpaket enthält einen leichtgewichtigen In-Process-Runner. Keine externen Abhängigkeiten, keine Datenbank, keine Azure-Ressourcen. Funktioniert hervorragend für lokale Entwicklung und Unit-Tests.

Dauerhaftigkeit mit Durable Task hinzufügen

Wenn ein Workflow Prozessneustarts überleben muss — weil er lang läuft, weil er Human-in-the-Loop-Schritte hat, weil er auf viele parallele Agent-Aufrufe verteilt wird — reicht der In-Memory-Runner nicht aus.

MAFs Durable Task-Integration speichert den Workflow-Zustand in Azure Storage. Wenn der Prozess neu startet, wird der Workflow von dort fortgesetzt, wo er aufgehört hat. Das Programmiermodell bleibt gleich; Sie tauschen nur den Runner aus.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Dieselben Executors, derselbe Workflow-Graph — gesichert durch dauerhaften Zustand.

Azure Functions-Hosting

Die dritte Schicht ist das Azure Functions-Hosting. Ihr Workflow wird zu einer Function-App: Lösen Sie den Workflow über einen HTTP-Endpoint aus, und die dauerhafte Laufzeit kümmert sich um Skalierung, Zustand und Zuverlässigkeit.

Das bedeutet, dass ein Multi-Agent-Workflow mit parallelen Aufrufen, bedingten Verzweigungen und menschlichen Genehmigungen über eine serverlose Functions-Umgebung skalieren kann, ohne benutzerdefinierte Zustandsverwaltung.

Warum das wichtig ist

Die Kombination ist bedeutsam für echte KI-Systeme:

Parallele Agent-Aufrufe — gleichzeitig auf mehrere spezialisierte Agenten verteilen ohne Blockierung, Ergebnisse aggregieren wenn alle abgeschlossen sind
Lang laufende Prozesse — Workflows, die menschliche Genehmigung oder externe Ereignisse beinhalten, können über Stunden oder Tage pausieren und fortgesetzt werden
Skalierung — Azure Functions skaliert die Ausführung horizontal; das Durable Task-Framework koordiniert den parallelen Zustand

Wenn Sie MAF-Workflows über einfache lokale Demos hinaus erstellen, ist dies der Weg zur produktionsreifen Ausführung.

Originalbeitrag: Durable Workflows in the Microsoft Agent Framework

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

Agenten Zu Bauen Ist Der Einfache Teil — Sie Sicher Zu Betreiben Ist Der Schwierige Teil

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Es gibt ein Muster in der KI-Agenten-Entwicklung, das ich begonnen habe, „Demo-Bedauern" zu nennen. Der Agent funktioniert in Demos hervorragend. Dann fragt jemand: Was passiert, wenn er das falsche Tool aufruft? Was wenn er auf Daten zugreift, auf die er nicht sollte? Wer hat das geprüft?

Microsoft Agent Framework unterstützt Sie beim Aufbau und der Orchestrierung. Agent Governance Toolkit (AGT) deckt den Teil danach ab — Governance, Richtliniendurchsetzung und Prüfbarkeit zur Laufzeit.

Was Jedes Projekt Wirklich Macht

Microsoft Agent Framework (MAF) bietet Ihnen das Programmiermodell: Multi-Agenten-Workflows, A2A-Protokoll-Interoperabilität, Middleware-Hooks, Speicher und verwaltetes Hosting über Foundry Agent Service. Es behandelt Content-Sicherheit auf der Ebene der Modell-Ein-/Ausgabe.

Agent Governance Toolkit (AGT) verbindet sich mit demselben Middleware-Pipeline, um Aktionen zu steuern. Jeder Tool-Aufruf, Ressourcenzugriff und Inter-Agenten-Nachricht wird vor der Ausführung gegen die Richtlinie bewertet. Sub-Millisekunden-Overhead. Keine Sidecars, keine Proxies, keine geänderten Prompts.

Agenten-Aktion --> Richtlinienprüfung --> Erlauben / Ablehnen --> Audit-Log (< 0.1 ms)

Verschiedene Schichten, vollständige Abdeckung, eine Pipeline.

Die Einbindung Ist Nur Middleware Hinzufügen

In Python fügt AGT denselben middleware-Parameter hinzu, den Sie für Protokollierung oder Inhaltsfilter verwenden würden:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

In .NET dasselbe Muster via .Use():

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Gleicher Agent, gleiche Orchestrierung, gleiche Tools. AGT fügt Governance-Funktionen hinzu, ohne die Agentenlogik zu berühren.

Was Sie Bekommen

GovernancePolicyMiddleware — bewertet jede Aktion gegen deklarative Richtlinienregeln
CapabilityGuardMiddleware — Allowlist, welche Tools ein Agent aufrufen darf (das Tool approve_small_loan ist oben nicht in der Allowlist — absichtlich)
RogueDetectionMiddleware — erkennt anomale Verhaltensmuster zur Laufzeit
AuditTrailMiddleware — Merkle-verkettetes Audit-Log, damit jede Aktion kryptografisch manipulationssicher ist

Letzteres ist für die Compliance wichtig. Eine Merkle-Kette bedeutet: Wenn jemand das Log ändert, bricht die Kette. Das Audit ist der Beweis.

Fünf Branchenszenarien

Das AGT-Repository enthält fünf vollständige End-to-End-Szenarien: Finanzdienstleistungen (Kreditsachbearbeiter), Gesundheitswesen (Patientendaten), Recht (Vertragsüberprüfung), Regierung (Bürgerdienste) und Fertigung (Qualitätskontrolle). Jedes kombiniert echte MAF-Agenten mit echter AGT-Governance-Middleware.

Das sind keine Spielzeug-Demos. Das sind die Szenarien, bei denen Sie in der Produktion tatsächlich Governance benötigen würden.

Fazit

Wenn Sie Agenten entwickeln, die echte Daten berühren, Entscheidungen mit Konsequenzen treffen oder unbeaufsichtigt in der Produktion laufen — Governance ist nicht optional. Die Kombination MAF + AGT gibt Ihnen den vollständigen Stack: Mit Agent Framework bauen, mit AGT verwalten.

Beide Projekte sind Open Source. Der Originalartikel enthält Links zu den vollständigen Code-Beispielen.

Originalbeitrag: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

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

Azure SQL Kann Jetzt Embeddings Generieren — In Reinem T-SQL, Keine Anwendungsschicht Erforderlich

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

Wenn Sie jemals eine RAG-Pipeline gebaut haben, kennen Sie die Pipeline-Steuer: Ihre Daten leben in SQL, aber um Embeddings zu generieren, müssen Sie sie extrahieren, eine Embedding-API aufrufen, Batching und Ratenlimits handhaben und die Ergebnisse irgendwo vektorsuchtauglich speichern. Oft in einer völlig anderen Datenbank.

Azure SQL hat das meiste davon gerade mit zwei Features eliminiert, die jetzt allgemein verfügbar sind: CREATE EXTERNAL MODEL und AI_GENERATE_EMBEDDINGS.

Was Sie Tun

Diese beiden T-SQL-Features funktionieren als integrierte Pipeline:

CREATE EXTERNAL MODEL — registriert einen externen KI-Modell-Endpoint als benanntes Datenbankobjekt. Sie legen Ort, API-Format, Modelltyp und Anmeldeinformationen einmal fest. Überall wiederverwendbar.

AI_GENERATE_EMBEDDINGS — eine skalare T-SQL-Funktion, die das registrierte Modell aufruft und ein JSON-Array von Vektorwerten zurückgibt. Funktioniert in SELECT-, INSERT-, UPDATE- und MERGE-Anweisungen.

Zusammen bilden sie eine End-to-End-Embedding-Pipeline ohne die SQL-Engine zu verlassen.

Der Vollständige Workflow

-- Schritt 1: Registrieren Sie Ihren Embedding-Anbieter einmal
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Schritt 2: Embeddings inline in T-SQL generieren
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Schritt 3: Mit Vektorabstand suchen
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Das ist die gesamte Pipeline: Daten in SQL, Embeddings in SQL generiert, Ähnlichkeitssuche in SQL. Keine Orchestrierungsschicht, kein ETL, keine separate Vektordatenbank.

Unterstützte API-Formate und Optionen

In der GA-Version unterstützt API_FORMAT Azure OpenAI und OpenAI. MODEL_TYPE ist derzeit auf EMBEDDINGS beschränkt. Das PARAMETERS-JSON ermöglicht das Festlegen von Standardwerten auf Modellebene einschließlich der Anzahl der Wiederholungsversuche:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

Die Authentifizierung verwendet Datenbankzugangsdaten, sodass Geheimnisse aus Ihrem Anwendungscode herausgehalten werden.

Was Dies für .NET-Anwendungen Ermöglicht

Für .NET-Entwickler, die KI-Features auf vorhandenen SQL-Daten aufbauen, ist dies bedeutsam. Sie müssen nicht:

Daten für Embeddings in einen Zwischenspeicher extrahieren
Eine externe Embedding-Pipeline verwalten
Eine separate Vektordatenbank einrichten (obwohl Sie Azure AI Search verwenden können, wenn Sie einen vollwertigen Vektorspeicher möchten)
Die Datenzugriffsschicht Ihrer Anwendung ändern

Sie können semantische Suche zu bestehenden SQL-Anwendungen inkrementell hinzufügen, mit denselben T-SQL-Tools, die Sie bereits haben.

Fazit

RAG-Muster auf SQL-Daten sind dramatisch einfacher geworden. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL bedeutet, dass Ihre bestehende SQL-Anwendung Vektorsuche-Fähigkeiten ohne neue Infrastruktur erwerben kann.

Beide Features sind heute in Azure SQL Database und Azure SQL Managed Instance allgemein verfügbar.

Originalbeitrag: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

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

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.

Eine KI-gestützte Konferenz-App mit dem komponierbaren .NET-Stack erstellen

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

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

Eine KI-gestützte Konferenz-App mit dem komponierbaren .NET-Stack erstellen — Microsoft hat ConferencePulse entwickelt, eine Blazor Server-App für Live-Konferenzsessions, indem fünf .NET-Erweiterungsbibliotheken kombiniert wurden. Sie wurde auf dem MVP Summit eingesetzt.

Was ConferencePulse leistet

ConferencePulse läuft während Live-Sessions und bietet: KI-generierte Umfragen aus dem Session-Inhalt, Publikums-Q&A mit einer RAG-Pipeline, die aus einer Live-Wissensdatenbank schöpft, automatisch generierte Erkenntnisse und Session-Zusammenfassungen, die von mehreren gleichzeitig laufenden KI-Agenten erstellt werden. Der Stack ist .NET 10, Blazor Server, Aspire, aufgeteilt auf fünf Projekte: Web, Core, Ingestion, Agents, Mcp und AppHost.

Microsoft.Extensions.AI: eine Abstraktion für alles

IChatClient ist die einheitliche Abstraktion — einmal eingerichtet, funktioniert dieselbe Schnittstelle für Azure OpenAI, OpenAI, Anthropic oder jeden anderen Anbieter. Sechs Zeilen für einen vollständig konfigurierten Client mit Funktionsaufruf, OpenTelemetry-Tracing und Logging-Middleware:

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

Derselbe IChatClient wird später für den Anreicherungsschritt der Datenaufnahme wiederverwendet — kein separater Client dafür nötig.

DataIngestion-Pipeline

Session-Inhalte fließen durch eine Pipeline: MarkdownReader → HeaderChunker (500 Token, 50 Token Überlappung) → SummaryEnricher + KeywordEnricher → VectorStoreWriter (Qdrant). Die Anreicherungskomponenten verwenden denselben IChatClient, um Zusammenfassungen zu generieren und Schlüsselwörter vor der Indexierung zu extrahieren. Publikumsfragen, Q&A-Paare und Umfrageergebnisse werden in Echtzeit aufgenommen, während die Session fortschreitet — die Wissensdatenbank wächst während des Vortrags.

VectorData: anbieterunabhängige Suche

VectorStoreCollection.SearchAsync() funktioniert gleich, egal ob der zugrunde liegende Speicher Qdrant oder Azure AI Search ist. Hybridsuche (Vektor + Volltext) wird unterstützt. Die RAG-Pipeline für Publikums-Q&A fragt diese Sammlung ab und erhält relevante Chunks, die als Kontext an den Chat-Client weitergegeben werden.

MCP: Session-Inhalt als Tools

Der Session-Inhalt wird über MCP bereitgestellt, sodass jeder MCP-kompatible Client darauf zugreifen kann. Sowohl Server als auch Client sind implementiert — der Server stellt Session-Wissen als MCP-Tools bereit, und der Client ermöglicht das Aufrufen dieser Tools innerhalb der Agenten-Pipeline.

Agent Framework: parallele Multi-Agent-Zusammenfassung

Die Session-Zusammenfassung wird von drei gleichzeitig laufenden Agenten generiert — PollSummaryAgent, QuestionSummaryAgent und InsightSummaryAgent — und dann zusammengeführt. Dies verwendet das Gruppen-Chat- oder parallele Ausführungsmuster aus dem Microsoft Agent Framework. Jeder Agent behandelt einen Aspekt; der Orchestrator fügt die Ausgaben zusammen.

Das Designprinzip

Der Beitrag macht einen bemerkenswerten Punkt: Verwende das einfachste Tool, das passt. Direkte IChatClient-Aufrufe für einfache Generierungsaufgaben. Tool-/Funktionsaufruf für strukturierte Datenextraktion. Vollständige Agenten nur, wenn autonomes mehrstufiges Reasoning benötigt wird. Die Bibliotheksschichtung erzwingt dies — du kannst Microsoft.Extensions.AI verwenden, ohne das vollständige Agent Framework einzubinden.

Siehe den vollständigen Beitrag für die vollständige Projektstruktur und Quellcode-Links.

Microsoft Agent Framework Teil 3: Von Tools zu Workflows — Die Bausteine fügen sich zusammen

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

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

Wenn du der Building Blocks for AI in .NET-Serie gefolgt bist, weißt du: Teil 1 brachte uns IChatClient (die universelle Modellschnittstelle) und Teil 2 Microsoft.Extensions.VectorData (semantische Suche und RAG). Beides sind grundlegende Bausteine, jeder für sich nützlich. Aber hier beginnt alles, sich zu verbinden.

Teil 3 dreht sich um das Microsoft Agent Framework — und ehrlich gesagt ist es genau das Stück, auf das ich in .NET gewartet habe. Version 1.0 erschien im April. Die API ist stabil. Es ist Zeit, echte Agenten zu bauen.

Was ein Agent wirklich ist (vs. ein Chatbot)

Bevor wir in den Code einsteigen, klären wir diesen Unterschied. Ein Chatbot empfängt Input, ruft ein Modell auf, gibt Output zurück. Einfache Schleife.

Ein Agent hat Autonomie. Er kann über eine Aufgabe nachdenken, entscheiden, welche Tools er verwenden soll, diese aufrufen, Ergebnisse auswerten und entscheiden, was als nächstes zu tun ist — alles ohne explizite Schritt-für-Schritt-Logik von deiner Seite. Du gibst ihm Tools und Anweisungen, und er kümmert sich um die Orchestrierung.

Stell es dir so vor: IChatClient ist wie ein Gespräch. Ein Agent ist wie das Delegieren einer Aufgabenliste an jemanden.

Dein erster Agent in 10 Zeilen

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

Die .AsAIAgent()-Erweiterungsmethode ist die Brücke. Dasselbe Muster wie .AsIChatClient() von MEAI — es verpackt das SDK des Anbieters in eine stabile Abstraktion. Funktioniert mit Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry oder lokalen Modellen.

Streaming funktioniert ebenfalls:

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

Dem Agenten Tools geben

Hier hören Agenten auf, ausgefeilte Chatbots zu sein. Tools sind Funktionen, die das Modell je nach Benutzeranfrage aufrufen kann. Du brauchst keine Routing-Logik — das Modell findet es selbst heraus.

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

Zwei Dinge zu beachten. Erstens: AIFunctionFactory kommt von MEAI — dieselbe Tool-Factory, die du mit einem normalen IChatClient verwenden würdest. Bereits definierte Tools für Chat-Szenarien funktionieren hier auch.

Zweitens: Die Description-Attribute sind sehr wichtig. So versteht das Modell, was ein Tool macht und wann es eingesetzt werden soll. Behandle sie als Dokumentation für deine KI, nicht für Menschen.

Sessions: Gespräche mit echtem Gedächtnis

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

Ohne Session ist jeder RunAsync-Aufruf zustandslos. Mit Session weiß der Agent, auf welchen Witz du dich beziehst. AgentSession bewahrt den Gesprächsverlauf zwischen den Turns.

Für zustandslose Produktionsdienste lassen sich Sessions sauber serialisieren:

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... irgendwo speichern ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

Das ist entscheidend, wenn dein Agent in einer serverlosen oder horizontal skalierten Umgebung läuft.

AIContextProvider: Persistentes Gedächtnis über Sessions hinaus

Sessions bewahren den Gesprächsverlauf innerhalb einer Session. Aber was ist mit Wissen über einen Benutzer über mehrere Sessions hinweg? Dafür ist AIContextProvider zuständig.

Er hat zwei Hooks:

ProvideAIContextAsync — läuft vor jeder Interaktion, injiziert Kontext in den Agenten
StoreAIContextAsync — läuft nach jeder Interaktion, ermöglicht Lernen und Persistierung

Das Muster ist elegant: Du kannst mehrere Provider stapeln — einer für Benutzerpräferenzen, einer für kürzliche Interaktionen, einer der deinen VectorData-Store nach relevanten Dokumenten abfragt. Letzteres ist genau das RAG-Muster aus Teil 2, das jetzt automatisch bei jedem Agenten-Aufruf ausgeführt wird.

Multi-Agenten-Workflows

Hier verdient das Framework seinen Namen. Es enthält ein graphenbasiertes Workflow-System, in dem Executors (Agenten, Funktionen, was auch immer) über Kanten verbunden werden.

Nativ unterstützte Muster:

Sequenziell: Die Ausgabe von Agent A speist Agent B
Parallel (Fan-out/Fan-in): Dispatchiert parallel an mehrere Agenten, sammelt Ergebnisse
Bedingtes Routing: Leitet Arbeit je nach Ausgabe an unterschiedliche Agenten weiter
Schreiber-Kritiker-Schleifen: Ein Agent schreibt, ein anderer bewertet, Schleife bis zur Genehmigung
Sub-Workflows: Hierarchisches Komponieren von Workflows

Ein Schreiber-Kritiker-Beispiel:

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

Sauber, lesbar, und das bedingungsbasierte Routing bedeutet, dass du die Schleifenlogik nicht selbst schreibst.

Human-in-the-Loop

Nicht alles sollte vollständig autonom laufen. Für sensible Operationen — Datenbankschreibvorgänge, Finanztransaktionen, Kommunikationsversendungen — möchtest du, dass ein Mensch genehmigt, bevor der Agent ausführt.

Das Framework hat dafür eingebaute Unterstützung via FunctionApprovalRequestContent und FunctionApprovalResponseContent. Der Agent schlägt den Tool-Aufruf vor, dein Anwendungscode präsentiert ihn dem Benutzer, und die Antwort entscheidet, ob die Ausführung fortgesetzt wird.

Das ist die richtige Art, in Unternehmensumgebungen über Agenten nachzudenken: nicht vollständig autonom, sondern Autonomie mit Leitplanken.

Das Gesamtbild

Wenn du einen Schritt zurückgehst:

MEAI gibt dir eine universelle Schnittstelle zu jedem Modell
VectorData gibt deinen Agenten Zugriff auf das Wissen deiner Organisation durch semantische Suche
Agent Framework orchestriert alles — verwendet intern IChatClient, kombiniert sich mit Kontext-Providern und koordiniert durch Workflows

Jedes Teil wurde darauf ausgelegt, mit den anderen zu komponieren. Schau dir den Originalbeitrag von Jeremy Likness und das Agent Framework GitHub-Repository für die vollständigen Beispiele an.

Fazit

Der Microsoft Agent Framework Teil 3 schließt den Kreis der Building Blocks-Serie. Für .NET-Entwickler, die KI-Agenten bauen wollen — keine Chatbots, echte Agenten, die Tools verwenden, Dinge merken und koordinieren — das ist dein Weg nach vorne.

Der stabile 1.0-Release bedeutet, dass du damit in der Produktion bauen kannst. Wenn du darauf gewartet hast, in die Agentenentwicklung in .NET einzusteigen, ist jetzt der richtige Zeitpunkt.

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.

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.

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.

Windows App Dev CLI v0.3: F5 aus dem Terminal und UI-Automatisierung für Agenten

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

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

Die F5-Erfahrung von Visual Studio ist großartig. Aber VS nur zum Starten und Debuggen einer gepackten Windows-App öffnen zu müssen, ist zu viel — egal ob man in einer CI-Pipeline ist, einen automatisierten Workflow ausführt oder ein KI-Agent die Tests durchführt.

Windows App Development CLI v0.3 wurde veröffentlicht und adressiert das direkt mit zwei Hauptfunktionen: winapp run und winapp ui.

winapp run: F5 von überall

winapp run nimmt einen ungepackten App-Ordner und ein Manifest und erledigt alles, was VS beim Debug-Start tut: registriert ein Loose-Paket, startet die App und bewahrt den LocalState zwischen Re-Deploys.

# App bauen, dann als gepackte App starten
winapp run ./bin/Debug

Funktioniert für WinUI, WPF, WinForms, Console, Avalonia und mehr. Die Modi sind für Entwickler und automatisierte Workflows ausgelegt:

--detach: Startet und gibt die Kontrolle sofort an das Terminal zurück. Ideal für CI.
--unregister-on-exit: Räumt das registrierte Paket beim App-Schließen auf.
--debug-output: Erfasst OutputDebugString-Meldungen und Ausnahmen in Echtzeit. Mit --symbols werden PDBs vom Microsoft Symbol Server geladen.

Neues NuGet-Paket: dotnet run für gepackte Apps

Für .NET-Entwickler gibt es ein neues NuGet-Paket: Microsoft.Windows.SDK.BuildTools.WinApp. Nach der Installation handhabt dotnet run den gesamten Inner Loop: Build, Loose-Layout-Paket vorbereiten, bei Windows registrieren und starten — alles in einem Schritt.

# winapp init erledigt die Einrichtung
winapp init
# Oder direkt installieren
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

Funktioniert mit WinUI, WPF, WinForms, Console, Avalonia. Keine manuellen Schritte, nur dotnet run.

winapp ui: UI-Automatisierung aus der Kommandozeile

Das ist der Feature, der agentische Szenarien ermöglicht. winapp ui bietet vollständigen UI-Automatisierungszugriff auf jede laufende Windows-App — WPF, WinForms, Win32, Electron, WinUI3 — direkt aus dem Terminal.

Was möglich ist:

Alle Fenster der obersten Ebene auflisten
Den vollständigen UI-Automatisierungsbaum eines Fensters traversieren
Elemente nach Name, Typ oder Automatisierungs-ID suchen
Klicken, aufrufen und Werte setzen
Screenshots aufnehmen
Auf das Erscheinen von Elementen warten — ideal für Testsynchronisierung

winapp ui und winapp run kombiniert ergeben einen vollständigen Build → Start → Verifikation-Workflow aus dem Terminal. Ein Agent kann die App ausführen, den UI-Zustand prüfen, programmatisch interagieren und das Ergebnis validieren.

Weitere Neuerungen

winapp unregister: Entfernt ein sidegeladenes Dev-Paket nach dem Test.
winapp manifest add-alias: Fügt einen uap5:AppExecutionAlias hinzu, damit die App per Name aus dem Terminal gestartet werden kann.
Tab-Vervollständigung: Ein Befehl für die vollständige PowerShell-Vervollständigung.
Package.appxmanifest als Standard: winapp init erzeugt jetzt Package.appxmanifest (VS-Konvention) statt appxmanifest.xml.

Installation

winget install Microsoft.WinAppCli
# oder
npm install -g @microsoft/winappcli

Die CLI ist in Public Preview. Das GitHub-Repository enthält vollständige Dokumentation, und die ursprüngliche Ankündigung hat alle Details.

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.

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.

Docker Sandbox lässt Copilot-Agenten euren Code refactoren — ohne Risiko für eure Maschine

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

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

Wer Copilots Agent-Modus für mehr als kleine Änderungen genutzt hat, kennt den Schmerz. Jeder Dateischreibvorgang, jeder Terminal-Befehl — wieder eine Berechtigungsabfrage. Jetzt stellt euch das mal bei 50 Projekten vor. Macht keinen Spaß.

Das Azure-Team hat gerade einen Beitrag über Docker Sandbox für GitHub Copilot-Agenten veröffentlicht, und ehrlich gesagt ist das eine der praktischsten Verbesserungen für agentisches Tooling, die ich gesehen habe. Es nutzt MicroVMs, um Copilot eine vollständig isolierte Umgebung zu geben, in der er frei arbeiten kann — Pakete installieren, Builds ausführen, Tests laufen lassen — ohne euer Host-System zu berühren.

Was Docker Sandbox tatsächlich bietet

Die Kernidee ist simpel: Eine leichtgewichtige MicroVM mit einer vollständigen Linux-Umgebung hochfahren, euren Workspace hineinsynchronisieren und den Copilot-Agenten frei darin arbeiten lassen. Wenn er fertig ist, werden die Änderungen zurücksynchronisiert.

Das macht es zu mehr als nur “Sachen in einem Container ausführen”:

Bidirektionale Workspace-Synchronisation, die absolute Pfade beibehält. Eure Projektstruktur sieht innerhalb der Sandbox identisch aus. Keine pfadbedingten Build-Fehler.
Privater Docker-Daemon innerhalb der MicroVM. Der Agent kann Container bauen und ausführen, ohne jemals den Docker-Socket eures Hosts zu mounten. Das ist ein großer Sicherheitsgewinn.
HTTP/HTTPS-Filterproxys, die kontrollieren, was der Agent im Netzwerk erreichen kann. Ihr entscheidet, welche Registries und Endpoints erlaubt sind. Supply-Chain-Angriffe durch ein fragwürdiges npm install in der Sandbox? Geblockt.
YOLO-Modus — ja, so nennen sie das wirklich. Der Agent läuft ohne Berechtigungsabfragen, weil er buchstäblich euren Host nicht beschädigen kann. Jede destruktive Aktion ist eingedämmt.

Warum .NET-Entwickler aufhorchen sollten

Denkt an die Modernisierungsarbeit, vor der so viele Teams gerade stehen. Ihr habt eine .NET-Framework-Solution mit 30 Projekten und müsst auf .NET 9 umsteigen. Das sind hunderte Dateiänderungen — Projektdateien, Namespace-Updates, API-Ersetzungen, NuGet-Migrationen.

Mit Docker Sandbox könnt ihr einen Copilot-Agenten auf ein Projekt ansetzen, ihn innerhalb der MicroVM frei refactoren lassen, dotnet build und dotnet test zur Validierung ausführen und nur die Änderungen übernehmen, die tatsächlich funktionieren. Kein Risiko, dass er versehentlich eure lokale Entwicklungsumgebung zerschießt, während er experimentiert.

Der Beitrag beschreibt auch den Einsatz einer Flotte paralleler Agenten — jeder in seiner eigenen Sandbox — die gleichzeitig verschiedene Projekte bearbeiten. Für große .NET-Solutions oder Microservice-Architekturen ist das eine massive Zeitersparnis. Ein Agent pro Service, alle isoliert laufend, alle unabhängig validiert.

Der Sicherheitsaspekt zählt

Hier ist der Punkt, den die meisten übersehen: Wenn ihr einem KI-Agenten erlaubt, beliebige Befehle auszuführen, vertraut ihr ihm eure gesamte Maschine an. Docker Sandbox dreht dieses Modell um. Der Agent bekommt volle Autonomie in einer Wegwerfumgebung. Der Netzwerk-Proxy stellt sicher, dass er nur von genehmigten Quellen ziehen kann. Euer Host-Dateisystem, Docker-Daemon und eure Credentials bleiben unangetastet.

Für Teams mit Compliance-Anforderungen — und das sind die meisten .NET-Unternehmen — ist das der Unterschied zwischen “Wir können agentische KI nicht nutzen” und “Wir können sie sicher einsetzen.”

Fazit

Docker Sandbox löst die fundamentale Spannung des agentischen Programmierens: Agenten brauchen Freiheit, um nützlich zu sein, aber Freiheit auf eurer Host-Maschine ist gefährlich. MicroVMs geben euch beides. Wenn ihr großangelegtes .NET-Refactoring oder eine Modernisierung plant, lohnt es sich, das jetzt einzurichten. Die Kombination aus Copilots Code-Intelligenz mit einer sicheren Ausführungsumgebung ist genau das, worauf Produktionsteams gewartet haben.

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.

.NET Aspire 13.2 Will der Beste Freund Deines KI-Agenten Sein

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

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

Kennst du den Moment, wenn dein KI-Agent soliden Code schreibt, du begeistert bist, und dann alles zusammenbricht, wenn er versucht, das Ding tatsächlich auszuführen? Port-Konflikte, Geister-Prozesse, falsche Umgebungsvariablen — plötzlich verbrennt dein Agent Tokens beim Troubleshooting von Startproblemen statt Features zu bauen.

Das Aspire-Team hat gerade einen wirklich durchdachten Post über genau dieses Problem veröffentlicht, und ihre Antwort ist überzeugend: Aspire 13.2 ist nicht nur für Menschen konzipiert, sondern auch für KI-Agenten.

Das Problem ist real

KI-Agenten sind unglaublich gut im Code schreiben. Aber eine funktionierende Full-Stack-App zu liefern, erfordert viel mehr als nur Dateien zu generieren. Du musst Services in der richtigen Reihenfolge starten, Ports verwalten, Umgebungsvariablen setzen, Datenbanken verbinden und Feedback bekommen, wenn etwas kaputt geht. Im Moment handhaben die meisten Agenten all das durch Trial-and-Error — Befehle ausführen, Fehlerausgaben lesen, es nochmal versuchen.

Wir packen Markdown-Anleitungen, Custom Skills und Prompts drauf, um sie zu leiten, aber die sind unvorhersehbar, können nicht kompiliert werden und kosten Tokens allein zum Parsen. Das Aspire-Team hat den Kern erkannt: Agenten brauchen Compiler und strukturierte APIs, nicht mehr Markdown.

Aspire als Agenten-Infrastruktur

Das bringt Aspire 13.2 für die agentische Entwicklung mit:

Dein gesamter Stack in typisiertem Code. Der AppHost definiert deine komplette Topologie — API, Frontend, Datenbank, Cache — in kompilierbarem TypeScript oder C#:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Ein Agent kann das lesen, um die App-Topologie zu verstehen, Ressourcen hinzuzufügen, Verbindungen zu verkabeln und zum Verifizieren zu kompilieren. Der Compiler sagt ihm sofort, wenn etwas falsch ist. Kein Raten, kein Trial-and-Error mit Konfigurationsdateien.

Ein Befehl um sie alle zu starten. Statt dass Agenten docker compose up, npm run dev und Datenbank-Startskripte jonglieren, ist alles einfach aspire start. Alle Ressourcen starten in der richtigen Reihenfolge, auf den richtigen Ports, mit der richtigen Konfiguration. Langlebige Prozesse blockieren den Agenten auch nicht — Aspire verwaltet sie.

Isolierter Modus für parallele Agenten. Mit --isolated bekommt jeder Aspire-Lauf eigene zufällige Ports und separate User Secrets. Mehrere Agenten arbeiten über Git Worktrees hinweg? Sie kollidieren nicht. Das ist riesig für Tools wie VS Codes Background-Agenten, die parallele Umgebungen aufspannen.

Agenten-Augen durch Telemetrie. Hier wird es richtig mächtig. Die Aspire CLI stellt während der Entwicklung volle OpenTelemetry-Daten bereit — Traces, Metriken, strukturierte Logs. Dein Agent liest nicht einfach Konsolenausgaben und hofft das Beste. Er kann eine fehlgeschlagene Anfrage über Services hinweg tracen, langsame Endpunkte profilen und genau identifizieren, wo Dinge kaputtgehen. Das ist Observability auf Produktionsniveau in der Entwicklungsschleife.

Die Bowlingbahn-Bumper-Analogie

Das Aspire-Team nutzt eine großartige Analogie: Denk an Aspire als Bowlingbahn-Bumper für KI-Agenten. Wenn der Agent nicht perfekt ist (und das wird er nicht sein), verhindern die Bumper, dass er Rinnenschüsse wirft. Die Stack-Definition verhindert Fehlkonfiguration, der Compiler fängt Fehler, die CLI übernimmt das Prozessmanagement, und die Telemetrie liefert die Feedback-Schleife.

Kombiniere das mit etwas wie Playwright CLI, und dein Agent kann deine App tatsächlich benutzen — durch Flows klicken, das DOM prüfen, kaputte Dinge in der Telemetrie sehen, den Code fixen, neustarten und erneut testen. Bauen, ausführen, beobachten, fixen. Das ist die autonome Entwicklungsschleife, die wir verfolgt haben.

Erste Schritte

Neu bei Aspire? Installiere die CLI von get.aspire.dev und folge dem Getting-Started-Guide.

Nutzt du Aspire bereits? Führe aspire update --self aus, um Version 13.2 zu bekommen, und zeige dann deinem Lieblings-Coding-Agenten dein Repo. Du wirst überrascht sein, wie viel weiter er mit Aspires Leitplanken kommt.

Zusammenfassung

Aspire 13.2 ist nicht mehr nur ein Framework für verteilte Apps — es wird zur essentiellen Agenten-Infrastruktur. Strukturierte Stack-Definitionen, Ein-Befehl-Start, isolierte parallele Ausführungen und Echtzeit-Telemetrie geben KI-Agenten genau das, was sie brauchen, um vom Code-Schreiben zum App-Liefern zu kommen.

Lies den vollständigen Post vom Aspire-Team für alle Details und Demo-Videos.

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.

MCP Apps bekommen eine Fluent API — Erstelle reichhaltige AI-Tool-UIs in .NET in drei Schritten

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

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

MCP-Tools sind großartig, um AI-Agenten Fähigkeiten zu geben. Aber was, wenn dein Tool dem Benutzer etwas zeigen muss — ein Dashboard, ein Formular, eine interaktive Visualisierung? Genau dafür gibt es MCP Apps, und sie sind jetzt viel einfacher zu erstellen.

Lilian Kasem vom Azure SDK-Team hat die neue Fluent-Konfigurations-API vorgestellt für MCP Apps auf .NET Azure Functions, und es ist die Art von Verbesserung der Entwicklererfahrung, bei der man sich fragt, warum es nicht schon immer so einfach war.

Was sind MCP Apps?

MCP Apps erweitern das Model Context Protocol, indem sie Tools eigene UI-Views, statische Assets und Sicherheitskontrollen mitgeben können. Anstatt nur Text zurückzugeben, kann dein MCP-Tool vollständige HTML-Erlebnisse rendern — interaktive Dashboards, Datenvisualisierungen, Konfigurationsformulare — alles von AI-Agenten aufrufbar und den Benutzern durch MCP-Clients präsentiert.

Der Haken war, dass das manuelle Verkabeln all dieser Dinge tiefes Wissen über die MCP-Spezifikation erforderte: ui://-URIs, spezielle MIME-Types, Metadaten-Koordination zwischen Tools und Ressourcen. Nicht schwer, aber fummellig.

Die Fluent API in drei Schritten

Schritt 1: Definiere deine Funktion. Ein standardmäßiges Azure Functions MCP-Tool:

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

Schritt 2: Mach sie zur MCP App. In deinem Programm-Startup:

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

Schritt 3: Füge deine HTML-View hinzu. Erstelle assets/hello-app.html mit der UI, die du brauchst.

Das war’s. Die Fluent API kümmert sich um die gesamte MCP-Protokoll-Plumbing — generiert die synthetische Ressourcen-Funktion, setzt den korrekten MIME-Type und injiziert die Metadaten, die dein Tool mit seiner View verbinden.

Die API-Oberfläche ist gut durchdacht

Ein paar Dinge, die mir besonders gefallen:

View-Quellen sind flexibel. Du kannst HTML von Dateien auf der Festplatte servieren oder Ressourcen direkt in deine Assembly einbetten für eigenständige Deployments:

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSP ist komponierbar. Du erlaubst explizit die Origins, die deine App braucht, nach dem Prinzip der minimalen Berechtigung. Rufe WithCsp mehrmals auf und die Origins akkumulieren sich:

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

Sichtbarkeitskontrolle. Du kannst ein Tool nur für das LLM sichtbar machen, nur für die Host-UI oder für beides. Du willst ein Tool, das nur UI rendert und nicht vom Modell aufgerufen werden soll? Kein Problem:

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

Erste Schritte

Füge das Preview-Paket hinzu:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

Wenn du bereits MCP-Tools mit Azure Functions baust, ist das nur ein Paket-Update. Der MCP Apps Quickstart ist der beste Einstiegspunkt, wenn du neu im Konzept bist.

Zusammenfassung

MCP Apps sind eine der spannendsten Entwicklungen im AI-Tooling-Bereich — Tools, die nicht nur Dinge tun, sondern den Benutzern auch Dinge zeigen können. Die Fluent API entfernt die Protokollkomplexität und lässt dich auf das Wesentliche konzentrieren: die Logik deines Tools und seine Oberfläche.

Lies den vollständigen Beitrag für die komplette API-Referenz und Beispiele.

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.

VS Code 1.115 — Hintergrund-Terminal-Benachrichtigungen, SSH-Agent-Modus und Mehr

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

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

VS Code 1.115 ist gerade erschienen, und obwohl es ein leichteres Release in Bezug auf Hauptfeatures ist, sind die agentenbezogenen Verbesserungen wirklich nützlich, wenn man täglich mit KI-Coding-Assistenten arbeitet.

Lass mich hervorheben, was wirklich wissenswert ist.

Hintergrund-Terminals kommunizieren mit Agenten

Das ist das herausragende Feature. Hintergrund-Terminals benachrichtigen Agenten jetzt automatisch, wenn Befehle abgeschlossen sind, einschließlich Exit-Code und Terminal-Ausgabe. Eingabeaufforderungen in Hintergrund-Terminals werden ebenfalls erkannt und dem Benutzer angezeigt.

Warum ist das wichtig? Wenn du Copilots Agent-Modus verwendet hast, um Build-Befehle oder Test-Suites im Hintergrund auszuführen, kennst du den Schmerz von “Ist das schon fertig?” — Hintergrund-Terminals waren im Wesentlichen Fire-and-Forget. Jetzt wird der Agent benachrichtigt, wenn dein dotnet build oder dotnet test abgeschlossen ist, sieht die Ausgabe und kann entsprechend reagieren. Es ist eine kleine Änderung, die agentengesteuerte Workflows deutlich zuverlässiger macht.

Es gibt auch ein neues send_to_terminal-Tool, das Agenten ermöglicht, Befehle mit Benutzerbestätigung an Hintergrund-Terminals zu senden. Das behebt das Problem, bei dem run_in_terminal mit einem Timeout Terminals in den Hintergrund verschob und sie schreibgeschützt machte.

SSH-Remote-Agent-Hosting

VS Code unterstützt jetzt die Verbindung zu Remote-Maschinen über SSH, installiert automatisch die CLI und startet sie im Agent-Host-Modus. Das bedeutet, dass deine KI-Agent-Sitzungen direkt auf Remote-Umgebungen zielen können — nützlich für .NET-Entwickler, die auf Linux-Servern oder Cloud-VMs bauen und testen.

Edit-Tracking in Agent-Sitzungen

Dateiänderungen während Agent-Sitzungen werden jetzt verfolgt und wiederhergestellt, mit Diffs, Undo/Redo und Zustandswiederherstellung. Wenn ein Agent Änderungen an deinem Code vornimmt und etwas schiefgeht, kannst du genau sehen, was sich geändert hat, und es zurückrollen. Beruhigend, wenn man Agenten seine Codebasis ändern lässt.

Browser-Tab-Erkennung und weitere Verbesserungen

Ein paar weitere Quality-of-Life-Ergänzungen:

Browser-Tab-Tracking — Chat kann jetzt Browser-Tabs verfolgen und verlinken, die während einer Sitzung geöffnet wurden, sodass Agenten auf Webseiten verweisen können, die du gerade anschaust
Dateieinfügen im Terminal — füge Dateien (einschließlich Bilder) mit Strg+V, Drag-and-Drop oder Rechtsklick in das Terminal ein
Testabdeckung in der Minimap — Testabdeckungsindikatoren werden jetzt in der Minimap für einen schnellen visuellen Überblick angezeigt
Pinch-to-Zoom auf Mac — der integrierte Browser unterstützt Pinch-to-Zoom-Gesten
Copilot-Berechtigungen in Sitzungen — die Statusleiste zeigt Nutzungsinformationen in der Sitzungsansicht
Favicon in Gehe zu Datei — geöffnete Webseiten zeigen Favicons in der Schnellauswahlliste

Fazit

VS Code 1.115 ist ein inkrementelles Release, aber die Agent-Verbesserungen — Hintergrund-Terminal-Benachrichtigungen, SSH-Agent-Hosting und Edit-Tracking — ergeben zusammen eine spürbar flüssigere Erfahrung für KI-unterstützte Entwicklung. Wenn du Copilots Agent-Modus für .NET-Projekte verwendest, sind das genau die Art von Quality-of-Life-Verbesserungen, die den täglichen Reibungsverlust reduzieren.

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

Aspire 13.2 liefert eine Docs-CLI — und dein KI-Agent kann sie auch nutzen

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

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

Kennst du diesen Moment, wenn du tief in einem Aspire AppHost steckst, Integrationen verdrahtest, und du genau nachschauen musst, welche Parameter die Redis-Integration erwartet? Du wechselst mit Alt-Tab zum Browser, suchst auf aspire.dev, kneifst die Augen zusammen bei den API-Docs, und kommst zurück zu deinem Editor. Kontext verloren. Flow unterbrochen.

Aspire 13.2 hat gerade eine Lösung dafür geliefert. Die aspire docs-CLI ermöglicht es dir, offizielle Aspire-Dokumentation direkt aus deinem Terminal zu suchen, durchstöbern und lesen. Und weil sie auf wiederverwendbaren Services basiert, können KI-Agenten und Skills dieselben Befehle nutzen, um Docs nachzuschlagen, statt APIs zu halluzinieren, die gar nicht existieren.

Das Problem, das hier wirklich gelöst wird

David Pine bringt es im Originalbeitrag auf den Punkt: KI-Agenten waren furchtbar darin, Entwicklern beim Bauen von Aspire-Apps zu helfen. Sie empfahlen dotnet run statt aspire run, verwiesen auf learn.microsoft.com für Docs, die auf aspire.dev leben, schlugen veraltete NuGet-Pakete vor, und — mein persönlicher Favorit — halluzinierten APIs, die nicht existieren.

Warum? Weil Aspire viel länger .NET-spezifisch war, als es polyglott ist, und LLMs mit Trainingsdaten arbeiten, die älter sind als die neuesten Features. Wenn du einem KI-Agenten die Möglichkeit gibst, tatsächlich die aktuellen Docs nachzuschlagen, hört er auf zu raten und wird nützlich.

Drei Befehle, null Browser-Tabs

Die CLI ist erfrischend einfach:

Alle Docs auflisten

aspire docs list

Gibt jede verfügbare Dokumentationsseite auf aspire.dev zurück. Brauchst du maschinenlesbare Ausgabe? Füge --format Json hinzu.

Nach einem Thema suchen

aspire docs search "redis"

Durchsucht sowohl Titel als auch Inhalte mit gewichteter Relevanzbewertung. Dieselbe Suchmaschine, die intern die Dokumentationswerkzeuge antreibt. Du bekommst gerankte Ergebnisse mit Titeln, Slugs und Relevanzwerten.

Eine vollständige Seite lesen (oder nur einen Abschnitt)

aspire docs get redis-integration

Streamt die vollständige Seite als Markdown in dein Terminal. Brauchst du nur einen Abschnitt?

aspire docs get redis-integration --section "Add Redis resource"

Chirurgische Präzision. Kein Scrollen durch 500 Zeilen. Nur der Teil, den du brauchst.

Der KI-Agent-Aspekt

Hier wird es interessant für uns Entwickler, die mit KI-Werkzeugen arbeiten. Dieselben aspire docs-Befehle funktionieren als Tools für KI-Agenten — über Skills, MCP-Server oder einfache CLI-Wrapper.

Statt dass dein KI-Assistent Aspire-APIs auf Basis veralteter Trainingsdaten erfindet, kann er aspire docs search "postgres" aufrufen, die offiziellen Integrations-Docs finden, die richtige Seite lesen und dir den dokumentierten Ansatz liefern. Echtzeit-aktuelle Dokumentation — nicht das, was das Modell vor sechs Monaten auswendig gelernt hat.

Die Architektur dahinter ist bewusst so gestaltet. Das Aspire-Team hat wiederverwendbare Services gebaut (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) anstelle einer einmaligen Integration. Das bedeutet, dieselbe Suchmaschine funktioniert für Menschen im Terminal, KI-Agenten in deinem Editor und Automatisierung in deiner CI-Pipeline.

Praxisszenarien

Schnelle Terminal-Nachschlagen: Du steckst drei Dateien tief und brauchst Redis-Konfigurationsparameter. Zwei Befehle, neunzig Sekunden, zurück an die Arbeit:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

KI-gestützte Entwicklung: Dein VS Code Skill wrapt die CLI-Befehle. Du fragst „Füge eine PostgreSQL-Datenbank zu meinem AppHost hinzu" und der Agent schlägt die echten Docs nach, bevor er antwortet. Keine Halluzinationen.

CI/CD-Validierung: Deine Pipeline validiert AppHost-Konfigurationen programmatisch gegen offizielle Dokumentation. Die --format Json-Ausgabe lässt sich sauber mit jq und anderen Tools weiterverarbeiten.

Eigene Wissensdatenbanken: Baust du deine eigenen KI-Tools? Leite strukturierte JSON-Ausgabe direkt in deine Wissensdatenbank:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Kein Web Scraping. Keine API-Keys. Dieselben strukturierten Daten, die intern von den Dokumentationswerkzeugen genutzt werden.

Die Dokumentation ist immer aktuell

Das ist der Teil, den ich am meisten schätze. Die CLI lädt keinen Snapshot herunter — sie fragt aspire.dev mit ETag-basiertem Caching ab. In dem Moment, in dem die Docs aktualisiert werden, spiegelt deine CLI und jeder darauf aufbauende Skill das wider. Keine veralteten Kopien, keine „aber im Wiki stand doch…"-Momente.

Zum Abschluss

aspire docs ist eines dieser kleinen Features, das ein echtes Problem sauber löst. Menschen bekommen terminal-nativen Dokumentationszugriff. KI-Agenten bekommen eine Möglichkeit, aufzuhören zu raten und stattdessen echte Docs zu referenzieren. Und alles wird von derselben Wahrheitsquelle gespeist.

Wenn du mit .NET Aspire baust und die CLI noch nicht ausprobiert hast, führe aspire docs search "dein-thema-hier" aus und schau, wie es sich anfühlt. Dann überleg dir, diese Befehle in dein KI-Skill- oder Automatisierungs-Setup einzubauen — deine Agenten werden es dir danken.

Schau dir David Pines Deep Dive an, wie die Dokumentationswerkzeuge entstanden sind, und die offizielle CLI-Referenz für alle Details.

Microsoft Agent Framework Erreicht 1.0 — Das Ist Wirklich Wichtig für .NET-Entwickler

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

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

Wenn du die Reise des Agent Frameworks seit den frühen Tagen von Semantic Kernel und AutoGen verfolgt hast, ist das hier bedeutend. Microsoft Agent Framework hat gerade Version 1.0 erreicht — produktionsreif, stabile APIs, langfristiges Support-Commitment. Es ist sowohl für .NET als auch für Python verfügbar und wirklich bereit für echte Workloads.

Ich schneide durch den Ankündigungslärm und konzentriere mich auf das, was wichtig ist, wenn du KI-gestützte Apps mit .NET baust.

Die Kurzversion

Agent Framework 1.0 vereint das, was früher Semantic Kernel und AutoGen waren, in ein einziges Open-Source-SDK. Eine Agent-Abstraktion. Eine Orchestrierungs-Engine. Mehrere KI-Anbieter. Wenn du zwischen Semantic Kernel für Enterprise-Patterns und AutoGen für forschungsbasierte Multi-Agent-Workflows hin und her gesprungen bist, kannst du aufhören. Das ist jetzt das eine SDK.

Der Einstieg ist fast unfair einfach

Hier ist ein funktionierender Agent in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Das war’s. Eine Handvoll Zeilen und du hast einen KI-Agenten, der gegen Azure Foundry läuft. Das Python-Äquivalent ist genauso knapp. Füge Funktions-Tools, Multi-Turn-Konversationen und Streaming hinzu, wie du vorankommst — die API-Oberfläche skaliert, ohne seltsam zu werden.

Multi-Agent-Orchestrierung — das ist die echte Sache

Einzelne Agenten sind gut für Demos, aber Produktionsszenarien brauchen normalerweise Koordination. Agent Framework 1.0 liefert kampferprobte Orchestrierungsmuster direkt von Microsoft Research und AutoGen:

Sequenziell — Agenten verarbeiten der Reihe nach (Autor → Reviewer → Editor)
Gleichzeitig — verteile an mehrere Agenten parallel, führe Ergebnisse zusammen
Handoff — ein Agent delegiert basierend auf der Absicht an einen anderen
Gruppen-Chat — mehrere Agenten diskutieren und konvergieren zu einer Lösung
Magentic-One — das forschungsbasierte Multi-Agent-Pattern von MSR

Alle unterstützen Streaming, Checkpointing, Human-in-the-Loop-Freigaben und Pause/Fortsetzen. Der Checkpointing-Teil ist entscheidend — lang laufende Workflows überleben Prozess-Neustarts. Für uns .NET-Entwickler, die dauerhafte Workflows mit Azure Functions gebaut haben, fühlt sich das vertraut an.

Die Features, die am meisten zählen

Hier ist meine Shortlist dessen, was wissenswert ist:

Middleware-Hooks. Du weißt, wie ASP.NET Core Middleware-Pipelines hat? Gleiches Konzept, aber für die Agent-Ausführung. Fange jede Stufe ab — füge Content-Sicherheit, Logging, Compliance-Richtlinien hinzu — ohne die Agent-Prompts anzufassen. So machst du Agenten enterprise-ready.

Steckbare Memory. Konversationshistorie, persistenter Key-Value-State, vektorbasiertes Retrieval. Wähle dein Backend: Foundry Agent Service, Mem0, Redis, Neo4j, oder baue dein eigenes. Memory ist das, was einen zustandslosen LLM-Aufruf in einen Agenten verwandelt, der sich tatsächlich an den Kontext erinnert.

Deklarative YAML-Agenten. Definiere die Anweisungen, Tools, Memory und Orchestrierungs-Topologie deines Agenten in versionskontrollierten YAML-Dateien. Lade und starte mit einem einzigen API-Aufruf. Das ist ein Game-Changer für Teams, die das Agent-Verhalten iterieren wollen, ohne Code neu zu deployen.

A2A- und MCP-Unterstützung. MCP (Model Context Protocol) ermöglicht es Agenten, externe Tools dynamisch zu entdecken und aufzurufen. A2A (Agent-to-Agent-Protokoll) ermöglicht runtime-übergreifende Zusammenarbeit — deine .NET-Agenten können sich mit Agenten in anderen Frameworks koordinieren. A2A 1.0-Unterstützung kommt bald.

Die Preview-Features, die es wert sind, beobachtet zu werden

Einige Features wurden als Preview in 1.0 ausgeliefert — funktional, aber APIs können sich weiterentwickeln:

DevUI — ein browserbasierter lokaler Debugger zur Visualisierung der Agent-Ausführung, Nachrichtenflüsse und Tool-Aufrufe in Echtzeit. Denk an Application Insights, aber für Agent-Reasoning.
GitHub Copilot SDK und Claude Code SDK — verwende Copilot oder Claude als Agent-Harness direkt aus deinem Orchestrierungscode. Komponiere einen programmierfähigen Agenten neben deinen anderen Agenten im selben Workflow.
Agent Harness — eine anpassbare lokale Runtime, die Agenten Zugriff auf Shell, Dateisystem und Messaging-Loops gibt. Denk an Coding-Agenten und Automatisierungsmuster.
Skills — wiederverwendbare Domain-Capability-Pakete, die Agenten strukturierte Fähigkeiten out of the box geben.

Migration von Semantic Kernel oder AutoGen

Wenn du bestehenden Semantic Kernel- oder AutoGen-Code hast, gibt es dedizierte Migrationsassistenten, die deinen Code analysieren und schrittweise Migrationspläne generieren. Der Semantic Kernel Migrationsleitfaden und der AutoGen Migrationsleitfaden führen dich durch alles.

Wenn du auf den RC-Paketen warst, ist das Upgrade auf 1.0 nur ein Versions-Bump.

Zum Abschluss

Agent Framework 1.0 ist der Produktions-Meilenstein, auf den Enterprise-Teams gewartet haben. Stabile APIs, Multi-Provider-Support, Orchestrierungsmuster, die tatsächlich im großen Maßstab funktionieren, und Migrationspfade von sowohl Semantic Kernel als auch AutoGen.

Das Framework ist vollständig Open Source auf GitHub, und du kannst heute mit dotnet add package Microsoft.Agents.AI loslegen. Schau dir den Schnellstart-Leitfaden und die Beispiele an, um praktisch einzusteigen.

Wenn du auf das Signal „sicher für den Produktionseinsatz" gewartet hast — das ist es.

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.

Das Aspire 13.2 Dashboard hat jetzt eine Telemetrie-API — und das ändert alles

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

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

Wenn du verteilte Apps mit .NET Aspire baust, weißt du bereits, dass das Dashboard das Beste an der ganzen Erfahrung ist. Alle Traces, Logs und Metriken an einem Ort — kein externes Jaeger, kein Seq-Setup, keine „lass mich mal im anderen Terminal schauen"-Momente.

Aspire 13.2 hat es deutlich besser gemacht. James Newton-King hat das Update angekündigt, und ehrlich gesagt? Die Telemetrie-Export- und API-Features allein rechtfertigen das Upgrade.

Telemetrie exportieren wie ein normaler Mensch

Hier ist das Szenario, das wir alle kennen: Du debuggst ein verteiltes Problem, reproduzierst es endlich nach zwanzig Minuten Setup, und jetzt musst du dem Team zeigen, was passiert ist. Vorher? Screenshots. Trace-IDs kopieren und einfügen. Das übliche Chaos.

Aspire 13.2 fügt einen ordentlichen Logs und Telemetrie verwalten-Dialog hinzu, in dem du:

Alle Telemetrie löschen kannst (nützlich vor einem Reproduktionsversuch)
Ausgewählte Telemetrie als ZIP-Datei im Standard-OTLP/JSON-Format exportieren kannst
Diese ZIP-Datei später in jedes Aspire-Dashboard reimportieren kannst

Der letzte Punkt ist das Killer-Feature. Du reproduzierst einen Bug, exportierst die Telemetrie, hängst sie an dein Work Item, und dein Kollege kann sie in sein eigenes Dashboard importieren, um genau das zu sehen, was du gesehen hast. Kein „kannst du das auf deinem Rechner reproduzieren?" mehr.

Einzelne Traces, Spans und Logs haben auch eine „Export JSON"-Option im Kontextmenü. Musst du einen bestimmten Trace teilen? Rechtsklick, JSON kopieren, in die PR-Beschreibung einfügen. Fertig.

Die Telemetrie-API ist der echte Game Changer

Das begeistert mich am meisten. Das Dashboard bietet jetzt eine HTTP-API unter /api/telemetry zum programmatischen Abfragen von Telemetriedaten. Verfügbare Endpunkte:

GET /api/telemetry/resources — Ressourcen mit Telemetrie auflisten
GET /api/telemetry/spans — Spans mit Filtern abfragen
GET /api/telemetry/logs — Logs mit Filtern abfragen
GET /api/telemetry/traces — Traces auflisten
GET /api/telemetry/traces/{traceId} — alle Spans für einen bestimmten Trace abrufen

Alles kommt im OTLP-JSON-Format zurück. Das treibt die neuen CLI-Befehle aspire agent mcp und aspire otel an, aber die wirkliche Bedeutung ist größer: Du kannst jetzt Tooling, Skripte und KI-Agent-Integrationen bauen, die die Telemetrie deiner App direkt abfragen.

Stell dir einen KI-Coding-Agent vor, der deine tatsächlichen verteilten Traces beim Debuggen sehen kann. Das ist nicht mehr hypothetisch — genau das ermöglicht diese API.

GenAI-Telemetrie wird praktisch

Wenn du KI-gestützte Apps mit Semantic Kernel oder Microsoft.Extensions.AI baust, wirst du den verbesserten GenAI-Telemetrie-Visualizer zu schätzen wissen. Aspire 13.2 fügt hinzu:

KI-Toolbeschreibungen als Markdown gerendert
Einen dedizierten GenAI-Button auf der Traces-Seite für schnellen Zugriff
Bessere Fehlerbehandlung für abgeschnittenes oder nicht-standardmäßiges GenAI-JSON
Click-to-Highlight-Navigation zwischen Tool-Definitionen

Der Blogpost erwähnt, dass VS Code Copilot Chat, Copilot CLI und OpenCode alle das Konfigurieren eines OTEL_EXPORTER_OTLP_ENDPOINT unterstützen. Richte sie auf das Aspire-Dashboard und du kannst buchstäblich deinen KI-Agents beim Denken in Echtzeit über Telemetrie zusehen. Das ist ein Debugging-Erlebnis, das du nirgendwo anders findest.

Zusammenfassung

Aspire 13.2 verwandelt das Dashboard von „netter Debugging-UI" zu „programmierbarer Observability-Plattform". Der Export/Import-Workflow allein spart echte Zeit beim verteilten Debugging, und die Telemetrie-API öffnet die Tür zu KI-gestützter Diagnostik.

Wenn du bereits Aspire nutzt, aktualisiere. Wenn nicht — das ist ein guter Grund, aspire.dev auszuprobieren.

Visual Studios März-Update lässt dich eigene Copilot-Agenten bauen — und find_symbol ist ein großes Ding

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

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

Visual Studio hat gerade sein bedeutendstes Copilot-Update bekommen. Mark Downie hat das März-Release angekündigt, und die Überschrift sind Custom Agents — aber ehrlich gesagt könnte das find_symbol-Tool weiter unten die Funktion sein, die deinen Workflow am meisten verändert.

Benutzerdefinierte Copilot-Agenten in deinem Repo

Willst du, dass Copilot deinen Team-Codierstandards folgt, deine Build-Pipeline ausführt oder deine internen Docs abfragt? Jetzt kannst du genau das bauen.

Custom Agents werden als .agent.md-Dateien definiert, die du in .github/agents/ in deinem Repository ablegst. Jeder Agent hat vollen Zugriff auf Workspace-Awareness, Code-Verständnis, Tools, dein bevorzugtes Modell und MCP-Verbindungen.

Agent Skills: wiederverwendbare Instruktionspakete

Skills werden automatisch aus .github/skills/ in deinem Repo oder ~/.copilot/skills/ in deinem Profil geladen. Denke an Skills als modulare Expertise, die du mischen und kombinieren kannst.

Das neue find_symbol-Tool gibt Copilots Agent-Modus sprachservice-gestützte Symbol-Navigation. Statt Text zu suchen, kann der Agent alle Referenzen eines Symbols finden und auf Typ-Informationen, Deklarationen und Scope zugreifen.

Für .NET-Entwickler ist das eine massive Verbesserung — C#-Codebasen mit tiefen Typ-Hierarchien profitieren enorm.

Tests mit Copilot profilen

Im Test Explorer gibt es jetzt Profile with Copilot. Der Profiling Agent führt den Test aus und analysiert automatisch CPU-Nutzung und Instrumentierungsdaten.

Perf Tips beim Live-Debugging

Performance-Optimierung passiert jetzt während des Debuggens. Visual Studio zeigt inline Ausführungszeit und Performance-Signale. Siehst du eine langsame Zeile? Klicke auf den Perf Tip und frage Copilot nach Optimierungsvorschlägen.

NuGet-Schwachstellen aus dem Solution Explorer beheben

Bei erkannten NuGet-Schwachstellen siehst du einen Fix with GitHub Copilot-Link direkt im Solution Explorer.

Zusammenfassung

Custom Agents und Skills sind die Überschrift, aber find_symbol ist der Sleeper Hit — es verändert grundlegend, wie genau Copilot beim Refactoring von .NET-Code sein kann. Kombiniert mit Live-Profiling und Schwachstellen-Fixes fühlen sich die KI-Features von Visual Studio jetzt wirklich praktisch an.

Lade Visual Studio 2026 Insiders herunter, um alles auszuprobieren.

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.

VS Code 1.112: Was .NET-Entwickler wirklich interessieren sollte

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

VS Code 1.112 ist gelandet, und ehrlich? Dieses Release fühlt sich anders an, wenn du deine Tage in der .NET-Welt verbringst. Es gibt viel in den offiziellen Release Notes, aber lass mich dir etwas Scrollen ersparen und mich auf das konzentrieren, was für uns wirklich zählt.

Copilot CLI ist gerade viel nützlicher geworden

Das große Thema dieses Releases ist Agent-Autonomie — Copilot mehr Raum geben, sein Ding zu machen, ohne dass du jeden Schritt überwachst.

Nachrichtensteuerung und Warteschlange

Kennst du den Moment, wenn Copilot CLI mitten in einer Aufgabe ist und dir auffällt, dass du etwas vergessen hast zu erwähnen? Vorher musstest du warten. Jetzt kannst du Nachrichten senden, während eine Anfrage noch läuft — entweder um die aktuelle Antwort zu steuern oder Folgeanweisungen in die Warteschlange zu stellen.

Das ist riesig für die längeren dotnet-Scaffolding-Aufgaben, wo du Copilot beim Projekt-Setup zuschaust und denkst “oh warte, ich brauche auch MassTransit da drin.”

Berechtigungsstufen

Das ist die Funktion, die mich am meisten begeistert. Copilot CLI-Sitzungen unterstützen jetzt drei Berechtigungsstufen:

Standard-Berechtigungen — der übliche Flow, bei dem Tools vor dem Ausführen um Bestätigung bitten
Genehmigungen umgehen — genehmigt alles automatisch und wiederholt bei Fehlern
Autopilot — wird voll autonom: genehmigt Tools, beantwortet eigene Fragen und macht weiter, bis die Aufgabe erledigt ist

Wenn du etwas wie das Scaffolding einer neuen ASP.NET Core API mit Entity Framework, Migrationen und Docker-Setup machst — Autopilot-Modus bedeutet, du beschreibst was du willst und holst dir einen Kaffee. Er wird es herausfinden.

Du kannst Autopilot mit der Einstellung chat.autopilot.enabled aktivieren.

Änderungen vor der Delegation vorschauen

Wenn du eine Aufgabe an Copilot CLI delegierst, erstellt er einen Worktree. Vorher, wenn du nicht committete Änderungen hattest, musstest du die Quellcodeverwaltung prüfen, um zu sehen, was betroffen wäre. Jetzt zeigt die Chat-Ansicht ausstehende Änderungen direkt dort an, bevor du entscheidest, ob du sie kopieren, verschieben oder ignorieren willst.

Kleine Sache, aber es erspart dir den “warte, was hatte ich gestaged?"-Moment.

Web-Apps debuggen ohne VS Code zu verlassen

Der integrierte Browser unterstützt jetzt vollständiges Debugging. Du kannst Breakpoints setzen, durch Code steppen und Variablen inspizieren — alles in VS Code. Kein Wechsel mehr zu Edge DevTools.

Es gibt einen neuen editor-browser Debug-Typ, und wenn du bereits vorhandene msedge- oder chrome-Launch-Konfigurationen hast, ist die Migration so einfach wie das Ändern des type-Felds in deiner launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Für Blazor-Entwickler ist das ein Game Changer. Du führst bereits dotnet watch im Terminal aus — jetzt bleibt dein Debugging auch im selben Fenster.

Der Browser hat auch unabhängige Zoom-Stufen bekommen (endlich), richtige Rechtsklick-Kontextmenüs, und der Zoom wird pro Website gespeichert.

MCP-Server-Sandboxing

Das ist wichtiger als du vielleicht denkst. Wenn du MCP-Server verwendest — vielleicht hast du einen für deine Azure-Ressourcen oder Datenbankabfragen eingerichtet — liefen sie bisher mit denselben Berechtigungen wie dein VS Code-Prozess. Das bedeutet voller Zugriff auf dein Dateisystem, Netzwerk, alles.

Jetzt kannst du sie sandboxen. In deiner mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

Wenn ein gesandboxter Server Zugriff auf etwas braucht, das er nicht hat, fordert VS Code dich auf, die Berechtigung zu erteilen. Viel besser als der “hoffen wir, dass niemand etwas Merkwürdiges macht”-Ansatz.

Hinweis: Sandboxing ist derzeit auf macOS und Linux verfügbar. Windows-Support kommt — Remote-Szenarien wie WSL funktionieren aber bereits.

Monorepo-Customization-Discovery

Wenn du in einem Monorepo arbeitest (und seien wir ehrlich, viele Enterprise-.NET-Lösungen enden als eines), löst das einen echten Schmerzpunkt.

Zuvor, wenn du einen Unterordner deines Repos geöffnet hast, fand VS Code deine copilot-instructions.md, AGENTS.md oder benutzerdefinierten Skills nicht, die im Repository-Root lagen. Jetzt mit der Einstellung chat.useCustomizationsInParentRepositories geht es bis zum .git-Root hoch und entdeckt alles.

Das bedeutet, dein Team kann Agent-Anweisungen, Prompt-Dateien und benutzerdefinierte Tools über alle Projekte in einem Monorepo teilen, ohne dass jeder den Root-Ordner öffnen muss.

/troubleshoot für Agent-Debugging

Hast du jemals benutzerdefinierte Anweisungen oder Skills eingerichtet und dich gefragt, warum sie nicht erkannt werden? Der neue /troubleshoot-Skill liest Agent-Debug-Logs und sagt dir, was passiert ist — welche Tools verwendet oder übersprungen wurden, warum Anweisungen nicht geladen wurden und was langsame Antworten verursacht.

Aktiviere es mit:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Dann tippe einfach /troubleshoot why is my custom skill not loading? im Chat.

Du kannst diese Debug-Logs jetzt auch exportieren und importieren, was großartig ist, um sie mit deinem Team zu teilen, wenn etwas nicht wie erwartet funktioniert.

Bild- und Binärdatei-Unterstützung

Agenten können jetzt Bilddateien von der Festplatte und Binärdateien nativ lesen. Binärdateien werden im Hexdump-Format präsentiert, und Bildausgaben (wie Screenshots vom integrierten Browser) erscheinen in einer Karussell-Ansicht.

Für .NET-Entwickler denke: füge einen Screenshot eines UI-Bugs in den Chat ein und lass den Agenten verstehen, was falsch ist, oder lass ihn die Ausgabe eines Blazor-Komponenten-Renderings analysieren.

Automatische Symbol-Referenzen

Kleine Qualitäts-Verbesserung: wenn du einen Symbolnamen (eine Klasse, Methode, etc.) kopierst und in den Chat einfügst, konvertiert VS Code ihn jetzt automatisch in eine #sym:Name-Referenz. Das gibt dem Agenten vollen Kontext über das Symbol, ohne dass du es manuell hinzufügen musst.

Wenn du stattdessen reinen Text möchtest, verwende Ctrl+Shift+V.

Plugins können jetzt aktiviert/deaktiviert werden

Zuvor bedeutete das Deaktivieren eines MCP-Servers oder Plugins, ihn zu deinstallieren. Jetzt kannst du sie an- und ausschalten — sowohl global als auch pro Workspace. Rechtsklick in der Erweiterungsansicht oder der Customization-Ansicht und fertig.

Plugins von npm und pypi können sich jetzt auch automatisch aktualisieren, obwohl sie zuerst um Genehmigung bitten, da Updates bedeuten, dass neuer Code auf deinem Rechner ausgeführt wird.

Zusammenfassung

VS Code 1.112 pusht eindeutig hart auf die Agent-Experience — mehr Autonomie, besseres Debugging, engere Sicherheit. Für .NET-Entwickler sind das integrierte Browser-Debugging und die Copilot CLI-Verbesserungen die herausragenden Features.

Wenn du noch keine vollständige Copilot CLI-Sitzung im Autopilot-Modus für ein .NET-Projekt ausprobiert hast, ist dieses Release ein guter Zeitpunkt zum Starten. Denk nur daran, deine Berechtigungen einzustellen und es machen zu lassen.

VS Code 1.112 herunterladen oder innerhalb von VS Code aktualisieren über Hilfe > Nach Updates suchen.

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

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

Das Handoff-Muster: Wenn Ein Agent Nicht Ausreicht

Wie Handoff Funktioniert

Ein Minimales Beispiel

Wann Handoff Verwenden (und Wann Nicht)

Rückkanten und Human-in-the-Loop

Fazit

Langlebige Workflows in Microsoft Agent Framework: Von In-Memory zu Azure Functions

Die grundlegenden Bausteine

Der In-Memory-Runner für lokale Entwicklung

Dauerhaftigkeit mit Durable Task hinzufügen

Azure Functions-Hosting

Warum das wichtig ist

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

Agenten Zu Bauen Ist Der Einfache Teil — Sie Sicher Zu Betreiben Ist Der Schwierige Teil

Was Jedes Projekt Wirklich Macht

Die Einbindung Ist Nur Middleware Hinzufügen

Was Sie Bekommen

Fünf Branchenszenarien

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

Azure SQL Kann Jetzt Embeddings Generieren — In Reinem T-SQL, Keine Anwendungsschicht Erforderlich

Was Sie Tun

Der Vollständige Workflow

Unterstützte API-Formate und Optionen

Was Dies für .NET-Anwendungen Ermöglicht

Fazit

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

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

Eine KI-gestützte Konferenz-App mit dem komponierbaren .NET-Stack erstellen

Was ConferencePulse leistet

Microsoft.Extensions.AI: eine Abstraktion für alles

DataIngestion-Pipeline

VectorData: anbieterunabhängige Suche

MCP: Session-Inhalt als Tools

Agent Framework: parallele Multi-Agent-Zusammenfassung

Das Designprinzip

Microsoft Agent Framework Teil 3: Von Tools zu Workflows — Die Bausteine fügen sich zusammen

Was ein Agent wirklich ist (vs. ein Chatbot)

Der Deployment-Ablauf mit `azd`