Antonio Gullí es el director de ingeniería de Google. Escribió un libro de 453 páginas que desglosa el desarrollo de AI Agent en 21 patrones de diseño. Pero esta no es una reseña del libro. Mi motivación para leer este libro es muy específica: he escrito sobre Harness Engineering, sobre la experiencia de Clawdbot, sobre el artículo «El agente inteligente de IA no es magia», que trata de los siete puntos de inflexión desde la quema de Token hasta la verdadera utilidad. Después de cada artículo, siempre había una pregunta que no había resuelto por completo: ¿existe una lógica subyacente reutilizable detrás de todo esto? Este libro me dio la respuesta, y es más profunda de lo que pensaba.

Es posible que lo que estés escribiendo no sea un Agent en absoluto. El juicio más duro del libro está oculto en el prólogo. La mayoría de la gente está usando «IA» que es solo Level 0: LLM desnudo, sin herramientas, sin memoria, sin capacidad de actuar. Le preguntas cuál será la mejor película en los Oscar de 2025 y te da una suposición. El libro lo dice sin rodeos: las cosas de Level 0 no son Agent. Subir de nivel es lo que convierte algo en un verdadero Agent:

Level 1: Usuario de herramientas. El Agent empieza a usar herramientas: búsqueda, API, bases de datos. Pero no se trata solo de «poder ajustar las interfaces», sino de juzgar cuándo debe ajustarlas, qué debe ajustar y cómo debe usar los resultados. El libro da un ejemplo muy concreto: un usuario pregunta «qué series nuevas hay últimamente», el Agent se da cuenta de que esta información no está en los datos de entrenamiento, toma la iniciativa de usar la herramienta de búsqueda para encontrarla y luego sintetiza los resultados. El paso clave es «darse cuenta por sí mismo». No es que un humano le diga «ve a buscar», sino que él mismo juzga que necesita buscar. Esta capacidad de juicio es el umbral del Level 1.

Level 2: Pensador estratégico. Tiene dos cosas más: planificación e Context Engineering. El libro define Context Engineering: no se trata de apilar información, sino de seleccionar, recortar y empaquetar cuidadosamente el contexto. El ejemplo es muy bueno: un usuario quiere encontrar una cafetería entre dos lugares. El Agent primero ajusta la herramienta de mapas para obtener un montón de datos, y luego juzga que «el siguiente paso solo necesita el nombre de la calle», recorta la salida del mapa en una lista corta y la introduce en la herramienta de búsqueda local. Cada paso está haciendo reducción de ruido de la información. Hay una frase en el libro que he leído varias veces: «Para que la IA alcance la máxima precisión, hay que darle un contexto corto, enfocado y potente». Context Engineering es lo que hace esto. En este nivel, el Agent también puede autorreflexionar. Después de terminar el trabajo, lo revisa él mismo y, si encuentra un problema, lo corrige.

Level 3: Colaboración multi-Agent. La postura del libro es muy clara: no pienses siempre en crear un super agent todopoderoso. La forma realmente fiable de hacerlo es como montar un equipo: Project Manager Agent + Researcher Agent + Designer Agent + Copywriter Agent. El libro pone como ejemplo el lanzamiento de un nuevo producto: un «Project Manager Agent» hace la programación general y delega tareas a «Market Research Agent», «Product Design Agent» y «Marketing Agent». La clave es la comunicación: cómo se transmiten los datos entre los Agent, cómo se sincronizan los estados, cómo se gestionan los conflictos. Este capítulo dibuja seis topologías de comunicación, desde el Agent único más simple hasta el híbrido personalizado más flexible, y explica qué escenario es adecuado para cada una.

Después de leer estos cuatro niveles, de repente entiendo por qué mucha gente dice «mi Agent no funciona bien». El modelo no es el problema, el problema es que lo estás usando como un chatbot, y puede que ni siquiera haya llegado al Level 1.

