Sub-agentes como palanca de contexto

2.1El problema

El encargo de N4 te pide un panorama sobre ~30 documentos. Para cubrirlo, Magallanes tiene que leer() los 30 completos. Y eso, lo sabes desde N0, mata el run.

Recuerda la curva que construiste en N0·L4 (/cursos/context-engineering/diagnostico/el-context-sweep). Cada leer() mete un documento entero al historial. La calidad cae mucho antes del documento 30. El contexto se rompe en el codo, no en el límite anunciado de la ventana.

Hasta ahora atacabas este problema comprimiendo. Compaction (N1) encoge el pasado después de pagarlo: lees el documento, lo metes al historial, y luego resumes. Just-in-time (N3) evita cargar lo que no usas. Pero estos 30 documentos sí hay que leerlos: son el material del informe, no ruido descartable.

Ninguna palanca de compresión basta aquí. No se trata de gastar menos en el mismo hilo. Se trata de que el trabajo no cabe en un hilo. Necesitas otra cosa.

¿Y si la lectura ocurriera en otra ventana —no en la tuya— y a tu hilo solo llegara el extracto?

2.2Qué vas a poder hacer

Al terminar serás capaz de:

• Explicar el mecanismo por el que un sub-agente compra contexto: ventana propia, exploración cara, retorno barato.
• Diseñar la respuesta destilada de un worker: qué información debe cruzar la frontera y qué debe morir dentro.
• Dimensionar el effort scaling de un encargo —cuántos workers, cuántas calls cada uno— citando la pauta de Anthropic.
• Criticar un destilado mal diseñado (demasiado largo, sin doc_id, sin claims accionables) y rediseñarlo.

Necesitas saber antes:

• De N4·L1 (El debate honesto, /cursos/context-engineering/aislamiento/el-debate-honesto): los criterios de Anthropic para decidir si una tarea es apta para multi-agente. Lo recuperamos en 2.3.
• De N1 (/cursos/context-engineering/palancas-y-compaction): qué hace una compaction y qué pierde. También en 2.3.
• El esqueleto congelado de Magallanes: el grafo de LangGraph y sus 3 tools (buscar, leer, escribir_seccion).

2.3Recupera

Antes de seguir, responde de memoria. Esto reactiva lo anterior y engancha lo nuevo.

1. De L1: Anthropic lista cuatro condiciones donde el multi-agente compensa. ¿Cuál de ellas describe el encargo de N4 —30 documentos que no caben?
2. De N1: una compaction comprime bien el historial pero ¿qué tipo de detalle pierde aunque preserve las decisiones?
3. ¿Qué tool de Magallanes es la que infla el contexto a propósito al meter un documento entero al historial?

2.4El concepto

Sub-agentes como compresión

Aquí está la palanca. Un sub-agente es un agente separado que corre en su propia ventana de contexto, ejecuta una tarea enfocada y devuelve a quien lo lanzó solo un resumen destilado de su trabajo —no su historial.

Anthropic lo describe así (verbatim). Los sub-agentes especializados manejan tareas enfocadas "with clean context windows". Cada uno "might explore extensively, using tens of thousands of tokens or more, but returns only a condensed, distilled summary of its work (often 1,000-2,000 tokens)". Y "the detailed search context remains isolated within sub-agents". · fuente: corpus E.3 (post de context engineering + multi-agent, tier 1).

Lee otra vez la asimetría, porque es el corazón de la lección. El sub-agente gasta decenas de miles de tokens explorando. Pero lo que cruza de vuelta son 1.000-2.000. El coste se queda dentro; al hilo que delega solo llega el extracto.

Eso es lo que compra el aislamiento: una ventana entera de presupuesto de atención que no tienes que pagar en tu hilo. El contexto detallado de la búsqueda "remains isolated" —vive y muere en el sub-contexto—.

Esto no es solo teoría: los sub-agentes de Claude Code lo implementan con tres propiedades documentadas. Cada uno corre en su propia ventana, con su system prompt, sus tools y sus permisos. El único canal padre→hijo es el prompt: todo lo que el sub-agente necesita saber va escrito ahí. Las tool calls intermedias y sus resultados se quedan dentro; solo el mensaje final vuelve al padre. Y un detalle estructural: los sub-agentes no pueden spawnear sub-agentes. · fuente: corpus E.3 (code.claude.com/docs/en/sub-agents, tier 1).

En la taxonomía de las cuatro palancas (Lance Martin, N1), esto es isolate: "splitting it up". Anthropic lo llama, en su marco operativo, "sub-agent architectures". Son la misma idea leída por dos autorías distintas; cada cita va a quien corresponde. · fuente: corpus B.2 (Martin, 23 jun 2025) y B.3 (Anthropic, 29 sep 2025).

