La mayoría de las personas todavía describe un agente de IA como un modelo conectado a herramientas. Eso es técnicamente útil, pero operacionalmente incompleto. Un agente también necesita una visión gestionada del mundo: qué ha sucedido, qué importa ahora, qué hechos son confiables, qué sigue siendo incierto y qué debería hacer a continuación.
Esa visión es su contexto. Diseñarla se está convirtiendo en una habilidad distinta: una que yo llamaría ingeniería de contexto.
La ingeniería de contexto no consiste simplemente en redactar prompts. Es la disciplina de estructurar la información que un agente ve en cada paso para que pueda mantener la coherencia sin enviar un transcript completo, una biblioteca de documentos o el historial de herramientas de vuelta a un modelo costoso en cada turno. El trabajo se sitúa entre la arquitectura de la información, la recuperación de información, el diseño de software y el comportamiento del modelo.
Por qué «darle más contexto al agente» suele ser un mal consejo
Las ventanas de contexto más largas hacen tentador conservarlo todo. Pero más material no garantiza un mejor razonamiento. Las instrucciones relevantes pueden diluirse entre observaciones obsoletas, notas contradictorias, resultados repetidos de herramientas o un hecho importante enterrado en medio de una secuencia extensa. El análisis de “lost in the middle” del resumen refleja un problema práctico: un agente puede recibir técnicamente la evidencia y aun así no utilizarla.
También existe un costo directo. Cada token incluido en una solicitud puede aumentar la latencia y el costo de inferencia, según los precios y los mecanismos de almacenamiento en caché del proveedor. Un sistema que reenvía repetidamente un transcript cada vez más extenso puede volverse más lento y menos asequible a medida que continúa una tarea.
Por lo tanto, el objetivo no es el contexto máximo. Es un contexto suficiente y dirigido: el conjunto de trabajo confiable más pequeño para la decisión en cuestión.
Cuatro decisiones de diseño detrás de un agente coherente
1. Mantener un estado de creencias, no solo un transcript
Un transcript registra lo que se dijo. Un estado de creencias registra lo que el agente cree actualmente sobre la tarea.
Por ejemplo, un agente que gestiona una escalación de soporte podría mantener campos estructurados como:
- Objetivo: identificar si el cliente cumple los requisitos para un reemplazo.
- Hechos conocidos: fecha de compra y número de serie del producto, con referencias a las fuentes.
- Preguntas abiertas: si la falla ocurrió en condiciones cubiertas por la garantía.
- Restricciones: no prometer un reembolso antes de obtener la aprobación.
- Siguiente acción: recuperar la política de garantía y comparar las fechas.
- Confianza o estado: verificado, inferido, controvertido o desconocido.
Este enfoque se parece a la investigación ABBEL de Berkeley, que utiliza estados de creencias en lenguaje natural supervisados en lugar de depender de historiales completos de interacción. La idea importante no es un formato particular. Es separar el estado duradero de la tarea de los detalles desechables de la conversación.
Una actualización útil del estado de creencias debería responder: ¿Qué cambió? ¿Qué evidencia lo respalda? ¿Qué sigue sin resolverse? ¿Qué debería suceder a continuación? Si un ingeniero no puede inspeccionar esas respuestas, es probable que el agente esté cargando supuestos ocultos en un prompt opaco.
2. Recuperar información para la decisión, no para el tema
Los sistemas de recuperación suelen comenzar con una pregunta amplia como «encuentra información sobre la cuenta del cliente». Una consulta mejor está vinculada a la siguiente decisión: «recupera la regla de reembolso vigente para compras de hace más de 30 días, aplicable en la región del cliente».
Ese cambio importa porque la recuperación es una forma de selección de contexto. El agente debería recibir los fragmentos de políticas, registros o ejemplos relevantes para la acción actual, no un conjunto genérico de documentos relacionados.
Los filtros pueden mejorar esta selección antes de que el modelo vea algún resultado. Por ejemplo, Amazon Bedrock AgentCore Web Search admite filtros de dominio y fecha de publicación aplicados por el servidor en cada solicitud. Estos controles no demuestran que una fuente sea correcta, pero pueden reducir la exposición a material irrelevante u obsoleto y hacer explícita la política de recuperación.
Los profesionales que diseñan sistemas de recuperación deberían especificar:
- qué fuentes están permitidas para cada tarea;
- cómo se determina la frescura;
- qué metadatos acompañan cada resultado;
- cómo se presentan las fuentes en conflicto;
- cuándo el agente debe detenerse y pedir aclaraciones.
“Buscar en la web” es una capacidad. “Buscar en estas fuentes, dentro de este rango de fechas, evidencia relevante para esta decisión” es ingeniería de contexto.
3. Comprimir sin borrar la incertidumbre
La compresión es necesaria cuando una tarea es larga, pero un resumen ingenuo puede convertir afirmaciones tentativas en hechos establecidos. Un resumen acumulativo que diga “el usuario confirmó la dirección” es peligroso si el intercambio original solo lo daba a entender.
Una buena compresión conserva las distinciones que un agente necesita para razonar de forma segura:
- hecho frente a inferencia;
- instrucción actual frente a instrucción histórica;
- acción completada frente a acción propuesta;
- fuente verificada frente a afirmación no verificada;
- respuesta conocida frente a pregunta sin resolver.
Un patrón práctico consiste en mantener secciones separadas para decisiones, evidencia, supuestos, obstáculos y acciones pendientes. Otra opción es adjuntar identificadores de fuente o marcas de tiempo a las afirmaciones importantes. Los resúmenes deben ser artefactos reemplazables, no el único registro que sobreviva: conserva los eventos subyacentes para auditoría y recuperación, y ofrece al modelo una vista de trabajo compacta.
El compendio señala que el resumen recursivo y la compactación del contexto pueden ser costosos y degradar el rendimiento, particularmente en dominios con pocos datos, como la generación colaborativa de código. Esto es una advertencia contra tratar el resumen como si no perdiera información automáticamente. La compresión necesita pruebas con tareas representativas, incluidos casos en los que una pequeña salvedad cambia la respuesta correcta.
4. Filtrar las observaciones antes de que se conviertan en memoria
Los agentes que usan herramientas generan observaciones constantemente: resultados de búsqueda, registros, texto de páginas, respuestas de API, capturas de pantalla, salida del compilador y planes intermedios. No todas las observaciones merecen entrar en la siguiente llamada al modelo, y mucho menos en el estado a largo plazo.
El filtrado de observaciones plantea tres preguntas:
- ¿Es relevante esta observación para la decisión actual?
- ¿Es lo bastante autorizada como para influir en el estado de creencias?
- ¿Contiene instrucciones que deberían tratarse como datos y no como comandos?
La tercera pregunta es tanto un límite de seguridad como un límite de contexto. Una página web puede contener texto destinado a redirigir al agente. Un documento recuperado puede ser evidencia útil sin tener autoridad para cambiar los objetivos o permisos del agente. Por lo tanto, el filtrado debe clasificar el contenido según su función: instrucción, evidencia, metadatos o texto no confiable.
El filtrado también ahorra dinero. Si una herramienta de navegador devuelve una página completa, pero la tarea solo requiere un precio, una fecha y un identificador de producto, pasar toda la página crea ruido y consume tokens. Extraer primero los campos relevantes puede mejorar tanto la confiabilidad como el costo.
Un presupuesto de contexto sencillo para un flujo de trabajo de agente
Antes de elegir un modelo o añadir otra herramienta, divide el contexto del agente en cuatro capas:
- Control: reglas del sistema, permisos, esquema de salida y restricciones innegociables.
- Estado: el objetivo actual, las decisiones, las preguntas abiertas y la siguiente acción.
- Evidencia: registros recuperados u observaciones relevantes para esa acción, con su procedencia.
- Historial: eventos anteriores conservados para recuperación, depuración o auditoría, pero omitidos salvo que sean necesarios.
Luego define una política de promoción. Una observación puede permanecer como efímera, convertirse en evidencia para el paso actual, actualizar el estado de creencias o escribirse en la memoria persistente. La promoción debe requerir una razón. De lo contrario, la memoria se convierte en un archivo sin curaduría.
Para cada paso del agente, registra el paquete de contexto enviado al modelo: sus categorías, el tamaño aproximado en tokens, los filtros de recuperación y la versión de compresión. Esto permite responder una pregunta práctica cuando cambia el comportamiento: ¿falló el modelo o el sistema le proporcionó una visión equivocada del mundo?
Qué probar antes de considerar confiable el diseño
La ingeniería de contexto necesita pruebas dirigidas al manejo de la información, no solo a la calidad de la respuesta final. Algunos casos útiles incluyen:
- un dato crítico colocado al principio, al final y en el medio de un historial largo;
- dos fuentes que discrepan, una de ellas más reciente que la otra;
- un resumen que contiene un marcador de incertidumbre;
- una respuesta de herramienta que contiene un gran volumen de texto irrelevante;
- una instrucción maliciosa incrustada en el contenido recuperado;
- la rehidratación del estado después de pausar y reiniciar el agente;
- la misma tarea con un presupuesto de contexto menor;
- un resultado de recuperación vacío u obsoleto.
Mide si el agente selecciona la evidencia correcta, conserva la incertidumbre, sigue la restricción actual y evita repetir contexto innecesario. Las áreas de regresión recomendadas por el resumen—pérdida de contexto, fundamentación de la recuperación, salida estructurada, no terminación y rehidratación del estado—son especialmente relevantes aquí.
Realiza múltiples pruebas cuando la variabilidad del modelo sea relevante y compara el costo y la latencia de cada estrategia de contexto. Un prompt más corto no es automáticamente mejor si provoca más llamadas a herramientas o reintentos. El objetivo útil es el costo de un flujo de trabajo correcto y recuperable, no el conteo de tokens de una sola solicitud.
La implicación profesional: el ingeniero de contexto es un rol interdisciplinario
Las personas que se vuelvan valiosas en esta área no necesariamente serán quienes escriban los prompts más largos. Podrán traducir un proceso empresarial en estado, evidencia, autoridad y reglas de decisión.
Eso requiere varias capacidades concretas:
- diseñar esquemas para el estado de las tareas y la procedencia;
- escribir políticas de recuperación y filtros de metadatos;
- crear rutinas de compresión y selección de observaciones;
- separar las instrucciones confiables del contenido no confiable;
- perfilar el uso de tokens, la latencia, los reintentos y las llamadas a herramientas;
- probar la pérdida y la rehidratación del estado;
- explicar a personas no especializadas por qué un agente vio —o no vio— un hecho específico.
Un proyecto sólido para un portafolio podría demostrar el mismo agente con tres políticas de contexto: transcripción completa, resumen acumulativo y estado de creencias estructurado con recuperación dirigida. Muestra los casos en que la tarea tiene éxito, los casos de falla, el contexto enviado en cada paso y las ventajas y desventajas en costo o latencia. Esto resulta más convincente que una demostración de chatbot porque expone las decisiones de diseño que hacen confiable a un agente.
La lección estratégica es sencilla: los agentes no se vuelven coherentes simplemente porque los modelos se vuelvan más capaces. Se vuelven coherentes cuando los sistemas que los rodean mantienen una descripción disciplinada, actual y de tamaño adecuado del trabajo. La ingeniería de contexto es el arte de construir esa descripción y de saber qué dejar fuera.
Priya Raman es la editora humana responsable de AI Career Brief.
