Cómo monday.com ejecuta agentes IA en producción con Amazon Bedrock

Introducción

Ejecutar agentes de IA en demo es una cosa; hacerlo dentro de un producto empresarial con usuarios, on-call y cumplimiento es otra muy distinta. monday.com ha integrado agentes basados en Amazon Bedrock en su flujo de trabajo de desarrollo y reporta que nueve de cada diez Builders usan herramientas de codificación asistida por IA mensualmente, frente a aproximadamente la mitad hace medio año. Además, el rendimiento por desarrollador en cantidad de PRs abiertos aumentó en más de un 50%. Estos resultados provienen de sus datos internos en producción.

En este artículo desgranamos la arquitectura que habilita esos números, las adaptaciones realizadas sobre un código heredado de una década y la aproximación que mantiene a los agentes como miembros del equipo, no como procesos descontextualizados.

El reto de integrar agentes en un SaaS maduro

monday.com no es un experimento greenfield: es una base de código con diez años de historia, millones de usuarios de pago, cientos de microfrontends y microservicios, y equipos multidisciplinarios de Builders (ingenieros, PMs, analistas y diseñadores de producto). En ese contexto, cualquier PR generado por un agente debe pasar por los mismos controles que el código humano y no puede romper expectativas de disponibilidad o cumplimiento.

Por eso las decisiones de diseño priorizaron identidad estable de los agentes, trazabilidad en las herramientas ya usadas por los equipos y mecanismos de control sobre qué puede abrir un agente en producción.

Tres niveles de adopción de IA

monday.com describe su evolución en tres niveles:

• L1 — Asistente: IA como pair programmer. Herramientas para trabajo rápido y asistido, como completados y sugerencias, con adopción que casi se duplicó en un año.
• L2 — Habilidades y sub-agentes: equipos construyen agentes reutilizables para tareas repetitivas, con ingenieros en el asiento del conductor. Aquí es donde la mayoría de monday opera hoy, y donde vieron el salto en throughput por desarrollador.
• L3 — Multi-agente: agentes que asumen entregas de extremo a extremo y los humanos orquestan. Esa visión apunta a agentes con autonomía bajo supervisión humana.

Estos niveles ayudan a enmarcar la transición dentro de organizaciones que necesitan equilibrar productividad, riesgo y control.

Agentes como compañeros: Sphera

La plataforma interna se llama Sphera. En lugar de mostrar una cola de trabajos, el primer punto de contacto es una página de “Teams” que mezcla humanos y agentes. Cada agente tiene perfil, manager, alcance y un score de desempeño. Atlas, el agente citado en el caso, tiene rol de “Software Engineer”: toma tickets, escribe PRs y entrega features, pero sin IDE; opera sobre el mismo backlog que las personas.

La identidad persistente es fundamental: un agente aparece en Slack, GitHub y monday de forma reconocible, puede ser asignado, revisado o desactivado como cualquier otro miembro del equipo. Esta decisión transforma la ergonomía de adopción: los agentes conviven en el equipo en vez de ser procesos ocultos.

Tres buzones, un agente

Un agente en monday tiene tres canales de entrada primarios: una mención en Slack (@agent), la asignación de un item en monday y una solicitud de revisión de PR en GitHub. Todos estos eventos alimentan la misma sesión de agente, con la misma memoria y workspace en disco: son variantes del mismo evento que fluyen por la misma ruta y procesan el mismo contexto.

No se ejecutan tres sistemas independientes; se corre uno solo con múltiples entradas.

Arquitectura y servicios AWS

La implementación combina servicios gestionados de AWS con un harness propio. Los servicios clave son:

• Amazon SNS (pub/sub) y Amazon SQS (colas) para recibir y encaminar eventos.
• Amazon EKS para ejecutar consumidores y pods de agentes.
• Amazon RDS como base relacional cuando se requiere.
• Amazon ElastiCache para estado ‘live’ de baja latencia.
• Amazon EFS como sistema de archivos compartido para sesiones y memoria.
• Amazon S3 para almacenamiento de objetos.
• AWS Secrets Manager para gestión de secretos por sesión.
• Amazon Bedrock para las llamadas a modelos LLM.

Ruta de eventos: cada disparador externo llega a SNS, que hace fan-out a colas SQS por equipo y tema. Un conjunto de consumidores llamado monday Builders CoWORK, ejecutado en EKS, consume esas SQS, resuelve el agente propietario y despacha el evento al pod correcto que ejecuta el agente.

