El 95% de los AI Agents No Planifican — Improvisan. y No es Culpa del Modelo
El 95% de los AI Agents improvisan en lugar de planificar. Aprende el framework de Descomposición Reflexiva con Validación para construir agentes que razonan de verdad.
El 95% de los AI Agents que Ves en Producción No Están Planificando — Están Improvisando
Y no, el problema no es que GPT-4 no sea lo suficientemente inteligente.
*El problema es que le estás pidiendo que actúe antes de pensar y confías en que "razonar paso a paso" sea suficiente. *
La industria asume que el cuello de botella de la planificación en agentes se resolverá con modelos más grandes. GPT-5. Claude 4. Llama 4. Más parámetros. Más contexto. Más inteligencia.
El dato real es otro: el 95% de los AI Agents fallan en planificación no por límites de capacidad del modelo, sino por una arquitectura de prompting pobre. Específicamente, la ausencia de bucles deliberativos con verificación.
Mejorar el modelo sin mejorar el bucle deliberativo es como poner un motor Ferrari en un coche sin volante.
---
La Gran Mentira del Chain-of-Thought
Cuando Wei et al. introdujeron el chain-of-thought (CoT) en 2022, fue un avance enorme. Pedirle al modelo que "piense paso a paso" mejoraba el razonamiento en tareas matemáticas, lógicas y de sentido común.
La comunidad lo adoptó como la solución única para el razonamiento de agentes.
*Aquí está lo que casi nadie dice: CoT es una técnica de generación de texto. El modelo produce tokens que "parecen" razonamiento, pero no hay ninguna garantía de corrección interna. *
Un modelo con CoT puede generar un plan perfectamente estructurado que sea conceptualmente erróneo. Y como no hay verificación, el agente ejecuta el error con toda la confianza del mundo.
Mira este ejemplo. Un agente reactivo frente a un goal ambiguo como "organiza mi bandeja de entrada":
❌ Agente reactivo (sin CoT):
```python
def handle_goal(goal: str):
Salta directamente a la acción
emails = fetch_emails()
for email in emails:
archive(email) # Archiva todo sin criterio
return "Bandeja organizada"
```
Resultado: archiva correos importantes junto con spam. El usuario pierde una factura crítica.
✅ Agente con CoT (mejor, pero insuficiente):
```python
def handle_goal(goal: str):
Pide al modelo que razone
plan = llm.invoke(f"Goal: {goal}. Think step by step to create a plan.")
Ejecuta el plan sin validación
for step in plan.steps:
execute(step)
return "Plan ejecutado"
```
Resultado: el plan parece razonable, pero puede contener pasos inviables (e.g., "conecta con la API de Gmail que no existe"). El agente ejecuta y falla en el paso 3.
El CoT mejora el formato del razonamiento, pero no su corrección.
---
La Evidencia: Por Qué CoT Solo No Es Suficiente
Los datos del análisis de sistemas multi-agente en producción muestran algo inquietante:
El 90% de las implementaciones actuales son un solo agente mal configurado.
Cuando se añaden más agentes sin una capa de orquestación deliberativa, el ruido se multiplica.
3 agentes mal coordinados producen peores resultados que 1 agente bien diseñado.
¿Por qué? Porque cada agente actúa sin verificar si su plan es compatible con los planes de los demás. Y sin un paso de validación interno, ni siquiera verifican sus propios planes.
La analogía con la ingeniería de software es directa:
> Nadie despliega código sin tests. Un agente que ejecuta un plan sin verificarlo es como hacer deploy a producción sin pasar por CI/CD.
El paso de validación en el bucle deliberativo es el test unitario del plan: verifica que cada sub-objetivo tiene sentido antes de ejecutarlo. Y la reflexión post-ejecución es el test de integración: confirma que el paso completado realmente contribuye al goal general.
---
El Framework: Descomposición Reflexiva con Validación
Después de probar esta arquitectura en producción para agentes que gestionan bandejas de entrada, modifican bases de datos y escriben código, el patrón que funciona no es complicado. Es estructurado.
Lo llamo la Descomposición Reflexiva con Validación, y consta de 5 pasos:
Paso 1: Descomposición Forzada
Ante cualquier goal ambiguo, el agente debe explícitamente generar una lista estructurada de sub-objetivos antes de cualquier acción.
La clave: no es un prompt "blando" ("piensa paso a paso"). Es una estructura rígida con validación programática.
```python
from pydantic import BaseModel, Field, validator
from typing import List
from instructor import from_openai
import openai
Forzamos al modelo a generar un plan con estructura validable
client = from_openai(openai.OpenAI())
class SubGoal(BaseModel):
id: str = Field(description="Identificador único del sub-objetivo")
description: str = Field(description="Qué hay que hacer exactamente")
dependencies: List[str] = Field(default_factory=list,
description="IDs de sub-objetivos que deben completarse primero")
success_criteria: str = Field(description="¿Cómo sabemos que este paso está completo?")
requires_tool: str = Field(description="¿Qué herramienta o API necesita?")
@validator('requires_tool')
def tool_must_exist(cls, v):
available_tools = ['gmail_api', 'sendgrid_api', 'database', 'filesystem']
if v not in available_tools:
raise ValueError(f'Tool {v} no disponible. Usa: {available_tools}')
return v
class ReflexivePlan(BaseModel):
goal_original: str
sub_goals: List[SubGoal] = Field(min_items=1, max_items=10)
@validator('sub_goals')
def no_circular_dependencies(cls, v):
for sg in v:
for dep_id in sg.dependencies:
if dep_id == sg.id:
raise ValueError(f'Dependencia circular detectada en {sg.id}')
return v
def decompose_goal(ambiguous_goal: str) -> ReflexivePlan:
plan = client.chat.completions.create(
model="gpt-4o",
response_model=ReflexivePlan,
messages=[{
"role": "system",
"content": "Descompón el goal del usuario en sub-objetivos ejecutables. "
"Cada sub-objetivo debe ser atómico, medible y realizable con las herramientas disponibles."
}, {
"role": "user",
"content": f"Goal: {ambiguous_goal}"
}]
)
return plan
```
Si el modelo intenta generar un paso que requiere una herramienta que no existe, el validador de Pydantic lo rechaza. El plan no se acepta hasta que pasa todas las validaciones.
Paso 2: Validación Cruzada de Cada Sub-Paso
Cada sub-objetivo generado debe pasar un test de verificación antes de marcar como "ready":
1. ¿Es alcanzable con las herramientas disponibles? → Validación programática contra el inventario de tools.
2. ¿Tiene una salida medible? → El campo `success_criteria` debe ser verificable (e.g., "archivar 10 emails" sí, "mejorar la bandeja" no).
3. ¿Depende de algún paso anterior? → El grafo de dependencias debe ser acíclico y completo.
Si falla, se re-planifica. No se ejecuta nada hasta que el plan completo esté validado.
Paso 3: Ejecución con Punto de Control Reflexivo
Después de cada sub-acción ejecutada, el agente debe detenerse y reflexionar:
```python
def execute_with_reflection(plan: ReflexivePlan):
executed = set()
while len(executed) < len(plan.sub_goals):
Busca sub-objetivos cuyas dependencias estén satisfechas
ready = [sg for sg in plan.sub_goals
if sg.id not in executed and all(d in executed for d in sg.dependencies)]
for sub_goal in ready:
result = execute_sub_goal(sub_goal)
PUNTO DE CONTROL REFLEXIVO
reflection = llm.invoke(
f"Acabo de ejecutar '{sub_goal.description}'. "
f"Resultado: {result}. "
f"Goal original: '{plan.goal_original}'. "
f"¿Me acerca al goal? ¿Necesito ajustar los pasos restantes? "
f"Responde solo 'PROCEED' o 'REPLAN'."
)
if reflection.strip() == 'REPLAN':
print(f"[REFLEXIÓN] Replanificando desde {sub_goal.id}...")
return decompose_goal(plan.goal_original)
executed.add(sub_goal.id)
return "Plan completado"
```
Paso 4: Bucle de Retroalimentación
Si la reflexión detecta desviación, el agente regresa al paso 1 (re-descomposición del goal) en lugar de continuar ciegamente con el plan original.
Este es el punto crítico que diferencia una arquitectura deliberativa de una secuencia de acciones. La mayoría de los agentes, ante un resultado inesperado, intentan continuar con el plan original. Un agente con Descomposición Reflexiva reconoce que el plan inicial estaba basado en suposiciones incorrectas y genera uno nuevo.
Paso 5: Logging de la Cadena Deliberativa
Guardar todo el proceso como artefacto para depuración:
```python
class DeliberationLog(BaseModel):
timestamp: str
goal_original: str
plan_generated: ReflexivePlan
validations: List[dict] # Resultado de cada validación
execution_steps: List[dict] # timestamp, sub_goal_id, resultado, decisión
final_outcome: str
Estructura de cada paso de ejecución para el log
{
"timestamp": "2026-07-29T10:30:00Z",
"sub_goal_id": "SG-001",
"action": "fetch_emails",
"validation_result": "PASS",
"reflection_outcome": "PROCEED",
"tool_used": "gmail_api"
}
```
Esto no es opcional. Sin logging deliberativo, no puedes depurar por qué tu agente tomó una decisión equivocada. Y sin depuración, no puedes mejorar el prompting del sistema.
---
El Coste Real de No Validar
La objeción más común: "Añadir un paso de verificación aumenta la latencia y el coste de cada llamada al LLM."
Es una objeción válida... si ignoras el coste real.
> El coste real no es el de una llamada extra de validación. Es el de ejecutar un plan incorrecto durante 10 pasos antes de detectar el error.
Una validación al inicio (1 llamada extra) es órdenes de magnitud más barata que 9 pasos de ejecución inútil.
| Enfoque | Llamadas al LLM | Tasa de error en goals ambiguos | Pasos ejecutados antes de detectar error |
|---|---|---|---|
| Reactivo | 1 | ~80% | 0 (nunca detecta) |
| CoT simple | 3-5 | ~60% | 3-4 |
| CoT + validación | 4-6 | ~25% | 0-1 |
| Descomposición Reflexiva | 5-8 | ~10% | 0 (valida antes) |
Los números son estimaciones basadas en pruebas internas con goals del mundo real ("organiza mi bandeja de entrada", "mejora el SEO del blog", "analiza estos 1000 leads y priorízalos"). La reducción de error es lo suficientemente grande para que la latencia extra sea irrelevante.
---
"Esto es Solo Prompt Engineering, No una Arquitectura Real"
Esta objeción revela exactamente el problema que este artículo busca señalar.
*La arquitectura de prompting ES la arquitectura del agente. No hay "agente" sin prompting. *
El modelo es solo un motor de inferencia. Decidir cómo y cuándo el modelo genera texto, qué estructura debe seguir, y cómo se validan sus salidas, ES el diseño del sistema.
Mira este ejemplo. El mismo modelo, el mismo goal, dos resultados drásticamente diferentes según la arquitectura de prompting:
```python
Enfoque A: "Prompt blando"
response = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Organiza mi bandeja de entrada. Piensa paso a paso."}]
)
Output: un párrafo de texto con un plan vago que el agente no puede ejecutar
Enfoque B: Descomposición Reflexiva con Validación
plan = decompose_goal("Organiza mi bandeja de entrada")
Output: un array de sub-objetivos con validaciones, dependencias y criterios de éxito
El agente tiene un plan ejecutable, no una sugerencia
```
El modelo es el mismo. La diferencia es la arquitectura.
---
Herramientas para Implementarlo en Producción
Si quieres llevar este patrón a producción hoy:
LangChain → Para la orquestación del flujo deliberativo (el bucle entre descomposición, validación, ejecución, reflexión).
Instructor o Outlines → Para forzar structured output del plan. Sin esto, el modelo puede desviarse del formato esperado.
Pydantic → Para definir esquemas de validación de los sub-objetivos con validadores personalizados.
LangSmith o MLflow → Para el logging deliberativo. Rastrear toda la cadena de pensamiento como trazas es esencial para depurar decisiones equivocadas.
El stack no es exótico. Son herramientas que ya usas. La diferencia es cómo las conectas.
---
Lo Que Construirás en 2026
El AI Agent que construyas este año no será mejor porque uses un modelo más grande.
Será mejor porque diseñes un sistema que obligue al modelo a pensar, validar y reflexionar antes de actuar.
La Descomposición Reflexiva con Validación no es teoría. Es un patrón que he probado en producción para agentes que gestionan leads, escriben informes SEO y modifican bases de datos. Funciona porque replica lo que un humano haría ante un goal ambiguo: desglosar, verificar cada paso, ejecutar con cautela, y replanificar cuando algo no cuadra.
*El modelo no necesita ser más inteligente. Necesita una arquitectura que no le deje actuar como un idiota. *
Construye eso, y tu agente hará lo que el 95% no sabe hacer: planificar de verdad.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF