Abordagem de "malha de agentes" para a modernização de sistemas legados com o Red Hat AI

O software legado não se aposenta por conta própria. Ele reside em produção, acumulando dívida técnica, resistindo a mudanças e tornando-se silenciosamente um risco — não pelo que faz, mas pelo que não consegue mais oferecer suporte.

Esse é o desafio enfrentado pelos principais integradores de sistemas (SIs) que trabalham em apoio ao governo e à indústria. Em um portfólio de aplicações de missão crítica, SIs e empresas aeroespaciais gerenciam bases de código Python e Java antigas que precisam migrar para uma base moderna, focada em segurança e passível de suporte — especificamente o Red Hat Enterprise Linux 10 (RHEL 10).

O objetivo não é apenas uma atualização de software. Trata-se de manter a velocidade da entrega de software, a velocidade da IA e a postura de segurança das quais dependem os data centers governamentais, as áreas de missão em campo ou os sistemas móveis em aeronaves.

Isso não é algo apenas teórico para o governo federal dos EUA. O framework de governança de IA do GSA e o Departamento de Guerra (DoW) agora exigem que agências e serviços operacionalizem a IA responsável, em vez de apenas adotá-la. Para as partes interessadas de defesa e missão, esse mandato não é apenas uma formalidade; é uma função propulsora para ajustar a fábrica de software antes de confiar aos agentes nela contidos qualquer tarefa importante. 

Durante um compromisso recente, um dos requisitos obrigatórios era a compatibilidade offline total. Ambientes que apoiam a segurança nacional muitas vezes não têm acesso à internet por design. Qualquer dependência de um serviço externo (GitHub, uma API de nuvem, um registro de pacote remoto) é uma dependência que pode se tornar uma vulnerabilidade, um ponto de falha ou deixar o sistema totalmente em não conformidade. 

Modernizar o sistema manualmente era tecnicamente possível, mas o esforço de engenharia estimado se estenderia por anos de mão de obra, tornando o projeto inviável na escala necessária. A alternativa era não fazer nada e continuar operando sistemas legados com riscos operacionais crescentes. Surgiu então a questão: existiria um terceiro caminho? Poderíamos criar um processo mais eficiente utilizando automação por agentes, permitindo que engenheiros supervisionassem a modernização em escala em vez de realizar cada etapa manualmente?

Descobrimos que sim, e criamos uma plataforma de agentes utilizando o Red Hat AI e o Red Hat OpenShift AI.

O problema da modernização de sistemas legados em escala

A migração brownfield — mover código de produção real (e não uma prova de conceito (POC) greenfield) — é fundamentalmente diferente de criar algo novo. Não basta apenas enviar um prompt para uma IA e considerar o trabalho concluído.

Geralmente, as bases de código legadas apresentam as seguintes características:

• Arquiteturas legadas: sistemas projetados sob suposições, frameworks e infraestrutura que refletem as normas de engenharia de épocas anteriores.
• Cobertura de testes limitada ou irregular: grande parte da base de código foi escrita antes de os testes automatizados se tornarem uma disciplina padrão.
• Contratos comportamentais implícitos: dependências entre módulos e serviços que existem na prática, mas que nunca foram formalmente documentadas ou aplicadas.
• Dívida técnica acumulada: camadas de soluções alternativas, bibliotecas obsoletas e correções de compatibilidade que gradualmente se tornaram parte do sistema de produção.

Para missões de segurança nacional, as consequências de errar não são abstratas. Uma migração malfadada não apenas interrompe uma aplicação; ela pode paralisar um fluxo de trabalho, atrasar uma missão ou introduzir uma vulnerabilidade de segurança em infraestruturas que protegem pessoas.

Este é exatamente o ambiente em que grandes modelos de fronteira de uso geral que operam por trás de uma API de nuvem não são uma opção. Não se pode enviar código confidencial para um endpoint externo. Você não pode tolerar comportamentos de inferência imprevisíveis em escala. Mesmo que você consiga se conectar a modelos de fronteira de nuvem, não há como justificar o volume de tokens e o overhead de computação. Isso ocorre quando as solicitações se expandem em longas cadeias de raciocínio em espaços de parâmetros massivos. Na escala de migração, onde os sistemas contêm milhões de linhas de código, isso se traduz rapidamente em latência, custos de infraestrutura e maior risco operacional.

Modelos pequenos e eficientes são o instrumento certo

