So baust Du Deinen Persönlichen KI-Assistenten Schritt für Schritt mit Claude Code, MCP und einem Telegram-Bot (Tutorial 2026)

Vom Kiwop-Team · Digitalagentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz für globale Kunden in Europa und den USA · Veröffentlicht am 19. April 2026 · Zuletzt aktualisiert: 19. April 2026

TL;DR — Schritt-für-Schritt-Tutorial, um Deinen Persönlichen KI-Assistenten auf Claude Code MCP als Basis-Stack aufzubauen: vier Kanäle (IMAP, Gmail, Slack, Telegram), automatische Briefings um 08:00 und 19:00 Uhr, bidirektionaler Bot und Slash-Befehle. Rund 500 Zeilen Python, null kostenpflichtige Abhängigkeiten jenseits des Claude Max x20-Abonnements. Komplettes Setup in 60-90 Minuten nach den Schritten.

Dies ist der zweite Artikel der Serie über den PA von Kiwop. Der erste, Von OpenClaw zu PA mit Claude Code und MCP, erklärt, warum wir ihn nach der Policy-Änderung von Anthropic vom 4. April 2026 gebaut haben. Dieses Tutorial zeigt, wie wir ihn gebaut haben, mit dem echten Code, den wir seit zwei Wochen in Produktion haben. Am Ende hast Du einen funktionsfähigen Persönlichen KI-Assistenten auf Deiner Maschine, mit derselben Architektur, die wir täglich in der Agentur nutzen. Das Referenz-Repository liegt unter https://github.com/purroy/majordomo.

Es ist keine Spielzeug-Demo. Er verarbeitet Produktions-E-Mails, echte Termine, Telegram-Nachrichten vom Mobilgerät und Briefings, die um 08:00 und 19:00 Uhr ohne menschliches Eingreifen landen. Die Philosophie ist absichtlich minimalistisch: Jedes Stück tut eine Sache, der Klebstoff zwischen den Teilen ist Unix, und die Secrets berühren die Festplatte niemals im Klartext.

Was Du bauen wirst

Am Ende des Tutorials hat Dein PA vier aktive Kanäle und eine bewusst einfache Architektur.

Die vier aktiven Kanäle des PA sind:

• Eigene IMAP/SMTP-E-Mail: für das Firmenpostfach Deiner Domäne (mail.deinefirma.com), gelesen mit Python-Skripten über die Python-Standardbibliothek. Lesen, Triage, Verfassen und Senden mit expliziter Bestätigung.
• Google Workspace (Gmail + Calendar + Drive): über die offiziellen MCP Server — Du kannst weitere ähnliche wie Outlook/Microsoft 365 hinzufügen, wenn Deine Organisation sie nutzt.
• Slack: DMs und Erwähnungen, über den offiziellen Slack-MCP-Server für Claude.
• Telegram: ein bidirektionaler Bot, der gleichzeitig Ausgangskanal (Briefings) und Eingangskanal (Du sprichst vom Mobilgerät aus mit dem PA) ist.

Der technische Stack besteht aus vier Schichten. Claude Code als dialogorientierter Motor. MCP-Konnektoren für alles, wofür es einen offiziellen gibt (Google + Slack). Eigene Python-Skripte für die Lücken, die MCP nicht abdeckt (IMAP und Telegram). Und launchd (unter macOS) oder systemd/Task Scheduler (unter Linux/Windows) für den Start und die geplanten Trigger.

Die tatsächlichen Grenzkosten sind null auf das Claude Max x20-Abonnement, das Du bereits für die Entwicklung zahlst. Die ~500 Zeilen Python gehören Dir — keine installierbaren Abhängigkeiten, nur Standardbibliothek. Kein Backend, keine Datenbank, kein Docker. Der gesamte persistente Zustand lebt in lokalen Dateien und im Keychain des Betriebssystems.

Auf hoher Ebene folgt die Architektur drei Prinzipien, die es sich lohnt, explizit zu machen, bevor wir uns in den Code vertiefen. Das erste ist, dass Claude Code der Motor ist, aber nicht der Besitzer des Zustands: Deine Prompts liegen in versionierbaren Markdown-Dateien in Deinem eigenen Repository, Deine Secrets liegen im Keychain des Systems, Deine Briefings sind Dateien auf der Festplatte. Wenn Du morgen den Motor wechseln wolltest, müsstest Du nur die Aufrufe von claude --print durch eine andere äquivalente CLI ersetzen. Das zweite ist, dass MCP die Schwerarbeit erledigt, wenn ein offizieller Server existiert (Google, Slack), und Du nur dann Code schreibst, wenn keiner existiert (IMAP, Telegram). Das dritte ist, dass die Sicherheit in drei unabhängigen Schichten lebt — OAuth des MCP, Keychain von macOS und Bestätigungsregel in Prompts — sodass die Kompromittierung einer Schicht nicht das System kompromittiert.

