Agent Engineering: cuándo coordinar varios agentes y cuándo no

Un agente crea preguntas para una actividad de evaluación continua. Otro asume el juicio académico: comprueba que miden la competencia declarada y, cuando llegan las respuestas, aplica la rúbrica para proponer una calificación. Un tercero opera Moodle: incorpora los ítems aprobados y solo registra la calificación después de la aprobación prevista. Las tres fronteras son creación, evaluación y escritura autorizada.

También pueden ser un solo usuario con tres nombres. Si los tres se autentican con el mismo token, comparten identidad y permisos, de modo que el reparto solo existe en las instrucciones que describen sus papeles. El generador puede tener permiso para publicar aunque su prompt diga que no debe hacerlo.

Poner nombres y papeles a varias instancias de un modelo no crea una organización. Si comparten credencial, quien genera una pregunta puede conservar también el permiso para registrar una calificación aunque su prompt diga que no debe hacerlo. Cada participante necesita una responsabilidad concreta, un encargo claro, unos permisos limitados y una entrega que otro componente sea capaz de validar.

En este texto llamo Agent Engineering al diseño de quién decide, quién actúa, qué información pasa de uno a otro y qué prueba permite cerrar el trabajo conjunto.

La primera decisión no es cuántos agentes crear. Es si el problema necesita alguno.

Código, flujo, agente o varios agentes

Si el camino ya se conoce, suele bastar con código. Validar un esquema, convertir un formato o aplicar una regla no mejora porque un modelo decida cada paso.

Cuando el recorrido es estable, pero alguna parte exige interpretar texto, se puede utilizar un flujo fijo y reservar el modelo para clasificar, extraer o redactar. La aplicación sigue decidiendo el orden.

Un agente resulta útil cuando ese orden no puede conocerse por completo de antemano. Recibe un objetivo, observa el estado, elige una herramienta, actúa y adapta el siguiente paso. La definición de Anthropic describe precisamente ese ciclo: planificar, actuar, observar y ajustar hasta terminar o pedir ayuda.

Varios agentes añaden otro problema: coordinar decisiones. Separar tareas o ejecutar varias llamadas en paralelo no lo exige por sí solo. Un flujo fijo también puede hacerlo. La arquitectura multiagente merece la pena cuando cada unidad necesita su propio objetivo, herramientas y criterio de parada, y cuando esa separación mejora el resultado.

Puede ocurrir al investigar líneas independientes, utilizar herramientas muy especializadas, separar producción y revisión o mantener permisos que nunca deben reunirse en una sola identidad.

La guía de Google Cloud recomienda empezar por un único agente y reservar la coordinación para problemas que no puede manejar con facilidad. Anthropic propone una cautela parecida: añadir complejidad cuando la mejora sea demostrable.

Un papel no es un contrato

«Eres el agente investigador» solo describe un personaje. No dice qué debe investigar, qué fuentes puede consultar, cuándo ha terminado ni qué tiene que entregar. El coordinador recibe un texto convincente y debe adivinar si contiene lo que necesitaba.

Cada tarea delegada debería dejar claro:

El contrato debe quedar registrado fuera de la conversación. Si cambia una instrucción, una herramienta o la forma de la entrega, cambia el comportamiento y hay que probar la nueva versión. El capítulo sobre Prompt Engineering explica el ciclo de vida de esas instrucciones.

Delegar sin enviar todo el historial

Copiar la conversación completa al especialista parece cómodo. También puede exponer datos que no necesita, ocupar su contexto y borrar el límite entre responsabilidades.

El coordinador debería preparar un encargo pequeño: objetivo, hechos necesarios, restricciones, referencias y forma de entrega. Si falta un dato que el agente no puede obtener, devuelve una pregunta concreta. Si descubre trabajo fuera de su alcance, lo registra para que el coordinador decida qué hacer.

Cada especialista recibe un encargo limitado y devuelve una entrega que el coordinador puede comprobar.

Ver a tamaño originalCerrar

La ventaja de especializar desaparece si todos los agentes reciben todas las herramientas y toda la información.

El traspaso puede deformar el trabajo

Un investigador distingue un hecho confirmado, una inferencia y una duda. Si resume las tres cosas con el mismo tono de seguridad, el siguiente agente recibe una certeza que nunca existió.

Una entrega útil conserva el identificador de la tarea, la versión de entrada, el resultado, las fuentes, los supuestos, los efectos ya producidos y lo que queda pendiente. «Tarea completada» no aporta nada de eso.

El receptor debe validar la entrega antes de continuar. Si faltan campos o evidencias, el coordinador la rechaza, pide una corrección o cambia el plan. No conviene pasar el texto incompleto al siguiente modelo y confiar en que lo repare: podría rellenar los huecos sin avisar.

Esa entrega también permite reanudar el trabajo. Si todo el estado vive en los chats, un fallo obliga a reconstruirlo leyendo conversaciones. Un artefacto identificable permite saber qué terminó, qué produjo efectos y desde dónde es seguro continuar.

Un estado común fuera de las conversaciones

Una sala donde todos los agentes escriben parece suficiente hasta que aparecen mensajes duplicados, conclusiones incompatibles y dudas sobre qué frase describe el estado actual.

