El checkpoint macro

4.1El problema

El encargo final es el mismo que mató a Magallanes en N0·L1. Lo escalaste hasta que no cabe en una ventana entera. Hoy lo termina.

Pero terminarlo no basta. En N0·L4 aprendiste a no aceptar "funciona" sin una curva. El checkpoint macro hereda ese rigor y lo sube de nivel. No pregunta "¿el sistema orquestado completa el encargo?". Pregunta tres cosas a la vez:

1. ¿Cuánto mejor que el baseline monolítico, medido con el mismo harness?
2. ¿A qué coste en tokens, medidos y no estimados?
3. ¿Para qué variante del encargo NO lo recomendarías, y qué harías en su lugar?

Las tres respuestas con datos del harness. Sin la primera, "mejoró" es otra anécdota — el fantasma que perseguiste todo el curso. Sin la segunda, escondes que un sistema multi-agente consume ~15× los tokens de un chat (Anthropic, 13 jun 2025 · corpus A.6). Sin la tercera, vendes una arquitectura como universal cuando no lo es.

Esta lección monta la comparativa N0-vs-N4 y construye ese veredicto de tres partes. Es el cuerpo del checkpoint C4.

4.2Qué vas a poder hacer

Al terminar serás capaz de:

• Integrar las palancas de N1, N2 y N3 en el sistema orquestado, cada una en la clase de contexto donde su coste es cero y su beneficio máximo: compaction en el hilo del orquestador, artefactos externos para el informe, toolset por rol. No por acumular features.
• Re-ejecutar el sweep de N0 sobre ambos sistemas —monolítico y orquestado— con el mismo harness, mismo encargo, mismas métricas.
• Construir la comparativa N0-vs-N4 y leerla: dónde el orquestado sostiene calidad que el monolítico pierde, y dónde paga de más sin ganar.
• Medir los tokens totales con token counting y emitir un veredicto de costes honesto, incluida la variante donde este diseño no se paga.

Necesitas saber antes:

• De N4·L3 (/cursos/context-engineering/aislamiento/orquestar-en-langgraph): el grafo supervisor con workers de ventana propia y los briefs de delegación. Lo damos por montado.
• De N0·L4 (/cursos/context-engineering/diagnostico/el-context-sweep): cómo se diseña un sweep válido —semántica fija, ≥4 longitudes, seed— y la curva calidad-vs-longitud. Lo reutilizamos tal cual.
• Las palancas de N1 (compaction), N2 (notas y store externos) y N3 (toolset por rol). No las re-enseñamos; las integramos.

4.3Recupera

Antes de seguir, responde de memoria. Esto reactiva una palanca por nivel y prepara la integración. Es deliberado que mezclemos los cuatro niveles: el checkpoint macro los pide juntos.

1. Un agente repite acciones de su historial en vez de planificar (N0/N1). ¿Qué palanca lo ataca, y qué tipo de información preserva al comprimir?
2. De N2: tu store y tus notas escriben en dos momentos posibles. ¿Cómo se llaman, y qué cuesta cada uno?
3. De N3: pusiste una frontera entre lo que cargas de entrada y lo que cargas durante la ejecución. ¿Cómo se llama esa estrategia de cargar bajo demanda?

4.4El concepto

La integración es diseño, no acumulación

Llegas a N4 con cuatro palancas en la mano. La tentación es activarlas todas "por si acaso". Es el error que vas a normalizar más abajo. Integrar bien significa poner cada palanca donde el sistema la necesita por su estructura — no encenderlas en bloque.

El sistema orquestado tiene dos clases de contexto: el del orquestador y el de cada worker. Cada palanca actúa sobre una clase concreta.

Compaction, en el hilo del orquestador (N1). El orquestador no lee documentos enteros, pero su historial igual crece: acumula los destilados que devuelve cada worker, turno tras turno. Esa pendiente es real. La compaction comprime ese historial cuando supera el umbral, preservando las decisiones de delegación y descartando lo redundante. La API de Anthropic dispara su estrategia server-side al superar 150.000 tokens de input por defecto (mínimo configurable 50.000) · fuente: corpus B.4. Recuerda de N0·L3: en el monolítico crecían los tool results; aquí crecen los destilados — misma contabilidad, otra pendiente.

