Ingeniería del contexto para agentes de AI: memoria y herramientas

Viacheslav Dubrov

2025-10-05 · Actualizado 2026-08-16 · 17 min · Agentes de IA

Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

La ingeniería del contexto es el pipeline que selecciona lo que ve un modelo antes de cada decisión: instrucciones, ejemplos, conocimiento, memoria, definiciones de herramientas, observaciones y guardrails. Un agente no actúa sobre todo lo que conoce el sistema. Actúa sobre el working set ensamblado para la siguiente llamada al modelo.

Ahí es donde empiezan muchos fallos. Una preferencia obsoleta parece actual. El texto recuperado contiene una instrucción. Un tool result largo oculta la precondición que ha fallado. Un resumen recuerda la decisión, pero pierde qué archivo cambió.

Para los ingenieros que construyen u operan agentes de AI, sistemas de recuperación y aplicaciones que usan herramientas, el trabajo práctico consiste en ensamblar el working set mínimo suficiente para cada decisión del agente, preservando al mismo tiempo el ámbito, la procedencia y los permisos. Este artículo explica cómo diseñar un pipeline de contexto por decisión, localizar sus trust boundaries, comprobar si su working set permite realizar la tarea y hacer que los fallos sean inspeccionables, en lugar de culpar a un modelo que solo ve la entrada ensamblada.

TL;DR. Trata el contexto como un artefacto de runtime tipado y con procedencia. Selecciónalo en cada paso, aplica el ámbito del tenant y los permisos antes de la recuperación, y separa las instrucciones de confianza de los datos no confiables. Presupuesta según la utilidad, valida las acciones fuera del modelo y evalúa los resultados de la tarea, no solo la longitud del contexto.

El contexto es una entrada de decisión, no memoria

La ventana de contexto es la entrada actual del modelo más los tokens generados. Puede contener turnos de conversación, pero no es un sistema de memoria persistente. La memoria a largo plazo, los índices de documentos, las bases de datos y los almacenes de artefactos viven fuera de la ventana. Un pipeline de contexto decide qué copiar dentro.

El tamaño de la ventana es un límite de capacidad, no una garantía de calidad. Lost in the Middle y RULER muestran que la recuperación y el razonamiento pueden variar según la posición, la tarea, el modelo y la longitud de la secuencia. La lección operativa no es que los tokens del centro se ignoren siempre. Es que añadir tokens que parecen relevantes puede reducir aun así el rendimiento en la tarea.

El diagrama muestra el resultado cualitativo del estudio, no una curva universal de atención. Liu et al. probaron question answering sobre múltiples documentos y recuperación de pares clave-valor. A menudo observaron un mejor rendimiento cuando el elemento relevante aparecía cerca del principio o del final. El tamaño y la forma del efecto cambiaban según el modelo, la tarea y la longitud del contexto. Trata la posición como una variable de tu propio conjunto de evaluación, en lugar de asumir una penalización fija para el centro.

Lo siguiente es un esquema de Pydantic ilustrativo, no una implementación probada de un repositorio. Solo valida los tipos de campo y los valores literales. No autoriza el tenant, no mantiene total_input_tokens coherente con items, no persiste el manifest ni impone el comportamiento del modelo.

from datetime import datetime
from typing import Literal

from pydantic import BaseModel

class ContextItem(BaseModel):
    item_id: str
    kind: Literal["instruction", "task_state", "evidence", "memory", "tool"]
    source: str
    trust: Literal["trusted", "untrusted"]
    retrieved_at: datetime | None = None
    version: str | None = None
    token_count: int

class ContextManifest(BaseModel):
    request_id: str
    tenant_id: str
    items: list[ContextItem]
    total_input_tokens: int

El manifest hace reproducible un fallo. «El modelo ha alucinado» se convierte en una pregunta comprobable: ¿qué evidencias, versión, ámbito de permisos y tool schema recibió realmente?

