Agentes de IA
Quase todo projeto de agente começa bem. O piloto roda com um punhado de perguntas, com dado que alguém arrumou na mão para demonstração e com uma pessoa do lado corrigindo o que sai torto. Aí o agente vai para produção, onde o dado chega do jeito que o sistema guardou, a pergunta vem do jeito que o cliente quiser fazer e ninguém está olhando por cima do ombro. Produção não se parece com o piloto, e o motivo do cancelamento raramente é o modelo.
A diferença entre o agente que ajuda e o que atrapalha aparece na primeira pergunta de verdade. Escolhe uma pergunta que um cliente seu faria e olha os dois lados: o que precisa existir por trás para ela ter resposta, e o que o agente responde quando esses sistemas não estão ao alcance dele.
Repara que a resposta inventada é a mais simpática das duas. Um modelo de linguagem foi treinado para continuar o texto de um jeito plausível, e quando não tem o dado na mão. O cliente não tem como perceber a diferença, e quem descobre é o seu atendimento, três dias depois, com o problema já maior.
Boa parte dos pedidos que chegam para a gente começa com "queremos um agente", e boa parte dos projetos começa pela camada de integração mesmo assim. Não é teimosia: um agente é um programa que lê e escreve nos seus sistemas, e ele só consegue fazer isso se os seus sistemas souberem conversar. Cada camada aqui embaixo sustenta a de cima, e quando falta uma delas o problema aparece lá em cima, na resposta que o cliente lê.
Quando as camadas de baixo já existem, e às vezes existem, o agente entra em semanas. Quando não existem, a gente prefere dizer isso na primeira conversa, com o plano de como construí-las, do que descobrir junto no terceiro mês.
Quer saber em que camada a sua operação está hoje? Bora olhar junto
Botar um agente autônomo para decidir sozinho dentro de um processo crítico é uma decisão de risco antes de ser uma decisão de tecnologia, e ela não se resolve escolhendo entre "com IA" e "sem IA". A conversa que rende é outra: etapa por etapa, o que o agente resolve sozinho, o que ele prepara para uma pessoa aprovar e o que continua inteiro na mão de gente. Essa fronteira a gente desenha no começo do projeto e revisa conforme o agente ganha histórico.
Resposta que sai do dado, é igual toda vez e custa pouco se sair errada.
O agente junta o contexto em segundos e alguém bate o martelo com tudo na tela.
Conversa em que o contexto vale mais que a regra, ou em que o erro é caro demais.
A fronteira anda com o tempo, e anda com base em registro. Depois de três meses de operação dá para olhar o log e ver que, em 98% das liberações de crédito até certo valor, a pessoa aprovou exatamente o que o agente propôs, sem mudar nada. Aí faz sentido subir aquela etapa para o agente resolver sozinho, com um limite e um alerta. O caminho contrário também acontece, e é igualmente saudável.
A gente trabalha com Python e com modelos open source rodando no ambiente do cliente, e chama API de terceiro onde ela traz valor real para o caso, em vez de chamar por padrão. Essa escolha parece detalhe técnico até a conta chegar, e a diferença aparece em três lugares bem concretos.
Um agente de atendimento que conversa com 40 mil clientes por mês faz muito mais que 40 mil chamadas ao modelo, porque cada conversa tem várias idas e voltas e cada ida leva o histórico junto. Com API de terceiro você paga por token, e a conta cresce junto com o sucesso do agente. Com modelo aberto no seu servidor, o custo é o da máquina: fixo, previsível e conhecido antes de subir.
Preço, limite de requisição e o próprio comportamento do modelo mudam quando o fornecedor decide mudar, e já mudaram várias vezes. Um modelo que roda no seu ambiente continua o mesmo amanhã, com a mesma resposta para a mesma pergunta, e a hora de trocar por um melhor é você quem escolhe.
Toda pergunta que vai para uma API de terceiro leva contexto junto: nome do cliente, CPF, histórico de compra, às vezes o teor da reclamação. Esse pacote sai da sua rede e passa por uma infraestrutura que não é sua. Rodando dentro de casa, o dado não atravessa a fronteira da empresa, e o log de quem consultou o quê fica com você.
Cada setor chega com uma restrição diferente sobre o que pode sair do ambiente interno, e normalmente é essa restrição que define a arquitetura, bem antes de qualquer discussão sobre qual modelo é o melhor. A gente já operou sob regras bem diferentes:
Três projetos que moram nas camadas de baixo, que são as que sustentam qualquer agente que venha depois. Os números são os que os clientes toparam publicar.
A gente integrou todo o ecossistema digital da Vero. A orquestração dos CRMs (NG, IXC, Voalle e Simetra) roda em Python com FastAPI, e o login único cobre sete sistemas de billing diferentes, herdados de aquisições. É exatamente a camada de dado consistente e de API que um agente precisa alcançar para responder qualquer coisa sobre um cliente.
O Visie Flow guia o consumidor até a solução do problema do produto dele, e quem escreve e muda essas árvores é o time da Whirlpool, num editor low-code, sem passar por TI. É o projeto mais próximo de um assistente guiado que a gente tem, com integração a CRM e ERP por CPF, e reduziu visita técnica desnecessária e chamado de call center.
A integração com as seguradoras é por API onde existe API, e por RPA nas que só operam por e-mail. Isso é o trabalho sujo da camada de baixo: quando o parceiro não tem interface, a gente constrói uma do lado de cá para que o resto do sistema enxergue todas as seguradoras do mesmo jeito.
Traz uma pergunta que os seus clientes fazem todo dia, ou uma que a sua própria equipe faz e leva meia hora para responder. A gente olha junto quais sistemas guardam esse dado hoje, o que já dá para alcançar por API e o que precisa ser construído antes. Dessa primeira conversa já sai um primeiro passo com prazo e preço, de duas semanas.