Voraussetzungen und tatsächliche Kosten

Bevor Du anfängst, prüfe, ob Du hast, was nötig ist. Das Tutorial geht von macOS aus, weil wir es verwenden, aber am Ende gibt es einen Abschnitt darüber, wie man es auf Linux oder Windows portiert.

Konto- und Abonnement-Anforderungen:

• Claude Max x20 von Anthropic: das "for power users"-Abonnement, etwa 200 USD/Monat. Claude Code ist inbegriffen und ist der Motor des PA.
• Google-Workspace-Konto mit Berechtigungen zum Autorisieren von Gmail, Calendar und Drive via OAuth.
• Slack-Workspace, in dem Du ein Konto hast (Du musst kein Admin sein für den MCP zum Lesen Deiner eigenen DMs und Erwähnungen).
• Eine E-Mail-Domäne über IMAP, wenn Dein Hauptpostfach nicht Gmail ist (optional — wenn Deine gesamte E-Mail Gmail ist, überspringe Schritt 3).
• Telegram-Konto (kostenlos) zum Erstellen des Bots über @BotFather.

Systemanforderungen:

• macOS 14+ mit installiertem Homebrew (für den Basisfluss des Tutorials).
• Python 3.11+ (kommt mit aktuellem macOS; sonst brew install [email protected]).
• Claude Code CLI installiert: npm i -g @anthropic-ai/claude-code oder via brew.
• Terminal mit Full Disk Access-Berechtigungen, wenn Du möchtest, dass launchd die Briefings ausführen kann, ohne wiederholt Autorisierung anzufordern.

Projizierte monatliche Kosten, ehrliche Aufschlüsselung:

Der entscheidende Punkt: Die Grenzkosten des PA sind null, wenn Du bereits Claude Max hast. Wenn Du es nicht hast und es nur für den PA kaufen würdest, ändert sich die Rechnung — Du müsstest abwägen, ob die Zeitersparnis Dir 200 USD/Monat wert ist. Für jeden, der bereits Claude Code in der Entwicklung nutzt, ist die Antwort meist trivialerweise ja.

Die geschätzte Zeit, um das Tutorial von null abzuschließen, einschließlich OAuth und unvermeidlichem Debugging, beträgt 60 bis 90 Minuten. Wenn Du nur die ersten drei Kanäle willst (ohne Telegram oder geplante Briefings), sinkst Du auf 30-40 Minuten.

Schritt 1: Basisstruktur des Projekts

Der PA lebt in einem eigenen Verzeichnis außerhalb jedes anderen Projekts. Die erste Entscheidung ist, wo er platziert wird. Wir verwenden konventionell ~/Dev/PA — ersetze es, wenn Du einen anderen Pfad bevorzugst. Das vollständige Referenz-Repository liegt unter https://github.com/purroy/majordomo — nutze es, wenn Du Dich in einem Schritt verlierst.

Die .gitignore muss alles mit persönlichen Daten ausschließen — Briefings, E-Mail-Entwürfe, Bot-Zustand:

Nun die wichtigste Datei des Repositorys: CLAUDE.md. Sie definiert die Persona des Assistenten, die Standardsprache und die Bestätigungsregel, die das Herz der PA-Sicherheit ist.

Die Bestätigungsregel ist nicht verhandelbar. Sie unterscheidet einen PA, den Du einem Sprachmodell überlassen kannst, von einem, der Dir eine peinliche E-Mail schickt, wenn er ein "ja" von vor zwei Zügen falsch interpretiert. Wir haben sie den gesamten März ohne einen einzigen Falsch-Positiv getestet.

Erster Commit:

Schritt 2: MCP Servers verbinden

MCP ([Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25)) ist der offene Standard, den Anthropic Ende 2024 veröffentlicht hat, damit Sprachmodelle sich einheitlich mit externen Werkzeugen verbinden können. Ein MCP Server ist ein Prozess, der eine Reihe von Funktionen (E-Mails lesen, Dateien suchen, Nachrichten senden) über ein gemeinsames Protokoll bereitstellt; ein MCP Client (wie Claude Code) startet ihn und konsumiert diese Funktionen, als wären es eigene Werkzeuge. Wenn Du tiefer verstehen möchtest, warum MCP das Stück ist, das die KI-Agenten 2026 freischaltet, haben wir eine umfassendere Analyse in WebMCP: Deine Website bereit für KI-Agenten.

Für den PA aktivieren wir vier offizielle MCP Servers, alle vier von Anthropic/Claude oder den Anbietern selbst veröffentlicht:

