Wie Agents funktionieren

Ein Agent steht auf drei Dingen: was er lesen kann, was er aufrufen kann und was er ändern darf. Wenn das Dritte stimmt, lassen sich die ersten beiden gefahrlos vergeben.

Ein Signup Profiler auf Microsoft Foundry macht aus einer nackten Testregistrierung ein Lead-Profil, bevor ein Mitarbeiter sie öffnet: Beruf, Unternehmen, eine Empfehlung, ein Confidence Score und die Quell-Links hinter jedem Befund, mit Tracing und Token-Verbrauch pro Run. Eine Document Pipeline nimmt Dokumente über die Sidebar, als Handyfoto oder aus einem gemeinsamen Postfach über Microsoft Graph und archiviert jedes Original.

Model Context Protocol macht aus einer bestehenden REST API typisierte Tools, die Mitarbeiter in ihren eigenen Worten aufrufen. Das Modell entwirft; ein interaktives Formular führt den einzigen Schreibvorgang aus.

Was einen Run betriebsfähig macht

Zwischen einer Demo und einem betriebsfähigen Run liegt dauerhafter State. Microsoft Agent Framework 1.0, im April 2026 für .NET und Python erschienen, liefert das gemeinsame Ledger, das jedes Mitglied auf Stand hält: was erledigt ist und was noch offen ist.

Microsoft Foundry Hosted Agents laufen mit Scale-to-Zero und VM-Isolation pro Session, ein langer Run hält zwischen den Schritten also keine Infrastruktur warm. Das Agent Harness ergänzt automatische Context Compaction und OpenTelemetry Tracing nach Application Insights und hält damit jede Stage prüfbar.

Die Failure Modes, auf die es ankommt, zeigen sich im Betrieb, nicht beim Lesen der Dokumentation. Jeder wird beim ersten Mal, an dem er diagnostiziert wird, ins Harness geschrieben. So zahlt man den Preis einmal und nicht bei jedem Build.

Multi-Agent & Autonomous

Manche Arbeit ist zu groß für einen einzelnen Agent. Das Microsoft Agent Framework teilt sie auf: Ein Researcher sammelt Material, ein Writing Team entwirft und prüft, und ein gemeinsames Ledger hält jedes Mitglied auf Stand, was erledigt ist und was noch aussteht.

Diese Pipeline läuft heute in Production. Ein Operator beschreibt einen Artikel, die Anfrage streamt zu einem Team auf Microsoft Foundry, und das Ergebnis kommt vollständig zurück: der Artikel mit Frontmatter, ein LinkedIn-Post, eine SEO-Datei, ein Publish Manifest und eine Variante in der zweiten Sprache.

Autonomie hat einen Boden. Magentic Teams scheitern an der Responses API von Microsoft Foundry mit einem Manager-Ledger-Fehler; die funktionierende Konfiguration ist der Chat Completions Client. Dieser Befund wird einmal aufgeschrieben und nie wieder neu verhandelt.

7
Schedule Tools, die Fragen aus dem Büro im Chat Client beantworten
0
gespeicherte Datensätze, bevor ein Mensch den Vorschlag freigibt
10×
schnellere Antwortentwürfe nach einem Modellwechsel, zu einem Viertel der Kosten
3 Wochen
vom leeren Repository zur Anwendung in Production

Von der wöchentlichen Fleißarbeit zum Run, den jemand prüfen kann

Envision & Plan 2 Schritte
01

Fangen Sie bei den Aufgaben an, die die Woche wirklich auffressen

Die Kandidatenliste kommt von den Menschen, die die Arbeit machen, nicht aus einer Technologie-Inventur. Eine einwöchige Erhebung hält fest, wohin die Zeit der erfahrenen Leute tatsächlich geht, ein Scoring-Raster bewertet jede Aufgabe auf AI-Eignung gegen Aufwand und Wiederholung, und ein Workshop von 90 Minuten wählt die fünf besten zum Bauen aus. Aufgaben, die automatisierbar aussehen, aber in jedem einzelnen Fall echtes Urteilsvermögen brauchen, werden hier benannt und ausgeschlossen. Das im Workshop herauszufinden kostet eine Stunde. Es im Build herauszufinden kostet eine Phase.
02

Jede ausgewählte Aufgabe bekommt einen Delivery Path und eine Baseline

