knowledge-base/wiki/concepts/agents/graph-engineering.md

---
created: 2026-07-26
updated: 2026-07-26
sources:
  - xpost/2026-07-25_anatoli-kopadze-graph-engineering-guide.md
tags: [concept, agents, graph-engineering, workflows, orchestration, parallel-execution, verification, agent-architecture, shapes, chain, diamond, router, cycle]
people: [anatoli-kopadze]
---

# Graph Engineering — Die 4 Fundamental Shapes für AI Agent Workflows

> *"Most people use 10% of AI — type one prompt, close tab. The people using the other 90% aren't typing prompts at all. They're running agents in parallel, wired into graphs that check their own work."*
> — Anatoli Kopadze (@AnatoliKopadze), Juli 2026

## Definition

**Graph Engineering** ist die Disziplin, AI-Workflows als gerichtete Graphen zu modellieren und zu optimieren. **Tasks** sind Nodes, **Dependencies** sind Edges. Das Ziel: unabhängige Tasks parallel laufen lassen statt sequentiell — und die klassische lineare Loop-Struktur durch einen optimierten, kontrollierten Plan ersetzen.

Anders als [[graph-based-agents.md]] (das LangGraph als Implementierungsframework in den Mittelpunkt stellt), fokussiert Graph Engineering auf die **Shape-Klassifikation** — ein Vokabular von 4 fundamentalen Graph-Formen, die als Bausteine für jeden Agent-Workflow dienen.

## Shape 0 – Basics: Graph als visueller Plan

Jeder Graph besteht aus:
- **Nodes (Tasks):** Was soll passieren? (z.B. `research`, `code`, `test`, `review`, `decide`)
- **Edges (Dependencies):** Was muss vorher fertig sein?
- **Parallelität:** Tasks ohne Abhängigkeiten können gleichzeitig laufen

Der Shift von linearen Loops zu Graphen ist nicht nur technisch — es ist ein **Planungs-Paradigmenwechsel**: Statt "mach das immer wieder, bis es passt" → "zeichne den optimalen Pfad, dann führe ihn aus".

## Shape 1 – The Chain (Sequentiell)

```
A → B → C
```

**Wann verwenden:** Nur wenn Tasks wirklich voneinander abhängen.
**Vorteil:** Einfach, vorhersagbar, debug-bar.
**Nachteil:** Langsam — nutzt keine Parallelität.

> **Beispiel:** Datenbereinigung → Feature-Extraktion → Modell-Training. Jeder Schritt braucht den vorherigen.

## Shape 2 – The Diamond (Der Arbeitgeber) ⬥

```
         ┌── Worker 1 ──┐
Start ───┼── Worker 2 ──┼── Verifier/Merge ──→ Output
         └── Worker N ──┘
```

**Wann verwenden:** Für die meisten Alltags-Workflows.
**Was passiert:**
1. **Start-Node:** Verteilt die Aufgabe
2. **Fan-Out (Parallel Workers):** N unabhängige Agenten arbeiten parallel
3. **Verifier/Merge-Node:** Sammelt Ergebnisse, prüft Qualität, konsolidiert
4. **Output:** Fertiges Ergebnis

**Anwendungen:**
- **Research:** Mehrere Quellen parallel scannen → Synthese
- **Market Scans:** Gleichzeitige Analyse verschiedener Segmente
- **Code Reviews:** N Review-Agenten parallel → Merge der Findings

> 💡 **Kopadzes Empfehlung:** Starte IMMER mit dem Diamond. Es ist das mächtigste Pattern für den Alltag.

## Shape 3 – The Router (Entscheidungs-Verzweigung)

```
               ┌── Pfad A ──┐
Decision Node ──┼── Pfad B ──┼──→ Output
               └── Pfad C ──┘
```

**Wann verwenden:** Wenn das Ergebnis einer Task bestimmt, was als nächstes passiert.
**Was passiert:**
1. **Decision Node:** Ein Evaluations-Agent prüft das Ergebnis (z.B. "Ist der Code korrekt?")
2. **Routing:** Basierend auf dem Ergebnis wird zu einem spezifischen Pfad geroutet
3. **Ziel-Pfade:** Jeder Pfad hat seine eigene Logik

**Kern-Insight:** Die Branching-Logik lebt in der **Graph-Struktur** (den Edges), nicht im **Model Guess** (dem Prompt). Das macht das Verhalten deterministischer, testbarer und sicherer.

> **Beispiel:** Code-Generierung → Code-Review → [Bestanden? → Merge | Fehler gefunden? → Fix-Node | Sicherheitsproblem? → Escalation-Node]

