O Loop PAOVR: O Loop de Agentes Real que Realmente Conclui Tarefas

Planejar → Agir → Observar → Verificar → Reparar

Pare de construir agentes que apenas narram a conclusão. Comece a construir sistemas que a provam.

Em 2026, a conversa finalmente superou "engenharia de prompt está morta".

O que a substituiu é mais silencioso, mais difícil e muito mais útil: engenharia de loops.

A maioria dos agentes ainda falha da mesma forma. Eles geram uma resposta final confiante, declaram vitória e deixam o humano descobrir que metade do trabalho foi inventado, pulado ou nunca verificado. Todos nós já vimos um agente queimar cinco dólares em tokens apenas para alucinar com confiança uma chamada de API completamente errada ou inventar um resultado de ferramenta que nunca existiu. O modelo raramente é mais o problema real. O que falta é o contrato.

Este é um guia de campo para produção sobre o Loop PAOVR — o único padrão de controle que conclui trabalho real de forma consistente: Planejar → Agir → Observar → Verificar → Reparar.

É a síntese de ReAct, Plan-and-Solve, do design moderno de harness da Anthropic e da OpenAI, e das lições duras dos times que executam agentes em produção em vez de em demos.

Você vai sair com:

• Uma anatomia precisa do Loop PAOVR que sobrevive a tarefas de horizonte longo
• Os prompts reais que usamos em produção
• Contratos JSON e interfaces TypeScript que agentes e runtimes podem consumir
• Stacks de implementação reais de 2026 (Next.js, TypeScript, Supabase, Vercel)
• Padrões de memória vetorial que transformam agentes amnésicos em trabalhadores que se acumulam
• Os padrões de falha que ainda dominam e como eliminá-los
• Um plano de instalação de uma semana que você pode rodar no seu próprio stack

Isso não é teoria. É a diferença entre um agente que fala sobre terminar e um que prova que terminou.

Índice

1. Por que a maioria dos agentes ainda falha em 2026
2. A mudança do prompting para a engenharia de loops
3. O Loop PAOVR: Planejar → Agir → Observar → Verificar → Reparar
4. Estágio 1 — Planejar: pare de pedir aos agentes que pensem. Peça que eles façam um grafo
5. Estágio 2 — Agir: execução atômica com contratos de ferramenta
6. Estágio 3 — Observar: aterrissar na realidade
7. Estágio 4 — Verificar: a etapa que quase todo mundo pula
8. Estágio 5 — Reparar: recuperação sem recomeçar do zero
9. Contratos JSON que sobrevivem em produção
10. Os prompts que realmente usamos em produção
11. Engenharia de contexto dentro do loop
12. Disjuntores, orçamentos e condições de parada
13. Padrões de falha que continuo vendo em 2026
14. Como sistemas reais de produção usam esse loop
15. Um plano de instalação de uma semana
16. Checklist para publicar
17. O que fazer nos próximos 15 minutos
18. Leituras adicionais, pessoas e ferramentas
19. Perguntas frequentes

1. Por que a maioria dos agentes ainda falha em 2026

O modo de falha mudou.

Em 2023–2024 o modelo muitas vezes simplesmente errava.

Em 2026 o modelo costuma ser competente na etapa atômica. O sistema falha porque não existe uma definição executável de "concluído".

Sintomas típicos:

• O agente produz um plano bonito e depois improvisa a execução.
• Ele marca uma tarefa como completa porque a última chamada de ferramenta retornou algo.
• Ele nunca re-checa os critérios de sucesso originais após a ação final.
• O contexto cresce até que o objetivo original fique soterrado sob o ruído das ferramentas.
• Quando algo quebra, o agente reescreve o plano inteiro em vez de reparar a folha quebrada.

A causa raiz comum é a mesma: o loop não tem um estágio de Verificar com dentes.