El ciclo de ensamblaje

Un pipeline fiable realiza estas operaciones en orden:

1. Resolver el contexto de la petición de confianza. Autentica fuera del modelo al actor, el tenant, la configuración regional, la hora y el estado actual de la tarea.
2. Elegir la siguiente decisión. Un paso de planificación, una consulta de evidencias, la selección de una herramienta y una respuesta final necesitan contextos diferentes.
3. Recuperar dentro del ámbito. Aplica los filtros de autorización y tenant antes del ranking semántico, no después de que los documentos entren en el conjunto de candidatos.
4. Ordenar y presupuestar. Selecciona elementos según utilidad, actualidad, autoridad y diversidad, dentro de un presupuesto de entrada.
5. Ensamblar con trust boundaries. Mantén la política en los canales de instrucciones y presenta el contenido recuperado como datos entrecomillados. Las instrucciones recuperadas no se convierten en política del sistema.
6. Generar una propuesta tipada. El constrained decoding puede imponer la sintaxis y la estructura admitidas. No puede hacer que los valores sean correctos.
7. Validar y ejecutar. El código de la aplicación comprueba la autorización, las reglas de negocio, los argumentos de las herramientas y las postcondiciones.
8. Registrar la procedencia y el resultado. Guarda el manifest, los IDs de las fuentes seleccionadas, las referencias a los tool results, el resultado de la validación y el resultado de la tarea.

El ciclo se aplica a cada decisión. Reutilizar un contexto grande para toda la ejecución de un agente crea evidencias obsoletas y da a cada paso acceso a material que no necesita.

Asigna una única función a cada fuente de contexto

Las instrucciones definen el comportamiento duradero

Las instrucciones especifican el rol, la política, el contrato de salida y el comportamiento de escalado. Mantén estable el contenido estable para mejorar el prefix caching, pero no fijes valores que cambian en runtime. Un umbral de reembolso pertenece a un servicio de políticas o a un registro de datos versionado, no a un prompt copiado indefinidamente.

La jerarquía de instrucciones es un límite de control, no un sandbox de seguridad. El modelo puede seguir texto malicioso en un documento recuperado. Delimita el contenido no confiable, indica que es evidencia y no una instrucción, restringe las herramientas de forma independiente y prueba casos de prompt injection.

No copies los nombres de roles de un proveedor a una jerarquía universal. La OpenAI Model Spec define niveles de autoridad para las instrucciones de plataforma o sistema, desarrollador y usuario. La Anthropic Messages API utiliza un parámetro de nivel superior system y mensajes user y assistant. Esa API no expone un rol developer equivalente. Otros runtimes toman decisiones diferentes. Mapea tu política a los canales documentados por el proveedor y aplica después los permisos y los efectos secundarios en el código de la aplicación.

El estado de la tarea registra compromisos

La prosa de la conversación es una fuente de verdad deficiente para el trabajo en varios pasos. Mantén un estado explícito para el objetivo, la fase actual, las acciones completadas, las aprobaciones pendientes, las referencias a artefactos y el estado de las pruebas. El modelo puede resumir ese estado para la narración. El código de la aplicación es el propietario de la versión canónica.

Los ejemplos muestran decisiones límite

Los ejemplos few-shot son útiles cuando aclaran un límite difícil, no cuando se limitan a repetir el esquema. Selecciona ejemplos que coincidan con la decisión actual e incluyan casos límite con consecuencias. Evalúa la recuperación de ejemplos igual que la recuperación de documentos: un ejemplo superficialmente similar pero incompatible con la política puede ser peor que no tener ninguno.

El conocimiento aporta evidencias

La recuperación es adecuada para datos recientes, privados o citables. No existe un top_k, tamaño de chunk, peso híbrido o cutoff de reranker universalmente óptimo. Ajusta el pipeline completo con preguntas cuyas evidencias de respaldo conozcas.

