Der PAOVR-Loop: Der echte Agent-Loop, der Aufgaben wirklich abschließt

Planen → Handeln → Beobachten → Verifizieren → Reparieren

Hör auf, Agenten zu bauen, die Erledigung nur erzählen. Beginne Systeme zu bauen, die sie beweisen.

2026 ist die Diskussion endlich über „Prompt-Engineering ist tot" hinausgegangen.

Was es ersetzt hat, ist leiser, härter und weitaus nützlicher: Loop-Engineering.

Die meisten Agenten scheitern immer noch auf dieselbe Weise. Sie erzeugen eine selbstsichere Endantwort, verkünden den Sieg und überlassen es dem Menschen herauszufinden, dass die Hälfte der Arbeit erfunden, übersprungen oder nie geprüft wurde. Wir haben alle schon zugesehen, wie ein Agent fünf Dollar an Tokens verbrannt hat, nur um selbstbewusst einen völlig falschen API-Aufruf zu halluzinieren oder ein Tool-Ergebnis zu erfinden, das nie existierte. Das Modell ist selten noch das eigentliche Problem. Was fehlt, ist der Vertrag.

Dies ist ein produktionsreifer Praxisleitfaden für die PAOVR-Schleife — das einzige Steuermuster, das echte Arbeit konsistent zu Ende bringt: Planen → Handeln → Beobachten → Verifizieren → Reparieren.

Sie ist die Synthese aus ReAct, Plan-and-Solve, modernem Harness-Design von Anthropic und OpenAI und den harten Lehren von Teams, die Agenten in Produktion betreiben statt in Demos.

Du gehst mit Folgendem raus:

• Einer präzisen Anatomie der PAOVR-Schleife, die langfristige Aufgaben übersteht
• Den tatsächlichen Prompts, die wir in Produktion verwenden
• JSON-Verträgen und TypeScript-Schnittstellen, die sowohl Agenten als auch Runtimes konsumieren können
• Echten 2026er-Implementation-Stacks (Next.js, TypeScript, Supabase, Vercel)
• Vektor-Speichermustern, die amnesische Agenten in Arbeiter verwandeln, die sich verbessern
• Fehlermustern, die weiterhin dominieren, und wie man sie beseitigt
• Einem Installationsplan für eine Woche, den du auf deinem eigenen Stack umsetzen kannst

Das ist keine Theorie. Es ist der Unterschied zwischen einem Agenten, der darüber redet, fertig zu sein, und einem, der beweist, dass er fertig ist.

Inhaltsverzeichnis

1. Warum die meisten Agenten 2026 immer noch scheitern
2. Der Wechsel vom Prompting zum Loop-Engineering
3. Die PAOVR-Schleife: Planen → Handeln → Beobachten → Verifizieren → Reparieren
4. Stufe 1 — Planen: Sag den Agenten nicht, sie sollen denken. Sag ihnen, sie sollen grafisch planen
5. Stufe 2 — Handeln: atomare Ausführung mit Tool-Verträgen
6. Stufe 3 — Beobachten: Verankerung in der Realität
7. Stufe 4 — Verifizieren: Der Schritt, den fast jeder überspringt
8. Stufe 5 — Reparieren: Erholung ohne Neustart bei null
9. JSON-Verträge, die Produktion überleben
10. Die Prompts, die wir tatsächlich in Produktion verwenden
11. Kontext-Engineering innerhalb der Schleife
12. Schutzschalter, Budgets und Stoppbedingungen
13. Fehlermuster, die ich 2026 weiterhin sehe
14. Wie echte Produktionssysteme diese Schleife nutzen
15. Ein Installationsplan für eine Woche
16. Checkliste für den Launch
17. Was du in den nächsten 15 Minuten tust
18. Weiterführende Links, Personen und Tools
19. Häufig gestellte Fragen

1. Warum die meisten Agenten 2026 immer noch scheitern

Das Fehlermuster hat sich verschoben.

In den Jahren 2023–2024 war das Modell oft schlicht falsch.

2026 ist das Modell beim atomaren Schritt meist kompetent. Das System scheitert, weil es keine durchsetzbare Definition von „fertig" gibt.

Typische Symptome:

• Der Agent erzeugt einen schönen Plan und improvisiert dann die Ausführung.
• Er markiert eine Aufgabe als abgeschlossen, weil der letzte Tool-Aufruf etwas zurückgegeben hat.
• Er prüft die ursprünglichen Erfolgskriterien nach der letzten Aktion nie wieder.
• Der Kontext wächst, bis das ursprüngliche Ziel unter dem Tool-Rauschen begraben ist.
• Wenn etwas bricht, schreibt der Agent den gesamten Plan neu, statt das kaputte Blatt zu reparieren.

