Agent-Framework-Auswahl hat jetzt einen Benchmark, den du zitieren kannst

IBM Research und Hugging Face haben diesen Monat das Open Agent Leaderboard veröffentlicht — der erste öffentliche Benchmark, der Agent-Frameworks gleichzeitig nach Task-Erfolgsrate und Kosten bewertet. Wer als CTO noch zwischen LangGraph, AutoGen, smolagents oder einem eigenen Harness abwägt: Der Auswahlprozess hat sich verändert. Die Antwort muss nicht mehr lauten "wir mochten die Docs" oder "unser letzter Engineer kannte es halt." Die unbequeme Konsequenz: Frameworks, die dein Team als gleichwertig eingestuft hat, sind es messbar nicht — und die Abstände spielen in Produktionsumgebungen eine echte Rolle.

Was sich geändert hat — und was das Leaderboard wirklich misst

Das Open Agent Leaderboard, von IBM Research in Zusammenarbeit mit Hugging Face veröffentlicht, evaluiert Open-Source-Agent-Frameworks anhand eines standardisierten Sets agentischer Tasks. Die Evaluierungsmethodik bewertet jedes Framework nach Task-Erfolgsrate (hat der Agent das Ziel erreicht?), Tool-Calling-Genauigkeit (hat er die richtigen Tools in der richtigen Reihenfolge aufgerufen?) und Kosten pro Task in USD — mit einem fest definierten Modell-Backend, sodass das Framework — nicht das Basismodell — die eigentliche Variable ist.

Das Leaderboard ist innerhalb des Evaluation-Harness modell-agnostisch ausgelegt. Das bedeutet: Zwei Frameworks auf demselben Basismodell können deutlich unterschiedliche Erfolgsraten erzielen — je nachdem, wie sie Prompts strukturieren, State verwalten und Tool-Call-Retries handhaben. Die Kostenkennzahl erfasst den Token-Verbrauch über den gesamten Agent-Loop, nicht nur einen einzelnen Inference-Call — und genau das ist die Zahl, die auf deiner API-Rechnung in Produktion auftaucht.

Die Methodik unterscheidet zwischen Single-Agent- und Multi-Agent-Konfigurationen und trennt tool-intensive Tasks (Dateioperationen, API-Calls, Code-Ausführung) von reasoning-intensiven Tasks (mehrstufige Planung, konditionales Branching). Diese zwei Achsen decken sich fast direkt mit der Aufteilung echter Enterprise-Workloads: orchestrierungsintensive Pipelines versus research-ähnliche Reasoning-Chains.

Warum das die Mathematik der Framework-Entscheidung verändert

Die meisten Teams wählen ein Agent-Framework so wie einen JavaScript-Bundler: nach Community-Momentum, weil intern jemand dafür plädiert hat oder weil ein Tutorial zufällig gut war. 2024 war das vertretbar — die Frameworks waren alle früh, Benchmarks gab es nicht. 2026 ist die Entscheidung für ein Framework eine mehrjährige Architekturentscheidung. Agent-Logik akkumuliert sich. Prompt-Strukturen wachsen ins Tooling ein. Nach 12 Monaten in Produktion von einer Orchestrierungsschicht auf eine andere zu migrieren ist kein Wochenendprojekt.

Die Kosten-pro-Task-Zahl ist die, die die meisten Entscheidungsträger unterschätzen. Ein Framework, das 40 % mehr pro Task kostet, ist bei 10.000 Tasks im Monat ein Rundungsfehler. Bei 500.000 Tasks im Monat — was ein erfolgreicher interner Rollout innerhalb von 18 Monaten erreicht — ist es ein Budgetposten, der in deinem Infrastructure-Review auftaucht. Das Leaderboard gibt dir eine Möglichkeit, diese Zahl vor dem Build zu modellieren, nicht nachdem du bereits festgelegt bist.

