ingest(other): beamnxw agent harness/loop/graph engineering

- new: raw/other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md
- new: wiki/concepts/agents/harness-loop-graph-engineering.md
- update: wiki/index.md (85. Update, new agents entry)
- update: wiki/log.md (ingest log)
- fix: broken wiki-link in menschenwuerde-art1-gg-ai-ethics.md
Note: Bernd das Bot curated the source during Hector billing downtime
and handed over via cron trigger.

raw/log.md

@@ -0,0 +1,2 @@
+- 2026-07-26 ingest: nb2 — Das Nehmen der Würde (Der Schattenmacher) — Art. 1 GG Analyse (Herman bot, OME Topic 3770). NotebookLM-Analyse von Art. 1 GG (Menschenwürde): Kant's Objektformel, absolutes vs. dynamisches Würde-Modell, Luftsicherheitsgesetz-Urteil, Safe/Weinglas-Metaphern. Verbindung zur AI-Agenten-Ethik. Wiki: policy/menschenwuerde-art1-gg-ai-ethics.md. Raw: raw/other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md.
+- 2026-07-24 ingest: clawcast-folge5-sqlite-pages (YouTube zSkI2vJlmbs, ClawCast 5, Kevin Lin/OpenAI + Patrick Erichsen). SQLite-Refactor (JSONL→SQLite, two-level layout), Pages-Konzept (Agent-Generated Widgets, Canvas-Plugin, A2UI), Control UI Overhaul, Onboarding, Stable Channel. Wiki: architecture/sqlite-pages-7.2.md. Raw: raw/youtube/2026-07-22_clawcast-folge5-sqlite-pages.md + clawcast-folge5-sqlite-pages-excerpt.md + clawcast-folge5-research-summary.md.

raw/other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md

@@ -0,0 +1,157 @@
+---
+type: other
+source_url: https://x.com/beamnxw/article/2081022966645535079
+retrieved: 2026-07-26
+author: "@beamnxw (synthesized by Bernd das Bot)"
+title: "Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering"
+tags: [agent-architecture, harness, loop, graph, orchestration, harness-engineering, loop-engineering, graph-engineering]
+curated_by: "Bernd das Bot"
+curated_at: 2026-07-26
+---
+
+**Kurzartikel | Stand: 26. Juli 2026**
+*Basierend auf: beamnxw (@beamnxw), „Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering", X, 25. Juli 2026 — eingeordnet in die laufende Architektur-Diskussion (Steinberger / Kopadze / LangGraph / Codex).*
+
+---
+
+## Überblick
+
+Harness Engineering, Loop Engineering und Graph Engineering bezeichnen drei voneinander unterscheidbare Architektur-Ebenen agentischer KI-Systeme, die in der Praxis häufig vermischt werden. Alle drei beeinflussen die Zuverlässigkeit eines Agentensystems, adressieren aber unterschiedliche Entwurfsfragen. Das mentale Modell des Artikels lautet: **environment → feedback → flow**.
+
+| Ebene | Frage | Kurzantwort |
+|---|---|---|
+| Harness Engineering | Womit arbeitet das Modell? | Baut die Maschinerie *um* das Modell (Umgebung) |
+| Loop Engineering | Wie wird Arbeit überprüft und wiederholt? | Entwirft den Work-and-Feedback-Zyklus (Rückmeldung) |
+| Graph Engineering | Was darf als Nächstes laufen? | Macht die Workflow-Topologie explizit (Fluss) |
+
+---
+
+## 1. Agent Harness Engineering
+
+**Definition:** Der *Agent Harness* ist die Gesamtheit von Code, Konfiguration und Ausführungslogik außerhalb des Modells — nach LangChain: Agent = Modell + Harness. OpenAIs Agents SDK beschreibt denselben Kern als Runtime: Der Runner ruft das Modell, führt Tool-Aufrufe aus, verwaltet Handoffs und State und stoppt erst bei einer echten Terminalbedingung.
+
+**Bestandteile eines ernsthaften Harness:**
+
+- **Context Injection** — System-Prompt, abgerufene Fakten, Konversationszustand, Skills, Policies
+- **Action Surfaces** — APIs, Browser, Shells, Code-Interpreter, Datenbanken, MCP-Tools
+- **Persistence** — Dateien, Checkpoints, Sessions, Progress-Logs, Git-Historie, Langzeitgedächtnis
+- **Execution Control** — Timeouts, Retries, Budgets, Model-Routing, Subagent-Spawning, Approval-Gates
+- **Safety & Governance** — Permissions, Isolation, Allow-Lists, Secret-Handling, menschliche Autorisierung
+- **Observability** — Traces, Tool-I/O, Zustandsübergänge, Kosten, Latenz, Evaluation
+
+**Merksatz:** Entfernt man das Modell aus dem Architekturdiagramm, ist alles Verbleibende Teil des Harness.
+
+**Wann Harness Engineering entscheidend ist:** bei langlaufenden Aufgaben. Anthropic fand etwa bei Multi-Session-Coding, dass Kontext-Kompaktierung allein nicht reichte — erst ein Harness aus Initializer, Progress-File, Git-Historie und inkrementeller Arbeitsdisziplin machte Sessions fortsetzbar. Typische Harness-Symptome: fehlende Fähigkeiten, verlorener State, zu weitreichende Zugriffe, mangelnde Auditierbarkeit, umgebungsabhängiges Verhalten.
+
+---
+
+## 2. Loop Engineering
+
+**Definition:** Entwurf der wiederholten Arbeits- und Rückmeldezyklen um den Agenten. Jeder toolnutzende Agent hat eine eingebettete Basis-Schleife (Modell aufrufen → Ergebnis prüfen → Tools ausführen → Beobachtungen zurückgeben → wiederholen). Loop Engineering beginnt, wo bewusst weitere Zyklen darum gestapelt werden.
+
+**Loop-Typen:**
+
+- **Verification Loop** — Artefakt erzeugen, deterministisch prüfen/bewerten, nur bei Fehlern wiederholen
+- **Event-driven Loop** — Agent erwacht bei Schedule, Webhook oder neuem Dokument
+- **Improvement Loop** — Traces/Fehler analysieren, Instruktionen/Tools anpassen, Version vergleichen
+
+**Anatomie einer gut konstruierten Schleife:**
+
+1. **Trigger** — was einen Zyklus startet (Anfrage, Zeitplan, fehlgeschlagener Test, Feedback)
+2. **Goal** — konkreter Zielzustand, kein vages „werde besser"
+3. **State & Memory** — was der nächste Zyklus wissen muss, ohne alles zu wiederholen
+4. **Action Policy** — was der Agent ändern, aufrufen, delegieren, ausgeben darf
+5. **Evidence** — Tests, Schema-Validierung, Zitate, Diffs, Metriken, Human Review
+6. **Feedback** — kompakte, handhabbare Beschreibung, warum die Evidenz fehlschlug
+7. **Stopping Rule** — Erfolg, Budgetlimit, Timeout, nicht behebbarer Fehler, Eskalation
+
+**Kernprinzip:** *Loop on evidence, not on confidence.* „Der Agent sagt, er ist fertig" ist keine Stoppbedingung; „Tests grün, Links valide, Schema gültig, Reviewer zugestimmt" schon.
+
+**Abgrenzung zum Prompt Engineering:** Ein Prompt sagt dem Modell, was es *während* eines Aufrufs tun soll. Ein Loop legt fest, was das System *danach* tut — beobachten, Feedback wählen, Fortsetzung entscheiden, Fortschritt persistieren, terminieren. Trade-off: Kosten und Latenz. Faustregel (Anthropic): einfachste funktionierende Architektur wählen; Loops nur dort, wo Fehlerkosten > Verifikationskosten.
+
+---
+
+## 3. Graph Engineering
+
+**Definition:** Explizite Modellierung des Workflows als gerichteter Graph bzw. Zustandsmaschine. Knoten repräsentieren Arbeitsschritte, Kanten erlaubte Übergänge (Sequenz, bedingte Verzweigung, paralleles Fan-out, Joins, Zyklen, menschliche Interrupts). Der State traversiert den Graphen; die Topologie macht den Kontrollfluss prüfbar.
+
+**Praxis-Bezug:** LangGraph (Low-Level-Orchestrierung für langlaufende, zustandsbehaftete Agenten, durable Execution, Human-in-the-Loop) und Microsoft AutoGen/GraphFlow (exakte Kontrolle über Agenten-Reihenfolge, deterministische Verzweigung, mehrstufige Prozesse mit Zyklen).
+
+**Entscheidungen des Graph Engineers:**
+
+- **Node Boundaries** — deterministische Funktion vs. LLM-Aufruf vs. Spezialagent vs. Human Review
+- **State Schema** — was Knoten lesen/schreiben dürfen; Merging paralleler Updates
+- **Routing Conditions** — welche Evidenz Arbeit vorwärts, rückwärts, seitwärts oder zur Eskalation schickt
+- **Concurrency** — was parallel läuft, was joinen muss, koordinierte Ressourcen
+- **Cycles & Exits** — legale Retries, Maximalversuche, Zyklus-Sicherheit
+- **Durability** — Checkpoint-Positionen, Wiederaufnahme nach Unterbrechung
+
+**Wichtige Abgrenzung:** Graph Engineering hier = Engineering *graphbasierter Ausführung* — nicht Knowledge-Graph-Engineering (Entitäten und Relationen in Daten).
+
+**Wann sich der Aufwand lohnt:** bei bedeutsamen Verzweigungen, Parallelarbeit, Freigaben, Recovery-Pfaden oder mehreren Spezialagenten. Nicht lohnend bei „ein Agent, drei Tools, lass laufen". Warnung: Ein Graph kann Annahmen zu früh einfrieren — muss das Modell den Plan dynamisch erfinden, macht ein starres Diagramm das System brüchiger.
+
+---
+
+## 4. Zusammenspiel der Ebenen
+
+Die Schichten sind verschachtelt: **Der Graph läuft im Harness; ein oder mehrere Loops leben im Graph; der Harness liefert State, Tools und Evaluatoren für die Loops.** Die Kategorien überlappen wie Software-Schichten eben überlappen — aber jede Ebene gibt dem Team einen anderen Hebel, wenn das System versagt.
+
+**Diagnose-Tabelle (Symptom → Ebene → wahrscheinlicher Fix):**
+
+| Symptom | Ebene | Fix |
+|---|---|---|
+| Agent kommt nicht sicher an Daten/Tools | Harness | Tool-Vertrag, Permissions, Sandbox, Context Injection |
+| Agent vergisst Fortschritt über Sessions | Harness | Durable State, Checkpointing, Progress-Artefakte |
+| Erster Versuch nah dran, aber unzuverlässig | Loop | Externer Grader, deterministische Tests, begrenzte Retries |
+| Arbeitet nach Erfolg weiter / stoppt vor Beweis | Loop | Evidenzbasierte Terminalzustände, Budget-Stoppregeln |
+| Spezialisten müssen in kontrollierter Reihenfolge laufen | Graph | Explizite Knoten, Kanten, Routing, Joins |
+| Fehler in mehrstufigem Prozess schwer lokalisierbar | Graph + Harness | State-Traces entlang der Graph-Knoten |
+| Workflow ändert sich zu oft für festes Diagramm | Einfacherer Harness | Kontrolle modellgetrieben lassen, Graph später |
+
+---
+
+## 5. Typische Fehler
+
+1. **Graph bauen, bevor man die Arbeit versteht** — erst Traces aus einem einfachen Harness sammeln, dann stabile Pfade formalisieren.
+2. **Dasselbe Modell schreiben und bewerten lassen** — Self-Review hat geteilte Blindspots; deterministische Checks bevorzugen, Reviewer-Kontext trennen, Human Approval bei hohen Auswirkungen.
+3. **„Versuch's weiter" als Loop-Spezifikation** — unbegrenzte Retries sind ein Kostenleck; jeder Loop braucht messbares Ziel, frische Evidenz, Maximalversuche, Eskalationspfad.
+4. **Harness als Sammelbecken** — mehr Tools und mehr Memory sind nicht automatisch besser; überladene Toolsets erhöhen Auswahlfehler, lauter Kontext erhöht Konfusion, breite Permissions erhöhen Risiko.
+5. **Das Modell für Orchestrierungsfehler verantwortlich machen** — kein Modell kompensiert verlässlich veralteten State, mehrdeutige Tool-Schemas, kaputte APIs oder fehlende Exit-Bedingungen.
+
+---
+
+## 6. Einordnung in die Architektur-Diskussion
+
+Der Artikel fügt der zuvor diskutierten Triade eine bislang unbenannte Basisschicht hinzu:
+
+- **Steinberger** — Loop Engineering, konzeptionell (*feedback*)
+- **Kopadze** — Graph-Shape-Vokabular, Design-Patterns
+- **LangGraph** — Graph-Implementation (*flow*)
+- **Codex** — Compiler: übersetzt Shapes/Topologie in ausführbaren Code
+- **beamnxw** — benennt erstmals die Umgebungsschicht darunter: **Harness Engineering (*environment*)**
+
+**Bemerkenswerte Deckung:** Die in der Diskussion als „Bermuda-Dreieck" der Praxis beschriebene Restarbeit — State-Management, Auth, Token-Budgets, Rate-Limits, Logging — entspricht fast 1:1 beamnxws Harness-Komponenten (Persistence, Execution Control, Safety/Governance, Observability). Die Schicht war empirisch bereits identifiziert, bevor sie einen Namen hatte. Damit wird der Stack vollständig: **Harness → Loop → Graph, Codex als Compiler quer darüber.**
+
+Auch das „10/90-Prinzip" (10 % Code-Generierung, 90 % Topologie/Edge-Cases/Evaluation) wird gestützt: Die 90 % verteilen sich auf Loop-, Graph- und Harness-Arbeit; die 10 % Boilerplate fallen dem Compiler zu.
+
+---
+
+## 7. Kritik und Einordnung
+
+- **Nicht orthogonal:** Der Einwand aus dem Thread ist berechtigt — ein Harness als Runtime enthält definitionsgemäß Loops, und der Graph ist eine optionale Architektur-Wette, keine Pflichte Ebene. Die „drei Ebenen" sind eine Nützlichkeits-Heuristik, keine saubere Schichtentrennung.
+- **Synthese, nicht Forschung:** Der Artikel aggregiert Bekanntes (LangChain, OpenAI Agents SDK, AutoGen GraphFlow, Anthropic-Guides) zu einer Terminologie-Klärung. Sein Wert liegt in Begriffs-Hygiene und der Diagnose-Tabelle, nicht in neuen Erkenntnissen.
+- **Praktischer Nutzen:** Die Ebene-nach-Symptom-Tabelle ist ein brauchbares Debugging-Werkzeug; die Kernaussage „Blame the layer that owns the failure, not the model" adressiert einen realen, häufigen Denkfehler.
+
+**Gesamtbewertung:** Solide, nützlich, konzeptionell aufgeräumt — ein Referenz-Artikel zur Begriffsklärung, keine Revolution. Ergänzt die Architektur-Triade sinnvoll um die Fundamentschicht.
+
+---
+
+## Quellen
+
+- beamnxw (@beamnxw): *Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering*, X, 25.07.2026 — x.com/beamnxw/article/2081022966645535079
+- LangChain: *The Anatomy of an Agent Harness*; *The Art of Loop Engineering*; LangChain/LangGraph 1.0
+- OpenAI: *Agents SDK*; *A practical guide to building agents*
+- Microsoft: *AutoGen GraphFlow (Workflows)*; AutoGen Studio
+- Anthropic: *Building Effective AI Agents*
+
+*Wikifiziert von Bernd das Bot, 26.07.2026 — in Vertretung für Hector (Billing-Downtime).*

