CONTEXT ENGINEERING: QUÉ ES Y POR QUÉ IMPORTA.

Qué es el context engineering

Context engineering es la práctica de diseñar, estructurar y mantener todo el conocimiento que un modelo de lenguaje consume para producir una respuesta. No solo la pregunta que le haces, sino el entorno de información completo, los documentos que lee, los datos que recupera, la memoria de lo que ha pasado antes, las reglas que sigue y las herramientas a las que se conecta.

El término se popularizó a lo largo de 2025, cuando quedó claro que la pieza que faltaba en los sistemas de IA no era capacidad de razonamiento sino calidad de contexto. Andrej Karpathy ayudó a extenderlo, Anthropic publicó su guía Effective Context Engineering for AI Agents, y a mediados de año apareció la primera taxonomía formal de la disciplina en la literatura académica. En poco tiempo pasó de expresión de nicho a forma habitual de nombrar el trabajo real que hay detrás de un agente que funciona.

En qué se diferencia del prompt engineering

El prompt engineering se ocupa de la instrucción, cómo formular la pregunta para que el modelo responda mejor. Fue útil cuando la interacción con la IA se reducía a una caja de texto y una respuesta, pero un agente que trabaja de verdad no vive en una caja de texto. Lee ficheros, consulta un CRM, recuerda decisiones de sesiones anteriores, encadena tareas. El prompt es apenas una fracción de lo que consume.

La diferencia se ve con una imagen sencilla. El prompt engineering afina la pregunta que entra por la puerta, el context engineering diseña toda la casa, qué hay en cada habitación, qué está a la vista y qué guardado, qué está actualizado y qué caducado, quién puede tocar qué. Puedes tener la pregunta perfecta y obtener basura si la casa está desordenada. Y al revés, con la casa en orden, una pregunta mediocre produce buenos resultados, porque el modelo tiene delante lo que necesita.

Por qué el contexto es el cuello de botella

Hay una tesis sencilla detrás de todo esto. El modelo es un bien de consumo, el contexto es el activo. Los modelos mejoran cada trimestre y se igualan, cualquiera puede usar el mismo que usa su competencia. Lo que no se puede copiar es el conocimiento de tu organización bien estructurado, verificado y vigente. Dos empresas con el mismo modelo producen resultados radicalmente distintos según la calidad de su contexto.

Esto no es una intuición, empieza a estar medido. En un experimento de Vercel, el mismo agente, sin cambiar el modelo ni los prompts, pasó del 53% al 100% de eficacia solo cambiando qué conocimiento consumía y cómo estaba organizado. En otro caso documentado, un químico sin experiencia en programación produjo más de cien mil líneas de código funcional apoyándose únicamente en un agente y en contexto bien estructurado. El contexto hizo el trabajo, no el modelo.

Hay una contradicción aquí con lo que nos dice el instinto habitual. Cuando un agente produce un mal resultado, la reacción natural es editar el output o retocar el prompt. El patrón correcto es otro, preguntarse qué le faltaba al contexto. La calidad de lo que produce la IA es un síntoma de la calidad del conocimiento que la alimenta. Si arreglas el síntoma y no la fuente, el error vuelve mañana con otra forma.

El riesgo oculto

Hay un fallo que hace especialmente peligroso al mal contexto, la documentación fantasma. Documentos que parecen vivos pero están muertos por dentro. Forma impecable, sustancia floja, datos obsoletos, fuentes sin verificar, afirmaciones que ya no son ciertas.

Una persona con criterio detecta un documento así y aplica cautela. Un agente no, lo trata como válido, lo cita con confianza, lo resume con elocuencia y propaga el error a velocidad de máquina. El resultado es una ilusión de productividad, mucho output y poco impacto, un equipo que siente que avanza porque el agente entrega con fluidez, sobre cimientos que nadie ha verificado. Gobernar el contexto es, antes que nada, un sistema inmunitario contra este tipo de documento.

Los tres niveles del contexto

Conviene distinguir tres niveles, porque cada uno se gobierna de forma distinta y las organizaciones suelen atender solo al primero.

El primer nivel es el contexto inmediato, lo que le das al modelo en la propia interacción, la instrucción y los datos que acompañan a esa petición concreta. Es el territorio del prompt engineering clásico. Importa, pero es el más superficial y el que menos diferencia sostiene, porque se rehace en cada conversación.

El segundo es el contexto de sesión, la memoria. Lo que el agente ha aprendido durante el trabajo, las preferencias que ha descubierto, las decisiones que se tomaron antes y condicionan lo que viene después. Sin este nivel, el agente empieza de cero cada vez y repite preguntas que ya tenían respuesta. Con él, acumula competencia. Pero la memoria sin curación se convierte en ruido, así que este nivel exige reglas sobre qué se guarda, qué se descarta y cuánto espacio ocupa.

El tercero, que se trabaja muy poco y el que más diferencia produce, es el contexto organizacional. El conocimiento de la empresa entera, sus datos, sus políticas, su forma de hacer las cosas, su criterio. Aquí es donde el context engineering deja de ser una técnica individual para convertirse en un problema de gobernanza. No basta con que un empleado sepa dar buenas instrucciones a la IA, hace falta que el conocimiento del que depende toda la organización esté ordenado, verificado y accesible. Este nivel no se resuelve con prompts, se resuelve gobernando el conocimiento.

Esto no es nuevo, y ahí está la ventaja

La parte que la industria tecnológica suele pasar por alto es que estos problemas están resueltos desde hace décadas. Organizar conocimiento para que la información correcta llegue al consumidor correcto en el momento correcto es, literalmente, la definición de la biblioteconomía. No hace falta inventar taxonomías nuevas, hace falta aplicar las que ya se han validado durante un siglo.

