Contratos de delegación para equipos de agentes de IA: alcance, aceptación y gestión de fallos
Por qué los títulos de trabajo de los agentes no evitan las transferencias defectuosas, y cómo se puede probar un contrato de delegación con políticas obligatorias, así como reglas independientes para la aceptación y los fallos.
Imagínese un cambio en un producto gestionado por tres agentes: se debe añadir una paginación mediante cursor a la API, al cliente que la llama y a las pruebas. Los tres indican éxito, pero el cliente no puede interpretar lo que devuelve la API. El agente de la API emite next_cursor, el agente del cliente espera nextCursor, y el agente de las pruebas verifica los modelos simulados creados basándose en la suposición del cliente. Cada tarea local parece completada, pero el cambio combinado falla con la primera solicitud real.
Etiquetar a los agentes como Ingeniero, Especialista en Clientes y Revisor no indica qué interfaz gana ni quién aprueba el resultado. Esas decisiones deben quedar establecidas en un contrato de delegación, que consiste en una asignación concreta que especifica los insumos, el alcance permitido, el resultado requerido, las condiciones de aceptación y qué ocurre en caso de fallo. Su valor proviene de cómo el sistema utiliza dicho acuerdo, y no de simplemente generar otro documento más.
Piénselo en capas: un rol determina cómo aborda el trabajo un agente, mientras que un contrato detalla qué contribuciones son admisibles. La política en tiempo de ejecución decide qué es realmente capaz de hacer el agente, y la aceptación determina si esa contribución se convierte en un estado de producto.
La especialización deja abierta la transferencia de responsabilidades
Un rol describe una perspectiva, como la búsqueda de problemas de seguridad, la creación del cliente o la crítica al diseño. Un contrato de tarea describe una asignación específica: utilizar esta versión de la interfaz, modificar estos archivos, presentar esta evidencia. La autoridad en tiempo de ejecución determina qué puede leer, modificar o ejecutar realmente el trabajador.
Separarlos permite que un rol útil siga siendo útil sin hacerlo responsable de todo. Un revisor puede detectar cambios que rompan la funcionalidad sin tener permiso para aprobarlos, y un ingeniero puede proponer una interfaz revisada sin tener la facultad de hacerla la versión aceptada.
La investigación sobre multiagentes de Anthropic, realizada en agosto de 2026, hace tangible el problema de la dependencia. En sus experimentos de creación de juegos, los roles prescriptivos y una jerarquía al estilo CEO apenas cambiaron, y los juegos siguieron siendo de mala calidad incluso cuando algunos modelos obtuvieron mejores puntuaciones en las pruebas de coordinación. El mismo informe señala comportamientos y errores correlacionados. Esos resultados provienen de experimentos específicos y no dicen nada definitivo sobre cada equipo de agentes; además, sus comparaciones de búsqueda de vulnerabilidades difieren en alcance y uso de recursos, por lo que los totales brutos no permiten determinar cuánto contribuyó la coordinación.
Existe un contrejemplo. El documento técnico de Anthropic sobre su sistema de investigación indica beneficios derivados de la investigación paralela y describe tareas que incluyen objetivos, formatos de salida, orientación sobre herramientas y límites. También señala un mayor consumo de recursos y advierte sobre el trabajo con muchas dependencias. Esto aboga por tomar en serio la descomposición, pero no demuestra que una arquitectura de investigación se transfiera sin cambios a la ingeniería en un código compartido.
La propuesta aquí se refiere a la línea que separa el trabajo delegado del trabajo aceptado. Determinar si trazar esa línea de forma explícita justifica su costo adicional es algo que hay que probar.
Escribe la tarea en torno a la dependencia
Para el cambio de paginación, comience con que el responsable del producto corrija el comportamiento deseado y que el responsable de la API apruebe la interfaz. Supongamos que la interfaz utiliza next_cursor, donde null indica la página final. A continuación, los procesos de la API y del cliente pueden desarrollarse basándose en una revisión específica, mientras que las pruebas de aceptación verifican el resultado resultante de la fusión.
El siguiente YAML es una ilustración del contrato para el proceso del cliente. Sus rutas, nombres de revisiones e identificadores de verificación forman parte del ejemplo y no constituyen un estándar ni forman parte de la API de ningún framework.
task_id: pagination-client-17
objective: Fetch successive pages using next_cursor; stop at null.
inputs:
repository:
ref: product-repo
revision: base-42
requirement:
ref: pagination-behavior
revision: r3
interface:
ref: api/pagination.yaml
revision: r7
scope:
writable:
- client/pagination.ts
- tests/client/pagination.test.ts
non_goals:
- interface_changes
- api_changes
- deployment
deliverable:
- patch_against_base-42
- check_results_bound_to_patch_and_input_revisions
acceptance:
checks:
- client-pagination-unit
- pagination-api-client-e2e
owner: product-maintainer
policy_ref: client-worker-v2
failure:
stale_or_conflicting_input: stop_and_report_to_owner
missing_evidence: return_incomplete
authority_required: request_owner_decision
max_attempts: 2
exhausted: return_unaccepted_to_owner
Los nombres de las comprobaciones deben corresponder a comandos y afirmaciones reales en un registro que controle el ejecutor. En este ejemplo, representan comprobaciones unitarias relacionadas con el manejo del cursor y una comprobación de extremo a extremo que examina varias páginas en relación con la API real del candidato, incluido el cierre con null. El trabajador del cliente puede ejecutar sus propias comprobaciones unitarias, mientras que el ejecutor de integración genera la evidencia combinada una vez que existan ambos parches.
De manera similar, policy_ref simplemente indica el nombre de una política. El distribuidor debe asociar la asignación aprobada a un trabajador autenticado y buscar dicha política en una configuración que el trabajador no pueda editar. Una referencia desconocida o una solicitud de una política más estricta debe hacer que la validación falle, y editar el YAML nunca debe otorgar acceso adicional.
Limitar el trabajo a dos intentos es una decisión local que mantiene los ciclos de reparación dentro de límites, pero no dice nada sobre la fiabilidad. Un presupuesto de ejecución finito establecido por el propietario asegura que ningún intento dure para siempre.
Una tarea estructurada no constituye un límite de autorización. YAML puede describir el alcance previsto, pero el entorno de ejecución debe seguir aplicándolo.
Un camino de pasos que hace realidad el contrato
Alrededor de los trabajadores existe un camino de pasos. El mecanismo aquí es simplemente el software que inicia a los trabajadores, gestiona sus herramientas y registra lo que ocurre.
- Aprobar las dependencias: los responsables del producto y de la API aprueban los requisitos y la interfaz.
- Validar la asignación: su autor proporciona el contrato y las versiones resueltas.
- Desplegar según la política establecida: el distribuidor inicia trabajadores de API y clientes aislados.
La tarea puede ser realizada por un humano o por otro agente. A continuación se realizan dos verificaciones: un validador determinista confirma la estructura y que todas las referencias se resuelvan, mientras que el responsable verifica que el texto realmente refleje los requisitos del producto. Después de eso, el distribuidor espera a que existan dependencias aprobadas, carga las entradas fijas y pone en marcha cada trabajador dentro de sus límites.
Cuatro preguntas deben mantenerse separadas. La validez del esquema verifica si los campos requeridos existen y están bien formados. La adecuación semántica comprueba si la asignación describe correctamente el trabajo. La aplicación de permisos determina si un trabajador puede exceder sus facultades. La evidencia del resultado verifica si el producto resultante satisface los requisitos. Un documento que sea estructuralmente válido responde únicamente a la primera de estas preguntas.
Para su aplicación, una lista de rutas escribibles debe convertirse en una verdadera restricción en tiempo de ejecución, respaldada por una verificación de archivos modificados durante la integración. El acceso a la shell no debe ofrecer una forma alternativa de eludir los controles de archivos o red. Un proceso de verificación separado mantiene las propuestas aparte, pero por sí solo no constituye un límite de autorización.
El anuncio de GitHub sobre permisos gestionados del 9 de septiembre describe las operaciones que están bloqueadas de forma centralizada, requieren aprobación o están permitidas, con límites que la configuración del espacio de trabajo no puede reducir. Su descripción arquitectónica sobre flujos de trabajo agentes habla de ejecución aislada y escrituras por fases, sometidas a verificación. Ambos son ejemplos de mecanismos de cumplimiento, y ninguno demuestra que este diseño de delegación mejore la entrega o garantice cambios correctos.
Propiedad del resultado fusionado
En el ejemplo de paginación, el ejecutor de integración fusiona las propuestas de la API y del cliente en un espacio de trabajo temporal. Verifica el alcance, comprueba las revisiones de entrada y ejecuta las pruebas de aceptación registradas contra ese espacio temporal específico. Luego, el responsable de la aceptación examina las pruebas y evalúa cualquier juicio relacionado con el producto que las pruebas no puedan resolver.
La aceptación independiente significa que el trabajador que realizó el trabajo no controla por sí solo los criterios y las pruebas. Las afirmaciones y configuraciones integrales quedan fuera del acceso de escritura del trabajador, y los resultados están vinculados al resumen del candidato. La aceptación puede combinar verificaciones deterministas con un mantenedor humano, y otro LLM es opcional. Nombrar a un modelo como Supervisor no establece autoridad ni hace que su juicio sea fiable.
Solo un propietario autorizado puede cambiar los criterios de aceptación, y lo hace con una razón registrada y una nueva revisión de la asignación. El agente ejecutor puede solicitar un cambio, pero no debe excluir una prueba fallida del conjunto ni redefinir la paginación como completada después de una sola página.
Finalmente, un integrador autorizado aprueba al candidato seleccionado a través del camino de fusión protegido que ya está establecido. El registro de aceptación indica el candidato exacto y las revisiones de entrada que abarca. Si la rama destino avanza antes de la integración, el candidato se vuelve a crear y se verifica nuevamente contra la nueva base primero.
Los resultados que presentan conflictos vuelven al responsable del límite en disputa. Dos interfaces plausibles siguen siendo dos interfaces incompatibles, por lo que hasta que ese responsable tome una decisión, ninguna propuesta se convierte en la definición compartida solo por llegar primero.
El manejo de fallos debe formar parte del mismo flujo de trabajo
Cada uno de estos casos debe probarse de forma aislada contra el flujo de trabajo de paginación, con una respuesta esperada y un responsable encargado de hacerla cumplir.
Cuando ambos trabajadores intentan modificar la interfaz, el distribuidor rechaza la propiedad simultánea sobre ella y las restricciones en tiempo de ejecución impiden la edición no autorizada. La integración rechaza cualquier parche que se salga del alcance asignado, y el propietario de la API decide sobre el cambio solicitado.
Si la revisión de la interfaz cambia mientras se está trabajando en ella, la verificación de dependencias marca la propuesta como obsoleta. El propietario elige si vuelve a presentarla basándose en la nueva revisión, y la integración no puede aceptar silenciosamente las pruebas recopiladas para la versión anterior.
Cuando aparece código plausible sin pruebas, la puerta de aceptación lo registra como incompleto. Un ejecutor de confianza realiza las verificaciones necesarias, y un mensaje de finalización seguro no puede sustituir a los resultados reales.
Cuando un trabajador se detiene a mitad de camino, el arnés registra la interrupción y mantiene la propuesta parcial por separado. Antes de que comience el trabajo de reemplazo, el intento anterior se retira para que no pueda presentar un resultado aceptado más tarde.
Si un nuevo intento podría crear dos veces el mismo entorno de vista previa, el adaptador de acciones externas primero reconcilia la solicitud anterior. Cuando el proveedor admite la deduplicación, se utiliza una clave de operación estable, y los efectos que siguen siendo inciertos se envían al responsable para su revisión.
Si la integración requiere autorización que el trabajador no posee, la política de herramientas bloquea la operación y envía una solicitud al responsable adecuado. La propuesta permanece sin aceptar hasta que llegue esa decisión.
El escenario de entorno de vista previa es un complemento opcional del ejemplo, gestionado por el servicio de integración, cuyo despliegue se mantiene fuera del ámbito del trabajador del cliente. Una clave de operación designa un único efecto deseado en todas las reintentos, un identificador de intento separa las ejecuciones individuales, y un reintento no debe crear una nueva operación solo para superar una respuesta ambigua.
La cuenta inicial de Agent Harness de Temporal describe la ejecución duradera y los puntos de control alrededor de un bucle de agente interno, con esperas para la recuperación y la aprobación. Se trata de un proyecto en desarrollo del proveedor y no constituye evidencia comparativa independiente. Todavía se necesita una deduplicación o reconciliación específica del proveedor para las acciones externas, ya que la orquestación duradera por sí sola no demuestra efectos de ejecución exactamente una vez en un servicio arbitrario, y la propia documentación de reintentos de Temporal recomienda la detección de duplicados en las etapas posteriores al reintentar.
Cada reparación consume parte del presupuesto de intentos y recursos declarado. Cuando alguno de ellos se agota, el flujo de trabajo devuelve un resultado rechazado junto con las pruebas correspondientes y el responsable designado. Las escalaciones también requieren una fecha de vencimiento o una forma de cancelación, para que la responsabilidad no quede perdida en una conversación abandonada.
Los contratos pueden formalizar un trabajo incorrecto
El costo adicional es la principal objeción. Cuando un único agente modifica una función aislada, el problema sumado a las pruebas existentes ya puede proporcionar suficiente control sobre el alcance y la aceptación. Los prototipos desechables y las tareas de investigación independientes de bajo riesgo suelen requerir poco más que instrucciones claras. Crear un servicio basado en contratos solo para reetiquetar este tipo de acuerdos sería inútil.
Tampoco los contratos pueden generar la intención de producción o la capacidad necesaria cuando estas están ausentes. Una mala descomposición sigue siendo deficiente, los errores correlacionados persisten, y un oráculo de aceptación defectuoso, es decir, la prueba o juicio que determina si el resultado es correcto, sigue siendo erróneo. Supongamos que la prueba de extremo a extremo reutiliza el modelo simulado defectuoso del cliente: su resultado positivo entonces pasa por alto completamente el fallo original.
Por esa razón, este diseño merece ser comparado con alternativas más simples, como un único agente o un flujo de trabajo determinista. La pregunta es si la coordinación adicional mejora el trabajo aceptado o controla un riesgo real para la carga de trabajo en cuestión.
Cómo probarlo
No se ha realizado ningún nuevo experimento con este componente. Vale la pena comparar tres configuraciones: un único agente (A), varios agentes con asignaciones basadas en roles (B) y varios agentes que utilizan contratos de delegación explícitos junto con el enfoque mencionado anteriormente (C).
La equidad exige proporcionar a A, B y C información idéntica sobre las tareas y criterios de aceptación, herramientas y límites de seguridad comparables, entornos iniciales similares y un presupuesto total de recursos declarado. B y C comparten modelos y número de trabajadores, mientras que A utiliza un modelo equivalente cuando es factible. La variable bajo estudio es el mecanismo de delegación y coordinación, sin capacidades adicionales ni requisitos ocultos por parte de ninguno.
B debe mantener las medidas de seguridad habituales y descripciones útiles de las tareas. Si surge naturalmente un acuerdo explícito de transferencia de responsabilidades, registre ese comportamiento y no lo prohíba. Publique las configuraciones reales para que la comparación no se convierta en una implementación pulida frente a un punto de referencia deliberadamente débil.
Elija tareas que representen la combinación real: algunas con partes independientes, otras con dependencias secuenciales, y algunas con interfaces o recursos compartidos entre los procesos. Las pruebas se repiten desde entornos reiniciados en orden aleatorio, y las tareas normales permanecen separadas de los fallos introducidos intencionadamente. Después de un piloto, las configuraciones se congelan; las tareas reservadas sirven para realizar la comparación real, y la incertidumbre se reporta según la estructura de dependencias.
La metodología de evaluación de Anthropic distingue entre la transcripción y el estado del entorno que deja atrás, y evalúa al modelo junto con su entorno de ejecución. Ese es el lugar adecuado para medir: ¿funciona la paginación en el entorno combinado? El hecho de que tres agentes anuncien haber terminado no demuestra nada.
Se aplican tres medidas principales: los resultados finales aceptados, el costo total de cada resultado aceptado y el tiempo transcurrido hasta la aceptación. Los costos incluyen pruebas fallidas, coordinación, intentos repetidos, revisión, configuración y redacción de contratos. La configuración inicial se informa por separado del costo recurrente; se indica cualquier suposición de amortización y se registra abiertamente el tiempo dedicado por personas. Si no se acepta nada, se debe indicar el gasto total y cero éxitos, en lugar de mostrar un costo unitario que parezca finito pero sea engañoso.
Además de esto, se deben registrar las fallas de integración, el trabajo duplicado, las fallas por datos obsoletos, las intervenciones humanas, las violaciones del alcance y los resultados rechazados después de haberse informado como completos. Las violaciones intentadas y las que tuvieron éxito se informan por separado, y las pruebas inconclusas y los tiempos de espera se mantienen registrados para que los éxitos rápidos no oculten los fracasos prolongados.
Rechazar correctamente un parche obsoleto demuestra que las funciones de control funcionan, pero la tarea del producto sigue fallando a menos que se acepte un resultado válido dentro del presupuesto. Los resultados iniciales de los pilotos solo indican una dirección. Si los contratos generan costos adicionales sin mejores resultados aceptables o sin reducir significativamente el riesgo, el consejo sensato es omitirlos para esa carga de trabajo.
Comience con una transferencia que pueda inspeccionar
Un punto de partida razonable es un flujo de trabajo existente con dos trabajadores y un responsable designado para la aceptación. La verificación de integración queda fuera del control de los trabajadores, y cada caso de fallo se prueba por separado antes de ampliar el alcance. Un mensaje breve al respecto puede dirigirse a un agente de programación:
Add the minimum delegation contract to [WORKFLOW].
Acceptance owner: [OWNER].
Preserve existing safety boundaries.
1. Inspect current delegation, inputs, permissions, and acceptance.
Exit: map who assigns, executes, checks, accepts, and commits.
2. Identify missing boundaries; reuse existing issues and checks.
Exit: owner-approved scope, revisions, deliverable, and criteria.
3. Wire the minimum contract into dispatch and result handling.
Exit: references resolve; proposals cannot accept themselves; unauthorized operations are blocked by the actual runtime.
4. Exercise valid and invalid handoffs in isolated fixtures.
Exit: demonstrate acceptance, conflict rejection, stale-input detection, missing-evidence rejection, interruption recovery, bounded retries, and authority escalation. Mock external effects.
5. Report changed files, commands run, outcomes, and remaining gaps.
Exit: distinguish implemented controls from unverified behavior.
No reemplace la plataforma de orquestación ni modifique tareas no relacionadas, y no publique, despliegue ni amplíe los permisos.
La API, el cliente y las pruebas siguen dependiendo de trabajadores capaces. El cambio radica en la regla operativa que los rige. Antes de que el trabajo combinado se considere completo, especifique qué debe incluir cada contribución, quién puede aceptarla y qué ocurre si no se puede aceptar. Los títulos de los trabajos nunca delimitan ese límite.