Un elemento de evidencia útil incluye:

• fuente e identificador estable del documento
• versión o fecha de entrada en vigor
• ámbito de permisos
• fragmento citado y ubicación
• puntuaciones de recuperación y reranking para depuración

No pidas al modelo que cite una URL que nunca ha recibido. No registres documentos privados completos solo para depurar la selección.

La memoria aporta continuidad con ámbito

La memoria son datos recuperados con riesgos adicionales de ciclo de vida. Como metadatos de diseño, registra el sujeto, la procedencia, el propósito, el consentimiento aplicable o la decisión sobre la base jurídica, la fecha de creación, la política de caducidad o revisión y la vía de eliminación. La legislación de privacidad aplicable y el asesoramiento jurídico del producto determinan la base jurídica de un producto y sus datos, no esta lista de comprobación.

Reglas fijas como «las preferencias viven 365 días» no son una política portable. La retención depende de la necesidad del producto, las expectativas del usuario y la legislación. Antes de cargar una memoria, comprueba:

1. ¿Corresponde a este sujeto autenticado y a este tenant?
2. ¿Es relevante su propósito para esta decisión?
3. ¿Está suficientemente actualizada para utilizarla?
4. ¿Su fuente es autoritativa o simplemente inferida por el modelo?

Trata las memorias inferidas como hipótesis. No conviertas silenciosamente una respuesta del modelo en un hecho permanente sobre el usuario.

Los contratos de las herramientas exponen capacidades

Las descripciones de las herramientas deben explicar las precondiciones, los efectos, el ámbito de autorización, el esquema de entrada, el esquema de salida, la idempotencia y los fallos relevantes. Una llamada que cumple el esquema puede seguir sin estar autorizada o ser insegura.

Después de la ejecución, sustituye la salida raw y verbosa por una observación tipada que conserve el resultado relevante para la decisión y una referencia al artefacto completo:

{
    "tool": "check_api_key_status",
    "status": "revoked",
    "checked_at": "2026-07-15T09:30:00Z",
    "account_id": "A-123",
    "artifact_ref": "toolrun://req-42/step-3"
}

La especificación de MCP estandariza cómo interactúan los clientes con herramientas, recursos y prompts. No autoriza su uso ni hace confiable el contenido devuelto. Mantén fuera del modelo y de la descripción del protocolo las comprobaciones del gateway, las credenciales y la política.

Carga detalle cuando una decisión lo necesite

La divulgación progresiva es un patrón de ensamblaje de contexto: mantén disponibles los identificadores y el estado de confianza de la tarea, y recupera después el detalle para la decisión actual. No promete que un presupuesto concreto de tokens vaya a funcionar con todos los modelos.

El router debe aplicar el ámbito de autorización y tenant antes de la recuperación. Debe devolver fragmentos de evidencia, registros de memoria y tool schemas que sirvan para la decisión actual. El modelo propone entonces una acción. El código de la aplicación valida esa propuesta antes de ejecutarla. La guía de Anthropic sobre el contexto de herramientas utiliza el mismo principio selectivo para grandes conjuntos de herramientas. Tool search mantiene las definiciones fuera de la ventana de contexto hasta que el modelo las solicita. Mide si ese paso adicional de routing mejora el éxito de las tareas, la latencia y los tokens por tarea completada correctamente en tu sistema.

Cómo se degrada el contexto

El contexto deficiente no falla de una sola manera. El siguiente modelo de degradación de cinco patrones es una síntesis propia para depuración, basada en las evaluaciones de contexto largo anteriores y en la investigación sobre prompt injection:

• Pérdida por posición: la evidencia necesaria está presente, pero el modelo la utiliza de forma inconsistente debido a su posición y a la secuencia que la rodea. Las evaluaciones de contexto largo muestran que el efecto varía según el modelo y la tarea. No existe un intervalo universal del «centro problemático».
• Envenenamiento: una memoria incorrecta, un documento obsoleto, una instrucción maliciosa o una observación defectuosa de una herramienta entra en el working set e influye en decisiones posteriores.
• Distracción: la evidencia relevante compite con material reciente o semánticamente similar, pero innecesario para el paso actual.
• Confusión: instrucciones, ejemplos o descripciones de herramientas solapadas dejan al modelo con varias interpretaciones plausibles de la tarea.
• Choque: dos elementos con apariencia de autoridad discrepan sobre un valor, una política o la siguiente acción, y el ensamblador no expone sus versiones ni su precedencia.

Estos fallos requieren soluciones diferentes. Un ranking mejor puede ayudar con la distracción, pero no puede reparar una fuente obsoleta. Los delimitadores pueden ayudar a separar datos e instrucciones, pero no pueden autorizar una herramienta. Una ventana de contexto mayor puede conservar más material conflictivo sin resolver el conflicto.

Cuando falle una ejecución, inspecciona el manifest y pregunta qué patrón se produjo antes de cambiar el prompt o añadir otra fase de recuperación.

Presupuesta según la utilidad, no con cuotas por componente

Un presupuesto de contexto reserva espacio para la salida y después asigna la entrada a la decisión actual. Parte de la ventana admitida por el modelo, resta la salida máxima y la sobrecarga del protocolo, y empaqueta los candidatos en el espacio restante.

Puntúa los candidatos con características que tus evaluaciones puedan cuestionar:

utility = relevance × authority × freshness × scope_match
          − redundancy_penalty − injection_risk

Trata la fórmula como una propuesta de diseño. En una respuesta sobre políticas, la autoridad puede pesar más que la similitud semántica. En depuración, un log reciente de un fallo puede superar a la documentación general.

El orden también importa. Mantén primero las instrucciones de confianza estables cuando la semántica de caché del proveedor se beneficie de un prefijo compartido. Coloca la tarea y la decisión actuales cerca de las evidencias a las que hacen referencia. Evita incluir timestamps o IDs de petición en los prefijos estables cuando no sean necesarios ahí.

Comprime sin perder el estado

La compresión tiene pérdida salvo que el original siga siendo direccionable. La evaluación de Factory Research sobre tres enfoques de compresión en sesiones prolongadas de agentes plantea el objetivo en términos de tokens por tarea, no tokens por petición. Lo adapto como recomendación de ingeniería: optimiza los tokens por tarea completada correctamente, no los tokens por petición, bajo condiciones de tarea comparables; no lo trates como una ley universal. Evaluación de Factory Research

Utiliza mecanismos separados para materiales distintos:

• Conversación: resume decisiones, preguntas sin resolver y compromisos.
• Observaciones de herramientas: conserva hallazgos tipados y referencias a artefactos. Elimina boilerplate y payloads repetidos.
• Evidencias recuperadas: conserva los IDs de las fuentes, los fragmentos de respaldo y las fechas de entrada en vigor para que el sistema pueda volver a recuperarlas.
• Estado de la tarea: almacénalo de forma canónica fuera del resumen.
• Trazabilidad de archivos o artefactos: mantén un índice explícito de lecturas, escrituras, hashes y resultados de pruebas.

Activa la compactación a partir de una degradación medida o de un umbral de presupuesto elegido para el modelo y la tarea. No publiques una regla genérica de «comprimir al 70 %» como si todos los modelos fallaran en el mismo punto.

Evalúa la compresión con probes que requieran continuar, no con solapamiento léxico:

• ¿Cuál es el objetivo actual y la siguiente acción?
• ¿Qué archivos o registros han cambiado?
• ¿Qué decisión se rechazó y por qué?
• ¿Qué fuente respalda la afirmación actual?
• ¿Qué aprobación sigue pendiente?

Ejecuta la misma tarea con y sin compresión. Compara el éxito, las acciones incorrectas, las nuevas recuperaciones, la latencia y el total de tokens.

