El Bucle PAOVR: El Bucle de Agentes Real que de Verdad Termina el Trabajo
Planificar → Actuar → Observar → Verificar → Reparar
Deja de construir agentes que hablan de completar tareas. Empieza a construir sistemas que lo demuestran.
En 2026 la conversación por fin superó "la ingeniería de prompts está muerta".
Lo que la ha sustituido es más silencioso, más difícil y mucho más útil: la ingeniería de bucles (loop engineering).
La mayoría de los agentes siguen fallando de la misma manera. Generan una respuesta final llena de confianza, declaran victoria y dejan que el humano descubra que la mitad del trabajo fue inventada, saltada o nunca comprobada. Todos hemos visto a un agente quemar cinco dólares en tokens solo para alucinar con confianza una llamada API completamente errónea o inventar un resultado de herramienta que nunca existió. El modelo rara vez es ya el problema real. Lo que falta es el contrato.
Esta es una guía de campo para producción del Bucle PAOVR — el único patrón de control que completa de forma consistente trabajo real: Planificar → Actuar → Observar → Verificar → Reparar.
Es la síntesis de ReAct, Plan-and-Solve, el diseño moderno de harness de Anthropic y OpenAI, y las duras lecciones de los equipos que ejecutan agentes en producción en lugar de en demos.
Al terminar tendrás:
- Una anatomía precisa del Bucle PAOVR que sobrevive a tareas de horizonte largo
- Los prompts reales que usamos en producción
- Contratos JSON e interfaces de TypeScript que tanto los agentes como los runtimes pueden consumir
- Stacks de implementación reales de 2026 (Next.js, TypeScript, Supabase, Vercel)
- Patrones de memoria vectorial que convierten a los agentes amnésicos en trabajadores que se acumulan
- Los patrones de fallo que siguen dominando y cómo eliminarlos
- Un plan de instalación de una semana que puedes ejecutar en tu propio stack
Esto no es teoría. Es la diferencia entre un agente que habla de terminar y uno que demuestra que ha terminado.
Prueba AuditMe en vivo — Escaneo instantáneo gratuito
Pega cualquier URL a continuación y obtén una puntuación SEO real en unos 60 segundos. Sin registro: es el mismo motor descrito en este artículo.
Tabla de contenidos
- Por qué la mayoría de los agentes siguen fallando en 2026
- El cambio de la ingeniería de prompts a la ingeniería de bucles
- El Bucle PAOVR: Planificar → Actuar → Observar → Verificar → Reparar
- Etapa 1 — Planificar: deja de pedir a los agentes que piensen. Pídeles que grafiquen
- Etapa 2 — Actuar: ejecución atómica con contratos de herramientas
- Etapa 3 — Observar: anclarse en la realidad
- Etapa 4 — Verificar: el paso que casi todo el mundo se salta
- Etapa 5 — Reparar: recuperación sin empezar desde cero
- Contratos JSON que sobreviven a producción
- Los prompts que realmente usamos en producción
- Ingeniería de contexto dentro del bucle
- Disyuntores, presupuestos y condiciones de parada
- Patrones de fallo que sigo viendo en 2026
- Cómo utilizan este bucle los sistemas de producción reales
- Un plan de instalación de una semana
- Lista de verificación para publicar
- Qué hacer en los próximos 15 minutos
- Lecturas adicionales, personas y herramientas
- Preguntas frecuentes
1. Por qué la mayoría de los agentes siguen fallando en 2026
El modo de fallo ha cambiado.
En 2023–2024 el modelo a menudo simplemente se equivocaba.
En 2026 el modelo suele ser competente en el paso atómico. El sistema falla porque no existe una definición ejecutable de "hecho".
Síntomas típicos:
- El agente produce un plan precioso y luego improvisa la ejecución.
- Marca una tarea como completa porque la última llamada a herramienta devolvió algo.
- Nunca vuelve a comprobar los criterios de éxito originales después de la acción final.
- El contexto crece hasta que el objetivo original queda enterrado bajo el ruido de las herramientas.
- Cuando algo se rompe, el agente reescribe el plan completo en lugar de reparar la hoja rota.
La causa raíz común es siempre la misma: el bucle no tiene una etapa de Verificar con dientes.
ReAct (Yao et al., 2022) nos enseñó a intercalar Pensamiento → Acción → Observación. Eso fue necesario. No fue suficiente para el trabajo de producción de horizonte largo. Plan-and-Solve (Wang et al., 2023) añadió una fase de planificación explícita. Los harness modernos de Anthropic y OpenAI añadieron presupuestos, worktrees y skills. La pieza que aún separa las demos de los sistemas fiables es un control duro de Verificar → Reparar.
Si tu agente no puede responder a la pregunta "¿cómo sé que esto ha terminado?" con evidencia en lugar de narración, no ha terminado.
2. El cambio de la ingeniería de prompts a la ingeniería de bucles
La ingeniería de prompts optimizaba el turno individual.
La ingeniería de bucles optimiza la trayectoria completa. Para la capa de master prompt que este bucle reemplaza, consulta Master Prompts en 2026. Para la capa de master prompt que este bucle reemplaza, consulta Master Prompts en 2026. Para la capa de master prompt que este bucle reemplaza, consulta Master Prompts en 2026.
Las personas que publican agentes fiables en 2026 hablan de cosas diferentes:
- Boris Cherny (Claude Code, Anthropic): "Ya no le doy prompts a Claude. Tengo bucles ejecutándose que le dan prompts a Claude".
- Addy Osmani y la comunidad en general: la ingeniería de bucles como disciplina.
- La propia guía de Anthropic sobre el Agent SDK / Claude Code: reunir contexto → actuar → verificar el trabajo → repetir.
- Los equipos de producción: disyuntores, maxTurns, umbrales de coste, verificadores externos.
La unidad de diseño ya no es "el prompt de sistema perfecto".
Es el bucle de control que mantiene al modelo dentro de un contrato hasta que el contrato se cumple o el presupuesto se agota.
Este artículo trata sobre ese bucle — concretamente, sobre la versión PAOVR.
3. El Bucle PAOVR: Planificar → Actuar → Observar → Verificar → Reparar
Esta es la forma mínima fiable:
PLANIFICAR
↓
ACTUAR (un paso atómico)
↓
OBSERVAR (feedback real de la herramienta / del entorno)
↓
VERIFICAR (contra un done_when explícito)
↓
├─ hecho → siguiente tarea o terminar
└─ no hecho → REPARAR → volver a ACTUAR o re-planificar solo el subárbol afectadoEste es el Bucle PAOVR.
Reglas de diseño clave:
- Una acción atómica por Actuar. Prefiere un máximo de 1–3 llamadas a herramientas.
- Cada tarea tiene un
done_whenclaro. Si no puedes escribirlo, la tarea no está lista. - Verificar es externo o al menos independiente. El mismo modelo que generó el trabajo no debería ser el único juez.
- Reparar es local. No tires todo el plan porque falló una hoja.
- Siempre existen condiciones de parada duras. Límite de iteraciones, límite de coste, fallo idéntico repetido, presupuesto de contexto.
Este es el patrón que sobrevive cuando la tarea requiere 40 pasos en lugar de 4.
4. Etapa 1 — Planificar: deja de pedir a los agentes que piensen. Pídeles que grafiquen
Planificar ya no es "piensa paso a paso".
Es la producción de un grafo ejecutable.
Cómo es un buen plan
- El objetivo se declara como resultado observable
- Supuestos explícitos
- Preguntas de aclaración solo cuando el coste de equivocarse es alto
- Tareas a nivel de hoja (realizables en 1–3 llamadas a herramientas)
- Dependencias declaradas
- Cada tarea tiene una cadena de
done_whenque un verificador posterior pueda comprobar - Riesgos listados
El prompt de planificador que realmente usamos
Actúa como el Planificador de Tareas. No ejecutas. Solo produces un plan ejecutable.
Reglas:
1. Divide el objetivo en pasos atómicos.
2. Un paso = una acción o un grupo muy relacionado de llamadas a herramientas (máx. 3).
3. Declara las dependencias con IDs de tarea.
4. Cada paso debe tener un done_when claro que pueda verificarse más tarde.
5. Si falta información crítica, lista supuestos y clarifying_questions. No inventes hechos.
6. Produce solo JSON estricto. Nada de ensayos en prosa.
Devuelve exactamente 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": "condición observable que demuestra que está completo"
}
],
"risks": ["string"]
}Este planificador es deliberadamente torpe en cuanto a la ejecución. Ese es el punto. La separación de responsabilidades es lo que mantiene el sistema depurable.
5. Etapa 2 — Actuar: ejecución atómica con contratos de herramientas
El Ejecutor recibe una tarea, el estado actual del plan y las observaciones anteriores. Tiene prohibido adelantarse.
Prompt del ejecutor
Actúa como el Agente Ejecutor.
Toma exactamente una próxima tarea del plan. No te adelantes. No inventes datos que falten.
Entradas que recibirás:
- plan JSON
- current_task_id
- resultados / observaciones de herramientas anteriores (si los hay)
Método:
1. Vuelve a leer el done_when de la tarea actual.
2. Si estás bloqueado por falta de datos, solicita la herramienta más barata o marca el estado como blocked.
3. Realiza la acción útil más pequeña que haga avanzar la tarea.
4. Devuelve solo salida estructurada:
## Acción
(lo que hiciste)
## Evidencia
(resultado bruto de la herramienta u observación — nunca reescribas la verdad para que parezca otra cosa)
## Estado
done | partial | blocked
## Riesgos residuales
(cualquier riesgo nuevo introducido)
## Próxima recomendación
(solo si el estado no es done)El Ejecutor nunca decide que el objetivo global está terminado. Esa decisión pertenece al bucle exterior después de la verificación.
6. Etapa 3 — Observar: anclarse en la realidad
La observación es el único lugar donde al modelo se le permite ver el mundo real.
Reglas que siguen importando en 2026:
- Nunca dejes que el modelo invente la salida de una herramienta. El runtime la proporciona.
- Prefiere respuestas de herramienta estructuradas a texto libre cuando sea posible.
- Mantén la ventana de observación pequeña y de alta señal. La pudrición de contexto es real.
- Registra cada observación con una marca de tiempo y el nombre de la herramienta. Lo necesitarás para depurar.
Esta es la etapa que convierte a ReAct de un prompt ingenioso en un sistema de control fiable.
7. Etapa 4 — Verificar: el paso que casi todo el mundo se salta
La verificación es la diferencia entre un agente que afirma el éxito y uno que lo demuestra.
Qué significa realmente "hecho"
Una tarea está hecha solo cuando su done_when es verdadero y la evidencia respalda esa afirmación.
El verificador debería ser preferiblemente:
- Una llamada de modelo separada con un prompt de sistema diferente, o
- Un comprobador externo (pruebas, linter, validador de esquemas, puntuación SEO, revisión humana), o
- Una función determinista cuando el dominio lo permita.
Prompt del verificador
Actúa como el Verificador. No generas trabajo nuevo. Solo juzgas si la tarea actual está completa.
Recibes:
- la tarea original (incluido el done_when)
- la acción realizada
- la evidencia / observación
- cualquier resultado afirmado
Reglas:
1. Cita el done_when.
2. Decide: satisfied | not_satisfied | insufficient_evidence.
3. Si es not_satisfied, nombra la única comprobación o reparación siguiente más barata.
4. Nunca aceptes narración como prueba. Exige evidencia.
5. Produce JSON estricto:
{
"task_id": "...",
"done_when": "...",
"verdict": "satisfied|not_satisfied|insufficient_evidence",
"evidence_summary": "una o dos frases",
"missing": ["lo que todavía se requiere"],
"recommended_repair": "la siguiente acción más pequeña o null"
}Esta es la etapa que impide la mentira cortés.
8. Etapa 5 — Reparar: recuperación sin empezar desde cero
Cuando Verificar devuelve not_satisfied, el sistema tiene dos opciones limpias:
- Reparación local — volver a ejecutar o ajustar solo la hoja que falló.
- Re-planificación del subárbol — solo cuando las propias dependencias han cambiado.
Nunca tires el plan entero porque falló un paso. Así es como los agentes desperdician tokens y pierden confianza.
Regla de reparación que ahorra horas:
Si el Estado es partial o blocked o Verificar dice not_satisfied:
1. Nombra el bloqueador en una frase.
2. Propón la comprobación o acción siguiente más barata.
3. No reescribas todo el plan a menos que las dependencias anteriores realmente hayan cambiado.
4. Conserva cada tarea completada y su evidencia.9. Contratos JSON que sobreviven a producción
El texto libre está bien para los humanos. Los agentes necesitan esquemas.
Este es un esquema de plan mínimo listo para producción y el registro de ejecución correspondiente:
{
"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
}
}En TypeScript esto se mapea limpiamente a interfaces que tanto el compilador como el runtime aplican:
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;
};
}Estas interfaces se convierten en la fuente única de verdad entre tu orquestador, las funciones edge y la capa de logging.
10. Los prompts que realmente usamos en producción
Ya tienes los tres centrales (Planificador, Ejecutor, Verificador).
Aquí está el controlador del bucle exterior que los une:
Actúa como el Controlador del Bucle. Posees la trayectoria completa.
Tu única tarea:
1. Cargar o crear el plan.
2. Seleccionar la siguiente tarea lista (dependencias satisfechas, estado no done).
3. Entregársela al Ejecutor.
4. Alimentar al Verificador con el resultado.
5. Cuando esté satisfied → marcar como hecha y continuar.
6. Cuando esté not_satisfied → disparar Reparar (local primero).
7. Aplicar los disyuntores antes de cada nuevo turno.
8. Cuando todas las tareas estén verificadas como hechas, emitir el resultado final + riesgos residuales.
9. Nunca inventar que algo está completo.
Háblas solo con actualizaciones de estado estructuradas y estado JSON.Estos cuatro prompts forman un esqueleto completo y desplegable del Bucle PAOVR. Mánténlos versionados en git igual que versionas cualquier otra configuración crítica.
11. Ingeniería de contexto dentro del bucle
El contexto es un recurso finito. En ejecuciones largas se convierte en el modo de fallo principal.
Reglas prácticas que siguen vigentes:
- Mantén la política maestra (rol, restricciones, contrato de salida) estable y en caché.
- Dale al Ejecutor solo la tarea actual + observaciones recientes + el done_when original.
- Resume o descarga las tareas completadas en lugar de reproducir todo el historial.
- Prefiere el contexto fresco para los trabajadores de ejecución pura y el contexto acumulado solo para el planificador/orquestador.
- Mide el llenado del contexto. Cuando supere ~60–70 % de la ventana útil, fuerza un paso de compresión o de checkpoint.
Por eso los mejores sistemas de 2026 tratan el sistema de archivos, git y la memoria externa como herramientas de contexto de primera clase en lugar de volcarlo todo en el prompt. Documentamos la arquitectura de recuperación agéntica que sustenta este patrón en La doble vida del RAG Crawler. Documentamos la arquitectura de recuperación agéntica que sustenta este patrón en La doble vida del RAG Crawler. Documentamos la arquitectura de recuperación agéntica que sustenta este patrón en La doble vida del RAG Crawler.
La memoria vectorial como ciudadana de primera clase
Las ventanas de contexto son grandes, pero volcar todo en ellas destruye la atención. Los agentes de producción en 2026 usan arquitecturas de memoria externa.
Un patrón práctico:
- Tras cada tarea completada (o fallida), inserta un resumen estructurado breve de lo que ocurrió, la evidencia y el resultado.
- Guarda esos embeddings en un almacén vectorial. pgvector es la opción por defecto de muchos equipos porque vive junto al estado relacional.
- Antes de la etapa de Planificar de una nueva ejecución, el orquestador realiza una micro-recuperación RAG contra las ejecuciones históricas del propio agente.
- Las restricciones recuperadas se inyectan en el contexto del Planificador como lecciones duras ("los intentos anteriores fallaron cuando el selector del shadow-DOM agotó el tiempo; prefiere la ruta data-testid").
El efecto es acumulativo. Un agente que fracasó al interactuar con un elemento de UI concreto cientos de veces en sesiones pasadas ya no tiene que redescubrir el modo de fallo. La memoria convierte a un amnésico brillante en un trabajador que de verdad mejora.
Acompaña los embeddings con un modelo de text-embedding rápido y de alta calidad. Los modelos de text-embedding de Gemini son una elección habitual en 2026 por el equilibrio coste/calidad. Mantén el presupuesto de recuperación minúsculo — normalmente los 3–5 fallos o éxitos pasados más relevantes son suficientes. Cualquier cosa más reintroduce la pudrición de contexto bajo otro nombre.
12. Disyuntores, presupuestos y condiciones de parada
Un bucle sin paradas duras es un pasivo.
Conjunto mínimo:
| Señal | Ajuste típico | Aplicación |
|---|---|---|
| Máx. turnos / iteraciones | 20–60 según la tarea | Runtime |
| Máx. coste (USD o tokens) | Presupuesto específico de la tarea | Runtime |
| Racha de fallos idénticos | 2–3 | Instrucción + runtime |
| Presupuesto de contexto | 70 % de la ventana útil | Instrucción |
| Tiempo máximo (wall-clock) | Opcional | Runtime |
Cuando se dispara un disyuntor, el agente debe:
- Detener nuevas acciones.
- Devolver los resultados parciales que ya estaban verificados.
- Indicar claramente qué provocó la parada y qué queda abierto.
- Escalar si existe un gate humano.
El trabajo parcial verificado siempre vale más que una alucinación segura de sí misma.
13. Patrones de fallo que sigo viendo en 2026
- Completado narrado — el modelo dice "hecho" sin evidencia.
Solución: una etapa de Verificar dura con juicio externo o independiente.
- Un plan que en realidad es una novela — tareas que aún requieren un breve ensayo de instrucciones.
Solución: sigue dividiendo hasta que cada hoja sean 1–3 llamadas a herramientas.
- Pudrición de contexto — el objetivo original enterrado bajo 30 observaciones de herramientas.
Solución: poda agresiva + contexto de orquestador separado + memoria vectorial para lecciones a largo plazo.
- Reparar mediante reescritura total — un fallo hace que el agente lo descarte todo.
Solución: regla de reparación local primero.
- done_when ausente — "hazlo bien" u "optimiza la página".
Solución: rechaza aceptar una tarea sin una condición de finalización observable.
- Alucinación de herramientas — el modelo inventa resultados de herramientas.
Solución: el runtime siempre suministra la Observación; al modelo nunca se le permite generarla.
- Bucles corteses infinitos — el agente sigue "probando una cosa más".
Solución: disyuntores con detección de fallos idénticos.
Estos siete siguen representando la mayoría del dolor en producción.
14. Cómo utilizan este bucle los sistemas de producción reales
El patrón aparece (con nombres diferentes) en los sistemas que de verdad se publican:
- Claude Code y el Anthropic Agent SDK — reunir → actuar → verificar → repetir, con tipos de bucle explícitos y condiciones de parada.
- Los agentes de código que tratan la suite de pruebas como verificador.
- Los agentes de investigación que fuerzan un paso de verificación contra las fuentes antes de afirmar un dato.
- Los pipelines de contenido y SEO que ejecutan un control de calidad después de la generación.
La capa de implementación de 2026
La teoría se mapea directamente a los stacks modernos. No necesitas un backend de Python monolítico y enorme para ejecutar este bucle limpiamente.
Una arquitectura común de alto apalancamiento en 2026:
- Orquestación: Next.js App Router (o una capa ligera de server components) posee el Controlador del Bucle. Las interfaces de TypeScript estrictas aplican los contratos JSON en tiempo de compilación.
- Estado y logs: Supabase (Postgres + pgvector) almacena el estado de la ejecución, el historial de tareas y la memoria vectorial de ejecuciones pasadas.
- Ejecución: las funciones serverless / edge en Vercel gestionan los pasos Actuar individuales. Esto mantiene la superficie pequeña y los cold starts aceptables.
- Superficie de herramientas: muchos equipos estandarizan en el Model Context Protocol (MCP) para que los agentes hablen con las herramientas de forma coherente.
- Desarrollo local y agentes de código: la misma filosofía impulsa las sesiones avanzadas de refactorización en herramientas como OpenCode y Cline. No solo escriben código; observan la salida del terminal, verifican contra el linter y la suite de pruebas, y reparan localmente sin borrar el archivo entero.
La idea clave es que el Bucle PAOVR es agnóstico al lenguaje. Una vez que tienes contratos tipados y un almacén de estado fiable, la misma forma funciona para agentes de código, agentes de investigación y crawlers específicos de dominio.
Caso práctico: sobrevivir al caos del web crawling
Veamos un entorno de producción real de 2026. Al construir el pipeline de crawlers para la plataforma de SEO con IA AuditMe, la peor pesadilla no era parsear HTML — era la pura imprevisibilidad de la web. Los sitios agotan el tiempo de espera, los DOM cambian, las páginas con mucho JavaScript se renderizan de forma diferente cada vez, y los scripts lineales estándar se rompen constantemente.
Para arreglarlo, todo el motor de auditoría se reescribió alrededor del Bucle PAOVR. En lugar de un script monolítico, el sistema usa Next.js App Router y Supabase para orquestar tareas atómicas. Por ejemplo, si pasas una URL por el Website SEO Checker gratuito, en realidad estás disparando un pipeline de varias etapas Planificar → Actuar → Verificar por debajo.
Si una comprobación falla (por ejemplo, un timeout de la API durante un render DOM pesado), no mata la auditoría. El bucle simplemente captura el fallo en la etapa de Verificar, dispara un failover de proveedores múltiples de API a través de la etapa de Reparar, y continúa sin problemas. Solo se reintenta la hoja afectada.
Llevó meses de refactorización — y un sinfín de sesiones locales con herramientas como OpenCode y Cline — conseguir la memoria vectorial y las condiciones de parada correctas. Documentamos regularmente estas duras lecciones arquitectónicas, incluido cómo manejar la preparación para la búsqueda con IA y las ventanas de contexto, en el blog de AuditMe.
Este es el Bucle PAOVR aplicado a un crawler de producción real que debe mantenerse fiable bajo condiciones de red ruidosas y estructuras de página que cambian constantemente.
15. Un plan de instalación de una semana
Día 1
Escribe los tres prompts centrales (Planificador, Ejecutor, Verificador). Ejecútalos manualmente en una tarea simple de varios pasos. Mide dónde intenta el modelo saltarse Verificar.
Día 2
Añade esquemas JSON estrictos (o interfaces de TypeScript) y un objeto de estado simple. Haz que el bucle exterior se niegue a continuar sin un estado válido.
Día 3
Introduce un verificador externo (pruebas, comprobación de esquema o una segunda llamada de modelo). Obliga al sistema a usarlo.
Día 4
Añade disyuntores: máx. turnos, coste, fallo idéntico. Pruébalos rompiendo deliberadamente una herramienta.
Día 5
Implementa la Reparación local primero. Confirma que una sola hoja fallida no destruye todo el plan. Opcionalmente, conecta un almacén de memoria pgvector mínimo para los fallos pasados.
Día 6
Ejecuta una tarea real de 20–40 pasos. Registra cada observación y verificación. Identifica la etapa de mayor fricción.
Día 7
Escribe el playbook interno de una página para tu equipo. Versiona los prompts y los esquemas. Mete el esquema de estado en git.
Al final de la semana tendrás un Bucle PAOVR que ya es más fiable que el 90 % de los agentes que corren actualmente en el mundo real.
16. Lista de verificación para publicar
Antes de llamar a cualquier agente "producción":
- [ ] Cada tarea tiene un
done_whenexplícito - [ ] Planificador y Ejecutor están separados
- [ ] La etapa de Verificar existe y es independiente
- [ ] La Reparación es local primero
- [ ] Los disyuntores los aplica el runtime, no solo el prompt
- [ ] Las observaciones nunca las inventa el modelo
- [ ] El trabajo completado se conserva y aporta evidencia
- [ ] Los presupuestos de coste y de turnos son visibles
- [ ] Los resultados parciales se devuelven en una parada temprana
- [ ] Los prompts y los esquemas están versionados
- [ ] Las lecciones a largo plazo se guardan fuera de la ventana de contexto (memoria vectorial o equivalente)
Si alguna casilla no está marcada, el agente sigue siendo una demo.
17. Qué hacer en los próximos 15 minutos
- Copia el prompt del Planificador en tu stack de agentes actual.
- Toma una tarea real que te importe y oblígala a emitir el esquema de plan JSON.
- Escribe un
done_whenpara las tres primeras tareas hoja que un desconocido pudiera verificar. - Añade una única llamada de Verificar después del primer Actuar.
- Ejecútalo una vez y mira la diferencia entre narración y evidencia.
Esa es toda la diferencia entre "normalmente funciona" y "puedo fiarme de él cuando no estoy mirando".
18. Lecturas adicionales, personas y herramientas
Artículos fundamentales
- ReAct: Synergizing Reasoning and Acting in Language Models — Yao et al., 2022
- Plan-and-Solve Prompting — Wang et al., 2023
- The Prompt Report — sigue siendo la mejor encuesta única
Personas y práctica
- Boris Cherny (Claude Code, Anthropic) — mentalidad de bucle primero
- Addy Osmani — popularizó la "ingeniería de bucles"
- Documentación del Agent SDK / Claude Code de Anthropic
- Documentación de OpenAI sobre agentes y Codex
Herramientas y plataformas que vale la pena seguir
- Claude Code / Anthropic Agent SDK
- Cursor, OpenCode, Cline y los harness modernos de agentes de código
- Model Context Protocol (MCP)
- pgvector + modelos de embedding modernos para la memoria del agente
- Next.js App Router y Supabase para la capa de orquestación + estado
- Observabilidad de producción para agentes (coste, turnos, tasa de verificación)
Guías relacionadas de AuditMe
- Master Prompts en 2026 — la capa de master prompt que envuelve este bucle
- La doble vida del RAG Crawler — recuperación agéntica y memoria vectorial en producción
- Qué hace que ChatGPT, Claude y Perplexity citen tu sitio web — cómo deciden los motores de IA qué confiar
- Generative Engine Optimization: una guía de visibilidad GEO — conseguir que los buscadores de IA te citen
- IA en el SEO en 2026 — dónde se encuentran la búsqueda y los bucles agénticos
- Cómo medir la visibilidad en búsquedas de IA en 2026 — medir la descubribilidad por IA
Guías relacionadas de AuditMe
- Master Prompts en 2026 — la capa de master prompt que envuelve este bucle
- La doble vida del RAG Crawler — recuperación agéntica y memoria vectorial en producción
- Qué hace que ChatGPT, Claude y Perplexity citen tu sitio web — cómo deciden los motores de IA qué confiar
- Generative Engine Optimization: una guía de visibilidad GEO — conseguir que los buscadores de IA te citen
- IA en el SEO en 2026 — dónde se encuentran la búsqueda y los bucles agénticos
- Cómo medir la visibilidad en búsquedas de IA en 2026 — medir la descubribilidad por IA
Guías relacionadas de AuditMe
- Master Prompts en 2026 — la capa de master prompt que envuelve este bucle
- La doble vida del RAG Crawler — recuperación agéntica y memoria vectorial en producción
- Qué hace que ChatGPT, Claude y Perplexity citen tu sitio web — cómo deciden los motores de IA qué confiar
- Generative Engine Optimization: una guía de visibilidad GEO — conseguir que los buscadores de IA te citen
- IA en el SEO en 2026 — dónde se encuentran la búsqueda y los bucles agénticos
- Cómo medir la visibilidad en búsquedas de IA en 2026 — medir la descubribilidad por IA
FAQ
¿No es esto ReAct con pasos extra?
ReAct es la intercalación necesaria de razonamiento y acción. El Bucle PAOVR añade planificación explícita con contratos, verificación independiente y reparación controlada. Esas tres adiciones son las que hacen fiable el trabajo de horizonte largo.
¿Todavía necesito un buen prompt de sistema?
Sí. Los prompts anteriores son los prompts de sistema. Solo que se centran en la política y los contratos en lugar de en la personalidad.
¿Puede el mismo modelo hacer Planificar, Actuar y Verificar?
Puede, pero la fiabilidad baja. Prefiere la separación, aunque sea el mismo modelo base con prompts de sistema y temperaturas diferentes.
¿Y los sistemas multi-agente?
El mismo bucle sigue aplicándose. El orquestador ejecuta el Bucle PAOVR exterior; los agentes especialistas se convierten en la etapa de Actuar para herramientas o dominios concretos.
¿Cómo añado memoria a largo plazo sin explotar el contexto?
Usa memoria vectorial (pgvector + embeddings) y recupera solo los pocos fallos o éxitos relevantes antes de planificar. Mantén el presupuesto de recuperación minúsculo.
¿Cómo sé cuándo dejar de añadir etapas?
Cuando el agente pueda terminar una tarea de 30 pasos, sobrevivir a un fallo de herramienta y devolver resultados parciales verificados bajo un presupuesto duro — para. Más complejidad suele añadir más modos de fallo de los que elimina.
Nota final
Los agentes que seguirán corriendo en producción en 2027 no son los que tienen el bloque de personalidad más listo. Son los que tienen bucles que aplican un contrato, exigen evidencia, recuerdan sus fallos pasados y saben reparar sin empezar de cero.
Construye el Bucle PAOVR.
Versiona los contratos.
Verifica todo.
Dale al agente una memoria que se acumule.
Entonces el modelo podrá por fin hacer lo que le llevamos pidiendo tres años: terminar el trabajo.
Escrito para practicantes que publican. Actualizado para el panorama de agentes de 2026.
Eduard Tymchenko
SEO Expert & Founder of AuditMe
Seasoned SEO & SMM expert with 10+ years of experience. Built AuditMe to help businesses improve their search rankings through data-driven, results-oriented SEO strategies. Specializes in technical SEO, Core Web Vitals, and WordPress optimization.
Ejecuta tu auditoría SEO gratuita
Obtén un análisis SEO completo de cualquier URL en 60 segundos. Sin registro.
O abre el analizador completo con más detalles
Analiza tu sitio gratisHerramientas SEO gratuitas
Artículos relacionados
Continúa aprendiendo con estas guías y tutoriales de SEO:
Master Prompts in 2026: Stop Prompting Like It's 2023
Production guide to master prompts, LLM orchestration, agent loops, and prompt engineering for production — with JSON contracts, verification, RAG-aware context, and eval that survives model swaps.
25 min read
The New SEO: When Search Engines Stop Reading Websites and Start Using Them
Search is moving from ranking pages to running them as machine interfaces. This guide explains the six-dimension Website Intelligence framework — discoverability, understanding, verification, actionability, reliability, and observability — that makes your site machine-readable, verifiable, and actionable for AI search engines and agents.
23 min read
How to Track AI Search Visibility in 2026: The Complete GEO Measurement Guide
Measure your brand's visibility in AI answers with the 12-query method, citation-rate benchmarks, a 15-minute weekly routine, and an honest GEO tool comparison — updated September 2026.
18 min read
The Double Life of the RAG Crawler: Building Knowledge Engines and Defending Them in 2026
Build RAG crawlers that don't rot — and defend knowledge bases from graph-guided extraction attacks like RAGCrawler. Architecture, tooling, failures, and a security playbook for 2026.
25 min read