Ein Agent analysiert eine Anfrage und ruft ein Tool auf. Die Antwort? Lässt auf sich warten. Wenn sie da ist, wird das nächste System aufgerufen und die Daten werden verarbeitet. Erst im Anschluss wird eine Aktion ausgeführt. Jeder dieser Schritte ist für sich genommen unauffällig. Zwei Sekunden hier, drei Sekunden dort.
Bei einem einzelnen Schritt fällt die Verzögerung kaum auf. Bei einer längeren Agenten-Kette summieren sich diese Sekunden jedoch schnell. Aus einer Anfrage, die ein Mensch in zehn Sekunden beantwortet hätte, wird ein Vorgang, der eine Minute dauert. Nicht, weil der Agent falsch liegt, sondern weil er auf dem Weg zur richtigen Antwort zu viele Stationen durchläuft.
Damit wird Latenz zu einer eigenen Architekturfrage. Ein produktiver AI-Agent muss nicht nur richtige Antworten liefern. Er muss sie auch in einer Zeit liefern, die für den Prozess sinnvoll ist. Denn im Enterprise-Umfeld ist Geschwindigkeit nicht nur eine Frage der Nutzererfahrung. Sie kann Teil der Prozessqualität sein.
Wo die Zeit in einer Agenten-Kette tatsächlich verloren geht
Wer verstehen will, warum ein Agent langsam ist, muss die Kette in ihre Bestandteile zerlegen. Ein typischer Durchlauf besteht aus einer Abfolge von Modellaufrufen und Tool-Aufrufen, die sich gegenseitig bedingen. Das Modell entscheidet, welches Tool aufgerufen wird. Das Tool liefert ein Ergebnis. Das Modell interpretiert das Ergebnis und entscheidet über den nächsten Schritt.
| Schritt | Typische Dauer | Was die Dauer bestimmt |
|---|---|---|
| Modellaufruf zur Planung | Ein bis mehrere Sekunden | Modellgröße, Länge des Kontexts, Länge der Ausgabe |
| Tool-Aufruf | Millisekunden bis Sekunden | Zielsystem, Netzwerk, Authentifizierung, Datenmenge |
| Modellaufruf zur Interpretation | Ein bis mehrere Sekunden | Erneuter Aufruf mit größerem Kontext als zuvor |
| Wartezeit auf eine Freigabe | Minuten bis Stunden | Prozess und Verfügbarkeit von Menschen, nicht Technik |
Entscheidend ist, dass sich dieses Muster pro Schritt wiederholt. Ein Agent, der acht Tool-Aufrufe braucht, durchläuft mindestens neun Modellaufrufe. Wenn jeder Zyklus aus Modell und Tool drei bis fünf Sekunden dauert, ist nach acht Schritten eine halbe Minute vergangen, ohne dass irgendeine einzelne Komponente langsam gewesen wäre.
Dazu kommt ein Effekt, der häufig übersehen wird: Mit jedem Schritt wächst der Kontext. Jedes Tool-Ergebnis wird Teil der Konversation, die das Modell beim nächsten Aufruf verarbeiten muss. Der zehnte Modellaufruf ist deshalb nicht nur ein weiterer Aufruf, sondern ein langsamerer und teurerer als der erste.
Warum Latenz bei Agenten anders ist als bei klassischer Software
In einer klassischen Anwendung ist die Antwortzeit für einen Anwendungsfall weitgehend vorhersehbar. Eine Anfrage durchläuft einen definierten Pfad. Wer den Pfad kennt, kann die Latenz messen, Engpässe finden und optimieren. Das Ergebnis ist eine Antwortzeit, die bei gleicher Last in einem engen Band liegt.
Bei einem Agenten ist die Anzahl der Schritte nicht festgelegt. Dieselbe Aufgabe kann an einem Tag in vier Schritten gelöst werden und am nächsten Tag in zwölf, weil das Modell einen anderen Weg wählt, ein Tool ein unerwartetes Ergebnis liefert oder ein Zwischenschritt wiederholt werden muss. Latenz wird damit nicht nur höher, sondern vor allem variabler. Für einen Prozess ist eine variable Antwortzeit oft schwieriger als eine langsame, aber verlässliche.
Hinzu kommt, dass ein Agent sich für Umwege entscheiden kann, die technisch korrekt, aber unnötig sind. Er fragt dieselben Daten zweimal ab. Er holt ein vollständiges Dokument, obwohl ein Feld gereicht hätte. Er ruft ein Modell auf, um etwas zu entscheiden, das eine einfache Regel hätte entscheiden können. Jeder dieser Umwege ist für sich betrachtet harmlos. In Summe sind sie der Grund, warum ein intelligenter Agent trotzdem zu langsam sein kann.
Vier Fragen, die die Architektur beantworten muss
Welche Informationen synchron verarbeitet werden müssen, welche parallel geladen werden können, welche Schritte vorbereitet werden können und an welcher Stelle eine zusätzliche Modellabfrage überhaupt notwendig ist, sind keine Fragen an das Modell. Es sind Fragen an die Architektur, in die das Modell eingebettet ist.
- Was muss wirklich synchron ablaufen? Nur Schritte, deren Ergebnis für den nächsten Schritt gebraucht wird, müssen aufeinander warten. Vieles, was Agenten heute nacheinander tun, hängt nicht voneinander ab.
- Was kann parallel geladen werden? Wenn ein Agent Kundendaten, Vertragsstatus und offene Tickets braucht, gibt es keinen Grund, diese drei Abfragen nacheinander auszuführen. Drei parallele Aufrufe dauern so lange wie der langsamste, nicht so lange wie alle zusammen.
- Was kann vorbereitet werden, bevor der Agent beginnt? Vieles ist schon bekannt, bevor die erste Modellabfrage stattfindet: Wer die Anfrage stellt, welcher Kunde betroffen ist, welche Daten typischerweise gebraucht werden. Diese Informationen lassen sich vorab laden und dem Agenten mitgeben, statt sie ihn Schritt für Schritt zusammentragen zu lassen.
- Wo ist eine Modellabfrage überhaupt notwendig? Nicht jede Entscheidung in einer Kette braucht ein Sprachmodell. Eine Validierung, eine Zuordnung nach festen Regeln oder eine Formatumwandlung ist in Code schneller, günstiger und vorhersehbarer.
Diese vier Fragen sollten vor dem produktiven Einsatz beantwortet sein. Sie bestimmen die Struktur des Agenten weit stärker als die Wahl des Modells.
Synchron oder asynchron: Die Frage nach dem Prozess
Nicht jede Aufgabe eines Agenten muss in Sekunden beantwortet sein. Ein Assistent, mit dem ein Servicemitarbeiter während eines Kundengesprächs arbeitet, hat andere Anforderungen als ein Agent, der über Nacht eingehende Dokumente klassifiziert. Bevor Latenz optimiert wird, sollte deshalb klar sein, in welchem Interaktionsmuster der Agent arbeitet.
| Muster | Beispiel | Anforderung an die Latenz | Was hilft |
|---|---|---|---|
| Interaktiv | Assistent im Kundengespräch, Chat im Arbeitsalltag | Wenige Sekunden pro Antwort | Streaming, Zwischenstände, vorgeladener Kontext |
| Semi-synchron | Angebotserstellung, Recherche zu einem Fall | Minuten, mit sichtbarem Fortschritt | Statusmeldungen, Benachrichtigung bei Abschluss |
| Asynchron | Nächtliche Verarbeitung, Massenprüfung von Belegen | Stunden sind akzeptabel | Durchsatz und Parallelisierung statt Einzellatenz |
Die richtige Frage ist nicht, wie schnell der Agent sein kann. Sie lautet: Wie schnell braucht ihn der Prozess?
Ein häufiger Fehler besteht darin, jeden Agenten als interaktiven Chat zu entwerfen, auch wenn der dahinterliegende Prozess das gar nicht verlangt. Umgekehrt ist es problematisch, einen Agenten in einen interaktiven Prozess einzubauen, dessen Kette strukturell nicht unter zehn Sekunden zu bekommen ist. In beiden Fällen ist das Problem nicht das Modell, sondern die fehlende Übereinstimmung zwischen Agent und Prozess.
Deterministische Schritte gehören nicht ins Modell
Ein wesentlicher Teil der Latenz in vielen Agenten entsteht durch Modellaufrufe, die gar nicht notwendig wären. Das Modell wird gebeten, eine Kundennummer aus einer E-Mail zu extrahieren, obwohl sie im Betreff in einem festen Format steht. Es soll prüfen, ob ein Datum in der Zukunft liegt. Es soll entscheiden, an welche Abteilung ein Fall geht, obwohl die Regel dafür seit Jahren dokumentiert ist.
Jeder dieser Aufrufe kostet Sekunden und bringt Varianz in einen Schritt, der keine Varianz braucht. Die Regel ist einfach: Was sich als Code schreiben lässt, sollte als Code laufen. Das Modell entscheidet dort, wo Urteilsvermögen gefragt ist. Alles andere übernimmt die Integrations- und Tool-Schicht.
Das hat einen zweiten Vorteil. Deterministische Schritte sind testbar, messbar und bei jedem Durchlauf gleich. Wer sie aus dem Modell herauslöst, verkürzt nicht nur die Kette, sondern macht sie auch vorhersehbarer. Das ist dieselbe Trennung, die auch bei der Fehlerbehandlung in agentischen Architekturen entscheidend ist: Der Agent handelt innerhalb eines Rahmens, den die Infrastruktur vorgibt.
Modellwahl, Kontextgröße und die Kosten pro Schritt
Nicht jeder Schritt braucht das größte verfügbare Modell. Eine Klassifikation, ein Routing oder eine einfache Zusammenfassung lässt sich mit einem kleineren Modell in einem Bruchteil der Zeit erledigen. Das große Modell bleibt den Schritten vorbehalten, in denen tatsächlich geschlussfolgert werden muss. Eine Architektur, die pro Schritt das passende Modell wählt, ist schneller und günstiger als eine, die überall dasselbe verwendet.
Ähnlich verhält es sich mit dem Kontext. Was bei jedem Aufruf mitgeschickt wird, bestimmt die Antwortzeit direkt. Ein Agent, der bei jedem Schritt ein vollständiges Vertragsdokument im Kontext trägt, ist langsamer als einer, der nur die relevanten Abschnitte erhält. Gezieltes Nachladen von Informationen, das Zusammenfassen von Zwischenergebnissen und das bewusste Verwerfen von nicht mehr benötigtem Kontext sind deshalb keine Feinheiten, sondern Teil des Entwurfs. Wie viel ein Agent überhaupt im Gedächtnis behalten sollte, ist dabei eine eng verwandte Frage.
Auch die Schnittstellen selbst spielen eine Rolle. Eine API, die für menschliche Nutzung in einer Oberfläche entworfen wurde, liefert oft zu viel oder zu wenig für einen Agenten. Wenn der Agent drei Aufrufe braucht, um eine Information zusammenzusetzen, die ein einziger passender Endpunkt liefern könnte, ist das ein Latenzproblem, das sich nicht im Agenten lösen lässt. Welche Anforderungen Agenten an APIs stellen, ist deshalb auch eine Frage der Geschwindigkeit.
Latenz messen, bevor sie optimiert wird
Optimierung ohne Messung führt in die falsche Richtung. In vielen Fällen stellt sich heraus, dass nicht das Modell die Zeit kostet, sondern ein einzelnes Zielsystem, das für jede Anfrage mehrere Sekunden braucht. Oder dass ein Agent im Durchschnitt nur fünf Schritte braucht, in zehn Prozent der Fälle aber zwanzig. Solche Muster sind nur sichtbar, wenn die Kette instrumentiert ist.
| Kennzahl | Warum sie wichtig ist |
|---|---|
| Dauer pro Schritt, getrennt nach Modell und Tool | Zeigt, ob die Zeit im Modell, in den Zielsystemen oder in der Wartezeit verloren geht |
| Anzahl der Schritte pro Aufgabe | Macht Umwege und unnötige Wiederholungen sichtbar |
| Verteilung der Gesamtdauer, nicht nur der Durchschnitt | Der Durchschnitt verdeckt die Ausreißer, die den Prozess stören |
| Kontextgröße pro Aufruf | Erklärt, warum spätere Schritte langsamer sind als frühe |
| Anteil der Vorgänge über dem Zielwert | Übersetzt Latenz in eine Aussage über Prozessqualität |
Diese Daten sind dieselben, die auch für Beobachtbarkeit und Kostenkontrolle gebraucht werden. Wer die Dauer jedes Schritts erfasst, kennt auch die Anzahl der Modellaufrufe und damit die Kosten pro Aufgabe. Latenz, Kosten und Nachvollziehbarkeit hängen in agentischen Systemen so eng zusammen, dass sie sinnvollerweise gemeinsam gemessen werden.
Geschwindigkeit als Teil der Prozessqualität
Im Enterprise-Umfeld ist Latenz selten nur eine Frage des Komforts. Ein Agent, der im Kundenservice neunzig Sekunden braucht, um eine Auskunft vorzubereiten, ist nicht einsetzbar, solange der Kunde am Telefon wartet, selbst wenn jede Auskunft korrekt ist. Ein Agent, der Leads über Nacht vorqualifiziert, darf dagegen pro Lead eine Minute brauchen, ohne dass es jemand bemerkt. Die Antwortzeit entscheidet darüber, an welcher Stelle im Prozess ein Agent überhaupt sinnvoll eingesetzt werden kann.
Latenz hat außerdem technische Folgen, die über die Wahrnehmung hinausgehen. Aufrufende Systeme haben Timeouts. Wenn ein Agent regelmäßig länger braucht, als das vorgelagerte System wartet, gehen Ergebnisse verloren oder werden wiederholt angefordert. Aus einem Latenzproblem wird damit ein Fehlerbehandlungsproblem, mit allen Fragen zu Wiederholung und doppelter Ausführung, die daran hängen.
Und schließlich beeinflusst Geschwindigkeit, ob Menschen mit einem Agenten arbeiten. Ein Werkzeug, das verlässlich langsamer ist als der bisherige manuelle Weg, wird umgangen, egal wie gut seine Ergebnisse sind. Akzeptanz entsteht nicht allein durch Korrektheit, sondern durch Korrektheit in einer Zeit, die zum Arbeitsalltag passt. Wer AI-Agenten im Unternehmen einführt, sollte die Antwortzeit deshalb von Anfang an als Anforderung behandeln, nicht als nachträgliche Optimierung.
Fazit
Die Diskussion über AI-Agenten dreht sich meist um Fähigkeiten: Welche Aufgaben kann der Agent lösen, wie gut sind seine Antworten, wie autonom arbeitet er? Die Frage, wie lange er dafür braucht, kommt oft erst dann auf, wenn der erste Pilot in den Betrieb gehen soll und sich herausstellt, dass eine Minute pro Vorgang im echten Prozess nicht tragbar ist.
Latenz ist bei Agenten kein Detail, das sich am Ende durch ein schnelleres Modell beheben lässt. Sie entsteht in der Struktur der Kette: in der Anzahl der Schritte, in der Reihenfolge der Aufrufe, im Umfang des Kontexts und in der Entscheidung, wo überhaupt ein Modell gefragt wird. Diese Entscheidungen werden beim Entwurf getroffen.
Ein produktiver Agent muss deshalb nicht nur richtige Antworten liefern. Er muss sie in einer Zeit liefern, die der Prozess verträgt. Geschwindigkeit ist im Enterprise-Umfeld nicht nur eine Frage der Nutzererfahrung. Sie ist Teil der Qualität des Prozesses, in dem der Agent arbeitet.