Durante un tiempo, la \"ingeniería de prompts\" fue el nombre que le dimos al arte de obtener buenos resultados de los grandes modelos de lenguaje. Tenía sentido en los primeros días. La mayoría de las personas usaban interacciones de un solo turno, y la palanca principal realmente parecía ser la redacción: preguntar con más claridad, agregar un ejemplo, restringir el formato, y el modelo se comportaba mejor.
Ese enfoque ya es demasiado pequeño para el problema real.
Cuando un sistema de IA falla en producción, el problema generalmente no es que el modelo necesitaba una oración más ingeniosa en el prompt del sistema. El problema es que el modelo no vio la información correcta, vio demasiada información irrelevante, vio la información correcta en el formato equivocado, o no pudo llevar el estado correcto de un paso al siguiente. En otras palabras, el problema no era solo el prompt. El problema era el pipeline de contexto completo.
Por eso el término ingeniería de contexto ha ganado popularidad. La frase entró en la discusión mainstream de IA a mediados de 2025, cuando Tobi Lütke y Andrej Karpathy argumentaron que la \"ingeniería de prompts\" subestimaba el trabajo real involucrado en construir sistemas LLM confiables.[1] Pero la disciplina subyacente es más antigua que el nombre. Si has construido RAG, llamadas a herramientas, sistemas de memoria, resumen o bucles de evaluación, ya has hecho partes de la ingeniería de contexto. Lo que cambió es que finalmente tenemos un nombre que describe el trabajo completo.
Si quieres la imagen más simple posible, la ingeniería de contexto es la capa entre el mundo exterior y la memoria de trabajo del modelo.
flowchart TD\n U[\"Solicitud del usuario\"] --> CE[\"Motor de contexto\"]\n\n I[\"Instrucciones y políticas\"] --> CE\n R[\"Conocimiento recuperado\"] --> CE\n M[\"Memoria y estado guardado\"] --> CE\n T[\"Definiciones y resultados de herramientas\"] --> CE\n H[\"Historial reciente de conversación\"] --> CE\n\n CE --> W[\"Ventana de contexto del modelo\"]\n W --> L[\"El LLM razona y actúa\"]\n L --> O[\"Respuesta o llamada a herramienta\"]\n O --> S[\"Nueva memoria, logs y estado\"]\n S --> CEEse es todo el juego.
El modelo es el motor de razonamiento. El motor de contexto decide sobre qué razona el modelo.
Una razón por la que el término resuena es que une varios hilos que habían estado evolucionando por separado.
La Generación Aumentada por Recuperación, o RAG, nos enseñó que los modelos necesitan acceso a conocimiento externo en tiempo de inferencia.[2] ReAct nos enseñó que el razonamiento y la acción funcionan mejor cuando los modelos pueden llamar herramientas, observar resultados y continuar desde allí.[3] La investigación sobre memoria nos enseñó que los asistentes de larga duración necesitan estrategias de indexación, recuperación y lectura en lugar de acumulación interminable de transcripciones.[4] La evaluación de contexto largo mostró que simplemente meter más tokens en un modelo no es lo mismo que darle mejor memoria de trabajo.[5][6][7]
Visto así, la ingeniería de contexto no es un reemplazo de esas ideas. Es el paraguas que las cubre a todas.
Ese paraguas importa porque los sistemas de IA modernos ya no son prompts aislados. Son sistemas dinámicos que ensamblan instrucciones, documentos, datos estructurados, salidas de herramientas y estado previo en una ventana de contexto temporal para el siguiente paso. LangChain lo describió bien cuando definió la ingeniería de contexto como el trabajo de proporcionar la información y las herramientas correctas en el formato correcto para que el LLM pueda completar la tarea de manera plausible.[8]
La frase \"completar la tarea de manera plausible\" hace mucho trabajo ahí. Es la prueba correcta.
Si un agente falla, la primera pregunta no debería ser: \"¿Cómo hago el prompt más inteligente?\"
La primera pregunta debería ser: \"¿Realmente le di al modelo lo que necesitaba para tener éxito?\"
La ingeniería de prompts sigue importando. Solo se convirtió en un subconjunto de una disciplina más amplia.
El modelo mental antiguo era:
| Ingeniería de prompts | Ingeniería de contexto |
|---|---|
| Escribir mejores instrucciones | Construir el entorno de información completo |
| Enfocarse en una sola solicitud | Enfocarse en sistemas de múltiples pasos |
| Mayormente estático | Dinámico y con estado |
| Optimizar la redacción | Optimizar selección, estructura, memoria y herramientas |
| Mejorar una sola llamada al modelo | Mejorar el bucle completo |
Esta distinción se vuelve obvia en el momento en que construyes un agente.
Supón que estás construyendo un agente de soporte para software empresarial. El usuario pregunta: \"¿Por qué nuestras solicitudes de API están agotando el tiempo de espera?\"
Si piensas solo en términos de prompt, podrías mejorar la redacción:
Esas son mejoras válidas. Pero no son suficientes.
Las preguntas reales del sistema son más difíciles:
Eso es ingeniería de contexto.
El prompt es un elemento dentro de ella.
En la práctica, el contexto incluye todo lo que el modelo ve en tiempo de inferencia, no solo el prompt visible.[8][9]
Eso generalmente significa:
Por eso la frase \"llenar la ventana de contexto\" se ha vuelto tan central. La ventana de contexto no es solo un lugar donde va el texto. Es la memoria de trabajo temporal del modelo. Todo lo que entra en ella compite por atención.
Y la competencia es la palabra clave.
Cada token adicional no es simplemente información adicional. También es distracción adicional.
Uno de los malentendidos más comunes en el mercado actual de IA es que las ventanas de contexto más grandes hicieron que la ingeniería de contexto fuera menos importante.
La investigación apunta en la dirección opuesta.
Lost in the Middle mostró que los modelos a menudo usan contextos largos de manera desigual, rindiendo mejor cuando la información relevante aparece cerca del principio o del final, y peor cuando la información importante está en el medio.[5] El estudio de RAG de contexto largo de Databricks encontró que, si bien agregar más documentos recuperados puede ayudar, solo un pequeño número de modelos de última generación mantuvo un rendimiento sólido por encima de 64k tokens.[6] El informe Context Rot de Chroma fue aún más lejos: incluso las tareas simples se vuelven menos confiables a medida que crece la longitud de entrada, especialmente cuando se introducen ambigüedad y distractores.[7]
Esta es la parte que muchos equipos aprenden de la manera difícil.
Las ventanas más grandes no eliminan la necesidad de elegir. Hacen que el costo de las malas elecciones sea menos obvio al principio y más doloroso después.
Un prompt largo puede fallar de al menos cuatro maneras diferentes:
Por eso la ingeniería de contexto no se trata de maximizar tokens. Se trata de maximizar la densidad de señal dentro de la ventana de contexto.
Aquí es donde entra una de las mejores ideas recientes.
Jason Liu argumentó que el siguiente paso después del RAG clásico basado en fragmentos es dejar de pensar solo en \"los pasajes más similares\" y comenzar a pensar en la forma del espacio de búsqueda.[10] Su enfoque es especialmente útil porque traza una progresión por la que muchos equipos ya están pasando:
Los primeros tres son mejoras en lo que se recupera.
El cuarto es más interesante. Mejora lo que el agente aprende sobre el corpus en sí.
Las facetas le dan al modelo algo parecido a la visión periférica. En lugar de devolver solo los mejores fragmentos, el sistema también puede devolver metadatos agregados:
Eso importa porque la búsqueda por similitud está sesgada hacia lo que es más fácil de hacer coincidir, no necesariamente lo que es más importante inspeccionar.[10] Un sistema de recuperación puede sobre-mostrar incidentes resueltos bien documentados y sub-mostrar incidentes escasos y aún abiertos. Una búsqueda legal puede sobre-mostrar contratos firmados y ocultar los no firmados que realmente necesitan atención. Las facetas ayudan al agente a ver no solo \"qué coincidió\", sino \"qué más existe cerca\".
Este es un cambio conceptual importante.
RAG era principalmente sobre recuperación.
La ingeniería de contexto es cada vez más sobre navegación.
La forma más fácil de hacer concreta la ingeniería de contexto es dividirla en los trabajos reales que realiza.
El primer trabajo es decidir qué merece entrar en la ventana.
Esto incluye recuperación, clasificación, filtrado, elección de fuente y verificaciones de frescura. Suena obvio, pero es donde todavía se gana o se pierde una enorme cantidad de calidad. Benchmarks como BRIGHT muestran que la recuperación realista es mucho más difícil de lo que sugiere la coincidencia semántica superficial.[11] Si la calidad de tu recuperación es débil, ninguna cantidad de pulido de prompts posteriores salvará completamente el resultado.
La selección no es solo \"encontrar fragmentos relevantes\". Es:
Los buenos sistemas a menudo recuperan menos que los sistemas ingenuos, pero lo hacen de manera más intencional.
El segundo trabajo es decidir cómo se representa el contexto elegido.
La misma información puede ser útil o inútil dependiendo del formato. La guía de uso de herramientas de Anthropic es explícita al respecto: las descripciones e interfaces de herramientas moldean fuertemente el comportamiento del modelo.[9] La guía de prompts de contexto largo hace recomendaciones similares para el etiquetado XML, el etiquetado de fuentes y las secciones de documentos claramente separadas.[12]
En la práctica, la estructura significa:
Un resultado corto y bien etiquetado a menudo supera a un blob JSON gigante.
El tercer trabajo es reducir el contexto sin destruir lo que importa.
Aquí es donde muchos sistemas de agentes mejoran mucho o empeoran mucho.
La compresión puede significar:
La documentación de caché de prompts de OpenAI muestra que el orden de los prompts importa económica y cognitivamente: los prefijos compartidos estáticos son más baratos y rápidos cuando se colocan al frente porque los aciertos de caché dependen de la reutilización exacta del prefijo.[13] El trabajo más reciente de OpenAI en la API de Responses sobre compactación lleva la misma idea más lejos al tratar el historial de agentes de larga duración como algo que debe comprimirse en una representación más eficiente en tokens antes de que se llene la ventana.[14]
La compresión no es opcional. La única pregunta es si la haces deliberadamente o dejas que la ventana de contexto se degrade por sí sola.
El cuarto trabajo es decidir qué debe persistir más allá del turno actual.
Aquí es donde muchos equipos cometen el mismo error: confunden la memoria con la retención de transcripciones.
Pero la buena memoria no es \"guardar todo para siempre\". LongMemEval enmarca la memoria a largo plazo como un problema de tres etapas: indexación, recuperación y lectura.[4] Esa es la forma correcta de pensarlo. Un sistema de memoria debería ayudar al modelo a recuperar el hecho previo correcto en el momento correcto, no ahogarlo en el pasado completo.
Esto lleva a una distinción útil:
Si todo permanece en la memoria de trabajo, el modelo se distrae.
Si todo se saca, el modelo pierde continuidad.
La ingeniería de contexto decide qué pertenece a cada capa.
El quinto trabajo es hacer que las herramientas sean legibles para el modelo.
Esta es una parte subestimada de la disciplina. Una superficie de herramientas no es solo diseño de API de software. También es diseño de contexto.
El modelo necesita entender:
Por eso las descripciones de herramientas importan tanto.[9] También es por eso que el énfasis de Jason Liu en los resultados de herramientas es importante.[10] La salida de una herramienta no solo responde la consulta actual. Le enseña al agente cómo pensar en la siguiente consulta.
Cuando la superficie de herramientas se estandariza a través de un protocolo como MCP, esto se vuelve aún más importante. MCP facilita la conexión de herramientas, recursos y prompts a aplicaciones LLM, pero no decide qué información debe mostrarse, cómo debe filtrarse o cuánta debe inyectarse en la siguiente llamada al modelo.[15] El protocolo es la plomería. La ingeniería de contexto sigue siendo el arte.
El sexto trabajo es decidir cuándo no compartir contexto.
Esta es una de las mayores diferencias entre demos de juguete y agentes en producción.
A veces la respuesta correcta no es un prompt compartido más grande. Son múltiples prompts más pequeños con alcances aislados.
El sistema de investigación multi-agente de Anthropic es un ejemplo sólido.[16] Sus subagentes se ejecutan en paralelo con ventanas de contexto separadas, lo que les ayuda a explorar diferentes ramas de un problema sin contaminarse mutuamente con cada detalle intermedio. LangChain describe un patrón similar bajo \"aislar\": a veces la mejor manera de mejorar la confiabilidad del agente es dividir contextos en lugar de acumularlos.[17]
Esto importa porque el contexto compartido tiene un costo oculto. Crea dependencia de camino. Una sola rama mala puede influir en el siguiente paso, y el siguiente, y el siguiente.
El aislamiento es una forma de limitar el radio de explosión.
En 2025, la ingeniería de contexto era principalmente un nombre útil para un problema que la gente ya sentía. En 2026, está comenzando a endurecerse en una arquitectura.
El primer gran cambio es que los constructores están moviendo el estado duradero fuera de la ventana de contexto sin procesar. La edición de contexto y la herramienta de memoria de Anthropic separan explícitamente lo que permanece activo en la ventana de trabajo de lo que debe persistir entre sesiones.[18] El cookbook de enero de 2026 de OpenAI sobre personalización hace el mismo movimiento en una forma diferente: objetos de estado estructurados que persisten entre ejecuciones y se inyectan deliberadamente de vuelta en la memoria de trabajo al inicio de cada ejecución.[19] La API de Responses de OpenAI luego lleva esto un paso más allá con compactación nativa, para que los bucles de agentes de larga duración no requieran que cada equipo construya un subsistema de resumen personalizado desde cero.[14]
Los Managed Agents de Anthropic hace el patrón subyacente inusualmente explícito: la sesión no es la ventana de contexto del modelo.[20] Esa es una idea crítica de 2026. La ventana es memoria de trabajo transitoria. El log de sesión es el objeto duradero. El arnés decide cómo dividir, compactar y rehidratar ese contexto duradero de vuelta en la siguiente llamada al modelo.
El segundo cambio es que la recuperación se está volviendo más justo a tiempo y más nativa de la interfaz. En lugar de cargar por adelantado cada token posiblemente relevante, los equipos están dando a los agentes superficies de recuperación que ya saben cómo operar. ChromaFs de Mintlify es un buen ejemplo: en lugar de arrancar un sandbox completo para la recuperación de documentación, presenta los docs como un sistema de archivos virtual navegable con ls, cat y grep, reduciendo la creación de sesiones p90 de aproximadamente 46 segundos a aproximadamente 100 milisegundos.[21] AgentFS de Turso lleva la misma intuición hacia la ejecución general de agentes: una abstracción de sistema de archivos copy-on-write con almacenamiento portátil de un solo archivo y auditoría integrada.[22]
El tercer cambio es que los grafos de contexto se están convirtiendo en una dirección de implementación, no solo en una metáfora. La tesis de Foundation Capital hizo visible el término, pero la afirmación más fuerte es arquitectónica: cuando los agentes están en el camino de ejecución, pueden capturar trazas de decisiones como artefactos duraderos, no solo emitir salidas finales.[26][27] Los sistemas de código abierto como Graphiti y las plataformas comerciales como Zep operacionalizan esto como grafos de contexto temporales con ventanas de validez, episodios de procedencia e recuperación híbrida a través de semántica, palabras clave y estructura de grafo.[23] TrustGraph adopta un enfoque relacionado al tratar el contexto como un artefacto versionado: grafo, embeddings, evidencia y políticas empaquetados en \"núcleos de contexto\" portátiles que pueden promoverse o revertirse como salidas de compilación.[24][25]
El cuarto cambio es que la ingeniería de contexto ahora es visible en la práctica real de software, no solo en blogs de plataformas. El artículo de MSR de 2026 sobre ingeniería de contexto en software de código abierto estudió 466 repositorios y encontró que los archivos de contexto de IA como AGENTS.md se están extendiendo, pero aún sin una estructura de contenido estable.[28] Eso importa porque marca un movimiento de la teoría a los artefactos operacionales. El contexto ya no es solo algo inferido en tiempo de ejecución. Se está creando, versionando, revisando y minando como parte del ciclo de vida del software.
Si quieres el modelo mental de 2026 en una imagen, se ve así:
flowchart LR\n E[\"Log de sesión / eventos\"] --> A[\"Ensamblador de contexto\"]\n F[\"Archivos, docs y herramientas\"] --> A\n G[\"Grafo de contexto / memoria\"] --> A\n P[\"Políticas y AGENTS.md\"] --> A\n\n A --> W[\"Ventana de contexto de trabajo\"]\n W --> X[\"Acción del agente\"]\n\n X --> E\n X --> GEsa es una arquitectura muy diferente a \"prompt + búsqueda vectorial\".
Una razón por la que esta conversación se vuelve confusa es que la gente usa ingeniería de contexto y grafo de contexto como si significaran lo mismo. No es así.
La ingeniería de contexto es la disciplina más amplia. Es el trabajo de decidir qué va en la próxima ventana de contexto, qué queda fuera, qué se comprime y qué se recupera bajo demanda.
Un grafo de contexto es un posible sustrato de memoria a largo plazo dentro de ese sistema más grande.
Esa distinción importa porque no todo agente útil necesita un grafo de contexto. Un asistente de documentación sobre contenido mayormente estático puede necesitar buena recuperación, diseño de herramientas y compactación, pero no un grafo. Un agente de codificación puede llegar sorprendentemente lejos con instrucciones de repositorio, un log de sesión duradero y una abstracción de sistema de archivos.[20][21][22][28]
Los grafos de contexto se vuelven convincentes cuando el problema tiene cuatro características:
Por eso la mejor definición de un grafo de contexto, en mi opinión, no es \"una base de datos de grafos para IA\". Es una representación duradera de precedente.
Por eso también importan tanto las trazas de decisiones. El enfoque de Foundation Capital es útil aquí: las reglas le dicen al agente qué debería suceder en general; las trazas de decisiones le dicen qué sucedió en un caso específico, bajo restricciones reales, con excepciones reales.[26] Una vez que esas trazas están vinculadas entre entidades y tiempo, obtienes algo mucho más valioso que la memoria genérica. Obtienes juicio buscable.
Si estuviera construyendo un stack serio de ingeniería de contexto hoy, no comenzaría con el grafo. Comenzaría con las interfaces y las reglas de promoción.
Cada acción, resultado de herramienta, observación y artefacto intermedio importante debe aterrizar en un log de sesión de solo adición o almacén de eventos. Este es tu objeto de contexto recuperable.[14][20]
No confundas la ventana de contexto activa con la fuente de verdad.
La ventana es para razonar.
La sesión es para recuperación, reproducción, depuración y rehidratación selectiva.
El ensamblador debe gestionar explícitamente:
Esta es la capa que decide qué ve el modelo ahora. Debe ser observable, testeable y barato de cambiar.[18][19][14]
Dale al modelo primero manejadores ligeros: rutas de archivos, IDs de objetos, URLs, plantillas de consulta, IDs de tickets, IDs de incidentes. Luego déjalo extraer detalles solo cuando sea necesario.[9][18][21]
Aquí es donde los sistemas de archivos, las herramientas MCP, las APIs de búsqueda y las consultas estructuradas se vuelven más valiosas que los volcados gigantes de top-K.
No todo debería convertirse en memoria.
Promovería cuatro clases de artefactos:
Todo lo demás debería permanecer en el log de sesión hasta que demuestre que merece ser promovido.
Esta es la parte que muchos equipos invierten.
El grafo no debería ser tu transcripción sin procesar en forma de grafo. Debería ser la capa curada que se sienta por encima de las sesiones y por debajo del ensamblado en tiempo real:
Si omites el paso de promoción, el grafo se convierte en un vertedero.
Si haces bien la promoción, el grafo se convierte en la memoria de cómo razona realmente la organización.[23][26]
Para 2026, una de las ideas más prometedoras es tratar el contexto como un artefacto versionado. En proyectos de software esto aparece como AGENTS.md y otros archivos de contexto específicos del repositorio.[28] En sistemas nativos de grafos aparece como núcleos de contexto: paquetes portátiles de ontología, estructura de grafo, embeddings, procedencia y política de recuperación.[24][25]
Esto importa porque los cambios de contexto necesitan la misma disciplina operacional que los cambios de código:
Una vez que el contexto se convierte en un artefacto, se vuelve gobernable.
Necesitas ambas:
Esas no son la misma cosa.
Quiero saber:
Si no puedes responder esas preguntas, todavía estás depurando prompts en la oscuridad.
Si estás tratando de evaluar dónde se encuentra tu propio sistema, este modelo de madurez es más útil que las definiciones abstractas.
Tienes un prompt del sistema, un mensaje de usuario y quizás un par de ejemplos.
Esto puede funcionar sorprendentemente bien para tareas estrechas. Se rompe rápidamente cuando la tarea requiere conocimiento fresco, persistencia o herramientas.
Agregas documentos en tiempo de ejecución.
Aquí es donde muchos equipos se detienen. También es donde muchos equipos comienzan a ver las limitaciones del fragmentado, clasificación e hinchazón de contexto ingenuos.
Ahora gestionas historial, resultados de herramientas, memoria y formato de manera intencional.
Este es el primer nivel donde \"ingeniería de contexto\" se convierte en un término útil, porque el sistema ya no es solo prompt más recuperación. Está ensamblando múltiples formas de contexto dinámicamente.
El sistema cambia cómo construye el contexto según la tarea.
Puede:
En este punto, la construcción de contexto es parte de la lógica central de la aplicación.
El sistema trata el contexto como una superficie de ingeniería de primera clase.
Tiene:
Hacia aquí se dirigen los sistemas de producción más sólidos.
Si tuviera que reducir toda la disciplina a una lista de verificación, se vería así:
Nada de esto es glamoroso. Por eso exactamente importa.
La ingeniería de prompts se popularizó porque sonaba como un atajo.
La ingeniería de contexto importa porque describe el trabajo real.
El centro de gravedad en IA se está moviendo.
La pregunta fronteriza solía ser: ¿Qué tan inteligente es el modelo?
La pregunta aplicada es cada vez más: ¿Qué ve el modelo antes de tener que actuar?
Ese es un problema de ingeniería diferente. Tiene menos que ver con prompts individuales y más con el diseño de sistemas. Menos con la redacción y más con el flujo de información. Menos con la calidad de salida de un solo turno y más con si un agente puede mantenerse confiable a lo largo del tiempo.
Por eso la ingeniería de contexto seguirá creciendo como disciplina. Cuanto mejores se vuelven los modelos, más los fallos restantes parecen fallos de contexto. Estado faltante. Herramienta incorrecta. Mala recuperación. Historial inflado. Formato deficiente. Evidencia contradictoria. Memoria débil. Bucles sin límite.
La ironía es que esto hace que los sistemas de IA se parezcan más al software clásico, no menos. Estamos de vuelta construyendo pipelines, interfaces, máquinas de estado, jerarquías de memoria, cachés y capas de observabilidad. La novedad es que todas esas piezas ahora existen al servicio de un motor de razonamiento probabilístico.
El nombre puede ser nuevo. La dirección no lo es.
Los sistemas de IA confiables serán construidos por equipos que traten el contexto como una superficie de producto de primera clase.
Todos los demás seguirán llamando al modelo inestable.
Referencias:
[1] Simon Willison. (2025, 27 de junio). Context engineering.
[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
[8] LangChain. (2025, 23 de junio). The rise of \"context engineering\".
[9] Anthropic. How to implement tool use.
[10] Jason Liu. (2025, 27 de agosto). Beyond Chunks: Why Context Engineering is the Future of RAG.
[12] Anthropic. Long context prompting tips.
[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
[16] Anthropic. (2025, 13 de junio). How we built our multi-agent research system.
[17] LangChain. (2025, 2 de julio). Context Engineering.
[18] Anthropic. (2025, 29 de septiembre). Managing context on the Claude Developer Platform.
[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
[21] Mintlify. (2026, 24 de marzo). How we built a virtual filesystem for our Assistant.
[22] Turso. AgentFS.
[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
[24] TrustGraph. The context development platform.
[25] TrustGraph. Working with Context Cores.
[26] Gupta, J., and Garg, A. (2025, 22 de diciembre). AI's trillion-dollar opportunity: Context graphs.
[27] Garg, A. (2026, 16 de enero). Why context graphs are the missing layer for AI.
", "source_hash": "sha256:352e42d5b8ff71176c26e2e3f9853217033b811bae4f0beaef2cc91e2401caa9", "model": "claude-sonnet-4-6", "generated_at": "2026-04-23T20:55:39.493774+00:00" }