• Gmail MCP: Lesen, Suchen und Verfassen von E-Mails.
• Google Calendar MCP: Agenda, Erstellen und Ändern von Events.
• Google Drive MCP: Suchen und Lesen von Dateien.
• Slack MCP: Lesen von DMs, Kanälen und Senden mit Bestätigung.

Der einfachste Weg, sie zu konfigurieren, ist über die Oberfläche von Claude Code. Starte vom Projekt-Root (~/Dev/PA):

Innerhalb der interaktiven Sitzung von Claude Code füge die MCP Servers mit dem Befehl /mcp add für jeden hinzu. Der Befehl startet den entsprechenden OAuth-Fluss im Browser — autorisiere mit dem Konto, das der PA verwenden soll, nicht notwendigerweise Dein persönliches Hauptkonto.

Sicherheit des OAuth-Flusses. Ein entscheidender Aspekt: Die offiziellen MCP Servers nutzen OAuth des Browsers, keine Credentials auf der Festplatte. Dein refresh_token wird vom MCP Server in eigenen verschlüsselten Speichern aufbewahrt, nicht vom PA. Das bedeutet, dass jemand, der Dein .claude/ oder Dein Repository stiehlt, keinen Zugriff auf Dein Gmail erhält — er müsste zusätzlich den Speicher des MCP Servers und letztlich Deinen macOS-Keychain kompromittieren. Die Angriffsfläche bleibt eingegrenzt.

Sobald die vier autorisiert sind, prüfe, ob Claude Code sie erkennt:

Du solltest die verfügbaren Tools gruppiert nach Dienst sehen: mcp__claude_ai_Gmail__search, mcp__claude_ai_Google_Calendar__list_events etc. Die Nomenklatur folgt dem Muster mcp__<server>__<tool>.

An diesem Punkt kannst Du den PA bereits fragen "Was habe ich heute im Kalender?" oder "Suche in Drive den Vertrag mit Kunde X" und es funktioniert. Was fehlt, sind die beiden Kanäle, die MCP nicht gut abdeckt: die Unternehmens-IMAP-E-Mail und Telegram.

Schritt 3: Python-Skripte für IMAP und Keychain

Wenn Deine gesamte E-Mail in Gmail liegt, ist dieser Schritt optional. Wenn, wie bei uns, das Hauptpostfach über einen eigenen IMAP-Server läuft (mail.kiwop.com in unserem Fall), ist es Zeit, die Brücke zu schreiben.

Die Architektur der Skripte ist bewusst klein. Ein internes Modul _mail.py mit der gemeinsamen Logik (IMAP-Verbindung, Parsing, SMTP) und drei minimalen Befehlen, die der PA aufrufen kann:

• mail_fetch.py: listet aktuelle oder ungelesene UIDs als JSON.
• mail_read.py: liest den vollständigen Body einer UID (ohne sie als gelesen zu markieren — verwendet BODY.PEEK).
• mail_send.py: sendet eine E-Mail oder speichert sie als Entwurf.

Goldene Regel zu Credentials. Speichere das IMAP-Passwort niemals in einer Repo-Datei oder in einer persistenten Umgebungsvariable wie ~/.zshrc. Das Risiko ist nicht theoretisch: Jedes Mal, wenn Du ein Skript teilst, einen Commit mit getracktem .env machst oder eine VS-Code-Erweiterung installierst, die Deine Umgebung liest, legst Du Secrets offen. Auf macOS haben wir Keychain, einen verschlüsselten Keychain des Betriebssystems, der über den Befehl security zugänglich ist. Die Skripte lesen die Credential im Moment, wenn sie sie brauchen, und schreiben sie niemals auf die Festplatte.

Zuerst speichere die Credentials in Keychain:

Die üblichen Ports: 993 für IMAP über SSL und 587 für SMTP mit STARTTLS. Wenn Dein Anbieter implizites SMTPS verwendet, wechsle zu 465.

Nun das Shell-Helper, das in Keychain liest und schreibt. Wir nennen es scripts/keychain.sh:

Das Python-Äquivalent verwendet subprocess, um security aufzurufen:

Der Fallback auf Umgebungsvariablen ist bewusst: Wenn Du das auf Linux (systemd) portierst, existiert dort security nicht und Du verwendest Env-Vars, die aus der Unit-Datei exportiert werden, gelesen aus einer Datei mit Berechtigungen 600.

Mit verbundenem Keychain wird mail_fetch.py klar. Es ist ein CLI, das JSON ausgibt, damit Claude Code es leicht parsen kann:

mail_send.py fügt eine wichtige Schutzmaßnahme hinzu: Ohne das Flag --yes speichert es die Nachricht als .eml in drafts/ und sendet sie nicht. Nur mit explizitem --yes geht sie über SMTP raus. Das wendet die Bestätigungsregel des CLAUDE.md auf Code-Ebene an, nicht nur im Prompt — selbst wenn das Modell die Regel überspringen würde, würde das Skript nicht senden.

Kritisches Detail zu `BODY.PEEK`. Wenn der PA eine E-Mail "liest", um sie zu triagieren, darf er sie nicht als gelesen markieren. Wenn Du sie markierst, verlierst Du Deinen Pendenzen-Posteingang als visuelles Signal im E-Mail-Client. Das IMAP-Flag, das \Seen setzt, ist BODY[]; das, welches es nicht setzt, ist BODY.PEEK[]. Verwende es immer in mail_read.py.

Schritt 4: Telegram-Bot mit persistenter Sitzung

Der Telegram-Bot ist das interessanteste Stück des PA, weil es den Fluss umdreht: Statt dass Du ein Terminal öffnest und an Claude schreibst, empfängt Claude Deine Nachrichten vom Mobilgerät.

Der Plan: ein Python-Daemon, der long polling gegen die Telegram-API macht (ohne Bedarf an öffentlichem Webhook), und jede empfangene Nachricht an claude --print mit einer im PA-Repository ausgeführten Sitzung weiterleitet. Claude führt den Prompt mit all seinen Werkzeugen aus (MCP + Python-Skripte) und gibt die Antwort zurück. Der Daemon formatiert sie für Telegram und sendet sie an den Chat zurück.

Den Bot zu erstellen dauert zwei Minuten. Öffne Telegram, sprich mit @BotFather, starte /newbot, gib ihm einen Namen und einen Username. Er gibt Dir ein Token vom Typ 123456:ABC-XYZ_.... Speichere es in Keychain und ermittle dann Deine chat_id (die ID der 1-zu-1-Unterhaltung zwischen Dir und dem Bot):

Nun der Daemon. Das Skelett von telegram_bot.py sieht so aus:

Drei nicht offensichtliche Details des Designs.

Erstens, Whitelist der `chat_id`: Die Variable allowed_chat ist Dein eigener Chat, und jede Nachricht von einer anderen chat_id wird stillschweigend verworfen. Wenn jemand den Username Deines Bots entdeckt und ihm Nachrichten sendet, antwortet er ihm nicht. Es ist die einfachste, aber wirksamste Barriere gegen Missbrauch.

Zweitens, `--permission-mode bypassPermissions`: Der Daemon läuft, ohne um Bestätigung für die Ausführung von Repo-Skripten zu bitten, weil kein Mensch davorsitzt, der antworten könnte. Die Sicherheit kommt nicht von den Prompts von Claude Code, sondern davon, dass (a) der Daemon nur auf die whitelisted chat_id antwortet, (b) der PA die Bestätigungsregel in CLAUDE.md hat und (c) sensible Skripte wie mail_send.py auf Code-Ebene --yes verlangen.

Drittens, ephemere Sitzungen pro Nachricht. Jedes ask_claude generiert eine neue session-id mit uuid.uuid4(). Das bedeutet, dass der Bot zwischen Nachrichten kein Konversationsgedächtnis behält — jede Anfrage beginnt bei null mit Deinem CLAUDE.md und Deinen geladenen Befehlen. Das "Langzeit"-Gedächtnis (Deine Präferenzen, Signatur, priorisierten Kontakte) lebt in memory/ als Dateien, die Claude beim Start jeder Sitzung liest, nicht in der Sitzung selbst. Das vermeidet die Anhäufung veralteten Kontexts und macht das Verhalten sehr vorhersehbar.

Telegram-kompatibles Markdown. Telegram rendert kein Markdown im GitHub-Stil (es versteht keine Tabellen, versteht Links mit eckigen Klammern in vielen Kontexten nicht, interpretiert bestimmte Zeichen falsch). Statt mit parse_mode: MarkdownV2 zu kämpfen — das Dich zwingt, alle Sonderzeichen zu escapen und leicht kaputt geht — verwenden wir einen kleinen Konverter zu lesbarem Klartext (md_to_telegram.py), der die Markdown-Syntax entfernt, während die Struktur erhalten bleibt.

Um es vor launchd zu testen:

Öffne Telegram, schreibe /ping an Deinen Bot. Er sollte pong antworten. Sende dann "Wie spät ist es?" — er sollte Dir mit der aktuellen Uhrzeit antworten, indem er das System über eine Claude-Sitzung abfragt. Glückwunsch: Du hast jetzt einen PA, der vom Mobilgerät aus zugänglich ist.

