Há uma pergunta que continuo ouvindo: "devemos optar por RPA ou por agentes de IA?" Ela pressupõe que você escolhe um. Na prática, eles atuam em partes diferentes do mesmo processo — e a pergunta mais útil é exatamente onde cada um pertence.
Aqui está uma analogia que me ajudou a pensar nisso com clareza.
Em uma seguradora, o subscritor e o processador de sinistros fazem trabalhos completamente diferentes. O subscritor analisa o histórico do cliente, pondera os fatores, toma uma decisão que não está em nenhum manual. O processador segue uma lista de verificação: preencher esses campos, gerar o documento, enviar ao cliente. Um é julgamento. O outro é execução. Ninguém pergunta qual dos dois é "mais eficiente" — porque eles não estão fazendo a mesma coisa.
As ferramentas de automação funcionam da mesma forma. Para qualquer etapa de um processo, uma pergunta é suficiente: há uma resposta correta conhecida aqui, antes de alguém analisar?
Onde um robô é simplesmente melhor
Carregar documentos recebidos em um ERP por meio de uma regra de roteamento padrão. Validar campos de apólices — valores, datas, identificadores. Conciliar registros de pagamento com lançamentos contábeis.
Para tudo isso: a regra é clara, a sequência é fixa, o resultado é previsível. O RPA executa rapidamente, deixa uma trilha de auditoria completa e não precisa pensar. Trazer um agente para essas etapas significa adicionar custo e imprevisibilidade onde nenhum dos dois é necessário.
As pessoas às vezes subestimam quanto do negócio é realmente assim. Operações determinísticas não vão desaparecer.
O que um agente faz — e como ele realmente falha
Um cliente envia um e-mail. Só pelo texto, não é óbvio se é uma reclamação sobre um sinistro negado, uma consulta de status ou uma dúvida sobre os termos da apólice. Um humano lê, entende o contexto, encaminha para a equipe certa.
Um agente faz o mesmo: lê o texto, classifica com base nas instruções que você escreveu, encaminha — com um registro de cada decisão.
Isso não é um script com ramificações if-else. É um modelo de linguagem que age sobre o significado do texto, não em correspondências exatas de palavras. Um analista de negócios o configura por meio de instruções em linguagem natural — sem necessidade de código. Mas requer iteração. Você verifica os casos extremos, refina a instrução, verifica novamente. Leva tempo.
Vale a pena entender como os agentes falham antes de implantar um. Um robô falha ruidosamente — lança um erro e para, você percebe imediatamente. Um agente pode tomar uma decisão errada que parece completamente razoável. Esse é um tipo diferente de risco. No início, revise manualmente uma amostra de decisões, defina os casos em que o agente deve escalar para um humano e estabeleça esse limite explicitamente. Não pule essa etapa.
Por que um agente não substitui o RPA
Um agente pode tomar decisões. Ele não consegue executá-las.
Não consegue fazer login em um ERP, atualizar um registro, clicar em um botão de confirmação em um sistema bancário central. O agente decide; outra coisa tem que agir.
Cada sistema empresarial é sua própria interface — sua própria lógica, seu próprio versionamento, seus próprios casos extremos. A integração com SAP, Oracle ou uma plataforma central legada não fica mais simples porque os modelos de linguagem estão melhorando. Ainda é um problema de engenharia, e é exatamente o problema que o RPA foi criado para resolver.
Portanto, "substituição" é o enquadramento errado. Eles operam em camadas diferentes.
A camada entre eles: o processamento de documentos
Entre o agente e o robô, muitas vezes há uma terceira peça.
IDP — Processamento Inteligente de Documentos — converte conteúdo não estruturado em dados estruturados. Extrai campos de formulários digitalizados, PDFs, anexos de imagens e os passa adiante em um formato utilizável.
Um agente pode tecnicamente ler um documento por conta própria. Para tarefas pontuais, tudo bem. Para processamento em volume — é mais lento, mais caro e a precisão é mais difícil de medir. O IDP foi criado especificamente para isso: treinado em tipos específicos de documentos, produz uma métrica de precisão por campo e sinaliza quando não está confiante. O agente então trabalha com dados que já estão limpos.
Pense nisso como uma camada de preparação. Ela facilita tudo que vem depois.
Como isso se parece na prática
Liquidação de sinistros. Os documentos chegam em partes — o registro inicial hoje, o relatório do perito em três dias, a documentação adicional uma semana depois.
O robô coleta cada documento conforme chega. O IDP extrai os dados — mas uma digitalização é de baixa qualidade, a confiança cai abaixo do limite, esse documento vai para revisão manual. O agente classifica o caso: padrão ou não padrão. O padrão prossegue automaticamente, o robô insere a decisão no sistema central. O não padrão: o cliente está contestando a estimativa de danos, sua conta conflita com o relatório do perito. O agente gera uma solicitação de documentação adicional, passa para um especialista. O especialista decide. O robô executa.
A automação pura com RPA normalmente atinge 60–70% de um processo antes de encontrar as exceções. Adicione a camada de agentes, e em implementações maduras você está olhando para 90–97% de processamento direto. O agente lida com os pontos de julgamento; o robô ainda faz a execução.
A inversão arquitetural: quando o agente está no comando
Tudo acima pressupõe que o RPA é a camada de orquestração principal — o robô chama o agente quando encontra um ponto de julgamento. Isso funciona bem para automação existente.
Mas está emergindo um padrão diferente. Fluxos de trabalho agent-first, onde o agente orquestra e o robô é uma ferramenta que ele chama.
Construímos um MCP Server para o Primo RPA exatamente para isso. MCP — Model Context Protocol — é um padrão aberto que permite que qualquer agente compatível (Claude, Cursor, o seu próprio) se conecte à plataforma RPA e use robôs como ferramentas invocáveis. O agente decide quando delegar a execução estruturada; o robô a executa e retorna o resultado.
Isso inverte a direção habitual: não "o robô chama o agente" mas "o agente chama o robô."
Por que isso importa? Porque se você está construindo fluxos de trabalho baseados em agentes agora, sua infraestrutura RPA não precisa se tornar uma camada legada que você contorna. Ela se torna um serviço — invocável a partir de qualquer camada de orquestração que você estiver usando. Ainda estamos aprendendo onde esse padrão funciona melhor, honestamente. Mas as integrações que ele viabiliza são genuinamente diferentes do que era possível antes.
Medindo o que realmente está funcionando
Três camadas, três coisas diferentes para medir.
Robôs: tempo de ciclo, taxa de exceções, horas FTE liberadas. Direto.
Processamento de documentos: proporção de documentos processados sem revisão manual, precisão de extração em relação a uma referência rotulada, porcentagem de casos de baixa confiança sinalizados. O número-chave é a taxa de processamento direto — qual proporção passa completamente de forma automática.
Agentes: precisão de decisão comparada ao que um especialista decidiria, taxa de escalada, tempo do input ao resultado em casos não padrão.
Quando os três funcionam juntos, uma métrica de ponta a ponta se torna significativa: qual porcentagem do processo é concluída sem envolvimento humano — do documento recebido ao registro no sistema. É aí que você realmente consegue ver o que cada camada contribui.
Por onde começar
Pegue um dos seus processos automatizados — idealmente o que tem mais exceções indo para tratamento manual — e percorra cada etapa com aquela única pergunta: há uma resposta correta conhecida aqui, antes de alguém analisar?
As etapas onde a resposta é "não" — é onde uma pessoa está atuando atualmente. Esses são os pontos candidatos para a camada de agentes.
Então: escolha um, defina como é o sucesso antes de começar, execute o piloto em pequena escala. A arquitetura não é complicada. O trabalho está sempre nos detalhes.