Agents, BPM e BPEL: continuidade ou ruptura?
Agents, BPM e BPEL: continuidade ou ruptura?
Como a onda agentic reacende problemas antigos de processos, integração, governança e arquitetura empresarial
Por Leopoldo Carvalho Correia de Lima
Há uma tentação recorrente em tecnologia: cada vez que uma nova onda chega, fingimos que a história começou agora.
Com AI Agents e sistemas multiagentes, esse risco é enorme. A narrativa mais superficial vende a ideia de uma ruptura completa: agentes autônomos, capazes de conversar, decidir, executar tarefas, usar ferramentas e colaborar entre si como se a engenharia de software tivesse acabado de descobrir a roda.
Mas, para quem viveu arquitetura de sistemas em ambiente corporativo de verdade — integração de sistemas, SOA, BPM, BPEL, filas, SLA, compensação transacional e auditoria — a sensação é outra.
Parece novo. Mas também parece muito familiar.
O que BPEL e agents têm em comum
BPEL nasceu no contexto de SOA, Web Services, XML e integração corporativa. A preocupação era clara: como coordenar chamadas entre serviços diferentes para executar um processo de negócio ponta a ponta?
Recebia-se um evento, invocava-se um serviço de cliente, chamava-se um serviço de crédito, tratavam-se exceções, acionavam-se compensações e finalizava-se uma transação de negócio.
Com agents, o desenho começa parecido.
Recebe-se uma solicitação, entende-se a intenção, escolhe-se a próxima ação, chama-se uma ferramenta, avalia-se o resultado, aciona-se outro agente, pede-se validação humana e gera-se uma resposta final.
A semelhança não é acidental.
Nos dois casos, estamos falando de orquestração. Existe uma entrada, uma sequência de atividades, decisões intermediárias, chamadas a capacidades externas, tratamento de exceções e uma saída esperada.
Mas há uma diferença fundamental.
No BPEL, o processo normalmente sabia qual serviço chamar e em que momento. No mundo dos agents, o sistema pode precisar decidir dinamicamente qual ferramenta usar, qual agente acionar, qual informação buscar e quando parar.
O BPEL orquestrava serviços. O BPM orquestrava processos. Os sistemas multiagentes orquestram decisões, ferramentas e especialistas digitais.
BPM: a disciplina que os agents ainda precisam aprender
BPM nunca foi apenas desenhar caixinhas bonitas em BPMN.
Em ambientes sérios, BPM sempre tratou de temas como estado, responsabilidade, fila, prazo, exceção, aprovação, rastreabilidade e melhoria contínua.
Esses temas continuam absolutamente relevantes em arquiteturas com agents. Na verdade, ficaram ainda mais urgentes.
Um processo tradicional pode ter uma etapa chamada “Analisar proposta comercial”. Essa etapa talvez fosse feita por uma pessoa. Agora, parte dessa análise pode ser feita por um agent.
Mas isso não elimina a necessidade de governança. Pelo contrário.
Ainda precisamos saber quem iniciou a solicitação, qual era o contexto, qual agent foi acionado, quais ferramentas foram usadas, quais dados foram consultados, qual recomendação foi gerada, qual foi o grau de confiança, se houve aprovação humana, qual decisão final foi tomada e como auditar tudo isso depois.
Sem isso, não temos automação inteligente.
Temos improviso automatizado.
Tool calling é o novo service invocation
Outra semelhança evidente está entre service invocation e tool calling.
No BPEL, invocávamos serviços como:
consultarCliente()
validarCredito()
registrarPedido()
emitirNotaFiscal()
Em agents, chamamos ferramentas com nomes diferentes, mas com o mesmo propósito: conectar raciocínio à operação real.
buscar_cliente()
consultar_crm()
gerar_proposta()
pesquisar_documentos()
atualizar_pipeline()
A diferença é que, em muitos casos, o agent pode decidir quando chamar a ferramenta e com quais parâmetros.
Isso é poderoso.
Mas também é perigoso.
Uma chamada errada pode consultar dados indevidos, executar uma ação incorreta, gerar custo desnecessário ou produzir um efeito operacional real e irreversível.
Por isso, tool calling precisa de contrato.
Cada ferramenta deve ter entrada esperada, saída esperada, permissões, limites, tratamento de erro, logs e política de uso.
Sem contrato, tool calling vira gambiarra com linguagem natural.
O mapa mental da transição
| Ontem | Hoje |
|---|---|
| BPEL orquestrava serviços | Agents orquestram ferramentas e decisões |
| BPM controlava processos | Workflows agentic controlam fluxos híbridos |
| Human task registrava aprovação | Human-in-the-loop valida risco e julgamento |
| Service invocation chamava sistemas | Tool calling conecta modelo à operação |
| Audit trail registrava execução | Tracing registra prompts, tools, decisões e custos |
| Regras determinísticas guiavam o fluxo | Decisões semânticas influenciam o caminho |
| Exceções eram tratadas por processo | Ambiguidades exigem supervisão e avaliação |
A mudança, portanto, não é apenas tecnológica. É arquitetural.
A empresa deixa de orquestrar apenas sistemas previsíveis e passa a orquestrar componentes capazes de interpretar, sugerir e agir.
Isso aumenta o potencial de automação.
Mas também aumenta a responsabilidade de desenho.
Human-in-the-loop é a velha human task com nova urgência
Em BPM, tarefas humanas sempre foram parte natural do processo.
Aprovar uma compra. Revisar um contrato. Autorizar um desconto. Validar um cadastro. Resolver uma exceção.
No mundo dos agents, isso aparece com outro nome: human-in-the-loop.
Mas a lógica é muito parecida.
O agent pode analisar, resumir, classificar e recomendar. Mas certas ações precisam de revisão humana antes de seguir.
Enviar uma proposta com desconto relevante. Aprovar crédito. Negar solicitação de cliente. Executar ação financeira. Publicar conteúdo institucional. Alterar um cadastro sensível. Responder sobre um tema jurídico.
Nesses casos, human-in-the-loop não deve ser tratado como um botão improvisado.
Deve ser tratado como fila de trabalho, com responsável, SLA, status, decisão, justificativa e trilha de auditoria.
Ou seja: exatamente o tipo de disciplina que BPM já conhece.
Multiagent sem BPM vira spaghetti de prompts
O entusiasmo com multiagents precisa ser equilibrado com engenharia.
Quando vários agents interagem sem contratos, sem estado, sem critério de parada e sem rastreabilidade, o resultado pode parecer sofisticado em demonstração, mas rapidamente vira uma confusão difícil de operar.
Um agent chama outro. O segundo interpreta diferente. O terceiro refaz o trabalho. O quarto gera uma conclusão sem evidência. Ninguém sabe exatamente onde o erro começou.
Isso não é arquitetura.
É teatro distribuído.
Sistemas multiagentes sérios precisam de disciplina: papéis claros, contratos de entrada e saída, ferramentas autorizadas, estado compartilhado, critérios de parada, políticas de escalonamento, human-in-the-loop, observabilidade e avaliação contínua.
Sem isso, multiagent vira apenas uma versão moderna do velho spaghetti integration.
Só que agora com alucinação.
A arquitetura mais madura
A pergunta não deveria ser: “Agents vão substituir BPM?”
A pergunta correta é: em quais pontos do processo faz sentido inserir capacidade cognitiva?
Use BPM quando o processo é conhecido, estruturado, regulado, repetitivo e precisa de controle operacional.
Use agents quando a tarefa exige interpretação, classificação, análise de texto, busca contextual, recomendação ou tomada de decisão baseada em informações incompletas.
Combine os dois quando o processo precisa de governança, mas algumas etapas exigem inteligência contextual.
A arquitetura que mais faz sentido para empresas não é substituir BPM por agents.
É encaixar agents dentro de processos governados.
O BPM funciona como sistema nervoso do processo. Os agents funcionam como células cognitivas especializadas. As APIs e ferramentas conectam o raciocínio à operação real. O humano entra nos pontos em que risco, valor ou ambiguidade exigem julgamento.
Essa combinação é muito mais próxima da realidade corporativa do que a fantasia de agents totalmente autônomos resolvendo tudo sozinhos.
Exemplos práticos
Há vários processos corporativos nos quais essa combinação faz sentido:
- análise de proposta comercial;
- análise de crédito;
- análise documental;
- triagem jurídica;
- classificação de chamados;
- qualificação de leads;
- atendimento de suporte;
- revisão de compliance;
- processamento de solicitações internas.
Em todos esses casos, o processo não precisa ser entregue cegamente a um agent.
O desenho mais maduro é outro: manter o processo governado e inserir agents nas etapas em que interpretação, contexto e recomendação realmente geram valor.
Continuidade ou ruptura?
A resposta é: as duas coisas.
Há continuidade porque os problemas centrais permanecem os mesmos: processo, integração, estado, exceção, aprovação, auditoria e governança.
Mas há ruptura porque a natureza da unidade executora mudou.
Antes, orquestrávamos sistemas determinísticos e tarefas humanas explícitas.
Agora, passamos a orquestrar componentes probabilísticos capazes de interpretar linguagem, selecionar ferramentas, gerar hipóteses, resumir evidências e recomendar ações.
Isso exige uma nova camada de arquitetura.
Não basta saber promptar. Não basta conhecer uma ferramenta de agent. Não basta desenhar um fluxo bonito.
É preciso pensar como arquiteto.
O futuro da automação corporativa não será feito apenas de chatbots mais inteligentes.
Será feito de processos híbridos, onde BPM, APIs, eventos, dados, agents e humanos trabalham juntos.
BPEL orquestrava serviços. BPM orquestrava processos. Multiagents orquestram decisões, ferramentas e especialistas digitais.
Mas, em produção, todos continuam precisando das mesmas coisas que a arquitetura empresarial sempre defendeu: contrato, estado, governança, observabilidade e responsabilidade.
A tecnologia mudou.
A disciplina continua indispensável.
Leopoldo Carvalho Correia de Lima é arquiteto empresarial sênior, engenheiro de IA e professor em programas de formação executiva em inteligência artificial. Atua há mais de 25 anos com arquitetura empresarial, integração de sistemas, automação, governança tecnológica e aplicações práticas de IA generativa em ambientes de negócio. É autor de Os Demônios de Maxwell no Software Líquido.