As aplicações de IA baseadas em agentes precisam de um design diferente do das interfaces web tradicionais, não necessariamente por causa de um novo protocolo, mas porque o próprio padrão de tráfego é diferente. Uma única conversa pode se estender por dezenas de solicitações independentes, enquanto o agente continua trabalhando em velocidade automatizada e sem os períodos de espera humanos que aliviam a pressão sobre a infraestrutura.
O artigo, publicado no The New Stack como conteúdo patrocinado pela Oracle, propõe reutilizar princípios antigos de microsserviços para criar interfaces compatíveis com OpenAI e capazes de escalar, usando a Oracle AI Database Free como base para o modelo de prova de conceito.
Por que o tráfego dos agentes difere do das aplicações web?
O navegador pode manter a sessão em um único servidor graças à afinidade de roteamento e aos períodos de reflexão do usuário. Já o agente pode executar 40 ciclos consecutivos, e cada ciclo chega como uma solicitação HTTP independente cujo roteamento para o mesmo servidor não é garantido pelo protocolo. Se o histórico da conversa permanecer na memória local do processo, a solicitação seguinte poderá perder o contexto assim que for encaminhada para outra instância do serviço.
Além disso, as chamadas de ferramentas podem ramificar-se de forma imprevisível; uma única solicitação pode não chamar nenhum serviço adicional ou pode resultar em várias chamadas, incluindo operações de busca vetorial que podem levar 400 milissegundos. Os agentes aumentam ainda mais a pressão por meio de suas próprias políticas de repetição, enquanto o tráfego chega em rajadas contínuas determinadas mais pelos limites de simultaneidade e pelo hardware do que pelo comportamento do usuário.
O problema silencioso no design inicial
O autor apresenta um protótipo que mantém o histórico da conversa em um dicionário dentro do processo, usa um único conjunto para controlar a simultaneidade e executa chamadas de ferramentas no próprio caminho da solicitação. Esse design funciona nos testes, mas, na prática, depende de que todas as mensagens da conversa cheguem ao mesmo dispositivo.
Ao distribuir 200 conversas, cada uma com quatro mensagens, alternadamente entre várias instâncias, os servidores podem continuar retornando códigos HTTP 200, enquanto o modelo responde sem o histórico correto da conversa. Portanto, a falha não aparece necessariamente como um erro técnico evidente; ela se manifesta como um comportamento incorreto do ponto de vista do usuário.
Três princípios para corrigir a falha
- Retirar o estado do processo: o estado da conversa e o histórico das chamadas de ferramentas são armazenados em um repositório compartilhado, para que qualquer instância possa atender qualquer mensagem da conversa.
- Isolamento ou circuit breakers: os diferentes caminhos e dependências, como a conclusão da conversa e a execução de ferramentas, recebem limites de simultaneidade e tempos limite independentes, impedindo que a falha de um deles esgote todo o sistema.
- Endpoints inteligentes e pipelines simples: o protocolo compatível com OpenAI permanece como uma camada de transporte estável, enquanto a lógica de roteamento, o gerenciamento de orçamento e memória e as políticas de chamada de ferramentas são colocados acima dele.
O que muda na prática?
O modelo de prova de conceito divide o sistema em um gateway que se comunica pelo protocolo OpenAI e não mantém estado, um serviço de memória que possui o histórico da conversa e a auditoria, um serviço de ferramentas independente com limites próprios de simultaneidade e tempos limite, e a Oracle AI Database Free como repositório compartilhado. O design usa sinais de controle independentes, como 24 slots para a simultaneidade das conversas e 8 para chamadas de ferramentas.
Essa divisão permite a expansão horizontal sem depender do sistema de arquivos local ou da afinidade de roteamento das solicitações. O cliente oficial da OpenAI também pode usar a interface sem modificar o SDK, desde que o protocolo seja compatível.
A conclusão editorial é que a escalabilidade dos agentes de IA não é resolvida apenas aumentando o número de instâncias. O verdadeiro teste é preservar o estado, controlar as dependências lentas e impedir que repetições ou chamadas de ferramentas transformem as rajadas de agentes em uma falha em cadeia. Como o artigo é conteúdo patrocinado pela Oracle, ele continua sendo uma apresentação de uma abordagem arquitetural e de um modelo de prova de conceito, não uma comparação independente entre bancos de dados nem uma garantia de desempenho em todos os ambientes.