Agentes de IA e RPA: Quatro regras de design que realmente importam

Você tem um agente. Ele entende solicitações, classifica documentos, toma decisões. O problema é o que vem depois — entre o momento em que o agente decide e o momento em que algo realmente muda em um sistema.

Na maioria dos ambientes empresariais, essa lacuna é preenchida por uma pessoa. Alguém pega a saída do agente, abre o aplicativo correto, insere os dados, envia o formulário. O agente é inteligente, mas não tem mãos.

O RPA fecha essa lacuna — especificamente em sistemas sem uma API utilizável, onde a única forma de acesso é pela interface do usuário. Este artigo trata de como projetar essa conexão para que a combinação realmente funcione em produção.

Por que a fronteira é difícil

Três propriedades do RPA moldam diretamente como você projeta a fronteira.

A latência é imprevisível. Uma chamada de API retorna em uma janela de tempo conhecida. Um robô trabalha por meio de uma UI: aguarda o carregamento das páginas, aguarda os elementos aparecerem, fica na fila do orquestrador. O mesmo robô pode ser concluído em 10 segundos ou 3 minutos dependendo da carga do sistema. É assim que a automação de UI funciona. Para um agente que espera que as chamadas de ferramenta se comportem como chamadas de função, isso é um descompasso estrutural.

Robôs quebram com mudanças de interface. Um robô identifica elementos de UI por seletores, nomes de campo ou estrutura do DOM. Qualquer atualização do sistema — mesmo cosmética — pode quebrar esses identificadores. Quanto mais robôs você tiver, maior a probabilidade de que algo esteja quebrado a qualquer momento.

Robôs são determinísticos. Um robô executa exatamente o que lhe é dito. Sem interpretação, sem adaptação. Essa é sua força — previsibilidade, auditabilidade — e sua restrição fundamental. Se a entrada se desviar do formato esperado, o robô falha ou produz saída incorreta sem aviso.

Quatro regras para projetar a fronteira

O erro mais comum é projetar a integração como síncrona. O agente chama o robô, aguarda um resultado, continua. Isso funciona quando o robô responde em milissegundos. Falha quando o robô leva 3 minutos — o agente mantém um contexto aberto, consome tokens e acaba por expirar ou tenta novamente assumindo que a primeira chamada falhou.

O padrão correto é assíncrono. O agente dispara o robô e segue em frente. O resultado chega por callback, polling ou um ativo compartilhado. O agente pode executar ramificações paralelas ou simplesmente reconhecer que uma ação foi iniciada.

Pense nas ações de RPA como trabalhos enviados a um ambiente de execução, não como chamadas de função que retornam imediatamente.

A implicação prática é a seleção de tarefas. Tarefas onde um humano já espera — verificação KYC, processamento de documentos em lote, relatórios noturnos — são candidatos naturais. Tarefas onde a latência é visível ao usuário em tempo real precisam de uma abordagem diferente ou de um design de UX explícito para ocultar o atraso.

O async desloca a complexidade — não a elimina. Uma chamada síncrona retorna um resultado ou falha com um erro. Uma chamada assíncrona tem quatro resultados possíveis: sucesso, erro de execução, timeout de espera de resultado e nenhuma resposta. O agente deve lidar com os quatro. Na prática, trabalhar esses resultados ocupa a maior parte do esforço de integração.

Operações de leitura e escrita têm perfis de risco diferentes e devem ser projetadas como categorias separadas.

Uma leitura é segura para retentar. Se o robô não respondeu e o agente chama novamente, o pior resultado é uma consulta duplicada. Resultados de leitura também podem ser cacheados — status de conta, dados de contraparte, conteúdo de documentos não mudam a cada segundo.

Uma escrita não é segura para retentar sem confirmação explícita. Se o agente não recebe confirmação e chama novamente, você pode acabar com duas transações enviadas ou dois registros criados. Em sistemas financeiros, isso não tem recuperação.

