Claude Code Agentic OS Framework: So habe ich mein eigenes System entwickelt

Claude Code Agentic OS Framework: So habe ich mein eigenes System entwickelt

Ich habe sechs Monate lang Claude Code wie einen extrem schnellen Praktikanten behandelt – intelligent, unermüdlich, gelegentlich brillant – und genau in den Momenten vergesslich, die mich am meisten Zeit gekostet haben. Jede Sitzung begann damit, dass ich erneut die gleiche Markenstimme, die gleiche Ordnerstruktur, die gleichen Regeln erklärte, die ich bereits an drei anderen Stellen notiert hatte. Jede von mir gebaute Fähigkeit existierte isoliert. Jede Automation, die ich eingerichtet hatte, funktionierte einwandfrei – bis ich sie jemandem übergeben musste, der nie mit einem Terminal gearbeitet hatte.

Dann habe ich aufgehört, Einzellösungen zu bauen, und begonnen, ein System zu entwickeln.

Was ich hier vorstellen werde, ist das Claude Code agentic OS Framework, auf das ich gestoßen bin, nachdem ich meinen Stack im Q1 2026 drei Mal auseinandergenommen und von Grund auf neu aufgebaut habe. Es ist kein Produkt. Es ist kein Plugin. Es ist ein Architektur-Muster, das Claude Code von einem Coding Assistant in etwas verwandelt, das einem persönlichen Betriebssystem näherkommt – eines, das sich Dinge merkt, zuverlässig ausführt und problemlos an Kund:innen übergeben werden kann, die noch nie ein Terminal geöffnet haben.

Der Ansatz, der mir den Durchbruch gebracht hat, war simpel: Die meisten Claude Code Setups scheitern an denselben drei Stellen. Speicher, Konsistenz und Zugänglichkeit. Schließt man diese drei Lücken, hört das Tool auf, einfach nur ein Tool zu sein. Es wird zur Infrastruktur.

Die drei Lücken, die jedes Claude Code Setup hat

Bevor die Architektur Sinn ergibt, muss das Problem, das sie löst, klar definiert sein. Denn wenn du Claude Code länger als ein paar Wochen benutzt hast, hast du mit großer Wahrscheinlichkeit alle drei dieser Lücken gespürt – ohne ihnen einen Namen zu geben.

Lücke eins: Speicher. Claude Code ist zwischen Sitzungen zustandslos, es sei denn, du gibst ihm einen Ort, an dem es Gelerntes ablegen kann. CLAUDE.md hilft dabei, aber letztlich ist es nur eine einzige Datei, die die Arbeit eines ganzen Aktenschranks machen muss. Sobald du möchtest, dass der Agent sich an die Präferenzen eines Kunden, die Historie eines Projekts oder eine Entscheidung von vor drei Wochen erinnert – bist du wieder beim Erklären von vorn. Die meisten denken bei „Speicher“ sofort an eine vollständige RAG-Pipeline mit Pinecone oder Supabase Vektoreinbettungen. Für 90 % der Workflows ist das massiv überdimensioniert. Du brauchst Persistenz, keinen semantischen Suchlauf über eine Million Dokumente.

Lücke zwei: Konsistenz. Lässt du Claude Code am Montag einen Blog-Post schreiben, bekommst du etwas. Stellst du am Freitag dieselbe Aufgabe, bekommst du etwas anderes – ein anderer Ton, ein anderer Aufbau, ein anderes Footer. Diese Streuung ist nicht die Schuld des Modells. Es ist ein Prompt-Engineering-Problem, das wie ein Modell-Problem aussieht. Ohne strukturierte Skills, die kodieren, wie du die Aufgabe bearbeitet haben möchtest, ist jede Ausführung ein erneuter Münzwurf. Skills und Automatisierungen beheben das, aber nur dann, wenn sie wie in einem echten Betrieb organisiert sind – nicht einfach in einen flachen ~/.claude/skills/-Ordner gekippt.

Lücke drei: Zugang. Über diese Lücke spricht niemand, weil technische Gründer sie nicht spüren. Aber sobald du Claude Code an eine weniger technische Kollegin, einen Kunden oder um 22 Uhr an dein eigenes Gehirn übergeben sollst (wenn du keine Lust hast, claude --continue --session-id foo zu tippen) – merkst du sie sofort. Das Terminal ist ein Graben. Für dich ein Feature. Für alle anderen eine unüberwindbare Mauer.

Das agentic OS Framework entsteht genau dann, wenn du aufhörst, diese drei Lücken einzeln zu lösen, und stattdessen beginnst, sie gemeinsam anzugehen.

