monday.com ha ofrecido una mirada detallada a cómo ejecuta agentes de IA en producción para la entrega de software sobre Amazon Bedrock, dando al mercado un caso concreto de cómo luce la “IA agéntica” dentro de un gran entorno SaaS empresarial y no en un entorno de demostración.

La revelación llega a través de una publicación del AWS Machine Learning Blog y una noticia de AWS, por lo que la información está en gran medida controlada por el proveedor. Aun así, es notable porque monday.com no solo describe el uso de modelos, sino también los sistemas, colas, capas de almacenamiento, flujos de revisión y salvaguardas operativas necesarios para permitir que agentes internos de IA interactúen con Slack, GitHub y los flujos de trabajo de monday en producción. Para los creadores de IA y los compradores empresariales, la importancia tiene menos que ver con un benchmark aislado y más con las decisiones de arquitectura detrás de la confiabilidad, la repetición, la auditabilidad y la supervisión humana.

Según el relato de AWS sobre la configuración de monday.com, la empresa organiza a sus “AI Teammates” internos en tres niveles. En la primera capa, los humanos utilizan herramientas de codificación con IA como asistentes. En la segunda, los equipos crean habilidades reutilizables y subagentes para trabajos repetidos. En la tercera, los agentes asumen tareas de entrega de extremo a extremo mientras los humanos orquestan y revisan. AWS dice que el sistema interno de monday.com, llamado Sphera, otorga a los agentes identidades estables entre sistemas para que se les pueda asignar trabajo, revisar o desactivar de maneras que se asemejan a compañeros de equipo humanos.

Del asistente de codificación al flujo de trabajo de agente gestionado

La parte más interesante de la descripción de monday.com es que enmarca la adopción de IA como una progresión operativa y no como un lanzamiento de producto único. AWS dice que monday.com utiliza Cursor para tareas rápidas de programación en pareja y Claude Code para trabajos de ingeniería más pesados, lo que la empresa categoriza como su capa asistente L1. Luego avanza hacia agentes internos reutilizables en L2 y entrega multiagente en L3.

Esto importa porque muchas implementaciones empresariales de IA se estancan entre experimentos de “copilot” y automatización en producción. El relato de monday.com sugiere que la brecha no se resuelve solo con mejores modelos. Se resuelve envolviendo el acceso al modelo en una capa de orquestación que entiende la asignación de trabajo, la memoria de sesión, el uso de herramientas, la revisión de código, la repetición y el manejo de fallos.

En el sistema de monday.com, un agente puede activarse desde tres canales: una mención en Slack, una asignación de un elemento de monday o una solicitud de revisión de un pull request en GitHub. AWS dice que las tres rutas llegan a la misma sesión del agente, compartiendo la misma memoria y el mismo espacio de trabajo en disco. Ese diseño parece destinado a evitar un contexto fragmentado entre distintas herramientas de colaboración.

El agente central destacado en la publicación, llamado Atlas, se describe como un agente ingeniero de software que puede tomar tickets, escribir pull requests y lanzar funciones. AWS presenta a Atlas como un miembro de una estructura de equipo más amplia dentro de Sphera, donde los agentes tienen un rol definido, un alcance, un responsable y una puntuación de rendimiento. Ese encuadre puede sonar cosmético, pero monday.com dice que en realidad forma parte del esquema operativo de cómo se dirigen y gobiernan los agentes.

Por qué importa aquí la pila de AWS

La arquitectura que monday.com ha revelado es notable en parte porque no se trata de una única plataforma monolítica de agentes. En su lugar, AWS dice que monday.com construyó un sistema por capas sobre servicios en la nube estándar, con Amazon Bedrock gestionando el acceso a modelos y una pila más amplia de eventos y almacenamiento haciendo la mayor parte del trabajo operativo.

Según la publicación, los activadores externos llegan primero a Amazon SNS, que luego distribuye mensajes a colas de Amazon SQS. Los consumidores que se ejecutan en Amazon EKS extraen mensajes, resuelven qué agente debe encargarse de ellos y entregan el trabajo a un pod ejecutor de agentes. monday.com dice que esta configuración de pub/sub más colas le proporciona reintentos, colas de mensajes fallidos, control de presión cuando Amazon Bedrock limita la tasa, repetición duradera para probar compilaciones parcheadas y distribución paralela.