Esta combinación pub/sub + colas aporta funcionalidades críticas: retries y dead-letter queues por defecto, control de back-pressure cuando Bedrock responde con throttling, posibilidad de re-play durable (por ejemplo, re-ejecutar el último día de eventos contra una build parcheada antes de promover), y fan-out concurrente.

El harness: monday-agent-sdk alrededor del runtime

El runtime utilizado es el Claude Agent SDK, pero monday añade una capa propia (monday-agent-sdk) por tres motivos:

1. Neutralidad del proveedor en el call site: las llamadas de LLM se enrutan a endpoints de Amazon Bedrock.
2. Mitigar cold-starts: los runners de agente se entregan con caches y node_modules calientes, de modo que la primera invocación de modelo suele ser menor a un segundo.
3. Mantener las opiniones de integración: cómo se evalúa un agente, cómo se componen plugins, y cómo se integra con Slack, monday y GitHub. En resumen, el runtime puede ser commodity; el harness contiene las decisiones arquitectónicas del equipo.

Si en el futuro el SDK del proveedor mejora el runtime, monday puede retirar su versión y mantener el harness.

Estado, memoria y sesiones: particionar para rendimiento y costo

Los agentes manejan al menos tres tipos de estado y ponerlos todos en una única tienda genera penalidades (costo, latencia o corrección):

• Estado en vivo: tarea actual, cursor de ejecución, lock distribuido, heartbeat y log de mensajes. Esto vive en Amazon ElastiCache por lecturas sub-milisegundo y expiración automática.
• Sesiones y memoria: cada sesión activa es un directorio en un filesystem compartido montado vía Amazon EFS. Ejemplo de estructura:

/sessions/<session-id>/ repos/ # workspace con checkout secrets.json # secretos por sesión (encriptados) messages/ # log cronológico de eventos /agents/<agent-id>/ MEMORY.md # memoria persistente entre sesiones diary/2026-04-21.md # diario por día

Se eligió EFS por dos razones: muchas herramientas y plugins (git, npm, editores de archivos) esperan un filesystem POSIX, y porque al reanudar una ejecución en otro pod, ese pod monta la misma ruta EFS y continúa donde quedó. En el artículo original se muestra un ejemplo de diario para Atlas en diary/2026-04-21.md con entradas de tareas en progreso.

• Almacenamiento duradero: S3 y RDS se usan para datos que no requieren acceso POSIX inmediato.

ElastiCache ofrece la latencia y costo adecuados para el patrón de acceso intensivo, aunque DynamoDB sería una opción válida en otros contextos.

Operación, seguridad y control humano

Los agentes en monday no funcionan en una burbuja: las PRs que abren pasan por revisiones, los managers humanos pueden desactivar agentes, y la plataforma mantiene trazabilidad entre mensajes en Slack, solicitudes en GitHub y items en monday.

La decisión de darles identidad persistente facilita auditoría y gobernanza; los equipos pueden tratar a un agente como cualquier otro miembro con responsabilidades y limites.

Lecciones para equipos en América Latina

• Prioricen identidad y trazabilidad: en organizaciones reguladas o con soporte 24/7, es clave que un agente deje rastro en las mismas herramientas que el resto del equipo.
• Mantengan un harness propio: incluso si usan SDKs de terceros, una capa que gestione políticas internas, evaluación y plugins facilita la gobernanza.
• Particionen el estado: elegir la tecnología correcta para estado vivo, sesiones y almacenamiento duradero reduce costos y errores operativos.
• Avancen por niveles: comenzar con asistentes (L1) y consolidar habilidades reutilizables (L2) permite capturar productividad antes de buscar autonomía completa.

Para empresas latinoamericanas que ponderan adopción de agentes, estos pasos permiten equilibrar innovación con riesgo operativo y cumplimiento.

Conclusión

monday.com demuestra que ejecutar agentes de IA en producción a escala empresarial exige decisiones arquitectónicas claras: identidad de agente, un harness que encapsule políticas, partición de estado y una infraestructura resiliente que integre pub/sub, colas y soporte para filesystem compartido. Con Amazon Bedrock como proveedor de modelos y una capa propia que los une con Slack, GitHub y monday, lograron un incremento notable en adopción y productividad sin sacrificar control ni trazabilidad.