Azure AI Foundry Threads

Wer in Azure AI Foundry eine KI bereitstellt, startet nicht einfach ein großes Sprachmodell. Er setzt es in eine verwaltete Laufzeitumgebung, in der Nachrichten, Werkzeugaufrufe und einzelne Ausführungsschritte protokolliert und nachverfolgbar gemacht werden. Das unterscheidet ein Experiment von einem System, das im Unternehmen bestehen kann.

Dieser Artikel zeigt, wie Agenten in Foundry aufgebaut sind und wie Threads, Runs und Run-Steps zusammen eine lückenlose Prüfspur bilden. Außerdem geht es um die Rolle von Tools, MCP und Berechtigungen und darum, warum all das für Compliance, Debugging und Reproduzierbarkeit entscheidend ist.

Azure AI Foundry Agent: Modell, Anweisungen und Werkzeuge

Ein Agent in Foundry ist kein Chatfenster mit Autovervollständigung. Er ruht auf drei Kernkomponenten, die sich gut als Team-Bild beschreiben lassen: Der Agent ist eine Art Teamleiter, der für klar umrissene Aufgaben gebaut wurde.

• Das Modell ist das Gehirn. Es übernimmt Schlussfolgerungen und Sprache, analysiert also Texte und plant Schritte.
• Die Anweisungen sind der Einsatzbefehl. Sie verhindern, dass das Modell abschweift, und legen es auf die Ergebnisse fest, die Sie tatsächlich brauchen.
• Die Werkzeuge sind die Ausrüstung: Codeausführung, Suchkonnektoren, Reporting-APIs oder beliebige angebundene Drittsysteme.

Erst im Zusammenspiel entsteht ein Agent, der nicht improvisiert, sondern Aufgaben mit Protokollen und Kontrollpunkten abarbeitet. Fehlt eine dieser Schichten, bekommen Sie weder Reproduzierbarkeit noch Revisionssicherheit, sondern lediglich Textgenerierung ohne Nachweise.

Flexibel bei der Modellwahl

Bei vielen Chat-APIs erhalten Sie nur ein Modell und einen Prompt. Ein formelles Verständnis für Befehle oder die Orchestrierung von Werkzeugen gibt es dort nicht. Der Foundry Agent Service stellt dagegen sicher, dass alle drei Schichten vorhanden sind. Zudem sind Sie nicht an ein einziges Modell gebunden. Im Foundry-Katalog können Sie wechseln, etwa zu GPT4 für komplexe Aufgaben, zu einem schlankeren Modell für einfache Aufgaben oder zu Mistral oder Deep Seek. Der Wechsel geschieht immer innerhalb einer Struktur, die Verantwortlichkeit erzwingt.

Häufige Stolpersteine: Was passiert, wenn die Struktur fehlt?

Fehlen Anweisungen, Werkzeuge oder Protokollierung, entstehen im Unternehmen schnell Probleme, die weit über ein kleines Ärgernis hinausgehen:

• Inkonsistente Ergebnisse: Eine Vertragszusammenfassung liest sich so, die nächste widerspricht ihr subtil.
• Verlorene Nachvollziehbarkeit: Ohne strukturiertes Protokoll lässt sich nicht belegen, wie eine Antwort zustande kam.
• Debugging als Ratespiel: Entwickler können die Argumentationskette nicht mehr zurückverfolgen.
• Fehlende Beweise: Ohne Aufzeichnung bleiben bei Audits nur Screenshots, vage Erinnerungen und mündliche Beruhigungen gegenüber Stakeholdern.

Foundry begegnet dem, indem die Anweisungen als festes Regelwerk dienen und das Toolset je nach Anwendungsfall eng begrenzt oder erweitert werden kann. Alles, was der Agent tut, wird festgehalten.

Threads: das persistente Protokoll jeder Konversation

Ein Thread ist in Foundry kein loses Chatfenster, das mit dem Schließen verschwindet. Er ist eine persistente Konversationsablage. Jeder Austausch wird gespeichert, egal ob er vom Nutzer, vom Agenten oder in einer Multiagenten-Umgebung von einem anderen Agenten stammt.

Threads sind dabei mehr als statische Mitschriften. Sie sind strukturierte Container, die Kürzungen automatisch handhaben und den aktiven Kontext innerhalb der Modellgrenzen halten, während der vollständige Audit-Trail erhalten bleibt. Der Agent versteht also die laufende Konversation weiter, und das Unternehmen behält ein dauerhaftes, überprüfbares Protokoll. Man bekommt Kontinuität für den Agenten und Governance für die Organisation.

Nachrichten als Einträge

