Postman y la escala de 40 millones de desarrolladores
Postman ha habilitado Agent Mode para su comunidad global de 40 millones de desarrolladores, ejecutándolo sobre Amazon Bedrock. El lanzamiento, descrito en un artículo publicado el 9 de octubre de 2026, aborda la transición desde un prototipo de demostración hasta un sistema productivo que gestiona una demanda variable, latencia sensible y picos de tráfico concentrados. Agent Mode permite a los usuarios interactuar con la plataforma de forma nativa mediante IA: realizar pruebas de APIs, generar documentación, descubrir puntos de acceso e implementar flujos de trabajo sin navegar manualmente por la interfaz.
La decisión de optar por Bedrock responde a la necesidad de escalar sin operar infraestructura propia de inferencia de modelos, conservando al mismo tiempo la flexibilidad en la selección de modelos, el control sobre el rendimiento, el procesamiento geográficamente distribuido entre regiones y la gestión de costes. El sistema está diseñado para que el usuario deba aprobar explícitamente cualquier acción que modifique el estado de la aplicación, y las herramientas disponibles se ajustan a cada tarea mientras se recopila el contexto específico de cada entidad.
Los desafíos arquitectónicos: herramientas, contexto y datos
Integrar un agente en un producto maduro como Postman, que lleva 11 años evolucionando, implicaba desafíos estructurales más allá de la calidad del modelo o el diseño de los prompts. Durante ese tiempo, los desarrolladores y usuarios habían aprendido a localizar información expandiendo barras laterales, revisando pestañas y abriendo solicitudes. Reingenierizar esa conciencia para un agente que razona sobre datos en lugar de navegar por pantallas obligó a replantear supuestos presentes en las APIs, la experiencia de usuario y la distribución del conocimiento del producto.
Control de la proliferación de herramientas
En las primeras iteraciones, el equipo tendió a utilizar herramientas atómicas: acciones pequeñas y precisas como abrir una solicitud, actualizar un campo u obtener metadatos específicos. Este enfoque garantizaba corrección y control, pero reveló problemas de experiencia. Muchos flujos reales requerían secuencias largas de llamadas a herramientas; aun cuando cada paso era rápido, la interacción global resultaba lenta porque cada acción debía regresar al modelo antes de iniciar la siguiente. El usuario observaba al agente ejecutar paso a paso acciones que mentalmente agrupaba como una sola operación.
Las pruebas mostraron que los errores de selección de herramientas aumentaban cuando el catálogo visible superaba aproximadamente las 40 herramientas. El agente podía invocar herramientas inexistentes, pasar argumentos incorrectos a pesar de contar con esquemas válidos o elegir herramientas semánticamente razonables pero inadecuadas según el contexto. Modelos más grandes o recientes redujeron estos fallos, pero no los eliminaron. Más allá de cierto tamaño del catálogo, exponer más herramientas reducía la efectividad del agente.
La arquitectura actual selecciona herramientas según la necesidad y el contexto, y aísla los hilos de ejecución individuales. El modelo solo ve las herramientas relevantes para la tarea en curso. Un agente raíz consulta una base de datos vectorial de embebidos de herramientas y reduce más de 170 opciones a unas 15 relevantes para la solicitud, para luego delegarlas a un subagente aislado contextualmente. Un problema secundario era que muchas APIs del cliente estaban implícitamente acopladas al estado de la interfaz: las herramientas que modificaban solicitudes requerían ciertos elementos abiertos, mientras que otras abrían nuevas pestañas como efecto secundario. El agente debía abrir una pestaña para leer, imitando interacciones de interfaz en lugar de razonar sobre datos. Postman trabaja activamente en desacoplar las herramientas de las pestañas, y su función Native Git aprovecha este enfoque; Agent Mode ahora puede enviar solicitudes en segundo plano sin una pestaña abierta, aunque sigue requiriendo la aprobación del usuario.
El contexto como cuello de botella
Postman suponía inicialmente que la falta de herramientas sería el mayor obstáculo. En la práctica, la ausencia o insuficiencia del contexto causó más fallos que la carencia de capacidades. El contexto es la comprensión que tiene el agente de dónde se encuentra el usuario en Postman, qué entidades están activas y qué estado ya se ha establecido. Cuando ese contexto era erróneo o inexistente, incluso las herramientas correctas resultaban ineficaces.
Se distinguen dos formas de contexto suministradas al agente: un contexto amplio y superficial, recopilado automáticamente y minificado para el prompt, y un contexto profundo y enfocado, seleccionado por el usuario y enrutado mediante un gestor (handler) dedicado por cada tipo de entidad. Cada gestor destila la entidad en la información que el agente necesita conocer. El desafío era estructural: durante 11 años, los desarrolladores aprendieron a encontrar información a través de la interfaz. Reingenierizar esa conciencia para un agente requirió múltiples iteraciones para determinar qué era relevante para cada flujo de trabajo y qué era ruido.
Serializar el modelo de datos de interfaz existente no producía un contexto útil porque esos objetos estaban diseñados para el renderizado y la transferencia de datos, no para el razonamiento. Postman construyó entonces gestores de contexto dedicados que destilan cada entidad en lo necesario. A medida que más objetos recibieron gestores, la truncatura se convirtió en el siguiente problema: muchos campos contienen datos abiertos generados por el usuario, como descripciones de solicitudes, especificaciones OpenAPI y payloads de petición. Estos datos pueden saturar la ventana de contexto. Gestionar cuidadosamente el presupuesto de contexto resulta esencial a escala y apoya el enfoque basado en sistema de archivos que el equipo explora, donde cada gestor no necesita personalización adicional.
Lecturas basadas en esquemas
Para productos como el API Catalog, Postman consolidó múltiples vistas estrechas en una única herramienta de consulta. Estas exposiciones incluyen datos estructurados como el tiempo de actividad de servicios, resultados de pruebas y tiempos de respuesta de puntos de acceso a través de numerosos servicios. Dados los esquemas de las tablas ClickHouse subyacentes, el agente puede generar consultas complejas con joins y cláusulas WHERE.
Este enfoque reduce sustancialmente el número de herramientas distintas necesarias para responder preguntas analíticas: en lugar de construir una herramienta por cada pregunta, el trabajo de ingeniería se traslada a modelar bien los datos una sola vez. El agente puede generar una variedad mucho mayor de consultas que la que el equipo podría haber enumerado como herramientas individuales. Donde existen datos bien estructurados, dar al agente acceso de lectura consciente del esquema a un motor de consultas, en lugar de una proliferación de herramientas de lectura de propósito único, produce una mejor curva de escalabilidad.
Amazon Bedrock: flexibilidad, retención cero y caché multinivel
Agent Mode utiliza Amazon Bedrock para acceder de forma gestionada a los modelos de fundación detrás del agente. Bedrock permite a Postman escalar esta carga de trabajo productiva sin operar su propia infraestructura de inferencia, conservando la flexibilidad en la selección de modelos y el control sobre el rendimiento, el procesamiento geográfico y los costes. La plataforma soporta inferencia cruzada entre regiones con alcance geográfico, configuraciones de retención de datos cero dependientes del modelo y caché de prompts multinivel.
Postman también emplea Amazon Bedrock Guardrails como control de IA responsable para enmascarar información personalmente identificable antes de que alcance el modelo de lenguaje subyacente. Los administradores empresariales pueden activar este guardián en la configuración de Agent Mode. La supervisión humana permanece como parte del diseño productivo: se requiere la aprobación del usuario antes de acciones que modifiquen el estado de la aplicación, y las herramientas se ajustan a la tarea mientras se selecciona el contexto predefinido y se aplican configuraciones de retención de datos dependientes del modelo.
Lecciones para agentes empresariales en producción
La experiencia de Postman ilustra los desafíos prácticos del despliegue de agentes de IA a escala real. El control de la proliferación de herramientas, la gestión del contexto como recurso limitado, el desacoplamiento de las herramientas del estado de la interfaz y el uso de lecturas basadas en esquemas son patrones clave para llevar los agentes más allá de los prototipos. La integración con una plataforma gestionada como Bedrock aporta escalabilidad, flexibilidad de modelos y controles de seguridad sin asumir la operación de infraestructura propia.
Los hechos confirmados provienen de la publicación del 9 de octubre de 2026, donde Postman y AWS describen los patrones arquitectónicos emergentes. No se proporcionan cifras detalladas de costes ni tiempos de inferencia específicos, ni se aclara si todos los artículos relacionados corresponden al mismo evento o son publicaciones independientes. La importancia radica en que ofrece una referencia tangible para equipos que buscan desplegar agentes en productos maduros con una superficie amplia y conceptos especializados, demostrando que el contexto suele ser más crítico que la capacidad de las herramientas.
