Cómo Postman ejecuta Agent Mode en Amazon Bedrock para 40 millones de desarrolladores

De demo a producción: un problema distinto

Crear un agente de IA para una demostración y mantenerlo operativo para 40 millones de desarrolladores son desafíos ingenieriles muy distintos. Postman diseñó Agent Mode como una forma nativa de trabajar con APIs: pruebas, documentación, descubrimiento e implementación a través de la interacción con un agente que razona sobre datos en lugar de navegar interfaces.

La evolución de Postman a lo largo de 11 años hizo evidente que la experiencia de usuario y las suposiciones implícitas en la interfaz no son triviales de traducir a un agente. Mientras un usuario humano explora sidebars, pestañas y requests, un agente necesita acceso estructurado y predecible a la información y a las acciones que puede ejecutar.

Arquitectura general y por qué usar Amazon Bedrock

Agent Mode corre sobre Amazon Bedrock, que ofrece acceso gestionado a modelos de base (foundation models). Esa decisión responde a necesidades operativas claras: la comunidad global de Postman genera demanda variable y picos de tráfico con requisitos sensibles a la latencia. Bedrock permite escalar la inferencia sin operar infraestructura de modelos propia, a la vez que ofrece flexibilidad en la selección de modelos y control sobre throughput, procesamiento geográfico y costos.

En producción, Postman combina herramientas del lado del cliente, orquestación del agente, contextos diseñados para tareas concretas y la inferencia en Bedrock. Además, el diseño incorpora aprobaciones humanas para cualquier acción que modifique el estado de la aplicación, reduciendo riesgos operativos.

Control humano y privacidad como parte del diseño

Agent Mode exige la aprobación del usuario antes de ejecutar cambios que afecten datos o configuración. Como control responsable, Postman usa Amazon Bedrock Guardrails para redactar información personal identificable (PII) antes de llegar al modelo. Los administradores empresariales pueden habilitar estas protecciones desde la configuración de guardrails del producto.

También aplican políticas de retención de datos dependientes del modelo: algunas integraciones definen cero retención de datos según la política del proveedor de modelos, lo cual es crítico para clientes con requisitos regulatorios o de privacidad.

Manejo de la proliferación de herramientas (tool sprawl)

En Agent Mode las “herramientas” definen las acciones que el agente puede ejecutar dentro de Postman. En iteraciones tempranas el equipo optó por herramientas muy atómicas —abrir un request, actualizar un campo, leer un metadato— porque favorecen precisión y control. Sin embargo, surgieron dos problemas prácticos:

• Muchas tareas reales requieren largas secuencias de llamadas a herramientas. Aunque cada acción fuese rápida, el flujo completo se percibía lento porque siempre había que volver al modelo entre pasos. Los usuarios veían al agente ejecutar pasos que ellos consideraban una sola operación.
• A partir de un punto, exponer demasiadas herramientas degrada la efectividad del agente. Las pruebas de Postman mostraron un aumento de errores de selección cuando el conjunto visible superaba alrededor de 40 herramientas: el agente podía invocar herramientas inexistentes, pasar argumentos incorrectos o elegir operaciones semánticamente plausibles pero erróneas en contexto.

La solución fue tratar el catálogo de herramientas como parte del “presupuesto de contexto”: seleccionar dinámicamente las herramientas relevantes por tarea y encapsular ejecuciones en hilos de contexto aislado. En su arquitectura actual, el agente raíz consulta una base de vectores con embeddings de herramientas y reduce más de 170 herramientas a unas 15 pertinentes para la solicitud, entregando ese subconjunto a un subagente que opera con acceso limitado.

Un problema relacionado era el acoplamiento implícito entre APIs cliente y el estado de la interfaz (por ejemplo, abrir una pestaña para leer un request). Postman está desacoplando herramientas de pestañas y usando funciones nativas como Native Git para permitir que el agente ejecute requests en segundo plano, siempre con la aprobación del usuario cuando corresponde.

Exponer lecturas estructuradas mediante esquemas

Para catálogos de APIs y productos que agregan métricas (uptime, resultados de tests, tiempos de respuesta), Postman consolidó múltiples vistas en una herramienta de consulta única que trabaja con datos estructurados. Dado que las tablas subyacentes (por ejemplo en ClickHouse) tienen esquemas conocidos, el agente puede generar consultas complejas y entender las respuestas en formato estructurado, lo que mejora precisión y reduce ambigüedad respecto a lecturas no estructuradas.

Este enfoque —exponer lecturas basadas en esquemas— favorece que el agente razone sobre datos concretos en lugar de interpretar capturas de pantalla o estados de UI.

El contexto, no la capacidad, como cuello de botella

Una lección recurrente fue considerar el contexto disponible para el modelo como el principal límite para el rendimiento del agente. Exponer más herramientas, datos o histórico no siempre mejora los resultados; lo que importa es seleccionar y proveer el contexto correcto para la tarea en curso. Por eso Agent Mode prioriza el contexto selecto: sólo las herramientas, datos y fragmentos relevantes llegan al modelo en cada interacción.

Complementan esto con técnicas de caching de prompts en múltiples niveles para reducir latencia y costos de inferencia sin sacrificar frescura cuando se requiere.

Lecciones operativas y para equipos en América Latina

Las decisiones de diseño de Postman son útiles para equipos de producto y TI en América Latina que planean desplegar agentes de IA en producción:

• Planifiquen el catálogo de acciones como parte del contexto: menos, pero bien seleccionadas, suelen funcionar mejor que muchas herramientas atómicas.
• Desacoplen las APIs de la UI cuando sea posible; un agente debería poder operar sobre datos sin replicar interacciones visuales.
• Aprovechen lecturas estructuradas y esquemas en sus almacenes de datos para mejorar la precisión de consultas automatizadas.
• Consideren proveedores gestionados como Amazon Bedrock si necesitan escalar inferencia globalmente sin operar clusters de modelos, especialmente cuando el tráfico es variable y sensible a la latencia.
• Implementen controles de privacidad y aprobaciones humanas desde el diseño para cumplir requisitos regulatorios y de confianza empresarial.

Conclusión

Llevar un agente de IA de prototipo a producción implica más que elegir un modelo potente o diseñar prompts. Requiere repensar cómo se exponen herramientas y datos, controlar el presupuesto de contexto, diseñar aprobaciones humanas y aplicar protecciones de privacidad. La implementación de Postman sobre Amazon Bedrock ilustra un conjunto de patrones prácticos —selección dinámica de herramientas, lecturas basadas en esquema, procesamiento geográficamente segmentado y políticas de retención dependientes del modelo— que permiten operar un agente a escala para millones de usuarios. Para equipos en la región, estas lecciones ofrecen una hoja de ruta realista para implementar agentes útiles, seguros y escalables en productos maduros.