¡Hola Devs! La factura más grande de tu agente es la que no ves
Todo agente tiene un mecanismo que decide qué ve el modelo en cada turno. En la mayoría de los sistemas en producción, esa decisión se congeló durante el prototipo y nunca se revisó. Eso es un problema, porque normalmente ahí vive la mayor parte del costo operativo — y, silenciosamente, buena parte de las respuestas decepcionantes.
Fíjate en el detalle: esta es la única parte del agente que mejora sola. El modelo sigue igual de capaz que el día que lo elegiste. Las instrucciones solo cambian cuando alguien las reescribe. Pero lo que el agente sabe, a lo que puede acceder y lo que recuerda crece mientras corre. Gestionar ese crecimiento es lo que llamamos ingeniería de contexto.
Un modelo no tiene memoria propia. En cada turno, la ventana de contexto le entrega todo lo que puede usar: instrucciones, herramientas, documentos recuperados, historial de la conversación. Cuando el turno termina, todo eso desaparece y hay que reenviarlo en el siguiente. Para un chatbot respondiendo una pregunta, está bien. Para un agente trabajando decenas de turnos detrás de un resultado, se vuelve el gasto más grande — y el contenido innecesario se cobra una y otra vez.
El costo menos obvio es el de calidad. Más contexto no significa mejores respuestas. Un dato relevante enterrado en 40 páginas es más difícil de usar, y una lista de herramientas gigante hace más probable que el modelo elija la equivocada. Cada error agrega turnos — y costo — para recuperarse. A diferencia de cambiar a un modelo más barato (que sacrifica calidad) o acortar instrucciones (que puede debilitar la respuesta), quitar contexto innecesario baja el costo sin bajar la calidad. Por eso es la optimización más fácil de defender internamente.
(Contexto original: the economics of agent optimization)
Las cuatro preguntas que definen la ingeniería de contexto
La ingeniería de contexto no es una decisión de diseño que tomas una vez — practicada continuamente, es así como el agente mejora, porque cada turno revela lo que realmente usó. Cuatro preguntas cubren el trabajo, y la mayoría de los equipos las ataca en este orden.
1. ¿Qué debería saber el agente?
Muchos equipos empiezan con búsquedas amplias que meten documentos enteros al prompt. Fácil de construir, caro de correr. Una capa gestionada de conocimiento resuelve esto descomponiendo la query en subqueries, buscando fuentes en paralelo, haciendo reranking semántico y devolviendo solo pasajes fundamentados con citas. En benchmarks internos sobre BrowseComp-Plus, este enfoque mejoró el recall de evidencia hasta un 54% y redujo el costo de tokens de recuperación en un 34%.
2. ¿A qué debería poder llegar el agente?
El overhead de herramientas es traicionero. Agregar una herramienta es una línea de código, pero su descripción completa viaja en el prompt en cada turno — se necesite o no. Cuando la toolbox crece a cientos de herramientas, ese impuesto de descripción domina la cuenta. La solución es tool search: en lugar de exponer la lista completa, el modelo recibe una forma de describir en lenguaje natural lo que necesita, y una forma de llamar lo que regrese. El costo de la lista de herramientas se mantiene plano, sin importar cuán grande sea la toolbox.
# Ingenuo: cada descripción de herramienta se envía en cada turno
tools = [search_tool, code_tool, sql_tool, ...] # 200+ herramientas
response = model.chat(prompt, tools=tools) # 💸 impuesto completo en cada llamada
# Mejor: expone una sola entrada de tool-search
tool_search = {
"name": "find_tool",
"description": "Describe en lenguaje natural la capacidad que necesitas."
}
response = model.chat(prompt, tools=[tool_search])
# El modelo pide una capacidad, tú la resuelves del lado del servidor,
# y solo el schema de la herramienta elegida entra en el siguiente turno.
En un benchmark interno contra un dataset público de tool-retrieval, el consumo promedio de tokens de entrada cayó alrededor del 97% en bibliotecas grandes — impacto directo en el costo de inferencia.
3. ¿Cómo debería hacer el trabajo el agente?
Conocimiento y herramientas cubren qué encuentra y hace el agente. Ninguno de los dos cubre cómo espera tu empresa que se haga el trabajo — la ruta de escalamiento que sigue un agente de soporte, el checklist que aplica una revisión de código. Esa guía normalmente vive en las instrucciones, se copia y pega entre agentes, y viaja en cada request aunque sea irrelevante. La solución es una skill: un procedimiento nombrado, gestionado centralmente, que el agente solo carga cuando es relevante. Primero ve el nombre y una descripción corta; las instrucciones completas se cargan bajo demanda.
Qué debería recordar el agente — y los límites de todo esto
Los agentes necesitan continuidad, pero no necesitan cargar cada detalle de cada interacción. Reenviar la conversación completa al modelo agrega costo y quema contexto, incluso cuando solo unos pocos detalles siguen importando. Un modelo práctico de memoria se divide en tres capas:
- Memoria de sesión — la conversación actual.
- Memoria de usuario — preferencias y hechos que persisten entre sesiones.
- Memoria procedural — flujos aprendidos y patrones de ejecución de tareas.
La memoria procedural complementa muy bien a las skills gestionadas centralmente: la skill define el procedimiento aprobado, mientras que la memoria procedural deja que el agente aprenda de su propia ejecución. En evaluaciones internas, habilitar memoria procedural produjo cerca de 5% de mejora en STATE-Bench y Tau-Bench.
⚠️ Dónde se pone difícil
La ingeniería de contexto no es comida gratis. Algunas advertencias honestas:
- Necesitas observabilidad primero. No puedes podar lo que no ves. Si no logueas qué entra en la ventana de contexto en cada turno, estás adivinando.
- La calidad del retrieval es un techo. Si tu base de conocimiento está desactualizada o el reranker es débil, ninguna poda salva la calidad de la respuesta.
- La memoria es una superficie de compliance. La memoria de usuario y la procedural almacenan datos. Políticas de retención, TTL y aislamiento por usuario no son opcionales — son el precio de entrada en industrias reguladas.
- El lock-in de vendor es real. Las capas gestionadas de conocimiento, toolboxes y servicios de memoria son convenientes, pero diseña tu agente para que retrieval, herramientas y memoria sean intercambiables detrás de interfaces. Frameworks como LangGraph, Microsoft Agent Framework, GitHub Copilot SDK y Claude Agent SDK son objetivos razonables — no acoples tu lógica de negocio al SDK de un solo vendor.
- Los benchmarks son direccionales, no promesas. Una reducción del 97% de tokens en un dataset público de tool-retrieval es señal, no garantía. Mide en tu carga de trabajo.
Próximos pasos para estudiar
- Perfila un agente en producción: loguea el desglose de tokens entre instrucciones, herramientas, docs recuperados e historial por turno. La rebanada más grande es tu primer objetivo.
- Cambia listas estáticas de herramientas por tool-search en cualquier agente con más de ~20 herramientas.
- Saca procedimientos repetidos de las instrucciones y mételos en skills versionadas y gestionadas centralmente.
- Agrega memoria de sesión/usuario solo después de tener políticas de retención y TTL en su lugar.
- Estudia agentic retrieval y reranking semántico — son las dos palancas más grandes del lado del conocimiento.
Conclusión
La ingeniería de contexto no se trata de encoger el prompt. Se trata de construir agentes que se vuelven mejores con el uso. Cuando el conocimiento que jalan, las herramientas que descubren, los procedimientos que siguen y las memorias que retienen mejoran con el tiempo, el agente se vuelve más capaz y más eficiente — sin rebuild.
El consejo práctico para cualquier equipo que está poniendo agentes en producción: antes de cambiar de modelo o reescribir prompts, mira qué entra en la ventana de contexto en cada turno. En la mayoría de los sistemas en producción, ahí se está yendo el dinero.