Por que ter time de TI próprio não substitui experiência em agentes

Dizem que ninguém aprende na cabeça alheia. Em implementações de agentes de IA, aprender na cabeça alheia é exatamente o que se compra quando se trabalha com quem já fez isso várias vezes.

Um time interno, por bom que seja, vê um caso: o seu. E a diferença entre um time e outro quase nunca é de talento técnico. É quantas vezes viu quebrar a mesma coisa.

O que exatamente se aprende repetindo?

Uma lista de situações que não aparecem em nenhuma documentação porque não são da tecnologia: são do choque entre a tecnologia e como uma empresa funciona de verdade. Cinco dessa lista, todas vistas em implementações reais.

Um acompanhamento automático configurado em dias corridos que sai num domingo, quando não há ninguém do outro lado para atender a resposta.

Um número de WhatsApp bloqueado por padrões de envio anormais, coisa que acontece e que precisa ser prevenida no desenho do fluxo, não depois de já ter acontecido.

Um critério do que conta como tarefa resolvida que ninguém escreveu antes de começar, e que aparece pela primeira vez no dia da primeira fatura, que é o pior dia possível para discutir isso.

Um cliente que em vez de escrever manda um áudio de dois minutos, ou uma foto de uma foto, e o processo não previa isso.

Uma regra de distribuição por região que atribui o lead a uma filial onde naquele dia não há ninguém, porque a regra foi escrita olhando o mapa e não a escala.

Por que nada disso está publicado?

Porque não é conhecimento geral, é casuística. A documentação das plataformas explica o que se pode fazer, não o que dá errado. E o que dá errado quase nunca é um erro técnico: é uma combinação pontual do processo daquela empresa com uma regra da plataforma com um costume do time.

Ninguém escreve isso porque não se pode generalizar. Acumula-se, que é diferente.

Um time de TI interno não aprende o mesmo?

Aprende exatamente o mesmo. A diferença é a ordem em que aprende e quem está na frente enquanto aprende.

Um time que implementa agentes com frequência chega ao projeto novo com essa lista já escrita e a usa como checklist na primeira reunião de configuração. Um time interno vai descobrindo, e cada ponto da lista é descoberto com um cliente real do outro lado. O custo não é de horas de engenharia. É de conversas que deram errado antes de alguém saber que aquele caso existia.

O que se deveria pedir então a um parceiro?

Três coisas concretas, e as três se pedem antes de assinar.

Que traga a lista de situações à primeira reunião, não que a monte com o cliente ao longo do caminho. Se a conversa começa por "conte o seu processo" e não aparece nenhuma pergunta incômoda, essa lista não existe.

Que diga o que não vai funcionar. Um fornecedor que diz sim para tudo está prometendo algo que depois vai renegociar na implementação.

Que conte um caso em que errou e o que mudou depois. Não há como acumular casuística sem ter errado no caminho, então um parceiro que não consegue nomear nenhum caso próprio está contando outra história.

Quando não é preciso um parceiro?

Quando o processo é simples de verdade: um único canal, sem integrações com sistemas próprios, com respostas que não dependem do estado de nada e com volume baixo. Ali, um time interno resolve e não há nenhuma razão para somar mais alguém.

O problema é que quase nenhum processo que valha a pena automatizar cumpre as quatro condições. Assim que uma só se rompe, começa a lista de cima.