Hauptgedanke

Ein Skill soll drei Kundenprofile analysieren. Mangels Filter am Eingang lädt er fünfhundert. Das Ergebnis ist identisch, der Verbrauch nicht — rund 150 000 Input-Tokens für Material, das nie gebraucht wird.

Die Kosten eines Lesevorgangs richten sich nicht danach, was man daraus zieht, sondern danach, was man ins Fenster gelegt hat. Ein Agent „überfliegt“ nicht: Alles, was hineinkommt, wird bezahlt, auch das, was er sofort verwirft.

Damit verschiebt sich die Optimierungsarbeit: Die Frage ist nicht mehr, wie man besser fragt, sondern wie man die Datenbank abfragt — Filter, Paginierung, Vorauswahl per Skript. Bedingtes Lesen geht noch weiter: eine Quelle gar nicht erst öffnen, wenn eine Vorbedingung nicht erfüllt ist.

Warum das wichtig ist

Das verortet die Einsparung beim Datenzugriff statt beim Prompt, wo man sie gewöhnlich sucht.

Und es liefert ein erkennbares Symptom in einem Audit-Bericht: einen Leseschritt, dessen Volumen in keinem Verhältnis zur Zahl der tatsächlich verarbeiteten Elemente steht.

Nuancen und Grenzen

Filtern setzt voraus, dass man vorher weiß, was relevant ist. Wenn gerade die Relevanz das ist, was die Ausführung erst feststellen soll, ist breites Lesen keine Verschwendung, sondern die Arbeit selbst.

Und eine schlecht gesetzte Auswahl ist schlimmer als vollständiges Lesen: Sie liefert eine plausible Antwort auf gekürztem Material, ohne dass irgendetwas darauf hinweist.

Offene Fragen

• Wie misst man im Nachhinein, welcher Teil der geladenen Daten tatsächlich in den Output eingeflossen ist?