So baust du dir deinen eigenen Jarvis

Ich klatsche in die Hände, und mein Rechner begrüßt mich. Ich frage, was heute ansteht, und er liest mir meine Termine vor. Ich sage „bewerte meine Website", und zwei Minuten später höre ich eine Note mit Begründung. Ich sage „bestell mir was vom Asiaten", und im Browser liegt mein übliches Essen im Warenkorb.

Das ist Version 6. Version 4 und 5 habe ich weggeworfen.

In diesem Guide zeige ich dir, wie das Ding aufgebaut ist. Keine Prompts zum Kopieren, sondern die Bauweise: welche Teile es gibt, wie sie zusammenhängen und welche Entscheidungen den Unterschied gemacht haben. Wenn du danach selbst einen baust, wird er anders aussehen als meiner. Das ist Absicht.

Das Gesamtbild in einem Satz

Ein Jarvis ist eine Schleife: Ohr → Gehirn → Mund, und das Gehirn darf zwischendurch Werkzeuge benutzen.

1. Ohr. Ein kleines Spracherkennungsmodell läuft dauerhaft und komplett offline auf deinem Rechner und wartet nur auf das Weckwort. Erst wenn es anschlägt, geht dein Mikrofon an einen richtigen Spracherkennungsdienst (bei mir Deepgram), der mitschreibt, was du sagst.
2. Gehirn. Der erkannte Text geht mit einem Systemprompt und einer Liste von Werkzeugen an ein Sprachmodell. Das Modell antwortet entweder direkt oder ruft ein Werkzeug auf (Function Calling), bekommt das Ergebnis zurück und formuliert dann die Antwort.
3. Mund. Die Antwort geht Satz für Satz an eine Sprachausgabe (bei mir ElevenLabs). Satzweise ist wichtig: Der erste Satz wird schon gesprochen, während das Modell noch am zweiten schreibt.

Das war es im Kern. Alles andere in diesem Guide ist die Frage, wie du das so baust, dass es nach drei Wochen nicht auseinanderfällt.

Warum Version 4 und 5 gescheitert sind

Beide Versionen sind in Tagen über ihren eigenen Plan hinausgewachsen. Version 5 hatte am Ende 23 Werkzeuge, geplant waren 5 bis 6. Und jedes neue Feature hat den Kern angefasst: In Version 4 gab es einen Verteiler mit sechs Wegen, in Version 5 war die Logik für die Anzeigekarten dreimal kopiert, einmal pro Modellanbieter.

Das Muster war beide Male dasselbe. Es gab keine festen Stellen, an denen etwas Neues andocken konnte. Also ist jedes Feature in die Mitte gewachsen, und irgendwann hat jede Änderung drei andere Sachen kaputt gemacht.

Die Lehre daraus ist die wichtigste Regel dieses Guides:

Der Kern kennt keine Werkzeugnamen. Er geht nur eine Liste durch.

Die vier Verträge

Version 6 steht auf vier festen Bauformen. Alles, was Jarvis kann, passt in genau eine davon. Passt etwas in keine, gehört es wahrscheinlich nicht ins Projekt.

Dazu kommt eine fünfte für die Oberfläche: ein Modul im Dashboard, das eine Kachel, ein Panel oder eine ganze Seite beisteuern kann. Gleiche Regel: Die Oberfläche kennt keine Module beim Namen, sie sammelt sie ein.

Wie ein Werkzeug aussieht

Jedes Werkzeug ist ein eigener Ordner mit einer Datei, die eine feste Form hat:

• ein Name und eine Beschreibung für das Modell, also wann es das Werkzeug nehmen soll und wann nicht
• ein Eingabeschema, damit das Modell nur gültige Parameter schicken kann
• die Ausführung selbst
• ein paar Schalter: ist es schnell genug für ein Live-Gespräch, braucht es eine Bestätigung, welche Verbindung braucht es

Ein Werkzeug importiert nie ein anderes Werkzeug. Der Kern importiert nie ein Werkzeug beim Namen. Beides prüfe ich mit automatischen Tests, nicht nur per Vorsatz. Vorsätze haben Version 5 nicht gerettet.

