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 únicas, 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.
\nEse marco ahora es demasiado pequeño para el problema real.
\nCuando un sistema de IA falla en producción, el problema generalmente no es que el modelo necesitara una frase 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 incorrecto, o no pudo llevar el estado correcto de un paso al siguiente. En otras palabras, el problema no fue solo el prompt. El problema fue toda la tubería de contexto.
\nPor eso el término ingeniería de contexto ha cobrado fuerza. La frase entró en la discusión principal de la 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 la construcción de 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, resúmenes 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 todo el trabajo.
\nSi 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.
\nflowchart 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 de conversación reciente\"] --> 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, registros y estado\"]\n S --> CE\nEse es todo el juego.
\nEl modelo es el motor de razonamiento. El motor de contexto decide sobre qué puede razonar el modelo.
\nUna razón por la que el término resuena es que une varios hilos que habían estado evolucionando por separado.
\nLa Generación Aumentada por Recuperación, o RAG, nos enseñó que los modelos necesitan acceso a conocimiento externo en el momento de la inferencia.[2] ReAct nos enseñó que el razonamiento y la acción funcionan mejor cuando los modelos pueden llamar a herramientas, observar los resultados y continuar desde allí.[3] La investigación en memoria nos enseñó que los asistentes de larga duración necesitan estrategias de indexación, recuperación y lectura, en lugar de una 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 una mejor memoria de trabajo.[5][6][7]
\nVisto de esta manera, la ingeniería de contexto no es un reemplazo de esas ideas. Es el paraguas que las cubre.
\nEse paraguas importa porque los sistemas modernos de IA ya no son prompts aislados. Son sistemas dinámicos que ensamblan instrucciones, documentos, datos estructurados, resultados de herramientas y estado previo en una ventana de contexto temporal para el siguiente paso. LangChain describió esto 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]
\nLa frase \"completar la tarea de manera plausible\" hace mucho trabajo allí. Es la prueba correcta.
\nSi un agente falla, la primera pregunta no debería ser: \"¿Cómo hago el prompt más inteligente?\"
\nLa primera pregunta debería ser: \"¿Le di al modelo lo que necesitaba para tener éxito?\"
\nLa ingeniería de prompts todavía importa. Simplemente se convirtió en un subconjunto de una disciplina más grande.
\nEl modelo mental antiguo era:
\n| Ingeniería de prompts | \nIngeniería de contexto | \n
|---|---|
| Escribir mejores instrucciones | \nConstruir el entorno de información completo | \n
| Enfocarse en una sola solicitud | \nEnfocarse en sistemas de múltiples pasos | \n
| Mayormente estática | \nDinámica y con estado | \n
| Optimizar la redacción | \nOptimizar selección, estructura, memoria y herramientas | \n
| Mejorar una sola llamada al modelo | \nMejorar todo el bucle | \n
Esta distinción se vuelve obvia en el momento en que construyes un agente.
\nSupongamos que estás construyendo un agente de soporte para software empresarial. El usuario pregunta: \"¿Por qué nuestras solicitudes a la API están dando tiempo de espera?\"
\nSi piensas solo en términos de prompts, podrías mejorar la redacción:
\nEsas son mejoras válidas. Pero no son suficientes.
\nLas preguntas reales del sistema son más difíciles:
\nEso es ingeniería de contexto.
\nEl prompt es una línea de pedido dentro de ella.
\nEn la práctica, el contexto incluye todo lo que el modelo ve en el momento de la inferencia, no solo el prompt visible.[8][9]
\nEso generalmente significa:
\nPor 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 compite por la atención.
\nY la competencia es la palabra clave.
\nCada token extra no es solo información adicional. También es distracción adicional.
\nUno de los conceptos erróneos más comunes en el mercado actual de la IA es que las ventanas de contexto más grandes hicieron que la ingeniería de contexto fuera menos importante.
\nLa investigación apunta en la dirección opuesta.
\nLost in the Middle mostró que los modelos a menudo usan contextos largos de manera desigual, funcionando 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 los 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 la entrada, especialmente cuando se introducen ambigüedad y distractores.[7]
\nEsta es la parte que muchos equipos aprenden por las malas.
\nLas ventanas más grandes no eliminan la necesidad de elegir. Hacen que el costo de las malas decisiones sea menos obvio al principio y más doloroso después.
\nUn prompt largo puede fallar de al menos cuatro maneras diferentes:
\nPor eso la ingeniería de contexto no se trata de maximizar los tokens. Se trata de maximizar la densidad de señal dentro de la ventana de contexto.
\nAquí es donde entra una de las mejores ideas recientes.
\nJason 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 marco es especialmente útil porque traza una progresión por la que muchos equipos ya están transitando:
\nLos primeros tres son mejoras en lo que se recupera.
\nEl cuarto es más interesante. Mejora lo que el agente aprende sobre el corpus en sí.
\nLas facetas le dan al modelo algo así como visión periférica. En lugar de devolver solo los primeros fragmentos, el sistema también puede devolver metadatos agregados:
\nEso importa porque la búsqueda por similitud está sesgada hacia lo que es más fácil de coincidir, no necesariamente hacia lo que es más importante de inspeccionar.[10] Un sistema de recuperación puede sobresalir en incidentes resueltos bien documentados y subestimar los incidentes escasos que aún están abiertos. Una búsqueda legal puede sobresalir en 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\".
\nEste es un cambio conceptual importante.
\nRAG se trataba principalmente de recuperación.
\nLa ingeniería de contexto se trata cada vez más de navegación.
\nLa forma más fácil de hacer concreta la ingeniería de contexto es dividirla en los trabajos reales que realiza.
\nEl primer trabajo es decidir qué merece entrar en la ventana.
\nEsto incluye recuperación, clasificación, filtrado, elección de fuente y comprobaciones de actualidad. Suena obvio, pero sigue siendo donde se gana o se pierde una gran cantidad de calidad. Puntos de referencia 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 tu calidad de recuperación es débil, ninguna cantidad de pulido posterior del prompt salvará completamente el resultado.
\nLa selección no es solo \"encontrar fragmentos relevantes\". Es:
\nLos buenos sistemas a menudo recuperan menos que los sistemas ingenuos, pero lo recuperan de manera más intencional.
\nEl segundo trabajo es decidir cómo se representa el contexto elegido.
\nLa misma información puede ser útil o inútil dependiendo del formato. La guía de uso de herramientas de Anthropic es explícita sobre esto: las descripciones e interfaces de las 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]
\nEn la práctica, la estructura significa:
\nUn resultado corto y bien etiquetado a menudo supera a un blob JSON gigante.
\nEl tercer trabajo es reducir el contexto sin destruir lo que importa.
\nAquí es donde muchos sistemas de agentes mejoran mucho o empeoran mucho.
\nLa compresión puede significar:
\nLa documentación de almacenamiento en caché de prompts de OpenAI muestra que el orden de los prompts importa tanto económica como cognitivamente: los prefijos compartidos estáticos son más baratos y rápidos cuando se colocan al principio porque los aciertos de caché dependen de la reutilización exacta del prefijo.[13] La API de Respuestas más nueva de OpenAI impulsa la misma idea aún más con la compactación nativa, tratando 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 la ventana se llene.[14]
\nLa compresión no es opcional. La única pregunta es si lo haces deliberadamente o dejas que la ventana de contexto se degrade por sí sola.
\nEl cuarto trabajo es decidir qué debe persistir más allá del turno actual.
\nAquí es donde muchos equipos cometen el mismo error: confunden la memoria con la retención de transcripciones.
\nPero la buena memoria no es \"conservarlo 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 pensar en ello. Un sistema de memoria debería ayudar al modelo a recuperar el hecho correcto anterior en el momento correcto, no ahogarlo en el pasado completo.
\nEsto lleva a una distinción útil:
\nSi todo permanece en la memoria de trabajo, el modelo se distrae. Si todo se expulsa, el modelo pierde continuidad.
\nLa ingeniería de contexto decide qué pertenece a cada capa.
\nEl quinto trabajo es hacer que las herramientas sean legibles para el modelo.
\nEsta es una parte subestimada de la disciplina. La superficie de una herramienta no es solo el diseño de una API de software. También es diseño de contexto.
\nEl modelo necesita entender:
\nPor eso las descripciones de las herramientas importan tanto.[9] También es por eso que el énfasis de Jason Liu en los resultados de las herramientas es importante.[10] La salida de una herramienta no solo responde a la consulta actual. Le enseña al agente cómo pensar en la siguiente consulta.
\nCuando la superficie de la herramienta 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ánto debe inyectarse en la siguiente llamada al modelo.[15] El protocolo es la fontanería. La ingeniería de contexto sigue siendo el oficio.
\nEl sexto trabajo es decidir cuándo no compartir el contexto.
\nEsta es una de las mayores diferencias entre las demostraciones de juguete y los agentes de producción.
\nA veces, la respuesta correcta no es un prompt compartido más grande. Son múltiples prompts más pequeños con ámbitos aislados.
\nEl sistema de investigación multiagente 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 entre sí 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 los contextos en lugar de acumularlos.[17]
\nEsto importa porque el contexto compartido tiene un costo oculto. Crea dependencia de la ruta. Una sola rama mala puede influir en el siguiente paso, y en el siguiente, y en el siguiente.
\nEl aislamiento es una forma de limitar el radio de explosión.
\nEn 2025, la ingeniería de contexto era principalmente un nombre útil para un problema que la gente ya sentía. En 2026, está empezando a endurecerse en una arquitectura.
\nEl 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 personalización de OpenAI de enero de 2026 hace el mismo movimiento de una forma diferente: objetos de estado estructurados que persisten entre ejecuciones y se inyectan deliberadamente de nuevo en la memoria de trabajo al comienzo de cada ejecución.[19] La API de Respuestas de OpenAI luego lleva esto un paso más allá con la 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]
\nLos Agentes Gestionados de Anthropic hacen que el patrón subyacente sea 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 registro de la sesión es el objeto duradero. El arnés decide cómo dividir, compactar y rehidratar ese contexto duradero de nuevo en la siguiente llamada al modelo.
\nEl 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 precargar 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 documentos como un sistema de archivos virtual navegable con ls, cat y grep, reduciendo el tiempo de creación de sesión p90 de aproximadamente 46 segundos a aproximadamente 100 milisegundos.[21] AgentFS de Turso impulsa la misma intuición hacia la ejecución general de agentes: una abstracción de sistema de archivos de copia en escritura con almacenamiento de archivo único portátil y auditoría incorporada.[22]
El tercer cambio es que los grafos de contexto se están convirtiendo en una dirección de implementación, no solo 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 se sientan en la ruta de ejecución, pueden capturar rastros de decisión como artefactos duraderos, no solo emitir resultados finales.[26][27] Sistemas de código abierto como Graphiti y plataformas comerciales como Zep operacionalizan esto como grafos de contexto temporales con ventanas de validez, episodios de procedencia y recuperación híbrida a través de semántica, palabras clave y estructura de grafos.[23] TrustGraph adopta un enfoque relacionado al tratar el contexto como un artefacto versionado: grafo, incrustaciones, evidencia y políticas empaquetados en \"núcleos de contexto\" portátiles que se pueden promover o revertir como resultados de compilación.[24][25]
\nEl cuarto cambio es que la ingeniería de contexto ahora es visible en la práctica real del software, no solo en los blogs de las 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 sin una estructura de contenido estable todavía.[28] Eso importa porque marca un movimiento de la teoría a los artefactos operativos. El contexto ya no es solo algo inferido en tiempo de ejecución. Se está creando, versionando, revisando y extrayendo como parte del ciclo de vida del software.
Si quieres el modelo mental de 2026 en una imagen, se ve así:
\nflowchart LR\n E[\"Registro de sesión / eventos\"] --> A[\"Ensamblador de contexto\"]\n F[\"Archivos, documentos 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 --> G\nEsa es una arquitectura muy diferente de \"prompt + búsqueda vectorial\".
\nUna 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í.
\nLa ingeniería de contexto es la disciplina más amplia. Es el trabajo de decidir qué entra en la siguiente ventana de contexto, qué se queda fuera, qué se comprime y qué se recupera bajo demanda.
\nUn grafo de contexto es un posible sustrato de memoria a largo plazo dentro de ese sistema más grande.
\nEsa distinción importa porque no todos los agentes útiles necesitan 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 del repositorio, un registro de sesión duradero y una abstracción del sistema de archivos.[20][21][22][28]
\nLos grafos de contexto se vuelven convincentes cuando el problema tiene cuatro características:
\nPor 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 del precedente.
\nPor eso también los rastros de decisión importan tanto. El marco de Foundation Capital es útil aquí: las reglas le dicen al agente lo que debería suceder en general; los rastros de decisión le dicen lo que sucedió en un caso específico, bajo restricciones reales, con excepciones reales.[26] Una vez que esos rastros se vinculan a través de entidades y tiempo, obtienes algo mucho más valioso que la memoria genérica. Obtienes juicio buscable.
\nSi estuviera construyendo una pila seria de ingeniería de contexto hoy, no empezaría con el grafo. Empezaría con las interfaces y las reglas de promoción.
\nCada acción, resultado de herramienta, observación y artefacto intermedio importante debería aterrizar en un registro de sesión o almacén de eventos de solo adición. Este es tu objeto de contexto recuperable.[14][20]
\nNo confundas la ventana de contexto activa con la fuente de verdad.
\nLa ventana es para razonar. La sesión es para recuperación, repetición, depuración y rehidratación selectiva.
\nEl ensamblador debería gestionar explícitamente:
\nEsta es la capa que decide lo que el modelo ve ahora. Debería ser observable, comprobable y barato de cambiar.[18][19][14]
\nDale al modelo identificadores ligeros primero: rutas de archivo, IDs de objetos, URLs, plantillas de consulta, IDs de tickets, IDs de incidentes. Luego, que obtenga los detalles solo cuando sea necesario.[9][18][21]
\nAquí es donde los sistemas de archivos, las herramientas MCP, las API de búsqueda y las consultas estructuradas se vuelven más valiosos que los volcados gigantes de top-K.
\nNo todo debería convertirse en memoria.
\nYo promovería cuatro clases de artefactos:
\nTodo lo demás debería permanecer en el registro de la sesión hasta que demuestre que merece la promoción.
\nEsta es la parte que muchos equipos invierten.
\nEl grafo no debería ser tu transcripción sin procesar en forma de grafo. Debería ser la capa curada que se encuentra por encima de las sesiones y por debajo del ensamblaje en tiempo real:
\nSi te saltas 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]
\nPara 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, incrustaciones, procedencia y política de recuperación.[24][25]
Esto importa porque los cambios de contexto necesitan la misma disciplina operativa que los cambios de código:
\nUna vez que el contexto se convierte en un artefacto, se vuelve gobernable.
\nNecesitas ambas:
\nNo son lo mismo.
\nQuiero saber:
\nSi no puedes responder a esas preguntas, todavía estás depurando prompts en la oscuridad.
\nSi estás tratando de evaluar dónde se encuentra tu propio sistema, este modelo de madurez es más útil que las definiciones abstractas.
\nTienes un prompt del sistema, un mensaje de usuario y tal vez un par de ejemplos.
\nEsto puede funcionar sorprendentemente bien para tareas estrechas. Se rompe rápidamente cuando la tarea requiere conocimiento fresco, persistencia o herramientas.
\nAñades documentos en tiempo de ejecución.
\nAquí es donde muchos equipos se detienen. También es donde muchos equipos comienzan a ver las limitaciones de la fragmentación ingenua, la clasificación y la hinchazón del contexto.
\nAhora gestionas el historial, los resultados de las herramientas, la memoria y el formato de manera intencional.
\nEste 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.
\nEl sistema cambia la forma en que construye el contexto según la tarea.
\nPuede:
\nEn este punto, la construcción de contexto es parte de la lógica central de la aplicación.
\nEl sistema trata el contexto como una superficie de ingeniería de primera clase.
\nTiene:
\nHacia aquí se dirigen los sistemas de producción más sólidos.
\nSi tuviera que reducir toda la disciplina a una lista de verificación, se vería así:
\nNada de esto es glamoroso. Es exactamente por eso que importa.
\nLa ingeniería de prompts se volvió popular porque sonaba a un atajo.
\nLa ingeniería de contexto importa porque describe el trabajo real.
\nEl centro de gravedad en la IA se está moviendo.
\nLa pregunta de frontera solía ser: ¿Qué tan inteligente es el modelo?
\nLa pregunta aplicada es cada vez más: ¿Qué puede ver el modelo antes de tener que actuar?
\nEse es un problema de ingeniería diferente. Se trata menos de prompts individuales y más de diseño de sistemas. Menos de redacción y más de flujo de información. Menos de la calidad de la salida de una sola vez y más de si un agente puede mantenerse confiable a lo largo del tiempo.
\nPor eso la ingeniería de contexto va a seguir creciendo como disciplina. Cuanto mejores sean los modelos, más se parecerán los fallos restantes a fallos de contexto. Estado faltante. Herramienta incorrecta. Mala recuperación. Historial inflado. Formato deficiente. Evidencia contradictoria. Memoria débil. Bucles sin límite.
\nLa ironía es que esto hace que los sistemas de IA se sientan más como software clásico, no menos. Hemos vuelto a construir tuberías, 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.
\nEl nombre puede ser nuevo. La dirección no lo es.
\nLos sistemas de IA confiables serán construidos por equipos que traten el contexto como una superficie de producto de primera clase.
\nTodos los demás seguirán llamando al modelo poco fiable.
\nReferencias:
\n[1] Simon Willison. (2025, 27 de junio). Context engineering.
\n[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
\n[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
\n[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
\n[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
\n[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
\n\n[8] LangChain. (2025, 23 de junio). The rise of \"context engineering\".
\n[9] Anthropic. How to implement tool use.
\n[10] Jason Liu. (2025, 27 de agosto). Beyond Chunks: Why Context Engineering is the Future of RAG.
\n\n[12] Anthropic. Long context prompting tips.
\n\n\n[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
\n[16] Anthropic. (2025, 13 de junio). How we built our multi-agent research system.
\n[17] LangChain. (2025, 2 de julio). Context Engineering.
\n[18] Anthropic. (2025, 29 de septiembre). Managing context on the Claude Developer Platform.
\n\n[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
\n[21] Mintlify. (2026, 24 de marzo). How we built a virtual filesystem for our Assistant.
\n[22] Turso. AgentFS.
\n[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
\n[24] TrustGraph. The context development platform.
\n[25] TrustGraph. Working with Context Cores.
\n[26] Gupta, J., y Garg, A. (2025, 22 de diciembre). AI’s trillion-dollar opportunity: Context graphs.
\n[27] Garg, A. (2026, 16 de enero). Why context graphs are the missing layer for AI.
\n", "source_hash": "sha256:3f3faa38dd809a893509e9f3c2de70a7ec3778cc6cef2fa58967b63bd169d7d9", "model": "deepseek/deepseek-v4-flash", "generated_at": "2026-08-07T08:10:54.510471+00:00" }