Was ein Agentic OS eigentlich ist

Der Begriff „agentic OS“ wird oft leichtfertig verwendet. Was ich in diesem speziellen Kontext darunter verstehe: eine Architektur, bei der Claude Code die Ausführungs-Engine ist, eine persistente Speicher-Schicht für Kontinuität sorgt, ein hierarchisches Skillsystem Konsistenz gewährleistet und ein Dashboard es Nicht-Terminal-Nutzern ermöglicht, darauf zuzugreifen.

Vier Ebenen. Das ist das ganze Konzept.

┌─────────────────────────────────────────────┐
│  Dashboard / Command Center (Next.js)       │  ← Zugang
├─────────────────────────────────────────────┤
│  Skills + Automatisierungen (lokal + remote)│  ← Konsistenz
├─────────────────────────────────────────────┤
│  Memory Layer (Obsidian vault, Markdown)    │  ← Gedächtnis
├─────────────────────────────────────────────┤
│  Claude Code (Engine)                       │  ← Ausführung
└─────────────────────────────────────────────┘

Der Grund, warum diese Architektur funktioniert, ist, dass jede Ebene genau eine Aufgabe hat – und sie geraten nicht miteinander in Konflikt. Claude Code macht das, worin es bereits gut ist: logisches Denken, Code schreiben, mehrstufige Aufgaben ausführen. Obsidian übernimmt die Persistenz, weil es ohnehin ein Dateisystem aus Markdown-Dateien ist – also genau das Format, das Claude Code nativ liest und schreibt. Skills und Automatisierungen verwandeln ad-hoc-Prompts in verlässliche Workflows. Das Dashboard umfasst das alles in einer klickbaren Oberfläche.

Ich möchte einen Punkt hervorheben, der mich beim Aufbau am meisten überrascht hat: Das Dashboard ist das Element, das die Rechnung für nicht-technische Nutzer verändert – aber es ist auch das Teil, das meine eigene Arbeitsweise am stärksten beeinflusst hat. Später mehr dazu. Behalte es schon mal im Kopf.

Ebene Eins: Speicher ohne RAG

Lassen Sie mich mit dem Teil beginnen, der mir am meisten Nacharbeit bereitet hat.

Ich habe zwei Wochenenden im Februar damit verbracht, eine richtige RAG-Speicherebene für Claude Code zu bauen. Supabase als Vektor-Store, OpenAI-Embeddings, ein eigener MCP-Server, der Claude semantische Suchanfragen ermöglichte. Es funktionierte. Es war aber auch völlig überdimensioniert für das, was ich eigentlich brauchte, nämlich: „Erinnere dich daran, was wir letzten Dienstag beschlossen haben.“

Ich habe alles herausgerissen und durch einen Obsidian-Vault ersetzt. Die gesamte Schicht war in etwa 40 Minuten eingerichtet.

Hier ist der Grund, warum Obsidian speziell als AI-Speicherebene für Claude Code funktioniert:

• Obsidian-Vaults sind einfach Ordner mit Markdown-Dateien. Kein proprietäres Format. Keine Datenbank. Keine Synchronisierungsschicht, die gepflegt werden muss. Claude Code liest und schreibt nativ Markdown – das „Speichersystem“ ist also ganz einfach ein Dateisystemzugriff.
• Wiki-ähnliche Verlinkungen ([[note-name]]) geben Struktur ohne Schema. Claude kann Links genauso wie ein Mensch verfolgen und so thematische Fäden über mehrere Notizen hinweg aufnehmen.
• Es ist kostenlos, lokal und portabel. Wenn ich Claude Code durch Codex CLI oder ein beliebiges nächstes Tool ersetze, nehme ich meine Speicherebene einfach mit. Es gibt kein Vendor-Lock-in.
• Obsidian selbst rendert den Vault hervorragend für Menschen. Wenn ich nachlesen will, was der Agent geschrieben hat, muss ich keine Datenbank abfragen. Ich öffne Obsidian und lese.

Meine Vault-Struktur sieht ungefähr so aus:

~/vault/
├── _claude/
│   ├── CLAUDE.md              # globaler Kontext, wird jede Sitzung geladen
│   ├── session-logs/          # was bei jedem Durchlauf geschah
│   └── decisions/             # warum ich bestimmte Entscheidungen getroffen habe
├── clients/
│   └── [client-name]/
│       ├── brief.md
│       ├── brand-voice.md
│       └── delivered/
├── projects/
│   └── [project-name]/
└── knowledge/
    ├── claude-code-patterns.md
    └── skills-registry.md

