Compañeros de equipo de IA: cómo monday.com ejecuta agentes de IA de producción en Amazon Bedrock

Los compañeros de equipo de IA son IA agentes en Amazon Bedrock, y pocas organizaciones de ingeniería los ejecutan en producción a la escala que lo hace monday.com. Nueve de cada diez constructores utilizan herramientas de codificación de IA cada mes, en comparación con hace aproximadamente medio año. El rendimiento de relaciones públicas por ingeniero ha aumentado a más de la mitad. Cada cifra en esta publicación proviene de los datos de producción internos del lunes.

En esta publicación, compartimos la arquitectura detrás de esos números, las modificaciones que lo hicieron funcionar en una base de código de hace una década y el juego de fusión con puntaje de confianza que cierra la brecha hacia la autonomía total.

Esto no es un terreno nuevo

monday.com es una base de código de una década de antigüedad, millones de usuarios pagos, cientos de microfrontends y microservicios, cientos de constructores (ingenieros, PM, analistas y diseñadores de productos). Cada PR que abre un agente ingresa a un sistema que millones de usuarios esperan seguir trabajando durante la próxima implementación. Las demostraciones de Greenfield son sencillas. El trabajo es ejecutar agentes dentro de un SaaS empresarial con disponibilidad real, clientes y cumplimiento.

Tres niveles de ingeniería de IA

Puedes enmarcar el viaje en tres niveles:

L1, el asistente. Los ingenieros utilizan la IA como programador de pares. Cursor para el trabajo rápido y reflexivo, Claude Code para los levantamientos pesados. La adopción casi se ha duplicado año tras año. L2, habilidades y subagentes. Los equipos crean agentes reutilizables para trabajos repetidos, con los ingenieros al mando. Aquí es donde se desarrolla la mayor parte del lunes hoy y donde el rendimiento de relaciones públicas por desarrollador aumentó a más de la mitad. L3, multiagente. Totalmente agente. Los agentes son dueños de la entrega de un extremo a otro mientras los ingenieros organizan, toman tareas de los tableros, hablan en Slack y Monday y envían códigos junto con los humanos.

Los agentes son compañeros de equipo, no trabajos

Sphera es el sistema de agentes internos de Monday. Lo primero que ve no es una cola de trabajos, es una página de Teams: una combinación de humanos y agentes, cada uno con un perfil, un administrador, un alcance y una puntuación de desempeño. Atlas, el agente central de este post, es uno de ellos: rol: Ingeniero de software. Trabajo: recoger boletos, escribir el PR, enviar la función. IDE: ninguno. El mismo retraso que todos los demás.

Esto no es decoración, es el esquema. Cada agente tiene una identidad estable que fluye a través de Slack, GitHub y Monday, por lo que un humano los etiqueta, asigna, revisa código o desactiva como cualquier otro compañero de equipo. Los agentes que mueven la aguja viven en equipos reales, realizan un trabajo real y son responsables del resultado.

la arquitectura

Así es como encaja el sistema, desde las bandejas de entrada que escucha un agente hasta los servicios de AWS que transmiten cada evento.

Tres bandejas de entrada, un agente

Un agente creado el lunes tiene tres bandejas de entrada de primera clase: una @mención de Slack, una asignación de elemento del lunes y una solicitud de revisión de relaciones públicas de GitHub. Los tres acceden a la misma sesión de agente, con la misma memoria y espacio de trabajo en el disco: tres tipos del mismo evento, la misma cola, la misma ruta. No ejecutamos sistemas de tres agentes. Ejecutamos uno.

La arquitectura en un diagrama.

Los siete servicios de AWS que utilizamos son Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Relational Database Service (Amazon RDS), Amazon ElastiCache, Amazon Elastic File System (Amazon EFS) y Amazon Simple Storage Service (Amazon S3). Junto a ellos, AWS Secrets Manager se encarga de la gestión de secretos por sesión. Amazon Bedrock maneja las llamadas de modelos y monday-agent-sdk se ejecuta dentro de cada módulo de agente corredor.

Ruta del evento: del SNS al SQS y al lunes Builders CoWORK

Cada activador externo aterriza en SNS, que se distribuye en colas SQS por equipo por tema y clave de enrutamiento. Monday Builders CoWORK, un conjunto de consumidores de SQS en EKS, extrae cada mensaje, resuelve qué agente es el propietario y lo entrega al grupo de agentes correcto.

La cola Pub/sub plus nos brinda cuatro cosas a las que no renunciaremos: reintentos y colas de mensajes no entregados listas para usar, contrapresión cuando Amazon Bedrock acelera, repetición duradera (volvemos a ejecutar el último día de eventos contra una versión parcheada antes de promocionar) y distribución simultánea. Si el SDK de Claude Agent incluye algo mejor en la capa de tiempo de ejecución, eliminamos nuestra versión. El arnés se queda.