Optimiza el pipeline de contexto

La optimización debe preservar el contrato de decisión. Cuatro técnicas resultan útiles una vez que has medido un cuello de botella:

Estas técnicas resuelven problemas diferentes. La compactación y la edición del contexto pueden reducir el contenido enviado al modelo. La carga selectiva de herramientas evita enviar schemas que no se utilizan. El prompt caching puede reducir el coste de los prefijos repetidos, pero no reduce el número de tokens de la ventana de contexto. La partición cambia las capacidades y evidencias que recibe cada decisión. La guía de Anthropic sobre el contexto de herramientas hace explícitas estas diferencias, y su documentación sobre edición del contexto expone triggers configurables, no un umbral universal.

Compacta el historial completado

Sustituye los turnos antiguos de la conversación por un handoff estructurado que registre las decisiones, las preguntas sin resolver, los artefactos modificados y el estado de las pruebas. Mantén el transcript original o los artefactos direccionables cuando la revisión o la recuperación lo requieran.

Enmascara las observaciones verbosas

Una herramienta puede devolver páginas de logs cuando el siguiente paso solo necesita un estado, un código de error y una referencia a un artefacto. Convierte el resultado raw en una observación tipada después de validarlo y conserva el payload completo fuera del prompt. No permitas que el modelo resuma y elimine la única evidencia del fallo.

Conserva prefijos cacheables

Los proveedores y runtimes pueden reutilizar trabajo cuando el principio de una petición permanece estable. Mantén las instrucciones duraderas y los tool schemas en un orden coherente, y desplaza los timestamps, IDs de petición, evidencias recuperadas y estado actual al sufijo dinámico. Confirma la semántica de caché del proveedor antes de diseñar basándote en ella.

Divide por decisión

Un planificador, un recuperador, un agente que llama a herramientas y un paso de respuesta final no necesitan el mismo material. Da a cada paso las instrucciones de confianza, el estado, las evidencias y las herramientas mínimas que necesita. La partición reduce simultáneamente el uso de tokens y la exposición de capacidades, pero solo las evaluaciones a nivel de tarea pueden demostrar si ha eliminado información necesaria.

Protege la supply chain del contexto

La investigación sobre prompt injection trata el contenido externo no confiable como una superficie de ataque (artículo). En el modelo operativo de este artículo, el envenenamiento del contexto puede llegar a través de documentos, memorias, tool results, skills o mensajes anteriores del asistente. Marcar el texto como «no confiable» ayuda al modelo, pero el enforcement debe ser arquitectónico.

La siguiente checklist de supply chain es una recomendación de ingeniería propia. Convierte los límites del protocolo y del threat model en controles de la aplicación. Ni la especificación de MCP ni el artículo sobre prompt injection aplican esta checklist completa.

Utiliza estos límites:

1. Autoriza antes de recuperar y ejecutar herramientas.
2. Separa los datos de los canales de instrucciones y delimita el texto externo.
3. Permite herramientas mediante una allowlist por paso y por actor. Por defecto, no concedas capacidades con efectos secundarios.
4. Valida los identificadores de recursos en lugar de permitir que el modelo invente claves de tenant o rutas de archivos.
5. Exige confirmación para operaciones de alto impacto según la política, no según la confianza del modelo.
6. Analiza y revisa las skills o connectors ejecutables antes de instalarlos.
7. Impide que los secretos y el contexto sensible raw entren en los logs y en la memoria a largo plazo.

La «reparación» automática solo es apropiada para cambios que preservan el significado, como analizar un formato de fecha conocido. Rellenar argumentos de herramientas que faltan con «valores por defecto razonables» puede cambiar la operación. Pide aclaraciones o rechaza cuando el significado no esté claro.

Ejemplo práctico: una petición de soporte sobre una API key

