Cómo construir agentes de IA efectivos

• Los equipos que han implementado con éxito agentes basados en LLM tienden a usar patrones simples y combinables en lugar de frameworks complejos.
• Es necesario entender las diferencias estructurales entre workflows y agentes, y se recomienda introducir siempre la mínima complejidad posible para encontrar la solución óptima.
• Diversos patrones de agentes —como prompt chaining, routing, paralelización, orquestador-workers y bucles de evaluación-optimización— se usan en entornos reales de producción, y cada uno tiene casos de uso específicos con ventajas y desventajas.
• Al implementar agentes, los principios clave son la simplicidad, transparencia y diseño de interfaces, además de poner atención al diseño de herramientas y al prompt engineering.
• Cada vez hay más casos en los que los agentes aportan valor real en soporte al cliente y en entornos de desarrollo de software.

---

Resumen general

Durante el último año, Anthropic ha trabajado con equipos de distintas industrias para construir agentes basados en modelos de lenguaje grandes (LLM). En la práctica, los casos exitosos de adopción de agentes han tendido a basarse en patrones simples y combinables, más que en frameworks complejos o bibliotecas especializadas. Este post comparte aprendizajes obtenidos de colaboraciones con clientes y del desarrollo interno, junto con consejos prácticos para construir agentes efectivos.

Qué es un agente

Los agentes pueden definirse de varias maneras.

• Algunos los definen como sistemas completamente autónomos que completan tareas complejas de forma independiente usando herramientas externas.
• Otros los entienden como implementaciones prescriptivas que siguen workflows limitados o procesos previamente definidos.

Anthropic clasifica ambos como sistemas agénticos, pero establece una diferencia arquitectónica importante entre workflows y agentes.

• Workflow: estructura en la que el LLM y las herramientas se orquestan mediante rutas de código predefinidas.
• Agente: estructura en la que el LLM decide dinámicamente cómo usar herramientas y cómo llevar el proceso, manteniendo el control sobre la forma de cumplir la tarea.

Este post explica en detalle ambas formas de sistema, y los casos de aplicación práctica se tratan en el Apéndice 1.

Cuándo usar agentes (y cuándo no)

Al desarrollar aplicaciones, es deseable seguir el principio de mínima complejidad, agregando complejidad de forma gradual solo cuando sea necesario.

• Los sistemas agénticos pueden mejorar el desempeño de la tarea incluso si sacrifican parte de la latencia/costo.
• Si no hace falta complejidad, muchas veces basta con una sola llamada al LLM, ejemplos en el prompt o integración con búsqueda.
• Los workflows son adecuados cuando importan la previsibilidad y la consistencia; los agentes, cuando se necesita flexibilidad y escala.

Cuándo y cómo usar frameworks

Existen varios frameworks que facilitan la implementación de sistemas agénticos.

• LangGraph (LangChain)
• Amazon Bedrock AI Agent framework
• Rivet, Vellum, entre otros

Estos frameworks simplifican tareas de bajo nivel como llamadas al LLM, definición/parsing de herramientas y construcción de cadenas de invocación. Sin embargo, una abstracción excesiva puede hacer que el flujo real de prompts y respuestas se vuelva opaco, o aumentar innecesariamente la complejidad.

• Se recomienda que los desarrolladores comiencen usando directamente la API del LLM tanto como sea posible.
• Incluso si se usa un framework, es importante entender con precisión cómo funciona internamente.

Hay implementaciones de ejemplo en anthropic-cookbook.

Bloques de construcción, workflows y patrones de agentes

Anthropic presenta patrones de sistemas agénticos que se usan con frecuencia en entornos operativos reales.

Bloque de construcción: LLM aumentado

El núcleo de un sistema agéntico es un LLM aumentado con capacidades como búsqueda, herramientas y memoria.

• El modelo puede encargarse por sí mismo de generar consultas de búsqueda, seleccionar la herramienta adecuada y almacenar información.
• Un punto clave al implementarlo es adaptar esas capacidades al caso de uso y ofrecer al LLM una interfaz clara y bien documentada.

Con el recientemente publicado Model Context Protocol, es posible integrar fácilmente diversas herramientas de terceros.

Explicación por tipo de workflow

Prompt chaining

• La tarea se divide en una serie de pasos, y cada llamada al LLM procesa el resultado anterior.
• Se puede gestionar el proceso agregando validaciones programáticas (gates) en cada etapa.
• Ejemplos de uso: generar texto de marketing y luego traducirlo; diseñar un esquema de documento → validarlo → redactar el contenido.

Routing

• Clasifica la entrada y la dirige a tareas posteriores especializadas.
• Permite usar prompts y herramientas específicas para cada categoría.
• Ejemplos de uso: enrutar consultas de clientes (reembolsos, soporte técnico, etc.), seleccionar modelos según el nivel de dificultad.