Ese es un punto importante para los equipos que planifican agentes de IA en producción. La parte difícil a menudo no es generar código o texto. Es gestionar cargas de trabajo repentinas, reejecutar trabajos tras fallos, rastrear lo que ocurrió y recuperarse de forma segura cuando las dependencias o los endpoints de modelo dejan de estar disponibles. La arquitectura de monday.com muestra una preferencia por patrones de infraestructura aburridos pero probados.

La empresa también dice que envuelve el Claude Agent SDK en lugar de depender de él directamente. AWS atribuye tres razones a monday.com: preservar la neutralidad del proveedor en el punto de llamada a través de Amazon Bedrock, reducir la latencia de arranque en frío con cachés precalentadas y mantener el control de lo que llama la capa “harness”, donde viven la evaluación, la composición de plugins, las comunicaciones y la lógica de revisión. Ese es un indicador útil para los creadores. Sugiere que el tiempo de ejecución del modelo puede ser intercambiable, mientras que el plano de control y la lógica del flujo de trabajo se convierten en la ventaja interna duradera.

Almacenamiento, memoria y las decisiones de ingeniería menos glamorosas

Una segunda lección de la revelación es que los sistemas de agentes necesitan varios tipos de estado, y esos estados no deben vivir en una sola base de datos.

AWS dice que monday.com mantiene el estado en vivo, como la tarea actual, el heartbeat, los bloqueos y los registros de mensajes, en Amazon ElastiCache para acceso de baja latencia. La memoria de sesión y los archivos de trabajo se almacenan en Amazon EFS, mientras que los registros duraderos como transcripciones, artefactos, instantáneas y evaluaciones van a Amazon S3. Amazon RDS figura entre los servicios utilizados, aunque el extracto de la publicación no detalla su función específica. AWS Secrets Manager se usa para el manejo de secretos por sesión.

Esta división importa porque muchos prototipos de agentes tratan la memoria como una sola abstracción. En la práctica, los agentes de codificación necesitan algo más parecido a un sistema distribuido convencional: estado efímero rápido, un sistema de archivos compartido para herramientas que esperan semántica POSIX y almacenamiento a largo plazo para auditorías y evidencia.

AWS dice que monday.com eligió Amazon EFS en lugar de almacenamiento de objetos para las sesiones activas porque el Claude Agent SDK y herramientas de desarrollo comunes como git y npm esperan un sistema de archivos real. También permite que una sesión se reanude en un pod diferente de Amazon EKS montando la misma ruta. Es una decisión pragmática y refleja la realidad de que los agentes de software suelen depender de las mismas suposiciones sobre archivos y procesos que los desarrolladores humanos.

Para los equipos de IA empresarial, este es uno de los aspectos más creíbles de la historia. Va más allá de la abreviatura de marketing “memoria” y muestra que los espacios de trabajo persistentes, la reanudabilidad y los entornos de herramientas deterministas son centrales para la confiabilidad de los agentes.

Evidencia, afirmaciones y lo que sigue sin verificarse

Dado que el material de origen proviene de AWS y del AWS Machine Learning Blog, las afirmaciones más fuertes sobre rendimiento y adopción deben tratarse como reportadas por el proveedor. AWS dice que todas las cifras de la publicación provienen de los datos internos de producción de monday.com.

Entre esas afirmaciones se incluye que nueve de cada diez desarrolladores en monday.com usan herramientas de codificación con IA cada mes, frente a aproximadamente la mitad hace un año, y que el rendimiento de pull requests por ingeniero ha aumentado en más de la mitad. AWS también dice que esta capa L2 de habilidades y subagentes es donde opera actualmente la mayor parte de monday.com.

Son afirmaciones significativas si son exactas, pero los lectores deben notar lo que no se ofrece en la evidencia disponible. No hay una metodología independiente, no hay un denominador bruto para “developers”, no hay un período base más allá de un lenguaje relativo amplio, y no hay un desglose de si el mayor rendimiento de pull requests se tradujo en mejor tiempo de ciclo, menos incidentes o cargas de revisión diferentes. Tampoco se cuantifican costos, tasas de defectos ni la frecuencia con la que los revisores humanos rechazan o reescriben la salida del agente.

