El comportamiento de un modelo en cualquier momento es una función de todo lo que hay en su ventana de contexto. Decidir qué entra en esa ventana, instrucciones, retrieval, memoria y herramientas, no es escribir prompts. Es arquitectura, y merece el mismo rigor.
Celestino Salim
Senior Software Engineer
La mayoria de los equipos tratan fine-tuning y RAG como alternativas. No lo son. Son dos puntos en un espectro de context engineering que tambien incluye contexto largo con caching y destilacion. Este es el framework de decision que uso en produccion.
La frase "prompt engineering" hizo daño real. Enmarcó el trabajo como redacción: encuentra la frase mágica, agrega "piensa paso a paso", espolvorea una persona encima. Ese marco tenía sentido cuando una funcionalidad LLM era un string de entrada y un string de salida.
Los agentes terminaron esa era. El comportamiento de un modelo en cualquier momento es una función de todo lo que hay en su ventana de contexto: las instrucciones que cargó, los documentos que el retrieval trajo, la memoria que el sistema decidió arrastrar, las definiciones de herramientas sentadas en el prompt. Decidir qué entra en esa ventana, en qué forma, en qué momento, no es un problema de redacción. Es un problema de diseño de sistemas, y dejé de tratarlo como cualquier otra cosa.
Toda ventana de contexto es un recurso finito, con precio y sensible a la posición. Los tokens cuestan dinero. La atención se degrada en contextos largos. El contenido colocado temprano se comporta distinto del colocado tarde. Llenar la ventana no es gratis aunque quepa.
Eso convierte el ensamblaje de contexto en un problema de asignación de recursos, con la misma forma que la gestión de memoria o el diseño de caches. Qué se admite. Qué se expulsa. Qué se resume en una representación más barata. Qué no puede soltarse nunca. Cuando reviso un sistema de agentes ahora, pido el presupuesto de contexto como antes pedía un query plan: muéstrame qué hay en la ventana en el momento de la decisión, y justifica cada sección.
En cada sistema de agentes que he construido o revisado, la ventana de contexto se alimenta de cuatro subsistemas. Cada uno suele no tener dueño y estar afinado por accidente.
Las reglas permanentes: identidad, restricciones, convenciones, contratos de salida. Las instrucciones son código. Pertenecen al repo, versionadas, revisadas y organizadas en capas deliberadas: una base global, una capa por superficie, un contrato por tarea. En mi propio workspace un solo archivo de instrucciones canónico alimenta a todos los runtimes de agentes, porque dos archivos de instrucciones que divergen producen dos sistemas distintos que comparten nombre.
Todo lo que el sistema busca en tiempo de ejecución porque no podía, o no debía, vivir en las instrucciones permanentes. RAG es la instancia famosa, pero los resultados de herramientas, las lecturas de archivos y las respuestas de APIs también son retrieval. Las preguntas de diseño son preguntas de cadena de suministro: qué fuentes existen, qué tan frescas están, cómo se decide la relevancia y qué demuestra que se trajo lo correcto. El retrieval que no se puede evaluar es decoración.
Lo que persiste entre sesiones. Los agentes lo olvidan todo por defecto, lo que significa que la memoria no es un problema de almacenamiento, es un problema de política de escritura. Las decisiones difíciles son qué vale la pena escribir, en qué forma y cuándo se vuelve a cargar. Yo mantengo la memoria de agentes en archivos versionados con reglas explícitas sobre qué califica, porque un cajón de "aprendizajes" de solo agregar es context rot con mejor nombre.
La parte que la mayoría de los equipos olvida que es contexto. Cada definición de herramienta, su nombre, descripción y schema, ocupa lugar en la ventana y moldea el comportamiento antes de que ocurra llamada alguna. Un catálogo de herramientas inflado es un prompt inflado: gasta presupuesto, diluye la atención e invita a la llamada equivocada. Menos herramientas con descripciones precisas le ganan consistentemente al catálogo completo. Las descripciones de herramientas merecen revisión por la misma razón que los contratos de API: el consumidor no puede leer tus intenciones, solo tu interfaz.
Una vez que ves los cuatro subsistemas, las fallas familiares de agentes dejan de parecer problemas del modelo:
Cada una de estas tiene un arreglo de sistemas. Ninguna tiene un arreglo duradero de truco de prompt. Reformular mueve la falla de lugar como agregar RAM mueve un memory leak.
La declaración a la que siempre vuelvo: los trucos de prompt optimizan un string; el context engineering diseña el pipeline que produce el string. Es el mismo giro que dio la industria cuando dejó de afinar queries a mano y empezó a diseñar schemas, o cuando dejó de desplegar a mano y empezó a construir pipelines. El artefacto deja de ser lo que pules. El sistema que produce el artefacto se convierte en lo que diseñas.
En la práctica, eso significa que el ensamblaje de contexto recibe el tratamiento completo: está versionado, es observable (puedes volcar la ventana exacta que produjo cualquier decisión), está testeado (los evals atrapan regresiones cuando una capa cambia) y tiene dueño. Si no puedes reproducir el contexto que causó una falla, no estás debuggeando, estás adivinando.
Los equipos que internalizan esto dejan de preguntar "qué debería decir el prompt" y empiezan a preguntar "qué debería saber el modelo en este momento, y qué subsistema es responsable de que eso esté ahí". Esa pregunta tiene una respuesta de arquitectura, y arquitectura es algo que ya sabemos hacer bien.
Enseño la versión aplicada, presupuestos, capas, retrieval y políticas de memoria para agentes reales, en la lección Context Engineering for Agents del curso Building AI Agents.