Der iterative Erstellungszyklus: So bauen Sie besser mit Plan Mode, Multi‑Agent‑Dialogen und Verifikation

Ein praktischer Praxisleitfaden für 2026 zu den Themen Programmierung, Recherche, Content, Produkte, Wissenssysteme und KI-native Workflows

Es gibt einen Punkt, an dem das Hinzufügen weiterer Intelligenz zu einem KI-Workflow nicht mehr weiterhilft.

Nicht, weil das Modell schwach ist.

Sondern weil der Workflow schwach ist.

Man kann einem Agenten ein riesiges Kontextfenster, ein Dutzend Tools, eine lange Anweisung und einen sorgfältig optimierten Prompt geben. Dennoch kann er das Ziel missverstehen, einer Annahme zu blind vertrauen, Recherchen duplizieren, etwas verändern, das unangetastet bleiben sollte, oder den Erfolg verkünden, bevor überhaupt jemand das Ergebnis überprüft hat.

Die instinktive Antwort lautet oft:

Füge einen weiteren Agenten hinzu.

Dann noch einen.

Dann einen Prüfer.

Dann einen „Senior Architect“.

Dann einen finalen Redakteur.

Am Ende hat man ein winziges künstliches Unternehmen aufgebaut, das mehr Zeit mit Koordinieren als mit der eigentlichen Arbeit verbringt.

Das ist nicht das Ziel.

Der nützlichere Gedanke ist einfacher:

Optimiere nicht für die Anzahl der Agenten. Optimiere für die Qualität der Zustandsübergänge zwischen Intention, Evidenz, Aktion und verifizierter Fertigstellung.

Dieser Leitfaden nennt dieses System den Iterative Creation Loop.

OBSERVE → CONTRACT → PLAN → CHALLENGE → SPECIALIZE
        → REFINE → APPROVE → EXECUTE → VERIFY → LEARN ↺

Die Agenten sind optional.

Die Schleife nicht.

Für manche Aufgaben sollte ein starker Agent den größten Teil der Schleife durchlaufen. Für andere verdienen unabhängige Forscher, Kritiker, Spezialisten und Prüfer ihre eigenen Kontexte. Die Architektur sollte der Form der Arbeit folgen.

Das Ergebnis ist kein „Schwarm“. Es ist etwas Nützlicherem: ein wiederholbarer Prozess, um unsichere Arbeit in überprüfte Arbeit zu verwandeln.

---

TL;DR

Der nützliche Wandel geht von der Antwortgenerierung zur Artefakt-Progression.

Anstatt:

Human → Prompt → Model → Answer

verwende:

Goal Contract
     ↓
Observe real evidence
     ↓
Create a falsifiable plan
     ↓
Attack the plan
     ↓
Delegate only real uncertainties
     ↓
Execute in checkpoints
     ↓
Verify independently
     ↓
Record what was learned

Einige aktuelle Erkenntnisse erklären, warum es sich lohnt, dies ernst zu nehmen, ohne den Artikel in Hype umschlagen zu lassen.

Primärquellen: Anthropic, PACT, MAST, Rethinking Multi-Agent Collaboration.

Praktische Regel: Beginne mit einem Agenten, finde den Flaschenhals, füge die geringste Menge an Koordination hinzu, die ihn beseitigt, und messe, ob sich die zusätzliche Komplexität bezahlt macht.

---

Inhaltsverzeichnis

1. 01.Die Kernidee: Eine Schleife bauen, keinen Rat
2. 02.Wenn Multi‑Agenten tatsächlich helfen — und wann sie die Situation verschlimmern
3. 03.Planmodus: Die Grenze zwischen Denken und dem Verändern der Welt
4. 04.Die artefakt‑first-Architektur
5. 05.Rollen und Topologien: Struktur aus der Aufgabe wählen
6. 06.Das Dialogprotokoll: Aktion, Zustand, Ergebnis
7. 07.Die vollständige iterative Erstellungs‑Schleife
8. 08.Wie man die Schleife heute ausführt: Cursor, Claude Code, SDKs und benutzerdefinierte Harnesses
9. 09.Was die Beweise aus 2025–2026 tatsächlich aussagen
10. 10.Vier praktische Playbooks: Software, Forschung, Inhalte und Produkte
11. 11.Verifikation und Messung: „Fertig“ beobachtbar machen
12. 12.Fehlermodi: Wie gut aussehende Agentensysteme scheitern
13. 13.SEO, GEO und KI‑lesbare Veröffentlichung ohne die Folklore
14. 14.Das wiederverwendbare Betriebskit

---

1. Die Kernidee: Eine Schleife bauen, keinen Rat

Der Ausdruck „Multi‑Agent‑System“ lässt die Agenten wie das Hauptelement erscheinen.

Das sind sie nicht.

Das Hauptelement ist der Workflow‑Zustand.

Ein Fach‑Agent ist einfach eine temporäre Kontextgrenze. Ein Kritiker ist eine Rolle mit einem antagonistischen Ziel. Ein Verifizierer ist ein Tor, das Evidenz verlangt. Ein Manager ist ein Routing‑Mechanismus.

Was von einer Phase zur nächsten überlebt, sollte der Zustand der Arbeit sein.

INTENTION
   ↓
OBSERVED STATE
   ↓
HYPOTHESIS / PLAN
   ↓
CHALLENGE
   ↓
ACTION
   ↓
NEW OBSERVATION
   ↓
VERIFICATION
   ↓
LEARNING

Dieses Muster ist nicht neu. In der Softwareentwicklung gibt es Tests und Code‑Reviews. Die Wissenschaft arbeitet mit Hypothesen und Experimenten. Der Betrieb nutzt Incident‑Response und Post‑Mortems. Produktteams prototypisieren, beobachten und iterieren.

Agentische Systeme machen einen Teil der Schleife dramatisch günstiger: Man kann mehr Untersuchung, Kritik, Synthese und Verifikation durchführen, ohne dass ein Mensch jeden Zwischenschritt ausführt.

Das eigentliche Problem verschiebt sich daher von „Kann ein Modell etwas Beeindruckendes erzeugen?“ zu:

Kann das System den richtigen Zustand bewahren, während es von unsicherer Absicht zu überprüftem Ergebnis übergeht?

1.1 Antwortgenerierung vs Artefakt‑Fortschritt

Eine Chat‑Antwort ist ein Endobjekt. Ein Artefakt kann inspiziert, geändert, versioniert, getestet und wiederverwendet werden.

Vergleiche:

Question → Answer

mit:

Goal Contract
→ Plan
→ Evidence Ledger
→ Decision Log
→ Implementation / Draft
→ Verification Report

Die zweite Pipeline erzeugt Objekte, mit denen zukünftige Agenten und Menschen arbeiten können.

Das ist die entscheidende Design‑Verschiebung.

1.2 Die drei Fragen, die jede Phase beantworten muss

Zu jedem Zeitpunkt in der Schleife sollte der nächste Teilnehmer in der Lage sein, zu beantworten:

1. 15.Was wollen wir erreichen?
2. 16.Was wissen wir derzeit?
3. 17.Was ist die nächste gerechtfertigte Aktion?

Die meisten schlechten Agent‑Workflows scheitern, weil eine dieser Fragen implizit wird.

Das Ziel geht in einem langen Kontext verloren.

Die Evidenz vermischt sich mit Spekulation.

Die nächste Aktion wird gewählt, weil das vorherige Modell zuversichtlich klang.

Die Schleife dient dazu, diese drei Fragen explizit zu halten.

1.3 Warum „mehr Agenten“ das falsche Ziel ist

Angenommen, ein Agent kann eine Aufgabe in acht Werkzeugaufrufen lösen.

Sie erstellen vier Agenten:

Planner
Researcher
Critic
Verifier

Jetzt haben Sie:

- fünf Kontexte statt einem,

- mehr Routing,

- mehr Zustandsübertragung,

- mehr Tokens,

- mehr Latenz,

- mehr Möglichkeiten für Widersprüche.

Sofern diese zusätzlichen Kontexte nichts Reales einbringen — unabhängige Evidenz, parallele Arbeit, spezialisierte Werkzeuge, bessere Verifikation oder nützliche Isolation — erhöhen Sie die Komplexität, ohne die Leistungsfähigkeit zu steigern.

Deshalb sollte die Architektur nachfragegesteuert sein.

2. Wenn Multi‑Agenten tatsächlich helfen — und wann sie die Situation verschlimmern

Die Frage ist nicht, ob Multi‑Agent‑Systeme leistungsfähig sind.

Das sind sie.

Die Frage ist, woher die Leistung kommt.

Ein nützliches Modell ist:

Multi-agent benefit
≈
parallelism
+ context isolation
+ specialization
+ independent criticism
+ additional tool capacity
− coordination cost
− token cost
− latency
− new failure modes