Die Einträge eines Threads sind Nachrichten. Sie sind nicht auf Text beschränkt, sondern können auch Bilder, Tabellendateien oder generierten Code enthalten. Jede Nachricht trägt einen Zeitstempel und eine Rolle, entweder Benutzer oder Assistent. Wer einen Thread untersucht, sieht daher, was gesagt wurde, wer es wann sagte und um welchen Inhaltstyp es sich handelte. Ein Compliance-Beauftragter kann so die Textanfrage vom Vortag, das vom Agenten erzeugte Diagramm und beide Zeitpunkte nachvollziehen.

Nutzen für Audit und Entwicklung

Regulierungsbehörden oder interne Prüfteams sehen im Thread den gesamten Ablauf: Anfrage, Antwort, verwendete Tools und Zeitpunkt. Entwickler nutzen dieselben Aufzeichnungen wie einen Debug-Modus. Hat ein Agent einen falschen Codeschnipsel erzeugt, lässt sich der Thread bis zur auslösenden Anfrage zurückverfolgen. Bei Workflows, die juristische Texte abrufen, zeigt das Protokoll Anfrage, Antwort und die Information, ob unterstützende Tools aufgerufen wurden. Kommunizieren mehrere Agenten miteinander, wird auch dieser Austausch festgehalten.

Runs: Wenn der Agent vom Plan zur Ausführung übergeht

Ein Thread speichert Gesprächsverlauf, Anweisungen und Kontext. Ein Run ist der Auslöser, der den Agenten aktiviert, damit er diesen Kontext verarbeitet. Man kann sich den Run als Startknopf vorstellen: Der Thread enthält etwa die Bitte, eine CSV-Datei zu analysieren oder ein Liniendiagramm zu zeichnen. Der Run ist der Moment, in dem der Agent diese Anfrage mit Modell, Anweisungen und Werkzeugen bearbeitet. Er kann dabei zusätzliche Daten abrufen, Berechnungen durchführen oder den Code-Interpreter aufrufen, um ein Artefakt zu erzeugen.

Runs sind keine Blackbox, sondern überwachte, statusverfolgte Ausführungen. Typische Status sind:

• in der Warteschlange
• in Bearbeitung
• erfordert Aktion
• abgeschlossen
• fehlgeschlagen

SDK-Beispiele fragen diese Zustände häufig in einer Schleife ab. So wissen Sie nicht nur, was erledigt wird, sondern auch, wann es geschieht.

Run-Steps: Nachvollziehbarkeit bis auf Schrittebene

Eine Antwort kann überzeugend aussehen, und trotzdem bleibt unklar, ob der Agent eine externe API aufgerufen, Code geschrieben oder nur Text improvisiert hat. Diese Undurchsichtigkeit ist in Unternehmensumgebungen riskant. Run-Steps lösen das Problem, indem jeder Run Schritt für Schritt aufgezeichnet wird: welche Modellausgaben erzeugt, welche Tools aufgerufen, welche Berechnungen durchgeführt und welche Nachrichten produziert wurden.

Das gleicht einer Schachnotation für KI. Statt „Bauer nach e4“ steht dort sinngemäß: Datei abrufen um 10:02, Codeblock ausführen um 10:03, Diagramm-Artefakt zurückgeben um 10:04. Jede Aktion wird in Reihenfolge notiert und lässt sich später wiederholen.

Vorteile für Entwickler

Ohne Run-Steps bleibt nur eine fertige Antwort und die Frage, wie sie entstanden ist. War die Suchanfrage falsch? Hat sich ein Rechenfehler eingeschlichen? Mit Run-Steps scrollen Sie durch die Zeitleiste, identifizieren den genauen Fehler und beheben ihn. Fehlersuche wird so zu Forensik statt zu Rätselraten.

Vorteile für Compliance-Teams

Fragen Auditoren, wie eine Zusammenfassung erstellt wurde, muss niemand die Modelllogik abstrakt erklären. Es gibt einen Beleg: den Toolaufruf, den Interpreter-Schritt und die zusammengestellte Antwort, alles mit Zeitstempel. Das verwandelt Erklärungen in Governance, denn es zählen Beweise statt Geschichten. Muss ein Workflow erneut laufen oder wird ein Ergebnis angezweifelt, kann man derselben Sequenz folgen und sie erneut abspielen.

Zusammengefasst: Threads sind das Tagebuch, Runs die Aktivierung und Run-Steps das detaillierte Einsatzprotokoll.

Tools, MCP und Sicherheit: Vom Chat zum Arbeitsagenten

Erst Tools machen aus einem plaudernden Agenten einen Arbeiter. Statt zu beschreiben, wie man ein Dokument prüft oder rechnet, führt er die Aufgabe aus und liefert das Ergebnis. Foundry kennt dafür drei Kategorien.