A regra: nunca misture lógica de leitura e escrita no mesmo robô. Projete-os como unidades atômicas separadas. Para escritas, exija confirmação explícita antes que o próximo passo possa prosseguir.

O RPA tradicional coloca a inteligência no robô — ele ramifica, decide, trata exceções internamente. Isso fazia sentido quando o robô era a parte inteligente. Em um sistema agente-RPA, o agente é a camada inteligente. O trabalho do robô é a execução.

Um robô atômico faz uma única coisa. Recebe uma entrada definida e retorna uma saída definida. Toda a lógica de ramificação e o tratamento de exceções vivem no agente.

Um exemplo concreto: um robô que verifica uma contraparte em um registro externo recebe três campos — nome da entidade jurídica, número de registro, jurisdição. Retorna um status (encontrado / não encontrado / erro) e, se encontrado, um indicador de risco e a fonte. Esse é o contrato completo. Se o registro estiver indisponível, o robô retorna um status de erro. Não retenta internamente, não muda para um registro diferente. Essa decisão pertence ao agente.

O contrato também torna os robôs descobríveis. Um agente que pode ler uma descrição estruturada dos robôs disponíveis — o que cada um recebe, o que retorna — pode selecionar a ferramenta certa dinamicamente. Isso é o que transforma uma biblioteca de automações em algo sobre o qual um agente pode raciocinar.

Como efeito colateral, robôs atômicos são mais confiáveis. Menos seletores, menos etapas, menos pontos de falha.

Isso também muda como a orquestração funciona. Historicamente, o orquestrador era o cérebro — ele sequenciava etapas, gerenciava a lógica. Em uma arquitetura agente-RPA, o agente assume esse papel. O orquestrador se torna um barramento de execução.

Os deployments de RPA existentes quase sempre precisam de rework antes de poderem servir como ferramentas de agente. Robôs construídos para fluxos de trabalho determinísticos não são projetados para receber entrada variável de um agente. Esse rework é um pré-requisito, não uma otimização.

Um agente é não determinístico. Suas decisões não podem ser totalmente previstas ou auditadas como um sistema baseado em regras. Essa é a natureza dos sistemas de raciocínio — e cria um problema de governança quando agentes interagem com sistemas financeiros, dados regulados ou qualquer ambiente onde a auditabilidade importa.

A solução é tratar o robô como o limite de conformidade.

O robô é executado sob uma conta de serviço com permissões explicitamente limitadas. Ele só pode fazer o que lhe é permitido, e esse conjunto de permissões é definido antecipadamente — não inferido em tempo de execução. Cada ação é registrada no orquestrador: o que foi chamado, quando, com quais parâmetros e o que retornou.

Isso significa que, independentemente do que o agente decida, o limite do sistema se mantém. Se o agente fizer uma chamada inesperada para alterar um limite de crédito, mas a conta de serviço do robô tiver apenas acesso de leitura a esse sistema, a ação não é executada. O não determinismo do agente encontra um limite de permissões determinístico.

Para ambientes regulados — o setor bancário, em particular — essa arquitetura tem um valor prático específico: quando um auditor pergunta o que aconteceu, sob qual autoridade e com quais restrições, você tem uma resposta completa. Essa resposta vive nos logs do orquestrador, não no rastro de raciocínio do agente.

Padrões na prática

O agente chama o robô. O agente decide e invoca o robô como ferramenta. Verificação KYC: o agente processa um pacote de documentos, lança robôs em paralelo para verificar registros, coleta resultados. Correspondência recebida: o agente classifica uma solicitação, o robô cria um ticket. Monitoramento de limites: o agente detecta uma posição se aproximando de um limite, chama o robô para atualizar parâmetros em um sistema de risco legado. Nos três casos a divisão é a mesma — o agente orquestra, o robô executa uma ação definida.

