The PAOVR Loop: The Real Agent Loop That Actually Finishes Jobs

The PAOVR Loop: The Real Agent Loop That Actually Finishes Jobs

Why Most Agents Still Fail in 2026

Most agents still fail in the same way: they generate a confident final answer, declare victory, and leave the human to discover that half the work was invented, skipped, or never checked. This is a production-grade field guide to the PAOVR Loop - the only control pattern that consistently finishes real work.

The Shift from Prompting to Loop Engineering

The conversation has moved past “prompt engineering is dead.” What replaced it is quieter, harder, and far more useful: loop engineering. The missing piece that still separates demos from reliable systems is a hard Verify → Repair gate.

The PAOVR Loop: Plan → Act → Observe → Verify → Repair

The PAOVR Loop is the synthesis of ReAct, Plan-and-Solve, modern harness design from Anthropic and OpenAI, and the hard lessons of teams that run agents in production instead of demos. It is the minimal reliable shape:

PLAN ↓ ACT (one atomic step) ↓ OBSERVE (real tool / environment feedback) ↓ VERIFY (against explicit done_when) ↓ ├─ done → next task or finish └─ not done → REPAIR → back to ACT or re-plan only the affected subtree

Stage 1 - Plan: Stop Asking Agents to Think. Ask Them to Graph

Planning is no longer “think step by step.” It is the production of an executable graph. What a good plan looks like:

• Goal stated as an observable outcome
• Explicit assumptions
• Clarifying questions only when the cost of being wrong is high
• Tasks that are leaf-level (doable in 1-3 tool calls)
• Dependencies declared
• Every task has a done_when string that a later verifier can check
• Risks listed

The planner prompt we actually use is:

Act as the Task Planner. You do not execute. You only produce an executable plan.

Stage 2 - Act: Atomic Execution with Tool Contracts

The Executor receives one task, the current plan state, and any previous observations. It is forbidden from jumping ahead.

Executor prompt:

Act as the Executor Agent. Take exactly one next task from the plan. Do not jump ahead. Do not invent missing data.

Stage 3 - Observe: Grounding in Reality

Observation is the only place the model is allowed to see the real world.

Rules that still matter in 2026:

• Never let the model invent tool output. The runtime supplies it.
• Prefer structured tool responses over free text when possible.
• Keep the observation window small and high-signal.
• Context rot is real. Log every observation with a timestamp and tool name.

Stage 4 - Verify: The Step Almost Everyone Skips

Verification is the difference between an agent that claims success and one that demonstrates it.

Verifier prompt:

Act as the Verifier. You do not generate new work. You only judge whether the current task is complete.

Stage 5 - Repair: Recovery Without Restarting from Zero

When Verify returns not_satisfied, the system has two clean options:

• Local repair - re-run or adjust only the failed leaf.
• Subtree re-plan - only when dependencies themselves have changed.

JSON Contracts That Survive Production

Here is a minimal production-ready plan schema and a corresponding execution record:

{
  "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
  }
}

The Prompts We Actually Use in Production

You already have the three core ones (Planner, Executor, Verifier). Here is the outer loop controller that ties them together:

Act as the Loop Controller. You own the overall trajectory.

Your only job:

1. Load or create the plan.
2. Select the next ready task (dependencies satisfied, status not done).
3. Hand it to Executor.
4. Feed the result to Verifier.
5. On satisfied → mark done and continue.
6. On not_satisfied → trigger Repair (local first).
7. Enforce circuit breakers before every new turn.
8. When all tasks are verified done, emit final result + residual risks.

Context Engineering Inside the Loop

Context is a finite resource. In long runs it becomes the primary failure mode.

Practical rules that still hold:

• Keep the master policy (role, constraints, output contract) stable and cached.
• Give the Executor only the current task + recent observations + the original done_when.
• Summarize or offload completed tasks instead of replaying the entire history.
• Prefer fresh context for pure execution workers and accumulated context only for the planner/orchestrator.
• Measure context fill. When it crosses ~60-70% of the useful window, force a compression or checkpoint step.

Vector Memory as a First-Class Citizen

Production agents in 2026 use external memory architectures.

A practical pattern:

After every completed (or failed) task, embed a short structured summary of what happened, the evidence, and the outcome. Store those embeddings in a vector store.