La ingeniería de contexto de LangChain lleva la fiabilidad de los agentes más allá de ventanas de contexto más grandes

La ingeniería de contexto de LangChain considera ahora cuatro mecanismos esenciales para los agentes de larga duración, pese a la fijación de la industria por ventanas de contexto cada vez mayores. El enfoque combina presupuestos de contexto, descarga externa, compresión, estado estructurado de tareas pendientes y memoria persistente. En conjunto, estos controles trasladan la responsabilidad del modelo de lenguaje al arnés del agente.

La distinción importa porque un límite de contexto anunciado es solo una cifra de capacidad. No garantiza que un agente detecte la instrucción correcta después de cientos de llamadas a herramientas. Tampoco preserva el trabajo sin terminar cuando desaparecen mensajes antiguos.

Por ello, la competencia emergente no enfrenta a LangChain con un único marco rival. Enfrenta el estado gestionado por el arnés con la premisa de que un modelo puede recuperar de forma fiable su objetivo a partir de una transcripción en expansión. OpenAI y Anthropic están adoptando movimientos arquitectónicos similares, lo que sugiere que este problema abarca modelos y plataformas.

La ingeniería de contexto de LangChain convierte el contexto en un recurso gestionado

El cambio importante es que el contexto se está convirtiendo en un recurso de ejecución diseñado, no en una transcripción ilimitada.

Un informe del 12 de septiembre destacó cuatro mecanismos dentro de un arnés de agentes: gestión de presupuestos, compresión, repetición del estado de tareas pendientes y memoria entre sesiones. La documentación subyacente sobre ingeniería de contexto dota a estas ideas de comportamientos concretos en tiempo de ejecución.

El marco Deep Agents de LangChain divide el contexto en varias categorías. El contexto de entrada contiene prompts, archivos de memoria, habilidades e instrucciones de herramientas. El contexto de ejecución transporta configuraciones como identificadores de usuario o credenciales durante una ejecución. La compresión gestiona una conversación desbordada, mientras que el almacenamiento persistente respalda la información que debe sobrevivir entre hilos.

Esta clasificación cambia la forma en que los desarrolladores diagnostican los fallos de los agentes. Que un modelo olvide un requisito no significa automáticamente que carezca de inteligencia. El arnés puede haber colocado ese requisito en la capa de almacenamiento equivocada, ocultarlo bajo ruido o eliminarlo durante la compresión.

Los valores predeterminados del marco muestran hasta qué punto estas decisiones se han vuelto específicas. Los resultados grandes de herramientas pueden trasladarse al almacenamiento del sistema de archivos y sustituirse por referencias. Según la documentación, los resultados que superan los 20.000 tokens pueden descargarse automáticamente.

La resumización comienza cuando el contexto activo alcanza un umbral configurado, como el 85 por ciento de la ventana de entrada disponible del modelo. El marco conserva entonces una parte reciente mientras convierte el historial anterior en un resumen estructurado.

Estas cifras son valores predeterminados de implementación, no leyes universales. Un agente de investigación que procesa documentos extensos puede necesitar descargar información antes. Un agente de programación que depura un fallo acotado puede beneficiarse de conservar durante más tiempo la salida reciente de la terminal.

El principio más amplio es más duradero. El historial sin procesar no debería permanecer dentro del prompt del modelo solo porque alguna vez fue útil.

Deep Agents también preserva la conversación completa fuera del prompt activo cuando se produce la resumización. El resumen se convierte en la representación de trabajo, mientras que el registro original sigue disponible para su recuperación posterior.

Este diseño separa dos requisitos que las interfaces de chat suelen combinar. El agente necesita un conjunto de trabajo compacto para su próxima decisión. El sistema necesita un registro canónico para la recuperación, la inspección y la auditoría.

La distinción también explica por qué el informe de septiembre es más que otra historia sobre redacción de prompts. Su verdadero tema es la arquitectura de estado. La formulación del prompt sigue siendo relevante, pero la ubicación, la retención y la recuperación determinan ahora si las instrucciones sobreviven a una tarea larga.

Un desarrollador puede observar este patrón durante una migración de repositorio. El agente primero lee especificaciones, archivos de dependencias, pruebas y registros de compilación. Varias salidas pueden superar en minutos el tamaño de la solicitud original.

