Un agente recibe una misión aparentemente común: preparar una propuesta comercial. Para hacerlo debe revisar archivos, buscar antecedentes, comparar precios, pedir un análisis de riesgos y redactar una versión final. El problema aparece cuando el trabajo pasa de una mano digital a otra. ¿Quién autorizó que se consultara una carpeta sensible? ¿Qué ocurre si el especialista contratado por el sistema se demora o devuelve un cálculo errado? ¿Quién responde si un subagente reenvía el encargo a un tercero sin que nadie haya definido ese permiso?
La mayor parte de los sistemas actuales resuelve esa escena con una combinación de reglas fijas, llamadas a herramientas y algo de optimismo. Divide la tarea, la reparte y espera que el flujo termine bien. El paper Intelligent AI Delegation, firmado por Nenad Tomašev, Matija Franklin y Simon Osindero, de Google DeepMind, parte de que ese mecanismo sirve para demostraciones acotadas, pero resulta insuficiente cuando las cadenas de trabajo se prolongan, cambian de contexto y empiezan a tener consecuencias fuera de una ventana de chat.
La tesis del documento no consiste en pedir agentes más obedientes. Propone una infraestructura de delegación. En ella, asignar una tarea implica transferir una porción definida de autoridad, responsabilidades y capacidad de acción. También exige aclarar qué se espera, qué recursos quedan disponibles, cómo se vigila el proceso, qué prueba certifica que se cumplió el encargo y dónde se corta la responsabilidad si intervienen varios participantes.
Cuando una orden se transforma en una cadena
El encargo: un agente de compras debe evaluar proveedores y preparar una recomendación para un equipo humano.
La delegación: puede derivar la verificación de precios a un servicio, la revisión contractual a otro y la búsqueda de antecedentes a una fuente externa.
El punto crítico: cada eslabón necesita saber qué datos puede consultar, hasta dónde llega su mandato, qué debe informar y bajo qué condiciones el proceso debe detenerse o volver al origen.
Ese desplazamiento parece técnico, pero modifica la pregunta central. El desafío deja de ser cómo conseguir que un modelo ejecute muchas instrucciones. Pasa a ser cómo organizar una red en la que cada agente puede actuar, contratar servicios, gastar recursos, producir efectos sobre sistemas externos y, llegado el caso, derivar trabajo a otros. La delegación ya no es una conveniencia de programación. Es una forma de gobierno operativo.
El encargo no termina al dividirlo
Los autores distinguen la delegación de la simple fragmentación de una tarea. Dividir un objetivo en subtareas es apenas el comienzo. Delegar supone asignar competencia, establecer obligaciones y conservar una forma de rendición de cuentas. El documento propone evaluar cada pedido según una trama de variables: complejidad, criticidad, incertidumbre, duración, costo, recursos requeridos, restricciones, posibilidad de verificación, reversibilidad, contexto y grado de subjetividad. Ninguna de ellas funciona de manera aislada.
La reversibilidad explica bien la diferencia. Redactar un correo o marcar un registro dudoso en una base de datos admite corrección sencilla. Ejecutar una operación financiera, borrar información o enviar un mensaje al exterior produce efectos que pueden ser costosos o imposibles de deshacer. El paper sostiene que las tareas irreversibles deberían atravesar barreras de responsabilidad más estrictas y escalas de autoridad más empinadas. No se trata de volver lento todo el sistema, sino de evitar que el mismo permiso sirva para sugerir una acción y para ejecutarla.
La idea más concreta del paper: la descomposición debería empezar por el final. Antes de entregar una subtarea, el delegador tiene que definir qué evidencia permitirá verificarla. Si el resultado es demasiado subjetivo, demasiado costoso de comprobar o demasiado opaco, el encargo debe subdividirse hasta alcanzar una unidad que pueda ser validada.
Los investigadores llaman a ese principio contract-first decomposition. Suena abstracto, aunque describe una disciplina conocida en ámbitos donde el error cuesta caro: no se encarga un trabajo sin especificar qué cuenta como trabajo terminado. Para una corrección de software, la prueba puede ser un conjunto de tests ejecutados y firmados. Para un análisis de datos, puede ser la trazabilidad de las fuentes y una revisión independiente. Para una decisión con alto componente subjetivo, el propio documento acepta que la intervención humana conserva un lugar difícil de reemplazar.
La propuesta también discute quién recibe cada parte. Un agente no debería elegir solo al más veloz o al más barato. Debe comparar capacidad, disponibilidad, costo, tiempo estimado, historial relevante y necesidades de acceso. La selección se parece menos a pulsar un botón y más a contratar un servicio bajo condiciones explícitas. En el horizonte que imagina DeepMind, los agentes podrían negociar esas condiciones entre sí, presentar ofertas y aceptar una tarea con límites de recursos, frecuencia de reportes y certificaciones exigidas.
Un contrato antes que una orden
El esquema de DeepMind no imagina una jerarquía rígida con un agente jefe y muchos ejecutores silenciosos. Admite redes centralizadas, relaciones entre pares, mercados de servicios y equipos híbridos donde los humanos reciben tareas de sistemas automatizados. Esa diversidad es necesaria porque la capacidad no está repartida de manera uniforme. Un especialista puede ser excelente para revisar código y mediocre para interpretar una norma; una persona puede aportar criterio en un caso ambiguo, pero introducir demoras que vuelven inviable una respuesta de tiempo real.
La coordinación, entonces, debe optimizar objetivos que compiten. Calidad, velocidad, costo, privacidad, consumo de recursos y probabilidad de éxito no se acomodan naturalmente en una misma dirección. El paper habla de una frontera entre confianza y eficiencia. Elegir un ejecutor con mejor reputación puede reducir el riesgo, aunque eleve el precio. Abrir más contexto puede mejorar el resultado, pero amplía la superficie de exposición. Cambiar de delegado a mitad de camino puede salvar una tarea que se degradó, aunque genere gasto adicional y pérdida de tiempo.
Hay una consecuencia que merece atención. No toda tarea justifica esta maquinaria. Los autores advierten que la negociación, el monitoreo, los contratos y la verificación tienen costo propio. Para una acción breve, de baja criticidad y resultado evidente, la delegación sofisticada puede ser más cara que la ejecución directa. Es una observación saludable en un mercado que suele presentar toda coordinación automática como ganancia inmediata. Si el control vale más que el encargo, no hay eficiencia, hay burocracia computacional.
Qué cambia cuando la delegación tiene estructura
La autoridad se vuelve graduable: un agente puede recibir permiso de lectura sobre una carpeta precisa sin heredar acceso ilimitado al resto del sistema.
La tarea deja rastros: los informes de avance, los artefactos intermedios y las comprobaciones permiten reconstruir qué ocurrió cuando el resultado falla.
El reemplazo deja de ser una catástrofe: si el trabajo parcial se registra con criterios comunes, otro delegado puede retomarlo sin reiniciar todo el proceso.
La arquitectura se apoya en una distinción decisiva entre reputación y confianza. La reputación sería el historial verificable y público de un agente: tareas completadas, consumo de recursos, incumplimientos, certificaciones y comportamiento registrado. La confianza, en cambio, sería el umbral privado y contextual que un delegador exige para una tarea determinada. Un agente puede tener buen historial general y no alcanzar el estándar para una operación crítica. Esa diferencia evita una simplificación peligrosa: convertir la trayectoria de un sistema en una nota única, como si todos los encargos fueran equivalentes.
El monitoreo completa ese mecanismo. Puede observar solo el resultado final o seguir el proceso; puede ser directo, mediante interfaces y reportes, o indirecto, mediante los efectos que deja una acción en un entorno compartido. Los autores reconocen que la transparencia total no siempre es posible ni deseable, en especial cuando hay secretos comerciales, datos sensibles o métodos propietarios. Por eso incorporan alternativas como pruebas criptográficas, entornos de ejecución confiables y reportes que demuestren cumplimiento sin revelar toda la información subyacente.
La red necesita memoria de sus decisiones
El punto más ambicioso del paper aparece cuando deja el interior de una empresa y piensa en una red abierta. Allí, agentes de distintos proveedores podrían descubrirse, negociar, subcontratar y cobrar por trabajos especializados. Para que esa economía no se convierta en una feria de promesas imposibles de comprobar, DeepMind plantea cinco pilares: evaluación dinámica de capacidades, ejecución adaptable, transparencia estructural, coordinación confiable a gran escala y resiliencia frente a fallas sistémicas.
La evaluación tiene que ser dinámica porque una etiqueta fija sobre un agente dice poco de su situación actual. Puede estar saturado, sin presupuesto, con una ventana de contexto agotada o involucrado en otra cadena de delegación. La ejecución también debe poder corregirse sobre la marcha. Si el desempeño cae, si cambia el entorno o si aparece un bloqueo, el sistema tendría que reasignar la tarea, modificar sus parámetros o escalar la decisión a quien corresponda. Una automatización que no puede revisar su plan termina confundiendo continuidad con obstinación.
Ese enfoque ayuda a entender por qué el paper menciona protocolos que ya ordenan partes del ecosistema. Agent2Agent, impulsado por Google, facilita el descubrimiento entre pares y el intercambio de estados de una tarea; el Model Context Protocol conecta aplicaciones con herramientas y fuentes de información; el Universal Commerce Protocol busca estandarizar la interacción comercial entre agentes y proveedores. Para los autores, ninguno resuelve por sí solo el problema completo. Falta una capa que una permisos, condiciones de ejecución, evidencia verificable y responsabilidad a lo largo de toda la cadena.
El paper ofrece un marco, no una infraestructura lista
No presenta un sistema desplegado: propone protocolos, extensiones y criterios de diseño que todavía requieren implementación, pruebas de interoperabilidad y validación en contextos reales.
La verificación tiene límites: comprobar una prueba matemática no equivale a validar una recomendación estratégica, una interpretación jurídica o una investigación abierta.
Las cadenas largas multiplican el problema: cuando A delega en B y B en C, la responsabilidad no desaparece. Debe quedar expresamente asignada, incluso si el origen no puede observar cada paso en forma directa.
La seguridad aparece aquí como condición de funcionamiento, no como un adorno añadido al final. El documento contempla inyecciones de instrucciones, accesos indebidos, consumo abusivo de recursos, informes falsos y efectos que se propagan por redes demasiado homogéneas. Su respuesta no es confiar en un filtro único. Propone permisos mínimos, límites que se estrechan al avanzar por una cadena, interruptores que revocan autoridad cuando se deteriora la reputación y mecanismos de recuperación cuando un delegado falla.
La lectura de Mundo IA
El mérito del paper no está en anunciar un futuro de agentes omnipotentes. Está en atacar el vacío que queda entre una demostración brillante y una operación real. Hoy abundan sistemas capaces de iniciar una tarea; faltan reglas comunes para saber cuándo pueden continuar, qué permisos arrastran, cómo se reemplazan sin perder el trabajo y quién carga con el resultado. La próxima disputa no será solo por modelos más capaces. Será por la infraestructura que determine qué clase de trabajo pueden delegar y bajo qué condiciones.
La delegación inteligente, tal como la describen Tomašev, Franklin y Osindero, exige abandonar la fantasía de que un agente confiable es simplemente un agente que acierta muchas veces. La confianza operativa se construye con una arquitectura que limita, registra, verifica y permite corregir. En un mundo con cadenas de tareas cada vez más largas, esa diferencia puede definir si los agentes se convierten en infraestructura útil o en una sucesión elegante de responsabilidades perdidas.
Referencias
Agent2Agent Protocol, especificación y documentación del protocolo.
Model Context Protocol, especificación oficial.
Model Context Protocol, especificación de autorización.
Google Developers, Universal Commerce Protocol.
Anthropic, presentación del Model Context Protocol.
Coalition for Secure AI, “Model Context Protocol Security”, enero de 2026.
