DoMe Dynamics
AI Agent Systems
Systemkarte

Die Systemkarte der Werkstatt.

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.

Arbeitsweise · wie eine Idee durch das System läuft

Drei Karten, drei Fragen
6 StationenWie läuft eine Idee durch das System?Arbeitsweise
5 SchichtenWoraus besteht das System funktional?Schichten
3 KernflüsseWie laufen Aufgabe, Wissen und Veröffentlichung durch das System?Kernflüsse
Arbeitsweise

Ein System, kein Werkzeugkasten.

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 DCO als sechste Station.

  1. Idee & Impuls

    Log-Vorfälle, Audits und der Backlog liefern den nächsten Einsatz — Ideen entstehen im Betrieb, nicht am Whiteboard.

    Vorfälle & Log
  2. Wissensbasis

    Obsidian-Wiki, durchsuchbare Wissensindizes (RAG) und Session-Memory halten den Kontext, den Agenten zum Arbeiten brauchen.

    living-vault
  3. Agenten

    Zwei Agenten, zwei Stärken: Claude denkt breit — Synthese, Architektur, Umsetzung. Codex setzt eng um und verifiziert. Jede substanzielle Änderung geht durch beide.

    dual-bridge
  4. Sichtbarkeit

    Hook-Events, Sessions und Kosten laufen live in Cockpits auf, statt in Logs zu versanden.

    Observatory
  5. Veröffentlichung

    Website, Case Studies und Werkstatt-Log machen Ergebnisse öffentlich prüfbar — und speisen neue Ideen zurück.

    Werkstatt-Log
  6. Steuerung (DCO)

    Der Orchestrator nimmt Aufträge an, verteilt sie auf Agenten und eskaliert über Approval-Gates — als Nabe die sechste, steuernde Station des Kreislaufs.

    DCO-Case-Study
Funktionale Schichten

Die Projekte bilden ein System aus fünf funktionalen Schichten.

Die 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.

/01

Orchestration

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.

DCOdual-bridgeDCO-CockpitDream-Team

Beweis Produktiv genutzter Orchestrator, dokumentierte Architektur, Test- und Changelog-Tiefe.

Grenze Persönliche lokale Systeme — kein öffentlicher SaaS-Dienst.

DCO-Aufgaben-Pipeline im Tour-Modus mit Beispieldaten; Aufnahme und Owner-Redaction-Check am 11.07.2026 freigegeben.
/02

Memory & Retrieval

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.

Agent-Memory-AtlasPrompt-Preludeagentic-osWissensbasisWiki-RAG

Beweis Claim-gebundener Capability-RAG, MCP-Server und harte Test-Suiten.

Grenze Wissensräume bleiben privat — öffentlich sind Architektur und kuratierte Slices.

136 Fähigkeiten · 22.145 Chunks · 1.949 Tests · mehrere kuratierte Vaults · automatischer Rebuild · Stand 14.07.2026

Im Detail: Wie das Gedächtnis funktioniert
Mobiler Ausschnitt derselben sanitisierten Recall-Abfrage; Aufnahme und Owner-Redaction-Check am 11.07.2026 freigegeben.
/03

Observability

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
Mobiler Trace-Ausschnitt mit synthetischen, public-safe Laufdaten; Aufnahme und Owner-Redaction-Check am 11.07.2026 freigegeben.
/04

Public Proof

Ü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.

/05

Experimentation

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).

evolabAgent-Lab-Vault

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

Kernflüsse

Drei Abläufe, ein System.

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.

Aufgabe → Ausführung

Eine Aufgabe wird priorisiert, mit Gedächtniskontext angereichert, ausgeführt und gegengeprüft; Learnings fließen zurück.

Wissen → Fähigkeitswahl

Kuratierte Quellen werden hybrid durchsuchbar; eine Agentenanfrage erhält belegte Treffer und wird zur passenden Fähigkeit geroutet.

Vollständiger Fluss, Recall-Beleg und Mechanik im Detail

Build → Review → Veröffentlichung

Claude und Codex bearbeiten und prüfen eine Änderung wechselseitig; erst nach Owner-Freigabe wird veröffentlicht und live geprüft.

Wissensbasis

Eine Quelle, die führt.

Die Wissensbasis ist der Boden unter allen Schichten. Drei Regeln bestimmen, wie Wissen hinein- und wieder herauskommt.

Private Quellen bleiben getrennt

Notizen, Entscheidungen und Rohmaterial liegen in eigenen Wissensräumen. Was wahr ist, gehört deshalb noch nicht automatisch auf die Website.

Der Atlas macht Inhalte auffindbar

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.

Öffentlich wird nur Freigegebenes

Die öffentlichen Seiten erhalten kuratierte, geprüfte Ausschnitte. Jede Freigabe ist ein bewusster Schritt, kein Automatismus.

Stand 14.07.2026Quelle Atlas Public ProjectionScope Wissensbasis · Snapshot public-20260714-052435119170

Wie die Wissensbasis im Alltag arbeitet — vom Sammeln über den Öffentlichkeitsfilter bis zum Abruf durch Agenten — zeigt das Agenten-Gedächtnis-Dossier

Guardrail-Prinzipien

Sicherheitsnetze sind Betriebslogik, kein Anhang.

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.

Datenminimierung

Öffentliche Seiten zeigen nur public-safe Inhalte. Private Nachweise, rohe Wiki-Inhalte und persönliche Dokumente gehören nicht in frei erreichbare Assets.

Zugriff mit Absicht

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.

Tool-Grenzen

MCP-Tools, Direct-Paths und Automationen bekommen klare Aufgaben, Grenzen und Approval-Punkte, bevor sie Daten verändern oder veröffentlichen.

Auditierbarkeit

Änderungen werden mit Tests, Changelogs, Live-Checks und Wiki-Todos nachvollziehbar gehalten, damit Entscheidungen später nicht aus dem Kontext fallen.

Deterministischer Stopp

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-Log

Praktisches 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.

Wer nach der Architektur den Werdegang dahinter einordnen möchte, findet ihn im Profil

Die Werkstatt ist offen.

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 Lab-Modus archiviert