A demo sempre termina no insight. O agente lê dados de pedido de compra, identifica uma anomalia e apresenta uma recomendação. A sala acena. Então alguém pergunta: “e depois? Ele atualiza o registro?” A sala fica quieta. Esse é o momento em que o projeto real começa.
O write-back é onde projetos de agentes corporativos falham ou têm sucesso. É onde as decisões arquiteturais que foram puladas na fase de protótipo se tornam inevitáveis.
O Problema de Write-Back que Ninguém Resolve na Demo
Demos de agentes são construídas em torno da metade segura do loop: ler dados do ERP, gerar insight, sumarizar em formato legível. O modelo tem bom desempenho nisso. As operações de leitura são idempotentes. Erros são visíveis e corrigíveis. A folha de pagamento de ninguém é afetada.
Produção é diferente. O agente precisa escrever de volta: atualizar um status de pedido de compra, fechar um ticket, reclassificar uma transação, acionar um fluxo de aprovação, criar um registro de fornecedor. Essas operações não são idempotentes. Resolução errada de entidade cria registros duplicados. Transações incompletas deixam o ERP em estado inconsistente. Escritas duplicadas corrompem dados dos quais sistemas downstream dependem. E diferente de uma resposta de RAG alucinada que um usuário pode descartar, uma escrita ruim no ERP exige que um humano a encontre, entenda e corrija manualmente.
Três modos de falha respondem pela maioria dos incidentes de write-back:
Resolução errada de entidade. O agente recebe “atualizar o pedido para Carlos Lima” e encontra dois registros que correspondem ao nome, um para um funcionário e outro para um contato externo. Sem uma etapa de disambiguação, ele escolhe um. Escolhe o errado 40% das vezes, o que é 40% de vezes a mais quando a operação é irreversível.
Transação incompleta. O fluxo de trabalho do ERP exige três etapas: criar registro, anexar documento, acionar roteamento de aprovação. O agente completa as etapas um e dois. Um timeout de API interrompe a etapa três. O ERP agora está em estado inconsistente: um registro existe, um documento está anexado, mas o fluxo de aprovação nunca foi acionado. A próxima pessoa a olhar para o registro não consegue dizer se o processo foi concluído ou abandonado.
Sem plano de rollback. O agente inicia um fluxo de trabalho de múltiplas etapas. A etapa quatro falha. Não há procedimento de rollback definido para as etapas um a três. A correção manual leva quatro horas. O projeto de agente é pausado aguardando revisão de governance.
Esses não são problemas de LLM. São problemas de arquitetura de software. Têm soluções de arquitetura de software.
Resolução de Entidade Antes do Write-Back
A regra cardinal do write-back em ERP: nunca escreva em um registro usando uma string de nome. Sempre resolva para um identificador canônico primeiro.
Resolução de entidade é uma camada de lookup dedicada entre o agente e o ERP. Recebe input em linguagem natural, consulta o próprio modelo de identidade do ERP, retorna o identificador canônico para o registro alvo e fornece uma pontuação de confiança e informação de disambiguação.
A arquitetura: o agente produz um objeto de intenção estruturado (“atualizar pedido de compra para fornecedor X, alterar status para aprovado, valor Y”). A camada de resolução de entidade recebe esse objeto, consulta o ERP por registros correspondentes ao fornecedor X, retorna zero ou mais candidatos com pontuações de confiança. Se um candidato superar o limiar de confiança, o identificador é passado para a camada de write-back. Se nenhum candidato superar o limiar, o agente para e traz a ambiguidade à superfície para resolução humana.
O limiar de confiança não é arbitrário. É calibrado contra a qualidade dos dados do seu ERP específico. ERPs com master data limpo toleram um limiar mais alto. ERPs com anos de dados legados, registros duplicados e convenções de nomenclatura inconsistentes exigem um limiar mais baixo e gates de resolução humana mais frequentes. A camada de resolução de entidade revela a qualidade dos dados do seu ERP antes de afetar operações de produção.
Para TOTVS Protheus, SAP ou Oracle: a resolução de entidade deve respeitar o próprio modelo de identidade do ERP. O Protheus usa seu próprio schema de identificador de entidade. Impor um modelo de identidade externo sobre ele introduz uma camada de mapeamento que se torna uma responsabilidade de manutenção. Consulte os identificadores de entidade do próprio ERP através da sua própria API.
A Arquitetura Human-in-the-Loop para Ações de ERP
Toda ação de ERP que um agente pode executar deve ser classificada antes do agente rodar, não depois de falhar.
O framework de classificação:
| Tipo de ação | Reversibilidade | Requisito de aprovação |
|---|---|---|
| Leitura | N/A | Nenhum |
| Escrita de baixo risco | Reversível, baixo impacto de negócio | Registrar e executar |
| Escrita de alto risco | Reversível, impacto significativo de negócio | Aprovação humana antes da execução |
| Irreversível | Não pode ser desfeito | Aprovação dupla com log de auditoria completo |
Essa classificação é uma configuração de software, não uma instrução de modelo. O agente não decide em qual categoria uma ação se enquadra em tempo de execução. As categorias são definidas em tempo de design, mapeadas para tipos de ação e aplicadas pela camada de orquestração.
Canais de aprovação que funcionam na prática: uma mensagem no Slack com botões de aprovar e rejeitar, um e-mail com um token de aprovação assinado, ou uma fila de portal interno com notificação. A interface de aprovação deve mostrar ao aprovador exatamente o que o agente pretende fazer, em linguagem simples, com o contexto de negócio que motivou a ação. “Aprovar encerramento do PC-2891 (fornecedor: ABC Manufacturing, valor: CHF 45.000, motivo: entrega confirmada pelo sistema de armazém em 2026-04-12)” é aprovável. “Agente propõe operação de escrita no registro ERP ID 2891” não é.
Um princípio de design do framework 12-Factor Agents: aprovação humana é um componente de sistema, não um caminho de exceção. Construa o fluxo de aprovação antes da primeira ação do agente tocar dados de produção. Se o fluxo de aprovação não existir quando o agente chegar a uma ação de alto risco, ele ou pulará a aprovação (produzindo o incidente) ou parará sem caminho de escalada (produzindo o ticket de suporte).
Transações de ERP são frequentemente não-atômicas. Se um agente inicia um fluxo de trabalho de múltiplas etapas, o plano de rollback deve ser definido e testado antes da primeira etapa executar. Não “resolveremos o rollback se algo der errado.” Procedimentos de rollback definidos, mapeados para cada tipo de ação, testados contra um ambiente de staging. A primeira vez que o procedimento de rollback é necessário não é o momento certo para escrevê-lo.
O Padrão de Servidor MCP para Integração com ERP
Expor capacidades do ERP como servidores MCP transforma cada capacidade em uma interface governada: schema de input tipado, acesso autenticado, rate limiting e um log de auditoria para cada invocação.
O padrão: cada capacidade do ERP, “criar pedido de compra,” “atualizar registro de fornecedor,” “fechar ticket,” se torna uma ferramenta MCP separada com um schema de input definido, permissões definidas e comportamento de auditoria definido. Agentes acessam capacidades do ERP através dessas ferramentas. Chamadas diretas ao banco de dados, chamadas diretas à API REST sem governance e integrações ad hoc que ignoram a camada de permissão não são permitidas.
Benefícios na camada de governance: permissões para operações de escrita no ERP são configuradas uma vez na camada MCP e herdadas por todo agente que usa essas ferramentas. Novas capacidades são adicionadas ao servidor MCP e ficam disponíveis para todos os agentes autorizados simultaneamente. Capacidades depreciadas são removidas uma vez e desaparecem em todo lugar.
Para TOTVS Protheus especificamente: nenhum servidor MCP oficial da TOTVS existe até o momento mais recente de pesquisa [verificar status atual antes da implantação]. Implementação customizada usando APIs REST do Protheus é necessária. Isso é trabalho de engenharia, não uma tarefa de configuração.
Uma consideração de segurança que não pode ser adiada: uma classe de vulnerabilidade RCE no design do protocolo MCP em 2026 confirmou que servidores MCP são software e exigem as mesmas práticas de segurança que qualquer outro componente de produção. Whitelist, patches atuais e logging de auditoria na camada de gateway. Um servidor MCP conectado a um ERP de produção é uma superfície de ataque de alto valor.
O Rollout em Fases que Previne Desastres
Nenhum projeto de agente corporativo deve ir de piloto para autonomia total de write-back em uma única etapa. O rollout em fases existe porque cada fase traz à superfície problemas antes que as consequências sejam em escala de produção.
Fase 1: somente leitura. O agente lê dados do ERP, apresenta recomendações e para. Sem capacidade de escrita. Rodar por quatro a oito semanas. Validar precisão de resolução de entidade, trazer à superfície problemas de qualidade de dados no master data, confirmar que as recomendações estão direcionalmente corretas. As constatações de qualidade de dados da fase 1 tipicamente reordenam o trabalho das fases 2 a 4.
Fase 2: escrita supervisionada. O agente propõe ações. Um humano revisa e aprova cada uma antes da execução. Rodar até a taxa de aprovação estabilizar, tipicamente acima de 95% sem modificação. Propostas rejeitadas são material diagnóstico para melhorar a resolução de entidade.
Fase 3: escrita autônoma com monitoramento. Tipos de ação pré-aprovados executam sem revisão humana. Todas as execuções registradas. Detecção de anomalias sinaliza desvios para revisão humana.
Fase 4: automação de alto volume. Somente para tipos de ação com precisão comprovada e baixo risco de reversibilidade nas fases 1 a 3.
Pular uma fase é acelerar em direção ao incidente de corrupção de dados que pausa o programa por dois trimestres.
O Business Case para Fazer Isso Certo
Fornecedores de ERP estão lançando suas próprias camadas de IA: TOTVS LYNN (anunciada em fevereiro de 2026), SAP Joule, assistentes integrados da Oracle. Essas são soluções genéricas. Não são construídas em torno dos seus processos específicos, características de qualidade de dados ou restrições regulatórias.
Agentes customizados com conhecimento profundo de processo e uma camada de integração governada superam copilots de fornecedores para fluxos de trabalho especializados. A infraestrutura de integração, serviço de resolução de entidade e trilha de auditoria de ações são reutilizáveis em todo projeto de agente subsequente. O segundo projeto custa uma fração do primeiro.
As equipes que se movem mais rápido na integração de agentes com ERP são as que investiram em governance cedo o suficiente para ter uma fundação estável quando o negócio demandou escala.
Para equipes corporativas avaliando integração de agentes com sistemas de negócio centrais, o AI Opportunity Sprint mapeia a arquitetura de integração antes de qualquer código ser escrito.