O ReAct (Yao et al., 2022) nos ensinou a intercalar Pensamento → Ação → Observação. Isso era necessário. Não era suficiente para trabalho de produção de horizonte longo. O Plan-and-Solve (Wang et al., 2023) adicionou uma fase explícita de planejamento. Harnesses modernos da Anthropic e da OpenAI adicionaram orçamentos, worktrees e skills. A peça que ainda separa demos de sistemas confiáveis é um portal rígido de Verificar → Reparar.

Se seu agente não consegue responder à pergunta "como eu sei que isso terminou?" com evidência em vez de narração, ele não terminou.

2. A mudança do prompting para a engenharia de loops

A engenharia de prompt otimizava o turno individual.

A engenharia de loops otimiza a trajetória inteira. Para a camada de master prompt que este loop substitui, veja Master Prompts em 2026.

As pessoas que entregam agentes confiáveis em 2026 falam sobre coisas diferentes:

• Boris Cherny (Claude Code, Anthropic): "Não dou mais prompts ao Claude. Tenho loops rodando que dão prompts ao Claude."
• Addy Osmani e a comunidade em geral: a engenharia de loops como disciplina.
• A própria orientação da Anthropic sobre o Agent SDK / Claude Code: reunir contexto → agir → verificar o trabalho → repetir.
• Times de produção: disjuntores, maxTurns, limites de custo, verificadores externos.

A unidade de design não é mais "o prompt de sistema perfeito".

É o loop de controle que mantém o modelo dentro de um contrato até que o contrato seja satisfeito ou o orçamento se esgote.

Este artigo é sobre esse loop — especificamente, sobre a versão PAOVR dele.

3. O Loop PAOVR: Planejar → Agir → Observar → Verificar → Reparar

Esta é a forma mínima confiável:

PLANEJAR
  ↓
AGIR (uma etapa atômica)
  ↓
OBSERVAR (feedback real de ferramenta / ambiente)
  ↓
VERIFICAR (contra um done_when explícito)
  ↓
  ├─ pronto → próxima tarefa ou terminar
  └─ não pronto → REPARAR → voltar a AGIR ou replanejar apenas a subárvore afetada

Este é o Loop PAOVR.

Regras de design principais:

1. Uma ação atômica por Agir. Prefira no máximo 1–3 chamadas de ferramenta.
2. Toda tarefa tem um done_when claro. Se você não consegue escrevê-lo, a tarefa não está pronta.
3. Verificar é externo ou pelo menos independente. O mesmo modelo que gerou o trabalho não deve ser o único juiz.
4. Reparar é local. Não jogue fora o plano inteiro porque uma folha falhou.
5. Condições de parada rígidas sempre existem. Limite de iterações, limite de custo, falha idêntica repetida, orçamento de contexto.

Este é o padrão que sobrevive quando a tarefa exige 40 passos em vez de 4.

4. Estágio 1 — Planejar: pare de pedir aos agentes que pensem. Peça que eles façam um grafo

Planejar não é mais "pense passo a passo".

É a produção de um grafo executável.

Como é um bom plano

• O objetivo declarado como um resultado observável
• Suposições explícitas
• Perguntas de esclarecimento apenas quando o custo de errar é alto
• Tarefas no nível de folha (executáveis em 1–3 chamadas de ferramenta)
• Dependências declaradas
• Toda tarefa tem uma string de done_when que um verificador posterior possa checar
• Riscos listados

O prompt de planejador que realmente usamos

Atue como o Planejador de Tarefas. Você não executa. Você apenas produz um plano executável.

Regras:
1. Divida o objetivo em etapas atômicas.
2. Uma etapa = uma ação ou um grupo bem relacionado de chamadas de ferramenta (máx. 3).
3. Declare dependências com IDs de tarefa.
4. Cada etapa deve ter um done_when claro que possa ser verificado depois.
5. Se faltar informação crítica, liste suposições e clarifying_questions. Não invente fatos.
6. Produza apenas JSON estrito. Sem ensaio em prosa.