monday-agent-sdk: una envoltura delgada, a propósito

El SDK de Claude Agent es el tiempo de ejecución. Lo envolvemos por tres motivos:

Neutralidad del proveedor en el lugar de la llamada. El agente LLM llama a la ruta a un punto de enlace modelo de Amazon Bedrock. Costo de arranque en frío. Los ejecutores de agentes se entregan con node_modules cálidos y cachés de complementos, por lo que la primera llamada al modelo generalmente se realiza en menos de un segundo. Queríamos nuestro propio arnés. El tiempo de ejecución se está convirtiendo en una mercancía. El arnés es donde viven nuestras opiniones: cómo se evalúa un agente, cómo se componen los complementos, cómo se comunica con Slack, Monday y GitHub, cómo se revisa su resultado con respecto a los estándares de Monday. Mantenemos el tiempo de ejecución como problema de otra persona y hacemos nuestro el arnés.

Estado, memoria, sesiones.

Los agentes tienen al menos tres tipos de estado. Poner los tres en una sola tienda le cuesta dinero, latencia o corrección. El estado activo se traslada a Amazon ElastiCache. Tarea actual, cursor de ejecución, bloqueo distribuido, latido y registro de mensajes de agente/humano. Lecturas de submilisegundos, claves de caducidad automática. Amazon DynamoDB funcionaría; ElastiCache es más económico y rápido para esta forma de acceso. Las sesiones y la memoria se almacenan en Amazon Elastic File System. Cada sesión activa es un directorio en un sistema de archivos compartido:

/sesiones// ├── repositorios/ # espacio de trabajo retirado ├── secrets.json # secretos cifrados por sesión └── mensajes/ # registro cronológico de eventos /agentes// ├── MEMORY.md # memoria entre sesiones └── diary/2026-04-21.md # diario por día

Dos razones, no S3. Primero, el SDK de Claude Agent y la mayoría de los complementos esperan un sistema de archivos POSIX real (git, npm, ediciones de archivos), que elimina toda una clase de errores de "funciona en desarrollo, se interrumpe en el trabajador". En segundo lugar, cuando se reanuda una ejecución en un pod EKS diferente, ese pod monta la misma ruta EFS y continúa donde lo dejó.

El diario de Atlas es un archivo real. Un fragmento redactado:

# diary/2026-04-21.md ## En progreso – ENG-3491: encabezados de límite de velocidad: verificar la preparación, luego abrir PR – ENG-3502: aumento de dependencia: bloqueado en la regla de límite de seguridad de Guardrails, esperando la revisión del propietario estándar ## Lo que aprendí en la última sesión: el equipo de API de cuentas archiva cada nuevo código de error en el registro compartido ANTES de que se abra el PR. Lo hice en el mismo PR la última vez y lo revertí. Presentó la actualización del registro primero esta vez.

Ese archivo es cómo Atlas reanuda su trabajo a la mañana siguiente. Lo lee, recuerda que el equipo de API de cuentas quiere que la actualización del registro de errores se archive por separado y se pone a trabajar. La memoria es un archivo en un disco que puede montar más de un pod.

Los registros duraderos van al S3. Las transcripciones finales, las instantáneas, los artefactos y las evaluaciones se codifican por ID de sesión. EFS tiene memoria de trabajo; S3 es la pista de auditoría.

Amazon Bedrock como tejido modelo

Amazon Bedrock es más que un lugar para conseguir tokens. Es el servicio que nos permite gestionar cientos de agentes sin perder de vista el coste, la seguridad o la capacidad. La mayoría de los requisitos operativos para implementar agentes a escala ya son características de Amazon Bedrock:

Los perfiles de inferencia de aplicaciones enrutan cada llamada de modelo, de modo que el seguimiento de costos y la planificación de capacidad permanecen en un solo lugar. Una pista de auditoría para cada llamada modelo: cuando la seguridad o un regulador pregunta qué agentes enviaron adónde en una ventana, tenemos un lugar para responder. Conmutación por error entre regiones cuando una región de AWS se acelera. El código de agente no se da cuenta. Los puntos de enlace de AWS PrivateLink mantienen el tráfico del modelo dentro de nuestra nube privada virtual (VPC).

Ejecutando en EKS

La flota informática es Amazon EKS, un pod por sesión de agente activo, que monta el espacio de trabajo EFS del agente. El aislamiento de fallos es por sesión. KEDA impulsa el escalado automático en sesiones activas promedio en todos los pods, medidas con Datadog. Ejecutamos una única imagen de trabajador. Los repositorios se almacenan en caché en EFS y se reutilizan entre sesiones. Sin red de servicios, sin orquestador de orquestadores. EKS, SQS y la capa de caché llevan la carga.

