Agenten effizient betreiben: Kontext, Koordination und Prüfaufwand begrenzen

01

Den gesamten Ablauf statt einzelner Modellaufrufe messen

Ein Agentenprozess benötigt neben Facharbeit auch Quellenzugriff, Koordination, Werkzeugbedienung und Ergebnisprüfung. Diese Tätigkeiten sichern den Ablauf ab, können aber einen erheblichen Teil seiner Ressourcen beanspruchen. Eine Optimierung sollte deshalb zunächst zeigen, wo Zeit und Kontext entstehen. Die Zahl eingesetzter Agenten oder einzelner Toolaufrufe reicht dafür nicht aus.

Hilfreich ist eine Trennung nach Aufgabenart und Phase: Routinekoordination, fachliche Bearbeitung, Review und Systemweiterentwicklung. Zusätzlich werden Durchlaufzeit, Modellinputs, Wartezeit und manuelle Eingriffe erfasst. Damit lassen sich wiederkehrende Verwaltungsarbeiten erkennen, die in feste Software verlagert werden könnten.

Ein kleiner Kontext ist dabei kein Selbstzweck. Ein Fachschritt muss seine nötigen Quellen lesen können. Ebenso darf eine Zeitersparnis keine erforderliche Prüfung entfernen. Gesucht werden Schritte, die ohne neuen fachlichen Erkenntnisgewinn wiederholt werden, oder technische Abläufe, die das Modell bei jedem Lauf erneut herleitet.

02

Das sem.-Beispiel: hoher Aufwand für die Koordination

COS-ADR-039 dokumentiert für den 7. und 8. Oktober 2026 eine Auswertung von 18 Orchestrator-Sitzungen und 33 Unteragenten mit insgesamt 307 Millionen Input-Tokens. Rund 120 Millionen wurden Routineläufen des Orchestrators, 93 Millionen Reviews und 50 Millionen Planern und Fachagenten zugeordnet. Weitere rund 41 Millionen entfielen auf Änderungswünsche im Automationschat. Die gerundeten Teilwerte ergeben keine exakte Aufteilung der Gesamtsumme.

Innerhalb des Orchestrators wurden 44 Prozent der Tokens Nachrichten, Warten und Zwischenprüfungen zugeordnet. Weitere 16 Prozent betrafen das Herleiten der Bedienung aus Quelltext und Dokumentation, 15 Prozent handgeschriebene Skripte und Belege. Diese Anteile beziehen sich auf den Orchestrator. Der dokumentierte Mittelwert eines Routinelaufs lag bei 26 Minuten gegenüber einer vorgesehenen Grenze von 20 Minuten.

Der Befund liefert Ansatzpunkte für den untersuchten Prozess. Er ist keine allgemeine Aussage über die Wirtschaftlichkeit von Agentensystemen. Kumulierte Input-Tokens können denselben Kontext mehrfach enthalten. Cache-Anteile, abrechenbare Kosten und eine Verteilung der Einzellaufzeiten sind hier nicht ausgewiesen. Auch Systemänderungen gehören zur genannten Stichprobe.

03

Kontext vor der eigentlichen Arbeit gezielt reduzieren

Eine separate Untersuchung in COS-ADR-037 betrachtet 31 Gmail-Läufe und neun Review-Unteragenten. Sie nennt etwa 60.000 bis 75.000 Tokens Kontext vor der ersten Mail und ordnet neu geschriebenen Verwaltungs-Skripten 30 bis 51 Prozent der Laufzeit zu. HubSpot machte dort ungefähr ein bis zwei Prozent der Input-Tokens aus. Die beiden Untersuchungen haben unterschiedliche Stichproben und werden nicht addiert.

Die sem.-Korrekturen setzten deshalb am Laufstart an. Kompakte Karten nennen benötigte Schritte und feste Aufrufmuster. Hintergrundregeln werden fallbezogen nachgeladen. Wiederkehrende technische Aufgaben wie Reservierung, Journalsicherung, Aufgabenübernahme und Abschluss werden durch feste Kommandos erledigt. Damit muss ein Routineagent ihre Bedienung nicht bei jedem Lauf neu entwickeln.

Ein weiterer Ansatz ist eine gezielte erneute Prüfung nach Regeländerungen. Im dokumentierten sem.-Fall konnte eine Profiländerung die Prüfung aller bekannten Quellen auslösen; eine fehlende Fortschrittsmarkierung verhinderte ihren Abschluss. Die Korrektur begrenzte die Prüfung auf tatsächlich betroffene Quellen. Entscheidend sind dabei sowohl ein klarer Geltungsbereich als auch ein gesicherter Fortschrittsstand.

04

Lösungsansatz: KI für fachliche Entscheidungen einsetzen

Wiederkehrende Verwaltung eignet sich für feste, geprüfte Funktionen mit begrenzten Eingaben und Ausgaben. Das Modell kann sich dann auf Einordnung, fachliche Abwägung und fallbezogene Bearbeitung konzentrieren. Diese Aufteilung reduziert den Bedarf, technische Hilfsabläufe während einer Routine neu zu schreiben, und macht deren Verhalten separat prüfbar.

Auch Reviews sollten einen benannten Prüfzweck haben. Ein neuer Fachinhalt kann eine unabhängige Prüfung benötigen; ein unveränderter Wartezustand lässt sich unter passenden Bedingungen technisch bestätigen. Die sem.-Korrektur unterscheidet solche Verwaltungsausgänge von Fachresultaten. Kundenwirksame und externe Aktionen behalten die Prüfungen ihres jeweiligen Fachprozesses.

• Routineeinstieg auf benötigte Schritte begrenzen und Details erst für ausgewählte Fälle laden.
• Wiederkehrende Speicherung, Reservierung und Abschlussverwaltung in geprüfte Funktionen verlagern.
• Fachinstanzen mit einem vollständigen Auftrag versorgen und unnötige Statusrückfragen vermeiden.
• Jeden Review an einen konkreten Inhalt, eine Änderung oder ein Risiko binden.
• Systemweiterentwicklung in einem eigenen Arbeitsauftrag vom Routinebetrieb trennen.

05

Die Wirkung mit vergleichbaren Fällen nachweisen

Eine aussagekräftige Nachmessung vergleicht ähnliche Aufgabentypen mit derselben Ergebnisprüfung. Neben Dauer und Tokens werden Fehlaufnahmen, Wiederholungen und Nutzerkorrekturen erfasst. So bleibt sichtbar, ob eine schnellere Koordination auch einen brauchbaren Fachabschluss ermöglicht. Cache-Anteile und fachlich erledigte Arbeit gehören zur Einordnung der Ressourcenwerte.

Zum dokumentierten Stand vom 8. Oktober war der Nutzen der neuesten sem.-Änderungen noch nicht durch vollständige vergleichbare Läufe belegt. Lokale und synthetische Tests bestätigten Teile der Umsetzung; reale Laufnachweise waren noch offen. Die Maßnahmen sind daher nachvollziehbare Lösungsansätze. Ihre Wirkung bleibt eine gesonderte Messaufgabe, die vor einem weiteren Ausbau sinnvoll ist.