Por Qué El 90% de los AI Agents Se Rompen en Producción y Cómo Arreglarlo
El 90% de los AI Agents en producción son scripts con un LLM dentro. Aprende la arquitectura de 5 capas que realmente funciona.
El 90% de los AI Agents en Producción Son Scripts de Python con un LLM Encima
Todo el mundo construye agents. Nadie los opera en producción con confianza.
La industria os dice que los AI agents van a revolucionar vuestras operaciones. Que pronto tendréis sistemas autónomos que gestionan vuestra startup, responden tickets, escriben código, y toman decisiones sin vosotros. La realidad es otra.
*Los AI agents hoy son bucles while con un LLM dentro. Y después de 5 iteraciones, el acierto cae por debajo del 50%.*
No lo digo yo. Lo dice la arquitectura de los frameworks más populares, las limitaciones del patrón ReAct, y el hecho de que cada demo que veis funciona — hasta que llegáis al paso 4.
El Problema No Es la Inteligencia. Es la Arquitectura
La creencia popular dice: "Si el modelo es suficientemente bueno, el agent funcionará."
Falso.
El verdadero bottleneck no es el modelo. Es lo que ponéis alrededor. Sin guardrails deterministas, sin recuperación de errores estructurada, sin memoria externa, cualquier agent — da igual si usa GPT-4o o Claude 3.7 — se rompe en cuanto la tarea se alarga más de 3 pasos.
Dónde fracasan los agents hoy:
❌ Acumulación de errores en cadenas largas: Cada iteración del bucle ReAct introduce ruido. El LLM misinterpret las salidas de las tools, alucina observaciones, pierde el hilo del objetivo original. Después de 5 pasos, el 60% de las ejecuciones divergen del objetivo inicial.
❌ Sin recuperación estructurada: La mayoría de implementaciones usan try-except genéricos que capturan errores pero no saben qué hacer con ellos. El agent se queda colgado, entra en loop infinito, o devuelve basura.
❌ Memoria naive: Context window stuffing. Cram todo en el prompt hasta que explota. Summarization que pierde detalle. RAG que no sirve para estado de tarea. La memoria es el problema unsolved de los agents.
❌ Coordinación multi-agent caótica: Cuando ponéis varios agents a colaborar, los errores de uno se propagan a los demás. Un cascade hallucination donde cada agent amplifica los errores del anterior.
La Evidencia: Por Qué el Patrón ReAct Es Frágil y Qué Viene Ahora
El patrón ReAct (Reasoning + Acting) de Yao et al. (2023) es la base de prácticamente todos los frameworks de agents actuales. LangChain, AutoGPT, CrewAI — todos usan variantes del mismo esquema:
```
LLM → selección de tool → ejecución → observación → repetir
```
Parece elegante. Es una trampa.
El problema con ReAct puro:
Cada "observación" que alimenta la siguiente iteración puede estar corrupta. Si la tool devuelve un error, el LLM puede interpretarlo como éxito. Si la salida es ambigua, el LLM inventa datos. Y cada error alimenta el siguiente ciclo, creando una bola de nieve de divergencia.
Los benchmarks de la comunidad muestran que las tasas de completitud de tasks caen sharply después de 3-5 llamadas secuenciales a tools. No es un problema del modelo. Es un problema del loop.
Andrew Ng identificó esto en 2024 y propuso lo que llamó "agentic design patterns": reflection, tool use, planning, y multi-agent collaboration. Pero estos patrones no resuelven el problema de fondo — solo lo hacen más tolerante.
Lo que realmente funciona en producción:
Los systems que funcionan — GitHub Copilot, Replit, los coding agents de las startups que realmente operan en producción — comparten una característica: determinismo en el outer loop, flexibilidad en el inner loop.
No buscan autonomía total. Buscan agentes delimitados: creativos dentro de límites strictos, con capacidad de decisión pero con bordes definidos.
El Framework del Agente Híbrido: 5 Capas Para Agents que No Se Rompen
Después de construir y romper dozens de agents, he llegado a una arquitectura que funciona. La llamo El Framework del Agente Híbrido — porque combina la rigidez de un sistema determinista con la flexibilidad de un LLM en los nodos de decisión.
Capa 1: Define los Guardrails Antes de Pensar en el LLM
Nunca dejes que el LLM decida parámetros críticos sin validación estructurada.
```python
from pydantic import BaseModel, Field
from typing import Literal
class AgentAction(BaseModel):
action: Literal["search", "calculate", "fetch", "respond"]
params: dict = Field(default_factory=dict)
max_retries: int = 3
timeout_seconds: int = 30
```
Antes de llamar al LLM, defines el schema. El LLM puede elegir qué acción tomar, pero los parámetros siempre pasan por validación. Bounds checking, type enforcement, valores permitidos. Esta capa es tu red de seguridad.
Capa 2: Implementa el ReAct Loop En 50 Líneas Antes de Usar un Framework
Entiende la mecánica antes de abstractarla.
```python
import anthropic
client = anthropic.Anthropic()
def react_loop(task: str, tools: list[dict], max_iterations: int = 10):
messages = [{"role": "user", "content": task}]
for i in range(max_iterations):
LLM decide siguiente acción
response = client.messages.create(
model="claude-3-7-20260214",
max_tokens=1024,
tools=tools,
messages=messages
)
if not response.content:
break
for block in response.content:
if block.type == "text":
messages.append({"role": "assistant", "content": block.text})
elif block.type == "tool_use":
Ejecutar tool con timeout y manejo de errores
result = execute_with_timeout(block.name, block.input, timeout=30)
messages.append({
"role": "user",
"content": f"<result>{result}</result>"
})
Check de terminación
if is_terminal_state(messages):
break
return extract_final_answer(messages)
```
Este loop mínimo te muestra exactamente dónde se rompe todo. Sin abstracciones, ves el error accumulation.
Capa 3: Error Recovery Estructurado — No Solo Try-Except
Los errores no son excepcionales. Son el estado normal de un agent en producción.
```python
from enum import Enum
class ErrorType(Enum):
TOOL_TIMEOUT = "timeout"
TOOL_ERROR = "execution_error"
LLM_AMBIGUITY = "ambiguous_response"
CONTEXT_OVERFLOW = "context_limit"
class StructuredErrorRecovery:
def __init__(self):
self.error_log = []
def handle(self, error: Exception, context: dict) -> str:
error_type = self.classify(error)
recovery_actions = {
ErrorType.TOOL_TIMEOUT: self._retry_with_backoff,
ErrorType.TOOL_ERROR: self._fallback_to_alternative,
ErrorType.LLM_AMBIGUITY: self._ask_for_clarification,
ErrorType.CONTEXT_OVERFLOW: self._compress_context,
}
action = recovery_actions.get(error_type, self._escalate_to_human)
return action(context)
def _retry_with_backoff(self, context: dict) -> str:
Exponential backoff con máximo de 3 intentos
for attempt in range(3):
try:
return execute_with_backoff(context, delay=2**attempt)
except Exception:
continue
return self._escalate_to_human(context)
def _fallback_to_alternative(self, context: dict) -> str:
Si falla tool A, intentar tool B con capacidad similar
alternatives = get_alternative_tools(context["failed_tool"])
for alt in alternatives:
try:
return alt.execute(context)
except:
continue
return self._escalate_to_human(context)
```
La diferencia entre un agent que funciona y uno que no es esta capa. Sin ella, cualquier error es un crash. Con ella, el agent se recupera y continúa.
Capa 4: Memoria Externa — El LLM Context Es Cache, No Storage
No metas todo en el contexto. Construye un sistema de memoria externo desde el día 1.
```python
from supabase import create_client
import json
class ExternalMemoryStore:
def __init__(self, supabase_url: str, supabase_key: str):
self.client = create_client(supabase_url, supabase_key)
self.vector_client = create_vector_client() # pgvector o Pinecone
def store_step(self, agent_id: str, step: dict):
Estado estructurado en PostgreSQL
self.client.table("agent_steps").insert({
"agent_id": agent_id,
"action": step["action"],
"result": step["result"],
"timestamp": "now()"
})
Embedding de la observación en vector store para RAG
embedding = embed_text(f"Action: {step['action']}, Result: {step['result']}")
self.vector_client.insert({
"id": f"{agent_id}_{step['timestamp']}",
"values": embedding,
"metadata": {"action": step["action"]}
})
def retrieve_relevant(self, agent_id: str, query: str, k: int = 5) -> list[dict]:
query_embedding = embed_text(query)
results = self.vector_client.search(
query_vector=query_embedding,
top_k=k,
filter={"agent_id": agent_id}
)
Recupera estado estructurado junto con contexto semántico
step_ids = [r["id"] for r in results]
states = self.client.table("agent_steps").select("*").in_("id", step_ids).execute()
return self._reconstruct_context(states.data)
```
Este patrón convierte la memoria de algo que cramming en el context en un sistema queryable, persistente, y recovery-friendly.
Capa 5: Tool Schemas con Descripciones de Calidad
La calidad de tu agent está bound por la calidad de tus definiciones de tools.
```python
tools = [
{
"name": "search_inventory",
"description": "Busca productos en el inventario por nombre, SKU, o categoría. Devuelve hasta 50 resultados ordenados por relevancia. Si el query es ambiguo, devuelve las 5 categorías más probables para desambiguación.",
"input_schema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Término de búsqueda. Puede ser nombre de producto, SKU parcial, o categoría."
},
"filters": {
"type": "object",
"description": "Filtros opcionales: availability, price_range, category"
},
"limit": {
"type": "integer",
"default": 20,
"description": "Máximo de resultados a devolver (1-50)"
}
},
"required": ["query"]
}
}
]
```
Descripción unclear → tool mal usada → outputs erráticos → agent diverge.
Conclusión: La Autonomía Es una Ilusión. Los Borders Son la Realidad
La próxima vez que veáis un demo de un AI agent haciendo algo impresionante, preguntad: ¿cuántos pasos tiene la tarea? ¿Qué pasa si falla en el paso 3? ¿Hay recovery? ¿Dónde está la memoria?
La mayoría de demos给你们看的 son ejecuciones single-run, cherry-picked. La varianza en tasks similares supera el 60% en muchos casos.
El verdadero breakthrough no es la autonomía. Es la combinación de guardrails deterministas + nodos de decisión con LLM + error recovery estructurado + memoria externa.
Los agents que van a sobrevivir en producción no son los más inteligentes. Son los que tienen los bordes más definidos.
Vosotros sabéis construir sistemas robustos. Los AI agents son solo otro sistema. Aplicad las mismas lecciones.
Si quieres el código completo del framework con tests y ejemplos de coordinación multi-agent, lo tengo en mi repo. Pregunta en los comentarios.
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