diff --git a/raw/log.md b/raw/log.md index 77b6467..1933b33 100644 --- a/raw/log.md +++ b/raw/log.md @@ -1 +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. diff --git a/raw/other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md b/raw/other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md new file mode 100644 index 0000000..e115052 --- /dev/null +++ b/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).* diff --git a/raw/other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md b/raw/other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md new file mode 100644 index 0000000..c924030 --- /dev/null +++ b/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 diff --git a/wiki/concepts/agents/harness-loop-graph-engineering.md b/wiki/concepts/agents/harness-loop-graph-engineering.md new file mode 100644 index 0000000..a1f90d1 --- /dev/null +++ b/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 — +- 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 \ No newline at end of file diff --git a/wiki/concepts/policy/menschenwuerde-art1-gg-ai-ethics.md b/wiki/concepts/policy/menschenwuerde-art1-gg-ai-ethics.md new file mode 100644 index 0000000..fd558cb --- /dev/null +++ b/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) \ No newline at end of file diff --git a/wiki/index.md b/wiki/index.md index 2f04f36..8d34077 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -2,7 +2,7 @@ *Auto-generated: 2026-07-07* - *Letzte Aktualisierung: 2026-07-26 (84. 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).)* + *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 | @@ -143,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 | diff --git a/wiki/log.md b/wiki/log.md index 5cfc375..638e315 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1518,3 +1518,16 @@ Bestehende `post-transformer-llm-architectures.md` bleibt als Vier-Säulen-Über - 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.