Autor: Yanhua
Antonio Gullí es el director de ingeniería de Google. Escribió un libro de 453 páginas que descompone el desarrollo de agentes de IA en 21 patrones de diseño.
Pero esto no es una reseña de libro. Mi motivación para leer este libro era muy específica: he escrito Harness Engineering, he escrito sobre las lecciones aprendidas con Clawdbot, he escrito el artículo “Los agentes de IA no son magia”, que detalla los siete giros desde quemar tokens hasta lograr algo realmente útil; después de cada uno, siempre quedaba una pregunta que no había resuelto por completo: ¿hay alguna lógica subyacente reutilizable detrás de todo esto?
This book gave me the answers, and deeper than I thought.
Lo que escribiste probablemente no sea un Agent
La evaluación más contundente del libro está escondida en el prólogo.
La mayoría de las personas usan lo que llaman “IA” como Level 0: un LLM desnudo, sin herramientas, sin memoria, sin capacidad de acción. Le preguntas cuál será la mejor película de la Oscar en 2025 y él adivina. El libro lo dice muy claramente: lo que es Level 0, no es un Agent.
Subir es el verdadero agente:
Nivel 1: Usuario de herramientas
El agente comienza a usar herramientas: búsqueda, API, base de datos. Pero no se trata solo de “poder llamar a interfaces”, sino de decidir por sí mismo cuándo llamarlas, qué llamar y cómo utilizar los resultados. El libro proporciona un ejemplo muy concreto: el usuario pregunta “¿Qué nuevos programas hay recientemente?”, y el agente se da cuenta de que esta información no está en sus datos de entrenamiento, por lo que activamente llama a la herramienta de búsqueda y sintetiza el resultado. El paso clave está en “darse cuenta por sí mismo”. No es que un humano le diga “busca esto”, sino que él mismo decide que necesita buscar. Esta capacidad de juicio es el umbral del Nivel 1.
Nivel 2: Pensador estratégico
Dos cosas más: planificación y Context Engineering. El libro define Context Engineering como no acumular información, sino seleccionar, recortar y empaquetar cuidadosamente el contexto. Un ejemplo muy acertado: el usuario busca una cafetería entre dos ubicaciones. El agente primero llama a una herramienta de mapas para obtener una gran cantidad de datos, luego decide por sí mismo que “solo se necesitan los nombres de las calles”, recorta la salida del mapa en una lista corta y la proporciona a una herramienta de búsqueda local. Cada paso realiza una reducción de ruido informativo.
En el libro hay una frase que leí varias veces: “Para que la IA alcance la máxima precisión, debe recibir un contexto breve, enfocado y potente.” La ingeniería de contexto es precisamente lo que hace esto.
A este nivel, el agente aún puede reflexionar sobre sí mismo. Después de completar la tarea, revisa su propio trabajo y corrige los problemas por sí mismo. Lo explicaré con más detalle más adelante.
Nivel 3: Colaboración de múltiples agentes
La postura del libro es clara: no insistas en crear un super agente universal. El enfoque verdaderamente confiable es construir un equipo, con un agente gerente de proyecto + un agente investigador + un agente diseñador + un agente redactor. El ejemplo que presenta el libro es el lanzamiento de un nuevo producto: un "agente gerente de proyecto" coordina todo y asigna tareas al "agente de investigación de mercado", al "agente de diseño de producto" y al "agente de marketing". Lo clave es la comunicación: ¿cómo intercambian datos los agentes, cómo sincronizan su estado y cómo resuelven conflictos? Este capítulo presenta seis estructuras de comunicación, desde el agente único más simple hasta la mezcla personalizada más flexible, con explicaciones sobre qué escenario es adecuado para cada una.
Después de ver estos cuatro niveles, de pronto entiendo por qué mucha gente dice “mi agente no funciona bien”. El modelo no tiene problema; el problema es que lo estás usando como un chatbot, y probablemente ni siquiera llegue al Nivel 1.
Engineering de contexto: el concepto más subestimado del libro
He escrito un artículo sobre Harness Engineering, que explica que el diseño de la pista es más importante que la potencia del motor. Después de leer este libro, me di cuenta de que Context Engineering es el equivalente de Harness Engineering en el nivel de los prompts.
La ingeniería de prompts tradicional solo se ocupa de "cómo haces la pregunta". La ingeniería de contexto del libro se ocupa de "qué tiene el agente frente a él antes de hacer la pregunta". Incluye cuatro niveles de información:
Primera capa, system prompt. Define quién es el Agent, qué tono y qué límites tiene. La mayoría solo escribe esta capa.
Capa dos, datos externos. Documentos recuperados por RAG, valores devueltos por llamadas a herramientas, datos de API en tiempo real. Este es el punto donde la mayoría se atascan: saben que deben alimentar datos, pero no saben cómo hacerlo sin abrumar al modelo.
Tercer nivel, datos implícitos. Identidad del usuario, historial de interacciones, estado del entorno. Cosas que no dices explícitamente pero que el Agente debería saber. Por ejemplo, si le dices al Agente: “Ayúdame a enviar un correo a John para confirmar la reunión de mañana”, él debería saber qué reunión tienes programada para mañana en tu calendario y cuál es tu relación con John.
Cuarta capa, bucle de retroalimentación. Después de cada salida del agente, se evalúa automáticamente la calidad y se ajusta la estrategia de contexto para la próxima vez. El libro llama a esto “optimización automática del contexto”, y el Vertex AI Prompt Optimizer de Google es una implementación ingenieril de este enfoque.
Cuando leí esto, recordé el artículo que escribí anteriormente titulado "Los agentes de IA no son magia", en el que una de las lecciones era "Tu agente necesita reglas, y muchas reglas". Ahora, al mirar atrás, esas reglas eran esencialmente la versión manual de Context Engineering, y el libro las sistematiza.
Reflection: Dos Agentes realmente son mejores que uno
Este es el patrón más práctico del libro para mí.
El núcleo de Reflection es sencillo: el Agent revisa su propio trabajo después de completarlo y corrige los problemas por sí mismo. Pero la implementación requiere cuidado. El libro especifica claramente: Producer y Critic deben ser dos Agentes distintos, con diferentes system prompt. Un mismo persona revisando su propio trabajo siempre tendrá ciegas. Si le pides al mismo LLM que escriba código y luego lo revise, probablemente dirá: “está bien”.
The book provides a complete code example.
El prompt del productor es “Eres un desarrollador de Python, escribe una función para calcular el factorial, manejando condiciones límite y excepciones”.
El prompt de Critic es: “Eres un ingeniero senior exigente que revisa línea por línea el código, buscando errores, estilo, condiciones límite omitidas y áreas de mejora. Si es perfecto, emite
CODE_IS_PERFECT; de lo contrario, enumera todos los problemas”.Luego hay un bucle for: Producer escribe el código → Critic revisa → Producer ajusta según los comentarios → Critic vuelve a revisar → hasta que Critic diga
CODE_IS_PERFECTo se alcance el número máximo de iteraciones.
Así de simple. Pero el libro advierte sobre un costo fácilmente ignorado: cada ciclo de reflexión es una nueva llamada al LLM, y cuantas más iteraciones, más caro se vuelve. Además, a medida que el historial de la conversación crece, la ventana de contexto se llena con versiones anteriores y opiniones críticas, reduciendo el espacio real disponible para el razonamiento. Por lo tanto, la mejor práctica para Reflection es: establecer un número máximo razonable de iteraciones (el libro usa 3), y detenerse tan pronto como el Critic esté satisfecho, sin buscar la perfección.
El uso va mucho más allá de escribir código. Escribir artículos, hacer planes, resumir documentos, resolver problemas lógicos: el modelo Producer-Critic se puede aplicar a todos ellos. El libro enumera siete escenarios de aplicación, y la lógica central es la misma: primero producir, luego revisar y finalmente corregir.
Multi-Agent no es tanto más complejo, mejor
Lo que más me gustó de este capítulo fueron los seis gráficos de topología de comunicación. Mucha gente empieza con cosas complejas, pero en realidad la mayoría de los escenarios solo necesitan tres:
Agente único (ejecución independiente): la tarea se puede dividir en subproblemas independientes, cada agente se encarga de su propio trabajo. Simple y fácil de mantener.
Red peer-to-peer: Los agentes se comunican directamente entre sí sin un nodo de control central. Descentralizada, con buena tolerancia a fallos; la caída de un agente no afecta al sistema en su conjunto. Sin embargo, el costo de coordinación es alto y puede volverse desordenada.
Supervisor (programación central): Un agente Supervisor gestiona un grupo de agentes Worker. Asigna tareas, recopila resultados y resuelve conflictos. Jerarquía clara, fácil de gestionar. Pero el Supervisor es un punto único de fallo y un cuello de botella de rendimiento.
Las otras tres (Supervisor-as-Tool, jerárquica y híbrida personalizada) son variantes y combinaciones de las primeras tres. El libro lo dice con claridad: la topología que necesitas depende de la complejidad de tu tarea. Cuanto más fragmentes la tarea, mayor será el costo de comunicación; hasta cierto punto, el modelo Supervisor resulta más eficiente que el jerárquico.
Mi experiencia es que muchas personas dedican el 80% del tiempo a los protocolos de comunicación al construir Multi-Agent, olvidándose de hacer una pregunta más básica: ¿realmente necesita esta tarea múltiples Agentes? El libro lo explica claramente: un solo Agente de Nivel 2 + Reflection suele ser suficiente. El Nivel 3 está diseñado para escenarios en los que un solo Agente realmente no puede lograrlo.
Modelo de tres capas de Memory, antes tenía una sensación vaga pero no lo había nombrado
El capítulo de Memory es el que más me resuena, porque mientras escribía los dos artículos sobre Obsidian + Claude, estuve reflexionando constantemente sobre una pregunta: ¿cómo deberían estructurarse las memorias de un Agente?
El libro da la respuesta:
Sesión (capa de sesión): La ventana de contexto de la conversación actual, que es la memoria más corta y desaparece al finalizar la conversación. Los modelos de contexto largo simplemente amplían esta ventana, pero siguen siendo temporales por naturaleza, y cada inferencia requiere procesar toda la ventana, lo que resulta costoso y lento.
Estado (capa de estado): Datos temporales durante la ejecución de la tarea actual. Por ejemplo, “¿qué tarea se está realizando?”, “¿en qué paso se ha llegado?”, “¿qué datos se generaron en el proceso?”. Es más duradero que la sesión, pero se limpia al finalizar la tarea. El libro incluye un ejemplo completo utilizando el mecanismo de Estado de Google ADK.
Memoria (capa de persistencia): memoria a largo plazo que trasciende sesiones y tareas. Las preferencias del usuario, las experiencias aprendidas y las decisiones históricas importantes se almacenan en bases de datos o bibliotecas vectoriales mediante recuperación semántica. El libro enfatiza un punto muy importante: la memoria no solo consiste en almacenar, sino también en diseñar una estrategia integral sobre “qué almacenar, cuándo almacenarlo y cómo recuperarlo”. Almacenar demasiado genera ruido; almacenar demasiado poco resulta insuficiente.
En el artículo que escribí anteriormente sobre Clawdbot, mencioné los "archivos de estado" y "documentos del entorno de trabajo", que en esencia son implementar manualmente las capas State y Memory; el libro estructuró este proceso.
Cinco suposiciones, la quinta es la más absurda
Al final del libro se plantean cinco suposiciones sobre el futuro de los Agentes; las primeras cuatro aún se mantienen dentro del rango de inferencia razonable: Agentes generales que pasan de escribir código a gestionar proyectos, descubrimiento activo y profundamente personalizado de tus necesidades, inteligencia encarnada que sale de la pantalla y entra en el mundo físico, y Agentes que se convierten en entidades económicas independientes.
El quinto me dejó impactado: Multi-Agent变形.
Solo declara el objetivo, por ejemplo: "Crear un negocio de comercio electrónico de café de alta gama". El sistema decide automáticamente: primero crea el "Agente de investigación de mercado" y el "Agente de marca". Tras ejecutar un ciclo de datos, determina automáticamente que el Agente de marca ya no es necesario y lo divide en tres nuevos: "Agente de diseño de logotipo", "Agente de creación de sitio web", "Agente de cadena de suministro". Si el Agente de creación de sitio web se convierte en un cuello de botella, el sistema copia automáticamente tres agentes en paralelo para trabajar simultáneamente en diferentes páginas. Durante todo el proceso, el sistema ajusta automáticamente las indicaciones de cada agente y reorganiza continuamente la estructura del equipo.
El libro lo llama "sistema multi-agente orientado a objetivos y autotransformable". No está ejecutando el plan que escribiste, sino generando su propio plan, ajustándolo y reorganizando su equipo de ejecución.
Esto me recuerda a AutoResearch de Karpathy: escribe un program.md, define objetivos, métricas y límites, y luego "inicia". El humano está fuera del ciclo. Pero este libro va más lejos: incluso cómo formar y reorganizar al equipo de Agentes lo decide el sistema por sí mismo. El humano solo declara "qué quiere".
Tres cosas que puedes hacer ahora mismo
Después de leer este libro, tengo tres acciones inmediatas que puedo implementar:
En primer lugar, agrega un Critic a tu Agent actual. Ya sea que uses Claude Code, CrewAI o un marco propio, añade un paso al final de tu flujo de trabajo actual: haz que otro Agent (con un prompt de sistema diferente) revise la salida del paso anterior. Generación de código con revisión de código, redacción de artículos con verificación de hechos, planificación con evaluación de viabilidad. Una llamada adicional a LLM, pero la calidad suele duplicarse. El modelo Producer-Critic del libro es plug-and-play.
En segundo lugar, comienza con la ingeniería de contexto, no solo con la ingeniería de indicaciones. Revisa el archivo de instrucciones que le escribiste al agente. Si solo contiene reglas del tipo “¿cómo debes hacerlo?” y carece de contexto sobre “¿qué entorno enfrentas ahora?”, añádelo. Indica al agente en qué proyecto se encuentra, qué decisiones tomó anteriormente y cuáles son las preferencias del usuario. El capítulo sobre ingeniería de contexto del libro y tu
AGENTS.mdson dos formas de expresar lo mismo.Tercero, no te apresures a pasar a Multi-Agent. Lleva tu Agent único al Nivel 2: con herramientas, Reflexión y Memoria. El libro enfatiza repetidamente que un Agent único de Nivel 2, combinado con Producer-Critic y Context Engineering, cubre la mayoría de los escenarios prácticos. El Nivel 3 está diseñado para tareas verdaderamente interdisciplinarias, con múltiples etapas y que requieren división paralela de tareas. El problema de la mayoría no es que no haya suficientes Agentes, sino que ni siquiera han ajustado bien un solo Agent.
Este libro tiene 453 páginas y fue publicado por Springer en 2025. Los ejemplos de código cubren LangChain/LangGraph, Google ADK, CrewAI y OpenAI API. La introducción está escrita por el VP de AI de Google Cloud, y cuenta con una próloga recomendada por el CIO de Goldman Sachs, sorprendentemente muy buena.
Pero la razón por la que lo recomiendo no es “completo”. Al leerlo, te darás cuenta de una cosa: todos los obstáculos que has enfrentado en Agentes durante los últimos seis meses ya han sido organizados en patrones. No necesitas volver a inventar Reflection, no necesitas adivinar cómo dividir Memory, ni necesitas probar qué topología de comunicación usar en Multi-Agent.
Alguien ya te dibujó el mapa, lo único que queda es caminar.
¿Estás desarrollando con un AI Agent? ¿A qué nivel llegó tu Agent actualmente?