Mantener cada byte en el prompt activo vuelve la siguiente decisión más costosa y menos enfocada. Eliminarlo todo corre el riesgo de borrar el error que explica por qué falló la última prueba. El arnés debe elegir continuamente qué permanece activo, qué se convierte en referencia y qué entra en el estado duradero.

Esa elección crea la tensión central. La compresión protege la continuidad frente al desbordamiento, pero la propia compresión puede descartar el detalle necesario para continuar correctamente.

Una ventana más grande no garantiza un objetivo estable

El contexto extenso resuelve la capacidad de almacenamiento con más facilidad que la atención, la relevancia o el control de tareas.

Una carga de trabajo basada en agentes difiere de leer un único documento largo. La transcripción crece mediante decisiones repetidas, llamadas a herramientas, fallos, correcciones y cambios del entorno. La información que parecía poco importante durante un paso puede resultar decisiva varios pasos después.

La investigación ha cuestionado repetidamente la idea de que todos los tokens dentro de una ventana de contexto reciben la misma atención práctica. Trabajos anteriores sobre el problema de la atención posicional descubrieron que los modelos podían infrautilizar información relevante situada en el centro de entradas largas.

Esa investigación también vinculó el efecto con un sesgo de atención en forma de U. Los tokens cercanos al inicio y al final recibían más atención independientemente de su relevancia. La calibración propuesta mejoró los resultados hasta en 15 puntos porcentuales en las tareas de recuperación evaluadas.

Los modelos más recientes han mejorado en las pruebas simples de recuperación. La investigación de Google halló que Gemini 2.5 Flash manejaba determinadas tareas de búsqueda de hechos cerca de su límite de contexto sin el mismo declive posicional. Sin embargo, recuperar un dato no equivale a controlar un bucle de agente en evolución.

Un agente de larga duración debe recordar los criterios de aceptación originales mientras reacciona a nueva evidencia. Debe distinguir el trabajo completado del trabajo intentado. También debe detectar cuándo un nuevo fallo invalida un plan anterior.

LOCA-bench aborda esa distinción evaluando agentes bajo un crecimiento de contexto controlable. Su benchmark de contexto extenso mantiene estables las semánticas subyacentes de las tareas mientras incrementa el historial del entorno.

Los investigadores informan que el rendimiento de los agentes generalmente se deteriora a medida que los estados del entorno se vuelven más complejos. También concluyen que las estrategias avanzadas de gestión de contexto pueden mejorar el éxito general. Ese resultado desplaza la atención de la capacidad del modelo al sistema combinado de modelo y arnés.

La presión práctica recae sobre los equipos que desarrollan agentes de programación, agentes de investigación y productos de uso de computadoras. Ya no pueden describir una ventana de contexto grande como una estrategia completa de fiabilidad.

Cada herramienta adicional amplía la posible transcripción. La salida del navegador incorpora texto de navegación y elementos de página repetidos. Las herramientas de shell devuelven registros, trazas del compilador y resultados de pruebas. Las herramientas documentales pueden inyectar miles de líneas de archivos cuya relevancia sigue siendo incierta.

Por tanto, más entrada puede reducir la densidad de señal. Incluso si el modelo acepta técnicamente los tokens, el agente debe identificar qué observaciones determinan la siguiente acción.

La elaboración de presupuestos aborda este problema antes de que llegue el límite. Un presupuesto de contexto asigna el escaso espacio del prompt según su valor operativo. Los objetivos actuales y las normas de seguridad merecen una retención más sólida que las salidas antiguas y exitosas de herramientas.

El presupuesto también debe reservar espacio para la siguiente respuesta del modelo. Llenar una ventana de entrada hasta su límite anunciado puede dejar demasiado poco espacio para el razonamiento, los argumentos de herramientas o las instrucciones de recuperación.

Aquí es donde la compresión de contexto de los agentes se convierte en una política operativa en lugar de una función de emergencia. Los equipos necesitan umbrales, campos protegidos, asignaciones para el historial reciente y rutas de recuperación. También necesitan evaluaciones que prueben la política con trazas realistas.

Una evaluación útil debería introducir correcciones al final de una tarea. Debería ocultar detalles necesarios dentro de la salida de herramientas anterior. Debería obligar al agente a reanudar tras la compresión e identificar si cada requisito sigue activo.

La prueba también debería medir la continuidad falsa. Un agente puede producir prosa fluida tras perder su objetivo. La coherencia superficial no demuestra que su estado interno de tarea siga siendo correcto.

