Case Study

Document Intake, den man bewerten kann — nicht nur tracen

Wenn Agenten Dokumente in Drive ablegen und Tasks öffnen, ist ein grüner Chat Turn nicht dasselbe wie ein erledigter Intake Job.

Diese Case Study führt durch einen typischen Pfad für Document Intake. Du siehst, was bricht, wenn „fertig“ nur im Chat lebt. Du siehst die Schritte der Ablage in klarer Sprache. Du siehst, was Witdem auf einem echten Demo Lauf zeigt. Ergebnis, Ziel und Kosten sitzen auf derselben ID.

Das Problem

Dokumente kommen schneller an, als Menschen sie sortieren können. Postfächer füllen sich mit PDFs, Scans und Anhängen aus Mails. Geteilte Drives und Ticket Listen wachsen parallel.

Jemand muss den Ordner wählen. Jemand muss die Datei benennen. Jemand muss klären, wer den nächsten Schritt besitzt.

Danach verlieren Teams den Faden zwischen Tools. Der Chat Assistent kann sagen, dass er die Datei hat. Drive kann eine Kopie unter einem Pfad halten, den niemand vereinbart hat. Ein Task kann in einem anderen Tool existieren. Oder auch nicht.

Die Regel fragt schärfer. Liegt die Datei dort, wo sie liegen muss? Wurden die Folgeschritte geöffnet, die der Prozess braucht?

Ohne klares Ziel auf dem Lauf wird „das Modell hat geantwortet“ zum Ersatz für „Intake hat funktioniert.“ Dieser Schein Erfolg ist teuer. Menschen prüfen Drive von Hand. Sie öffnen Chat Verläufe erneut. Sie streiten mit Screenshots statt mit einem bewerteten Lauf.

Was das in der Praxis heißt

Stell dir einen Intake Job von Start bis Ende vor. Eine Person bringt ein Dokument in den Chat. Der Stack legt es ab. Er öffnet vielleicht Tasks als Folgeschritt. Dann kommt eine klare Frage. Hat dieser Lauf den Job erledigt, den du benannt hast?

Schau zuerst auf den Chat Turn und die Tool Aufrufe. Sie können gesund aussehen. Das sagt nur: Der Pfad ist gelaufen.

Schau dann auf die echten Systeme. Liegt die Datei am richtigen Ort in Drive? Sind die Tasks da, wenn der Prozess sie braucht? Wenn nicht, ist der Job fürs Geschäft fehl. Auch wenn der Chat gut aussieht.

Hänge Kosten an dieselbe Lauf ID. Tokens und Zeit zählen mehr, wenn du weißt, ob das Ziel gehalten hat. Ein billiger Fehl und ein teurer Fehl brauchen andere Reviews. Beide brauchen ein klares Ziel Kennzeichen.

Schreib die Regel für Erfolg einmal neben den Ablauf. Jede Review soll denselben Lauf gleich werten. Das ist Document Intake, den man bewerten kann. Nicht nur scrollen.

Scheinerfolg beim Intake

Intake scheitert still, wenn die Runtime gesund aussieht. Tools können zurückkehren. Der Chat Turn kann enden. Der Job zur Ablage kann die Latte trotzdem verfehlen.

Ops kann dem grünen Chat Pfad vertrauen. Produkt sieht trotzdem einen unvollständigen Intake Job. Ohne benanntes Ziel auf dem Lauf treffen sich beide Sichten nie in einer Review.

Ein beendeter Turn ist nicht dasselbe wie ein gelungener Job zur Ablage. Spans zeigen den genommenen Pfad. Sie beweisen nicht den Write in Drive. Sie beweisen auch nicht die Tasks, die der Prozess verlangt.

Ein Produkt Ziel ist eine kurze, geteilte Regel für „fertig“. Belege sind die Felder, die Pass oder Fail zeigen. Behalte beides neben dem Lauf, den du ohnehin prüfst.

Die Pipeline