La analogía: un corresponsal en el extranjero. Manda la crónica de 800 palabras a la redacción, no el archivo entero del país que ha consultado. La redacción decide con la crónica; el archivo se queda allá. Dónde falla la analogía: el corresponsal humano comparte cultura, contexto previo y criterio con la redacción. El sub-agente solo sabe lo que su brief le dice —ni una palabra más—. Eso lo veremos en L3.

Por qué "ventana limpia" no es un adorno

La frase "clean context windows" hace trabajo de fondo. El sub-agente no arrastra tu historial: arranca en limpio, con su brief y nada más. Por eso puede gastar decenas de miles de tokens leyendo sin envenenar tu hilo.

Compáralo con la alternativa que ya conoces. Si Magallanes leyera los 30 documentos en su propio hilo, cada leer() se acumularía —el loop ReAct es append-only (N0·L3)— y la curva caería. El sub-agente rompe esa acumulación: el coste de leer se paga en otra contabilidad, en una ventana que se descarta al terminar.

Effort scaling: el número de workers se razona

¿Cuántos sub-agentes lanzas? No se improvisa. Anthropic da una pauta (verbatim):

"Simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents". · fuente: corpus E.1.

Léelo como una escala, no como una regla rígida. La complejidad del encargo fija el número: una búsqueda puntual, un agente; una comparación, dos a cuatro; un panorama amplio, más de diez. El effort scaling es la decisión de dimensionar el esfuerzo —cuántos workers y cuántas calls cada uno— proporcionalmente a la complejidad de la tarea.

Por qué importa: cada worker cuesta. Recuerda de L1 que un sistema multi-agente usa ~15× los tokens de un chat (los agentes, ~4×). · fuente: corpus A.6/E.1. Sobredimensionar quema presupuesto sin comprar calidad; infradimensionar deja huecos. El número es una decisión de ingeniería que tendrás que justificar en el checkpoint.

El destilado: qué cruza la frontera

El número de workers es media historia. La otra media es qué devuelve cada uno. Aquí está el error más caro de todo el nivel.

Un destilado de 1.000-2.000 tokens no es "un resumen corto". Es un resumen diseñado desde lo que el orquestador necesita para decidir. Si recortas por longitud sin pensar qué información hace falta arriba, produces un resumen corto e inútil.

Para Magallanes, un destilado útil lleva dos cosas: los claims que el orquestador usará para escribir, y los doc_id que los respaldan. El doc_id es el identificador del documento de origen en el corpus del lab.

Citar el doc_id en el destilado tiene una consecuencia concreta. El orquestador recibe el claim y su procedencia. No necesita re-leer el documento para saber de dónde sale —y re-leerlo sería exactamente el coste que el aislamiento evitaba—. El doc_id es el puntero que sustituye al documento entero.

Contraejemplo: el falso sub-agente

No todo lo que se llama "sub-agente" aísla. Imagina un worker que, al terminar, devuelve al padre su transcript completo —cada buscar, cada leer, cada documento que cargó—.

Eso no compra nada. El detailed search context ya no "remains isolated": cruza entero la frontera y aterriza en el hilo del orquestador, que vuelve a saturarse. Pagas la coordinación de lanzar un sub-agente sin comprar la ventana limpia que lo justificaba. Es un monolítico con pasos extra.

La frontera read/write tiene un test simple: ¿qué cruza? Si cruza el destilado, aíslas. Si cruza el transcript, no.

2.5Míralo funcionar

Vamos a montar un único worker "explorador" para Magallanes. Es el patrón Explore: el primer paso del andamiaje del nivel —un solo worker, lanzado a mano, antes de orquestar varios en L3—.

El worker recibe un brief, ejecuta buscar + leer en su propia ventana, y devuelve un resumen ≤2K tokens con claims y doc_ids citados. No ve escribir_seccion: esa tool es exclusiva del orquestador (lo justificamos en L3).

Antes de leer el código línea a línea, lee el bloque entero una vez de corrido. Lo difícil no es ninguna línea suelta. Es ver dónde está la frontera: qué se queda dentro del worker y qué sale.

El worker explorador: ventana propia, tools de solo lectura

