El contexto no se «da»: se construye, en cada decisión, a partir de varias
fuentes y bajo un presupuesto. El context engineering es el oficio de
orquestar esa construcción. Y es la capa que más se subestima, porque no
se ve: cuando funciona, el agente simplemente «entiende»; cuando falla,
nadie sabe por qué respondió eso.
Introducción
Hace diez días definimos el business context (las siete dimensiones) y el
concepto de context engineering. Ayer construimos la memoria que alimenta
el contexto. Hoy lo que toca es el mecanismo: cómo se construye, en cada
decisión, el contexto que el agente realmente necesita.
Porque hay una tentación que conviene nombrar desde el principio: la de
«darle todo al modelo». Ventanas de contexto enormes, «meter toda la
empresa en el prompt». Y hemos visto por qué eso no funciona: el modelo
elige del ruido sin saber qué le corresponde. El context engineering es la
disciplina opuesta: dar lo justo, lo correcto y lo pertinente, y nada más.
El problema
Una cadena de retail ha desplegado un agente de customer intelligence que
ayuda al equipo de pricing y a los responsables de categoría. El agente tiene
acceso a «todo»: ventas, stock, promociones, historial de clientes,
competencia, informes. Y el equipo de pricing empieza a detectar algo
sutil:
- Le piden «¿qué margen tenemos en la referencia R-118 en la zona norte?» y
el agente responde con el margen nacional, porque el dato nacional era el
primero en el contexto. - Le piden «¿cómo afecta la promo de la competencia a nuestra referencia
R-204?» y el agente ignora que la R-204 está agotada en tres tiendas de la
zona, así que la promo de la competencia no le afecta a nuestro stock
(aunque sí a la demanda potencial). - A dos responsables de categorías distintas, la misma pregunta da
respuestas distintas, porque a cada uno se le metió un trozo distinto del
«todo» en el prompt.
El problema no es que falte información: sobra. El problema es que no hay
un mecanismo que construya, para cada pregunta, el contexto específico que
esa pregunta necesita, con las restricciones de zona, stock, vigencia de
promo y permisos de cada usuario. El «todo» no es contexto: es ruido
bienintencionado.
El concepto
El context engineering es, operacionalmente, un orquestador de
contexto: un componente del sistema que, dada una decisión o una pregunta,
construye el contexto como un proceso con pasos, no como una
concatenación de datos.
Los pasos de un orquestador de contexto, en la práctica:
- Clasificar la tarea. Qué tipo de decisión se está tomando (precificar,
aprobar, diagnosticar, responder). El tipo de tarea determina qué
dimensiones del contexto importan. - Resolver el sujeto. Qué entidad u objeto es el foco (esta referencia,
este cliente, esta zona, este contrato). La entity resolution (día 5)
resuelve la identidad canónica del sujeto. - Seleccionar las dimensiones. De las siete dimensiones del business
context (día 10: usuario, tarea, temporal, organizativo, histórico,
transaccional, permisos/riesgo), cuáles son relevantes para esta tarea.
No todas las tareas necesitan todas las dimensiones. - Recuperar de cada fuente. Para cada dimensión relevante, recuperar de
la fuente adecuada:
– Usuario/permisos → del sistema de identidad.
– Transaccional (estado del objeto) → de los sistemas de origen (ERP,
CRM, stock) vía API o de la capa de conocimiento.
– Histórico → de la memoria episódica (día 9, 12).
– Relacional (alcance, dependencias) → del knowledge graph (día 7).
– Conocimiento estable (políticas, reglas) → del RAG (día 8) o de la
ontología (día 4).
– Temporal (vigencia) → de la capa de conocimiento con metadatos de
vigencia. - Aplicar el presupuesto de tokens. El contexto tiene un coste (económico
y de atención del modelo). Se prioriza: lo más pertinente primero, y se
corta lo sobrante. Curar, no acumular. - Formatear con estructura. El contexto no se inyecta como texto plano
suelto: se estructura (secciones etiquetadas, hechos con su fuente,
reglas separadas de datos) para que el modelo lo procese bien y, sobre
todo, para que la respuesta sea auditable: cada pieza de contexto tiene
su origen. - Registrar el contexto usado. Para cada respuesta, se guarda qué
contexto se construyó y de dónde venía cada pieza. Eso es lo que hace
posible auditar «por qué el agente respondió eso» (día 18).
Lo esencial: el contexto es una construcción determinista (o
semi-determinista) que el sistema hace antes de llamar al modelo. El
modelo no «encuentra» el contexto: el sistema se lo da, construido. Y esa
distinción es la que convierte el contexto de un accidente (lo que tocaba
estar en el prompt) en una propiedad del sistema.
Arquitectura
En el diagrama de la serie, el context engineering es el mecanismo que
convierte las capas construidas en el prompt de cada decisión:
AGENTES
↓
REASONING
↓
┌───────────┴───────────┐
↓ ↓
MEMORY CONTEXT
(día 12) (HOY: orquestador de contexto,
7 pasos, presupuesto,
formato, registro)
↓
KNOWLEDGE (día 11)
El orquestador de contexto es el punto donde todas las capas anteriores
(semántica, ontología, entidades, grafo, RAG, memoria) se convierten en el
conjunto concreto de tokens de una decisión. Es la capa más «de ingeniería»
de toda la infraestructura cognitiva, y la que menos se ve cuando funciona.
Caso de uso
La cadena de retail, con su pregunta de marginación. Descomponemos:
- Problema. El agente de customer intelligence da respuestas
inconsistentes y a nivel de granularidad equivocado (nacional en vez de
zona), porque no construye el contexto específico de cada pregunta. - Decisión. Calcular el margen de la referencia R-118 en la zona norte
y valorar el impacto de la promo de la competencia. - Conocimiento necesario. El precio y coste de R-118 en zona norte; el
stock por tienda; la promo de la competencia y su vigencia; las reglas de
pricing de la categoría; el historial de margen de R-118. - Datos. Ventas, stock, coste, promociones (propias y competencia),
informes de categoría. - Relaciones. R-118 → categoría → reglas de pricing; R-118 → tiendas →
zona norte → stock; promo competencia → afecta a → categoría. - Contexto. El usuario es responsable de zona norte (permisos: ve zona
norte, no nacional); la pregunta es de zona (no nacional); la promo de
la competencia está vigente hasta fin de mes; R-118 está agotada en 3
tiendas de la zona. - Memoria. El trimestre pasado, una promo similar de la competencia
redujo el margen de R-118 en zona norte un 4 %; la decisión que se tomó
entonces (contra-promo parcial) y su resultado. - Razonamiento. Margen zona norte (no nacional); stock agotado en 3
tiendas → la promo de la competencia no afecta al stock actual de esas
tiendas, sí a la demanda potencial; cruzar con el episodio del trimestre
pasado (contra-promo parcial redujo el impacto); aplicar las reglas de
pricing de la categoría. - Acción. Responder «margen zona norte: X %; la promo de la competencia
afecta a demanda potencial (stock agotado en 3 tiendas); según el
episodio similar del T1, una contra-promo parcial redujo el impacto;
propuesta: contra-promo parcial en las tiendas con stock» con la
justificación y las fuentes. - Infraestructura. El orquestador de contexto construyendo: tarea
(precificar) → sujeto (R-118, zona norte) → dimensiones (usuario/zona,
transaccional/stock, temporal/vigencia promo, histórico/episodio T1) →
recuperación de cada fuente → presupuesto → formato → registro. El
contexto construido es lo que da la respuesta correcta y auditable.
Trade-offs
- Coste. El orquestador de contexto es un sistema con lógica de
orquestación: clasificación de tarea, selección de dimensiones,
recuperación de varias fuentes, presupuesto. Es infraestructura, no un
prompt. - Complejidad. Las interacciones entre dimensiones (permisos que anulan
histórico, temporalidad que cambia transaccional) son el trabajo real y el
más delicado. Un orquestador que no gestiona esas interacciones produce
contextos incoherentes. - Latencia. Construir el contexto añade pasos (y llamadas a varias
fuentes) antes de la inferencia. Para decisiones de baja criticidad puede
no compensar; para decisiones de alto impacto, es donde se recupera. - Presupuesto de tokens. El presupuesto es una restricción real: demasiado
contexto degrada la atención del modelo y eleva el coste. Curar exige
decidir qué se corta, y eso es una decisión de calidad, no de ahorro. - Seguridad. El orquestador es donde los permisos se aplican de verdad:
si una dimensión trae datos que el usuario no puede ver, el contexto ha
fallado y el modelo los va a usar. Es el control de acceso operativo del
sistema. - Limitación honesta: el orquestador construye contexto a partir de lo
que las capas inferiores proporcionan. Si la capa de conocimiento o la
memoria son malas, el contexto hereda la basura. No compensa: amplifica.
Implicación para la empresa
Para el CIO, el context engineering es la capa que hace auditable al
agente: si cada respuesta tiene su contexto registrado con origen, se puede
explicar por qué el agente respondió lo que respondió. Sin ella, el agente
es una caja negra con cara de asistente.
Para el CDO, el orquestador de contexto es donde convergen todas las capas
que hemos construido (semántica, ontología, grafo, RAG, memoria) y donde los
permisos y la temporalidad se aplican operativamente. Es la capa de mayor
retorno por unidad de complejidad, y la más difícil de hacer bien.
Para la alta dirección, el mensaje es de consistencia: un agente que construye
contexto correcto da la misma respuesta correcta a la misma pregunta,
independientemente de quién la haga (dentro de sus permisos). Esa
consistencia es lo que separa un sistema de producción de un juguete.
Conclusión
El context engineering, operacionalmente, es un orquestador de contexto:
clasifica la tarea, resuelve el sujeto, selecciona las dimensiones
pertinentes, recupera de cada fuente, aplica el presupuesto de tokens,
formatea con estructura y registra lo usado. El contexto no se «da»: se
construye, determinista y auditables, antes de llamar al modelo.
Hoy el agente tiene conocimiento, memoria y contexto. Le falta una cosa para
ser un agente de verdad: saber qué parte del razonamiento es suya (la del
modelo) y qué parte es de la infraestructura (la de las reglas, el grafo,
la temporalidad). Esa división es el tema de mañana, y es una de las
decisiones de arquitectura más importantes de toda la serie.
Siguiente artículo
Mañana: ¿Qué debe razonar un modelo y qué debe resolver la infraestructura?. Veremos por qué no todo debe resolverse dentro del LLM,
y cómo se divide el razonamiento entre el modelo (lenguaje, generalización)
y la infraestructura (reglas, grafo, temporalidad, restricciones).
Fuentes
- Anthropic (2025). «Effective context engineering for AI agents». —
Definición de context engineering como «el conjunto de estrategias para
curar y mantener el óptimo conjunto de tokens durante la inferencia». - Definición de trabajo de la ICE: ver serie, Día 1.