Die gemeinsame Grundursache ist immer dieselbe: die Schleife hat keine Verifizierungsstufe mit Zähnen.

ReAct (Yao et al., 2022) lehrte uns, Gedanke → Aktion → Beobachtung zu verschränken. Das war notwendig. Für langfristige Produktionsarbeit war es nicht hinreichend. Plan-and-Solve (Wang et al., 2023) fügte eine explizite Planungsphase hinzu. Moderne Harnesses von Anthropic und OpenAI fügten Budgets, Worktrees und Skills hinzu. Das fehlende Stück, das Demos immer noch von zuverlässigen Systemen trennt, ist ein hartes Verifizieren → Reparieren-Tor.

Wenn dein Agent die Frage „Woher weiß ich, dass das fertig ist?" nicht mit Belegen statt mit Erzählungen beantworten kann, ist er nicht fertig.

2. Der Wechsel vom Prompting zum Loop-Engineering

Prompt-Engineering optimierte den einzelnen Turn.

Loop-Engineering optimiert die gesamte Trajektorie. Für die Master-Prompt-Ebene, die dieser Loop ersetzt, siehe Master Prompts 2026. Für die Master-Prompt-Ebene, die dieser Loop ersetzt, siehe Master Prompts 2026.

Menschen, die 2026 zuverlässige Agenten ausliefern, sprechen über andere Dinge:

• Boris Cherny (Claude Code, Anthropic): „Ich prompte Claude nicht mehr. Ich habe Schleifen laufen, die Claude prompter."
• Addy Osmani und die breitere Community: Loop-Engineering als Disziplin.
• Anstropics eigene Anleitung zum Agent SDK / Claude Code: Kontext sammeln → handeln → Arbeit verifizieren → wiederholen.
• Produktionsteams: Schutzschalter, maxTurns, Kostenschwellen, externe Verifizierer.

Die Design-Einheit ist nicht mehr „der perfekte System-Prompt".

Es ist die Steuerschleife, die das Modell innerhalb eines Vertrags hält, bis der Vertrag erfüllt ist oder das Budget erschöpft ist.

Dieser Artikel handelt von genau dieser Schleife — konkret von der PAOVR-Version.

3. Die PAOVR-Schleife: Planen → Handeln → Beobachten → Verifizieren → Reparieren

Das ist die minimal zuverlässige Form:

PLANEN
  ↓
HANDELN (ein atomarer Schritt)
  ↓
BEOBACHTEN (echtes Tool- / Umgebungsfeedback)
  ↓
VERIFIZIEREN (gegen explizites done_when)
  ↓
  ├─ fertig → nächste Aufgabe oder beenden
  └─ nicht fertig → REPARIEREN → zurück zu HANDELN oder nur den betroffenen Teilbaum neu planen

Das ist die PAOVR-Schleife.

Wichtige Design-Regeln:

1. Eine atomare Aktion pro Handeln. Bevorzugt maximal 1–3 Tool-Aufrufe.
2. Jede Aufgabe hat ein präzises done_when. Wenn du es nicht schreiben kannst, ist die Aufgabe nicht bereit.
3. Verifizieren ist extern oder zumindest unabhängig. Dasselbe Modell, das die Arbeit erzeugt hat, sollte nicht der einzige Richter sein.
4. Reparieren ist lokal. Wirf nicht den gesamten Plan weg, weil ein Blatt gescheitert ist.
5. Es gibt immer harte Stoppbedingungen. Iterationslimit, Kostenlimit, wiederholter identischer Fehler, Kontextbudget.

Das ist das Muster, das überlebt, wenn eine Aufgabe 40 Schritte statt 4 braucht.

4. Stufe 1 — Planen: Sag den Agenten nicht, sie sollen denken. Sag ihnen, sie sollen grafisch planen

Planen ist nicht mehr „Denk Schritt für Schritt".

Es ist die Erzeugung eines ausführbaren Graphen.

Wie ein guter Plan aussieht

• Das Ziel als beobachtbares Ergebnis formuliert
• Explizite Annahmen
• Rückfragen nur, wenn die Kosten eines Irrtums hoch sind
• Aufgaben auf Blatt-Ebene (in 1–3 Tool-Aufrufen machbar)
• Abhängigkeiten deklariert
• Jede Aufgabe hat ein done_when, das ein späterer Verifizierer prüfen kann
• Risiken aufgelistet

