Ein Agent ist ein Aktionssystem
Der wichtige Unterschied zwischen einem Chatbot und einem Agenten ist nicht die Oberfläche. Es ist die Befugnis. Ein Agent kann Werkzeuge aufrufen, Daten abrufen, Zustand bewahren und eine Folge von Entscheidungen ausführen. Damit werden Identität, Berechtigungen, Fehlerbehandlung und Beobachtbarkeit zum Produkt – nicht zu Infrastrukturdetails für später.
Microsoft Foundry Agent Service bietet mehrere Runtime-Formen. Die sinnvolle Frage ist nicht, welche am fortschrittlichsten erscheint. Entscheidend ist, welche genügend Kontrolle für die Mission bietet, ohne unnötigen Betriebsaufwand zu erzeugen.
Drei Bereitstellungsformen
Prompt-Agenten
Prompt-Agenten werden über Instruktionen, ein Modell und Werkzeuge definiert; Foundry betreibt die Runtime. Sie passen zu klar begrenzten Assistenten und Workflows ohne eigene Orchestrierungslogik.
Die verwaltete Runtime reduziert Container- und Skalierungsarbeit. Sie ersetzt weder versionierte Instruktionen noch repräsentative Tests, Berechtigungsdesign und Betriebsverantwortung.
Hosted Agents
Hosted Agents verpacken eigenen Agent-Code für einen von Foundry verwalteten Endpunkt. Sie eignen sich für individuelle Orchestrierung, Framework-spezifisches Verhalten, Multi-Agent-Koordination oder besondere Interaktionsprotokolle.
Diese Flexibilität schafft mehr Verantwortung für Code und Abhängigkeiten. Die Organisation bleibt Eigentümerin der Logik, auch wenn Foundry die Containerumgebung betreibt.
Bestehende Anwendungs-Runtimes
Teams können Agent-Code auch in einer bestehenden Anwendung belassen und die Responses API von Foundry für Modelle und Plattformwerkzeuge aufrufen. Das ist sinnvoll, wenn die Anwendung bereits ein reifes Bereitstellungs-, Identitäts- und Beobachtbarkeitsmodell besitzt.
Migrieren Sie keine stabile Runtime, nur damit das Architekturdiagramm einheitlicher aussieht.
Den Betriebsrahmen definieren
Eine Instruktion wie «Sei vorsichtig» ist keine Kontrolle. Ein produktiver Rahmen muss ausserhalb des Modells bestehen:
- nur die für die aktuelle Aufgabe notwendigen Werkzeuge freigeben;
- Ein- und Ausgaben deterministisch validieren;
- Nutzer- oder Workload-Identität in nachgelagerten Aufrufen bewahren;
- folgenschwere oder irreversible Aktionen bestätigen lassen;
- Zeit, Werkzeugaufrufe, Ausgaben und betroffene Datensätze begrenzen;
- Seiteneffekte soweit möglich idempotent oder wiederherstellbar machen;
- bei unzureichender Sicherheit, Berechtigung oder Verfügbarkeit stoppen und eskalieren.
Das System sollte weniger Befugnisse besitzen als die unterstützte Person – nicht gemeinsame Zugangsdaten mit grösserem Zugriff.
Werkzeuge als Verträge entwerfen
Name und Beschreibung eines Werkzeugs beeinflussen das Modellverhalten. Die empfangende Anwendung bleibt jedoch die Sicherheitsgrenze. Geben Sie jedem Werkzeug einen engen Zweck und ein typisiertes Schema. Lehnen Sie mehrdeutige Bezeichner, unzulässige Felder und unmögliche Zustandsübergänge ab.
Trennen Sie Lese- und Schreibwerkzeuge. Stellen Sie für folgenreiche Änderungen Vorschau- oder Dry-Run-Funktionen bereit. Strukturierte Fehler sollen eine sichere Wiederherstellung ermöglichen, statt ein erfundenes Erfolgsergebnis zu provozieren.
Für den Kundendienst sind «freigegebene Bestellübersicht abrufen» und «Stornierungsanfrage für Bestellung X erstellen» bessere Verträge als ein generisches Werkzeug «ERP-Operation ausführen».
Entscheidungen nachzeichnen, nicht verborgenes Denken
Nützliche Beobachtbarkeit erfasst Anfrage, Modell- und Agent-Version, Werkzeugauswahl, validierte Argumente, Werkzeugresultat, Latenz, Token-Nutzung, Richtlinienentscheide und Endergebnis. Sie sollte nicht vom Sammeln privater Gedankengänge abhängen.
Untersuchen Sie fehlgeschlagene und beinahe fehlgeschlagene Traces als Produktevidenz. Ein Trace mit korrekter Endantwort nach wiederholten unberechtigten Werkzeugaufrufen ist kein erfolgreicher Trace.
Menschliche Kontrolle muss operativ sein
«Human in the loop» wird oft notiert, ohne Mensch, Auslöser oder Reaktionszeit zu benennen. Definieren Sie:
- welche Aktion eine Freigabe erfordert;
- wer die Anfrage erhält;
- welche Evidenz sichtbar ist;
- wie lange das System wartet;
- was bei Ablehnung oder Zeitüberschreitung geschieht;
- wie der Workflow gestoppt oder zurückgesetzt wird.
Der Eskalationsweg muss während eines Vorfalls funktionieren, nicht nur in einer Demo.
Der Produktionstest
Bevor Sie mehr Autonomie gewähren, belegen Sie, dass der Agent die begrenzte Aufgabe erfüllt, sicher scheitert, Identität bewahrt, Grenzen respektiert und eine prüfbare Spur hinterlässt. Beginnen Sie mit Empfehlungen, ergänzen Sie Werkzeugnutzung unter Bestätigung und erweitern Sie die Befugnis nur bei ausreichender Evaluations- und Betriebsevidenz.
Die beste Agentenarchitektur ist nicht jene mit der grössten Autonomie. Es ist jene mit der kleinsten Befugnis, die für das Ergebnis ausreicht.
Offizielle Referenz
Microsoft beschreibt Prompt-Agenten, Hosted Agents, die direkte Nutzung der Responses API, Werkzeuge, Identität und Beobachtbarkeit in der Übersicht über Foundry Agent Service.