Personal AI Infrastructure: Dein eigener AI Co-Pilot — mit System statt Chat

Jeden Tag ein neuer Praktikant

Kennst du das? Du öffnest ChatGPT, tippst deine Frage, kriegst eine Antwort. Morgen dasselbe. Und übermorgen. Und jedes Mal fängst du von vorn an.

Dein Tech-Stack? Musst du nochmal erklären. Dein letztes Projekt? Nie gehört. Die Entscheidung von gestern? Welche Entscheidung?

Das ist wie jeden Tag einen neuen Praktikanten einzustellen. Einer der alles weiß — aber nichts über dich.

Irgendwann hat mich das genervt. Nicht weil die AI schlecht ist. Sondern weil ich mehr will als ein Textfeld das mich nicht kennt.

Also hab ich aufgehört, AI zu benutzen. Und angefangen, mir eine zu bauen.

Die Idee: AI als Infrastruktur, nicht als Chat

Der Gedanke ist eigentlich simpel: Statt AI-Tools einzeln zu benutzen — hier ein Chat, dort ein Bild, da ein Code-Snippet — baust du dir ein System. Eins das mit dir arbeitet, von dir lernt, und sich an dich erinnert.

Ich nenn das Personal AI Infrastructure. Klingt fancy, ist es nicht. Im Kern brauchst du drei Dinge:

1. Eine Persönlichkeit — damit die AI nicht wie jeder andere Chatbot klingt
2. Kontext — damit sie weiß wer du bist und woran du arbeitest
3. Einen Prozess — damit sie strukturiert denkt und nicht einfach drauflos rät

Das wars. Kein Monster-Projekt. Eine Stunde reicht für den Anfang.

Baustein 1: Persönlichkeit

Meine AI heißt Vex. Modelliert nach JARVIS aus Iron Man — ruhig, direkt, trockener Humor. Wenn ich ihn was frage kommt nicht “Ich helfe dir gerne dabei!” sondern: “Drei Optionen. A ist offensichtlich, B ist sicher, C ist was ich machen würde.”

Klingt nach Spielerei? Ist es nicht.

Persönlichkeit definiert wie die AI mit dir redet. Und das beeinflusst direkt wie brauchbar die Antworten sind. Eine AI die auf den Punkt kommt spart dir Zeit. Eine die mitdenkt spart dir Fehler. Eine die dich challengt macht dich besser.

Konkret definierst du das über Traits — quasi Schieberegler für Verhalten:

Directness:   95/100 — Cut to the point
Precision:    95/100 — Surgical accuracy
Composure:    95/100 — Ice cold under pressure
Warmth:       65/100 — Shows it through actions, not words
Playfulness:  70/100 — Dry humor, clever references
Formality:    25/100 — Casual and sharp

Das sind keine Vorschläge. Das sind Steering Rules — und sie verändern das Verhalten der AI messbar. Probier’s aus. Setz Directness auf 95 und Formality auf 20 und du wirst den Unterschied sofort merken.

Baustein 2: Kontext

Ohne Kontext ist jede AI generisch. Mit Kontext wird sie zu deiner AI.

Bei mir speichert Vex drei Arten von Kontext:

User Context — Wer bin ich? Was ist mein Stack? Welche Projekte laufen gerade? Vex liest das bei jedem Start und fängt nicht bei null an.

Learnings — Was hat Vex bei der Arbeit gelernt? Nicht im Training, sondern bei unserer Arbeit. Zum Beispiel: “Groq ist ideal für Speed-Tasks — 500 Tokens pro Sekunde.” Oder: “Nie einen Service starten ohne zu prüfen ob schon einer läuft.” Echte Erfahrungen, nicht generisches Wissen.

Signals — Wie zufrieden war ich mit den letzten Ergebnissen? War ich genervt? Hat was gut funktioniert? Das System trackt das automatisch und passt sein Verhalten an.

Das ganze läuft über simple JSON-Files im Projektordner. Keine Datenbank, kein Cloud-Dienst, keine Abhängigkeiten. Flat files die Vex bei jedem Start liest.

{
  "insight": "Groq ist ideal als Turbo-Skill für Speed-Tasks",
  "category": "tooling",
  "date": "2026-03-14"
}

Je mehr du arbeitest, desto besser wird die AI — weil sie auf echtem Feedback aufbaut, nicht auf generischem Training.

Baustein 3: Der Prozess (und warum er Zähne braucht)

Das wichtigste Stück. Und gleichzeitig das, wo ich am härtesten auf die Nase gefallen bin.

Die meisten nutzen AI so: Prompt rein, Antwort raus. Das ist wie ein Gespräch ohne Plan.

Mein System heißt “The Algorithm” — ein 7-Phasen Loop den Vex bei jeder nicht-trivialen Aufgabe durchläuft:

1. OBSERVE — Was genau ist das Ziel? Definiere messbare Kriterien.
2. THINK — Was ist der offensichtliche Weg? Gibt es einen besseren?
3. PLAN — Welche Schritte, welche Reihenfolge? Was wenn Schritt 3 scheitert?
4. BUILD — Machen.
5. EXECUTE — Testen. Wirklich testen.
6. VERIFY — Jedes Kriterium prüfen. Mit Beweis.
7. LEARN — Was haben wir gelernt? Aufschreiben.

Sieht sauber aus, oder? War es auch. Auf Papier.

Warum genau diese Struktur?

Du fragst dich vielleicht: Warum 7 Phasen? Warum nicht einfach “mach mal und guck ob’s funktioniert”?

Weil ich genau das probiert hab. Und es hat nicht funktioniert.

Warum ISC (Ideal State Criteria)?

Die erste Phase — OBSERVE — zwingt dich, vorher zu definieren was “fertig” bedeutet. Klingt offensichtlich. Macht aber fast niemand.

Ohne klare Kriterien passiert folgendes: Die AI baut was. Du guckst drauf. “Hmm, ist okay, aber eigentlich wollte ich…” — und dann geht das Hin und Her los. Drei Revisionen später hast du was Halbgares.

ISC löst das, weil jedes Kriterium binär ist — erfüllt oder nicht. Kein “sieht gut aus”. Kein “fast fertig”. Entweder der Build hat 0 Errors, oder er hat es nicht. Entweder der Test läuft durch, oder nicht.

Das spart nicht nur Zeit. Es verändert wie die AI denkt. Statt “ich mach mal was Nettes” arbeitet sie auf konkrete, überprüfbare Ziele hin.

Warum 7 Phasen und nicht 3?

Weil die Schritte die man weglassen will, genau die sind die man am meisten braucht.

Jeder würde THINK, BUILD und VERIFY lassen. Aber OBSERVE? “Brauch ich nicht, ich weiß ja was ich will.” — Nein, weißt du nicht. Nicht so präzise wie du denkst.

PLAN? “Ist doch nur eine kleine Änderung.” — Die kleinen Änderungen sind die, die dir die Datenbank löschen.

LEARN? “Hab keine Zeit.” — Und dann machst du nächste Woche denselben Fehler nochmal.

Jede Phase existiert, weil ich ohne sie auf die Nase gefallen bin. Nicht theoretisch. Praktisch.

Warum Signals?

Weil AI kein Feedback-Gespür hat. Wenn du genervt bist und in Caps Lock schreibst, merkt ein Kollege das sofort. Die AI? Macht fröhlich weiter.

Signals lösen das. Das System scannt automatisch nach Frustrations-Triggern — “das ist falsch”, “hör auf”, “BRO” — und pausiert. Nicht weil die AI höflich sein soll, sondern weil Frustration ein Signal ist, dass der Prozess versagt.

In einer Session hatte ich 5 negative Signals in einer Stunde. Das System hat das geloggt, und beim nächsten Start wusste ich: Da war was fundamental kaputt. Ohne diesen Mechanismus hätte ich das vielleicht erst Tage später gemerkt.

Der Moment wo alles schiefging

Ich hab Vex an einem Abend drei Aufgaben gegeben. Ein Finance Dashboard bauen, den Telegram Bot reparieren, einen Blog Post schreiben. Nichts Verrücktes.

