Ingeniería de Contexto El Truco Oculto Para Bajar el Costo de Tus Agentes de IA Sin Perder Calidad

¡Hola Devs! El mayor costo de tu agente no es el modelo

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 tomó en el prototipo — y nunca se revisó. Eso es un problema, porque el contexto suele ser el mayor gasto operativo de un agente, y además es justo la parte que puede mejorar sola.

El modelo sigue tan capaz como el día que lo elegiste. Las instrucciones solo cambian cuando alguien las reescribe. Pero lo que el agente sabe, puede acceder y recuerda crece mientras corre. Gestionar ese crecimiento se llama ingeniería de contexto.

Los dos costos de los que nadie habla

Costo #1 — el obvio: Un modelo no tiene memoria. En cada turno, la ventana de contexto se reconstruye desde cero: instrucciones, descripciones de herramientas, documentos recuperados, historial de la conversación. Para un chatbot que responde una pregunta, todo bien. Para un agente trabajando en decenas de turnos hacia un resultado, es el gasto dominante. El contenido innecesario se cobra en cada turno.

Costo #2 — el invisible: Más contexto no significa mejores respuestas. Un dato relevante enterrado en 40 páginas es más difícil de usar. Una lista de herramientas inflada aumenta la probabilidad de llamadas equivocadas. Cada error genera otro turno — y otra factura.

Lo que hace atractiva a la ingeniería de contexto: la mayoría de las reducciones de costo implican un tradeoff. ¿Modelo más barato? Menos calidad. ¿Instrucciones más cortas? Respuestas más débiles. Pero quitar contexto innecesario baja el costo sin tocar la calidad. Es un alineamiento raro entre CFO e ingeniería.

Las 4 preguntas que definen la ingeniería de contexto

La ingeniería de contexto responde una pregunta por turno: ¿qué necesita esta petición? — no ¿qué podría necesitar algún día?

1. ¿Qué debe saber el agente?

El enfoque ingenuo: aventar documentos completos al prompt. Fácil de construir, caro de correr.

El enfoque gestionado: una capa de conocimiento que descompone la query en subqueries, busca fuentes en paralelo, hace reranking semántico y devuelve solo pasajes fundamentados con citas.

# Flujo conceptual de una capa de retrieval gestionada
# (estilo Microsoft Foundry IQ — pseudocódigo)

def retrieve_for_agent(user_query: str, caller_identity: str):
    # 1. Descompón la query en subqueries enfocadas
    subqueries = decompose(user_query)

    # 2. Dispara búsqueda en paralelo en las fuentes conectadas
    raw_results = parallel_search(
        subqueries,
        sources=["SharePoint", "OneLake", "Azure SQL", "Blob Storage"],
        identity=caller_identity,  # pasa la identidad del Entra ID
    )

    # 3. Reranking semántico, conserva solo pasajes fundamentados
    ranked = semantic_rerank(raw_results)
    passages = [r for r in ranked if r.is_grounded][:TOP_K]

    # 4. Aplica etiquetas de sensibilidad antes de devolver
    return filter_by_purview_labels(passages)

Dos propiedades hacen que valga la pena construir esta capa una sola vez: una base de conocimiento única puede servir a varios agentes, y el control de acceso se aplica en el momento del retrieval, usando la identidad de quien llamó. El agente solo ve lo que el usuario tiene permiso de ver.

2. ¿A qué debe poder llegar el agente?

El overhead de herramientas se pasa por alto fácil. Agregar una herramienta puede costar una línea de código — pero su descripción completa ocupa el prompt en cada turno, se necesite o no.

Una toolbox gestionada resuelve esto exponiendo un solo endpoint MCP para herramientas nativas (web search, code interpreter, file search) más servidores MCP personalizados, specs OpenAPI y agentes A2A. Más importante: la búsqueda de herramientas invierte la interfaz del modelo — en vez del catálogo completo, el modelo recibe (a) una forma de describir en lenguaje natural qué necesita, y (b) una forma de llamar lo que regrese.