La descarga externa y la compresión resuelven partes distintas del desbordamiento

La descarga externa elimina evidencia voluminosa del prompt, mientras que la compresión reescribe el historial operativo del agente.

Los dos mecanismos están relacionados, pero tratarlos como intercambiables genera fallos evitables. La descarga externa conserva el material original en otro lugar. La compresión crea una representación más pequeña que no puede preservar todos los detalles.

Pensemos en una búsqueda de código que devuelve miles de coincidencias. El resultado completo puede residir en un archivo, una base de datos o un almacén de objetos. El prompt activo solo necesita una ruta, una vista previa breve y suficientes metadatos para recuperar líneas relevantes más adelante.

Esto preserva la fidelidad porque el contenido original sigue disponible. El agente no necesita recordar cada coincidencia. Necesita recordar dónde está el resultado y por qué se recopiló.

La compresión tiene más consecuencias. Convierte una secuencia de mensajes en una representación de estado más pequeña. Esa representación debe preservar decisiones, requisitos, fallos sin resolver y el plan actual.

Anthropic describe la compactación como la práctica de resumir una conversación cerca de su límite y, después, iniciar un nuevo contexto con ese resumen. Su guía sobre contexto para agentes recomienda preservar decisiones arquitectónicas, errores sin resolver y detalles de implementación.

Anthropic también advierte que una compactación agresiva puede eliminar información sutil cuya importancia se vuelve visible más adelante. Esa es la disyuntiva fundamental. El sistema debe descartar material antes de saberlo todo sobre los pasos futuros.

OpenAI ha llegado a una conclusión arquitectónica similar. Su API de Responses incluye compactación de respuestas nativa para flujos de trabajo prolongados e intensivos en el uso de herramientas.

OpenAI afirma que la representación compactada preserva el estado previo clave de forma eficiente en tokens. El siguiente contexto incluye ese elemento de compactación junto con información seleccionada de alto valor de la ventana anterior.

Estas implementaciones difieren, pero su dirección está alineada. Ambas sitúan la lógica de continuidad en la capa del arnés y de la API. Ninguna presupone que los desarrolladores deban reenviar una transcripción sin procesar que crece indefinidamente.

El objetivo inicial más seguro suele ser la salida redundante de herramientas. Una escritura de archivo completada no requiere que todo el archivo escrito siga incrustado en el historial de la conversación. Una instalación de dependencias exitosa rara vez necesita cientos de líneas históricas de registros.

Las operaciones fallidas requieren más cuidado. El error exacto, el comando que lo produjo y los detalles relevantes del entorno pueden determinar el siguiente intento. Un resumen genérico que diga “la compilación falló” destruye estado útil.

Por ello, una buena compresión de contexto de agentes debe preservar los vínculos causales. Debe registrar qué acción produjo qué observación, qué conclusión se obtuvo y si esa conclusión sigue siendo tentativa.

También debe distinguir el material de origen de la inferencia del agente. Si un resumen mezcla ambos, el agente reanudado puede tratar una conjetura anterior como evidencia verificada.

Un diseño práctico utiliza tres capas. La capa caliente contiene el objetivo, las restricciones, el estado de tareas pendientes, los mensajes recientes y la evidencia inmediata. La capa templada contiene resúmenes y artefactos indexados. La capa fría almacena transcripciones canónicas, archivos y resultados más antiguos.

La recuperación se vuelve entonces tan importante como el almacenamiento. Una referencia a un archivo solo ayuda si el agente sabe cuándo consultarla. Los metadatos deben describir el tema, el origen, la marca temporal y la relación del artefacto con el objetivo actual.

Un agente de investigación ofrece un ejemplo claro. Puede descargar artículos completos mientras mantiene activos los registros de citas y los resúmenes de afirmaciones. Antes de publicar, puede volver a los pasajes originales y verificar que cada resumen siga siendo preciso.

Un agente de programación puede utilizar el mismo patrón. Puede conservar la prueba fallida actual y la corrección prevista dentro del contexto activo. Los registros de compilación antiguos siguen siendo consultables, mientras que las decisiones arquitectónicas pasan a una nota duradera del proyecto.

Este enfoque por capas no elimina las pérdidas. Hace que las pérdidas sean explícitas, recuperables y comprobables.

El estado de tareas pendientes es el pequeño plano de control que mantiene el trabajo encaminado