Paralelización

• Divide una tarea en unidades más pequeñas, las procesa en paralelo y luego agrega los resultados.
• Sectioning: procesa cada parte de manera independiente.
• Voting: repite la misma tarea con varias perspectivas o prompts y usa mayoría u otros mecanismos.
• Ejemplos de uso: filtrar preguntas de usuarios y separar respuestas, evaluación automática, revisión de código.

Orquestador-workers

• Un LLM central descompone y asigna dinámicamente la tarea, mientras varios LLM workers procesan partes y luego combinan resultados.
• Es adecuado para subtareas no predefinidas y variables según la entrada.
• Ejemplos de uso: codificación con cambios en múltiples archivos, exploración compleja de información.

Bucle de evaluación-optimización

• Usa en un bucle repetido un LLM que responde y otro que evalúa.
• Es útil cuando hay criterios de evaluación claros y vale la pena mejorar con base en retroalimentación.
• Ejemplos de uso: evaluar matices sutiles en traducción literaria, exploración de información en múltiples rondas.

Agentes

• Con el avance de los LLM, ya existen agentes en servicios reales capaces de manejar entradas complejas, razonamiento y planificación, uso de herramientas y recuperación ante errores.

• Empiezan con una instrucción o conversación del usuario → aclaran la tarea → la ejecutan de forma autónoma → pueden recibir retroalimentación en puntos intermedios → terminan al completar la tarea o al alcanzar una condición de interrupción.

• En la implementación real, el LLM itera tomando como referencia la retroalimentación del entorno (resultados de herramientas, ejecución de código), y el conjunto de herramientas y su documentación es fundamental.

• Ejemplos de uso: agentes de programación para resolver tareas de SWE-bench, automatización del uso de computadora basada en Claude.

• Ámbito de aplicación: problemas abiertos donde no se puede predecir una ruta o una secuencia fija de pasos, o situaciones donde se requiere confianza en la toma de decisiones.

• También hay que considerar la posibilidad de costos y errores compuestos que aumenta con la autonomía, por lo que son indispensables las pruebas en sandbox y los guardrails.

Combinación y personalización de patrones

• Los bloques de construcción presentados no son reglas rígidas, sino elementos que pueden combinarse según distintas situaciones.
• Lo importante es elegir la estructura óptima mediante medición de resultados y mejora iterativa, agregando complejidad gradualmente.

Resumen y principios recomendados

El éxito de un sistema con LLM no depende de la complejidad ni de usar la tecnología más nueva, sino de encontrar el enfoque correcto para el objetivo.

• Empezar con prompts simples, evaluar resultados, optimizar iterativamente y ampliar la complejidad por etapas.

• Tres principios clave en el diseño de agentes:

  1. Mantener la simplicidad
  2. Priorizar la transparencia (claridad desde la etapa de diseño)
  3. Dar importancia a la documentación y pruebas de herramientas/interfaces

• Los frameworks pueden ayudar a comenzar rápido, pero en la práctica la confiabilidad y el mantenimiento dependen de minimizar la capa de abstracción y tener capacidad de implementación directa.

Apéndice 1: Casos de aplicación de agentes en la práctica

Soporte al cliente

El área de soporte al cliente es naturalmente adecuada para aplicar agentes, ya que combina interfaces tipo chatbot con integración de herramientas.

• Coexisten una interfaz conversacional y la necesidad de acceder a datos externos y ejecutar procesos de negocio.
• Se pueden conectar herramientas para información del cliente, historial de pedidos, bases de conocimiento, etc.
• Se automatizan tareas como reembolsos o gestión de tickets.
• Es posible definir con claridad los criterios de resolución.

Los casos de implementación exitosa validan la efectividad de los agentes mediante modelos de cobro basados en uso, definidos por criterios de resolución exitosa.

Agentes de programación

En entornos de desarrollo de software también ha mejorado mucho el aprovechamiento de agentes para tareas como la resolución automática de problemas.

• El código permite verificar resultados mediante pruebas automatizadas.
• Se puede mejorar iterativamente usando los resultados de las pruebas.
• La definición del problema es clara y la calidad del resultado se puede medir objetivamente.

Caso interno de Anthropic: en el benchmark SWE-bench Verified, resolvió issues reales de GitHub usando únicamente la descripción del pull request. Además de las pruebas automatizadas, la revisión humana sigue siendo importante para verificar si el sistema cumple con los requisitos globales.

Apéndice 2: Cómo hacer prompt engineering para herramientas

En todos los sistemas agénticos, las herramientas son un elemento clave.

• LLM como Claude pueden interactuar con servicios externos desde una API siguiendo con precisión estructuras y definiciones.
• La respuesta puede incluir un tool use block.
• La definición y especificación de herramientas también requiere un diseño tan minucioso como el prompt engineering.