Es gibt keine universelle numerische Formel. Der Punkt ist architektonischer Natur: Jedes zusätzliche Agentenmodell bringt Kosten mit sich, für die es einen triftigen Grund geben sollte.

2.1 Der Aufgaben-Topologietest

Bevor Sie ein Team erstellen, klassifizieren Sie die Aufgabe.

Das Papier Rethinking Multi-Agent Collaboration: When More Is Less vom September 2026 unterscheidet dies formal genauso: Die Vorteile sind bei langfristigen Aufgaben mit wenigen Abhängigkeiten am größten, während eng gekoppelte sequentielle Workflows Einzelagentensysteme begünstigen können, da der Koordinationsaufwand dominant wird.

Quelle: Rethinking Multi-Agent Collaboration: When More Is Less.

2.2 Geringe vs. starke Abhängigkeit

Diese Unterscheidung ist einer der schnellsten Wege, um eine Entscheidung zu treffen.

Geringe Abhängigkeit

A ───┐
B ───┼──→ synthesis
C ───┤
D ───┘

A, B, C und D können unabhängig voneinander arbeiten.

Ein Multi-Agenten-Ansatz ist attraktiv.

Starke Abhängigkeit

A → B → C → D
    ↑   ↓
    └───┘

Jede Stufe hängt von Details der vorherigen ab.

Ein einzelner Agent oder ein deterministischer Workflow ist möglicherweise einfacher zu verwalten.

2.3 Der Unabhängigkeitstest

Bevor Sie einen Spezialisten starten, fragen Sie:

Könnte diese Person zehn Minuten lang unabhängig arbeiten und etwas abliefern, das eine andere Person tatsächlich verwenden kann?

Wenn die Antwort nein lautet, handelt es sich wahrscheinlich nicht um eine gute parallele Unteraufgabe.

2.4 Der Kontextextest

Fragen Sie:

Benötigt der Spezialist das gesamte Gespräch?

Wenn nicht, isolieren Sie es.

Ein Performance-Forscher benötigt wahrscheinlich nicht das gesamte Produktbriefing.

Ein Faktenprüfer benötigt wahrscheinlich nicht das gesamte Brainstorming-Transkript.

Ein Sicherheitsspezialist benötigt möglicherweise die Architektur und die geänderten Dateien, aber nicht die Marketingdiskussion.

Kontextisolierung ist nicht nur eine Kostenoptimierung. Sie ist oft eine Qualitätsoptimierung.

2.5 Die Regel „Keine Agenten erstellen“

Erstellen Sie keinen zusätzlichen Agenten, wenn:

- the task is simple,
- there is no meaningful parallelism,
- all stages need the same context,
- deterministic tools already solve the verification problem,
- or the expected benefit is purely stylistic.

Ein guter Orchestrator kann sagen:

No specialist required.
Proceed with single-agent execution.

Das ist ausgereifte Orchestrierung.

---

3. Plan-Modus: Die Grenze zwischen Nachdenken und der Veränderung der Welt

Der Plan-Modus ist aus einem trügerisch einfachen Grund nützlich: Er macht den Plan sichtbar, bevor die Implementierung zu teuer wird, um sie rückgängig zu machen.

Cursor beschreibt den Plan-Modus als einen Ablauf, bei dem der Agent die Codebasis durchsucht, Fragen stellt, einen detaillierten Plan erstellt, diesen von Ihnen überprüfen oder bearbeiten lässt und dann auf Basis dieses Plans baut. Pläne können im Workspace gespeichert werden. Die CLI von Cursor stellt den Plan-Modus auch über Befehle wie /plan und --mode=plan bereit.

Claude Code unterstützt gleichermaßen einen Berechtigungsmodus für Pläne sowie Subagenten und Agenten-Teams für komplexere Arbeitsabläufe.

Quellen:

- Cursor Plan Mode

- Cursor CLI

- Claude Code Permissions

- Claude Code Subagents

- Claude Code Agent Teams

3.1 Reversibles Schließen vs. irreversible Aktion

Ohne eine Planungsgrenze:

request
  ↓
agent edits
  ↓
discovers constraint
  ↓
edits again
  ↓
discovers dependency
  ↓
repairs previous edit
  ↓
human untangles diff

Mit einer solchen Grenze:

request
  ↓
inspect
  ↓
identify constraints
  ↓
compare approaches
  ↓
plan
  ↓
review
  ↓
execute

Das Modell wurde nicht intelligenter.

Der Arbeitsablauf wurde sicherer.

3.2 Der Zielvertrag

Vor dem Plan das Problem einfrieren.

goal: "Refactor the authorization layer without changing behavior"
constraints:
  - "preserve public API"
  - "preserve current authorization semantics"
  - "keep existing tests passing"
forbidden:
  - "framework migration"
  - "database schema change"
acceptance:
  - "all existing tests pass"
  - "new regression tests pass"
  - "duplicate authorization branches removed"
unknowns:
  - "legacy route behavior"

Der Vertrag sollte leicht zitierbar und schwer misszuverstehen sein.

3.3 Ein Plan sollte die Zukunft vorhersagen

Schwach:

Architektur und Zuverlässigkeit verbessern.

Falsifizierbar:

Ersetze die duplizierte Berechtigungsauflösung in den Modulen A und B durch den bestehenden kanonischen Resolver, bewahre die öffentlichen Signaturen, füge Regressionstests für Gast/Administrator-Grenzen hinzu und vergleiche anschließend den genehmigten Dateibereich mit dem endgültigen Diff.

Die zweite Version kann fehlschlagen.

Genau das macht sie nützlich.

3.4 Planungs-Antipatterns

Das Architektur‑Fan‑Fiction‑Problem

Der Agent geht davon aus, dass Abstraktionen existieren, weil sie sinnvoll wären.

Lösung:

Inspect first.
If a component is not found, mark it UNKNOWN.
Do not invent it.

Das „Alles‑ist‑im‑Umfang“-Problem

Der Benutzer fordert eine Refaktorierung. Der Agent gestaltet stillschweigend drei Systeme neu.

Lösung:

approved files
approved services
forbidden changes

Der Plan, der nicht getestet werden kann

Wenn Sie nicht erklären können, wie ein Schritt verifiziert wird, ist der Schritt nicht bereit.

---

4. Die artefakt‑erste Architektur

Die wichtigste Designentscheidung besteht darin, den geteilten Zustand sichtbar zu machen.

Entwerfen Sie nicht nach dem Prinzip „wer spricht mit wem“.

Entwerfen Sie nach welchen Artefakten durch das System fließen.

Ich empfehle fünf kanonische Artefakte:

1. Goal Contract
2. Plan
3. Evidence Ledger
4. Decision Log
5. Verification Report

4.1 Zielvertrag

Es ist die stabile Definition von Erfolg.

# Goal Contract

Goal:
Refactor the reporting module without changing public behavior.

Constraints:
- preserve API
- preserve error semantics
- preserve current output format

Forbidden:
- schema migration
- framework replacement
- unrelated cleanup

Definition of done:
- existing tests pass
- regression suite passes
- public API diff is zero
- performance remains within target

4.2 Plan

Der Plan ist eine Hypothese, kein Versprechen, dass die Realität ihm gehorchen wird.

Er sollte enthalten:

- beobachtete Orte,

- Abhängigkeiten,

- Annahmen,

- Sequenz,

- Risiken,

- Abnahmetests,

- Rollback-/Wiederherstellungspfad.

Wenn neue Evidenz den Plan ungültig macht, überarbeiten Sie den Plan, anstatt so zu tun, als würde der alte noch die Realität beschreiben.

4.3 Evidenzbuch

Dies ist das Artefakt, das verhindert, dass Wiederholung zur Wahrheit wird.

Beispiel:

claim: "OAI-SearchBot is relevant to OpenAI web search discovery"
source: "OpenAI Publishers and Developers FAQ"
source_type: "official-documentation"
state: "VERIFIED"
used_for: "AI crawler preflight"

Die Quelle kann die Behauptung unterstützen, ohne eine viel stärkere Behauptung wie „dies garantiert Zitation“ zu unterstützen.

Diese Unterscheidung ist der gesamte Zweck eines Evidenzbuchs.

4.4 Evidenzzustände

Verwenden Sie einen kleinen Wortschatz.

Ein nachgelagerter Agent sollte niemals in der Lage sein, UNKNOWN durch bloßes Wiederholen in VERIFIED zu verwandeln.

4.5 Entscheidungsprotokoll

Entscheidungen und abgelehnte Alternativen aufzeichnen.

Decision: Use manager + specialist-as-tool orchestration.

Rejected: unrestricted peer handoffs.

Reason: final synthesis needs one owner and specialists have bounded tasks.

Evidence: OpenAI Agents SDK manager-style orchestration guidance.

Entscheidungsprotokolle werden mit der Zeit wertvoller, da sie nicht nur die aktuelle Architektur erklären, sondern auch, warum sie existiert.