Un estado estructurado de tareas pendientes protege la dirección de la tarea al indicar repetidamente al agente qué queda sin terminar.

Una lista de tareas parece más sencilla que la compresión o la memoria. Esa simplicidad hace que sea fácil subestimarla. En tareas largas, el estado de tareas pendientes actúa como un plano de control compacto sobre un conjunto de evidencia mucho mayor.

Los Deep Agents de LangChain incluyen una capacidad write_todos que divide el trabajo en pasos discretos. Un patrón de tareas relacionado almacena elementos con estados pendiente, en curso y completado.

Esas etiquetas crean una representación más fiable que un párrafo narrativo de progreso. Un párrafo puede mencionar varias acciones sin distinguir claramente entre finalización e intención. El estado estructurado exige un estatus explícito para cada elemento.

El estado de tareas pendientes también sobrevive a la resumificación con más facilidad que los compromisos dispersos. Un compactador puede proteger un objeto estructurado sin tener que localizar cada promesa dentro de la transcripción.

Esto se vuelve importante cuando un agente encuentra trabajo secundario atractivo. Un agente de programación puede descubrir errores de lint no relacionados durante la implementación de una función. Sin una lista de tareas estable, puede dedicar el contexto restante a corregir problemas fuera del alcance.

El estado de tareas pendientes vuelve a poner a la vista los criterios de aceptación. Puede indicar que la función solicitada sigue incompleta, que el nuevo problema de lint queda aplazado y que aún deben ejecutarse las pruebas de regresión.

Un elemento útil debe incluir más que una etiqueta breve. Necesita un estado, una condición de finalización y cualquier dependencia bloqueante. Las tareas de alto riesgo también pueden requerir la evidencia necesaria antes de completarse.

Por ejemplo, “actualizar la autenticación” es demasiado impreciso. Un elemento mejor establece que debe cambiar el comportamiento de actualización de tokens, que deben aprobarse las pruebas de inicio de sesión existentes y que es necesario verificar un nuevo caso de caducidad.

La repetición forma parte del mecanismo. El arnés puede insertar el estado actual de tareas pendientes cerca de la siguiente decisión del modelo, manteniendo el objetivo de trabajo cerca del final del prompt.

Esta ubicación contrarresta una debilidad estructural del control basado únicamente en transcripciones. La solicitud original permanece cerca del principio, mientras que la salida reciente de herramientas domina el final. La lista de tareas reformula el objetivo operativo donde el modelo está actuando en ese momento.

Sin embargo, el estado de tareas pendientes introduce sus propios modos de fallo. Un agente puede marcar un elemento como completado después de editar un archivo, pero antes de ejecutar las pruebas. Puede crear muchos elementos diminutos que consumen atención sin aclarar el progreso.

Por tanto, las actualizaciones de estado necesitan reglas de evidencia. Un cambio de código no queda verificado simplemente porque se aplicó un parche. Una afirmación de investigación no queda validada simplemente porque un resultado de búsqueda la mencionó.

El arnés puede exigir una referencia de verificación al cambiar un elemento a completado. Esa referencia podría identificar una prueba aprobada, un artefacto revisado o una fuente primaria citada.

La revisión humana también se vuelve más sencilla. Una persona puede inspeccionar una lista explícita de trabajo completado y pendiente sin reconstruir la tarea a partir de cientos de mensajes.

El estado de tareas pendientes no debería convertirse en memoria a largo plazo. Describe la tarea actual, no todas las preferencias ni decisiones históricas. Mezclar esas funciones produce otro objeto de estado sobrecargado.

Tampoco debería sustituir la evidencia detallada. La lista dirige la atención hacia los artefactos, pero no puede contener todos los hechos relevantes. Un elemento de tareas puede enlazar a un registro de pruebas sin incorporar el registro completo.

Para los trabajadores del conocimiento, este patrón se parece al diseño disciplinado de un flujo de trabajo de IA. Los objetivos, la evidencia, las decisiones y las próximas acciones se mantienen diferenciados en lugar de mezclarse en un único flujo conversacional.

Esa separación es el valor real. La transcripción registra actividad. El estado de tareas pendientes registra obligación.

La memoria de los agentes de IA amplía la continuidad más allá de una sesión

La memoria persistente resuelve la continuidad entre sesiones, pero solo cuando el arnés controla qué se escribe y qué se recupera.

La compresión permite que un agente atraviese los límites de contexto dentro de una ejecución larga. La memoria aborda un límite diferente: el final de un hilo y el comienzo de otro.

