Denkmaschinen · Teil 0 · Warum selbst bauen · 2. Juli 2026

Warum einen eigenen KI-Agenten bauen, wenn es Claude, Codex und OpenClaw längst gibt?

Teil 0 einer Artikelserie über zwei eigene Agenten-Projekte: wintermute (ein produktiver persönlicher KI-Agent) und agenticframework (ein produktiv einsetzbares Meta-Framework für autonome Entwicklungs-Pipelines).

Die Frage, die zuerst beantwortet werden muss

Bevor es in dieser Serie um Architektur, Sicherheit oder Kosten geht, steht eine unbequemere Frage im Raum: Warum überhaupt selbst bauen? Es gibt leistungsfähige KI-Assistenten fertig zu kaufen — Claude, ChatGPT, GitHub Copilot, Codex CLI, gehostete Multi-Agent-Plattformen wie OpenClaw. Jede Zeile Code, die man selbst schreibt, ist Zeile Code, die man selbst warten muss, um 2 Uhr nachts, wenn der Container aus Gründen nicht mehr hochkommt, die einem niemand erklären wollte.

Ich beantworte das anhand von zwei echten, produktiv eingesetzten Projekten: wintermute, ein seit Monaten produktiv laufender persönlicher Agent mit Telegram-Anbindung (WhatsApp ist als nächster Kanal vorbereitet), und agenticframework, ein Meta-Framework, das komplette Software-Entwicklungs-Pipelines mit mehreren spezialisierten Agenten orchestriert.

Eine Klarstellung vorab: OpenClaw ist kein Konkurrent, sondern Infrastruktur

Ein häufiges Missverständnis lässt sich an einem konkreten Detail auflösen: wintermute läuft produktiv auf einem Hetzner CAX11 Server, und die Deployment-Konfiguration dafür liegt in einem Repository namens openclaw-server. Das könnte den Eindruck erwecken, wintermute sei "auf OpenClaw aufgebaut" oder ein Fork davon.

Schön wär's — dann hätte ich mir die letzten Monate sparen können. Das ist nicht der Fall. OpenClaw ist in diesem Kontext die Hosting-Infrastruktur, auf der neben wintermute auch andere, unabhängige Agenten laufen (etwa "Dixie", ein Assistent, dessen Kommentar zur Motivation hinter wintermute im README zitiert wird). wintermute selbst ist von Grund auf eigenständig implementiert — mit genau zwei externen Abhängigkeiten von Substanz: LiteLLM (eine Abstraktionsschicht, die verschiedene LLM-Anbieter-APIs auf ein gemeinsames Interface normalisiert) und FastAPI (ein generisches Web-Framework, kein Agenten-Framework). Der komplette Agenten-Loop, das Memory-System, das Tool-Dispatch und die Persona-Logik sind Eigenentwicklung.

Diese Unterscheidung ist wichtig, weil sie die eigentliche Frage schärft: Es geht nicht darum, eine bestehende Agenten-Plattform zu meiden. Es geht darum, dass die Orchestrierung, das Gedächtnis und die Vertrauensgrenzen selbst kontrolliert werden — während man sich bei Infrastruktur (Hosting, Modell-Inferenz) bewusst auf bestehende Bausteine stützt.

Vier Gründe, die sich am Code festmachen lassen

1. Kontext-Kontinuität über Sitzungen und Kanäle hinweg

Chat-Tools wie ein Standard-Claude- oder ChatGPT-Fenster sind an eine Sitzung gebunden. Sobald der Tab schließt, ist der Kontext weg — oder er liegt in einer Form vor, die der Nutzer nicht einsehen und nicht kuratieren kann.

wintermute löst das mit einem dreistufigen Gedächtnismodell:

  • Tages-Logs (memory/conversation/YYYY-MM-DD.md) — menschenlesbare, chronologische Aufzeichnung.
  • Kuratiertes Langzeitgedächtnis (memory/longterm.md) — manuell gepflegt, wird in jeden System-Prompt injiziert.
  • Semantisches Gedächtnis (Qdrant, lokal betrieben, ~100 MB RAM) — automatisch befüllt, abrufbar per Ähnlichkeitssuche, nicht per Stichwort.

Der Agent ist zudem nicht an einen Kanal gebunden: Dieselbe Identität, dasselbe Gedächtnis ist über Telegram und (geplant) WhatsApp ansprechbar. Das ist mit einem gehosteten Einzel-Interface strukturell nicht abbildbar.

2. Unabhängigkeit vom Modell-Anbieter

Über LiteLLM lassen sich Modelle für unterschiedliche Aufgaben-Slots (Default, "Thinking"-Modus, "Fast"-Modus) austauschen — Anthropic Claude, Moonshot Kimi, OpenAI, oder ein lokal über Ollama betriebenes Modell, gesteuert über Umgebungsvariablen. Wer ausschließlich ein einzelnes kommerzielles Tool nutzt, hat implizit eine Entscheidung über Preis, Rate-Limits und Produkt-Roadmap eines einzelnen Anbieters mitgetroffen — ohne sie bewusst getroffen zu haben. Das rächt sich zuverlässig genau dann, wenn der Anbieter am Montagmorgen ein neues Preismodell verkündet und man selbst am Montagnachmittag noch dringend etwas ausliefern wollte.

