advisory / 02
Prüfung agentischer Systeme
Ein Zweitgutachten zu dem Agenten, den Sie betreiben — oder zu dem Angebot, das Sie zeichnen wollen.
In der Demo funktioniert es. Das ist der teuerste Satz in diesem Feld: Demo-Erfolg und Produktionszuverlässigkeit sind zwei verschiedene Größen, und die Lücke ist messbar. Werkzeug-aufrufende Agenten lagen 2024 unter 50% Aufgaben-Erfolg — und unter 25%, wenn dieselbe Aufgabe achtmal wiederholt wurde.
Ein technisches Zweitgutachten in zwei Wochen zu dem Agenten, dem LLM-Feature oder dem Retrieval-System, das Sie bereits betreiben — oder zu dem Angebot, das Sie zeichnen wollen — gemessen am Stand der Technik.
das erhalten Sie
Sie erhalten: ein schriftliches Entscheidungsmemorandum — einen Architecture Decision Record, eine Spezifikation für die Eval-Umgebung und eine nach Schweregrad gereihte Maßnahmenliste, in der jeder Befund den günstigsten Test nennt, der ihn belegt. Dazu eine 90-minütige Durchsprache mit Ihrem Team.
was geprüft wird — die feste Checkliste
- 01
Kontrollfluss — wer entscheidet: das Modell oder der Code, und ob diese Entscheidung irgendwo schriftlich ist
- 02
Eval-Abdeckung und Konsistenz — was gemessen wird, auf welchen Aufgaben, und nicht „hat es einmal funktioniert“, sondern „funktioniert es acht von acht Malen“; ein Demo-Transkript ist kein Nachweis
- 03
Retrieval-Qualität — Chunking, Embedding-Wahl, Re-Index-Strategie und ob jede Antwort auf die Seite zurückführbar ist, aus der sie stammt
- 04
Werkzeug- und Berechtigungsgrenzen — was der Agent aufrufen darf, unter welcher Identität, und wie breit die Angriffsfläche ist: Prompt-Injection führt die aktuelle Top-Ten-Risikoliste an, und „Excessive Agency“ ist das Risiko, das eine manipulierte Ausgabe in eine reale Handlung verwandelt
- 05
Datenabfluss pro Route — welche Aufrufe Ihre Infrastruktur verlassen und welche darin bleiben, pro Route statt im Durchschnitt
- 06
Kosten- und Latenzhülle — agentische Muster verbrauchen rund das Vierfache einer Chat-Interaktion, Multi-Agent-Systeme rund das Fünfzehnfache; die Rechnung ist eine Architektureigenschaft, kein Betriebsunfall
- 07
Fallback- und Fehlerverhalten — was passiert, wenn ein Werkzeug ausfällt, eine Antwort leer ist oder das Modell etwas liefert, womit der Code nicht rechnet
- 08
Übergabe — wer dieses System betreiben und ändern kann, wenn die Person, die es gebaut hat, nicht mehr da ist
Form des Auftrags
2–3 Wochen, Fixpreis, ein System pro Prüfung. Ein zweites System ist eine zweite Prüfung — die Scope-Disziplin ist der Punkt, kein Upsell. Liegen zwei Angebote vor, prüft das Gutachten beide gegen dieselbe Checkliste.
2–3 Wochen, Fixpreis, ein System pro Prüfung · ein System pro Prüfung · die Checkliste ist das Angebot
Varianten nach Organisation
- Startups
- bringen Sie das Repository und die Prompts mit; der kürzeste Weg von „es funktioniert“ zu „es funktioniert zuverlässig“
- KMU
- die schriftliche Antwort auf ein Lieferantenversprechen, vor der Rechnung
- Konzerne
- vor dem Architekturboard durchführen und das Entscheidungsdokument ablegen
- ohne Technikabteilung
- ein Urteil in Klartext: was das System tut, was es berühren darf und was Sie den Anbieter als Nächstes fragen sollten
- öffentliche Verwaltung
- der technische Annex zu Ihrer Beschaffungsentscheidung, auf Deutsch
nicht für
kein Umbau, keine Übernahme — aus der Prüfung wird keine Wartung.
die Nachweise hinter diesem Format
der nächste Schritt
bringen Sie das Architekturdiagramm und die Eval-Ergebnisse mit; fehlen beide, ist das der erste Befund.
öffentliche Verwaltung
der technische Annex zu Ihrer Beschaffungsentscheidung, auf Deutsch.
zuletzt aktualisiert 2026-10-17 · vierteljährlich geprüft
Quellen: τ-bench (arXiv:2406.12045), ICLR 2025 · OWASP Top 10 for LLM Applications 2025 · Anthropic Engineering, Multi-Agent-Research-System, 2025.