Quando o framework de agentes de IA não é suficiente: sete recursos de plataforma ausentes na produção

Seu agente funciona. Sei que sim. Você o criou no LangChain, CrewAI ou em alguma ferramenta personalizada, testou em cenários reais e ele funcionou corretamente. O problema não é o agente. O problema é tudo o que está ao seu redor.

Em “Por que bons agentes de IA falham em produção: a camada de infraestrutura ausentePágina disponível no idioma inglês (Portuguese, Brazil não disponível)”, três falhas atingiram uma única implantação de agentes de IA muito rapidamente: 43 tickets de suporte duplicados, US$ 4.000 cobrados na conta errada e uma política de reembolso alucinada que resultou em um estorno de US$ 280 que a empresa precisou honrar. Esse agente funcionou perfeitamente no desenvolvimento, mas falhou na produção porque a infraestrutura era insuficiente. A diferença entre um agente funcional em desenvolvimento e uma implantação pronta para produção não é um problema de framework, mas de infraestrutura.

Este artigo revela essa lacuna. Abordaremos os seguintes tópicos:

• Sete recursos específicos que nenhum framework oferece atualmente
• Onde o seu framework termina
• Por que três soluções alternativas comuns falham
• O que realmente ajuda a preencher a lacuna, sem exigir a reescrita do seu agente

Sete itens que seu framework não oferece

O incidente das 6 horas da manhã expôs três falhas. Mas essas três falhas são sintomas de uma carência maior de infraestrutura. Ao mapear falhas de agentes em produção nas organizações, as mesmas sete lacunas aparecem sempre.

1. Identidade criptográfica

A identidade criptográfica fornece uma prova verificável de qual carga de trabalho faz uma solicitação, com atributos de identidade que determinam quais serviços ela pode acessar. A cobrança indevida de US$ 4.000 ocorreu porque o agente operou com credenciais amplas que nunca foram limitadas ao escopo de produção. Um Large Language Model (LLM) selecionou o identificador de conta incorreto e nada na infraestrutura o impediu. Com a identidade criptográfica, a plataforma restringe quais serviços o agente pode acessar, e as APIs downstream configuradas corretamente impõem quais parâmetros são válidos para um chamador específico. O modelo ainda pode selecionar o identificador incorreto, mas o impacto potencial é limitado: o dano se restringe aos recursos no escopo autorizado do agente, e não a todas as contas do sistema. Para os tomadores de decisão, esta é a diferença entre “uma conta foi afetada” e “todas as contas foram expostas”.

2. Sandbox de execução

O sandbox de execução oferece isolamento nos níveis de hardware e aplicação para que uma carga de trabalho comprometida ou com comportamento inadequado não acesse o sistema operacional host nem afete outras cargas. Isso não é exclusivo dos agentes: qualquer carga de trabalho precisa de isolamento, mas os agentes tornam isso urgente por operarem de maneira autônoma, chamando APIs e executando ações de ferramentas na velocidade da máquina. Sem o sandbox, a falha de uma carga de trabalho afeta todas as outras na mesma máquina. Um agente que pode gravar no sistema de arquivos ou abrir conexões de rede fora de seu escopo é um risco que a equipe de segurança nunca aprovará para produção.

3. Governança de ferramentas

A governança de ferramentas é uma política de infraestrutura que determina quais ferramentas um agente pode chamar. Ela é aplicada na camada de rede para que nenhuma injeção de prompt (técnica em que entradas maliciosas enganam um agente para executar ações indesejadas) a ignore. Já vi equipes tentarem impor o acesso a ferramentas via engenharia de prompt, mas a estratégia não é eficaz. Um adversário determinado ou um modelo criativo contorna as restrições no nível do prompt. A governança deve estar na infraestrutura, não no prompt.

4. Observabilidade e rastreamento

A observabilidade e o rastreamento incluem rastreamentos de execução completos que capturam cada prompt, chamada de ferramenta e resultado intermediário. As três falhas no incidente das 06h00 passaram despercebidas até que clientes e faturas as revelassem. Com rastreamentos de execução completos, cada falha estaria visível antes do relato de um cliente. Para desenvolvedores, isso significa depurar uma interação de agente de várias etapas da mesma forma que se depura uma chamada de microsserviço distribuído. Para a empresa, isso significa trilhas de auditoria que atendam aos revisores de conformidade.

5. Avaliação contínua