El informe y las notas, como artefactos externos (N2). El informe en construcción y las notas de trabajo no viven en messages. Viven fuera del contexto, en estado compartido consultable al retomar. Es la técnica de structured note-taking de Anthropic: el agente escribe notas persistidas fuera de la ventana y las recupera más tarde, manteniendo "critical context and dependencies that would otherwise be lost across dozens of tool calls" · fuente: corpus C.2. Así, una compaction del orquestador no se lleva por delante el informe a medias.

Toolset por rol (N3). Cada worker ve el mínimo de tools que su trabajo exige. El explorador ve buscar y leer; no ve escribir_seccion. El orquestador es el único con escribir_seccion; no lee documentos enteros. Esto no es estética. Es la frontera read/write de N4·L2 aplicada: las escrituras paralelas acoplan decisiones implícitas, las lecturas no.

La comparativa final como método

Aquí está el corazón del checkpoint. La comparativa final es el sweep de N0 re-ejecutado, sin tocar nada, sobre ambos sistemas: el monolítico de tu C0 y el orquestado de hoy. Mismo harness, mismas métricas, mismo encargo escalado.

La analogía: es un test A/B con una sola variable. Cambias la arquitectura —monolítico contra orquestado— y dejas todo lo demás congelado. Dónde falla la analogía: un A/B clásico aleatoriza usuarios; aquí no hay población, hay un encargo fijo lanzado a longitudes crecientes. La aleatoriedad la controlas con el seed, como en N0·L4.

Reutilizas el instrumento que construiste en N0·L4 tal cual. El sweep ya sabe variar la longitud manteniendo la semántica fija; ahora lo apuntas a dos providers en vez de uno.

Honestidad de costes: a iso-encargo, no a iso-tokens

El sistema orquestado gana fiabilidad. También gasta más. Esconder lo segundo invalida lo primero.

Los tokens totales se miden, no se estiman. Cada worker consume tokens en su ventana; el orquestador consume los suyos. La suma de inputs medidos es el proxy de coste del run: en investigación, la lectura domina. Como referencia de orden de magnitud, Anthropic reporta que sus sistemas multi-agente usan ~15× los tokens de un chat, y los agentes ~4× · fuente: corpus A.6/E.1. Tu run dará su propia cifra; esa referencia te dice qué esperar, no qué afirmar.

Normaliza esto, porque es el sesgo más tentador del nivel. Es común comparar "a iso-tokens" para que el multi-agente luzca: das al monolítico el mismo presupuesto de tokens y mides quién rinde más con esa cuota. Suena justo. No lo es para esta decisión.

La comparación honesta es a iso-encargo: ambos sistemas reciben el mismo encargo escalado, y reportas cuántos tokens gastó cada uno para resolverlo. El orquestado puede sostener calidad donde el monolítico cae; también puede costar varias veces más. Las dos cosas son verdad y las dos van en el veredicto.

El veredicto incluye dónde NO compensa

La quinta dimensión de C4 exige un caso donde este diseño no se paga. No es un trámite. Es la diferencia entre entender la arquitectura y copiarla.

Hay una variante donde el monolítico con buenas palancas N1-N3 basta y sale más barato. Cuando el trabajo cabe en una ventana con compaction razonable, el aislamiento no compra fiabilidad y sí cobra coordinación. Lo viste en N4·L1: si la tarea no excede una ventana, ni es breadth-first, ni es de alto valor, pagas la orquestación sin recibir nada a cambio.

Lo que NO es esta comparativa