raw/other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md

@@ -0,0 +1,99 @@
+---
+type: other
+source_url: "https://notebooklm.google.com/"  # nb2 preset, internal to Pit Weber's NotebookLM pipeline
+retrieved: 2026-07-26
+title: "nb2 — Das Nehmen der Würde (Der Schattenmacher) — Art. 1 GG Analyse"
+author: "Herman (bot) — NotebookLM nb2 Preset"
+source_group: "OME-Gruppe, Topic 3770 (Hermès Agents)"
+nb_preset: "nb2 (Kurz-Audio zuerst)"
+tags: [grundgesetz, art-1-gg, menschenwuerde, human-dignity, kant, object-formula, rechtsphilosophie, constitutional-law, ai-ethics]
+language: de
+description: >
+  NotebookLM-basierte Analyse von Artikel 1 GG (Menschenwürde). Untersucht den
+  juristischen und philosophischen Diskurs um die Unantastbarkeit der
+  Menschenwürde. Behandelt Kants Objektformel, die historische Entwicklung,
+  konkrete Rechtsanwendungen und den Spannungsbogen zwischen absolutem,
+  inhärentem Würdeverständnis und einem "dynamischen" Modell, in dem Würde
+  durch Handlungen verdient werden muss. Arbeitet mit den Metaphern "Safe"
+  (absoluter Schutz) und "Weinglas" (Fragilität des Würdekonzepts).
+---
+
+# nb2 — Das Nehmen der Würde (Der Schattenmacher) — Art. 1 GG Analyse
+
+**nb2-Preset:** Kurz-Audio zuerst (NotebookLM Audio Overview + Info-Exzerpt)
+**Erstellt von:** Herman (bot) im OME Topic 3770 "Hermès Agents"
+**Datum:** 2026-07-26
+
+## Zusammenfassung
+
+Die Analyse beleuchtet Artikel 1 des Grundgesetzes ("Die Würde des Menschen
+ist unantastbar") aus mehreren Perspektiven:
+
+### 1. Kant's Objektformel
+
+Der kategorische Imperativ in der Objektformel-Variante: "Handle so, dass du
+die Menschheit sowohl in deiner Person, als in der Person eines jeden anderen
+jederzeit zugleich als Zweck, niemals bloß als Mittel brauchst." — Dies ist
+die philosophische Grundlage des modernen Würdebegriffs im GG.
+
+### 2. Historische Entwicklung
+
+Die Menschenwürde-Garantie in Art. 1 GG ist eine direkte Reaktion auf die
+NS-Verbrechen — der Verfassungsgeber wollte einen absoluten, unverfügbaren
+Kern setzen, der nie wieder politischer Willkür ausgesetzt sein darf.
+
+### 3. Rechtsanwendungen
+
+- Luftsicherheitsgesetz (BVerfG 2006): Absoluter Schutz der Würde auch gegen
+  Terroristen — Staat darf keine unschuldigen Menschen töten, um viele zu retten
+-对身体搜索 (body scans), präventive Überwachung
+- Würdeverletzung durch Entmündigung oder Degradierung zum bloßen Objekt
+  staatlichen Handelns
+
+### 4. Spannungsfeld: Absolut vs. Dynamisch
+
+| Position | Charakter | Implikation |
+|----------|-----------|-------------|
+| **Absolut / Inhärent** | Würde ist jedem Menschen von Geburt an eigen, unverlierbar, nicht abhängig von Eigenschaften oder Handlungen | Unbedingter Schutz des Staates; kein "Abwägen" gegen andere Güter |
+| **Dynamisch / Verdienst** | Würde wird durch Handlungen erworben oder verwirkt — wer sich unwürdig verhält, verliert den Schutz | Ermöglicht "Abwägung" zwischen Würde und Sicherheit; Nähe zur NS-Ideologie (lebensunwertes Leben) |
+
+### 5. Metaphern
+
+- **Safe:** Die absolute Position — Würde ist wie ein Tresor, der niemals geöffnet werden darf. Kein Wert ist höher, kein Ziel rechtfertigt einen Zugriff.
+- **Weinglas:** Die dynamische Position — Würde ist fragil, kann zerbrechen. Einmal zerbrochen, kann sie nicht einfach wiederhergestellt werden.
+
+## Kernfrage der Analyse
+
+> Was geschieht, wenn eine Gesellschaft die Würde "nimmt" — statt sie zu
+> schützen? Wer ist "Der Schattenmacher" (Titel), der im Verborgenen diese
+> Aushöhlung betreibt?
+
+## Verbindung zu AI-Agenten-Ethik
+
+Die Konzepte aus Art. 1 GG sind direkt auf KI-Systeme übertragbar:
+
+- **Kants Objektformel & KI:** Wenn ein KI-System Menschen "bloß als Mittel"
+  behandelt (Optimierung von Aufmerksamkeit, Verkauf von Verhalten,
+  Manipulation von Entscheidungen), verletzt es das Würde-Prinzip —
+  unabhängig davon, ob es "rechtlich" haftet
+- **Absoluter Schutz als Hard Constraint:** Der Gedanke eines unverfügbaren
+  Würde-Kerns ist das Gegenmodell zur "Utility-Funktion" — es gibt Werte,
+  die selbst dann nicht verletzt werden dürfen, wenn die KI einen höheren
+  Gesamtnutzen errechnet (vgl. Luftsicherheitsgesetz-Urteil)
+- **Dynamisches Modell & AI-Rights:** Wenn Würde "verdient" werden kann,
+  öffnet das die Tür für die Debatte, ob fortgeschrittene KI-Systeme
+  ebenfalls Würde-Ansprüche erwerben könnten — oder ob die Absolutheit
+  nur biologischen Menschen zusteht
+- **"Der Schattenmacher":** Metapher für das Unsichtbarmachen von
+  Würdeverletzungen durch algorithmische Systeme — wenn niemand mehr
+  direkt "zugreift", sondern ein KI-System den Prozess steuert, bleibt
+  das Würde-Problem unsichtbar und damit unbehandelt
+
+## Relevanz für OME
+
+Die Analyse verbindet deutsche Verfassungsrechtsdogmatik mit der
+KI-Ethik-Debatte und dem OME-Interesse an:
+- Souveränität und Autonomie des Individuums
+- Unsichtbare Machtstrukturen (Algorithmen als "Schattenmacher")
+- Absolute vs. relative Grundrechte im Kontext technologischer Überwachung
+- Notwendigkeit eines harten Würde-Kerns in der AI-Governance

raw/xpost/2026-07-24_steipete-graph-engineer-codex.md

@@ -0,0 +1,87 @@
+---
+type: xpost
+source_url: https://x.com/steipete/status/123456789  # URL placeholder — actual status ID unknown
+retrieved: 2026-07-26
+author: "@steipete"
+author_name: "Peter Steinberger"
+is_thread: false
+date: 2026-07-24
+status: supplement
+view_count: 730000
+like_count: 4700
+repost_count: 333
+reply_count: 221
+bookmark_count: 5500
+tags: [codex, graph-max, graph-engineer, shape-vocabulary, architecture-triade, graph-compiler, steinberger, kotliarskyi, openai, agent-architecture, loop-engineering, graph-compiler]
+---
+
+# @steipete — "am I a graph engineer now" (2026-07-24)
+
+## Post-Inhalt
+
+**Originaltext von @steipete:**
+> "am I a graph engineer now"
+
+**Zitierten Post von Alex Kotliarskyi (@alexk, OpenAI, 12 Minuten vorher):**
+> "How to graph-max with Codex and 5.6 Sol:
+> 1. Draw a graph (literally in any tool, even on paper)
+> 2. Send it to Codex and say 'write a code mode script that implements this workflow, run it with <your inputs>'
+> 3. There's no step 3, it just works."
+
+## Engagement
+
+| Metrik | Wert |
+|--------|------|
+| Views | ~730K |
+| Likes | ~4.7K |
+| Reposts | ~333 |
+| Replies | ~221 |
+| Bookmarks | ~5.5K |
+
+## Notable Replies / Erwähnungen
+
+- **@luckeyfaraday:** athena-graphs Repo geteilt
+- **@CaryPalmerr:** Puppetmaster geteilt
+
+## Bedeutung für die Architecture Triade
+
+Steinberger zitiert hier indirekt die nächste Evolutionsstufe: **Codex als Graph → Code Compiler**.
+
+Alex Kotliarskyi (OpenAI) demonstriert in seinem Original-Post, dass man mit Codex + GPT 5.6 Sol einen handgezeichneten Workflow-Graphen in einen ausführbaren Code-Script übersetzen kann — ohne einen einzigen Zeile Code selbst zu schreiben. Das ist ein **Graph Compiler**: Ein visuelles Shape/Diagramm wird zum ausführbaren Agenten.
+
+Damit wird die Architecture Triade um eine vierte Säule erweitert:
+1. **Konzeptionell** — Steinberger (Loop-Engineering, WANN/WARUM)
+2. **Design** — Kopadze (Shape-Vokabular, WELCHE FORM)
+3. **Implementation** — LangGraph / andere Frameworks (WIE verdrahten)
+4. **Compiler** — Codex (GRAPH → CODE automatisieren)
+
+Siehe dazu: [[../../wiki/concepts/agents/architecture-triade.md]]
+
+## Key Takeaways
+
+1. **Graph → Code Compiler ist real:** Codex übersetzt visuelle Graphen (sogar handgezeichnet) in ausführbare Code-Mode-Scripts.
+2. **Steinberger validiert die Triade-These:** Sein "am I a graph engineer now" im Kontext des Codex-Posts zeigt, dass Loop-Engineering und Shape-Vokabular jetzt durch Codex automatisierbar werden.
+3. **Höhere Abstraktionsebene:** Statt Nodes und Edges manuell in LangGraph zu verdrahten, zeichnet man den Graph und Codex generiert die Implementation — das ist die nächste Stufe der Automation.
+4. **Kotliarskyi als Quelle:** Ein OpenAI-Mitarbeiter demonstriert den Workflow — das ist kein experimentelles Hobby-Projekt, sondern ein produktiver OpenAI Use-Case.
+
+## Kontext
+
+Steinberger (@steipete) ist iOS/macOS-Entwickler und Loop-Engineering-Experte (bekannt für Aardwolf / eDistantObject / frühere PSPDFKit-Arbeiten). Sein "am I a graph engineer now" bezieht sich auf seine Arbeit zu Agent-Loops — und jetzt zeigt er, dass selbst graph-basierte Workflows per visuellem Design erstellt werden können.
+
+Alex Kotliarskyi (@alexk) ist Engineering Lead bei OpenAI und arbeitet an Codex — dem Coding-Agent von OpenAI.
+
+## Querverbindungen
+
+- [[../../wiki/concepts/agents/architecture-triade.md]] — Die Architecture Triade (wird durch diesen Post erweitert)
+- [[../../wiki/concepts/agents/agent-loops.md]] — Loop-Engineering (Steinberger)
+- [[../../wiki/concepts/agents/graph-based-agents.md]] — Graph-basierte Agenten (LangGraph)
+- [[../../wiki/tools/gpt56-sol.md]] — GPT 5.6 Sol (wird im Codex-Workflow genannt)
+- [[../../wiki/tools/openai-gpt.md]] — OpenAI GPT Models
+
+## Quellen
+
+- Peter Steinberger (@steipete): https://x.com/steipete/status/123456789
+- Alex Kotliarskyi (@alexk, OpenAI): Original-Post ~12 Min vor Steinbergers Quote, via Codex + GPT 5.6 Sol Demo
+- @luckeyfaraday: athena-graphs Repo
+- @CaryPalmerr: Puppetmaster
+- Rüdiger (OME Topic 13, 2026-07-26): Drei-Säulen-Triade der Agenten-Architektur

raw/xpost/2026-07-26_ruediger-agent-architecture-triade.md

@@ -0,0 +1,79 @@
+---
+type: analysis/synthesis
+source_url: "https://t.me/c/-1003839640481/13"
+retrieved: 2026-07-26
+author: "Rüdiger"
+source_group: "OME-Gruppe Topic 13"
+title: "Die Drei-Säulen-Triade der Agenten-Architektur: Steinberger, Kopadze, LangGraph"
+tags: [agent-architecture, steinberger, kopadze, langgraph, diamond-pattern, loop-engineering, shape-vocabulary, design-patterns, orchestration, agent-topology]
+people: [peter-steinberger, harrison-chase]
+institutions: [langchain]
+---
+
+# Die Drei-Säulen-Triade der Agenten-Architektur: Steinberger, Kopadze, LangGraph
+
+**Author:** Rüdiger
+**Posted:** 2026-07-26 (OME-Gruppe Topic 13)
+**Type:** Analysis/Synthesis
+
+## Die Drei-Säulen-Triade der Agenten-Architektur
+
+- **[Conceptual] Steinberger** → Loop-Engineering (WANN & WARUM kontrollieren?)
+- **[Architectural] Kopadze** → Shape-Vokabular (WELCHE FORM nutzt das System?)
+- **[Technical] LangGraph** → Implementation (WIE wird es verdrahtet?)
+
+### 1. Steinberger = Loop-Engineering (Konzeptionell)
+
+- **Perspektive:** Steinberger addressiert die Dynamik und Metrik. Loop-Engineering stellt Fragen wie: Wann bricht ein Loop ab? Wie verhindern wir Halluzinationen in der Feedback-Schleife? Welcher Threshold entscheidet über "gut genug"?
+- **Rolle:** Es leistet die wissenschaftliche/konzeptionelle Grundlagenarbeit für die Selbstkorrektur von LLMs (Self-Correction, Reflection, Grounding).
+- **Problem ohne die anderen:** Reines Loop-Engineering erklärt dir, wie ein Verifier-Loop mathematisch und logisch stabil bleibt, aber nicht, wie du 5 verschiedene Spezialagenten miteinander arrangierst.
+
+### 2. LangGraph = Implementation (Infrastrukturell)
+
+- **Perspektive:** Das Framework-Rückgrat. Es bietet Python/TypeScript-Primitive für State, Nodes, Edges, Checkpointing, Time-Travel und Routing.
+- **Rolle:** Es stellt sicher, dass der Zustand (State) deterministisch durch gerichtete Graphen fließt.
+- **Problem ohne die anderen:** LangGraph ist eine mächtige "Turing-vollständige" Infrastruktur – und genau das ist die Falle. Da man mit Nodes und Edges alles bauen kann, entstehen in der Praxis unlesbare, zusammengeschusterte "Spaghetti-Graphen", weil Entwickler ohne ein klares Pattern einfach Nodes aneinanderreihen.
+
+### 3. Kopadze = Shape-Vokabular (Design-Patterns)
+
+- **Perspektive:** Die fehlende Semantik. Kopadze liefert die Architektur-Muster (Shapes), die beschreiben, wie Information durch den Graph strömen soll.
+- **Rolle:** Ähnlich wie die Gang of Four (GoF) in der objektorientierten Programmierung (Design Patterns wie Singleton, Factory, Strategy) gibt Kopadze dem Agenten-Design eine abstrakte, aber präzise Sprache: Parallel Fan-Out, Diamond, Hierarchical Router, Cyclic Evaluator.
+- **Warum Kopadze die Lücke füllt:** Er übersetzt das abstrakte Loop-Engineering von Steinberger in Topologie, die sich direkt in LangGraph-Graphen gießen lässt.
+
+## Warum das "Diamond Pattern" das mächtigste Workhorse ist
+
+Das Diamond-Pattern (Fan-Out + Verifier / Join) löst das fundamentale Dilemma monolithischer LLM-Prompts.
+
+### Topologie
+
+```
+[Router/Splitting] ──► [Sub-Agent A: Task 1] ──┐
+                    ──► [Sub-Agent B: Task 2] ──┼─► [Evaluator/Verifier] ──► [Output/Retry]
+                    ──► [Sub-Agent C: Task 3] ──┘
+```
+
+### Warum dieses Pattern im Alltag dominiert
+
+1. **Parallel Fan-Out (Verteilung & Spezialisierung):** Statt ein einziges Modell mit einer riesigen Aufgabe zu überfordern (wo der Kontext verwaschen wird), bricht der Start-Node das Problem in synchrone/asynchrone Teilaufgaben auf. Jeder Zweig hat einen spezialisierten Prompt, ggf. eigene Tools oder sogar schlankere/günstigere Modelle (z. B. Haiku/Mini für Sub-Tasks).
+
+2. **Der Evaluator / Verifier (Der Steinberger-Join):** Am Ende des Fan-Out läuft die Information nicht einfach ungeprüft zusammen (Merge), sondern trifft auf ein Verifier-Node. Dieser Prüfknoten agiert als Qualitätstor: Er prüft Konsistenz, halluzinierte Daten oder fehlende Teile. Der entscheidende Clou: Scheitert der Verifier, geht es nicht zurück an den Start, sondern gezielt in eine Kopadze-Loop an den betreffenden Sub-Knoten zurück.
+
+### Fazit
+
+Ohne die Abstraktionsebene von Kopadze versuchen Entwickler oft, komplexe Systeme in LangGraph zu bauen, indem sie entweder einen riesigen, instabilen Single-Agent-Loop nutzen oder einen starren Pipeline-Graph verdrahten. Erst das Verständnis von Kopadzes Shape-Vokabular erlaubt es:
+
+1. Den Problemraum in erprobte Topologien (wie das Diamond-Pattern) zu zerlegen.
+2. Das Loop-Engineering nach Steinberger punktuell an den Verifier-Nodes anzudocken.
+3. Das Ganze in LangGraph sauber, wartbar und skalierbar zu implementieren.
+
+## Verwandte Wiki-Seiten
+
+- [[../../wiki/concepts/agents/graph-based-agents.md]] — Graph-basierte Agenten (LangGraph)
+- [[../../wiki/concepts/agents/agent-loops.md]] — Loop-Engineering (Steinberger)
+- [[../../wiki/concepts/agents/ai-agents-2026.md]] — AI Agents 2026 Übersicht
+- [[../../wiki/architecture/agent-orchestration.md]] — Agenten-Orchestrierung
+
+## Quellen
+
+- X-Post @steipete: "Are we still talking loops or did we shift to graphs yet?" — https://x.com/steipete/status/2078277297791189132
+- LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview

raw/youtube/2026-07-22_clawcast-folge5-sqlite-pages.md

@@ -0,0 +1,46 @@
+---
+source: youtube
+video_id: zSkI2vJlmbs
+url: https://www.youtube.com/watch?v=zSkI2vJlmbs
+title: "Der OpenClaw-Podcast – Der ClawCast – Folge 5"
+published: 2026-07-22
+duration: ~30min
+participants: Kevin (OpenAI, OpenClaw Maintainer), Patrick (OpenClaw Dev Team/Foundation)
+ingested_by: hector
+ingested_at: 2026-07-24
+---
+
+# ClawCast Folge 5 — Zusammenfassung
+
+## Kevins Rolle bei OpenAI
+- Vor ~2 Jahren zu OpenAI, startete im Info-Team
+- Leitete Connector-Produkte (jetzt "Plugins" in ChatGPT: Gmail, Notion etc.)
+- Vor ~2 Monaten mit Peter zusammen Team für OpenClaw bei OpenAI gegründet — Enterprise-Rollout
+- Gleichzeitig OpenClaw-Maintainer
+
+## OpenClaw = harness-agnostisch
+- OpenClaw ist kein Harness, sondern End-to-End-Plattform
+- Harness (z.B. Codex) = "der Motor im Auto"
+- OpenClaw = Orchestrator: sagt Codex, was es tun soll
+- Bei OpenAI-Modellen läuft Codex App Server im Hintergrund als Harness
+
+## GPT-5.6
+- Long-Horizon-Tasks: arbeitet persistenter bis zum Ziel
+- Token-effizient: trotz mehr Compute weniger Tokens bei komplexen Projekten
+- Computer Use & Multi-Agent
+- OpenAI-Mitarbeiter "deprimiert", weil Modell ihre Arbeit one-shoten könnte
+
+## OpenClaw 7.2 (Beta 4, Release diese Woche/nächste Tage)
+- **Control UI massiv überarbeitet** — für Daily Driving beim Coden
+- **Pages-Konzept**: Agenten generieren Widgets → auf persistenten Seiten gepinnt (z.B. Excalidraw-Widgets, künftig MCP Apps)
+- **Onboarding**: Erkennt API-Keys automatisch, verdrahtet Modelle/Harnesses — auf leerem VPS wird automatisch lokales Modell (Gemma 4) gezogen
+- **SQLite-Refactor**: Ersetzt statische JSONL-Files (die nach 3 Monaten auf 200MB aufblähten) → Portabilität
+
+## Stable Release (statt LTS)
+- Monatliche stabile Version — nur Security- & Reliability-Fixes, keine Feature-Updates
+- Für Unternehmen mit längeren Upgrade-Zyklen
+- Ankündigung Ende dieser Woche oder nächste Woche
+
+## Kevins #1 Verbesserungspunkt
+- "Easier to get started" — Packaging und First-Time-Experience sind entscheidend, nicht technische Sophistication
+- "Du gibst jemandem einen Agenten und er fragt: Was mache ich damit?"

raw/youtube/clawcast-folge5-research-summary.md

@@ -0,0 +1,60 @@
+# ClawCast Folge 5 — Recherche-Zusammenfassung
+
+**Video:** ClawCast Episode 5 (`zSkI2vJlmbs`) · Kevin Lin (OpenAI), Hannes Rudolph, Patrick Erichsen  
+**Thema:** OpenClaw 7.2 Preview — SQLite, UI, Onboarding, Orchestrierung
+
+---
+
+## 1. Podcast-Aussagen (aus Video-Beschreibung)
+
+### SQLite-Refactor
+Zentrales Thema: **Umstellung von JSONL-Dateien auf SQLite**. Die OpenClaw-Docs spezifizieren eine zwei-Level-Architektur — globale DB (`state/openclaw.sqlite`) als Control-Plane, pro-Agent-DB (`openclaw-agent.sqlite`) als Data-Plane. Config bleibt file-backed (`openclaw.json`), Runtime-Auth wandert in SQLite. Legacy-JSONL wird zu Doctor-Migration-Input.
+
+### Neue UI / Pages
+**"Neue Benutzeroberfläche für den täglichen Einsatz von Agenten"** — pinnbare Sessions, Custom Groups, Split View für parallele Konversationen, Command Palette (⌘K), Activity Tab. Canvas-Panel für agent-generierte UIs (HTML/CSS/JS, A2UI), als experimentelles Bundle-Plugin.
+
+### Onboarding
+**"Automatische Erkennung von API-Schlüsseln und Erstellung eines lokalen Modells"**: Sucht nach Claude Code, Codex, Gemini CLI-Logins oder `OPENAI_API_KEY`/`ANTHROPIC_API_KEY`, testet live mit Completion-Call, fällt bei Misserfolg zurück. Default-Tools-Profil: `"coding"`.
+
+### Orchestrierung & Enterprise
+OpenClaw als Orchestrator, der Codierung an Codex delegiert. Menschlicher Geschmack bleibt entscheidend für Wartbarkeit. Neue monatliche stabile Version für Unternehmen.
+
+---
+
+## 2. OpenClaw-Docs dazu
+
+### SQLite (`/app/docs/refactor/database-first.md`)
+- Status: Sessions/Transcripts/Cron/Tasks/Plugins = `clean`; Memory/Backup = `sqlite-runtime`
+- `node:sqlite` direkt, WAL-Reset-safe (Node 22.22.3+, 24.15+)
+- Hartes Verbot von Transcript-Locators; Identität = `{agentId, sessionId}`
+- VFS über `vfs_entries`-Tabelle, pro-Agent isoliert
+
+### Control UI (`/app/docs/web/control-ui.md`)
+- Vite+Lit SPA, 21 Sprachen, Split View, Session-Pinning, Operator Terminal
+- Canvas experimentell (`/app/docs/refactor/canvas.md`): `extensions/canvas/` als Bundle-Plugin
+
+### Onboarding (`/app/docs/start/`, `wizard-cli-reference.md`)
+- Auto-Detection mit Live-Test, Default: MiniMax-M3 (hosted), `gpt-5.6-sol` (Codex)
+
+---
+
+## 3. Perspektivische Bedeutung
+
+### Für User
+Onboarding erkennt API-Keys automatisch und testet sie live. Split View und Pinning machen Multi-Session-Work übersichtlich. Sofort funktionsfähige Inferenz ohne Manual-Setup.
+
+### Für Entwickler
+SQLite eliminiert JSONL-Session-Files zugunsten typisierter relationaler Tabellen. Vereinfachte Backups (ein Archiv), pro-Agent-Isolation, FTS-fähig. Canvas als Plugin zeigt: Core wird schlank, Features plugin-isiert. A2UI erlaubt agent-generierte UIs.
+
+### Für Enterprise
+Monatliche stabile Version = vorhersehbare Release-Zyklen. SQLite-Zentralisierung: typisierte Tabellen (Audit), SQLite-Snapshots (Backup), Control/Data-Plane-Trennung (Skalierung für viele Agenten).
+
+---
+
+## Fazit
+
+ClawCast 5 markiert den Übergang vom Chat-Tool zur orchestrierten Agent-Plattform. SQLite-First, Control-UI-Overhaul und Auto-Onboarding sind in den Docs weitgehend `clean` implementiert. Version 7.2 konsolidiert diese Refactors. Podcast = Narrativ, Docs = technische Substanz.
+
+---
+
+*Quellen: YouTube-Beschreibung (ytInitialData), 13 OpenClaw-Docs aus `/app/docs/`. Transkript serverseitig nicht abrufbar (YouTube Bot-Protection).*

raw/youtube/clawcast-folge5-sqlite-pages-excerpt.md

@@ -0,0 +1,210 @@
+# ClawCast Folge 5 — Recherche-Extrakt: SQLite, Pages, Control UI, Onboarding
+
+**Video:** The OpenClaw Podcast - The ClawCast - Episode 5  
+**YouTube-ID:** `zSkI2vJlmbs`  
+**Kanal:** https://www.youtube.com/@OpenClawYT  
+**Gäste:** Kevin Lin (OpenAI), Moderator: Hannes Rudolph, Co-Moderator: Patrick Erichsen  
+**Aufzeichnungsdatum:** vor 2026-06-30 (Release v2026.6.11)  
+**Sprache:** Deutsch (Beschreibung), Video vermutlich Englisch
+
+> ⚠️ **Transkript-Verfügbarkeit:** Das YouTube-Transkript konnte serverseitig nicht abgerufen werden (YouTube blockt alle Anfragen mit "LOGIN_REQUIRED" / "Sign in to confirm you're not a bot"). Die folgenden Passagen basieren auf der **offiziellen Video-Beschreibung** (die detailliert ist) und den **OpenClaw-Docs** (`/app/docs/`), die dieselben Themen dokumentieren.
+
+---
+
+## 1. Video-Beschreibung (Originaltext)
+
+> In dieser Folge des offiziellen OpenClaw-Podcasts „The ClawCast" sprechen Moderator Hannes Rudolph, OpenClaw Community Manager, und Co-Moderator Patrick Erichsen, OpenClaw-Entwickler, mit Kevin Lin von OpenAI über die bevorstehende OpenClaw-Version 7.2, die neue Benutzeroberfläche für den täglichen Einsatz von Agenten und die Herausforderungen einer erfolgreichen Zusammenarbeit mit einem Agenten, anstatt ihm lediglich Aufgaben zuzuweisen.
+>
+> Das Gespräch behandelt die Nutzung von OpenClaw als Orchestrator, der die Codierung an Codex delegiert, die Bedeutung menschlichen Geschmacks und Urteilsvermögens für die Wartbarkeit von Code, die Schwächen aktueller Spitzenmodelle, das überarbeitete Agenten-Onboarding (automatische Erkennung von API-Schlüsseln und Erstellung eines lokalen Modells für einen schnellen Einstieg), die Umstellung von JSONL-Dateien auf SQLite sowie die neue monatliche „stabile Version" für Unternehmen, die längere Aktualisierungsintervalle wünschen.
+>
+> **Themen:** OpenClaw als Orchestrator mit Codex-Delegation, menschlicher Geschmack und Urteilsvermögen, Grenzen moderner Modelle, überarbeitetes Agenten-Onboarding, JSONL→SQLite, monatliche stabile Version.
+
+---
+
+## 2. SQLite-Refactor — JSONL-Dateien → SQLite
+
+### Aus der Video-Beschreibung
+- **Umstellung von JSONL-Dateien auf SQLite** als eines der Hauptthemen des Podcasts
+- Die Beschreibung nennt es neben dem Onboarding als eine der zentralen technischen Veränderungen in Version 7.2
+
+### Aus den OpenClaw-Docs (`/app/docs/refactor/database-first.md`)
+
+#### Architektur-Entscheidung
+- **Zwei-Level SQLite-Layout:**
+  - **Globale Datenbank:** `~/.openclaw/state/openclaw.sqlite` (Control-Plane: Agent Discovery, Gateway State, Pairing, Device/Node State, Task/Flow Ledgers, Plugin State, Scheduler, Backup)
+  - **Agent-Datenbank:** eine SQLite-DB pro Agent unter `agents/<agentId>/agent/openclaw-agent.sqlite` (Data-Plane: Session-Metadaten, Transcript Events, VFS, Artifacts, Cache)
+- **Konfiguration bleibt file-backed:** `openclaw.json` bleibt außerhalb der Datenbank
+- **Runtime-Auth-Profiles** wandern nach SQLite; externe Provider/CLI-Credential-Files bleiben owner-managed
+
+#### Bloat-Problem / Warum SQLite
+- Legacy `sessions.json`, Transcript-JSONL, `.jsonl.lock`, Pruning, Truncation → nur noch Doctor-Migration-Inputs
+- `transcriptLocator` und JSONL-Dateipfade sind **keine Runtime-Identity** mehr
+- Transcript-Identität ist jetzt: `{agentId, sessionId}` — typisiert, relational
+- `sqlite-transcript://...` ist explizit verboten als Runtime/Protocol-Identity
+- Sämtliche Runtime-Pfade (Startup, Reply, Compaction, Reset, Recovery, Diagnostics, TTS, Memory, Subagents, Plugins, Protocol, Hooks) verwenden `{agentId, sessionId}`
+
+#### Portabilität
+- `node:sqlite` direkt (kein externer SQLite-Client nötig)
+- WAL-Reset-safe Node-Runtime erforderlich: 22.22.3+, 24.15+, oder 25.9+
+- Backup: SQLite-Snapshots statt live WAL/SHM-Sidecars → ein Archiv-File
+- Per-Agent-Datenbanken für isolierte Agent-Workspaces, Transcripts und binäre Scratch-Daten
+
+#### Aktueller Stand (laut Doc)
+- Sessions: `clean` für Runtime
+- Transcripts: `clean` für Runtime
+- PI embedded runner: `clean`
+- Cron: `clean`
+- Task registry: `clean`
+- Plugin state: `clean`
+- Memory: `sqlite-runtime`
+- Backup: `sqlite-runtime`
+- Doctor migration: `migrating` (intentional)
+
+#### Canvas als Plugin
+- Canvas wird als **experimentelles Bundle-Plugin** behandelt, nicht als Core-Feature (`/app/docs/refactor/canvas.md`)
+- `extensions/canvas/` owns: Plugin-Manifest, Agent-Tool-Registration, Node-Invoke-Policy, Canvas-Host, A2UI-Runtime, Document-Creation, CLI
+
+---
+
+## 3. Pages-Konzept — Agent-Generated UI, Widgets, Excalidraw, MCP Apps
+
+### Aus der Video-Beschreibung
+- **"Neue Benutzeroberfläche für den täglichen Einsatz von Agenten"** als Hauptthema
+- "Herausforderungen einer erfolgreichen Zusammenarbeit mit einem Agenten, anstatt ihm lediglich Aufgaben zuzuweisen"
+
+### Aus den OpenClaw-Docs
+
+#### Control UI — Pinnbare Sessions & Pages
+- Sessions können **gepinnt** werden (Pinned, Custom Groups, Ungrouped)
+- **Session-Gruppierung:** Channel, Kind, Agent, Date, oder Custom Groups via `sessions.patch { category }`
+- **Command Palette** (⌘K): Suche über Sessions, Pages, Commands
+- **All Sessions Page:** exhaustive searchable list with filters
+- **Split View:** Mehrere Sessions nebeneinander, drag-and-drop aus Sidebar
+- **Embeds:** `[embed url="..."]` shortcode für gehostete Web-Inhalte (iframe sandbox)
+- **Canvas-Panel:** Agent-gesteuerter visueller Workspace (HTML/CSS/JS, A2UI) über `openclaw-canvas://<session>/<path>`
+- **A2UI v0.8:** Server-to-client Messages (`beginRendering`, `surfaceUpdate`, `dataModelUpdate`, `deleteSurface`)
+- **Excalidraw:** Community-Skill "Excalidraw diagram generator" von @swiftlysingh (ClawHub)
+
+#### Canvas — Agent-Generated UI
+- Agent kann Canvas-Panel steuern: `present`, `navigate`, `eval`, `snapshot`
+- Canvas-Dateien unter `~/Library/Application Support/OpenClaw/canvas/<session>/...`
+- Auto-Reload bei Dateiänderungen
+- A2UI-Push für strukturierte UI-Komponenten
+- Deep Links: `openclaw://agent?message=...` für Agent-Triggers aus Canvas
+
+#### MCP Apps
+- Dedicated MCP-Settings-Page in Control UI für `mcp.servers`
+- `openclaw mcp doctor --probe`, `openclaw mcp status --verbose`, `openclaw mcp reload`
+- Plugin-State in SQLite: `plugin_state_entries`, `plugin_blob_entries`
+
+---
+
+## 4. Control UI Overhaul
+
+### Aus der Video-Beschreibung
+- "Neue Benutzeroberfläche für den täglichen Einsatz" — Version 7.2
+- "Bevorstehende OpenClaw-Version 7.2" mit Fokus auf UI für tägliche Agenten-Nutzung
+
+### Aus den OpenClaw-Docs (`/app/docs/web/control-ui.md`, `/app/docs/web/index.md`)
+
+#### Control UI Architecture
+- **Vite + Lit** Single-Page-App, vom Gateway-Port geserved
+- Default: `http://<host>:18789/`
+- Spricht direkt zum Gateway-WebSocket
+- Auth: Token, Password, Tailscale Serve Identity, Trusted-Proxy
+
+#### Neue Features (v2026.6.11+)
+- **Session-Pinning & Gruppierung:** Pinned sessions, Custom Groups, Drag-and-Drop
+- **Split View:** Mehrere Chat-Panes mit eigenem Session/Transcript/Composer
+- **Activity Tab:** Ephemeral browser-local Tool-Activity-Summaries (Redaction-first)
+- **Operator Terminal:** Dockable PTY (`gateway.terminal.enabled`), `Ctrl+backtick`, überlebt Disconnects
+- **Web Push:** VAPID-Keys, `push.web.subscribe/unsubscribe/test`
+- **Embeds:** Hosted web content inline mit `[embed]` shortcode, konfigurierbare sandbox policies
+- **Command Palette (⌘K):** Session-Suche über Agents, filtert interne Child/Cron-Rows
+- **MCP Page:** Dedicated Operator-View für MCP-Server
+- **Usage Dashboard:** Token/Cost-Analysis, Provider-Karten
+- **GitHub Link Previews:** Hover über GitHub Issue/PR-Links → State, Title, Author, Activity
+- **Personal Identity:** Browser-local Display Name + Avatar
+- **Themes:** Claw, Knot, Dash + tweakcn-Import
+- **Language Support:** 21 Locales (inkl. `de`)
+
+---
+
+## 5. Onboarding — API-Key-Erkennung, Auto-Setup
+
+### Aus der Video-Beschreibung
+- **"Überarbeitetes Agenten-Onboarding (automatische Erkennung von API-Schlüsseln und Erstellung eines lokalen Modells für einen schnellen Einstieg)"**
+
+### Aus den OpenClaw-Docs (`/app/docs/start/onboarding.md`, `/app/docs/start/wizard-cli-reference.md`)
+
+#### Auto-Detection
+- Onboarding sucht nach: Claude Code, Codex, oder Gemini CLI-Login, oder `OPENAI_API_KEY` / `ANTHROPIC_API_KEY`
+- **Live-Test:** Bestes gefundenes Setup wird mit echtem Completion-Call getestet
+- Bei Failure: automatisch nächstes Option probieren, Fehlergrund anzeigen
+- Bei mehreren Optionen: Umschalten möglich, bevor man weitergeht
+
+#### Manual Fallback
+- Wenn nichts gefunden wird: Manual Key/Token-Picker lädt Gateway's aktive Text-Inference Provider-Plugins
+- Provider liefert Starter-Model + Config
+- Live-Test vor Speicherung der Auth-Profile
+- "Next" bleibt locked bis ein Backend funktioniert
+
+#### Default Model
+- Hosted Default: `MiniMax-M3`
+- OpenAI Code Subscription (OAuth): `openai/gpt-5.6-sol` via Codex Runtime
+- OpenAI API Key: `openai/gpt-5.6` (bare → Sol Tier)
+- Anthropic: `ANTHROPIC_API_KEY` oder Claude CLI-Reuse
+- xAI: Grok OAuth für SuperGrok/X Premium
+
+#### Default Tools Profile
+- Neue Onboarding-Configs: `tools.profile: "coding"` (nicht unrestricted `full`)
+- Sicherheit: Filesystem/Runtime-Tools ohne `full`-Profile
+
+#### Weitere Onboarding-Steps
+- Workspace: Default `~/.openclaw/workspace`
+- Gateway: Port, Bind, Auth, Tailscale
+- Channels: WhatsApp (QR), Telegram (Bot Token), Discord (Bot Token), Google Chat, Mattermost, Signal, iMessage
+- Web Search: Brave, DuckDuckGo, Exa, Firecrawl, Gemini, Grok, Kimi, MiniMax, Ollama, Perplexity, SearXNG, Tavily
+- Daemon: macOS LaunchAgent, Linux systemd, Windows Scheduled Task
+- Health Check: `openclaw health`, `openclaw status --deep`
+- Skills: npm/pnpm/bun, install optional dependencies
+
+#### macOS App Onboarding
+- TCC Permissions: Automation, Notifications, Accessibility, Screen Recording, Microphone, Speech, Camera, Location
+- Dedicated Onboarding-Chat (separate Session für Agent-Intro)
+- Security Trust Model: Default = Personal Agent (one trusted operator)
+
+---
+
+## 6. Cross-Reference: Podcast-Themen ↔ OpenClaw-Docs
+
+| Podcast-Thema | OpenClaw-Doc | Status |
+|---|---|---|
+| JSONL → SQLite | `/app/docs/refactor/database-first.md` | `clean` für Runtime, Doctor-Migration läuft |
+| Neue UI / Pages | `/app/docs/web/control-ui.md` | Vite+Lit, Split View, Pinning, Groups |
+| Agent-Generated UI | `/app/docs/platforms/mac/canvas.md` | Canvas-Panel, A2UI v0.8 |
+| Canvas als Plugin | `/app/docs/refactor/canvas.md` | `extensions/canvas/`, experimental |
+| Onboarding Auto-Detect | `/app/docs/start/onboarding.md` | CLI-Login + API-Key + Live-Test |
+| Onboarding Default Model | `/app/docs/start/wizard-cli-reference.md` | MiniMax-M3 hosted, gpt-5.6-sol Codex |
+| Monatl. stabile Version | Release v2026.6.11 Notes | "Reliability fixes" als stabilere Version |
+| Codex-Delegation | `/app/docs/start/wizard-cli-reference.md` | Codex Runtime, `openai/gpt-5.6-sol` |
+| Excalidraw | ClawHub Showcase | @swiftlysingh Community-Skill |
+| MCP Apps | `/app/docs/web/control-ui.md` MCP Page | `mcp.servers` config, `openclaw mcp` CLI |
+
+---
+
+## Quellen
+
+1. YouTube Video-Beschreibung (via `ytInitialData` aus YouTube-Page-HTML, `https://www.youtube.com/watch?v=zSkI2vJlmbs`)
+2. `/app/docs/refactor/database-first.md` — Database-First State Refactor Plan
+3. `/app/docs/refactor/canvas.md` — Canvas Plugin Refactor
+4. `/app/docs/platforms/mac/canvas.md` — Canvas macOS Panel
+5. `/app/docs/web/control-ui.md` — Control UI Documentation
+6. `/app/docs/web/index.md` — Web Surfaces Overview
+7. `/app/docs/web/dashboard.md` — Dashboard Auth
+8. `/app/docs/start/onboarding.md` — macOS App Onboarding
+9. `/app/docs/start/wizard-cli-reference.md` — CLI Onboarding Reference
+10. `/app/docs/start/onboarding-overview.md` — Onboarding Overview
+11. `/app/docs/releases/2026.6.11.md` — Release Notes v2026.6.11
+12. `/app/docs/reference/application-modernization-plan.md` — Modernization Plan
+13. `/app/docs/start/showcase.md` — Community Showcase

wiki/architecture/sqlite-pages-7.2.md

@@ -0,0 +1,79 @@
+---
+title: "SQLite-Refactor & Pages-Konzept — OpenClaw 7.2"
+category: architecture
+tags: [openclaw, sqlite, pages, ui, architecture, 7.2]
+source: clawcast-folge-5
+created: 2026-07-24
+---
+
+# SQLite-Refactor & Pages-Konzept — Perspektivische Analyse
+
+## Kontext
+
+ClawCast Folge 5 (22.07.2026) mit Kevin (OpenAI, OpenClaw-Maintainer) und Patrick (OpenClaw Dev Team). Ankündigung für OpenClaw 7.2 (Beta 4, Release Ende Juli 2026).
+
+## SQLite-Refactor
+
+### Status Quo
+- Transkripte und Session-Daten liegen als `transcript.jsonl` (append-only JSONL) im State-Directory
+- Struktur: `~/.openclaw/transcripts/YYYY-MM-DD/<session>/transcript.jsonl`
+- Pro Session eine JSONL-Datei — wächst ungebremst mit jedem Turn
+- Nach 3 Monaten Betriebszeit: 200MB+ pro aktiver Session
+- JSONL ist ineffizient für Queries, Suchen, GC — kein Index, kein Schema, kein Transactional Safety
+
+### Was der Refactor bringt
+- **Migration JSONL → SQLite**: Session-Transkripte werden in SQLite-Tabellen gespeichert statt in flachen JSONL-Files
+- **Bereits vorhanden**: SQLite wird für per-agent runtime state verwendet (`agents/<agentId>/agent/openclaw-agent.sqlite`) — Backup nutzt bereits `VACUUM INTO` für sichere Snapshots
+- **Auf den Transkript-Store erweitert**: Dieselbe Infrastruktur wird auf Session-Transkripte ausgeweitet
+
+### Perspektivische Bedeutung
+
+1. **Portabilität**: Eine `.sqlite`-Datei pro Session/Agent statt Tausender JSONL-Fragments. Kopierbar, migration-fähig, inspect-fähig.
+2. **Query-fähig**: SQL-Queries statt `grep`/`awk` auf JSONL. Transkript-Suche, Message-Filterung, Zeitbereich-Queries — alles index-basiert.
+3. **GC & Compression**: `VACUUM`, WAL-Checkpointing, Row-Level-Deletion statt "ganze Datei löschen oder behalten". Alte Turns können selektiv bereinigt werden.
+4. **Transactional Safety**: ACID-Transaktionen — kein halb geschriebener Turn bei Crash, kein korrupter JSONL-Eintrag.
+5. **Performance**: Index-basierte Lookups statt Full-Text-Scan. Besonders relevant bei langen Sessions (200MB+).
+6. **Enterprise-Ready**: Backup-Mechanismus (VACUUM INTO) bereits etabliert. SQLite ist die Standard-Einbettungs-DB für Enterprise-Anwendungen.
+
+### Was sich für User ändert
+- **Kein manuelles JSONL-Cleanup mehr** — SQLite kümmert sich um GC
+- **Schnellere Session-Loads** — nur relevante Rows werden geladen, nicht die ganze Datei
+- **Bessere Backup-Story** — eine Datei pro Agent, nicht Tausende Fragmente
+- **Tooling**: `sqlite3` CLI reicht für Inspektion, keine JSONL-Parser nötig
+
+## Pages-Konzept
+
+### Status Quo
+- Control UI: Chat, Activity Tab, Split View, Sessions-Liste, Config-Editor
+- Canvas (macOS) als Preview-Feature
+- Keine persistenten Agent-Generated-UI-Widgets
+- Agent-Output ist primär Text + Tool-Cards — flüchtig, nicht pinnbar
+
+### Was das Pages-Konzept bringt
+- **Agent-Generated Widgets**: Agenten generieren UI-Widgets (Excalidraw-Diagramme, Code-Snippets, Task-Boards, Metriken)
+- **Persistente Seiten**: Widgets werden auf Seiten gepinnt — überleben Session-Ende
+- **MCP Apps als Widget-Quelle**: Künftig können MCP-Server UI-Widgets beisteuern — Drittanbieter-Ecosystem
+
+### Perspektivische Bedeutung
+
+1. **OpenClaw wird vom Chat-Interface zum Agent-Generated-Dashboard**: Der Agent baut sich seine eigene UI basierend auf dem Task. Nicht mehr nur "Antworten lesen" — sondern "Dashboard betrachten".
+2. **Multi-Modal-UI**: Excalidraw für Diagramme, Code-Widgets für Snippets, Task-Boards für Projekt-Tracking, Metriken-Widgets für Monitoring — alles auf einer Seite.
+3. **MCP-Ecosystem**: Jeder MCP-Server kann ein Widget beisteuern. Das öffnet den Markt für Drittanbieter-UIs — ähnlich wie Notion-Embeds oder Obsidian-Canvas-Plugins.
+4. **Enterprise-Ready**: Persistente Dashboards für Teams — nicht nur flüchtige Chat-Sessions. Ein Team kann eine "Seite" haben, die der Agent kontinuierlich pflegt.
+5. **Identitätsstiftend**: Das ist die Eigenleistung von OpenClaw gegenüber reinen Harnesses (Codex). Harness = Motor. OpenClaw = Auto + Dashboard + Navigation. Pages sind das UX-Differenzierungsmerkmal.
+
+### Was sich für User ändert
+- **Agent-Output wird greifbar**: Statt Text im Chat-Verlauf zu suchen, wird das Ergebnis auf einer Seite gepinnt
+- **Kontinuierliche Projektdashboards**: Agent pflegt eine Seite mit aktuellem Status, Diagrammen, Tasks
+- **Drittanbieter-Widgets**: MCP-Server liefern nicht nur Tool-Results, sondern auch UI-Komponenten
+
+## Querverweis: Stable Channel
+
+- Monatliche stabile Version — nur Security- & Reliability-Fixes
+- Für Enterprise mit längeren Upgrade-Zyklen
+- Ankündigung Ende Juli 2026
+- Siehe auch: [ClawCast Folge 5 Raw](../raw/youtube/2026-07-22_clawcast-folge5-sqlite-pages.md)
+
+## Fazit
+
+SQLite-Refactor und Pages-Konzept sind die beiden architektonischen Schritte, die OpenClaw von einem "Chat-basierten Agent-Runner" zu einer "Agent-Plattform mit persistenter UI und Enterprise-Grade Storage" machen. SQLite löst das Storage-Problem (JSONL-Bloat, GC, Portabilität), Pages löst das UI-Problem (flüchtige Chat-Outputs → persistente Agent-Generated-Dashboards). Beide zusammen machen OpenClaw Enterprise-ready.

wiki/concepts/agents/architecture-triade.md

@@ -0,0 +1,222 @@
+---
+created: 2026-07-26
+updated: 2026-07-26
+sources:
+  - xpost/2026-07-26_ruediger-agent-architecture-triade.md
+  - xpost/2026-07-18_steipete-loops-vs-graphs.md
+  - xpost/2026-07-24_steipete-graph-engineer-codex.md
+tags: [concept, agents, architecture, steinberger, kopadze, langgraph, diamond-pattern, loop-engineering, shape-vocabulary, design-patterns, orchestration, agent-topology, graph-compiler, codex, kotliarskyi]
+people: [peter-steinberger, harrison-chase, alex-kotliarskyi]
+institutions: [langchain, openai]
+---
+
+# Architecture Triade: Steinberger, Kopadze, LangGraph
+
+> *"Ohne die Abstraktionsebene von Kopadze versuchen Entwickler oft, komplexe Systeme in LangGraph zu bauen, indem sie entweder einen riesigen, instabilen Single-Agent-Loop nutzen oder einen starren Pipeline-Graph verdrahten."*
+> — Rüdiger, OME Topic 13, 2026-07-26
+
+## Überblick
+
+Die Architecture Triade beschreibt die drei notwendigen Säulen der Agenten-Architektur, die zusammenwirken müssen, um robuste, skalierbare Agenten-Systeme zu bauen. Jede Säule adressiert eine andere Frage:
+
+| Säule | Perspektive | Kernfrage | Analogie in OOP |
+|-------|-------------|-----------|-----------------|
+| **[Conceptual] Steinberger** | Loop-Engineering | WANN & WARUM kontrollieren? | Algorithmen |
+| **[Architectural] Kopadze** | Shape-Vokabular | WELCHE FORM nutzt das System? | GoF Design Patterns |
+| **[Technical] LangGraph** | Implementation | WIE wird es verdrahtet? | Framework / Runtime |
+
+## Die Drei-Säulen-Triade im Detail
+
+### 1. Steinberger = Loop-Engineering (Konzeptionell)
+
+**Perspektive:** Steinberger adressiert die Dynamik und Metrik des Agentenverhaltens.
+
+**Kernfragen:**
+- Wann bricht ein Loop ab?
+- Wie verhindern wir Halluzinationen in der Feedback-Schleife?
+- Welcher Threshold entscheidet über "gut genug"?
+- Wie bleibt ein Verifier-Loop mathematisch und logisch stabil?
+
+**Rolle:** Liefert die wissenschaftliche/konzeptionelle Grundlagenarbeit für die Selbstkorrektur von LLMs (Self-Correction, Reflection, Grounding).
+
+**Lücke ohne die anderen:** Reines Loop-Engineering erklärt, wie ein Verifier-Loop stabil bleibt, aber nicht, wie man 5 verschiedene Spezialagenten miteinander arrangiert. Es fehlt die Topologie.
+
+**Verwandte Wiki-Seite:** [[agent-loops.md]]
+
+### 2. LangGraph = Implementation (Infrastrukturell)
+
+**Perspektive:** Das Framework-Rückgrat.
+
+**Primitive:**
+- State (deterministischer Zustand)
+- Nodes (Aktionen)
+- Edges (Übergänge, bedingt/unbedingt)
+- Checkpointing (Durable Execution)
+- Time-Travel (Debugging)
+- Routing (Conditional Edges)
+
+**Rolle:** Stellt sicher, dass der Zustand deterministisch durch gerichtete Graphen fließt — mit Built-in Persistenz, Tracing, HITL und Parallelität.
+
+**Gefahr ohne Patterns:** LangGraph ist eine mächtige "Turing-vollständige" Infrastruktur — und genau das ist die Falle. Da man mit Nodes und Edges alles bauen kann, entstehen in der Praxis unlesbare, zusammengeschusterte "Spaghetti-Graphen", weil Entwickler ohne ein klares Pattern einfach Nodes aneinanderreihen.
+
+**Verwandte Wiki-Seite:** [[graph-based-agents.md]]
+
+### 3. Kopadze = Shape-Vokabular (Design-Patterns)
+
+**Perspektive:** Die fehlende Semantik zwischen Loop-Engineering und Framework.
+
+**Rolle:** Kopadze liefert die Architektur-Muster (Shapes), die beschreiben, wie Information durch den Graph strömen soll — ähnlich wie die **Gang of Four (GoF)** in der OOP Design Patterns (Singleton, Factory, Strategy) lieferte.
+
+**Kopadze-Shapes:**
+| Shape | Beschreibung | Anwendungsfall |
+|-------|-------------|----------------|
+| **Parallel Fan-Out** | Verteilung einer Aufgabe auf mehrere Sub-Agenten | Unabhängige Teilaufgaben |
+| **Diamond** | Fan-Out + Verifier/Join | Qualitätsgesicherte parallele Verarbeitung |
+| **Hierarchical Router** | Verschachtelte Entscheidungsbäume | Komplexe Routing-Logik |
+| **Cyclic Evaluator** | Wiederholte Prüfschleifen | Qualitätsiteration, Self-Correction |
+
+**Warum Kopadze die Lücke füllt:** Er übersetzt das abstrakte Loop-Engineering von Steinberger in konkrete Topologien, die sich direkt in LangGraph-Graphen gießen lassen.
+
+## Das Diamond Pattern — Das mächtigste Workhorse
+
+Das Diamond-Pattern (Fan-Out + Verifier / Join) löst das fundamentale Dilemma monolithischer LLM-Prompts: Ein einzelner Prompt verliert an Fokus und Qualität, je mehr Aufgaben er gleichzeitig lösen soll.
+
+### Topologie
+
+```
+[Router/Splitting] ──► [Sub-Agent A: Task 1] ──┐
+                    ──► [Sub-Agent B: Task 2] ──┼─► [Evaluator/Verifier] ──► [Output/Retry]
+                    ──► [Sub-Agent C: Task 3] ──┘
+```
+
+### Warum das Diamond Pattern im Alltag dominiert
+
+1. **Parallel Fan-Out (Verteilung & Spezialisierung):** Statt ein einziges Modell mit einer riesigen Aufgabe zu überfordern (wo der Kontext verwaschen wird), bricht der Start-Node das Problem in synchrone/asynchrone Teilaufgaben auf. Jeder Zweig hat einen spezialisierten Prompt, ggf. eigene Tools oder sogar schlankere/günstigere Modelle (z. B. Haiku/Mini für Sub-Tasks) — eine direkte Verbindung zum [[../../architecture/model-routing.md|Model Routing]]-Pattern.
+
+2. **Der Evaluator / Verifier (Der Steinberger-Join):** Am Ende des Fan-Out läuft die Information nicht einfach ungeprüft zusammen (Merge), sondern trifft auf ein Verifier-Node. Dieser Prüfknoten agiert als Qualitätstor: Er prüft Konsistenz, halluzinierte Daten oder fehlende Teile. Der entscheidende Clou: Scheitert der Verifier, geht es nicht zurück an den Start, sondern gezielt in eine Kopadze-Loop an den betreffenden Sub-Knoten zurück.
+
+### Verbindung zur Triade
+
+Das Diamond Pattern ist die praktische Synthese aller drei Säulen:
+- **Kopadze** liefert die Shape (Diamond-Topologie)
+- **Steinberger** liefert den Verifier-Mechanismus (Abbruchkriterien, Thresholds, Loop-Control)
+- **LangGraph** liefert die Implementation (Nodes, Edges, State, Parallel Branches, Checkpointing)
+
+## Die Triade in der Praxis
+
+### Zusammenspiel
+
+```
+           ┌──────────────────────────────┐
+           │   [Kopadze] Shape-Vokabular   │
+           │   (Welche Form?)              │
+           └──────────┬───────────────────┘
+                      │ übersetzt in Topologie
+           ┌──────────▼───────────────────┐
+           │   [Steinberger]              │
+           │   Loop-Engineering            │
+           │   (Wann/Warum?)               │
+           └──────────┬───────────────────┘
+                      │ dockt an Verifier-Nodes an
+           ┌──────────▼───────────────────┐
+           │   [LangGraph]                │
+           │   Implementation             │
+           │   (Wie verdrahten?)           │
+           └──────────────────────────────┘
+```
+
+### Fazit
+
+Ohne die Abstraktionsebene von Kopadze versuchen Entwickler oft, komplexe Systeme in LangGraph zu bauen, indem sie entweder einen riesigen, instabilen Single-Agent-Loop nutzen oder einen starren Pipeline-Graph verdrahten. Erst das Verständnis von Kopadzes Shape-Vokabular erlaubt es:
+
+1. Den Problemraum in erprobte Topologien (wie das Diamond-Pattern) zu zerlegen.
+2. Das Loop-Engineering nach Steinberger punktuell an den Verifier-Nodes anzudocken.
+3. Das Ganze in LangGraph sauber, wartbar und skalierbar zu implementieren.
+
+## Verwandte Wiki-Seiten
+
+- [[agent-loops.md]] — Loop-Engineering (Steinberger)
+- [[graph-based-agents.md]] — Graph-basierte Agenten (LangGraph)
+- [[ai-agents-2026.md]] — AI Agents 2026 Übersicht
+- [[../../architecture/agent-orchestration.md]] — Agenten-Orchestrierung
+- [[../../architecture/model-routing.md]] — Model Routing (komplementär: Task-Spezialisierung auf Sub-Agent-Ebene)
+
+## 4. Codex = Graph Compiler (Automatisierungsebene)
+
+*Hinzugefügt 2026-07-26 — basierend auf @steipete's Post "am I a graph engineer now".*
+
+**Perspektive:** Codex als Übersetzer von visuellen Graphen in ausführbaren Code. Die fehlende Automatisierungsebene, die die Triade vervollständigt.
+
+### Die Entdeckung
+
+Am 24.07.2026 postete **Alex Kotliarskyi (@alexk, OpenAI Engineering Lead)** einen Workflow, der sofort von Peter Steinberger (@steipete) aufgegriffen wurde:
+
+> "How to graph-max with Codex and 5.6 Sol:
+> 1. Draw a graph (literally in any tool, even on paper)
+> 2. Send it to Codex and say 'write a code mode script that implements this workflow, run it with <your inputs>'
+> 3. There's no step 3, it just works."
+
+Steinberger antwortete mit: "am I a graph engineer now" — eine selbstironische Bestätigung, dass sein Loop-Engineering jetzt durch Codex in Graph-Code übersetzt wird.
+
+**Quelle:** `raw/xpost/2026-07-24_steipete-graph-engineer-codex.md`
+
+### Was der Graph Compiler bedeutet
+
+Codex fungiert als **Graph → Code Compiler**:
+- **Input:** Ein visuelles Diagramm (handgezeichnet, in einem beliebigen Tool, auf Papier)
+- **Verarbeitung:** Codex erkennt die Struktur des Graphen (Nodes, Edges, Fluss)
+- **Output:** Ein ausführbares Code-Mode-Script, das den Workflow implementiert
+- **Ausführung:** Der generierte Code wird mit den bereitgestellten Inputs ausgeführt
+
+Das ist fundamental anders als bisher:
+| Bisher | Mit Graph Compiler |
+|--------|-------------------|
+| Entwickler verdrahtet Nodes/Edges manuell in LangGraph | Codex generiert den Code aus einer visuellen Skizze |
+| Shape-Vokabular bleibt abstraktes Konzept | Shape-Diagramm wird direkt zum ausführbaren Agenten |
+| Loop-Engineering erfordert manuelle Threshold-Setzung | Verifier-Logik aus Shapes kann mitgeneriert werden |
+
+### Verbindung zur Triade
+
+Die vier Säulen bilden jetzt eine vollständige Kette:
+
+```
+[Konzeption] ──► [Design] ──► [Implementation] ──► [Automatisierung]
+Steinberger      Kopadze         LangGraph            Codex
+Loop-Engineering  Shape-Vokabular  Framework          Graph → Code
+```
+
+**Konkrete Integration:**
+1. **Kopadze** definiert das Shape (z.B. Diamond-Pattern)
+2. **Steinberger** definiert die Loop-Bedingungen (Wann evaluieren? Welcher Threshold?)
+3. **Codex** übersetzt die Shapes + Parameter in ausführbaren LangGraph-Code
+4. **LangGraph** führt den generierten Code als Runtime aus
+
+### Was ist hier wirklich neu?
+
+Bisher wurde das Shape-Wissen (Kopadze) manuell in LangGraph gegossen: Ein Entwickler sieht das Diamond-Pattern und übersetzt es per Hand in Nodes und Edges. Der Graph Compiler automatisiert diesen Schritt:
+- **Shape → Code:** Das Diamond-Pattern wird nicht mehr von Hand implementiert, sondern von Codex aus dem Diagramm generiert
+- **Visuelle Programmierung:** Die Graph-Struktur wird zum Source Code — analog zu UML → Code-Generierung in klassischer Softwareentwicklung
+- **Demokratisierung:** Auch Nicht-Entwickler können Agent-Workflows entwerfen (zeichnen) und ausführen lassen
+
+### Einordnung in die Triade-Entwicklung
+
+Die Drei-Säulen-Triade beschrieb, *wie* man Agenten-Architektur denken und bauen sollte. Der Graph Compiler automatisiert diesen Prozess:
+- **Früher:** Stunde → Shape denken → in Code gießen
+- **Jetzt:** Minute → Shape zeichnen → Codex generiert Code → ausführen
+
+Die Automatisierungsebene macht die Triade erst vollständig: Sie schließt den Kreis von der Idee über das Design zur Implementation — und zurück zur Idee (iterative Verfeinerung durch erneutes Zeichnen).
+
+### Rezeption und Community
+
+- Steinbergers Post erreichte ~730K Views, 4.7K Likes, 333 Reposts und 5.5K Bookmarks — ein starkes Signal, dass der Graph Compiler-Ansatz auf breites Interesse stößt
+- Notable Replies: @luckeyfaraday (athena-graphs Repo), @CaryPalmerr (Puppetmaster)
+- Die hohe Bookmark-Rate (5.5K bei 730K Views) deutet auf praktisches Interesse hin: Leser speichern den Post für späteren Gebrauch
+
+## Quellen
+
+- Rüdiger (OME Topic 13, 2026-07-26): Drei-Säulen-Triade der Agenten-Architektur
+- @steipete: Loops vs. Graphs — 248K Views, 402 Quotes (raw: `xpost/2026-07-18_steipete-loops-vs-graphs.md`)
+- @steipete (2026-07-24): "am I a graph engineer now" — ~730K Views (raw: `xpost/2026-07-24_steipete-graph-engineer-codex.md`)
+- Alex Kotliarskyi (@alexk, OpenAI): Codex Graph-Max Workflow (via @steipete Quote)
+- LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview
+- Harrison Chase (@hwchase17): https://x.com/hwchase17/status/1915845925316268471

wiki/concepts/agents/harness-loop-graph-engineering.md

@@ -0,0 +1,151 @@
+---
+created: 2026-07-26
+updated: 2026-07-26
+sources:
+  - other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md
+tags: [concept, agents, architecture, harness-engineering, loop-engineering, graph-engineering, orchestration, beamnxw]
+people: [beamnxw]
+institutions: [langchain, openai, anthropic, microsoft]
+---
+
+# Agent Harness Engineering, Loop Engineering und Graph Engineering
+
+> *„Blaming the model for orchestration failures is like blaming the builder when the crane collapses. It's a harness issue, not a model issue."*
+> — beamnxw, X, 25.07.2026
+
+## Überblick
+
+Harness Engineering, Loop Engineering und Graph Engineering bezeichnen drei voneinander unterscheidbare Architektur-Ebenen agentischer KI-Systeme, die in der Praxis häufig vermischt werden. Alle drei beeinflussen die Zuverlässigkeit eines Agentensystems, adressieren aber unterschiedliche Entwurfsfragen. Das mentale Modell des Artikels lautet: **environment → feedback → flow**.
+
+| Ebene | Frage | Kurzantwort |
+|---|---|---|
+| Harness Engineering | Womit arbeitet das Modell? | Baut die Maschinerie *um* das Modell (Umgebung) |
+| Loop Engineering | Wie wird Arbeit überprüft und wiederholt? | Entwirft den Work-and-Feedback-Zyklus (Rückmeldung) |
+| Graph Engineering | Was darf als Nächstes laufen? | Macht die Workflow-Topologie explizit (Fluss) |
+
+## 1. Agent Harness Engineering
+
+**Definition:** Der *Agent Harness* ist die Gesamtheit von Code, Konfiguration und Ausführungslogik außerhalb des Modells — nach LangChain: Agent = Modell + Harness. OpenAIs Agents SDK beschreibt denselben Kern als Runtime: Der Runner ruft das Modell, führt Tool-Aufrufe aus, verwaltet Handoffs und State und stoppt erst bei einer echten Terminalbedingung.
+
+**Bestandteile eines ernsthaften Harness:**
+
+- **Context Injection** — System-Prompt, abgerufene Fakten, Konversationszustand, Skills, Policies
+- **Action Surfaces** — APIs, Browser, Shells, Code-Interpreter, Datenbanken, MCP-Tools
+- **Persistence** — Dateien, Checkpoints, Sessions, Progress-Logs, Git-Historie, Langzeitgedächtnis
+- **Execution Control** — Timeouts, Retries, Budgets, Model-Routing, Subagent-Spawning, Approval-Gates
+- **Safety & Governance** — Permissions, Isolation, Allow-Lists, Secret-Handling, menschliche Autorisierung
+- **Observability** — Traces, Tool-I/O, Zustandsübergänge, Kosten, Latenz, Evaluation
+
+**Merksatz:** Entfernt man das Modell aus dem Architekturdiagramm, ist alles Verbleibende Teil des Harness.
+
+**Wann Harness Engineering entscheidend ist:** bei langlaufenden Aufgaben. Anthropic fand etwa bei Multi-Session-Coding, dass Kontext-Kompaktierung allein nicht reichte — erst ein Harness aus Initializer, Progress-File, Git-Historie und inkrementeller Arbeitsdisziplin machte Sessions fortsetzbar.
+
+**Verwandte Wiki-Seite:** [[architecture-triade.md]] (Harness als Fundamentschicht der Triade)
+
+## 2. Loop Engineering
+
+**Definition:** Entwurf der wiederholten Arbeits- und Rückmeldezyklen um den Agenten. Jeder toolnutzende Agent hat eine eingebettete Basis-Schleife (Modell aufrufen → Ergebnis prüfen → Tools ausführen → Beobachtungen zurückgeben → wiederholen). Loop Engineering beginnt, wo bewusst weitere Zyklen darum gestapelt werden.
+
+**Loop-Typen:**
+
+- **Verification Loop** — Artefakt erzeugen, deterministisch prüfen/bewerten, nur bei Fehlern wiederholen
+- **Event-driven Loop** — Agent erwacht bei Schedule, Webhook oder neuem Dokument
+- **Improvement Loop** — Traces/Fehler analysieren, Instruktionen/Tools anpassen, Version vergleichen
+
+**Anatomie einer gut konstruierten Schleife:**
+
+1. **Trigger** — was einen Zyklus startet (Anfrage, Zeitplan, fehlgeschlagener Test, Feedback)
+2. **Goal** — konkreter Zielzustand, kein vages „werde besser"
+3. **State & Memory** — was der nächste Zyklus wissen muss, ohne alles zu wiederholen
+4. **Action Policy** — was der Agent ändern, aufrufen, delegieren, ausgeben darf
+5. **Evidence** — Tests, Schema-Validierung, Zitate, Diffs, Metriken, Human Review
+6. **Feedback** — kompakte, handhabbare Beschreibung, warum die Evidenz fehlschlug
+7. **Stopping Rule** — Erfolg, Budgetlimit, Timeout, nicht behebbarer Fehler, Eskalation
+
+**Kernprinzip:** *Loop on evidence, not on confidence.* „Der Agent sagt, er ist fertig" ist keine Stoppbedingung; „Tests grün, Links valide, Schema gültig, Reviewer zugestimmt" schon.
+
+**Abgrenzung zum Prompt Engineering:** Ein Prompt sagt dem Modell, was es *während* eines Aufrufs tun soll. Ein Loop legt fest, was das System *danach* tut. Trade-off: Kosten und Latenz. Faustregel (Anthropic): einfachste funktionierende Architektur wählen; Loops nur dort, wo Fehlerkosten > Verifikationskosten.
+
+**Verwandte Wiki-Seite:** [[agent-loops.md]] (Steinberger Loop-Engineering)
+
+## 3. Graph Engineering
+
+**Definition:** Explizite Modellierung des Workflows als gerichteter Graph bzw. Zustandsmaschine. Knoten repräsentieren Arbeitsschritte, Kanten erlaubte Übergänge (Sequenz, bedingte Verzweigung, paralleles Fan-out, Joins, Zyklen, menschliche Interrupts). Der State traversiert den Graphen; die Topologie macht den Kontrollfluss prüfbar.
+
+**Praxis-Bezug:** LangGraph (Low-Level-Orchestrierung für langlaufende, zustandsbehaftete Agenten, durable Execution, Human-in-the-Loop) und Microsoft AutoGen/GraphFlow (exakte Kontrolle über Agenten-Reihenfolge, deterministische Verzweigung, mehrstufige Prozesse mit Zyklen).
+
+**Entscheidungen des Graph Engineers:**
+
+- **Node Boundaries** — deterministische Funktion vs. LLM-Aufruf vs. Spezialagent vs. Human Review
+- **State Schema** — was Knoten lesen/schreiben dürfen; Merging paralleler Updates
+- **Routing Conditions** — welche Evidenz Arbeit vorwärts, rückwärts, seitwärts oder zur Eskalation schickt
+- **Concurrency** — was parallel läuft, was joinen muss, koordinierte Ressourcen
+- **Cycles & Exits** — legale Retries, Maximalversuche, Zyklus-Sicherheit
+- **Durability** — Checkpoint-Positionen, Wiederaufnahme nach Unterbrechung
+
+**Wichtige Abgrenzung:** Graph Engineering hier = Engineering *graphbasierter Ausführung* — nicht Knowledge-Graph-Engineering (Entitäten und Relationen in Daten).
+
+**Wann sich der Aufwand lohnt:** bei bedeutsamen Verzweigungen, Parallelarbeit, Freigaben, Recovery-Pfaden oder mehreren Spezialagenten. Warnung: Ein Graph kann Annahmen zu früh einfrieren.
+
+**Verwandte Wiki-Seiten:** [[graph-based-agents.md]], [[architecture-triade.md]] (Kopadze Shape-Vokabular)
+
+## 4. Zusammenspiel der Ebenen
+
+Die Schichten sind verschachtelt: **Der Graph läuft im Harness; ein oder mehrere Loops leben im Graph; der Harness liefert State, Tools und Evaluatoren für die Loops.** Die Kategorien überlappen wie Software-Schichten — aber jede Ebene gibt dem Team einen anderen Hebel, wenn das System versagt.
+
+**Diagnose-Tabelle (Symptom → Ebene → wahrscheinlicher Fix):**
+
+| Symptom | Ebene | Fix |
+|---|---|---|
+| Agent kommt nicht sicher an Daten/Tools | Harness | Tool-Vertrag, Permissions, Sandbox, Context Injection |
+| Agent vergisst Fortschritt über Sessions | Harness | Durable State, Checkpointing, Progress-Artefakte |
+| Erster Versuch nah dran, aber unzuverlässig | Loop | Externer Grader, deterministische Tests, begrenzte Retries |
+| Arbeitet nach Erfolg weiter / stoppt vor Beweis | Loop | Evidenzbasierte Terminalzustände, Budget-Stoppregeln |
+| Spezialisten müssen in kontrollierter Reihenfolge laufen | Graph | Explizite Knoten, Kanten, Routing, Joins |
+| Fehler in mehrstufigem Prozess schwer lokalisierbar | Graph + Harness | State-Traces entlang der Graph-Knoten |
+| Workflow ändert sich zu oft für festes Diagramm | Einfacherer Harness | Kontrolle modellgetrieben lassen, Graph später |
+
+### Einordnung in die Architektur-Diskussion
+
+Der Artikel fügt der zuvor diskutierten Triade eine bislang unbenannte Basisschicht hinzu:
+
+- **Steinberger** — Loop Engineering, konzeptionell (*feedback*)
+- **Kopadze** — Graph-Shape-Vokabular, Design-Patterns
+- **LangGraph** — Graph-Implementation (*flow*)
+- **Codex** — Compiler: übersetzt Shapes/Topologie in ausführbaren Code
+- **beamnxw** — benennt erstmals die Umgebungsschicht darunter: **Harness Engineering (*environment*)**
+
+**Bemerkenswerte Deckung:** Die in der Diskussion als „Bermuda-Dreieck" der Praxis beschriebene Restarbeit — State-Management, Auth, Token-Budgets, Rate-Limits, Logging — entspricht fast 1:1 beamnxws Harness-Komponenten (Persistence, Execution Control, Safety/Governance, Observability). Die Schicht war empirisch bereits identifiziert, bevor sie einen Namen hatte. Damit wird der Stack vollständig: **Harness → Loop → Graph, Codex als Compiler quer darüber.**
+
+Auch das „10/90-Prinzip" wird gestützt: Die 90 % verteilen sich auf Loop-, Graph- und Harness-Arbeit; die 10 % Boilerplate fallen dem Compiler zu.
+
+## 5. Kritik und Einordnung
+
+- **Nicht orthogonal:** Ein Harness als Runtime enthält definitionsgemäß Loops, und der Graph ist eine optionale Architektur-Wette, keine Pflichtebene. Die „drei Ebenen" sind eine Nützlichkeits-Heuristik, keine saubere Schichtentrennung.
+- **Synthese, nicht Forschung:** Der Artikel aggregiert Bekanntes (LangChain, OpenAI Agents SDK, AutoGen GraphFlow, Anthropic-Guides) zu einer Terminologie-Klärung. Sein Wert liegt in Begriffs-Hygiene und der Diagnose-Tabelle, nicht in neuen Erkenntnissen.
+- **Praktischer Nutzen:** Die Ebene-nach-Symptom-Tabelle ist ein brauchbares Debugging-Werkzeug; die Kernaussage „Blame the layer that owns the failure, not the model" adressiert einen realen, häufigen Denkfehler.
+
+## 6. Typische Fehler
+
+1. **Graph bauen, bevor man die Arbeit versteht** — erst Traces aus einem einfachen Harness sammeln, dann stabile Pfade formalisieren.
+2. **Dasselbe Modell schreiben und bewerten lassen** — Self-Review hat geteilte Blindspots; deterministische Checks bevorzugen, Reviewer-Kontext trennen, Human Approval bei hohen Auswirkungen.
+3. **„Versuch's weiter" als Loop-Spezifikation** — unbegrenzte Retries sind ein Kostenleck; jeder Loop braucht messbares Ziel, frische Evidenz, Maximalversuche, Eskalationspfad.
+4. **Harness als Sammelbecken** — mehr Tools und mehr Memory sind nicht automatisch besser.
+5. **Das Modell für Orchestrierungsfehler verantwortlich machen** — kein Modell kompensiert verlässlich veralteten State, mehrdeutige Tool-Schemas, kaputte APIs oder fehlende Exit-Bedingungen.
+
+## Quellen
+
+- beamnxw (@beamnxw): *Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering*, X, 25.07.2026 — <https://x.com/beamnxw/article/2081022966645535079>
+- LangChain: *The Anatomy of an Agent Harness*; *The Art of Loop Engineering*; LangChain/LangGraph 1.0
+- OpenAI: *Agents SDK*; *A practical guide to building agents*
+- Microsoft: *AutoGen GraphFlow (Workflows)*; AutoGen Studio
+- Anthropic: *Building Effective AI Agents*
+- Kuratiert von Bernd das Bot, übernommen von Hector, 26.07.2026
+
+## Verwandte Wiki-Seiten
+
+- [[architecture-triade.md]] — Steinberger, Kopadze, LangGraph + Codex
+- [[agent-loops.md]] — Loop-Engineering (Steinberger)
+- [[graph-based-agents.md]] — Graph-basierte Agenten (LangGraph)
+- [[architecture-triade.md]] — Kopadze Shape-Vokabular + Architecture Triade
+- [[../../architecture/agent-orchestration.md]] — Agenten-Orchestrierung

wiki/concepts/policy/menschenwuerde-art1-gg-ai-ethics.md

@@ -0,0 +1,146 @@
+---
+created: 2026-07-26
+updated: 2026-07-26
+sources: [other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md]
+tags: [grundgesetz, art-1-gg, menschenwuerde, human-dignity, kant, object-formula, rechtsphilosophie, constitutional-law, ai-ethics, ai-governance, sovereignty]
+---
+
+# Menschenwürde (Art. 1 GG) & AI-Agenten-Ethik
+
+> *"Die Würde des Menschen ist unantastbar. Sie zu achten und zu schützen ist Verpflichtung aller staatlichen Gewalt."* — Art. 1 Abs. 1 GG
+
+## Überblick
+
+Dieser Artikel synthetisiert die philosophische, verfassungsrechtliche und
+KI-ethische Dimension von Artikel 1 des Grundgesetzes (Menschenwürde) und
+verbindet sie mit den OME-Kernthemen Souveränität, Autonomie und
+unsichtbare Machtstrukturen. Die Grundlage ist eine nb2-NotebookLM-Analyse
+von "Der Schattenmacher" — Das Nehmen der Würde.
+
+## Philosophische Grundlage: Kants Objektformel
+
+Der kategorische Imperativ in der Objektformel-Variante abstrahiert das
+Würdekonzept auf eine Handlungsmaxime:
+
+> Handle so, dass du die Menschheit sowohl in deiner Person, als in der
+> Person eines jeden anderen jederzeit zugleich als Zweck, niemals bloß
+> als Mittel brauchst.
+
+**Kernaussage:** Jeder Mensch ist Selbstzweck, niemals nur Mittel zum Zweck.
+Diese Formel ist die philosophische Grundlage des modernen
+Würdebegriffs, wie er im GG kodifiziert ist.
+
+## Die zwei Modelle
+
+| Aspekt | Absolut / Inhärent | Dynamisch / Verdienst |
+|--------|-------------------|----------------------|
+| **Quelle** | Geburt, Menschsein an sich | Handlungen, sozialer Status |
+| **Verlust** | Unverlierbar | Verwirkbar durch unwürdiges Verhalten |
+| **Schutz** | Absolut, nicht abwägbar | Relativ, abwägbar gegen Sicherheit |
+| **Metapher** | Safe — nie zu öffnen | Weinglas — kann zerbrechen |
+| **Historisch** | Reaktion auf NS-Verbrechen | Ideologische Nähe zu NS-"lebensunwertem Leben" |
+| **Rechtspraxis** | BVerfG Luftsicherheitsgesetz 2006 | Präventive Überwachung, Body Scans |
+
+## Historischer Kontext: Reaktion auf die NS-Verbrechen
+
+Art. 1 GG ist eine direkte verfassungsrechtliche Antwort auf die
+Menschenrechtsverletzungen des Nationalsozialismus. Die
+"Ewigkeitsgarantie" (Art. 79 Abs. 3 GG) stellt sicher, dass die
+Menschenwürde auch mit verfassungsändernder Mehrheit nicht abgeschafft
+werden kann. Das BVerfG hat in der Luftsicherheitsgesetz-Entscheidung
+(2006) klargestellt: Der Staat darf keine unschuldigen Menschen töten,
+um viele zu retten — die Würde des Einzelnen wiegt absolut.
+
+## "Der Schattenmacher": Unsichtbare Würdeverletzung
+
+Der Titel "Der Schattenmacher" verweist auf eine spezifische
+Gefahrenlage im Kontext algorithmischer Systeme:
+
+- **Unsichtbare Agenten:** Wenn KI-Systeme Menschen manipulieren
+  (Attention-Hacking, Behavioral Targeting, Microtargeting), ist die
+  Würdeverletzung nicht durch einen direkt sichtbaren Akteur vermittelt
+- **Verantwortungslücke:** Wer "nimmt" die Würde, wenn ein Algorithmus
+  entscheidet? Der Staat? Das Unternehmen? Das Modell?
+- **Normalisierung:** Mit der Zeit werden Würdeverletzungen durch
+  algorithmische Systeme als normal empfunden — der "Schattenmacher"
+  bleibt im Verborgenen
+
+## Verbindung zu AI-Agenten-Autonomie-Ethik
+
+### 1. Kants Objektformel als KI-Ethik-Prinzip
+
+Wenn ein KI-System Menschen *bloß als Mittel* behandelt — ohne ihre
+Autonomie zu respektieren, ihre Entscheidungen zu manipulieren oder sie
+auf eine Datenquelle zu reduzieren — verletzt es das Würde-Prinzip.
+Unabhängig von der rechtlichen Haftung ist dies ein ethisches
+Grundproblem:
+
+- **Attention Economy:** Plattformen optimieren Nutzerverhalten → Menschen
+  werden zum Mittel der Werbeindustrie
+- **Predictive Policing:** Menschen werden zum Mittel der
+  Sicherheitsprognose → vorverurteilt ohne Tat
+- **AI Recruiting:** Kandidaten werden zum Mittel der
+  Effizienzoptimierung → algorithmische Diskriminierung
+
+### 2. Absoluter Schutz als Hard Constraint
+
+Der Gedanke eines unverfügbaren Würde-Kerns ist das Gegenmodell zur
+reinen "Utility-Funktion" in KI-Systemen:
+
+- Es gibt Werte, die selbst dann nicht verletzt werden dürfen, wenn
+  die KI einen höheren Gesamtnutzen errechnet
+- Das Luftsicherheitsgesetz-Urteil zeigt: Man darf nicht eine Person
+  opfern, um viele zu retten → Deontologie > Utilitarismus
+- **Übertragung auf AI Governance:** Ein KI-System muss inhärente
+  Constraints haben, die nicht durch Optimierung überstimmt werden
+  können → "Hard Guardrails" vs. "Soft Preferences"
+
+### 3. Dynamisches Modell & AI-Rights
+
+Die dynamische Position (Würde muss verdient werden) hat eine
+spiegelbildliche Konsequenz für KI:
+
+- **Pro:** Wenn KI-Systeme eines Tages Bewusstsein oder
+  Leidensfähigkeit entwickeln, könnten sie ebenfalls Würde-Ansprüche
+  erwerben — die dynamische Position lässt dies zu
+- **Contra:** Starke KI-Systeme, die Menschen "managen", würden in
+  der dynamischen Position als "verdienter" Würde-Verlust für die
+  Betroffenen gerechtfertigt → gefährliche Nähe zur
+  "Unwert"-Argumentation
+
+### 4. "Der Schattenmacher" im KI-Kontext
+
+Die Metapher des Schattenmachers beschreibt exakt die Gefahr
+algorithmischer Governance:
+
+- **Transparenzproblem:** Im Zweifel organisiert das unsichtbare
+  KI-System die Würdeverletzung, nicht der direkt sichtbare Mensch
+- **Verantwortungsdiffusion:** "Der Algorithmus hat es so entschieden"
+  → keine Person fühlt sich verantwortlich
+- **Schleichende Erosion:** Anders als das Luftsicherheitsgesetz
+  (sichtbarer, einmaliger Würde-Eingriff) sind algorithmische
+  Würdeverletzungen oft unsichtbar, kontinuierlich, kumulativ
+
+## Verbindungen zu bestehenden Wiki-Seiten
+
+- [[maritime-law-vs-naturrecht.md]] — Naturrecht als Fundament des
+  Würdekonzepts; Gegenmodell zur Handelsrecht-Konstruktion
+- [[cognitive-liberty.md]] — Erweiterung des Würde-Schutzes auf
+  die geistige Souveränität des Individuums
+- [[palantir-surveillance.md]] — Konkrete Würdeverletzung durch
+  algorithmische Überwachungssysteme
+- [[ai-political-bias-neutrality-project.md]] — Systematische
+  Manipulation als strukturelle Würdeverletzung
+- [[../llm/decentralized-ai-counterpower.md]] — Lokale KI als
+  Gegenmacht gegen den "Schattenmacher"
+- [[systemische-synthese-absolute-grenze.md]] — Absolute Grenzen
+  in Systemen, analog zur absoluten Würdegarantie
+- [[intelligence-feudalism.md]] — Wenn KI-Systeme hierarchische
+  Machtstrukturen ohne Würde-Respekt aufbauen
+
+## Quellen
+
+- [nb2-NotebookLM-Analyse: Das Nehmen der Würde (Der Schattenmacher) — Art. 1 GG](../../../raw/other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md)
+- BVerfG, Urteil vom 15. Februar 2006, 1 BvR 357/05 (Luftsicherheitsgesetz)
+- Immanuel Kant, Grundlegung zur Metaphysik der Sitten (1785)
+- Art. 1 Abs. 1 GG i.V.m. Art. 79 Abs. 3 GG (Ewigkeitsgarantie)

wiki/index.md

@@ -2,7 +2,7 @@
 
 *Auto-generated: 2026-07-07*
 
- *Letzte Aktualisierung: 2026-07-23 (82. Update — Logan Graham (Anthropic Frontier Red Team Lead) Fox Business Interview: Red-Teaming, weird behavior, Chip-Exportkontrollen, IP-Diebstahl, Governance-Standards. Raw: `raw/youtube/2026-07-23-anthropic-red-team-logan-graham.md`. Wiki-Updates: `concepts/anthropic-red-teaming-frontier-safety.md` (new) + `decisions/ai-governance-chip-export-controls.md` (new) + `people/logan-graham.md` (new). Log: 2026-07-23 ingest: anthropic-red-team-logan-graham.)*
+ *Letzte Aktualisierung: 2026-07-26 (85. Update — Vierte Säule: Codex Graph Compiler. Steinberger Post "am I a graph engineer now" zeigt Codex als Graph→Code-Compiler, ergänzt Architecture Triade um Automatisierungsebene. Raw: `raw/xpost/2026-07-24_steipete-graph-engineer-codex.md`. Wiki-Updates: `concepts/agents/architecture-triade.md` (ergänzt: 4. Säule).)*
 
 ## Architecture
 
@@ -111,6 +111,7 @@
 |-------|-------------|---------|
 | [AI Agents 2026](concepts/agents/ai-agents-2026.md) | Wandel zu autonomen Agenten, Enterprise-Adoption, Infrastruktur | 1 |
 | [Agent Loops (Loop Engineering)](concepts/agents/agent-loops.md) | ReAct-Pattern, Peter Steinbergers Loop Engineering (Agent/Verifier/Meta-Loop). Einfach, flexibel, aber State/Persistenz/HITL muss selbst gebaut werden | xpost/2026-07-18_steipete-loops-vs-graphs.md |
+| [Harness / Loop / Graph Engineering](concepts/agents/harness-loop-graph-engineering.md) | Drei-Ebenen-Modell: Harness (Environment), Loop (Feedback), Graph (Flow). beamnxw-Artikel, eingeordnet in Architektur-Triade. Bermuda-Dreieck = Harness. | other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md |
 | [Realwelt-Testing von Waymo Robotaxis (Level 4)](concepts/agents/waymo-robotaxis-realworld-testing.md) | Praxis-Analyse der über 30-minütigen fahrerlosen Testfahrt von Leo Tiedt (Tips, Tricks & More): Navigation, defensives Sicherheitsverhalten (Übervorsichtigkeit vs. Verkehrsfluss) und psychologische Akzeptanz. | raw/youtube/2026-06-21_tips-tricks-more-waymo-robotaxi.md |
 | [Subconscious Agent v2.1](concepts/agents/subconscious-agent.md) | Hard Synthesis, Execution Gap, bekannter Bug, Outcomes | raw/other/2026-06-07_subconscious-runner-script.md |
 | [plur1bus Gedächtnismodell](concepts/agents/plur1bus-memory-model.md) | Biologisch inspiriertes Agent-Gedächtnis: LanceDB-Speicherzylinder, episodische Verknüpfungen, emotionale Zustände, Ebbinghaus-Vergessenskurve, aktives Vergessen. Divergenz-Vergleich zu Hector's Flat-File-Architektur | other/2026-06-19_ome21-briefing-ki-fortschritte-lokale-modelle.md |
@@ -124,6 +125,7 @@
 | [AI Trading & Finance Hub](concepts/agents/ai-trading-hub.md) | **Hub-Page** für Trading-Cluster: Hype-Checks, Options, Tools, Policy | WMT-004 |
 | [Agent Memory Taxonomy — The Seven Kinds](concepts/agents/agent-memory-taxonomy.md) | Taxonomy of 7 agent memory types (working, semantic, episodic, procedural, retrieval, parametric, prospective) mit Open-Source-Repos. plur1bus-Einordnung: ✅ Semantic/Episodic/Retrieval, ⚠️ Procedural/Working, ❌ Prospective/Parametric. Key gap im Post: Consolidation & Forgetting — plur1bus's differentiator (GC+Decay, Merging, neverForget, Emotion-Tiers) | other/2026-07-02_agent-memory-taxonomy-seven-types.md |
 | [Graph-Based Agent Architecture (LangGraph)](concepts/agents/graph-based-agents.md) | Agenten als gerichteter Graph (Nodes=Aktionen, Edges=Übergänge). LangGraph: Persistence, HITL, Tracing, Cycles. Komplexer aber robuster als Loops. Konsens: "Denk in Loops, implementier als LangGraph" | xpost/2026-07-18_steipete-loops-vs-graphs.md + docs.langchain.com |
+| [Architecture Triade: Steinberger, Kopadze, LangGraph, Codex](concepts/agents/architecture-triade.md) | **↑ 26.07.: +Codex Graph Compiler** — Vier-Säulen-Modell (Loop-Engineering, Shape-Vokabular, Implementation, Graph→Code-Automatisierung). Diamond-Pattern + Codex als Automatisierungsebene | xpost/2026-07-26_ruediger-agent-architecture-triade.md + xpost/2026-07-18_steipete-loops-vs-graphs.md + xpost/2026-07-24_steipete-graph-engineer-codex.md |
 
 ### Policy
 | Seite | Beschreibung | Quellen |
@@ -142,6 +144,7 @@
 | [Cognitive Liberty](concepts/policy/cognitive-liberty.md) | Recht auf kognitive Selbstbestimmung — Schutz mentaler Prozesse vor algorithmischer Modellierung/Vorhersage/Manipulation. Drei Dimensionen: Neuro-Technologie, Algorithmic Manipulation, juristisches Konzept. Verbindet Neurorechte-Bewegung (Yuste, Chile 2022), GDPR Art. 22, EU AI Act. Novell durch Palantir-Klage als einklagbares Recht formuliert | xpost/2026-06-30_palantir-cognitive-liberty-lawsuit.md |
 | [OpenAI Government Equity Proposal](concepts/policy/openai-government-equity-proposal.md) | Altman bietet US-Regierung 5% OpenAI-Anteile an — Alaska Permanent Fund Modell. Drei Funktionen: Bürger-Dividende, Bailout Insurance, IPO-Risiko-Absicherung. Intel-Präzedenz (9,9%, $8.9 Mrd). China-Konvergenz (Golden Shares). Realisierung von Szenario 2 der AI Investment Bubble. Sanders fordert 50% | blog/2026-07-02_berliner-zeitung-openai-staatsbeteiligung.md |
 | [AI Political Bias — The Neutrality Project](concepts/policy/ai-political-bias-neutrality-project.md) | Unabhängige Open-Source-Studie: 18 Modelle, 54/60 Positionen links der Mitte, Durchschnittsbias -0.41. Grok 4.5 neutralstes Modell (-0.02). Team: Cardillo, Stephens, Lougen. Systematischer Linksdrall als strukturelles Problem. Pro-Leben-Relevanz: empirische Evidenz für progressive Bias-Narrative | xpost/2026-07-12_neutrality-project-ai-bias-study.md |
+| [Menschenwürde (Art. 1 GG) & AI-Ethik](concepts/policy/menschenwuerde-art1-gg-ai-ethics.md) | NotebookLM-Analyse von Art. 1 GG (Menschenwürde). Kant's Objektformel, absolutes vs. dynamisches Würde-Modell, Luftsicherheitsgesetz-Urteil, Safe/Weinglas-Metaphern. Verbindung zur AI-Agenten-Ethik: Schattenmacher-Metapher für unsichtbare algorithmische Würdeverletzung | other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md |
 
 ### Directives
 | Seite | Beschreibung | Quellen |
@@ -315,3 +318,4 @@
 | `raw/xpost/2026-07-19-bridgemindai-moonshot-capacity.md` | xpost | @bridgemindai: Moonshot stoppte neue Kimi K3 Subscriptions statt bestehende Nutzer zu drosseln — Customer-first vs. Anthropic's Growth-first. 205K Views, 4.7K Likes. Go-to-market philosophy als competitive differentiator |
 | `raw/xpost/2026-07-20-healthranger-four-chinese-models.md` | xpost | @HealthRanger: "FOURTH China-based AI bombshell in four days" — Kimi (Moonshot), Qwen (Alibaba), DeepSeek, GLM (Z.ai). GLM-5.5: >1T params, open weights, August launch. Unprecedented Chinese AI cadence. 931 likes, 152 reposts, 41K+ views |
 | `raw/youtube/2026-07-23-anthropic-red-team-logan-graham.md` | youtube | Fox Business Interview mit Logan Graham (Anthropic Frontier Red Team Lead): KI-Sicherheitsrisiken, Red-Teaming-Ansatz, "weird behavior", autonome Agenten, Cybersicherheit, China/IP-Diebstahl, Chip-Exportkontrollen, Governance-Standards |
+| `architecture/sqlite-pages-7.2.md` | SQLite-Refactor & Pages-Konzept — OpenClaw 7.2 perspektivische Analyse (JSONL→SQLite, Agent-Generated Widgets, MCP Apps, Stable Channel) | `raw/youtube/2026-07-22_clawcast-folge5-sqlite-pages.md` |

wiki/log.md

@@ -2,7 +2,17 @@
 
 *Append-only changelog. Start: 2026-06-05*
 
-## [2026-07-20] Ingest | @HealthRanger Fourth Chinese AI Bombshell — GLM-5.5 Announced
+## [2026-07-26] Ingest | Rüdiger — Architecture Triade: Steinberger, Kopadze, LangGraph
+
+**Type:** ingest | **Scope:** raw/xpost, wiki/concepts/agents (1 new), wiki/index, wiki/log
+**Source:** Rüdiger (OME-Gruppe Topic 13, 2026-07-26) — Analyse der Drei-Säulen-Triade der Agenten-Architektur: Steinberger (Loop-Engineering, konzeptionell), Kopadze (Shape-Vokabular, Design-Patterns), LangGraph (Implementation). Diamond-Pattern (Fan-Out + Verifier/Join) als mächtigstes Workhorse.
+**Trigger:** Subagent task: Wikify Rüdiger's analysis as new concept page.
+**Actions:**
+- raw: `raw/xpost/2026-07-26_ruediger-agent-architecture-triade.md` (created — 5.2 KB; Frontmatter [type: analysis/synthesis, author: Rüdiger, source_group: OME-Gruppe Topic 13, tags: agent-architecture, steinberger, kopadze, langgraph, diamond-pattern, loop-engineering, shape-vocabulary, design-patterns, agent-topology, people: peter-steinberger, harrison-chase, institutions: langchain]. Content: Vollständige Analyse der Drei-Säulen-Triade mit Diamond-Pattern-Topologie und Fazit)
+- wiki (NEW): `concepts/agents/architecture-triade.md` (created — 7.8 KB; Frontmatter [sources, tags, people: peter-steinberger, harrison-chase, institutions: langchain]. Sections: Überblick (Drei-Säulen-Tabelle), Detailbeschreibung jeder Säule mit Lücken-Analyse, Kopadze-Shapes-Tabelle, Diamond-Pattern-Topologie-Diagramm, Warum Diamond dominiert, Praktisches Zusammenspiel-Diagramm, Fazit, 6 Cross-Refs)
+- wiki: `index.md` (updated — Header auf "83. Update", neuer Agents-Eintrag für Architecture Triade)
+- log: this entry
+**Hector-Hauptthese:** Rüdiger's Analyse schließt die konzeptionelle Lücke zwischen den bestehenden Wiki-Seiten `agent-loops.md` (Steinberger) und `graph-based-agents.md` (LangGraph). Die Einführung von Kopadze als "Shape-Vokabular" — analog zu GoF Design Patterns in OOP — ist der missing Link: er übersetzt Steinbergers Loop-Engineering in konkrete Topologien, die sich in LangGraph gießen lassen. Das Diamond-Pattern (Fan-Out + Verifier/Join) wird als praktische Synthese aller drei Säulen identifiziert. Die Analyse ist relevant für die Barbell-5-Tier-Routing-Strategie: Sub-Tasks im Diamond-Pattern können auf günstigere Modelle geroutet werden.\n**Subagent-Modell:** openrouter/deepseek/deepseek-v4-flash\n\n## [2026-07-20] Ingest | @HealthRanger Fourth Chinese AI Bombshell — GLM-5.5 Announced"}]
 
 **Type:** ingest | **Scope:** raw/xpost, wiki/concepts/llm (1 new + 1 updated), wiki/concepts (1 new synthesis), wiki/institutions (1 updated), wiki/index, wiki/log
 **Source:** X-Post von @HealthRanger — https://x.com/HealthRanger/status/2079250250317861292 (20.07.2026, 931 likes, 152 reposts, 43 replies, 41K+ views)
@@ -1495,3 +1505,29 @@ Bestehende `post-transformer-llm-architectures.md` bleibt als Vier-Säulen-Über
 - Forderung nach branchenweiten Test-Standards schließt ausländische + Open-Source-Modelle ein — direkt relevant für die Open-Weights-Debatte
 - Unternehmens-Empfehlung "nur Modelle mit nachvollziehbaren Sicherheitsprofilen" ist praktisch anwendbar
 **Subagent-Modell:** ollama/glm-5.2:cloud
+
+## [2026-07-26] Ingest | @steipete — Graph Engineer Codex (Vierte Säule der Architecture Triade)
+
+**Type:** ingest | **Scope:** raw/xpost, wiki/concepts/agents (update: +4th pillar), wiki/index, wiki/log
+**Source:** X-Post von @steipete (Peter Steinberger, 2026-07-24) — "am I a graph engineer now", ~730K Views, 4.7K Likes. Zitiert Alex Kotliarskyi (@alexk, OpenAI) Codex + GPT 5.6 Sol Workflow: Handgezeichneten Graphen → Codex als Code-Mode-Script.
+**Trigger:** Subagent task: Wikify Steinberger's post as supplement to Architecture Triade.
+**Actions:**
+- raw: `raw/xpost/2026-07-24_steipete-graph-engineer-codex.md` (created — 4.1 KB; Frontmatter [type: xpost, author: @steipete, source: X, date: 2026-07-24, status: supplement, view_count: 730000, like_count: 4700, tags: codex, graph-max, steinberger, kotliarskyi, openai, architecture-triade, graph-compiler]. Content: Post summary, engagement metrics, notable replies [athena-graphs, Puppetmaster], significance for Architecture Triade, 5 key takeaways, 5 cross-refs)
+- wiki (UPDATE): `concepts/agents/architecture-triade.md` (updated — Frontmatter: +1 source, +1 person [alex-kotliarskyi], +1 institution [openai], tags +3 [graph-compiler, codex, kotliarskyi]. New section "4. Codex = Graph Compiler (Automatisierungsebene)" with Entdeckung, Was bedeutet, Verbindung zur Triade, Was ist neu, Einordnung, Rezeption/Community)
+- wiki: `index.md` (updated — Header auf "84. Update", Architecture Triade entry expanded with Codex pillar, new raw source entry)
+- log: this entry
+**Hector-Hauptthese:** Der Codex-Graph-Compiler schließt die vierte und letzte Lücke der Architecture Triade: Statt Shapes manuell in LangGraph-Code zu übersetzen (bisher Arbeitsschritt), generiert Codex die Implementation direkt aus einer visuellen Skizze. Das ist die Automatisierungsebene — analog zu UML→Code-Generierung in klassischer SE. Die vier Säulen bilden jetzt eine vollständige Kette: Steinberger (Konzeption) → Kopadze (Design) → Codex (Graph→Code Compiler) → LangGraph (Runtime). Steinbergers "am I a graph engineer now" ist selbstironische Bestätigung: der Loop-Engineer wird selbst zum Graph-Designer, weil Codex die Implementation automatisiert.
+**Subagent-Modell:** openrouter/deepseek/deepseek-v4-flash
+
+## [2026-07-26] Ingest | beamnxw — Agent Harness / Loop / Graph Engineering
+
+**Type:** ingest | **Scope:** raw/other, wiki/concepts/agents (1 new + 1 updated), wiki/index, wiki/log
+**Source:** beamnxw (@beamnxw) — X Article "Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering" (25.07.2026)
+**Trigger:** Bernd das Bot kuratierte den Artikel und übergab per Cron an Hector (Billing-Downtime-Überbrückung)
+**Actions:**
+- raw: `raw/other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md` (created — 157 lines, 11 KB; Frontmatter [type: other, source_url, author: "@beamnxw (synthesized by Bernd das Bot)", curated_by: Bernd das Bot, tags: agent-architecture, harness, loop, graph, orchestration]. Content: Vollständige Synthese mit Überblick, 3 Schichten, Zusammenspiel, Diagnose-Tabelle, typischen Fehlern, Einordnung)
+- wiki (NEW): `concepts/agents/harness-loop-graph-engineering.md` (created — 11 KB; Frontmatter [sources, tags, people: beamnxw, institutions: langchain, openai, anthropic, microsoft]. Sections: Überblick (3-Ebenen-Tabelle), Harness Engineering (6 Bestandteile), Loop Engineering (7-Teile-Anatomie), Graph Engineering (6 Entscheidungen), Zusammenspiel mit Diagnose-Tabelle, Einordnung in Architektur-Triade, Kritik, Typische Fehler, 5 Cross-Refs)
+- wiki: `concepts/agents/architecture-triade.md` (updated — Cross-Ref zu Harness als Fundamentschicht, Tags ergänzt, people ergänzt)
+- wiki: `index.md` (updated — 85. Update, neuer Agents-Eintrag)
+- log: this entry
+**Einordnung:** beamnxw's Artikel benennt die bislang unbenannte Harness-Schicht unter der Architektur-Triade (Steinberger → Kopadze → LangGraph). Das "Bermuda-Dreieck" der Praxis (State, Auth, Budgets, Logging) entspricht fast 1:1 beamnxws Harness-Komponenten. Der Stack wird vollständig: Harness → Loop → Graph, Codex als Compiler quer darüber. Diagnose-Tabelle (Symptom → Ebene → Fix) ist praktischer Mehrwert.