Cinco modernizaciones que hicieron que todo funcionara

La arquitectura es el suelo. Las siguientes cinco modificaciones son las que hicieron que los agentes fueran útiles dentro de una base de código de hace una década. Ninguno es exótico. Todos no eran obvios hasta que los encontramos:

Evaluaciones antes de las actualizaciones del modelo

“Se ve bien” fue el estándar para las primeras relaciones públicas de Atlas. Se rompió una vez que subió el volumen. Agregamos dos capas de evaluación: métricas deterministas (RP fusionadas, tasa de reversión, tasa de fusión sin intervención) por agente y evaluaciones con puntuación de LLM en cinco dimensiones por RP: Intención y Decisión, Ejecución y Artefacto, Integridad y Utilidad, Instrucción y Límites, Eficiencia. Ambos retroalimentan el arnés. En las sucesivas versiones de Atlas no cambiamos ningún modelo, ni indicaciones, ni empujones humanos, solo las evaluaciones y las puntuaciones se movieron en todas las dimensiones.

La memoria es un archivo, no un almacén de vectores.

Sesión 1: Atlas creó una función. Sesión 2: no tenía idea de que había sucedido la Sesión 1. Probamos el relleno de ventanas de contexto y la recuperación de vectores en transcripciones anteriores. Ambos funcionaron mal. Lo que funcionó: un MEMORY.md por agente y un diario/AAAA-MM-DD.md escrito al final de la sesión, leído al inicio de la sesión. Rebaja simple, sin incrustaciones, sin puntuación de retiro, sin ceremonia de agente-RAG.

Zona de pruebas remota antes de la revisión humana

La primera docena de RP de Atlas pasaron las pruebas locales y entraron en CI. Una base de código a escala de lunes tiene dependencias que solo existen en entornos reales: indicadores de funciones, servicios de terceros, tráfico real. Le dimos a Atlas una zona de pruebas remota por sesión, y cada PR se implementa automáticamente en ella. Se ejecutan pruebas, comprobaciones y tráfico de producción reproducido antes de que solicite una revisión humana: no se pudo arreglar el envío nuevamente, no hay ningún ser humano en el circuito.

PR Guardrails: revisión automatizada según los estándares del lunes

Atlas enviaba más y la revisión humana se convirtió en el cuello de botella. Convertimos cada estándar de ingeniería de los lunes en un revisor automatizado: etiquetado de métricas, higiene de indicadores de características, uso de Datadog, límites de seguridad, convenciones de microservicios y bases de datos, calidad de las pruebas, documentación. Un subconjunto está bloqueando. Cada uno está conectado al conocimiento interno a través de los servidores MCP de Monday, por lo que el revisor ve el mismo contexto que vería el equipo propietario del estándar.

Todas las relaciones públicas, tanto de agentes como de humanos, pasan por Guardrails. A escala, eso significa decenas de miles de RP evaluados por mes y cientos de miles de verificaciones estándar ejecutadas. Aproximadamente uno de cada cinco RP no cumple con al menos un estándar y se recupera, y las anulaciones humanas se ejecutan en un solo dígito. El sistema gestiona la aplicación de la ley, no el revisor humano.

Builders CoWORK: tableros de lunes como capa de estado compartido

El último modo de falla fue el más costoso: los agentes en silos abrieron relaciones públicas que ningún equipo poseía. Agregamos el espacio de trabajo CoWORK, la superficie orientada al usuario del mismo CoWORK de Monday Builders que enruta los eventos. Las tareas, el estado, los bloqueadores y las transferencias de un agente ahora se encuentran en el mismo tablero del lunes que los del equipo, por lo que la responsabilidad dejó de ser un problema del sistema: el lunes ya lo resolvió para los humanos.

Agentes trabajando en un espacio colaborativo.

Los agentes son compañeros de trabajo a los que puedes pedir que compartan información o realicen tareas, como cualquier compañero de equipo.

De un cuello de botella al siguiente

A finales del primer trimestre de 2026, el cuello de botella ya no era la generación de código sino la revisión humana: Guardrails capturaba lo que los humanos solían capturar, pero cada RP todavía esperaba que un humano lo aprobara. Ese muro fue el siguiente.

El primero de muchos: Morphex

Morphex es el primer agente de ingeniería totalmente autónomo del lunes, que trabaja dentro del mismo repositorio, canal de CI, Guardrails y protocolos de reversión que cada constructor. Diecinueve de cada veinte RP de Morphex se fusionan automáticamente, no saltándose la revisión sino pasando todas las puertas, y un RP aprobado se envía a producción sin ningún ser humano en el circuito. Abre más PR al mes que la mayoría de los ingenieros, y un PR rechazado falla por las mismas razones que cualquier ingeniero: pruebas inestables, especificaciones ambiguas, casos extremos no manejados.

