El coste oculto de un agente no está solo en la respuesta. Está en todo lo que necesita leer antes de responder.
Cuando una empresa calcula el coste de un agente, suele empezar por el modelo: cuántos tokens consume, cuánto cuesta cada millón de tokens, cuántas llamadas hará al día y qué volumen de usuarios tendrá. Es lógico. Pero se queda corto.
Un agente empresarial no recibe solo una pregunta. Recibe también instrucciones, definiciones de herramientas, documentos recuperados, fragmentos de bases de conocimiento, memoria, historial de conversación y, en muchos casos, información de sistemas como ERP, CRM, SharePoint, OneLake o aplicaciones internas. Todo eso ocupa contexto. Y gran parte vuelve a enviarse al modelo en cada turno.
Microsoft lo resume con una idea especialmente relevante para producción: el contexto puede convertirse en una de las mayores partidas de coste operativo de un agente multietapa. Pero además tiene un segundo efecto: demasiado contexto puede empeorar la calidad. Un dato importante enterrado entre decenas de páginas compite con ruido. Una lista enorme de herramientas aumenta las posibilidades de elegir mal. Y cada error puede generar nuevas llamadas, nuevos pasos y más consumo.
Prompt engineering mejora cómo se formula una instrucción. Context engineering decide qué información, herramientas, procedimientos y memoria entran en la ventana de contexto para resolver mejor una tarea.
Cuatro decisiones que determinan cuánto sabe, cuánto hace, cuánto recuerda y cuánto cuesta un agente
Microsoft estructura esta disciplina alrededor de cuatro preguntas. Son técnicas, sí, pero deberían entrar también en cualquier conversación de arquitectura, gobierno y retorno.
Recuperar evidencia relevante, no volcar documentos enteros
El patrón más simple de RAG consiste en buscar contenido y meterlo en el prompt. Funciona, pero puede acabar introduciendo fragmentos demasiado amplios, repetidos o poco relevantes. El modelo paga por leerlos igualmente.
La alternativa es una capa de conocimiento que planifique la recuperación, divida la consulta, busque en distintas fuentes, reordene resultados y entregue solo la evidencia útil. Ahí encajan Azure AI Search, RAG empresarial y Foundry IQ.
No exponer veinte herramientas cuando solo necesitas dos
Cada herramienta necesita una descripción para que el agente sepa cuándo utilizarla. Si el agente carga siempre el catálogo completo de APIs, conectores y acciones, esa descripción viaja una y otra vez dentro del contexto.
Microsoft Foundry Toolboxes introduce un enfoque más limpio: el agente descubre las herramientas relevantes cuando las necesita, en lugar de recibir de entrada toda la biblioteca. Esto es especialmente importante cuando conectamos ERP, CRM, Microsoft 365, datos y servicios externos.
Cargar procedimientos solo cuando son necesarios
Un agente de soporte puede necesitar un procedimiento de escalado. Uno financiero, una secuencia de validación. Uno comercial, reglas de cualificación. Si esos procedimientos completos viven dentro de las instrucciones generales, se pagan incluso cuando la tarea no los necesita.
La lógica de skills permite encapsular procesos reutilizables y cargarlos bajo demanda. Esto reduce repetición y, al mismo tiempo, facilita gobernar versiones y criterios corporativos.
Memoria útil no significa guardar cada palabra de cada conversación
Reenviar todo el historial para que el agente “recuerde” es una solución cómoda, pero cara. Además, mucha información deja de ser relevante después de unos pocos turnos.
Una memoria bien diseñada conserva hechos, preferencias y patrones que aportan continuidad, y aplica retención, aislamiento y caducidad. Esto afecta directamente a coste, privacidad y comportamiento futuro.
Microsoft ya está midiendo cuánto puede cambiar el coste cuando optimizas el contexto
No son garantías universales para cualquier empresa. Son resultados de evaluaciones y benchmarks concretos de Microsoft. Precisamente por eso conviene leerlos como señales de dirección tecnológica, no como promesas comerciales.
Hasta un 54% más de evidence recall
Microsoft indica que sus evaluaciones internas de Foundry IQ sobre el benchmark BrowseComp-Plus mejoraron la recuperación de evidencia hasta un 54%.
Menor coste de tokens en recuperación
En la misma evaluación, Microsoft reportó una reducción del 34% en el coste de tokens asociado a la recuperación, combinando agentic retrieval, reordenamiento semántico y síntesis más eficiente.
Cuando el agente no necesita cargar la descripción de todas las herramientas, la diferencia puede ser enorme
Microsoft señala que Toolboxes, combinado con tool search, redujo alrededor de un 97% el consumo medio de tokens de entrada en una evaluación sobre un dataset público de recuperación de herramientas. No significa que cualquier proyecto vaya a ahorrar un 97%. Sí demuestra que el catálogo de herramientas puede convertirse en una partida de contexto muy relevante cuando el agente crece.
Dos agentes pueden hacer la misma tarea y tener una economía completamente distinta
Imagina un agente comercial conectado al CRM. Recibe la pregunta: “Prepárame la reunión con este cliente y dime qué oportunidades abiertas, incidencias y pedidos debo conocer”.
El primer diseño envía al modelo instrucciones generales de veinte páginas, expone todos los conectores disponibles, recupera el historial comercial completo, incluye decenas de documentos y vuelve a mandar la conversación entera en cada turno. Puede funcionar. Pero cada pregunta lleva una mochila enorme.
El segundo diseño identifica que la tarea necesita solo cuatro cosas: perfil del cliente, oportunidades, incidencias relevantes y pedidos recientes. Recupera únicamente esa evidencia, ofrece al agente solo las herramientas necesarias y conserva en memoria los datos persistentes realmente útiles. El objetivo final es el mismo. La economía de ejecución no.
Seis síntomas de que tu agente está utilizando demasiado contexto
1. Recupera documentos completos para responder a una pregunta de dos líneas
Si la evidencia útil está en tres párrafos, enviar cuarenta páginas aumenta tokens y obliga al modelo a separar señal de ruido.
2. Expone siempre todos los conectores y acciones posibles
El agente necesita entender la descripción de cada herramienta. Una biblioteca grande puede convertirse en coste recurrente incluso cuando casi ninguna herramienta se utiliza.
3. Arrastra toda la conversación para mantener memoria
Lo útil de una conversación puede reducirse a unos pocos hechos persistentes. Reenviar todo el diálogo no es memoria sofisticada; es contexto acumulado.
4. Repite políticas y procedimientos extensos en cada petición
Si una regla solo aplica a una excepción, no debería cargar siempre. Las skills reutilizables ayudan a separar conocimiento general de procedimientos bajo demanda.
5. Necesita demasiados turnos para corregir decisiones equivocadas
El coste no es solo el primer prompt. Una mala selección de herramienta o una recuperación pobre genera pasos adicionales y multiplica consumo.
6. Nadie sabe explicar qué parte del contexto aporta valor
Si el diseño se resume en “le pasamos todo porque puede necesitarlo”, falta arquitectura. La observabilidad debe permitir saber qué se recuperó, qué se utilizó y qué no.
Un agente barato en una demo puede convertirse en un agente caro cuando escala
El contexto que apenas importa con veinte usuarios empieza a importar muchísimo cuando una solución trabaja miles de veces al día, ejecuta tareas multietapa y conecta varias fuentes empresariales.
El objetivo es demostrar que la experiencia funciona
Pocos usuarios, pocas herramientas, datos controlados y volumen pequeño. Es normal priorizar velocidad de aprendizaje sobre optimización extrema.
El objetivo es que funcione bien miles de veces con coste controlado
Aquí importan latencia, recuperación, memoria, permisos, herramientas, observabilidad, fallos, retries, modelos y economía por tarea. Lo que era irrelevante a escala pequeña empieza a multiplicarse.
La métrica que conviene incorporar: coste por resultado, no solo coste por token
Un agente puede consumir pocos tokens y fallar a menudo. Otro puede consumir algo más y completar la tarea en menos pasos. El coste unitario del modelo no explica por sí solo qué arquitectura es más eficiente.
Por eso merece la pena conectar consumo con indicadores operativos: coste por caso resuelto, coste por documento validado, coste por oportunidad preparada, coste por incidencia cerrada, coste por pedido procesado o coste por tarea completada correctamente. Esa lógica enlaza directamente con una visión más amplia de coste real de la IA empresarial y con la guía específica de cuánto cuesta un agente de IA.
Cinco preguntas para revisar un agente antes de escalarlo
¿Qué información entra en cada turno y cuánta termina siendo útil?
Mide documentos recuperados, tamaño del contexto, repeticiones y evidencia realmente utilizada por el agente.
¿Qué herramientas necesita conocer para cada tipo de tarea?
No diseñes el catálogo de herramientas como una mochila permanente. Diseña descubrimiento, selección y permisos por contexto.
¿Qué procedimiento debe cargarse y cuándo?
Convierte reglas extensas en skills o componentes reutilizables y evita incluir procesos completos en cada interacción.
¿Qué debe recordar de verdad?
Diferencia memoria de sesión, preferencias persistentes y aprendizaje de procedimientos. Define también qué debe caducar.
¿Cuánto cuesta completar bien la tarea y qué valor devuelve?
Conecta tokens, latencia, número de pasos, errores y retries con una métrica empresarial. Sin esa relación, optimizar consumo puede convertirse en una carrera por ahorrar céntimos sin saber si el agente genera valor.
Conocimiento empresarial compartido, recuperado con permisos y preparado para varios agentes
Foundry IQ plantea una base de conocimiento que puede conectarse a distintas fuentes y ser reutilizada por varios agentes. La recuperación puede apoyarse en contenido de SharePoint, OneLake, Azure Blob Storage, Azure SQL y otras fuentes del ecosistema Microsoft.
La ventaja no es únicamente tecnológica. Una capa de conocimiento común evita que cada equipo construya su propio RAG, sus propios conectores, sus propios permisos y su propia lógica de recuperación. Eso reduce duplicidad y facilita gobernar el dato que entra en los agentes. Puedes ampliar esta parte en Azure AI para empresas.
El reto real empieza cuando el agente necesita entender negocio y actuar sobre sistemas reales
Un agente empresarial útil rara vez vive aislado. Necesita consultar CRM, ERP, documentos, Microsoft 365, Fabric, aplicaciones propias y procesos operativos. Y cada conexión introduce permisos, datos, excepciones, reglas, observabilidad y coste.
Ahí tiene sentido un enfoque de arquitectura extremo a extremo: identificar el caso de uso, decidir qué plataforma debe resolverlo, preparar datos, conectar sistemas y diseñar gobierno. Ese es también el enfoque del hub de IA empresarial Microsoft Cloud.
El coste de un agente se construye por capas, y el contexto atraviesa casi todas
Optimizar contexto no significa obsesionarse con unos cuantos tokens. Significa entender dónde se multiplica el consumo y qué decisiones de arquitectura afectan al coste total de una tarea empresarial.
Precio por entrada, salida y capacidad de razonamiento
Es la partida más visible porque tiene tarifa. Pero el modelo no trabaja en el vacío. Un modelo más barato puede salir caro si necesita muchos más pasos para completar la tarea, si falla más al elegir herramientas o si obliga a ampliar el contexto para compensar una peor comprensión. La comparación correcta debe hacerse por resultado completo, no por una llamada aislada.
Buscar también cuesta, pero buscar mal cuesta dos veces
Una arquitectura RAG tiene coste de búsqueda, procesamiento y tokens. Si recupera contenido irrelevante, pagas por encontrarlo y después vuelves a pagar por enviarlo al modelo. Si además provoca una respuesta incorrecta, aparecen nuevos turnos de recuperación, validación o corrección. Por eso la calidad de retrieval es una variable económica, no solo de precisión.
Cada acción disponible añade descripción, permisos y riesgo
Un agente que consulta una base documental es relativamente sencillo. Un agente que además puede leer clientes, crear oportunidades, consultar pedidos, lanzar aprobaciones, generar documentos y actuar sobre ERP necesita más herramientas. Esa riqueza aumenta valor, pero también contexto, autenticación, pruebas y observabilidad. La respuesta no es eliminar capacidades, sino descubrirlas cuando son necesarias.
Retries, trazas, validaciones y escalados también forman parte de la factura
Cuando el agente falla, suele repetirse alguna etapa. Cuando la tarea es sensible, quizá necesite validación humana. Cuando actúa sobre negocio, hace falta trazabilidad. Todo eso es correcto y necesario, pero debe diseñarse. Un agente con contexto limpio y herramientas bien seleccionadas tiende a reducir decisiones erróneas que después obligan a gastar más para recuperarse.
Una fórmula conceptual útil: coste por tarea = contexto + modelo + herramientas + recuperación + errores + operación
No pretende sustituir un modelo financiero detallado. Sirve para recordar que una optimización centrada exclusivamente en precio por token puede ignorar la parte más costosa del sistema. En producción, una mejora pequeña en cada turno puede convertirse en una diferencia muy relevante cuando se multiplica por miles de tareas, usuarios y días.
El mismo principio cambia mucho según el tipo de agente
Context engineering no es una receta única. La estrategia correcta depende de la tarea, del dato y del riesgo de negocio.
Preparar una reunión comercial sin leer toda la vida del cliente
Para preparar una reunión, probablemente interesen las oportunidades activas, últimas interacciones, incidencias críticas, contratos vigentes y cambios recientes. No hace falta cargar cada correo de los últimos seis años ni cada oportunidad cerrada. El agente debe recuperar una fotografía relevante del momento y poder profundizar si la conversación lo exige.
Aquí el valor está en combinar CRM, Microsoft 365 y, si aplica, ERP. El contexto se vuelve una selección dinámica orientada a la decisión comercial.
Analizar una desviación sin enviar el ERP entero al modelo
Un agente financiero puede necesitar cifras de presupuesto, real, histórico comparable, centros de coste y una explicación de eventos relevantes. No necesita conocer todos los maestros, diarios y documentos de la organización para responder a una variación concreta.
La arquitectura debe recuperar datos estructurados, conservar trazabilidad y limitar el contexto al perímetro autorizado. En este escenario, precisión y control importan más que una respuesta larga.
Resolver una incidencia con conocimiento técnico realmente aplicable
Un agente de soporte no mejora porque le entregues toda la documentación corporativa. Mejora cuando identifica producto, versión, síntoma, severidad y contexto del cliente, y recupera procedimientos o casos anteriores que encajan con ese patrón.
Aquí la calidad de clasificación inicial y la recuperación de evidencia tienen impacto directo en tiempo de resolución, número de escalados y coste operativo.
Tomar una acción segura exige menos ruido y más reglas claras
Cuando el agente puede crear pedidos, proponer compras, actualizar registros o iniciar aprobaciones, cada decisión importa. El contexto debe reunir datos vigentes, reglas aplicables y herramientas autorizadas para esa tarea concreta.
Un catálogo enorme de acciones aumenta flexibilidad, pero también riesgo. La mejor arquitectura limita el espacio de decisión sin limitar el resultado de negocio.
Menos contexto también puede significar menos exposición de información sensible
La reducción de contexto no es solo una medida de ahorro. Si un agente recupera información siguiendo identidad y permisos, y limita la evidencia a lo necesario para la tarea, disminuye también la superficie de datos que viaja por cada interacción.
Esto importa en entornos con información comercial, financiera, personal, contractual o regulada. El diseño debe decidir no solo qué sabe el agente, sino qué puede saber cada usuario y durante cuánto tiempo debe conservarse.
Microsoft señala que Foundry IQ puede operar con identidad de Microsoft Entra y respetar controles de acceso y etiquetas de sensibilidad de Microsoft Purview en fuentes compatibles. La economía del agente y la seguridad empiezan a converger en la misma decisión: recuperar exactamente lo necesario.
Contexto, permisos, memoria y herramientas necesitan propietario
El conocimiento corporativo cambia. Las APIs cambian. Las políticas cambian. Los usuarios cambian de función. Un agente que se diseñó bien en el piloto puede degradarse si nadie mantiene sus fuentes, skills, herramientas o reglas de memoria.
Por eso conviene definir responsables de conocimiento, seguridad, plataforma y proceso de negocio. También establecer qué versiones de herramientas están aprobadas, qué fuentes son autoritativas, qué retención aplica y cómo se evalúa periódicamente la calidad.
La industrialización de agentes no consiste en “soltar” un modelo. Consiste en operar un sistema que combina software, datos, conocimiento y decisiones. El context engineering debe evolucionar con ese sistema.
Cómo pasar de “el agente funciona” a “el agente funciona con una economía controlada”
Medir antes de optimizar
Instrumenta consumo por tarea, tamaño de contexto, documentos recuperados, llamadas de herramientas, latencia, errores y tasa de éxito. Identifica qué tareas concentran coste y dónde aparecen repeticiones. Sin baseline, cualquier optimización se convierte en opinión.
Optimizar las dos o tres palancas con más impacto
Puede ser mejorar retrieval, reducir herramientas expuestas, separar instrucciones en skills o sustituir historial completo por memoria estructurada. No cambies todo a la vez. Evalúa calidad y coste después de cada ajuste para evitar ahorros que deterioren el resultado.
Convertir el aprendizaje en estándar de arquitectura
Documenta patrones reutilizables: cómo se recupera conocimiento, cómo se publica una herramienta, cómo se define una skill, qué memoria está permitida, cómo se prueban cambios y qué KPIs debe cumplir un agente antes de escalar. El objetivo no es optimizar un agente. Es evitar repetir el mismo error en los siguientes diez.
Optimizar contexto no consiste en recortar información a ciegas
El objetivo es eliminar ruido sin perder evidencia, control ni capacidad de resolver la tarea. Estas son cuatro formas bastante eficaces de estropear una optimización.
Recortar tanto que el agente pierde contexto esencial
Un agente que no recibe el contrato vigente, la política aplicable o el estado real del pedido puede consumir menos y equivocarse más. La optimización debe medirse contra calidad, no solo contra tokens.
Cambiar de modelo antes de entender dónde está el desperdicio
Si el 70% del contexto es irrelevante, un modelo más barato seguirá procesando información innecesaria. Primero conviene observar retrieval, herramientas, memoria e instrucciones. Después comparar modelos con una carga ya razonable.
Optimizar solo el coste medio y olvidar los casos extremos
Las tareas complejas pueden concentrar la mayor parte del consumo: expedientes largos, consultas multietapa, tool calls encadenadas o recuperación sobre muchas fuentes. Mirar solo el promedio puede ocultar exactamente los flujos que hacen inviable la economía del sistema.
Ahorrar tokens sin medir si el negocio recibe mejores resultados
Una reducción del 20% en consumo es irrelevante si baja la tasa de resolución o aumenta la revisión humana. El objetivo es encontrar el punto donde coste, calidad, velocidad y riesgo se equilibran alrededor de una métrica empresarial concreta.
Si estás trabajando agentes, estas páginas completan el mapa
Context engineering, costes y agentes: lo esencial antes de escalar
¿Qué es context engineering en IA?
Es el diseño de la información que un modelo recibe para resolver una tarea: instrucciones, conocimiento recuperado, herramientas disponibles, procedimientos y memoria. El objetivo es aportar contexto suficiente y relevante sin introducir ruido innecesario.
¿Es lo mismo que prompt engineering?
No. El prompt forma parte del contexto, pero no es todo el contexto. Un agente empresarial también recibe herramientas, resultados de búsquedas, datos, memoria y reglas que condicionan su comportamiento y su coste.
¿Más contexto siempre mejora la respuesta?
No. Microsoft advierte de que demasiado contenido puede dificultar que el modelo identifique lo relevante. En recuperación y herramientas, más no significa necesariamente mejor. La precisión depende de la calidad y pertinencia del contexto.
¿Optimizar contexto puede reducir el coste de un agente?
Sí, porque reduce tokens innecesarios y puede disminuir errores, pasos adicionales y llamadas repetidas. El ahorro real depende de la arquitectura, el modelo, el volumen, las fuentes y el patrón de uso.
¿Foundry IQ sustituye a Azure AI Search?
No debe plantearse así. Foundry IQ utiliza capacidades de recuperación y conocimiento dentro de Microsoft Foundry, y Azure AI Search sigue siendo una pieza clave para búsqueda y agentic retrieval. La arquitectura concreta depende de fuentes, seguridad y necesidades de recuperación.
¿Qué debería medir una empresa además de tokens?
Latencia, precisión, tasa de éxito, número de pasos, errores, retries, uso de herramientas, calidad de recuperación, coste por tarea completada y valor de negocio generado. El objetivo no es usar menos IA, sino usarla de forma más eficiente.
La economía de los agentes ya se está convirtiendo en una disciplina propia
Microsoft ha publicado una serie específica, The Economics of Agent Optimization, centrada en cómo pasar de pilotos a sistemas de IA gestionados como inversión. La entrega sobre context engineering insiste en revisar qué entra en la ventana de contexto en cada turno antes de culpar al modelo del coste o de la calidad.
La pregunta ya no es solo qué modelo usar. Es qué contexto merece pagar tu empresa.
La IA empresarial está entrando en una etapa menos espectacular y bastante más importante: optimizar cómo funciona cuando deja de ser una demo. Ahí aparecen cuestiones como recuperación, herramientas, skills, memoria, permisos, observabilidad y coste por resultado.
Para CIOs y responsables de IA, esa es una buena noticia. Significa que hay margen para mejorar la economía de los agentes sin reducir necesariamente su ambición. Pero exige arquitectura, medición y gobierno. Exactamente lo que diferencia un experimento de una capacidad empresarial.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)