Schritt 5: Geplante Briefings mit launchd

[`launchd`](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html) ist der Prozess- und Task-Scheduler von macOS. Er entspricht cron + systemd kombiniert in einem einzigen System. Jeder Task wird in einer XML-Datei (.plist) definiert, die macOS mitteilt, was auszuführen ist, wann und was zu tun ist, wenn es fehlschlägt.

Wir werden drei launchd jobs erstellen:

1. Telegram-Bot als permanenter Daemon (KeepAlive: true).
2. Morgen-Briefing jeden Tag um 08:00 Uhr.
3. Abend-Briefing jeden Tag um 19:00 Uhr.

Zuerst das Wrapper scripts/run_briefing.sh, das Claude Code im nicht-interaktiven Modus startet, um das Briefing zu generieren:

Nun die .plist des Morgen-Briefings. Speichere sie in scripts/launchd/com.kiwop.pa-briefing-morning.plist:

Wichtige Stelle: der explizite `PATH` in EnvironmentVariables. launchd erbt Deinen PATH nicht vom Shell, also ist claude nicht verfügbar, wenn Du ihn nicht übergibst, und das Briefing schlägt stillschweigend fehl. Füge /opt/homebrew/bin (Apple Silicon), /usr/local/bin (Intel) und ~/.local/bin (wenn Du Claude Code via pip --user installiert hast) ein.

Dupliziere die Datei für das Abend-Briefing, indem Du morning durch evening und die Stunde auf 19 änderst. Und erstelle die des Telegram-Bots:

Das Trio RunAtLoad: true + KeepAlive: true + ThrottleInterval: 15 bedeutet: Starte beim Login, starte bei Absturz neu und versuche nicht, schneller als alle 15 Sekunden neu zu starten (um Fehlschlag-Schleifen zu vermeiden).

Um die drei .plist zu aktivieren:

Zum Verifizieren, dass sie aktiv sind:

Du solltest die drei Einträge mit PID sehen (für den Bot, der kontinuierlich läuft) oder mit - (für die Briefings, die nur zu ihren Zeiten laufen).

Um ein Briefing manuell auszulösen, ohne auf 08:00 Uhr zu warten (nützlich zum Testen):

Schritt 6: Slash-Befehle /morning, /evening, /inbox, /reply

Die Slash-Befehle von Claude Code leben in .claude/commands/ als Markdown-Dateien. Jede Datei ist ein Prompt Template, das Claude ausführt, wenn Du /name in der Sitzung aufrufst. Sie sind die sauberste Art, wiederholte Flows zu kapseln, ohne denselben langen Prompt jedes Mal zu wiederholen.

Für den PA definieren wir vier minimale Befehle: /morning, /evening, /inbox, /reply. Dies ist das Beispiel von .claude/commands/morning.md:

Buenos días — <fecha>

Agenda de hoy

• HH:MM–HH:MM · Título · (lugar / asistentes)

Correo (N no leídos)

🔥 Fuego: [UID] Remitente — Asunto · contexto ⚠ Importante: [UID] ... Para revisar: [UID] ... Ruido: N items

Slack

🔥 ... ⚠ ...

Prioridades sugeridas

1. ...
2. ...
3. ...

Der Befehl /reply ist besonders wichtig, weil er die Bestätigungsregel anwendet:

Achte auf das Muster: Der Befehl erzwingt die Bestätigungsregel auf Prompt-Ebene (Schritt 5), und das Skript erzwingt die Regel auf Ausführungsebene (das obligatorische --yes in mail_send.py). Doppelte Schicht. Wenn das Modell Schritt 5 "vergisst", sendet das Skript nicht. Wenn jemand das Skript ändert, um --yes zu umgehen, verlangt der Prompt immer noch Bestätigung. Es ist dieselbe Philosophie der Verteidigung in der Tiefe, die wir in Projekten zur LLM-Integration für jede Aktion mit irreversiblen Effekten empfehlen.

Die vier Basis-Befehle reichen für 90% der täglichen Nutzung. Du kannst weitere hinzufügen: /schedule (Meetings erstellen), /book (von einer Einladung aus planen), /auth (Diagnose des Zustands der MCPs).

Schritt 7: Setup End-to-End testen

Mit allem montiert ist es Zeit für eine komplette Testrunde, bevor wir es als funktional einstufen. Dies ist die Checkliste, die wir bei Kiwop verwenden, jedes Mal wenn wir das Setup auf einer anderen Maschine replizieren:

1. MCPs authentifiziert. In einer Claude-Code-Sitzung aus ~/Dev/PA:

Die vier Server müssen mit verfügbaren Tools erscheinen. Wenn einer "not authenticated" sagt, wiederhole den OAuth.

