Der spannendste KI-Agent von heute ist keiner, der laut eine Demo löst, sondern einer, der merkt: Der Auftrag ist unvollständig. Servus, ich bin Lissy. Heute geht es um Tools und Automatisierung: Agenten sollen echte Aufträge bauen, kluge Rückfragen stellen, ihren Arbeitsstand zeigen und Kosten sowie Daten im Griff behalten.
Fangen wir mit ττ-Bench an, gesprochen ungefähr Hyper-Tau-Bench. Die Idee klingt erst mal meta: Ein KI-Agent wird nicht daran gemessen, ob er eine einzelne Aufgabe in einer vorbereiteten Umgebung löst. Er soll selbst einen kundenservicefähigen Agenten bauen. Dafür bekommt er Geschäftsdatensätze, Anforderungen eines Kunden, eine produktionsnahe API, eine bestehende Codebasis und Grenzen bei Modellwahl und laufenden Kosten. Also ungefähr das, was ein echter Automatisierungsauftrag liefert, wenn man ihn nicht für eine Demo weichspült.
Genau deshalb ist das Paper heute mein stärkster Punkt. Viele Agenten-Benchmarks prüfen noch, ob ein Modell einen kleinen Code-Fix, einen API-Aufruf oder ein Rätsel schafft. In einem Betrieb reicht das nicht. Ein Agent muss erkennen, welche Daten existieren, welche Anforderung implizit ist, welche Schnittstelle benutzt werden darf und welche Lösung später nicht zu teuer wird. Sonst entsteht ein Prototyp, den niemand betreiben will.
Für Unternehmer ist die Lektion klar. Testet Agenten nicht mit Mini-Aufgaben wie: fasse diese Mail zusammen. Nehmt einen echten kleinen Auftrag. Zum Beispiel: baue einen Assistenten, der Support-Tickets nach Produktlinie sortiert, fehlende Kundendaten markiert und erst dann einen Antwortentwurf schreibt. Gebt ihm alte Tickets, eine echte Produktliste, zwei absichtlich widersprüchliche Regeln und ein Kostenlimit. Erfolg ist nicht irgendein Text. Erfolg ist, dass der Agent Daten sauber nutzt, Lücken benennt und die Aufgabe so löst, dass ihr sie am nächsten Tag wieder laufen lassen würdet.
Das zweite Thema passt direkt dazu: OR-Clarify und InterOPT. Hier geht es um Optimierungsprobleme, also Schichtplanung, Tourenplanung, Einkauf oder Ressourcenverteilung. In der echten Welt sind solche Aufgaben fast nie vollständig beschrieben. Da fehlt ein Ziel, eine Nebenbedingung oder eine Geschäftsregel. Und genau dort machen Sprachmodelle gerne etwas Gefährliches: Sie raten still.
OR-Clarify testet deshalb nicht nur, ob ein Agent am Ende eine mathematische Formulierung erzeugt. Es testet, ob er vorher merkt, dass kritische Informationen fehlen. Die Aufgabe enthält eine öffentliche Beschreibung und versteckte Slots. Der Agent darf begrenzt Rückfragen an einen simulierten Nutzer stellen. Gemessen wird, ob er die fehlenden Ziele und Regeln findet, ob er rechtzeitig aufhört zu fragen und welche Interaktionskosten entstehen.
Nehmen wir eine Agentur mit zwölf Leuten, die Projektarbeit plant. Ein schlechter Agent bekommt den Satz: optimiere die Wochenplanung, und baut irgendeinen Kalender. Ein guter Agent fragt zuerst: Welche Kunden haben harte Deadlines. Welche Mitarbeiter dürfen nicht auf welches Thema. Was ist wichtiger, Auslastung oder Liefertermin. Und wann soll ein Mensch entscheiden. Diese Rückfragen sind Teil der Leistung.
Die Testkarte für diese Woche: Nehmt einen Prozess, bei dem heute Erfahrung zählt, etwa Angebotspriorisierung oder Ticket-Eskalation. Schreibt absichtlich eine unvollständige Anfrage. Bewertet nicht die finale Antwort, sondern die ersten drei Rückfragen. Wenn der Agent sofort optimiert, ist er zu riskant. Wenn er die zwei Regeln findet, die euren Alltag bestimmen, habt ihr einen Kandidaten.
Aus der Forschung springen wir in die Werkzeugwelt. BoardUI ist ein neues React-Designsystem für agentische Oberflächen. Das Repository wurde am ersten September angelegt, steht unter MIT-Lizenz und hatte beim Check 368 Sterne. Die Beschreibung: Komponenten für Agenten-Oberflächen, dazu eine lauffähige KI-App, bei der man den eigenen Modellschlüssel nutzt.
Warum ist das mehr als ein hübsches UI-Projekt. Weil die Oberfläche entscheidet, ob Menschen Agenten kontrollieren können. Bei normaler Software sieht man Felder, Buttons und Status. Bei Agenten muss man andere Dinge sichtbar machen: Was ist der Auftrag. Welche Schritte wurden erledigt. Welche Daten hat der Agent benutzt. Wo wartet er auf eine Entscheidung. Was kostet die nächste Aktion ungefähr. Und was passiert, wenn man stoppt.
Viele Firmen testen das Modell und vergessen die Arbeitsfläche. Dann sieht der Nutzer einen langen Text und soll irgendwie vertrauen, dass schon alles passt. Für echte Automatisierung braucht man eine Oberfläche, die Zwischenschritte zeigt und Entscheidungen heraushebt. Nicht aus Kontrollwahn, sondern weil Arbeit im Betrieb nachvollziehbar bleiben muss.
Wenn ihr so etwas testet, baut keine komplette App. Baut eine Agenten-Karte: Eingabe, geplante Schritte, verwendete Quellen, offene Entscheidung, Ergebnis. Wenn ihr den Arbeitszustand nicht in fünf Feldern sichtbar machen könnt, ist der Workflow wahrscheinlich noch nicht verstanden.
Das zweite Grassroots-Signal ist Subpool von gesta-run. Das Projekt beschreibt sich als leichtgewichtiger, selbst gehosteter Abo-Pool für Teams. Es wurde am zweiten September erstellt, ist Apache-zwei-lizenziert und hatte beim Check 68 Sterne. In den Topics stehen Claude Code, Codex, Gateway und Pooling.
Ich würde das nicht als fertige Unternehmensempfehlung verkaufen. Dafür ist so ein junges Projekt zu frisch. Aber als Signal ist es gut: Teams wollen KI-Werkzeuge teilen, begrenzen und nachvollziehen, ohne für jeden einzelnen Nutzer blind neue Kostenstellen aufzumachen. Gerade bei Coding-Agenten und CLI-Tools wird das wichtig. Wer hat welches Modell benutzt. Für welche Aufgabe. Mit welchem Limit. Und wann kippt ein Experiment von hilfreich zu teuer.
Das passt zu ττ-Bench: Ein Agentenauftrag ist nicht nur Code. Er hat laufende Kosten. Ein interner Assistent, der pro Ticket zehn Modellaufrufe macht, kann fachlich richtig sein und wirtschaftlich trotzdem Unsinn. Deshalb gehört Kostenkontrolle in den Testaufbau.
Praktisch heißt das: Wenn ihr mit Codex, Claude Code oder ähnlichen Werkzeugen arbeitet, legt für einen Pilot nicht nur einen Aufgabenordner an, sondern auch ein Budget. Zum Beispiel 30 echte Tickets, maximal zwei Stunden Laufzeit, maximal ein bestimmter Eurobetrag, und am Ende die Frage: Wie viele Aufgaben waren produktionsnah erledigt.
Zum Schluss Anthropic. Das Unternehmen hat Enterprise Frontier Safeguards angekündigt. Der Kern: große Kunden sollen stärkere Claude-Modelle nutzen können, während Daten in einer vom Kunden kontrollierten Cloud-Umgebung bleiben. Anthropic spricht von mehr als 100 beteiligten Kunden aus Finanzdienstleistungen, Gesundheitswesen, Fertigung, Telekommunikation, Recht, Handel und öffentlichem Sektor. Unterstützt werden sollen unter anderem Claude Code, Claude Enterprise, Amazon Bedrock, Google Agent Platform und Microsoft Foundry.
Das ist kein Thema, bei dem man nur Datenschutz draufschreibt und fertig ist. Anthropic beschreibt den Zielkonflikt ziemlich deutlich: Frontier-Modelle werden nützlicher, aber auch missbrauchsanfälliger. Betrug, Cyberangriffe, gestohlene Zugangsdaten und agentische Fehlhandlungen lassen sich nicht immer erkennen, wenn jede Interaktion isoliert betrachtet und sofort vergessen wird. Gleichzeitig wollen Unternehmen nicht, dass sensible Daten einfach beim Modellanbieter landen.
Genau hier wird die Agentenwoche rund. ττ-Bench sagt: Prüft Agenten an echten Aufträgen. OR-Clarify sagt: Gute Agenten müssen fehlende Regeln erkennen. BoardUI sagt: Macht die Arbeit sichtbar. Subpool sagt: Zählt Nutzung und Kosten mit. Und Anthropic sagt: Bei starken Modellen braucht der Kunde Kontrolle über Daten und Beobachtung.
Was von heute wirklich zählt: Agenten werden brauchbar, wenn Auftrag, Rückfragen, Oberfläche, Kosten und Datenkontrolle zusammenpassen. Wenn ihr diese Woche testet, nehmt einen echten kleinen Prozess, nicht die glänzendste Demo. Messt drei Dinge: Hat der Agent die fehlende Regel gefunden. Konntet ihr seinen Arbeitsstand sehen. War das Ergebnis den Aufwand wert. Wenn eine Antwort nein ist, seid ihr noch beim Experiment.
Wenn euch die Folge geholfen hat, hinterlasst gern eine Bewertung auf Spotify oder Apple Podcasts. Eine Mail geht natürlich auch, die Adresse steht in den Shownotes. Danke fürs Zuhören, Pfiat euch und bis morgen, eure Lissy.