Athena — AI Agent para TOTVS Protheus

Athena é um agente de IA em produção que responde perguntas de negócio consultando o ERP TOTVS Protheus. Atende centenas de usuários de múltiplas empresas — times de RH, logística, financeiro e operações — cada uma com sua própria instância de banco de dados e sintaxe SQL.

A escala do problema

TOTVS Protheus é um dos ERPs mais complexos do mercado brasileiro. Cada cliente tem centenas de tabelas, joins não-óbvios, campos com nomes codificados e regras de negócio que variam por módulo, por empresa e por configuração de implantação.

O desafio adicional: as empresas atendidas usam bancos diferentes. Algumas rodam Oracle, outras SQL Server, outras PostgreSQL. A mesma pergunta de negócio exige queries sintaticamente diferentes dependendo do cliente.

Fazer um usuário de RH conseguir perguntar "qual a taxa de absenteísmo do mês passado por setor?" e receber uma resposta correta — sem saber nada de SQL, sem saber qual tabela usar, sem conhecer as regras de cálculo do módulo — era o objetivo.

O que não funcionou primeiro

A abordagem inicial foi colocar toda a base de conhecimento no system prompt: queries de referência, regras de negócio, mapeamento de tabelas, diferenças de sintaxe por banco.

Funcionava para perguntas simples. Quebrava para perguntas complexas.

O modelo passava a alucinar de formas sutis — as piores do ponto de vista de produção: não erros óbvios, mas filtros incorretos ou incompletos. Uma query que rodava, retornava resultado, mas trazia dado errado porque faltava um filtro de competência, ou porque usou a tabela de movimentação no lugar da tabela de saldo.

Além disso, prompt gigante significa latência alta e custo alto por query — inviável em produção com centenas de usuários simultâneos.

A solução: RAG com chunking semântico por delimitador

A arquitetura adotada durante a POC usou LangGraph para orquestrar um nó de RAG customizado antes do agente principal.

A base de conhecimento foi estruturada num documento Markdown com mais de 100 blocos por módulo — cada bloco contendo:

A query de referência para aquele tipo de consulta
As tabelas envolvidas e seus relacionamentos
Os filtros obrigatórios e suas regras de negócio
Variações de sintaxe por banco (Oracle / SQL Server / PostgreSQL)
Exemplos de perguntas que mapeiam para aquele bloco

A decisão técnica central foi o chunking por delimitador semântico (#----------#) em vez de tamanho fixo. Chunking por tamanho cortaria uma query no meio, separaria um filtro da sua regra de negócio, quebraria o contexto que o agente precisava.

Com delimitador semântico, cada bloco é recuperado inteiro ou não é recuperado. O agente recebe contexto cirúrgico — só o que é relevante para aquela pergunta, no dialeto SQL certo para aquele cliente.