Der Planner-Prompt, den wir wirklich verwenden

Handle als Task Planner. Du führst nicht aus. Du erzeugst nur einen ausführbaren Plan.

Regeln:
1. Zerlege das Ziel in atomare Schritte.
2. Ein Schritt = eine Aktion oder eine eng verwandte Gruppe von Tool-Aufrufen (max. 3).
3. Deklariere Abhängigkeiten mit Aufgabenvariablen.
4. Jeder Schritt muss ein klares done_when haben, das später verifiziert werden kann.
5. Wenn kritische Informationen fehlen, liste Annahmen und clarifying_questions auf. Erfinde keine Fakten.
6. Gib nur striktes JSON aus. Keinen Prosa-Aufsatz.

Gib genau dieses Schema zurück:
{
  "goal": "string",
  "assumptions": ["string"],
  "clarifying_questions": ["string"],
  "tasks": [
    {
      "id": "t1",
      "title": "string",
      "description": "string",
      "depends_on": ["t0"],
      "tool_hint": "none|search|code|browser|api|file",
      "done_when": "beobachtbare Bedingung, die die Fertigstellung beweist"
    }
  ],
  "risks": ["string"]
}

Dieser Planner ist bewusst dumm in Bezug auf die Ausführung. Das ist der Punkt. Trennung der Zuständigkeiten ist es, was das System debugbar hält.

5. Stufe 2 — Handeln: atomare Ausführung mit Tool-Verträgen

Der Executor erhält eine Aufgabe, den aktuellen Planzustand und frühere Beobachtungen. Es ist ihm verboten, vorzuspringen.

Executor-Prompt

Handle als Executor Agent.
Übernimm genau eine nächste Aufgabe aus dem Plan. Spring nicht vor. Erfinde keine fehlenden Daten.

Eingaben, die du erhältst:
- plan JSON
- current_task_id
- frühere Tool-Ergebnisse / Beobachtungen (falls vorhanden)

Methode:
1. Lies das done_when der aktuellen Aufgabe erneut.
2. Wenn du mangels Daten blockiert bist, fordere das billigste Tool an oder markiere den Status als blocked.
3. Führe die kleinste nützliche Aktion aus, die die Aufgabe voranbringt.
4. Gib nur strukturierte Ausgabe zurück:

## Aktion
(was du getan hast)

## Beleg
(rohe Tool-Ausgabe oder Beobachtung — paraphrasiere die Wahrheit nie weg)

## Status
done | partial | blocked

## Restrisiken
(alle neu eingeführten Risiken)

## Nächste Empfehlung
(nur wenn der Status nicht done ist)

Der Executor entscheidet nie, dass das Gesamtziel fertig ist. Diese Entscheidung gehört der äußeren Schleife nach der Verifizierung.

6. Stufe 3 — Beobachten: Verankerung in der Realität

Die Beobachtung ist der einzige Ort, an dem das Modell die reale Welt sehen darf.

Regeln, die 2026 noch zählen:

• Lass das Modell nie Tool-Ausgabe erfinden. Der Runtime liefert sie.
• Bevorzuge strukturierte Tool-Antworten gegenüber freiem Text, wo immer möglich.
• Halte das Beobachtungsfenster klein und signalreich. Kontextfäule ist real.
• Protokolliere jede Beobachtung mit Zeitstempel und Tool-Name. Du wirst sie zum Debuggen brauchen.

Das ist die Stufe, die ReAct von einem pfiffigen Prompt in ein zuverlässiges Steuersystem verwandelt.

7. Stufe 4 — Verifizieren: Der Schritt, den fast jeder überspringt

Verifizierung ist der Unterschied zwischen einem Agenten, der Erfolg behauptet, und einem, der ihn demonstriert.

Was „fertig" wirklich bedeutet

Eine Aufgabe ist erst fertig, wenn ihr done_when wahr ist und der Beleg diesen Anspruch stützt.

Der Verifizierer sollte vorzugsweise sein:

• Ein separater Modellaufruf mit einem anderen System-Prompt, oder
• Ein externer Prüfer (Tests, Linter, Schema-Validator, SEO-Score, menschliche Überprüfung), oder
• Eine deterministische Funktion, wenn es die Domäne erlaubt.

Verifier-Prompt

Handle als Verifier. Du erzeugst keine neue Arbeit. Du beurteilst nur, ob die aktuelle Aufgabe abgeschlossen ist.

Du erhältst:
- die ursprüngliche Aufgabe (einschließlich done_when)
- die durchgeführte Aktion
- den Beleg / die Beobachtung
- ein etwaig behauptetes Ergebnis

