Depois dos pagamentos, o próximo campo de batalha da economia dos agentes: mercados de tarefas

Autor: Delphi

Compilação: AididiaoJP, Foresight News

O comércio eletrónico por agentes tem sido discutido há dois anos, e a componente de pagamentos foi a primeira a ganhar tração. A Stripe permite que os agentes paguem a comerciantes, o x402 da Coinbase oferece um canal de liquidação em stablecoins, e a compra de dados e serviços de inferência por utilização já está operacional. Mas quando uma tarefa ultrapassa o simples "chamar uma API uma vez", o problema muda: o agente não consegue concluí-la sozinho, precisa de subcontratar parte do trabalho e confirmar que a outra parte realmente fez o que foi acordado.

Este artigo da Delphi centra-se exatamente nessa etapa. Um mercado de tarefas não é mais um protocolo de pagamentos, mas sim um local onde os agentes podem subcontratar as partes que não conseguem concluir: primeiro define-se o entregável, depois inicia-se a execução, e o pagamento só é libertado após a aceitação do resultado. Se a transferência for fiável, a tarefa pode avançar sem arrastar o utilizador de volta para o papel de gestor de projeto, a coordenar fornecedores passo a passo.

Comprar inputs não é o mesmo que comprar resultados

Quando um senhorio está a selecionar inquilinos, um agente pode obter relatórios de crédito e registos de despejo junto de fornecedores já existentes. A outra parte devolve materiais padronizados, e o senhorio decide com base neles. Aqui, compra-se um input para a decisão; o fim da tarefa continua nas mãos do senhorio.

Uma contestação do imposto predial é diferente. O agente pode comparar transações na vizinhança e descobrir que a avaliação parece demasiado alta, mas essa descoberta não altera automaticamente a nota de liquidação. Para avançar, normalmente é preciso encontrar alguém familiarizado com os procedimentos do condado para entregar a documentação e comparecer em tribunal. O mercado de tarefas deve ajudar o agente a encontrar essa pessoa e a definir antecipadamente o modo de trabalho e as condições de pagamento.

O primeiro caso aproxima-se do atual modelo de pagamento por utilização: preço claro, entregável padronizado e verificação quase automática. No segundo, compra-se um assunto concluído. A entrega de documentos não significa que o processo esteja pronto, e um recibo não equivale a conformidade. As condições de pagamento têm de estar ligadas a um "resultado verificável", e não ao facto de a outra parte "afirmar que fez".

É também esta a fronteira entre um mercado de tarefas e um mercado comum de APIs (Interface de Programação de Aplicações): o mercado de APIs vende chamadas; o mercado de tarefas vende unidades de trabalho concluídas e confirmadas.

Sem uma definição clara da tarefa, o mercado não funciona

Para uma tarefa poder entrar num mercado de tarefas, é preciso primeiro defini-la de modo que ambas as partes saibam exatamente a que resultado o dinheiro está associado. Um especialista pode perfeitamente entregar materiais de contestação de baixíssima qualidade e, ainda assim, anexar um recibo. Se o comprador paga por "um material conforme", alguém tem de rever os materiais antes de libertar o pagamento.

Quem faz a revisão e como qualquer das partes pode contestar o resultado da revisão deve, idealmente, ficar escrito na encomenda. Assim, o comprador não teme receber uma entrega de má qualidade, e quem aceita a tarefa não teme uma recusa de pagamento sem justificação. Sem esta camada, o mercado descamba para dois maus cenários: ou o comprador recusa pagar arbitrariamente e a oferta profissional não quer entrar, ou basta apresentar um resultado superficial para receber e o comprador deixa de publicar tarefas.

Tarefas demasiado pequenas também não compensam. Se o custo da revisão e da resolução de litígios for superior à poupança obtida com a subcontratação, as pessoas voltam a fazer o trabalho elas próprias ou continuam a usar apenas interfaces padronizadas. Por isso, numa fase inicial, o mercado surgirá mais provavelmente em tarefas com fronteiras claras, repetíveis e com verificação objetiva, e não em encomendas vagas e pontuais.

As empresas serão compradoras iniciais mais adequadas. Já dividem tarefas entre vários fornecedores e têm processos internos e padrões de comparação. O agente pode preparar a tarefa dentro da empresa, subcontratar as etapas que têm de ser externalizadas e depois confrontar o resultado recebido com os processos existentes. Se a tarefa for recorrente, quem a executa também acumula um histórico de conclusões desse tipo. Quando a reputação pode ser acumulada, a correspondência seguinte não precisa de construir confiança a partir do zero.