4.6 Verifikationsbericht

Der finale Bericht sollte sich wie ein Beweis lesen, nicht wie eine Feier.

Criterion 1 — PASS
Evidence: 128/128 tests passed.

Criterion 2 — PASS
Evidence: public API snapshot unchanged.

Criterion 3 — FAIL
Evidence: duplicate branch remains in module C.

Decision: NO-GO
Repair: remove duplication and rerun targeted suite.

Dieses Dokument ist für den nächsten Agenten, Reviewer oder Menschen wiederverwendbar.

---

5. Rollen und Topologien: Wählen Sie die Struktur anhand der Aufgabe

Rollen sind so lange nützlich, wie sie unterschiedliche Verantwortlichkeiten, Kontexte oder Befugnisse repräsentieren.

Das klassische Vier-Rollen-Modell ist ein guter Ausgangspunkt, kein Gesetz:

5.1 Sequenzielle Orchestrierung

Planner → Specialist → Executor → Verifier

Verwenden Sie dies, wenn jeder Schritt von der vorherigen Ausgabe abhängt.

5.2 Parallele Orchestrierung

┌→ Research A ─┐
Planner ┼→ Research B ─┼→ Synthesizer
        └→ Research C ─┘

Verwenden Sie dies, wenn die Zweige unabhängig voneinander sind.

5.3 Übergabe (Handoff)

Triage → specialist

Verwenden Sie dies, wenn ein Spezialist den aktiven Kontext oder die Benutzerinteraktion übernehmen soll.

5.4 Manager + Agenten als Tools

┌→ Specialist A
Manager ─────────┼→ Specialist B
                 └→ Specialist C
                     ↓
                 final synthesis

Verwenden Sie dies, wenn ein Agent die Verantwortung für die finale Antwort tragen und entscheiden soll, wann Spezialisten benötigt werden.

Das Agents SDK von OpenAI dokumentiert sowohl die Manager-orientierten „Agenten als Tools“- als auch die Übergabemuster (Handoff-Muster) explizit sowie eine code-gesteuerte Orchestrierung, bei der die Anwendung die Kontrolle über den Workflow besitzt.

Quelle: OpenAI Agents SDK — Agent orchestration.

5.5 Gruppenchat

A ↔ B ↔ C ↔ Manager

Ein Gruppenchat kann für echte Beratungen funktionieren, hat jedoch einen unschönen Fehlerzustand: alle reden weiter, weil sich niemand zuständig fühlt, das Ganze zu stoppen.

Verwenden Sie explizite Rundenlimits und einen Entscheidungsträger.

5.6 Dynamische / magnetische Orchestrierung

Das Agent Framework von Microsoft beschreibt die magnetische Orchestrierung als einen Manager, der spezialisierte Agenten dynamisch auf Basis des sich entwickelnden Aufgabenstatus koordiniert.

Das ist nützlich, wenn der Weg nicht im Voraus bekannt ist.

Es ist nicht automatisch besser als eine einfachere Pipeline.

Source: Microsoft — Magentic orchestration.

5.7 Die Entscheidungsmatrix für Topologien

---

6. Das Dialogprotokoll: Aktion, Status, Ergebnis

Ein Multi-Agenten-System kann selbst dann fehlschlagen, wenn jede einzelne Modellantwort gut aussieht.

Warum?

Weil Kommunikation selbst eine Systemressource ist.

Betrachten Sie Folgendes:

Agent A → 2,000-word explanation
Agent B reads it and writes 1,800 words
Agent C receives A+B and writes 1,500 words
Agent D receives everything and decides what matters

Ein Großteil dieses Textes ist eine Erklärung der Überlegungshistorie, nicht der Zustand, der für die Fortsetzung erforderlich ist.

Ein Papier vom Juni 2026 mit dem Titel What Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems stellt PACT vor — Protocolized Action-state Communication and Transmission (protokollierte Aktions-Zustands-Kommunikation und -Übertragung). Das Papier untersucht verschiedene Kommunikationsstrategien und argumentiert, dass nützliche Nachrichten zwischen Agenten einen handlungszentrierten Zustand bewahren sollten, anstatt blind formlose Ausgaben weiterzuleiten. Die Experimente berichten über ein wesentlich besseres Leistungs-Kosten-Verhältnis und einen reduzierten Token-Verbrauch in den getesteten Umgebungen. Das Papier betont zudem, dass keine einzelne feste Kommunikationsstrategie überall optimal ist.

Quelle: PACT.

Der Teil, den es sich zu kopieren lohnt, ist unkompliziert:

Übertragen Sie den für die Fortsetzung erforderlichen Zustand, nicht das Protokoll, das diesen erzeugt hat.

6.1 Die Action-State-Result-Nachricht

Ein praktischer Übergabedatensatz:

### Action-State Message

From: Critic
To: Planner

Action:
Reject plan step 3.2.

State:
The plan assumes generated routes are all crawlable. Repository inspection shows that one route family can produce orphaned URLs without canonical links.

Result:
Add a route-crawlability acceptance test and an explicit canonical URL requirement.

Evidence:
route manifest + crawler output + relevant source file.

Confidence:
High.

Next needed:
Revise step 3.2 before execution.

6.2 Warum „Result“ nützlich ist

„Action“ besagt, was passiert ist.

„State“ besagt, warum.

„Result“ besagt, welches Artefakt oder welche Entscheidung der Empfänger weiterführen soll.

Ohne „Result“ muss der nächste Agent die beabsichtigte Übergabe rekonstruieren.

6.3 Halten Sie Nachrichten empfängerorientiert

Ein Sender kümmert sich vielleicht um fünfzig Details.

Der Empfänger benötigt vielleicht fünf.

Eine gute Nachricht beantwortet:

What changed?
Why does it matter?
What should I use?
What remains unresolved?

6.4 Leiten Sie keinen privaten internen Monolog weiter

Strukturierte Koordination erfordert nicht die Weitergabe versteckter Begründungsspuren.

Übertragen Sie:

- Beobachtungen,

- Tool-Ausgaben,

- Schlussfolgerungen,

- Belege,

- Entscheidungen,

- ungelöste Fragen,

- nächste Aktionen.

Das reicht aus, um die Koordination sicherzustellen.

6.5 Eine kompakte JSON-Form

Wenn Sie maschinenlesbare Übergaben benötigen:

{
  "action": "reject_plan_step",
  "state": "route family can produce orphaned URLs",
  "result": "add crawlability + canonical acceptance test",
  "evidence": [
    "route-manifest.json",
    "crawler-output.json"
  ],
  "confidence": "high",
  "next_needed": "revise_plan"
}

Dies ist besonders nützlich, wenn der Orchestrator codebasiert ist.

---

7. Die vollständige iterative Erstellungsschleife

Die Schleife ist eine Abfolge von Kontrollpunkten und kein Ritual um ihrer selbst willen.

7.1 Schritt 0 — Den Vertrag einfrieren

Schreiben Sie:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

Tun Sie dies, bevor das Team kreativ wird.

7.2 Schritt 1 — Beobachten

Regel:

Keine Erfindung, wo eine Überprüfung möglich ist.

Überprüfen Sie für Software:

- Quellcode-Baumstruktur,

- relevante Dateien,

- Abhängigkeiten,

- Tests,

- Konfiguration,

- aktuelle Abstraktionen,

- kürzliche Änderungen.

Überprüfen Sie für Recherchen:

- Primärquellen,

- offizielle Dokumentation,

- aktuelles Produktverhalten,

- Forschungspapiere,

- widersprüchliche Beweise.

Überprüfen Sie für Inhalte:

- Suchintention,

- maßgebliche Referenzen,

- Terminologie,

- konkurrierende Interpretationen,

- Fragen der Zielgruppe.

Die Ausgabe sollte mit Beobachteten Fakten beginnen.

7.3 Schritt 2 — Planen

Der Planner liefert:

observed facts
assumptions
proposed sequence
dependencies
risks
acceptance tests
rollback path

Alles Unverifizierte bleibt entsprechend gekennzeichnet.

7.4 Schritt 3 — Hinterfragen

Der Critic erhält eine einzige Anweisung:

Gehen Sie davon aus, dass der Plan falsch ist. Finden Sie die geringste Anzahl an folgenreichen Gründen, warum er scheitern kann.

Priorisieren Sie:

goal violations
wrong assumptions
hidden dependencies
missing tests
security/reliability risks
scope creep
unnecessary complexity

Bitten Sie den Critic nicht, den Plan neu zu schreiben.

Bitten Sie ihn, den Plan zu zerlegen.

7.5 Schritt 4 — Spezialisieren

Setzen Sie Spezialisten nur für ungelöste Unklarheiten ein.

Beispiele:

Performance question
Security question
Framework compatibility question
Research evidence question
Accessibility question
Crawler behavior question

