stamatios
← Voltar ao feed
Trem sobre trilhos fixos com copiloto robô escolhendo o caminho, combinação de fluxos determinísticos e agentes de IA
Agentes

Engenharia da LeanIX defende combinar fluxos determinísticos com agentes

resumo de ~3 min

Um caso que inspirou a reflexão

Jernej Klancic, engenheiro da LeanIX (time da SAP), escreveu sobre as lições de um caso relatado por uma contratada que construiu um sistema de IA agêntica para um cliente farmacêutico. O objetivo do sistema era detectar variações de receita e agir sobre elas - um caso que parecia ideal para uma abordagem totalmente agêntica, mas que não era, pelo menos não integralmente. A equipe começou fazendo tudo com agentes, encontrou problemas recorrentes de confiabilidade e só se estabilizou ao tornar partes do fluxo determinísticas.

Klancic fala de uma posição privilegiada para essa observação: seu time não constrói os agentes em si, mas os servidores MCP e as ferramentas que os agentes chamam. Essa visão de bastidor mostra claramente onde os agentes prosperam e onde tropeçam - e SAP também está levando agentes aos seus fluxos internos.

Determinístico versus agêntico: um espectro, não uma escolha

O autor define os dois extremos. Sistemas determinísticos seguem processos previsíveis, como linhas de montagem: cada componente executa uma função específica em sequência pré-definida, e a saída é sempre rastreável até a entrada. Sistemas agênticos têm maior autonomia: o agente decide dinamicamente os passos com base no contexto em evolução, podendo planejar, adaptar, retroalimentar e usar ferramentas variadas.

Nenhum dos dois é inerentemente superior - o desafio é saber quando usar cada um e como combiná-los.

Como o caso evoluiu

O sistema farmacêutico funcionava assim: o agente verifica os dados de vendas do mês anterior, compara com o mesmo mês do ano anterior e, se a variação superar um limiar, investiga a causa raiz para depois produzir uma proposta - seja para reverter uma queda, seja para replicar um período de crescimento.

Inicialmente, cada etapa passava por um LLM. O resultado era pouco confiável: relatórios inconsistentes, causas raiz perdidas e recomendações sem a precisão exigida pelo cliente. A virada veio quando a equipe percebeu que a etapa de detecção de anomalias sempre seguia a mesma lógica, com sinais que nunca mudam. Essa parte foi substituída por um pipeline determinístico que executa consistentemente os mesmos passos:

  • verifica os dados de vendas no Databricks;
  • agrupa os dados por região;
  • classifica as regiões por desempenho;
  • compara o mês atual com o mesmo mês do ano anterior;
  • pontua a variação em uma escala de 1 a 10 (5 = sem mudança, 10 = forte crescimento, 1 = queda);
  • devolve o resultado ao agente para raciocinar.

Antes dessa mudança, o agente podia pular etapas ou abordar a comparação de forma diferente a cada execução. Segundo o autor, essa não-determinismo é valioso no raciocínio aberto, mas atrapalha quando a tarefa tem um procedimento fixo e correto.

Incentivados pelo resultado, os engenheiros aplicaram a mesma lógica à fase de investigação. Ela também dependia do mesmo conjunto fixo de fontes a cada vez. Eles então definiram ferramentas determinísticas cobrindo aspectos como contagem de assinaturas, subsídios a medicamentos e número de receitas por paciente - não há valor em ser "criativo" sobre quais dados coletar, já que o domínio restringe isso. Só depois da coleta o agente raciocina sobre os dados para identificar a causa raiz e propor uma solução.

As lições do autor

Para Klancic, o mais valioso na história não é o erro inicial - que considera normal -, mas o fato de a equipe compartilhar o processo de encontrar o equilíbrio certo. Ele argumenta que todo projeto, empresa ou time precisará passar por essa mesma iteração, e que não existe um modelo universal para construir agentes.

A moldura do espectro é útil porque evita a falsa dicotomia: as abordagens não são opostas em que se precisa escolher um lado. As implementações de IA mais eficazes encontram sua posição no espectro a partir dos requisitos específicos do caso de uso, não do que está em alta.

Na prática, é possível começar por qualquer extremo: iniciar totalmente agêntico e identificar onde o sistema é não confiável para então endurecer essas partes com ferramentas determinísticas, ou começar totalmente determinístico e introduzir um agente onde as regras fixas forem rígidas demais. Os dois caminhos são válidos - o trabalho está na iteração, observando onde as coisas quebram ou travam e ajustando.

Ele conclui com a pergunta que sugere para quem inicia um projeto de IA: não "devemos usar agentes?", mas "quais partes realmente precisam ser agênticas?". E alerta que esperar mudanças ao longo do caminho é o esperado - acertar o equilíbrio desde o início é a exceção, não a regra. É a mesma jornada do time dele, que constrói ferramentas confiáveis e previsíveis para que os agentes possam depender delas.