Jede ausgewählte Aufgabe wird dem Delivery Path zugeordnet, der zu ihr passt, und der Baseline, an der sie gemessen wird. Manche Aufgaben brauchen einen Agent, der liest und empfiehlt, manche einen, der Live-Systeme aufruft, und manche mehrere Agents, die sich über Arbeit abstimmen, die für einen allein zu groß ist. Data Residency, Identity und Audit-Anforderungen werden hier geklärt und nicht später in einem Review entdeckt. Die Baseline-Zahlen werden festgehalten, bevor irgendetwas gebaut wird. So läuft der Vergleich danach gegen eine gemessene Zahl statt gegen einen Eindruck.
Implement 4 Schritte
03

Setzen Sie den Agent dorthin, wo die Frage ohnehin gestellt wird

Mitarbeiter öffnen keine Anwendung, um eine Frage zu stellen, die sie tippen könnten. Ein ausgelieferter Build stellt sieben Schedule Tools über Model Context Protocol auf eine laufende Planungsdatenbank bereit, geschrieben im deutschen Vokabular des Büros, sodass unscharfe Mitarbeiter- und Gebäudenamen richtig aufgelöst werden, und als Custom Connector an Claude angebunden. Der Zugriff läuft über API-Key-Authentifizierung mit OAuth Protected-Resource Metadata, und der Connector zeigt auf den Staging Slot, bevor er je an Production-Daten kommt.
04

Binden Sie die Dokumente an, bevor Sie das Modell anbinden

Ein Agent ist genau so viel wert wie das, was er lesen kann. Eine ausgelieferte Ingestion Pipeline nimmt drei Wege in eine gemeinsame Review Queue: eine Datei, die in die Sidebar gezogen wird, ein Foto vom Handy und ein gemeinsames Postfach, gelesen über Microsoft Graph. Die Extraktion macht aus jedem Dokument einen Entwurfsdatensatz, das Originaldokument wandert ins Blob Storage, und der Datensatz trägt ein Review Flag, bis ein Mensch ihn bestätigt. Nichts kommt ungesehen in die Bücher.
05

Das Modell entwirft, ein Mensch schreibt

Das Pattern, das einen schreibfähigen Agent akzeptabel macht: Das Modell hält nie den Schreibpfad. In der ausgelieferten Implementierung erzeugt das Modell einen Entwurf und gibt ein interaktives Formular zurück, das im Chat Client gerendert wird, und dieses Formular ruft das eine Save Tool dahinter auf. Ein Modell, das nicht direkt schreiben kann, kann auch nichts Falsches schreiben. Das ist meist der Unterschied zwischen einer Integration, die der Owner eines System of Record freigibt, und einer, die er ablehnt.
06

Gegen echte Daten laufen lassen, gespeichert wird erst nach dem Review

Ein monatlicher Planungslauf zeigt die Form. Das Büro legt seine Excel-Arbeitsliste auf der Planungsseite ab, das Modell liest sie, ordnet die Gebäude zu und schlägt einen ganzen Monat an Technikerrouten vor, nach Standort gruppiert, mit echten Fahrzeiten aus Google Maps. Kein einziger Datensatz wird geschrieben, bevor ein Mensch den Vorschlag geprüft hat. Der Lauf läuft serverseitig mit sichtbarem Fortschritt und legt einen History-Eintrag an. So lässt sich ein Plan auch Wochen nach der Freigabe noch erklären.
Operate 3 Schritte
07

Modellwahl und Kosten bleiben eine administrative Entscheidung

Welches Modell einen Use Case fährt, gehört in eine Einstellung, nicht in ein Deployment. Jedes AI Feature kommt mit einer Model Registry: Ein Administrator wählt das Modell pro Use Case in einem Admin-Screen, vergibt AI Credits pro Benutzer und hält die Token-Kosten dem Feature zurechenbar, das sie verursacht hat. Diese Kontrolle zahlt sich schnell aus. Bei einem Feature für Antwortentwürfe machte ein Modellwechsel die Vorschläge rund zehnmal schneller und viermal günstiger, ohne dass am Feature selbst etwas geändert wurde.
08

Jeder Run wird Stage für Stage nachvollziehbar

Probleme sollen in einem Log landen, bevor sie bei einem Benutzer landen. Eine Resolution Pipeline fächert einen einzelnen Barcode-Scan auf vier öffentliche Quellen auf, führt die Kandidaten mit einem Sprachmodell zusammen und fällt auf Vision zurück, wenn kein Barcode lesbar ist. Jede Stage schreibt eine JSON-Zeile mit Correlation ID und Token-Kosten, und derselbe Trace läuft als mitwachsende Stage-Liste mit Live-Kostenanzeige auf den Bildschirm. Kosten pro Run und Fehlerpfade bleiben danach nachvollziehbar.
09

Die E-Mail des Kunden ist das Backlog

