v7O agente recebe a instrução de atualizar um pedido. A chamada ao ERP demora, a conexão cai e ele tenta novamente. Minutos depois, há duas reservas de estoque. Em outro fluxo, o sistema responde “sucesso”, mas gravou o cliente certo com a condição comercial errada. O agente encerra a tarefa, o painel fica verde e a divergência só aparece no faturamento.
Quando a IA apenas produz um rascunho, uma falha costuma ser visível antes de gerar efeito. Quando ela cria pedido, agenda visita, altera status, dispara cobrança ou reserva material, a resposta técnica não basta para provar o resultado de negócio. “Enviei”, “recebi HTTP 200” e “concluído” são estados diferentes.
Este artigo apresenta o método RECIBO: um protocolo para registrar a intenção, impedir duplicidade, confirmar o efeito no sistema oficial, limitar tentativas, reconciliar diferenças e compensar o que deu errado. Ele serve tanto para agentes de IA quanto para automações convencionais; a diferença é que um agente pode escolher caminhos e ferramentas dinamicamente, o que aumenta a importância de contratos determinísticos ao redor da ação.
Por que a conversa mudou de resposta para ação
Agentes são sistemas que planejam, usam ferramentas e observam resultados em ciclos. Em abril de 2026, a Anthropic resumiu o avanço de chatbots para agentes capazes de operar arquivos e múltiplas aplicações, alertando que ações mais consequentes ampliam o custo de interpretar mal a intenção. Nenhuma defesa isolada garante confiabilidade.
O World Economic Forum, em seu playbook de maio de 2026, propôs combinar política de delegação, desenho do sistema e supervisão operacional para tornar ações auditáveis, aplicáveis e atribuíveis. Em fevereiro, o NIST lançou uma iniciativa específica para padrões de agentes e destacou que a utilidade real depende da interação confiável com sistemas externos e dados internos.
Para uma PME, essa discussão se traduz em perguntas concretas: se a conexão cair, o agente pode repetir? Como sabe que a atualização ocorreu? Qual sistema decide a verdade? Quem compara o que foi solicitado com o que ficou gravado? Como desfazer uma ação sem apagar mudanças legítimas feitas depois?
“A API aceitou” não significa “o negócio terminou certo”
Uma ação passa por pelo menos quatro estados:
- intenção registrada: sabemos o que deveria acontecer, para qual objeto, sob qual regra e autorização;
- requisição aceita: o sistema de destino recebeu ou enfileirou o comando;
- efeito confirmado: o sistema oficial mostra o estado esperado, com identificador verificável;
- resultado reconciliado: o efeito continua coerente com o pedido, seus dependentes e a regra de negócio.
Um código de sucesso pode provar apenas o segundo estado. Uma atualização de CRM pode ser aceita e depois sobrescrita; um e-mail pode ser enfileirado e rejeitado; uma reserva pode existir sem o preço validado; uma consulta pode ser reagendada sem cancelar o lembrete antigo. O critério de conclusão precisa observar o artefato de negócio, não a autodeclaração do agente.
Método RECIBO: seis controles em torno de cada ação
R — Resultado esperado e estado anterior
Antes de escrever, registre o objeto, o estado atual, a transição permitida e o estado esperado. “Atualizar cliente” é vago. “Mover oportunidade 482 de qualificada para visita agendada, vinculada ao corretor 17, em 19 de agosto às 14h” é verificável.
Use pré-condições. Se o pedido já foi faturado, se o horário deixou de estar livre ou se o preço mudou depois da aprovação, o agente deve parar ou reavaliar — não forçar uma decisão baseada em estado vencido.
E — Evento único e chave de idempotência
Cada intenção de negócio recebe um identificador único, mantido em todas as tentativas. A propriedade técnica é chamada idempotência: repetir a mesma requisição não cria efeitos adicionais. A AWS explica que uma falha de rede deixa o chamador sem saber se a ação ocorreu; tentar novamente sem um identificador pode produzir duplicidade.
A documentação da Stripe mostra um contrato prático: a chave permite repetir uma criação ou alteração sem executar a mesma operação duas vezes, e parâmetros diferentes com a mesma chave são recusados. Não use CPF, e-mail ou outro dado sensível como chave; gere um identificador sem significado pessoal e associe-o ao registro interno protegido.
Quando o sistema legado não suporta idempotência, crie uma camada intermediária que grave intenção, chave, parâmetros e resultado antes de chamar o destino. Uma busca aproximada por nome ou texto não é deduplicação confiável.
C — Confirmação no sistema de registro
Depois da escrita, leia o objeto no sistema que tem autoridade sobre aquele estado. Compare campos críticos, não apenas a existência do registro. A confirmação de uma visita pode exigir ID do lead, corretor, imóvel, horário, status e ausência de conflito; a de um pedido pode exigir cliente, itens, quantidades, preço, condição e reserva.
Defina uma prova de efeito: ID criado, versão, horário, campos esperados e origem. Se a operação for assíncrona, o estado correto pode ser “aceito, aguardando confirmação”, nunca “concluído”. Estabeleça prazo para consultar novamente e um limite após o qual o caso vai para exceção.
I — Impacto, irreversibilidade e compensação
Classifique a ação antes de delegá-la:
- leitura: não altera estado, mas ainda exige controle de acesso e privacidade;
- reversível: pode voltar ao estado anterior com segurança e sem efeito externo relevante;
- compensável: não é simplesmente desfeita, mas existe uma ação de negócio que neutraliza o efeito;
- irreversível ou de alta consequência: exige validação humana ou execução determinística após todas as conferências.
Cancelar uma reserva pode ser uma compensação; apagar a linha como se nunca tivesse existido destrói o histórico. O padrão de transação compensatória do Azure Architecture Center, atualizado em 2026, recomenda registrar cada etapa e como compensá-la. Também lembra que compensação pode falhar, depende da regra do domínio e nem sempre restaura exatamente o estado inicial.
B — Budget de tentativas, espera e bloqueio
Retry infinito não é resiliência. Para cada ferramenta, defina quais erros permitem nova tentativa, quantas vezes, com qual intervalo e quando abrir exceção. Erro de rede pode ser transitório; preço fora da alçada, campo inválido ou cliente bloqueado é erro de negócio e não melhora com repetição.
Use espera progressiva, limite de tempo e trava para impedir duas execuções concorrentes sobre o mesmo objeto quando a operação não tolerar disputa. Mantenha a mesma chave para a mesma intenção; uma nova chave representa uma nova decisão, não uma maneira de contornar falha.
O — Owner, ocorrência e reconciliação
O dono do resultado define a regra de reconciliação e trata o que o sistema não resolveu. Em um horário curto — a cada poucos minutos para agenda, diário para CRM, conforme o processo para estoque ou financeiro — compare:
- intenções aprovadas sem efeito confirmado;
- efeitos no destino sem intenção correspondente;
- duplicidades por objeto, valor ou janela;
- campos críticos divergentes;
- compensações pendentes ou falhas;
- casos parados além do prazo.
Reconciliação não é pedir ao agente para reler o próprio texto. É comparar o livro de intenções com o sistema oficial e, quando necessário, com um segundo sinal independente. A fila resultante precisa de prioridade, responsável, prazo e evidência de encerramento.
O recibo mínimo da ação
Uma tabela simples já melhora a operação. Use uma linha por intenção e registre:
- ID da intenção;
- processo, objeto e sistema de destino;
- estado anterior e versão lida;
- transição e resultado esperados;
- regra e autorização aplicadas;
- chave de idempotência;
- parâmetros críticos, com dados pessoais minimizados;
- número e horário de cada tentativa;
- resposta técnica recebida;
- prova do efeito no sistema oficial;
- status: preparado, enviado, confirmado, divergente, compensando ou encerrado;
- owner, prazo e ação de compensação.
Esse recibo não precisa expor raciocínio interno do modelo nem copiar conteúdo sensível. Ele precisa preservar fatos operacionais suficientes para auditar, reconciliar e recuperar a ação.
Matriz de decisão: como tratar cada tipo de ação
- baixo impacto + reversível: execução automática, confirmação e reconciliação por amostra;
- alto volume + compensável: idempotência obrigatória, confirmação automática e reconciliação integral;
- alto impacto + reversível: pré-condições fortes, limite de autonomia e alerta imediato;
- irreversível, legal, clínica ou financeiramente sensível: agente prepara; pessoa autorizada confirma; sistema determinístico executa.
O nível de autonomia não deve ser definido pela taxa média de acerto. Ele depende da consequência do pior erro plausível, da capacidade de detectar a falha e do custo de compensar.
Exemplos nas verticais da V7
- v7 Obras: ao reservar material, usar referência da solicitação, confirmar item, quantidade, obra e saldo; se a compra posterior falhar, liberar a reserva conforme regra registrada.
- v7 Carteira: ao atualizar cobrança, impedir mensagens duplicadas, confirmar título e status no ERP e reconciliar comunicações com pagamentos que entraram depois da leitura.
- v7 Agro: ao registrar orçamento, validar vigência, unidade, estoque e condição; mudança de preço invalida a pré-condição e devolve o caso ao responsável.
- v7 Imob: ao agendar visita, confirmar disponibilidade, corretor, imóvel e canal; detectar dois agendamentos concorrentes antes de notificar o cliente.
- v7 Clínicas Retorno: limitar o agente a ações administrativas autorizadas, confirmar agenda e lembretes e enviar conflitos ou exceções clínicas para a equipe responsável.
- v7 Custom: envolver cada escrita em ERP, CRM ou sistema interno com intenção, chave única, pré-condição, prova de efeito e rota de recuperação.
Piloto de 20 dias para um fluxo de escrita
- Dias 1 a 3: escolher uma única ação de volume relevante e listar estados, regras e sistema oficial;
- Dias 4 a 6: classificar impacto, reversibilidade, ponto sem retorno e autorização;
- Dias 7 a 9: implementar recibo, identificador de correlação e chave de idempotência ou camada de deduplicação;
- Dias 10 a 12: definir confirmação, prazo, limite de tentativas e fila de exceções;
- Dias 13 a 15: simular timeout antes e depois da gravação, repetição, concorrência, dado vencido e resposta parcial;
- Dias 16 a 18: operar assistido e reconciliar 100% das ações;
- Dias 19 e 20: medir duplicidade evitada, divergência, tempo de confirmação, intervenção e recuperação.
O piloto só avança quando a equipe consegue responder, para qualquer caso: o que foi autorizado, quantas tentativas ocorreram, qual efeito ficou no sistema, como a diferença foi detectada e quem a encerrou.
Checklist para gestores
- Existe um sistema oficial para confirmar o resultado?
- A ação tem estado anterior, transição e estado esperado definidos?
- Dados lidos têm versão ou horário de validade?
- A mesma intenção mantém a mesma chave em todas as tentativas?
- Parâmetros diferentes com a mesma chave são bloqueados?
- O sistema legado precisa de uma camada de deduplicação?
- A confirmação verifica campos críticos, não só o ID?
- Há estados intermediários para operações assíncronas?
- Erros técnicos e de negócio recebem tratamentos diferentes?
- O número de tentativas e o tempo máximo são limitados?
- Ações concorrentes sobre o mesmo objeto são controladas?
- A compensação preserva histórico e respeita mudanças posteriores?
- Casos irreversíveis passam por aprovação autorizada?
- A reconciliação compara intenção e efeito de forma independente?
- Existe owner e SLA para divergências?
Com quatro ou mais respostas “não” ou “não sei”, o agente ainda não tem um contrato de escrita seguro. Mantenha-o em modo de recomendação ou operação assistida até que o fluxo produza recibos confiáveis.
O ponto de vista da V7 Agents
IA gera ROI quando transforma um processo real sem criar dívida operacional invisível. Para isso, precisa de dados, regra, responsável, confirmação e rotina de revisão. Um agente não deve ser a autoridade sobre o próprio sucesso; o sistema de registro e a reconciliação precisam provar o resultado.
O V7 IA Ready identifica ações, sistemas oficiais, riscos e lacunas antes da delegação. Os Agentes Verticais incorporam vocabulário e regras do setor. A Operação Contínua acompanha recibos, divergências, tentativas e compensações para impedir que pequenas falhas virem estoque duplicado, cliente abordado duas vezes ou agenda inconsistente.
Fontes consultadas
- Anthropic — Trustworthy agents in practice, abril de 2026.
- World Economic Forum — AI Agents in Action, maio de 2026.
- NIST — AI Agent Standards Initiative, fevereiro de 2026.
- AWS Builders’ Library — Making retries safe with idempotent APIs.
- Stripe API Reference — Idempotent requests.
- Microsoft Azure Architecture Center — Compensating Transaction pattern, atualizado em abril de 2026.
Seu agente executa ações ou apenas declara sucesso?
O diagnóstico V7 IA Ready mapeia intenção, sistema oficial, idempotência, confirmação, reconciliação, compensação e owner antes de colocar um fluxo de escrita em produção.