Consejos para diseñar el formato de herramientas

• Asegurar suficientes tokens para que el modelo no caiga en “trampas” al redactar.

• Se recomienda usar formatos naturales y comunes en internet.

• Minimizar la sobrecarga innecesaria de formato, como contar líneas de código o escapar cadenas.

• Así como se invierte en diseñar la interfaz humano-computadora (HCI), también hay que dedicar el mismo cuidado a la interfaz agente-computadora (ACI).

• Desde la perspectiva del modelo, debe ser “claro” cómo entender y usar la herramienta, incluyendo ejemplos de uso, casos límite y formatos de entrada.

• También conviene diseñar nombres de parámetros y descripciones con términos intuitivos, como si se escribieran docstrings.

• Probar el uso real con distintos valores de entrada y mejorar iterativamente.

• Diseñar argumentos para reducir errores (Poka-yoke).

Al construir el agente para SWE-bench, se invirtió más tiempo en optimizar el diseño de herramientas que en el prompt completo. Ejemplo: para reducir errores de rutas de archivos al salir del directorio raíz, se cambió el diseño para aceptar solo rutas absolutas, y después funcionó perfectamente.

[GN⁺]

Comentario de Hacker News

• A este comentario le pareció especialmente impresionante que el texto empezara aclarando la definición de "AI agents". La definición que usa aquí es "un sistema en el que el LLM gestiona dinámicamente por sí mismo los procesos y el uso de herramientas, y controla por su cuenta cómo ejecutar la tarea". También le gustó cómo distingue entre ‘agent’ y ‘workflow’, así como la manera en que presenta varios patrones prácticos de workflow. Cuando el texto salió por primera vez, incluso escribió su propio resumen: notas sobre building-effective-agents. Y recientemente también le pareció interesante el texto de Anthropic sobre cómo construyeron un sistema de investigación multi-agent, y además tiene notas adicionales al respecto: notas sobre multi-agent research system

  • Cree que la definición de workflow que da este texto no es precisa. Hoy en día, muchos motores de workflow no siguen rutas de código predefinidas y en muchos casos funcionan prácticamente igual que un agent. Considera que el autor redefinió workflow con la intención de marcar una diferencia, pero que en la práctica un agent no deja de ser un workflow en forma de bucle que hace llamadas dinámicas según la respuesta del LLM. También sostiene que los motores de workflow modernos son muy dinámicos

  • Uno de los coautores de Building Effective Agents también dio una charla sobre ese texto en AIE, y comparte que la recepción fue muy buena: video de YouTube

  • Dice que el texto sobre investigación multi-agent es realmente muy bueno, pero no está de acuerdo con la afirmación de Building Effective AI Agents de que "construir el sistema desde cero sin framework es mejor desde el punto de vista educativo". Sostiene que una primera ventaja de usar un buen framework es poder probar fácilmente distintos LLMs, y además sin depender de un proveedor específico

  • Pregunta qué framework de AI agent usa Anthropic. Opina que no parece que hayan publicado nunca su framework interno

  • Agradece las notas adicionales y comenta que este tema también se ha vuelto un asunto muy importante para él últimamente

• En AI, medio año se siente larguísimo. Dice que hace unos meses leyó este texto una y otra vez, pero que ahora claramente siente que el desarrollo de agents llegó a un cuello de botella. Opina que incluso el Gemini más reciente parece haber retrocedido en rendimiento

  • Ejecutar varios agents al mismo tiempo sale caro y eso reduce el RoI. Por ejemplo, un DeepSearch agent para acciones usa 6 agents y cuesta alrededor de 2 dólares por consulta. La orquestación multi-agent es difícil de controlar, y si el modelo es más potente, disminuye la necesidad de usar múltiples agents. En cambio, cuanto más débil es el modelo, más aumenta el valor de negocio de una AI especializada y de alcance limitado; comparte esa experiencia real

  • Pregunta por qué siente que los agents retrocedieron. Le intriga por qué simplemente no pueden crear varias copias de sí mismos, trabajar en paralelo 24/7, verificarse y mejorarse continuamente

  • Opina que resolver el problema de prompt injection es extremadamente difícil y que eso se está convirtiendo en un cuello de botella serio

