Werkstatt · Kapitel 1 · 30. Juli 2026

Warum ein eigener Agent?

TL;DR: Kommerzielle Assistenten (ChatGPT, Claude.ai, Gemini) sind bequem, aber du leihst sie nur. Eigener Agent heißt: deine Daten, deine Werkzeuge, dein Modell-Stack, deine Memory-Hoheit — bezahlt mit Wartungs- und Betriebsaufwand. Dieses Kapitel klärt die ehrliche Trade-off-Rechnung.

Das Problem

Frag dich: Wo läuft dein aktueller Lieblings-Assistent? Wo liegen die Gespräche? Wer entscheidet, welches Modell deine Anfrage beantwortet? Wer entscheidet, wann der Anbieter dein Memory zurücksetzt oder eine neue Politik einführt?

Bei kommerziellen Assistenten ist die Antwort jedes Mal dieselbe: nicht du.

Das ist nicht zwingend ein Problem. Für viele Aufgaben — eine Mail formulieren, eine Reisefrage beantworten, ein Stück Code debuggen — ist die fremde Hoheit egal. Die Daten sind harmlos, der Modellwechsel betrifft dich nicht, und die Bequemlichkeit einer fertigen App schlägt jeden Selbstbau.

Es wird zum Problem, sobald drei Dinge gleichzeitig zutreffen:

  1. Die Daten sind sensibel oder privat. Kalender, Tagebuch, Finanzen, Gesundheits-Notizen, Quellcode mit Geschäftslogik.
  2. Du willst Kontinuität über Monate oder Jahre. Ein Assistent, der dich kennt, der gestern weiß und morgen noch weiß.
  3. Du willst Werkzeuge anbinden, die kein Anbieter für dich integriert. Deinen Mailserver, dein Smart Home, dein Wiki, deine eigene Code-Basis.

Sobald diese drei zusammenkommen, ist „ChatGPT mit Custom GPTs" zu wenig: du gibst sensible Daten an einen Dritten, das Memory ist nicht deins, und die Tool-Anbindung endet dort, wo der Anbieter sie freigibt.

Konsequenz: Wer das langfristig will, kommt um einen selbstbetriebenen Agenten nicht herum. Nicht weil er „besser" ist — sondern weil er anders positioniert ist.

Unsere Lösung

Wintermute löst das durch eine klare Trennung:

  • Modell-Anbieter sind austauschbar. Über LiteLLM kann derselbe Agent gegen Anthropic, OpenAI, lokale Ollama-Modelle oder Moonshot/Kimi laufen. Anbieter-Wechsel ist eine Konfig-Zeile, kein Architektur-Bruch — bis hin zum One-Shot-Wechsel pro Nachricht: /think und /fast schalten auf konfigurierte Alternativ-Modelle, /local routet einen einzelnen Turn auf einen lokalen Ollama-Server (z.B. eine eigene GPU-Maschine im Tailscale-Netz). Details: Kapitel 06.
  • Memory liegt bei dir. Tägliche Logs als lesbare Markdown- Dateien, langfristiges Wissen in einer lokalen Vektor-Datenbank (Qdrant). Beides versionierbar, sicherbar, durchsuchbar — auf deiner Hardware. Details: Kapitel 04.
  • Werkzeuge sind explizit. Über das MCP-Protokoll (Model Context Protocol) bekommt der Agent Zugriff auf Dateisystem, E-Mail, GitHub, Web-Suche, eigene Datenbanken — aber nur auf das, was du ihm in der Gateway-Konfiguration freigibst. Auch deine Host-Projekte kann er lesen, aber nur über explizit read-only eingebundene Verzeichnisse. Details: Kapitel 05.
  • Du bleibst Eigentümer der Persönlichkeit. Der System Prompt ist Code in deinem Repository. Du entscheidest, wie der Agent klingt, was er weigert, was er priorisiert. Dazu kommen Standing Instructions: eine YAML-Datei mit Dauer-Aufträgen, die du von Hand pflegst und die der Agent nur lesen kann, nie schreiben. Details: Kapitel 03.

Das Ergebnis ist kein „besseres ChatGPT". Es ist eine andere Kategorie Werkzeug: weniger Politur, mehr Hoheit.

Trade-offs & offene Fragen

Sei ehrlich zu dir, bevor du anfängst. Die folgenden Punkte sind keine Hindernisse — aber sie sind real:

  • Wartungslast. Du bist Operator. Updates, Backups, TLS-Zertifikate, Modell-Migrationen — das macht keiner für dich. Plane mit ein paar Stunden pro Monat im stabilen Zustand, deutlich mehr in den ersten Wochen.
  • Keine kommerzielle Politur. Kein Mobile-App-Studio, keine teamübergreifende Kollaboration mit fertigen Berechtigungs-Rollen, kein 24/7-Support. Was du nicht baust, hast du nicht.
  • Modell-Kosten bleiben. „Eigener Agent" heißt nicht „kostenlos". Du betreibst zwar die Anwendungsschicht selbst, aber die meisten ernstzunehmenden Modelle laufen weiterhin bei Anthropic, OpenAI oder Moonshot — und kosten pro Token. Vollständig lokale Modelle (über Ollama) sind möglich, aber qualitativ noch nicht auf Frontier-Niveau.
  • Halluzinationen sind weiterhin dein Problem. Eigener Stack bedeutet nicht „weniger Halluzinationen". Im Gegenteil: ohne den Schutz fertiger Produkt-Guardrails musst du selbst Verteidigungslinien einziehen. Kapitel 07 ist diesem Thema komplett gewidmet.
  • Sicherheit ist Eigenverantwortung — und nie fertig. Tokens, SSH-Schlüssel, Tool-Berechtigungen: wenn du nicht weißt, was ein Container mit Docker-Socket-Zugriff für Implikationen hat, dann ist das eine Lücke, die du füllen musst. Wintermute selbst lief anfangs mit einem privilegierten Gateway-Container (Docker-Socket, SSH-Key im Container) und hat das erst in einer eigenen Hardening-Welle abgebaut: host-seitiger Updater statt Selbst-Update im Container, SSRF-Schutz im web_fetch-Tool, gehärtete IMAP- und Auth-Pfade. Rechne damit, dass du solche Runden auch drehst.

