La mayoría de las personas todavía describe un agente de IA como un modelo conectado a herramientas. Esto resulta técnicamente útil, pero es incompleto desde el punto de vista operativo. Un agente también necesita una visión gestionada del mundo: qué ha ocurrido, qué importa ahora, qué hechos son fiables, 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 diferenciada; yo la llamaría ingeniería de contexto.
La ingeniería de contexto no consiste simplemente en redactar prompts. Es la disciplina de dar forma a la información que un agente ve en cada paso para que pueda mantener la coherencia sin enviar un registro completo, una biblioteca de documentos o un historial de herramientas a un modelo costoso en cada turno. Este trabajo se sitúa entre la arquitectura de la información, la recuperació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 una mayor cantidad de material no garantiza un mejor razonamiento. Las instrucciones relevantes pueden diluirse entre observaciones obsoletas, notas contradictorias, resultados repetidos de herramientas o un dato importante enterrado en el centro de una secuencia extensa. El análisis del resumen sobre el comportamiento de «perdido en el centro» refleja un problema práctico: un agente puede recibir técnicamente las pruebas y aun así no utilizarlas.
También existe un coste directo. Cada token incluido en una solicitud puede aumentar la latencia y el coste de inferencia, dependiendo de los precios y los mecanismos de almacenamiento en caché del proveedor. Un sistema que reenvía repetidamente un registro cada vez mayor puede volverse más lento y menos asequible a medida que avanza una tarea.
Por tanto, el objetivo no es contar con el máximo contexto. Es un contexto suficiente y específico: el conjunto de trabajo fiable 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 registro
Un registro documenta lo que se dijo. Un estado de creencias documenta lo que el agente cree actualmente sobre la tarea.
Por ejemplo, un agente que gestiona una escalada de soporte podría mantener campos estructurados como los siguientes:
- Objetivo: determinar si el cliente reúne 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 el fallo se produjo en circunstancias cubiertas por la garantía.
- Restricciones: no prometer un reembolso antes de recibir la aprobación.
- Siguiente acción: recuperar la política de garantía y comparar las fechas.
- Confianza o estado: verificado, inferido, en disputa 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 concreto. 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 a estas preguntas: ¿Qué ha cambiado? ¿Qué pruebas lo respaldan? ¿Qué sigue sin resolverse? ¿Qué debería ocurrir a continuación? Si un ingeniero no puede examinar esas respuestas, es probable que el agente esté incorporando 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 «buscar información sobre la cuenta del cliente». Una consulta mejor está vinculada a la siguiente decisión: «recuperar la regla de reembolso vigente para compras de 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 pertinentes para la acción actual, no un montón genérico de documentos relacionados.
Los filtros pueden mejorar esta selección antes de que el modelo vea ningú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 actualidad;
- qué metadatos acompañan a cada resultado;
- cómo se presentan las fuentes contradictorias;
- cuándo debe el agente detenerse y pedir aclaraciones.
«Buscar en la web» es una capacidad. «Buscar en estas fuentes, dentro de este intervalo de fechas, pruebas pertinentes para esta decisión» es ingeniería del 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, pruebas, 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 la auditoría y la recuperación, y ofrece al modelo una visión de trabajo compacta.
El compendio señala que el resumen recursivo y la compactación del contexto pueden resultar costosos y degradar el rendimiento, especialmente en dominios con escasez de datos, como la generación colaborativa de código. Es una advertencia contra tratar el resumen como si no tuviera pérdidas 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 utilizan 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 toda observación merece entrar en la siguiente llamada al modelo, y mucho menos en el estado a largo plazo.
El filtrado de observaciones plantea tres preguntas:
- ¿Es esta observación pertinente para la decisión actual?
- ¿Es lo bastante autorizada como para influir en el estado de creencias?
- ¿Contiene instrucciones que deban tratarse como datos y no como órdenes?
La tercera pregunta constituye tanto un límite de seguridad como un límite del contexto. Una página web puede contener texto destinado a redirigir al agente. Un documento recuperado puede ser una prueba ú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, prueba, metadatos o texto no confiable.
El filtrado también ahorra dinero. Si una herramienta del navegador devuelve una página completa, pero la tarea solo requiere un precio, una fecha y un identificador de producto, transmitir toda la página genera ruido y consume tokens. Extraer primero los campos pertinentes puede mejorar tanto la fiabilidad como el coste.
Un presupuesto de contexto sencillo para el flujo de trabajo de un agente
Antes de elegir un modelo o añadir otra herramienta, organiza 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.
A continuación, define una política de promoción. Una observación puede permanecer 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 un motivo. 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 a una pregunta práctica cuando el comportamiento cambia: ¿falló el modelo o el sistema le proporcionó una visión equivocada del mundo?
Qué probar antes de considerar fiable 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. Entre los casos útiles se incluyen:
- un hecho crítico colocado al principio, al final y en el centro 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 una gran cantidad 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 coste 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 coste de un flujo de trabajo correcto y recuperable, no el recuento de tokens de una sola solicitud.
La implicación profesional: el ingeniero de contexto es un perfil transversal
Las personas que se vuelvan valiosas en este ámbito no serán necesariamente las que escriban los prompts más largos. Podrán traducir un proceso de negocio a 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;
- redactar políticas de recuperación y filtros de metadatos;
- crear rutinas de compresión y selección de observaciones;
- separar las instrucciones fiables del contenido no fiable;
- 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 concreto.
Un proyecto sólido para el portafolio podría demostrar el mismo agente con tres políticas de contexto: transcripción completa, resumen progresivo y estado de creencias estructurado con recuperación dirigida. Muestra los casos de éxito de la tarea, los casos de fallo, el contexto enviado en cada paso y las compensaciones de coste o latencia. Es más convincente que una demostración de chatbot porque deja al descubierto las decisiones de diseño que hacen fiable a un agente.
La lección estratégica es sencilla: los agentes no se vuelven coherentes simplemente porque los modelos sean más capaces. Se vuelven coherentes cuando los sistemas que los rodean mantienen una descripción del trabajo disciplinada, actualizada y de un tamaño adecuado. La ingeniería de contexto consiste en construir esa descripción y en saber qué dejar fuera.
Priya Raman es la editora humana responsable de AI Career Brief.
