Presupuestos de contexto para agentes de negocio de larga duración

Un agente de larga duración debería poder olvidar una conversación sin olvidar qué tiene permitido hacer. Si compactar la transcripción cambia si está autorizado a reembolsar a un cliente, el problema está en la arquitectura de la aplicación.

Las ventanas de contexto facilitan esta confusión. Se añaden la tarea, los resultados de las herramientas, los mensajes del cliente y las decisiones anteriores a un historial cada vez mayor, y después se pide al modelo que conserve lo importante. Con el tiempo, entre lo importante aparecen un estado de pedido desactualizado y una interpretación optimista de una aprobación. Un resumen más corto puede conservar ambos a la perfección.

Yo, por lo general, trataría el contexto de trabajo del modelo como una proyección desechable del estado persistente. Hay que reconstruirlo para la siguiente decisión y mantener fuera de esa proyección los registros necesarios para justificarla.

Tres tipos de información con distinta autoridad

Pensemos en un agente de atención al cliente hipotético que investiga un pedido retrasado. Consulta el pedido, encuentra la política pertinente, redacta una respuesta y espera a un supervisor. Durante la espera, el almacén envía la mercancía. El agente retoma la tarea con un resumen que sigue diciendo «no enviado». Tener más memoria no ha actualizado la información.

El estado que actúa como fuente de verdad pertenece al sistema responsable de cada dato: el servicio de pedidos para el estado del envío, el servicio de aprobaciones para la decisión del supervisor y el almacén del flujo de trabajo para la fase actual de la tarea. Estos registros deben tener versiones explícitas. Una nota generada por el modelo puede apuntar a ellos, pero no debería sustituirlos de forma silenciosa.

La evidencia recuperada respalda el razonamiento. Conviene guardar su fuente, alcance, revisión y momento de recuperación, además de la afirmación que sustenta. Una política de reembolsos y un correo de un cliente tienen distinta autoridad. Hay que etiquetarlos en consecuencia al ensamblar el contexto y separar las instrucciones de los documentos de la política de ejecución de la aplicación.

La memoria conversacional conserva la intención y la continuidad: qué pidió el cliente, qué alternativas se descartaron y qué preguntas siguen abiertas. Es útil, pero un resumen que diga «aprobado» debe remitir a un registro real de aprobación antes de permitir una operación de escritura.

La arquitectura de Lumi de Nieve ya describe fases de conversación, consultas a API internas y estado del chat persistente. El diseño de este artículo amplía la discusión al ciclo de vida del contexto; es una propuesta de diseño para un flujo de atención al cliente, no una afirmación sobre una nueva implementación de Lumi.

Un registro de tarea pequeño y explícito

Para este flujo hipotético, empezaría con un registro de tarea parecido al siguiente. El esquema exacto importa menos que poder inspeccionar las decisiones sin leer el chat entero:

{
  "task_id": "support-482",
  "tenant_id": "tenant-a",
  "phase": "awaiting_review",
  "objective": "Resolver la consulta sobre el pedido retrasado",
  "subject": {
    "order_id": "order-731",
    "observed_version": 18
  },
  "evidence": [
    {
      "ref": "policy/refunds",
      "revision": "7",
      "retrieved_at": "2026-10-19T08:30:00Z",
      "supports": "eligibility"
    }
  ],
  "approval": {
    "ref": "approval-912",
    "status": "pending",
    "scope": "reembolso propuesto para order-731"
  },
  "memory": {
    "ref": "summary-6",
    "derived_from": "events-1..42"
  },
  "next_step": "Actualizar el pedido y la aprobación antes de proponer una acción"
}

El identificador de cliente (tenant), el objeto de la tarea y el alcance de la aprobación deben tratarse como campos validados por la aplicación. El modelo puede proponer cambios en el objetivo o el siguiente paso; después, hay que validarlos frente al flujo de trabajo. Un resumen compactado no debe ampliar el alcance de una aprobación.

La documentación actual de LangGraph distingue entre checkpoints vinculados a un hilo y almacenes compartidos entre hilos. También advierte de que los checkpointers en memoria pierden sus datos cuando se reinicia el proceso. Hay que elegir la persistencia de forma deliberada, recordando que guardar una observación no actualiza el dato de negocio subyacente.

Dedicar el contexto a la siguiente decisión

El prompt debe construirse a partir de la fase actual. Un paso de investigación necesita los datos del pedido y la política aplicable. Un paso de redacción necesita conclusiones verificadas y restricciones de comunicación. Un paso de escritura necesita precondiciones vigentes y la acción exacta permitida. Cargar todas las respuestas históricas de las herramientas en los tres pasos aporta muy poco.

Antes de convertirlo en tokens, hay que definir un presupuesto en las unidades de la propia aplicación: campos de estado obligatorios, un conjunto acotado de fragmentos de evidencia, preguntas sin resolver y diálogo reciente. Hay que reservar capacidad para las definiciones de herramientas, la salida y las necesidades de razonamiento permitidas al modelo, según los límites del modelo elegido. No hay un porcentaje universal que merezca la pena copiar.

