La guía de agentes de Anthropic, capítulo a capítulo

Hace un par de días conté lo que me parece la guía de agentes de Anthropic: dónde acierta, dónde infla el vocabulario y qué me creo de sus cifras. Aquel post era una opinión. Este es lo otro que me pedían varios: el recorrido ordenado, capítulo a capítulo, para quien quiera saber qué hay dentro sin leerse las páginas en inglés.

Aviso de qué es esto y qué no. No es una traducción del documento: es mi resumen estructurado, con mis palabras, siguiendo su mismo orden. Cuando cito literalmente lo verás entrecomillado y en inglés, que es como está en el original. Y sobre todo: léete el original, que es gratis y se baja sin formulario.

• Descarga directa del PDF: Building Effective AI Agents: Architecture Patterns and Implementation Frameworks
• Página oficial: resources.anthropic.com/building-effective-ai-agents
• Y el artículo de ingeniería anterior, del que bebe todo esto: Building Effective AI Agents

Son cinco capítulos. Vamos.

Capítulo 1: resumen ejecutivo

Abre con una frase que resume la tesis entera y que, dicho sea de paso, es buen eslogan: «Generative AI answers questions. AI agents solve problems».

La distinción que establece es la de siempre pero bien planteada. La automatización tradicional necesita guiones rígidos con todos los pasos escritos de antemano. Un agente no: evalúa la tarea, elige herramientas, prueba enfoques, mira el resultado y ajusta. El símil que usa —un empleado competente ante un proyecto que no conoce— es discutible pero se entiende.

Lo que sí me parece útil es dónde sitúa el valor: procesos donde los pasos exactos no se pueden predeterminar. Cita respuesta ante incidentes, análisis de datos, flujos de alta de clientes y desarrollo con tests automáticos que sirven de bucle de realimentación. Fíjate en el último, porque volveré sobre él.

Luego vienen los casos que sostienen el argumento comercial:

• Coinbase, con agentes de atención al cliente que gestionan miles de mensajes por hora manteniendo un 99,99% de disponibilidad; dicen haber generado entre 35 y 50 aplicaciones internas de IA.
• Tines, plataforma de orquestación para equipos de seguridad e IT, que colapsa operaciones multipaso en operaciones de un solo agente con una mejora de 100x en time-to-value.
• Gradient Labs, con agentes de atención para servicios financieros y tasas de resolución del 80-90%.
• Un banco minorista donde los memorandos de riesgo de crédito pasan de semanas revisando diez fuentes a mano a ganancias de productividad del 20-60% y un 30% menos de tiempo de respuesta.

Un apunte de lectura: el párrafo sobre un fabricante europeo de más de 10.000 millones de euros de facturación está cortado a mitad de frase en la maqueta. No es fallo de mi extractor; lo comprobé renderizando la página. En un documento de marketing corporativo eso llama la atención.

Capítulo 2: casos de uso

Es el capítulo más flojo en contenido técnico y el más útil si tienes que convencer a un comité. Un catálogo de implantaciones reales por área:

Programación. Augment Code, sobre Claude en Vertex AI, para navegar bases de código de millones de líneas interdependientes. El dato que citan: un cliente completó en dos semanas un proyecto que su CTO estimaba en cuatro a ocho meses, y la incorporación de desarrolladores nuevos pasó de semanas a uno o dos días.

Análisis de datos. Grafana usa Claude para que cualquiera, del CTO al junior, pregunte en lenguaje natural —«¿cuál es la latencia de mi servicio de checkout?»— y el modelo construya la consulta PromQL o LogQL correspondiente. Este es de los que más me interesan profesionalmente, porque es exactamente el problema de que tus métricas las sepa consultar solo el que las montó.

Atención al cliente. Fin, de Intercom, con hasta un 86% de resolución y un 51% de media sin personalizar, sobre más de 25.000 clientes, bajando tiempos de respuesta de 30 minutos a segundos en más de 45 idiomas. Y Assembled, con un enfoque distinto que me parece más honesto: en vez de desviar consultas simples, atacan las de nivel 2 en adelante, con un 20% más de satisfacción y más de un 50% menos de escalados.

Legal. Thomson Reuters con CoCounsel, y Legora, que reporta un 18% más de rendimiento en su conjunto de evaluación propio y atribuye la mejora a «consistency over large tasks and documents and accurately following complex instructions». Traducido: no es que el modelo sea más listo, es que se desvía menos en trabajos largos. Cualquiera que haya metido un LLM en un proceso real sabe que eso vale más que unos puntos de benchmark.