Retorne exatamente este esquema:
{
  "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": "condição observável que comprova a conclusão"
    }
  ],
  "risks": ["string"]
}

Este planejador é deliberadamente burro em relação à execução. Esse é o ponto. A separação de responsabilidades é o que mantém o sistema debuggável.

5. Estágio 2 — Agir: execução atômica com contratos de ferramenta

O Executor recebe uma tarefa, o estado atual do plano e observações anteriores. Ele está proibido de pular etapas.

Prompt do executor

Atue como o Agente Executor.
Pegue exatamente a próxima tarefa do plano. Não pule etapas. Não invente dados faltantes.

Entradas que você receberá:
- plan JSON
- current_task_id
- resultados / observações anteriores de ferramenta (se houver)

Método:
1. Releia o done_when da tarefa atual.
2. Se estiver bloqueado por falta de dados, solicite a ferramenta mais barata ou marque o status como blocked.
3. Execute a menor ação útil que faça a tarefa avançar.
4. Retorne apenas saída estruturada:

## Ação
(o que você fez)

## Evidência
(saída bruta da ferramenta ou observação — nunca parafraseie a verdade)

## Status
done | partial | blocked

## Riscos residuais
(quaisquer novos riscos introduzidos)

## Próxima recomendação
(apenas se o status não for done)

O Executor nunca decide que o objetivo geral terminou. Essa decisão pertence ao loop externo após a verificação.

6. Estágio 3 — Observar: aterrissar na realidade

A observação é o único lugar onde o modelo pode ver o mundo real.

Regras que ainda importam em 2026:

• Nunca deixe o modelo inventar a saída de uma ferramenta. O runtime a fornece.
• Prefira respostas de ferramenta estruturadas em vez de texto livre quando possível.
• Mantenha a janela de observação pequena e de alto sinal. A podridão de contexto é real.
• Registre cada observação com um carimbo de tempo e o nome da ferramenta. Você vai precisar deles para depurar.

Este é o estágio que transforma o ReAct de um prompt esperto em um sistema de controle confiável.

7. Estágio 4 — Verificar: a etapa que quase todo mundo pula

A verificação é a diferença entre um agente que afirma o sucesso e um que o demonstra.

O que "concluído" realmente significa

Uma tarefa só está concluída quando o seu done_when é verdadeiro e a evidência sustenta essa afirmação.

O verificador deve ser preferencialmente:

• Uma chamada de modelo separada com um prompt de sistema diferente, ou
• Um verificador externo (testes, linter, validador de schema, score de SEO, revisão humana), ou
• Uma função determinística quando o domínio permitir.

Prompt do verificador

Atue como o Verificador. Você não gera trabalho novo. Você apenas julga se a tarefa atual está completa.

Você recebe:
- a tarefa original (incluindo o done_when)
- a ação realizada
- a evidência / observação
- qualquer resultado reivindicado

Regras:
1. Cite o done_when.
2. Decida: satisfied | not_satisfied | insufficient_evidence.
3. Se for not_satisfied, aponte a única próxima verificação ou reparo mais barato.
4. Nunca aceite narração como prova. Exija evidência.
5. Produza JSON estrito:

{
  "task_id": "...",
  "done_when": "...",
  "verdict": "satisfied|not_satisfied|insufficient_evidence",
  "evidence_summary": "uma ou duas frases",
  "missing": ["o que ainda é necessário"],
  "recommended_repair": "menor próxima ação ou null"
}

Este é o estágio que impede a mentira educada.

8. Estágio 5 — Reparar: recuperação sem recomeçar do zero

Quando Verificar retorna not_satisfied, o sistema tem duas opções limpas:

1. Reparo local — executar novamente ou ajustar apenas a folha que falhou.
2. Replanejamento da subárvore — somente quando as próprias dependências mudaram.

Nunca jogue fora o plano inteiro porque uma etapa falhou. É assim que os agentes desperdiçam tokens e perdem confiança.

