A monday.com ofereceu uma visão detalhada de como executa agentes de IA em produção para entrega de software no Amazon Bedrock, dando ao mercado um estudo de caso concreto de como a “IA agêntica” se parece dentro de um grande ambiente SaaS corporativo, em vez de um ambiente de demonstração.

A divulgação vem por meio de um post no AWS Machine Learning Blog e de um item de notícias da AWS, então a informação é amplamente controlada pelo fornecedor. Ainda assim, é notável porque a monday.com está descrevendo não apenas o uso de modelos, mas os sistemas, filas, camadas de armazenamento, fluxos de revisão e salvaguardas operacionais necessários para permitir que agentes internos de IA interajam com Slack, GitHub e workflows da monday em produção. Para construtores de IA e compradores corporativos, a relevância está menos em um benchmark e mais nas escolhas de arquitetura por trás de confiabilidade, replay, auditabilidade e supervisão humana.

De acordo com a descrição da AWS sobre a configuração da monday.com, a empresa organiza seus “AI Teammates” internos em três níveis. Na primeira camada, humanos usam ferramentas de codificação com IA como assistentes. Na segunda, as equipes criam skills reutilizáveis e subagentes para trabalho recorrente. Na terceira, os agentes assumem tarefas de entrega ponta a ponta enquanto os humanos orquestram e revisam. A AWS diz que o sistema interno da monday.com, chamado Sphera, dá aos agentes identidades estáveis entre sistemas para que possam receber trabalho, ser revisados ou ser desativados de maneiras que lembram colegas de equipe humanos.

Do assistente de codificação ao fluxo de trabalho de agente gerenciado

A parte mais interessante da descrição da monday.com é que ela enquadra a adoção de IA como uma progressão operacional, e não como um único lançamento de produto. A AWS diz que a monday.com usa o Cursor para tarefas rápidas de programação em dupla e o Claude Code para trabalhos de engenharia mais pesados, o que a empresa categoriza como sua camada de assistente L1. Depois, avança para agentes internos reutilizáveis em L2 e para entrega com múltiplos agentes em L3.

Isso importa porque muitas implantações corporativas de IA travam entre experimentos de “copilot” e automação em produção. O relato da monday.com sugere que a lacuna não é resolvida apenas por modelos melhores. Ela é resolvida ao envolver o acesso ao modelo em uma camada de orquestração que entende atribuição de trabalho, memória de sessão, uso de ferramentas, revisão de código, replay e tratamento de falhas.

No sistema da monday.com, um agente pode ser acionado por três canais: uma menção no Slack, uma atribuição de item na monday ou uma solicitação de revisão de pull request no GitHub. A AWS diz que todos os três caminhos chegam à mesma sessão do agente, compartilhando a mesma memória e o mesmo workspace em disco. Esse design parece destinado a evitar contexto fragmentado entre diferentes ferramentas de colaboração.

O agente central destacado no post, chamado Atlas, é descrito como um agente engenheiro de software que pode pegar tickets, escrever pull requests e entregar recursos. A AWS apresenta o Atlas como um membro de uma estrutura de equipe mais ampla dentro do Sphera, onde os agentes têm papel, escopo, gestor e pontuação de desempenho definidos. Esse enquadramento pode parecer apenas cosmético, mas a monday.com diz que ele faz parte do esquema operacional de como os agentes são endereçados e governados.

Por que a stack da AWS importa aqui

A arquitetura divulgada pela monday.com é notável em parte porque não é uma única plataforma monolítica de agentes. Em vez disso, a AWS diz que a monday.com construiu um sistema em camadas sobre serviços de nuvem padrão, com o Amazon Bedrock lidando com o acesso aos modelos e uma stack mais ampla de eventos e armazenamento fazendo a maior parte do trabalho operacional.

Segundo o post, os gatilhos externos primeiro chegam ao Amazon SNS, que então distribui mensagens para filas do Amazon SQS. Consumidores executando no Amazon EKS retiram as mensagens, resolvem qual agente deve assumi-las e entregam o trabalho a um pod executor de agentes. A monday.com diz que essa configuração de pub/sub mais filas lhe dá retries, dead-letter queues, back-pressure quando o Amazon Bedrock limita a taxa, replay durável para testar builds corrigidos e fan-out concorrente.