Marketing. Advolve, orquestando millones de anuncios con validación de datos en tiempo real: 90% menos de trabajo operativo y 15% más de retorno sobre la inversión publicitaria.

Servicios financieros. Inscribe, que reduce el tiempo de revisión de fraude de 30 minutos a 90 segundos —un 20x— con informes auditables. El detalle que me parece el mejor argumento del capítulo entero no es la velocidad: es que eso permite dar crédito a gente sin historial bancario que hoy queda fuera porque revisarla a mano no sale a cuenta.

Capítulo 3: los patrones de arquitectura

Aquí está el ochenta por ciento del valor del documento. Y empieza por los principios, no por los diagramas, que ya dice algo bueno de quien lo escribió.

Los principios de diseño

Empieza simple. Agentes de un solo propósito que hagan una cosa bien, y evolución desde ahí. El argumento no es estético: los sistemas simples cuestan menos en tokens y cómputo, se depuran mejor y dan métricas que se atan a resultados de negocio.

Elige el modelo adecuado. Equilibrio entre capacidad, velocidad y coste, con el símil del martillo y el mazo. La frase operativa: pasar una tarea simple por el modelo premium no solo es un derroche, es además más lento. Y a volumen, esas diferencias se multiplican. Es exactamente lo que decía sobre poner model explícito en tus subagentes.

Diseño modular. Prompts en ficheros de configuración centralizados, herramientas como módulos discretos reutilizables, y agentes que se definen usando solo lo que necesitan. La frase que mejor resume el capítulo: «Your architecture should bend with progress, not break under it».

Skills. Paquetes modulares de capacidad —conocimiento de dominio, flujos estandarizados, integraciones— en vez de meter toda la experiencia en el prompt. Lo interesante es que son componibles: una skill de cumplimiento puede llamar a una de análisis documental, que a su vez llama a una de extracción. Y se actualizan sin reescribir la lógica del agente.

Observabilidad. El apartado que más me ha gustado, porque es el que nadie pone en las presentaciones. Un agente que falla no te deja una traza de pila que leer: necesitas ver cadenas de prompts, rutas de decisión, contextos recuperados, consumo de tokens y el razonamiento entero. Lo dicen sin adornos: depurar esto exige entender no solo qué pasó, sino por qué el modelo decidió lo que decidió. Las herramientas de monitorización tradicionales no se diseñaron para eso.

Los patrones

Agente único. Un bucle: percibir, decidir, actuar. El usuario da una tarea, el agente planifica, ejecuta con las herramientas que tiene, observa el resultado, ajusta, y repite hasta terminar o hasta chocar con una condición de parada, del tipo «aquí párate para revisión humana». Los componentes son tres: el modelo como motor de razonamiento, el prompt que define su papel, y el conjunto de herramientas. Más las Skills como cuarta capa opcional.

Flujos secuenciales. El pipeline de toda la vida: cada etapa alimenta a la siguiente. Sirve para aprobaciones multipaso, cadenas de creación de contenido (borrador → revisión → publicación), transformación y validación de datos, y comprobaciones de cumplimiento con varios criterios.

Paralelización. Cuando las subtareas se pueden trocear y procesar a la vez. Recomendado cuando varias perspectivas mejoran la calidad, cuando los análisis son independientes, cuando la velocidad importa más que el coste de coordinación, y cuando una evaluación de riesgo necesita puntos de vista diversos.

Sistemas jerárquicos o supervisores. Un supervisor que delega en especialistas. El detalle de implementación que más me sirve: los subagentes se tratan como herramientas, y el supervisor usa el mecanismo normal de llamada a herramientas para decidir a cuál invoca. Los subagentes pueden tener sus propios subagentes sin que el supervisor se entere.

Sistemas colaborativos. Agentes autónomos que se comunican entre sí directamente o a través de memoria compartida, sin capa supervisora. El documento reconoce que en pruebas tempranas la arquitectura de enjambre «slightly outperforms supervisor architecture across the board», precisamente por ahorrarse esa capa de traducción. Y avisa del precio: complejidad de comunicación y comportamiento emergente. Traducido a lenguaje de guardia: cosas que pasan y nadie sabe por qué.

El marco de decisión

La parte que recortaría y pegaría en la pared. Anuncia tres preguntas fundamentales y luego enumera cuatro, lo cual es un despiste de edición divertido en un documento sobre rigor arquitectónico. Van las cuatro:

1. ¿Cuánto control necesitas? Requisitos altos —cumplimiento normativo, transacciones financieras, operaciones críticas de seguridad— llevan a agente único o flujo secuencial. El criterio que dan es buenísimo y se lo he robado ya: si vas a tener que explicarle a un auditor exactamente por qué el sistema decidió lo que decidió, quieres comportamiento predecible y trazable. Un agente único aprobando préstamos con criterios claros se audita; tres modelos colaborando en la recomendación, no.

2. ¿Cuán complejo es el dominio? Un dominio → agente único. Varios dominios pero predecibles → flujos secuenciales o paralelos. Problemas abiertos y complejos → multiagente. Con el aviso pegado: no sobreingenieres.

3. ¿Qué restricciones de recursos tienes? Aquí está la cifra que debería salir en todos los titulares en vez de las de productividad: los sistemas multiagente consumen del orden de 10 a 15 veces más tokens que un agente único. «Haz las cuentas con tu volumen esperado antes de comprometerte». Y la de plazos: un agente único se despliega en semanas; un sistema multiagente tarda meses en quedar bien.

4. ¿Necesitas experiencia de dominio profunda? Antes de saltar a multiagente, pregúntate si un solo agente con Skills especializadas resuelve el problema.

La guía de selección y los híbridos

Cierra el capítulo con listas de «esto funciona mejor para» —agente único para atención al cliente con categorías bien definidas, procesamiento documental con reglas claras, revisión de código y análisis rutinario— y con tres combinaciones híbridas que son las que de verdad acaban en producción:

• Jerárquico con procesamiento paralelo: un supervisor de riesgo delega en agentes de crédito, mercado y operacional, cada uno paralelizando dentro de su dominio.
• Secuencial con enrutado dinámico: un flujo lineal que, según el resultado intermedio, deriva a un agente simple o a un equipo multiagente.
• Agente único con escalado a multiagente: lo rutinario lo lleva un agente barato, y los casos raros disparan la maquinaria cara. Optimiza coste sin renunciar a capacidad.

Y una evolución de ejemplo en cinco fases para un comercio electrónico, de agente único a sistema multiagente con agentes evaluadores, que resume la doctrina del documento: empieza simple, mídelo todo, añade complejidad solo cuando entregue valor medible.

Capítulo 4: hacia dónde va esto

Cuatro páginas de cierre sin patrones nuevos. La idea que repite —y que es la que yo firmaría— es que el éxito consiste en alinear la complejidad técnica con el valor de negocio en vez de perseguir la arquitectura más sofisticada que sepas construir. Empezar con agentes únicos para demostrar retorno, construir sistemas observables desde el primer día, y hacer evolucionar la arquitectura según digan los datos.

Dice también, con razón, que las organizaciones que toman ese camino medido rinden mejor de forma consistente que las que sobreingenieran de salida.

Capítulo 5: siguientes pasos

Dos páginas de enlaces a la plataforma de desarrollo de Claude, a la documentación de Agent Skills y demás. Es el capítulo de la llamada a la acción; poco que resumir.

Lo que me llevo del recorrido

Después de leerlo ordenado, mi lectura cambia poco respecto a lo que ya escribí, pero se afina.

El documento es mucho más prudente que su envoltorio. El titular que circula habla de automatizar una empresa entera; el contenido dice, capítulo tras capítulo, que empieces por un agente que haga una cosa, que midas, y que no te compliques. Esa distancia entre la portada y el interior es la parte más instructiva de todo el asunto.

Las dos cifras que valen son las incómodas. No el 100x de Tines ni el 86% de Intercom, que vienen de casos de éxito seleccionados por el proveedor. Son el 10-15x de tokens y el semanas contra meses. Esas dos las puedes meter en una hoja de cálculo mañana y decidir con ellas.

Y la pregunta del auditor es el mejor filtro que ofrece. En mi oficio hay procesos donde un agente autónomo sería estupendo y procesos donde la sola idea es un problema regulatorio. La diferencia no la marca la dificultad técnica: la marca si puedo explicar, a posteriori y ante quien pregunte, por qué el sistema hizo lo que hizo. Con una facturación de telecomunicaciones delante, esa pregunta se responde sola.

Bájatelo y léelo. Son cinco capítulos, se despacha en una tarde, y es de lo poco escrito sobre agentes que recomienda hacer menos en vez de más.