Context Engineering: el concepto más subestimado del libro. He escrito un artículo sobre Harness Engineering, que trata de 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 la representación de Harness Engineering a nivel de prompt. El Prompt Engineering tradicional solo se ocupa de «cómo preguntas». El Context Engineering del libro se ocupa de «qué tiene el Agent delante antes de preguntar». Incluye cuatro capas de información: la primera capa, system prompt. Define quién es el Agent, qué tono tiene y cuáles son sus límites. La mayoría de la gente solo escribe esta capa. La segunda capa, datos externos. Documentos recuperados por RAG, valores devueltos por llamadas a herramientas, datos de API en tiempo real. Aquí es donde la mayoría de la gente se atasca: saben que tienen que introducir datos, pero no saben cómo introducirlos para no ahogar el modelo. La tercera capa, datos implícitos. Identidad del usuario, historial de interacciones, estado del entorno. Cosas que no has dicho explícitamente pero que el Agent debería saber. Por ejemplo, si le dices al Agent «ayúdame a enviar un correo electrónico a John para confirmar la reunión de mañana», debería saber qué reunión tienes en tu calendario para mañana y cuál es tu relación con John. La cuarta capa, bucle de retroalimentación. Después de cada salida, el Agent evalúa automáticamente la calidad y ajusta la estrategia de contexto para la siguiente vez. El libro llama a esto «optimización automatizada del contexto», y Vertex AI Prompt Optimizer de Google es la realización de ingeniería de esta idea. Cuando leí esto, recordé el artículo que escribí antes, «El agente inteligente de IA no es magia», en el que una de las experiencias era «tu agente inteligente necesita reglas, y muchas reglas». Ahora, mirando hacia atrás, esas reglas son esencialmente una versión manual de Context Engineering, y el libro lo sistematiza.

Reflection: dos Agent son realmente mejores que uno. Este es el patrón más valioso para mí en todo el libro. El núcleo de Reflection es muy simple: el Agent revisa su propio trabajo después de terminarlo, y si encuentra un problema, lo corrige él mismo. Pero la forma de implementarlo es importante. El libro dice explícitamente: el Producer y el Critic deben usar dos Agent diferentes, dando diferentes system prompt. La misma persona que revisa sus propias cosas debe tener puntos ciegos. Si dejas que el mismo LLM escriba primero el código y luego revise el código que ha escrito, lo más probable es que diga «está bien». El libro da un ejemplo de código completo. El prompt del Producer es «eres un desarrollador de Python, escribe una función para calcular el factorial, manejando las condiciones de contorno y las excepciones». El prompt del Critic es «eres un ingeniero senior quisquilloso, revisa el código línea por línea, comprueba si hay errores, estilo, condiciones de contorno omitidas, áreas de mejora. Si es perfecto, imprime CODE_IS_PERFECT, de lo contrario, enumera todos los problemas». Luego hay un bucle for: Producer escribe el código → Critic revisa → Producer modifica según los comentarios → Critic revisa de nuevo → hasta que Critic diga CODE_IS_PERFECT o se alcance el número máximo de iteraciones. Es así de simple. Pero el libro advierte de un problema de costes que se pasa por alto fácilmente: cada bucle de reflexión es una nueva llamada a LLM, y cuantas más iteraciones, más caro. Y a medida que el historial de la conversación se expande, la ventana de contexto se llena de versiones anteriores y comentarios críticos, y el espacio de razonamiento realmente disponible se reduce. 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 una vez que el Critic esté satisfecho, no buscar la perfección. Los usos van mucho más allá de la escritura de código. Escribir artículos, hacer planes, resumir documentos, resolver problemas de lógica, el modelo Producer-Critic puede aplicarse a todos ellos. El libro enumera siete escenarios de aplicación, con la misma lógica central: primero producir, luego revisar y luego corregir.