No es lanzar el orquestado, ver que termina, y declararlo mejor. Sin la curva del monolítico al lado, no sabes cuánto mejoró ni dónde. Tampoco es comparar el orquestado en su mejor encargo contra el monolítico en su peor encargo: eso es marketing, no medición. Y no es reportar la calidad omitiendo los tokens. Un sistema que acierta más gastando 15× no "gana" sin más; gana para encargos que pagan ese 15×.

4.5Míralo funcionar

Vamos a montar la comparativa: un sweep que corre el mismo encargo escalado contra dos providers —el monolítico de N0 y el orquestado de N4— y emite dos curvas y la tabla de costes.

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 que es el sweep de N0·L4 con un segundo provider y un contador de tokens. Primero hazte una idea de la forma: un bucle por longitud, dos invocaciones por punto, dos métricas y la suma de tokens.

El provider del sistema orquestado

El sweep de N0·L4 envolvía el grafo monolítico en un call_api. El orquestado se envuelve igual — misma firma de promptfoo (corpus F.8) —, solo que dentro invoca el grafo supervisor que montaste en N4·L3.

1# provider_n4.py — el sistema orquestado, envuelto con la firma de promptfoo (corpus F.8)
2# call_api(prompt, options, context) -> {"output": ..., "tokenUsage": {"total": ...}}
3from magallanes_n4 import construir_orquestado   # el grafo supervisor de N4·L3
4
5def call_api(prompt: str, options: dict, context: dict) -> dict:
6    cfg = context.get("vars", {})
7    n_irrelevantes = int(cfg.get("n_irrelevantes", 0))
8    seed = int(cfg.get("seed", 42))
9
10    # Mismo flag de longitud que el monolítico: inyecta n irrelevantes alrededor
11    # del MISMO encargo (semántica fija). El seed fija la aleatoriedad.
12    graph = construir_orquestado(n_irrelevantes=n_irrelevantes, seed=seed)
13    # El estado arranca con un acumulador en 0. Cada nodo (workers y orquestador)
14    # lo incrementa con coste.contar() antes de su llamada al modelo (ver abajo).
15    result = graph.invoke(
16        {"messages": [{"role": "user", "content": prompt}], "tokens_acumulados": 0},
17        config={"configurable": {"thread_id": f"n4-{n_irrelevantes}"}},
18    )
19
20    informe = result["messages"][-1].content        # el informe final del orquestador
21    total = result["tokens_acumulados"]              # suma medida de workers + orquestador
22    return {"output": informe, "tokenUsage": {"total": total}}

Tres cosas de este provider:

• construir_orquestado(n_irrelevantes=, seed=) es la envoltura de laboratorio del grafo supervisor de N4·L3, con el mismo flag de longitud que ya usaba el monolítico. El encargo no cambia entre las dos arquitecturas — solo la arquitectura.
• El mismo prompt llega a las dos. Esa es la línea iso-encargo: cambias el sistema, no la tarea.
• tokenUsage.total reporta los tokens medidos, no estimados. La cifra sale de result["tokens_acumulados"]: un acumulador del estado del grafo que cada nodo incrementa con coste.contar() antes de su llamada. Lo montas abajo.

Medir los tokens con token counting

El SDK de Anthropic ofrece count_tokens, que devuelve los tokens de input de una llamada sin gastar generación (corpus F.6 · {"input_tokens": N}). Solo mide input, no output. Lo usas como proxy de coste: en un run de investigación la lectura domina la generación. Cada worker lee decenas de miles de tokens y devuelve un destilado de 1.000-2.000 (corpus E.3). El input es la partida grande. Para el coste completo, suma además los tokens de output de cada respuesta real. Aquí medimos el input porque manda.