Regra de reparo que economiza horas:

Se o Status for partial ou blocked ou o Verificador disser not_satisfied:
1. Nomeie o bloqueador em uma frase.
2. Proponha a próxima verificação ou ação mais barata.
3. Não reescreva o plano inteiro a menos que as dependências anteriores tenham mudado de fato.
4. Preserve cada tarefa concluída e sua evidência.

9. Contratos JSON que sobrevivem em produção

Texto livre é bom para humanos. Agentes precisam de esquemas.

Aqui está um esquema de plano mínimo pronto para produção e um registro de execução correspondente:

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

Em TypeScript isso mapeia de forma limpa para interfaces que tanto o compilador quanto o runtime impõem:

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;
  };
}

Essas interfaces se tornam a fonte única de verdade entre o seu orquestrador, as funções edge e a camada de logging.

10. Os prompts que realmente usamos em produção

Você já tem os três principais (Planejador, Executor, Verificador).

Aqui está o controlador do loop externo que os conecta:

Atue como o Controlador do Loop. Você é dono da trajetória inteira.

Seu único trabalho:
1. Carregar ou criar o plano.
2. Selecionar a próxima tarefa pronta (dependências satisfeitas, status não done).
3. Entregá-la ao Executor.
4. Alimentar o Verificador com o resultado.
5. Em satisfied → marcar como done e continuar.
6. Em not_satisfied → acionar Reparar (local primeiro).
7. Aplicar os disjuntores antes de cada novo turno.
8. Quando todas as tarefas estiverem verificadas como done, emitir o resultado final + riscos residuais.
9. Nunca inventar a conclusão.

Fale apenas em atualizações de status estruturadas e estado JSON.

Esses quatro prompts formam um esqueleto completo e implantável do Loop PAOVR. Mantenha-os versionados no git da mesma forma que você versiona qualquer outra configuração crítica.

11. Engenharia de contexto dentro do loop

Contexto é um recurso finito. Em execuções longas, ele se torna o principal modo de falha.

Regras práticas que continuam valendo:

• Mantenha a política mestre (papel, restrições, contrato de saída) estável e em cache.
• Dê ao Executor apenas a tarefa atual + observações recentes + o done_when original.
• Resuma ou descarregue tarefas concluídas em vez de reproduzir todo o histórico.
• Prefira contexto novo para trabalhadores de execução pura e contexto acumulado apenas para o planejador/orquestrador.
• Meça o preenchimento do contexto. Quando ele cruzar ~60–70% da janela útil, force uma etapa de compressão ou checkpoint.

É por isso que os melhores sistemas de 2026 tratam o sistema de arquivos, o git e a memória externa como ferramentas de contexto de primeira classe em vez de despejar tudo no prompt. Documentamos a arquitetura de recuperación agéntica que sustenta esse padrão em The Double Life of the RAG Crawler.

Memória vetorial como cidadã de primeira classe

Janelas de contexto são grandes, mas despejar tudo nelas destrói a atenção. Agentes de produção em 2026 usam arquiteturas de memória externa.

Um padrão prático:

1. Após cada tarefa concluída (ou falha), incorpore um resumo estruturado curto do que aconteceu, a evidência e o resultado.
2. Armazene esses embeddings em um armazenamento vetorial. O pgvector é a escolha padrão de muitos times porque fica ao lado do estado relacional.
3. Antes do estágio de Planejar de uma nova execução, o orquestrador faz uma micro-recuperação RAG contra as execuções históricas do próprio agente.
4. As restrições recuperadas são injetadas no contexto do Planejador como lições duras ("tentativas anteriores falharam quando o seletor do shadow-DOM deu timeout; prefira o caminho data-testid").

O efeito é composto. Um agente que falhou ao interagir com um determinado elemento de UI centenas de vezes em sessões passadas não precisa redescobrir o modo de falha. A memória transforma um amnésico brilhante em um trabalhador que de fato melhora.

