{"slug": "the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs", "title": "The PAOVR Loop: The Real Agent Loop That Actually Finishes Jobs", "summary": "A production field guide published in 2026 argues that the PAOVR Loop — Plan, Act, Observe, Verify, Repair — is the control pattern that consistently finishes real agent work, synthesizing ReAct (Yao et al., 2022), Plan-and-Solve (Wang et al., 2023), and harness design from Anthropic and OpenAI. The guide attributes most agent failures in 2026 to a missing enforceable definition of \"done\" rather than model capability, citing agents that burn five dollars in tokens to hallucinate a wrong API call or invent a tool result. It prescribes JSON contracts, TypeScript interfaces, circuit breakers, budgets, and a one-week install plan built on Next.js, TypeScript, Supabase, and Vercel.", "body_md": "# The PAOVR Loop: The Real Agent Loop That Actually Finishes Jobs\n\nPlan → Act → Observe → Verify → Repair Stop building agents that narrate completion. Start building systems that prove it. In 2026 the conversation finally moved past “prompt engineering is dead.” What replaced it is quieter, harder, and far more useful: loop engineering. Most agents still fail the\n\nPlan → Act → Observe → Verify → Repair Stop building agents that narrate completion. Start building systems that prove it. In 2026 the conversation finally moved past “prompt engineering is dead.” What replaced it is quieter, harder, and far more useful: loop engineering. Most agents still fail 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. We’ve all watched an agent burn five dollars in tokens just to confidently hallucinate a completely wrong API call or invent a tool result that never existed. The model is rarely the real problem anymore. The missing contract is. This is a production-grade field guide to the PAOVR Loop — the only control pattern that consistently finishes real work: Plan → Act → Observe → Verify → Repair. It 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. You will leave with: A precise anatomy of the PAOVR Loop that survives long-horizon tasks The actual prompts we use in production JSON contracts and TypeScript interfaces that agents and runtimes can both consume Real 2026 implementation stacks (Next.js, TypeScript, Supabase, Vercel) Vector memory patterns that turn amnesiac agents into compounding workers Failure patterns that still dominate and how to kill them A one-week install plan you can run on your own stack This is not theory. It is the difference between an agent that talks about finishing and one that proves it finished. Why Most Agents Still Fail in 2026 The Shift from Prompting to Loop Engineering The PAOVR Loop: Plan → Act → Observe → Verify → Repair Stage 1 — Plan: Stop Asking Agents to Think. Ask Them to Graph Stage 2 — Act: Atomic Execution with Tool Contracts Stage 3 — Observe: Grounding in Reality Stage 4 — Verify: The Step Almost Everyone Skips Stage 5 — Repair: Recovery Without Restarting from Zero JSON Contracts That Survive Production The Prompts We Actually Use in Production Context Engineering Inside the Loop Circuit Breakers, Budgets, and Stopping Conditions Failure Patterns I Keep Seeing in 2026 How Real Production Systems Use This Loop A One-Week Install Plan Ship Checklist What to Do in the Next 15 Minutes Further Reading, People & Tools Frequently Asked Questions The failure mode shifted. In 2023–2024 the model was often simply wrong. In 2026 the model is usually competent at the atomic step. The system fails because there is no enforceable definition of “done.” Typical symptoms: The agent produces a beautiful plan and then freestyles the execution. It marks a task complete because the last tool call returned something. It never re-checks the original success criteria after the final action. Context grows until the original goal is buried under tool noise. When something breaks, the agent rewrites the entire plan instead of repairing the broken leaf. The common root cause is the same: the loop has no Verify stage with teeth. ReAct (Yao et al., 2022) taught us to interleave Thought → Action → Observation. That was necessary. It was not sufficient for long-horizon production work. Plan-and-Solve (Wang et al., 2023) added an explicit planning phase. Modern harnesses from Anthropic and OpenAI added budgets, worktrees, and skills. The missing piece that still separates demos from reliable systems is a hard Verify → Repair gate. If your agent cannot answer the question “How do I know this is finished?” with evidence instead of narration, it is not finished. Prompt engineering optimized the single turn. Loop engineering optimizes the entire trajectory. The people who ship reliable agents in 2026 talk about different things: Boris Cherny (Claude Code, Anthropic): “I don’t prompt Claude anymore. I have loops running that prompt Claude.” Addy Osmani and the broader community: loop engineering as a discipline. Anthropic’s own guidance on the Agent SDK / Claude Code: gather context → take action → verify work → repeat. Production teams: circuit breakers, maxTurns, cost thresholds, external verifiers. The unit of design is no longer “the perfect system prompt.” It is the control loop that keeps the model inside a contract until the contract is satisfied or the budget is exhausted. This article is about that loop — specifically the PAOVR version of it. Here 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 This is the PAOVR Loop. Key design rules: One atomic action per Act. Prefer 1–3 tool calls maximum. Every task has a crisp done_when. If you cannot write it, the task is not ready. Verify is external or at least independent. The same model that generated the work should not be the only judge. Repair is local. Do not throw away the entire plan because one leaf failed. Hard stopping conditions always exist. Iteration limit, cost limit, repeated identical failure, context budget. This is the pattern that survives when the task takes 40 steps instead of 4. Planning is no longer “think step by step.” It is the production of an executable graph. 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 Act as the Task Planner. You do not execute. You only produce an executable plan. Rules: 1. Split the goal into atomic steps. 2. One step = one action or one tightly related group of tool calls (max 3). 3. Declare dependencies with task IDs. 4. Every step must have a crisp done_when that can be verified later. 5. If critical information is missing, list assumptions and clarifying_questions. Do not invent facts. 6. Output strict JSON only. No prose essay. Return exactly this schema: { \"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\": \"observable condition that proves completion\" } ], \"risks\": [\"string\"] } This planner is deliberately dumb about execution. That is the point. Separation of concerns is what keeps the system debuggable. The Executor receives one task, the current plan state, and any previous observations. It is forbidden from jumping ahead. Act as the Executor Agent. Take exactly one next task from the plan. Do not jump ahead. Do not invent missing data. Inputs you will receive: - plan JSON - current_task_id - previous tool results / observations (if any) Method: 1. Re-read the done_when for the current task. 2. If you are blocked on missing data, request the cheapest tool or mark status blocked. 3. Perform the smallest useful action that moves the task forward. 4. Return structured output only: ## Action (what you did) ## Evidence (raw tool output or observation — never paraphrase away the truth) ## Status done | partial | blocked ## Residual risks (any new risks introduced) ## Next recommendation (only if status is not done) The Executor never decides the overall goal is finished. That decision belongs to the outer loop after verification. 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. You will need it for debugging. This is the stage that turns ReAct from a clever prompt into a reliable control system. Verification is the difference between an agent that claims success and one that demonstrates it. A task is done only when its done_when is true and the evidence supports that claim. The verifier should preferably be: A separate model call with a different system prompt, or An external checker (tests, linter, schema validator, SEO score, human review), or A deterministic function when the domain allows it. Act as the Verifier. You do not generate new work. You only judge whether the current task is complete. You receive: - original task (including done_when) - action taken - evidence / observation - any claimed result Rules: 1. Quote the done_when. 2. Decide: satisfied | not_satisfied | insufficient_evidence. 3. If not_satisfied, name the single cheapest next check or repair. 4. Never accept narration as proof. Require evidence. 5. Output strict JSON: { \"task_id\": \"...\", \"done_when\": \"...\", \"verdict\": \"satisfied|not_satisfied|insufficient_evidence\", \"evidence_summary\": \"one or two sentences\", \"missing\": [\"what is still required\"], \"recommended_repair\": \"smallest next action or null\" } This is the stage that prevents the polite lie. 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. Never throw away the entire plan because one step failed. That is how agents waste tokens and lose trust. Repair rule that saves hours: If Status is partial or blocked or Verify says not_satisfied: 1. Name the blocker in one sentence. 2. Propose the cheapest next check or action. 3. Do not rewrite the entire plan unless upstream dependencies actually changed. 4. Preserve every completed task and its evidence. Free-form text is fine for humans. Agents need schemas. 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 } } In TypeScript this maps cleanly to interfaces that the compiler and the runtime both enforce: 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; }; } These interfaces become the single source of truth between your orchestrator, edge functions, and logging layer. 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. 9. Never invent completion. You speak only in structured status updates and JSON state. These four prompts form a complete, deployable skeleton for the PAOVR Loop. Keep them versioned in git the same way you version any other critical configuration. 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. This is why the best 2026 systems treat the file system, git, and external memory as first-class context tools rather than dumping everything into the prompt. Context windows are large, but dumping everything into them destroys attention. 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. pgvector is the default choice for many teams because it lives next to the relational state. Before the Plan stage of a new run, the orchestrator performs a micro-RAG retrieval against the agent’s own historical executions. The retrieved constraints are injected into the Planner’s context as hard lessons (“previous attempts failed when the shadow-DOM selector timed out; prefer the data-testid path”). The effect is compounding. An agent that failed to interact with a particular UI element hundreds of times across past sessions no longer has to rediscover the failure mode. Memory turns a brilliant amnesiac into a worker that actually improves. Pair the embeddings with a fast, high-quality text-embedding model. Gemini text-embedding models are a common 2026 choice for the cost/quality balance. Keep the retrieval budget tiny — usually the top 3–5 most relevant past failures or successes are enough. Anything more and you re-introduce context rot under a different name. A loop without hard stops is a liability. Minimum set: Signal Typical setting Enforcement Max turns / iterations 20–60 depending on task Runtime Max cost (USD or tokens) Task-specific budget Runtime Identical failure streak 2–3 Instruction + runtime Context budget 70% of useful window Instruction Wall-clock timeout Optional Runtime When a breaker trips, the agent must: Stop new actions. Return partial results that were already verified. State clearly what triggered the stop and what remains open. Escalate if a human gate exists. Partial verified work is always more valuable than a confident hallucination. Narrated completion — the model says “done” without evidence. Fix: hard Verify stage with external or independent judgment. Plan that is actually a novel — tasks that still require a short essay of instructions. Fix: keep splitting until each leaf is 1–3 tool calls. Context rot — original goal buried under 30 tool observations. Fix: aggressive pruning + separate orchestrator context + vector memory for long-term lessons. Repair by total rewrite — one failure causes the agent to discard everything. Fix: local-first repair rule. Missing done_when — “make it good” or “optimize the page.” Fix: refuse to accept a task without an observable completion condition. Tool hallucination — model invents tool results. Fix: runtime always supplies Observation; model is never allowed to generate it. Infinite polite loops — agent keeps “trying one more thing.” Fix: circuit breakers with identical-failure detection. These seven still account for the majority of production pain. The pattern appears (under different names) in the systems that actually ship: Claude Code and the Anthropic Agent SDK — gather → act → verify → repeat, with explicit loop types and stopping conditions. Coding agents that treat the test suite as the verifier. Research agents that force a verification step against sources before claiming a fact. Content and SEO pipelines that run a quality gate after generation. The theory maps directly to modern stacks. You do not need a massive monolithic Python backend to run this loop cleanly. A common high-leverage architecture in 2026: Orchestration: Next.js App Router (or a lightweight server component layer) owns the Loop Controller. Strict TypeScript interfaces enforce the JSON contracts at compile time. State & Logs: Supabase (Postgres + pgvector) stores run state, task history, and the vector memory of past executions. Execution: Serverless / edge functions on Vercel handle individual Act steps. This keeps the surface small and the cold starts acceptable. Tool surface: Many teams standardize on the Model Context Protocol (MCP) so agents can talk to tools in a consistent way. Local development & coding agents: The same philosophy powers advanced refactoring sessions in tools like OpenCode and Cline. They do not just write code; they observe terminal output, verify against the linter and test suite, and repair locally without wiping the whole file. The key insight is that the PAOVR Loop is language-agnostic. Once you have typed contracts and a reliable state store, the same shape works for coding agents, research agents, and domain-specific crawlers. Let’s look at a real 2026 production environment. When building the crawler pipeline for the AI SEO platform AuditMe, the biggest nightmare wasn’t parsing HTML — it was the sheer unpredictability of the web. Sites timeout, DOMs shift, JavaScript-heavy pages render differently every time, and standard linear scripts break constantly. To fix this, the entire auditing engine was rewritten around the PAOVR Loop. Instead of a monolithic script, the system uses Next.js App Router and Supabase to orchestrate atomic tasks. For example, if you run a URL through the free Website SEO Checker, you are actually triggering a multi-stage Plan → Act → Verify pipeline under the hood. If a check fails (for example, an API timeout during a heavy DOM render), it doesn’t kill the audit. The loop simply catches the failure in the Verify stage, triggers a multi-provider API failover via the Repair stage, and continues seamlessly. Only the affected leaf is retried. It took months of refactoring — and countless local sessions with tools like OpenCode and Cline — to get the vector memory and stopping conditions right. We regularly document these architectural hard lessons, including how to handle AI search readiness and context windows, over on the AuditMe blog. This is the PAOVR Loop applied to a real production crawler that has to stay reliable under noisy network conditions and constantly changing page structures. Day 1 Write the three core prompts (Planner, Executor, Verifier). Run them manually on a simple multi-step task. Measure where the model tries to skip Verify. Day 2 Add strict JSON schemas (or TypeScript interfaces) and a simple state object. Make the outer loop refuse to continue without a valid status. Day 3 Introduce one external verifier (tests, schema check, or a second model call). Force the system to use it. Day 4 Add circuit breakers: max turns, cost, identical failure. Test them by deliberately breaking a tool. Day 5 Implement local-first Repair. Confirm that a single failed leaf does not destroy the whole plan. Optionally wire a minimal pgvector memory store for past failures. Day 6 Run a real 20–40 step task. Log every observation and verification. Identify the highest-friction stage. Day 7 Write the one-page internal playbook for your team. Version the prompts and schemas. Put the state schema in git. By the end of the week you will have a PAOVR Loop that is already more reliable than 90% of the agents currently running in the wild. Before you call any agent “production”: [ ] Every task has an explicit done_when [ ] Planner and Executor are separate [ ] Verify stage exists and is independent [ ] Repair is local-first [ ] Circuit breakers are enforced by the runtime, not just the prompt [ ] Observations are never invented by the model [ ] Completed work is preserved and evidenced [ ] Cost and turn budgets are visible [ ] Partial results are returned on early stop [ ] Prompts and schemas are versioned [ ] Long-term lessons are stored outside the context window (vector memory or equivalent) If any box is unchecked, the agent is still a demo. Copy the Planner prompt into your current agent stack. Take one real task you care about and force it to emit the JSON plan schema. Write a done_when for the first three leaf tasks that a stranger could verify. Add a single Verify call after the first Act. Run it once and look at the difference between narration and evidence. That is the entire difference between “it usually works” and “I can trust it when I’m not watching.” ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022 Plan-and-Solve Prompting — Wang et al., 2023 The Prompt Report — still the best single survey Boris Cherny (Claude Code, Anthropic) — loop-first mindset Addy Osmani — popularized “loop engineering” Anthropic Agent SDK / Claude Code docs OpenAI’s agent and Codex documentation Claude Code / Anthropic Agent SDK Cursor, OpenCode, Cline and modern coding agent harnesses Model Context Protocol (MCP) pgvector + modern embedding models for agent memory Next.js App Router and Supabase for the orchestration + state layer Production observability for agents (cost, turns, verification rate) Isn’t this just ReAct with extra steps? ReAct is the necessary interleaving of reasoning and acting. The PAOVR Loop adds explicit planning with contracts, independent verification, and controlled repair. Those three additions are what make long-horizon work reliable. Do I still need a strong system prompt? Yes. The prompts above are the system prompts. They are just focused on policy and contracts instead of personality. Can the same model do Plan, Act, and Verify? It can, but reliability drops. Prefer separation, even if it is the same base model with different system prompts and temperature. What about multi-agent systems? The same loop still applies. The orchestrator runs the outer PAOVR Loop; specialist agents become the Act stage for particular tools or domains. How do I add long-term memory without exploding context? Use vector memory (pgvector + embeddings) and retrieve only the top few relevant past failures or successes before planning. Keep the retrieval budget tiny. How do I know when to stop adding stages? When the agent can finish a 30-step task, survive a tool failure, and return verified partial results under a hard budget — stop. Further complexity usually adds more failure modes than it removes. Final note The agents that will still be running in production in 2027 are not the ones with the cleverest personality block. They are the ones whose loops enforce a contract, demand evidence, remember their past failures, and know how to repair without starting over. Build the PAOVR Loop. Version the contracts. Verify everything. Give the agent a memory that compounds. Then the model can finally do what we have been asking it to do for three years: finish the job. Written for practitioners who ship. Updated for the 2026 agent landscape.\n\n## Key Takeaways\n\n- •Plan → Act → Observe → Verify → Repair Stop building agents that narrate completion\n- •This story was reported by **Dev.to** , covering developments in the**dev** space.\n- •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage.\n\n📖 Continue reading the full article:\n\n[Read Full Article on Dev.to →](https://dev.to/edo911/the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs-1j7k)", "url": "https://wpnews.pro/news/the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs", "canonical_source": "https://ainexusdaily.vercel.app/article/2026-09-11-the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs", "published_at": "2026-09-11 10:07:43+00:00", "updated_at": "2026-09-11 10:32:39.738332+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models", "ai-research"], "entities": ["PAOVR Loop", "ReAct", "Plan-and-Solve", "Anthropic", "OpenAI", "Next.js", "TypeScript", "Supabase"], "alternates": {"html": "https://wpnews.pro/news/the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs", "markdown": "https://wpnews.pro/news/the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs.md", "text": "https://wpnews.pro/news/the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs.txt", "jsonld": "https://wpnews.pro/news/the-paovr-loop-the-real-agent-loop-that-actually-finishes-jobs.jsonld"}}