Das entscheidende Element ist _claude/CLAUDE.md. Diese Datei ist der Einstiegspunkt von Claude Code in den Vault – eine Art Inhaltsverzeichnis für den Agenten. Sie sagt Claude, wo die Kunden-Briefs liegen, wo Sitzungsprotokolle hingeschrieben werden, und welche Dateien Entscheidungen enthalten, die niemals widersprochen werden dürfen. In jeder Sitzung liest der Agent zuerst diese Datei, bevor er in die jeweils benötigten Bereiche des Vaults geht.

Für die meisten Leser gilt: Wenn Sie sich fragen, ob Sie „ein RAG-System bauen“ oder lieber „einen Obsidian-Vault aufsetzen“ sollten – fangen Sie mit dem Vault an. Sie können RAG immer noch hinzufügen, wenn Sie tatsächlich einen Umfang erreichen, bei dem semantische Suche wichtig wird. Ich selbst bin noch nicht an diesem Punkt und betreibe dieses Setup seit drei Monaten für vier Marken und über 230 Inhalte. Wer die vertiefte Version dieses Arguments möchte: Ich habe bereits darüber geschrieben, warum Obsidian als Claude Codes persistenter Speicher und warum ein flacher Wissens-Vault für die meisten Workflows einer RAG-Pipeline überlegen ist.

Ein Hinweis bevor es weitergeht — Die Speicher-Ebene ist in diesem Framework nicht optional. Ohne sie hat die Skills-Ebene keinen Ankerpunkt. Konsistenz erfordert etwas, mit dem sie konsistent sein kann. Das ist die Brücke zum nächsten Teil.

Ebene Zwei: Skills und Automatisierungen, strukturiert wie ein Organigramm

Dies ist die Ebene, auf der die meisten agentischen OS-Versuche im Chaos enden.

Der Fehler, den ich immer wieder sehe – und den ich selbst eine Zeit lang gemacht habe – ist, jede einzelne Fähigkeit einfach in einen flachen Ordner zu werfen. ~/.claude/skills/post-writer, ~/.claude/skills/research, ~/.claude/skills/social-scheduler, dreißig weitere. Danach versucht man sich sechs Wochen später zu erinnern, welches Skript was macht.

Die Lösung ist, Skills nicht länger als Skripte zu sehen, sondern als Rollen in einem Team zu begreifen.

Das ist die Hierarchie, auf die ich mich festgelegt habe:

Funktionen sind die breiten Arbeitsbereiche. „Content-Produktion“, „Recherche“, „Client Ops“, „Brand Monitoring“. Das sind keine Skills, sondern Kategorien, in die ein Skill gehört.

Skills sind atomare, wiederverwendbare Tätigkeiten innerhalb einer Funktion. In „Content-Produktion“ habe ich zum Beispiel blog-post-writer, image-brief-generator, social-distribution-package. Jeder Skill übernimmt eine spezifische Aufgabe und macht sie richtig gut. Jeder besitzt eine eigene SKILL.md-Datei, die beschreibt, wann Claude ihn aufrufen soll, welche Inputs gebraucht werden und welche Outputs erzeugt werden.

Sub-Skills übernehmen die Spezialisten-Arbeiten, die ihnen vom übergeordneten Skill delegiert werden. blog-post-writer hat Sub-Skills für die Recherchephase, Voice-Matching, SEO-Strukturierung und Selbstbewertung. Der Haupt-Skill koordiniert, die Sub-Skills führen aus.

Automatisierungen sind Skills mit Triggern. Es handelt sich um die gleichen Skills, aber sie laufen nun zeitgesteuert oder werden automatisch ausgeführt, wenn ein bestimmtes Ereignis eintritt. Geplante Automatisierungen werden durch Cronjobs angestoßen. On-Demand-Automatisierungen werden durch einen Button-Klick im Dashboard oder einen Hook in Claude Code selbst ausgelöst.

Claude Code hat Anfang des Jahres ein Skill-Creator-Plugin im offiziellen Marketplace veröffentlicht, das die meiste Grundstruktur für dich übernimmt. Wenn man /plugin install skill-creator direkt in Claude Code ausführt, erhält man einen geführten Workflow: Skill beschreiben, ihn mit echten Inputs testen, das Prompt iterieren und schließlich in den Skills-Ordner einpflegen. Rund um dieses System gibt es ein riesiges Ökosystem – die Community Marketplaces auf tonsofskills.com und claudemarketplaces.com listen im April 2026 Tausende von Plugins und Agents, die sich problemlos in diese Hierarchie einsortieren lassen, wenn du sie nach ihren Funktionen organisierst.