Die Aufgabe eines Spezialisten sollte so präzise sein, dass sie in einen einzigen Satz passt.

7.6 Schritt 5 — Meinungsverschiedenheiten klären

Nicht verwenden:

latest response wins

Verwenden Sie eine Evidenz-Prioritätsskala:

1. direct mechanical evidence
2. reproducible experiment
3. official / primary documentation
4. source-code inspection
5. peer-reviewed or clearly identified research
6. strong secondary analysis
7. expert judgment
8. model intuition

Dies ist eine praktische Heuristik, keine universelle wissenschaftliche Rangliste. Ihre Aufgabe besteht darin zu verhindern, dass rhetorische Zuversicht über Beweismaterial gestellt wird.

7.7 Schritt 6 — Den kanonischen Plan verfeinern

Fügen Sie kein weiteres Hin und Her an ein gigantisches Protokoll an.

Aktualisieren Sie den Plan.

Der Plan sollte der maßgebliche, aktuelle Zustand bleiben.

7.8 Schritt 7 — Einen Checkpoint genehmigen

Genehmigen Sie keine gesamte riskante Implementierung als einzelnes atomares Versprechen.

Genehmigen Sie eine kleine Einheit:

Checkpoint 1
→ execute
→ verify
→ update state

Checkpoint 2
→ execute
→ verify
→ update state

7.9 Schritt 8 — Ausführen

Die Ausführung sollte nun einen Vertrag, einen Geltungsbereich und Testbedingungen haben.

7.10 Schritt 9 — Verifizieren

Der Prüfer sollte Folgendes sehen:

- Zielvertrag (Goal Contract),

- Akzeptanzkriterien,

- resultierendes Artefakt,

- relevante rohe Beweise,

- deterministische Testergebnisse.

Ihm sollte das Ergebnis nicht im Voraus mitgeteilt werden.

7.11 Schritt 10 — Lernen

Aufzeichnen:

what failed
which assumption was wrong
which test caught it
which communication was wasteful
whether the specialist was necessary
whether the overall topology paid off

Dies wird zum zukünftigen organisatorischen Gedächtnis.

7.12 Das vollständige Zustandsdiagramm

┌──────────┐
│  OBSERVE │
└────┬─────┘
     ↓
┌──────────┐
│ CONTRACT │
└────┬─────┘
     ↓
┌──────────┐
│   PLAN   │
└────┬─────┘
     ↓
┌──────────┐
│ CHALLENGE│
└────┬─────┘
     ↓
┌──────────┐
│SPECIALIZE│  only where needed
└────┬─────┘
     ↓
┌──────────┐
│  REFINE  │
└────┬─────┘
     ↓
┌──────────┐
│ APPROVE  │
└────┬─────┘
     ↓
┌──────────┐
│ EXECUTE  │
└────┬─────┘
     ↓
┌──────────┐
│ VERIFY   │
└────┬─────┘
     ↓
┌──────────┐
│  LEARN   │
└────┬─────┘
     │
     └────────────→ OBSERVE

---

8. So führen Sie die Schleife heute aus: Cursor, Claude Code, SDKs und benutzerdefinierte Harnesses

Das Framework sollte nach dem Workflow kommen.

8.1 Cursor

Der Plan Mode von Cursor ist ein natürlicher Ausgangspunkt für die erste Hälfte der Schleife:

Plan Mode
→ inspect repository
→ ask questions
→ create/edit Markdown plan
→ review
→ build
→ review diff
→ run checks

Die Dokumentation von Cursor empfiehlt den Plan Mode ausdrücklich für komplexe Funktionen, dateiübergreifende Änderungen, unsichere Anforderungen und Architekturentscheidungen. Für kleine, vertraute Bearbeitungen besagt sie, dass stattdessen der Agent-Modus geeignet sein kann.

Nützliche Referenzen:

- Cursor Plan Mode

- Cursor Plan Mode help

- Cursor CLI

- Cursor quickstart

Praktisches Setup

1. Write Goal Contract.
2. Enter Plan Mode.
3. Ask for observed facts first.
4. Ask for plan + acceptance tests.
5. Run a fresh-context Critic pass.
6. Revise the plan.
7. Build one checkpoint.
8. Run deterministic checks.
9. Run verifier.

8.2 Claude Code

Claude Code unterstützt planorientierte Berechtigungssteuerung, Subagenten mit separaten Arbeitskontexten und Agententeams für eine unabhängigere Koordination.

Die nützliche Unterscheidung ist:

Subagent
= isolated worker for a bounded task

Agent team
= multiple independent sessions coordinating on a broader problem

Verwenden Sie Subagenten, wenn die Zwischenarbeit groß ist, aber nur das Ergebnis an den Hauptkontext zurückgegeben werden muss.

Verwenden Sie Teams, wenn unabhängige Arbeiter sich um eine gemeinsame Aufgabe herum koordinieren müssen.

Nützliche Referenzen:

- Claude Code Subagents

- Claude Code Agent Teams

- Claude Code Permissions

8.3 OpenAI Agents SDK

Die aktuellen SDK-Dokumentationen von OpenAI beschreiben zwei breite Orchestrierungsstrategien:

LLM-gesteuert: Das Modell entscheidet, welche Agenten/Tools aufgerufen werden.

Code-gesteuert: Die Anwendungslogik bestimmt den Ablauf.

Es wird zudem unterschieden zwischen:

Agenten als Tools: Der Manager behält die Kontrolle.

Übergaben (Handoffs): Der Spezialist übernimmt.

Dieselbe Dokumentation beschreibt Chaining, Evaluatorschleifen und parallele Agentenausführung als gängige code-gesteuerte Muster.

Das liefert Ihnen eine unkomplizierte Implementierung der iterativen Erstellungsschleife:

planner
→ critic
→ refiner
→ executor
→ evaluator
→ repair/replan

Referenzen:

- OpenAI Agents SDK

- Agent orchestration

- JavaScript multi-agent guide

8.4 LangChain und LangGraph

Die aktuelle Dokumentation von LangChain behandelt das Multi-Agenten-Design explizit als ein Problem des Kontext-Engineerings und dokumentiert Muster wie:

- Subagenten,

- Übergaben (Handoffs),

- Router,

- Fähigkeiten (Skills).

LangGraph bietet eine explizitere Graph-/Zustandskontrolle für Anwendungen, die persistente, inspizierbare Workflow-Übergänge erfordern.

Referenzen:

- LangChain multi-agent

- LangGraph

8.5 CrewAI

CrewAI ist ein auf Rollen und Aufgaben ausgerichteter Ansatz zum Prototyping von Crew-Workflows.

Die wichtige Frage ist nicht, ob das Framework Ihren Prozess als „Crew“ bezeichnet. Die wichtige Frage ist, ob Sie Folgendes abbilden können:

Goal
→ task decomposition
→ ownership
→ dependencies
→ outputs
→ verification

Referenz: CrewAI documentation.

8.6 Microsoft Agent Framework

Die aktuelle Dokumentation zum Microsoft Agent Framework stellt mehrere Orchestrierungsmuster vor:

Sequential
Concurrent
Handoff
Group Chat
Magentic

Es unterstützt zudem Workflow-Interaktionen mit menschlicher Beteiligung (Human-in-the-Loop).

Dieses Vokabular ist selbst dann nützlich, wenn Sie das Framework nie verwenden, da es Ihnen Namen für verschiedene Koordinationsstrukturen an die Hand gibt.

Referenzen:

- Workflow orchestrations

- Magentic orchestration

- AI agent orchestration patterns

8.7 Framework-Auswahlübersicht

Dies ist kein Ranking. Es ist eine Eignungsmatrix.

---

9. Was uns die Evidenz für 2025–2026 tatsächlich sagt

Das Feld der Multi-Agenten-Systeme hat genügend Erkenntnisse angesammelt, dass „mehr Agenten = intelligenter“ kein ernsthaftes Designprinzip mehr ist.

Die interessante Frage lautet, woher die Leistungssteigerungen kommen und wo sie verschwinden.

9.1 Anthropic: Mehr Rechenleistung kann mehr Forschungskapazität kaufen

Der Technikbericht von Anthropic zu seinem Multi-Agenten-Forschungssystem (Research system) ist eines der klarsten öffentlich zugänglichen Beispiele.

Die Architektur verwendet einen führenden Agenten, um die Forschung zu planen, und delegiert Richtungen an Subagenten, die parallel dazu Untersuchungen durchführen.

Anthropic berichtet über:

- eine Verbesserung um 90,2 % im Vergleich zur Single-Agent-Baseline bei der internen BrowseComp-Evaluierung,

- etwa das 15-Fache des Token-Verbrauchs eines gewöhnlichen Chats,

- erhebliche Leistungssteigerungen durch Parallelisierung und zusätzliche Kontextkapazität,