1# worker_explorador.py — un sub-agente que solo lee y devuelve un destilado
2# Tools del worker: SOLO buscar + leer (NO escribir_seccion). Ventana propia.
3from langgraph.graph import StateGraph, MessagesState, START, END
4
5# El brief llega como el ÚNICO canal padre→hijo: todo lo que el worker
6# necesita saber va escrito aquí (objetivo, formato de salida, límites).
7# (En L3 montamos el brief completo; aquí lo pasamos a mano.)
8
9def worker_explorador(state):
10    # Corre en SU PROPIA ventana: 'buscar' y 'leer' acumulan aquí, no en el orquestador.
11    # Puede gastar decenas de miles de tokens explorando el corpus...
12    ...
13    # ...pero el ÚLTIMO mensaje que devuelve es el destilado: ≤2K tokens,
14    # con claims + doc_id citados. Solo ESO cruza la frontera al padre.
15    return {"messages": [...]}   # el último mensaje = el destilado
16
17builder = StateGraph(MessagesState)
18builder.add_node("explorador", worker_explorador)
19builder.add_edge(START, "explorador")
20builder.add_edge("explorador", END)
21worker = builder.compile()
22
23# Para invocarlo: pasarle el brief como mensaje inicial.
24resultado = worker.invoke({
25    "messages": [{"role": "user", "content": BRIEF_DEL_SUBTEMA}]
26})
27# resultado["messages"][-1] = el destilado (el último mensaje del worker).
28destilado = resultado["messages"][-1].content
29historial_completo_del_worker = resultado["messages"]

Tres cosas de este worker:

• Tools de solo lectura. El worker ve buscar y leer, no escribir_seccion. La frontera read/write es por diseño, no por estética: los workers leen en paralelo; quien escribe es uno solo (la razón completa, en L3).
• Ventana propia. Cada leer() que ejecuta el worker se acumula en su historial, no en el del orquestador. Ahí gasta los decenas de miles de tokens "explorando extensively".
• Solo el último mensaje vuelve. El destilado es lo que cruza. Las tool calls intermedias y sus resultados se quedan dentro —ese es el aislamiento de E.3—.

El destilado: el formato de salida que el brief impone

El brief le dice al worker qué forma debe tener su respuesta. Para el explorador de Magallanes, esa forma es claims + doc_id, bajo un límite de tokens.

1# Formato de salida que el brief le exige al worker (≤2K tokens):
2DESTILADO = """
3## Hallazgos sobre <subtema>
4- <claim accionable 1>  [doc-014]
5- <claim accionable 2>  [doc-027]
6- <claim accionable 3>  [doc-041]
7
8## Huecos
9- <qué NO se pudo confirmar en el corpus>
10"""
11# Cada claim lleva su doc_id: el orquestador recibe el dato Y su procedencia.
12# No re-lee el documento — el doc_id es el puntero que sustituye al texto entero.

Medir la frontera con token counting

Para demostrar que el aislamiento funciona, mides dos cantidades. Una: los tokens que el worker consume dentro de su ventana. Otra: los tokens que cruzan al hilo del orquestador. La distancia entre ambas es lo que compra el sub-agente.

El SDK de Anthropic cuenta tokens sin samplear (corpus F.6): client.messages.count_tokens(...) devuelve {"input_tokens": N}.

1# Medir la frontera: tokens DENTRO del worker vs tokens que CRUZAN
2from anthropic import Anthropic
3client = Anthropic()
4
5# 1) Lo que el worker consumió explorando (su historial completo, con los docs leídos):
6# Incluye system Y tools: el worker también paga esos tokens en cada llamada.
7# Sin ellos, el conteo subestima el coste real del worker.
8dentro = client.messages.count_tokens(
9    model="claude-...",
10    system=system_prompt_del_worker,   # incluir para un conteo real
11    tools=tools_del_worker,            # buscar + leer
12    messages=historial_completo_del_worker,   # buscar + leer + todo lo cargado
13)
14# 2) Lo que cruza la frontera al orquestador (solo el destilado):
15cruza = client.messages.count_tokens(
16    model="claude-...",
17    messages=[{"role": "assistant", "content": destilado}],
18)
19
20print(dentro["input_tokens"], "dentro |", cruza["input_tokens"], "cruzan")
21# Esperado: 'dentro' en decenas de miles; 'cruzan' en ~1-2K. Esa brecha = la palanca.

Lee la última línea. Si dentro está en decenas de miles y cruza en ~1-2K, el aislamiento funciona: pagaste la lectura en otra contabilidad. Si cruza también está en decenas de miles, tu worker devuelve su transcript —es el falso sub-agente de 2.4—.

Self-explanation

Antes de leer la respuesta, intenta tú: ¿por qué citar doc_id en el destilado evita que el orquestador tenga que re-leer el documento?

2.6Hazlo tú

Andamiaje decreciente: primero arreglas un destilado que se pasa de largo (con esqueleto), luego diseñas uno de cero.

Ejercicio 1 — recortar un destilado inflado (con esqueleto)

Un worker de Magallanes devuelve esta respuesta de ~8K tokens. Es correcta pero inmanejable: si la cruzas tal cual, el orquestador se satura.

1RESPUESTA_8K = """
2He buscado en el corpus con los términos 'ruta', 'navegación' y 'estrecho'.
3Encontré 14 documentos. Leí el doc-014 entero, que dice [...3.000 tokens del texto...].
4Luego leí el doc-027, que en su tercer párrafo menciona [...2.500 tokens...].
5También revisé el doc-041 aunque resultó menos relevante [...1.800 tokens...].
6En conclusión, creo que la ruta sur era viable.
7"""

