Sua IA respondeu “feito”. Mas a tarefa foi concluída?

Comece pelo resultado que encerra o trabalho

Vamos acompanhar um exemplo fictício. Uma equipe comercial recebe a solicitação de alterar o endereço de entrega do cadastro C-104. O cliente possui um endereço fiscal e outro de entrega. O resultado esperado é mudar apenas o segundo, preservando os demais campos. O pedido de compra que já está em separação fica fora dessa alteração e precisa de tratamento próprio.

Essa descrição faz diferença antes de qualquer discussão técnica. “Atualizar o endereço” pode significar alterar o cadastro, corrigir um pedido em aberto ou registrar uma solicitação para análise. Se pessoas e sistemas usam sentidos diferentes, uma execução tecnicamente bem-sucedida pode produzir o resultado errado.

Por isso, o primeiro acordo é operacional: qual objeto muda, quais campos podem mudar e qual evidência permite encerrar a tarefa? Neste exemplo, o encerramento exige consultar o cadastro no sistema responsável e encontrar o endereço solicitado no campo correto. A confirmação do pedido em separação seria outra tarefa, com outro responsável.

Ligue pedido, autoridade, execução e confirmação

Reconstruir o percurso ajuda a separar perguntas que normalmente aparecem misturadas no histórico de uma conversa. O pedido explica a intenção. A autoridade define o que aquele participante pode fazer. A execução registra a tentativa. A confirmação confronta essa tentativa com o estado que importa para o processo.

Esses registros precisam ter uma ligação reconhecível. Uma identificação da tarefa, a referência do cadastro e a sequência das tentativas ajudam a equipe a reconstruir o percurso sem depender de adivinhar quais mensagens pertencem à mesma operação. O desenho dessa ligação depende dos sistemas envolvidos.

A permissão precisa valer no ponto da ação

No exemplo, a regra pode permitir que o agente prepare uma alteração, mas exigir aprovação de uma pessoa antes de gravá-la. Essa pessoa precisa ver o cadastro escolhido, o campo atual e o valor proposto. Aprovar uma intenção vaga não oferece o mesmo contexto que aprovar uma alteração específica.

Depois da aprovação, a integração precisa executar aquilo que foi autorizado. Se o cadastro ou o endereço proposto mudar, o projeto deve definir quando a aprovação deixa de valer e precisa ser refeita. Também é preciso prever como suspender a operação e quem pode retomar o trabalho.

Um gateway de modelos pode ajudar a administrar acesso e consumo das chamadas ao modelo. Isso não demonstra, por si só, que uma atualização de cadastro foi autorizada ou que o sistema aplicou a alteração. Se o agente chama a API do cadastro por outro caminho, é nesse percurso que os controles da ação precisam ser definidos e integrados. A cobertura deve ser verificada em cada implantação.

Trate “não sei se concluiu” como um estado real

Imagine que a integração enviou a atualização, mas a resposta não chegou. Há pelo menos duas possibilidades: o destino não recebeu a chamada ou recebeu e alterou o cadastro antes de a conexão cair. Mandar o agente tentar novamente, sem investigar, não distingue essas situações.

Para uma substituição simples de campo, repetir o mesmo valor pode parecer inofensivo. Mas a mesma lógica aplicada a um envio de mensagem, uma cobrança ou a criação de um pedido pode produzir efeitos duplicados. O procedimento de recuperação deve considerar o tipo de ação e as proteções que o sistema oferece.

Em HTTP, idempotência significa que repetir uma requisição idêntica tem o mesmo efeito pretendido no servidor que executá-la uma vez. Isso não garante respostas iguais nem comprova o resultado do negócio. A RFC 9110 orienta a não repetir automaticamente uma requisição não idempotente sem saber que a operação pode ser repetida ou que a primeira tentativa não foi aplicada. Na integração, confirme essa propriedade antes de adotar a repetição como recuperação.

A comunicação com a pessoa deve acompanhar esse estado. “A atualização foi solicitada; ainda estamos conferindo o cadastro” descreve melhor uma execução incerta do que “feito”. Se a confirmação depender de processamento posterior, combine também quando consultar novamente e quando uma pessoa assume.

Guarde evidência que alguém consiga interpretar

Um registro útil responde a uma investigação concreta. Neste cenário, interessam a referência da solicitação, o cadastro escolhido, os campos autorizados, o responsável pela aprovação quando aplicável, o resultado da chamada e a confirmação no destino. Acrescentar todo o conteúdo de todas as conversas não substitui essa organização.

Também há uma escolha sobre quais dados registrar. Um endereço completo pode ser necessário no sistema que realiza a entrega, mas não em todos os painéis de acompanhamento. Defina com a equipe quais informações cada papel precisa consultar e como encontrar o registro de origem quando houver uma investigação.

A ausência de um registro não prova que a ação falhou. Um registro de sucesso tampouco prova que o objetivo de negócio foi atingido. A equipe precisa entender o alcance de cada evidência: recebimento da chamada, gravação do campo e entrega efetiva são acontecimentos diferentes.

Melhore um percurso antes de ampliar a cobertura

Escolha uma ação que a equipe já conheça e reconstrua um caso concluído e um caso com dúvida. Coloque lado a lado o pedido, a regra, a tentativa e o resultado. Marque o que foi observado, o que foi declarado por alguém e o que ainda falta verificar.

A próxima melhoria pode ser pequena e específica: exibir o campo antes da aprovação, ligar os registros pela referência da tarefa ou criar uma fila para confirmações pendentes. Defina quem fará a mudança e repita o mesmo percurso para conferir seu efeito.

Começar com agentes próprios ou de terceiros é compatível com esse trabalho. A pergunta inicial é onde eles atuam e quais pontos podem ser observados ou controlados. A resposta orienta o escopo de integração; não deve ser presumida pela presença de um produto no desenho.

Perguntas para levar à equipe

• Qual estado no sistema de destino encerra esta tarefa?
• A autorização identifica o objeto e a alteração que serão executados?
• O que fazemos quando a chamada pode ter funcionado, mas a confirmação não chegou?
• Quem consegue reconstruir uma tentativa sem depender do relato do agente?

Antes de ampliar a autonomia, torne uma ação verificável de ponta a ponta. Um mapa que admite “ainda não sabemos” ajuda a equipe a escolher o próximo controle com mais precisão.