Multi-Agent no es cuanto más complejo, mejor. Lo que más me gusta del capítulo de Multi-Agent Collaboration son esos seis diagramas de topología de comunicación. Mucha gente empieza con cosas complejas, pero en realidad tres son suficientes para la mayoría de los escenarios: Agent único (ejecución independiente): las tareas pueden dividirse en subproblemas independientes, y cada Agent se encarga de lo suyo. Simple, fácil de mantener. Red entre pares (Peer-to-Peer): los Agent se comunican directamente entre sí, sin un nodo de control central. Descentralizado, buena tolerancia a fallos, si un Agent falla no afecta a la situación global. Pero los costes de coordinación son altos y es fácil que se produzca el caos. Supervisor (programación central): un Supervisor Agent gestiona un grupo de Worker Agent. Asigna tareas, recopila resultados, resuelve conflictos. Jerarquía clara, fácil de gestionar. Pero el Supervisor es un punto único de fallo y también un cuello de botella de rendimiento. Las otras tres (Supervisor-as-Tool, jerárquico, híbrido personalizado) son variaciones y combinaciones de las tres primeras. El libro lo dice de forma muy realista: la estructura de topología que necesitas depende de la complejidad de tu tarea. Cuanto más se divida la tarea, mayores serán los costes de comunicación, y hasta cierto punto el modo Supervisor es más eficiente que el jerárquico. Mi experiencia es que mucha gente dedica el 80% del tiempo a los protocolos de comunicación cuando construye Multi-Agent, y se olvida de hacer una pregunta más básica: ¿esta tarea realmente necesita múltiples Agent? El libro lo deja muy claro, un Agent único de Level 2 + Reflection suele ser suficiente. Level 3 está preparado para aquellos escenarios en los que un Agent único realmente no puede hacerlo. El problema de la mayoría de la gente no es que no tengan suficientes Agent, sino que no han ajustado bien ni siquiera un Agent.

Modelo de tres capas de Memory, que antes sentía vagamente pero no había nombrado. El capítulo de Memory es con el que más me identifico, porque cuando escribí esos dos artículos de Obsidian + Claude, estuve pensando en una pregunta: ¿cómo debo estratificar la memoria del Agent? El libro da la respuesta: Session (capa de conversación): la ventana de contexto de la conversación actual, esta es la memoria más corta, desaparece cuando termina la conversación. Los modelos de contexto largo solo han ampliado esta ventana, pero esencialmente sigue siendo temporal, y cada inferencia tiene que procesar toda la ventana, lo que es caro y lento. State (capa de estado): datos temporales en curso de la tarea actual. Por ejemplo, «qué tarea se está haciendo», «qué paso se ha completado» y «qué datos se han generado en el medio». Más largo que Session, pero se limpia cuando termina la tarea, el libro da un ejemplo completo usando el mecanismo State de Google ADK. Memory (capa persistente): memoria a largo plazo entre sesiones y entre tareas. Preferencias del usuario, experiencias aprendidas, decisiones históricas importantes, almacenadas en una base de datos o base de datos vectorial, recuperación semántica. El libro destaca un punto muy importante: Memory no es solo almacenar, sino también diseñar un conjunto completo de estrategias de «qué almacenar, cuándo almacenar, cómo recuperar». Almacenar demasiado genera mucho ruido, almacenar demasiado poco no es suficiente. En el artículo que escribí antes sobre Clawdbot, mencioné los «archivos de estado» y los «documentos del área de trabajo», que son esencialmente capas State y capas Memory hechas a mano, y el libro enmarca este asunto.