O instinto na maioria das aplicações de IA é buscar o maior modelo disponível. Mais parâmetros, mais contexto, melhores respostas. Essa lógica se desfaz rapidamente em ambientes desconectados, de missão crítica e com recursos limitados. Grandes modelos de fronteira costumam introduzir latência excessiva e loops de raciocínio imprevisíveis. Além disso, geram altas demandas de memória de GPU, difíceis de atender em infraestruturas controladas.

Small Language Models (SLMs) são ideais para fluxos de trabalho baseados em agentes, pois esses sistemas exigem execução confiável e respostas de baixa latência, não apenas a escala bruta do modelo. Modelos menores podem oferecer um comportamento rápido e determinístico que funciona bem para tarefas de automação, como chamada de ferramentas, orquestração e raciocínio estruturado. Eles também são mais fáceis de ajustar e operar localmente, permitindo que as equipes implantem frotas de agentes específicos do domínio sem depender de endpoints externos. Em outras palavras, quando um modelo "conhece" apenas um domínio, a distribuição de probabilidade se torna mais precisa e ele tende a produzir a mesma resposta com mais frequência.

Dito isso, nossos testes revelaram que a capacidade do modelo ainda tem forte correlação com a janela de contexto e a contagem de parâmetros, principalmente em tarefas de migração de código que exigem compreensão de grandes sistemas de software. Os modelos com melhor desempenho nos testes iniciais foram as variantes do Llama 4 e os modelos Claude. Isso se deve às janelas de contexto amplas (> 256 mil tokens) e à forte capacidade de raciocínio. Por outro lado, descobrimos que o Claude às vezes analisava demais tarefas simples de engenharia, produzindo cadeias de raciocínio longas e desnecessárias que aumentam o uso de tokens e a latência. Na escala de migração, esse comportamento resulta rapidamente em custos de computação significativos.

Por esse motivo, no momento, estamos executando o Meta Maverick localmente, com testes paralelos utilizando modelos Mistral devido aos requisitos de memória de GPU dos modelos maiores. Também estamos reavaliando o Llama 4 Scout, que apresenta bom desempenho, mas também desafia os limites da computação disponível no ambiente atual.

Como solução prática, implementamos uma estratégia de modelo híbrido que utiliza modelos menores ao refatorar fluxos de trabalho para mitigar limitações de contexto.

Nossas seleções de modelos atuais para o harness de agentes:

• mistralai/Devstral-Small-2-24B-Instruct: designado para agentes de codificação. Contexto de 256 mil tokens, desempenho sólido em benchmarks de codificação e otimização para análise de software e tarefas de refatoração.
• mistralai/Ministral-3-14B-Reasoning: designado para agentes não codificadores. Contexto de 256 mil tokens, eficácia para raciocínio estruturado, análise de dependências e orquestração em fluxos de trabalho de migração.

Além dos modelos de agente, o sistema utiliza modelos especializados para indexação e recuperação de conhecimento:

• gpt-oss-120B: Cria o gráfico de conhecimento GraphRAG que representa a estrutura global da base de código.
• intfloat/e5-mistral-7B-instruct: Modelo de embedding usado para indexação do GraphRAG e recuperação vetorial.

Essas escolhas não foram concessões. Foram decisões de engenharia específicas para o objetivo, com base no ambiente de computação disponível. As limitações de contexto encontradas dependem da capacidade da GPU, não da arquitetura em si. Conforme a infraestrutura escala, a estrutura do agente e a estratégia de seleção de modelos acompanham esse crescimento.

A arquitetura de malha de agentes: Uma "estrutura de estruturas" de agentes de IA baseada no OpenShift AI

A base desta plataforma é uma estrutura de agentes de IA, um framework de orquestração modular que coordena vários agentes de IA especializados, cada um responsável por uma parte específica do fluxo de trabalho de migração. Essa estrutura roda no OpenShift AI e utiliza o vLLM para oferecer uma inferência de modelos eficiente e de baixa latência. Com o tempo, esse padrão evolui para o que chamamos de agent mesh — uma arquitetura de "estrutura de estruturas" onde múltiplos fluxos de trabalho de agentes de IA podem interoperar, coordenar tarefas e compartilhar estados em programas complexos de modernização.

Veja o que a arquitetura está fazendo hoje:

