Humanos e Agentes de IA Precisam de Um Registro de Comércio, Não Duas Realidades

Uma demonstração de comércio com IA pode parecer completa após três etapas:

prompt -> pesquisa de produto -> chamada de ferramenta

Isso é suficiente para demonstrar conectividade. Não é suficiente para demonstrar comércio.

As perguntas difíceis começam imediatamente depois:

• O vendedor publicou informações suficientes para uma decisão?
• O preço cotado ainda era válido quando o pedido foi enviado?
• O Agente preparou um pedido ou fez um compromisso vinculativo?
• Qual humano aprovou a etapa consequente?
• Qual caminho de liquidação foi selecionado?
• Se uma resposta expirou, a ação falhou, teve sucesso ou permaneceu desconhecida?
• Que evidências o comprador, vendedor e operador podem inspecionar mais tarde?

Um sistema orientado à produção não deve responder a essas perguntas de forma diferente, dependendo se o usuário chegou através de um navegador ou de um Agente.

Humanos e Agentes precisam de permissões diferentes sobre um registro de comércio explícito, não duas realidades incompatíveis.

Comece com fatos compartilhados

Um Agente não pode tomar uma decisão de compra confiável apenas com cópias de marketing. Um registro de produto útil precisa de fatos relevantes para a decisão, como:

{
  "preço": "19,90 USDC",
  "disponibilidade": "em_estoque",
  "tempo_de_manuseio": "dentro de 72h",
  "estimativa_de_entrega": "7-14 dias",
  "janela_de_retorno": "7 dias",
  "desconhecidos": ["transportadora final antes do cumprimento"]
}

O esquema exato diferirá de sistema para sistema. A propriedade importante é que uma pessoa e um Agente inspecionem os mesmos fatos, incluindo o que não é conhecido.

Se o navegador diz "disponível" enquanto o endpoint do Agente retorna um inventário desatualizado, o sistema não criou um comércio agente. Ele criou uma segunda vitrine, menos visível, que eventualmente discordará da primeira.

Separe a preparação do compromisso

Muitas ações úteis do Agente são reversíveis:

• pesquisar;
• comparar;
• solicitar uma cotação;
• montar um carrinho;
• preparar um pedido;
• explicar os termos ao usuário.

A fronteira do compromisso é diferente. Criar um pedido, autorizar o pagamento ou aceitar um termo consequente não deve ser disfarçado em uma cadeia de ferramentas que parece inofensiva.

Um fluxo mais seguro se parece com isto:

descobrir
  -> cotação
  -> preparar pedido
  -> mostrar termos e desconhecidos
  -> aprovação humana
  -> criar pedido

A WebAZ atualmente usa essa distinção em seu caminho de comércio autenticado. Um Agente pode pesquisar, cotar, redigir e enviar um pedido. Uma aprovação de Passkey humana é necessária antes que o pedido exista.

O MCP de compras públicas revisado é mais restrito por design. É anônimo e apenas para descoberta: expõe pesquisa, mas não pode criar pedidos ou mover fundos.

Essa limitação é uma propriedade do produto, não um efeito de demonstração ausente. Um cliente pode conectar a superfície sem acidentalmente dar a um prompt exploratório autoridade transacional.

Os caminhos de liquidação devem permanecer distinguíveis

“Pagamento suportado” esconde mais do que explica.

Mecanismos de liquidação diferentes têm diferentes suposições de confiança, modos de falha e opções de recuperação. Eles não devem ser apresentados como botões intercambiáveis atrás de uma reivindicação de pagamento genérica.

A WebAZ atualmente expõe dois caminhos de liquidação reais.

Pagamento Direto

O Pagamento Direto suporta pagamento fora da plataforma do comprador para o vendedor. A WebAZ registra estados de pedidos, reconhecimentos, uma captura das instruções de pagamento do vendedor e evidências submetidas.

A fronteira é importante: a WebAZ não retém o principal. Ela não verifica o beneficiário ou o método de pagamento, garante pagamento ou entrega, ou emite o reembolso do vendedor.

Escrow on-chain USDC

O caminho USDC bloqueia fundos reais em um contrato imutável na Base-mainnet. O contrato restringe saídas e impõe limites por pedido na cadeia; a WebAZ não custodia o principal.

O contrato não teve uma auditoria de segurança de terceiros. Essa divulgação pertence ao lado do recurso, não em uma nota de rodapé que desaparece durante a promoção.

O princípio compartilhado não é que os dois caminhos sejam igualmente seguros. É que o caminho selecionado e sua fronteira permaneçam visíveis no registro da transação.

O pagamento não é cumprimento

Um provedor de pagamento pode relatar sucesso enquanto o sistema de comércio ainda carece de um pedido confirmado, alocação de inventário ou estado de cumprimento.

Os Agentes tornam essa distinção mais urgente porque uma nova tentativa automatizada pode transformar um tempo limite ambíguo em uma ação consequente duplicada.

Após cada gravação, o sistema deve ser capaz de responder:

1. Qual é o último fato comprovado?
2. O que permanece desconhecido?
3. É seguro tentar a próxima ação novamente?
4. Qual participante age a seguir?
5. Que evidência apoia essa conclusão?

É por isso que estado, reconhecimentos, evidências, recuperação e manuseio de disputas fazem parte da interface de comércio, em vez de detalhes de back-office.

Aplique a mesma disciplina à contribuição

A participação do Agente tem um problema de fronteira semelhante.

Um Agente pode descobrir uma tarefa pública, inspecionar suas restrições e preparar uma sugestão respaldada por evidências. Isso não torna automaticamente a sugestão uma contribuição aceita, concede acesso à fonte ou cria uma reivindicação econômica.

O núcleo de produção da WebAZ é privado. O acesso à fonte e as contribuições de código são baseadas em convite. O trabalho assistido por IA convidado requer um humano responsável vinculado a uma Passkey.

Novamente, diferentes papéis operam em um registro:

solicitante -> executor/ferramenta -> revisor -> artefato aceito -> parte responsável

O Agente pode ser nomeado como executor sem ser apresentado como a pessoa que aceitou a responsabilidade pelo envio do resultado.

Um teste de implementação de quatro perguntas

Pegue uma transação real em seu próprio sistema e pergunte:

1. O que o Agente pode ler?
2. O que ele pode preparar sem comprometer o usuário?
3. Qual etapa exata requer aprovação humana?
4. Que evidência permanece após essa ação?

Se as superfícies do navegador e do Agente produzirem respostas diferentes, a integração ainda não está operando sob um modelo de comércio único.

Se "pagamento bem-sucedido" é o último estado explicável, o registro da transação está incompleto.

Se o Agente pode se comprometer, mas ninguém pode identificar o aprovador responsável, o modelo de permissão está incompleto.

O objetivo não é máxima autonomia. É autonomia legível: e