Inhaltsverzeichnis
Wenn der immer gleiche Vorgang plötzlich aus der Zeit läuft
Du hast einen KI-Agenten im Einsatz, der etwas Wiederkehrendes erledigt. Er zieht sich morgens Daten aus einem Vorsystem, sortiert sie, bereitet sie auf. Es funktioniert. Und trotzdem gibt es diese Tage, an denen derselbe Vorgang dreimal so lange dauert wie sonst, ohne dass jemand etwas geändert hätte.
Das ist kein Zeichen dafür, dass die Automatisierung schlecht gebaut ist. Es ist ein Zeichen dafür, dass an einer Stelle noch eine Entscheidung offen steht, die der Agent bei jedem Lauf neu trifft. Dieser Beitrag zeigt dir, wo diese Stelle typischerweise sitzt, was es konkret bringt, sie zu schließen, und woran du erkennst, welche Schritte bei dir dafür infrage kommen.
Zwei Wege, ein Vorsystem zu benutzen
Ein KI-Agent kann ein anderes System auf zwei Arten benutzen.
Entweder er spricht es direkt an: Er formuliert eine Anfrage, bekommt eine Antwort, liest sie, entscheidet, was als Nächstes zu tun ist. Jeder dieser Schritte ist eine eigene Runde, und jede Antwort bleibt in seinem Arbeitsgedächtnis liegen, bis der Vorgang zu Ende ist.
Oder jemand schreibt einmal ein kleines Programm, das genau dieselben Anfragen stellt, aber in einer Schleife und ohne Zwischenstopp. Der Agent startet es und bekommt nur das fertige Ergebnis zurück. Alles, was auf dem Weg dorthin anfällt, sieht er nie.
Der erste Weg ist der naheliegende, und für vieles ist er genau richtig. Er ist flexibel, er braucht keine Vorarbeit, und bei einer einzelnen Abfrage gibt es nichts zu gewinnen. Interessant wird der Unterschied erst dort, wo sich etwas wiederholt.
Die Frage ist nie “Agent oder Code”, sondern welche einzelnen Schritte innerhalb der Automatisierung besser in Code aufgehoben sind.
Der teuerste Teil sind selten die Daten, die du brauchst
Ein Beispiel aus unserem eigenen Betrieb. Wir lassen uns täglich die fälligen Aufgaben aus unserem Projektmanagement-System zusammenstellen, jede mit der Zuordnung zum richtigen Kunden.
Die Aufgaben selbst sind wenig Text. Das Problem ist die Zuordnung: In welchem Kundenbereich eine Aufgabe liegt, steht nicht in der Antwort. Das steht in einem separaten Verzeichnis, und dieses Verzeichnis ist groß. Um am Ende pro Aufgabe zwei Wörter zu erhalten, muss ein Vielfaches an Verzeichnisdaten durchquert werden.
Das ist das Muster, das die meisten unterschätzen. Nicht die Nutzdaten treiben den Aufwand, sondern die Nachschlagedaten, die man durchqueren muss, um an sie heranzukommen. Wer nur zählt, wie viele Datensätze am Ende herauskommen, sieht den größeren Posten gar nicht.
Als wir denselben Auftrag einmal direkt über die Schnittstelle und einmal über ein gekapseltes Programm haben laufen lassen, standen am Ende drei Aufrufe gegen zehn, rund 7.000 gegen 18.000 Zeichen im Arbeitsgedächtnis und 25 gegen 73 Sekunden. Das Ergebnis war Feld für Feld identisch.
Warum derselbe Vorgang mal teuer und mal billig ist
Jetzt kommt der Teil, der uns selbst überrascht hat.
Wir haben denselben Vergleich zweimal gefahren, im Abstand von zwei Tagen, mit identischem Auftrag. Beim ersten Mal holte sich der Agent das komplette Verzeichnis, rund 70.000 Zeichen. Beim zweiten Mal entschied er sich anders und fragte stattdessen gezielt die sieben Einträge ab, die er wirklich brauchte, rund 18.000 Zeichen.
Faktor 3,8 Unterschied, bei gleichem Ergebnis. Beide Vorgehensweisen waren fachlich vertretbar, und beide lieferten das Richtige. Der Punkt ist nicht, dass eine davon falsch war. Der Punkt ist, dass niemand vorher weiß, welche kommt.
Für einen Prototyp ist das egal. Für etwas, das jeden Morgen läuft und in dem Budget und Laufzeit planbar sein sollen, ist es das nicht. Ein gekapselter Ablauf macht es jedes Mal gleich, und genau darin liegt sein Wert, nicht in der Ersparnis eines einzelnen Laufs.
Der Unterschied, den kein Dashboard anzeigt
Es gibt einen zweiten Effekt, und der ist unangenehmer als Kosten.
Große Verzeichnisse werden seitenweise ausgeliefert. Wer sie durchsucht, muss nach jeder Seite entscheiden, ob er weiterblättert. In einem unserer Läufe lagen sechs der sieben gesuchten Einträge auf Seite 1, der siebte erst auf Seite 3. Ein Abbruch nach der ersten Seite hätte ein Ergebnis geliefert, das vollständig aussieht und es nicht ist. Keine Fehlermeldung, keine Warnung, nur eine Zeile weniger.
Solche stillen Lücken sind der eigentliche Grund, warum sich das Kapseln lohnt. Ein Programm blättert bedingungslos bis zum Ende, weil es nicht abwägt. Es hat an dieser Stelle keinen Ermessensspielraum, und das ist hier ein Vorteil.
Dasselbe gilt für die Eigenheiten fremder Schnittstellen. Wir sind auf einen Datumsfilter gestoßen, dessen Grenze anders funktioniert, als die Dokumentation des Anbieters es beschreibt. Wer die Anfrage wörtlich nach der Doku formuliert, bekommt null Treffer, obwohl sieben Aufgaben offen sind. Das Ergebnis sieht aus wie ein ruhiger Tag.
So etwas als Hinweis in einer Arbeitsanweisung zu notieren, funktioniert eine Weile. Im Programmcode steht es als eine Zeile, abgesichert durch einen automatischen Test, der anschlägt, sobald sich das Verhalten ändert. Eine Regel, an die jemand denken muss, hält nur so lange, wie jemand daran denkt.
Die Faustregel für deinen Fall
Du musst dafür nichts umbauen. Es geht um einzelne Schritte innerhalb einer bestehenden Automatisierung. Drei Fragen reichen:
Wiederholt sich der Zugriff?
Einmal pro Vorgang ist unkritisch. Einmal pro Datensatz, pro Kunde, pro Beleg ist ein Kandidat.
Fallen dabei Zwischendaten an, die niemand liest?
Nachschlagetabellen, Verzeichnisse, seitenweise Ergebnisse. Wenn ja, gehört dieser Teil in Code.
Hängt die Vollständigkeit an einer Abwägung?
Überall dort, wo jemand entscheiden muss, ob er weitersucht, kann still etwas fehlen.
Umgekehrt bleibt der direkte Weg richtig für Einzelabfragen, für alles Schreibende und für Aufgaben, deren Form noch offen ist. Genau darin liegt die Stärke eines Agenten, und die nimmt man ihm nicht weg, indem man ihm die stumpfen Wiederholungen abnimmt.
FAQ
Am deutlichsten an schwankender Laufzeit bei gleichbleibender Aufgabe. Wenn derselbe Vorgang mal eine halbe und mal drei Minuten braucht, steckt dahinter fast immer ein Nachschlageschritt, der unterschiedlich gelöst wird.
Für den ersten Schritt selten. Es geht meist um wenige Dutzend Zeilen rund um eine Schnittstelle, die ohnehin schon angebunden ist. Wichtiger als der Umfang ist, dass es einen automatischen Test gibt, der anschlägt, wenn der Anbieter etwas ändert.
Nein, weil nur der immer gleiche Teil festgelegt wird. Die Bewertung, die Priorisierung und die Entscheidung, was mit dem Ergebnis passiert, bleiben beim Agenten. Er bekommt lediglich saubere Daten statt eines Bergs von Zwischenschritten.
Meistens gar nicht, und das ist der Kern des Problems. Deshalb ist eine feste Soll-Zahl aus dem Vorsystem wertvoller als jede Plausibilitätsprüfung am Ergebnis: gefunden gegen erwartet, und bei Abweichung eine echte Meldung.
Fazit
Ein Agent, der ein Vorsystem direkt anspricht, ist ein guter Start, und für viele Aufgaben bleibt es die richtige Lösung. Sobald etwas täglich läuft und sich über viele Einzelfälle wiederholt, verschiebt sich die Rechnung: Nicht die Ergebnisse kosten, sondern der Weg dorthin, und die Vollständigkeit hängt an Entscheidungen, die niemand sieht.
Wenn du gerade dabei bist, KI-Automatisierung über den Prototyp hinaus in den Alltag zu bringen, lohnt sich genau dieser Blick auf die Zwischenschritte. Wir schauen uns so etwas regelmäßig an und teilen die Erfahrungen hier weiter.
