Wie wir das Screening von Bewerbungen mit einem KI-nativen Workflow neu aufgebaut haben
Wir haben 125 KI-Agenten parallel eingesetzt, um 115 Kandidaten anhand einer einheitlichen Bewertungsskala zu prüfen, und dabei für 65 $ eine rangierte, nachvollziehbar begründete und vollständig auditierbare Shortlist erstellt.
String (cache miss) | 2.306.691 | $5,00 | $11,53 | | Cache-Schreibvorgänge | 6.536.462 | $6,25 | $40,85 | | Cache-Lesevorgänge | 12.806.404 | $0,50 | $6,40 | | Ausgabe | 248.312 | $25,00 | $6,21 | | Gesamt | | | ~$65 |
Das ergibt rund $0,57 pro Kandidat.
Ein kontraintuitiver Befund: Cache-Schreibvorgänge sind der größte Posten
Die naheliegende Annahme ist, dass Prompt-Caching stark helfen sollte, weil alle 115 Agenten dieselben 6 Kriterien-Dateien lesen. Das stimmt so nicht, wie man erwarten würde.
Prompt-Caching funktioniert über exakten Präfix-Abgleich, und jede Agenten-Session ist unabhängig. 125 Agenten bedeuten 125 unabhängige Sessions – jede mit einer anderen Aufgabenbeschreibung (unterschiedliche Kandidatendaten) –, sodass ein von Agent A geschriebener Cache von Agent B nicht getroffen werden kann. Caching hilft aber innerhalb der eigenen Multi-Turn-Ausführung jedes Agenten (Kriterien lesen → GitHub besuchen → Portfolio besuchen → Ausgabe, wobei frühere Inhalte in jeder Runde erneut gelesen werden).
Das offenbart einen architektonischen Trade-off: Fan-out-Parallelität vervielfacht die Kosten für Cache-Schreibvorgänge (jeder Agent baut seinen eigenen Cache auf), erkauft dafür aber isoliertes, nicht kontaminierendes Urteilsvermögen und eliminiert die quadratische Kontext-Akkumulation sequenzieller Verarbeitung. Für Aufgaben, bei denen die Qualität des Urteils entscheidend ist, lohnt sich dieser Trade-off.
Wie man den ROI einordnen sollte
Direkter Vergleich mit manueller Prüfung: Ein Hiring Manager, der einen Lebenslauf sorgfältig liest, GitHub prüft und Notizen schreibt – vorsichtig geschätzt 5 bis 10 Minuten pro Kandidat. Bei 115 Kandidaten sind das 10 bis 19 Stunden fokussierter Arbeit, wobei die Maßstäbe währenddessen driften.
Dieser Workflow lieferte:
| Was | Wie gut |
|---|---|
| Kosten | $0,57 pro Kandidat, vollständige Rangliste in ~13 Minuten |
| Tiefe | Vierdimensionale Bewertungen, schriftliche Begründung, Risikohinweise und adversariales Review-Urteil pro Kandidat |
| Konsistenz | Kandidat #1 und Kandidat #115 nach exakt demselben Regelwerk bewertet |
| Nachvollziehbarkeit | Vollständige Argumentationskette für jede Platzierung |
Der wichtigere ROI liegt jedoch in der Aufmerksamkeitslenkung: Der Workflow lenkte die menschliche Aufmerksamkeit weg von den 83 klar ungeeigneten Kandidaten und hin zu den 6 echten Buildern an der Spitze. Das ist der wertvollste Beitrag, den eine Erstsichtung leisten kann.
Könnte es günstiger sein?
Ja, aber es muss es vermutlich nicht sein. Würde dies zu einem hochfrequenten, hochvolumigen Vorgang (Hunderte Kandidaten täglich), wäre die praktische Optimierung:
- Sonnet für die Bewertungsphase verwenden, Opus nur für das adversariale Review – vermutlich 70 bis 80 % Kostenreduktion bei minimalem Qualitätsverlust.
- Oder ein günstigeres Modell für einen groben ersten Durchgang nutzen, dann Opus für die detaillierte Bewertung der Top-Kandidaten.
Aber Einstellungsentscheidungen sind selten, folgenschwer und schwer rückgängig zu machen. Bei $65 für die Verarbeitung einer gesamten Pipeline mit voller Nachvollziehbarkeit und iterierbaren Kriterien ist die Schlussfolgerung klar: das beste Modell verwenden. Urteilsqualität nicht für marginale Kosteneinsparungen eintauschen.
Das große Ganze
Was an diesem Experiment wirklich spannend ist, ist nicht „KI kann Lebensläufe screenen" – das ist keine neue Idee. Es ist, dass das Modell des dynamischen Workflows – Code, der eine Flotte von KI-Agenten orchestriert – bestimmte Arbeitskategorien erstmals strukturierbar, reproduzierbar und iterierbar macht.
Hiring ist nur der Einstiegspunkt. Dasselbe Muster – Kriterien als lesbare Dateien + parallele Fan-out-Bewertung + adversariales Review + deterministische Aggregation – überträgt sich auf jeden Bereich, in dem konsistente, hochvolumige subjektive Urteile gefragt sind: Content-Moderation, Code-Review, Triage von Nutzer-Feedback, Wettbewerbsanalyse, Due Diligence.
Das Regelwerk ist v0.1. Es ist nicht perfekt. Aber es ist jetzt ein versioniertes, diskutierbares, verbesserbares Gut – keine implizite Übereinkunft, die nur in jemandes Kopf existiert. Dieser Wandel, mehr als jedes einzelne Ergebnis, war es eigentlich, worum es in diesem Experiment ging.