3. Selbst definierte Vertrauensgrenzen

Ein zentrales, dokumentiertes Sicherheitsproblem bei Agenten mit Werkzeugzugriff ist: Wer verhindert, dass der Agent seine eigenen Betriebsregeln überschreibt? Bei wintermute wurde dieses Problem explizit adressiert (siehe Issue #68): Die "Standing Instructions" liegen in einer YAML-Datei, die vom Host aus read-only in den Container gemountet wird. Der Agent kann sie lesen, aber nicht verändern — eine Eigenschaft, die man bei einem Blackbox-Produkt nicht selbst herstellen kann, weil man die Laufzeitumgebung nicht kontrolliert. Im Klartext sieht das im docker-compose.yml so aus:

# on the host, mounted READ-ONLY. The agent only reads it. Defaults to
# /dev/null so the line is valid until you point it at a real file.
- ${STANDING_INSTRUCTIONS_FILE_HOST:-/dev/null}:/run/config/standing-instructions.yaml:ro

Der Trick ist nicht das YAML selbst, sondern das :ro am Ende der Zeile. Kein Prompt der Welt, egal wie überzeugend formuliert, kann eine Datei beschreiben, die der Container gar nicht beschreiben darf. Wer diese Regel nur im System-Prompt formuliert ("bitte ändere deine eigenen Anweisungen nicht"), hat eine Bitte. Wer sie als Mount-Flag durchsetzt, hat eine Garantie.

Ein zweites Beispiel aus derselben Kategorie: Ursprünglich hatte wintermute direkten Zugriff auf Docker-Socket und SSH-Schlüssel, um sich selbst zu aktualisieren — eine große Angriffsfläche für Prompt-Injection. Die Lösung (dokumentiert als Lesson #9) war die Auslagerung dieser Fähigkeit in einen separaten, unprivilegierten Host-Service mit HMAC-Authentifizierung. Der Agent selbst hat danach keinerlei privilegierten Zugriff mehr — er kann nur einen HTTP-Endpunkt aufrufen. Das ist eine architektonische Entscheidung, die nur trifft, wer die gesamte Laufzeitumgebung selbst gestaltet.

Der Token-Vergleich in diesem Updater-Service ist ein gutes Beispiel dafür, wo man leicht etwas falsch macht, ohne es zu merken:

def verify(self, presented: str) -> bool:
    """Constant-time comparison of presented token vs. configured token.

    Returns False if either side is empty (i.e. fail closed when the
    token file is missing).
    """
    if not self._token or not presented:
        return False
    return hmac.compare_digest(self._token, presented)

Zwei Dinge, die hier bewusst NICHT passieren: Erstens wird nicht mit presented == self._token verglichen — ein simpler ==-Vergleich auf Strings bricht bei der ersten abweichenden Stelle ab, und diese minimale Zeitdifferenz lässt sich per Timing-Angriff ausnutzen, um das Token Zeichen für Zeichen zu erraten. hmac.compare_digest vergleicht in konstanter Zeit. Zweitens: Ist die Token-Datei leer oder fehlt sie, wird verweigert, nicht durchgelassen (fail closed). Beides sind die Art Details, die in einem Hobby-Skript für gewöhnlich fehlen — und die genau dann wehtun, wenn ein System öffentlich erreichbar ist.

4. Ein anderer Fall: Prozess-Orchestrierung statt Einzelagent

Bei agenticframework liegt die Motivation nochmal anders. Hier geht es nicht um einen einzelnen, personalisierten Assistenten, sondern um eine mehrstufige Pipeline aus spezialisierten Agenten — von der Anforderungsklärung (Agent "Ada") über Architektur (Agent "Daedalus") und Zerlegung in atomare Tickets (Agent "Tess") bis zu parallelen Qualitäts-Gates für Stil/Tests und Sicherheit (Agenten "Argus" und "Molly", deren Sicherheits-Veto nicht durch menschliche Freigabe übersteuerbar ist).

Das ist strukturell etwas anderes als "ein Coding-Agent in einem Repository". Es ist eine Prozesslogik mit typisierten Übergabedokumenten zwischen den Phasen, einem gerichteten Abhängigkeitsgraphen für die Ticket-Reihenfolge und einem vollständigen, versionierten Audit-Trail (Run-Manifest plus append-only Event-Log) für jeden Durchlauf. Ein fertiges Coding-Assistenz-Tool bildet diese Organisationslogik nicht ab, weil es für einen anderen Anwendungsfall gebaut wurde: einen Entwickler, der an einem Repository arbeitet — nicht einen Prozess, der über mehrere Rollen und Freigabe-Punkte hinweg nachvollziehbar sein muss.

Der notwendige Gegenbeweis: Wann Eigenbau sich NICHT lohnt

Glaubwürdigkeit entsteht nicht durch die Behauptung, Eigenbau sei immer richtig, sondern durch den dokumentierten Fall, in dem er es nicht war. wintermute hatte testweise die Fähigkeit, Änderungen am eigenen Code vorzuschlagen (Self-Modification). Klingt nach Science-Fiction, war aber vor allem eines: anstrengend. Das Ergebnis, festgehalten als Lesson #25 im Lessons-Log vom 6. Mai 2026: zu viele halluzinierte Commits, ein Aufwand an externer Prüfung pro Interaktion, der in keinem Verhältnis zum Nutzen stand. Ein Agent, der sich selbst umbaut und dabei Dinge erfindet, die es nie gab, ist kein Fortschritt — das ist ein Praktikant mit Root-Zugriff und Selbstvertrauen. Die Funktion wurde vollständig abgeschaltet — und durch einen bescheideneren Mechanismus ersetzt: Der Agent kann bei Unsicherheit ein GitHub-Issue eröffnen und die Entscheidung an einen Menschen oder ein Tool mit besseren Schreibrechten weiterreichen.

Interessant ist dabei nicht die Abschaltung selbst, sondern wo sie durchgesetzt wird. Es wäre einfach gewesen, das nur in den System-Prompt zu schreiben ("verändere nicht deinen eigenen Code"). Stattdessen sitzt die Regel im Tool-Layer, als eigene Guard-Funktion, die vor jedem schreibenden GitHub-Call läuft:

async def _self_repo_guard(
    cfg: GitHubConfig, gh: _GitHub, repo: str, op: str
) -> dict[str, Any] | None:
    """Refuse all code-modifying writes targeting ``self_repo``."""
    if not cfg.self_repo or repo != cfg.self_repo:
        return None
    return _err(
        f"refused: {repo!r} is the configured self-repo. Self-modification "
        f"is disabled (gh_{op} write path). Wintermute does not produce "
        f"code changes against his own source any more...",
        "self_repo_guard",
    )

Der Unterschied klingt pedantisch, ist aber der ganze Punkt: Ein Prompt-Verbot übersteht keinen gut formulierten Jailbreak-Versuch. Eine Funktion, die vor jedem put_file/create_branch/open_pr-Aufruf prüft, ob das Ziel-Repo das konfigurierte self_repo ist, und im Zweifel schlicht mit einer strukturierten Fehlermeldung abbricht, übersteht ihn. Das Modell kann sich noch so überzeugend selbst überreden — der Tool-Call kommt nie durch.

Das ist der eigentliche Kernpunkt dieses ersten Artikels: Die Entscheidung für Eigenbau ist keine grundsätzliche Haltung, sondern eine laufende Kosten-Nutzen-Abwägung, die je nach Fähigkeit unterschiedlich ausfallen kann — und die man nur treffen kann, wenn man die Komponenten versteht und kontrolliert, die man einsetzt.

Fazit und Ausblick

Die Entscheidung für einen eigenen Agenten ist in beiden Projekten keine Ablehnung bestehender Werkzeuge, sondern eine bewusste Trennung: Modell-Inferenz und Hosting werden von bestehenden, spezialisierten Anbietern bezogen (Anthropic, Moonshot, OpenClaw-Infrastruktur); Gedächtnis, Vertrauensgrenzen und Prozess-Orchestrierung werden selbst kontrolliert, weil genau dort die eigentlichen Anforderungen liegen, die generische Produkte nicht adressieren.

Das ist auch der Grund, warum das hier kein Einzelartikel ist, sondern der Auftakt einer Serie. Wer einmal anfängt, die eigene Infrastruktur zu hinterfragen, hört bei "warum überhaupt selbst bauen" nicht auf — es folgen unweigerlich Fragen wie "und wem gehört dann eigentlich, was dabei rauskommt", "was mache ich, wenn das Ding halluziniert, während ich schlafe" und "wo genau höre ich auf, dem Agenten zu vertrauen". Genau diese Fragen ziehen sich durch die kommenden Teile:

  • Als Nächstes: digitale Souveränität — wem Kontext, Code und Entscheidungslogik eigentlich gehören, wenn man KI-Agenten produktiv einsetzt. Spoiler: die Antwort hat weniger mit Technik zu tun als man denkt, und mehr damit, wer am Ende die Rechnung und die Verantwortung trägt.
  • Danach: Sicherheit — wie man verhindert, dass ein autonomer Agent mehr darf, als ihm guttut (und was passiert, wenn man das zu spät merkt).
  • Und: Halluzinationen — was man tut, wenn der Agent selbstbewusst Dinge behauptet, die schlicht nicht wahr sind. Kleiner Vorgeschmack: es hilft, ihm dabei zuzusehen.

Insgesamt sind sieben weitere Teile geplant, jeweils an einer echten Lesson aus einem der beiden Repos aufgehängt — keine Theorie, sondern Dinge, die tatsächlich kaputtgegangen sind und dann repariert wurden.

Quellen: wintermute/README.md, wintermute/LESSONS.md (Lesson #9, #18, #25), wintermute/docs/GITHUB-TOOLS.md, wintermute/agent/pyproject.toml; agenticframework-Architekturdokumentation (6-Phasen-Modell, Agenten Ada/Daedalus/Tess/Seldon/Case/Argus/Molly/Turing/Forge).