O robô chama o agente. Aqui o robô conduz o fluxo de trabalho principal, mas delega uma etapa cognitiva. Triagem AML: o robô coleta dados e baixa extratos, depois passa o pacote completo para o agente para análise de risco. Resposta a incidentes de segurança: o robô coleta logs de toda a infraestrutura, o agente avalia o sinal, o robô executa a resposta. O robô lida com o trabalho estruturado e navegável. O agente lida com a interpretação.

O robô prepara dados para o agente. Este é fácil de ignorar porque não há chamada direta em nenhuma direção — o robô simplesmente roda em segundo plano. O caso mais claro é a indexação RAG de sistemas legados. Se os sistemas fonte não têm API — arquivos antigos, gestão documental legada, portais internos — o único caminho de extração é a automação de UI. O robô roda em um cronograma, extrai documentos, os deposita no armazenamento, e o pipeline de indexação padrão faz o restante. O agente nunca chama esse robô diretamente. Ele simplesmente se torna mais capaz.

Falha parcial não é um caso extremo

No padrão KYC acima, três robôs rodam em paralelo. Em produção, um deles ocasionalmente não responderá. Isso é normal — não é um caso extremo.

Quando uma chamada paralela não retorna, o agente tem quatro opções:

Aguardar. Manter o fluxo de trabalho aberto até que o resultado chegue ou um timeout rígido seja acionado. Correto quando os dados ausentes são necessários para a decisão e o atraso é aceitável.

Prosseguir com dados parciais. Continuar com o que chegou e sinalizar explicitamente a lacuna. Aceitável quando a verificação ausente é complementar — mas a lacuna deve ser visível na saída. Uma decisão tomada com dados incompletos que parece completa é um problema de auditoria.

Escalar. Encaminhar o caso para um humano com uma descrição clara do que está faltando. Em ambientes regulados, a escalada é frequentemente o padrão correto, não um recurso de última instância.

Retentar uma vez, depois escalar. Uma retentativa cobre falhas transitórias. Mais de uma sem resultado sinaliza algo estruturalmente errado.

A escolha entre essas opções não deve ser inferida em tempo de execução. Deve ser especificada por chamada de robô no momento do design: o que esse resultado significa para a decisão e o que acontece se ele não chegar.

O que surpreende as equipes na prática

Os robôs existentes precisam de rework significativo. Robôs construídos para processos determinísticos esperam entradas fixas e limpas. Quando um agente começa a chamá-los com parâmetros variáveis — diferentes formatos de nome, diferentes casos extremos — eles falham ou produzem saída incorreta. Reconstruir robôs existentes como ferramentas atômicas não é uma tarefa pequena. Orce para isso.

A latência força uma pergunta útil. A primeira reação a robôs lentos é torná-los mais rápidos. A pergunta mais produtiva é: quais tarefas realmente precisam ser síncronas? Normalmente, menos do que se assume.

A fronteira precisa ser decidida, não assumida. Sem uma decisão arquitetônica explícita, ela deriva durante o desenvolvimento. A lógica acaba em robôs que deveria estar no agente. Agentes obtêm acesso ao sistema que deveria passar pelos robôs. Quando algo quebra, torna-se impossível rastrear onde a decisão foi tomada e sob quais permissões a ação foi executada. Em ambientes regulados, essa ambiguidade não é aceitável.

Por onde começar

Se você está avaliando onde o RPA se encaixa na sua plataforma de agentes, procure tarefas que atendam a três critérios ao mesmo tempo: entrada variável ou não estruturada que o agente possa lidar; um conjunto finito de ações em um sistema sem API utilizável; e tolerância para execução assíncrona.

Se você já tem um portfólio de RPA, comece identificando os robôs que vale a pena atomizar primeiro. Bons candidatos tocam um único sistema, são concluídos em menos de um minuto e retornam uma saída previsível o suficiente para ser descrita em um contrato. Robôs que abrangem múltiplos sistemas ou retornam estruturas variáveis não são impossíveis de expor — mas o custo de rework é maior.

Comece com os simples. Faça o padrão funcionar de ponta a ponta. As automações complexas podem vir depois, uma vez que você saiba que a fronteira se mantém.