Die zweite unterschätzte Dimension ist die Tool-Calling-Genauigkeit unter Fehlerbedingungen. Die meisten Framework-Demos zeigen den Happy Path. Die Leaderboard-Evaluierung enthält Tasks, bei denen Tools Fehler zurückgeben, nur Teilergebnisse liefern oder Retry-Logik erfordern. Die Erfolgsrate bei diesen Tasks sagt die Produktionszuverlässigkeit deutlich besser voraus als die Performance in sauberen Demos. Wenn dein Workload stark tool-abhängig ist — und die meisten Enterprise-Agent-Workloads sind es — zählt dieser Sub-Score mehr als die Headline-Accuracy.

Sprich mit Domani AI über deinen Build →

Der Montag-Morgen-Schritt: Deine Anforderungen gegen die Leaderboard-Achsen prüfen

Fang nicht damit an, das vollständige Leaderboard zu lesen. Schreib zuerst drei Constraints aus deinem tatsächlichen Build auf — bevor du dir die Rankings anschaust:

• Latency-Budget: Was ist die maximal akzeptable End-to-End-Task-Completion-Zeit? Frameworks mit mehr Retry- und Reflection-Loops erzielen bessere Accuracy-Werte, addieren aber Wall-Clock-Zeit.
• Tool-Surface: Wie viele verschiedene Tools muss dein Agent aufrufen — und wie häufig geben diese Tools Nicht-200-Responses zurück? Gewichte den Tool-Calling-Accuracy-Sub-Score entsprechend.
• Monatliches Task-Volumen auf 18-Monats-Skala: Projiziere voraus, nicht vom aktuellen Stand. Multipliziere diese Zahl mit dem Kosten-pro-Task-Delta zwischen deinen zwei Top-Framework-Kandidaten.

Sobald du diese drei Zahlen hast, schau dir die Sub-Scores des Leaderboards für deine Task-Konfiguration an (Single-Agent vs. Multi-Agent, tool-intensiv vs. reasoning-intensiv). Shortliste die zwei Frameworks, die nach deinen gewichteten Kriterien am besten abschneiden. Dann mach einen 48-Stunden-Spike: Nimm einen echten Task aus deinem Backlog, implementiere ihn in beiden Frameworks und messe den tatsächlichen Token-Verbrauch und die Erfolgsrate auf deinem Tooling. Das Leaderboard liefert dir den Prior — der Spike liefert das Likelihood-Update für deinen spezifischen Stack.

Wenn dein Team keine 48 Stunden für diesen Spike hat, ohne jemanden aus einer laufenden Lieferverpflichtung herauszureißen, ist das selbst ein Signal: Du bist nicht ausreichend aufgestellt, um diese Architekturentscheidung ohne externen Input sicher zu treffen.

Was es kostet, jetzt zu handeln versus auf ein reiferes Leaderboard zu warten

Jetzt zu handeln bedeutet, sich für ein Framework zu entscheiden, bevor das Leaderboard alle Frameworks abdeckt, die dein Team in Betracht zieht. Das Open Agent Leaderboard ist live, aber nicht vollständig — wenn dein bevorzugtes Framework noch nicht enthalten ist, bist du wieder auf unvollständige Informationen angewiesen. Der ehrliche Kompromiss: Du kannst 60 bis 90 Tage auf eine breitere Abdeckung warten — aber wenn dein Build in Q3 startet, komprimiert diese Verzögerung dein Architektur-Fenster erheblich.

Das größere Risiko liegt auf der anderen Seite: unbegrenzt auf einen perfekten Benchmark zu warten und gleichzeitig jeden Engineer das Framework wählen zu lassen, das er kennt. Das erzeugt einen heterogenen Agent-Stack, der teuer zu betreiben und kaum zu auditieren ist. Eine standardisierte Framework-Entscheidung — auch eine imperfekte, getroffen mit den besten verfügbaren Daten — kostet über 24 Monate weniger als drei parallel laufende Frameworks, weil niemand eine Entscheidung getroffen hat.

Das Leaderboard trifft die Entscheidung nicht für dich. Es nimmt dir die Ausrede, sie nicht zu treffen.