El agente recuperado

5.1El problema

Junio de 2025. En un par de semanas, Tobi Lütke, Andrej Karpathy y Philipp Schmid consolidan un término: context engineering. · fuente: corpus B.1 (Lütke ~18-19 jun, Karpathy ~25 jun, Schmid 30 jun 2025).

Abril de 2026. Birgitta Böckeler publica en martinfowler.com sobre harness engineering —"everything in an AI agent except the model itself" (Böckeler, 2026)—. Es subconjunto, no sucesor de context engineering; el detalle en 5.4. · fuente: corpus B.6 (2 abr 2026).

Los términos rotan más rápido que tus sistemas en producción. Magallanes seguirá investigando encargos cuando "context engineering" suene tan a 2025 como "prompt engineering" sonaba al escribir esto.

Hoy haces dos cosas. La primera: entregas el checkpoint C4 —el sistema orquestado que completa el encargo que mató a Magallanes en N0·L1—. La segunda, menos obvia y más duradera: escribes la memoria de diseño que explica cada decisión. Esa memoria decide si dentro de dos años tienes principios transferibles o vocabulario caducado.

Este es el gate macro del curso. Integra N0 a N3. No pregunta "¿funciona?": pregunta "¿cuánto mejor que el baseline, a qué coste, y cuándo NO harías esto?". Las tres respuestas, con números.

5.2Qué vas a poder hacer

Al terminar serás capaz de:

• Producir el entregable C4 completo: sistema multi-contexto, comparativa N0-vs-N4 con el harness, y memoria de diseño.
• Estructurar una memoria de diseño que cubra las cinco dimensiones de la rúbrica sin huecos.
• Autoevaluar tu entregable contra la rúbrica FIEL, detectando los errores comunes antes del gate.
• Articular los tres principios del curso que sobreviven al rebranding del campo.

Necesitas saber antes:

• De N4·L1 (/cursos/context-engineering/aislamiento/el-debate-honesto): los criterios de decisión y el caso donde NO compensa.
• De N4·L2 (/cursos/context-engineering/aislamiento/subagentes-como-palanca-de-contexto): qué cruza la frontera del sub-agente.
• De N4·L3 (/cursos/context-engineering/aislamiento/orquestar-en-langgraph): los cuatro elementos de un brief de delegación.
• De N4·L4 (/cursos/context-engineering/aislamiento/el-checkpoint-macro): la comparativa a iso-encargo y la honestidad de costes.

Este nivel asume los gates C0-C3 superados. El baseline de N0 es la otra mitad de tu comparativa.

5.3Recupera

Antes de seguir, responde de memoria. Esto reactiva el nivel completo y dos anclas del curso.

Del nivel:

1. ¿Qué criterios deciden si una tarea es apta para aislamiento (L1)?
2. ¿Qué cruza la frontera de un sub-agente, y qué muere dentro (L2)?
3. ¿Qué cuatro elementos lleva un brief de delegación completo (L3)?
4. ¿A iso-qué se compara el sistema orquestado contra el monolítico (L4)?

Del curso:

5. ¿Por qué degrada un contexto largo aunque "quepa" en la ventana (N0)?
6. ¿Qué palanca corresponde a un fallo por historial repetitivo (N0/N1)?

5.4El concepto

La memoria de diseño como artefacto de ingeniería

Aquí está el entregable que distingue un sistema que funciona de un ingeniero que entiende su sistema.

Una memoria de diseño es el documento que justifica cada decisión de tu arquitectura multi-contexto frente a la rúbrica C4. No es un README ni un informe de resultados. Es el registro de por qué partiste el encargo así, dónde pusiste cada frontera y qué te costó.

La analogía: es el cuaderno de bitácora del navegante. No describe el destino —eso lo dice el informe—; registra cada decisión de rumbo y por qué se tomó. Dónde falla la analogía: la bitácora se escribe durante la travesía. La memoria de diseño la escribes al cerrar, con los datos del harness ya en la mano.

Su estructura sigue las cinco dimensiones del gate, en orden. Las transcribimos fiel a continuación: son a la vez el índice de tu memoria y el listón.

La rúbrica C4 — el listón, fiel