Combine os embeddings com um modelo de text-embedding rápido e de alta qualidade. Os modelos de text-embedding do Gemini são uma escolha comum em 2026 pelo equilíbrio custo/qualidade. Mantenha o orçamento de recuperação pequeno — normalmente os 3–5 fracassos ou sucessos passados mais relevantes são suficientes. Qualquer coisa a mais reintroduz a podridão de contexto sob outro nome.

12. Disjuntores, orçamentos e condições de parada

Um loop sem paradas rígidas é um passivo.

Conjunto mínimo:

Quando um disjuntor dispara, o agente deve:

1. Parar novas ações.
2. Retornar resultados parciais que já foram verificados.
3. Declarar claramente o que disparou a parada e o que permanece em aberto.
4. Escalar se existir um gate humano.

Trabalho parcial verificado é sempre mais valioso que uma alucinação confiante.

13. Padrões de falha que continuo vendo em 2026

1. Conclusão narrada — o modelo diz "done" sem evidência.

Correção: estágio de Verificar rígido com julgamento externo ou independente.

1. Um plano que na verdade é um romance — tarefas que ainda exigem um pequeno ensaio de instruções.

Correção: continue dividindo até que cada folha seja 1–3 chamadas de ferramenta.

1. Podridão de contexto — o objetivo original soterrado sob 30 observações de ferramenta.

Correção: poda agressiva + contexto de orquestrador separado + memória vetorial para lições de longo prazo.

1. Reparo por reescrita total — uma falha faz o agente descartar tudo.

Correção: regra de reparo local primeiro.

1. done_when ausente — "deixe bom" ou "otimize a página".

Correção: recuse aceitar uma tarefa sem uma condição de conclusão observável.

1. Alucinação de ferramenta — o modelo inventa resultados de ferramenta.

Correção: o runtime sempre fornece a Observação; o modelo nunca pode gerá-la.

1. Loops educados infinitos — o agente fica "tentando mais uma coisa".

Correção: disjuntores com detecção de falhas idênticas.

Esses sete ainda respondem pela maior parte da dor em produção.

14. Como sistemas reais de produção usam esse loop

O padrão aparece (sob nomes diferentes) nos sistemas que de fato são entregues:

• Claude Code e o Anthropic Agent SDK — reunir → agir → verificar → repetir, com tipos de loop explícitos e condições de parada.
• Agentes de código que tratam a suíte de testes como verificador.
• Agentes de pesquisa que forçam uma etapa de verificação contra fontes antes de afirmar um fato.
• Pipelines de conteúdo e SEO que executam um gate de qualidade após a geração.

A camada de implementação de 2026

A teoria mapeia diretamente para stacks modernos. Você não precisa de um backend Python monolítico e enorme para rodar esse loop de forma limpa.

Uma arquitetura comum e de alta alavancagem em 2026:

• Orquestração: Next.js App Router (ou uma camada leve de server components) é dona do Controlador do Loop. Interfaces TypeScript estritas impõem os contratos JSON em tempo de compilação.
• Estado e logs: Supabase (Postgres + pgvector) armazena o estado da execução, o histórico de tarefas e a memória vetorial de execuções passadas.
• Execução: funções serverless / edge no Vercel cuidam das etapas individuais de Agir. Isso mantém a superfície pequena e os cold starts aceitáveis.
• Superfície de ferramentas: muitos times padronizam no Model Context Protocol (MCP) para que agentes conversem com ferramentas de forma consistente.
• Desenvolvimento local e agentes de código: a mesma filosofia impulsiona sessões avançadas de refatoração em ferramentas como OpenCode e Cline. Elas não apenas escrevem código; observam a saída do terminal, verificam contra o linter e a suíte de testes e reparam localmente sem apagar o arquivo inteiro.

A percepção central é que o Loop PAOVR é agnóstico de linguagem. Uma vez que você tem contratos tipados e um armazenamento de estado confiável, a mesma forma funciona para agentes de código, agentes de pesquisa e crawlers de domínio específico.