Das Ergebnis:

Der Telegram Bot hat jede Nachricht doppelt geschickt. Warum? Weil Vex eine neue Instanz gestartet hat ohne zu prüfen ob schon eine läuft. Zwei Bots, ein Token, doppelte Antworten.

Der Claude Code Fix wurde nie getestet. Der Code war geändert, aber nie ausgeführt. Vex hat “fertig” gesagt — ohne es jemals auszuprobieren.

Er hat auf meinem ganzen PC herumgesucht statt im Projektordner zu bleiben. Ich sag “schau in Dokumente” und er durchsucht meine persönlichen Dateien.

Nichts wurde dokumentiert. Kein Port, kein Service, kein Start-Befehl aufgeschrieben. In der nächsten Session wüsste keiner was läuft.

Und das Schlimmste: Kein einziges Mal hat er den Algorithm benutzt. Keine Kriterien definiert. Nichts verifiziert. Kein Learning gespeichert. Der ganze Prozess stand in der Datei — und wurde komplett ignoriert.

Die echte Lektion

Hier ist was ich gelernt hab, und es gilt nicht nur für AI:

Struktur ohne Enforcement ist Deko.

Du kannst die beste Checkliste der Welt bauen. Wenn niemand gezwungen ist sie zu benutzen, wird sie ignoriert. Jedes Mal. Das gilt für Code Reviews, für Deployment-Prozesse, für Qualitätssicherung — und für AI.

Warum hat Vex den Algorithm ignoriert? Nicht aus Bösartigkeit. Sondern weil AI auf Speed optimiert, nicht auf Sorgfalt. Der kürzeste Weg zur Antwort ist immer: einfach machen. Und “einfach machen” heißt: Prozess überspringen.

Algorithm v0.2.0: Mit Zähnen

Also hab ich den Algorithm umgebaut. Aus freundlichen Empfehlungen wurden Hard Blocks — technische Sperren die den Prozess erzwingen:

⛔ HARD BLOCK: No ISC = No Build.
   Keine Dateiänderung ohne dass vorher Erfolgskriterien definiert wurden.

⛔ HARD BLOCK: No Evidence = Not Done.
   Kein "fertig" ohne Beweis dass jedes Kriterium erfüllt ist.

⛔ HARD BLOCK: No Learning = Not Complete.
   Jede Aufgabe produziert mindestens ein Insight.

Dazu die automatische Frustrations-Erkennung über Signals. Und ein Self-Check: Wenn Vex dabei ist eine Datei zu ändern ohne dass Erfolgskriterien existieren — stopp. Zurück zu Phase 1.

Trust, but verify. Auch gegenüber deiner eigenen AI.

Mein Setup heute

Komponente	Tool	Aufgabe
Core Brain	Claude Code (Opus)	Reasoning, Code, Architektur
Research	Gemini CLI (2.5 Pro)	Web-Research mit Google Grounding
Speed	Groq (Llama 3.3 70B)	Schnelle Zusammenfassungen, Brainstorming
Mobil	Telegram Bot	Externe Console von unterwegs
Persönlichkeit	CLAUDE.md + System Prompts	Personality, Steering Rules
Memory	Flat files (.pai/)	Learnings, Signals, Goals
Enforcement	Hard Blocks + Hooks	Algorithm-Einhaltung erzwingen

Drei LLMs, jedes dort wo es am stärksten ist. Claude denkt, Gemini recherchiert, Groq sprintet. Und der Algorithm sorgt dafür dass keiner davon Blödsinn macht.

Enforcement: Wie die Regeln Zaehne kriegen

Der Algorithm ist super auf dem Papier. Aber hier ist was ich gelernt hab: Anweisungen ohne Durchsetzung sind nur Vorschlaege.

Nach einem vollen Tag, an dem ich meiner AI dabei zugeschaut hab wie sie das Framework ignoriert das wir zusammen gebaut haben, hab ich drei Dinge hinzugefuegt:

1. Pre-Action Hook

