Vom Chatbot zum handelnden Agenten
Ein Chatbot beantwortet Fragen. Ein Agent führt Aktionen aus: Reise buchen, E-Mail schreiben, Ticket anlegen, Datenbankabfrage starten. Aus einem Gespräch wird eine Handlung. Falsche Handlungen wiegen schwerer als falsche Antworten. Microsofts KI-Agenten werden von über 80.000 Unternehmen genutzt; der Microsoft 365 Copilot hat mehr als 20 Millionen aktive Nutzer. Marco Casalaina, VP of Products bei Microsoft Core AI, berichtet aus den eingesetzten Systemen. Seine Erkenntnis: Wer einen Prototyp für produktionsreif hält, irrt.
Der Wandel ist grundlegend. „Wir verlassen die Phase der reinen Fragebeantwortung“, sagt Casalaina. „2026 nutzen mehr Kunden Sprache als Frontend; das Chatbot-Zeitalter endet.“ Bisher tippte der Nutzer, der Bot antwortete. Jetzt handelt der Agent: Er bucht Meetings, führt Analysen durch, sendet E-Mails, legt Tickets an. Der Nutzer kann per Sprache interagieren. Mit „Voice Live“ wird ein Text-Agent ohne Neuentwicklung zum Sprachagenten.
Warum der Prototyp in der Produktion scheitert
Ein Agent lässt sich mit einem guten Sprachmodell an einem Nachmittag zusammenbauen. Der erste Prototyp überzeugt im Test. Die Testprompts laufen, die Demo gelingt, nach einer Woche steht die Pilotversion. Probleme zeigen sich erst mit echten Nutzern. Sie stellen unvorhergesehene Fragen. Dokumente veralten. Neue Randfälle erscheinen, die nicht im Testdatensatz waren. Ein Modell-Update ändert das Verhalten des Agenten subtil – unbemerkt, bis ein Kunde sich beschwert. Ohne Identitätskontrollen läuft der Agent als Systemkonto. Bei Fehlern fehlt die Prüfspur. Ohne Schutzmechanismen äußert er selbstbewusst Falsches. Ohne Beobachtbarkeit bleibt unklar, ob die Qualität steigt oder fällt. Im Prototyp zeigt sich keines dieser Probleme; in der Produktion treten alle auf.
„Das Harness ist genauso wichtig wie das Modell“, sagt Casalaina. Harness bezeichnet die gesamte Infrastruktur um das Modell: Laufzeit, Werkzeuge, Kontextabruf, Identität, Absicherungen, Evaluatoren, Bereitstellungspipeline. Modelle ändern sich häufig; Datenbank-Updates sind meist einfacher. Jedes Modell hat eigene Eigenschaften, auf die das Harness reagieren muss. Als Anthropic Claude Opus 4.8 erschien, justierte das GitHub Copilot CLI Team sein Harness nach und führte Evaluierungen erneut durch, bevor sie das Modell auslieferten.
Die fünf Schichten des Produktions-Harness
Ein Produktionsagent besteht aus mehr als einem Sprachmodell. Microsoft nennt fünf Schichten, die zusammenspielen müssen.
1. Die Inferenzschicht: Die unterste Schicht ist die einheitliche Schnittstelle zum Modellzugriff. Modelle bleiben austauschbar. Foundry unterstützt zahlreiche Modelle (OpenAI, Anthropic, xAI, DeepSeek, Microsofts MAI-Familie). Verschiedene Agenten benötigen verschiedene Modelle, und das passende Modell wechselt oft.
2. Die Agentenlaufzeit (Agent Runtime): Die Laufzeitumgebung macht aus dem Modell einen Agenten. Sie steuert Orchestrierung, Werkzeugaufrufe, Gesprächszustand. Nicht jeder Schritt braucht das LLM; ein guter Agent schickt nur logisch anspruchsvolle Aufgaben an das Modell und erledigt andere wie Datenbanksuchen mit normalem Code. Framework-Neutralität ist wichtig: Ein Agent sollte zwischen Frameworks (z.B. LangChain, LangGraph, CrewAI) portierbar sein, ohne das Harness neu zu schreiben. Foundry unterstützt den Austausch.
3. Observability und Governance: In der Produktion braucht die Organisation eine einheitliche Sicht auf alle Agenten. Dazu gehören Gesundheitsmetriken, Token-Verbrauch, Latenz, Drift-Erkennung und Projektübersichten für das Plattform-Team. Ohne diese Schicht bleiben Regressionen unsichtbar, Kosten steigen. Foundrys Control Plane liefert eine projektübergreifende Flottenübersicht und leitet Telemetriedaten an Azure Monitor und Application Insights weiter – die gleiche Pipeline wie für Infrastruktur-Alarme.
4. Identitätsschicht: Wenn Agenten Aktionen ausführen, brauchen sie eigene Identitäten, Rollen und Prüfspuren. Ein fehlerhafter Agent sollte durch dieselben Zugriffskontrollen begrenzt werden wie ein fehlerhafter Mitarbeiter. Die Branche erweitert vorhandene Enterprise-Identitätssysteme um Agenten als neue Prinzipal-Klasse. Foundry erweitert Microsofts Entra zu diesem Zweck.
5. Kontextschicht (Context Layer): Die Kontextschicht stellt sicher, dass der Agent richtig antwortet. Ohne guten Kontext halluziniert er – er antwortet selbstbewusst, aber falsch, weil er nicht erkennt, was er nicht weiß. Casalaina nennt die Bereitstellung des richtigen Kontexts eine der schwierigsten Aufgaben.
Zwei Engineering-Ideen aus Foundry
Erstens: Retrieval-as-a-Subagent. Der Kontextabruf wird als Unteragent modelliert, der Daten dynamisch abruft und aufbereitet, statt auf einer statischen Wissensdatenbank zu basieren. Das ermöglicht feinere Steuerung und Fehlerbehandlung.
Zweitens: Agenten einen eigenen Platz zum Handeln geben. Mit einer Identität kann der Agent lesen und schreiben – Dokumente in SharePoint, Datensätze in Dynamics, E-Mails in Outlook. Microsoft hat die Agent-Identität in Entra etabliert, sodass der Agent als Akteur mit definierten Rechten und Prüfspur handelt.
Evaluierung und kontinuierliche Verbesserung
Microsoft bewertet Produktionsagenten mit ergebnisbasierten Kennzahlen nach einem Bewertungsraster (Rubric). Die Evaluierung läuft automatisiert: Der Agent bearbeitet einen Datensatz typischer Aufgaben, die Ergebnisse werden gegen eine vordefinierte Matrix gemessen. Die Messwerte fließen in eine automatische Verbesserungsschleife, in der das Harness selbstständig Anpassungen vornimmt – etwa die Gewichtung von Kontextquellen oder die Reihenfolge der Tool-Aufrufe. Der Prozess läuft kontinuierlich – Dokumente aktualisieren sich, neue Modelle erscheinen. Einmalige Evaluierung genügt nicht.
Was das für andere Teams bedeutet
Diese Lektionen lassen sich auf jedes Unternehmen übertragen: Erstens: Unterschätze die Komplexität des Modellumfelds nicht. Der Prototyp ist einfach, die Produktion schwer. Zweitens: Baue einen modularen Harness, der Modelle und Frameworks austauschbar hält. Drittens: Gib deinen Agenten eine Identität – sonst sind sie weder sicher noch prüfbar. Viertens: Investiere von Anfang an in Beobachtbarkeit und Evaluierung, nicht erst nach einem Vorfall.
Quelle: blog.bytebytego.com
