A CrossnoKaye fez o agente de IA das fábricas calcular em uma sandbox Python, e não na cabeça do LLM

Se você já tentou acoplar um agente LLM a um sistema industrial, sabe como isso costuma terminar. Os dados ficam em historians (bancos de séries temporais) com nomes de tags confusos. A lógica dos equipamentos está embutida em código proprietário dos controladores, que uma ferramenta externa não enxerga. E dar acesso a todos os sistemas de uma vez significa espalhar credenciais pela rede da fábrica. A CrossnoKaye resolveu o problema sem "encaixar" o agente pelo lado de fora: ela o integrou à sua própria plataforma.

Agente dentro da plataforma, não fora dela

A ATLAS é uma plataforma de automação definida por software. Na planta, roda um cluster Kubernetes local, que executa os cenários básicos de controle (máquinas de estado, sequências, limites, intertravamentos) sobre os CLPs e DCS já existentes. O cliente não precisa trocar o hardware. O gateway de borda apenas envia dados para fora e não abre nenhuma porta de entrada. Se a conexão com a nuvem cai, a fábrica continua operando com a lógica local.

O agente AURA vive no mesmo perímetro de segurança, no Amazon EKS. Ele lê o estado da fábrica por um gateway de dados único, com as permissões do usuário que faz a chamada. Ali estão a topologia dos equipamentos, a lógica de intertravamento já expandida, as leituras físicas e calculadas, o histórico de alarmes e a documentação no Bedrock Knowledge Bases.

O contexto faz muita diferença. Em uma pedreira, o britador secundário parou duas vezes em um turno depois do terciário. Pelos timestamps, parecia que o culpado era o britador secundário. Mas a AURA via o esquema das correias e os intertravamentos. A correia de recirculação sob o britador terciário patinava, a proteção contra sobrecarga disparava, e o intertravamento a montante desligava o secundário para não despejar material sobre um equipamento parado. O operador foi enviado até a correia, e o problema foi resolvido em minutos.

Quem calcula é o código, não o modelo

O LLM interpreta bem o contexto de engenharia e planeja a investigação, mas não consegue calcular de forma confiável estatísticas ou balanços sobre milhões de leituras dentro do prompt. Por isso a AURA escreve Python e o executa no Code Interpreter do Amazon Bedrock AgentCore. São microVMs isoladas, gerenciadas pela AWS. Além delas, entram o Bedrock Guardrails e camadas de proteção na borda.

Duas decisões daqui são úteis também fora da indústria.

Sandboxes quentes e descartáveis. No chat interativo, o engenheiro testa hipóteses passo a passo: carrega um dia de alarmes de 94 plantas, filtra sensores de nível que "trepidam" e cruza os desligamentos de compressores com a temperatura de bulbo úmido. Um cold start a cada turno apagaria as tabelas da memória.

Por isso, cada conversa fica ligada a uma única sessão ativa do AgentCore, com TTL deslizante de 15 minutos; se o usuário volta depois de uma pausa, uma nova sessão é criada. Para as Tasks agendadas e as Routines noturnas, é o contrário. Como é preciso reprodutibilidade, cada execução roda em uma microVM nova, que é encerrada logo após o cálculo.

Isso evita vazamento de estado entre execuções e o custo de uma sandbox ociosa.

Contratos de dados em vez de texto do stdout. As primeiras versões, em que o modelo imprimia JSON ou um resumo na saída padrão, se mostraram frágeis. O modelo confundia nomes de colunas, perdia parte da janela de tempo ou quebrava o formato usado para gerar gráficos.

Agora o orquestrador valida o contrato de entrada com antecedência e coloca na sandbox até 50 conjuntos de dados. Ao script do modelo, ele acrescenta um wrapper de verificação, que confirma que cada tabela declarada existe como pandas.DataFrame, com as colunas e os tipos esperados, e a salva em Parquet.

Se o script falha ou falta uma coluna, o usuário não vê números errados. Um workflow no Temporal transforma o traceback e a incompatibilidade de schema em uma solicitação estruturada, e o agente corrige o código e reinicia o cálculo.

O que isso entrega na prática

Um exemplo com a frota: ao analisar as falhas críticas de 94 plantas em um dia, o código agrupou os eventos por unidade, regra e intervalo entre disparos. Em vez de um ranking por número de alarmes, o resultado mostrou que as 103 ativações em uma fábrica eram duas regras repetidas de nível em um tanque. Em outra, 58 ativações (amônia, evaporadores, válvulas de gás quente) couberam em um segundo. É justamente ali que está a falha em cascata dos equipamentos.

A AURA também executa Routines, observadores em segundo plano que funcionam por agenda, limites e modos de operação dos equipamentos. Eles abrem a investigação por conta própria, em modo somente leitura. Antes de enviar um relatório (Brief), o sistema verifica se cada link nele aponta para uma janela de telemetria salva.

Limitações e conclusão

Os números sobre aumento de produção de 11–17%, redução de 21% no consumo de energia e zero incidentes de segurança por milhão de horas são declarações da própria CrossnoKaye. Eles se referem a toda a plataforma APC, e não ao agente isoladamente. A descrição também está muito atrelada à stack da AWS: VPC Lattice, MSK, SQS, EKS, AgentCore. Vale lembrar ainda que, na CrossnoKaye, essa arquitetura roda sobre uma plataforma pronta, com um modelo único da fábrica, e a maioria das empresas não tem esse alicerce.

Há três lições gerais. Primeiro, o agente precisa de acesso à estrutura do sistema, e não só aos logs. Segundo, convém calcular qualquer afirmação numérica em um ambiente isolado. Terceiro, é melhor aceitar o resultado da sandbox apenas por meio de um schema e de um validador, devolvendo o erro ao agente para que ele se corrija sozinho. Essas práticas servem também para finanças, logística e qualquer análise em que um erro de número custa caro.