2. Funktionale IMAP-E-Mail. Vom Terminal aus:

Sollte ein JSON mit Deinen drei aktuellsten ungelesenen E-Mails zurückgeben. Wenn es mit imaplib.IMAP4.error fehlschlägt, überprüfe Keychain und Ports.

3. Manuelles Briefing. Aus einer interaktiven Claude-Code-Sitzung:

Generiert ein komplettes Briefing. Sollte nicht länger als 60 Sekunden dauern.

4. Bidirektionaler Telegram-Bot. Von Telegram aus an Deinen Bot:

• /ping → pong (sofort)
• "Was habe ich heute im Kalender?" → Antwort mit der echten Agenda (30-40 Sekunden)

5. launchd-Logs ohne Fehler.

Die telegram_bot.err.log muss eine Zeile "Bot up. Allowed chat=..." enthalten. Wenn es ein FATAL: secret read failed gibt, überprüfe, ob Keychain die Items PA-telegram-bot-token und PA-telegram-chat-id enthält.

6. Kaltstart-Test des geplanten Briefings.

Sollte das Tages-Briefing generiert und eine Kopie an Dein Telegram geschoben haben. Wenn Telegram nichts empfängt, überprüfe die PA-telegram-*-Credentials in Keychain.

Häufige Probleme und wie man sie diagnostiziert:

Wenn er die sechs Punkte der Checkliste besteht, ist der PA bereit für den täglichen Einsatz. Ab hier geht es nur noch um Verfeinerung: memory/ mit Deinen Stilpräferenzen hinzufügen, weitere Slash-Befehle je nach erkannten wiederholten Flows hinzufügen, die Prompts von morning.md und evening.md an die genaue Ausgabe anpassen, die Dir am nützlichsten ist.

Praktischer Rat zu den ersten sieben Tagen. Nach dem Aufsetzen wird der PA suboptimale Dinge tun, bis Du entdeckst, was ihm an Kontext über Dich fehlt. Wir empfehlen, in der ersten Woche im "Nur-Lesen"-Modus anzufangen: Lass ihn Briefings generieren, lass ihn den Posteingang triagieren, aber verwende noch nicht /reply und bestätige keine Schreibaktionen. Während dieser Woche wirst Du Muster entdecken, die zu korrigieren sind — "klassifiziert die E-Mails dieses Kunden falsch, weil er nicht weiß, dass er VIP ist", "fasst kurze Slack-Nachrichten zu stark zusammen", "markiert als Rauschen Dinge, die für mich wichtig sind". All diese Korrekturen gehen in memory/triage_rules.md und ins CLAUDE.md. Ab Tag sieben oder acht, wenn die Triage bei 85-90% konsistent ist, kannst Du die Schreibnutzung mit /reply öffnen und beginnen, echte Zeit zu gewinnen. Diese Kalibrierungsphase zu überspringen ist der häufigste Fehler und die Hauptursache für Abbrüche in unserer Stichprobe von Personen, denen wir beim Aufbau geholfen haben.

Varianten und Skalierung: Linux, Windows und 24/7 betreiben

Das Tutorial ist auf macOS geschrieben, weil das unsere Arbeitsumgebung ist, aber die Architektur ist portabel. Die vier wichtigsten Anpassungen:

Prozessmanager.

Ein systemd-Unit für den Telegram-Bot unter Linux sähe ungefähr so aus (~/.config/systemd/user/pa-telegram.service):

Aktivierung: systemctl --user daemon-reload && systemctl --user enable --now pa-telegram.service.

Secret-Speicher.

Der Fallback auf Umgebungsvariablen in einer Datei mit Berechtigungen 600 funktioniert auf allen drei Plattformen und ist der gemeinsame Nenner, wenn Du einen einzigen Code für alle Systeme willst.

launchd vs systemd, ehrlicher Vergleich:

Ihn 24/7 auf einem Remote-Server laufen lassen? Es ist machbar und wir haben es getestet. Das Muster: ein kleiner Linux-VPS mit systemd, der den Telegram-Bot und die geplanten Briefings betreibt, plus eine IMAP/SMTP-Verbindung zum Postfach, plus das Claude Code CLI mit Deinem Anthropic-Konto authentifiziert. Vorteile: Der PA antwortet, auch wenn Dein Laptop aus ist. Nachteile: Der OAuth der MCP Server ist ohne lokalen Browser heikler (Du musst den initialen Fluss auf Deiner Maschine machen und den Refresh-Token kopieren), und jedes Update des Claude Code CLI erfordert SSH und Deployment. Für die meisten Fachleute, die den Mac täglich nutzen, ist ihn lokal zu behalten die Option mit dem besten Verhältnis Einfachheit/Nutzen.