Esse é um ponto importante para equipes que planejam agentes de IA em produção. A parte difícil muitas vezes não é gerar código ou texto. É gerenciar cargas de trabalho em rajadas, reexecutar jobs após falhas, rastrear o que aconteceu e se recuperar com segurança quando dependências ou endpoints de modelo ficam indisponíveis. A arquitetura da monday.com mostra uma preferência por padrões de infraestrutura chatos, mas comprovados.

A empresa também diz que envolve o Claude Agent SDK em vez de depender dele diretamente. A AWS atribui três razões a essa decisão da monday.com: preservar a neutralidade em relação ao provedor no ponto de chamada por meio do Amazon Bedrock, reduzir a latência de cold start com caches pré-aquecidos e manter o controle da camada que chama de “harness”, onde vivem a avaliação, a composição de plugins, as comunicações e a lógica de revisão. Esse é um sinal útil para construtores. Sugere que o runtime do modelo pode ser intercambiável, enquanto o plano de controle e a lógica do workflow se tornam a vantagem interna durável.

Armazenamento, memória e as escolhas de engenharia menos glamourosas

Uma segunda lição da divulgação é que sistemas de agentes precisam de vários tipos de estado, e esses estados não devem ficar em um único banco de dados.

A AWS diz que a monday.com mantém o estado ativo — como tarefa atual, heartbeat, locks e logs de mensagens — no Amazon ElastiCache para acesso de baixa latência. A memória de sessão e os arquivos de trabalho são armazenados no Amazon EFS, enquanto registros duráveis, como transcrições, artefatos, snapshots e avaliações, vão para o Amazon S3. O Amazon RDS aparece entre os serviços usados, embora o trecho do post não detalhe seu papel específico. O AWS Secrets Manager é usado para tratamento de segredos por sessão.

Essa divisão importa porque muitos protótipos de agentes tratam memória como uma única abstração. Na prática, agentes de codificação precisam de algo mais próximo de um sistema distribuído convencional: estado efêmero rápido, um sistema de arquivos compartilhado para ferramentas que esperam semântica POSIX e armazenamento de longo prazo para auditorias e evidências.

A AWS diz que a monday.com escolheu o Amazon EFS em vez de armazenamento de objetos para sessões ativas porque o Claude Agent SDK e ferramentas comuns de desenvolvedor como git e npm esperam um sistema de arquivos real. Isso também permite que uma sessão seja retomada em um pod diferente no Amazon EKS ao montar o mesmo caminho. É uma escolha pragmática e reflete a realidade de que agentes de software muitas vezes dependem das mesmas suposições de arquivos e processos que desenvolvedores humanos.

Para equipes corporativas de IA, este é um dos aspectos mais críveis da história. Ele vai além do atalho de marketing de “memória” e mostra que workspaces persistentes, retomada e ambientes de ferramentas determinísticos são centrais para a confiabilidade dos agentes.

Evidências, alegações e o que ainda não foi verificado

Como o material de origem vem da AWS e do AWS Machine Learning Blog, as alegações mais fortes de desempenho e adoção devem ser tratadas como relatadas pelo fornecedor. A AWS diz que todos os números do post vêm dos dados internos de produção da monday.com.

Essas alegações incluem que nove em cada dez builders da monday.com usam ferramentas de codificação com IA todos os meses, ante cerca de metade há seis meses, e que o throughput de pull requests por engenheiro aumentou em mais da metade. A AWS também diz que essa camada L2 de skills e subagentes é onde a maior parte da monday.com opera atualmente.

Essas são alegações relevantes, se precisas, mas os leitores devem notar o que não é fornecido nas evidências disponíveis. Não há metodologia independente, não há denominador bruto para “builders”, não há período de base além de uma linguagem relativa ampla, e não há detalhamento de se um throughput maior de pull requests se traduziu em melhor tempo de ciclo, menos incidentes ou diferentes cargas de revisão. Tampouco o material quantifica custo, taxas de defeito ou com que frequência revisores humanos rejeitam ou reescrevem a saída dos agentes.