1. Integrierte Tools

Dazu zählen der Code-Interpreter, die Bing-Suche, SharePoint- und Microsoft Fabric-Konnektoren sowie Azure AI Search. Der Agent kann damit Daten analysieren, Dateien abrufen, Unternehmensinhalte durchsuchen und Diagramme oder Berichte erstellen, ohne dass dafür eigener Code nötig ist.

2. Eigene Tools über OpenAPI und MCP

Sie sind nicht auf das beschränkt, was Microsoft bereitstellt. Eigene Tools lassen sich über OpenAPI-Spezifikationen oder das Model Context Protocol (MCP) registrieren. MCP funktioniert wie ein USB-C-Anschluss für KI-Tools: Beim Anbinden an entfernte MCP-Server übernimmt das System Toolerkennung, Versionierung und Aufruf automatisch, ohne dass Sie Wrapper von Hand schreiben. Das senkt den Integrationsaufwand erheblich, vor allem wenn viele Systeme verknüpft werden müssen. Über Logic Apps erreicht der Agent außerdem über 1400 bestehende SaaS- und On-Premises-Konnektoren. Statt Adapter für CRM-, ERP- oder ITSM-Plattformen neu zu programmieren, konfigurieren Sie die Konnektoren, die das Unternehmen bereits nutzt.

3. Beobachtbare Tool-Aufrufe

Jeder Aufruf wird auf Step-Ebene mit Identität, Eingaben, Ausgaben und Zeitstempeln protokolliert. So lässt sich genau nachvollziehen, was aufgerufen wurde, ob Berechtigungen eingehalten wurden, und es entstehen dauerhafte Nachweise für die Compliance.

Ein Beispiel aus der Praxis

Sie laden eine CSV-Datei als Nachricht in einen Thread hoch. Der Agent ruft in seinen Ausführungsschritten den Code-Interpreter auf, verarbeitet die Datei und erzeugt ein Diagramm. Dieses erscheint als angehängtes Bild direkt im Thread-Protokoll. Parser- oder Visualisierungscode mussten Sie nicht schreiben: Sie gaben eine Anweisung, der Agent wählte das Tool und lieferte die Datei, die sich direkt in einen Bericht einfügen lässt.

Berechtigungen bleiben erhalten

Greifen Tools auf Unternehmenssysteme wie SharePoint oder Fabric zu, geschieht das über eine durch Microsoft Entra vermittelte Authentifizierung im Auftrag des Benutzers. Fehlt einem Nutzer die Leseberechtigung für eine Datei, umgeht der Agent diese Barriere nicht. Identität und Berechtigungen bleiben intakt, und jeder Aufruf ist nachvollziehbar: Wer hat ihn ausgelöst, was wurde gesendet, was empfangen? Dadurch agiert der Agent innerhalb von Leitplanken, denen die IT bereits vertraut.

Praktische Takeaways

• Bauen Sie Agenten bewusst aus Modell, Anweisungen und Werkzeugen auf. Ohne alle drei fehlen Reproduzierbarkeit und Revisionssicherheit.
• Nutzen Sie die Modellvielfalt im Foundry-Katalog und wählen Sie das Modell passend zur Aufgabe.
• Verstehen Sie Threads als dauerhaftes Protokoll mit Rollen, Zeitstempeln und unterschiedlichen Inhaltstypen, nicht als flüchtigen Chat.
• Überwachen Sie Runs über ihre Statuswerte und werten Sie Run-Steps aus, um Fehler gezielt zu finden.
• Setzen Sie für Unternehmensanbindungen auf integrierte Tools, OpenAPI, MCP und Logic Apps, statt eigene fehleranfällige Brücken zu bauen.
• Verlassen Sie sich auf Microsoft Entra, damit Berechtigungen der Nutzer auch beim Agentenzugriff gelten.
• Starten Sie ein Testprojekt: Erstellen Sie einen Basisagenten, führen Sie einen Thread aus und untersuchen Sie die Run-Steps im SDK (zum Beispiel .NET) oder im Portal.

Fazit

Azure AI Foundry behandelt KI-Agenten nicht als magische Gesprächspartner, sondern als gesteuerte Operatoren mit Regelwerk, Ausrüstung und lückenloser Dokumentation. Threads halten die Konversation fest, Runs führen sie aus, und Run-Steps machen jeden einzelnen Schritt sichtbar. Für Entwicklungsleiter und Compliance-Verantwortliche heißt das: reproduzierbare, prüfbare Ausführungen mit voller Kontrolle über den Lebenszyklus. Ergebnisse lassen sich so belegen statt nur behaupten.