«El modelo tiene 128.000 tokens de contexto» y «el agente entiende el
negocio» no son la misma frase. La primera es una especificación técnica.
La segunda es una propiedad del sistema. Y la distancia entre las dos se
llama business context.
Introducción
Ayer definimos la memoria: qué debe recordar un agente. Hoy toca su
compañero inseparable: el contexto. Y lo toca corrigiendo la confusión
más extendida de toda la IA empresarial, alimentada por los propios
fabricantes de modelos: la idea de que una ventana de contexto grande
resuelve el problema.
No lo resuelve. Resuelve algo mucho más modesto: permite meter más texto
en la inferencia. Qué texto meter, en qué orden, con qué permisos y para qué
decisión, es otro problema. Y ese problema es el que separa una demo de un
sistema que opera.
El problema
Una empresa de servicios ha conectado su asistente corporativo a «todo»:
documentación, políticas, bases de datos, correos. El modelo tiene una
ventana de contexto enorme, así que el equipo de IA concluyó que «el modelo
puede ver toda la empresa».
En producción, el asistente hace cosas que nadie entiende:
- Un comprador le pide «¿puedo aprobar este descuento del 18 %?» y el
asistente responde «sí, dentro de la política» — sin saber que el comprador
que pregunta solo aprueba hasta el 15 %, o que la política aplicable es la
de 2026, no la de 2024 que también estaba en la ventana. - A un técnico de soporte le pide el historial de un cliente y el asistente
mezcla el historial de tres clientes distintos que compartían dirección
en un documento adjunto. - A la misma pregunta, respondida a distintos usuarios, el asistente da
respuestas distintas: a unos les muestra datos que no les corresponde ver,
a otros les omite información que sí deberían tener.
En los tres casos, el modelo no era «demasiado tonto». El problema es que
la ventana de contexto es un contenedor, no un cerebro: meter toda la
empresa en el contenedor no le da comprensión; le da ruido, y el modelo
elige del ruido sin saber qué le corresponde, qué está vigente y para qué
decisión se le está pidiendo la respuesta.
El concepto
Dos términos que la conversación comercial mezcla, y que hay que separar
una vez por todas:
- Context window (ventana de contexto). La capacidad técnica del
modelo: cuántos tokens puede procesar en una inferencia. Es un número
(8K, 128K, 1M). Es una especificación del hardware y del modelo. - Business context (contexto empresarial). La información situada que
una decisión concreta necesita: quién actúa, sobre qué, en qué momento,
bajo qué restricciones. No es un número: es un conjunto de dimensiones
que hay que identificar y poblar.
Las dimensiones del business context que un agente empresarial necesita, en
la práctica:
- Contexto del usuario. Quién pregunta y qué puede ver: rol, permisos,
departamento. (En el ejemplo: el comprador aprueba hasta el 15 %.) - Contexto de tarea. Qué se está haciendo y en qué punto: «aprobación
de descuento», no «pregunta general». - Contexto temporal. Cuándo ocurre: qué versión de la política está
vigente hoy, qué contrato está activo ahora, qué caduca pronto. - Contexto organizativo. Dónde sitúa la decisión la estructura: qué
unidad, qué jerarquía de aprobación, qué presupuesto. - Contexto histórico. Qué ha pasado antes: decisiones previas,
incidencias, el estado del diálogo (memoria, día 9). - Contexto transaccional. El estado concreto del objeto de la
decisión: este pedido, este cliente, este contrato, con sus valores
actuales. - Contexto de permisos y riesgo. Qué está permitido hacer y cuánto
riesgo conlleva: umbrales, niveles de escalamiento, requisitos de
aprobación.
Ninguna de esas dimensiones es «más texto en la ventana». Son selecciones
hechas a partir de fuentes distintas, con reglas distintas y en función de
la decisión. Y ese proceso de selección tiene nombre:
Context Engineering: el diseño de sistemas que curan y mantienen el
conjunto óptimo de información que llega a la inferencia —la información
correcta, en el formato correcto, en el momento correcto— para que el
modelo pueda completar la tarea.
La definición es la que se ha consolidado desde mediados de 2025 (Anthropic
la formuló de forma explícita: «el conjunto de estrategias para curar y
mantener el óptimo conjunto de tokens durante la inferencia de un LLM,
incluida toda la información que llegue al prompt más allá del propio
prompt»). El salto que esta serie añade es que, en la empresa, el contexto
no se cura a mano: se construye dinámicamente a partir de las siete
dimensiones anteriores, desde las capas que hemos ido construyendo
(semántica, ontología, entidades, grafo, memoria). El context engineering
es, en la práctica, el orquestador que decide qué trae de cada capa para
cada decisión.
Arquitectura
En el diagrama de la serie, el contexto es la otra columna de la
recolección, junto a la memoria:
KNOWLEDGE
↑
┌──────────┴──────────┐
↓ ↓
MEMORY CONTEXT
(día 9) (hoy: business context,
construido dinámicamente
de las 7 dimensiones)
El contexto y la memoria son dos caras de la misma moneda: la memoria es
lo que se recuerda; el contexto es lo que se trae ahora, y por qué. Y
ambos alimentan la misma cosa: el conjunto de tokens que el modelo va a
procesar. La diferencia de diseño es que el contexto se reconstruye en cada
decisión (no es un almacén fijo), mientras que la memoria persiste.
Caso de uso
La empresa de servicios, con su pregunta del descuento. Descomponemos:
- Problema. El asistente aprueba o desaprueba descuentos con criterios
inconsistentes porque no sabe quién pregunta, qué política está vigente
ni qué umbral aplica. - Decisión. Validar si un descuento del 18 % es aprobable por el
comprador que lo solicita. - Conocimiento necesario. La política de descuentos vigente y su
jerarquía de aprobación; el perfil del comprador; el historial del
cliente; el estado del pedido. - Datos. Políticas (PDF, varias versiones), CRM (cliente, perfil), ERP
(pedido), sistema de permisos (roles). - Relaciones. Comprador → rol → umbral de aprobación; política →
versión → vigencia; cliente → pedido → línea; cliente → historial de
descuentos. - Contexto. El usuario es un comprador junior (umbral 15 %); la
política vigente es la de 2026; el pedido es de un cliente estratégico
con histórico de descuentos aceptados; la decisión tiene riesgo medio
(importe sobre un umbral). - Memoria. El último descuento a este cliente fue del 12 %, aprobado;
hay una negociación abierta que justifica la excepción. - Razonamiento. 18 % > umbral del comprador (15 %) → el comprador no
puede aprobarlo; la política 2026 permite excepción hasta el 20 % con
aprobación del director → escalar al director con la justificación
(cliente estratégico + negociación abierta). - Acción. Responder «no puedes aprobarlo tú (umbral 15 %); he preparado
la solicitud de excepción para el director con la justificación» y
encolar la aprobación. - Infraestructura. Las siete dimensiones del contexto construidas
dinámicamente (usuario, tarea, temporal, organizativo, histórico,
transaccional, permisos/riesgo) + la memoria del caso + el razonamiento
que aplica la jerarquía. La ventana de contexto enorme era necesaria
pero insuficiente: sin las siete dimensiones, el modelo elegía del
ruido.
Trade-offs
- Coste. Construir contexto dinámico es un sistema de orquestación: hay
que identificar las fuentes de cada dimensión, las reglas de selección y
el orden. Es más caro que «meterlo todo en el prompt». - Complejidad. Las siete dimensiones no son independientes: el contexto
de permisos puede anular el contexto histórico (un dato que el usuario vio
ayer y hoy no debería ver). Gestionar esas interacciones es el trabajo
real del context engineering. - Latencia. Construir el contexto añade pasos antes de la inferencia.
Para decisiones de baja criticidad puede no compensar; para decisiones de
alto impacto es exactamente donde el coste se recupera. - Presupuesto de tokens. Aun con ventanas enormes, el contexto tiene un
coste (económico y de atención del modelo: demasiado contexto degrada la
precisión). Hay que curar, no acumular. - Seguridad. El contexto es el punto 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
más importante del sistema. - Limitación honesta: el context engineering cura el contexto que las
capas inferiores proporcionan. Si la semántica, el grafo o la memoria son
malos, el contexto hereda la basura. No es una capa que compense: es una
capa que amplifica.
Implicación para la empresa
Para el CIO, la lección es de expectativas: la «ventana de contexto grande»
es una especificación de compra, no una propiedad del sistema. La propiedad
que hay que exigir es que el agente construya el contexto correcto para cada
decisión, y eso es diseño de infraestructura, no selección de modelo.
Para el CDO, el context engineering es donde convergen todas las capas que
hemos visto: semántica, ontología, entidades, grafo, memoria. Si esas capas
no existen, el contexto se construye sobre aire. Y es también donde los
permisos y el riesgo se aplican de forma operativa.
Para la alta dirección, el mensaje es de control: un agente que no sabe qué
contexto traer es un agente que no se puede auditar. El contexto construido
explícitamente es lo que permite responder «por qué el agente respondió
eso».
Conclusión
Una ventana de contexto enorme es una especificación técnica: permite meter
más texto. Un agente que entiende el negocio construye business context:
la información situada de las siete dimensiones (usuario, tarea, temporal,
organizado, histórico, transaccional, permisos/riesgo), curada
dinámicamente para cada decisión. A ese proceso le llamamos context
engineering, y es el último eslabón de la primera mitad de esta serie.
Hemos terminado de describir qué necesita un agente: datos con
significado, entidades resueltas, relaciones, conocimiento recuperable,
memoria tipada y contexto situado. A partir de mañana cambiamos de pregunta:
de «¿qué necesita un agente?» a «¿cómo se construye, pieza a pieza, la
infraestructura que se lo proporciona?».
Siguiente artículo
Mañana: Cómo construir una capa de conocimiento para una empresa.
Empezamos la segunda mitad de la serie: el diseño de la arquitectura que
integra datos, semántica, ontología, entidades, relaciones y conocimiento en
una capa que el agente puede usar.
Fuentes
- Anthropic (2025). «Effective context engineering for AI agents». —
Definición de context engineering: «el conjunto de estrategias para curar
y mantener el óptimo conjunto de tokens durante la inferencia de un LLM». - Definición de trabajo de la ICE: ver serie, Día 1.
