knowledge-base/wiki/concepts/agents/architecture-triade.md

---
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
tags: [concept, agents, architecture, steinberger, kopadze, langgraph, diamond-pattern, loop-engineering, shape-vocabulary, design-patterns, orchestration, agent-topology]
people: [peter-steinberger, harrison-chase]
institutions: [langchain]
---

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

## 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`)
- LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview
- Harrison Chase (@hwchase17): https://x.com/hwchase17/status/1915845925316268471