Lección 3: Escribir prompts para delegar
Objetivos de aprendizaje:
- Escribir un prompt de delegación autocontenido que no dependa de que el subagente vea la conversación entre tú y el orquestador
- Detallar el alcance, los límites y qué fuentes usar de la tarea dentro del propio prompt de delegación
- Explicar el principio de «un dominio de problema, un agente» y qué te cuesta romperlo
Requisitos: Terminar la Lección 2 y entender la arquitectura orquestador-subagente y el aislamiento de contexto | Anterior: Lección 2 << | Siguiente: Lección 4 >>
Recordatorio: todo lo que el subagente no puede ver, tienes que escribírselo tú
La Lección 2 cubrió un mecanismo que importa aquí: "Each subagent starts with a fresh, isolated context window. It doesn't see your conversation history, the skills you've already invoked, or the files Claude has already read. Claude composes a delegation message that summarizes the task, and the subagent works from there."1 (cada subagente arranca con una ventana de contexto fresca y aislada; no ve tu historial de conversación, las skills que ya has invocado ni los archivos que Claude ya ha leído; Claude compone un mensaje de delegación que resume la tarea, y el subagente trabaja a partir de ahí). Esta lección lo concreta. Significa que todo el trasfondo que hablaste con el usuario a nivel del orquestador, los compromisos que cerraste en rondas anteriores, la restricción que el usuario soltó al pasar: el subagente no sabe nada de eso. Lo único que el subagente sabe son las palabras que escribiste en esta única tarea de delegación.
Esto no es un recordatorio amable, es una restricción dura: el techo de calidad del prompt de delegación fija el techo de calidad de lo que el subagente produce. Todo lo que el prompt no detalle, el subagente lo adivinará, lo saltará o se inventará una suposición y seguirá adelante. Adivina bien y tuviste suerte. Adivina mal y esa subtarea entera queda básicamente desperdiciada.
Autocontenido: el prompt tiene que decirlo todo por sí solo
Autocontenido: tras leer un prompt de delegación, el subagente no necesita trasfondo extra para deducir con precisión qué debería hacer. Hay una prueba simple para saber si un prompt es autocontenido. Sácalo por su cuenta, quita todo el contexto entre tú y el orquestador, y léelo en frío. Si aun así tienes que adivinar para rellenar los detalles de la tarea, el prompt no pasa la prueba.
Toma el ejemplo de la Lección 1 de investigar precios en tres proveedores de nube. Si el orquestador entrega al subagente una tarea que dice solo «busca los precios de AWS», esa única línea lleva información suficiente para el orquestador mismo, porque el contexto del orquestador todavía sostiene el trasfondo de «por qué lo estamos buscando», «con quién lo compararemos después» y «en qué dimensiones estamos comparando». Pero el subagente no puede ver nada de eso. Lo que recibe es una línea solitaria, «busca los precios de AWS», y le toca adivinar: ¿los precios de qué categorías de producto? ¿Solo los precios actuales, o los cambios del último año? ¿Qué aspecto debería tener el entregable una vez encontrado? Cada suposición es una apuesta que puede salir mal.
Detallar alcance y restricciones: qué hacer, qué no, qué fuentes usar
La guía oficial lista lo que debería contener una descripción de tarea de subagente sólida: "Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information."2 (cada subagente necesita un objetivo, un formato de salida, orientación sobre las herramientas y fuentes a usar, y límites de tarea claros; sin descripciones de tarea detalladas, los agentes duplican trabajo, dejan huecos o no logran encontrar la información necesaria).
Abre esa lista. «Objetivo» y «formato de salida» son fáciles de captar. Los dos que se saltan son el último par: orientación sobre las fuentes y límites de la tarea. La orientación sobre las fuentes le dice al subagente dónde buscar la respuesta: la página oficial de precios, un sitio externo de comparación de precios, o ambos con la página oficial teniendo prioridad. Los límites de la tarea le dicen al subagente que esta ejecución solo cubre esta porción, que no se pase de ahí: solo los precios actuales, sin cambios históricos de precio; solo las líneas de producto principales, sin listar cada servicio oscuro. Sáltate esos dos y el subagente tiende a irse por uno de dos caminos. O se pierde información que sí querías, o trae mucho más de lo que querías y quema llamadas a herramientas y tokens que podrías haber ahorrado.
Reescrita como una descripción de tarea autocontenida y con alcance claro, la investigación del proveedor de nube se ve a grandes rasgos así:
Sacada por su cuenta, esta descripción le permite al subagente juzgar con precisión «qué buscar, hasta dónde llevarlo, qué entregar» sin conocer nada de lo que el orquestador discutió internamente.
El contraejemplo: las instrucciones vagas dejan a los subagentes improvisar
Qué sale mal de verdad cuando no detallas alcance y límites: el equipo oficial dio un ejemplo real de la práctica: "We started by allowing the lead agent to give simple, short instructions like 'research the semiconductor shortage,' but found these instructions often were vague enough that subagents misinterpreted the task or performed the exact same searches as other agents."2 (empezamos permitiendo que el agente líder diera instrucciones simples y cortas como «investiga la escasez de semiconductores», pero descubrimos que esas instrucciones a menudo eran lo bastante vagas como para que los subagentes malinterpretaran la tarea o hicieran exactamente las mismas búsquedas que otros agentes).
«investiga la escasez de semiconductores» se lee como si entregara una tarea, pero no fija nada: ¿en qué rango de tiempo? ¿Centrada en el lado de la oferta, el de la demanda o el impacto de las políticas? ¿Entregada en qué forma? Tres subagentes a los que se entrega la misma instrucción vaga muy probablemente busquen todos hacia «las causas de la escasez de semiconductores», el ángulo que viene primero a la mente, y el resultado son tres cuerpos de investigación que se solapan mucho, mientras que los ángulos que de verdad necesitaban cobertura (digamos, el impacto en las industrias derivadas, o cómo respondieron distintos países) quedan sin tocar. Esta es la raíz, a nivel de prompt, del problema del «trabajo duplicado» de la Lección 2: no es que los subagentes no hagan caso, es que la descripción de la tarea misma nunca trazó los límites.
Un dominio de problema, un agente
Más allá de escribir un solo prompt con claridad, cómo varios subagentes se reparten el trabajo también sigue un principio que puedes destilar de la práctica oficial —el equipo oficial nunca lo nombró, este nombre es nuestro—: un dominio de problema, un agente: cada subagente debería ser dueño solo de una clase de problema con límites claros, en lugar de que un único subagente haga malabares con varias cosas sin relación a la vez.
El sistema oficial tiene un ejemplo directo: montaron un CitationAgent dedicado, "a CitationAgent, which processes the documents and research report to identify specific locations for citations. This ensures all claims are properly attributed to their sources."2 (un CitationAgent, que procesa los documentos y el informe de investigación para identificar las ubicaciones concretas de las citas; esto garantiza que todas las afirmaciones se atribuyan correctamente a sus fuentes). Encontrar dónde van las citas es una clase de trabajo completamente distinta de «investigar la estrategia de precios de alguna empresa»: lo primero es comprobar y ubicar, lo segundo es buscar y juzgar. Entrega ambas al mismo subagente y tiene que ir y venir entre dos modos de pensamiento del todo distintos, y su descripción de tarea crece larga y enredada por intentar servir a dos objetivos, fácil de descuidar uno por el otro. Divide en dos subagentes enfocados y la descripción de tarea de cada uno se mantiene simple y con límites claros, lo que hace eco de la vara de medir de la Lección 1: si se puede partir en subtareas independientes, vale la pena partirlo.
Resumen
- El subagente no puede ver el historial de conversación del orquestador,1 lo que significa que un prompt de delegación tiene que ser autocontenido: legible por su cuenta, aparte de cualquier trasfondo conversacional, y aun así suficiente para que el subagente juzgue con precisión qué debería hacer.
- Una descripción de tarea sólida tiene que contener un objetivo, un formato de salida, orientación sobre las fuentes y límites de tarea claros; sin esto, los subagentes duplican trabajo, dejan huecos o no logran encontrar la información necesaria.2
- El contraejemplo real oficial demuestra que las instrucciones vagas como «investiga la escasez de semiconductores» llevan a los subagentes a malinterpretar la tarea o a hacer exactamente las mismas búsquedas que otros subagentes2: el alcance y los límites no son opcionales, son la clave para evitar el trabajo duplicado.
- Un dominio de problema, un agente (la destilación que hace esta lección de la práctica oficial): cada subagente debería ser dueño solo de una clase de problema con límites claros, como montar un CitationAgent dedicado para manejar las ubicaciones de citas, repartiendo trabajo de naturaleza distinta entre subagentes distintos2 para que cada descripción de tarea se mantenga simple y enfocada.
- Para juzgar si un prompt de delegación es lo bastante bueno, la prueba es simple: sácalo por su cuenta y léelo una vez, y mira si el subagente tiene que adivinar para rellenar los detalles de la tarea.
>> Lección 4: Patrones de colaboración: pipeline, revisión, votación