Quando alguém mostra um agente de IA funcionando, o que aparece é a conversa: a pergunta entra, a resposta sai, às vezes o agente consulta um sistema e volta com o dado certo. Parece que tudo acontece dentro do modelo de IA.
Não acontece. Por trás de qualquer agente que trabalha de verdade numa operação existe uma camada que decide o que ele lembra, o que ele pode fazer, onde ele precisa parar e como cada passo fica registrado. Essa camada se chama orquestração. Para quem contrata, entender o básico dela é a melhor forma de separar uma demonstração bonita de um agente que aguenta o dia a dia.
O modelo pensa, a orquestração conduz
O modelo de IA, sozinho, recebe um texto e devolve outro texto. Ele não tem memória entre uma conversa e outra, não acessa seu ERP, não sabe quais ações exigem aprovação e não guarda histórico de nada. Tudo isso é responsabilidade do sistema em volta dele.
Uma comparação ajuda. Pense num profissional muito bom recém-contratado. Ele sabe raciocinar, mas precisa de acesso aos sistemas, de uma pasta com o histórico do cliente, de regras sobre o que pode decidir sozinho e de um chefe que confere o trabalho. A orquestração é tudo isso, montado em software.
Na prática, ela cuida de quatro coisas: estado, ferramentas, limites e registro. Quando um agente erra na operação, a causa quase sempre está em uma dessas quatro peças, e não na inteligência do modelo. Ele esqueceu o que o cliente disse, usou uma ferramenta que não deveria ter, passou de um limite que ninguém configurou ou fez algo que ninguém consegue reconstituir depois. Vale olhar cada uma com calma.
Estado: o que o agente sabe neste momento
Estado é a memória de trabalho do agente. Em que etapa do processo ele está, o que o cliente já disse, quais dados já foram consultados, o que falta fazer. Sem estado, o agente pergunta de novo o que já foi respondido, perde o fio quando a conversa é interrompida e não consegue retomar um processo que dura dias.
Imagine um agente que acompanha a cobrança de uma fatura atrasada. O cliente responde na terça que vai pagar na sexta. Na segunda seguinte, o agente precisa saber dessa promessa, conferir se o pagamento entrou e decidir o próximo passo. Isso só funciona se o estado foi guardado fora do modelo, num lugar confiável.
Boas perguntas para quem vai construir:
- Onde fica guardado o histórico de cada caso, e por quanto tempo?
- Se o agente cair no meio de uma tarefa, ele retoma de onde parou?
- Duas mensagens chegando ao mesmo tempo para o mesmo caso viram duas ações duplicadas?
Ferramentas: o que o agente pode fazer
Ferramentas são as ações que o agente consegue executar: consultar um pedido no ERP, criar uma oportunidade no CRM, mandar mensagem no WhatsApp, gerar um boleto. Cada ferramenta é uma porta para um sistema seu, e cada porta precisa ser desenhada com cuidado.
O ponto principal é dar ao agente só as ferramentas que a tarefa exige, com as permissões mínimas. Um agente que responde dúvidas sobre status de pedido precisa ler pedidos. Ele não precisa cancelar pedido, alterar preço ou ver dados financeiros de outros clientes.
Também importa como a ferramenta se comporta quando algo dá errado. Se o ERP demora a responder, o agente tenta de novo? Quantas vezes? Ele avisa alguém? Essas decisões parecem detalhe técnico, mas são elas que evitam um pedido gravado duas vezes ou uma mensagem enviada para o cliente errado.
Limites: onde o agente precisa parar
Limite é a regra que diz até onde o agente vai sozinho. Alguns exemplos comuns:
- Desconto acima de um valor precisa de aprovação de uma pessoa.
- Qualquer menção a processo judicial vai direto para o jurídico.
- Reembolso só depois de alguém do financeiro conferir.
- Mensagem para cliente com reclamação grave é revisada antes de sair.
- Se o agente não tem certeza, ele pergunta ou passa adiante, em vez de adivinhar.
Esses limites precisam estar no código da orquestração, e não só nas instruções do modelo. Instrução escrita em texto é uma orientação que o modelo segue na maioria das vezes. Regra no sistema é uma barreira que ele não consegue atravessar. Para o que importa de verdade, você quer a barreira.
O que não pode dar errado tem que ser regra do sistema, e não um pedido educado ao modelo.
Registro: provar o que aconteceu
Cada coisa que o agente faz precisa ficar registrada: o que ele recebeu, o que consultou, o que decidiu, qual ação executou e quem aprovou, quando houve aprovação. Esse registro serve para três coisas.
- Investigar erros. Quando um cliente reclama, você precisa ver exatamente o que o agente fez e por quê.
- Melhorar o agente. Os casos em que ele passou para uma pessoa ou foi corrigido mostram onde ajustar.
- Responder por dados pessoais. A LGPD exige que a empresa saiba como trata os dados dos titulares e consiga demonstrar isso. Um agente sem registro deixa você sem resposta.
Registro também precisa de cuidado. Ele não deve guardar mais dados pessoais do que o necessário, e o acesso a ele deve ser restrito a quem precisa.
Por que isso deveria pesar na sua decisão
Dois agentes podem usar o mesmo modelo de IA e ter comportamentos completamente diferentes na operação. A diferença está quase toda na orquestração. Por isso, comparar fornecedores pelo modelo que usam diz pouco. Comparar pela forma como tratam estado, ferramentas, limites e registro diz muito.
Quando estiver avaliando quem vai construir seus agentes, peça para ver:
- Um caso real sendo retomado depois de uma interrupção.
- A lista de ações que o agente pode executar e as permissões de cada uma.
- Onde ficam as regras de aprovação e quem consegue alterá-las.
- O registro completo de um atendimento, do começo ao fim.
- O que acontece quando um sistema integrado fica fora do ar.
Se a resposta para essas perguntas for vaga, o agente pode até funcionar na demonstração. Mas a operação vai descobrir as lacunas da pior forma, com cliente do outro lado.
O modelo de IA melhora sozinho a cada versão. A orquestração é o que você precisa garantir que alguém construiu bem.