5 min de lectura

Agentes de IA en producción: lo que Postman aprendió al llevar Agent Mode a 40 millones de desarrolladores

Agentes de IA en producción: Postman llevó Agent Mode a 40 millones de desarrolladores con Amazon Bedrock. Estas son las lecciones clave para tu empresa.

Ilustración abstracta de un agente de IA central conectado con millones de desarrolladores mediante una red luminosa en la nube

Construir un agente para una demo y operar uno para 40 millones de usuarios son problemas de ingeniería distintos. Esa es la advertencia con la que Postman y AWS abren el relato de cómo llevaron Agent Mode a producción. El equipo esperaba que lo más difícil fuera la calidad del modelo y el diseño de prompts. Se equivocó: el verdadero cuello de botella fue el contexto, no las capacidades. Para cualquier líder que planee desplegar agentes de IA en producción, la lección es incómoda y valiosa.

Agent Mode es la puerta de entrada de Postman para trabajar con su plataforma de forma «nativa en IA»: pruebas de APIs, documentación, descubrimiento e implementación. Es una pieza que debe funcionar sobre un producto con 11 años de historia, construido para humanos que navegan por barras laterales, pestañas y solicitudes abiertas. Un agente no navega pantallas, razona sobre datos, y ahí aparecieron los supuestos ocultos del producto. Según el artículo publicado por Srinivas Kini y Shubham Gupta en el blog de machine learning de AWS, el agente corre sobre Amazon Bedrock, que le da acceso gestionado a modelos fundacionales sin que Postman opere su propia infraestructura de inferencia. La demanda de su comunidad global es variable, sensible a la latencia y con picos bruscos. Bedrock le permite además elegir modelos y controlar el rendimiento, el procesamiento geográfico y el costo, con inferencia entre regiones acotada geográficamente, retención de datos que depende del modelo y caché de prompts en varios niveles.

Los tres hallazgos de arquitectura son claros:

  • Demasiadas herramientas degradan al agente. Postman empezó con herramientas muy atómicas (abrir una solicitud, editar un campo, leer un metadato). Los flujos reales exigían largas cadenas de llamadas, y cada paso volvía al modelo antes del siguiente, lo que hacía lenta la experiencia. Además, en sus pruebas los errores de selección aumentaron cuando el catálogo visible superaba unas 40 herramientas: el agente invocaba herramientas inexistentes o elegía opciones plausibles pero equivocadas. La solución actual consulta una base vectorial de embeddings de herramientas, reduce más de 170 a unas 15 relevantes y las entrega a un subagente con contexto aislado.
  • Lecturas basadas en esquemas. En el API Catalog, Postman consolidó varias vistas estrechas en una sola herramienta de consulta. Con los esquemas de las tablas de ClickHouse, el agente genera consultas complejas (uptime, errores, latencia p95) sin que el equipo tenga que anticipar cada pregunta.
  • El contexto era el cuello de botella. Muchas herramientas dependían del estado de la interfaz: para leer una solicitud había que abrir su pestaña. Postman las está desacoplando; hoy el agente ya puede enviar solicitudes en segundo plano, aunque con aprobación del usuario.
  • La supervisión humana forma parte del diseño. Agent Mode pide aprobación antes de cualquier acción que modifique el estado de la aplicación, limita las herramientas por tarea y usa Amazon Bedrock Guardrails para redactar información personal antes de que llegue al modelo. Los administradores empresariales pueden activarlo en la configuración. Los autores subrayan que estos controles reducen riesgos, pero no eliminan la necesidad de pruebas y monitoreo en producción. Otras fuentes que recogieron la noticia coinciden en el mensaje de fondo: hacer que un agente funcione es fácil comparado con hacerlo funcionar a escala.

    Lecciones para llevar agentes de IA en producción a tu organización

    Si tu empresa está pasando del piloto al despliegue real, el caso de Postman ofrece un manual práctico:

    1. Trata el catálogo de herramientas como parte del presupuesto de contexto. Más herramientas no equivalen a más capacidad. Mide en qué punto empiezan a subir los errores de selección y limita lo que ve el modelo en cada tarea, con búsqueda semántica y subagentes especializados.
    2. Desacopla lo que el agente puede hacer de lo que la interfaz tiene abierto. Si tus APIs internas asumen que alguien está mirando una pantalla, el agente tropezará. Audita esos acoplamientos antes de integrar.
    3. Invierte en modelar datos, no en multiplicar herramientas de lectura. Si tienes datos bien estructurados, da al agente acceso de lectura con conocimiento del esquema. Cambias cantidad de herramientas por calidad de modelado, y la curva de escalabilidad mejora.
    4. Diseña el contexto antes que los prompts. Define qué entidades están activas, dónde está el usuario y qué estado ya se estableció. Postman descubrió que un contexto incompleto hacía inútiles incluso herramientas correctas.
    5. Mantén al humano en las acciones de riesgo. Exige aprobación para lo que modifica estado y aplica protección de datos personales desde la capa de inferencia.
    6. Elige una infraestructura que no te encierre. La flexibilidad de modelos, el control geográfico del procesamiento y la gestión de costos pesan tanto como la calidad del modelo cuando tu demanda tiene picos.

    Cómo evaluar y proteger tu agente antes de escalar

    El artículo de Postman no ofrece cifras de ROI ni métricas de adopción, así que conviene no extrapolar resultados económicos. Lo que sí deja claro es el orden de prioridades: primero contexto y diseño de herramientas, después modelo. Es una conclusión coherente con otros casos recientes, como el de Elastic, que explica cómo evaluar agentes de IA con un framework único tras casi dos años en producción. Si tu agente tendrá permisos para actuar, conviene revisar también la arquitectura de seguridad multicapa que GitHub aplica a sus agentes en CI/CD. Y si buscas otro ejemplo de IA sobre Bedrock aplicada a un problema operativo concreto, mira cómo Miro redujo de días a horas la resolución de bugs.

    El siguiente paso para tus agentes de IA en producción

    La pregunta para tu equipo ya no es qué modelo usar, sino si tu producto es legible para un agente. ¿Tus herramientas están acotadas por tarea? ¿Tus datos tienen esquemas que una máquina pueda consultar? ¿Tu contexto llega completo? Responder con honestidad a esas tres preguntas es el mejor punto de partida para que tus agentes de IA en producción pasen de la demo a la operación real.

    Preguntas frecuentes

    ¿Qué es Agent Mode de Postman y para qué sirve?

    Agent Mode es la forma de Postman de trabajar con su plataforma de manera nativa en IA. Cubre pruebas de APIs, documentación, descubrimiento e implementación. El agente razona sobre datos en lugar de navegar la interfaz, funciona sobre Amazon Bedrock y está pensado para una comunidad de 40 millones de desarrolladores.

    ¿Por qué fallan los agentes de IA cuando tienen demasiadas herramientas?

    Postman observó que los errores de selección aumentaban cuando el catálogo visible superaba unas 40 herramientas: el agente llamaba herramientas inexistentes o elegía opciones equivocadas. Su solución reduce más de 170 herramientas a unas 15 relevantes por tarea mediante búsqueda vectorial y subagentes con contexto aislado.

    ¿Cómo protege Postman los datos y controla las acciones de su agente de IA?

    Agent Mode exige aprobación del usuario antes de acciones que modifican el estado de la aplicación. Además limita las herramientas por tarea, aplica retención de datos según el modelo y usa Amazon Bedrock Guardrails para redactar información personal antes de llegar al modelo. Los administradores empresariales pueden activar esa protección.