100 Tipps zum Bau eines persönlichen KI-Agenten: Vom Cloud-Prototyp zur Produktion

Ein Entwickler hat sechs Wochen damit verbracht, einen persönlichen KI-Agenten von Grund auf zu entwickeln – keinen Chatbot-Wrapper, sondern einen persistenten Assistenten, der Aufgaben verwaltet, Deals verfolgt, E-Mails liest, Geschäftsdaten analysiert und proaktiv übersehene Punkte aufdeckt. Das Projekt begann in der Cloud (Claude Projects mit gemeinsamen Gedächtnisdateien, umfangreichen Kontextfenstern, benutzerdefinierten Fähigkeiten) und wurde dann zu Claude Code in VS Code migriert, das lokalen Dateizugriff, Git-Tracking, Shell-Hooks und geplante unbeaufsichtigte Aufgaben ermöglichte. Die Migration zwang zur Lösung von Problemen, von deren Existenz sie nichts wussten. Diese 100 Tipps sind das destillierte Ergebnis, wobei sich die maximale Claude-Nutzung von anfänglich 100 % Entwicklung / 0 % Praxis nach sechs Wochen auf 20 % / 80 % verlagerte.

Grundlagen & Identität (1–8)

• Schreiben Sie eine Verfassung, keinen System-Prompt. Ein System-Prompt listet Befehle auf; eine Verfassung erklärt Regeln. Wenn der Agent auf einen Grenzfall stößt, den keine Regel abdeckt, argumentiert er auf Basis der Verfassung, anstatt zu raten. Das unterscheidet Agenten, die sich elegant verhalten, von denen, die selbstbewusst halluzinieren.
• Geben Sie Ihrem Agenten einen Namen, eine Stimme und eine Rolle. Beispiel: „Immer erste Person. Direkt. Daten vor Emotionen. Keine Füllwörter. Keine abschließenden Zusammenfassungen.“ Das eliminiert hunderte Mikroentscheidungen pro Sitzung und schafft Konsistenz für Audits.
• Trennen Sie harte Regeln von Verhaltensrichtlinien. Harte Regeln in einem eigenen Abschnitt – nie überschrieben. Verhaltensrichtlinien passen sich an. Wenn man sie vermischt, werden beide bedeutungslos.
• Definieren Sie Ihren Auftraggeber tiefgehend. Wem dient der Agent? Was frustriert sie/ihn? Wie trifft sie/er Entscheidungen? Beispiel: „Entscheidet mit Daten, nicht mit Bauchgefühl. Will Alternativen mit Bewertung, keine einzelne Empfehlung. Hasst vage Antworten.“
• Erstellen Sie getrennt eine Fähigkeitskarte und eine Komponentenkarte. Fähigkeitskarte: Was der Agent kann (Fertigkeiten, Integrationen, Automatisierungen). Komponentenkarte: Wie er aufgebaut ist (Dateien, Verbindungen). Beides zu vermischen ergibt nach drei Monaten ein nutzloses Dokument.
• Definieren Sie, was der Agent NICHT ist. „Kein Zusammenfasser. Keine Ja-Maschine. Keine Suchmaschine. Wartet nicht, bis man ihn fragt.“ Negative Definitionen verhindern Abdrift in generische Hilfsbereitschaft.
• Bauen Sie ein DENKEN vs. HANDELN-Modell auf. Bei Unsicherheit → DENKEN (analysieren, entwerfen, vorbereiten). Bei Klarheit → HANDELN (ausführen, schreiben, erledigen. Nie einfrieren. Standardmäßig auf der niedrigsten Risikostufe handeln und das Ergebnis präsentieren.
• Versionieren Sie Ihre Identitätsdatei in Git. git blame auf der Konfiguration hilft, Verhaltensregressionen zu debuggen, die auf bestimmte Änderungen zurückgehen.

Gedächtnissystem (9–18)

• Verwenden Sie flache Markdown-Dateien für das Gedächtnis – keine Datenbank. Lesbar, durchsuchbar, git-verfolgbar, direkt vom Agenten ladbar. Keine Infrastrukturebene.
• Trennen Sie das Gedächtnis nach Domäne, nicht nach Datum. Dateien wie entities_people.md, entities_companies.md, entities_deals.md, hypotheses.md, task_queue.md. Eine Datei = eine Domäne. Chronologische Ablagen werden nach zwei Wochen nicht mehr durchsuchbar.
• Erstellen Sie eine MEMORY.md-Indexdatei. Einzelner Index, der jede Gedächtnisdatei mit einer einzeiligen Beschreibung auflistet. Der Agent lädt zuerst den Index und ruft bei Bedarf bestimmte Dateien ab. Hält die Nutzung des Kontextfensters vorhersagbar.
• Unterscheiden Sie explizit zwischen „Cache“ und „Wahrheitsquelle“ (Source of Truth). Markieren Sie jede Cache-Datei mit einem last_sync:-Zeitstempel. Beispiel: Die lokale deals.md ist ein Cache des CRM; das CRM ist die SSOT.