Os agentes de codificação — equipados com Devstral — analisam o código-fonte legado em Python 2 ou Java, identificam APIs obsoletas, geram equivalentes refatorados e criam testes de caracterização que capturam o comportamento original antes de qualquer mudança. Eles não apenas traduzem a sintaxe, mas preservam a intenção comportamental.

Agentes de tarefas não relacionadas a código — equipados com Ministral — realizam tarefas de raciocínio em todo o fluxo de trabalho, incluindo mapeamento de dependências, planejamento de migração e acompanhamento de progresso. A lógica de orquestração determinística rege o fluxo de execução, permitindo que os agentes coordenem as etapas de migração, validação, bloqueio e as próximas ações.

Um agente personalizado de gerenciamento de rastreamento gerencia a integração com o GitLab (e pode ser totalmente substituído em ambientes desconectados). Este componente consiste em código totalmente inspecionável em vez de uma "caixa-preta", o que permite que as organizações integrem a estrutura aos seus sistemas de desenvolvimento e governança.

A estrutura em si foi projetada para ser modular e substituível, combinando agentes personalizados com agentes open source, como o OpenCode. Quando as organizações questionam se o sistema é uma caixa-preta, a resposta é complexa: a camada de inferência do LLM, como qualquer rede neural, é inerentemente opaca. No entanto, a lógica de orquestração, o código do agente, os resultados e as trilhas de decisão são totalmente rastreáveis, auditáveis e inspecionáveis. Isso é essencial para organizações que operam sob os requisitos de segurança e garantia do DoW.

O vLLM, que atua como mecanismo de inferência no OpenShift AI, é um facilitador essencial. Uma inferência eficiente vai além da otimização de desempenho: em ambientes com recursos limitados de GPU, ela viabiliza os fluxos de trabalho multiagentes. A entrega otimizada do vLLM permite que a plataforma processe os ciclos de raciocínio iterativos necessários para a migração sem esgotar os recursos computacionais em uma única tarefa.

Conforme surgem novas estruturas de agentes de IA para tarefas adjacentes, como testes, revisão de segurança ou validação de implantação, elas podem se interconectar via agent mesh. Isso permite uma automação coordenada em todos os pipelines de modernização.

O fluxo de trabalho da migração: Python primeiro, Java em seguida

A fase inicial deste projeto foca na migração do Python 2 para o Python 3, servindo como entrega real e validação do framework. O Python 2 atingiu o fim da vida útil em 2020. Os sistemas que ainda o utilizam operam com vulnerabilidades não corrigidas e sem suporte upstream. Para sistemas governamentais e empresariais, isso não é um risco teórico.

Nossa hipótese, validada nos testes, é que o custo da migração aumenta proporcionalmente à complexidade da dependência externa. Aplicações fortemente acopladas a pacotes de terceiros obsoletos exigem significativamente mais iterações de agentes de IA para uma migração limpa. Isso orientou o design do modelo: menos subtarefas de agentes de IA por fluxo, escopo mais restrito por iteração e etapas de validação mais determinísticas entre elas.

Meta de 30 dias: 80% de cobertura de teste, sem necessidade de dependência do GitLab, equivalência funcional validada entre as versões Python 2 e Python 3.

Figura 1: Fluxo de trabalho da fábrica de software de agentes de IA composto por agentes de codificação, agentes de não codificação e ferramentas no OpenShift AI.

O roadmap de 30/60/90 dias passa a focar na migração de Java para as versões do OpenJDK e Corretto (7, 8, 11, 17, 21) em direção ao Java 25, com caminhos de migração que variam dependendo se o ambiente de destino é RHEL 8 ou RHEL 9/10. Vale ressaltar que essa não é uma solução mágica ou universal. O framework de agentes de IA é um ponto de partida, e cada agente nele é criado especificamente para uma tarefa no fluxo de trabalho de migração, o que o torna extensível para Java sem precisar reconstruir tudo do zero.

Meça o que realmente importa: KPIs de brownfield

Muitos KPIs de desenvolvimento de software tradicionais e de agentes de IA são escritos para o desenvolvimento greenfield. Eles presumem que você conhece a arquitetura, tem acesso à documentação e está criando algo novo. Recompensam a velocidade.

Na migração de legado brownfield, velocidade sem correção não é sucesso, é a geração de dívida técnica na velocidade da IA.

O framework de KPIs que definimos para esse engajamento é estruturado em torno de três perguntas:

Funciona? Taxa de equivalência funcional, taxa de aprovação em testes de integração, taxa de falha de alteração. Essas são métricas de aprovação ou reprovação. Se o código refatorado não produzir saídas idênticas às do original com as mesmas entradas, nada mais importa.

Entendemos como funciona? Taxa de aceitação do desenvolvedor, delta de cobertura de teste, taxa de conclusão da migração. Uma migração não termina quando o código é executado. Ela está concluída quando os desenvolvedores responsáveis por ela podem ler, confiar e manter o código.

A equipe pode assumir a solução a longo prazo? Pontuação de confiança do desenvolvedor, tempo para a primeira contribuição, ganho de capacidade do desenvolvedor. A métrica final de retorno sobre o investimento (ROI) não é o custo de tokens por tarefa. É o tempo que a equipe de engenharia recupera do trabalho repetitivo de migração para se concentrar em contribuições de maior valor para a missão.

Métricas de velocidade — taxa de transferência, latência de iteração, ações do agente por minuto — pertencem a um painel de engenharia para o ajuste do sistema. Elas não devem constar em uma revisão de programa como indicadores de sucesso.

O que o Red Hat AI e o OpenShift AI tornam possível

Nada disso funciona sem uma plataforma que realmente ofereça suporte. OpenShift AI fornece a camada fundamental para tudo o que foi descrito aqui:

• Serviço de modelos com vLLM: inferência eficiente e escalável para os modelos de codificação e raciocínio que alimentam a estrutura de agentes.
• Fluxos de trabalho de personalização de modelos: oferece suporte a ajuste fino, LoRA e quantização para modelos que precisam ser executados em ambientes com recursos limitados.
• Suporte a clusters desconectados: a plataforma foi projetada para execução em ambientes sem acesso à internet, o que é um requisito básico aqui.
• Logs de auditoria e observabilidade: a rastreabilidade e a explicabilidade exigidas pelos stakeholders da missão, integradas à plataforma em vez de adicionadas posteriormente.
• Arquitetura modular e em containers: os agentes são baseados em containers, intercambiáveis e podem ser implantados por meio da infraestrutura existente do OpenShift, que integradores de sistemas, empresas aeroespaciais e o governo federal já conhecem.

Figura 2:  Componentes e recursos para a criação de agentes com Red Hat AI.

A adição do RHEL 10 como o ambiente de execução de destino não é acidental. O RHEL 10 traz fortalecimento de segurança, suporte de runtime atualizado para Python e Java modernos e a confiabilidade operacional que os sistemas governamentais exigem. A migração para ele não é apenas uma decisão de ciclo de vida de software, mas sim uma decisão de segurança e prontidão para a missão.

O padrão mais amplo: Malha de agentes em todas as áreas de missão

Este engajamento é um exemplo único de algo que esperamos repetir na base industrial de defesa, no governo federal e no setor em geral. Os ambientes de software legados são enormes. Os recursos de engenharia para migrá-los manualmente não existem na escala que o problema exige. E a janela de segurança para a execução de softwares sem suporte está se fechando.

Os agentes de IA no OpenShift AI multiplicam a capacidade das equipes de engenharia, acelerando a modernização de código de anos para uma fração do tempo, com rigor e rastreabilidade.

Nesse modelo, estruturas de agentes coordenam agentes especializados para realizar tarefas de modernização distintas. À medida que essas estruturas se expandem para funções adjacentes (por exemplo: testes, análise de segurança e validação de implantação), elas começam a formar uma malha de agentes: uma arquitetura de "estrutura de estruturas" que coordena fluxos de trabalho de engenharia complexos em grandes ambientes de software.

Os agentes realizam trabalho repetitivo. A equipe de engenharia cuida da arquitetura, da supervisão, das avaliações de agentes e do tratamento de exceções. Essa divisão de trabalho é o modelo.

Modelos pequenos. Inferência eficiente. Agentes modulares. Operação desconectada. Modernização do sistema alinhada à missão.

Considerações finais

Modelos de fronteira são mecanismos de raciocínio extraordinários. Plataformas de agentes de IA criadas para fins específicos são instrumentos de missão.

Para agências governamentais, não se trata de adotar a última tendência de IA. Trata-se de ter a infraestrutura e os recursos de IA para manter os sistemas críticos seguros, modernos e a serviço da missão.

Estamos criando isso com o Red Hat AI.

Leia mais

• Red Hat AI
• Red Hat OpenShift AI