Las tres capas — y cuáles se commoditizan
Cualquier sistema de IA empresarial vive en tres capas. Hasta ahora hablábamos de las tres como si fueran lo mismo, mezcladas en el discurso comercial. La consolidación de abril obliga a separarlas.
Capa cognitiva
Los modelos: Gemini, Claude, GPT, Llama, los que sean.
Tres o cuatro proveedores principales, APIs equivalentes, benchmarks comparables. Tu CTO va a poder elegir casi por precio en 18 meses.
Capa de control
Routing, autorización, observabilidad, gobernanza, auditoría.
Los hyperscalers la nombran «Agent Control Plane» y la integran con la suscripción. Igual que la virtualización con VMware hace 15 años.
Capa de contexto
Datos curados, relaciones del dominio, instrucciones operativas codificadas.
No se commoditiza. Es lo que hace que el agente que vendes a un banco no sea intercambiable con el que vendes a otro.
Por qué la capa de contexto no se vende en Marketplace
Tres razones operativas, no filosóficas:
1. Es propiedad del cliente por definición. Los datos curados son tus datos. Las relaciones documentadas son tu conocimiento del dominio. Las instrucciones operativas son tus políticas. Un Marketplace puede vender plantillas, ejemplos, frameworks — no puede vender lo específico de tu empresa, porque no lo tiene. Si te ofrecen un agente «ya entrenado con el contexto de tu sector», o (a) están vendiendo un genérico que tendrás que personalizar de todas formas, o (b) te están vendiendo el contexto de un competidor del que se llevaron datos en un proyecto anterior, lo que es problema legal antes que técnico.
2. No es estandarizable. La diferencia entre dos empresas que venden seguros es exactamente lo que cada una considera «cliente premium»: el umbral, los criterios, las excepciones, las políticas de retención. Esa definición no está en ningún manual sectorial. Está en cómo opera concretamente tu empresa. Un agente pre-built con un contexto estandarizado puede cubrir el 20% genérico — el 80% que decide tu rentabilidad sigue siendo tuyo. Y construir ese 80% es ingeniería, no configuración.
3. Requiere disciplina ingenieril específica. Esta es la parte donde context engineering ≠ prompt engineering, ni data engineering, ni MLOps. Hay decisiones técnicas concretas — qué información se retiene, cuándo expira, qué se trae bajo demanda, qué se deja fuera deliberadamente, qué se invalida cuando cambia el negocio — que tienen impacto operativo directo (latencia, coste cloud) y de negocio (qué decisiones automatizadas son posibles). Esas decisiones son una disciplina de ingeniería propia, con sus propios anti-patrones, su propio coste de error, su propia curva de aprendizaje.
A esa disciplina la llamamos ingeniería de contexto. La desarrollamos como concepto en otra pieza; aquí toca su arquitectura. A continuación está cómo se diseña.
Las 5 capas de la ingeniería de contexto
Cuando alguien dice «context engineering», normalmente está pensando en RAG. RAG es una técnica dentro de la capa 4. La ingeniería de contexto, vista como arquitectura, tiene cinco capas, y diseñar las cinco explícitamente es lo que separa a un agente que funciona en producción de uno que se queda en piloto.
Las políticas operativas codificadas en lenguaje natural — el «manual del empleado» del agente. Versionado, con responsable, con proceso de cambio. No es el system prompt grande.
El contexto de la sesión actual. Acotada por turnos o por minutos. Decide cuándo el agente «olvida» lo que dijiste hace cuatro mensajes.
El contexto entre sesiones. Días, semanas, meses. La política de retención e invalidación es el corazón de esta capa.
Qué se trae al contexto cuando se necesita. RAG es una implementación, no una política. Aquí viven las decisiones de relevancia, prioridad y resolución de contradicción.
La capa más olvidada y la que más fallos en producción provoca. TTL explícito por tipo, push-invalidation cuando algo cambia, auditoría de qué se está sirviendo.
Capa 1: instrucciones curadas
Son las políticas operativas codificadas en lenguaje natural — el equivalente al manual del empleado. Qué hace, qué no hace, qué tono usa, qué casos escala, qué decisiones nunca toma sin humano. No es el system prompt grande. Es un cuerpo curado, versionado, con responsable de mantenimiento, con proceso de cambio.
La diferencia operativa: cuando legal cambia una política de retención de datos, sabes exactamente qué documento del cuerpo curado actualizar y qué tests pasar antes de redeploy. Sin esto, las políticas viven en el system prompt como un solo bloque irrevisable, y cada cambio rompe tres cosas que nadie había probado.
Capa 2: memoria de trabajo
Es el contexto de la sesión actual — lo que el agente recuerda dentro de una conversación. Acotada por turnos o por minutos, no por meses. Es la capa que decide cuándo el agente «olvida» lo que le acabas de decir hace cuatro mensajes.
Mal diseñada, esta capa o explota la factura (todo el historial en cada llamada) o pierde información crítica (resumen agresivo que tira el dato que importa). Bien diseñada, tiene política explícita de qué se mantiene literal, qué se resume, qué se descarta — y esa política es revisable.
Capa 3: memoria episódica
Es el contexto entre sesiones — lo que el agente recuerda de interacciones pasadas con el mismo cliente, el mismo proyecto, el mismo dossier. Días, semanas, meses.
Aquí es donde más empresas se equivocan: o no la implementan (cada conversación arranca de cero, frustrando al usuario) o la implementan sin TTL ni invalidación (el agente sigue usando información desactualizada de hace seis meses). La política de retención e invalidación es el corazón de esta capa.
Capa 4: retrieval policy
Es la política de «qué se trae al contexto cuando se necesita» — sobre qué corpus, con qué criterio de relevancia, con qué límite. Aquí vive RAG, pero RAG es una implementación, no una política.
La política decide preguntas reales: ¿se trae el documento más reciente, el más relevante semánticamente, o ambos con un peso? ¿Se prioriza un documento firmado sobre un draft? ¿Qué se hace cuando hay contradicción entre dos fuentes? Sin política explícita, RAG funciona los primeros tres meses y empieza a fallar cuando el corpus crece y la cadencia de actualización cambia.
Capa 5: invalidación y expiración
Es la política de cuándo el contexto deja de ser válido. La capa más olvidada y la que más fallos en producción provoca.
Una política de cliente cambió en marzo: ¿el agente sigue citando la versión de diciembre? Un producto fue retirado del catálogo: ¿el agente sigue ofreciéndolo? Un empleado salió de la empresa: ¿el agente sigue mencionándolo como contacto?
Esta capa requiere TTL explícito por tipo de información, mecanismo de invalidación bajo demanda (push) cuando algo cambia, y auditoría de qué se está sirviendo en producción. Sin esta capa, todo el resto del trabajo se degrada con el tiempo de forma silenciosa.
El contrato de coste por petición
Las cinco capas anteriores están conectadas por una decisión que decide si tu factura cloud crece linealmente con el uso o explota: qué capa paga qué, con qué límite por petición.
Una petición típica a un agente bien diseñado activa: una porción de instrucciones curadas (capa 1), el extracto relevante de memoria de trabajo (capa 2), una porción acotada de memoria episódica (capa 3), uno o dos documentos retrievados (capa 4), todo bajo políticas de TTL (capa 5).
La matemática que asusta al CFO: si cada capa puede consumir 10.000 tokens, una petición puede llegar fácilmente a 50.000 tokens — y a 50.000 peticiones por día son 2.500 millones de tokens diarios. Multiplicado por el precio del modelo, son cifras que aparecen en el comité de Q3 con un signo de exclamación.
El contrato de coste obliga a decidir, antes de implementar: cuánto puede consumir cada capa por petición, cuándo se prefiere truncar a traer más, cuándo se prefiere bajar a un modelo más barato a cambio de más contexto. Estas decisiones se toman al diseñar la arquitectura — no se descubren cuando llega la factura. Es el ángulo que desarrollamos en el coste real de IA en producción: la diferencia entre piloto y escala no es lineal.
Tres anti-patrones que vemos recurrentemente
RAG como tirita
El equipo añade RAG porque «el agente no sabe X». Funciona en demos, falla cuando el corpus crece.
Causa raíz: ausencia de retrieval policy explícita y de capa 5 (invalidación). Solución: subir RAG a política versionada con responsable, no a hack.
Prompt-as-database
El system prompt acumula instrucciones, ejemplos, datos, reglas — hasta llegar a 30.000 tokens irrevisables. La factura sube, la calidad baja, nadie quiere tocarlo porque «rompe cosas».
Solución: separar capa 1 (instrucciones curadas, versionadas) de capas 2-4 (datos bajo demanda).
Memoria persistente sin TTL
Se implementa memoria episódica entusiasmados, sin política de invalidación. A los seis meses el agente cita información desactualizada, recomienda productos retirados, contacta a empleados que se han ido.
Solución: TTL explícito por tipo, mecanismo de push-invalidation, auditoría periódica.
Cómo se introduce en un brownfield
No hay que tirar nada. Plan de migración en cuatro semanas, ejecutable sin parar producción.
Para cada agente actual en producción, identifica qué hay implementado en cada una de las cinco capas (puede ser cero) y qué se asume implícitamente. Output: mapa de capas + lista de implícitos.
Pon números a cada capa con datos reales del último mes. Identifica los dos o tres puntos donde la factura crece sin que la calidad mejore. Output: contrato de coste documentado + alertas de threshold.
Implementa la capa 5 sobre la información que más cambia (catálogo, políticas, contactos). Push-invalidation desde sistemas fuente, TTL en lo demás. Output: capa 5 operativa.
Saca el contenido de «manual del empleado» del system prompt a un cuerpo versionado con responsable. Sin más. Las capas 2-4 se pueden refactorizar después; lo crítico es que la capa 1 deje de ser código pegado al prompt. Output: capa 1 operativa, base estable para iterar.
A las cuatro semanas: agente con arquitectura documentada, factura predecible y capacidad real de iterar. No es el destino final — es el punto desde el que se puede construir.
Lo que el Marketplace no puede comprar
Cuando el comité de dirección reciba la propuesta del integrador con el catálogo de 1.000+ agentes pre-built, la pregunta correcta no es «¿este agente cubre nuestro caso?». Es: «si compramos este agente, ¿quién va a construir las cinco capas de contexto sobre nuestros datos? ¿Con qué metodología? ¿Quién es dueño de la capa de contexto en año 3?».
Si las respuestas son «el integrador, su metodología, ellos son dueños», lo que estás comprando no es un agente. Es una dependencia.
Lo que el Marketplace vende — modelos cognitivos accesibles, planos de control estandarizados, agentes pre-built — es valioso y barato. Lo que el Marketplace no puede vender es el contexto específico de tu empresa diseñado con disciplina arquitectónica. Y eso es el 80% del trabajo y el 100% de la diferenciación.
Si tu próximo RFP de IA te ayuda a separar lo uno de lo otro, ya tenemos el siguiente paso publicado: Ingeniería de contexto: 7 preguntas para tu RFP de IA — el brief del comprador que aplica este criterio a la mesa de evaluación.
Fuentes y referencias: análisis del Marketplace de agentes y de los movimientos de hyperscalers, Big 4 e integradores grandes en abril de 2026; nomenclatura «Agent Control Plane» en keynotes de hyperscalers (2026); metodología onext de Spec-Driven Development e ingeniería de contexto en producción.
Lectura complementaria: Context Engineering: la disciplina | 7 preguntas para tu RFP de IA | Coste real de IA en producción | Spec-Driven Development
Metodología onext: onext AI Engine es la metodología con la que acompañamos a empresas medianas y grandes a diseñar sus cinco capas de contexto sobre agentes pre-built o construidos a medida — con propiedad y portabilidad del contexto desde el día uno.