Esa tasa de 19 en 20 es un piso, no un techo. La pregunta abierta: qué señal nos dice, de antemano, qué RP es seguro fusionar sin un humano.

La señal: un reciente recorte riguroso

Entre nuestros principales agentes generadores de relaciones públicas (sin selección selectiva), las cifras se desglosan claramente: alrededor de tres de cada diez relaciones públicas se fusionaron, aproximadamente tres cuartas partes de aquellos con cero ediciones humanas y una tasa de reversión de un solo dígito bajo. Alrededor de una cuarta parte de los RP fueron capturados y rechazados por Guardrails antes de llegar a un humano.

Ese último número es el más importante. Guardrails detuvo una cuarta parte de las relaciones públicas de los agentes porque el sistema vio que no estaban listos, lo que dejó una población de fusiones prefiltrada. Una tasa de reversión de un solo dígito en esa población es la señal de que la fusión automática basada en la confianza es viable.

Fusión automática con puntuación de confianza

La puntuación de confianza combina cuatro señales disponibles en el momento en que se abre el PR:

Resultado determinista de Guardrails: cada estándar de bloqueo debe pasar. Trayectoria de evaluación por agente: ventana de puntuación de evaluación reciente para esta versión del agente. Tasa de reversión histórica por (agente × repositorio × clase de cambio): las reversiones cercanas a cero en aumentos de dependencia en un servicio de bajo riesgo es una imagen diferente de una tasa de reversión más alta en migraciones monolíticas. Resultado del Sandbox: el verde de la modernización 3 es necesario, no suficiente.

Por encima del umbral, el PR se fusiona automáticamente. Debajo de él, se dirige a un humano con la señal de falla específica anunciada. Esa es la transición de L2 a L3: no eliminar humanos, sino eliminar humanos de los casos en los que la señal del sistema es lo suficientemente fuerte como para que agregar un humano no mejore el resultado. Estamos impulsando una métrica durante los próximos dos trimestres: la fracción de relaciones públicas de agentes fusionados que se envían sin un revisor humano, manteniendo la tasa de reversión estable o mejorando.

La ingeniería de IA no se trata de crear agentes perfectos. Se trata de crear circuitos de retroalimentación que permitan confiar de forma segura en los agentes imperfectos y, al mismo tiempo, ahorrar tiempo a los humanos.

Cierre honesto

Por qué lo construimos a la manera de los lunes

El valor no es el tiempo de ejecución, es solo un arnés alrededor del SDK de Claude Agent. Vive en todo lo que hemos conectado a su alrededor, y ese cableado es lunes de principio a fin:

Monday Boards como capa de estado compartido: las tareas, el estado y las transferencias de cada agente se encuentran donde ya se ve el resto del negocio. Servidores Monday MCP como sustrato al que se conectan los Guardrails y los estándares. la autenticación e identidad de monday, por lo que cada agente tiene un usuario real de Slack, GitHub y monday bajo el mismo RBAC que cualquier humano. canal de implementación del lunes para que el código del agente se envíe a través del mismo CI/CD que cualquier otro constructor.

Los agentes que comparten estado, identidad e infraestructura con los humanos no necesitan una capa de gobernanza separada. El existente ya aplica. Eso hace que el sistema sea auditable, reversible y confiable por defecto, no por adición. Un sistema estándar habría aplanado todo eso en el modelo de otra persona.

Tres cosas que haríamos diferente

Las evaluaciones deberían haber estado en el sistema el día uno, no el mes nueve. El resultado que el Atlas obtuvo de ellos fue el titular. Invertimos demasiado en tiendas de vectores antes de darnos cuenta de que MEMORY.md en EFS siempre era la respuesta correcta. Y el primer CoWORK vivía en un espacio de trabajo separado que obligaba a los humanos a cambiar de contexto para ver qué estaban haciendo los agentes. Pasarlo a los tableros de los lunes debería haber sido la primera decisión, no una corrección posterior.

Conclusión

No somos monday-agent-sdk de código abierto. El envoltorio es pequeño y la mayor parte de su valor es el arnés, que es específico para el lunes de una manera que no ayudaría a nadie más. Lo que compartimos es la arquitectura y el manual operativo, porque la industria avanza más rápido cuando los equipos que ejecutan agentes de producción a escala son honestos acerca de lo que funciona.

Si está incorporando agentes a sus equipos de ingeniería, se encontrará con la mayoría de los mismos muros que nosotros y ya los hemos cruzado. Hable con nosotros: el equipo de ingeniería de IA de Monday o el equipo de Amazon Bedrock estarán encantados de compartir nuestros conocimientos.

Más información

Sobre los autores