Ein Budget für die Anzahl

Ich zähle bei jedem Build, wie viele Werkzeuge, Routen und Tabellen es gibt, und vergleiche das mit einem festen Budget. Heute sind es 14 Werkzeuge. Das Budget darf steigen, aber nur mit einem aufgeschriebenen Grund und Datum. Das klingt bürokratisch. Es ist der Grund, warum Version 6 nicht bei 23 Werkzeugen gelandet ist.

Schnell im Gespräch, langsam im Hintergrund

Ein Live-Gespräch verträgt keine zwei Minuten Wartezeit. Deshalb gibt es zwei Arten, wie ein Werkzeug laufen kann:

• Schnelle Werkzeuge sieht das Modell direkt im Gespräch. Uhrzeit, Termine, Notizen, Wetter, Fenster öffnen. Bei mir sind das 12 Stück, und auch dafür gibt es ein Budget, weil jedes zusätzliche Werkzeug die Auswahl für das Modell schwerer und langsamer macht.
• Langsame Aufgaben gibt Jarvis an einen Hintergrundarbeiter ab. Der bekommt ein eigenes Modell, arbeitet ohne Zeitdruck und meldet sich, wenn er fertig ist. „Bewerte meine Website" läuft so: Jarvis sagt kurz, dass er sich darum kümmert, und spricht das Ergebnis, sobald es da ist.

Für den Hintergrund nehme ich ein anderes Modell als für das Gespräch. Vorne zählt Geschwindigkeit, hinten Gründlichkeit.

Der eigentliche Geschwindigkeitshebel

Die meisten denken bei Latenz an das Modell. Der größere Hebel ist, dem Modell die zweite Runde zu ersparen.

Wenn du fragst „was steht heute an", passiert ohne Vorbereitung Folgendes: Modell denkt, ruft das Kalenderwerkzeug auf, wartet auf Google, bekommt die Termine, denkt nochmal, antwortet. Zwei volle Runden.

Deshalb hält Jarvis einen Weltzustand im Arbeitsspeicher: Uhrzeit, Wetter, heutige Termine, Vorschau auf den Posteingang, offene Aufgaben, aktuelle Zahlen. Das wird im Hintergrund regelmäßig und nach jedem Gespräch aufgefrischt und steht fertig im Prompt. Die Frage nach den Terminen ist damit eine einzige Runde.

Zwei Regeln dazu:

• Im Gesprächspfad gibt es keinen einzigen Datenbankzugriff. Alles, was ein Gesprächsschritt braucht, liegt schon im Speicher. Auch das ist per Test abgesichert.
• Die Liste „das weißt du schon, dafür brauchst du kein Werkzeug" wird aus den Quellen erzeugt, die gerade wirklich vollständig geladen sind. Nie fest eingetragen. Sonst fehlt eine Quelle, das Modell glaubt trotzdem, es wüsste Bescheid, und erfindet eine Antwort.

Dazu kommen Füllsätze: vorab aufgenommene Clips in der Stimme der Persona wie „Einen Moment", die sofort abspielen, während das Modell noch arbeitet. Ehrlich gesagt ist das der Teil, der sich am meisten nach Magie anfühlt, obwohl er am wenigsten Technik ist. Bei mir liegt die Antwortzeit im Median bei rund 5 Sekunden, und ohne Füllsätze würde sich das deutlich länger anfühlen.

Gedächtnis: Dateien für Text, Datenbank für Struktur

Jarvis hat zwei Arten von Gedächtnis, und die Trennung ist bewusst.

Alles, was ein Mensch schreibt oder liest, liegt in Markdown-Dateien:

• eine Datei für den Charakter der Persona
• eine Datei für die Regeln, die jede Persona teilt (wann ein Werkzeug angekündigt wird, was im Fehlerfall gesagt wird)
• eine Datei mit Fakten über dich, die Jarvis sich merken soll
• ein Gesprächsprotokoll pro Tag

Der Vorteil: Du kannst alles in einem normalen Editor oder in Obsidian öffnen und von Hand korrigieren. Kein Datenbankprogramm, keine Migration.