Ein typischer Intake Stack sieht in Produkt Begriffen so aus. Jeder Schritt hat einen Job. Keiner allein beantwortet: War Intake erledigt?

Onyx ist die Chat Grenze zum Menschen. Jemand legt ein Dokument ab oder verweist darauf. Der Assistent nimmt es in den Chat auf. Dort denkt die Person, der Job habe begonnen.

witdem-proxy sitzt zwischen dieser Chat Fläche und der Verarbeitung. Er trägt die Anfrage in die nächste Stufe. Dort lässt sich die Messung für den ganzen Lauf anbinden.

Haystack führt die Pipeline zur Verarbeitung. Er zieht Struktur aus dem Dokument. Er ordnet die Art des Dokuments. Er bereitet vor, was „korrekt abgelegt“ in diesem Fall heißt.

Ein LLM Schritt entscheidet dann Labels, Wege oder Wahlen zur Ablage. Das Modell ist ein Schritt im Job. Es ist nicht das System of Record.

Google Drive und Tasks halten die Folgen, von denen das Geschäft abhängt. Drive speichert die abgelegte Datei. Tasks öffnen Folgeschritte für Review, Freigabe oder Sonderfälle. Dort muss „fertig“ in der realen Welt sichtbar werden.

Witdem sitzt auf der Seite der Messung dieses Pfads. Es ersetzt weder Onyx noch Proxy, Haystack, Modell, Drive oder Tasks. Es sagt, ob ein Lauf den genannten Intake Job erledigt hat. Es sagt, was der Lauf gekostet hat. Es sagt, ob Extra Arbeit sichtbar wurde. Und das neben demselben Lauf, den man sonst nur als Spans oder Chat sieht.

Was Witdem auf einem Lauf zeigt

Operatoren sollten Erfolg nicht aus drei UIs neu bauen. Eine Lauf ID sollte den Zustand der Runtime tragen. Dazu das Ergebnis des Jobs. Dazu das Produkt Ziel. Dazu die gemessenen Kosten, wenn Belege da sind.

Die öffentlichen Demo Screens zu Document Intake zeigen diesen Join. Öffne eine Karte zum Lauf auf einen Blick. Du siehst, wie der Job aufgelöst wurde. Du siehst, ob das Produkt Ziel erreicht wurde. Du siehst Dauer, Tokens und gemessene Kosten in derselben Ansicht.

Zwei nahe Demo Läufe erreichen beide das Produkt Ziel. Sie lösen unterschiedlich auf. Eine endet als Stored With Tasks. Das heißt Ablage plus Tasks als Folgeschritt. Die andere endet als Stored. Das heißt nur Ablage. Der Unterschied ist sichtbar. Du musst nicht jeden Chat Turn öffnen.

Die Liste aller Läufe hält diese Ergebnisse auf denselben Karten. Operatoren scannen diese Karten ohnehin. Business Result und Produkt Ziel stehen gemeinsam auf jeder Zeile zu Document Intake. Du vergleichst nahe Läufe in einer Liste. Du musst Chat, Drive und Tickets nicht von Hand verbinden.

Konkrete Einblicke

Diese Notizen stammen von Document Intake Läufen auf demo.witdem.com/runs. Ein Beispiel ist der Lauf 55be9c22116c4573ac09d0eea13e99e0 (14. Sep. 2026). Das sind Demo Fakten. Keine erfundenen Kunden Zahlen.

Runtime und Ziel teilen eine ID. Dieser Intake Lauf ist completed. Das Business Result ist Stored With Tasks. Das Produkt Ziel ist Achieved. Eine grüne Pipeline allein beweist die Latte Ablage plus Tasks nicht. Der bewertete Lauf tut es.

Ergebnisse unterscheiden sich auf ähnlichen Pfaden. Nahe Zeilen zu Document Intake zeigen Stored und Stored With Tasks. Beide zeigen Ziel erreicht. Operatoren sehen, ob Erfolg „nur abgelegt“ oder „abgelegt und Tasks angelegt“ bedeutete.

