Os 22 agentes da Bayer não rodam os modelos de melhoramento. Eles explicam o que aconteceu

Um melhorista olha o output de um modelo para um ensaio de milho e ele não bate com o da safra passada. Os dados de entrada eram outros? Alguém mudou a configuração? A execução falhou no meio e reiniciou? Até pouco tempo, na Bayer Crop Science, responder a isso significava achar um engenheiro, que passaria boa parte de uma hora entre APIs, documentação, repositórios de metadados, dashboards e logs.

Esse é o problema que a Bayer descreveu em um estudo de caso publicado pela AWS em 23 de outubro. Vale a pena estudar porque os agentes que ela construiu não tomam decisões de melhoramento e não rodam os modelos. Eles explicam o que a plataforma existente fez.

A plataforma já funcionava. Entendê-la é que não

O Connected Decision Engine da Bayer faz o deploy, a orquestração e o monitoramento de workflows de machine learning para o melhoramento genético de plantas, com mais de 500 configurações de modelo entre culturas, regiões e times de pesquisa. Ele mantém o histórico de execução e os controles operacionais. Seus usuários são melhoristas, analistas, pesquisadores, cientistas de dados e engenheiros de dados.

Rodar os workflows já não era o gargalo. Entendê-los era. Cada pergunta exigia saber qual de vários sistemas guardava a resposta, e as pessoas que sabiam eram engenheiros cujo tempo ia para explicar em vez de construir.

A nova camada: um supervisor e 22 especialistas, todos somente leitura

O Agentic Decision Engine fica ao lado da plataforma existente, não dentro dela. Um agente supervisor construído com LangGraph classifica cada pergunta e a encaminha para um dos 22 agentes especialistas, combinando resultados quando a pergunta atravessa domínios. Exemplos: um especialista de domínio que busca na documentação, um agente operacional que lê o status dos workflows em tempo real, um agente de diagnóstico que lê a telemetria do CloudWatch e um agente de visualização que desenha gráficos em um interpretador de código em sandbox.

As escolhas de infraestrutura merecem atenção:

• Ferramentas por um gateway. Cerca de 20 APIs da plataforma são expostas como ferramentas MCP pelo Amazon Bedrock AgentCore Gateway, o que, segundo a Bayer, cortou o esforço de integração por API em mais de 99%.
• Identidade em cada fronteira. Os usuários se autenticam com o Microsoft Entra ID; as chamadas de serviço usam IAM. Cada agente recebe um catálogo de ferramentas com escopo definido: o agente de documentação não consegue chamar APIs da plataforma que não tenham relação com a sua função.
• Somente leitura por design. O agente de diagnóstico “pode ler os dados operacionais de que precisa para o diagnóstico, mas não pode modificar workflows”.
• Estado fora do runtime. Os checkpoints de orquestração ficam no DynamoDB, não na sessão do agente.

A Bayer relata que, na primeira fase, o sistema resolve cerca de 80% das perguntas dos usuários sem um engenheiro, e que diagnosticar uma falha caiu de mais de uma hora para menos de dez minutos. São números relatados pelo cliente em um relato publicado pelo fornecedor; o artigo não define o que é “resolvido” nem descreve um método de avaliação. Mais de 100 usuários já usaram o sistema em um lançamento com acesso restrito.

Cinco decisões que outros times podem copiar

As lições que a Bayer lista são mais transferíveis do que o diagrama de arquitetura:

1. Persistir o estado de orquestração fora do runtime. Uma sessão que termina não deveria levar a investigação com ela.
2. Tratar o modelo como um contrato de interface. Quando um modelo mais novo, com modo de raciocínio, quebrou o tool calling e a saída estruturada, o time manteve o atual para o lançamento. Trocar de modelo é uma mudança a ser testada, não uma substituição direta.
3. Definir o escopo das ferramentas por agente. Catálogos menores significam menos tokens e menos escolhas erradas, além de um raio de impacto menor.
4. Promover uma ferramenta a agente só quando ela assume estado, retentativas ou apresentação. Nem toda capacidade precisa de um agente próprio; os 22 são consequência dos domínios da plataforma, não uma meta.
5. Medir o sucesso da tarefa, não o sucesso do transporte. Um agente que devolve uma resposta bem formatada para a pergunta errada é uma falha que nenhum dashboard de uptime vai mostrar. Fizemos o mesmo ponto sobre avaliar o que o agente fez, não o resumo dele.

Por que a escolha de somente leitura é a lição de verdade

É tentador ler isso como uma história sobre arquitetura multiagente. É mais útil como uma história sobre onde começar. O primeiro agente em produção sobre um sistema complexo não precisava de permissão para mudar nada, então as perguntas que costumam travar projetos de agentes (quem aprova uma ação, como fazer o rollback, quem responde) não apareceram. O que ele precisava era de acesso ao histórico: metadados de execução, configuração, logs, documentação.

Isso bate com o que vemos em agentes de operações, cujo diagnóstico é um ponto de partida e não um achado, e nos nossos cinco testes para trabalho pronto para agentes dentro de processos existentes. Uma camada de explicação tem valor por si só, e também produz a evidência que qualquer um iria querer antes de deixar um agente agir: quais perguntas ele responde bem, onde as fontes são rasas e quais dados a plataforma nunca registrou. A próxima fase da Bayer, interoperabilidade de agentes entre ambientes híbridos, vai testar até onde essa base leva.