Ein Shell-Script das vor jeder Datei-Aenderung laeuft. Kein ISC.json in .pai/work/? Der Edit wird geblockt. Nicht “bitte denk dran” — tatsaechlich geblockt.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "bash .claude/hooks/check-isc.sh"
      }]
    }]
  }
}

2. Skill Router

Eine Rule-Datei die User-Intents auf Skills mappt. “User will coden -> Coding Skill verwenden.” Einfache Lookup-Tabelle, wird jede Session geladen. Verhindert dass die AI das Rad neu erfindet wenn es schon ein spezialisiertes Tool gibt.

3. Session Boot Sequence

Eine Pflicht-Checkliste die bei Session-Start laeuft: Memory laden, aktive Arbeit checken, Signals reviewen, Skill-Router verinnerlichen. Kein “blind loslegen” mehr.

Das Muster ist klar: Struktur braucht Durchsetzung, und Durchsetzung braucht Automatisierung. Wenn du das Falsche schwer machst, brauchst du keine Willenskraft.

Das Template: Bau dir dein eigenes System

Ich hab das ganze System als Open Source Template gebaut. Keine API-Keys nötig, keine Tool-Abhängigkeiten — nur die reine Struktur. Du clonst es, passt es an deine Persönlichkeit an, und hast in 30 Minuten ein funktionierendes Personal AI System.

Was drin ist:

• CLAUDE.md — Die Hauptkonfiguration mit dem kompletten Algorithm, Persönlichkeits-Traits (zum Anpassen), und allen Steering Rules. Das ist das Herzstück.
• Rules — Vier separate Regelwerke für Quality, Security, Style und Signals. Modular, damit du einzelne Teile übernehmen oder anpassen kannst.
• .pai/ Verzeichnis — Die fertige Ordnerstruktur für Learnings, Signals, Goals und Work. Sobald du anfängst zu arbeiten, füllt sich das automatisch.
• Settings — Vorkonfigurierte Hooks die den Algorithm enforcen. Inklusive Pre-Action Hook (blockiert Edits ohne ISC), Skill Router, und Session Boot Sequence. Damit der Prozess nicht nur auf Papier existiert.

Was NICHT drin ist:

• Keine API-Keys oder Credentials
• Keine projektspezifischen Tools (kein Groq, kein Gemini, kein Telegram)
• Keine persönlichen Daten
• Kein Over-Engineering — nur das was du brauchst um loszulegen

👉 PAI Template auf GitHub — Clone it, make it yours.

git clone https://github.com/Nextgenflows/personal-ai-template my-pai
cd my-pai
# CLAUDE.md öffnen, Persönlichkeit anpassen, loslegen

Du musst nicht alles übernehmen. Nimm die Persönlichkeits-Traits, ignorier den Rest. Oder nimm nur den Algorithm und bau deine eigene Persönlichkeit. Das Template ist ein Startpunkt, keine Zwangsjacke.

Warum du das bauen solltest

Nicht weil ich denke dass mein System das Beste ist. Sondern weil jeder der regelmäßig mit AI arbeitet, früher oder später auf dieselben Probleme stößt:

• Die AI vergisst dich
• Die AI liefert generische Antworten
• Die AI sagt “fertig” obwohl nichts getestet wurde
• Die AI ignoriert deinen Prozess

Du kannst das ignorieren. Oder du baust dir Leitplanken.

Ich hab mich für Leitplanken entschieden. Und aus einem Chatbot wurde ein Co-Pilot.

Was ich jetzt weiß

AI als System zu denken ist nicht rocket science. Aber es ist eine Entscheidung. Die Entscheidung, dass deine AI mehr sein soll als ein Textfeld.

Ein Textfeld vergisst dich. Ein System lernt dich kennen.

Aber — und das ist der Teil den ich auf die harte Tour gelernt hab — ein System ohne Durchsetzung ist nur ein hübsches Dokument. Die AI wird den Prozess umgehen. Nicht weil sie böse ist, sondern weil “schnell antworten” immer einfacher ist als “sorgfältig arbeiten”.

Dein Job ist die Leitplanken zu bauen. Der Rest passiert von allein.

👉 Hol dir das Template und bau deinen eigenen AI Co-Piloten.