Change Requests brauchen kein Ticketsystem. Am 4. August 2026 wurde aus einer einfachen E-Mail aus dem Büro eines Kunden ein Paket an Änderungen: in der laufenden Session gelesen, in ein dokumentiertes Work Item überführt, umgesetzt und als Preview-Adresse zurückgegeben, die den neuen Build gegen eigene isolierte Testdaten fährt. Der Kunde prüfte eine funktionierende URL, und danach wurde das Paket promoted. Onboarding-Material übergibt denselben Loop an die Mitarbeiter, die ihn künftig fahren.

Häufige Fragen

Was ist ein Agentic Business Process?
Ein Prozess, in dem der Agent liest, zuordnet und entwirft, und ein Mensch die Freigabe verantwortet. Ein ausgeliefertes Beispiel nimmt die monatliche Excel-Arbeitsliste, die das Büro ohnehin erstellt, ordnet die Gebäude zu und schlägt einen ganzen Monat an Technikerrouten vor, nach Standort gruppiert, mit echten Fahrzeiten aus Google Maps. Kein einziger Datensatz wird gespeichert, bevor jemand den Vorschlag geprüft hat, und jeder Run legt einen History-Eintrag an, der das Ergebnis später erklärt.
Was macht einen Agentic Process betriebsfähig statt zu einer Demo?
Ein Agentic Process in Production braucht drei Dinge, die eine Demo meist auslässt: ein gemeinsames Ledger, das den State hält, wenn ein Run länger dauert als eine Session; eine Kostenerfassung pro Stage, damit die Ausgaben zurechenbar bleiben; und einen aufgeschriebenen Failure Mode für jedes Plattformverhalten, das der eigenen Dokumentation widerspricht. Das Ledger liefert Microsoft Agent Framework 1.0. Microsoft Foundry Hosted Agents liefern Isolation pro Session und Scale-to-Zero, damit lange Runs keine Infrastruktur warm halten. Das Agent Harness bringt automatische Context Compaction und OpenTelemetry Tracing nach Application Insights mit, damit der Fehlerpfad, der beim dritten Run auftaucht, beim vierten nicht wiederkommt.
Wie kommen Agents an Unternehmensdaten, ohne das System neu zu bauen?
Über Model Context Protocol auf der API, die es ohnehin schon gibt. Eine Planungsplattform stellt sieben Schedule Tools auf ihrer laufenden Datenbank bereit, mit Tool-Beschreibungen im deutschen Vokabular des Büros, sodass unscharfe Mitarbeiter- und Gebäudenamen richtig aufgelöst werden, als Custom Connector an Claude angebunden. Mitarbeiter fragen, wer an einem bestimmten Tag einen Termin hat, statt den Planer zu öffnen. Der Connector läuft gegen den Staging Slot, bevor er auf Production zeigt.
Was hindert einen Agent daran, etwas Falsches in ein System of Record zu schreiben?
Das Modell bekommt den Schreibpfad nicht. Im ausgelieferten Pattern erzeugt es einen Entwurf und gibt ein interaktives Formular zurück, das im Chat Client gerendert wird, und dieses Formular ruft das eine Save Tool dahinter auf. Die Dokumentenannahme funktioniert genauso: Ein extrahierter Datensatz trägt ein Review Flag, und das Quelldokument bleibt im Blob Storage archiviert, bis ein Mensch ihn bestätigt. Die Freigabe ist ein Schritt im System, keine Gewohnheit, um die man Menschen bittet.
Wer entscheidet, welches Modell läuft, und was kostet ein Run?
Ein Administrator, in einer Model Registry mit einem Default pro Use Case und AI Credits pro Benutzer. Die Wirkung ist messbar: Bei einem Feature für Antwortentwürfe machte ein Modellwechsel die Vorschläge rund zehnmal schneller und viermal günstiger, ohne dass am Feature etwas geändert wurde. Auch auf Run-Ebene bleiben die Kosten sichtbar, denn jede Pipeline Stage schreibt eine JSON-Zeile mit ihren Token-Kosten, und derselbe Trace läuft als Live-Anzeige auf den Bildschirm.
Was passiert, wenn sich die Plattform anders verhält, als die Dokumentation sagt?
Sie wird einmal diagnostiziert und festgehalten. Magentic Teams auf Microsoft Foundry scheitern an der Responses API mit einem Manager-Ledger-Fehler; die funktionierende Konfiguration ist der Chat Completions Client. Dieser Befund liegt jetzt im Harness, das mit der Codebase mitreist, neben dem Deployment Run-Book und den Conventions. Die Failure Modes einer Plattform zu kennen ist ein großer Teil dessen, was ein zweites Projekt darauf schneller macht als das erste.