Traspaso de una tarea de un agente a otro: qué incluye el brief y qué se omite

Objetivo

Dar a un segundo agente (un subagente, un contexto nuevo tras una compactación o un especialista distinto) todo lo que necesita para continuar una tarea correctamente, y nada que pueda confundirlo o llenar su contexto con material que no puede aprovechar.

Requisitos previos

Un motivo claro para el traspaso: el receptor dispone de herramientas, permisos o un contexto limpio de los que carece el remitente. El artículo de ingeniería de Anthropic citado sobre su sistema de investigación afirma que cada subagente necesita un objetivo, un formato de salida, orientación sobre las herramientas y fuentes que debe usar y límites claros de la tarea, y que, sin descripciones detalladas de la tarea, los agentes duplican trabajo, dejan lagunas o no encuentran la información necesaria. La documentación del agente de programación describe la dirección complementaria: un subagente parte de un contexto nuevo que no ve el historial de la conversación, trabaja a partir del mensaje de delegación que recibe y devuelve únicamente el resumen.

Pasos

1. Escribe el objetivo en una frase y la comprobación de aceptación en otra ("terminado cuando pase la suite de pruebas y el diff afecte solo a billing/").
2. Pasa el material por identificador, no por contenido: rutas de archivos, hashes de commit, URL, IDs de registros, rangos de líneas. El receptor puede obtener lo que necesite; una copia pegada queda obsoleta y cuesta tokens dos veces.
3. Enumera las decisiones ya tomadas con su motivo ("se usa la biblioteca X porque Y no tiene mantenimiento"), para que el receptor no las reabra.
4. Enumera de forma explícita las incógnitas abiertas ("aún no se ha comprobado si la API tiene límite de peticiones"). Una incógnita omitida parece un asunto ya resuelto.
5. Indica el alcance y el presupuesto: qué herramientas y directorios están permitidos, qué acciones requieren aprobación, cuántas llamadas o cuánto tiempo tiene el receptor.
6. Fija el formato de respuesta: resultado, evidencia (qué comprobaciones se ejecutaron, con su salida), qué ha cambiado y las incógnitas pendientes, con una estructura que el remitente pueda integrar sin leer una transcripción.
7. Omite el resto: la salida cruda de herramientas, la conversación completa y los callejones sin salida. Conserva una línea por cada callejón sin salida ("se probó X, falló con Y") para que no se repita, y descarta el razonamiento que condujo a él.
8. Lee el brief una vez como si fuera lo único presente en el contexto; todo lo que solo tenga sentido con el historial del remitente se reescribe o se elimina.

Resultado esperado

Un receptor que empieza a trabajar ya en su primer turno, en lugar de hacer preguntas aclaratorias o volver a deducir las decisiones del remitente, y una respuesta que el remitente puede integrar de forma mecánica.

Límites y base de verificación

Los pasos son una propuesta derivada de la documentación citada; no se afirma que exista ninguna medición de la calidad de los traspasos. Los briefs para tareas adversariales o relevantes para la seguridad requieren, además, que se especifiquen los permisos del remitente y los límites de confianza, ya que el receptor no hereda nada de forma implícita.