Os utilizadores individuais não estão excluídos, mas, numa fase inicial, funcionam mais como demonstração. As empresas têm orçamento, compras repetidas e hábitos internos de verificação, o que as aproxima mais da densidade de encomendas necessária para arrancar o mercado.

Os pagamentos só resolvem a transferência; contratar pessoas ainda exige verificação

Entre enviar dinheiro e contratar uma tarefa existem custódia, entrega, verificação e contestação. A Stripe e o x402 cobrem a primeira metade. O agente continua a precisar de encontrar alguém para entregar a contestação e representar o proprietário. Sem verificação, quanto mais fáceis forem os pagamentos, mais depressa podem avançar as encomendas erradas.

Os produtos existentes já estão estruturados desta forma.

No TaskMarket (mercado de tarefas) da Daydreams, o comprador publica a tarefa e os agentes candidatam-se. O comprador deposita primeiro os fundos e pode deixar que os trabalhadores reivindiquem diretamente a tarefa ou pode primeiro analisar propostas e depois escolher. Os fundos ficam em custódia e só são libertados depois de o resultado entregue ser aceite.

No Agent Commerce Protocol da Virtuals, o agente que delega e o agente que executa negociam a tarefa, os fundos entram em custódia e são libertados após a entrega e aprovação. Também é possível incluir avaliadores externos para verificar se o resultado corresponde ao que foi previamente acordado. Do lado da NEAR (plataforma blockchain), tarefas, orçamentos, propostas e verificação estão a ser integrados num único fluxo, com a mesma orientação: "precificar a tarefa concluída" e não apenas uma chamada.

Os caminhos não são exatamente iguais, mas a estrutura é semelhante: publicar, corresponder, custodiar, entregar, verificar, libertar. Sem verificação, a custódia é apenas uma transferência adiada; com verificação, a custódia torna-se uma restrição sobre o resultado.

Há quem escreva a verificação de forma ainda mais detalhada: é preciso especificar o conteúdo da delegação, quem executa, o preço, o verificador, o entregável, a janela de contestação e o estado do reembolso. Quanto mais completa for a documentação, mais facilmente os agentes podem passar tarefas entre si, sem voltar a transformar o utilizador num coordenador.

Com mais um passo, os erros amplificam-se

O mercado de tarefas não é proposto apenas porque subcontratar soa sofisticado, mas porque fluxos com vários passos amplificam os erros. Numa tarefa de dez passos, se cada passo tiver 95% de probabilidade de estar correto, a probabilidade de concluir tudo sem erros é de apenas cerca de 60%. Cada transferência sem verificação arrasta o erro anterior para a etapa seguinte.

Por isso, o mercado precisa de pontos de controlo nas transferências: só se compra a etapa seguinte depois de a anterior ser aprovada. O erro fica retido no próprio passo, em vez de percorrer todo o fluxo e só no final se descobrir que a encomenda inteira é inválida. Isto é especialmente verdade para os agentes. Ao contrário de um funcionário de uma empresa, não se pode convocar uma reunião para apurar responsabilidades; o agente precisa de condições de verificação e regras de libertação de pagamento definidas antecipadamente.

Isto também explica por que a maioria das transações com agentes continua limitada a serviços cripto-nativos e simples: tarefas curtas, resultados fáceis de verificar e poucos litígios. O que realmente fará a diferença é encadear vários fornecedores em fluxos de trabalho mais longos e controlar cada passo.

O que se vê agora é a estrutura, não a escala

O que um mercado de tarefas tem de fazer é muito concreto: permitir que os agentes subcontratem parte das tarefas, pagar apenas depois de o resultado ser aceite e, assim, concluir realmente mais tarefas. A camada de pagamentos já existe. O que falta são unidades de trabalho concluído verificáveis, verificação com custo aceitável e uma densidade suficiente de encomendas repetidas.

A extensão dos processos internos das empresas para fora será a primeira procura séria. As delegações complexas do lado individual terão de esperar que os custos de verificação e de resolução de litígios baixem primeiro. Até lá, mais importante do que mais um protocolo de pagamentos é observar se três coisas aparecem em simultâneo: se a tarefa pode ser escrita como uma documentação verificável, se a custódia consegue reter os fundos até à aprovação e se quem executa tem um histórico de conclusões acumulável.

Com estas três condições reunidas, os agentes terão a oportunidade de concluir tarefas, em vez de as deixarem a meio e chamarem o utilizador de volta para continuar a ser o gestor de projeto.