Estudo de caso: sobreviver ao caos do web crawling

Vamos olhar um ambiente de produção real de 2026. Ao construir o pipeline de crawlers para a plataforma de SEO com IA AuditMe, o maior pesadelo não era parsear HTML — era a pura imprevisibilidade da web. Sites dão timeout, DOMs mudam, páginas com muito JavaScript renderizam de forma diferente a cada vez, e scripts lineares padrão quebram constantemente.

Para corrigir isso, todo o motor de auditoria foi reescrito em torno do Loop PAOVR. Em vez de um script monolítico, o sistema usa Next.js App Router e Supabase para orquestrar tarefas atômicas. Por exemplo, se você passar uma URL pelo Website SEO Checker gratuito, estará na verdade disparando um pipeline de múltiplos estágios de Planejar → Agir → Verificar por baixo dos panos.

Se uma verificação falhar (por exemplo, um timeout de API durante um render DOM pesado), ela não mata a auditoria. O loop simplesmente captura a falha no estágio de Verificar, dispara um failover de múltiplos provedores de API por meio do estágio de Reparar e continua sem interrupção. Apenas a folha afetada é tentada novamente.

Foram meses de refatoração — e inúmeras sessões locais com ferramentas como OpenCode e Cline — para acertar a memória vetorial e as condições de parada. Documentamos regularmente essas lições arquiteturais difíceis, incluindo como lidar com prontidão para busca com IA e janelas de contexto, no blog da AuditMe.

Este é o Loop PAOVR aplicado a um crawler de produção real que precisa permanecer confiável sob condições de rede ruidosas e estruturas de página em constante mudança.

15. Um plano de instalação de uma semana

Dia 1

Escreva os três prompts principais (Planejador, Executor, Verificador). Execute-os manualmente em uma tarefa simples de múltiplos passos. Meça onde o modelo tenta pular o Verificar.

Dia 2

Adicione schemas JSON estritos (ou interfaces TypeScript) e um objeto de estado simples. Faça o loop externo se recusar a continuar sem um status válido.

Dia 3

Introduza um verificador externo (testes, verificação de schema ou uma segunda chamada de modelo). Force o sistema a usá-lo.

Dia 4

Adicione disjuntores: máx. de turns, custo, falha idêntica. Teste-os quebrando deliberadamente uma ferramenta.

Dia 5

Implemente o reparo local primeiro. Confirme que uma única folha com falha não destrói o plano inteiro. Opcionalmente, conecte um armazenamento de memória pgvector mínimo para falhas passadas.

Dia 6

Execute uma tarefa real de 20–40 passos. Registre cada observação e verificação. Identifique o estágio de maior atrito.

Dia 7

Escreva o playbook interno de uma página para o seu time. Versionar os prompts e os schemas. Coloque o schema de estado no git.

Ao final da semana, você terá um Loop PAOVR que já é mais confiável do que 90% dos agentes atualmente rodando no mundo real.

16. Checklist para publicar

Antes de chamar qualquer agente de "produção":

• [ ] Toda tarefa tem um done_when explícito
• [ ] Planejador e Executor são separados
• [ ] O estágio de Verificar existe e é independente
• [ ] O reparo é local primeiro
• [ ] Disjuntores são aplicados pelo runtime, não só pelo prompt
• [ ] Observações nunca são inventadas pelo modelo
• [ ] Trabalho concluído é preservado e evidenciado
• [ ] Orçamentos de custo e de turns são visíveis
• [ ] Resultados parciais são retornados em parada antecipada
• [ ] Prompts e schemas são versionados
• [ ] Lições de longo prazo são armazenadas fora da janela de contexto (memória vetorial ou equivalente)

Se alguma caixa não estiver marcada, o agente ainda é uma demo.

17. O que fazer nos próximos 15 minutos

