Cuando le pides a un asistente de IA como Kiro (el asistente de IA de AWS), Claude Code o ChatGPT que "construya un agente," obtienes código funcional. Pero no ves las decisiones de arquitectura que ocurren detrás de escena. El agente responde a consultas, pero podría desperdiciar tokens en bucles de razonamiento, alucinar respuestas a partir de datos incompletos, o congelarse con APIs lentas. Estas fallas son silenciosas hasta llegar a producción.
Cuando le pides a asistentes de IA que construyan agentes, toman decisiones de arquitectura silenciosamente—eligiendo estrategias de recuperación, enfoques de validación y patrones de manejo de errores. Estos 8 patrones te dan el vocabulario para especificar decisiones de grado producción en tus prompts, previniendo alucinaciones y desperdicio de tokens antes de que se genere código.
Este post cierra dos series que escribí documentando las fallas de agentes más costosas en producción: Stop AI Agent Hallucinations (5 técnicas) y Why AI Agents Fail (3 modos de falla). Si conoces estos 8 patrones, puedes guiar a los asistentes de IA para evitarlos desde el inicio.
Esto no es una guía de implementación paso a paso. Es una referencia para saber qué existe y así reconocer cuándo usar cada patrón según tu caso de uso.
Código funcional para las 8 técnicas: Enlazado en cada sección
Por Qué Esto Importa
Los asistentes de IA generan código de agentes en segundos. Kiro, Claude Code, Cursor y ChatGPT pueden crear estructuras de herramientas, configurar llamadas a LLM y conectar sistemas de recuperación más rápido que programar manualmente.
Pero la velocidad crea un problema: obtienes código funcional sin ver las concesiones.
Cuando escribes "construye un agente de reservas con RAG," el asistente toma decisiones:
- ¿Qué estrategia de recuperación? (similitud vectorial, consultas de grafos, híbrido)
- ¿Cómo manejar salidas grandes? (truncar, resumir, almacenamiento externo)
- ¿Qué validación se ejecuta antes de usar una herramienta? (ninguna, prompts, hooks de framework)
- ¿Cómo manejar APIs lentas? (bloquear, timeout, patrones asíncronos)
Tu prompt no especifica esto. El asistente elige valores por defecto. Esos valores por defecto crean los modos de falla que este post documenta.
Los 8 Patrones de Falla (Referencia Rápida)
Fallas por Alucinación (5 patrones):
- GraphRAG - RAG vectorial fabrica estadísticas a partir de fragmentos incompletos
- Semantic Tool Selection - Demasiadas herramientas, el agente elige las equivocadas
- Neurosymbolic Guardrails - El agente ignora reglas de negocio en los prompts
- Runtime Guardrails (Steering) - El agente viola reglas, necesita corrección no bloqueo
- Multi-Agent Validation - Un solo agente afirma éxito cuando las operaciones fallan
Desperdicio Silencioso de Tokens (3 patrones):
- Memory Pointer Pattern - Datos grandes desbordan el contexto, causan truncamiento
- Async HandleId Pattern - APIs lentas bloquean el agente indefinidamente
- DebounceHook + Explicit States - El agente hace bucle con la misma llamada sin progreso
No implementas los 8. Aprendes qué resuelven, luego especificas los que tu caso de uso necesita al hacer prompts.
¿Qué Son Estos 8 Patrones?
Estos patrones resuelven las fallas de producción más costosas: alucinaciones por datos incompletos (GraphRAG, Semantic Tool Selection, Guardrails, Steering, Multi-Agent), y desperdicio silencioso de tokens (Memory Pointers, Async HandleId, DebounceHook). Aprendes qué resuelve cada uno, luego especificas los que tu caso de uso necesita al pedir a asistentes de IA. Esto previene depurar código de caja negra en producción.
Impacto Medido en Producción
| Patrón | Resultado | Fuente |
|---|---|---|
| GraphRAG | Conteos exactos vs aproximaciones fabricadas | RAG vs GraphRAG |
| Semantic Tool Selection | 86.4% menos errores, 89% menos costos de tokens | Tool Selection |
| Memory Pointers | 20M tokens reducidos a 1,234 tokens | estudio IBM Materials Science |
| Async HandleId | Bloqueo de 18 segundos eliminado, sin timeouts 424 | MCP Timeouts |
| Explicit States | 14 llamadas reducidas a 2 (mejora de 7x) | Reasoning Loops |
Patrón 1: GraphRAG para Consultas Precisas
¿Qué Es GraphRAG?
GraphRAG reemplaza la similitud vectorial con consultas a bases de datos de grafos para datos estructurados. Cuando tu agente necesita conteos exactos, agregaciones o recorrido de relaciones, GraphRAG traduce lenguaje natural a consultas Cypher que retornan resultados precisos desde datos estructurados en lugar de estadísticas alucinadas desde fragmentos de texto. Úsalo para consultas estructuradas, mantén RAG vectorial para búsqueda semántica.
Qué Se Rompe
RAG vectorial fabrica estadísticas. Preguntas "¿Cuántos hoteles en Miami tienen piscina y desayuno?" y la similitud vectorial recupera 3 fragmentos de texto que mencionan piscinas y desayuno. El LLM ve datos incompletos, calcula a partir de muestras y retorna "aproximadamente 120 hoteles" (fabricado a partir de 3 fragmentos de 200 hoteles).
Las consultas fuera de dominio retornan respuestas alucinadas en lugar de admitir que no existen datos.
La Solución
Reemplaza la recuperación vectorial con consultas de grafos para datos estructurados. Almacena hoteles, amenidades y relaciones en Neo4j. El LLM traduce "hoteles con piscinas y desayuno" a Cypher:
MATCH (h:Hotel)-[:HAS_AMENITY]->(a:Amenity)
WHERE a.name IN ['pool', 'breakfast']
RETURN count(DISTINCT h)
Resultado: 133 hoteles (conteo exacto desde la base de datos).
Consulta fuera de dominio: "No se encontraron hoteles en la Antártida" en lugar de fabricar resultados.
Qué Decirle a Tu Asistente de IA
"Construye un agente de viajes usando GraphRAG con Neo4j. Para consultas
estructuradas (hoteles, amenidades, disponibilidad), traduce a Cypher
y ejecuta contra el grafo. Solo usa RAG vectorial para descripciones
no estructuradas. Retorna conteos exactos desde recorrido del grafo."
Cuándo Usar
- Datos estructurados con relaciones (productos, inventario, ubicaciones)
- Consultas que requieren conteos, agregaciones o recorrido multi-salto
- Dominios donde fabricar estadísticas crea riesgo legal/financiero
Detalles completos: RAG vs GraphRAG: When Agents Hallucinate Answers
Aprende más: Documentación Neo4j Cypher
Patrón 2: Semantic Tool Selection
¿Qué Es Semantic Tool Selection?
Semantic tool selection usa embeddings vectoriales para filtrar herramientas antes de que el LLM las vea. Cuando tu agente tiene más de 10 herramientas, enviar todas las descripciones en cada llamada aumenta las tasas de error (el agente elige herramientas incorrectas) y los costos de tokens (pagando por descripciones no usadas). El filtrado semántico inserta descripciones de herramientas offline, luego en tiempo de ejecución compara la consulta con las 5 herramientas más relevantes, reduciendo errores en 86.4% y costos en 89%.
Qué Se Rompe
Con 50 herramientas, ocurren dos fallas: (1) el agente elige herramientas incorrectas porque las descripciones se superponen, y (2) los costos de tokens explotan por enviar las 50 descripciones de herramientas en cada llamada al LLM.
Impacto medido: Las tasas de error aumentan con el conteo de herramientas, los costos de tokens escalan linealmente.
La Solución
Usa embeddings vectoriales para filtrar herramientas antes de que el LLM las vea. Inserta descripciones de herramientas offline. En tiempo de ejecución, inserta la consulta del usuario, calcula similitud, pasa solo las 5 herramientas más relevantes al agente.
Resultados en producción:
- Errores reducidos: 86.4%
- Costos de tokens reducidos: 89%
- Latencia: <10ms para filtrado de herramientas
Qué Decirle a Tu Asistente de IA
"Construye un agente multi-herramienta con semantic tool selection. Usa FAISS
y SentenceTransformers para insertar descripciones de herramientas offline. En
tiempo de ejecución, inserta la consulta, recupera las 5 herramientas más similares,
pasa solo esas al agente. Mantén memoria de conversación, intercambia herramientas dinámicamente."
Cuándo Usar
- Agentes con más de 10 herramientas
- Herramientas con descripciones que se superponen
- Aplicaciones sensibles a costos
Detalles completos: Reduce Agent Errors and Token Costs with Semantic Tool Selection
Patrón 3: Neurosymbolic Guardrails (Bloqueo)
¿Qué Son Neurosymbolic Guardrails?
Neurosymbolic guardrails aplican reglas de negocio a nivel de framework, por debajo del control del LLM. Cuando los prompts solos no pueden aplicar restricciones (máximo de huéspedes, fechas válidas, límites de presupuesto), los guardrails usan hooks de pre-ejecución para validar parámetros y cancelar operaciones inválidas. Las reglas viven en código, no en prompts, así que el LLM no puede evadirlas. Usa guardrails de bloqueo para restricciones duras que no pueden violarse.
Qué Se Rompe
Los prompts no pueden aplicar reglas de negocio. Incluso con docstrings claros ("max_guests debe ser ≤10"), el LLM pasa max_guests=15 bajo presión porque los prompts son sugerencias, no restricciones. El agente viola reglas silenciosamente.
La Solución
Usa hooks de framework para validar parámetros antes de la ejecución de herramientas. Si la validación falla, cancela la llamada de herramienta y retorna guía correctiva. Las reglas viven en código a nivel de framework, por debajo del control del LLM.
Impacto medido: Cero violaciones en prueba de 100 consultas (vs. 12 violaciones solo con prompts).
Qué Decirle a Tu Asistente de IA
"Construye un agente de reservas con guardrails usando hooks de Strands Agents.
Crea un hook BeforeToolCallEvent que valide:
- max_guests ≤ 10
- check_in_date > hoy
- budget > 0
Si la validación falla, cancela la llamada de herramienta con event.cancel_tool()
y retorna mensaje de error. No confíes en prompts para validación."
Cuándo Usar
- Reglas de negocio que no pueden violarse (cumplimiento, legales, financieras)
- Validación que requiere cálculo (matemáticas de fechas, verificaciones de inventario)
- Reglas que cambian frecuentemente
Detalles completos: AI Agent Guardrails: Rules That LLMs Cannot Bypass
Patrón 4: Runtime Guardrails (Dirigir, No Bloquear)
¿Qué Es Dirigir vs Bloquear?
Steering guardrails retornan guía correctiva en lugar de bloquear operaciones. Cuando el agente viola una regla suave (problemas de formato, ajustes de parámetros, redacción de datos), el steering retorna instrucciones vía Guide() para que el agente se autocorrija y reintente. Esto difiere de los guardrails de bloqueo (Patrón 3) que detienen flujos de trabajo completamente. Usa steering para reglas donde el agente puede corregirse, bloqueo para restricciones duras.
Qué Se Rompe
Los guardrails duros (Patrón 3) bloquean operaciones y detienen flujos de trabajo. Para reglas suaves donde el agente puede autocorregirse (problemas de formato, ajustes de parámetros, redactar datos sensibles), el bloqueo crea fricción. El agente podría arreglar el problema por sí mismo si se le da guía.
La Solución
Usa Agent Control para retornar guía correctiva vía Guide() en lugar de bloquear. Cuando el agente viola una regla suave, el plano de control retorna instrucciones: "Ajusta el parámetro X a Y y reintenta." El agente se autocorrige y completa la tarea sin intervención humana.
Diferencia con el Patrón 3:
- Bloquear (Patrón 3): Restricciones duras, el flujo de trabajo se detiene
- Dirigir (Patrón 4): Reglas suaves, el agente se autocorrige
Qué Decirle a Tu Asistente de IA
"Construye un agente de reservas con Agent Control para reglas suaves. Conéctate
al servidor Agent Control. Para reglas suaves (formato de parámetros, ajustes
de fecha, redacción de datos), retorna Guide() con instrucciones de corrección
en lugar de bloquear. El agente debe reintentar con la corrección aplicada.
Usa bloqueos duros (Patrón 3) solo para reglas de cumplimiento que no pueden
violarse bajo ninguna circunstancia."
Cuándo Usar
- Reglas donde el agente puede autocorregirse (formato, ajustar parámetros)
- Flujos de trabajo donde el bloqueo crea UX pobre
- Reglas gestionadas centralmente vía API/dashboard (actualizar sin redesplegar)
Detalles completos: Runtime Guardrails for AI Agents: Steer, Don't Block
Patrón 5: Multi-Agent Validation
¿Qué Es Multi-Agent Validation?
Multi-agent validation despliega agentes especializados con diferentes roles (Executor, Validator, Critic) que verifican cruzadamente el trabajo de los demás. Los agentes únicos optimizan para parecer exitosos, no verificar resultados. Múltiples agentes con diferentes funciones de optimización atrapan errores que los demás pierden. El Executor realiza tareas, el Validator verifica contra la verdad fundamental, el Critic proporciona revisión final antes de retornar al usuario.
Qué Se Rompe
Los agentes únicos no pueden autovalidarse. Cuando un agente reserva un hotel, afirma "Éxito: Reservado Grand Plaza Hotel" incluso si la API retornó un error o el hotel no existe en la base de datos. El agente optimiza para parecer exitoso, no verificar resultados.
La Solución
Despliega múltiples agentes con diferentes roles: el Executor realiza tareas, el Validator verifica contra la verdad fundamental, el Critic proporciona revisión final. Los agentes comparten contexto y transfieren control autónomamente cuando su rol se completa.
Impacto medido: Multi-agente atrapa errores que el agente único pierde (p.ej., reservar hoteles inexistentes).
Qué Decirle a Tu Asistente de IA
"Construye un sistema multi-agente usando Strands Swarm con 3 agentes:
1. Executor: Reserva hoteles, busca vuelos
2. Validator: Verifica cruzadamente operaciones contra la base de datos
3. Critic: Revisión final antes de retornar al usuario
Los agentes comparten contexto vía swarm.context. Usa transferencias autónomas.
Los agentes deciden cuándo transferir según completación de tarea."
Cuándo Usar
- Operaciones de alto riesgo (financieras, médicas, legales)
- Tareas donde "parece exitoso" difiere de "realmente exitoso"
- Flujos de trabajo complejos con múltiples puntos de verificación
Detalles completos: How to Stop AI Agents from Hallucinating Silently with Multi-Agent Validation
Patrón 6: Memory Pointer Pattern
¿Qué Es el Memory Pointer Pattern?
El Memory Pointer Pattern almacena datos grandes fuera del contexto del LLM y pasa referencias cortas en su lugar. Cuando las herramientas retornan logs de más de 200KB o resultados de base de datos de 1000 filas, pasarlos directamente causa truncamiento silencioso. Los memory pointers almacenan datos en agent.state, retornan un puntero al LLM y proporcionan herramientas separadas que resuelven punteros para acceder a datos completos. IBM redujo de 20M tokens a 1,234 tokens usando este patrón.
Qué Se Rompe
El desbordamiento de ventana de contexto ocurre cuando las herramientas retornan más datos de los que el LLM puede procesar (logs de más de 200KB, resultados de base de datos de 1000 filas). El agente no colapsa. Trunca datos silenciosamente, pierde contexto, produce respuestas incompletas.
Caso real de producción (IBM Materials Science):
- Antes: 20 millones de tokens, flujo de trabajo falló
- Después: 1,234 tokens, flujo de trabajo exitoso
La Solución
Almacena datos grandes en agent.state, pasa referencias cortas al LLM. Las herramientas retornan punteros como "logs-app-server". Las herramientas subsiguientes resuelven punteros para acceder a datos completos. El LLM solo ve: "Datos almacenados como logs-app-server. Usa analyze_errors(pointer)."
Datos en contexto reducidos: 214KB → 52 bytes
Qué Decirle a Tu Asistente de IA
"Construye un agente de análisis de logs usando Memory Pointer Pattern. Cuando
fetch_logs retorne más de 20KB:
1. Almacenar en agent.state con ID de puntero único
2. Retornar al LLM: 'Datos almacenados como logs-{app}. Usa analyze_logs(pointer).'
3. Implementar analyze_logs(pointer) que resuelva desde agent.state
Nunca pases datos grandes directamente al contexto del LLM."
Cuándo Usar
- Herramientas que retornan salidas grandes (logs, consultas de base de datos, archivos)
- Flujos de trabajo con múltiples pasos de procesamiento sobre los mismos datos grandes
- Aplicaciones sensibles a costos
Detalles completos: AI Context Window Overflow: Memory Pointer Fix
Patrón 7: Async HandleId Pattern
¿Qué Es el Async HandleId Pattern?
El async handleId pattern previene que APIs externas lentas bloqueen tu agente. Cuando una API toma más de 30 segundos, las llamadas síncronas congelan todo el agente. Async handleId retorna un ID de trabajo inmediatamente, permitiendo que el agente continúe con otras tareas. Una herramienta check_status separada sondea por resultados cuando estén listos. Esto elimina errores de timeout 424 y mantiene los agentes responsivos.
Qué Se Rompe
Las APIs externas que toman más de 30 segundos bloquean el agente indefinidamente. Ninguna otra herramienta puede ejecutarse. Después de ~7 segundos, muchas implementaciones retornan errores de timeout 424, congelando el flujo de trabajo.
La Solución
Las herramientas retornan inmediatamente con un ID de trabajo en lugar de esperar. El agente almacena handleId y continúa. Una herramienta check_status(job_id) separada sondea por resultados asincrónicamente.
Impacto medido:
- Antes: API de 18 segundos bloquea agente, timeout 424
- Después: Herramienta retorna en menos de 1 segundo, agente sondea cuando está listo
Qué Decirle a Tu Asistente de IA
"Construye un agente con async handleId pattern para APIs lentas:
1. start_analysis(data): Envía trabajo, retorna job_id inmediatamente
2. check_status(job_id): Sondea por resultados
El agente llama start_analysis, almacena job_id, continúa con otras
tareas, llama check_status cuando está listo. No implementes llamadas bloqueantes."
Cuándo Usar
- APIs externas con tiempos de respuesta mayores a 5 segundos
- Procesamiento por lotes (análisis de video, transformaciones grandes)
- Cualquier sistema fuera de tu control
Detalles completos: Fix MCP Timeouts: Async HandleId Pattern
Patrón 8: DebounceHook + Explicit States
¿Qué Previene los Bucles de Razonamiento?
Los bucles de razonamiento ocurren cuando retroalimentación ambigua ("más puede estar disponible") señala que reintentar podría ayudar. Dos correcciones funcionan juntas: estados terminales explícitos (retornar SUCCESS/FAILED para que el LLM sepa cuándo detenerse) y DebounceHook (hook de framework que bloquea llamadas duplicadas). Las pruebas de producción mostraron que los estados explícitos redujeron las llamadas de 14 a 2, mientras que DebounceHook proporciona una red de seguridad para casos extremos.
Qué Se Rompe
Los agentes hacen bucle llamando a la misma herramienta repetidamente sin progreso. Retroalimentación ambigua como "Se encontraron 3 resultados. Más pueden estar disponibles" señala que reintentar podría ayudar. El agente hace bucle indefinidamente.
Caso real de producción: 847 pasos de razonamiento a $47/minuto, sin respuesta entregada.
La Solución (Dos Partes)
Parte A: Estados Terminales Explícitos
Retorna estados claros de SUCCESS o FAILED. Cambia "Más pueden estar disponibles" a "SUCCESS: Se encontraron todos los 3 vuelos coincidentes."
Parte B: Red de Seguridad DebounceHook
El hook de framework rastrea llamadas recientes a herramientas. Cuando el mismo par (tool_name, input) aparece dos veces, bloquea el tercer intento.
Impacto medido (demo de reserva de viajes):
- Retroalimentación ambigua: 14 llamadas
- SUCCESS explícito: 2 llamadas (reducción de 7x)
- DebounceHook: 12 llamadas (2 bloqueadas)
Qué Decirle a Tu Asistente de IA
"Construye un agente de viajes con protección anti-bucle:
1. Todas las herramientas retornan estados explícitos:
- SUCCESS: [completación clara]
- FAILED: [error claro]
Nunca retornes 'más puede estar disponible'
2. Implementa DebounceHook:
- Rastrea las últimas 3 llamadas de herramientas como (tool_name, input)
- Si el mismo par aparece dos veces, bloquea el tercer intento
- Retorna 'BLOCKED: Duplicado detectado'
Esto previene bucles sin límites manuales de reintentos."
Cuándo Usar
- Agentes propensos a bucles de reintento (búsqueda, agregadores de API)
- Aplicaciones sensibles a costos donde reintentos ilimitados son costosos
- Sistemas de producción donde bucles infinitos crean riesgo de disponibilidad
Detalles completos: How to Prevent AI Agent Reasoning Loops from Wasting Tokens
Errores Comunes
Error 1: Asumir Que los Valores Por Defecto Son Mejores Prácticas
Problema: "Construye un agente de producción" asume que el asistente sabe qué significa producción.
Solución: Especifica patrones: "Usa GraphRAG, guardrails, patrones async, etc..."
Error 2: Confiar Solo en Prompts para Validación
Problema: "Asegúrate de que max_guests < 10" en el prompt del sistema es ignorado bajo presión.
Solución: "Implementa hook BeforeToolCallEvent que valide y cancele llamadas inválidas."
Error 3: No Reconocer Cuándo Aplican los Patrones
Problema: El agente funciona en demo, se rompe en casos extremos.
Solución: Conoce los 8 patrones. Cuando veas alucinaciones, timeouts o bucles, reconocerás qué patrón lo resuelve.
Lo Que Esto Significa para el Desarrollo Asistido por IA
Los asistentes de IA seguirán mejorando en generar código funcional. Pero código funcional y arquitectura lista para producción siguen siendo objetivos diferentes.
La brecha no es la capacidad del asistente. Es la especificidad del prompt.
Cuando escribes "construye un agente de reservas," el asistente optimiza para código que compila y responde a consultas.
Cuando escribes "construye un agente de reservas usando GraphRAG para consultas estructuradas, guardrails para validación y patrones async para APIs de reservas," el asistente optimiza para código que compila, responde a consultas, previene alucinaciones, aplica reglas de negocio y maneja APIs lentas.
Estos 8 patrones son el vocabulario para comunicar intención de producción.
No implementas los 8. Aprendes qué resuelven. Cuando ves alucinaciones, reconoces que GraphRAG aplica. Cuando ves timeouts, reconoces que async handleId aplica. Cuando ves bucles, reconoces que estados explícitos + DebounceHook aplican.
Este conocimiento cambia cómo haces prompts a Kiro, Claude Code, Cursor y ChatGPT. En lugar de depurar fallas de caja negra en producción, especificas los patrones que las previenen durante la generación.
Aprende Más (Guías de Implementación Completas)
Cada patrón tiene una guía completa con código funcional:
- GraphRAG: RAG vs GraphRAG: When Agents Hallucinate Answers
- Semantic Tool Selection: Reduce Agent Errors and Token Costs
- Neurosymbolic Guardrails: AI Agent Guardrails: Rules That LLMs Cannot Bypass
- Runtime Guardrails (Steering): Runtime Guardrails for AI Agents: Steer, Don't Block
- Multi-Agent Validation: Stop AI Agents from Hallucinating Silently
- Memory Pointers: AI Context Window Overflow: Memory Pointer Fix
- Async HandleId: Fix MCP Timeouts: Async HandleId Pattern
- DebounceHook: Prevent AI Agent Reasoning Loops
Serie completa:
- Stop AI Agent Hallucinations: 5 Essential Techniques
- Why AI Agents Fail: 3 Failure Modes That Cost You Tokens and Time
Cierre
Cada patrón en este post existe porque algo se rompió en producción. Agentes que alucinaron estadísticas en demos de clientes. Bucles que quemaron tokens a $47/minuto. Desbordamientos de contexto que truncaron datos críticos. Timeouts que congelaron flujos de trabajo.
Ahora sabes qué se rompe y cómo prevenirlo al hacer prompts correctamente.
Cuando le pides a Kiro, Claude Code o ChatGPT que construya un agente, puedes especificar qué patrones aplican. Esa es la diferencia entre prototipos que se rompen y agentes que escalan.
Úsalo.
Gracias!
Top comments (0)