Den Workflow entwerfen
Explizite Aufgaben, strukturierte Tool-Verträge, persistenter Zustand und deterministische Kontrollpunkte rund um Modellentscheidungen.
AI Engineering
KI-Systeme, die handeln können – und überprüfbar bleiben.
Mein Schwerpunkt ist angewandtes AI Engineering: Agenten-Orchestrierung, LLM-gestützte Tools und die Infrastruktur, die ihr Verhalten beobachtbar, wiederherstellbar und durch klare Befugnisse begrenzt macht.
Ansatz
Mehr als ein Modell zu prompten
Die Grenzen belegen
Minimale Rechte, isolierte Ausführung, unabhängiges Review und eine ehrliche Dokumentation von Fehlerfällen.
Das Ergebnis messen
Tests und wiederholbare Evaluierungen statt Demo-Videos oder vom Modell erzeugter Erfolgsmeldungen.
Ausgewählte Systeme
Was meine Arbeit zeigt
Drei Systeme, die ich gebaut habe – jeweils mit öffentlichem Code und einer ausführlichen Fallstudie.
Agenten-Orchestrierung & Zuverlässigkeit
Acthelm
Ein agentengesteuertes Betriebssystem mit persistentem Aufgabenzustand, deterministischen Auslösern, isolierten Codeänderungen, unabhängigem Modell-Review und expliziter Release-Freigabe.
Engineering-Belege
- Agenten-Lebenszyklus und Aufgaben-Orchestrierung
- Grenzen der Tool-Ausführung und menschliche Freigabe
- Wiederherstellung nach Abstürzen und Nachvollziehbarkeit
Umfang: In aktiver Entwicklung; das Stage-C-Design ist kein Beleg für vollständig unbeaufsichtigte Ausführung.
LLM-Anwendungen & Tools für Agenten
Seerxo
Ein Live-Produkt mit CLI, lokalen und entfernten MCP-Integrationen, einer API und einer regelbasierten Listing-Prüfung, die von generativen Vorgängen getrennt ist.
Engineering-Belege
- MCP- und Tool-Schema-Design
- LLM-gestützte Produktintegration
- Deterministische Validierung und API-Verträge
Umfang: Das Backend ist nicht öffentlich; die Fallstudie beschränkt sich auf verifizierten Client-Code und dokumentierte Schnittstellen.
Ergänzende Arbeit · SSH-Sicherheits-Engineering
SigSieve
Kein KI-Projekt: ein SSH-Agent-Proxy in Rust, der begrenzt, welche Schlüssel weitergeleitet werden, und sie an vertrauenswürdige Ziel-Hostkeys binden kann. Er zeigt die Sicherheitsgewohnheiten, die ich in KI-Infrastruktur einbringe.
Engineering-Belege
- Bedrohungsmodellierung und minimale Rechte
- Sicherheitskontrollen auf Protokollebene
- Testgetriebener Umgang mit Fehlerfällen
Umfang: Experimentelle Sicherheitssoftware. Nicht unabhängig auditiert; kein Anspruch auf vollständigen Schutz.
Für Code-Reviewer
Wo man im Code anfängt
Technische Referenzen, geprüft am 3. November 2026. Die Implementierung ist an feste Quellstände gebunden: Acthelm b8b7e77, Seerxo 8c52984 und SigSieve alpha.4 5ea37b7.
- Deterministische Arbeitserkennung — keine Arbeit, kein Modellaufruf
app/business_reconciler.py - Golden Evals: „erledigt“ ohne Beleg wird abgelehnt
evals/test_supervisor_evals.py - Tests für Kodierung nicht vertrauenswürdiger Inhalte und Freigabe-Eskalation
evals/test_trust_evals.py - Crash-Recovery-Tests gegen echtes PostgreSQL
tests/test_worker_crash_recovery_postgres.py - MCP-Tool-Schemas mit expliziten Grenzen
src/mcp/tools.js - End-to-End-Test des stdio-MCP-Servers
tests/stdio-mcp.test.js - Bedrohungsmodell
docs/THREAT_MODEL.md - Findings-Register: jedes Problem und seine Behebung
docs/FINDINGS.md
KI-Evaluierung & Zuverlässigkeit
Validierung als Teil des Workflows
Deterministische Tests decken strukturierte Ausgaben, unbelegte Abschlussmeldungen, Wiederherstellung und Tool-Verträge ab. „In CI“ bezeichnet Tests im Test-Workflow des Projekts. Modellleistung wird separat gemessen; die Tabelle unterscheidet implementierte Prüfungen von Dimensionen ohne berichtetes Benchmark-Ergebnis.
| Dimension | Status | Beleg |
|---|---|---|
| Validierung strukturierter Ausgaben | In CI | Fehlerhafte oder fremde Agentenergebnisse werden abgelehnt · evals/test_supervisor_evals.py |
| Unbelegte Behauptungen | In CI | „Erledigt.“ ohne Beleg ergibt REVISION_REQUIRED · evals/test_supervisor_evals.py |
| Prompt Injection | Teilweise | Kodierungs- und Eskalationsszenarien sind getestet; das belegt keine Injection-Resistenz echter Modelle · evals/test_trust_evals.py |
| Sicherheitsgrenzen | In CI | Tripwire-Tests für CI-Berechtigungen und Zugangsdaten · tests/test_trust_boundary.py |
| Wiederherstellung von Agenten | In CI | Crash- und Stale-Run-Recovery gegen echtes PostgreSQL · tests/test_worker_crash_recovery_postgres.py |
| Regressionsszenarien | In CI | Stage-C-Golden-Szenarien, die jeweils den abgefangenen Fehler benennen · evals/test_stage_c_runner_evals.py |
| Tool-Verträge (MCP) | In CI | stdio-MCP-Server in Seerxo End-to-End getestet · tests/stdio-mcp.test.js |
| Aufgaben-Erfolgsquote | Nicht berichtet | — |
| Tool-Call-Genauigkeit auf Modellebene | Nicht berichtet | — |
| Latenz pro Aufgabe | Nicht berichtet | — |
| Kosten pro Aufgabe | Nicht berichtet | Nur als Richtlinie: kostenpflichtige API-Schlüssel werden abgelehnt · agents/cost_policy.yaml |
Evaluierungs-Roadmap
Erforderliche Belege für Modell-Benchmarks
Die deterministischen Tests oben prüfen das Verhalten der Steuerungsschicht. Ein Modell-Benchmark benötigt zusätzliche Belege; dies ist eine Evaluierungsmethode, keine zugesagte Produkt-Roadmap:
- Eine versionierte Aufgabensammlung mit festen Eingaben und vom Supervisor prüfbaren Erfolgskriterien
- Jeder Lauf mit Anbieter, Modellversion, Transkript, Tool-Calls und Ergebnis protokolliert
- Metriken je Sammlungsversion: Erfolg, Teilerfolg, falsche Freigaben, Wiederherstellungen, Latenz und Ressourcenverbrauch
- Ein CI-Job, der den deterministischen Teil bei jeder Änderung und den Modellteil auf Abruf ausführt und Rohdaten veröffentlicht
Das sind Evaluierungsfragen, keine veröffentlichten Benchmark-Ergebnisse. Ein belastbares Ergebnis braucht definierte Aufgaben, eine Methodik und Rohdaten.
Erledigt ein Agent Aufgaben zuverlässig?
Eine versionierte, wiederholbare Aufgabensammlung erstellen. Erfolg, Teilerfolg und Fehlschläge mit Testbedingungen und Stichprobengröße berichten.
Wann hilft ein Review durch mehrere Agenten?
Eine Ein-Agenten-Baseline mit Coder-plus-Reviewer-Workflows auf denselben Aufgaben vergleichen. Meinungsverschiedenheiten und falsche Freigaben erfassen.
Was passiert, wenn Tools ausfallen?
Timeouts, ungültige Tool-Ausgaben, veralteten Zustand und abgebrochene Läufe einspeisen. Wiederherstellung messen und festhalten, wo ein Mensch eingreifen muss.
Was kostet Autonomie?
Latenz, Token-/API-Nutzung (sofern zutreffend) und Ressourcenkosten pro abgeschlossener Aufgabe messen; Abonnements nicht mit Preisen pro Token verwechseln.
Derzeit nicht beansprucht: ein belegter RAG-Benchmark, ein selbst trainiertes Foundation Model, unabhängig auditierte Agenten-Sicherheit oder gemessener autonomer Aufgabenerfolg auf Produktionsniveau. Dafür braucht es eigene Belege.
Öffentliche Arbeit & Community
Offen entwickeln, Arbeit nützlich machen
Wiederverwendbarer Code, technische Dokumentation und transparente Grenzen gehören zur Arbeit. SigSieve und der Seerxo-Client sind öffentlich und MIT-lizenziert; der Quellcode von Acthelm ist öffentlich, hat aber derzeit keine Open-Source-Lizenz. Der Unterschied ist wichtig.
SigSieveSicherheitsmodell, Grenzen, Installation und Quellcode →SeerxoMCP-Tools, CLI-Dokumentation und Quellcode →Technische RechercheArchitekturstudien mit Belegen und Grenzen (Englisch) →
Sicherheitsprobleme bitte über die Security-Policy des jeweiligen Repositorys melden, nicht über öffentliche Issues.
Interesse an einer Zusammenarbeit?
Ich suche Rollen als AI Engineer, Applied AI Engineer und LLM-/Agent-Engineer. Meine stärksten Belege liegen in Agentensystemen, Entwickler-Tools und Backend-Infrastruktur.