Modelo de madurez de agentes: Supervisión humana, Ingeniería de herramientas, Orquestación.
Cinco niveles de madurez de los agentes probados en producción: supervisión humana, ingeniería de herramientas, orquestación de múltiples agentes y los problemas aún sin resolver.
Fuentes: Agentic Architectures — Article 15: The Maturity Model Revisited
Un modelo de madurez de agentes es fácil de dibujar, pero difícil de implementar en la práctica. Sobre el papel parece sencillo: una escalera que comienza con herramientas básicas y termina con sistemas de producción capaces de mejorar por sí mismos. Los frameworks siempre se ven ordenados antes de que alguien intente ejecutarlos bajo carga. Una vez que hay código real detrás de ellos, el mismo modelo adquiere un significado distinto. No estaba equivocado, pero conocer algo en teoría y conocerlo en la producción son tipos diferentes de conocimiento. Un mapa no puede indicarte cómo se siente el camino a las tres de la madrugada, cuando un disyuntor no se cierra y tú eres quien debe hacerse cargo de la situación.
Este es un repaso a dicho modelo una vez que se han construido las capas subyacentes: cómo se alinean los niveles con el trabajo de ingeniería, qué creencias no sobrevivieron al contacto con la producción, cómo se ve una arquitectura de referencia en capas y qué queda sin resolver. El código aquí es mínimo. El objetivo es dar un paso atrás y ver toda la estructura.
Cinco niveles, cada uno apoyado en el anterior
El modelo de madurez describe cinco niveles de capacidad del agente. Cada nivel es más que una versión mejorada del anterior, ya que también depende de todo lo que hay debajo de él. No se pueden saltar pasos. Un agente no puede ser realmente autónomo sin una infraestructura de evaluación, ni puede mejorar por sí mismo sin memoria. Los niveles se acumulan.
Así es como los temas de ingeniería se relacionan con ellos:
+---------+---------------------+------------------------------------------+
| Level | Capability | Articles That Build It |
+---------+---------------------+------------------------------------------+
| Level 1 | Reactive | Article 4: Protocols (MCP, A2A) |
| | Responds to inputs, | Basic tool use, standard interfaces |
| | calls tools | |
+---------+---------------------+------------------------------------------+
| Level 2 | Assisted | Article 5: Harness Engineering |
| | Shaped behavior, | Article 13: Human-in-the-Loop |
| | human oversight | |
+---------+---------------------+------------------------------------------+
| Level 3 | Supervised | Article 6: Multi-Agent Orchestration |
| | Coordinated, | Article 8: Evaluation Pipelines |
| | evaluated, secured | Article 9: Security and Red-Teaming |
+---------+---------------------+------------------------------------------+
| Level 4 | Autonomous | Article 7: Memory Architectures |
| | Operates | Article 10: Cost Optimization |
| | independently at | Article 11: Deployment Patterns |
| | scale | Article 14: Goal-Directed Loops |
+---------+---------------------+------------------------------------------+
| Level 5 | Self-Improving | Articles 7 + 8 combined |
| | Learns from its own | Article 12: The frontier (not yet here) |
| | operation | |
+---------+---------------------+------------------------------------------+
La forma es más importante que la mapeación. El nivel 5, la auto-mejora, no cuenta con un componente dedicado, porque no es algo que se construya directamente. Surge cuando la memoria y la evaluación trabajan juntas, y aun así ese aspecto aún no está completamente desarrollado. La parte superior del modelo sigue siendo en parte algo aspiracional. La auto-mejora puede aproximarse hoy en día, pero no lograrse por completo.
Eso no era obvio cuando se esbozó por primera vez el modelo. El nivel 5 parecía un destino al que se llegaba al ensamblar las piezas adecuadas. En la práctica, se comporta más bien como un horizonte que se aleja a medida que uno se acerca a él.
Creencias que la producción corrigió, desde el humano en el proceso hasta la orquestación
Esta es la parte que un documento de marco nunca podrá capturar, porque solo surge a partir de la construcción real. Varias suposiciones iniciales resultaron ser erróneas o, al menos, incompletas.
La memoria fue gravemente subestimada. En el primer boceto, la memoria se presentaba como un simple elemento, una característica que hacía que los agentes parecieran más continuos. Al desarrollarla, se demostró que la memoria es una infraestructura, con todo lo que esa palabra implica: diseño de esquemas, calidad de recuperación, políticas de degradación e isolamiento de usuarios. Luego vino una lección aún más incómoda: incluso la infraestructura que sabemos cómo construir no es exactamente la abstracción adecuada. Los equipos adaptan bases de datos diseñadas para otros propósitos porque no existe nada creado específicamente para esto. La memoria fue el tema más subestimado en el modelo original.
El objetivo es la previsibilidad, y la autonomía es secundaria. Este es el cambio más profundo. Al principio, el progreso se medía por cuánto podía hacer un agente sin la intervención humana, por lo que cada aumento en su independencia se consideraba un avance. Sin embargo, un agente que actúa solo pero de manera impredecible simplemente causa daños más rápidamente. La fiabilidad bajo supervisión resultó ser más importante que la independencia pura en cualquier implementación seria. Un fallo ilustrativo involucró a un agente que creó de forma autónoma docenas de tickets duplicados. Lo que necesitan los sistemas de producción es la cantidad adecuada de autonomía: limitada, auditable y predecible, con los seres humanos tomando las decisiones cuyo costo merece atención humana. Un lector sostuvo en una ocasión que la orquestación debería buscar la previsibilidad, no la autonomía, y tardé mucho en aceptar ese punto de vista.
La seguridad es una característica de cada capa. El plan original trataba la seguridad como un tema al final, algo que se añadía una vez que el sistema funcionaba. La inyección de comandos corrige eso. Sus objetivos están en otros lugares: el punto en el que se llaman las herramientas, la ruta por la cual se escriben los datos en memoria, la forma en que se modifican los objetivos y el tráfico entre los agentes. Cada componente tiene una dimensión de seguridad. La autenticación en los límites de las herramientas, el aislamiento en la memoria y los controles sobre la modificación de objetivos son todos aspectos de seguridad, distribuidos por todo el sistema y no concentrados en un solo lugar.
El bucle tiene prioridad sobre el prompt. Esta lección vino al final y habría sido más útil al principio. Gran parte de los esfuerzos en este campo se destinan a la ingeniería de prompts y a la búsqueda de frases mágicas. Pero un agente no es un prompt; es un bucle que persigue un objetivo a través de numerosos pasos, y un prompt perfecto dentro de un bucle defectuoso te da un agente elocuente que nunca llega a su destino. Una vez que piensas en términos de bucles, muchos problemas que parecían limitaciones del modelo resultan ser fallos en el diseño del bucle.
Tener a un ser humano involucrado no es un defecto que se pueda corregir mediante la ingeniería. Es tentador pensar que la participación humana es un apoyo temporal que se debe eliminar a medida que la tecnología madura. Los mejores sistemas de agentes de producción no son los más autónomos. Ellos colocan el juicio humano justo donde es necesario y en ningún otro lugar. La supervisión humana no es una etapa de la cual se pasa; es una característica deliberada y permanente de cualquier sistema cuyos errores conllevan un costo real.
La estructura en una sola imagen
Si se combina todo lo anterior, un sistema de agentes maduro se ve así:
+==========================================================================+
| HUMAN OVERSIGHT LAYER |
| Approval gates, escalation, audit trail (Article 13) |
+==========================================================================+
| | |
+==========================================================================+
| GOAL & LOOP LAYER |
| ReAct / Plan-Execute / Reflexion, goal revision (Article 14) |
+==========================================================================+
| | |
+==========================================================================+
| ORCHESTRATION LAYER |
| Supervisor-worker, pipeline, fan-out, debate (Article 6) |
+==========================================================================+
| | |
+==========================================================================+
| HARNESS LAYER |
| Self-verification, loop detection, reasoning routing (Article 5) |
+==========================================================================+
| | |
+--------------------------------------------------------------------------+
| MODEL LAYER |
| AWS Bedrock: Claude 3.7 / 3.5 / Haiku |
+--------------------------------------------------------------------------+
CROSS-CUTTING CONCERNS (touch every layer above):
+----------------+ +----------------+ +----------------+ +----------------+
| MEMORY | | EVALUATION | | SECURITY | | COST |
| Article 7 | | Article 8 | | Article 9 | | Article 10 |
| episodic, | | offline+online | | injection def, | | model routing, |
| semantic, | | LLM judge, | | guardrails, | | caching, |
| procedural | | regression | | red-teaming | | batch, budget |
+----------------+ +----------------+ +----------------+ +----------------+
+--------------------------------------------------------------------------+
| DEPLOYMENT LAYER (Article 11) |
| Blue-green, canary, state migration, model pinning, IaC |
+--------------------------------------------------------------------------+
Las capas verticales forman la ruta de la solicitud. Una tarea ingresa mediante supervisión humana, se moldea según objetivos y bucles, se coordina entre agentes, se refina mediante el mecanismo de control y finalmente se ejecuta contra el modelo. Las preocupaciones que afectan a todo el sistema llegan a cada capa. La memoria suministra tanto los bucles como el mecanismo de control. La seguridad protege los límites de la herramienta y la revisión de objetivos. El costo regula la ruta del modelo en cada paso. El despliegue abarca todo esto.
La visión nivel por nivel oculta cuán estrechamente están entrelazados estos componentes. Un cambio en uno se transmite a los demás. No se puede optimizar el costo sin comprender los bucles, ya que una ejecución costosa suele deberse a un bucle que no termina. El trabajo de seguridad también requiere la misma conciencia sobre la memoria, ya que una entrada corrupta sigue causando problemas mucho tiempo después de haberse escrito. Trate las capas como una sola estructura entrelazada y no como un conjunto de módulos separados.
Lo que aún nadie ha resuelto
Esta podría ser la sección más útil, ya que todo lo anterior describe lo que se puede construir, mientras que esta describe lo que aún no se puede. Un mapa honesto de las fronteras vale más que uno pulido.
No existe la memoria nativa de los agentes. La memoria actual se compone de bases de datos y almacenes vectoriales diseñados para otros propósitos. Un sistema verdaderamente nativo de los agentes, que registre el tiempo, busque por asociación, olvide de forma intencionada y permita al agente decidir qué guardar, según algunas estimaciones, está aún a unos años de distancia. Lo que existe funciona, pero no es lo que se necesita.
Los agentes no pueden determinar con certeza cuándo su conocimiento es aplicable. Esta es la forma más profunda del problema de la memoria obsoleta. Un agente puede recuperar un procedimiento relevante y aplicarlo con confianza en un caso en el que no es adecuado, ya que resulta difícil especificar cuándo un conocimiento deja de ser válido y aún más difícil probarlo cuando se recupera algo. Un procedimiento que funciona en una jurisdicción se aplica incorrectamente en otra, y ni el agente ni, con frecuencia, el usuario se dan cuenta. Esa es una limitación fundamental y no simplemente una deficiencia técnica.
La autoevaluación es poco fiable. Tanto la lógica de escalado como la puntuación de confianza dependen de que el agente juzgue con precisión su propia certeza. A veces lo logra, y otras veces se equivoca al dar la impresión de estar seguro, lo cual es el caso más perjudicial porque anula todas las medidas de seguridad que dependen de que el agente reconozca sus limitaciones. Aún no existe una solución fiable para una autoevaluación calibrada.
Los conjuntos de herramientas no se transfieren entre modelos. Cada conjunto de herramientas está ajustado al comportamiento de un modelo específico. Al cambiar de modelo, es necesario volver a ajustar los prompts, los umbrales de detección de bucles y las rúbricas de verificación. En principio no tendría que ser así, pero nadie ha creado una abstracción de conjunto de herramientas que funcione sin ajustes tras un cambio de modelo. La actualización de un modelo sigue siendo un proyecto y no un simple cambio de configuración.
No existe un verdadero aprendizaje continuo. La memoria procedural aproxima el aprendizaje: los enfoques exitosos se almacenan y se reutilizan. Sin embargo, las ponderaciones no cambian y el agente no desarrolla nuevas capacidades a partir de la experiencia. Él construye una biblioteca de soluciones anteriores de la cual toma información. Un agente que realmente mejore en una categoría de problemas a través de la experiencia no es algo que los sistemas de producción puedan hacer hoy en día.
El costo es impredecible en los casos extremos. Existen herramientas de gestión de costos y funcionan, pero la parte final de la distribución es resistente a los cambios. Una pequeña proporción de ejecuciones, aquellas que caen en bucles patológicos o casos límite complicados, sigue consumiendo recursos desproporcionados de maneras difíciles de prever. Se puede establecer un límite para ese gasto, aunque no siempre sea posible predecirlo.
Nada de esto es una razón para detenerse. Estos son los límites del mapa actual, y saber dónde se encuentran es lo que diferencia la ingeniería de la mera ilusión.
Por dónde empezar: aprovechar la ingeniería antes que la orquestación de agentes
Si estás desarrollando un sistema de agentes, no trates los temas como un orden de construcción. Están agrupados por concepto, no por secuencia de desarrollo. Si los construyes en ese orden, crearás memoria antes de tener un mecanismo para utilizarla, y evaluaciones antes de tener algo que evaluar.
Comienza desde el nivel de madurez en el que se encuentra tu sistema.
- Un agente básico que llama a herramientas y es poco fiable debería empezar con la ingeniería de mecanismos de soporte, ya que allí radican la mayoría de los problemas de fiabilidad.
- Un agente individual sólido que ha alcanzado un límite está listo para la orquestación de múltiples agentes.
- Un sistema destinado a la producción necesita evaluación, medidas de seguridad y trabajos de despliegue; nada de esto es opcional, y es sensato realizarlos más o menos en ese orden.
- La gestión de la memoria rinde frutos una vez que se cuenta con un agente funcional, evaluado y seguro, y se observa que el mismo trabajo se repite en cada ejecución. Incluirla antes es prematuro.
- La optimización de costos se vuelve urgente cuando el uso pasa de volúmenes de prueba a volúmenes de producción, aunque debería influir en el diseño desde el primer día.
- Los ciclos orientados a objetivos y los patrones con intervención humana están presentes en todo. Los encontrarás en cada etapa, así que infórmate sobre ellos desde temprano, incluso si los implementas gradualmente.
Las herramientas son intercambiables, pero las ideas no.
Los ejemplos presentados en esta discusión se basaron en AWS Bedrock, LangGraph y LangChain. Se trataba de elecciones prácticas, tomadas porque constituían la solución en uso en producción, pero no son las únicas posibles. La mayor parte de lo que realmente importa no está vinculado a ellos. La autenticación debe realizarse en los límites de la herramienta, independientemente de la nube. En cualquier framework, el bucle de procesamiento es más importante que el prompt. Los niveles de memoria, los patrones de coordinación entre múltiples agentes, las categorías de ataques y la matriz de relación entre reversibilidad y costo para la supervisión humana son conceptos que se aplican también a otras soluciones tecnológicas.
Esa es también la razón por la cual vale la pena contar con una alternativa local con Ollama y Docker. Permite ejecutar los patrones sin incurrir en costos de nube, y demuestra que los conceptos son separables de la implementación. Si una arquitectura de memoria funciona con un modelo local y un almacén de vectores local, entonces el diseño en realidad no debe nada a Bedrock desde un principio. Lo que se capturó fue el problema subyacente, y este se presenta de manera similar en cualquier plataforma. Lo mismo ocurre con los patrones de orquestación, ya que reemplazar LangGraph por otro framework cambia la sintaxis del bucle pero no los modos de fallo a los que debe hacer frente, y lo mismo aplica a las herramientas de evaluación que pueden dirigirse al modelo que esté detrás de ellas.
Lo que reveló escribirlo
Explicar un tema de manera clara y ordenada a alguien que no estuvo presente cuando lo aprendiste revela las lagunas en tu propio entendimiento. Muchos temas parecen estar dominados hasta que intentas plasmarlos por escrito.
La realidad honesta de este campo es que es al mismo tiempo emocionante e inmaduro. Ahora son posibles cosas que no lo eran hace dos años, y es fácil engañarse a sí mismo porque una expresión fluida da la impresión de mayor capacidad de la que realmente tiene. La distancia entre un agente que demuestra buen rendimiento en pruebas y uno que funciona de manera fiable en producción es enorme, y la mayor parte del trabajo técnico complejo se encuentra en esa brecha.
Si hay un mensaje que vale la pena enviar de vuelta al principio, es que el trabajo realmente interesante no consiste en hacer que los agentes sean más poderosos. Los modelos ya son poderosos y siguen mejorando según un ritmo que no podemos controlar. El trabajo interesante radica en hacer que esos modelos poderosos sean fiables, predecibles, seguros y lo suficientemente económicos como para confiar en ellos al tomar decisiones reales. Eso es ingeniería, no magia: mecanismos, bucles, memoria, evaluación y toda la infraestructura poco llamativa que convierte a un modelo capaz en algo en lo que se puede confiar.
La inteligencia proviene del modelo. La arquitectura es algo que uno mismo debe construir.
Leer más
- Notas prácticas: Arquitecturas agentes, Artículo 12: ¿Estamos listos para un?: Guía detallada de las Notas prácticas: Arquitecturas agentes, Artículo 12: ¿Estamos listos para un?: contratos, verificaciones y espacios para código reutilizable para los equipos que implementan este patrón.
- El ser humano en el ciclo de los agentes de IA: Puertas de aprobación, escalada y registros de auditoría: En los casos en que un agente necesita la aprobación humana, se presentan cuatro patrones (puertas de control, escalada, ediciones colaborativas, muestreo), posibilidades de pausar y reanudar con LangGraph, tiempos de espera, registros de auditoría y posibles problemas.