Der Grund, warum die hierarchische Struktur wichtig ist, ist nicht ästhetisch. Sie sorgt dafür, dass Claude Codes eigene Routing-Logik besser funktioniert, wenn die Skills sauber organisiert sind. Wenn der Agent entscheidet, welchen Skill er ausführen soll, passiert diese Entscheidung innerhalb seines Kontextfensters. Ein flacher Ordner mit 60 Skills verschwendet Tokens für die Unterscheidung. Eine Hierarchie aus vier Funktionen mit jeweils sechs bis acht Skills und jeweils benannten Sub-Skills ermöglicht es dem Agenten, schnell einzugrenzen.

Wenn du mehr über die eigentliche Hierarchie wissen willst, findest du die Details in meinem Claude Code Agent Teams Playbook und im Advanced Agent Skills Guide. Beide sind Cluster-Posts zu diesem Artikel.

Lokal vs. Remote Automation: Die wirklich entscheidende Entscheidung

Sobald Skills existieren, stellt sich die nächste Frage: Wo laufen sie? Genau an diesem Punkt geraten viele Builds ins Stocken, denn der Unterschied zwischen lokaler und remote Automation hat nichts mit Komplexität zu tun — sondern einzig damit, womit das Skill arbeiten muss.

Lokale Automationen laufen auf deinem Rechner. Sie haben Zugriff auf dein Dateisystem, deine installierten CLIs, deinen lokalen Obsidian-Vault, deine Git-Repos, deine Bildschirmaufzeichnungen und alles andere, was lokal gespeichert ist. Sie erfordern, dass du angemeldet bist. Wenn dein Laptop im Schlafmodus ist, schlafen sie auch.

Remote Automationen laufen in der Cloud — in der Regel über Claude Routines, die Anthropic im $20/Monat-Plan ausgeliefert und im April 2026 deutlich ausgebaut hat. Sie sind unabhängig von deinem Rechner. Kein Zugriff auf das Dateisystem, keine lokalen CLIs, aber sie sind auch nicht darauf angewiesen, dass du online bist.

Die Entscheidungslogik, die ich nutze, ist im Grunde nur diese Frage: Muss dieses Skill auf etwas Lokales zugreifen? Wenn ja, dann lokal. Wenn nein, dann remote. Kein Kopfzerbrechen.

Konkrete Beispiele:

Kandidaten für lokale Automation:

• Tiefgehende Research-Workflows, die Firecrawl CLI zum Scrapen, Notebook LM zur Synthese und die Ausgabe als Obsidian-Note verketten. Diese brauchen lokale CLIs und das Dateisystem – das geht nur lokal.
• Video-zu-Blog-Pipelines, bei denen ich ein Video herunterlade, lokal transkribiere, das Transkript an Claude Code übergebe und den Beitrag unter content/mejba.me/[slug].md speichere. Die Dateien sind lokal. Die Automation ebenso.
• Codebase-Refactorings, bei denen Claude Code direkt Repository-Dateien auf der Festplatte bearbeitet.
• Screenshot-basierte Design-Review-Skills, die ein lokales Browserfenster aufnehmen und das Bild an den Agenten weitergeben.

Kandidaten für Remote-Automation:

• Tägliche Websuche + Report, die jeden Morgen um 6 Uhr AI-News sucht, ein Digest kompiliert und als Markdown-Datei in ein GitHub-Repo pusht. Kein lokaler Zugriff nötig. Läuft in der Cloud. Ich stehe auf, git pull, lese den Digest.
• Geplantes Brand-Monitoring — stündliche Suche nach Erwähnungen einer Kundenmarke im Netz, alles Neue wird in einer Notion-Datenbank protokolliert. Reiner Cloud-Flow.
• Newsletter-Entwurf aus einem RSS-Feed jeden Sonntagabend, geliefert als Entwurf in Ghost oder Beehiiv via API. Kein lokaler Zustand.
• Lead Research und Outreach Drafting — nächtliches Pullen aus einer Leadliste, jede Firma recherchieren, personalisierte Outreach-Mails entwerfen und als Entwurf für menschliche Freigabe ablegen.

Der Grund, warum diese Unterscheidung so wichtig ist, liegt bei Kosten und Zuverlässigkeit. Remote-Automatierungen kosten dich nichts, wenn sie nachts um 3 Uhr scheitern — sie probieren es einfach nochmal. Lokale Automationen, die um 3 Uhr fehlschlagen, sind tot, bis du wieder aktiv bist. Dafür können lokale Automationen Dinge tun, die remote grundsätzlich nicht möglich sind – sie agieren direkt in deiner Arbeitsumgebung.