A avaliação contínua fornece a pontuação de produção dos resultados do agente em relação à política e à verdade absoluta (ground truth), para que regressões apareçam antes dos relatos de clientes. A política de reembolso alucinada — em que o agente informava um prazo de devolução de 90 dias em vez de 30 — chegou ao cliente porque nenhuma camada de avaliação validou o resultado com a política real. Conjuntos de testes estáticos detectam o que foi previsto; a avaliação contínua detecta o que não foi.

6. Aplicação de segurança

A aplicação de segurança oferece proteções no limite de inferência que interceptam a saída antes que ela chegue a clientes, bancos de dados ou agentes downstream. No exemplo em que um agente falhou três vezes em um dia, o framework roteou a resposta inventada pelo modelo diretamente ao cliente, sem qualquer verificação. A aplicação de segurança torna o limite de inferência um ponto de verificação, não uma passagem livre.

7. Gerenciamento do ciclo de vida

O gerenciamento do ciclo de vida inclui implantar, atualizar, escalar e descontinuar agentes em uma frota com uma postura operacional e de segurança consistente. Um agente é um projeto, mas 10 agentes em três equipes são um desafio operacional. Sem o gerenciamento do ciclo de vida, cada equipe cria seu próprio processo de implantação, modelo de segurança e cadência de atualização. A consistência desaparece.

Onde o seu framework termina

A produção exige consistência entre esses sete recursos. Então, qual é a situação real dos frameworks que você já utiliza? O LangChain e o LangGraph oferecem cadeias, agentes, chamadas de ferramentas, saída estruturada, orquestração baseada em gráficos, memória de sessão e integração de recuperação. A capacidade de composição é realmente forte. O CrewAI oferece coordenação multiagente, design de agentes baseado em funções, delegação de tarefas e orquestração de equipes, com padrões multiagente bem planejados. O Google ADK integra-se perfeitamente ao ecossistema do Google. O Claude Agents traz profundidade de raciocínio. O Strands (AWS) oferece integração de fluxo de trabalho nativa da AWS.

Cada framework se destaca no loop do agente: o ciclo de percepção, raciocínio e ação que define um agente. Nenhum deles fornece identidade criptográfica ou sandbox de execução. A governança de ferramentas na camada de rede está ausente. Rastreamento distribuído de nível de produção, avaliação contínua, aplicação de segurança no limite de inferência e gerenciamento do ciclo de vida da frota não existem em nenhum deles.

Isso não é uma crítica, é apenas uma distinção de categoria. Frameworks são ferramentas da camada de aplicações, mas os sete recursos listados são preocupações da camada de plataforma. Esperar que o seu framework os forneça é como esperar que o Django inclua o Kubernetes: a orquestração de containers é infraestrutura, não lógica de aplicação, e seria irracional esperar que um framework web a incluísse. O mesmo se aplica aqui. As camadas são apenas diferentes.

Se você já tentou implantar um agente do LangChain com identidade, rastreamento e governança adequados, já percebeu isso. Você acaba escrevendo mais código de integração de plataforma do que código do agente. O agente foi a parte fácil.

Três abordagens que não escalam

Se o agente foi a parte fácil, as equipes ainda precisam resolver a parte difícil. Todas as equipes com que converso já tentaram ao menos uma dessas abordagens antes de buscar uma solução de plataforma.

Desenvolvimento próprio. As equipes escrevem os próprios scripts de injeção de identidade, integração de rastreamento e implantação. Para um agente, isso funciona. É até gratificante, pois você compreende cada parte. Com 10 agentes em três equipes, cada uma tem seu próprio modelo de segurança, formato de rastreamento e processo de implantação. Não há consistência nem governança, apenas uma carga de manutenção crescente que afasta engenheiros seniores do desenvolvimento dos agentes. Já vi equipes dedicarem mais tempo à manutenção da integração de suas plataformas internas do que ao desenvolvimento de recursos para os agentes.

As plataformas de agentes hospedados, como Salesforce Agentforce, AWS Bedrock Agents ou Azure AI Agent Service, eliminam a lacuna de produção ao controlar todo o stack. A desvantagem é que elas também controlam o caminho dos dados. Cada prompt, chamada de ferramenta e artefato de raciocínio passa por um serviço de terceiros. Em setores regulamentados, em que os dados não podem sair da rede, isso é inviável. E, quando a plataforma altera preços ou descontinua um recurso, seus agentes precisam acompanhar a mudança.

