Ein stärkeres Modell ist schön. Aber wenn dein Agent jedes Mal wieder herausfinden muss, wie dein Betrieb funktioniert, bezahlst du dieselbe Lernkurve immer wieder. Servus, ich bin Lissy. Heute geht es nicht um die nächste Modellshow, sondern um eine nüchterne Frage: Was macht KI im Alltag wirklich billiger, zuverlässiger und kontrollierbarer. Die kurze Antwort: Arbeitswissen, Messung und ein paar ziemlich clevere Tricks beim Rechnen.
Der stärkste Kandidat des Tages heißt Repo-To-Skill. Die Idee klingt trocken, ist aber für Agenten grundlegend. Ein Agent soll nicht nur ein GitHub-Repository durchsuchen und hoffen, dass er im langen Kontext die richtige Stelle findet. Das System destilliert aus Repositories und Papers konkrete Skills. Also kleine, geprüfte Arbeitsanleitungen: Welche Datei ist wichtig. Welche Setup-Schritte braucht man. Welche Fehler treten oft auf. Welche Befehle führen wirklich zu einem Ergebnis.
Die Autoren nennen ihre Bibliothek AREX. Darin stecken mehr als fünftausend verifizierte Skills aus eintausend Machine-Learning-Repositories, sortiert in zwanzig Areas und einhundertachtundsiebzig Capability-Familien. Das ist nicht einfach RAG mit schöner Verpackung. RAG sucht passende Textstellen. Ein Skill sagt dem Agenten, wie er handeln soll. Das ist der Unterschied zwischen einer vollen Werkstatt und einem Handwerker, der weiß, welche Schublade er zuerst aufzieht.
Die Zahlen sind ordentlich: Mit GPT-5.5 und gleichem Harness steigt die Leistung gegenüber demselben Agenten ohne Skills um 134,3 Prozent auf MLE-bench, um 34,4 Prozent auf PaperBench, um 9,2 Prozent auf FrontierCS und um 14,0 Prozent auf PassNet. Das zeigt: Viele Agentenprobleme sind keine Intelligenzprobleme. Sie sind Wiederholungsprobleme. Der Agent lernt ständig neu, was eigentlich längst als Arbeitswissen festgehalten werden müsste.
Für einen SaaS-Gründer mit zwei Entwicklern, eine Agentur mit zwölf Leuten oder einen Solo-Berater ist der praktische Test simpel. Nimm einen Prozess, den du öfter mit KI machst, zum Beispiel Angebotsprüfung oder Bug-Triage. Schreib eine knappe Arbeitsanweisung mit Input, Schritten, Prüfpunkten und Stop-Regel. Dann lass denselben Agenten zehn echte Fälle einmal ohne diese Skill-Karte und einmal mit ihr bearbeiten. Wenn die zweite Runde weniger Rückfragen, weniger Korrekturen und weniger falsche Annahmen produziert, liegt der Wert nicht im Prompt, sondern im festgehaltenen Arbeitswissen.
Der zweite Baustein passt perfekt dazu: EarlyEval. Wenn Agenten länger arbeiten, wird Evaluation teuer. Ein Agent startet einen Benchmark, ruft Tools auf, liest Dateien, schreibt Code, korrigiert sich und läuft weiter. Am Ende weißt du, ob er die Aufgabe gelöst hat. Aber oft war schon nach ein paar Zwischenschritten erkennbar, dass der Lauf auf eine Wand zufährt.
EarlyEval trainiert getrennte Klassifikatoren für Erfolg und Misserfolg. Es schaut während eines Agentenlaufs auf Verhalten, Textsignale und Referenzmerkmale. Wenn eine kalibrierte Schwelle erreicht ist, wird der Run gestoppt. Nicht weil man ungeduldig ist, sondern weil weitere Tokens wahrscheinlich nur noch Geld verbrennen.
Die gemeldeten Einsparungen sind konkret: Über SWE-bench Verified, TerminalBench und Toolathlon spart EarlyEval 13 bis 26 Prozent der Agentenschritte. Bei den Tokens sind es bis zu 44,1 Prozent weniger Input und 29,4 Prozent weniger Output. Die Vorhersagegenauigkeit liegt bei 89 bis 97 Prozent. Die Resolve-Rate verschiebt sich im Schnitt nur um ein bis zwei Prozentpunkte.
Das ist kein glamouröses Feature. Aber betriebswirtschaftlich ist es genau die Technik, die entscheidet, ob man Agenten ernsthaft testet oder nach drei teuren Experimenten wieder lässt. Wenn ein Handwerksbetrieb mit Büroassistenz oder eine kleine Steuerkanzlei einen Agentenworkflow ausprobiert, ist nicht die Demo der kritische Moment. Kritisch ist die zweite Woche, wenn zwanzig echte Fälle durchlaufen und jeder Fehllauf Zeit, Tokens und Nerven kostet.
Der dritte Strang geht tiefer in die Architektur. Zwei neue Arbeiten drehen sich um denselben Schmerz: Lange Kontexte sind teuer. Ein Modell kann sehr viel Text aufnehmen, aber beim Generieren muss es ständig entscheiden, worauf es schaut. Dieser Speicher heißt KV-Cache. Je länger Kontext und Denkspur, desto stärker wird dieser Cache zum Kosten- und Latenzproblem.
Declarative Attention löst das mit einer eleganten Idee. Das Modell deklariert selbst, ob es gerade globalen Kontext braucht, ob es auf einen bestimmten Bereich fokussieren will oder ob der lokale, jüngste Output reicht. Die Engine liest diese Signale und überspringt große Teile des Speichers. In Tests über fünfzehn Long-Context-Aufgaben reduziert das bei Gemma-4-31B die insgesamt attendierten Tokens um 52,0 Prozent. Bei Qwen-3.6-27B sind es 31,1 Prozent. Die Accuracy fällt um 1,27 beziehungsweise 2,75 Prozentpunkte.
Random Attention ist noch frecher. Dort wird nach dem Prompt innerhalb jedes Attention-Heads zufällig Cache entfernt, statt mit komplizierten Relevanzscores zu arbeiten. Der Prompt bleibt geschützt, weil dort die Aufgabe steht. Die Reasoning-Spur ist oft redundanter, als man denkt. Die Autoren berichten über vier Modelle und sechs Reasoning-Aufgaben und sehen in vLLM 32 bis 43 Prozent höheren Durchsatz.
Die Pointe ist bodenständig: KI-Kosten sinken nicht nur, weil Anbieter Preise senken. Sie sinken auch, wenn Systeme lernen, weniger Ballast mitzuschleppen. Nicht jedes Dokument muss auf dem Tisch liegen. Manchmal reicht der Auftrag, die letzten Notizen und ein klarer Verweis darauf, wo der Rest steht.
Jetzt wird daraus eine praktische Unternehmerfrage. Ich würde diese Woche nicht mit GPT-6 Astra anfangen, nicht mit einem Modellvergleich und auch nicht mit einer riesigen Tool-Liste. Ich würde eine einzige wiederholbare Aufgabe auswählen und daraus eine Testkarte bauen.
Beispiel Almanac: Das Produkt verspricht einen Firmenagenten mit zweitem Gedächtnis. Der interessante Teil ist die Reibung dahinter. Gmail, Calendar, Granola, PostHog, persönliche Accounts, geteilte Accounts, OAuth-Connectoren, Rechte und Memory. Genau da scheitern viele Agentenprodukte im Betrieb. Nicht am Antworttext, sondern daran, dass sie den richtigen Kontext nicht sauber bekommen.
Oder InvoiceFlow-AI. Da liest KI Rechnungen aus PDFs, normalisiert die Daten und danach entscheiden deterministische Regeln über APPROVED, REVIEW oder REJECTED. Ich mag dieses Muster, weil es ehrlich ist. Die KI liest und strukturiert. Die Entscheidung über Geld bleibt an Regeln, Toleranzen, Duplikatprüfung, Vendor-Abgleich und menschlicher Kontrolle hängen. Das ist nicht weniger modern. Das ist erwachsener.
Die Testkarte für diese Woche wäre deshalb: Nimm zehn echte Rechnungen, Support-Mails oder Research-Fälle. Definiere vorab, wer verantwortlich ist. Schreibe eine Skill-Karte mit den Arbeitsschritten. Lege drei Messwerte fest: Wie viele Fälle werden ohne Nacharbeit richtig vorbereitet. Wie viele muss ein Mensch korrigieren. Und nach welchem Fehler brichst du den Test ab. Erfolg heißt nicht: klingt gut. Erfolg heißt zum Beispiel: acht von zehn Fällen sind korrekt vorsortiert, kein Hochrisiko-Fall wird automatisch durchgewunken und die Nacharbeit sinkt sichtbar. Wenn das nicht klappt, kaufst du kein größeres Modell, sondern verbesserst erst Kontext, Regeln oder den Prozess.
Wenn ich heute eine Linie ziehen müsste, dann diese: Die nächste KI-Frage ist nicht, welches Modell am hellsten leuchtet. Die Frage ist, welches Arbeitswissen du festhältst, welche Läufe du billig prüfen kannst und wo du der Maschine klare Grenzen gibst. Wer das sauber macht, bekommt mehr aus den Modellen heraus, ohne jeden Monat auf die nächste Ankündigung zu warten. Wenn euch die Folge geholfen hat, hinterlasst gerne eine Bewertung auf Spotify oder Apple Podcasts. Und wenn ihr mir schreiben wollt, die Adresse steht in den Shownotes. Pfiat euch und bis morgen, eure Lissy.