Faustregel: Eigener Agent lohnt sich, wenn du den Agenten täglich benutzt und entweder die Daten oder die Workflows nirgendwo sonst sinnvoll abbildbar sind. Für gelegentliche Nutzung bist du mit der kommerziellen Variante besser bedient.

🔧 Tech-Vertiefung

Hardware-Anforderungen (Wintermute-Erfahrungswerte)

Wintermute selbst — also Agent-Core, MCP-Gateway, Qdrant, Ollama-Embeddings (nicht Inferenz) — läuft auf einem kleinen Hetzner-Server (~8 GB RAM, 2 vCPU) ohne Probleme. RAM-Verbrauch im Standby:

  • Agent-Core (Python/FastAPI): ~150 MB
  • MCP-Gateway (Python/FastAPI): ~120 MB
  • Qdrant (Rust, ~100k Vectors): ~100 MB
  • Ollama-Embedding-Server (nomic-embed-text, 768-dim): ~270 MB on-disk, ~400 MB im RAM während Embedding
  • Telegram-Bot-Adapter: ~80 MB

Summe: knapp ~1 GB Steady-State. Spitzen bei Tool-Aufrufen und LLM-Calls bleiben unter 2 GB.

Lokale Inferenz

Wenn du auch das LLM selbst self-hosten willst, verdoppelt sich die Hardware-Anforderung schlagartig:

  • 7B-Modelle (Mistral, Llama-3-8B): mindestens 16 GB RAM, besser mit GPU mit 8+ GB VRAM
  • 70B-Modelle: 64+ GB RAM oder Profi-GPUs
  • Frontier-Klasse (Opus/GPT-4o-Klasse) ist Stand 2026 lokal realistisch nicht erreichbar

Wintermutes pragmatischer Kompromiss: lokal embedden, remote inferieren. Das hält die Hardware klein und die Modell-Qualität hoch. Trade-off: pro-Token-Kosten bleiben.

Es gibt inzwischen eine dritte Option zwischen „alles remote" und „GPU im Server": eine vorhandene Maschine mit GPU (z.B. dein Desktop zu Hause) über ein privates Netz wie Tailscale erreichbar machen und per OLLAMA_API_BASE + LOCAL_MODELS als Alias registrieren. /local <alias> <nachricht> schickt dann einzelne Turns dorthin — sensible Fragen lokal, der Rest beim Frontier-Modell.

Pricing-Vergleich (Stand 2026, grobe Hausnummern)

Bei „Wintermute-typischer" Nutzung — ein einzelner Nutzer, viele kurze bis mittlere Chat-Turns, ca. 1-3 Mio Input-Tokens und ca. 100-300k Output-Tokens pro Monat:

Variante Monatskosten (grob)
Claude Pro (claude.ai) ~20 USD, kein API-Zugriff
Anthropic API mit Opus ~30-80 USD je nach Tool-Use-Intensität
Lokal-only (Llama-3 70B auf eigener GPU) ~0 USD an API + Strom + Hardware-Abschreibung
Hetzner-VPS für Wintermute-Backend ~10-15 EUR

Die Wintermute-typische Kombi (kleiner VPS + Anthropic-API) landet meist bei 30-60 EUR/Monat — vergleichbar mit Claude Pro, dafür mit voller Hoheit über Daten, Memory und Tool-Anbindung.

Wann du nicht selbst bauen solltest

  • Du bist allein auf einem Mac/Laptop ohne Server-Lust und brauchst den Agent nur stundenweise. → ChatGPT oder Claude.ai sind effizienter pro Stunde deiner Zeit.
  • Du brauchst Multi-User mit echtem RBAC und Audit-Logs. → Wintermute ist Single-User-Architektur. Multi-User-Support ist offen (siehe Kapitel 09).
  • Du willst Voice / Realtime / Bilderzeugung als Erstklassen-Features. → Wintermute ist text-zentriert mit Tool-Aufruf. Voice ist via externe Adapter möglich, aber kein Schwerpunkt.

📚 Quellen im Wintermute-Repo

  • README.md — Wintermutes eigene Positionierung, Architektur-Bild, Stack
  • MEMORY.md — Memory-Hoheit als Differenzierungsmerkmal, drei-Schicht- Modell (Daily-Markdown / Long-term-Markdown / Qdrant)
  • MODELS.md — Multi-Provider-Architektur, LiteLLM-Integration, /local-Aliase
  • docs/SECURITY.md — Trust-Modell und Threat-Model für selbstgehostete Agenten
  • docs/UPDATER.md — die Hardening-Migration weg vom privilegierten Gateway-Container