El agente de Postman empeoró al ver unas 40 herramientas. Su solución trata la elección como una búsqueda

Si se le dan más herramientas a un modelo capaz, debería poder hacer más. Postman comprobó lo contrario a partir de cierto punto: “En las pruebas de Postman, los errores de selección de herramientas aumentaron cuando el conjunto visible superó aproximadamente las 40 herramientas.”

El dato procede de un artículo del 9 de octubre en el AWS Machine Learning Blog, firmado por Srinivas Kini, del equipo de IA de Postman, y Shubham Gupta, de AWS, que describe cómo funciona Agent Mode sobre Amazon Bedrock dentro de una plataforma para desarrolladores con once años de producto a sus espaldas. Los errores tenían un patrón reconocible: llamadas a herramientas inexistentes, argumentos incorrectos y herramientas que parecían correctas pero no lo eran en ese contexto.

Cada herramienta forma parte del prompt

La definición de una herramienta es texto que el modelo lee en cada turno: un nombre, una descripción, un esquema de parámetros. Cuarenta de ellas compiten por la atención del modelo, muchas con descripciones que se solapan. El modelo no está fallando al razonar; está eligiendo en un menú que se ha vuelto demasiado largo para leerlo con cuidado.

La respuesta de Postman fue dejar de mostrar el menú completo. Un agente raíz consulta una base de datos vectorial de embeddings de herramientas y, en palabras del artículo, “reduce más de 170 herramientas a aproximadamente 15 relevantes para la solicitud”. Después entrega esas herramientas a un subagente cuyo contexto está aislado para esa tarea, de modo que el modelo solo ve lo que la tarea necesita.

1. Petición del desarrollador
2. El agente raíz busca en los embeddings de herramientas
3. Unas 15 de más de 170 herramientas seleccionadas
4. Un subagente aislado trabaja la tarea
5. Aprobación del usuario antes de cualquier cambio de estado

• Herramientas reducidas por tarea: El agente raíz busca en los embeddings de herramientas · Unas 15 de más de 170 herramientas seleccionadas · Un subagente aislado trabaja la tarea

SolicitudSelección y aislamiento de contexto

Menos herramientas, pero mejores

El segundo cambio fue menos vistoso. Para el API Catalog, Postman había creado varias herramientas estrechas, cada una para un tipo de pregunta. Las fusionó en una sola herramienta de consulta que permite al agente escribir consultas con joins y filtros sobre los esquemas en ClickHouse. En la práctica, el equipo cambió muchas herramientas por pregunta por una interfaz de datos bien modelada.

Ese intercambio se puede generalizar. Los equipos que exponen sistemas internos a agentes suelen crear una herramienta por endpoint de API, porque así están organizados los sistemas. A un agente suele irle mejor con menos herramientas, diseñadas a partir de las preguntas que hace la gente, con el modelo de datos haciendo el trabajo. Vimos la misma economía en la API de conocimiento para desarrolladores de Google: el contexto más barato es el que el agente nunca tiene que cargar.

Controles que viajan con la solicitud

La arquitectura lleva sus controles consigo. “Agent Mode requiere la aprobación del usuario antes de acciones que modifican el estado de la aplicación”, y las herramientas se limitan a cada tarea. Amazon Bedrock Guardrails puede “eliminar la información de identificación personal antes de que llegue al modelo”, una opción que los administradores empresariales activan en Agent Mode.

Dos ajustes de datos merecen atención para quien construye sobre Bedrock. Postman fijó la retención de datos en ninguna para los modelos compatibles, con la advertencia de que “la disponibilidad y el comportamiento dependen del modelo”, así que cada modelo debe verificarse con la documentación vigente. Y Agent Mode usa inferencia entre regiones, donde la elección del perfil es una decisión de residencia de datos: los perfiles geográficos mantienen el enrutamiento dentro de una geografía, como Estados Unidos o la Unión Europea, mientras que los perfiles globales añaden capacidad en los picos, pero no tienen frontera geográfica y solo sirven para cargas sin requisitos de residencia.

Qué copiar y qué no

La cifra de 40 herramientas es una observación de Postman sobre su carga y sus modelos, no una constante universal. El artículo no ofrece cifras de latencia, tasa de error ni costo, y los “40 millones de desarrolladores” del título describen la audiencia de Postman, no usuarios confirmados de Agent Mode. Léalo como un análisis de arquitectura, no como un benchmark.

Lo que se puede trasladar es el método:

• Cuente las herramientas que ve cada agente, por tarea, y haga seguimiento como de cualquier otra configuración. Las listas de herramientas crecen en silencio a medida que los equipos añaden integraciones.
• Mida los errores de selección de herramientas a medida que crece la lista. Su umbral puede ser 25 o 60; solo lo sabrá si mide las llamadas a herramientas equivocadas o inexistentes en sus evaluaciones.
• Seleccione las herramientas antes de que el modelo razone, mediante búsqueda o enrutamiento de tareas, y aísle el contexto de cada subtarea.
• Mantenga la aprobación de escrituras junto a la herramienta, no en el prompt, para que se aplique sean cuales sean las herramientas que devuelva la búsqueda.

Esto también simplifica la gobernanza. Una herramienta que el agente no ve en una tarea es una herramienta que no puede usar mal en esa tarea, una superficie más pequeña y más fácil de probar que el catálogo completo que MCP hace tan fácil de conectar.