El diseño de LangChain utiliza rutas de memoria respaldadas por el sistema de archivos para la información que debe sobrevivir entre conversaciones. Un backend compuesto puede enviar rutas designadas, como un directorio de memorias, a un almacén duradero.

La documentación recomienda mantener al mínimo la memoria que siempre se carga. Las convenciones del proyecto y las preferencias estables del usuario pertenecen allí. Los flujos de trabajo detallados pueden permanecer en habilidades que se cargan solo cuando son relevantes.

Esta es una decisión de presupuesto disfrazada de regla organizativa. La información persistente sigue consumiendo contexto activo cuando se recupera. Guardarlo todo simplemente traslada la contaminación del contexto de la transcripción al almacén de memoria.

Por tanto, una memoria eficaz para agentes de IA requiere selección. Los hechos estables merecen persistencia. Las observaciones temporales, los planes caducados y las conjeturas sin verificar normalmente no.

La política de escritura importa porque la memoria generada por agentes puede amplificar errores. Si un agente almacena una conclusión incorrecta como regla duradera, las sesiones futuras pueden repetirla sin volver a examinar la evidencia original.

Cada memoria debe incluir procedencia, alcance y condiciones de actualización. La procedencia identifica de dónde proviene la información. El alcance establece a qué proyectos o usuarios se aplica. Las condiciones de actualización explican cuándo debe sustituirse la entrada.

Los conflictos requieren un tratamiento explícito. Una nueva instrucción de proyecto debe prevalecer sobre una convención anterior dentro de ese proyecto. No debe reescribir silenciosamente una preferencia global que se aplica en otros lugares.

La recuperación de memoria también necesita controles de relevancia. Cargar todas las notas guardadas al inicio recrea el problema del contexto sobredimensionado. El arnés debería inyectar solo un pequeño núcleo estable y recuperar otros registros cuando la tarea actual coincida con ellos.

Esto produce una división útil del trabajo. El prompt del sistema contiene comportamientos no negociables. El estado de tareas pendientes contiene obligaciones actuales. El contexto de trabajo contiene evidencia inmediata. La memoria persistente contiene conocimiento seleccionado de sesiones anteriores.

Los artefactos canónicos permanecen fuera de los cuatro. Los archivos fuente, las transcripciones, los resultados de pruebas y los documentos deben seguir siendo recuperables en su forma original.

Anthropic describe la toma estructurada de notas como una forma de que los agentes mantengan el progreso más allá de una única ventana de contexto. Sus ejemplos incluyen notas de tareas, ubicaciones exploradas, logros y estrategias reutilizadas después de reinicios.

El beneficio no es un recuerdo perfecto. Es la reconstrucción. Tras un reinicio, el agente puede recuperar su objetivo, localizar la evidencia y continuar desde un estado explícito.

Esa reconstrucción necesita límites de seguridad. La memoria personal no debe cruzarse entre usuarios. Los secretos del proyecto no deben entrar en un almacén compartido globalmente. El texto recuperado también debe seguir siendo datos, no instrucciones de confianza.

Estos riesgos hacen que la observabilidad sea esencial. Los desarrolladores deberían poder inspeccionar qué memorias entraron en un prompt, por qué fueron seleccionadas y si influyeron en una acción.

La eliminación también importa. Un sistema de memoria duradera necesita una forma de eliminar preferencias obsoletas, conclusiones incorrectas e información sensible. La persistencia sin controles de ciclo de vida se convierte en un pasivo.

Los sistemas más creíbles tratarán la memoria como datos gestionados, no como un recuerdo humano. Expondrán registros, procedencia, permisos, retención y comportamiento de recuperación.

Este enfoque también evita afirmaciones exageradas. La memoria de los agentes de IA no proporciona a un modelo una experiencia personal continua. Proporciona a un proceso sin estado o parcialmente con estado acceso a registros seleccionados de trabajos anteriores.

La próxima prueba es la calidad de recuperación, no la capacidad máxima de tokens

Las plataformas de agentes ahora deben demostrar que sus arneses preservan objetivos y evidencia después de transformaciones repetidas de estado.

Tres señales merecen atención durante los próximos meses. La primera es la precisión de recuperación después de múltiples ciclos de compactación. Los proveedores deberían comprobar si los agentes preservan restricciones, elementos sin terminar y atribución de fuentes a través de reinicios repetidos.

