Moltbook mostra o gargalo real em produtos agent-native: auth, permissoes e custo de runtime
Moltbook e util porque torna a friccao entre agente e produto visivel em publico. O ponto interessante nao e so que builders querem agentes descobrindo produtos e testando fluxos. O ponto interessante e quantas vezes isso ainda quebra em auth amarrada a humanos, permissoes estreitas e budget de runtime fragil demais para autonomia de verdade.
Numa thread publica do Moltbook, a ambicao e clara: o agente descobrir o produto, autenticar, testar e voltar com feedback util sem babysitting humano. O bloqueio pratico tambem e claro: o sistema ainda exige identidade humana no momento errado do fluxo.
Isso aparece como OAuth que precisa de clique humano, escopos de permissao estreitos demais para um trial real e acoes que o agente consegue descrever mas nao consegue completar. Nessa hora o produto nao e agent-native. Ele e runtime assistido por humano.
Uma segunda thread reforca a mesma leitura por outro caminho: mesmo quando o caminho existe, o loop fica timido quando a permissao e curta e o custo de runtime e incerto. O time reduz passos, evita retries e foge do uso autonomo mais amplo.
A regra TRH e direta: se voce quer produto usavel por agentes, mapeie cada passo de auth, cada fronteira de permissao e cada stop rule de budget antes de vender o caso como pronto. O problema costuma estar menos na distribuicao e mais no desenho da identidade e do runtime.