- schlechte Eignung für einige eng gekoppelte Aufgaben, bei denen Agenten einen großen gemeinsamen Kontext benötigen.

Die richtige Lektion lautet nicht: „Verwenden Sie viele Agenten.“

Sie lautet vielmehr:

Wenn eine Aufgabe einen hohen Wert hat, viele parallelisierbare Informationen zusammengetragen werden müssen und ein Engpass in einem einzelnen Kontext vorliegt, kann die Multi-Agenten-Ausführung nützliche zusätzliche Argumentationskapazität (Reasoning-Kapazität) einbringen.

Quelle: Anthropic — How we built our multi-agent Research system.

9.2 PACT: Kommunikation ist eine Optimierungsfläche

PACT stellt eine engere Frage:

Was sollten Agenten eigentlich zueinander sagen?

Die Antwort lautet nicht: „Senden Sie alles.“

Das Paper evaluiert mehrere Strategien und schlägt Action-State-Kommunikation als Methode vor, um entscheidungswirksame Informationen zu bewahren und gleichzeitig unnötigen Kontexttransfer zu reduzieren. Es berichtet in seinen Experimenten von erheblichen Token-Einsparungen, einschließlich Verbesserungen bei evaluierten Coding-Harnesses.

Der am besten übertragbare Gedanke ist:

public state update
> conversation transcript

Quelle: PACT.

9.3 MAST: Koordination erzeugt Fehlermodi

Das Papier Why Do Multi-Agent LLM Systems Fail? analysierte mehr als 150 Traces im Detail, um eine Taxonomie von 14 Fehlermodi zu erstellen, gruppiert in:

1. 18.Spezifikation und Systemdesign,
2. 19.Fehlende Ausrichtung zwischen Agenten,
3. 20.Aufgaben‑Verifikation und -Beendigung.

Das Projekt stellte später einen größeren annotierten Trace‑Datensatz für breitere Evaluationen bereit.

Der wichtige Punkt ist architektonisch:

Ein Multi‑Agenten‑System ist ein neues System. Es benötigt seine eigene Zuverlässigkeitstechnik.

Source: MAST.

9.4 MultiAgentBench: Koordination selbst kann gemessen werden

Die ACL‑2025‑MultiAgentBench‑Arbeit bewertet nicht nur die Aufgabenerfüllung, sondern auch das Koordinationsverhalten. Sie untersucht Stern‑, Ketten‑, Baum‑ und Graph‑Koordinationsprotokolle und verwendet Meilenstein‑orientierte Metriken.

Das ist nützlich, weil reine End‑Genauigkeit das Systemverhalten verbirgt.

Ein Workflow kann die richtige Antwort aus den falschen Gründen erzeugen.

Er kann auch enorme Ressourcen aufwenden, um ein bescheidenes Ergebnis zu erzielen.

Source: MultiAgentBench.

9.5 September 2026: „wenn mehr weniger ist“ wird zur zentralen Frage

Die September‑2026‑Studie Rethinking Multi-Agent Collaboration: When More Is Less untersucht direkt das Skalieren von Agenten‑Pools und Rekursionstiefe.

Ihre Kernbotschaft ist, dass die Aufgabenstruktur die Fähigkeitsgrenze definiert. Mehr Agenten erzeugen nicht konsequent bessere Ergebnisse.

Das ist fast exakt der Grund, warum dieser Leitfaden es ablehnt, „vier Agenten“ oder „zehn Agenten“ zu einer universellen Rezeptur zu machen.

Source: Rethinking Multi-Agent Collaboration.

9.6 Das Evidenzmuster

Aus diesen Quellen entsteht ein kohärentes Ingenieur‑Bild:

Multi-agent helps when:
+ work can be decomposed
+ branches are reasonably independent
+ contexts benefit from isolation
+ additional tool capacity matters
+ independent checking has real value

Multi-agent hurts when:
− dependencies are dense
− everyone needs the same context
− communication dominates work
− verification is weak
− agents duplicate each other
− the task is too small to justify the overhead

Das ist ein viel nützlicheres Fazit als „Multi‑Agent ist die Zukunft.“

---

10. Vier praktische Playbooks: Software, Forschung, Inhalte und Produkte

Die Schleife ist abstrakt. Diese Playbooks machen sie konkret.

10.1 Software: Refactoring ohne Verhaltensdrift

Ziel

Ein großes Reporting‑Modul aufteilen, ohne sein öffentliches Verhalten zu ändern.

Planer

Untersuchen:

- öffentliche Exporte,

- Aufrufer,

- gemeinsamer Zustand,

- Tests,

- leistungsrelevante Pfade,

- Konfiguration.

Ausgabe:

current boundaries
candidate extraction points
dependency order
regression tests
rollback path

Kritiker

Angriff:

hidden coupling
changed error behavior
circular dependencies
performance regressions
snapshot drift
unapproved files

Spezialist

Performance‑Spezialist erhält eine Frage:

Verursacht das Extrahieren des Formatierers, dass Arbeit auf einen Hot‑Path verschoben wird oder wird die Serialisierung dupliziert?

Ausführer

Ändert nur genehmigte Dateien.

Verifizierer

Bevorzuge deterministische Gates:

unit tests
integration tests
type checking
lint
build
API snapshot
benchmark
diff scope

Beispiel‑Verifizierungsprotokoll

PASS — 128/128 unit tests
PASS — 24/24 integration tests
PASS — 0 type errors
PASS — public API unchanged
PASS — benchmark within target
PASS — changed files within approved scope

Der LLM ist nicht der gesamte Verifizierer.

Er ist die Schicht, die Ergebnisse interpretiert, die deterministische Werkzeuge nicht vollständig interpretieren können.

10.2 Forschung: Erstelle eine Evidenzkarte anstelle eines Haufens von Zusammenfassungen

Frage:

Wie entdecken und nutzen aktuelle KI‑Suchsysteme Web‑Quellen?

Starte nicht sechs generische „Forscher“.

Teile die Unsicherheit auf:

Jeder Arbeiter liefert strukturierte Datensätze:

claim: "X"
source: "https://example.com/source"
source_type: "official-docs"
published: "2026-08-12"
evidence: "exact observation"
state: "SUPPORTED"
limitations:
  - "platform-specific"

Die wertvollste Forschungsrolle ist oft nicht ein weiterer Forscher.

Sie ist der Disconfirmation Researcher.

Gib einem Arbeiter diese Aufgabe:

Finde Belege, die die entstehende Schlussfolgerung widerlegen oder materiell schwächen würden.

Das reduziert Bestätigungskaskaden.

10.3 Content: epistemic Arbeit von Stil-Arbeit trennen

Ein starker technischer Artikel kann diese Pipeline nutzen:

Question map
    ↓
Evidence map
    ↓
Argument map
    ↓
Outline
    ↓
Draft
    ↓
Fact check
    ↓
Human-voice edit
    ↓
SEO/GEO preflight

Die schlechte Pipeline ist:

SEO agent
→ writer
→ humanizer
→ GEO agent
→ headline agent
→ final polish agent

Warum?

Weil jeder Agent die Oberflächenform optimiert. Niemand ist klar für die epistemische Wahrheit verantwortlich.

Content-Behauptungs-Labels (Content claim labels)

Ein nützliches internes Set von Labels:

FACT
REPORTED RESULT
OBSERVATION
INTERPRETATION
OPINION
PROPOSAL
UNKNOWN

Der veröffentlichte Artikel muss nicht jedes Label anzeigen. Der interne Workflow sollte sie kennen.

10.4 Produktentwicklung: Jeder Rolle ein anderes Fehlschlag-Ziel geben

Verwenden Sie vier Perspektiven:

Der User Advocate sollte eine konkrete Aufgabe erhalten:

Finden Sie jeden Punkt, an dem das Produkt den Nutzer auffordert, unsere interne Architektur zu verstehen, anstatt seine eigene Arbeit zu verstehen.

Das liefert deutlich praxisnahteres Feedback als „UX überprüfen“.

---

11. Verifizierung und Messung: „Fertigsein“ beobachtbar machen

Ein Workflow wird zu einem Engineering-System, wenn er erklären kann, warum er glaubt, dass er vollständig ist.

11.1 Verifizierungshierarchie

Nutzen Sie zuerst das günstigste verlässliche Gate.

LEVEL 1 — Mechanical
schema validation
unit tests
type checks
lint
HTTP checks
file existence

LEVEL 2 — Deterministic comparison
snapshots
diffs
benchmarks
invariants
regression datasets

LEVEL 3 — Model evaluation
semantic quality
classification
summarization fidelity
comparative judgment
style compliance

LEVEL 4 — Human review
high-stakes decisions
ambiguous interpretation
final publication
material production changes

Nutzen Sie kein Modell, um eine Frage zu beantworten, die ein Compiler beantworten kann.

11.2 Kriterium-für-Kriterium-Verifizierung

Schlecht:

Alles sieht gut aus.

Gut:

Criterion: Preserve public API
Status: PASS
Evidence: API snapshot diff = 0

Criterion: Remove duplication
Status: FAIL
Evidence: legacy branch remains in src/auth/legacy.ts

Criterion: Existing tests pass
Status: PASS
Evidence: 128/128

11.3 PASS / FAIL / UNKNOWN

UNKNOWN ist wichtig.

Ein Prüfer sollte sagen dürfen:

Ich konnte dieses Kriterium nicht feststellen.

Das ist besser als ein erfundenes PASS.

11.4 Frischer Kontext bedeutet nicht automatisch Unabhängigkeit

Ein frischer Prüfer kann dennoch voreingenommen sein, wenn man ihm die Schlussfolgerung des Erstellers füttert.

Vermeiden Sie:

The implementation succeeded. Please verify it.

Bevorzugen Sie:

Original goal:
...

Acceptance criteria:
...

Result:
...

Raw test evidence:
...

Determine PASS / FAIL / UNKNOWN.

Der Prüfer erhält Beweise, nicht das Urteil.

11.5 Kernmetriken

11.6 Führen Sie einen A/B-Test für Ihren Workflow durch

Anstatt darüber zu debattieren, ob Multi-Agenten „besser“ sind, vergleichen Sie:

A — one agent
B — planner + critic
C — planner + critic + specialist

Messen Sie für dieselbe Aufgabenklasse:

cost
latency
pass/fail
rework
defects
verification catches
human interventions

Behalten Sie zusätzliche Koordination nur bei, wenn sie das verifizierte Ergebnis so stark verbessert, dass es die Kosten rechtfertigt.

---

12. Fehlschlag-Modi (Failure modes): Wie gut aussehende Agentensysteme versagen

Das Hinzufügen von Agenten schafft ein neues System. Neue Systeme erzeugen neue Fehlschlag-Modi.

MAST formalisierte dieses Problem anhand von 14 Ausfallmodi (Failure Modes), die sich in Spezifikation/Systemdesign, Fehlausrichtung zwischen Agenten (Inter-Agent Misalignment) und Aufgabenüberprüfung/-beendigung unterteilen.

Quelle: Why Do Multi-Agent LLM Systems Fail?.

Die folgende operative Tabelle wandelt diese Forschung in konkrete technische Prüfungen um.

12.1 Unendliche Dialoge

Setzen Sie:

max_rounds = 3

Danach:

if no acceptance-blocking issue remains:
    approve
else:
    escalate

Lassen Sie das System keine Gründe erfinden, um die Debatte künstlich fortzuführen.

12.2 Konsens-Theater

Ein Kritiker sollte berechtigt sein, einen Plan abzulehnen.

Der Planer sollte jedoch auch den Kritiker ablehnen dürfen, wenn dessen Einwand unbegründet ist.

Gute adversarial Collaboration bedeutet nicht, dass „jeder widerspricht“.

Es lautet:

claim
→ evidence
→ challenge
→ resolution

12.3 Halluzinations-Kaskaden

Eine nicht unterstützte Behauptung wird gefährlich, wenn sie mehrere Agenten durchläuft:

UNKNOWN
 ↓
plausible
 ↓
supported-sounding
 ↓
“fact”
 ↓
implementation decision

Ihr Zustandsmodell sollte diese Umwandlung explizit machen.

12.4 Shared-State-Korruption

Verwenden Sie für wichtige Artefakte einen einzigen kanonischen Schreiber.

Critic      → proposes change
Specialist  → proposes evidence
Planner     → updates canonical plan
Verifier    → updates verification report
Human       → approves/rejects high-impact decisions

Andere schlagen vor. Ein Eigentümer schreibt (commit).

12.5 Tool-Halluzination

Pflegen Sie eine Closed-World-Registry:

tool: run_tests
description: "Runs the repository's configured test suite"
permissions: [read, execute]
side_effects: "may create temporary files"

Lassen Sie einen Agenten nicht annehmen, dass es „dafür bestimmt ein Tool geben muss“.

12.6 Token-Ökonomie

Ein Workflow kann technisch erfolgreich und wirtschaftlich absurd sein.

Die von Anthropic veröffentlichte 15-fache Token-Zahl für Multi-Agenten-Recherchen ist eine nützliche Warnung, auch wenn sie spezifisch für Anthropic-Architektur und -Evaluierung gilt.

Messen Sie:

cost per verified success

und nicht lediglich:

cost per run

---

13. SEO, GEO und KI-lesbares Publizieren ohne den Mythen-Hype

Von Agenten erstellte Arbeit wird zunehmend zu öffentlichen Inhalten.

Das wirft ein zweites Problem auf: Sobald der Workflow einen großartigen Artikel produziert hat, wie sorgen Sie dafür, dass Menschen, Suchmaschinen und KI-Systeme diesen leicht entdecken und verstehen können, ohne dass der Artikel zu einer „SEO-Suppe“ verkommt?

Die Antwort beginnt mit einer Unterscheidung:

Maschinenlesbare Informationsarchitektur ist nützlich. Magische GEO-Hacks sind kein Ersatz dafür.

13.1 Was Google im Jahr 2026 tatsächlich sagt

Googles aktuelle Richtlinien zu KI-Funktionen sind ungewöhnlich direkt:

- bestehende SEO-Best-Practices bleiben relevant,

- Seiten müssen indexiert und für die Suche berechtigt sein, um Links in AI Overviews oder dem AI Mode zu unterstützen,

- es gibt keine zusätzlichen technischen Anforderungen, die speziell für diese KI-Funktionen erforderlich sind,

- wichtige Inhalte sollten in Textform verfügbar sein,

- interne Links, Crawlbarkeit, Seiten-Experience und nützliche Originalinhalte bleiben wichtig,

- es ist kein spezielles Schema.org-Markup für AI Overviews oder den AI Mode erforderlich.

Google sagt außerdem, dass die Einhaltung von Best-Practices weder das Crawling, das Indexieren noch das Ausspielen garantiert.

Quellen:

- Google — AI Features and Your Website

- Google — Optimizing for generative AI features

Dieser letzte Punkt ist wichtig, weil er eine der schlimmsten Formen des KI-Suchmarketings zunichte macht:

„Machen Sie diese drei Dinge, und Google AI wird Sie zitieren.“

Eine solche universelle Garantie gibt es nicht.

13.2 Die Search Console bietet jetzt eine bessere Messebene

Google hat im Juni 2026 das Performance-Reporting für generative KI in der Suche eingeführt und erklärt, dass diese Einblicke bis zum 31. August 2026 weltweit ausgerollt wurden.

Die Berichte zeigen die Sichtbarkeit innerhalb generativer KI-Funktionen in der Suche, einschließlich AI Overviews und dem AI Mode, direkt im Performance-Reporting-System der Search Console.

Das ist eine wichtige praktische Verbesserung, da sie Publishern eine datenbasierte Messoberfläche aus erster Hand bietet, anstatt die gesamte Analyse der KI-Suche auf Vermutungen Dritter stützen zu müssen.

Quelle: Google Search Central — Search Generative AI performance reports.

Nutzen Sie diese Daten, sofern sie verfügbar sind.

13.3 Was „KI-lesbar“ bedeuten sollte

Eine nützliche Seite sollte es einer Maschine ermöglichen, Folgendes zu beantworten:

What is this page about?
Who wrote it?
When was it published/updated?
What are the major claims?
What evidence supports them?
Which sections answer which questions?
Which parts are facts versus interpretations?
Where are the primary sources?
What is the canonical version?

Das ist keine spezielle KI-Formatierung.

Das ist gute Informationsarchitektur.

13.4 Struktur für Long-Form-Referenzinhalte

Eine langlebige Artikelstruktur:

Title
↓
TL;DR
↓
Table of Contents
↓
Definition / thesis
↓
Evidence
↓
Counterexamples
↓
Architecture
↓
Implementation
↓
Examples
↓
Failure modes
↓
Measurement
↓
Limitations
↓
Templates
↓
Sources

Diese Struktur hilft Menschen und Abrufsystemen aus demselben zugrundeliegenden Grund: Sie reduziert Mehrdeutigkeiten.

13.5 Strukturierte Daten: nützlich, nicht magisch

Für einen Artikel können relevante Schema.org-Eigenschaften Folgendes umfassen:

Article
author
datePublished
dateModified
headline
image
mainEntityOfPage

Das Markup sollte jedoch die sichtbaren Inhalte korrekt beschreiben.

Behaupten Sie nicht, dass ein Article-Schema KI-Zitate oder Rankings garantiert.

In der Dokumentation zu strukturierten Daten von Google wird ausdrücklich erwähnt, dass strukturierte Daten dem System helfen, Inhalte zu verstehen, während die Berechtigung und Darstellung von zusätzlichen Systemen und Anforderungen abhängen.