• Tiene curiosidad por cómo los agents manejan task queueing, race condition y otros problemas de concurrencia. Dice que en los artículos sobre construcción de workflows multi-agent suele leerse que un orchestrator agent administra todo, pero siempre se pregunta si en la práctica hace falta un diseño más complejo y glue code más inteligente. O si de verdad todo esto funciona como una especie de “magia automática”

  • Explica que el estándar en los agents es que las herramientas se ejecuten secuencialmente, así que no hace falta preocuparse por problemas de concurrencia. Ahora varios modelos ya admiten llamadas paralelas a herramientas, de modo que si el modelo pide “ejecuta estas tres herramientas”, el harness las ejecuta en paralelo o en secuencia y luego pasa los resultados al siguiente paso. Anthropic está usando con más decisión configuraciones multi-agent, con una estructura en la que un agent superior delega tareas en paralelo a agents subordinados. Este truco se está aplicando en Claude Code, y también se amplía en notas de ingeniería inversa relacionadas (claude-trace) y en un texto sobre cómo funciona Claude Research (multi-agent-research-system). La etapa de descubrir patrones de uso de herramientas por parte de los LLM sigue siendo muy temprana, y además que los modelos se hayan vuelto realmente buenos usando tools es algo de apenas los últimos 6 meses, así que todavía hay mucho margen de mejora

  • Por eso prefiere ir en la dirección de que el propio LLM genere code para manejar las tool calls, en lugar de tratar todo como JSON. La librería smolagents de Huggingface usa un enfoque donde el LLM genera código para llamadas a funciones de Python. Si se quieren llamadas paralelas a tools, basta con indicarlo en el prompt, y el LLM también debe encargarse de la sincronización. Claro, existe el problema de ejecutar código generado por el LLM, pero hay varias soluciones posibles

  • Comparte un caso de uso de la interfaz web de Codex. Tenía un plan de refactorización demasiado largo como para terminarlo de una vez, así que usó la función “ask” para dividirlo en varias tareas y agrupar las que podían hacerse en paralelo. El LLM las repartió de manera parecida a como lo haría un equipo real, pero como no había un supuesto de comunicación entre tareas, la pérdida de contexto fue enorme. Aunque tardó más que hacerlo él mismo, igual lo intentó, pero terminó procesándolo de forma secuencial, dando a varias sesiones prompts detallados para cada tarea (objetivo, método, validación, documentación, etc.). En resumen, comparte la experiencia de que un orchestrator agent puede servir para tareas muy simples, pero su alcance real es más limitado de lo que parece

  • Sostiene que no hay nada que funcione automáticamente como por arte de magia. Dice que las características operativas que hay que cuidar en sistemas tradicionales también deben desarrollarse sí o sí para los AI agents. Advierte que, si uno ve solo demos de AI agents y piensa que puede “reemplazar el código de un equipo de código espagueti con unos cuantos prompts limpios de AI”, puede terminar engañado. En algunos pocos casos puede funcionar, pero al final todo ese código existe por una razón dentro del sistema, y si uno llega al punto de traducir todo ese código al LLM, entonces ya perdió el rumbo

  • En el caso de los coding agents, comenta que se está consolidando como patrón emergente el uso de contenedores para aislar el trabajo, y de git para revisar y hacer merge de los resultados. Como ejemplo menciona un caso de uso de contenedores y MCP: container-use, útil para trabajo de código en paralelo. Para otros trabajos, sigue usándose con frecuencia constructores de workflow como n8n, Zapier y CrewAI

• Este texto le recuerda el mensaje de empezar por “lo más simple” y agregar complejidad real solo cuando haga falta. Menciona la posibilidad de construir sistemas más estables, más fáciles de depurar y más baratos usando llamadas al LLM bien definidas y un poco de glue logic simple. En cambio, los sistemas de agents que se ven vistosos muchas veces terminan causando más problemas

• Expresa la esperanza de que la AI llegue a ser algo que realmente ayude a las personas

• Cree que está bien que Anthropic comparta este tipo de información técnica, pero que también debería ofrecer una versión de guía sencilla para no especialistas. Por ejemplo, aunque un departamento de marketing quiera adoptar agents, necesita una guía para poder definir especificaciones desde un nivel básico. Señala que al final del texto y en el apéndice sí hay algo relacionado, pero que aun así sigue quedándose en el plano de la implementación de “cómo construirlo”

• (Diciembre de 2024: comenta que ahora, al pensarlo, parece de hace muchísimo tiempo)

  • Jajaja, entonces ahora volvemos a tener que usar la cabeza otra vez y escribir el 100% del código manualmente, como cavernícolas, en diciembre de 2024 comentario relacionado

  • Opina que este texto ha resistido muy bien el paso del tiempo. Personalmente lo sigue usando como material de referencia y no le parece anticuado aunque haya pasado el tiempo. Lo evalúa como un texto que dio una nueva impresión de Anthropic como un “socio práctico para desarrollar herramientas de AI”

• Considera que el hype alrededor de los agents ya se ha calmado bastante

  • Diagnostica que ahora todo el mundo se interesa más bien por la AI Agency

• Comparte el dato de que este texto ya había sido discutido en ese momento: discusión original en HN

• Le gusta que este texto haya abordado el tema de forma realista, sin exageraciones ni siguiendo modas. Es crítico con la tendencia de mucha gente a construir sistemas de agents por seguir la moda, sin preguntarse antes si esa tarea realmente necesita un agent