Este es el checkpoint macro del curso. Apruebas con las cinco dimensiones. Transcrita de 03-arquitectura.md:

1. Decisión justificada — criterios documentados aplicados (paralelizable, read-heavy, excede ventana, valor); reconoce explícitamente un caso donde NO compensa.
2. Aislamiento real — sub-agentes con ventana propia; al orquestador solo cruzan resúmenes destilados; effort scaling razonado (nº de subagentes ∝ complejidad).
3. Handoffs completos — briefs con objetivo/formato/tools/límites (sin esto: trabajo duplicado); respuestas destiladas con lo esencial.
4. Recuperación demostrada — comparativa final con el harness: el sistema sostiene la calidad donde el monolítico de N0 caía. Es el checkpoint macro.
5. Honestidad de costes — tokens totales medidos (≈ ×N); veredicto explícito de cuándo este diseño no se paga.

Los cuatro errores comunes

Normaliza esto: las memorias de diseño fallan casi siempre por las mismas cuatro grietas. Reconócelas en la tuya antes que el gate.

Error 1 — justificación post-hoc. Construyes el sistema multi-agente, funciona, y entonces inventas los criterios que lo respaldan. La rúbrica pide la decisión razonada antes. La señal de alarma: tu memoria no incluye ningún caso donde NO compensaría.

Error 2 — comparativa con tareas distintas. Comparas el monolítico en una tarea y el orquestado en otra más fácil. Es el error nº1 del sweep, ahora a escala de sistema. La comparación honesta es a iso-encargo: misma tarea, reportando los tokens de cada uno. · fuente: N4·L4.

Error 3 — costes omitidos o estimados. "Cuesta unas 15 veces más" sin medirlo. Los tokens se cuentan, no se estiman. El multi-agente consume ~15× un chat y los agentes ~4×; esas son referencias de magnitud, no tu medición. · fuente: corpus E.1/A.6.

Error 4 — el "caso donde no compensa" de paja. Pones un contraejemplo absurdo ("no usaría 50 agentes para un saludo") en vez de uno real y cercano: refactorizar el informe manteniendo coherencia entre secciones es write-heavy acoplado, y ahí el aislamiento perjudica. · fuente: corpus E.2.

Cierre del curso — qué perdura

Antes del lab, tres capas que sobreviven cuando el vocabulario rote. Esta sección es densa porque comprime el curso entero; léela despacio.

Capa 1 — "harness engineering" es subconjunto, no sucesor. Böckeler define harness como "everything in an AI agent except the model itself" y escribe, verbatim: engineering a user harness "is a specific form of context engineering". Anthropic usa "harness" descriptivamente, no como reemplazo. · fuente: corpus B.6 (Böckeler, martinfowler.com, 2 abr 2026; Anthropic "Effective harnesses for long-running agents", 26 nov 2025). El término nuevo no entierra al viejo: lo contiene.

Capa 2 — el presupuesto de atención es el invariante. Las relaciones por pares crecen con n² para n tokens; eso no cambia con el rebranding. · fuente: corpus A.4. Mientras la atención sea finita, alguien tendrá que decidir qué tokens la merecen. Las APIs de compaction y los paquetes de supervisor rotarán entre versiones. Esa restricción, no.

Capa 3 — principios sobre técnicas. Las cuatro palancas de Lance Martin (write, select, compress, isolate) y el marco operativo de Anthropic (compaction, note-taking, sub-agentes, just-in-time) son lecturas del mismo presupuesto. · fuente: corpus B.2, B.3. Lo que el curso entrenó no es una librería: es el método. Medir, diagnosticar, elegir palanca, volver a medir.

5.5Míralo funcionar

Antes del gate, calibra el listón. Vas a leer el sistema y la memoria de diseño que lo acompaña: fuerte en la decisión y los handoffs, floja en costes. Verás primero el código, luego las secciones fuertes de la memoria y, al final, su grieta. Localizarla te enseña a no repetirla.

El sistema es una variante de Magallanes: un panorama de subtemas independientes sobre un corpus grande, orquestador-workers. El esqueleto es el congelado del nivel.