Kosten hängen am selben Lauf. Der Screen zu Stored With Tasks meldet 7,4 s, 263 Tokens und gemessene Kosten $0.00007635 neben dem Ergebnis. Fragen zu Kosten hängen am Job Ergebnis. Nicht an einem eigenen Sheet.

Retries sind sichtbare Felder. Dieses Beispiel zeigt 0 Attempts insgesamt / 0 extra und keine Recovery. Wenn Retries oder Recovery auf anderen Läufen erscheinen, stehen sie neben Ergebnis und Kosten. Sie leben nicht nur in der Chat Historie. Sie leben auch nicht nur in vergrabenen Tool Logs.

• completed + Stored With Tasks + Ziel Achieved auf einem Lauf
• Nahe Demo Ergebnisse: Stored vs. Stored With Tasks
• 7,4 s · 263 Tokens · $0.00007635 gemessen auf dem bewerteten Lauf
• 0 Attempts / 0 extra · keine Recovery auf diesem Pfad

Zoome vom Einzel Lauf heraus. Goal performance zeigt, wie genannte Ziele im Portfolio landen. Der Screen enthält Document filed unter diesen Zielen. Du siehst erreicht versus braucht Aufmerksamkeit. Du bleibst in der Schicht der Produkt Ergebnisse.

Was sich ändert

Builder nennen neben dem Ablauf, was Erfolg bedeutet. Regeln zur Ablage und Erwartungen an Tasks werden Produkt Ziele, die man prüfen kann. Sie leben nicht nur als Stammes Wissen in einem Chat Thread.

Operatoren bauen „hat Intake funktioniert?“ nicht mehr aus Chat, Drive und Tickets. Sie öffnen einen Lauf. Sie lesen Job Ergebnis, Ziel Zustand und Kosten. Sie eskalieren, wenn der Job die Latte verfehlt hat. Oder wenn die Belege unvollständig sind.

Darum geht es in dieser Case Study. Document Intake wird ein agentischer Workflow, den man bewerten kann. Es ist nicht nur eine Konversation zum Scrollen. Für den breiten Rahmen siehe den Pillar Leitfaden. Dort geht es um Tracing, Eval, Kosten und Produkt Ergebnisse auf einem Lauf. Framework Seiten decken Haystack und LangGraph ab.

FAQ

Heißt ein grüner Chat Turn, dass Intake gelungen ist? Nein. Grün heißt: Der Pfad des Assistenten ist fertig. Erfolg heißt: Das Produkt Ziel, das du benannt hast, hat für diesen Lauf gehalten. Zum Beispiel abgelegt wie gefordert. Mit Tasks, wenn der Prozess sie braucht.

Welche Schritte sitzen in diesem Intake Stack? In Produkt Begriffen: Onyx nimmt das Dokument an. Der witdem-proxy trägt es in die Verarbeitung. Haystack strukturiert den Job. Ein LLM Schritt hilft bei der Entscheidung. Google Drive plus Tasks halten die Folgen in der realen Welt.

Ersetzt Witdem Drive oder den Chat Assistenten? Nein. Witdem sitzt auf der Seite der Messung. Es verbindet Ergebnis, Ziel und Kosten auf derselben Lauf ID, die du ohnehin prüfst.

Was zeigen die Demo Screens? Karten zum Lauf auf einen Blick mit Stored oder Stored With Tasks, Ziel erreicht, Zeit, Tokens und Kosten. Dazu eine Liste aller Läufe mit diesen Feldern je Zeile. Dazu Goal performance inklusive Document filed.

Wo prüfe ich die Demo Fakten? Öffne Document Intake Läufe auf demo.witdem.com/runs. Zahlen und Labels auf dieser Seite passen zu diesen Screens.

Weiterführend

Observability für agentische Workflows · Haystack-Observability · LangGraph-Observability · LangChain-Observability · OpenAI-Agents-Observability