Context Management
Administrar la información activa
Context Management es la práctica de seleccionar, ensamblar, mantener, refrescar, comprimir, aislar y transferir la información que una aplicación AI pone a disposición de una inferencia o ejecución. Su objeto es el contexto efectivamente disponible para una tarea: instrucciones, evidencia, mensajes, estado relevante y resultados de herramientas. No exige que todos esos elementos estén presentes ni que la aplicación sea un agente.
Una interacción no comienza necesariamente con información suficiente y tampoco conserva indefinidamente su validez. El usuario puede cambiar el objetivo; una consulta puede devolver una versión más reciente; una acción puede modificar el estado que justificaba la decisión anterior. Administrar contexto significa decidir qué información necesita la siguiente operación y qué condiciones permiten seguir confiando en ella.
El problema aparece en dominios diferentes. Una aplicación de asistencia debe distinguir políticas vigentes y conversaciones anteriores; un analista debe conservar la procedencia de una cifra; un workflow debe transferir decisiones a una etapa posterior. La práctica general no prescribe una carpeta, una base de datos ni un framework. Cada aplicación necesita relacionar contenido activo, propósito y evidencia disponible.
Contexto y Context Window
El contexto es la información realmente suministrada. La Context Window es una capacidad o límite del modelo y su ejecución, tratado en LLM Fundamentals. Aumentar capacidad no selecciona fuentes ni resuelve contradicciones. Tampoco convierte información histórica en información vigente.
Una entrada puede caber y aun ser inadecuada: datos de otro caso, instrucciones incompatibles, versiones mezcladas o detalles irrelevantes pueden desplazar la evidencia decisiva. La ausencia de truncamiento solo demuestra una propiedad del tamaño bajo ciertas condiciones. No demuestra que la información sea suficiente, correcta o utilizable para la tarea.
Además del límite físico, existe un presupuesto práctico de atención, latencia y comprensión. Repetir un mismo hecho en mensajes distintos puede reforzarlo artificialmente y dificultar identificar su fuente. Por eso más contexto no equivale a mejor contexto. Reducirlo tampoco es un objetivo absoluto: una omisión puede eliminar precisamente la condición que cambiaba una decisión.
Context Engineering como práctica deliberada
Dentro de esta área, Context Engineering enfatiza el diseño intencional de qué información se selecciona, cómo se estructura, cuándo se actualiza y cómo se entrega. Context Management nombra la responsabilidad más amplia; Context Engineering es su práctica de ingeniería. No se necesita otro canónico general para repetir la misma frontera con un título diferente.
La exposición de Anthropic sobre effective context engineering, publicada en 2025, documenta un enfoque práctico de selección y mantenimiento del contexto de agentes. Es una perspectiva de implementación útil, no una definición universal ni evidencia de que una técnica funcione igual en cualquier modelo.
Context Engineering for Software Development conserva su identidad como aplicación específica al desarrollo: repositorio, instrucciones, cambios, tests, resultados y decisiones. Este documento establece la práctica independiente del dominio; aquel desarrolla cómo ejercerla sobre trabajo de software. No se convierte el canónico existente en una traducción o Perspective Note ni se repiten aquí sus procedimientos de repositorio.
Prompt Engineering se concentra en cómo expresar instrucciones, ejemplos y mensajes. Context Management también decide qué evidencia, versiones y estado deben acompañarlos. El diseño del contexto no reemplaza la expresión del prompt: una instrucción ambigua sigue siendo ambigua aunque esté acompañada de muchas fuentes, y un prompt claro puede recibir evidencia equivocada.
Context Selection
La selección pregunta qué información merece participar ahora y para qué decisión. Relevancia, autoridad, frescura, costo de incorporación, riesgo y fase de la tarea son criterios posibles. No forman una fórmula universal: la misma fuente puede ser suficiente para orientar una búsqueda y resultar insuficiente para autorizar una acción.
Conviene distinguir una solicitud del usuario, una regla aplicable, una observación y una hipótesis. Si se mezclan como texto indiferenciado, el consumidor puede tratar una suposición como requisito. Conservar procedencia y alcance permite revisar qué información sostiene una conclusión y qué incertidumbre todavía necesita resolución.
La selección también debe reconocer evidencia ausente. Si falta una condición decisiva, llenar el espacio con información parecida puede esconder esa ausencia. Una aplicación puede continuar con una respuesta limitada, solicitar aclaración o consultar una fuente adecuada. La decisión depende del contrato de la tarea, no de completar una entrada aparentemente abundante.
Los conflictos necesitan permanecer visibles hasta resolver su alcance. Dos fuentes pueden describir periodos diferentes y no contradecirse realmente; también pueden discrepar sobre el mismo hecho. Elegir automáticamente la última encontrada confunde orden de recuperación con autoridad. El contexto puede conservar ambas observaciones, sus procedencias y la pregunta que todavía no está resuelta. Si una decisión requiere resolverla, la aplicación necesita evidencia adicional o una intervención apropiada, en lugar de producir una síntesis que borre la discrepancia. Un resumen más uniforme no necesariamente representa mejor el estado del conocimiento.
Las fases modifican necesidades. Explorar alternativas puede requerir amplitud; ejecutar una decisión concreta puede requerir pocos datos actuales y verificables. Retener todos los materiales exploratorios con el mismo peso puede contaminar la ejecución con opciones descartadas. Descartarlos sin conservar la razón de la decisión también puede obligar a repetir trabajo o reabrir una alternativa por error.
Ensamblaje y procedencia
Ensamblar consiste en convertir materiales seleccionados en una entrada interpretable. El orden, las etiquetas y la separación entre instrucciones y evidencia importan porque condicionan cómo puede entenderse la información. Una lista de fragmentos sin origen dificulta reconocer si describen la misma versión o situaciones diferentes.
Un contexto útil puede identificar objetivo actual, restricciones, hechos observados, decisiones tomadas y preguntas abiertas. No es una plantilla obligatoria: son responsabilidades informativas que la aplicación debe cubrir cuando correspondan. Un workflow pequeño puede resolverlas con pocos campos; una tarea larga puede requerir artefactos enlazados y recuperación selectiva.
La procedencia debe sobrevivir a transformaciones relevantes. Un resumen que conserva una conclusión y pierde su condición de validez cambia lo que el siguiente paso puede inferir. «La entrega está disponible» no equivale a «la consulta de ayer indicó disponibilidad para una región». La segunda formulación conserva límites que pueden exigir refresh antes de actuar.
Context Refresh
Refresh revisa el contexto cuando cambia el estado relevante o aparece evidencia que contradice una premisa. No consiste simplemente en agregar mensajes. Puede requerir reemplazar una observación, retirar una conclusión, marcar información histórica o volver a consultar una fuente antes de una acción.
Los resultados de Tool Use pueden cambiar la interpretación de la tarea. Una búsqueda vacía no prueba necesariamente ausencia si estuvo limitada por permisos; una actualización exitosa puede invalidar el estado leído antes. El contexto activo debe representar esos límites en lugar de conservar simultáneamente versiones incompatibles como si todas describieran el presente.
Actualizar todo continuamente tampoco es gratuito. La aplicación necesita relacionar decisiones con la volatilidad de sus premisas. Un dato estable puede reutilizarse; una condición sensible al tiempo puede necesitar comprobación cercana al uso. No existe un intervalo universal que elimine el riesgo de obsolescencia.
Una revisión explícita ayuda a distinguir «no cambió» de «no se volvió a comprobar». Ambas situaciones pueden producir el mismo texto, pero aportan evidencia distinta. Si una comprobación falla, reemplazar silenciosamente el dato actual por uno antiguo puede introducir una certeza injustificada. El resultado debería conservar la incertidumbre o elegir una alternativa permitida.
Compression y Compaction
Compaction reduce o reorganiza contexto intentando preservar lo necesario para continuar. Puede utilizar resúmenes, estado estructurado, retención selectiva o artefactos externos que puedan recuperarse después. La meta es conservar información relevante para una tarea, no reproducir cada palabra del historial.
La transformación puede perder información. Un resumen puede borrar excepciones, fusionar versiones, convertir una hipótesis en hecho o eliminar por qué se descartó una alternativa. Compaction no es memoria perfecta y una reducción de tamaño no demuestra conservación de significado. Importa qué decisiones posteriores dependen del material eliminado.
Conviene preservar incertidumbres y referencias a evidencia verificable. Un estado estructurado puede distinguir pendiente, comprobado y supuesto; un resumen narrativo puede conservar las razones y límites. Ningún formato garantiza fidelidad por sí mismo. La utilidad depende de cómo se construye, revisa y consume el resultado.
Externalizar artefactos tampoco los hace automáticamente disponibles. Si una nueva sesión no puede localizar o leer el archivo, su existencia no ayuda a la inferencia. La transferencia debe incluir referencias recuperables y una indicación de qué contienen. Un enlace a evidencia completa puede complementar el resumen sin incorporar siempre todo el material.
Es especialmente importante evitar resúmenes recursivos que acumulen errores sin volver a la fuente. Cuando una condición se vuelve decisiva, puede ser preferible recuperar su evidencia original. No toda pérdida exige detener la tarea, pero debe reconocerse cuándo una decisión ya no está suficientemente sustentada.
Context Isolation
Context Isolation evita que información de tareas, usuarios, agentes o ámbitos distintos influya accidentalmente en una ejecución. Incluye decidir qué historial pertenece al caso actual, qué memoria puede consultarse y qué resultados se comparten. Compartir un modelo o infraestructura no obliga a compartir el mismo contexto activo.
No equivale a Agent Sandboxing ni a aislamiento del workspace. Separar mensajes no impide que una herramienta acceda a archivos de otro caso si sus permisos lo permiten. De forma inversa, ejecutar en directorios separados no impide incorporar manualmente al prompt información del ámbito incorrecto. Son responsabilidades diferentes que pueden componerse.
El aislamiento de contexto no constituye por sí solo una frontera de seguridad. La selección informativa debe ser coherente con autorización y almacenamiento, pero no sustituye controles de acceso. Una aplicación puede tener mensajes bien separados y aun filtrar información mediante un resultado compartido o una búsqueda con alcance incorrecto.
También existe contaminación conceptual sin acceso indebido: una decisión válida para un cliente puede aplicarse por error a otro que tiene condiciones distintas. El diseño necesita preservar el alcance de la información, no solo ocultar datos sensibles. La reutilización requiere saber qué supuestos se mantienen entre casos.
Context Handoff
Un Context Handoff transfiere información útil entre sesiones, agentes, etapas o personas. Puede incluir objetivo, estado observado, decisiones, restricciones, trabajo pendiente, evidencia y límites de verificación. La transferencia debe permitir continuar sin presentar como completado lo que solo fue propuesto.
No es lo mismo que Agent Handoffs, que trata la transferencia de responsabilidad o control. Puede haber entrega de contexto sin cambiar quién decide, como cuando una herramienta aporta un resumen. También puede cambiar el responsable con información insuficiente: completar la transferencia de control no demuestra que el receptor entienda el estado.
Un buen handoff distingue el estado registrado del estado actual. Si el receptor continuará más tarde o en otro entorno, algunas observaciones requieren refresh. Registrar cuándo y cómo se obtuvieron permite decidir qué debe comprobarse de nuevo. Un resumen sin esa información puede ser útil para orientarse y peligroso si se interpreta como verificación reciente.
El receptor tampoco necesita recibir todo el historial. Debe disponer de lo necesario para la siguiente fase y de una vía para recuperar detalles relevantes. La compresión y el handoff pueden colaborar, pero son decisiones distintas: una reduce o reorganiza información; el otro la entrega a un nuevo contexto de ejecución.
Memory y recuperación de evidencia
Agent Memory conserva o permite recuperar información entre interacciones. Context Management determina qué parte se vuelve activa y cómo se utiliza ahora. Una memoria puede alimentar contexto, pero no todo dato retenido merece incluirse ni todo contexto procede de memoria persistente.
La recuperación tampoco decide por sí sola qué evidencia es suficiente. RAG puede aportar candidatos para generación; Context Management sigue teniendo que seleccionarlos, ensamblarlos, refrescarlos o descartarlos. RAG es una composición posible, no un sinónimo de toda administración de información. Su materialización queda para XIII.
Un resultado recuperado puede ser relevante y estar desactualizado, o ser actual y referirse a una entidad diferente. La aplicación necesita contrastar esas dimensiones. Presentar muchos fragmentos similares puede aparentar corroboración aunque todos procedan de la misma fuente o repitan el mismo error.
Ejemplo y condiciones de uso
Una aplicación prepara una respuesta sobre una solicitud de servicio. Selecciona la política aplicable al caso, el estado consultado y la aclaración del usuario. Distingue datos históricos de condiciones actuales y conserva el origen de la política. No necesita comportarse como agente autónomo para administrar esa información.
Si el usuario cambia la región, la política anterior puede dejar de ser aplicable. Agregar la nueva región al final del historial no basta: la aplicación debe retirar o marcar la conclusión anterior y revisar qué evidencia sostiene la nueva. Si una etapa humana recibe el caso, el handoff debe mostrar tanto el cambio como las comprobaciones pendientes.
Cuando la conversación crece, puede resumirse su objetivo y externalizar detalles. Antes de una acción sensible, recuperar la condición original o volver a consultar el estado puede ser necesario. Una respuesta fluida basada en el resumen no demuestra que la política vigente permita actuar.
Esta práctica es útil cuando información y tarea evolucionan, hay múltiples fuentes o la continuidad importa. Puede añadir complejidad innecesaria si se convierte cada interacción pequeña en un sistema general de memoria y resúmenes. La implementación debería comenzar por las decisiones informativas reales y ampliar mecanismos cuando aparezcan fallos observables.
Composición y límites
Structured Generation controla la forma de salida; Context Management gobierna información de entrada. Human in the Loop puede resolver una ambigüedad que el contexto no contiene; eso no autoriza a inventar la respuesta ni convierte toda participación humana en diseño del contexto.
Estas prácticas son componibles, no una pila obligatoria. Un sistema puede usar contexto seleccionado sin herramientas, memoria persistente o agentes. La pregunta central sigue siendo qué información tiene la ejecución, qué significa y hasta cuándo puede sostener las decisiones que se toman con ella.
Fuentes y alcance
Referencia primaria consultada el 2026-10-30: Anthropic, Effective context engineering for AI agents, 2025. La separación entre administración general, práctica de ingeniería y aplicación al desarrollo es síntesis editorial del Atlas. No se fija una política universal de compaction, una capacidad de producto ni una arquitectura de almacenamiento. RAG y AI Guardrails permanecen fuera de esta materialización.