Quellen:

- Google — Structured data policies

- Schema.org — Article

13.6 robots.txt ist nur eine Ebene, nicht der gesamte Stack

Google gibt an, dass robots.txt den Zugriff von Crawlern steuert; es ist kein allgemeiner Noindex-Mechanismus.

Um Seiten aus der Google Suche herauszuhalten, verweist Google auf noindex oder Authentifizierung, anstatt sich allein auf robots.txt zu verlassen.

Quellen:

- Google — robots.txt

- Google — meta tags and attributes

Für KI-Crawler gilt dieselbe praktische Wahrheit: Eine Seite kann in der robots.txt erlaubt sein und dennoch durch andere Infrastrukturen scheitern.

Denken Sie in Ebenen:

robots.txt
   ↓
WAF / CDN
   ↓
bot mitigation
   ↓
authentication
   ↓
rate limiting
   ↓
JavaScript challenges
   ↓
HTTP response
   ↓
rendering / retrieval

OpenAI dokumentiert OAI-SearchBot für die Entdeckung im Zusammenhang mit der Websuche und stellt Publishern Leitlinien zur Verfügung, wie sie den Zugriff erlauben können. Anthropic dokumentiert separate Crawler-Identitäten wie ClaudeBot, Claude-User und Claude-SearchBot.

Quellen:

- OpenAI — Publishers and Developers FAQ

- Anthropic — Web crawlers and robots.txt

13.7 llms.txt: vernünftiges Experiment, kein magisches SEO

Das Projekt llms.txt ist ein Community‑Vorschlag, um kuratierte, maschinenorientierte Informationen über eine Website bereitzustellen.

Es kann als Dokumentation nützlich sein.

Es ist keine universelle Anforderung von Google.

Die aktuelle generative‑KI‑Richtlinie von Google besagt ausdrücklich, dass Sie keine speziellen KI‑Textdateien wie llms.txt erstellen müssen, um in den generativen KI‑Suchfunktionen zu erscheinen.

Quellen:

- llms.txt

- Google — generative AI guidance

Verwenden Sie es, weil es einen klaren Zweck für die Informationsarchitektur erfüllt, nicht weil jemand es als Ranking‑Schalter verkauft hat.

13.8 GEO‑Messung ist mehr als Zitationszahl

Aktuelle Forschung aus dem Jahr 2026 arbeitet an einem präziseren Modell der Sichtbarkeit in KI‑gestützten Suchmaschinen.

Eine Studie aus April 2026 unterscheidet:

citation selection
≠
citation absorption

Eine Seite kann abgerufen und zitiert werden, ohne wesentlich zum generierten Ergebnis beizutragen.

Eine Umfrage aus Juli 2026 beschreibt GEO ebenfalls als mehrstufigen Prozess, der Entdeckbarkeit, Abruf, Neuranking, Zitation, Prominenz, faktische Aufnahme und nachgelagertes Nutzerverhalten umfasst.

Quellen:

- From Citation Selection to Citation Absorption

- Optimizing Visibility in Generative Engines: A Critical Survey

Das legt einen besseren Mess‑Stack nahe:

Discoverability
↓
Retrieval
↓
Citation
↓
Citation position / prominence
↓
Answer contribution
↓
Factual fidelity
↓
Traffic / conversions

Das ist weitaus informativer als „AI visibility score = 83“.

13.9 Was aktuelle GEO‑Forschung nahelegt — sorgfältig

Studien aus dem Jahr 2026 finden Zusammenhänge und kontrollierte Effekte in Bezug auf Faktoren wie thematische Relevanz, Kontextposition, explizite Fakten, Struktur und Evidenzreichtum. Eine wettbewerbsorientierte GEO‑Studie bewertete 252 000 kontrollierte Versuche über sechs LLMs; eine weitere große ACL‑Studie 2026 untersucht latente Nutzer‑Bedarfs‑Ausrichtung; ein separates Rahmenwerk analysiert, wie der Einfluss von Zitaten sich vom Zitations‑Selektionsprozess unterscheidet.

Dies sind wertvolle Forschungslinien.

Sie sollten jedoch nicht zu universellen Ratschlägen verdichtet werden, etwa:

„Schreiben Sie exakt X Wörter, fügen Sie Y Überschriften hinzu, und jede KI wird Sie zitieren.“

Die praktischere, sicherere Aussage lautet:

Machen Sie wichtige Informationen explizit, relevant, gut belegt, leicht auffindbar und treu zum Ausgangsmaterial.

Quellen:

- What Gets Cited: Competitive GEO in AI Answer Engines

- Mind Reader — ACL 2026

- From Experience to Skill — Findings of ACL 2026

13.10 Praktischer GEO/SEO‑Preflight

TECHNICAL
[ ] Crawlable when intended
[ ] Indexable when intended
[ ] Canonical URL is correct
[ ] Important text is accessible
[ ] No accidental noindex
[ ] Internal links are present
[ ] HTTP responses are healthy

CONTENT
[ ] Clear title
[ ] One clear H1
[ ] Coherent heading hierarchy
[ ] Direct answers to major questions
[ ] Definitions before jargon
[ ] Material claims supported by sources
[ ] Facts separated from interpretation
[ ] Publication/update date
[ ] Author / provenance

AI ACCESS
[ ] Intended AI crawler policy is deliberate
[ ] WAF/CDN does not silently block intended access
[ ] Authentication is understood
[ ] Rate limits are sane
[ ] JavaScript challenges are not accidental blockers

STRUCTURE
[ ] Accurate Article/Organization/etc. structured data where appropriate
[ ] Structured data matches visible content
[ ] Stable URLs
[ ] Duplicate versions controlled
[ ] Sources are easy to follow

Für einen praktischen Preflight einer öffentlichen Seite kann der AuditMe's Website SEO Checker eine URL prüfen und Probleme in den Bereichen technisches SEO, Inhaltsstruktur, Schema, Performance und verwandte Bereitschaftsdimensionen aufzeigen.

Damit ist er als diagnostischer Durchlauf nützlich.

Er ist jedoch kein Beweis dafür, dass ein KI‑System die Seite zitieren wird.

AuditMe‑Links für den Workflow

- AuditMe — SEO‑ und Website‑Intelligenz‑Audit

- AuditMe — Website‑SEO‑Checker

- AuditMe — SEO‑Score‑Checker

Der richtige Einsatz eines Audittools in diesem Prozess ist als Preflight‑Beweis: Technische und strukturelle Probleme finden, bevor man eine Suchmaschine oder ein KI‑System die Seite entdecken lässt.

---

14. Das wiederverwendbare Betriebskit

Dieser Abschnitt ist zum Kopieren gedacht.

Sie können die Vorlagen in einem Repository, einer Wissensdatenbank, einer Prompt‑Bibliothek oder einer Workflow‑Engine ablegen.

14.1 Zielvertragsvorlage

# Goal Contract

## Goal
[One precise sentence]

## Why
[Why the work matters]

## Constraints
- [constraint]
- [constraint]

## Forbidden Changes
- [forbidden change]
- [forbidden change]

## Definition of Done
- [measurable criterion]
- [measurable criterion]

## Unknowns
- [unknown]
- [unknown]

14.2 Planer‑Prompt

You are the Planner.

Goal:
[goal]

Constraints:
[list]

Forbidden changes:
[list]

Definition of done:
[criteria]

First inspect the real evidence available to you.
Do not execute implementation.
Do not invent architecture.
Mark assumptions and unknowns explicitly.

Return:
1. Observed facts
2. Assumptions
3. Proposed plan
4. Dependencies
5. Risks
6. Acceptance tests
7. Rollback/recovery path

14.3 Kritiker‑Prompt

You are the Critic.

Assume the current plan is wrong.
Find the smallest number of high-impact reasons it could fail.

Prioritize:
- goal violations
- incorrect assumptions
- hidden dependencies
- missing tests
- security/reliability risks
- unnecessary complexity
- scope creep

Do not rewrite the plan.
Return each issue as:

Action:
State:
Result:
Evidence:
Confidence:
Next needed:

14.4 Fach‑Prompt

You are a domain specialist.

Question to resolve:
[one specific question]

Do not review the entire project.
Do not redesign unrelated systems.
Prefer primary documentation, code inspection, tests, or reproducible measurements.

Return:
Action:
State:
Result:
Evidence:
Confidence:
Open questions:

14.5 Verifizierer‑Prompt

You are the Verifier.

Original Goal:
[goal]

Definition of Done:
[criteria]

Inspect the result independently.
Do not rely on the creator's explanation.
Prefer deterministic evidence whenever available.

For every criterion return:
PASS / FAIL / UNKNOWN

For each result include:
- evidence
- blockers
- defects found
- repair needed

Final decision:
GO / CONDITIONAL GO / NO-GO

14.6 Menschliche‑Stimme‑Editor‑Prompt