Alles Strukturierte liegt in Postgres: Zahlen, Einstellungen, Verbindungen, geplante Jobs, und ein Protokoll jedes einzelnen Werkzeugaufrufs.

Wenn du eine neue Unterhaltung startest, bekommt Jarvis die letzten drei Wortwechsel aus dem Tagesprotokoll mit. Dadurch knüpft er nach einem Neuladen an, statt jedes Mal bei null anzufangen.

Was im Gedächtnis steht, wird Wahrheit

Das ist die Lektion, die ich am teuersten gelernt habe. Jarvis prüft nicht, ob stimmt, was in seinem Protokoll steht. Er glaubt es.

Ich habe bei einer Analyse gefunden, dass einer meiner automatischen Tests bei jedem Lauf einen erfundenen Wortwechsel ins echte Protokoll geschrieben hat. Über 100 Stück in einer Woche. Jarvis hat die als echte Erinnerung gelesen. Der Fix war eine Zeile im Test, das Aufräumen war mehr Arbeit.

Daraus zwei Regeln:

• Tests schreiben nie in das echte Gedächtnis. Nie.
• Was Jarvis über eine Aktion sagt, muss von der Aktion kommen, nicht vom Modell. Wenn ein Werkzeug nur den Warenkorb füllt, darf die Antwort nicht „ist bestellt" heißen. Sonst merkt er sich morgen, dass er bestellt hat.

Persona: Charakter ist Text, nicht Code

Eine Persona ist ein Ordner: eine Markdown-Datei für Charakter und Ton, ein paar kurze Szenen (Begrüßung, Aufwachen) und eine kleine Konfigurationsdatei für Stimme, Akzent und Weckwörter. Genau eine Persona ist aktiv.

Wichtig ist, was nicht in der Persona steht: welche Werkzeuge sie darf. Das ist für alle gleich. Der Charakter ist das, was du hörst, nicht das, was der Assistent tun darf. Eine kaputte Konfigurationsdatei führt dazu, dass die Persona gar keine Werkzeuge bekommt, nicht die einer anderen.

Hände am Rechner, ohne Shell

Jarvis kann Fenster öffnen, Programme starten und im Browser klicken. Das ist der gefährlichste Teil, und hier ist die Bauweise am strengsten.

• Es gibt kein Werkzeug, das beliebige Befehle ausführt. Nie.
• Alles, was am Rechner passiert, macht ein separates Begleitprogramm, das über eine feste Liste benannter Befehle angesprochen wird.
• Das Modell liefert immer nur einen Namen. Welches Programm, welche Argumente, welche Buttons im Browser geklickt werden, steht in einer lokalen Datei, die du selbst schreibst.

Beim Essen heißt das: Das Modell sagt „führe den Ablauf das Übliche beim Asiaten aus". Welche Seiten geöffnet und welche Knöpfe gedrückt werden, steht in meiner Datei, nicht im Modell. Selbst wenn jemand dem Modell etwas unterjubelt, kann es nur Namen aus meiner Liste aufrufen.

Verbindungen: langweilig schlägt schick

Für Kalender und Mail hatte ich in Version 5 das Model Context Protocol (MCP) im Einsatz. Das hat mich drei Runden Fehlersuche gekostet: verschluckte Fehler, eine leere Freigabeliste, die niemand gesehen hat, und ein Google-Server, der einen gültigen Inhalt mit einem Fehlercode zurückgeschickt hat.

In Version 6 sprechen die Kerndienste direkt mit der normalen API und eigenem Login. MCP nutze ich nur noch für Dienste am Rand.

Die zweite Regel: Jede Verbindung hat einen Gesundheitscheck. Ist er nicht grün, sieht das Modell die zugehörigen Werkzeuge gar nicht erst. Besser Jarvis sagt „das kann ich gerade nicht", als dass er es versucht und etwas erfindet.

Sicherheit, die im Code steht

