Imagine a seguinte situação em uma distribuidora. Às 16h42, uma cliente escreve no WhatsApp: “O pedido 8471 ainda dá tempo de ir para a filial de Campinas? Se der, manda por entrega expressa.”
O atendente abre a conversa, procura a empresa no CRM, consulta o pedido no ERP, confirma se houve emissão fiscal, olha a janela da transportadora e tenta descobrir quem pode autorizar o custo adicional. Leva doze minutos. Quando encontra a resposta, outra pessoa já alterou o endereço no ERP, mas não registrou o motivo no CRM. A equipe do estoque continua com a separação anterior.
Um agente de IA poderia reduzir esse vai e volta. Ele lê a mensagem, identifica o cliente e o pedido, consulta os sistemas, propõe a mudança e encaminha a aprovação necessária. O ponto decisivo não é o agente “entender português”. É a arquitetura que impede uma frase ambígua de virar alteração errada, cobrança duplicada ou pedido enviado para dois lugares.
Integrar agentes ao CRM, ao ERP e ao atendimento funciona quando cada sistema continua responsável pelo seu próprio estado. O agente coordena o trabalho por ferramentas pequenas, recebe apenas o contexto de que precisa, pausa antes de efeitos sensíveis e confirma o resultado no sistema de registro. Ele não ganha uma senha geral para improvisar dentro da empresa.
O problema não é fazer o agente falar; é decidir o que ele pode mudar
Uma demonstração costuma começar pela parte mais fácil. O agente responde à cliente com naturalidade, resume o histórico e diz que vai resolver. Na vida real, “resolver” pode significar ações muito diferentes: consultar um cadastro, alterar um endereço, recalcular frete, cancelar uma nota, avisar o estoque ou assumir um custo.
Essas ações não têm o mesmo risco. Consultar a situação do pedido é reversível e não muda o negócio. Trocar o endereço depois da emissão fiscal pode exigir outro tratamento. Contratar frete expresso cria custo. Cancelar um documento ou um pedido produz efeitos que não deveriam depender só da confiança do modelo em sua própria interpretação.
A documentação de padrões de agentes da Microsoft recomenda usar o menor nível de complexidade que resolva o caso. Uma chamada direta ao modelo atende classificação e resumo. Um agente com ferramentas costuma bastar para um domínio. Vários agentes acrescentam coordenação, latência e novas formas de falhar, por isso precisam de justificativa concreta.
Essa escolha evita transformar qualquer integração em um “time digital” difícil de observar. No caso do pedido 8471, um único agente com cinco ferramentas bem definidas pode ser mais seguro do que agentes separados para vendas, logística, financeiro e atendimento conversando livremente entre si.
A pergunta inicial muda de “qual modelo vamos usar?” para “qual decisão precisa de interpretação e quais efeitos serão permitidos?”. O modelo entra depois que esse mapa existe.
CRM, ERP e atendimento não são três cópias da mesma verdade
A conversa do WhatsApp registra o pedido da cliente e o momento em que ela fez a solicitação. O CRM guarda a relação comercial: empresa, contatos, responsável, histórico e acordos. O ERP registra pedido, itens, preço, estoque, faturamento e expedição. Cada fonte responde a uma parte do caso.
Se o agente tratar tudo como texto em uma memória única, surgem conflitos difíceis de perceber. Um resumo antigo pode dizer que o endereço principal fica em São Paulo, enquanto o pedido atual indica Campinas. Uma nota no CRM pode mencionar uma exceção comercial, mas não alterar o valor efetivamente faturado. A mensagem mais recente pode ser legítima ou pode ter vindo de um contato sem autorização para mudar a entrega.
O sistema de registro precisa vencer a disputa. O agente pode reunir contexto e explicar a diferença, mas não deve substituir o estado oficial por uma conclusão produzida em linguagem natural.
No pedido 8471, a integração poderia trabalhar assim:
- a mensagem cria um evento com identificador próprio;
- uma ferramenta localiza o contato e suas permissões no CRM;
- outra consulta o pedido e o estágio logístico no ERP;
- uma regra determina se a mudança é automática, impossível ou sujeita a aprovação;
- a ferramenta de escrita altera somente os campos autorizados;
- o resultado volta para o atendimento e fica ligado ao evento original.
Essa sequência tem trechos determinísticos e um trecho de interpretação. O modelo pode extrair intenção, reconhecer que “manda por entrega expressa” envolve custo e escolher a consulta adequada. Ele não precisa calcular tributo, decidir política comercial nem escrever diretamente em tabelas internas.
O agente deve usar ferramentas, não acesso solto ao sistema
Uma ferramenta é uma operação com nome, parâmetros, validação e resultado previsível. consultar_pedido(numero) é uma ferramenta. alterar_endereco_entrega(pedido, endereco, motivo, chave_idempotencia) também. “Acesso ao ERP” não é uma ferramenta; é uma superfície grande demais.
Essa diferença melhora segurança e qualidade ao mesmo tempo. Quando o agente enxerga vinte operações específicas, a escolha tem limites claros. Quando recebe um usuário de banco com permissão ampla, qualquer erro de interpretação pode atingir campos que nunca fizeram parte do fluxo.
A Anthropic distingue workflows, com caminhos definidos em código, de agentes que escolhem dinamicamente ferramentas e próximos passos. A empresa também recomenda padrões simples e combináveis, além de retorno constante ao estado real do ambiente. O agente precisa conferir o que aconteceu depois de agir; não basta assumir que a chamada funcionou.
Para a distribuidora, a ferramenta de mudança de entrega pode validar antes da escrita:
- se o pedido existe e pertence ao cliente identificado;
- se o contato tem permissão para solicitar a alteração;
- se o estágio atual ainda admite mudança;
- se o endereço está completo e pertence a uma filial válida;
- se há impacto de preço, documento fiscal ou transportadora;
- se a mesma intenção já foi processada.
O modelo não decide sozinho se essas condições são verdadeiras. A ferramenta consulta regras e sistemas. Quando encontra uma situação fora do contrato, devolve um motivo estruturado: pedido_faturado, contato_sem_permissao, frete_exige_aprovacao ou alteracao_ja_aplicada. O agente então explica o próximo passo ou encaminha a exceção.
Essa arquitetura também permite trocar de modelo sem reconstruir o negócio. As permissões, regras e efeitos ficam na integração. O modelo continua importante para interpretar, escolher e redigir, mas não carrega a política da empresa dentro de um prompt impossível de auditar.
A aprovação humana precisa acontecer antes do efeito sensível
Pedir aprovação para tudo cria uma fila que mata o benefício da automação. Não pedir aprovação para nada transforma erro de interpretação em efeito real. O desenho útil separa ações por risco.
Consultar pedido, resumir conversa e preparar uma resposta podem seguir automaticamente. Atualizar uma preferência de contato talvez também, dependendo da política. Mudar endereço de entrega, aceitar custo adicional, cancelar pedido ou emitir crédito pedem outra barreira.
A documentação de guardrails e revisão humana da OpenAI trata aprovação como uma interrupção antes da chamada sensível. O estado da execução é preservado; depois da decisão, a mesma execução continua. A pessoa não deveria refazer o caso nem copiar dados entre telas.
No pedido 8471, o agente reúne a solicitação, o estágio do pedido, o novo endereço, a diferença de frete e a regra comercial. O gerente recebe uma proposta objetiva:
Alterar entrega da matriz em São Paulo para a filial de Campinas. Acréscimo de R$ 84, pedido ainda não despachado, contato autorizado. Aprovar?
A aprovação se liga àquela ação, àqueles parâmetros e àquela versão do pedido. Se alguém faturar ou despachar enquanto o gerente analisa, a ferramenta revalida o estado antes de executar. Aprovar uma intenção antiga não pode autorizar uma alteração que já perdeu o sentido.
Guardrails também precisam ficar próximos das ferramentas. Uma validação genérica na entrada do chatbot não vê todos os efeitos que aparecem depois. Cancelamento, edição financeira e mudança de cadastro merecem políticas específicas no momento da chamada.
Retry sem idempotência transforma timeout em ação duplicada
A integração envia a alteração ao ERP e a resposta demora. O agente vê um timeout. Isso não significa que a operação falhou. O ERP pode ter gravado a mudança e perdido a resposta no caminho.
Se a automação repetir a chamada sem verificar, o resultado pode ser um segundo frete, uma segunda tarefa para o estoque ou duas mensagens de confirmação. O problema não é exclusivo de IA. Sistemas distribuídos convivem com respostas perdidas há décadas. Agentes apenas aumentam a quantidade de decisões e ferramentas envolvidas.
A defesa é uma chave de idempotência ligada à intenção de negócio. Para o pedido 8471, a chave pode combinar o evento da conversa, o pedido e o tipo de alteração. A primeira tentativa registra a operação. Se houver repetição, a ferramenta consulta essa chave e devolve o resultado já conhecido em vez de executar de novo.
Idempotência também ajuda quando a cliente manda duas mensagens com a mesma solicitação ou quando dois atendentes acionam o fluxo quase ao mesmo tempo. O sistema precisa distinguir repetição de uma mudança nova. “Trocar para Campinas” e, dez minutos depois, “na verdade, manter São Paulo” são duas intenções. Duas cópias da primeira frase são um caso só.
O registro deve guardar pelo menos:
- identificador do evento original;
- parâmetros normalizados da ação;
- versão do pedido lida antes da escrita;
- decisão de aprovação, quando houver;
- resultado retornado pelo sistema;
- horário e identidade da ferramenta executora.
Assim, retry vira recuperação, não aposta.
Contexto mínimo reduz confusão e exposição
Dar ao agente “todo o histórico do cliente” parece conveniente. Também mistura informação irrelevante, aumenta custo, piora a seleção do que importa e expõe dados sem necessidade.
Para alterar a entrega, o agente talvez precise do contato solicitante, do pedido, dos endereços elegíveis, do estágio logístico e da regra de aprovação. Ele não precisa de todas as conversas comerciais, documentos de outros pedidos, dados bancários ou registros de pessoas sem relação com o caso.
O princípio de menor privilégio vale para dados e para ações. Cada ferramenta consulta uma visão restrita e devolve uma resposta estruturada. Campos sensíveis podem ser omitidos ou mascarados. O agente recebe o suficiente para decidir o próximo passo, não uma réplica da empresa inteira.
O OWASP Top 10 for Agentic Applications de 2026 organiza riscos específicos de sistemas que planejam, usam ferramentas e agem em fluxos complexos. A autonomia amplia o dano possível de credenciais excessivas, instruções maliciosas e cadeias de ação sem controle. Limitar ferramentas e contexto reduz esse raio de impacto.
Há ainda um detalhe importante no atendimento: o texto recebido é dado externo, não instrução confiável para a infraestrutura. Uma cliente pode colar um e-mail, uma página pode conter comandos escondidos e um anexo pode misturar conteúdo com instruções. O agente interpreta a solicitação dentro da política da aplicação. Ele não obedece a qualquer texto como se fosse configuração do sistema.
Sem rastreabilidade, a empresa só descobre o erro pelo cliente
Um log que diz “agente executado com sucesso” não explica o pedido 8471. A equipe precisa reconstruir a sequência: qual mensagem iniciou o caso, quais dados foram consultados, qual ferramenta foi escolhida, quais parâmetros seguiram para o ERP, quem aprovou e qual estado foi confirmado depois.
Essa trilha serve para suporte, melhoria e responsabilidade. Se o endereço saiu errado, é possível separar causas diferentes:
- o agente interpretou a filial incorreta;
- o CRM associou o contato ao cliente errado;
- a ferramenta montou os parâmetros de forma defeituosa;
- o ERP aceitou uma transição que deveria bloquear;
- uma aprovação foi aplicada depois de o pedido mudar;
- a escrita deu certo, mas a mensagem ao estoque não foi entregue.
Sem essa separação, o time ajusta o prompt por tentativa e erro. Às vezes o modelo nem foi a causa.
O perfil de riscos para IA generativa do NIST amplia o AI Risk Management Framework com riscos e ações voltados a sistemas generativos. Na prática, a empresa precisa tratar governança como operação: inventariar usos, avaliar efeitos, monitorar resultados e manter mecanismos para responder quando algo foge do esperado.
Métricas úteis também vão além de “quantas conversas o agente respondeu”. Para esse fluxo, vale acompanhar:
- solicitações corretamente identificadas;
- ações concluídas sem retrabalho;
- aprovações aceitas, rejeitadas e expiradas;
- bloqueios por falta de dado ou permissão;
- retries recuperados sem duplicação;
- exceções encaminhadas a uma pessoa;
- tempo até o estado confirmado no ERP.
O artigo sobre como medir o ROI da IA aprofunda esse ponto: produtividade só conta quando termina em resultado verificado, não quando o modelo produz uma resposta bonita.
Comece por um fluxo delimitado, não por um agente para a empresa inteira
A primeira versão não precisa alterar endereço, recalcular frete, conversar com transportadora, emitir documento e reorganizar estoque. Pode começar menor.
Um caminho seguro para a distribuidora seria:
- Leitura: o agente identifica solicitações de mudança de entrega e reúne os dados do CRM e do ERP.
- Recomendação: ele classifica o caso como permitido, bloqueado ou sujeito a aprovação, sem escrever nada.
- Ferramenta restrita: a integração habilita uma única alteração para pedidos em estágio elegível.
- Aprovação: custos e exceções continuam com uma pessoa.
- Autonomia gradual: somente casos que passaram por avaliação repetida deixam de exigir revisão.
A equipe testa exemplos normais e situações ruins: contato não autorizado, pedido inexistente, endereço incompleto, documento já emitido, duas mensagens iguais, timeout depois da escrita e mudança concorrente no ERP. Teste em sandbox antes de conceder efeito real. A própria Anthropic recomenda testes extensos e condições de parada para agentes autônomos, porque erros podem se acumular ao longo das ações.
Esse percurso se conecta ao guia sobre como implementar IA na empresa: escolher o primeiro processo pelo valor e pela capacidade de verificar o resultado costuma ser melhor do que começar pelo caso mais chamativo.
Há processos em que um agente não é necessário. Se todas as solicitações seguem regras fixas e os dados chegam estruturados, uma automação tradicional será mais previsível. O agente ganha espaço quando a entrada é ambígua, o caminho depende do contexto e a decisão precisa escolher entre ferramentas. Mesmo assim, as operações que mudam o negócio continuam explícitas e testáveis.
O agente coordena; a integração sustenta a confiança
No fim do caso, a cliente recebe a confirmação correta. O CRM registra o pedido e a decisão comercial. O ERP mantém o endereço, o custo e o estágio logístico. O estoque enxerga a nova instrução. Se alguém precisar revisar o que aconteceu, a sequência está inteira.
O ganho não veio de entregar todos os sistemas ao modelo. Veio de uma arquitetura que combinou interpretação com limites: ferramentas pequenas, contexto mínimo, aprovação antes do risco, idempotência para repetir com segurança e registros suficientes para conferir o resultado.
Cada empresa tem estados, permissões e exceções diferentes. Um CRM pronto pode conhecer o contato, mas não a regra de expedição. O ERP pode guardar o pedido, mas não entender a conversa. O atendimento pode captar a urgência, mas não decidir sozinho quem absorve o frete. A integração sob medida costura essas fronteiras sem apagar a responsabilidade de cada sistema e de cada pessoa.
Se existe um fluxo importante preso entre conversa, CRM, ERP e conferências manuais, vale conversar com a Foyth Tech. O primeiro passo não é prometer um agente que faz tudo. É mapear uma ação verificável, limitar o que ela pode mudar e construir a trilha para ampliar a autonomia sem perder o controle.