Cinco suposiciones, la quinta es la más descabellada. El libro termina con cinco suposiciones sobre el futuro de Agent, las cuatro primeras todavía están dentro de un rango de deducción razonable: Agent de propósito general desde la escritura de código hasta la gestión de proyectos, descubrimiento proactivo de tus necesidades con personalización profunda, la inteligencia encarnada sale de la pantalla y entra en el mundo físico, Agent se convierte en una entidad económica independiente. La quinta me sorprendió: Multi-Agent transformable. Solo declaras el objetivo, por ejemplo, «crear un negocio de comercio electrónico que venda café de especialidad». El sistema decide automáticamente: primero crear «Market Research Agent» y «Brand Agent». Después de ejecutar una ronda de datos, juzga que Brand Agent ya no es necesario y lo divide en tres nuevos: «Logo Design Agent», «Website Building Agent» y «Supply Chain Agent». Si Website Building Agent se convierte en un cuello de botella, el sistema copiará automáticamente tres Agent paralelos para hacer diferentes páginas al mismo tiempo. A lo largo de todo el proceso, el sistema optimiza continuamente y de forma automática el prompt de cada Agent, y reestructura constantemente la arquitectura del equipo. El libro llama a esto «sistema multi-Agent autodirigido y autotransformable». No está ejecutando el plan que has escrito, sino que está generando su propio plan, ajustando su propio plan y reorganizando su propio equipo de ejecución. Esto me recuerda a AutoResearch de Karpathy: escribe un program.md, define objetivos, métricas, límites y pulsa «start». Los humanos están fuera del bucle. Pero este libro va más allá: incluso cómo se construye el equipo de Agent y cómo se reestructura se deja que lo decida el propio sistema. Los humanos solo declaran «qué quieren».

Tres cosas que puedes hacer de inmediato. Después de leer este libro, tengo tres acciones que puedo implementar de inmediato: Primero, añade un Critic a tu Agent actual. Tanto si estás usando Claude Code, CrewAI o tu propio framework, añade un paso al final de tu workflow existente: deja que otro Agent (usando un system prompt diferente) revise la salida del paso anterior. Generación de código más revisión de código, redacción de artículos más verificación de hechos, planificación más revisión de viabilidad. Una llamada más a LLM, pero la mejora de la calidad suele ser el doble. El patrón Producer-Critic del libro es plug-and-play. Segundo, empieza a hacer Context Engineering, no solo Prompt Engineering. Vuelve a mirar el archivo de instrucciones que escribiste para el Agent. Si todo son reglas de «cómo debes hacer», y falta el contexto de «a qué entorno te enfrentas ahora», complétalo. Dile al Agent en qué proyecto está ahora, qué decisiones ha tomado antes, cuáles son las preferencias del usuario. El capítulo de Context Engineering del libro y tu AGENTS.md son dos expresiones de la misma cosa. Tercero, no te apresures a usar Multi-Agent. Lleva tu Agent único al Level 2: ten herramientas, ten Reflection, ten Memory. El libro enfatiza repetidamente que un Agent único de Level 2 más Producer-Critic y Context Engineering puede cubrir la gran mayoría de los escenarios reales. Level 3 está preparado para tareas que realmente son intersectoriales, multifase y requieren división paralela del trabajo. El problema de la mayoría de la gente no es que no tengan suficientes Agent, sino que no han ajustado bien ni siquiera un Agent.

Este libro tiene 453 páginas y será publicado por Springer en 2025. Los ejemplos de código cubren LangChain/LangGraph, Google ADK, CrewAI, OpenAI API. El prólogo está escrito por el VP de Google Cloud AI, y también hay un prólogo recomendado por el CIO de Goldman Sachs, que es sorprendentemente bueno. Pero la razón por la que lo recomiendo no es que sea «completo». Es que después de leerlo te darás cuenta de una cosa: los problemas que has tenido con Agent en los últimos seis meses, alguien los ha organizado en patrones. No necesitas volver a inventar Reflection, no necesitas volver a adivinar cómo estratificar Memory, no necesitas volver a probar qué topología de comunicación debes usar para Multi-Agent. Alguien ha dibujado un mapa para ti, el resto es caminar. ¿Estás usando AI Agent para el desarrollo? ¿En qué Level está tu Agent actual?

[Yanhua]