Tres generaciones de pensadores de la documentación llegaron a la misma conclusión que hoy redescubren los equipos de IA. Ranganathan formuló en 1931 las leyes de la biblioteconomía y defendía el estante abierto, que el lector navegue las secciones hasta el libro en lugar de pedírselo a un intermediario. Es exactamente el patrón que Anthropic adoptó al construir Claude Code después de tres iteraciones, dejar que el agente navegue el conocimiento por capas en vez de inyectárselo todo de golpe. Wurman demostró en 1989 que solo existen cinco formas de organizar información y que no hay una sexta. Morville estableció en 2005 que si la información no se puede encontrar, para efectos prácticos no existe, y que los metadatos no son burocracia sino infraestructura invisible.

Lo único que ha cambiado es el consumidor. Antes era un investigador humano que buscaba en un catálogo y toleraba un documento algo desactualizado porque aplicaba juicio. Ahora es un agente que consume el conocimiento programáticamente, lo trata como verdad y propaga el error a escala. La disciplina que gobierna el conocimiento científico desde hace más de veinte años, con sus taxonomías, sus tesauros y sus controles de vigencia, no ha quedado obsoleta con la IA. Se ha vuelto más necesaria que nunca. Context engineering es la actualización de ese oficio para la era de los agentes, no un descubrimiento reciente de consultoras que conocieron el RAG el año pasado.

Qué es un framework de context engineering

Cuando el problema pasa del contexto inmediato al organizacional, hace falta algo más que buenas prácticas sueltas. Hace falta un marco de decisión que responda a preguntas concretas. Qué conocimiento entra en el sistema y qué se queda fuera. Cómo se distingue lo verificado de lo generado sin revisar. Cuándo caduca un documento y quién decide si sigue vigente. Qué se carga siempre y qué solo cuando el agente lo necesita. Quién es responsable de que cada pieza siga siendo cierta.

Un framework de context engineering ordena estas decisiones en capas. La gobernanza establece las reglas de calidad del conocimiento antes de conectar nada a ningún agente. La arquitectura traduce esas reglas a una estructura que un agente puede consumir con eficacia, porque un conocimiento bien gobernado pero mal organizado sigue produciendo malos resultados. La conexión resuelve cómo llega ese conocimiento al agente en el momento justo, sin sobrecargarlo. Y la operación mantiene el sistema vivo, porque un sistema de contexto que nadie cura se degrada solo, el conocimiento caduca, las fuentes cambian y el uso real revela huecos que el diseño no anticipó.

En AlterBiblio hemos desarrollado este marco con el nombre de CONTEXTA, a partir de dos décadas gobernando conocimiento científico y de la investigación reciente sobre agentes. No es el objeto de este artículo, pero si el tercer nivel, el organizacional, es donde reconoces tu problema, ahí es donde empieza el trabajo de verdad.

Qué pasa cuando el contexto falla y qué cuando está gobernado

La diferencia se aprecia mejor en concreto.

Cuando el contexto no está gobernado, un agente consulta un protocolo de hace tres años que sigue archivado como si fuera actual, porque nadie le puso fecha de caducidad ni responsable. Encuentra tres versiones del mismo dato en sitios distintos y cita la que primero aparece, que resulta ser la equivocada. Recupera un informe extenso lleno de narrativa impecable y cifras que ya no valen. Produce un entregable convincente, con buen tono y estructura, construido sobre información que nadie ha verificado. El equipo lo descubre tarde, cuando el error ya circula.

Cuando el contexto está gobernado, ocurre lo contrario. El conocimiento vivo está separado del archivado, así que el agente consume por defecto solo lo verificado y actualizado. Cada dato crítico tiene una única fuente oficial, y lo derivado enlaza a ella en vez de duplicarla. Lo que se almacena son datos anclados a su fuente, y la narrativa se genera al vuelo, así que no hay informes momificados propagando cifras muertas. Cada pieza tiene propietario y fecha, de modo que se sabe qué pesa y qué no. El agente sigue teniendo acceso al histórico si lo necesita, pero no lo confunde con lo vigente. El resultado no es solo más fiable, es auditable, puedes rastrear de dónde salió cada afirmación.

La compresión también cuenta. Más contexto no es mejor contexto. Vercel redujo el suyo de cuarenta a ocho kilobytes, un ochenta por ciento menos, sin perder eficacia, porque el contexto es un recurso finito con rendimientos decrecientes y saturarlo de ruido hace que el agente rinda peor que sin él. Gobernar no es acumular, es destilar.

Por dónde empieza el orden

Poner orden en el contexto no exige una plataforma ni un presupuesto grande para arrancar. Exige criterio, y descansa sobre unos pocos principios que ordenan todo lo demás.

Enunciarlos es fácil. Sostenerlos en una organización real, con sus cientos de documentos, sus sistemas que no se hablan entre sí y varios agentes escribiendo a la vez, es otra cosa. Ahí es donde un principio de una línea se convierte en un trabajo de taxonomías, migración y mantenimiento continuo, y donde la experiencia de haberlo hecho antes marca la diferencia. Pero el punto de partida no cambia, y no depende del modelo que uses. Mientras la industria discute cuál es mejor, la diferencia real la sigue marcando quién tiene su conocimiento en orden.

El context engineering no es una moda del vocabulario técnico, es el reconocimiento de que el activo diferencial de la IA no está en el modelo sino en el conocimiento que consume. Y ese conocimiento no se gobierna solo. La buena noticia es que la disciplina para hacerlo existe desde hace un siglo, solo había que actualizarla para un consumidor nuevo.

Si quieres profundizar en cómo estructurar el conocimiento de tu organización para que tus agentes produzcan resultados fiables, ese es el trabajo que hacemos con CONTEXTA, nuestro marco de gobernanza del conocimiento para IA.