Regeln:
1. Zitiere das done_when.
2. Entscheide: satisfied | not_satisfied | insufficient_evidence.
3. Bei not_satisfied benenne die einzelne billigste nächste Prüfung oder Reparatur.
4. Akzeptiere Erzählung nie als Beweis. Fordere Belege.
5. Gib striktes JSON aus:

{
  "task_id": "...",
  "done_when": "...",
  "verdict": "satisfied|not_satisfied|insufficient_evidence",
  "evidence_summary": "ein oder zwei Sätze",
  "missing": ["was noch erforderlich ist"],
  "recommended_repair": "kleinste nächste Aktion oder null"
}

Das ist die Stufe, die die höfliche Lüge verhindert.

8. Stufe 5 — Reparieren: Erholung ohne Neustart bei null

Wenn Verifizieren not_satisfied zurückgibt, hat das System zwei saubere Optionen:

1. Lokale Reparatur — nur das gescheiterte Blatt erneut ausführen oder anpassen.
2. Teilbaum-Neuplanung — nur wenn sich die Abhängigkeiten selbst geändert haben.

Wirf nie den gesamten Plan weg, weil ein Schritt gescheitert ist. So verschwenden Agenten Tokens und verlieren Vertrauen.

Reparaturregel, die Stunden spart:

Wenn Status partial oder blocked ist oder Verifizieren not_satisfied sagt:
1. Benenne den Blocker in einem Satz.
2. Schlage die billigste nächste Prüfung oder Aktion vor.
3. Schreibe nicht den gesamten Plan neu, außer die vorgelagerten Abhängigkeiten haben sich wirklich geändert.
4. Bewahre jede abgeschlossene Aufgabe und ihren Beleg.

9. JSON-Verträge, die Produktion überleben

Freitext ist für Menschen in Ordnung. Agenten brauchen Schemata.

Hier ist ein minimales produktionsreifes Plan-Schema und ein passender Ausführungsdatensatz:

{
  "run_id": "uuid",
  "goal": "...",
  "status": "running|completed|failed|budget_exhausted",
  "tasks": [
    {
      "id": "t3",
      "status": "done|partial|blocked|failed",
      "attempts": 2,
      "last_evidence": "...",
      "verified_at": "ISO timestamp"
    }
  ],
  "cost_so_far": {
    "tokens": 12840,
    "usd_estimate": 0.41
  },
  "circuit_breaker": {
    "max_turns": 40,
    "max_cost_usd": 5.0,
    "identical_failure_limit": 3
  }
}

In TypeScript lässt sich das sauber auf Schnittstellen abbilden, die sowohl der Compiler als auch der Runtime durchsetzen:

interface Task {
  id: string;
  title: string;
  description: string;
  depends_on: string[];
  tool_hint: "none" | "search" | "code" | "browser" | "api" | "file";
  done_when: string;
  status?: "pending" | "running" | "done" | "partial" | "blocked" | "failed";
  attempts?: number;
  last_evidence?: string;
  verified_at?: string;
}

interface AgentPlan {
  goal: string;
  assumptions: string[];
  clarifying_questions: string[];
  tasks: Task[];
  risks: string[];
}

interface RunState {
  run_id: string;
  goal: string;
  status: "running" | "completed" | "failed" | "budget_exhausted";
  tasks: Task[];
  cost_so_far: { tokens: number; usd_estimate: number };
  circuit_breaker: {
    max_turns: number;
    max_cost_usd: number;
    identical_failure_limit: number;
  };
}

Diese Schnittstellen werden zur einzigen Quelle der Wahrheit zwischen Orchesterer, Edge-Funktionen und Logging-Schicht.

10. Die Prompts, die wir tatsächlich in Produktion verwenden

Du hast bereits die drei zentralen (Planner, Executor, Verifier).

Hier ist der äußere Schleifen-Controller, der sie verbindet:

Handle als Loop Controller. Du besitzt die gesamte Trajektorie.

Deine einzige Aufgabe:
1. Plan laden oder erstellen.
2. Nächste bereite Aufgabe auswählen (Abhängigkeiten erfüllt, Status nicht done).
3. An den Executor übergeben.
4. Das Ergebnis dem Verifier zuführen.
5. Bei satisfied → als done markieren und fortfahren.
6. Bei not_satisfied → Reparieren auslösen (zuerst lokal).
7. Schutzschalter vor jedem neuen Turn durchsetzen.
8. Wenn alle Aufgaben als done verifiziert sind, Endergebnis + Restrisiken ausgeben.
9. Nie die Fertigstellung erfinden.