1# coste.py — suma medida de tokens por componente (token counting, corpus F.6)
2from anthropic import Anthropic
3
4client = Anthropic()
5
6def contar(system: str, messages: list, tools: list) -> int:
7    # count_tokens devuelve {"input_tokens": N} sin generar — rate limits propios.
8    resp = client.messages.count_tokens(
9        model="claude-...",          # el modelo del lab
10        system=system,
11        messages=messages,
12        tools=tools,
13    )
14    return resp.input_tokens   # solo input — el proxy de coste (ver arriba)
15
16# Cómo cada nodo del grafo alimenta el acumulador del estado.
17# Esta es la pieza que cierra el hilo de datos hasta tokenUsage.total:
18def nodo_worker(state: dict) -> dict:
19    medido = contar(SYSTEM_WORKER, state["messages"], [buscar, leer])
20    # ... el worker hace su llamada real y produce su destilado ...
21    return {"tokens_acumulados": state["tokens_acumulados"] + medido, "messages": [...]}
22
23def nodo_orquestador(state: dict) -> dict:
24    medido = contar(SYSTEM_ORQ, state["messages"], [escribir_seccion])
25    # ... el orquestador delega o escribe la siguiente sección ...
26    return {"tokens_acumulados": state["tokens_acumulados"] + medido, "messages": [...]}
27# Al terminar el grafo, state["tokens_acumulados"] = suma de todos los componentes.
28# Eso es lo que provider_n4.py lee como result["tokens_acumulados"].

El detalle que importa: cada ventana se mide aparte y se suman. El worker explorador puede acumular decenas de miles de tokens en su ventana. Al orquestador solo le cruza el destilado de ~1.000-2.000 tokens (corpus E.3). La tabla de costes separa esas dos partidas — es exactamente lo que demuestra el aislamiento.

El driver: dos curvas y la tabla de costes

El driver es el de N0·L4 con un cambio: corre cada longitud contra dos providers y registra los tokens de cada uno. Las dos métricas siguen siendo las deterministas de N0 —cobertura de subtemas y citas a doc_id— para que la comparación sea legítima.

1# comparativa.py — corre monolítico (N0) y orquestado (N4) al mismo encargo escalado
2import time
3from magallanes import construir_grafo            # monolítico congelado de N0·L3
4from magallanes_n4 import construir_orquestado    # orquestado de N4·L3
5
6LONGITUDES = [0, 10, 25, 50]   # nº de docs irrelevantes inyectados (≥4 puntos, como N0·L4)
7ENCARGO = "Investiga los subtemas del encargo y redacta el informe: ..."
8
9# Semántica congelada: lo esperado NO cambia con la longitud ni con la arquitectura.
10SUBTEMAS_ESPERADOS = ["ruta", "tripulación", "financiación"]
11DOC_IDS_CORPUS = ["doc-001", "doc-014", "doc-027"]
12
13def medir(informe: str) -> float:
14    # Las mismas dos métricas deterministas de N0·L4 — comparación iso-métrica.
15    cubiertos = sum(1 for s in SUBTEMAS_ESPERADOS if s.lower() in informe.lower())
16    cobertura = cubiertos / len(SUBTEMAS_ESPERADOS)
17    cita_real = 1.0 if any(d in informe for d in DOC_IDS_CORPUS) else 0.0
18    return 0.5 * cobertura + 0.5 * cita_real     # score determinista [0,1]
19
20def correr(construir, n_irrelevantes: int, seed: int = 42) -> tuple[str, int, float]:
21    graph = construir(n_irrelevantes=n_irrelevantes, seed=seed)
22    t0 = time.perf_counter()
23    result = graph.invoke(
24        {"messages": [{"role": "user", "content": ENCARGO}], "tokens_acumulados": 0},
25        config={"configurable": {"thread_id": f"cmp-{n_irrelevantes}"}},
26    )
27    latencia = time.perf_counter() - t0
28    # tokens_acumulados lo poblan los nodos vía coste.contar() (ver coste.py).
29    # El monolítico de N0 usa el mismo acumulador en su único hilo.
30    return result["messages"][-1].content, result["tokens_acumulados"], latencia
31
32if __name__ == "__main__":
33    # Una curva por arquitectura; mismo encargo, mismas longitudes, mismo seed.
34    # correr() devuelve (informe, tokens medidos, latencia) por punto.
35    curva_n0 = {n: correr(construir_grafo, n) for n in LONGITUDES}
36    curva_n4 = {n: correr(construir_orquestado, n) for n in LONGITUDES}
37    calidad_n0 = {n: medir(inf) for n, (inf, _, _) in curva_n0.items()}
38    calidad_n4 = {n: medir(inf) for n, (inf, _, _) in curva_n4.items()}
39    tokens_n4 = {n: tok for n, (_, tok, _) in curva_n4.items()}      # medidos, no estimados
40    latencia_n4 = {n: lat for n, (_, _, lat) in curva_n4.items()}    # time.perf_counter()