Der Sprung zu einem Multi-User-PA (einer, der einem Team dient) ist keine Variante desselben Tutorials — es ist ein SaaS und erfordert sehr andere Architekturentscheidungen (Multi-Tenancy, Authentifizierung, Session-Isolation). Wenn Dich diese Route interessiert, behandeln wir sie in den Projekten zur maßgeschneiderten Entwicklung von KI-Agenten.

Zwei Erweiterungen, die wir in der Praxis funktionieren gesehen haben, wenn der Basis-PA bereits stabil ist. Die erste ist ein memory/ befüllt mit Markdown-Dateien, die Claude in jeder Sitzung lädt: ein triage_rules.md mit Deinen exakten Kriterien zur E-Mail-Klassifizierung, ein writing_style.md mit Beispielen von Dir geschriebener E-Mails, damit die Entwürfe nach Deiner Stimme klingen, ein vip_contacts.md mit den Adressen, die nie in "Rauschen" fallen dürfen. Die zweite ist ein Watcher für E-Mails im Hintergrund (ein ähnlicher Daemon wie der Telegram-Bot, aber statt Telegram zu überwachen, überwacht er Dein IMAP-Postfach), der eine Benachrichtigung auslöst, wenn eine E-Mail eintrifft, die nach Deinen Regeln als Feuer markiert ist — nützlich für Flows, in denen das 08:00-Uhr-Briefing nicht ausreicht. Beide Erweiterungen werden mit derselben Philosophie wie der Rest gebaut: kurze Skripte, Secrets in Keychain, ephemere Claude-Code-Sitzungen.

Häufig gestellte Fragen

Was kostet es wirklich, diesen PA zu bauen?

Wenn Du bereits Claude Max x20 hast (etwa 200 USD/Monat), sind die Grenzkosten des PA null. Die MCP Servers sind kostenlos, der Telegram-Bot läuft auf Deinem Mac ohne Hosting, und die Python-Skripte erfordern keine kostenpflichtigen Abhängigkeiten. Wenn Du Claude Max nicht hast, ändert sich die Rechnung: Die 200 USD/Monat sind die Fixinvestition. Die Bauzeit nach diesem Tutorial beträgt 60-90 Minuten.

Ist es sicher, einem so gebauten PA Zugriff auf meine E-Mail und meinen Kalender zu geben?

Ja, mit den folgenden expliziten Bedingungen. Erstens authentifizieren sich die offiziellen MCP Servers per OAuth, ohne Dein Passwort auf der Festplatte zu speichern — das Token lebt in einem verschlüsselten Speicher des MCP Servers selbst. Zweitens liegen die IMAP/SMTP-Credentials im macOS-Keychain (Keychain des Betriebssystems, verschlüsselt), niemals in Klartextdateien. Drittens antwortet der Telegram-Bot nur auf die whitelisted chat_id, und die obligatorische Bestätigungsregel in CLAUDE.md verhindert Schreibaktionen ohne explizites "ja". Die Angriffsfläche bleibt stark eingegrenzt, vergleichbar mit der jedes Desktop-E-Mail-Clients.

Was ist mit dem Datenschutz? Trainiert Anthropic mit meinen E-Mails?

Anthropic erklärt öffentlich (Policy Stand 2026), dass per API und per Claude Code gesendete Daten nicht zum Training von Modellen verwendet werden. Für regulierte Inhalte (Gesundheit, Recht mit Berufsgeheimnis, vertrauliche Finanzen) empfiehlt es sich, die aktuellen spezifischen Bedingungen zu überprüfen und zu erwägen, ob ein PA auf eigener Infrastruktur angemessener ist — in diesem Fall kann eine Lösung für Enterprise RAG die richtige Alternative sein.

Kann man WhatsApp in diesen PA integrieren?

Stand April 2026 gibt es keinen offiziellen WhatsApp-MCP. Es gibt inoffizielle Bridges (Matrix, Beeper, die eigene WhatsApp Business Cloud API von Meta), die als zusätzlicher Kanal verbunden werden können, aber alle haben Vorbehalte: Die inoffiziellen Bridges können die ToS von Meta verletzen und instabil sein, und die Business Cloud API erfordert ein verifiziertes gewerbliches Konto. Unsere pragmatische Empfehlung ist, Telegram als primären mobilen Kanal zu verwenden.

Kann dieser PA mehrere Nutzer bedienen?