Ich habe das Framework ca. 60/40 lokal zu remote aufgeteilt, aber das spiegelt schlicht meine Arbeit wider. Wenn deine Arbeit vor allem SaaS-Operations, CRM, E-Mails und cloud-native Tools sind, wirst du deutlich mehr Remote-Anteil haben. Zu Claude Code’s Cloud Automation Channels und dem ersten Claude Routines-Build, das ich auf Opus 4.7 ausgeliefert habe, habe ich separat geschrieben, falls du tiefer einsteigen möchtest.

Layer Four: Das Dashboard ist der ganze Sinn

Hier möchte ich kurz innehalten und ein Geständnis ablegen.

Als ich das erste Mal hörte: „Bau ein Dashboard auf Claude Code auf“, war meine spontane Reaktion die eines Ingenieurs: Warum sollte ich eine Benutzeroberfläche für ein CLI-Tool bauen, das ich fließend beherrsche? Das Terminal ist schneller. Ich kann Dinge mit Pipes verknüpfen. Ich kann Aliase anlegen. Ein Dashboard klingt wie zusätzlicher Ballast, getarnt als Barrierefreiheit.

Dieses Reflex war falsch. Das Dashboard zu bauen, hat meine Nutzung von Claude Code stärker verändert als jedes andere Element des Frameworks.

Das habe ich übersehen: Das Terminal ist für den Moment optimiert, in dem man eine Aufgabe startet. Kaltstart, voller Fokus, Kaffee in der Hand – du tippst den Befehl und bist im Flow. Doch das Terminal ist miserabel in den Momenten zwischen den Aufgaben. Nachsehen, was die nächtlichen Automationen gebracht haben. Überwachen, wie ein lang laufender Research-Job vorankommt. Einen Skill-Aufruf an einen Kollegen übergeben, der nicht programmiert. Beim Mittagessen kurz checken, was gestern lief. In all diesen Situationen schlägt ein Dashboard das Terminal.

Was ich gebaut habe, ist eine einfache Next.js 15 App, die lokal läuft und fünf Dinge sichtbar macht:

1. Skill-Launcher — jeder Skill in meiner Hierarchie erscheint als Button, gruppiert nach Funktion. Draufklicken, Mini-Formular ausfüllen (Kunde, Projekt, Parameter), los geht’s. Das Dashboard führt dann den passenden Claude Code-Befehl aus.
2. Anstehende Routinen — zeigt alles, was in den nächsten 24 Stunden auf dem Plan steht. Fehler finde ich, bevor sie ausgelöst werden, nicht erst danach.
3. Letzte Aktivitäten — ein Feed dessen, was Claude in den letzten 48 Stunden getan hat, gezogen aus dem „session-logs“-Ordner meines Obsidian-Vaults. Jeder Eintrag verlinkt zum vollständigen Log.
4. Systemnutzung — Token-Verbrauch pro Skill pro Tag, pro Modell. So erkenne ich, wenn Automatisierungen heimlich Opus-Token verbrennen, obwohl Haiku reichen würde.
5. Output-Inbox — alles, was Claude produziert hat und auf meine Überprüfung wartet. Blog-Entwürfe, Research-Reports, E-Mail-Entwürfe.

Das Dashboard besteht aus ungefähr 800 Zeilen TypeScript. Es ist nicht kompliziert. Was das Ganze transformiert, ist nicht der Code – es ist die Änderung der Arbeitsweise. Wenn alles einen Button hat, delegiere ich anders. Ich delegiere mehr. Ich kann an Kollegen delegieren, die Claude Code im Terminal nie hätten bedienen können.

Und genau an dieser Stelle schließt sich eigentlich die Zugangslücke. Ich kann einem Kunden einfach das Dashboard zeigen, sagen: „Klicke hier, um einen Entwurf für dein wöchentliches Update zu generieren“, und er bekommt direkt Mehrwert aus Claude Code – ohne je erfahren zu müssen, was Claude Code überhaupt ist. Hier findet der Wandel vom „Tool“ zur „Infrastruktur“ statt.

Falls du Solo-Operator bist, bau das Dashboard zuerst für dich selbst, bevor du an Kunden denkst. Du wirst überrascht sein, wie stark sich dein eigenes Verhalten ändert, sobald die Reibung wegfällt.

Ein praktischer Aufbaupfad, dem Sie wirklich folgen können

