Drei Stellen gibt es in einem agentischen Ablauf, an denen er aus der Spur laufen kann: die Daten, die ins Modell hineingehen, der Ablauf selbst mit seinen Grenzen und die Rückmeldung, aus der er für den nächsten Lauf lernt. Diese Dreiteilung stammt nicht aus einem Lehrbuch, sondern aus der Arbeit am FeedAgent von monday.com, einem Agenten, der für jedes Mitglied eines Workspace einen persönlichen Activity Feed zusammenstellt. Das zuständige Engineering-Team beschreibt in einem langen Erfahrungsbericht, wie es dafür einen eigenen Harness gebaut hat – den Rahmen also, der einen Agenten führt, begrenzt und überprüft. Interessant daran ist nicht die einzelne Technik, sondern die Haltung: Der Rahmen ist ein eigenes Ingenieursprodukt, kein Anhängsel des Modells.
Das Team greift zu einem Bild, das sich durch den ganzen Bericht zieht: Eine Bowlingkugel läuft über die Bahn, der Harness ist die Bande an den Seiten. Ohne sie genügt ein schlechter Wurf, und die Kugel landet in der Rinne – eine erfundene Quellenangabe, eine falsche Ausgabeform, eine Endlosschleife, die das Budget verbrennt. Die Bande garantiert keinen Strike, aber sie hält die Kugel auf der Bahn. Diese Unterscheidung lässt sich auf jeden Agenten übertragen, der in Produktion läuft.
Was ein Harness leistet – und warum er nicht das Modell ist
Ein KI-Agent ist keine Pipeline, die einmal von links nach rechts durchläuft. Er ist eine Schleife: überlegen, Werkzeug aufrufen, erneut überlegen, irgendwann fertig. In jeder Runde kann etwas schiefgehen, und die Zahl der möglichen Wege wächst mit jedem Durchlauf. Ein robuster Harness für KI-Agenten in Produktion prüft diese Wege nicht einzeln, sondern legt einen Rahmen um sie: Er bestimmt, was der Agent zu sehen bekommt, wie weit er laufen darf, was von seinem Ergebnis Bestand hat und was er sich für den nächsten Lauf merkt. LLM Guardrails wirken dabei über den gesamten Ablauf, nicht erst am Ende.
Die Methode des Teams nennt sich „walk the flow“: Man geht jede Phase der Ausführung durch, betrachtet die Abzweigungen und Kurven, die der Agent nehmen kann, und stellt an jeder Stelle dieselbe Frage – was kann hier schiefgehen, und was tut der Harness dagegen? Das klingt banal, ist aber der eigentliche Aufwand. Einen Rahmen um einen Ablauf zu bauen, den man nicht in allen Einzelheiten kennt, funktioniert nicht. Und weil jeder Feed anders aussieht, den der Agent zusammenstellt, wiederholt sich diese Arbeit für jede Variante ein Stück weit neu.
Bestehende Lösungen helfen, ersetzen die eigene Arbeit aber nicht. LangChain bringt eine Agentenarchitektur mit eingebautem Harness mit, und das Team nutzt sie als Fundament. Darüber hinaus braucht es laut dem Bericht zwei Dinge: ein gründliches Verständnis des verwendeten Rahmens und ein ebenso gründliches Verständnis der eigenen Domäne. Erst aus beidem entsteht ein Harness, der zu den konkreten Anforderungen passt. KI-Agenten mit Guardrails zu bauen ist am Ende mehr eine Frage der Domänenkenntnis als der Bibliothekswahl.
Datenaufbereitung und PII-Schutz, bevor das Modell etwas sieht
Die erste Phase liegt noch vor dem eigentlichen Agentenlauf. Zuerst entsteht der System-Prompt: Hintergrund zur Aufgabe, Beschreibung des Ablaufs, Definition dessen, was als Erfolg gilt. Danach kommen die Daten des konkreten Feeds – Aktivitäten von Nutzern und Agenten über verschiedene Assets hinweg, bereits vorhandene Feed-Einträge und mehr. Entscheidend ist, dass das Modell nur das zu sehen bekommt, was der Harness bewusst freigibt. Die Datenaufbereitung ist damit eine Designentscheidung, kein Nebeneffekt.
Ein Aktivitäts-Vorverarbeiter übernimmt die Reduktion. Er fasst Schübe von Ereignissen zu einzelnen zusammen, behält nur die wichtigen aggregierten Änderungen und wirft Einrichtungsrauschen weg. Das geschieht deterministisch, ohne Beteiligung des Modells – der Agent sieht die rohe Flut nie. Damit werden zwei Ziele gleichzeitig erreicht: weniger Eingabe-Token, was Kontext und Kosten schont, und ein sauberer Ausgangspunkt. Wer KI-Agenten mit Blick auf Betriebskosten baut, kommt an dieser Stelle nicht vorbei, denn die Eingabelänge multipliziert sich mit jedem Lauf.
In derselben Phase sitzt der PII-Schutz. Personenbezogene Daten werden entfernt, bevor das Modell sie überhaupt zu Gesicht bekommt. Datenaufbereitung und PII-Schutz für KI-Agenten gehören damit zusammen: Was nicht im Prompt steht, kann auch nicht in einer Ausgabe auftauchen oder in einem Protokoll landen. Das ist der unauffälligste Teil des Harness und derjenige, der bei einer Prüfung die wenigsten Diskussionen zulässt.
Gegen Halluzinationen setzt das Team ein Alias-System. Rohe IDs im Prompt werden durch kurze Aliasnamen ersetzt. Damit entsteht eine Oberfläche, auf der sich Erfindungen erkennen lassen: Jede Referenz, die das Modell produziert, ohne sie tatsächlich abgerufen zu haben, fällt auf und wird verworfen. In der Ausgabe zitiert der Agent diese Aliasnamen als Belege für jeden Feed-Eintrag, und alles, was sich nicht auflösen lässt, wird aussortiert. Prompt-Caching am AI-Gateway sorgt schließlich dafür, dass der statische System-Prompt nicht bei jedem Lauf vollständig bezahlt wird. Übertragen wird er einmal, weitere Aufrufe innerhalb des Cache-Fensters kosten nur einen Bruchteil.
Grenzen für den laufenden Agenten
Mit zusammengesetztem Prompt wird der Agent erzeugt: ein Modell mit Laufzeitkonfiguration wie Name, Temperatur und Token-Grenzen, dazu die verdrahteten Werkzeuge, der System-Prompt und der Middleware-Stack. Hier entstehen die Fähigkeiten und die Grenzen des Agenten – was er tun kann, wie weit er gehen darf und welche Form sein Ergebnis haben muss. Ohne Ausgabeschema liefert das Modell freien Text, und freien Text kann nachgelagerter Code schlecht verarbeiten. Das Schema erzwingt deshalb einen schema-validierten Werkzeugaufruf, statt darauf zu vertrauen, dass das Modell gültiges JSON erzeugt. Der Bericht bringt den Unterschied auf eine Formel: Vertrag statt Hoffnung.
Verfehlt das Modell das Schema, folgt ein Wiederholungsversuch – mit dem Validierungsfehler als zusätzlichem Kontext. Damit hat das Modell die Information, die es zur Korrektur braucht, statt einfach denselben Fehler erneut zu produzieren. Zusätzlich greift ein Limit auf die Modellaufrufe, das beim Erreichen der Grenze einen sauberen Stopp auslöst und keinen unbehandelten Abbruch. Grenzen sind hier Teil der Erfolgsbedingung: Ein Lauf, der kontrolliert endet, ist einem Lauf vorzuziehen, der unkontrolliert weiterläuft.
Innerhalb des Laufs kommen zwei Begrenzungen zum Tragen, die man leicht verwechselt. Das Modellaufruf-Limit zählt, wie oft das Modell aufgerufen wird. Das Rekursionslimit begrenzt, wie viele Schleifendurchläufe der Graph insgesamt ausführen darf – es ist die äußere Decke über dem gesamten Lauf. Zusammen ergeben sie zwei getrennte Schranken: Das Modell kann nicht häufiger als N-mal aufgerufen werden, und die Schleife kann nicht öfter als M-mal kreisen. Jeder Lauf endet sauber, entweder mit validierter Ausgabe oder mit einem abgefangenen und protokollierten Fehler, der nicht bis zum Nutzer durchschlägt.
Die Werkzeuge sind eigene Fehlerquellen: ein Netzwerkaufruf, der scheitert, eine Datenbankabfrage, die nichts zurückgibt. Drei Muster aus dem Bericht sind relevant. Erstens: Ein unverzichtbares Werkzeug gehört nicht in die Auswahl des Agenten, sondern wird aus dem Lauf herausgenommen und später im Ablauf fest eingebaut, damit es garantiert ausgeführt wird. Zweitens: Der Kontext bleibt sauber, Rechte und Werkzeuge werden auf das Nötige begrenzt. Drittens: Fehlermeldungen sind Anweisungen, keine Signale. Der Unterschied zwischen einem schlichten Fehlerobjekt und einer Meldung wie „mit den verfügbaren Daten fortfahren“ ist der Unterschied zwischen Interpretationsarbeit und klarer Handlungsanweisung. Werkzeuge, die Verbindungen halten, brauchen zudem einen garantierten Abschlussweg, unabhängig davon, wie der Lauf endet.
Prüfen, bevor das Ergebnis echte Daten wird
Der Agent ist fertig und liefert eine strukturierte Antwort: neue Feed-Einträge und Aktualisierungen bestehender, jeweils mit den verwendeten Aliassen als Belege. Jetzt geht es nicht mehr um Steuerung, sondern um Überprüfung – kann man dem Ergebnis trauen? Zuerst läuft der Halluzinationsfilter: Alles, was sich nicht auf eine gültige Aktivitäts-ID auflösen lässt, wird verworfen und protokolliert. Hat das Modell einen Alias zitiert, der nie in den Ausgangsdaten vorkam, ist genau das eine Erfindung, und sie verschwindet an dieser Stelle, nicht erst beim Nutzer.
Danach folgt die Deduplikation. Dieselbe Aktivität darf nicht in zwei Feed-Einträgen auftauchen. Hat das Modell dasselbe Ereignis doppelt gruppiert, entscheidet eine Prioritätsregel, in welchem Eintrag es bleibt. Ein Set, das jede aufgelöste ID über den gesamten Ausgabedurchlauf verfolgt, setzt die Regel technisch durch. Beide Schritte folgen demselben Muster: Das Modell darf sich irren, aber der Fehler erreicht die Oberfläche nicht. Der personalisierte Activity Feed für Workspaces funktioniert nur, wenn jeder sichtbare Eintrag auf echte Aktivität zurückgeht und für sich genommen handlungsfähig ist.
Der Rückkanal – beobachten, erinnern, messen
Nach dem Lauf geht es um Sichtbarkeit: Welche Signale gibt es, und wo liegen sie? Der gesamte Aufruf ist in eine Trace-Funktion gehüllt, und LangSmith zeichnet jeden Zwischenschritt auf – Werkzeugaufrufe, Modellantworten, Token-Zahlen, Denkketten. Dort lebt die Sicht auf Werkzeugebene: welches Werkzeug wie oft gerufen wurde und was es zurückgab. Dazu feuert nach jedem Lauf ein Zusammenfassungsereignis, bei Erfolg wie bei Fehler, mit Dauer, Aktivitätszahlen, Anzahl der Feed-Einträge, Modellname, Werkzeugpfad und einer Aufschlüsselung der Prompt-Länge.
Ein Harness, der mit jedem Lauf bei null beginnt, hat kein Gedächtnis für das, was funktioniert hat. Feed Memory schließt diese Lücke: Verhaltenssignale aus der Nutzung fließen in den nächsten Lauf zurück. Explizite Regeln, die Nutzer dem Agenten direkt mitteilen, werden in strukturierte Vorgaben übersetzt und mit hoher Autorität vor der Kuratierung angewandt. Abgeleitete Beobachtungen entstehen ohne jede Aussage, allein aus Mustern über Verwerfungen, Klicks auf Handlungsaufrufe und Verweildauern. Sie haben niedrigere Autorität, dienen als weicher Kontext für Grenzfälle und überstimmen nie eine explizite Regel. Der Lesepfad schließt den Kreis: In der ersten Phase liest der Agent die angesammelten Regeln und Beobachtungen, bevor er kuratiert.
Weil der Agent nicht deterministisch arbeitet, reicht es nicht, nur seine deterministischen Teile zu testen. Das Team bewertet deshalb auf zwei Ebenen. Offline entsteht ein wachsender Datensatz aus Anwendungsfällen, die in Produktion aufgetreten sind, bewertet durch ein LLM als Richter mit eigenen Metriken pro Teilaspekt – ausgeführt in der CI, damit keine Verschlechterung unbemerkt in Produktion gelangt. Online läuft dieselbe Analyse auf Echtzeitdaten und zeigt Probleme, die im Datensatz noch nicht abgebildet sind. Beide Ebenen zusammen sind der Grund, warum das Team Änderungen am Agenten überhaupt verantworten kann.
Was die FeedAgent-Fallstudie für eigene Agenten bedeutet
Die wichtigste Beobachtung des Berichts ist zugleich die nüchternste: Die Fehlerquellen lagen nicht im Modell, sondern in den Annahmen, die das Team ringsum getroffen hatte. Was in den Prompt gelangt, was den Lauf begrenzt, was vor der Auslieferung geprüft wird und was für den nächsten Lauf gespeichert bleibt – nichts davon ist Aufgabe des Modells. Hier liegt die eigentliche Ingenieursarbeit, und sie ist unspektakulär: Vorverarbeitung, Schemata, Limits, Filter, Protokolle.
Wer Agenten in Produktion bringt, kann daraus eine Reihenfolge ableiten. Erst den Ablauf in seinen Phasen verstehen und die Abzweigungen benennen. Dann die Datenaufbereitung und den PII-Schutz festziehen, weil dort Eingabelänge, Kosten und Datenschutz gleichzeitig entstehen. Anschließend Grenzen setzen und Ausgaben schemavalidiert erzwingen. Erst danach lohnt der Blick auf Gedächtnis und Bewertungsschleife, weil beides ohne belastbare Grundlage nur Rauschen verstärkt. Ein robuster Harness für KI-Agenten in Produktion ist keine nachträgliche Ergänzung, sondern die Struktur, in der der Agent überhaupt erst betreibbar wird.
Die Bande an der Bowlingbahn garantiert keinen Strike, und der Harness garantiert keine perfekte Antwort. Er hält die Kugel auf der Bahn – in jedem Lauf, für jeden Nutzer, auch an dem Tag, an dem das Modell einen schlechten Wurf macht. Das ist weniger, als viele von einem Agenten erhoffen, und mehr, als man ohne ihn bekommt.
Quelle: engineering.monday.com