1. Copie o prompt do Planejador para o seu stack de agentes atual.
2. Pegue uma tarefa real que você se importa e force-a a emitir o schema de plano JSON.
3. Escreva um done_when para as três primeiras tarefas-folha que um estranho pudesse verificar.
4. Adicione uma única chamada de Verificar após o primeiro Agir.
5. Execute uma vez e observe a diferença entre narração e evidência.

Essa é toda a diferença entre "normalmente funciona" e "posso confiar quando não estou olhando".

18. Leituras adicionais, pessoas e ferramentas

Artigos fundamentais

• ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022
• Plan-and-Solve Prompting — Wang et al., 2023
• The Prompt Report — ainda é a melhor pesquisa única

Pessoas e prática

• Boris Cherny (Claude Code, Anthropic) — mentalidade de loop primeiro
• Addy Osmani — popularizou a "engenharia de loops"
• Documentação do Agent SDK / Claude Code da Anthropic
• Documentação da OpenAI sobre agentes e Codex

Ferramentas e plataformas que vale a pena acompanhar

• Claude Code / Anthropic Agent SDK
• Cursor, OpenCode, Cline e harnesses modernos de agentes de código
• Model Context Protocol (MCP)
• pgvector + modelos de embedding modernos para memória de agentes
• Next.js App Router e Supabase para a camada de orquestração + estado
• Observabilidade de produção para agentes (custo, turns, taxa de verificação)

Guias relacionados da AuditMe

• Master Prompts em 2026 — a camada de master prompt que este loop envolve
• The Double Life of the RAG Crawler — recuperação agêntica e memória vetorial em produção
• What Actually Makes ChatGPT, Claude, and Perplexity Cite Your Website — como os mecanismos de IA decidem no que confiar
• Generative Engine Optimization: um guia de visibilidade GEO — ser citado por buscadores de IA
• IA no SEO em 2026 — onde pesquisa e loops agênticos se encontram
• Como medir a visibilidade em pesquisa de IA em 2026 — medir a descobribilidade por IA

FAQ

Isso não é só ReAct com passos extras?

ReAct é a intercalação necessária de raciocínio e ação. O Loop PAOVR adiciona planejamento explícito com contratos, verificação independente e reparo controlado. Essas três adições são o que torna o trabalho de horizonte longo confiável.

Ainda preciso de um prompt de sistema forte?

Sim. Os prompts acima são os prompts de sistema. Eles apenas focam em política e contratos em vez de personalidade.

O mesmo modelo pode fazer Planejar, Agir e Verificar?

Pode, mas a confiabilidade cai. Prefira a separação, mesmo que seja o mesmo modelo base com prompts de sistema e temperaturas diferentes.

E os sistemas multi-agente?

O mesmo loop continua valendo. O orquestrador executa o Loop PAOVR externo; agentes especialistas se tornam o estágio de Agir para ferramentas ou domínios específicos.

Como adicionar memória de longo prazo sem explodir o contexto?

Use memória vetorial (pgvector + embeddings) e recupere apenas os poucos fracassos ou sucessos passados relevantes antes de planejar. Mantenha o orçamento de recuperação pequeno.

Como sei quando parar de adicionar estágios?

Quando o agente conseguir concluir uma tarefa de 30 passos, sobreviver a uma falha de ferramenta e retornar resultados parciais verificados sob um orçamento rígido — pare. Complexidade adicional normalmente adiciona mais modos de falha do que remove.

Nota final

Os agentes que ainda estarão rodando em produção em 2027 não são os com o bloco de personalidade mais esperto. São aqueles cujos loops impõem um contrato, exigem evidência, lembram falhas passadas e sabem reparar sem recomeçar.

Construa o Loop PAOVR.

Versionar os contratos.

Verificar tudo.

Dê ao agente uma memória que se acumula.

Então o modelo pode finalmente fazer o que estamos pedindo há três anos: terminar o trabalho.

Escrito para profissionais que entregam. Atualizado para o cenário de agentes de 2026.