Genug zur Architektur. Hier ist die Schrittfolge, die ich heute wählen würde, wenn ich noch einmal neu anfangen müsste – zugeschnitten auf jemanden, der Claude Code schon ein paar Mal pro Woche nutzt.

Woche eins: Memory. Installieren Sie Obsidian (kostenlos, obsidian.md). Legen Sie einen Vault an. Erstellen Sie das Ordnergerüst wie oben gezeigt. Schreiben Sie Ihre _claude/CLAUDE.md mit fünf Abschnitten: Wer Sie sind, an welchen Marken/Projekten Sie arbeiten, wo welche Dateien liegen, wie der Agent schreiben soll, was er nie tun darf. Nicht überdenken! Sie werden das Dokument im ersten Monat sowieso dreimal umschreiben. Dann verknüpfen Sie Claude Code mit dem Vault – entweder indem Sie es aus dem Vault-Verzeichnis starten, oder indem Sie den Vault-Pfad in Ihrer globalen CLAUDE.md angeben. Führen Sie ein paar echte Aufgaben aus und beobachten Sie, was der Agent zurückschreibt.

Woche zwei: zwei Skills. Wählen Sie die beiden Aufgaben, die Sie am häufigsten erledigen. Für mich waren das „Blogpost aus Videozusammenfassung schreiben“ und „Social Distribution Paket aus einem Artikel generieren“. Installieren Sie das Skill-Creator-Plugin per /plugin innerhalb von Claude Code. Verwenden Sie es, um jedes Skill-Grundgerüst zu erstellen. Testen Sie jedes Skill fünfmal mit realen Eingaben. Optimieren Sie das Prompt, bis die Ausgabe konsistent ist. Legen Sie die Skills im persönlichen Skills-Verzeichnis ab.

Zwei abgeschlossene Skills reichen, um zu erkennen, ob das Framework im tatsächlichen Workflow funktioniert. Bauen Sie erst weitere, wenn diese zuverlässig sind.

Woche drei: eine Automation. Wählen Sie ein Skill, das von geplanter oder bedarfsgesteuerter Ausführung profitiert. Falls lokale Dateien benötigt werden, richten Sie einen lokalen Cronjob ein, der Claude Code headless aufruft. Andernfalls nutzen Sie Claude Routines, um die Aufgabe in der Cloud zu terminieren. Eine Automation, eine Woche laufen lassen. Zeitplan optimieren. Edge Cases beheben.

Woche vier: Dashboard v0. Entwickeln Sie die denkbar einfachste Variante. Fünf Buttons, die Shell-Befehle an Claude Code senden. Kein Auth-System, keine Datenbank, läuft auf localhost:3000. Wenn Sie kein Frontend-Profi sind, kann das Frontend-Design-Skill von Claude Code die gesamte UI aus einer Beschreibung generieren. Mein v0 war eine einzige React-Komponente. Der Feinschliff kam später.

Ab Woche fünf: Nur erweitern, was sich bewährt. Fügen Sie einen Skill hinzu, wenn ein sich wiederholendes Muster entsteht. Ergänzen Sie eine Automation, wenn Sie merken, dass Sie denselben Skill immer manuell zum gleichen Zeitpunkt ausführen. Fügen Sie einen Dashboard-Button hinzu, wenn Sie etwas abgeben wollen oder aufhören möchten, den gleichen Befehl immer wieder einzutippen. Machen Sie keine Erweiterung um der Erweiterung willen. Das Framework belohnt Zurückhaltung – jeder Skill erhöht die Prompt-Kontextkosten, die der Agent bei jeder Dispatch-Entscheidung zahlen muss.

Wenn Sie eine ausführlichere Anleitung zur Agent-Teams-Seite suchen, finden Sie in meiner Claude Code Agent Teams Setup Guide eine viel tiefere Erläuterung der Skill-Hierarchie, als ich sie hier leisten kann.

Was die meisten Build-Guides falsch machen

Ich möchte drei Dinge hervorheben, die ich in anderen Agentic-OS-Artikeln immer wieder sehe und die meiner Meinung nach falsch oder zumindest unvollständig sind – basierend auf drei Monaten tatsächlichem Betrieb.

„Du brauchst RAG.“ Nein, brauchst du nicht. Nicht in dem Maßstab, in dem die meisten Einzelanwender oder kleinen Teams arbeiten. Ein gut organisiertes Obsidian-Vault mit 500 Notizen ist wertvoller als eine Vektordatenbank mit einer Million Embeddings, weil die Organisation selbst das Retrieval-System ist. RAG lohnt sich erst dann, wenn du zehntausende Dokumente durchsuchst und die Struktur nicht voraussehen kannst. Wenn du die Struktur vorhersagen kannst, schlägt Struktur immer Vektoren. Sobald ich den Punkt erreiche, an dem ich semantische Suche wirklich brauche, ergänze ich sie als zusätzliche Schicht. Nicht vorher.