• Bestätigung für alles, was nach außen geht oder schwer rückgängig zu machen ist: Mail senden, Termin anlegen, Website veröffentlichen. Das ist ein Schalter im Werkzeug, keine Bitte im Prompt. Eine Bitte im Prompt ist eine Empfehlung, ein Schalter im Code ist eine Tür.
• Notizen und Aufgaben brauchen keine Bestätigung. Die Regel richtet sich danach, wie groß der Schaden sein kann, nicht danach, ob etwas geschrieben wird.
• Jeder Werkzeugaufruf wird protokolliert, mit Eingabe, Ergebnis und ob es geklappt hat. Genau dieses Protokoll hat mir gezeigt, welche Werkzeuge im Alltag wirklich funktionieren und welche nicht.
• Geplante Jobs sind standardmäßig aus. Ein Job kostet Geld, solange der Server läuft, auch wenn du schläfst. Einschalten ist immer deine bewusste Entscheidung.

Wenn du in Deutschland baust

• Wenn du ein Google-Modell nutzt, gibt es zwei Wege: den einfachen mit API-Schlüssel und Vertex AI, wo du die Region auf Europa festlegen kannst. Für Gespräche, in denen Kundendaten vorkommen, lohnt sich der zweite Weg.
• Jede Funktion, die deinen Bildschirm an ein Modell schickt, schickt deinen ganzen Desktop, mit allem, was gerade offen ist. Überleg dir vorher, welches Fenster da nicht sichtbar sein sollte.
• Das Gedächtnis liegt bei mir lokal in Dateien und in einer Datenbank, die ich selbst betreibe. Nichts davon liegt bei einem Anbieter, dessen Speicherort ich nicht kenne.

Der Stack, den ich benutze

Das Hintergrundmodell ist bei mir der kleinste Posten. In zwei Wochen mit 187 Anfragen habe ich 21 Cent bezahlt, am intensivsten Tag 19 Cent für 153 Anfragen (Stand September 2026). Weil das stark davon abhängt, wie viel du delegierst, plane ich dafür mit 10 Dollar im Monat.

Du brauchst nicht genau diesen Stack. Du brauchst die Trennung dahinter: Ohr, Gehirn und Mund austauschbar, Werkzeuge als Liste, Gedächtnis lesbar.

In welcher Reihenfolge du baust

Wenn ich heute bei null anfangen würde, dann so:

1. Die Schleife ohne Werkzeuge. Mikrofon rein, Modell antwortet, Lautsprecher raus. Erst wenn das flüssig läuft, weiter.
2. Die Werkzeugliste und ein einziges Werkzeug. Etwas Harmloses wie Notizen. Dabei entsteht die feste Form, an die alle späteren Werkzeuge andocken.
3. Das Protokoll jedes Werkzeugaufrufs. Sofort, nicht später. Ohne das weißt du nie, was wirklich passiert ist.
4. Der Weltzustand. Uhrzeit und Wetter reichen am Anfang. Du merkst sofort, wie viel schneller Antworten werden.
5. Die erste echte Verbindung, zum Beispiel dein Kalender, mit Gesundheitscheck.
6. Persona und Gedächtnis als Markdown-Dateien.
7. Das Begleitprogramm für den Rechner, mit fester Befehlsliste.
8. Geplante Jobs, standardmäßig aus.

Und von Tag 1 an: ein Budget für die Anzahl der Werkzeuge und ein Test, der prüft, dass der Kern keine Werkzeugnamen kennt. Das sind die zwei Dinge, die Version 4 und 5 gefehlt haben.

Was du jetzt machen kannst

Bau heute Schritt 1. Nur die Schleife, ohne ein einziges Werkzeug. Wenn du deinen Rechner einmal hast antworten hören, weißt du, ob du den Rest willst.

Wenn du so etwas für dein Business haben willst, aber nicht selbst bauen möchtest, schreib mir. Und wenn du beim Nachbauen hängst, frag in der Community. Da zeige ich, was bei mir läuft.

Häufige Fragen

Verwandte Artikel

• Claude Agent SDK einfach erklärt, was der Unterschied zu Claude Code ist→
• ElevenLabs oder Standardstimmen für Content→
• Der Stack für Solounternehmer, der wirklich funktioniert→