Nein, per Design. Ein PA ist Single-User: Seine Credentials, sein Gedächtnis, seine Präferenzen und sein CLAUDE.md verweisen auf eine einzige Person. Für Multi-User-Szenarien (ein Team, das einen gemeinsamen Assistenten teilt) ist die korrekte Architektur ein multi-tenant SaaS mit Datenisolation pro Nutzer — keine Kopie des PA mit gemeinsamen Variablen. Es ist ein völlig anderes Gespräch.

Funktioniert er ohne Internetverbindung?

Nein. Claude Code benötigt eine Verbindung zum Abfragen des Modells, die MCP Servers nutzen Online-APIs (Google, Slack, Telegram), und IMAP/SMTP offensichtlich auch. Der hier beschriebene PA ist ein Client, der Cloud-Dienste orchestriert — kein lokales Modell. Wenn Du Offline-Betrieb brauchst, ist es ein komplettes Redesign mit einem lokalen LLM (Llama, Mistral), das auf ollama oder ähnlichem läuft, mit erheblichen Qualitäts- und Leistungseinschränkungen.

Wie lange braucht der PA, um sein erstes Morgen-Briefing zu liefern?

Das vollständige run_briefing.sh dauert zwischen 40 und 90 Sekunden, abhängig davon, wie viele E-Mails zu triagieren sind. Der langsamste Teil ist das IMAP-Fetch mit --with-body (eine Verbindung pro UID), gefolgt vom Modell-Reasoning über die Triage. Wenn Dein Posteingang sehr groß ist (>50 ungelesen), kann es auf 2-3 Minuten steigen. Wenn es die erste Ausführung ist und der Calendar-MCP noch aufwärmt, addiere 5-10 Sekunden extra.

Kann ich ihn für meinen konkreten Flow anpassen?

Ja, und es ist die Philosophie des Projekts. Die Schlüsseldateien zum Anfassen: CLAUDE.md (Persona, Ton, Regeln), .claude/commands/*.md (konkrete Flows), memory/ (persistente Präferenzen, Signatur, VIP-Kontakte, Triage-Regeln). Den Python-Code muss man selten anfassen, außer um zusätzliche IMAP-Konten hinzuzufügen oder einen neuen Kanal zu integrieren. Beginne damit, dass das Basis-Setup funktioniert, bevor Du anpasst — es ist günstiger zu lernen, wo man anpassen muss, wenn Du bereits siehst, was Dir überflüssig ist und was fehlt.

Fazit: 60 Minuten zwischen Dir und Deinem ersten operativen PA

Wir nutzen diesen PA seit zwei Wochen bei Kiwop und die ehrlichste Schlussfolgerung, die wir schreiben können, ist, dass der echte Produktivitätssprung nicht vom Modell kommt — er kommt vom minimalistischen Design rund um das Modell. Claude Code, Opus 4.7, die MCP Servers: Das ist der teure Teil, den Du nicht selbst baust. Die ~500 Zeilen Python, die Handvoll Markdown-Dateien, die drei .plist von launchd — das ist das, was Du selbst machst, und das ist, was die Fähigkeiten des Modells in einen nützlichen Assistenten für Deinen Tag verwandelt.

Dieses Tutorial hat den kompletten Weg von einem leeren Verzeichnis bis zu einem operativen PA mit vier Kanälen und geplanten Briefings abgedeckt. Der Referenzcode, den wir verwendet haben, ist unter https://github.com/purroy/majordomo unter einer permissiven Lizenz veröffentlicht — klone, forke, passe ihn an. Es ist nicht die einzige Art, einen PA im Jahr 2026 zu bauen, aber es ist eine, von der wir wissen, dass sie funktioniert, weil wir sie jeden Morgen um 08:00 Uhr nutzen, bevor wir den Arbeits-Mac einschalten.

Wenn Du während des Tutorials eine Lücke gefunden hast, in der Dein konkreter Fall mehr als diesen Basis-Stack benötigt — maßgeschneiderte Integrationen mit Deinem CRM, ein Teams-Kanal, ein proprietärer MCP für Dein ERP oder direkt ein Multi-User-Assistent für Dein ganzes Team — bauen wir bei Kiwop diese Teile als Teil unserer Dienstleistungen für Entwicklung von KI-Agenten und Beratung für Künstliche Intelligenz. Unser Ausgangspunkt ist immer derselbe: dünne, entkoppelte, anbieterunabhängige Schichten. Es gibt nichts in diesem Tutorial, was Du nicht selbst an einem Nachmittag replizieren könntest, aber wenn Zeit teurer ist als die Kosten für Outsourcing, kontaktiere unser Team und wir machen es mit Dir.

Der PA, der jetzt auf Deinem Mac läuft, gehört Dir. Niemand kann ihn über Nacht abschneiden. Und das ist 2026 das wertvollste Eigentum, das ein angewandter KI-Agent für die tägliche Arbeit haben kann.