„Jede Skill musst du selbst bauen.“ Das Community-Ökosystem rund um Claude Code im Jahr 2026 ist riesig und die meisten Guides stellen das deutlich zu klein dar. Der offizielle Anthropic-Marktplatz bietet verifizierte Plugins. In Community-Marktplätzen gibt es tausende weitere. Bevor du einen Skill selbst schreibst, suche danach. Drei meiner ersten selbstgebauten Skills habe ich bereits durch bessere Community-Versionen ersetzt. Das Framework definiert deine Hierarchie und die Memory Layer – die einzelnen Skills können von überall stammen.

„Das Dashboard ist für Nicht-Techniker.“ Halb richtig. Es ist für Nicht-Techniker und für dich – in jedem Moment, in dem du nicht mit voller Konzentration am Keyboard sitzt. Ich verwende mein eigenes Dashboard mehr als jeder aus meinem Team. Das Narrativ „Barrierefreiheit für Kunden“ unterschätzt völlig, wie sehr ein gutes Command-Center-UI dem Erbauer selbst nützt.

Wo dieses Framework an seine Grenzen stößt

Ehrlichkeit gebietet es, die Grenzen zu benennen.

Das Framework setzt voraus, dass du einen Workflow hast, der es wert ist, abgebildet zu werden. Wenn du einmalige, experimentelle Aufgaben erledigst – Recherche-Spikes, neuartige Probleme, wirklich kreative Exploration – dann wird dich der Overhead von Skills und Automatisierungen tatsächlich ausbremsen. Bei kreativer Arbeit öffne ich Claude Code immer noch einfach ohne CLAUDE.md, ohne Skills, ohne Vault, und lasse es pur laufen. Das agentic OS ist für wiederholbare Arbeit gedacht. Stelle sicher, dass das, was du abbildest, auch wirklich wiederholbar ist, bevor du es kodifizierst.

Es setzt auch voraus, dass du es pflegst. Skills veralten. Prompts, die für Opus 4.5 abgestimmt wurden, müssen vielleicht für Opus 4.7 neu angepasst werden. Automatisierungen funktionieren nicht mehr, wenn sich externe APIs ändern. Ich verbringe etwa zwei Stunden pro Woche mit der Pflege des Frameworks selbst – hauptsächlich indem ich Prompts aktualisiere, wenn sich das Modellverhalten verändert, und Skills entferne, die ich nicht mehr nutze. Diese Wartungskosten sind real. Wenn du das Framework baust und dann drei Monate liegen lässt, kannst du mit deutlicher Alterung rechnen.

Und es setzt voraus, dass du Claude Code genug vertraust, um eigenständig zu handeln. Das Dashboard macht es einfacher, Skills auszulösen, ohne groß nachzudenken. Automatisierungen laufen unbeaufsichtigt. Falls du keine Prüf-Checkpoints direkt in die Skills integrierst, wirst du irgendwann feststellen, dass der Agent etwas ausgeliefert hat, was er nicht hätte tun sollen. Die Sicherheitsmechanismen müssen in den Skill-Definitionen selbst verankert sein — Self-Evaluation-Schritte, Output-Review-Gates, explizite Abbruchbedingungen. Ein Framework, das schnell ohne Kontrollen läuft, ist ein Framework, das dich bei Skalierung blamieren wird.

Die wirklich wichtige Veränderung

Vor sechs Monaten bestand meine Nutzung von Claude Code aus einem Stapel Terminal-Tabs und einer CLAUDE.md, die jede Woche um 40 Zeilen wuchs. Es funktionierte. Aber es führte nicht zum Zinseszinseffekt. Jede neue Aufgabe war ein frischer Kontext-Load, jeder neue Kunde bedeutete eine weitere Datei in einem Ordner, den ich selten öffnete, und jeder gute Prompt, den ich schrieb, verschwand in meiner Shell-History, bis er hinausgescrollt war.

Das agentic OS Framework hat die Rechnung grundlegend verändert. Speicher im Vault bedeutet, dass das, was ich im März gelernt habe, auch im April noch nutzbar ist. Skills sorgen dafür, dass der Prompt, den ich für einen Kunden optimiert habe, auch beim nächsten zwanzig Mal eingesetzt werden kann. Dashboards machen aus „Mejba muss das selbst um 22 Uhr ausführen“ ein „Jeder im Team kann diesen Button klicken.“

