INITIALIZING
0%
Die meisten KI-Agenten werden noch immer wie Checklisten gebaut. Graph Engineering betrachtet ein agentisches System nicht als einen einzelnen intelligenten Loop, sondern als ein ausführbares System aus Zuständen, Berechnungen und Kontrollflüssen.
Author: Mariwan Abu-Aland Email: amariwan9@icloud.com Status: Field Note / Active Research
Die meisten KI-Agenten werden noch immer wie Checklisten gebaut.
Erst recherchieren. Dann schreiben. Dann prüfen. Dann veröffentlichen.
Auf den ersten Blick klingt das logisch.
Bis das System in Produktion geht.
Dann beginnen die Probleme.
Ein Research-Schritt wartet auf einen anderen Schritt, obwohl er dessen Ergebnis überhaupt nicht benötigt. Fünf unabhängige Untersuchungen laufen nacheinander statt parallel. Ein fehlgeschlagener API-Aufruf zwingt den gesamten Workflow zum Neustart. Ein Reviewer bekommt einen riesigen Conversation-Transcript statt des konkreten Artefakts, das er tatsächlich prüfen soll. Und irgendwann wird das Context Window selbst zur Architektur.
Das Problem ist dann häufig nicht mehr der Prompt.
Das Problem ist die Form der Arbeit.
Genau hier setzt Graph Engineering an.
Es betrachtet ein agentisches System nicht als einen einzelnen intelligenten Loop, sondern als ein ausführbares System aus Zuständen, Berechnungen, Entscheidungen, Evidenz, Kontrollflüssen und Fehlerpfaden.
Das Modell liefert Intelligenz. Der Graph liefert Struktur.
Diese Trennung wird immer wichtiger, sobald AI Agents von Prototypen zu langlebigen Produktionssystemen werden.
⸻
Das ist wahrscheinlich die wichtigste Regel im Graph Engineering.
Menschen beschreiben Prozesse normalerweise chronologisch:
Erst A, dann B, dann C.
Aber eine zeitliche Reihenfolge bedeutet nicht automatisch eine technische Abhängigkeit.
Nehmen wir ein Research-System.
Es soll:
Eine naive Architektur sieht so aus:
USER
|
v
Marktforschung
|
v
Repository-Analyse
|
v
Wettbewerbsanalyse
|
v
Synthese
Aber wenn die Repository-Analyse keine Marktdaten benötigt und die Wettbewerbsanalyse ebenfalls unabhängig ist, ist diese Reihenfolge künstlich.
Die tatsächliche Architektur lautet:
┌─> Marktforschung ───────┐
│ │
USER ─────────────┼─> Repository-Analyse ───┼──> Synthese
│ │
└─> Wettbewerbsanalyse ──┘
Das ist ein fundamentaler Unterschied:
Sequenz ist eine zeitliche Beziehung. Dependency ist eine Datenbeziehung.
Die erste Frage beim Graph Engineering lautet deshalb:
Welche Informationen benötigt dieser Node tatsächlich?
Wenn Node B keine Daten aus Node A konsumiert, gibt es möglicherweise keinen Grund, B auf A warten zu lassen.
Das erzeugt unmittelbar drei Vorteile:
Geringere Latenz
Wenn drei unabhängige Aufgaben jeweils 10, 12 und 8 Sekunden benötigen:
sequenziell:
10 + 12 + 8 = 30 Sekunden
Bei paralleler Ausführung liegt die theoretische Dauer eher bei:
max(10, 12, 8) = 12 Sekunden
Natürlich kommen in realen Systemen Scheduling, Queueing, Rate Limits, Netzwerk- und Modelllatenz hinzu.
Aber die grundsätzliche Einsparung bleibt.
Bessere Fehlertoleranz
Wenn ein Branch fehlschlägt, müssen die anderen nicht automatisch ebenfalls fehlschlagen.
Bessere Skalierbarkeit
Unabhängige Arbeit kann auf mehrere Worker verteilt werden.
Anthropic beschreibt genau diesen Vorteil in seinem Multi-Agent-Research-System: unabhängige Research-Aufgaben werden parallelisiert, während die Ergebnisse anschließend zusammengeführt werden. Gleichzeitig steigt dadurch der Tokenverbrauch erheblich.
⸻
Eine häufige Fehlinterpretation lautet:
A -> B
bedeutet:
"B passiert nach A."
Eine bessere Interpretation lautet:
"B darf ausgeführt werden, sobald ein definierter Zustand erreicht wurde und ein bestimmter Datenvertrag von A verfügbar ist."
Das ist wesentlich präziser.
Beispiel:
Research Agent
|
v
Raw Findings
|
v
Normalizer
|
v
Deduplicator
|
v
Evidence Store
Die Verbindung zwischen Research Agent und Normalizer transportiert Daten.
Die Verbindung zwischen Normalizer und Deduplicator transportiert bereits normalisierte Records.
Die Verbindung zum Evidence Store transportiert strukturierte und validierte Artefakte.
Damit wird der Edge selbst zu einem Teil der Architektur.
Ein Edge kann beispielsweise definieren:
Damit wird aus A -> B ein tatsächlicher technischer Vertrag.
⸻
Einen Node, den du nicht präzise beschreiben kannst, kannst du nur schwer zuverlässig testen, routen, ersetzen oder überwachen.
Ein Produktions-Node sollte mindestens besitzen:
Beispiel:
{
"node": "source_researcher",
"input": {
"topic": "string",
"source_type": "primary | secondary"
},
"output": {
"claim": "string",
"source_url": "string",
"evidence": "string",
"confidence": "high | medium | low"
},
"failure": {
"type": "no_primary_source",
"retryable": false
}
}
Das verändert die Architektur fundamental.
Ohne Contract muss der nächste Node interpretieren, was das Modell zufällig produziert hat.
Mit Contract weiß er exakt, was er bekommt.
Dadurch werden möglich:
Und vor allem:
Nodes werden austauschbar.
Du kannst beispielsweise das zugrunde liegende Modell austauschen, ohne die gesamte Pipeline neu zu bauen.
Solange der Contract stabil bleibt, bleibt die Architektur stabil.
⸻
Das ist einer der größten Unterschiede zwischen Demo-Agenten und Produktionssystemen.
Nicht jede Operation braucht ein LLM.
Zum Beispiel:
const usable = results
.filter(Boolean)
.flatMap(result => result.items);
const unique = [...new Map(
usable.map(item => [item.source_url, item])
).values()];
Dafür braucht man keinen Agenten.
Filtern ist deterministisch. Flattening ist deterministisch. Deduplication ist deterministisch. Sortieren ist deterministisch. Schema Validation ist deterministisch.
Viele State Transitions sind ebenfalls deterministisch.
Eine gute Faustregel lautet:
Verwende Modelle für Entscheidungen, die schwer formal zu spezifizieren sind. Verwende Software für Entscheidungen, die einfach formal zu spezifizieren sind.
Das verbessert:
Ein Graph, bei dem jede Datenübertragung einen neuen LLM-Call benötigt, ist nicht automatisch fortschrittlich.
Er ist häufig einfach teuer.
⸻
Die meisten Agentensysteme lassen sich aus relativ wenigen grundlegenden Kontrollflussmustern zusammensetzen.
Die Chain
A -> B -> C -> D
Verwende sie, wenn jeder Schritt tatsächlich vom vorherigen Ergebnis abhängt.
Beispiel:
Outline → Draft → Fact Check → Finalize
Chains sind einfach.
Sie werden aber häufig verwendet, obwohl ein Teil der Arbeit eigentlich parallelisiert werden könnte.
Der Diamond
-> B1 -
/ \
A ------> B2 -----> C
\ /
-> B3 -
Das ist die klassische Fan-out/Fan-in-Struktur.
Ein Node erzeugt mehrere unabhängige Aufgaben.
Diese werden parallel ausgeführt.
Anschließend werden die Ergebnisse zusammengeführt.
Das ist besonders nützlich für:
Der Router
-> QUICK PATH
/
CLASSIFIER ----
\
-> DEEP AUDIT
Der Router entscheidet abhängig vom Zustand, welcher Pfad notwendig ist.
Beispiel:
LOW RISK → kleines Modell → schnelle Prüfung → DONE
HIGH RISK → starkes Modell → mehrere unabhängige Prüfungen → Evidence Verification → Human Approval
Der wichtige Punkt:
Das Modell kann einen Pfad vorschlagen. Die Runtime muss entscheiden, welcher Pfad tatsächlich ausgeführt werden darf.
Damit bleibt die Flexibilität des Modells erhalten, ohne ihm vollständige Kontrolle über die Systemarchitektur zu geben.
Der Controlled Cycle
┌────────────────┐
│ ↓
WORK -> VERIFY -> PASS -> DONE
|
└-> FAIL -> REPAIR
Cycles sind sinnvoll, wenn die notwendige Anzahl an Iterationen vorher nicht bekannt ist.
Zum Beispiel:
Aber:
repeat until good
ist keine ausreichende Spezifikation.
Ein produktionsfähiger Cycle benötigt beispielsweise:
Ein Cycle ohne Stop-Bedingung ist kein robustes Agentensystem.
Es ist ein unkontrollierter Ressourcenverbraucher.
⸻
Parallelisierung bekommt viel Aufmerksamkeit.
Das schwierigere Problem ist häufig das Zusammenführen.
Angenommen, fünf Research Agents liefern:
Du hast jetzt 100 Findings.
Die naive Lösung:
100 Findings → LLM
führt das Context-Problem einfach auf einer höheren Ebene fort.
Besser:
Workers → Normalize → Deduplicate → Cluster → Rank → Evidence Verification → Synthesis
Der Join sollte also nicht einfach Informationen anhäufen.
Er sollte Informationen verdichten.
Das ist ein entscheidender Unterschied.
Ein guter Graph maximiert nicht die Menge der Informationen, die downstream transportiert werden.
Er maximiert deren Informationsdichte.
⸻
Ein Join erzeugt Synchronisation.
Synchronisation erzeugt Wartezeit.
Angenommen:
A = 3 Sekunden
B = 20 Sekunden
C = 4 Sekunden
Wenn die nächste Stufe alle drei Ergebnisse benötigt:
max(A, B, C) = 20 Sekunden
Aber wenn C bereits mit dem Ergebnis von A arbeiten kann, muss es möglicherweise nicht auf B warten.
Das kann zu einer Streaming- oder inkrementellen Architektur führen:
A ──────> Partial Processing
B ──────> Update
C ──────> Update
Damit beginnt Downstream-Verarbeitung bereits, bevor die gesamte Upstream-Arbeit abgeschlossen ist.
Hier beginnt Graph Engineering stark an klassische Distributed-Systems-Theorie zu erinnern.
Du musst über folgende Themen nachdenken:
Parallelität ist daher nicht einfach:
Promise.all(...)
Parallelität ist ein Ressourcenmanagementproblem.
⸻
Ein Produktionsgraph sollte erklären können, warum eine bestimmte Route gewählt wurde.
Beispiel:
const decision = await classifyRisk(change);
switch (decision.severity) {
case "low": return quickReview(change);
case "high": return fullParallelAudit(change);
default: return humanReview(change);
}
Der Classifier ist probabilistisch.
Der Switch ist deterministisch.
Diese Trennung ist extrem wertvoll.
Das Modell beantwortet:
"Wie sieht diese Situation aus?"
Die Runtime beantwortet:
"Was darf das System aufgrund dieser Klassifikation tun?"
Das wird besonders wichtig, wenn Agents Zugriff auf Tools oder externe Systeme haben.
Statt:
LLM → beliebiges Tool → Side Effect
sollte eine sichere Architektur eher so aussehen:
Model Decision → Policy Gate → Authorized Action → Verification → Commit
Der Graph wird damit zu einer Control Plane rund um die Modellautonomie.
⸻
Einer der wertvollsten Nodes produziert häufig überhaupt keinen neuen Content.
Seine Aufgabe ist es, schlechte Arbeit daran zu hindern, downstream zu gelangen.
Bei einem Research-System kann ein Verifier prüfen:
Bei Software:
Die Architektur:
GENERATOR → VERIFIER
/ \
PASS FAIL
| |
v v
NEXT REPAIR
|
└──> VERIFIER
Das erzeugt eine klare Rollentrennung.
Der Generator erzeugt. Der Verifier hinterfragt. Der Repairer verändert. Der Finalizer veröffentlicht.
Das ist deutlich robuster als:
"Generiere die Antwort und überprüfe gleichzeitig, ob sie korrekt ist."
Anthropic beschreibt ein ähnliches Evaluator-Optimizer-Muster, bei dem ein Modell Output erzeugt und ein separates Bewertungsstadium Feedback für eine weitere Iteration liefert.
⸻
Bei Research-Agenten gibt es noch ein weiteres Problem:
Provenance.
Eine Aussage sollte nicht einfach so aussehen:
{ "claim": "X is faster than Y" }
Sondern beispielsweise:
{
"claim": "X is faster than Y",
"evidence": [
{
"source": "https://example.com/report",
"location": "page 12",
"excerpt": "...",
"retrieved_at": "2026-08-17T18:20:00Z"
}
],
"confidence": 0.91
}
Jetzt kann der Graph die Evidenz unabhängig überprüfen.
Er kann erkennen:
Das ist wesentlich stärker als am Ende einfach einen Prompt auszuführen:
"Füge bitte Quellen hinzu."
Citation sollte Teil des Datenmodells sein, nicht Dekoration am Ende.
⸻
Hier trennt sich der Prototyp vom Produktionssystem.
Ein schönes Diagramm mit Boxes und Arrows reicht nicht.
Ein Produktionsworkflow muss mit folgenden Situationen umgehen können:
Dafür benötigt der Graph durable State.
Zum Beispiel:
run_id
graph_version
current_node
completed_nodes
pending_nodes
artifacts
decisions
evidence
budgets
retry_counts
approvals
errors
timestamps
Aber State darf nicht mit dem gesamten Conversation Context verwechselt werden.
Vermeide:
10.000 Token Transcript
+
alle Tool Calls
+
alle bisherigen Outputs
+
gesamte Historie
für jeden nächsten Node.
Besser:
state
|
+-- artifact_id
+-- evidence_ids
+-- decision
+-- metadata
+-- status
Die eigentlichen Artefakte liegen dauerhaft gespeichert.
Der Graph transportiert Referenzen.
Zum Beispiel:
Research Agent → research/report-183.json → Verifier
statt:
Research Agent → 12.000 Token Research → Verifier
Das reduziert nicht nur Token.
Es erzeugt eine Artifact Boundary.
Das Artefakt kann versioniert, geprüft, wiederverwendet und unabhängig getestet werden.
Frameworks wie LangGraph behandeln Persistenz und Checkpointing inzwischen als zentrale Bestandteile langlebiger Workflows. Dadurch können Graphen pausiert, wiederaufgenommen und nach Fehlern fortgesetzt werden.
⸻
Stell dir einen Workflow vor, der 20 Minuten läuft.
Nach 17 Minuten:
Research ✓
Analysis ✓
Verification ✓
Draft ✓
Dann crasht der Worker.
Ein naives System sagt:
Alles noch einmal.
Ein langlebiges System sagt:
Resume from checkpoint.
Das ist ein fundamentaler Unterschied.
Wenn der Workflow A → B → C → D → E lautet und D fehlschlägt, möchtest du:
A ✓
B ✓
C ✓
D retry
E pending
und nicht:
A redo
B redo
C redo
D retry
E pending
Aber Checkpointing allein reicht nicht.
Du benötigst zusätzlich Idempotency.
Angenommen:
send_email()
führt den Versand erfolgreich aus.
Direkt danach crasht der Worker, bevor der Erfolg gespeichert wird.
Beim Retry wird:
send_email()
erneut ausgeführt.
Der Benutzer erhält zwei Nachrichten.
Deshalb benötigen Side-Effect-Nodes häufig Idempotency Keys:
idempotency_key = run_id + node_id + logical_operation_id
Damit kann die Runtime erkennen:
gleiche logische Operation versus neue Operation
Das ist klassisches Distributed-Systems-Engineering – angewendet auf AI Workflows.
⸻
Produktionssysteme fragen nicht:
"Was passiert, wenn dieser Node ausfällt?"
Sie definieren die Antwort vorher.
Fehler können beispielsweise sein:
TRANSIENT
PERMANENT
SEMANTIC
AUTHORIZATION
RESOURCE
SAFETY
Diese Fehler dürfen nicht alle gleich behandelt werden.
Eine sinnvolle Policy kann sein:
RETRY → Network Timeout
FALLBACK → Primary Source unavailable
SKIP → Optional Branch failed
REPAIR → Invalid JSON
ESCALATE → High-risk operation
PAUSE → HUMAN APPROVAL
STOP → Budget exceeded
Damit wird Fehlerbehandlung Teil des Graphen.
Nicht nur ein try/catch irgendwo tief im Code.
⸻
"Retry dreimal" ist keine Reliability Strategy.
Ein Retry sollte nur stattfinden, wenn der Fehler tatsächlich transient sein könnte.
Zum Beispiel:
HTTP 429
HTTP 502
Connection Reset
Temporary Provider Failure
können sinnvoll retrybar sein.
Aber:
Invalid Schema
Invalid Tool Arguments
Missing Evidence
Policy Violation
werden durch einen identischen Retry häufig nicht besser.
Sonst entsteht:
FAIL → same input → same model → same prompt → FAIL → repeat
Das ist keine Recovery.
Das ist Wiederholung.
Eine echte Reparatur sollte eine Variable verändern:
FAIL → DIAGNOSE → CHANGE STRATEGY → RETRY
⸻
Nehmen wir Research.
Wir wissen m��glicherweise nicht vorher, wie viele Quellen benötigt werden.
Deshalb kann:
research → evaluate → research → evaluate
sinnvoll sein.
Aber der Graph muss wissen, wann genug genug ist.
Zum Beispiel:
let iteration = 0;
let stagnantRounds = 0;
const seen = new Set<string>();
while (
iteration < MAX_ITERATIONS &&
stagnantRounds < MAX_STAGNANT_ROUNDS
) {
const findings = await discover();
const fresh = findings.filter(
item => !seen.has(item.key)
);
for (const item of fresh) seen.add(item.key);
stagnantRounds = fresh.length === 0 ? stagnantRounds + 1 : 0;
iteration++;
}
Der entscheidende Teil ist nicht der Loop.
Es ist der Zustand.
Das System merkt sich bereits untersuchte Informationen.
Ohne diesen Zustand können dieselben Suchideen, Quellen oder verworfenen Hypothesen immer wieder auftauchen.
Ein produktiver Cycle benötigt deshalb:
⸻
Diese Unterscheidung ist extrem wichtig.
State umfasst alles, was das System benötigt, um korrekt weiterzulaufen.
Context ist nur der Teil dieses States, den ein bestimmter Model Call tatsächlich benötigt.
Beispiel:
GRAPH STATE
├── research_artifacts
├── source_metadata
├── decisions
├── permissions
├── retry_count
├── budget
├── approvals
└── execution_history
Der Synthesis-Agent benötigt möglicherweise nur:
SYNTHESIS CONTEXT
├── relevant findings
├── evidence
├── user requirements
└── output schema
Das bedeutet:
Context Engineering wird zu einem Graph-Problem.
Jeder Node sollte den kleinsten ausreichenden Context erhalten.
Das reduziert:
Und es verbessert gleichzeitig die Security.
⸻
Das wird besonders wichtig, sobald Agents Zugriff auf Tools und Unternehmensdaten bekommen.
Stell dir vor:
Research Agent → Customer Database → Publishing Agent
Wenn der Publishing Agent keine privaten Kundendaten benötigt, sollte er sie niemals erhalten.
Besser:
Research Data → Redaction → Public Evidence → Publishing
Damit wird der Datenfluss selbst zu einem Teil des Security Model.
Ein wichtiger Grundsatz lautet:
Data Flow determines Authority.
Je mehr Daten und Tools ein Node erhält, desto größer wird sein potenzieller Blast Radius.
Daher sollte auch bei Agents das Prinzip der Least Privilege gelten:
⸻
Human Approval wird häufig schlecht implementiert.
Die naive Variante:
Agent → "Are you sure?"
Das ist letztlich nur ein weiterer Prompt.
Ein echtes Human Gate ist eine Execution Boundary:
┌─> APPROVE → Continue
Agent → Gate ───┼─> EDIT → Modified State
└─> REJECT → Repair / Stop
Der Graph muss dafür:
Ein Mensch ist kein weiterer Agent.
Ein Mensch ist ein externes Ereignis.
Diese Unterscheidung ist architektonisch wichtig.
⸻
Normale Application Logs reichen für komplexe Agentensysteme häufig nicht aus.
Du willst nicht nur wissen:
request failed
Du willst wissen:
run_id
graph_version
node_id
parent_node
attempt
model
model_version
input_artifact_ids
output_artifact_ids
tool_calls
route_decision
latency
tokens
cost
validation_result
failure_type
retry_count
Ein Trace könnte beispielsweise so aussehen:
RUN 8f91
│
├── scope 1.2s
│
├── planner 4.8s
│
├── research.company 8.1s
├── research.papers 12.4s
├── research.experts 9.7s
│
├── deduplicate 0.3s
│
├── evidence.verify 6.1s
│
├── draft 7.8s
│
├── citation.verify 4.2s
│
└── publish_gate WAITING
Damit kannst du Fragen beantworten wie:
Observability wird dadurch nicht nur zum Debugging-Tool.
Sie wird zu einem Feedback-System für die Architektur.
⸻
Ein einzelner Accuracy Score reicht nicht.
Angenommen, zwei Runs produzieren beide korrekte Ergebnisse.
Run A:
12 Nodes, 31 Tool Calls, 4 Retries, 1,84 €, 48 Sekunden
Run B:
7 Nodes, 13 Tool Calls, 0 Retries, 0,41 €, 19 Sekunden
Beide sind korrekt.
Aber Run B ist offensichtlich das bessere System.
Eine vernünftige Evaluation muss deshalb mehrere Dimensionen berücksichtigen.
Quality: Accuracy, Completeness, Groundedness Efficiency: Latency, Tokens, Tool Calls, Cost Reliability: Failure Rate, Retry Rate, Recovery Success Routing: Correct Route Selection, Unnecessary Branches, Escalation Rate Safety: Policy Violations, Unauthorized Actions, Human-Gate Bypasses
Ein Graph sollte deshalb sowohl auf Node-Level als auch End-to-End evaluiert werden.
Das System ist die eigentliche Einheit.
⸻
Der Graph bestimmt, wo das System warten muss.
Bei einer sequenziellen Pipeline:
T = T1 + T2 + T3 + T4
Bei unabhängigen parallelen Branches:
T ≈ max(T1, T2, T3) + Tjoin
Bei Routing:
T = Tclassifier + Tselected_path
Bei Retries:
T = Σ attempt_i + backoff
Damit wird die Topologie selbst zu einem Performance Model.
Du kannst den Critical Path identifizieren.
Beispiel:
A ──────┐
├── C ── D
B ──┐ │
└───┘
Wenn:
A = 4s, B = 20s, C = 3s, D = 5s
dann dominiert B den Critical Path.
A von 4 auf 2 Sekunden zu optimieren bringt kaum etwas.
B von 20 auf 10 Sekunden zu reduzieren dagegen schon.
Das ist klassische Critical-Path-Analyse – nur angewendet auf LLM- und Agent-Systeme.
⸻
Ein Graph ist nicht automatisch günstiger als ein einzelner Agent.
Er kann sogar massiv teurer sein.
Anthropic beschreibt beispielsweise, dass Multi-Agent Research bei geeigneten, stark parallelisierbaren Aufgaben deutliche Vorteile bieten kann, gleichzeitig aber wesentlich mehr Tokens verbraucht als gewöhnliche Interaktionen.
Deshalb lautet die Frage nicht:
"Wie viele Agents kann ich einsetzen?"
Sondern:
"Wo erzeugt zusätzliche Koordination genügend Wert, um ihre Kosten zu rechtfertigen?"
Eine einfache Anfrage könnte durch:
User → kleines Modell → Validation → DONE
laufen.
Eine komplexe Untersuchung dagegen:
User → Planner → Parallel Specialists → Evidence Aggregation → Independent Verification → Strong Synthesizer → Human Gate
Der zweite Graph kostet mehr.
Er muss deshalb auch deutlich mehr Wert erzeugen.
⸻
Nicht jeder Node benötigt dasselbe Modell.
Ein heterogener Graph kann Modelle nach Aufgabe auswählen:
Extraction → günstiges Modell
Classification → günstiges Modell
Normalization → deterministischer Code
Planning → starkes Reasoning-Modell
Synthesis → starkes Modell
Verification → unabhängiges starkes Modell
Formatting → günstiges Modell / Code
Damit wird das Modell selbst zu einer Node-Level-Implementierungsentscheidung.
Das ermöglicht außerdem kontrollierte Upgrades.
Zum Beispiel:
verification-model-v1 kann gegen verification-model-v2
ausgetauscht werden, ohne den restlichen Graphen zu verändern.
⸻
Ein häufiger Denkfehler lautet:
Mehr Agents = mehr Intelligenz
Das stimmt nicht.
Agents sind besonders sinnvoll, wenn das Problem:
Sie sind weniger sinnvoll, wenn:
Die entscheidende Frage lautet deshalb nicht:
"Wie viele Agents brauche ich?"
Sondern:
"Wo erzeugt unabhängige Berechnung messbaren zusätzlichen Wert?"
⸻
Statische Parallelisierung:
-> Research
Input ->
\
-> Pricing
Die Aufgaben sind vorher bekannt.
Orchestrator-Worker:
-> Worker 1
/
Planner ->
\
-> Worker 2
\
-> Worker 3
Der Planner entscheidet dynamisch, welche Aufgaben entstehen.
Das ist sinnvoll, wenn die Struktur des Problems von Input zu Input unterschiedlich ist.
Anthropic unterscheidet genau zwischen festen parallelen Workflows und dynamischem Orchestrator-Worker-Design.
⸻
Betrachte:
Agent A → Agent B
Das kann bedeuten:
Agent A übergibt die Kontrolle an Agent B.
Das ist ein Handoff.
Eine andere Architektur ist:
A → Artifact
B → Artifact
C → Artifact
Hier arbeiten mehrere Agents auf einem gemeinsamen Zustand.
Das sind unterschiedliche Koordinationsmodelle.
Handoffs eignen sich, wenn ein Spezialist die Kontrolle übernehmen soll.
Shared-State-Graphs eignen sich, wenn mehrere Worker zu einem gemeinsamen Ergebnis beitragen.
Delegation ist nicht dasselbe wie Dataflow.
⸻
Sobald ein Graph Produktionsinfrastruktur ist, wird eine Änderung seiner Topologie zu einem Deployment-Thema.
Version 1: A → B → C
Version 2: A → B → D → C
Was passiert mit einem Run, der unter Version 1 gestartet wurde und nach einem Crash wiederaufgenommen wird?
Idealerweise:
Er läuft unter der Version weiter, unter der er gestartet wurde.
Deshalb sollte ein Run mindestens kennen:
Andernfalls kann ein langlebiger Job unter einer Architektur beginnen und unter einer anderen fortgesetzt werden.
Das kann extrem schwer zu debug sein sein.
Ein Graph ist deshalb letztlich ein versioniertes Software-Artefakt.
Behandle ihn auch so.
⸻
Ein Retry ohne Idempotency kann ein zuverlässiges System sogar unzuverlässiger machen.
Angenommen:
CREATE_PAYMENT
wird erfolgreich ausgeführt.
Der Worker crasht.
Die Runtime weiß nicht, ob die Operation erfolgreich war.
Sie führt sie erneut aus.
Jetzt hast du:
CREATE_PAYMENT
CREATE_PAYMENT
Dasselbe Problem existiert bei:
Eine sehr robuste Struktur ist deshalb:
PLAN → VALIDATE → APPROVE → COMMIT
Nur der finale Commit Node darf die irreversible Side Effect Operation ausführen.
Das macht den gesamten Graphen wesentlich einfacher zu kontrollieren.
⸻
Für High-Impact Agents ist folgende Architektur besonders interessant:
INTENT → PLAN → VALIDATE PLAN → EXECUTE → VERIFY RESULT
Statt:
LLM → mach einfach, was sinnvoll erscheint
erzeugt das Modell zunächst einen strukturierten Plan:
{
"actions": [
{
"tool": "update_database",
"target": "customer_183",
"operation": "update_status",
"new_value": "approved"
}
]
}
Der Graph kann anschließend prüfen:
Erst dann: EXECUTE
Das führt zu einer wichtigen Trennung:
Das Modell schlägt vor.
Die Runtime autorisiert.
Das Tool führt aus.
Der Verifier kontrolliert das Ergebnis.
⸻
Nehmen wir eine einfache Aufgabe:
"Schreibe einen tief recherchierten Artikel über ein technisches Thema und belege die wichtigen Aussagen mit zuverlässigen Quellen."
Eine naive Architektur:
USER → ONE AGENT → ARTICLE
Eine produktionsorientierte Architektur könnte dagegen so aussehen:
┌─ PRIMARY SOURCES ───────┐
│ │
TOPIC → SCOPE → DECOMPOSE ──┼─ PAPERS ────────────────┤
│ ├─> NORMALIZE
├── TECHNICAL DOCS ────────┤
│ │
└─ EXPERT ANALYSIS ───────┘
│
v
DEDUPLICATE
│
v
CLUSTER
│
v
EVIDENCE VERIFY
│
┌────────────┴────────────┐
│ │
PASS FAIL
│ │
v v
OUTLINE REPAIR
│ │
v └─> VERIFY
CLAIM EXTRACTION
│
v
CITATION VERIFICATION
│
┌──────┴──────┐
│ │
PASS FAIL
│ │
v └─> VERIFY
HUMAN REVIEW
│
v
PUBLISH
Jeder Teil hat eine klare Verantwortung.
Das ist nicht:
"Ein Agent schreibt einen Artikel."
Es ist:
Ein Research-and-Publishing-System.
Und genau diese Unterscheidung ist der Kern von Graph Engineering.
⸻
Messages sind flüchtig.
Artifacts sind dauerhaft.
Ein guter Graph erzeugt beispielsweise:
scope.json
research/
source-001.json
source-002.json
source-003.json
evidence.json
outline.json
draft.md
claims.json
citation-report.json
final.md
Jedes Artefakt kann Metadaten besitzen:
Damit entsteht Provenance.
Du kannst später beantworten:
Das ist der Unterschied zwischen einem Chat-Transcript und einem auditierbaren AI-System.
⸻
An diesem Punkt passiert etwas Interessantes.
Der Execution Graph und der Data-Lineage-Graph beginnen sich zu überschneiden.
Zum Beispiel:
User Request → Research Task
|
+----> Source A
| |
| v
| Evidence 1
|
+----> Source B
| |
| v
| Evidence 2
|
v
Claim → Draft Paragraph → Verified Article
Der Graph enthält jetzt nicht nur:
Was wurde wann ausgeführt?
sondern auch:
Woher kommt dieses Ergebnis?
Damit werden möglich:
Wenn Source B später ungültig wird, kannst du nachvollziehen, welche Claims davon abhängen.
Du musst nicht zwangsläufig den gesamten Workflow neu ausführen.
⸻
Angenommen:
Research → Evidence → Draft → Citation Check → Publish
Eine Quelle verändert sich.
Ein naives System startet alles neu.
Ein Graph mit Dependency Tracking kann stattdessen erkennen:
Source B → Evidence 7 → Claim 12 → Paragraph 4
Nur dieser Teil muss invalidiert und neu berechnet werden.
Das ist incremental computation für agentische Systeme.
Statt:
Change → rerun everything
bekommst du:
Change → invalidate affected nodes → recompute dependency subtree → reuse everything else
Das ist eine der interessantesten langfristigen Konsequenzen von explizitem Graph Engineering.
Der Graph wird zum Dependency Model für die Berechnung selbst.
⸻
Nicht jeder Workflow muss so aussehen:
Fan-out → wait for everything → Fan-in
Manchmal ist Streaming sinnvoller:
Source A ──┐
Source B ──┼──> Incremental Aggregator
Source C ──┘ |
v
Partial Draft
Sobald neue Evidenz eintrifft, kann die Downstream-Verarbeitung beginnen.
Das reduziert Time-to-First-Result.
Aber Streaming bringt zusätzliche Komplexität:
Deshalb gilt erneut:
Wähle Streaming, weil das Produkt es benötigt – nicht weil es technisch beeindruckend aussieht.
⸻
Viele AI-Architekturdiagramme zeigen immer komplexere Graphen, als wäre Komplexität automatisch Fortschritt.
Das ist sie nicht.
Jeder zusätzliche Node erzeugt:
Ein Graph mit 30 Nodes ist nicht automatisch besser als einer mit 5.
Das eigentliche Optimierungsziel lautet:
Die kleinste Topologie,
die die erforderliche
Qualität,
Reliability,
Latency,
Cost
und Safety
garantiert.
Deshalb ist eine der wichtigsten Regeln:
Wenn du keinen klaren Grund für einen Node nennen kannst, lösche ihn.
⸻
Nicht jeder Prompt braucht eine Orchestrierungsplattform.
Ein einzelner Agent Loop kann völlig ausreichend sein, wenn:
Ein Graph wird interessant, wenn:
Die Architektur sollte dem Problem folgen.
Nicht dem Hype.
⸻
Hier liegt die größere Entwicklung.
Prompt Engineering: Wie bringe ich das Modell dazu, bessere Antworten zu produzieren? Context Engineering: Welche Informationen muss das Modell sehen? Harness Engineering: Welche Tools, Umgebung, Memory und Constraints umgeben das Modell? Loop Engineering: Wie kann eine Einheit von Arbeit durch Feedback besser werden? Graph Engineering: Wie koordiniere ich das gesamte System?
Die Entwicklung sieht damit ungefähr so aus:
PROMPT → CONTEXT → HARNESS → LOOP → GRAPH → SYSTEM
Keine dieser Ebenen ersetzt die anderen.
Ein perfekter Graph mit schlechten Prompts produziert weiterhin schlechte Ergebnisse.
Ein perfekter Prompt in einem schlechten Graphen produziert weiterhin ein unzuverlässiges System.
Das Modell ist eine Komponente.
Die Runtime ist das Produkt.
⸻
Das ist möglicherweise die wichtigste konzeptionelle Veränderung.
Ein Agent sollte nicht ausschließlich als:
"Eine KI, die Dinge erledigt"
verstanden werden.
Für Produktionsarchitekturen ist folgende Sichtweise häufig hilfreicher:
Ein Agent ist ein probabilistischer Worker innerhalb eines überwiegend deterministischen Distributed Systems.
Das deterministische System kontrolliert:
Das Modell liefert:
Das ist eine extrem leistungsfähige Trennung.
Das Modell macht, worin Modelle stark sind.
Software macht, worin Software stark ist.
⸻
Topologie
Nodes
State
Reliability
Verification
Security
Economics
Observability
Simplicity
Wenn nicht: Lösche Nodes.
⸻
Die nächste Generation von AI Engineering wird nicht nur durch bessere Modelle definiert.
Sie wird durch bessere Systeme um diese Modelle herum definiert.
Die interessante Engineering-Frage lautet nicht mehr:
"Wie bringe ich ein LLM dazu, diese Aufgabe zu erledigen?"
Sondern:
"Wie baue ich ein System, in dem Intelligenz parallelisiert, verifiziert, begrenzt, fortgesetzt, beobachtet und skaliert werden kann?"
Dafür muss man in Graphen denken.
Nicht weil jede Anwendung ein Graph-Framework benötigt.
Sondern weil jede ausreichend komplexe agentische Anwendung bereits einen Graphen besitzt.
Die einzige Frage ist:
Hast du ihn bewusst entworfen?
Ein versteckter Graph existiert trotzdem.
Seine Branches befinden sich in Prompts.
Sein State steckt in Conversation Transcripts.
Seine Retries verstecken sich in Exception Handlern.
Seine Routing steckt in Modellentscheidungen.
Seine Dependencies leben in undokumentierten Annahmen.
Seine Fehler erscheinen erst in Produktion.
Graph Engineering macht diese unsichtbare Architektur explizit.
Und sobald die Architektur explizit ist, kannst du sie:
Und vor allem:
Du kannst Fehler lokal behandeln, ohne dass das gesamte System zusammenbricht.
Das Modell ist nicht das System.
Der Graph ist das System um das Modell herum.
Das ist der eigentliche Wandel:
Von AI-Demos zu AI Systems Engineering.
⸻
⸻
Für kürzere Notes, neue Tools und AI-Systeme, die ich teste:
Für tiefere technische Analysen:
Wenn du bis hier gelesen hast:
Bookmark den Artikel.
Und wenn du das nächste Mal einen Agenten baust, fang nicht mit dem Prompt an.
Fang mit dem Graphen an.