Resultado: el costo de la lista de herramientas queda plano, sin importar qué tan grande crezca la toolbox. En benchmark interno, esto cortó ~97% de los input tokens para librerías grandes.

3. ¿Cómo debe hacer el trabajo el agente?

Conocimiento y herramientas cubren qué encuentra y hace el agente. Ninguno cubre cómo tu empresa espera que se haga — la ruta de escalación, el checklist de review, el paso de compliance.

Esa guía normalmente vive en las instrucciones del agente, se copia entre varios agentes y va en cada petición, incluso cuando es irrelevante.

Las skills convierten esa guía en procedimientos nombrados y reutilizables, almacenados centralmente. El agente ve inicialmente solo el nombre y una descripción corta; carga las instrucciones completas solo cuando son relevantes. Actualiza la skill una vez y todos los agentes que la usan siguen el nuevo procedimiento — sin redeploy, sin cambio de código.

4. ¿Qué debe recordar el agente?

Reenviar la conversación completa en cada turno es caro y desperdiciador. Una capa de memoria bien hecha separa tres cosas:

• Memoria de sesión — la conversación actual
• Memoria de usuario — preferencias y datos persistentes entre sesiones
• Memoria procedural — flujos aprendidos y patrones de ejecución de tareas

La memoria procedural complementa las skills gestionadas centralmente: la skill define el procedimiento aprobado, mientras la memoria procedural deja que el agente aprenda de su propia ejecución. En las evaluaciones de Microsoft, habilitar memoria procedural dio ~5% de mejora en STATE-Bench y Tau-Bench.

Para un caso relacionado sobre ROI medible en IA empresarial, checa esto: Azure Databricks entrega 331% de ROI en menos de 6 meses.

Por qué esto se volvió sistema, no feature

Cualquier equipo puede conectar retrieval, herramientas, skills y memoria. La parte difícil es hacer que todo funcione junto, bajo un solo modelo de permisos, y mantenerlo actualizado conforme la empresa cambia.

Checklist práctico al evaluar un stack de ingeniería de contexto:

Limitaciones y advertencias

• Los números son internos. El 54% de recall, 34% de reducción de tokens y 97% de ahorro en input tokens vienen de evaluaciones de la propia Microsoft. Tómalos como direccionales, no universales.
• Tool search agrega latencia. El modelo tiene que describir qué quiere antes de llamar. Para agentes con pocas herramientas, el round-trip puede no pagarse solo.
• La memoria es superficie de compliance. Memoria procedural y de usuario necesitan políticas de retención, TTL y aislamiento por usuario — si no, creaste un data store paralelo sin darte cuenta.
• Las skills requieren gobernanza. Una skill central de la que todos dependen se vuelve infra crítica. Versiónala, pruébala, ten plan de rollback.

Por dónde seguir

Si construyes agentes hoy, empieza con auditoría — no con reescritura:

1. Loguea qué entra en la ventana de contexto en cada turno por una semana.
2. Rankea inputs por costo de token × frecuencia. Retrieval casi siempre gana.
3. Introduce tool search antes de agregar más herramientas.
4. Extrae un bloque de instrucción repetido a una skill y mide.
5. Empieza con memoria de sesión, luego usuario, procedural al final.

La visión grande: la ingeniería de contexto no es encoger el prompt. Es construir agentes que mejoran con el uso — donde conocimiento, herramientas, skills y memoria evolucionan sin rebuild. Para la vista de hardware de la misma economía, ve nuestro breakdown del acelerador de inferencia Maia 200 de Microsoft.

Conclusión

La ingeniería de contexto es la optimización rara que mejora costo y calidad al mismo tiempo. La mayoría de las palancas fuerzan un tradeoff; esta no.

Los equipos que van a ganar con agentes en los próximos dos años no serán los que tengan el modelo más grande. Serán los que traten la ventana de contexto como un recurso gestionado — auditado, medido y refinado continuamente.

Empieza viendo qué entra en la ventana de contexto en cada turno. En muchos casos, arreglar las entradas rinde más que cambiar el modelo.

Lectura complementaria: The Economics of Agent Optimization — Context Engineering for Enterprise AI Agents.