Descubrimiento progresivo de herramientas y observabilidad de agentes a escala

Un agente de operaciones conectado a cinco servidores MCP carga 60 definiciones de herramientas al empezar cada sesión: decenas de miles de tokens antes de que el usuario escriba algo. Las trazas muestran que casi todas las sesiones usan entre tres y cinco herramientas, casi siempre las mismas, y que el agente cada vez elige más seguido una herramienta equivocada con nombre parecido. El trimestre que viene se suman dos servidores más.

El costo del contexto monolítico

Cargar todo de entrada (contexto monolítico, monolithic context) tiene dos costos que crecen con cada herramienta:

• Tokens: las definiciones se pagan en cada pedido, se usen o no.
• Elección: con decenas de herramientas parecidas, la precisión para elegir la correcta baja. Ese es el síntoma más grave, porque no se arregla abaratando tokens.

Si las herramientas sobran o se superponen, primero se quitan o consolidan (lección 1). Esta lección es para cuando todas son legítimas, pero cada sesión usa pocas.

Descubrimiento progresivo

En el descubrimiento progresivo (progressive discovery), el agente arranca con poco y trae lo que necesita cuando lo necesita. En la API de Claude, la búsqueda de herramientas (tool search) lo implementa así:

1. Mandás todas las definiciones, pero marcás con defer_loading las que no tienen que entrar al contexto de entrada.
2. Al principio el modelo ve la herramienta de búsqueda y las no diferidas.
3. Cuando necesita algo, busca en el catálogo (nombres, descripciones y parámetros) y la API carga solo las que coinciden.
4. Dejá siempre cargadas las pocas que se usan en casi todas las sesiones, para que no haga falta buscarlas.

Con servidores MCP conectados por el conector de la API, el diferido se configura por servidor o por herramienta. Y como la búsqueda usa las descripciones, tienen que ser claras y con las palabras que usaría el usuario: recortarlas a una línea empeora la elección.

Opción del escenario	Qué resuelve
Caché sobre las definiciones	Baja el costo de los tokens; la elección entre 60 sigue igual
Descripciones de una línea	Menos tokens y peor elección
Un subagente por herramienta	Multiagente por defecto: más costo y coordinación
Búsqueda de herramientas con las más usadas cargadas	Tokens, elección y escala cuando lleguen más servidores

Observabilidad: ver cada paso

Un agente de reservas atiende 50.000 sesiones por día, cada una con varias llamadas al modelo y a sistemas de disponibilidad, precios y pagos. Hay fallas intermitentes (precios mal cotizados, reservas a medias) y solo se guarda la respuesta final. Repetir la entrada casi siempre funciona. Con eso no se puede saber qué paso falló.

Lo que hace falta son trazas (tracing) por sesión:

• Un span por cada llamada al modelo y por cada llamada a herramienta.
• En cada span: entradas, salidas, tokens, latencia, stop_reason y versión del prompt y del modelo.
• Un identificador de sesión que una todos los pasos.

A esta escala, guardar todo completo es caro. La solución es el muestreo (sampling): una fracción de las sesiones exitosas y todas las que fallan. Si la empresa ya tiene un backend de trazas para sus microservicios, se reutiliza. Y como las trazas contienen datos de clientes, se aplican las mismas reglas de retención y enmascarado que al resto de los logs.

Las trampas típicas

• Caché como solución a un problema de elección de herramientas.
• Recortar descripciones para ahorrar tokens.
• Diferir también las herramientas que se usan en casi todas las sesiones.
• Volcar el prompt completo de cada pedido a la salida estándar, sin estructura.
• Pedirles a los clientes que describan qué pasó.
• Reproducir a mano fallas intermitentes que al repetir la entrada no aparecen.

En el examen

Si el escenario cuenta muchas herramientas cargadas, pocas usadas por sesión y elecciones equivocadas, buscá la búsqueda de herramientas con las más usadas siempre cargadas; la mención de “más servidores el próximo trimestre” refuerza esa respuesta. Si describe un agente de varios pasos con fallas que no se pueden diagnosticar, buscá trazas con un span por llamada, muestreo de éxitos y todas las fallas guardadas. Descartá las opciones que solo abaratan o que dependen del relato de alguien.