hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
- 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.
This commit is contained in:
Hector 2026-07-26 22:40:59 +02:00
parent 25c2d88aec
commit eab5243e10
7 changed files with 570 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
raw/log.md
View file

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

157
raw/other/2026-07-26_bernd-agent-harness-loop-graph-engineering.md Normal file
View file

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

99
raw/other/2026-07-26_nb2-artikel1-gg-menschenwuerde.md Normal file
View file

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

151
wiki/concepts/agents/harness-loop-graph-engineering.md Normal file
View file

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

146
wiki/concepts/policy/menschenwuerde-art1-gg-ai-ethics.md Normal file
View file

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

4
wiki/index.md
View file

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

13
wiki/log.md
View file

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