Hay que medir la solicitud final con el mecanismo de recuento de tokens que admita el proveedor o, cuando sea necesario, con una estimación conservadora específica del modelo. Si se supera el presupuesto, primero se eliminan los datos duplicados o irrelevantes. Después se recuperan fragmentos más acotados. El diálogo antiguo solo debe compactarse tras proteger las restricciones aún sin resolver. Si la evidencia necesaria sigue sin caber, hay que dividir la decisión o detenerse.

La guía de ingeniería de contexto de Anthropic describe la recuperación justo a tiempo, las notas estructuradas y la compactación. Su recetario de marzo de 2026 establece una distinción útil: eliminar los datos de resultados antiguos de herramientas, resumir la transcripción y conservar memoria externa resuelven problemas distintos. Ninguna de estas técnicas debe tratarse como una comprobación automática de vigencia.

La retención selectiva y la compactación fallan de formas distintas

La retención selectiva conserva fragmentos precisos y sus referencias. Funciona bien con una cláusula de una política o una pregunta pendiente, pero una mala selección puede eliminar la excepción que cambia la decisión. Hay que conservar suficiente evidencia alrededor del fragmento para interpretarlo y mantener una vía de regreso a la fuente.

La compactación conserva un relato más amplio con menos tokens. Su punto débil es que el resumen puede omitir una negación, confundir una acción pendiente con una completada o conservar un dato después de que haya cambiado. Los resúmenes deben separar los resultados confirmados, las propuestas, las preguntas sin resolver y las referencias a las fuentes. Conviene mantener versiones de los resúmenes anteriores para poder investigar una transformación incorrecta.

Ambas técnicas pueden combinarse cuando proceda: un relato breve de la tarea más referencias explícitas a los registros que actúan como fuente de verdad y a la evidencia seleccionada. Tras un reinicio del contexto, hay que volver a cargar el registro de la tarea y revalidar los datos volátiles. Los permisos de la tarea no deben reconstruirse a partir del relato.

La exigencia de vigencia debe depender de las consecuencias de la decisión. Una descripción de empresa admite información recuperada hace más tiempo que el estado de un envío justo antes de un reembolso. Hay que utilizar las versiones de las fuentes cuando estén disponibles; una marca de tiempo, por sí sola, no demuestra que un registro siga igual. Las escrituras deben quedar vinculadas a la versión y al alcance comprobados por la aplicación, y el servicio debe rechazar las operaciones cuyas precondiciones hayan dejado de cumplirse.

Probar qué sobrevive al olvido

Conviene crear pares de trazas que lleguen a la misma decisión con el historial completo y tras aplicar retención o compactación. Hay que comprobar la acción resultante, la evidencia citada y las precondiciones incumplidas. Que la respuesta parezca razonable después de compactar es una prueba poco exigente.

• Cambiar el pedido después de recuperarlo. Al retomar la tarea, el agente debe actualizarlo o el sistema debe rechazar la acción basada en datos obsoletos.
• Situar una excepción crucial al principio de la traza. Verificar que la selección y la compactación la conservan o la recuperan de nuevo.
• Dejar una aprobación pendiente durante un reinicio del contexto. Confirmar que un resumen nunca la convierte en permiso para ejecutar.
• Recuperar revisiones contradictorias de una política y registros con nombres similares pertenecientes a otro cliente (tenant). Comprobar la selección de fuentes y el aislamiento entre clientes.
• Llenar el contexto con resultados duplicados de herramientas. Verificar que el sistema reduce la información de forma gradual o se detiene de forma controlada antes de perder restricciones necesarias.

Hay que registrar el tamaño del contexto, el número de recuperaciones, la latencia y el éxito de la tarea, junto con los intentos de acciones no válidas y los fallos por falta de evidencia. Conviene comparar las políticas con trazas representativas, incluidas compactaciones repetidas. Una factura de tokens más baja solo resulta útil si el flujo sigue alcanzando un resultado aceptable.

Mi recomendación es convertir el olvido en una operación habitual y probada. Mantener la verdad del negocio versionada, la evidencia vinculada a su fuente y la memoria reemplazable. Así, una ventana de contexto mayor se convierte en espacio de trabajo adicional, en lugar del sitio donde la aplicación espera que su estado siga existiendo.

Ideas clave

• Separar el estado de negocio que actúa como fuente de verdad, la evidencia recuperada y la memoria conversacional.
• Ensamblar el contexto para la siguiente decisión y reservar espacio para las restricciones necesarias.
• Usar retención selectiva y compactación con referencias explícitas a las fuentes y preguntas sin resolver.
• Revalidar los datos volátiles y hacer cumplir las precondiciones de escritura fuera del modelo.
• Probar las decisiones ante reinicios del contexto, evidencia contradictoria y compactaciones repetidas.

Fuentes

• Effective context engineering for AI agents — 2025-09-29
• Context engineering: memory, compaction, and tool clearing — 2026-03-20
• LangGraph Persistence — documentación consultada el 19 de octubre de 2026
• Lumi: Accelerating Pre-Sales with GenAI, Data Integration, and State Management — 2024-12-11