Para «¿Por qué no funciona mi API key?», la siguiente decisión es recopilar evidencias de diagnóstico, no generar la respuesta final. El ensamblador podría incluir:

• la política de soporte de confianza y el contrato de respuesta
• el ID de cuenta autenticado y el plan, procedentes del estado de la aplicación
• el objetivo actual del ticket y las acciones ya intentadas
• dos fragmentos actuales del runbook, seleccionados dentro del ámbito de producto y versión
• una memoria con ámbito que indique que la key se creó hace tres días, con su procedencia
• check_api_key_status y search_incidents, pero no herramientas para eliminar o rotar la key

El modelo propone una comprobación de estado de solo lectura. El código de la aplicación autoriza la cuenta, llama a la herramienta y registra una observación tipada. Una segunda llamada al modelo recibe los fragmentos relevantes del runbook junto con esa observación. La respuesta final cita la versión del runbook, nunca muestra la key y ofrece la rotación únicamente como una acción autorizada por separado.

Observa qué queda fuera: el historial no relacionado del ticket, todos los ejemplos de soporte, dumps raw de la cuenta, herramientas de mutación y memorias de otros tenants.

Antipatrones que deben probarse explícitamente

• Llenar la ventana: cargar todos los documentos, el historial, las memorias y las herramientas recuperados porque aún queda capacidad.
• RAG para todo: utilizar recuperación semántica para valores que pertenecen a una base de datos, un servicio de políticas o el estado autenticado de la aplicación.
• Memoria sin límites: conservar hechos inferidos sin ámbito, caducidad, semántica de corrección o eliminación.
• Una llamada para cada fase: pedir a un único prompt que recupere, razone, autorice, mute y explique sin límites observables.
• El esquema equivale a corrección: tratar un JSON válido como prueba de que los valores, los permisos o las decisiones de negocio son válidos.
• Sin evaluaciones por componente: puntuar solo la prosa final e ignorar los fallos de recuperación, selección de contexto o herramientas.

Convierte cada antipatrón en un contraejemplo del conjunto de evaluación. Una directriz que nunca se ejercita mediante una tarea o un trace es fácil de incumplir sin darse cuenta.

Evalúa el ensamblador, no solo la respuesta

Crea un conjunto fijo de tareas con etiquetas de evidencia, límites de permisos, llamadas de herramientas requeridas y acciones prohibidas. Para cada cambio de la política de contexto, mide:

Utiliza ablations para encontrar el valor causal: elimina la memoria, el reranking, los ejemplos o la compresión, uno cada vez. Un componente que añade tokens sin mejorar el slice relevante no debería cargarse por defecto.

Conclusión

Una buena ingeniería del contexto es selectiva y responsable. No llena una ventana grande solo porque haya capacidad disponible. Construye un working set específico para cada paso a partir de instrucciones de confianza, estado canónico de la tarea, evidencias con ámbito, memoria revisada y herramientas permitidas.

El ciclo es corto: ensamblar, generar el manifest, proponer, validar, ejecutar y evaluar. Cuando falla una decisión, ese ciclo indica si faltaban evidencias, actualidad, autoridad, estado o política. También proporciona una prueba para el siguiente cambio.

Referencias

• Lost in the Middle — uso del contexto largo dependiente de la posición
• RULER — evaluación multitarea de la longitud efectiva del contexto
• OpenAI Model Spec — niveles de autoridad de las instrucciones específicos del proveedor
• Anthropic Messages API — estructura del parámetro system y de los roles de los mensajes
• Manage tool context — carga selectiva de herramientas, caching y edición del contexto
• Anthropic context editing — borrado configurable de tool results y compactación
• Model Context Protocol specification — conceptos del protocolo y especificación actual
• Evaluating Context Compression for AI Agents — planteamiento de tokens por tarea y evaluación basada en probes
• Formalizing and Benchmarking Prompt Injection Attacks and Defenses — taxonomía de amenazas y defensas