Cuando hay tareas paralelas o efectos externos, conviene mantener un registro común. Puede guardar el responsable de cada tarea, sus dependencias, la versión de entrada, las entregas, las aprobaciones y los efectos producidos. El historial de mensajes ayuda a explicar una ejecución, pero no debería ser la única fuente para decidir qué falta.

La ingeniería de memoria añade una distinción útil: una preferencia personal, el estado temporal de una tarea y un hallazgo compartido no tienen el mismo dueño ni la misma duración.

Si dos agentes pueden modificar el mismo objeto, el último no debería borrar sin aviso una versión que el primero utilizó para decidir. Según el riesgo, harán falta versiones, bloqueos o una única autoridad de escritura.

Los permisos no se delegan con una frase

Moodle 5.1 separa autoridades que pueden aparecer durante el mismo recorrido de evaluación continua. Preparar preguntas no es lo mismo que evaluar la competencia de una persona, conceder una excepción de entrega o escribir la calificación. Conceder una prórroga requiere mod/assign:grantextension en el contexto de una actividad. Evaluar una competencia requiere moodle/competency:competencygrade en el contexto del curso o de la persona. Editar una calificación requiere moodle/grade:edit en el contexto del curso.

La configuración predeterminada tampoco concede los permisos a los mismos arquetipos. Un profesor no editor recibe la capacidad de conceder prórrogas y evaluar competencias, pero no la de editar calificaciones. Esta última se asigna al profesor editor y al gestor, y está marcada con los riesgos RISK_PERSONAL y RISK_XSS; las otras dos capacidades no declaran esos riesgos. La plataforma distingue tanto la autoridad como el alcance y el peligro de cada operación.

Sin embargo, un token de servicio de Moodle pertenece a un usuario: la tabla external_tokens conserva su userid, el contexto en el que es válido y, si se configuran, restricciones de dirección IP y caducidad. Si los tres agentes comparten token, comparten la identidad del usuario que lo respalda. La separación entre quien genera, evalúa y registra queda escrita en los prompts y desmentida por las credenciales.

Cada agente que necesite una autoridad diferente debe encontrar una frontera de autorización que la imponga. Puede aplicarse mediante identidades separadas o mediante un intermediario que limite las operaciones de cada credencial; cuando los roles o contextos difieran, una identidad propia permite reflejarlos en el sistema de destino. Si el evaluador no puede registrar la calificación, esa imposibilidad debe estar impuesta por el sistema, no por una frase.

Probar la coordinación

Cada especialista puede superar sus pruebas y el conjunto seguir fallando. El investigador encuentra un dato, pero el coordinador lo ignora. El ejecutor hace una llamada correcta dos veces y duplica el efecto. El revisor detecta un problema, pero no puede detener la publicación.

Por eso conviene provocar fallos de coordinación:

• dos agentes reciben la misma tarea y discrepan;
• un especialista entrega un resultado incompleto;
• una dependencia termina después de que el coordinador ya haya decidido;
• un agente intenta usar una herramienta fuera de sus permisos;
• una llamada se repite tras agotar el tiempo de espera;
• el revisor rechaza el trabajo y el productor lo declara corregido;
• se agota el presupuesto sin alcanzar el resultado;
• un agente produce un efecto y desaparece antes de registrarlo.

El capítulo sobre Loop Engineering explica por qué el cierre necesita una prueba que el propio productor no pueda fabricar. En un sistema con varios agentes, esa prueba también debe sobrevivir al traspaso y cambiar de verdad la decisión del coordinador.

Observar el trabajo completo

Contar llamadas al modelo no permite reconstruir una tarea. La traza debe unir el objetivo, las delegaciones, las versiones, las herramientas, las aprobaciones y los efectos. Esa traza permite responder quién hizo qué, con qué permisos y a partir de qué información.

La documentación de Google Cloud sobre observabilidad de agentes incluye las interacciones con el modelo, el uso de herramientas, la secuencia de decisiones, la latencia, los recursos, la seguridad y la calidad. Cuando hay varios agentes también hace falta relacionar cada ejecución con su tarea y con las que la precedieron.

La comparación importante se hace contra la alternativa más sencilla capaz de resolver el problema. Si varios agentes ofrecen una calidad parecida con más coste, más demora y más lugares donde fallar, la especialización no ha demostrado su utilidad.

Alguien sigue siendo responsable

Repartir el trabajo entre agentes no reparte automáticamente la responsabilidad. Una persona o función debe aprobar los objetivos y límites, detener ejecuciones, revocar herramientas y atender los efectos sobre otras personas.

La aprobación humana preventiva solo sirve antes de un efecto que todavía se puede evitar: aprobar un plan, resolver una contradicción, ampliar permisos o aceptar una acción difícil de revertir. La supervisión posterior puede detectar, detener y reparar un problema, pero no convertir el efecto en autorizado de forma retroactiva.

Yo solo añadiría un segundo agente después de identificar un problema que el diseño actual no resuelve, asignarle una responsabilidad exclusiva que pueda limitarse con permisos, definir una entrega verificable y acordar la medida con la que se comparará frente a un único agente. Sin esas decisiones, la coordinación añade apariencia organizativa, pero no una separación técnica.

El capítulo sobre AI System Engineering sitúa esta coordinación dentro del producto. Los agentes son una pieza junto a la interfaz, los datos, el contexto, la memoria, las herramientas, la seguridad y la operación. Coordinar bien sus tareas es necesario. Mantener todo el producto bajo control exige revisar el sistema completo.