Da mesma forma, a AWS diz que o Amazon Bedrock ajuda a monday.com a manter rastreamento de custos, planejamento de capacidade e trilhas de auditoria de chamadas ao modelo em um só lugar por meio de mecanismos como Application Inference Profiles. Isso é plausível como benefício de plataforma, mas a evidência aqui continua descritiva e não comparativa. Não há benchmark direto contra caminhos alternativos de implantação.

Ainda assim, o post é mais forte do que muitos estudos de caso de IA porque dedica mais tempo ao design do sistema do que a alegações abstratas de transformação. A ausência de validação independente não apaga o sinal arquitetônico; apenas limita o peso que compradores devem dar aos números de produtividade.

O que isso significa para construtores e compradores corporativos

Para equipes de software, o exemplo da monday.com aponta para uma divisão prática na stack de IA. Produtos como Cursor e Claude Code podem melhorar rapidamente a produção individual de desenvolvedores, mas escalar além da assistência pessoal exige uma infraestrutura muito mais próxima de engenharia de plataforma do que de engenharia de prompts.

Para compradores corporativos de IA, o caso lembra que implantar agentes de IA em organizações de software voltadas ao cliente impõe requisitos mais difíceis do que lançamentos de chatbots. Agentes que abrem pull requests ou atuam sobre tickets precisam de identidade durável, permissões delimitadas, observabilidade, caminhos de reversão, pontos de verificação de revisão e detalhe de auditoria suficiente para satisfazer as equipes de segurança e conformidade.

A história também torna mais nítido o enquadramento competitivo em torno do Amazon Bedrock. A AWS está posicionando o serviço não apenas como acesso ao modelo, mas como um ponto de controle para capacidade, governança e contabilização de custos em muitos agentes. Essa proposta provavelmente ressoa com empresas já padronizadas na AWS, especialmente as que querem opcionalidade de modelos sem construir sua própria camada de gateway do zero.

Ao mesmo tempo, o próprio design da monday.com sugere que os serviços de nuvem, sozinhos, não resolvem o problema central do workflow. A camada diferenciadora é o harness interno: roteamento, avaliação, lógica de plugins, política de revisão e integração específica da equipe com Slack, GitHub e a própria monday. Empresas comprando plataformas de agentes precisarão decidir quanto desse harness desejam possuir.

O que observar a seguir

O próximo sinal a observar é se a monday.com ou a AWS fornecem evidências mais fortes sobre qualidade de software e custo operacional, e não apenas métricas de atividade. Volume de pull requests é útil, mas compradores corporativos vão querer ver dados sobre taxas de incidentes, frequência de rollback, tempo de revisão e exceções de segurança.

Um segundo sinal é se a monday.com amplia a autonomia dos agentes além dos fluxos internos de engenharia. Se os agentes puderem migrar com segurança do suporte à codificação para tarefas mais amplas de produto e operações, isso fortaleceria o argumento de que sistemas multiagentes estruturados podem se tornar um padrão corporativo geral.

Terceiro, vale observar se a AWS transforma essa arquitetura em orientações mais productizadas ou recursos em torno do Amazon Bedrock, Amazon EKS e ferramentas de orquestração. A descrição atual ainda implica uma quantidade significativa de engenharia personalizada pela monday.com.

Por fim, será útil acompanhar se concorrentes publicam histórias de produção igualmente detalhadas. O mercado tem muitas alegações sobre agentes de IA, mas relativamente poucos relatos que expliquem como os agentes realmente mantêm contexto, se recuperam de falhas e passam por revisão humana em uma stack corporativa viva.

Perspectiva da Creati.ai

A verdadeira notícia aqui não é que a monday.com usa IA para codificação. Muitas empresas usam. O desenvolvimento mais importante é que a monday.com está descrevendo um modelo operacional de produção para agentes de IA que os trata como trabalhadores gerenciados dentro de sistemas existentes de entrega de software, com filas, sistemas de arquivos, trilhas de auditoria e limites explícitos de revisão.

É para isso que o mercado corporativo de IA está caminhando. Os vencedores não serão as equipes com as demonstrações mais chamativas, mas aquelas que conseguirem tornar os agentes de IA legíveis para gerentes de engenharia, equipes de segurança, equipes financeiras e operadores de plantão. A arquitetura da monday.com, כפי apresentada pela AWS, sugere que a adoção de agentes se torna crível quando é construída primeiro como infraestrutura e depois como inteligência.