Léelo de arriba abajo. medir es idéntica a la de N0·L4: dos comprobaciones de strings que tú controlas. correr invoca cualquiera de las dos arquitecturas con el mismo encargo y seed, y devuelve tres cosas: el informe, los tokens medidos del acumulador y la latencia con time.perf_counter(). El __main__ produce las dos curvas, los tokens y la latencia sobre las mismas longitudes. La comparación es legítima porque nada cambia salvo la arquitectura.

La verificación cualitativa la corres aparte con promptfoo y su llm-rubric, como en N0·L4 y el apéndice A — dos providers en el mismo config, una columna por arquitectura.

El resultado: las dos curvas y los costes

El sweep imprime dos curvas y una tabla. Estos números son ilustrativos —tu run dará los suyos—; lo que importa es la forma y la relación entre las columnas:

longitud (docs irrelevantes) | calidad N0 (monolítico) | calidad N4 (orquestado)
-------------------------------------------------------------------------------
  0 docs |  0.92 | #########################   |  0.90 | ########################
 10 docs |  0.85 | #######################     |  0.91 | #########################
 25 docs |  0.61 | ################            |  0.88 | ########################
 50 docs |  0.34 | #########                   |  0.86 | #######################

calidad
1.0 |  N0 *   N4 o
    |     o      o      o      o      ← N4 sostiene
    |  *
0.5 |        *
    |                      *          ← N0 se desploma (el codo de N0·L4)
0.0 +----+----+----+----+----
     0   10   25   50   docs irrelevantes

Lee la forma, no los dígitos. La curva N0 es la de N0·L4: cae con fuerza pasado el codo de los 10-25 documentos. La curva N4 se mantiene casi plana — porque cada documento se lee en la ventana de un worker, y al orquestador solo le cruza el destilado. El monolítico se ahoga en el contexto; el orquestado lo reparte.

Y la tabla de costes, a iso-encargo:

arquitectura | tokens totales (medidos) | desglose               | latencia (medida)
-----------------------------------------------------------------------------------------
N0 monolítico | (medido en tu run)      | un solo hilo           | (medido en tu run)
N4 orquestado | (medido, ≈ ×N mayor)    | Σ workers + orquestador | (medido — coordinación)

Las cifras absolutas las da tu run. El patrón es el del corpus: el orquestado cuesta del orden de varias veces más (referencia A.6: multi-agente ~15× un chat, agentes ~4×). La tabla pone ese coste delante, no debajo de la alfombra.

Self-explanation

Antes de leer la respuesta, intenta tú: ¿por qué comparamos a iso-encargo y no a iso-tokens?

4.6Hazlo tú

Andamiaje decreciente: integras las palancas y construyes la comparativa. Esto es el cuerpo de las partes (a), (c) y (d) del checkpoint C4.

Ejercicio — integra las palancas y corre la comparativa

Tienes el grafo orquestado de N4·L3. Haz tres cosas, en orden:

1. Integra las palancas donde correspondan. Compaction en el hilo del orquestador (su historial de destilados crece); informe y notas como artefactos externos fuera de messages (N2); toolset por rol (el explorador sin escribir_seccion, el orquestador sin leer de documentos enteros). Cada una donde su clase de contexto lo pide — no las enciendas en bloque.
2. Mide los tokens por componente. Usa count_tokens (corpus F.6) para sumar lo que consume cada worker y el orquestador. El total del run es esa suma.
3. Corre la comparativa. Re-ejecuta el sweep de N0·L4 sobre los dos providers, mismo encargo escalado, mismas longitudes, mismo seed. Emite las dos curvas y la tabla de costes.
4. Registra la latencia. Mide la latencia total del run orquestado contra el monolítico con time.perf_counter() alrededor de correr(). La coordinación cuesta tiempo, no solo tokens; ponlo en la tabla.

Pista de implementación: reutiliza comparativa.py de 4.5. La compaction del orquestador la montas según la API de B.4 (umbral, resumen, descarte) o con un nodo de summarización a mano en el grafo. La firma exacta del SummarizationNode como hook no está confirmada (corpus F.2), así que móntalo a mano si dudas. No hay solución cerrada.

Elaborative interrogation — antes de correrlo, predice: ¿por dónde caerá la curva N4 si OLVIDAS poner el informe como artefacto externo y dejas que la compaction del orquestador lo comprima?

4.7Comprueba

Sin pistas. Gate de maestría: leer tu propia comparativa y emitir el veredicto de tres partes.

Un compañero te pasa esta comparativa para validar su sistema orquestado. Léela y emite el veredicto — o señala por qué no puedes emitirlo.

longitud | calidad N4 (orquestado) | tokens N4
--------------------------------------------------
 25 docs |  0.88                   | (no medido)
 50 docs |  0.86                   | (no medido)

(No adjunta la curva del monolítico. Estima los tokens "en ~15× el chat" sin medirlos. Su caso de "cuándo NO compensa" dice: "cuando no hay presupuesto".)

1. Identifica qué le impide superar el checkpoint C4.
2. Explica qué dimensión de la rúbrica falla en cada caso.
3. Reescribe lo que haga falta para que el veredicto sea válido.

4.8Conecta

Acabas de construir la comparativa que es el cuerpo del checkpoint C4. Cubre dos de sus cinco dimensiones, las que se demuestran con datos.

Transcrita fiel de 03-arquitectura.md, la rúbrica C4 pide:

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.

La comparativa que montaste en 4.5 y corriste en 4.6 es exactamente la dimensión 4. La tabla de costes medidos y el veredicto de tres partes son la dimensión 5. Las dimensiones 1, 2 y 3 —decisión justificada, aislamiento real, handoffs completos— las trabajaste en N4·L1, L2 y L3. Falta empaquetarlas.

Esto cierra el arco que abrimos en N0·L1 (/cursos/context-engineering/diagnostico/el-mito-de-la-ventana-infinita). Empezaste con la anécdota de un run muerto: un encargo que Magallanes no podía con él. Hoy ese mismo encargo, escalado hasta exceder una ventana entera, lo completa un sistema orquestado — y tienes la curva que lo demuestra, con su baseline al lado y sus costes medidos. La anécdota es un dato.

Lo que viene en L5 es el gate. Allí escribes la memoria de diseño que completa las dimensiones 1-3 y empaqueta el entregable de C4: el sistema multi-contexto, la comparativa N0-vs-N4 de hoy, y la justificación de cada decisión. Es el cierre del curso.

4.9Reflexiona

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

• ¿Qué aprendiste? Resume en una frase por qué comparar a iso-encargo, y no a iso-tokens, es lo que hace honesto el veredicto.
• ¿Qué sigue sin estar claro? ¿Tienes claro por qué la compaction del orquestador NO debe poder tocar el informe a medias? Si no, vuelve a 4.4 (artefactos externos) y a la predicción de 4.6.
• ¿Qué harías distinto? La próxima vez que alguien te enseñe "mi sistema multi-agente es mejor", ¿qué tres datos le pedirías antes de aceptarlo?

Esto requiere práctica. La intuición de "qué palanca va en qué clase de contexto" llega integrando sistemas, no leyendo sobre ellos. En L5 conviertes esta comparativa en el entregable completo del checkpoint C4 — el que cierra el curso.