Gestión de contexto: hechos, escalado y procedencia

Tu agente de soporte lleva 40 turnos con un cliente. Al principio dijo: «Pedido 88213, 149,90 €, me lo prometieron para el viernes». Tras varios resúmenes progresivos, el agente escribe: «Entiendo que su pedido llegó con retraso y desea una compensación». El importe, el número y la fecha se han vuelto vagos. Nadie ha roto nada: el contexto simplemente se ha ido diluyendo.

Ese es el dominio 5, Context Management & Reliability (15 %, unas 9 preguntas). Pesa menos que otros, pero aparece cruzado con los escenarios de soporte, multiagente y extracción. Lo que se evalúa no es «tener mucho contexto», sino decidir qué entra, qué se conserva y qué se escala. Y casi nunca la respuesta es «un modelo con más ventana». Sobre RAG, la guía deja fuera embeddings y bases vectoriales: lo tratamos solo como concepto.

Conservar la información en interacciones largas (5.1)

Hay tres riesgos que el examen describe con síntomas concretos.

Resumen progresivo con pérdida. Cada compactación convierte cifras, fechas y expectativas del cliente en frases genéricas.
Lost in the middle. El modelo atiende mejor al principio y al final de una entrada larga que a lo que queda en medio.
Resultados de herramientas verbosos. Un lookup_order devuelve 40 campos y a ti te importan 5. Cada llamada acumula tokens inútiles.

La respuesta de diseño: un bloque persistente de «hechos del caso» (cliente, pedido, importe, fecha, lo prometido) que vive fuera del historial resumido y se reinyecta en cada turno. El resumen cubre la conversación; los hechos críticos no se resumen.

Frente a frenteDónde viven los datos críticos

Solo en el historial

se resume y se degrada

Cada compactación diluye cifras y fechas
Lo que queda a mitad del contexto se atiende peor
Los resultados de herramientas verbosos desplazan lo importante
El síntoma: el agente pregunta de nuevo o habla de forma vaga

Bloque de hechos del caso

persistente y estructurado

Importes, IDs, fechas y compromisos en un bloque aparte
Se coloca al principio, con encabezados claros
Las salidas de herramientas se recortan a los campos útiles
Los subagentes devuelven datos estructurados con metadatos

Si el enunciado habla de datos que se vuelven vagos tras resumir, la respuesta es sacarlos del resumen, no ampliar la ventana.

Otras prácticas que caen: poner los resúmenes clave al principio, usar secciones con encabezados y recortar la salida de las herramientas antes de que entre en el contexto (un hook PostToolUse, que viste en la lección 2, sirve para eso).

Escalado y ambigüedad (5.2)

¿Cuándo pasa un agente el caso a una persona? La guía distingue disparadores válidos de señales poco fiables.

Disparadores válidos:

El cliente pide una persona. Se escala de inmediato, sin discutir.
La política tiene un hueco o una excepción que el agente no puede decidir.
El agente no puede avanzar (herramienta caída, falta de permisos).

Señales poco fiables: el sentimiento del cliente y la confianza autodeclarada del modelo. Un cliente enfadado puede tener un caso trivial; un modelo puede estar muy seguro y equivocarse.

Si el caso es sencillo y el cliente solo está molesto, lo correcto es reconocer la frustración y ofrecer resolverlo, y escalar si insiste. Si hay varias coincidencias de cliente, el agente pide más identificadores en vez de elegir una. Y los criterios de escalado se dejan explícitos, con ejemplos few-shot (lección 5).

Pregunta de examen

Tu agente de soporte escala según el sentimiento detectado: si el cliente parece enfadado, pasa a un humano. Los humanos se quejan de recibir casos triviales, mientras otros casos con excepciones de política se resuelven mal. ¿Cuál es la mejor primera medida?

Errores en sistemas multiagente (5.3)

En la lección 3 viste los errores estructurados de MCP. Aquí el problema es qué hace el sistema cuando un subagente falla.

Un subagente de búsqueda hace timeout. Tres malas reacciones: devolver una lista vacía como si nada (suprime el error), abortar todo el informe por un solo fallo, o inventar el resultado. La buena es propagar un contexto de error estructurado:

Tipo de fallo (transitorio, permiso, negocio…).
Qué se intentó (consulta, fuente).
Resultados parciales que sí se obtuvieron.
Alternativas posibles.

El subagente resuelve localmente lo transitorio (un reintento) y solo propaga lo que no puede arreglar. El coordinador sintetiza con anotaciones de cobertura: «No se pudo consultar la fuente B; las conclusiones sobre X se basan solo en A y C». Y recuerda la distinción clave: fallo de acceso no es resultado vacío válido.

Paso a pasoUn fallo en un subagente, bien gestionado

El subagente de búsqueda recibe un timeout al consultar una fuente.

1 de 5

Exploración de código grande (5.4)

En sesiones largas sobre un repositorio grande el contexto se degrada: el modelo empieza a olvidar hallazgos tempranos o a contradecirse. Las medidas de la guía:

Ficheros scratchpad donde se anotan los hallazgos, para no depender de la memoria de la conversación.
Subagentes que exploran y devuelven un resumen, de modo que el detalle no ensucia el contexto principal (el subagente Explore de la lección 4).
Resumir antes de la siguiente fase: cerrar el descubrimiento con un resumen y arrancar la implementación con él.
Manifiestos de estado para recuperarse de una caída: qué se hizo, qué falta.
/compact para reducir un contexto cargado cuando la sesión debe continuar.

La idea común: externalizar el estado a algo que no se degrade, en lugar de confiar en que el modelo lo recuerde.

Revisión humana y confianza (5.5)

Tu extractor presume de un 97 % de precisión global. Parece excelente. Pero ese número puede esconder que en un tipo de documento, o en un campo concreto, falle el 30 %. La guía insiste en tres ideas:

Mide por tipo de documento y por campo, no solo en global.
Usa muestreo aleatorio estratificado para auditar, incluso las extracciones que parecen seguras.
La confianza por campo solo sirve si está calibrada con un conjunto etiquetado. Entonces se puede enrutar a humanos lo de baja confianza o con fuentes contradictorias.

Es la continuación de lo que ya apuntamos en la lección 5: la confianza del modelo es una señal de enrutado, no una prueba. Sin calibrar, es una opinión.

Procedencia e incertidumbre en síntesis multifuente (5.6)

Tu sistema de investigación combina cinco fuentes. Dos dan cifras distintas del mismo dato. ¿Qué hace la síntesis?

Preserva el mapeo afirmación-fuente. Cada dato del informe sigue vinculado a su origen; así se pueden citar y verificar. Si los subagentes devuelven solo prosa, el vínculo se pierde.
Anota los conflictos con su fuente, en lugar de elegir uno en silencio.
Usa las fechas de publicación: dos cifras distintas pueden ser dos momentos distintos, no una contradicción.
Separa lo establecido de lo discutido en secciones diferentes.
Adapta el formato al contenido: tablas para finanzas, prosa para noticias, listas para hallazgos técnicos.

Esto enlaza con las citaciones: la procedencia no se reconstruye al final, se arrastra desde la recuperación. Conceptualmente, eso es lo que hace útil un esquema RAG (recuperar fragmentos relevantes e incluirlos en el contexto): no que el modelo «sepa más», sino que cada afirmación pueda apoyarse en un fragmento identificable. Los detalles de embeddings y bases vectoriales quedan fuera del examen.

MapaQué hacer con fuentes que no coinciden

Mapa · Afirmación y fuente

Cada dato lleva su origen (fuente, fecha, fragmento). Los subagentes devuelven datos estructurados con metadatos, no solo texto resumido.

Pulsa cada casilla: son las cuatro decisiones que más se evalúan.

Para el examen

Un patrón recorre todo el dominio: cuando algo se degrada con el tiempo o con el volumen, la solución es estructurar y externalizar (hechos persistentes, scratchpads, errores estructurados, procedencia), no ampliar (más ventana, más modelo) ni adivinar (sentimiento, confianza autodeclarada).

En el examenDominio 5 en una ficha

Dominio · Dominio 5 · Context Management & Reliability (15 %)

Lo que tienes que dominar

Datos críticos (importes, fechas, IDs, compromisos) en un bloque persistente de hechos del caso, fuera del historial resumido.
Lost in the middle: lo importante, al principio o al final y con encabezados; recortar salidas verbosas de herramientas.
Escalar de inmediato si el cliente pide una persona, ante huecos de política o si no se puede avanzar.
Caso sencillo con cliente molesto: reconocer la frustración y ofrecer resolver; escalar si insiste.
Varias coincidencias de cliente: pedir más identificadores, no elegir.
Errores en multiagente: contexto estructurado (tipo, intento, parciales, alternativas) y recuperación local de lo transitorio.
Fallo de acceso no es resultado vacío válido; la síntesis anota la cobertura.
Exploración larga: scratchpad, subagentes, resumen entre fases, manifiestos de estado y /compact.
Precisión global no basta: desglosar por tipo y campo, muestreo estratificado y confianza calibrada con datos etiquetados.
Procedencia: mapeo afirmación-fuente, conflictos anotados con su origen y fechas de publicación.

Donde se suele fallar

Resolver la pérdida de datos con una ventana de contexto mayor o un modelo más grande.
Escalar por sentimiento o por confianza autodeclarada.
Devolver una lista vacía cuando un subagente no pudo acceder a la fuente.
Abortar todo el flujo por el fallo de un solo subagente.
Confiar en una precisión global alta sin desglosar por tipo de documento o campo.
Elegir en silencio una de dos cifras contradictorias en lugar de anotar ambas.
Sobreingeniería (clasificador, capa de enrutado) antes de definir criterios explícitos.

Checklist para el examen

0 de 9 dominados

Marca lo que ya sabrías responder en el examen.