flowchart LR
A[Fuentes disponibles] --> B[Seleccionar]
B --> C[Transformar]
C --> D[Ordenar]
D --> E[Etiquetar]
E --> F[Contexto de esta inferencia]
F --> G[Modelo]
Context engineering
Del prompt aislado al ensamblaje dinámico del contexto: instrucciones, evidencia, herramientas, estado, memoria y ejemplos para cada paso de un agente.
Durante buena parte del recorrido aprendimos a mejorar las instrucciones.
Primero escribimos prompts más claros. Después incorporamos documentos, criterios, ejemplos y formatos. Más adelante añadimos RAG, herramientas, workflows y memoria.
En un agente aparece una dificultad nueva.
El sistema ya no realiza una única operación con un bloque estático de información. Trabaja en varios pasos. Después de cada paso cambia lo que sabe sobre el caso, cambian las herramientas que puede necesitar y puede cambiar incluso la tarea inmediata.
El problema deja de ser solamente:
“¿Cómo escribo un buen prompt?”
Y pasa a ser:
“¿Qué información debe recibir el modelo ahora para tomar correctamente este paso?”
Esa es la intuición detrás de context engineering.
Idea central
En esta página utilizaremos context engineering para describir el proceso de seleccionar, preparar y ensamblar dinámicamente la información que recibe el modelo en una inferencia concreta.
Ese contexto puede incluir:
instrucciones · evidencia · herramientas · estado · memoria · ejemplos.
El objetivo no es entregar “todo lo disponible”.
Es entregar lo necesario, suficientemente identificado y en una forma que permita usarlo correctamente.
Del prompt al contexto completo
Un prompt avanzado puede contener bastante información. Pero en una aplicación real existen elementos que no necesariamente escribió el usuario y que cambian de un paso a otro.
Por ejemplo:
INSTRUCCIONES DEL SISTEMA
+
SOLICITUD DEL USUARIO
+
DOCUMENTOS RECUPERADOS
+
ESTADO ACTUAL DEL EXPEDIENTE
+
HERRAMIENTAS DISPONIBLES
+
RESULTADOS DE HERRAMIENTAS ANTERIORES
+
MEMORIA RELEVANTE
+
EJEMPLOS PARA LA TAREA ACTUALTodo eso puede formar parte de la información utilizada para una llamada al modelo.
Google describe context engineering como la construcción dinámica de ese payload completo: no sólo instrucciones estáticas, sino también historial, datos externos, resultados de herramientas, memoria y estado.
La diferencia con prompt engineering no debe exagerarse como si una disciplina hubiera reemplazado completamente a la otra.
El prompt continúa siendo importante.
El delta conceptual es éste:
ya no diseñamos únicamente las palabras de una instrucción; diseñamos el mecanismo que construye el input correcto para cada paso.
Una analogía: preparar la mesa de trabajo
Podemos imaginar que cada inferencia ocurre sobre una mesa.
Antes de pedir a una persona que revise una cláusula podemos colocar delante de ella:
- la cláusula;
- el contrato completo;
- una política interna;
- una nota del cliente;
- una checklist;
- un correo anterior;
- diez documentos que no tienen relación con el problema.
Tener más papeles sobre la mesa no garantiza una mejor revisión.
La analogía ayuda porque muestra que el trabajo depende de qué materiales están disponibles y cómo están organizados.
Deja de servir si imaginamos que todo el contexto es necesariamente visible al usuario o que el modelo puede trabajar indefinidamente con una mesa de tamaño ilimitado. En realidad existe una ventana de contexto finita y costos asociados a procesar información.
El contexto es un presupuesto, no un depósito
Una mala estrategia consiste en tratar el contexto como un archivo donde conviene agregar todo “por si acaso”.
Eso crea varios problemas.
Ruido
Información irrelevante puede competir con aquella que sí importa.
Contradicciones
Podemos incluir versiones antiguas y nuevas de una política sin indicar cuál gobierna.
Costo y latencia
Más información implica más procesamiento.
Contexto obsoleto
Una conclusión intermedia puede quedar disponible incluso después de haber sido corregida.
Riesgo de confidencialidad
Agregar información innecesaria también amplía la cantidad de datos expuestos al sistema.
Por eso una regla útil es:
el mejor contexto no es el máximo; es el mínimo suficiente y pertinente para la tarea actual.
Seis componentes del contexto
El índice del curso separa seis elementos porque cada uno cumple una función diferente.
Instrucciones
Las instrucciones indican cómo debe comportarse el sistema en ese paso.
Pueden establecer:
- tarea;
- objetivo;
- criterios;
- restricciones;
- formato;
- reglas de escalamiento.
No necesitamos repetir aquí la anatomía del prompt.
La novedad es que las instrucciones pueden cambiar según el estado de la tarea.
Por ejemplo, el mismo agente podría utilizar:
Paso de extracción
“Identifica únicamente cláusulas relativas a uso de datos. No evalúes todavía su riesgo.”
Paso de comparación
“Compara las cláusulas extraídas con el estándar interno. Distingue texto, criterio e inferencia.”
Paso de síntesis
“Consolida exclusivamente hallazgos ya respaldados por evidencia. No agregues nuevos hallazgos.”
No necesitamos un único prompt gigantesco que intente gobernar todas las operaciones simultáneamente.
Evidencia
La evidencia es el material sustantivo sobre el cual debe operar el sistema.
Puede incluir:
- fragmentos recuperados;
- documentos;
- resultados de búsquedas;
- datos de una base;
- respuestas de herramientas;
- outputs de otros componentes.
En trabajo jurídico importa especialmente etiquetar la procedencia.
Comparemos:
El plazo de notificación es 24 horas.con:
FUENTE: Política interna de incidentes, sección 4.2
TEXTO: “...”
FUNCIÓN: criterio interno de comparaciónLa segunda forma permite distinguir qué estamos mostrando y para qué se utiliza.
Evidencia no es instrucción
Un contrato contiene texto contractual.
Una política interna contiene criterios.
Un correo puede contener contexto fáctico.
Mezclarlos en un único bloque sin etiquetas aumenta el riesgo de que el sistema confunda sus funciones.
Herramientas
El modelo puede recibir información sobre las herramientas que están disponibles para esa operación.
No necesita conocer necesariamente todas las herramientas del sistema en todo momento.
Si el paso actual consiste en revisar un documento ya cargado, quizá no necesita una herramienta que pueda modificar permisos de usuarios.
Mostrar solamente herramientas pertinentes tiene dos ventajas:
- reduce el espacio de decisión;
- reduce el riesgo de seleccionar acciones innecesarias.
Una definición de herramienta debería permitir comprender:
- qué hace;
- qué necesita como entrada;
- qué devuelve;
- qué efectos puede producir.
El contexto no debe inducir a tratar una herramienta de alto impacto como si fuera una operación neutra.
Estado
El estado describe dónde se encuentra actualmente la tarea.
Puede contener información como:
contrato_principal: recibido
DPA: recibido
SLA: faltante
revisión_privacidad: en_proceso
revisión_seguridad: pendiente
preguntas_proveedor: no_enviadas
aprobación_humana: pendienteEl estado evita que el agente tenga que reconstruir todo desde una conversación larga.
También permite reglas explícitas:
“No prepares una recomendación de cierre mientras
SLA = faltantey el servicio haya sido clasificado como crítico.”
Estado no es memoria
El estado describe principalmente la ejecución actual.
La memoria, en cambio, permite continuidad más allá de la sesión o tarea inmediata.
La página siguiente desarrollará esa diferencia.
Memoria
La memoria puede aportar información persistente que resulte relevante para el trabajo actual.
Por ejemplo:
- una preferencia autorizada del equipo;
- un criterio previamente confirmado;
- el resultado consolidado de una interacción anterior;
- un antecedente de proyecto que debe conservarse.
Pero una memoria no debería entrar al contexto simplemente porque existe.
Debe ser recuperada selectivamente cuando sea pertinente.
Un dato verdadero pero irrelevante puede contaminar la tarea tanto como un documento equivocado.
Además, en contextos jurídicos debemos añadir preguntas de gobernanza:
- ¿de dónde proviene esa memoria?;
- ¿sigue vigente?;
- ¿a qué asunto pertenece?;
- ¿está permitido reutilizarla?;
- ¿puede contener información confidencial de otro cliente?;
Ejemplos
Los ejemplos pueden entrar al contexto para mostrar cómo debe ejecutarse una tarea.
Ya estudiamos zero-shot, one-shot y few-shot.
Aquí interesa el delta:
un agente puede seleccionar ejemplos relevantes para la tarea actual en vez de utilizar siempre los mismos.
Supongamos que debe clasificar cláusulas de transferencia internacional.
Podría recibir ejemplos de esa materia.
Si luego cambia a responsabilidad contractual, esos ejemplos dejan de ser útiles.
Los ejemplos son parte del contexto de inferencia, no conocimiento factual del expediente.
Deben estar claramente separados de la evidencia real.
Cuatro operaciones para construir contexto
Una forma especialmente útil de pensar context engineering es mediante cuatro verbos:
Seleccionar
¿Qué información entra?
Transformar
¿Entra completa, fragmentada, resumida o estructurada?
Ordenar
¿En qué orden aparece y qué relación tiene con la tarea actual?
Etiquetar
¿Puede distinguirse qué es instrucción, evidencia, ejemplo, memoria, estado o resultado de herramienta?
Podemos representarlo así:
Esta cadena muestra por qué context engineering es una tarea de arquitectura y no sólo de redacción.
Un ejemplo jurídico completo
Nuestro agente está revisando un proveedor de IA.
La tarea actual es evaluar una cláusula sobre reutilización de datos.
Contexto deficiente
El sistema recibe:
- contrato completo;
- siete políticas internas;
- todos los correos del proyecto;
- historial de veinte turnos;
- diez herramientas;
- ejemplos sobre SLA;
- memoria de otros proveedores.
La cantidad de información parece impresionante.
La calidad del contexto es mala.
Contexto diseñado
El sistema recibe:
Instrucción
“Compara la cláusula de uso de datos con el criterio interno. No determines todavía aprobación.”
Evidencia contractual
cláusula 8.3, con fuente identificada.
Criterio
política interna aplicable, versión vigente.
Estado
privacidad = revisión_en_proceso.
Herramientas
búsqueda en anexos y registro de hallazgo; no envío externo.
Memoria
ninguna, porque no existe información persistente necesaria.
Ejemplo
un ejemplo de cómo distinguir texto, inferencia e información faltante.
La segunda versión contiene menos información, pero tiene mayor disciplina semántica.
Contexto y trazabilidad
Context engineering también afecta la capacidad de reconstruir una decisión.
Si un agente produce:
“La cláusula constituye riesgo alto.”
queremos poder identificar qué contexto sustentó esa evaluación:
instrucción aplicada
+
evidencia utilizada
+
criterio vigente
+
estado del expediente
+
herramientas disponiblesEsto no exige registrar indiscriminadamente todo el contenido. La observabilidad tendrá una página propia.
El punto es conceptual: si el contexto cambia, la decisión puede cambiar.
Por tanto, el contexto es parte de la configuración relevante del sistema.
Contexto por tarea, no por sistema completo
Una aplicación puede disponer de una gran cantidad de información global y, sin embargo, cada paso requiere sólo una fracción.
Esto permite distinguir tres universos:
DISPONIBLE PARA LA APLICACIÓN
todo aquello a lo que técnicamente podría acceder
AUTORIZADO PARA EL AGENTE
subconjunto permitido para este agente
PERTINENTE PARA ESTE PASO
subconjunto que conviene incorporar ahoraLas tres capas no deberían confundirse.
Supongamos que una firma dispone de miles de expedientes. El hecho de que la plataforma esté integrada al gestor documental no significa que el agente deba recibir acceso a todos ellos. Y aunque tenga acceso autorizado al expediente actual, una llamada concreta quizá necesite solamente una cláusula y una política.
Esta distinción reduce simultáneamente ruido y riesgo.
Contexto global y contexto local
También conviene diferenciar información estable del sistema de información específica de la tarea.
Contexto relativamente estable puede incluir:
- función del agente;
- reglas generales;
- herramientas habilitadas;
- política de permisos.
Contexto local puede incluir:
- documento actual;
- pregunta concreta;
- estado del expediente;
- resultado de la herramienta anterior.
La arquitectura debe combinar ambos sin reconstruir innecesariamente todo en cada paso.
Actualizar el contexto cuando cambia el mundo
El agente no sólo agrega información. También debe retirar o marcar aquello que dejó de ser válido.
Ejemplo:
09:00 SLA = faltante
09:15 herramienta recupera SLA
09:16 SLA = recibidoSi el contexto continúa incluyendo simultáneamente “SLA faltante” como estado vigente, el sistema puede tomar decisiones sobre una representación obsoleta.
Context engineering incluye, por tanto, mantenimiento de consistencia del contexto, no sólo acumulación.
Qué puede salir mal
Entregar todo siempre
Confunde disponibilidad con relevancia.
Mezclar roles de información
Una política interna no es un contrato. Un ejemplo no es evidencia. Una memoria no es una fuente primaria.
Mantener información obsoleta
Contexto antiguo puede producir decisiones correctas respecto de un estado que ya no existe.
Ocultar los límites
Si el modelo no sabe qué herramientas están permitidas o qué información falta, puede generar soluciones imposibles.
Suponer que una ventana más grande resuelve el problema
Poder incluir más información no elimina la necesidad de seleccionar.
Google advierte que historiales crecientes aumentan costo y latencia y pueden deteriorar la atención sobre elementos críticos.
Qué debes recordar
Context engineering responde a una pregunta operacional:
¿qué necesita recibir el modelo en este paso para hacer correctamente este trabajo?
El contexto puede combinar instrucciones, evidencia, herramientas, estado, memoria y ejemplos.
Cada componente debe cumplir una función identificable.
El objetivo no es llenar la ventana de contexto.
Es construir una representación relevante, diferenciada y suficientemente controlada del problema actual.
El problema que todavía queda abierto
Dos de los componentes de esta página suelen confundirse con especial facilidad:
- información recuperada desde fuentes externas;
- información mantenida durante una sesión;
- información persistida para usos futuros.
No son lo mismo.
La siguiente página separa RAG, sesión y memoria: conocimiento externo, mesa de trabajo temporal y continuidad persistente.