Cómo Construir Agentes de IA Correctamente: La Guía de Anthropic en 14 Minutos
Fuente: xIA (@xiathis) en X.com | Compartido por: @sergiorocaa | Duración: ~14 minutos
Introducción
Este ingeniero de Anthropic explica en 14 minutos la manera correcta de construir agentes de IA. La mayoría de los desarrolladores pasan meses haciéndolo de manera equivocada.
Guarda esta guía antes de escribir tu próxima línea de código de agente. Los meses que pierde la mayoría de los desarrolladores se evitan siguiendo estos principios desde el inicio.
1. ¿Qué es realmente un agente de IA?
Un agente de IA no es simplemente una cadena de prompts. Es un sistema donde un modelo de lenguaje (LLM) actúa en un bucle de percepción–razonamiento–acción, utilizando herramientas externas para completar tareas complejas de varios pasos.
La distinción clave: un pipeline tradicional ejecuta pasos predefinidos. Un agente decide dinámicamente qué pasos tomar según el resultado de cada acción anterior. Observa el estado actual del mundo, razona sobre qué hacer a continuación, ejecuta una acción y luego observa el resultado antes de decidir el siguiente paso.
Este bucle es el bloque fundamental de cualquier agente construido correctamente, y la mayoría de los desarrolladores lo omiten por completo — construyen pipelines elaborados y los llaman agentes.
2. El Error más Común: Demasiada Complejidad desde el Inicio
La mayoría de los desarrolladores intentan construir un sistema multi-agente complejo desde el principio. Quieren orquestadores, subagentes, memorias vectoriales, pipelines paralelos y lógica de reintentos todo a la vez. Este es un error fundamental.
La guía de Anthropic es clara: empieza con el sistema más simple que funcione.
Comienza con un único LLM que llame a unas pocas herramientas. Verifica que funcione. Mide dónde falla. Solo entonces añade más complejidad, y únicamente si tienes evidencia de que la necesitas.
Cada capa de complejidad es una capa adicional de posibles fallos. Cada abstracción que añades es una superficie donde los errores pueden ocultarse. Cada agente que agregas es una nueva fuente de comportamiento impredecible.
El mejor sistema agente no es el más complejo — es el que resuelve de manera confiable tu problema específico con la menor cantidad de componentes móviles.
3. Los Cuatro Patrones de Flujo de Trabajo de Agentes
Anthropic identifica cuatro patrones fundamentales para construir flujos de trabajo de agentes. Entender cuándo usar cada uno es crítico.
Patrón 1 — Encadenamiento de Prompts
La tarea se descompone en una secuencia clara de pasos. La salida de cada llamada al LLM se convierte en la entrada del siguiente paso. No hay toma de decisiones dinámica entre pasos — la secuencia está fija en el momento del diseño.
Esto es ideal cuando el proceso tiene etapas bien definidas y secuenciales donde cada etapa produce una salida predecible que la siguiente puede consumir. Es el patrón más simple y debe ser tu primera opción.
Patrón 2 — Enrutamiento
Una llamada inicial al LLM actúa como clasificador. Analiza la solicitud entrante y la redirige al flujo de trabajo especializado más adecuado. Cada ruta está optimizada para un tipo específico de tarea.
Esto es útil cuando tu sistema maneja muchos tipos diferentes de entradas que requieren un tratamiento fundamentalmente distinto. Por ejemplo: un sistema de soporte que redirige preguntas de facturación, preguntas técnicas y preguntas de cuenta a diferentes sub-pipelines especializados.
Patrón 3 — Paralelización
Múltiples llamadas independientes al LLM se ejecutan simultáneamente sobre diferentes partes del problema. Los resultados se agregan luego en un paso de síntesis final.
Este patrón reduce la latencia total cuando las subtareas son genuinamente independientes y cuando el tiempo ahorrado por la paralelización justifica la complejidad añadida. No lo uses solo porque puedes — úsalo únicamente cuando la carga de trabajo se descomponga naturalmente en unidades independientes.
Patrón 4 — Orquestador y Subagentes
Un LLM principal (el orquestador) decide dinámicamente qué subtareas delegar y a qué subagentes especializados. Cada subagente opera en su propio contexto, con sus propias herramientas y memoria.
Este es el patrón más poderoso y el más complejo. Úsalo únicamente cuando la tarea sea verdaderamente dinámica — cuando genuinamente no puedas predecir en el momento del diseño qué subtareas serán necesarias o en qué orden.
4. El Bucle Agente Correcto: Percepción → Razonamiento → Acción → Observación
El bucle fundamental de un agente bien construido tiene cuatro etapas, y las cuatro son esenciales:
1. Percibir — El agente recibe el estado actual del entorno: la solicitud del usuario, los resultados de llamadas anteriores a herramientas, el contenido de la memoria relevante y cualquier otro contexto que necesite.
2. Razonar — El agente razona sobre qué hacer a continuación. Con los LLMs modernos esto ocurre a través de la cadena de pensamiento: el modelo genera razonamiento interno antes de comprometerse con una acción. No omitas esto — darle al modelo espacio para razonar antes de actuar mejora drásticamente la precisión.
3. Ejecutar (Acción) — El agente llama a una o más herramientas para interactuar con el mundo exterior: una búsqueda web, una consulta de base de datos, una ejecución de código, una escritura de archivo, una llamada a API.
4. Observar — El agente recibe los resultados de sus acciones y actualiza su comprensión del estado actual antes de decidir el siguiente paso.
El punto crítico: el agente siempre trabaja contra un estado actualizado. No planifica todos los pasos por adelantado y ejecuta ciegamente. Después de cada acción, el agente observa el resultado y razona nuevamente desde el nuevo contexto.
La mayoría de los agentes defectuosos fallan aquí: planifican por adelantado, ignoran resultados y ejecutan ciegamente. Un agente correcto trata cada acción como nueva información.
5. Diseño de Herramientas: El Alma del Agente
Las herramientas son la interfaz entre el razonamiento del LLM y el mundo real. Si tus herramientas están mal diseñadas, tu agente fallará sin importar cuán buenos sean tus prompts.
Cada herramienta debe tener:
- Un nombre claro y descriptivo que le diga al modelo exactamente qué hace la herramienta solo desde su nombre.
- Una descripción precisa que explique los escenarios específicos donde debe usarse esta herramienta y, igual de importante, cuándo NO debe usarse.
- Parámetros bien definidos con tipos explícitos, restricciones y ejemplos para cada argumento.
- Salidas predecibles que el modelo pueda analizar y razonar de manera confiable.
El error de diseño de herramientas más común: demasiadas herramientas similares.
Cuando dos herramientas tienen capacidades superpuestas, el modelo se confunde sobre cuál llamar. Desperdicia tokens razonando sobre la elección y comete errores. El principio de Anthropic es claro: cada herramienta debe tener un propósito único e inequívoco. Si dos herramientas parecen similares, casi con certeza deberían ser una sola herramienta con un parámetro que distinga los dos casos.
Una buena heurística: si no puedes explicarle a un colega en una sola oración exactamente cuándo usar la herramienta A versus la herramienta B, únelas.
6. Gestión del Contexto: No Llenes el Contexto Innecesariamente
El contexto es el recurso más valioso y más limitado del agente. La calidad del razonamiento se degrada a medida que información irrelevante llena la ventana de contexto. Esto no es una hipótesis — está demostrado empíricamente en muchos modelos.
La estrategia correcta:
- Pasa solo la información que el agente necesita para este paso específico. No todo el historial. No toda la memoria. Solo lo que es relevante ahora.
- Cuando una herramienta devuelve un resultado largo (una página web completa, una respuesta JSON grande, un documento extenso), resúmelo antes de incluirlo en el contexto. Extrae solo los campos que el agente realmente necesita.
- Usa memoria estructurada: mantén un resumen del estado compacto y actualizado en lugar de una transcripción en constante crecimiento de cada paso anterior.
- Cuando los subagentes devuelven resultados al orquestador, haz que devuelvan resúmenes estructurados — no su rastro de ejecución completo.
Los agentes que mejor se desempeñan en producción no son los que tienen las ventanas de contexto más grandes — son los que son disciplinados sobre qué ponen en contexto.
7. Cuándo Usar Agentes y Cuándo No Usarlos
Usa agentes cuando:
- La tarea requiere múltiples pasos dinámicos que genuinamente no pueden predeterminarse en el momento del diseño.
- Las decisiones intermedias dependen de resultados en tiempo real de pasos anteriores que no pueden conocerse de antemano.
- La tarea se beneficia de acceso a herramientas y fuentes de datos externas que deben consultarse de manera adaptativa.
- La tarea es lo suficientemente compleja como para que la mayor latencia y costo de múltiples llamadas al LLM esté justificado por la mejora en calidad.
No uses agentes cuando:
- Un pipeline simple de pasos fijos — incluso uno con varios pasos — resuelve el problema de manera confiable.
- La latencia de múltiples llamadas secuenciales al LLM es inaceptable para tu caso de uso. Cada bucle de agente añade cientos de milisegundos como mínimo.
- El costo de múltiples llamadas al LLM es prohibitivo a la escala en la que esperas operar.
- La tarea está suficientemente bien definida y es determinista como para que un sistema más simple la maneje igual de bien.
La disciplina para reconocer cuándo NO necesitas un agente es una marca de madurez en ingeniería. La mayoría de los sistemas en producción que se llaman a sí mismos "agénticos" funcionarían igual de bien — y con mucha mayor confiabilidad — como pipelines simples.
8. Confiabilidad y Manejo de Errores en Producción
Los agentes en producción fallan de maneras que los pipelines simples no fallan, y los modos de fallo son más sutiles y difíciles de depurar.
Lo que debes implementar:
Reintentos con retroceso exponencial — Las llamadas a herramientas externas fallan. Las APIs devuelven errores. Las solicitudes de red se agota el tiempo. Cada llamada a herramienta debe tener lógica de reintentos con delays crecientes entre intentos y un conteo máximo de reintentos.
Límites máximos de pasos — Sin un límite máximo en el número de pasos que puede tomar un agente, un agente confundido entra en un bucle infinito. Todo agente debe tener un número máximo de iteraciones configurable, tras el cual se detiene e informa un fallo.
Puntos de control de estado — Para tareas de larga ejecución, guarda el estado del agente en puntos de decisión clave. Si el agente falla en el paso 15 de 20, deberías poder reanudar desde el paso 15 en lugar de reiniciar desde cero.
Mensajes de fallo elegantes — Cuando un agente falla, debe devolver un mensaje de error claro y estructurado que explique qué ocurrió, qué se logró antes del fallo y qué no se logró. Los fallos silenciosos son el peor resultado.
Registro de cada acción — En producción, registra cada llamada a herramienta, cada resultado y cada paso de razonamiento. Los agentes son no deterministas. Sin registros, depurar un fallo es casi imposible.
9. Evaluación de Agentes: El Desafío Real
Evaluar agentes es fundamentalmente más difícil que evaluar LLMs, y la mayoría de los equipos invierten insuficientemente en esto.
El desafío central: las trayectorias de los agentes son no deterministas. El mismo agente, con la misma entrada, puede llegar a la respuesta correcta por caminos diferentes en diferentes ejecuciones. Las métricas de precisión estándar que comparan salidas paso a paso se desmoronan.
El enfoque correcto:
-
Evalúa resultados, no trayectorias. Define criterios claros de éxito para el resultado final. ¿Respondió correctamente el agente la pregunta? ¿Completó la tarea? Estas son las métricas que importan. No califiques los pasos intermedios a menos que un paso específico sea un punto de fallo conocido.
-
Construye casos de prueba representativos. Tu conjunto de evaluación debe incluir ejemplos realistas de las tareas reales que enfrentará tu agente. Los ejemplos sintéticos que no coinciden con los patrones de producción te darán una confianza engañosa.
-
Prueba los modos de fallo explícitamente. Incluye casos adversarios: entradas diseñadas para desencadenar fallos en herramientas, solicitudes ambiguas, casos límite y solicitudes donde la respuesta correcta es "No puedo hacer esto". Un agente que falla elegantemente en casos difíciles es mucho más valioso que uno que se ve bien en casos fáciles.
-
Registra y analiza trazas reales de producción. Los datos de evaluación más valiosos son las interacciones reales de usuarios que salieron mal. Construye un sistema para marcar respuestas de baja confianza o fallos reportados por usuarios, y retroalimenta al ciclo de evaluación.
10. El Principio Central de Anthropic: Menos es Más
La conclusión más importante de la guía de Anthropic para construir agentes efectivos es también la más contraintuitiva: el mejor sistema agente es el más simple que resuelve tu problema de manera confiable.
Antes de añadir orquestación multi-agente, pregúntate: ¿un agente único con tres herramientas bien diseñadas resolvería esto?
Antes de añadir memoria vectorial, pregúntate: ¿pasaría los documentos relevantes directamente en el contexto funcionaría igual de bien?
Antes de añadir paralelización, pregúntate: ¿la reducción de latencia realmente vale la complejidad añadida y los nuevos modos de fallo?
La complejidad no es una virtud en la ingeniería de agentes. Cada componente que añades debe ganarse su lugar resolviendo un problema que no puede resolverse sin él. Los ingenieros de Anthropic que trabajan en sistemas reales de producción han aprendido esto de la manera difícil.
Empieza simple. Mide. Añade complejidad solo cuando la evidencia lo demande.
Nota Final
Esta guía representa las mejores prácticas actuales de una de las principales organizaciones del mundo en seguridad y capacidades de IA. Los principios aquí aplican independientemente del LLM que uses, el framework sobre el que construyas, o el dominio en el que opere tu agente.
Los desarrolladores que siguen estos principios consistentemente construyen agentes que funcionan en producción. Los desarrolladores que los ignoran pasan meses depurando sistemas que funcionan en demos y fallan bajo condiciones reales.
Guárdalo. Vuelve a él antes de escribir el próximo agente.