Du sprichst nur in strukturierten Statusaktualisierungen und JSON-Status.

Diese vier Prompts bilden ein vollständiges, bereitstellbares Gerüst für die PAOVR-Schleife. Versioniere sie in git wie jede andere kritische Konfiguration.

11. Kontext-Engineering innerhalb der Schleife

Kontext ist eine endliche Ressource. In langen Läufen wird er zum primären Fehlermodus.

Praktische Regeln, die weiterhin gelten:

• Halte die Master-Policy (Rolle, Einschränkungen, Ausgabevertrag) stabil und gecacht.
• Gib dem Executor nur die aktuelle Aufgabe + die jüngsten Beobachtungen + das ursprüngliche done_when.
• Fasse abgeschlossene Aufgaben zusammen oder lagere sie aus, statt die gesamte Historie abzuspielen.
• Bevorzuge frischen Kontext für reine Ausführungsarbeiter und angesammelten Kontext nur für Planner/Orchestrator.
• Messe die Kontextfüllung. Wenn sie ~60–70 % des nutzbaren Fensters überschreitet, erzwinge einen Komprimierungs- oder Checkpoint-Schritt.

Deshalb behandeln die besten 2026er-Systeme das Dateisystem, git und externen Speicher als Erstklass-Kontextwerkzeuge, statt alles in den Prompt zu kippen. Die agentische Retrieval-Architektur hinter diesem Muster dokumentieren wir in The Double Life of the RAG Crawler. Die agentische Retrieval-Architektur hinter diesem Muster dokumentieren wir in The Double Life of the RAG Crawler.

Vektor-Speicher als Erstklass-Bürger

Kontextfenster sind groß, aber alles hineinzukippen zerstört die Aufmerksamkeit. Produktionsagenten nutzen 2026 externe Speicherarchitekturen.

Ein praktisches Muster:

1. Nach jeder abgeschlossenen (oder gescheiterten) Aufgabe eine kurze strukturierte Zusammenfassung dessen einbetten, was passiert ist, mit Beleg und Ergebnis.
2. Diese Embeddings in einem Vektor-Store ablegen. pgvector ist für viele Teams die Standardwahl, weil es neben dem relationalen Zustand liegt.
3. Vor der Planungsstufe eines neuen Laufs führt der Orchesterer eine Mikro-RAG-Recherche gegen die historischen Ausführungen des eigenen Agenten durch.
4. Die abgerufenen Einschränkungen werden als harte Lehren in den Kontext des Planners injiziert („frühere Versuche scheiterten, als der shadow-DOM-Selektor timeout auslöste; bevorzuge den data-testid-Pfad").

Der Effekt ist sich verstärkend. Ein Agent, der über Hunderte vergangener Sitzungen hinweg bei der Interaktion mit einem bestimmten UI-Element scheiterte, muss den Fehlermodus nicht wiederentdecken. Speicher verwandelt einen brillanten Amnesiker in einen Arbeiter, der sich tatsächlich verbessert.

Kombiniere die Embeddings mit einem schnellen, hochwertigen Text-Embedding-Modell. Gemini-Text-Embedding-Modelle sind 2026 wegen des Kosten/Qualitäts-Verhältnisses eine häufige Wahl. Halte das Retrieval-Budget winzig — normalerweise reichen die obersten 3–5 relevanten vergangenen Fehler oder Erfolge. Alles darüber führt Kontextfäule unter einem anderen Namen wieder ein.

12. Schutzschalter, Budgets und Stoppbedingungen

Eine Schleife ohne harte Stopps ist eine Haftung.

Mindestsatz:

Wenn ein Schutzschalter auslöst, muss der Agent:

1. Neue Aktionen stoppen.
2. Teilresultate zurückgeben, die bereits verifiziert wurden.
3. Klar sagen, was den Stopp ausgelöst hat und was offen bleibt.
4. Eskalieren, wenn es ein menschliches Gate gibt.

Verifizierte Teilarbeit ist immer wertvoller als eine selbstsichere Halluzination.

13. Fehlermuster, die ich 2026 weiterhin sehe

1. Erzählte Fertigstellung — das Modell sagt „done" ohne Beleg.

Fix: harte Verifizierungsstufe mit externem oder unabhängigem Urteil.

1. Ein Plan, der eigentlich ein Roman ist — Aufgaben, die noch einen kurzen Aufsatz an Anweisungen erfordern.

Fix: weiter aufteilen, bis jedes Blatt 1–3 Tool-Aufrufe ist.

1. Kontextfäule — das ursprüngliche Ziel unter 30 Tool-Beobachtungen begraben.

Fix: aggressives Pruning + separater Orchestrator-Kontext + Vektor-Speicher für langfristige Lehren.

1. Reparieren durch Total-Rewrite — ein Fehler lässt den Agenten alles verwerfen.

Fix: lokale Reparaturregel zuerst.

1. Fehlendes done_when — „Mach das gut" oder „Optimiere die Seite".

Fix: weigere dich, eine Aufgabe ohne beobachtbare Abschlussbedingung anzunehmen.

1. Tool-Halluzination — das Modell erfindet Tool-Ergebnisse.

Fix: der Runtime liefert die Beobachtung immer; dem Modell ist es nie erlaubt, sie zu erzeugen.

1. Endlose höfliche Schleifen — der Agent „versucht weiter noch eine Sache".

Fix: Schutzschalter mit Erkennung identischer Fehler.

Diese sieben machen weiterhin die Mehrheit des Produktionsschmerzes aus.

14. Wie echte Produktionssysteme diese Schleife nutzen

Das Muster taucht (unter verschiedenen Namen) in den Systemen auf, die tatsächlich ausgeliefert werden:

• Claude Code und das Anthropic Agent SDK — sammeln → handeln → verifizieren → wiederholen, mit expliziten Schleifentypen und Stoppbedingungen.
• Coding-Agenten, die die Testsuite als Verifier behandeln.
• Recherche-Agenten, die vor der Behauptung einer Tatsache einen Verifizierungsschritt gegen Quellen erzwingen.
• Content- und SEO-Pipelines, die nach der Generierung ein Qualitäts-Gate ausführen.

Die Implementierungsebene von 2026

Die Theorie lässt sich direkt auf moderne Stacks abbilden. Du brauchst kein massives monolithisches Python-Backend, um diese Schleife sauber auszuführen.

Eine verbreitete High-Leverage-Architektur 2026:

• Orchestrierung: Next.js App Router (oder eine schlanke Server-Component-Ebene) besitzt den Loop Controller. Strikte TypeScript-Schnittstellen setzen die JSON-Verträge zur Compile-Zeit durch.
• Zustand & Logs: Supabase (Postgres + pgvector) speichert den Laufzustand, die Aufgabenhistorie und den Vektor-Speicher vergangener Ausführungen.
• Ausführung: Serverless-/Edge-Funktionen auf Vercel verarbeiten einzelne Handeln-Schritte. Das hält die Oberfläche klein und die Cold Starts akzeptabel.
• Tool-Oberfläche: Viele Teams standardisieren auf das Model Context Protocol (MCP), damit Agenten konsistent mit Tools sprechen können.
• Lokale Entwicklung & Coding-Agenten: Dieselbe Philosophie treibt fortgeschrittene Refactoring-Sitzungen in Tools wie OpenCode und Cline an. Sie schreiben nicht nur Code; sie beobachten die Terminalausgabe, verifizieren gegen den Linter und die Testsuite und reparieren lokal, ohne die ganze Datei zu löschen.

Die Kern-Erkenntnis: Die PAOVR-Schleife ist sprachunabhängig. Sobald du typisierte Verträge und einen zuverlässigen Zustands-Store hast, funktioniert dieselbe Form für Coding-Agenten, Recherche-Agenten und domänenspezifische Crawler.

Fallstudie: Das Chaos des Web-Crawlings überleben

Schauen wir uns eine echte Produktionsumgebung von 2026 an. Beim Bau der Crawler-Pipeline für die KI-SEO-Plattform AuditMe war der größte Albtraum nicht das Parsen von HTML — es war die schiere Unvorhersehbarkeit des Webs. Seiten geben Timeouts, DOMs verschieben sich, JavaScript-lastige Seiten rendern jedes Mal anders, und standardmäßige lineare Skripte brechen ständig.

Um das zu beheben, wurde die gesamte Audit-Engine um die PAOVR-Schleife herum neu geschrieben. Statt eines monolithischen Skripts nutzt das System Next.js App Router und Supabase, um atomare Aufgaben zu orchestrieren. Wenn du zum Beispiel eine URL durch den kostenlosen Website SEO Checker schickst, löst das unter der Haube tatsächlich eine mehrstufige Planen → Handeln → Verifizieren-Pipeline aus.

Wenn eine Prüfung scheitert (zum Beispiel ein API-Timeout während eines schweren DOM-Renders), tötet das nicht die Audit. Die Schleife fängt den Fehler einfach in der Verifizierungsstufe ab, löst über die Reparieren-Stufe einen Failover mehrerer API-Anbieter aus und läuft nahtlos weiter. Nur das betroffene Blatt wird erneut versucht.

Es brauchte Monate der Refaktorierung — und unzählige lokale Sessions mit Tools wie OpenCode und Cline —, um den Vektor-Speicher und die Stoppbedingungen richtig hinzubekommen. Wir dokumentieren diese architektonischen harten Lehren regelmäßig, einschließlich der Frage, wie man KI-Suchbereitschaft und Kontextfenster behandelt, im AuditMe-Blog.

Das ist die PAOVR-Schleife angewandt auf einen realen Produktions-Crawler, der unter rauschenen Netzwerkbedingungen und sich ständig ändernden Seitenstrukturen zuverlässig bleiben muss.

15. Ein Installationsplan für eine Woche

Tag 1

Schreibe die drei zentralen Prompts (Planner, Executor, Verifier). Führe sie manuell an einer einfachen mehrstufigen Aufgabe aus. Miss, wo das Modell Verifizieren überspringen will.

Tag 2

Füge strikte JSON-Schemata (oder TypeScript-Schnittstellen) und ein einfaches Zustandsobjekt hinzu. Bring die äußere Schleife dazu, ohne gültigen Status die Fortsetzung zu verweigern.

Tag 3

Führe einen externen Verifizierer ein (Tests, Schema-Check oder einen zweiten Modellaufruf). Zwinge das System, ihn zu verwenden.

Tag 4

Füge Schutzschalter hinzu: max. Turns, Kosten, identischer Fehler. Teste sie, indem du ein Tool absichtlich brichst.

Tag 5

Implementiere lokale Reparatur zuerst. Bestätige, dass ein einzelnes gescheitertes Blatt nicht den gesamten Plan zerstört. Optional: einen minimalen pgvector-Speicher für vergangene Fehler anbinden.

Tag 6

Führe eine echte Aufgabe mit 20–40 Schritten aus. Protokolliere jede Beobachtung und Verifizierung. Identifiziere die Stufe mit der höchsten Reibung.

Tag 7

Schreibe das einseitige interne Playbook für dein Team. Versioniere die Prompts und Schemata. Lege das Zustandsschema in git ab.

Am Ende der Woche hast du eine PAOVR-Schleife, die bereits zuverlässiger ist als 90 % der Agenten, die gerade in der Praxis laufen.

16. Checkliste für den Launch

Bevor du irgendeinen Agenten „Produktion" nennst:

• [ ] Jede Aufgabe hat ein explizites done_when
• [ ] Planner und Executor sind getrennt
• [ ] Die Verifizierungsstufe existiert und ist unabhängig
• [ ] Reparieren ist zuerst lokal
• [ ] Schutzschalter setzt der Runtime durch, nicht nur der Prompt
• [ ] Beobachtungen werden nie vom Modell erfunden
• [ ] Abgeschlossene Arbeit wird bewahrt und belegt
• [ ] Kosten- und Turn-Budgets sind sichtbar
• [ ] Teilresultate werden bei frühem Stopp zurückgegeben
• [ ] Prompts und Schemata sind versioniert
• [ ] Langfristige Lehren werden außerhalb des Kontextfensters gespeichert (Vektor-Speicher oder Äquivalent)

Wenn eine Box nicht angekreuzt ist, ist der Agent immer noch eine Demo.

17. Was du in den nächsten 15 Minuten tust

1. Kopiere den Planner-Prompt in deinen aktuellen Agenten-Stack.
2. Nimm eine echte Aufgabe, die dir wichtig ist, und zwinge sie, das JSON-Plan-Schema auszugeben.
3. Schreibe ein done_when für die ersten drei Blatt-Aufgaben, das ein Fremder verifizieren könnte.
4. Füge nach dem ersten Handeln einen einzelnen Verifizieren-Aufruf hinzu.
5. Führe es einmal aus und schau dir den Unterschied zwischen Erzählung und Beleg an.

Das ist der gesamte Unterschied zwischen „funktioniert normalerweise" und „ich kann ihm vertrauen, wenn ich nicht zuschaue".

18. Weiterführende Links, Personen und Tools

Grundlegende Papiere

• ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022
• Plan-and-Solve Prompting — Wang et al., 2023
• The Prompt Report — immer noch die beste einzelne Übersicht

Personen & Praxis

• Boris Cherny (Claude Code, Anthropic) — Loop-First-Denkweise
• Addy Osmani — hat „Loop-Engineering" populär gemacht
• Dokumentation des Anthropic Agent SDK / Claude Code
• OpenAIs Dokumentation zu Agenten und Codex

Tools & Plattformen, die man im Auge behalten sollte

• Claude Code / Anthropic Agent SDK
• Cursor, OpenCode, Cline und moderne Coding-Agent-Harnesses
• Model Context Protocol (MCP)
• pgvector + moderne Embedding-Modelle für Agentenspeicher
• Next.js App Router und Supabase für die Orchestrierungs- + Zustandsebene
• Produktions-Observability für Agenten (Kosten, Turns, Verifizierungsrate)

Verwandte AuditMe-Guides

• Master Prompts 2026 — die Master-Prompt-Ebene, die dieser Loop umschließt
• The Double Life of the RAG Crawler — agentisches Retrieval und Vektor-Memory in Produktion
• What Actually Makes ChatGPT, Claude, and Perplexity Cite Your Website — wie KI-Engines entscheiden, was sie vertrauen
• Generative Engine Optimization: Ein GEO-Sichtbarkeitsleitfaden — von KI-Suchmaschinen zitiert werden
• KI im SEO 2026 — wo Suche und agentische Loops zusammenkommen
• So misst du die AI-Such-Sichtbarkeit 2026 — KI-Auffindbarkeit messen

Verwandte AuditMe-Guides

• Master Prompts 2026 — die Master-Prompt-Ebene, die dieser Loop umschließt
• The Double Life of the RAG Crawler — agentisches Retrieval und Vektor-Memory in Produktion
• What Actually Makes ChatGPT, Claude, and Perplexity Cite Your Website — wie KI-Engines entscheiden, was sie vertrauen
• Generative Engine Optimization: Ein GEO-Sichtbarkeitsleitfaden — von KI-Suchmaschinen zitiert werden
• KI im SEO 2026 — wo Suche und agentische Loops zusammenkommen
• So misst du die AI-Such-Sichtbarkeit 2026 — KI-Auffindbarkeit messen

FAQ

Ist das nicht nur ReAct mit zusätzlichen Schritten?

ReAct ist die notwendige Verschränkung von Denken und Handeln. Die PAOVR-Schleife fügt explizite Planung mit Verträgen, unabhängige Verifizierung und kontrollierte Reparatur hinzu. Diese drei Ergänzungen sind es, die langfristige Arbeit zuverlässig machen.

Brauche ich immer noch einen starken System-Prompt?

Ja. Die obigen Prompts sind die System-Prompts. Sie konzentrieren sich nur auf Policy und Verträge statt auf Persönlichkeit.

Kann dasselbe Modell Planen, Handeln und Verifizieren?

Es kann, aber die Zuverlässigkeit sinkt. Bevorzuge Trennung, selbst wenn es dasselbe Basismodell mit unterschiedlichen System-Prompts und Temperaturen ist.

Was ist mit Multi-Agent-Systemen?

Dieselbe Schleife gilt weiterhin. Der Orchesterer führt die äußere PAOVR-Schleife aus; Spezialisten-Agenten werden zur Handeln-Stufe für bestimmte Tools oder Domänen.

Wie füge ich Langzeitspeicher hinzu, ohne den Kontext zu sprengen?

Nutze Vektor-Speicher (pgvector + Embeddings) und rufe vor der Planung nur die obersten relevanten Fehler oder Erfolge ab. Halte das Retrieval-Budget winzig.

Woher weiß ich, wann ich aufhören sollte, Stufen hinzuzufügen?

Wenn der Agent eine 30-Schritte-Aufgabe beenden, einen Tool-Fehler überleben und unter einem harten Budget verifizierte Teilresultate zurückgeben kann — dann hör auf. Zusätzliche Komplexität fügt meist mehr Fehlermodi hinzu, als sie entfernt.

Abschließende Anmerkung

Die Agenten, die 2027 noch in Produktion laufen werden, sind nicht die mit dem klügsten Persönlichkeitsblock. Es sind die, deren Schleifen einen Vertrag durchsetzen, Belege verlangen, sich an ihre vergangenen Fehler erinnern und wissen, wie man repariert, ohne neu anzufangen.

Baue die PAOVR-Schleife.

Versioniere die Verträge.

Verifiziere alles.

Gib dem Agenten einen Speicher, der sich verstärkt.

Dann kann das Modell endlich das tun, was wir seit drei Jahren von ihm verlangen: die Arbeit erledigen.

Geschrieben für Praktiker, die ausliefern. Aktualisiert für die 2026er-Agentenlandschaft.