## Shape 4 – The Cycle (Kontrollierte Schleife)

```
                ┌─────────────────────────┐
                │                         ▼
Start ──→ Process ──→ Check Condition ──→ Stop (wenn erfüllt)
                │
                └── (weiter, wenn nicht erfüllt)
```

**Wann verwenden:** Für Discovery-Work und iterative Verfeinerung.
**Wichtig:** Braucht eine **harte Stop-Bedingung** (max cycles, timeout, convergence threshold).

**Anwendungen:**
- **Bug Sweeps:** Wiederholte Tests, bis keine Fehler mehr gefunden werden
- **Iterative Refinements:** Schrittweise Verbesserung eines Outputs
- **Discovery Work:** Solange forschen, bis eine Schwelle erreicht ist

> ⚠️ **Risiko:** Ohne harte Stop-Bedingung wird der Cycle zum Infinite Loop.

## Step-by-Step: Graph from Scratch

Kopadzes 10-Schritte-Plan für den Bau eines Agent-Graphen:

1. **Define goal** — Was soll der Graph erreichen?
2. **List every sub-task** — Alle Einzelschritte (egal ob parallel oder sequentiell)
3. **Draw dependencies** — Welcher Schritt braucht welchen anderen?
4. **Choose dominant shape** — Starte mit **Diamond** (Shape 2). Es passt für 80% der Fälle
5. **Add Router/Cycle only where needed** — Füge Komplexität nur dort hinzu, wo der Diamond nicht reicht
6. **Add verification nodes** — Jeder kritische Pfad braucht eine Qualitätskontrolle
7. **Set limits** — Max parallel workers, max cycles, timeout, retry count
8. **Test small** — Erst mit einem Mini-Datensatz, dann skalieren
9. **Visualize and iterate** — Mach den Graphen sichtbar (Mermaid, LangGraph Studio), iteriere
10. **Scale** — Erhöhe Parallelität, füge Quellen hinzu, deploye in Produktion

## Vergleichstabelle: Shapes

| Shape | Name | Parallelität | Komplexität | Anwendung | Stop-Bedingung |
|-------|------|-------------|-------------|-----------|----------------|
| 1 | Chain | ❌ Keine | Einfach | Strikt sequentielle Pipelines | Natürliches Ende |
| 2 | Diamond | ✅ Hoch | Mittel | Research, Scans, Reviews | Merge/Verifier |
| 3 | Router | ⚠️ Pro Pfad | Mittel | Entscheidungsbäume | Ziel-Pfad-Ende |
| 4 | Cycle | ⚠️ Intern | Hoch | Discovery, Iteration | Hard Limit nötig |

## Verhältnis zu Loops & LangGraph

Kopadzes Graph Engineering ergänzt die bestehende [[graph-based-agents.md]]- und [[agent-loops.md]]-Debatte:

- **Loops = konzeptionelle Grundlage** (ReAct-Pattern, Steinbergers Loop Engineering)
- **LangGraph = Implementierungs-Framework** (State, Persistenz, HITL, Tracing)
- **Graph Engineering = Shape-Vokabular** (Chain, Diamond, Router, Cycle als Design-Bausteine)

Zusammen ergibt sich ein **3-Ebenen-Modell**:
1. **Konzeption:** In Loops denken (Steinberger)
2. **Design:** Shapes zeichnen (Kopadze)
3. **Implementation:** Als LangGraph bauen (Harrison Chase)

## Verwandte Konzepte

- [[graph-based-agents.md]] — LangGraph als Implementierungs-Framework
- [[agent-loops.md]] — Loop Engineering (ReAct-Pattern)
- [[../../architecture/agent-orchestration.md]] — Übergeordnete Orchestrierungs-Patterns
- [[../../architecture/model-routing.md]] — Model Routing als komplementäre Optimierung (richtiges Modell für jede Node)
- [[../../tools/openclaw.md]] — OpenClaw als Agent-Plattform
- [[ai-agents-2026.md]] — Gesamtentwicklung autonomer Agenten
- [[../../../tools/model-routing.md]] — Cost-Saving Patterns mit Model-Split
- [[../../concepts/llm/llm-model-catalog.md]] — Modell-Katalog für Node-Zuweisung

## Quellen

- @AnatoliKopadze (2026-07-25): Graph Engineering Guide — X-Thread (viral)
- [[../../../../raw/xpost/2026-07-25_anatoli-kopadze-graph-engineering-guide.md]] (Raw Source)
- [[graph-based-agents.md]] — Vergleich und Einordnung
- [[agent-loops.md]] — Loop vs. Graph Abgrenzung