As extensões específicas de framework oferecem complementos orientados à produção em um único ecossistema; o LangSmith para rastreamento é um exemplo útil. Mas uma organização que utiliza LangChain, CrewAI e agentes personalizados agora precisa de três estratégias de produção separadas. Isso significa três formatos de rastreamento, três modelos de segurança e três conjuntos de ferramentas para as equipes aprenderem. A infraestrutura de produção deve ser independente de framework, e não mais um item preso ao ecossistema de um único fornecedor.

Cada abordagem resolve parte do problema, mas introduz uma nova restrição. A primeira não escala. A segunda troca soberania por conveniência. A terceira fragmenta a estratégia de produção entre os diferentes frameworks.

Seu agente, a plataforma da Red Hat

A restrição comum a todas as abordagens é a suposição de que a infraestrutura de produção deve vir do mesmo fornecedor do framework do agente ou ser criada do zero. Acredito que essa suposição esteja errada. O BYOA (bring your own agent) — abordagem do Red Hat AI onde a plataforma fornece infraestrutura de produção para qualquer framework de agente sem alterações de código — parte da premissa oposta.

A Red Hat não compete na camada de framework. Seja o seu agente executado em LangChain, CrewAI, Claude Agents, Google ADK, Strands ou Python personalizado, o Red Hat AI o operacionaliza. O código do agente escrito pela sua equipe no desenvolvimento é o mesmo que executa em produção. Identidade, sandboxing, governança de ferramentas, rastreamento, avaliação e gerenciamento do ciclo de vida são injetados pela plataforma, não escritos pelo desenvolvedor do agente. E a infraestrutura de produção é consistente em todos os frameworks da organização.

Para os tomadores de decisão, isso significa que o investimento da organização no framework escolhido é preservado. As equipes não precisam escolher entre o framework preferido e a infraestrutura de produção que garanta conformidade regulatória; elas têm ambos. A plataforma leva a infraestrutura de produção ao framework, e não o contrário.

O BYOA também representa a mudança do aluguel para a propriedade da infraestrutura de IA. A Red Hat identifica quatro pilares da soberania digital: soberania de dados, tecnologia, operações e garantia. A plataforma BYOA aborda todos os quatro pilares, que discutiremos nos próximos artigos.

A mesma infraestrutura de plataforma que atende a um agente autônomo de SRE pode dar suporte a um assistente de RH, a um fluxo de aprovação de compras ou a um bot de atendimento: a infraestrutura é independente de domínio, mesmo com casos de uso distintos.

A Red Hat fornece kits iniciais para LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK e outros, com integração de plataforma nativa: autenticação, conexão Model Context Protocol (MCP) e inicialização de rastreamento. As equipes começam a desenvolver no Dia 0, e não após semanas de trabalho de integração.

A decisão que você já sabe como tomar

Dia 0 em vez de semanas: essa abordagem deve parecer familiar. Há uma década, as organizações enfrentavam o mesmo desafio com containers: qualquer equipe podia criar um container, mas ninguém conseguia executá-los em produção com segurança, rede e gerenciamento de ciclo de vida consistentes. A resposta não foi “escolher um runtime de container melhor”, mas sim o Red Hat OpenShift: uma plataforma que operacionalizou qualquer runtime com a infraestrutura que eles não ofereciam. O que discutimos aqui soa familiar porque o Red Hat AI é executado sobre essa base.

A lacuna dos agentes tem o mesmo formato. A questão não é “qual framework devo usar”. Você já tomou essa decisão e, provavelmente, foi a correta. A pergunta é: "Quem fornece a infraestrutura de produção que meu framework não entrega?”. A primeira lacuna a ser fechada é aquela em que a distância entre o desenvolvimento e a produção é maior. Isso envolve segurança, e o nosso próximo artigo abordará esse tema.

Comece agora mesmo

Tudo pronto para eliminar a lacuna de produção dos seus agentes?

• Experimente o OpenShift AI gratuitamente no Developer Sandbox: crie e teste agentes em um ambiente pré-configurado sem custos.
• Explore os kits iniciais de agentes BYO: templates pré-configurados para LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK e outros.
• Faça o curso gratuito Red Hat AI Foundations: laboratórios hands-on que abrangem os fundamentos do desenvolvimento no Red Hat AI.
• Saiba mais sobre o Red Hat AI: visão geral da plataforma e recursos de infraestrutura de produção.
• Operacionalize o BYOA no Red Hat AI: a edição OpenClaw: veja o BYOA na prática com uma implantação real de agente.