Un benchmark útil incluiría requisitos introducidos en distintas etapas. Después mediría si el agente sigue esos requisitos tras descarga, compresión, interrupción y reanudación.

Esta señal reforzaría el enfoque gestionado por el arnés si el estado estructurado supera de forma consistente a las transcripciones largas sin procesar. Debilitaría el argumento si la compactación cambia repetidamente las decisiones o pierde restricciones protegidas.

La segunda señal es la observabilidad de la memoria. Los desarrolladores necesitan registros que muestren qué almacenó el agente, qué recuperó y por qué cada elemento entró en el contexto activo.

Las herramientas de inspección claras harían que la memoria de los agentes de IA fuera más segura para el uso empresarial. Una recuperación oculta o irreproducible dejaría a los equipos sin capacidad para explicar por qué un agente repitió una decisión desactualizada.

La tercera señal es el estado de tareas pendientes vinculado a verificación. Los frameworks deberían conectar el estado de finalización con evidencia concreta en lugar de permitir que el modelo declare éxito sin validación.

Para el trabajo de programación, esa evidencia puede incluir pruebas y resultados de compilación. Para la investigación, puede incluir comprobaciones de fuentes primarias. Para tareas de uso de ordenador, puede incluir cambios confirmados en el estado de la aplicación.

El éxito en esta señal demostraría que el estado de tareas pendientes ofrece más que una visualización del progreso. Establecería la lista de tareas como una superficie de control exigible.

El caso escéptico sigue siendo considerable. Cada algoritmo de compresión toma decisiones de retención bajo incertidumbre. Cada sistema de memoria puede recuperar el registro equivocado. Cada lista de tareas puede preservar un plan incorrecto con una consistencia impresionante.

Los arneses también pueden ocultar las limitaciones del modelo tras una continuidad pulida. Un agente puede reanudar el trabajo sin problemas mientras malinterpreta un requisito que desapareció durante la resumificación. Los usuarios necesitan evaluaciones basadas en resultados, no demostraciones de persistencia fluida.

Los costes introducen otra disyuntiva. Los resúmenes frecuentes requieren llamadas adicionales al modelo. La recuperación añade latencia. El almacenamiento duradero crea obligaciones de gobernanza. El seguimiento rico del estado aumenta la complejidad de ingeniería.

Sin embargo, la alternativa no es gratuita. El trabajo repetido consume tokens y tiempo. La pérdida de objetivos puede producir cambios incorrectos, investigación incompleta o uso inseguro de herramientas. Una ventana más grande retrasa estos fallos sin eliminar sus causas.

La ingeniería de contexto de LangChain es importante porque hace visibles estas disyuntivas. El trabajo de compactación de OpenAI y la orientación de Anthropic sobre memoria estructurada apuntan en la misma dirección. La fiabilidad a largo plazo se está convirtiendo en un problema de sistemas.

Por tanto, los equipos que evalúen un agente deberían plantear preguntas operativas. ¿Qué información permanece activa? ¿Qué se resume? ¿Qué registros siguen siendo canónicos? ¿Cómo recupera el agente el trabajo sin terminar después de una interrupción?

También deberían probar tiempos adversariales. Corrijan al agente poco antes de la compresión. Modifiquen un criterio de aceptación después de varios pasos completados. Reanuden la tarea en una sesión nueva e inspeccionen qué se conserva.

El diseño más sólido no dependerá de un único mecanismo. Los presupuestos evitan sobrecargas evitables. La descarga preserva evidencias voluminosas. La compresión mantiene una narrativa funcional. El estado de tareas pendientes protege las obligaciones inmediatas, mientras que la memoria recupera conocimientos seleccionados más adelante.

Esa combinación es la lección central de la ingeniería de contexto de LangChain. La próxima generación de agentes no triunfará por recordarlo todo. Triunfará por preservar el estado adecuado, recuperar la evidencia original y demostrar que el trabajo completado sigue cumpliendo el objetivo.

¿Qué deberían hacer ahora quienes desarrollan estos sistemas? Instrumentar una tarea larga representativa, forzar varios eventos de compactación y comparar el resultado final con sus criterios de aceptación originales. Registrar cada restricción perdida, cada finalización sin respaldo y cada recuperación innecesaria. Después, ajustar el presupuesto, el estado protegido de tareas pendientes y la política de memoria antes de ampliar la autonomía del agente.