Em fevereiro, meu time realizou um experimento para medir a capacidade dos LLMs de gerar fluxos de integração. Avaliamos o desempenho do LLM em uma escala de zero a um, sendo um a correspondência perfeita com nosso “padrão ouro”, um fluxo criado por especialistas.

O LLM alcançou 0,17. O fluxo gerado tinha uma estrutura simplista, que não seguia as melhores práticas nem fazia bom uso de padrões de integração. Ainda assim, dentro de uma definição bastante limitada, ele poderia ser considerado “funcional”. Mas empresas não querem integrações que sejam apenas funcionais. Elas precisam de integrações robustas, confiáveis e compreensíveis.

Esse experimento foi propositalmente injusto. Meu time vinha desenvolvendo um Harness para orientar LLMs na criação de fluxos de integração. Queríamos comparar o desempenho das diferentes versões do nosso Harness entre si e também com um baseline sem nenhuma das nossas intervenções avançadas.

Alguns meses depois, uma versão mais avançada do mesmo sistema gerou um fluxo EDI complexo que nosso CTO considerou 100% pronto para deploy.

Esse não foi um resultado típico, mas aconteceu. Quero mostrar como meu time chegou até lá.

O que construímos

Na Digibee, usamos as tecnologias mais avançadas disponíveis para acelerar o trabalho de integração. Oito anos atrás, o time fundador criou uma plataforma cloud-native que provisionava e otimizava automaticamente recursos de nuvem para engenheiros de integração. Agora, construímos uma versão AI-native que ajuda engenheiros a concluir projetos até 20 vezes mais rápido.

Passei os últimos meses trabalhando na construção desse sistema. O projeto completo inclui diferentes recursos agênticos que elevam o trabalho de integração corporativa. Neste artigo, vou focar na nossa ferramenta que recebe especificações e produz fluxos praticamente prontos em apenas cinco minutos.

Os desafios que encontramos

Uma pontuação de 0,17 não diz o que precisa ser corrigido. Sair desse resultado e chegar a um fluxo aprovado pelo nosso CTO exigiu resolver problemas que não aparecem em uma demo.

• O Harness não é um único template de prompt. Já escrevemos mais de 100 prompts para esse projeto e criamos novos a cada sprint. Além disso, todo o processo é envolvido por código e por uma rede de MCPs e APIs desenvolvidos especificamente para dar suporte às interações dos agentes.
• Avaliar um fluxo não é como avaliar um texto. Dois fluxos válidos podem ser completamente diferentes entre si. Por isso, tivemos que desenvolver nossa própria maneira de medir o que é “próximo o suficiente”, em vez de simplesmente adotar uma métrica padrão.
• A verificação da construção exigiu um sistema próprio. Os primeiros experimentos geravam flowspecs que eram exibidos corretamente na plataforma Digibee, mas quebravam imediatamente. Precisávamos de um ambiente capaz de testar componentes individuais e fluxos completos.

Nenhum desses problemas foi resolvido de uma vez. Fomos reduzindo cada um deles, versão após versão, até que o sistema começou a conquistar nossa confiança.

Adicionando padrões de integração

Nosso experimento de baseline mostrou que os LLMs não tinham noção de como deveria ser um fluxo de integração pronto para produção, pelo menos não um desenvolvido para rodar em nossa plataforma. Dados de treinamento generalistas não fornecem, de forma confiável, o conhecimento estrutural que um engenheiro de integração possui.

Um modelo tentando construir do zero uma sincronização entre Salesforce e NetSuite precisa reinventar o gerenciamento de watermarks, paginação, rate limiting e outros mecanismos nos dois lados. Toda vez. Para cada integração.

Resolvemos isso transformando esse conhecimento em uma biblioteca de padrões reutilizáveis e nomeados. Ela inclui sincronização incremental, orquestração orientada a eventos, request-response e outros padrões. Depois, estruturamos o processo de geração em torno dessa biblioteca.

O trabalho do agente deixou de ser inventar a infraestrutura de integração. Agora, ele seleciona os padrões certos, conecta-os aos conectores adequados e mapeia os campos e as regras de roteamento específicas do cliente. As partes mais difíceis já estão construídas. O agente faz a composição.