Del mismo modo, AWS dice que Amazon Bedrock ayuda a monday.com a mantener el seguimiento de costos, la planificación de capacidad y las pistas de auditoría de llamadas al modelo en un solo lugar mediante mecanismos como Application Inference Profiles. Eso es plausible como beneficio de plataforma, pero la evidencia aquí sigue siendo descriptiva más que comparativa. No hay un benchmark directo frente a rutas de despliegue alternativas.

Aun así, la publicación es más sólida que muchos casos de uso de IA porque dedica más tiempo al diseño del sistema que a afirmaciones abstractas de transformación. La ausencia de validación independiente no elimina la señal arquitectónica; solo limita cuánto peso deben dar los compradores a las cifras de productividad.

Qué significa esto para creadores y compradores empresariales

Para los equipos de software, el ejemplo de monday.com señala una división práctica en la pila de IA. Productos como Cursor y Claude Code pueden mejorar rápidamente la producción de desarrolladores individuales, pero escalar más allá de la asistencia personal requiere una infraestructura mucho más parecida a la ingeniería de plataforma que a la ingeniería de prompts.

Para los compradores de IA empresarial, el caso recuerda que desplegar agentes de IA en organizaciones de software orientadas al cliente plantea requisitos más duros que el lanzamiento de chatbots. Los agentes que abren pull requests o actúan sobre tickets necesitan identidad duradera, permisos acotados, observabilidad, rutas de reversión, puntos de revisión y suficiente detalle de auditoría para satisfacer a los equipos de seguridad y cumplimiento.

La historia también afina el marco competitivo en torno a Amazon Bedrock. AWS está posicionando el servicio no solo como acceso a modelos, sino como un punto de control para capacidad, gobernanza y contabilidad de costos entre muchos agentes. Es probable que ese mensaje resuene en empresas ya estandarizadas sobre AWS, especialmente en aquellas que quieren opcionalidad de modelos sin construir su propia capa de gateway desde cero.

Al mismo tiempo, el propio diseño de monday.com sugiere que los servicios en la nube por sí solos no resuelven el problema central del flujo de trabajo. La capa diferenciadora es el harness interno: enrutamiento, evaluación, lógica de plugins, política de revisión e integración específica del equipo con Slack, GitHub y el propio monday. Las empresas que compran plataformas de agentes tendrán que decidir cuánto de ese harness quieren poseer.

Qué observar a continuación

La siguiente señal a vigilar es si monday.com o AWS ofrecen pruebas más sólidas sobre la calidad del software y el costo operativo, no solo métricas de actividad. El volumen de pull requests es útil, pero los compradores empresariales querrán ver datos sobre tasas de incidentes, frecuencia de reversión, tiempo de revisión y excepciones de seguridad.

Una segunda señal es si monday.com amplía la autonomía de los agentes más allá de los flujos de trabajo internos de ingeniería. Si los agentes pueden pasar con seguridad de soporte de codificación a tareas más amplias de producto y operaciones, eso reforzaría el argumento de que los sistemas estructurados multiagente pueden convertirse en un patrón empresarial general.

Tercero, conviene observar si AWS convierte esta arquitectura en orientación o funciones más productizadas alrededor de Amazon Bedrock, Amazon EKS y herramientas de orquestación. La descripción actual sigue implicando una ingeniería personalizada considerable por parte de monday.com.

Por último, será valioso seguir si los competidores publican historias de producción igualmente detalladas. El mercado tiene muchas afirmaciones sobre agentes de IA, pero relativamente pocos relatos que expliquen cómo los agentes realmente conservan contexto, se recuperan de fallos y pasan la revisión humana en una pila empresarial viva.

Perspectiva de Creati.ai

La verdadera noticia aquí no es que monday.com use IA para programar. Muchas empresas lo hacen. El desarrollo más importante es que monday.com está describiendo un modelo operativo de producción para agentes de IA que los trata como trabajadores gestionados dentro de sistemas de entrega de software existentes, con colas, sistemas de archivos, registros de auditoría y límites explícitos de revisión.

Hacia ahí se dirige el mercado de IA empresarial. Los ganadores no serán los equipos con las demostraciones más llamativas, sino los que puedan hacer que los agentes de IA sean legibles para gerentes de ingeniería, equipos de seguridad, equipos financieros y operadores de guardia. La arquitectura de monday.com, tal como la presenta AWS, sugiere que la adopción de agentes se vuelve creíble cuando se construye primero como infraestructura y solo después como inteligencia.