PulseFlow Tecnologia
← Insights
·6 min de lectura·brief-ejecutivo·context-engineering·arquitectura·costo
PulseFlow Tecnologia

Context engineering como disciplina de arquitectura

El context engineering no es una técnica de optimización de prompt - es una decisión de arquitectura con impacto directo en el costo, la fiabilidad y la velocidad de un agente en producción. Dos casos reales, documentados por empresas distintas, muestran por qué esto ya no es una discusión técnica de nicho.

El costo real de tratar el contexto como un detalle

Manus documentó que, con Claude Sonnet, un token en caché cuesta $0,30 por millón frente a $3 sin caché - diez veces más caro. Como la proporción promedio entre entrada y salida en producción es de aproximadamente 100 tokens de entrada por cada 1 de salida, decisiones aparentemente pequeñas de contexto (como incluir una marca de tiempo precisa al inicio del prompt) multiplican el costo de toda la operación, porque invalidan el caché de todo lo que viene después. Esto no es optimización marginal - es la diferencia entre un agente económicamente viable a escala y uno que no lo es.

Qué pasa cuando el contexto no se trata como arquitectura

El experimento de harness engineering de OpenAI muestra el lado opuesto: un repositorio entero (~1 millón de líneas, 1.500+ PRs, producido por tres ingenieros conduciendo agentes) solo funcionó porque el contexto - decisiones de arquitectura, convenciones, dominio de negocio - fue diseñado deliberadamente para vivir dentro del propio repositorio, no en conversaciones de Slack que el agente nunca vería. Cuando ese contexto quedaba afuera, era tan invisible para el agente como lo sería para un empleado nuevo el primer día.

Lo que confirman los datos de mercado

La encuesta State of AI Agents, de LangChain, muestra que la mayor preocupación reportada por las empresas con agentes en producción es la calidad de ejecución - con un peso dos veces mayor que cualquier otro factor. Eso es consistente con el argumento central: cuando el contexto está mal diseñado, la respuesta del modelo puede ser técnicamente competente y aun así equivocada para la situación, porque el modelo nunca tuvo acceso a la información correcta, en el momento correcto, con el formato correcto.

Por qué esto es una decisión de arquitectura, no de prompt engineering

El prompt engineering pregunta "cómo formular la instrucción". El context engineering pregunta "qué ve el agente, cuándo lo ve, cuánto cuesta mantener eso, y qué pasa cuando esa información cambia". Son preguntas de arquitectura de sistema - del mismo tipo que se hacen sobre una base de datos o un caché de aplicación —, no preguntas de redacción. Las empresas que tratan el contexto como parte de la arquitectura, con dueños, métricas de costo y revisión periódica, tienden a ser las mismas que logran escalar agentes de un caso de uso aislado a producción real sin que exploten el costo o la calidad.

Qué exige esto del liderazgo técnico

Tratar el context engineering como disciplina de arquitectura significa asignar tiempo de arquitecto para diseñar qué entra en el contexto fijo versus el dinámico, medir el costo de caché como métrica de producto (no solo de infraestructura), y garantizar que las decisiones de negocio importantes no queden atrapadas en canales de comunicación que el agente nunca va a leer.

Fuentes