Diese Seite beantwortet eine Frage: Wie greifen die Teile der Werkstatt heute ineinander? Fünf Schichten reichen von der Steuerung bis zum Experiment — mit dem ehrlichen Blick darauf, was in der Praxis trägt und was noch Forschung ist.
Sechs Stationen, ein Kreislauf: Ideen kommen aus dem Betrieb, die Wissensbasis liefert Kontext, Agenten setzen um, Cockpits machen es sichtbar — und was live geht, erzeugt die nächste Idee. In der Mitte steuert der als sechste Station.
Log-Vorfälle, Audits und der Backlog liefern den nächsten Einsatz — Ideen entstehen im Betrieb, nicht am Whiteboard.
Vorfälle & LogObsidian-Wiki, durchsuchbare Wissensindizes (RAG) und Session-Memory halten den Kontext, den Agenten zum Arbeiten brauchen.
living-vaultZwei Agenten, zwei Stärken: Claude denkt breit — Synthese, Architektur, Umsetzung. Codex setzt eng um und verifiziert. Jede substanzielle Änderung geht durch beide.
dual-bridgeHook-Events, Sessions und Kosten laufen live in Cockpits auf, statt in Logs zu versanden.
ObservatoryWebsite, Case Studies und Werkstatt-Log machen Ergebnisse öffentlich prüfbar — und speisen neue Ideen zurück.
Werkstatt-LogDer Orchestrator nimmt Aufträge an, verteilt sie auf Agenten und eskaliert über Approval-Gates — als Nabe die sechste, steuernde Station des Kreislaufs.
DCO-Case-StudyDie Arbeitsproben stehen nicht nebeneinander, sie greifen ineinander — von der Steuerung über das Gedächtnis und die Beobachtung bis zum öffentlichen Beleg und zum Experiment. Jede Schicht trägt einen eigenen Beweis und eine ehrliche Grenze.
Macht aus einem Prompt einen Ablauf.
Hier wird Arbeit verteilt: vom Telegram-Auftrag über die Queue bis zur Bridge zwischen Geräten und Modellen. Diese Schicht entscheidet, wie Arbeit in Bewegung kommt: über Mini-App, Review-Loops oder zwei Modelle im Gespann.
Beweis Produktiv genutzter Orchestrator, dokumentierte Architektur, Test- und Changelog-Tiefe.
Grenze Persönliche lokale Systeme, kein öffentlicher SaaS-Dienst.
Verhindert, dass Sessions wieder bei null anfangen.
Hier wird Kontext haltbar: Projekt-Dossiers, Capability-Cards, Session-Memory, Prompt-Routing und semantische Suche. Die Schicht beantwortet nicht nur, was schon bekannt ist, sondern auch, welche Fähigkeit für eine Aufgabe zuständig ist.
Beweis Claim-gebundener Capability-RAG, MCP-Server und harte Test-Suiten.
Grenze Wissensräume bleiben privat; öffentlich sind Architektur und kuratierte Slices.
137 Fähigkeiten · 36.818 Chunks · 1.949 Tests · mehrere kuratierte Vaults · automatischer Rebuild · Kennzahlen-Stand 14.07.2026
Im Detail: Wie das Gedächtnis funktioniert →Macht Agentenarbeit sichtbar, messbar und nachspielbar.
Hier wird aus Terminal-Nachhall ein Ereignisstrom: Tool-Calls, Subagenten, Kosten, Tokens, Lanes, Replays und Fan-out-Bäume. Die Schicht zeigt nicht nur, dass ein Agent gearbeitet hat, sondern wie.
Beweis Replay-Demo mit synthetischen Daten, lokale Pipeline, fail-softe Hook-Sender.
Grenze Kein Live-Zugriff auf lokale Systeme; öffentlich sind Replays und Walkthroughs.
Im Detail: Das Replay in Aktion →Übersetzt interne Systeme in öffentliche, sichere Arbeitsproben.
Hier werden echte interne Systeme von öffentlich zeigbaren Ausschnitten getrennt: synthetische Daten, Allowlist-Builds, dokumentierte Walkthroughs und klare Grenzen statt Live-Zugriff auf private Infrastruktur.
Beweis Live-Sites, Case-Studies mit ehrlichen Grenzen und Public-Safety-Gates im Build.
Grenze Gezeigt wird der geprüfte Ausschnitt, nicht der ganze private Stack.
Hier entstehen neue Mechanismen, bevor sie in den Kern wandern.
Was passiert, wenn Agenten sich selbst verbessern, einander widersprechen oder ganze Ideen-Vaults in Builds überführen? Nicht jedes Experiment wird Produkt, aber jedes gute Experiment schärft den Stack (Cascade-Treiber und Prompt-Prelude-Experimente inklusive).
Beweis Selbstoptimierung gegen Lighthouse als externem Richter, dokumentierte Fehlschläge.
Grenze Experimente bleiben Experimente, kein Auto-Deploy in produktive Systeme.
5 öffentliche Schichten · intern führt der Atlas feingranularere Ebenen
Aus einer Aufgabe wird Ausführung, aus Wissen eine Fähigkeit, aus einem Build eine Veröffentlichung — dieselben drei Abläufe tragen den Rest der Seite. Die Daten kommen aus der Atlas Public Projection.
Eine Aufgabe wird priorisiert, mit Gedächtniskontext angereichert, ausgeführt und gegengeprüft; Learnings fließen zurück.
Kuratierte Quellen werden hybrid durchsuchbar; eine Agentenanfrage erhält belegte Treffer und wird zur passenden Fähigkeit geroutet.
Claude und Codex bearbeiten und prüfen eine Änderung wechselseitig; erst nach Owner-Freigabe wird veröffentlicht und live geprüft.
Die Wissensbasis ist der Boden unter allen Schichten. Drei Regeln bestimmen, wie Wissen hinein- und wieder herauskommt.
Notizen, Entscheidungen und Rohmaterial liegen in eigenen Wissensräumen. Was wahr ist, gehört deshalb noch nicht automatisch auf die Website.
Ein gemeinsamer Index hält fest, was die Werkstatt weiß, und liefert es zur passenden Aufgabe zurück — belegt statt aus dem Gedächtnis behauptet.
Die öffentlichen Seiten erhalten kuratierte, geprüfte Ausschnitte. Jede Freigabe ist ein bewusster Schritt, kein Automatismus.
Stand 20.07.2026Quelle Atlas Public ProjectionScope Wissensbasis · Projektionsstand · Snapshot public-20260720-194025802241
Wie die Wissensbasis im Alltag arbeitet — vom Sammeln über den Öffentlichkeitsfilter bis zum Abruf durch Agenten — zeigt das Agenten-Gedächtnis-Dossier
Die Stack-Seite soll zeigen, wie ich Agentensysteme nicht nur baue, sondern begrenze, prüfe und für reale Nutzung verantwortbar mache.
GUARD · CySec · Threat-Models · Audit-Dossiers · Approval-Pfade — aktiv im Eigenstack, quer über allen Schichten
Wie eine Änderung durch Review und Freigabe läuft, zeigt Fluss C — Build → Review → Veröffentlichung.
Öffentliche Seiten zeigen nur Inhalte, die für die Veröffentlichung unbedenklich sind. Private Nachweise, rohe Wiki-Inhalte und persönliche Dokumente gehören nicht in frei erreichbare Assets.
Access-Gates sind für sensible Nachweise sinnvoll, nicht für jeden ersten Kontakt. Der offene Einstieg bleibt reibungsarm, der private Raum wird gezielt freigegeben.
MCP-Tools, Direct-Paths und Automationen bekommen klare Aufgaben, Grenzen und Approval-Punkte, bevor sie Daten verändern oder veröffentlichen.
Änderungen werden mit Tests, Changelogs, Live-Checks und Wiki-Todos nachvollziehbar gehalten, damit Entscheidungen später nicht aus dem Kontext fallen.
Ein PreToolUse-Hook prüft jeden Shell-Befehl eines Agenten vor der Ausführung gegen destruktive Muster wie rm -rf, DROP TABLE, TRUNCATE und Force-Push. Gequotete Argumente werden maskiert, damit Daten nicht als Befehle gelesen werden; der Hook läuft fail-open mit JSONL-Audit-Log statt als Produktivitäts-Blockade. Entstanden ist er nach zwei realen Datenverlust-Vorfällen.
Die ganze Geschichte im Werkstatt-LogPraktisches Beispiel: Der CV bleibt unbedenklich veröffentlichbar und schnell lesbar. Zeugnisse, Urkunden und Notennachweise werden als separater, geschützter Nachweisraum geplant, statt sensible Dateien ungefiltert an die öffentliche Website zu hängen.
Die Antworten halten fest, was die Karte zeigt — und was sie bewusst nicht ist.
Die Architektur, in der die Agentensysteme zusammenarbeiten: fünf funktionale Schichten, drei Kernflüsse, das Operating Model und sichtbare Sicherheitsgrenzen.
Nein. Die Karte ist eine dokumentierte Architektur, kein Dashboard — es gibt keine Live-Ansicht der Systeme. Kennzahlen sind datierte Snapshots mit Quelle, keine Echtzeitwerte.
Nein. Die Karte zeigt den Eigenbetrieb eines Einzelnen — sie dokumentiert, wie die selbst gebauten Systeme im Alltag ineinandergreifen, keinen Team- oder Produktbetrieb.
Wer nach der Architektur den Werdegang dahinter einordnen möchte, findet ihn im Profil
Zuletzt aktualisiert: · ein Projekt von Dominic Meiser
Diese Werkstatt entsteht im Offenen — ich baue, schreibe und teile, was funktioniert. Wenn dich ein Bauteil interessiert, du eine Frage hast oder eine Idee testen willst, schreib mir.
Technische Dashboards während des Lab-Modus archiviert