Também distribuímos o trabalho entre subagentes especializados. Um único agente carregando todo o contexto necessário para construir um fluxo começa a enfrentar problemas de coerência à medida que o contexto aumenta. Um escopo mais restrito para cada agente ajuda a manter a consistência dos resultados.

A inclusão dos padrões aumentou nossa pontuação de similaridade. A partir daí, o desafio passou a ser outro.

Dando ao agente conhecimento sobre os conectores

Os padrões deram ao agente uma base estrutural. O problema seguinte era que ele nem sempre sabia, de forma confiável, com o que estava se conectando.

Para validar um fluxo gerado sem acessar endpoints externos reais, como APIs REST, bancos de dados, Salesforce ou SAP, construímos um sistema que gera versões simuladas desses conectores. Depois que os conectores eram simulados, um agente identificava o caminho de sucesso mais representativo, normalmente o mais longo capaz de executar a lógica central do negócio sem acionar tratamentos de erro.

Essa abordagem de “happy path” inicialmente gerou uma métrica enganosa: a cobertura de testes dos conectores de saída caiu 35%. Essa queda refletia uma escolha deliberada de design, não uma regressão de qualidade. Nossa abordagem anterior permitia que o sistema explorasse múltiplas soluções. Abrimos mão de uma cobertura exaustiva em troca de velocidade e execução imediata.

Com ou sem um caminho predefinido, o agente precisava dos schemas dos conectores para saber o que cada API exige, aceita e não tolera. Esse conhecimento determina se o fluxo funcionará em produção ou quebrará no primeiro edge case. O agente deveria buscar esses schemas sob demanda. Na prática, quase nunca fazia isso.

Resolvemos o problema retirando essa decisão do agente. Adicionamos uma etapa intermediária determinística que insere os schemas relevantes dos conectores antes do início da montagem. Não é uma instrução no prompt. É uma restrição. A cobertura aumentou 49%. O tempo de execução caiu 11%.

Versionando prompts como código

Escrevemos mais de 100 prompts durante o desenvolvimento do Digibee Digital Worker. Alguns deles já passaram por mais de 20 versões. Com tantas iterações e com os prompts interagindo entre si, pode ser difícil identificar quais mudanças melhoraram ou prejudicaram o desempenho.

No desenvolvimento de software, há muito tempo resolvemos esse desafio com controle de versão e testes estruturados. Aplicamos a mesma lógica aos prompts usando a plataforma de gerenciamento de prompts Opik.

Nosso ciclo de iteração de prompts funciona assim:

1. Escrevemos um prompt o mais completo possível.
2. Executamos um conjunto de sessões simuladas usando um fluxo como referência.
3. Comparamos as pontuações de similaridade e as métricas de cobertura com a versão anterior.
4. Avaliamos se a mudança trouxe uma melhoria.
5. Repetimos o processo.

A maioria dos prompts passa por 10 a 20 versões antes de se estabilizar. Mas essa estabilidade não é permanente: voltamos aos prompts sempre que o sistema muda ou surge um novo padrão de falha.

O principal risco que monitoramos é o overfitting. É fácil melhorar o desempenho de um prompt nos casos que você já conhece adicionando instruções mais específicas. Também é fácil, com isso, piorar seu desempenho em todos os casos que você ainda não viu.

Onde estamos agora

O resultado de EDI mencionado no início foi real. Mas também foi uma única sessão. Atualmente, o sistema costuma alcançar entre 80% e 90% de similaridade, embora os resultados possam variar bastante dependendo da complexidade e do caso de uso.

Para muitos fluxos, isso significa um primeiro rascunho que precisa de revisão e alguns ajustes antes do deploy. Não está finalizado, mas é um excelente ponto de partida. Para outros, significa que ainda não chegamos lá, mas estamos cada vez mais perto.

À medida que avançamos, estamos expandindo as funcionalidades do Digital Worker ao longo de todo o ciclo de vida da integração e aumentando nossa biblioteca de padrões para cobrir mais casos de uso.

Se você gerencia um backlog de integrações que cresce mais rápido do que sua equipe consegue dar conta, foi exatamente para isso que construímos essa solução. O Digibee Digital Worker está disponível em early access.

Tenha acesso antecipado à primeira plataforma de integração AI-native →

‍