Audit-Rubric fuer Agent-Systeme
Strukturierte Bewertung eines existierenden Agent-Systems in 10 Core-Kategorien plus 2 Bonus-Kategorien, jeweils 0/10. Liefert einen gewichteten Aggregat-Score plus Top-Maßnahmen-Liste mit Impact × Effort.
Verwendet die 10 Prinzipien aus agent-system-best-practices als Bewertungsbasis. Ist nicht zu verwechseln mit:
Wann triggern
- Nach 2-4 Wochen Production-Use eines neuen Agent-Systems
- Vor Kunden-Uebergabe / Vor Pricing-Aenderung
- Quartalsweise auf produktive Systeme
- Vor jeder Major-Refactor-Entscheidung (Multi-Tenant-Schritt, neue Modell-Generation)
Methodik
Pro Kategorie:
- Stark — was lauft gut, mit Belegen aus Source-Files/Logs
- Schwach — wo klemmt es, mit konkreten Beispielen
- Score 0-10 mit klarer Begruendung
- Hebel — eine konkrete Maßnahme die den groessten Score-Lift bringt
Am Ende:
- Gewichteter Aggregat-Score
- Top-5-Maßnahmen sortiert nach Impact × Effort
- Realistic-Ceiling-Einschaetzung (was kostet 9.5 vs 9.9 vs 10)
- Baseline-JSON fuer Regression-Vergleich
Die 10 Core-Kategorien mit Gewichtung
| # | Kategorie | Gewicht | Was gemessen wird |
|---|---|---|---|
| 1 | Modell-Auswahl & Routing | 8% | Default, Routing-Logik, Modell-Mix, Cost-Cap |
| 2 | Tool-Design & MCP-Integration | 12% | Anzahl, Whitelist-Strategie, search_tools, Naming, Side-Effects-Declaration |
| 3 | Context-Engineering & System-Prompt | 12% | Struktur, Date-Context, Tool-Hints, Anti-Halluzination, Templating |
| 4 | Memory & State-Management | 12% | Conversation-Persistence, DB-Backend, User-Memory, Vault-Integration |
| 5 | Eskalation, Safety & Human-in-the-Loop | 10% | Irreversible-Actions-Gating, Tool-Schema-Constraints, Audit-Trail |
| 6 | Evals & Quality-Gates | 10% | Eval-Suite, Regression-Detection, Acceptance-Kriterien, CI-Gate |
| 7 | Observability & Monitoring | 10% | Tool-Call-Success-Rate, Cost-per-User, SLI/SLO, Alarms |
| 8 | Cost-Engineering & Latency | 8% | Prompt-Caching, Parallel-Calls, Modell-Routing, Pre-Warming |
| 9 | Security & DSGVO-Compliance | 12% | Region-Lock, KMS, ZDR, Forward-Headers, AVV, Sub-Processor |
| 10 | Compounding & Iteration | 6% | Run-Logs, Lessons-Learned, System-Prompt-Versionierung, Pattern-Capture |
Bonus-Kategorien (additiv, 5% Gewicht jeweils):
- Multi-Tenancy-Readiness (Template-System, Per-Tenant-Isolation)
- Onboarding & Documentation (Customer-facing Quickstart, FAQ, Tooltips)
Score-Skala pro Kategorie
| Score | Bedeutung |
|---|---|
| 0-2 | Kritisch, blockiert Production-Use |
| 3-4 | Schwach, sichtbare Defizite |
| 5-6 | OK, im Mittelfeld |
| 7-8 | Gut, kein dringender Bedarf |
| 9 | Best-in-Class fuer KMU-Scale |
| 10 | Theoretisch — praktisch kaum erreichbar, oft over-engineered |
Score-Stufen-Definition (Beispiel Memory & State)
| Score | Stand |
|---|---|
| 0-2 | Keine Persistierung, kein Backup, Conversation-Loss bei Restart |
| 3-4 | SQLite-on-NFS mit bekannten Lock-Issues, Backup manuell |
| 5-6 | Postgres oder gleichwertig, automatische Backups, kein User-Memory |
| 7-8 | Postgres + Connection-Pooling + automatische Backups + Per-User-Settings |
| 9 | Plus Knowledge-Base pro User + Vault-Integration als Retrieval-Layer |
| 10 | Plus Cross-Session-Memory + pgvector + Event-Sourcing (oft over-engineered) |
Analoge Stufen-Definitionen pro Kategorie sind im jeweiligen Audit-Report zu dokumentieren.
Was gilt als 10/10 — und warum es oft Bullshit ist
Score 10 in einer Kategorie bedeutet: alle Best-Practices aus agent-system-best-practices umgesetzt plus systematische Quality-Loops. In der Realitaet kostet der Sprung von 9 auf 10 mehr als der Sprung von 4 auf 9. Best-in-Class-KMU-Setup liegt bei 9.2-9.5/10 Aggregat. Ab 9.5 ist es Engineering-Eitelkeit, keine Business-Notwendigkeit.
Faustregel: wenn ein Bonus-Item nicht durch konkrete User-Pain oder Sales-Pitch getriggert wird, ist es Over-Engineering.
Output-Format
intern/runs/<datum>-audit-<system-slug>/
├── _index.md (Run-Frontmatter + Top-5 + Naechster-Audit-Trigger)
├── report.md (Detail-Befund pro Kategorie)
└── baseline.json (Score-Snapshot fuer Regression-Vergleich)
baseline.json Format siehe 2026-05-17 Beispiel.
Top-Maßnahmen-Format
Pro Maßnahme:
ID: A1
Title: RDS-Migration durchziehen
Category: memory_state
Impact: 9/10 (loest groesstes operatives Risiko)
Effort: 1 Tag
Cost: +14 EUR/Monat
Wave: 1
Top-5 nach Impact × Effort. Drei Wellen empfohlen:
- Welle 1 (Production-Ready): 5-6 Bautage, hebt 2-3 Punkte
- Welle 2 (Reife): 7-8 Bautage, hebt 1 Punkt
- Welle 3 (Excellence, opportunistisch): 10-15 Bautage verteilt, hebt 0.3 Punkte
Anti-Patterns im Audit selbst
- Checklist-Modus. Audit muss reasoning sein, nicht Bullets abhaken. Pro Kategorie ein Befund mit Begruendung, dann Score.
- Wunschlisten-Bias. „Hier koennte man noch X” ist kein Befund. Befund ist „User merkt X weil Y nicht funktioniert”.
- Theoretisches Best-Practice-Zitieren. Wenn Best-Practice nicht im konkreten Kontext relevant ist, nicht reinschreiben.
- Severity-Inflation. Wenn alles „kritisch” ist, ist nichts mehr kritisch. Kritisch heisst: blockiert Production oder Compliance.
Erste Anwendung
Beispiel-Audit: _index — Audit der VF Open WebUI Infrastruktur. Aggregat-Score 6.6/10. Drei Wellen geplant zur Hebung auf 9.5/10.
Cross-Refs
- agent-system-best-practices — Source der 10 Prinzipien
- SKILL — komplementaer (Security-Achse)
- SKILL — komplementaer (Browser-QA)
- mcp-best-practices — Detail fuer Kategorie 2