Antes de leer cada bloque, ten presente el flujo: el orquestador delega con briefs, los workers leen en su ventana y devuelven destilados. Solo el orquestador escribe. Lee primero el código de corrido; luego la explicación.

El handoff — la pieza que separa los contextos

El handoff transfiere control a un worker y devuelve un acuse al historial del orquestador. La firma es exacta (corpus F.1 + api-nivel4.md).

1# Paquete langgraph-supervisor v0.0.31. NO confundir con langgraph-swarm,
2# cuyo create_handoff_tool NO tiene add_handoff_messages (api-nivel4.md, ÍTEM 1b).
3from langgraph_supervisor import create_handoff_tool
4
5# El ToolMessage de acuse (add_handoff_messages=True, default) mantiene
6# coherente el historial del orquestador: registra que delegó.
7delegar_a_explorador = create_handoff_tool(
8    agent_name="explorador",
9    name="delegar_subtema",
10    description="Transfiere un subtema al worker explorador.",
11)

El parámetro add_handoff_messages=True añade el ToolMessage de acuse. Sin ese acuse, el historial del orquestador tendría un hueco: una respuesta que llega sin que conste a quién se delegó.

Un matiz honesto del propio paquete: su readme recomienda "using the supervisor pattern directly via tools rather than this library for most use cases". · fuente: api-nivel4.md, ÍTEM 1. Lo usamos por claridad didáctica; en producción evalúa la alternativa con tus propias trazas.

El orquestador — quién ve qué

El supervisor enruta a los workers, recoge destilados y es el único que escribe. La firma exacta de create_supervisor (api-nivel4.md, ÍTEM 2):

1from langgraph_supervisor import create_supervisor
2# 'output_mode' decide qué del worker vuelve al supervisor:
3#   'last_message' (default) → solo el mensaje final (el destilado).
4#   'full_history'           → TODO el historial del worker (rompe el aislamiento).
5# Para el budget de N4, 'last_message' es la elección de diseño.
6
7supervisor = create_supervisor(
8    [explorador_agent, verificador_agent],   # workers: ventana propia, solo leen
9    model=...,                               # el LLM del orquestador
10    prompt="...",                            # rol: delega con briefs; tú escribes el informe
11    output_mode="last_message",              # solo cruza el destilado
12)
13app = supervisor.compile()                   # create_supervisor devuelve StateGraph sin compilar

La decisión de diseño que paga el aislamiento está en una línea: output_mode="last_message". Con 'full_history', todo el contexto del worker —decenas de miles de tokens— contaminaría al supervisor. Eso sería un monolítico con pasos extra. · fuente: corpus E.2 (contraejemplo de L3).

El reparto de tools por rol

Cada rol ve el mínimo. El explorador no escribe; el orquestador no lee documentos enteros. Es la palanca de N3 (toolset por rol) aplicada a la frontera read/write:

1# Magallanes N4 — toolset por rol (integración N3).
2# El worker ve solo buscar/leer; escribir_seccion es exclusiva del orquestador.
3TOOLS_EXPLORADOR   = [buscar, leer]              # lee en su ventana, devuelve destilado
4TOOLS_ORQUESTADOR  = [delegar_subtema, escribir_seccion]   # delega y escribe el informe

La frontera no es estética. Las escrituras paralelas acoplan decisiones implícitas; las lecturas paralelas no. · fuente: corpus E.2 ("Actions carry implicit decisions, and conflicting decisions carry bad results"); E.5 (anti-patrón write-heavy, paráfrasis de confianza media). Por eso escribir_seccion no se reparte.

Las secciones fuertes — cómo se ve una decisión y un handoff bien escritos

Antes de la grieta, mira las dos secciones que la memoria sí resuelve. Son prosa, no código: así se redacta el documento. Calibra este nivel de detalle para el tuyo.

Primero, la sección Decisión de la memoria de ejemplo —los cuatro criterios aplicados al caso, con el contraejemplo:

Decisión. Aíslo el encargo en orquestador-workers porque cumple los cuatro criterios. Es breadth-first con direcciones independientes: cada subtema se investiga sin depender de los demás. El corpus completo excede una ventana, así que un monolítico sufriría context rot antes de cubrirlo. La paralelización es pesada —ocho subtemas— y el informe es de alto valor, así que los tokens extra se justifican. NO aislaría la fase final de redacción: unificar las secciones en un informe coherente es write-heavy acoplado, y dos workers escribiendo en paralelo tomarían decisiones de estilo y estructura incompatibles que el orquestador no podría reconciliar. Esa fase se queda single-threaded. · fuente: corpus E.1 (cuatro criterios) + E.2 (contraejemplo write-heavy acoplado).

Después, la sección Handoffs: un brief de ejemplo con los cuatro elementos —objetivo, formato, tools/fuentes y límites—:

Handoffs. Cada subtema se delega con un brief de cuatro partes. Ejemplo del subtema 3: objetivo — "documenta las rutas de migración entre las versiones 2.x y 3.x"; formato de salida — "≤2K tokens, lista de cambios con el doc_id de cada fuente"; tools/fuentes — "solo buscar y leer sobre el corpus de release notes"; límites — "no cubras la versión 1.x; otro worker la tiene asignada". Sin el límite explícito, dos workers leerían los mismos documentos y duplicarían trabajo. · fuente: corpus E.1 (los cuatro elementos del brief; sin ellos, duplicación de trabajo).

Esas dos secciones aprobarían sus dimensiones. Ahora mira dónde la misma memoria se rompe.

La grieta de la memoria de ejemplo

La memoria que acompaña este sistema dice, en su sección de costes:

"El sistema orquestado cuesta aproximadamente quince veces más que el monolítico, como es habitual en multi-agente."

Esa frase suspende la dimensión 5. "Aproximadamente quince veces" no es una medición: es la referencia de magnitud del corpus aplicada como si fuera tu dato. · fuente: corpus E.1/A.6. La rúbrica pide tokens medidos. Token counting está disponible y es barato:

1# Token counting — mides, no estimas (corpus F.6).
2# client.messages.count_tokens(model=..., system=..., messages=[...], tools=[...])
3#   → {"input_tokens": N}
4# Mide DOS cosas distintas:
5#   1) tokens DENTRO de cada worker (su ventana de exploración).
6#   2) tokens que CRUZAN al orquestador (los destilados).
7# La dimensión 5 exige el total real, no "~15×".

Self-explanation

Antes de leer la respuesta, intenta tú. ¿Por qué la memoria de ejemplo aprueba decisión y handoffs pero suspende costes? ¿Y por qué eso basta para no superar el gate?

5.6Hazlo tú = checkpoint C4

Este es el lab integrador. No es un ejercicio antes del gate: es el gate. Produces el entregable completo del checkpoint C4.

Andamiaje: a estas alturas el esqueleto es tuyo. Las firmas de API las tienes en las lecciones del nivel. Lo que aporta esta lección es la estructura del entregable y el listón.

El entregable (tres piezas)

Pieza 1 — el sistema multi-contexto. Particiona con orchestrator-workers el encargo que excede una ventana. Workers con ventana propia que solo leen (buscar + leer) y devuelven destilados ≤2K tokens con doc_ids. Un orquestador que delega con briefs, acumula destilados y es el único que escribe (escribir_seccion). Integra las palancas N1-N3 donde correspondan:

• N1 — compaction en el hilo del orquestador (su historial de destilados también crece).
• N2 — el informe en construcción y las notas como artefactos externos compartidos.
• N3 — toolset por rol (el explorador no escribe; el orquestador no lee documentos enteros).

Pieza 2 — la comparativa final N0-vs-N4. Re-ejecuta el sweep de N0 (/cursos/context-engineering/diagnostico/el-context-sweep) tal cual —mismo harness, mismas métricas— sobre el encargo escalado, en ambos sistemas. Construye la curva: dónde el monolítico cae y el orquestado sostiene; dónde el orquestado paga de más sin ganar calidad. Con tokens medidos por token counting.

Pieza 3 — la memoria de diseño. Las cinco secciones de 5.4, en orden, sin huecos.

Antes de lanzar — el effort scaling

Antes de lanzar todo, una decisión que falla por improvisación: cuántos workers. La pauta es razonada, no inventada (verbatim Anthropic):

"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.

Un ejemplo resuelto antes de dimensionar el tuyo. Encargo con 5 subtemas factuales independientes: aplicas la pauta y salen 2 workers con 4-5 tool calls cada uno. La justificación: es fact-finding, así que no necesitas uno por subtema; agrupar ahorra coordinación. No saltas a 10 subagentes porque no es complex research.

Ahora el tuyo. Para tu encargo de N subtemas independientes, dimensiona el nº de workers citando esa pauta. Después, en dos columnas, separa qué información DEBE cruzar la frontera al orquestador y qué debe morir dentro del sub-contexto.

Normaliza el error: es común dimensionar "uno por subtema" sin pensar. Un subtema que es fact-finding puro no necesita más que pocas tool calls; agruparlo con otro puede ahorrar coordinación. El número se razona contra la pauta.

Elaborative interrogation

Antes de construir, predice. Re-ejecutas el sweep sobre los dos sistemas. ¿En qué tramo de la curva esperas que el orquestado NO mejore al monolítico — o incluso pierda?

5.7Comprueba — el mastery gate

Sin pistas. Este es el gate C4, el checkpoint macro. Apruebas con las cinco dimensiones.

Autoevalúa tu entregable contra la rúbrica de 5.4. Para cada dimensión, escribe el veredicto con feedback formativo: qué cumple, qué brecha tiene, cuál es el siguiente paso.

Para cerrar, el veredicto de tu comparativa en tres partes:

1. Recuperación — dónde tu sistema sostiene calidad que el monolítico pierde, con la curva.
2. Coste — cuánto cuesta, en tokens medidos (≈ ×N), no estimados.
3. Frontera honesta — para qué variante del encargo NO recomendarías este diseño y qué harías en su lugar.

5.8Conecta

Cierra el arco que abrimos en el primer minuto del curso.

En N0·L1 (/cursos/context-engineering/diagnostico/el-mito-de-la-ventana-infinita) empezaste con un run muerto: Magallanes ahogado por un encargo que no cabía, sin saber por qué. Era una anécdota.

Hoy terminas con otra cosa. Un sistema que completa ese encargo escalado. La curva que demuestra dónde el monolítico caía y el orquestado sostiene. Y una memoria que explica cada decisión —por qué aislaste, dónde pusiste la frontera, qué te costó—.

Entre esos dos puntos están las cuatro palancas. Recuperaste el historial con compaction (N1). Diste a Magallanes memoria que sobrevive a un reinicio (N2). Curaste su toolset y le diste conocimiento just-in-time (N3). Y cuando ni todo eso bastó, partiste el trabajo en ventanas aisladas (N4). Cuatro lecturas del mismo presupuesto de atención.

Lo que llevas contigo no es una arquitectura. Las arquitecturas caducan; "harness engineering" ya pisa el terreno de "context engineering" sin sustituirlo. · fuente: corpus B.6. Lo que llevas es el método: medir, diagnosticar, elegir palanca, volver a medir. Ese método no rota con el vocabulario.

Qué sigue: el harness que construiste no se guarda en un cajón. Es el compañero permanente de todo lo que diseñes a partir de aquí — el curso llm-evals-observabilidad lo lleva de instrumento de diagnóstico a práctica continua.

5.9Reflexiona

Tómate unos minutos. Escribir esto consolida el curso mejor que releerlo.

• ¿Qué aprendiste? Resume en una frase por qué la memoria de diseño importa tanto como el sistema que la acompaña.
• ¿Qué sigue sin estar claro? ¿Tienes claro por qué la comparativa va a iso-encargo y no a iso-tokens? Si no, vuelve a N4·L4.
• ¿Qué harías distinto? La próxima vez que alguien proponga partir un agente en sub-agentes "porque Anthropic lo hace", ¿qué tres preguntas harías antes de aceptar?

Esto requiere práctica. La intuición de "qué encargo de mi trabajo partiría — y cuál no" llega diseñando sistemas reales, no leyendo sobre ellos. El curso te dio el instrumento y el método. Lo que mides con ellos, a partir de aquí, es tuyo.

Fin del curso. Empezaste con un run muerto y una frase inútil. Terminas con un agente recuperado, una curva que lo prueba y un método que sobrevive al próximo término de moda.