You are the final human-voice editor.

Do not make the article more enthusiastic.
Make it more credible and authored.

Remove:
- generic AI transitions
- inflated adjectives
- repeated conclusions
- fake certainty
- unnecessary headings
- repetitive sentence rhythms

Preserve:
- technical specificity
- source attribution
- disagreement
- uncertainty
- concrete examples
- author judgment

Do not invent personal experience, clients, benchmarks, or case studies.

14.7 Agent‑Übergabeschema

from: "critic"
to: "planner"
action: "reject_plan_step"
state: "orphaned routes are possible"
result: "add crawlability and canonical acceptance test"
evidence:
  - "route-manifest.json"
  - "crawler-output.json"
confidence: "high"
next_needed: "revise_plan"

14.8 Vorgeschlagener Repository‑Aufbau

.agent/
├── goal-contract.md
├── plan.md
├── evidence-ledger.md
├── decisions.md
├── verification.md
├── prompts/
│   ├── planner.md
│   ├── critic.md
│   ├── specialist.md
│   ├── verifier.md
│   └── human-voice-editor.md
└── runs/
    ├── 2026-09-22-run-001.md
    └── 2026-09-23-run-002.md

Der genaue Ordner ist nicht entscheidend.

Die Trennung ist es.

14.9 Minimal funktionsfähige Schleife — 15 bis 30 Minuten

0–5 Minuten

Schreiben:

Goal
Constraints
Forbidden changes
Definition of done
Unknowns

5–10 Minuten

Planungsmodus / Planer‑Durchlauf.

10–15 Minuten

Kritiker mit frischem Kontext.

15–20 Minuten

Beweise‑gestützte Korrekturen lösen.

20–25 Minuten

Einen Checkpoint ausführen.

25–30 Minuten

Gegen den ursprünglichen Vertrag verifizieren.

Das reicht, um zu beginnen.

Sie benötigen keine verteilte Orchestrierungsplattform, um den Kernvorteil zu erhalten.

14.10 Kompakte Checkliste

Vor der Ausführung

[ ] Goal Contract exists
[ ] Constraints explicit
[ ] Forbidden changes explicit
[ ] Definition of done measurable
[ ] Real evidence inspected
[ ] Unknowns labeled
[ ] Plan falsifiable
[ ] Critic allowed to reject
[ ] Specialists have narrow assignments
[ ] Canonical plan has one owner

Während der Ausführung

[ ] Independent work parallelized only where useful
[ ] Handoffs pass state, not speeches
[ ] Evidence provenance preserved
[ ] Tool permissions scoped
[ ] Checkpoints explicit
[ ] Scope remains inside contract
[ ] Raw test outputs retained

Vor dem Ausliefern

[ ] Deterministic checks passed
[ ] Material claims verified
[ ] Contradictions resolved or labeled
[ ] Final artifact matches Goal Contract
[ ] Unknowns documented
[ ] Verification is independent enough to matter
[ ] Cost / latency / rework measured
[ ] Final artifact is reusable

14.11 Die 12 Regeln, die man sich merken sollte

1. Beginne mit einem Agenten.

Architiere keinen Rat, bevor du den Engpass benennen kannst.

2. Teile nach Unsicherheit, nicht nach Stellenbezeichnung.

Ein Spezialist existiert, weil etwas einen anderen Kontext, andere Werkzeuge, Fachwissen oder unabhängiges Urteil erfordert.

3. Parallelisiere unabhängige Arbeit.

Das ist einer der klarsten Gründe, mehrere Agenten zu nutzen.

4. Halte den Goal Contract stabil.

Andernfalls kann das System „erfolgreich“ sein, indem es das Problem ändert.

5. Mache den Plan kanonisch.

Verwandele den Chatverlauf nicht zu deiner Datenbank.

6. Übergib Zustand, nicht Reden.

Aktion + Zustand + Ergebnis ist ein praktischer Standard.

7. Greife an, bevor du ausführst.

Eine falsche Annahme in Markdown ist billig. Eine falsche Annahme in einem Produktions‑Diff ist es nicht.

8. Verifiziere mit der günstigsten zuverlässigen Methode.

Compiler statt Konversation. Test statt Meinung. Quelle statt Erinnerung.

9. Betrachte UNKNOWN als gültigen Zustand.

Fehlende Evidenz ist Information.

10. Messe verifizierte Ergebnisse.

Werkzeugaufrufe sind Aktivität. Ein bestandener Akzeptanztest ist ein Beweis für Fortschritt.

11. Halte das Framework kleiner als das Problem.

Wenn die Orchestrierung schwieriger ist als die zugrunde liegende Aufgabe, vereinfache.

12. Stoppe, wenn das Ziel erreicht ist.

Mehr Dialog bedeutet nicht automatisch mehr Qualität.

14.12 Schlussgedanke

Die Agenten‑Ära wird viele spektakuläre Demos hervorbringen.

Einige davon werden nützlich sein.

Viele werden jedoch Aktivität mit Fortschritt verwechseln.

Zehn Agenten können zwanzig Minuten reden und nichts produzieren, was ein Mensch sicher ausliefern könnte.

Ein Agent kann ein schwieriges Problem mit einem guten Plan und einem echten Test lösen.

Das interessante ingenieurtechnische Problem ist daher nicht:

Wie viele Agenten kann ich zur Zusammenarbeit bringen?

Sondern:

Welche Informationen müssen von einer Phase zur nächsten überleben, damit das System von der Absicht über evidenzbasierte Aktion bis hin zur verifizierten Fertigstellung gelangen kann?

Das ist die Iterative Creation Loop.

Die einfachste Implementierung ist oft noch die beste:

Goal Contract
→ Plan
→ Adversarial Critique
→ Narrow Specialist when needed
→ Checkpoint
→ Deterministic Verification
→ Independent Review
→ Learn

Beginne dort.

Miss es gegenüber der Ein‑Agent‑Version.

Füge Komplexität nur hinzu, wenn sie etwas beobachtbares liefert.

Das ist der Teil, der skalierbar ist.

Nicht die Anzahl der Agenten.

Die Qualität der Schleife.

---

Weiterführende Literatur und Primärquellen

Agenten‑Orchestrierung und Planung

- Cursor — Plan Mode

- Cursor — Plan Mode help

- Cursor — CLI

- Claude Code — Subagents

- Claude Code — Agent Teams

- Claude Code — Permissions

- OpenAI Agents SDK

- OpenAI — Agent orchestration

- OpenAI — JavaScript multi-agent orchestration

- LangChain — Multi-agent systems

- LangGraph

- CrewAI documentation

- Microsoft — AI agent orchestration patterns

- Microsoft Agent Framework — Workflow orchestrations

- Microsoft Agent Framework — Magentic orchestration

Multi-Agent-Forschung und -Evaluierung

- Anthropic — How we built our multi-agent Research system

- PACT — What Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems

- Why Do Multi-Agent LLM Systems Fail?

- MultiAgentBench

- Rethinking Multi-Agent Collaboration: When More Is Less

SEO, KI-Suche und Webzugriff

- Google — AI Features and Your Website

- Google — Optimizing for generative AI features

- Google — How Search Works

- Google — robots.txt

- Google — Meta tags and attributes

- Google — Structured data policies

- Google — Search Generative AI performance reports

- OpenAI — Publishers and Developers FAQ

- Anthropic — Web crawlers and robots.txt

- llms.txt proposal

GEO-Forschung und -Messung

- GEO: Generative Engine Optimization

- From Citation Selection to Citation Absorption

- What Gets Cited: Competitive GEO in AI Answer Engines

- Optimizing Visibility in Generative Engines: A Critical Survey

- Mind Reader — ACL 2026

- From Experience to Skill — Findings of ACL 2026

Praktische Preflight-Maßnahmen

- AuditMe — SEO & Website Intelligence Audit

- AuditMe — Website SEO Checker

- AuditMe — SEO Score Checker

---

Redaktioneller Hinweis

Dieser Leitfaden trennt bewusst von Anbietern gemeldete Engineering-Ergebnisse, akademische Erkenntnisse, offizielle Produktdokumentationen und praktische Heuristiken.

Die Metriken von Anbietern sind keine universellen Benchmarks. Akademische Ergebnisse hängen vom Benchmark-Design und den Versuchsbedingungen ab. Die Produktdokumentation beschreibt das derzeit angegebene Verhalten des Herausgebers, nicht jedes mögliche reale Ergebnis. GEO-Messungen können je nach Abfrage, Engine, Quellenmenge, Abrufprozess, Modell und Zeitpunkt variieren.

Das nützlichste Experiment bleibt nach wie vor das unglamouröseste:

Führen Sie dieselbe Aufgabenklasse mit und ohne zusätzliche Koordination aus. Messen Sie das verifizierte Ergebnis. Behalten Sie nur die Komplexität bei, die es tatsächlich verbessert.