A tela apresenta opções e ajuda a pessoa a decidir. O serviço que a atende calcula condições e registra mudanças. Quando esses papéis estão misturados, adicionar um agente tende a reproduzir regras em outro lugar, criando diferenças de preço ou de elegibilidade entre canais.
O ponto de partida é delimitar uma operação real: por exemplo, preparar um carrinho e encaminhar o comprador para confirmar. Não existe obrigação geral de aceitar oito modalidades de compra, nem justificativa para retirar verificações de risco apenas porque a chamada veio de uma máquina.
Neste guia
Qual contrato precisa existir entre o canal e a loja?
O contrato descreve os dados recebidos, as respostas possíveis e quem pode mudar cada informação. O canal envia o item escolhido, a quantidade e os dados necessários à entrega. A loja devolve condições calculadas, pendências e a próxima ação permitida. O valor sugerido pelo agente não deve substituir o cálculo comercial autorizado.
Inclua uma referência estável da sessão, sua validade e uma versão das condições apresentadas. Se frete, promoção ou quantidade mudar, a resposta precisa permitir que o canal mostre essa mudança. Um texto genérico de sucesso é insuficiente para decidir se já existe um pedido ou apenas uma proposta.
Quais estados evitam confundir carrinho com pedido?
| Situação | Decisão operacional |
|---|---|
| Informações incompletas | Pedir somente o que falta e preservar o restante. |
| Condições calculadas | Apresentar total e prazo sem declarar pagamento. |
| Ação do comprador necessária | Encaminhar para uma superfície confiável. |
| Resultado incerto | Consultar a operação antes de reenviar. |
| Pedido confirmado | Relacionar pedido, pagamento e atendimento. |
Esses nomes são um modelo de análise, não os nomes obrigatórios de um protocolo. A implementação deve mapear seus estados para o contrato adotado e registrar transições inválidas. Uma solicitação cancelada não pode reaparecer como compra nova apenas porque uma fila entregou novamente a mensagem.
Quando a pessoa ainda precisa participar?
Na especificação UCP de 25 de agosto de 2026, a conclusão manual em uma interface confiável é o padrão, salvo uso negociado da extensão AP2 Mandates. Portanto, aceitar UCP não significa aceitar execução autônoma irrestrita. O desenho da integração precisa explicitar qual caminho foi contratado e testado.
Também pode haver autenticação adicional, confirmação de condições alteradas ou uma restrição do meio de pagamento. Nesses casos, informe a pendência e ofereça continuidade. Prometer que todo desafio será invisível pode transformar uma proteção legítima em falha de compra sem explicação.
Como impedir que uma falha técnica crie duas compras?
Considere um exemplo hipotético: a loja confirma um pedido de duas luminárias, mas a conexão cai antes de o agente receber a resposta. O agente interpreta o silêncio como falha e tenta novamente. Sem uma referência consistente da operação, a loja pode criar outro pedido e outra cobrança.
A recuperação deve consultar o estado conhecido e reutilizar a chave de idempotência conforme o contrato, mantendo os mesmos parâmetros da tentativa original. Idempotência não corrige uma chave diferente para cada repetição nem substitui a proteção no sistema de pedidos. Teste também mensagens de pagamento duplicadas e recebidas fora de ordem.
Como aprovar a integração antes de ampliar o acesso?
Use critérios observáveis: alteração de preço exige nova apresentação das condições; falta de estoque bloqueia a confirmação; repetição da mesma operação não duplica pedido; expiração da sessão é explicada; pendência humana mantém um caminho utilizável. Registre o resultado esperado e o responsável por corrigir cada falha.
O guia de protocolos do commerce agêntico detalha a homologação ponta a ponta. Para discutir contratos e estados com a equipe técnica, o curso Software e IA para executivos oferece vocabulário útil. A próxima ação é escolher um único fluxo de compra, desenhar seus estados e executar uma falha de conexão em cada transição antes de abrir novos canais.