Die Lücke zwischen einem leistungsstarken Tool und nützlicher Infrastruktur liegt selten am Tool selbst. Claude Code konnte das von Anfang an. Was gefehlt hat, war die Architektur drumherum: Memory. Konsistenz. Zugriff. Wenn man diese drei Aspekte schließt, verändert sich die Mathematik radikal, was man allein — oder mit einem kleinen Team — betreiben kann.

Wenn du aus diesem Beitrag nur eine Sache umsetzt, dann baue das Obsidian Vault. Dieser eine Schritt hat für mich mehr freigeschaltet als die anderen drei Layer zusammen, weil darauf jede weitere Ebene aufbaut. Die Skills brauchen Memory, um konsistent anwendbar zu sein. Das Dashboard benötigt Sitzungsprotokolle zur Anzeige. Die Automatisierungen brauchen einen Ort, an dem Ausgaben hinterlegt werden, die auch andere einsehen können.

Dein Claude Code funktioniert heute einwandfrei. Die Frage ist, ob der hundertste Einsatz wertvoller ist als der erste – oder einfach nur das Gleiche, hundertmal von vorn.

Häufig gestellte Fragen

Was ist ein agentisches OS-Framework für Claude Code?

Ein agentisches OS-Framework ist eine Architektur, die Claude Code in vier Schichten einbettet — persistenter Speicher, hierarchische Skills, lokale und entfernte Automatisierungen sowie ein Dashboard — damit der Agent Kontext über mehrere Sitzungen hinweg behält, Aufgaben konsistent ausführt und auch von nicht-technischen Teammitgliedern genutzt werden kann. Dadurch wird Claude Code von einem CLI-Tool zu betrieblicher Infrastruktur. Die vollständige architektonische Aufschlüsselung findest du im Abschnitt „Was ein agentisches OS wirklich ist“ weiter oben.

Brauche ich eine RAG-Pipeline, um Claude Code Speicher zu geben?

Nein, die meisten Workflows benötigen kein RAG. Ein Obsidian-Vault mit strukturierten Markdown-Notizen und einem _claude/CLAUDE.md-Einstiegspunkt verleiht Claude Code persistenten Speicher, ohne die Komplexität von Vektor-Embeddings. Claude Code liest Markdown nativ, sodass das Vault sowohl als Speicherung als auch zur Wiederherstellung dient. Füge RAG nur hinzu, wenn du eine semantische Suche über zehntausende unstrukturierte Dokumente benötigst.

Was ist der Unterschied zwischen lokalen und entfernten Claude Code Automatisierungen?

Lokale Automatisierungen laufen auf deinem Rechner und können auf das Dateisystem, lokale CLIs und Obsidian-Vaults zugreifen — ideal für Research-Pipelines, Arbeiten am Codebase und alle Aufgaben mit lokalen Dateien. Entfernte Automatisierungen laufen über die Cloud mittels Claude Routines und sind unabhängig von deiner Maschine — ideal für geplante Websuchen, Brand-Monitoring und Cloud-API-Workflows. Entscheidungsregel: Wenn die Fähigkeit etwas Lokalbezogenes benötigt, läuft sie lokal.

Wie unterscheiden sich Claude Code Skills von Plugins?

Plugins sind das Distributionsformat, Skills der Inhalt. Ein Plugin ist ein Ordner mit einer plugin.json-Manifestdatei, die ein oder mehrere Skills (SKILL.md-Dateien) sowie Slash-Commands und Hooks bündeln kann. Du installierst ein Plugin über den /plugin-Befehl innerhalb von Claude Code, wodurch die enthaltenen Skills automatisch hinzugefügt werden. Seit April 2026 bieten der offizielle Anthropic Marketplace und Community-Marktplätze wie tonsofskills.com tausende Plugins und Skills an.

Können technisch unerfahrene Nutzer Claude Code wirklich über ein Dashboard verwenden?

Ja, genau das ist der praktische Zweck eines Dashboards. Ein lokales Next.js-Dashboard mit klickbaren Skill-Buttons, letzter Aktivität und anstehenden Routinen ermöglicht wirklich jedem, Claude Code Workflows auszulösen – ganz ohne Terminal. Das Dashboard steuert im Hintergrund Claude Code an — der Nutzer sieht Buttons, Klicks und Ausgaben. So übergebe ich Skills an Kunden und Teammitglieder, die nie ein Terminal geöffnet haben.

Lassen Sie uns zusammenarbeiten

Möchten Sie AI-Systeme entwickeln, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Security-Services): xcybersecurity.io