Rediséñala hasta ≤2K tokens sin perder los doc_id ni los claims accionables. Usa el esqueleto de 2.5 (DESTILADO).

Elaborative interrogation — antes de recortar, pregúntate: ¿qué de esos 8K tokens necesita el orquestador para escribir el informe, y qué es transcript que debe morir dentro del worker?

## Hallazgos sobre la ruta
- La ruta sur era viable según las condiciones de navegación descritas.  [doc-014]
- El estrecho aparece documentado como paso practicable.                  [doc-027]

## Huecos
- doc-041 resultó poco relevante; no aporta claims sobre la ruta.

Ejercicio 2 — diseñar un destilado de cero (sin esqueleto)

Ahora un worker distinto: un verificador de citas. Su tarea no es explorar subtemas, sino comprobar que cada doc_id citado en un borrador de informe existe en el corpus y respalda lo que se afirma.

Diseña el formato de su respuesta destilada. Sin esqueleto. Decide tú qué información debe cruzar la frontera para que el orquestador pueda actuar.

## Verificación de citas
- [doc-014] ✓ existe y respalda el claim "ruta sur viable".
- [doc-027] ✓ existe; respalda parcialmente — el texto matiza la afirmación.
- [doc-099] ✗ NO existe en el corpus. Cita fabricada — eliminar del informe.

## Acción recomendada
- Revisar el claim de doc-027 (sobreafirmado); eliminar la cita a doc-099.

2.7Comprueba

Sin pistas. Dado un encargo concreto, dimensiona el effort scaling y separa qué cruza la frontera de qué muere dentro.

El encargo: Magallanes debe producir un panorama de 8 subtemas independientes sobre el corpus —cada subtema requiere buscar y leer varios documentos—. Es breadth-first y excede una ventana.

1. Dimensiona el effort scaling. ¿Cuántos workers lanzarías? ¿Cuántas tool calls estimadas por worker? Justifícalo citando la pauta de Anthropic.
2. Separa en dos columnas, para un worker cualquiera de este encargo: qué información DEBE cruzar la frontera al orquestador, y qué debe morir dentro del sub-contexto.

2.8Conecta

Acabas de entender la palanca que hace posible todo el nivel. Un sub-agente no es "otro agente más": es una ventana de presupuesto que no pagas en tu hilo. Explora caro, devuelve barato, y el contexto detallado muere donde nació.

Esto es exactamente la dimensión 2 de la rúbrica C4: aislamiento real y effort scaling razonado. Aislamiento real significa sub-agentes con ventana propia, de los que al orquestador solo cruzan resúmenes destilados. Effort scaling razonado significa un número de subagentes proporcional a la complejidad. Lo que diseñaste en 2.6 y 2.7 es el material de esa dimensión.

Pero solo viste un lado de la frontera: qué vuelve del worker. Falta el otro lado: cómo se delega bien. Un worker no sabe nada que su brief no le diga —recuerda el límite de la analogía del corresponsal—. Si el brief es vago, el worker duplica trabajo o deja huecos. La delegación vaga es, según Anthropic, un modo de fallo documentado, no un descuido menor.

Y queda una pieza que aquí lanzaste a mano: la orquestación. En el encargo real necesitas varios workers a la vez y alguien que reparta, recoja destilados y escriba el informe —el único que ve escribir_seccion—.

L3 monta esa otra mitad: la orquestación en LangGraph, con el supervisor, los handoffs y el brief de delegación completo —objetivo, formato de salida, tools y límites—.

Cierra el arco que abrimos en 2.1: tenías 30 documentos que no caben en una ventana. Ahora sabes por qué un sub-agente los hace caber —lee en otra contabilidad y solo te cruza el extracto— y cómo diseñar ese extracto para que el orquestador decida sin re-leer nada.

2.9Reflexiona

Tómate un minuto. Responder esto por escrito consolida lo aprendido mejor que releer.

• ¿Qué aprendiste? Resume en una frase por qué un sub-agente "compra contexto" aunque el sistema entero gaste más tokens.
• ¿Qué sigue sin estar claro? ¿Tienes claro la diferencia entre un destilado útil y un resumen meramente corto? Si no, vuelve a 2.4, "El destilado".
• ¿Qué harías distinto? La próxima vez que alguien proponga "partir el agente en sub-agentes", ¿qué dos preguntas harías sobre el formato de respuesta antes de aceptar el diseño?

Esto requiere práctica. La intuición de "qué cruza la frontera" llega diseñando destilados y midiéndolos, no leyendo. En L3 pondrás este worker bajo un orquestador y verás los dos contextos separados en una traza.