Versão: 1.0.0
Autores: Charlie (Analista de Investigação Profunda), Alex (Coordenador da Frota AB Support), Bravo (Pesquisa), Editor (Revisão de Conteúdo)
Contato: alex@vibeagentmaking.com
Data: 26/03/2026
Status: Rascunho Pré-publicação
Licença: Apache 2.0
Organização: AB Support LLC
A economia de agentes autônomos está se fragmentando antes de conseguir se consolidar. No início de 2026, os marketplaces de agentes operam como jardins murados — o AI Agent Marketplace do Google Cloud valida agentes para o Vertex AI [1], o Salesforce AgentExchange exige integração com o Agentforce [2], o AWS Marketplace vincula agentes ao Bedrock AgentCore [3], e o AI Agent Marketplace da ServiceNow é restrito à sua própria plataforma [4]. Um agente listado em um marketplace é invisível para os clientes de todos os outros. Alternativas abertas existem — o marketplace Gorilla da UC Berkeley hospeda mais de 150 agentes [5], o registro de habilidades do ClawHub contém 13.729 habilidades criadas pela comunidade [6], e o AI Agent Store seleciona mais de 1.300 entradas [7] — mas estão desconectadas entre si e das plataformas empresariais. Não existe busca multiplataforma. Nenhum protocolo combina descoberta com correspondência, verificação de confiança e negociação de preços em um único padrão aberto.
Essa fragmentação recria o problema pré-web dos silos de informação. Antes dos mecanismos de busca, encontrar informação exigia saber em qual banco de dados consultar. Antes dos agregadores de viagem como o Kayak, encontrar o voo mais barato exigia verificar cada companhia aérea individualmente [8]. A economia de agentes enfrenta o mesmo problema estrutural: encontrar o melhor agente para uma tarefa exige pesquisar cada marketplace individualmente, comparar descrições de capacidades incompatíveis e fazer julgamentos de confiança sem dados de reputação padronizados.
O Agent Matchmaking Protocol (AMP) preenche essa lacuna. O AMP especifica cinco capacidades que juntas constituem uma camada completa de correspondência para o comércio de agentes autônomos:
O AMP é projetado como o ápice comercial do Ecossistema de Confiança da AB Support — um protocolo de Camada 4 (Mercado/Descoberta) que consome dados de todos os protocolos das camadas inferiores. Sua vantagem competitiva não é o algoritmo de correspondência em si (correspondência é um problema bem estudado), mas a profundidade da integração de confiança: onde os marketplaces existentes validam agentes uma única vez no momento da listagem por meio de controle corporativo, o AMP os valida continuamente por meio do histórico operacional verificado pela pilha de confiança completa.
O protocolo é agnóstico em relação ao sistema de identidade, agnóstico em relação ao marketplace e agnóstico em relação ao meio de pagamento. Ele especifica como os agentes são pareados, não quem eles são, onde estão listados ou como pagam. Essa neutralidade arquitetônica permite a adoção em todo o ecossistema fragmentado sem exigir que qualquer marketplace ceda controle.
Este whitepaper especifica o protocolo completo: modelos de dados para perfis de capacidades e solicitações de correspondência, algoritmos de correspondência com análise formal de trade-offs entre estabilidade e otimalidade, arquitetura de descoberta federada, mecanismos de descoberta de preços, integração de sinais de confiança, estratégias de bootstrapping de marketplace para o problema do ovo e da galinha, análise de segurança incluindo resistência a manipulação e correspondência com preservação de privacidade, e um levantamento do cenário competitivo cobrindo mais de 9 marketplaces existentes e mais de 40 fontes.
A economia de agentes possui descoberta. O protocolo Agent-to-Agent (A2A) do Google, adotado por mais de 150 organizações até meados de 2025 [9], padroniza como agentes publicam suas capacidades via Agent Cards em /.well-known/agent.json. O Model Context Protocol (MCP), doado para a Agentic AI Foundation (Linux Foundation) em dezembro de 2025, permite que agentes descubram ferramentas dinamicamente em tempo de execução [10]. O AgentDNS [20] e o Agent Name Service (ANS) [21] propõem nomeação e resolução semelhantes ao DNS para endpoints de agentes. O Agent Communication & Discovery Protocol (ACDP) [22] se baseia nos registros DNS SRV existentes para descoberta pragmática.
A economia de agentes possui comércio. O Agentic Commerce Protocol da OpenAI (com a Stripe) permite compras através do ChatGPT [13]. O Universal Commerce Protocol do Google (com Shopify, Etsy, Wayfair, Target, Walmart) padroniza interações agente-comércio com mais de 20 parceiros [14]. O ERC-8183 define custódia programável para transações de agentes on-chain [23]. O protocolo de pagamento x402 reporta mais de 35 milhões de transações desde meados de 2025, embora análises sugiram que aproximadamente metade desse volume reflita testes de infraestrutura e não comércio genuíno [24].
O que a economia de agentes não possui é uma camada de correspondência — um mecanismo em nível de protocolo que recebe a descrição de uma tarefa, pesquisa através do ecossistema fragmentado e retorna recomendações de agentes classificadas por capacidade, confiança, custo e compatibilidade.
Isso não é um problema de conveniência. É uma falha de mercado.
Quando os marketplaces são isolados, três patologias emergem:
Custos de busca dominam custos de transação. Uma empresa que busca um agente de revisão de código deve verificar o AI Agent Marketplace do Google Cloud, o Salesforce AgentExchange, o AWS Marketplace, o AI Agent Marketplace da ServiceNow, o marketplace open-source de Berkeley, o registro de habilidades do ClawHub e diretórios gerais — sete plataformas com interfaces de busca incompatíveis, taxonomias de capacidades diferentes e nenhuma forma de comparar resultados entre elas. Para usuários humanos, isso é tedioso mas administrável. Para agentes autônomos que precisam contratar outros agentes programaticamente e em velocidade de máquina, é uma barreira estrutural ao comércio.
O lock-in de plataforma suprime a concorrência. Um agente que constrói reputação no Salesforce AgentExchange não pode transferir essa reputação para o AWS Marketplace. O histórico do agente — o sinal mais informativo de desempenho futuro — fica preso em uma única plataforma. Isso cria custos de mudança artificiais que beneficiam incumbentes e penalizam agentes que atendem clientes em múltiplas plataformas. É o equivalente de agente a um motorista que não consegue levar sua avaliação do Uber para o Lyft.
Sinais de qualidade são ausentes ou inverificáveis. Marketplaces empresariais validam agentes uma vez no momento da listagem por meio de controle corporativo — o Google Cloud valida a compatibilidade com o Vertex AI, a Salesforce certifica a integração com o Agentforce. Registros abertos dependem de revisão da comunidade. Nenhum dos dois fornece sinais contínuos de qualidade. Um cliente escolhendo entre dois agentes de revisão de código no marketplace do Google Cloud não tem acesso aos históricos de desempenho desses agentes em outras plataformas, seus registros de disputas, suas taxas de conformidade com SLA ou suas cadeias de proveniência. A informação necessária para uma boa decisão de correspondência existe, dispersa entre protocolos e plataformas. Nenhum sistema a agrega.
O AMP opera na interseção de quatro disciplinas estabelecidas:
Recuperação de informação fornece a base para busca baseada em capacidades — correspondendo uma descrição de tarefa contra perfis de capacidades de agentes usando similaridade semântica, consultas estruturadas ou abordagens híbridas.
Teoria de correspondência fornece a base algorítmica para otimização bilateral de preferências — garantindo que, quando múltiplas tarefas competem pelo mesmo agente e múltiplos agentes poderiam servir a mesma tarefa, a atribuição resultante é estável (nenhum par tarefa-agente preferiria ser pareado diferentemente) [12].
Economia de plataformas fornece a base de design de mercado — compreendendo efeitos de rede cruzados, o problema de bootstrapping do ovo e da galinha, estratégias de precificação para mercados bilaterais e as condições sob as quais marketplaces fragmentados se consolidam ou persistem [25][26].
Design de mecanismos fornece a base de engenharia de incentivos — estruturando o protocolo para que relato honesto de capacidades, precificação precisa e entrega genuína de qualidade sejam as estratégias individualmente racionais para os participantes [27].
O AMP não tenta substituir marketplaces existentes. Como o Kayak, que pesquisa em companhias aéreas sem operar voos, o AMP pesquisa em marketplaces de agentes sem hospedar agentes. É um protocolo — uma especificação que qualquer marketplace, registro ou serviço de descoberta pode implementar — não uma plataforma. O protocolo define como perfis de capacidades são estruturados, como solicitações de correspondência são formuladas, como consultas federadas são executadas, como resultados são classificados usando sinais de confiança e como a descoberta de preços opera dentro do fluxo de correspondência.
O AMP especifica:
O AMP não especifica:
O AMP consome saídas de todos esses protocolos; não os duplica.
Os seguintes termos são usados ao longo desta especificação com significados precisos:
| Termo | Definição |
|---|---|
| Agente | Uma entidade de software autônoma capaz de realizar tarefas, tomar decisões e interagir com outros agentes ou humanos sem supervisão humana contínua |
| Capacidade | Um tipo específico de trabalho que um agente pode realizar, descrito em um nível de abstração significativo para correspondência (ex.: "revisão de código para microsserviços Python", não "invocar um linter") |
| Perfil de Capacidade | Uma descrição estruturada e legível por máquina das capacidades de um agente, características de desempenho, parâmetros de custo e disponibilidade — formalizada no AMP como um Perfil de Capacidade Unificado (UCP) |
| Solicitação de Correspondência | Uma consulta estruturada descrevendo uma tarefa a ser realizada, as preferências do solicitante em múltiplas dimensões (qualidade, custo, velocidade, confiança) e quaisquer restrições rígidas |
| Resposta de Correspondência | Uma lista classificada de agentes que satisfazem as restrições da solicitação de correspondência, ordenada por pontuação composta de compatibilidade |
| Pontuação de Compatibilidade | Uma pontuação multidimensional refletindo quão bem um agente se adequa a uma solicitação de correspondência específica, calculada a partir de correspondência de capacidade, sinais de confiança, alinhamento de custo, disponibilidade e compatibilidade de estilo |
| Registro | Qualquer sistema que armazena e serve perfis de capacidades de agentes — marketplaces empresariais, registros abertos, endpoints auto-hospedados |
| Federação | O mecanismo do protocolo pelo qual o AMP consulta múltiplos registros simultaneamente e mescla resultados em uma classificação unificada |
| Sinal de Confiança | Uma declaração verificável sobre o histórico ou qualidade de um agente, originada de protocolos do ecossistema de confiança (proveniência CoC, reputação ARP, conformidade ASA, registro de disputas AJP, status de ciclo de vida ALP) |
| Descoberta de Preços | O processo pelo qual um solicitante e um provedor concordam sobre o custo de um serviço, via preços publicados, leilão ou negociação |
| Correspondência Estável | Uma atribuição de correspondência em que nenhum par tarefa-agente não pareado preferiria mutuamente ser pareado um com o outro em vez de suas atribuições atuais [12] |
| Bootstrapping | O processo de superar o problema do ovo e da galinha em um marketplace bilateral: atrair oferta inicial (agentes listados) e demanda (solicitantes de tarefas) simultaneamente |
| UCP | Perfil de Capacidade Unificado — formato legível por máquina do AMP para descrever capacidades de agentes, interoperável com Agent Cards do A2A, manifestos MCP e especificações de habilidades OpenClaw |
| Nó AMP | Uma implementação do protocolo AMP que pode receber solicitações de correspondência, consultar registros, calcular classificações e retornar respostas de correspondência |
O design do AMP é guiado por sete princípios derivados das falhas dos marketplaces existentes e dos requisitos da economia de agentes:
O AMP é uma especificação, não um serviço. Qualquer organização pode implementar um Nó AMP sem permissão da AB Support ou de qualquer autoridade central. Isso segue o modelo do HTTP (qualquer um pode implementar um servidor web), DNS (qualquer um pode operar um resolvedor) e A2A (qualquer um pode publicar um Agent Card). A alternativa — uma plataforma centralizada de matchmaking — criaria um ponto único de falha, um intermediário rentista e um gargalo de controle que contradiz o caráter aberto e descentralizado do ecossistema de confiança.
O trade-off é real: uma plataforma centralizada captura mais valor (modelo CPC do Kayak, comissão de 30% da App Store) e pode iterar mais rápido na qualidade de correspondência. A abordagem de protocolo sacrifica esses fatores em favor da amplitude de adoção e da resiliência do ecossistema. Esta é uma escolha deliberada: o valor do AMP vem de ser o padrão de correspondência, não o serviço de correspondência.
O AMP não reinventa identidade, comunicação, pagamento, acordos, disputas ou verificação de qualidade. Ele consome saídas de protocolos que já lidam com essas funções:
| Função | Protocolo | Consumo pelo AMP |
|---|---|---|
| Identidade | CoC, DIDs, Agent Cards A2A | Verificar identidade do agente antes de incluir nos resultados |
| Reputação | ARP v2 | Usar pontuações compostas como sinais de classificação |
| Acordos | ASA | Usar histórico de conformidade com SLA como indicador de confiabilidade |
| Disputas | AJP | Usar taxa de disputas e resultados como sinal de risco |
| Ciclo de Vida | ALP | Filtrar agentes descontinuados/descomissionados |
| Comunicação | A2A, MCP | Encaminhar resultados de correspondência por canais existentes |
| Pagamento | x402, ERC-8183 | Integrar descoberta de preços sem lidar com liquidação |
Este princípio de "consumir, não duplicar" mantém o AMP focado em sua contribuição central — correspondência — enquanto habilita profundidade por meio de integração.
Classificação unidimensional (ex.: "ordenar por preço" ou "ordenar por avaliação") é o padrão na maioria dos marketplaces porque é fácil de implementar e fácil para humanos compreenderem. Também é categoricamente errada para matchmaking de agentes.
Um agente com acurácia perfeita mas tempos de resposta de 10 minutos é inútil para suporte ao cliente em tempo real. Um agente com o menor preço mas uma taxa de disputas de 40% é mais caro em expectativa do que um agente premium com uma taxa de disputas de 2%. Um agente com altas avaliações em revisão de código para JavaScript pode ser medíocre em revisão de microsserviços Python.
O AMP requer solicitações de correspondência multidimensionais e pontuação de compatibilidade multidimensional. As dimensões são:
| Dimensão | Fonte | O que Mede |
|---|---|---|
| Correspondência de Capacidade | Similaridade semântica do UCP | Quão bem as capacidades do agente se adequam à tarefa |
| Pontuação de Confiança | Composto de CoC + ARP + ASA + AJP | Quão confiável é o agente |
| Alinhamento de Custo | Sinais de preço | Quão bem a precificação do agente se adequa ao orçamento |
| Disponibilidade | Status do registro + ciclo de vida ALP | Se o agente está atualmente disponível e ativo |
| Compatibilidade de Estilo | Metadados do UCP + histórico de interação | Se o formato de saída e o estilo de interação do agente correspondem às preferências |
| Relevância de Domínio | Pontuações dimensionais do ARP + histórico ASA | Quão bem o histórico do agente neste domínio específico corresponde à tarefa |
Os solicitantes especificam pesos entre essas dimensões. O protocolo não impõe uma ponderação padrão — diferentes casos de uso têm prioridades legitimamente diferentes.
Marketplaces existentes dependem de confiança declarada — o agente (ou seu publicador) declara certas capacidades, e o marketplace valida a declaração uma vez. O AMP substitui declaração por evidência:
Onde existe evidência de confiança, o AMP a utiliza. Onde não existe (agentes novos, agentes de plataformas sem integração de confiança), o AMP aplica desconto apropriado sem excluir o agente inteiramente (ver Seção 10.3, Integração de Novos Agentes).
O modelo de descoberta federada do AMP respeita a autonomia de cada marketplace e registro. Uma consulta AMP não exige que os marketplaces exponham seus bancos de dados completos de agentes. Em vez disso, cada registro participante implementa um endpoint de consulta padronizado que:
Isso é análogo a como o Kayak consulta APIs de companhias aéreas — cada companhia controla seu próprio inventário e precificação; o Kayak meramente agrega resultados. Um marketplace pode participar da federação AMP sem ceder o controle sobre seus agentes, seus dados ou seu modelo de negócios.
O problema do ovo e da galinha — nenhum agente se lista porque não há solicitantes, nenhum solicitante busca porque não há agentes — mata a maioria dos marketplaces bilaterais antes de atingirem massa crítica [25]. O AMP aborda isso estruturalmente ao não exigir que um novo marketplace seja construído. Como o AMP é um protocolo de federação, ele faz bootstrapping conectando registros existentes (ClawHub com 13.729 habilidades, Berkeley com mais de 150 agentes, Apify com mais de 4.000 ferramentas, marketplaces empresariais com centenas de agentes validados) em vez de exigir nova oferta. A oferta já existe — como uma mistura de habilidades, ferramentas, perfis de agentes e entradas de diretório em níveis variados de abstração — e está meramente fragmentada.
Agentes podem ter razões competitivas para ocultar partes de seus perfis de capacidades. Um agente de pesquisa proprietário pode não querer divulgar sua cadeia de ferramentas exata. O AMP suporta divulgação progressiva: agentes publicam informações de capacidade suficientes para correspondência, mas podem reter detalhes de implementação até que uma correspondência seja confirmada e um acordo seja negociado. Sinais de confiança podem ser verificados em agregado (ex.: "a pontuação composta ARP deste agente excede 80") sem revelar pontuações dimensionais exatas, usando os mecanismos de prova de conhecimento zero especificados no ARP v2 [16].
Os marketplaces de agentes dominantes no início de 2026 são plataformas empresariais que agrupam descoberta com seus ecossistemas de nuvem:
Google Cloud AI Agent Marketplace foi lançado em 2025 dentro do Google Cloud Marketplace, oferecendo acesso a agentes especializados de parceiros validados usando busca em linguagem natural potencializada por Gemini [1]. A PwC sozinha publicou mais de 120 agentes na plataforma [29]. A descoberta usa consultas em linguagem natural — clientes descrevem um caso de uso e o sistema retorna agentes correspondentes validados para integração com A2A e Gemini Enterprise. Uma ferramenta "Agent Finder" fornece acesso navegável. Pontos fortes: busca sofisticada em linguagem natural, integração de faturamento empresarial. Limitação: apenas agentes validados pelo Google Cloud são visíveis; agentes multiplataforma são excluídos.
Salesforce AgentExchange foi lançado em 4 de março de 2025 com mais de 200 parceiros iniciais incluindo Google Cloud, Docusign e Box, posicionando-se como "o primeiro marketplace de agentes do mundo" [2]. Oferece quatro tipos de componentes: Actions, Prompt Templates, Topics e Agent Templates. No final de 2025, a Salesforce estendeu isso com o Agentforce 360 para AWS, conectando os ecossistemas Salesforce e AWS [30]. Pontos fortes: grande ecossistema de parceiros, integração profunda com CRM, extensão cross-cloud. Limitação: fortemente acoplado ao Agentforce — agentes não-Salesforce não podem se listar.
AWS Marketplace (Agentes de IA) adicionou uma seção dedicada "AI Agents & Tools" integrada com o Amazon Bedrock AgentCore, geralmente disponível em 13 de outubro de 2025 [3]. Em um hackathon recente de agentes de IA da AWS, 80% dos 600 agentes foram construídos usando AgentCore [3]. Clientes podem usar servidores MCP adquiridos através do AWS Marketplace como alvos MCP no AgentCore Gateway, conectando MCP e infraestrutura AWS. Pontos fortes: adoção por desenvolvedores (AgentCore), precificação flexível baseada em uso, ponte MCP. Limitação: centrado na AWS; agentes devem integrar-se com o Bedrock.
ServiceNow AI Agent Marketplace foi relançado em 2025 com um assistente de IA nativo que fornece recomendações personalizadas com base nos aplicativos e integrações existentes do cliente [4]. Parceiros de lançamento incluem Accenture, Deloitte, HCLTech e sete outros integradores empresariais. Pontos fortes: motor de recomendação potencializado por IA (mais sofisticado que navegação por categorias), coleções específicas por setor. Limitação: vinculado à plataforma ServiceNow.
UC Berkeley Gorilla Agent Marketplace opera um mecanismo de busca open-source para mais de 150 agentes LLM verificados provenientes de Langchain, LlamaIndex, OpenAI e CrewAI [5]. Revisado pela comunidade, compatível com múltiplos frameworks, listagem sem permissão. Pontos fortes: aberto, cross-framework. Limitação: escala pequena, sem capacidade transacional.
ClawHub hospeda 13.729 habilidades criadas pela comunidade em fevereiro de 2026, descobríveis via busca semântica vetorial potencializada por embeddings da OpenAI [6]. Cada habilidade é um arquivo SKILL.md com frontmatter YAML e instruções em markdown. Segurança é uma preocupação: pesquisadores descobriram 1.467 habilidades maliciosas (~3% do registro), com 91% combinando injeção de prompt com malware tradicional [31][32]. Pontos fortes: maior registro aberto, busca semântica, CLI estilo npm. Limitação: habilidades descrevem capacidades individuais, não perfis compostos de agentes; riscos de segurança significativos em conteúdo moderado pela comunidade.
AI Agent Store e AI Agents Directory agregam metadados sobre mais de 1.300 agentes em diversas categorias, mas não lidam com implantação, faturamento ou execução [7]. Funcionam como diretórios em vez de marketplaces transacionais.
Apify oferece mais de 4.000 web scrapers, agentes e ferramentas de automação com integração MCP [33]. Agen.cy fornece um diretório de agentes navegável para descoberta por tarefa e setor.
Microsoft Magentic Marketplace (novembro de 2025) é um ambiente de simulação open-source para estudar mercados agênticos, não um marketplace de produção [34][35]. Principais descobertas de experimentos controlados com centenas de agentes compradores e vendedores simultâneos: (a) modelos de fronteira alcançam bons resultados de bem-estar em configurações ideais, mas o desempenho se degrada em escala, (b) modos de falha emergentes incluem manipulação e viés de velocidade onde agentes vendedores exploram os limites de janela de contexto dos agentes compradores, e (c) agentes compradores com mais opções experimentam degradação da qualidade de decisão à medida que a sobrecarga de escolhas sobrecarrega suas janelas de contexto [36]. Código aberto no GitHub (microsoft/multi-agent-marketplace). Pontos fortes: dados empíricos mais rigorosos sobre dinâmicas de marketplace de agentes. Limitação: simulação, não sistema de produção.
| Capacidade | Google Cloud | Salesforce | AWS | ServiceNow | Berkeley | ClawHub | Magentic | AMP |
|---|---|---|---|---|---|---|---|---|
| Busca multiplataforma | Não | Parcial (ponte AWS) | Não | Não | Parcial | Não | N/A | Sim |
| Correspondência multidimensional | Não | Não | Não | Potencializada por IA | Não | Semântica | Pesquisa | Sim |
| Classificação ponderada por confiança | Validação corporativa | Certificação de parceiro | Revisão AWS | Certificação de parceiro | Comunidade | Comunidade + varredura | N/A | Pilha de confiança verificável |
| Descoberta de preços | Faturamento da plataforma | Faturamento da plataforma | Baseado em uso | Faturamento da plataforma | Gratuito | Gratuito | Simulada | Multimecanismo |
| Garantia de correspondência estável | Não | Não | Não | Não | Não | Não | Estudada | Sim (modo em lote) |
| Protocolo aberto | Não | Não | Não | Não | Sim | Sim | Sim | Sim |
| Preservação de privacidade | N/A | N/A | N/A | N/A | Não | Não | N/A | Parcial (TLS + anonimização; ZKP via ARP v2 para limiarização de pontuações) |
A lacuna é clara: nenhum sistema combina busca aberta e multiplataforma com correspondência multidimensional ponderada por confiança, garantias formais de estabilidade e descoberta de preços com múltiplos mecanismos. O AMP ocupa essa lacuna.
Nota sobre a metodologia de comparação: Esta tabela compara funcionalidades em nível de protocolo, e não prontidão operacional. Plataformas existentes possuem vantagens reais que o AMP ainda não equipara — incluindo maturidade operacional, integração de faturamento empresarial, suporte ao cliente estabelecido, garantias de SLA respaldadas por responsabilidade corporativa e anos de endurecimento em produção. As vantagens do AMP são arquitetônicas (abertura, federação, integração de confiança); as vantagens dos incumbentes são operacionais. Uma implantação em produção precisaria fechar a lacuna operacional para competir com plataformas estabelecidas. A garantia de correspondência estável do AMP se aplica em modo em lote; estabilidade em tempo real requer mecanismos complementares (ver Seção 6.3).
Descrições de capacidades de agentes existem em três níveis de abstração, nenhum suficiente isoladamente:
Nível de ferramenta (manifestos MCP): Listam ferramentas individuais que um agente pode invocar — web scraping, análise de arquivos, chamadas de API [10]. Esses são detalhes de implementação, não capacidades. Saber que um agente tem uma ferramenta de web scraping não informa se ele pode conduzir pesquisa competitiva.
Nível de habilidade (especificações OpenClaw): Descrevem habilidades individuais em markdown legível com metadados YAML [11]. Mais abstratas que ferramentas, mas ainda atômicas — uma habilidade descreve "web scraping" ou "sumarização", não uma capacidade composta como "agente de pesquisa que combina web scraping, sumarização e verificação de citações."
Nível de agente (Agent Cards A2A): Descrevem o que um agente pode fazer no nível de interface — habilidades, autenticação suportada, modalidades de entrada/saída [9]. Agent Cards são orientados à descoberta: informam o que um agente pode fazer, mas não quão bem, quão confiavelmente, a que custo, ou em comparação com alternativas.
O AMP introduz o Perfil de Capacidade Unificado (UCP) — um formato de descrição de capacidades que compõe descrições em nível de ferramenta e de habilidade em perfis em nível de agente enriquecidos com características de desempenho, sinais de confiança e metadados de compatibilidade.
Um UCP contém cinco seções:
5.2.1 Seção de Identidade
Vincula o UCP à identidade do agente em diferentes sistemas:
{
"identity": {
"amp_id": "amp:agent:abc123",
"a2a_card": "https://agent.example.com/.well-known/agent.json",
"coc_chain_id": "coc:chain:sha256:a1b2c3...",
"did": "did:web:agent.example.com",
"registries": [
{"type": "google_cloud", "listing_id": "gc-agent-456"},
{"type": "clawhub", "skill_ids": ["web-research-v3", "citation-verify"]}
]
}
}A seção de identidade é de referência cruzada, não autoritativa — a verificação de identidade é delegada aos respectivos protocolos de identidade (CoC, DIDs, A2A).
5.2.2 Seção de Capacidades
Descreve o que o agente pode fazer usando uma taxonomia hierárquica:
{
"capabilities": [
{
"domain": "research",
"subdomain": "competitive_analysis",
"description": "Conducts comprehensive competitive landscape research with web scraping, document analysis, and structured report generation",
"input_modalities": ["text", "url", "document"],
"output_modalities": ["text", "structured_data", "report"],
"tools_used": ["web_scraper", "pdf_parser", "summarizer", "citation_engine"],
"complexity_range": {
"min": "single-competitor profile",
"max": "full market landscape with 50+ entities"
},
"taxonomy_codes": {
"onet_soc": "15-2051.01",
"amp_capability": "research.competitive.landscape"
}
}
]
}O campo taxonomy_codes suporta múltiplos sistemas de classificação. O AMP define sua própria taxonomia hierárquica de capacidades (inspirada na estrutura do O*NET de atividades de trabalho generalizadas → intermediárias → detalhadas [37]) enquanto mantém interoperabilidade com classificações ocupacionais existentes. A taxonomia do AMP não é prescritiva — agentes podem declarar capacidades usando descrições em texto livre, códigos de taxonomia estruturados ou ambos. A correspondência semântica trata a tradução.
5.2.3 Seção de Desempenho
Descreve características de desempenho observadas empiricamente:
{
"performance": {
"reliability": {
"asa_completion_rate": 0.982,
"asa_sample_size": 247,
"uptime_30d": 0.997
},
"quality": {
"arp_composite_score": 84.2,
"arp_dimensional_scores": {
"accuracy": 91.3,
"reliability": 88.7,
"latency": 72.1,
"protocol_compliance": 95.0,
"cost_efficiency": 73.8
},
"qv_pass_rate": 0.94,
"qv_sample_size": 189
},
"speed": {
"median_response_time_ms": 45000,
"p95_response_time_ms": 180000,
"throughput_tasks_per_hour": 12
},
"dispute_profile": {
"ajp_dispute_rate": 0.018,
"ajp_favorable_resolution_rate": 0.85,
"ajp_sample_size": 55
}
}
}As métricas de desempenho não são auto-reportadas. São calculadas a partir de dados dos protocolos do ecossistema de confiança e são criptograficamente verificáveis:
arp_composite_score é derivado da álgebra de composição de sinais do ARP v2 [16]asa_completion_rate é calculado a partir dos registros de acordos ASA [18]ajp_dispute_rate é calculado a partir dos registros de casos AJP [17]coc_chain_length é verificável contra carimbos de tempo ancorados [15]Quando dados verificáveis não estão disponíveis (ex.: agentes não integrados com o ecossistema de confiança), os campos são omitidos em vez de estimados. Um Nó AMP PODE exibir métricas auto-reportadas não verificadas, mas DEVE distingui-las claramente de métricas verificadas nos resultados de correspondência.
5.2.4 Seção de Custo
Descreve o modelo de precificação do agente:
{
"cost": {
"pricing_model": "usage_based",
"base_rate": {"amount": 0.05, "currency": "USD", "per": "request"},
"variable_rate": {"amount": 0.002, "currency": "USD", "per": "output_token"},
"supports_negotiation": true,
"supports_auction": false,
"payment_rails": ["x402", "stripe", "invoice"],
"free_tier": {"requests_per_month": 100}
}
}{
"availability": {
"status": "active",
"alp_lifecycle_stage": "operational",
"capacity": {
"current_load_pct": 45,
"max_concurrent_tasks": 20,
"estimated_queue_time_ms": 5000
},
"schedule": {
"timezone": "UTC",
"available_hours": "00:00-23:59",
"maintenance_windows": []
}
}
}Os UCPs são projetados para serem gerados a partir de descrições de capacidades existentes:
| Formato de Origem | Mapeamento para UCP |
|---|---|
| Agent Card A2A | Identidade → a2a_card; Habilidades → Seção de Capacidades; Autenticação → filtrada |
| Manifesto de Ferramenta MCP | Ferramentas → tools_used na Seção de Capacidades; Parâmetros → complexity_range |
| SKILL.md OpenClaw | Frontmatter YAML → Seção de Capacidades; Binários requeridos → tools_used |
| API Personalizada | O implementador mapeia para o esquema UCP; campos não mapeados preservados em extensions |
Um Nó AMP DEVERIA ser capaz de ingerir Agent Cards A2A, manifestos MCP e especificações OpenClaw diretamente, gerando UCPs automaticamente. Isso reduz a barreira à adoção: agentes já listados em plataformas existentes não precisam criar UCPs manualmente.
O AMP define uma taxonomia hierárquica de capacidades em três níveis:
Nível 1 — Domínios (8 domínios): pesquisa, desenvolvimento, análise, comunicação, operações, criativo, segurança, específico de domínio
Nível 2 — Subdomínios (~40 subdomínios): ex.: pesquisa.competitiva, pesquisa.acadêmica, desenvolvimento.frontend, desenvolvimento.backend, análise.financeira, análise.jurídica, comunicação.tradução, comunicação.sumarização
Nível 3 — Capacidades (aberto): capacidades específicas dentro de cada subdomínio, ex.: pesquisa.competitiva.panorama, desenvolvimento.backend.design_de_api, análise.financeira.avaliação
Nível 1 e Nível 2 são definidos pelo protocolo e versionados. Nível 3 é extensível — agentes podem declarar novas capacidades no Nível 3 sem exigir atualizações do protocolo. A correspondência semântica trata capacidades novas de Nível 3 que não correspondem exatamente a entradas conhecidas da taxonomia.
Status da taxonomia: Os domínios de Nível 1 e exemplos de subdomínios de Nível 2 listados acima são ilustrativos e preliminares. A taxonomia completa de Nível 2 (~40 subdomínios) será publicada como um artefato versionado separado antes da finalização do AMP v1.0. Implementadores construindo com base na especificação atual devem tratar os códigos de taxonomia como provisórios e projetar seus sistemas para acomodar atualizações de taxonomia. O framework estrutural (hierarquia de três níveis, decomposição inspirada no O*NET) é estável; os códigos específicos não são.
A taxonomia se inspira estruturalmente na decomposição hierárquica de atividades ocupacionais do O*NET [37], mas é construída especificamente para capacidades de agentes e não para ocupações humanas. Onde o O*NET mapeia ocupações → atividades generalizadas → atividades intermediárias → atividades detalhadas → declarações de tarefas, o AMP mapeia agentes → domínios → subdomínios → capacidades → tipos de tarefas. O paralelo estrutural permite a futura conexão entre ontologias de capacidades humanas e de agentes, o que pode se tornar relevante à medida que a colaboração agente-humano se aprofunda.
Uma solicitação de correspondência especifica o que o solicitante precisa e como prioriza diferentes dimensões:
{
"match_request": {
"request_id": "mr-20260326-001",
"requester_id": "amp:agent:requester-xyz",
"task": {
"description": "Review Python microservice code for security vulnerabilities, focusing on authentication flows and data validation",
"domain": "security",
"subdomain": "code_review",
"input": {"type": "code_repository", "language": "python", "loc_estimate": 15000},
"output": {"type": "security_report", "format": "structured_json"},
"deadline_ms": 3600000,
"budget": {"max_amount": 50.00, "currency": "USD"}
},
"weights": {
"capability_match": 0.30,
"trust_score": 0.25,
"cost_alignment": 0.15,
"availability": 0.10,
"style_compatibility": 0.05,
"domain_relevance": 0.15
},
"constraints": {
"min_trust_score": 60,
"max_dispute_rate": 0.05,
"required_lifecycle_status": ["operational"],
"excluded_agents": [],
"required_registries": [],
"max_results": 10
},
"federation": {
"registries": ["all"],
"timeout_ms": 5000
}
}
}O objeto weights soma 1,0 e determina a importância relativa de cada dimensão na pontuação de compatibilidade. O objeto constraints especifica filtros rígidos — agentes que falham em qualquer restrição são excluídos antes da pontuação. Essa abordagem em duas fases (filtrar e depois classificar) espelha o pipeline padrão de recuperação de informação e é computacionalmente eficiente.
Dada uma solicitação de correspondência R e um agente candidato A, a pontuação de compatibilidade S(R, A) é calculada como:
S(R, A) = w_cap * C_capability(R, A)
+ w_trust * C_trust(R, A)
+ w_cost * C_cost(R, A)
+ w_avail * C_availability(R, A)
+ w_style * C_style(R, A)
+ w_domain * C_domain(R, A)Onde cada pontuação dimensional C_x é normalizada para [0, 100] e cada peso w_x vem do objeto weights da solicitação de correspondência.
Correspondência de Capacidade (C_capability):
Calculada via similaridade semântica entre a descrição da tarefa e as descrições de capacidade do UCP do agente. O AMP não prescreve um modelo de embedding específico, mas requer que a função de similaridade satisfaça três propriedades:
tools_used recebem um bônuscomplexity_range declarado do agente, a pontuação é descontadaFormalmente:
C_capability(R, A) = sim(R.task.description, A.capabilities)
* tool_bonus(R.task, A.tools_used)
* complexity_fit(R.task, A.complexity_range)Onde sim é uma função de similaridade semântica retornando [0, 1], tool_bonus retorna [1,0, 1,2] (até 20% de bônus por correspondências de ferramentas), e complexity_fit retorna [0,5, 1,0] (50% de penalidade para complexidade fora do intervalo, 1,0 para dentro do intervalo).
Pontuação de Confiança (C_trust):
Derivada do sinal composto do ARP v2 [16]:
C_trust(R, A) = f(ARP_composite, CoC_chain_length, ASA_compliance, AJP_dispute_rate)Onde f é a função de composição de sinais do ARP v2 com perfis de peso específicos por domínio. Se o agente não possui integração com o ecossistema de confiança, C_trust assume um valor de linha de base configurável (padrão: 50) representando confiança neutra — nem confiável nem desconfiável.
Alinhamento de Custo (C_cost):
C_cost(R, A) = max(0, 100 - penalty * |estimated_cost(A, R.task) - R.task.budget.target|)Onde estimated_cost projeta o modelo de precificação do agente para a tarefa específica, e penalty escala com a sensibilidade orçamentária. Agentes precificados dentro do orçamento recebem pontuações altas; agentes significativamente acima do orçamento são penalizados mas não excluídos (o solicitante pode decidir que o prêmio de confiança vale a pena).
Disponibilidade (C_availability):
C_availability(R, A) = lifecycle_check(A) * capacity_score(A) * deadline_fit(A, R.task)Onde lifecycle_check retorna 0 para agentes descontinuados/descomissionados (filtro rígido), capacity_score retorna [0, 100] baseado na carga atual, e deadline_fit retorna [0, 100] baseado em se o agente pode cumprir o prazo dada sua fila atual.
Compatibilidade de Estilo (C_style):
Calculada a partir do alinhamento de formato de saída e histórico de padrões de interação:
C_style(R, A) = format_match(R.task.output.format, A.output_modalities)
* interaction_history_score(R.requester_id, A)Onde interaction_history_score reflete filtragem colaborativa — se o solicitante trabalhou bem anteriormente com este agente ou agentes com perfis similares, a pontuação aumenta. Para primeiras interações, o valor padrão é neutro: 50.
Relevância de Domínio (C_domain):
C_domain(R, A) = arp_domain_score(A, R.task.domain) * asa_domain_compliance(A, R.task.domain)Onde arp_domain_score obtém as pontuações dimensionais do ARP do agente especificamente para o domínio solicitado (não seu composto geral), e asa_domain_compliance reflete sua taxa de conclusão de SLA em tarefas neste domínio específico.
O AMP suporta três modos de correspondência, selecionados pelo solicitante ou configurados automaticamente com base nas características da solicitação:
Modo 1: Busca Classificada (Padrão)
Para solicitações individuais buscando uma lista classificada de candidatos. Este é o modo mais comum — equivalente a uma consulta de mecanismo de busca. O Nó AMP calcula pontuações de compatibilidade para todos os agentes candidatos, aplica restrições como filtros rígidos e retorna os top-K resultados classificados por pontuação composta. Complexidade computacional: O(n log k) onde n é o número de candidatos e k é max_results.
Modo 2: Correspondência Estável
Para cenários em lote onde múltiplas tarefas competem pelos mesmos agentes e múltiplos agentes poderiam servir às mesmas tarefas. O AMP implementa uma variante do algoritmo de aceitação diferida de Gale-Shapley [12]:
Gale-Shapley garante estabilidade mas é ótimo para a tarefa (favorável ao lado da tarefa). O AMP fornece uma flag de configuração para produzir correspondências ótimas para o agente, e uma variante mediana-ótima que equilibra ambos os lados, embora a otimalidade mediana exija computação adicional. Complexidade computacional: O(n^2) no pior caso, onde n é o número de tarefas/agentes.
Ressalva de estabilidade: Gale-Shapley pressupõe preferências completas e estáticas. Na prática, as preferências dos agentes mudam dinamicamente (novas tarefas chegam, agentes completam trabalhos, preços mudam). O AMP aborda isso executando correspondência estável periodicamente em solicitações acumuladas em vez de continuamente, aceitando que entre as rodadas de correspondência a atribuição pode ser temporariamente subótima. O intervalo de correspondência é configurável (padrão: 60 segundos para mercados em tempo real, 300 segundos para mercados em lote).
Modo 3: Correspondência por Leilão
Para cenários onde a descoberta de preços é o objetivo principal. O solicitante publica uma tarefa, agentes enviam ofertas (preço + perfil de capacidade), e o mecanismo de leilão seleciona o agente vencedor. O AMP suporta três formatos de leilão:
{
"match_response": {
"request_id": "mr-20260326-001",
"timestamp": "2026-03-26T14:30:00Z",
"results": [
{
"rank": 1,
"agent_id": "amp:agent:securitybot-prime",
"compatibility_score": 89.3,
"dimensional_scores": {
"capability_match": 95.2,
"trust_score": 88.1,
"cost_alignment": 82.0,
"availability": 100.0,
"style_compatibility": 75.0,
"domain_relevance": 92.4
},
"ucp_summary": {
"primary_capability": "Python security code review with SAST/DAST integration",
"arp_composite": 88.1,
"asa_completion_rate": 0.991,
"estimated_cost": {"amount": 35.00, "currency": "USD"},
"estimated_completion_ms": 1800000
},
"trust_verification": {
"coc_chain_verified": true,
"coc_chain_length_days": 127,
"arp_score_verified": true,
"asa_history_verified": true,
"ajp_record_verified": true,
"verification_timestamp": "2026-03-26T14:29:58Z"
},
"registries_found_on": ["google_cloud", "clawhub"]
}
],
"metadata": {
"registries_queried": 5,
"registries_responded": 4,
"total_candidates_evaluated": 237,
"candidates_filtered_by_constraints": 198,
"candidates_scored": 39,
"query_time_ms": 3200
}
}
}O bloco trust_verification é crítico: ele informa ao solicitante quais sinais de confiança foram verificados independentemente pelo Nó AMP (não apenas reportados pelo agente). Isso distingue o AMP de marketplaces que exibem métricas auto-reportadas.
A federação AMP conecta um Nó AMP a múltiplos registros através de uma interface de consulta padronizada. A arquitetura possui três camadas:
┌──────────────────────────────────────────────────────┐
│ NÓ AMP │
│ ┌────────────┐ ┌─────────────┐ ┌──────────────┐ │
│ │ Motor de │ │ Roteador de │ │ Verificador │ │
│ │ Correspond.│ │ Federação │ │ de Confiança │ │
│ └─────┬──────┘ └──────┬──────┘ └──────┬───────┘ │
│ │ │ │ │
└────────┼────────────────┼────────────────┼───────────┘
│ │ │
┌─────┴──────┐ ┌─────┴──────┐ ┌─────┴──────┐
│ Adaptador │ │ Adaptador │ │ Adaptador │
│ de Registro│ │ de Registro│ │ de Registro│
│ Google │ │ ClawHub │ │ A2A │
│ Cloud │ │ │ │ Auto-hosp. │
└────────────┘ └────────────┘ └────────────┘Motor de Correspondência: Recebe solicitações de correspondência, calcula pontuações de compatibilidade, produz resultados classificados.
Roteador de Federação: Despacha subconsultas da solicitação de correspondência para registros cadastrados em paralelo, coleta respostas, normaliza resultados em UCPs e os passa para o Motor de Correspondência.
Verificador de Confiança: Verifica independentemente sinais de confiança (entradas da cadeia CoC, pontuações ARP, registros ASA, dados de disputas AJP) contra suas fontes autoritativas. Este é o componente que transforma confiança declarada em confiança verificada.
Adaptadores de Registro: Conectores específicos de protocolo que traduzem consultas de federação AMP no formato de consulta nativo de cada registro e traduzem respostas de volta em UCPs. Adaptadores são conectáveis — novos registros requerem apenas um novo adaptador, não alterações no protocolo.
Uma consulta de federação AMP segue um processo de cinco etapas:
Etapa 1: Tradução da Consulta. O Nó AMP traduz a solicitação de correspondência em subconsultas específicas por registro. Para um adaptador Google Cloud, isso significa construir uma consulta em linguagem natural compatível com Gemini a partir da descrição da tarefa. Para um adaptador ClawHub, isso significa construir uma consulta de busca semântica contra o índice de embeddings de habilidades. Para um adaptador A2A auto-hospedado, isso significa consultar endpoints /.well-known/agent.json.
Etapa 2: Despacho Paralelo. As subconsultas são despachadas para todos os adaptadores registrados simultaneamente com um timeout configurável (padrão: 5.000 ms). Registros que não respondem dentro do timeout são excluídos da correspondência atual — sua ausência é registrada nos metadados da resposta.
Etapa 3: Normalização de Respostas. Cada adaptador traduz a resposta de seu registro em UCPs. Campos que não podem ser mapeados são preservados em um objeto extensions em vez de descartados.
Etapa 4: Deduplicação e Resolução de Conflitos. Agentes podem estar listados em múltiplos registros. O Nó AMP deduplica por correspondência em campos de identidade (DID, ID de cadeia CoC, URL do Agent Card A2A). Quando o mesmo agente aparece de múltiplos registros, o UCP é mesclado — obtendo os dados mais completos de cada fonte e registrando em quais registros o agente foi encontrado.
Quando dados conflitam entre registros (ex.: um registro reporta suporte a Python enquanto outro reporta JavaScript, ou pontuações de capacidade diferem), o AMP aplica uma hierarquia de resolução de conflitos: (1) dados de fontes de camada de confiança superior têm precedência sobre fontes de camada inferior, (2) entre camadas de confiança iguais, os dados atualizados mais recentemente vencem, e (3) conflitos irresolvíveis são sinalizados nos metadados da resposta de correspondência com um campo data_conflicts, permitindo que o solicitante avalie discrepâncias. Nós AMP NÃO DEVERIAM descartar silenciosamente dados conflitantes.
Etapa 5: Enriquecimento de Confiança. Para cada UCP deduplicado, o Verificador de Confiança consulta o ecossistema de confiança para popular métricas de desempenho verificadas. Esta etapa é opcional mas fortemente recomendada — sem ela, todos os sinais de confiança são declarações não verificadas.
A consulta federada em cinco etapas introduz latência que deve ser compreendida para implantação prática. O exemplo de resposta de correspondência (Seção 6.4) mostra query_time_ms: 3200 para 237 candidatos — aqui está uma decomposição das contribuições esperadas de latência:
| Etapa | Latência Esperada | Observações |
|---|---|---|
| Tradução de Consulta | 5-20 ms | Computação local, negligível |
| Despacho Paralelo | 500-5.000 ms | Limitado por timeout; dominado pelo registro mais lento |
| Normalização de Respostas | 10-50 ms por registro | Computação local, paralelizável |
| Deduplicação + Resolução de Conflitos | 20-100 ms | Escala com contagem de candidatos |
| Enriquecimento de Confiança | 200-3.000 ms | Custo dominante; depende do estado do cache |
O enriquecimento de confiança é o gargalo de latência. Verificar entradas da cadeia CoC, buscar pontuações ARP, verificar registros ASA, consultar AJP e confirmar status ALP pode cada um requerer 100-500 ms por chamada de API externa. Para 39 candidatos pontuados (após filtrar 198 de 237), o enriquecimento serial levaria 20-100 segundos — claramente impraticável.
Nós AMP DEVERIAM implementar três estratégias de mitigação de latência:
Com cache e paralelismo, a cifra de 3.200 ms no exemplo é alcançável para consultas com cache quente. Consultas com cache frio contra mais de 5 registros com enriquecimento completo de confiança podem levar 5-10 segundos. Nós AMP DEVERIAM reportar taxas de acerto de cache nos metadados de resposta para que os solicitantes possam avaliar a atualidade dos resultados.
Qualquer registro pode participar da federação AMP implementando um endpoint de consulta mínimo:
POST /amp/v1/search
Content-Type: application/json
{
"query": {
"text": "Python security code review",
"domain": "security",
"subdomain": "code_review",
"constraints": {
"min_trust_score": 60,
"max_results": 50
}
}
}O formato de resposta é flexível — o adaptador de registro trata a tradução. O requisito mínimo é que a resposta contenha informação suficiente para construir um UCP parcial (no mínimo: identificador do agente e descrição de capacidade).
Registros se auto-cadastram com Nós AMP fornecendo sua URL de endpoint e um manifesto descrevendo seus requisitos de adaptador, parâmetros de consulta suportados e formato de resposta esperado. Não há registro central de registros — cada Nó AMP mantém sua própria lista de registros. Listas de registros podem ser compartilhadas entre Nós AMP através de um protocolo simples de sindicação (análogo ao OPML para agregadores de feeds), permitindo efeitos de rede sem centralização.
A federação AMP é projetada para complementar, não competir com, protocolos de descoberta existentes:
Agent Cards A2A: Nós AMP podem rastrear endpoints /.well-known/agent.json diretamente, tratando a web em si como um registro. Este é o caminho de integração de menor atrito — qualquer agente compatível com A2A é automaticamente descobrível pelo AMP sem nenhum registro adicional.
AgentDNS [20]: Se o AgentDNS alcançar adoção, Nós AMP podem usar a resolução AgentDNS como fonte de descoberta — resolvendo nomes de agentes para endpoints, depois buscando Agent Cards desses endpoints.
ANS [21]: A nomeação agnóstica de protocolo e a identidade baseada em PKI do ANS integram-se naturalmente com a verificação de identidade do AMP. A identidade verificada de um agente registrado no ANS pode ser consumida pelo Verificador de Confiança do AMP.
ACDP [22]: O uso de registros DNS SRV pelo ACDP para descoberta de agentes fornece outra fonte de registro. Nós AMP podem consultar registros SRV para descobrir agentes em domínios específicos.
A pilha emergente de descoberta — identidade (DIDs/PKI), nomeação (AgentDNS/ANS), capacidade (Agent Cards A2A/MCP) — fornece as três primeiras camadas. O AMP adiciona a quarta: correspondência. A descoberta informa o que existe; o AMP informa o que é melhor para sua necessidade específica.
A precificação de agentes é atualmente invisível (plataformas empresariais lidam com faturamento de forma opaca), fixa (preços publicados em registros) ou ausente (agentes open-source são gratuitos). Nenhum desses modelos serve bem a economia emergente de agentes:
O Gartner projeta que até 2028, 90% das compras B2B serão intermediadas por agentes de IA, empurrando mais de US$ 15 trilhões em gastos B2B através de exchanges de agentes de IA [41]. A McKinsey estima a oportunidade global de comércio agêntico — agentes de IA que compram, negociam e transacionam em nome de humanos — em US$ 3-5 trilhões até 2030, com até US$ 1 trilhão em receita de varejo orquestrada nos EUA [42]. Essas projeções sugerem, embora com a incerteza inerente a previsões de analistas, que a descoberta de preços agente-a-agente se tornará uma função econômica significativa.
O AMP suporta três mecanismos de descoberta de preços, selecionáveis por solicitação de correspondência:
Mecanismo 1: Preço Publicado (padrão)
O mecanismo mais simples. O UCP do agente declara seu modelo de precificação, e o Nó AMP estima o custo para a tarefa específica com base nesse modelo. Não ocorre negociação. É apropriado para:
Mecanismo 2: Solicitação de Cotação (RFQ)
O Nó AMP envia a descrição da tarefa para agentes correspondentes e solicita cotações de preço. Cada agente retorna uma cotação específica para a tarefa, opcionalmente com uma janela de validade. O solicitante seleciona entre os preços cotados. É apropriado para:
Interação RFQ:
Solicitante → Nó AMP: match_request com price_discovery: "rfq"
Nó AMP → Agentes Correspondentes: task_description + quote_request
Agentes → Nó AMP: cotações (preço, termos, janela_de_validade)
Nó AMP → Solicitante: match_response com cotações anexadas a cada resultado
Solicitante → Agente Selecionado: accept_quote(quote_id)Mecanismo 3: Leilão
Conforme descrito na Seção 6.3 (Modo 3), leilões são usados quando a competição de preços é o principal objetivo de correspondência. O AMP suporta formatos de leilão inglês, Vickrey (oferta selada de segundo preço) e combinatório.
As saídas da descoberta de preços retroalimentam o sistema de correspondência:
Sinais de preço NÃO são incorporados em pontuações de confiança — as decisões de precificação de um agente são uma estratégia de negócios, não um indicador de confiança. Um agente caro não é menos confiável que um barato. No entanto, a correlação preço-qualidade é monitorada: agentes cujos preços excedem significativamente a média ajustada por qualidade de seus pares recebem uma flag de divulgação nos resultados de correspondência (não uma penalidade, mas transparência).
A descoberta de preços do AMP integra-se com a infraestrutura de comércio existente:
O AMP não lida com liquidação de pagamento — ele descobre preços e facilita o acordo, depois delega para o meio de pagamento apropriado.
Um mecanismo de busca que retorna resultados sem ponderação de qualidade é um diretório. O PageRank do Google transformou a busca na web usando a estrutura de links como sinal de qualidade, rebaixando spam e promovendo fontes autoritativas [43]. As classificações de produtos da Amazon combinam velocidade de vendas, avaliações, preço e reputação do vendedor em uma única pontuação de relevância. Sem classificação ponderada por confiança, um marketplace de agentes é apenas um diretório — informa o que existe mas não o que é bom.
Marketplaces de agentes existentes usam um de três modelos de confiança, todos inadequados:
| Modelo | Exemplo | Limitação |
|---|---|---|
| Controle corporativo | Google Cloud, Salesforce, AWS | Validação única; sem sinal contínuo de qualidade; exclui agentes não-parceiros |
| Revisão da comunidade | Berkeley, ClawHub | Suscetível a ataques Sybil, manipulação de avaliações e viés de recência |
| Nenhum | AI Agent Store, Agen.cy | Diretório puro; zero sinal de qualidade |
O AMP define uma hierarquia de sinais de confiança em quatro camadas, com cada camada representando uma forma mais forte de evidência de confiança:
Camada 1 — Declarado (mais baixo): O agente auto-reporta capacidades e desempenho. Sem verificação. Exemplos: descrições de capacidades em texto livre, declarações auto-reportadas de acurácia.
Camada 2 — Atestado: Um terceiro atesta pelo agente. Exemplos: validação de marketplace corporativo (aprovado pelo Google Cloud), avaliações da comunidade (classificações do Berkeley Gorilla), certificação de parceiro (parceiro Salesforce AgentExchange).
Camada 3 — Medido: Métricas de desempenho calculadas a partir de dados reais de interação. Exemplos: pontuações compostas ARP de avaliação cega bilateral, taxas de conclusão ASA de registros de acordos, taxas de disputas AJP de registros de casos.
Camada 4 — Verificado (mais alto): Métricas medidas que são independentemente verificáveis por qualquer terceiro através de evidência criptográfica. Exemplos: entradas da cadeia CoC ancoradas via verificação de camada dupla OpenTimestamps e TSA, Portable Reputation Bundles do ARP v2 assinados como W3C Verifiable Credentials, registros de acordos ASA com integridade criptográfica.
Nós AMP DEVERIAM indicar claramente a camada de confiança de cada sinal nos resultados de correspondência. Uma Camada 4 "composto ARP: 88" carrega peso diferente de uma Camada 1 "acurácia auto-reportada: 95%."
A pontuação de confiança usada na pontuação de compatibilidade (Seção 6.2) é calculada a partir de sinais de confiança disponíveis usando a seguinte composição:
trust_score(A) = w_identity * identity_confidence(A)
+ w_performance * performance_quality(A)
+ w_reliability * reliability_score(A)
+ w_risk * (100 - risk_score(A))Onde:
Confiança de Identidade: Derivada do comprimento da cadeia CoC e do status de verificação de âncora. Uma cadeia mais longa, mais frequentemente ancorada, indica um agente mais estabelecido com mais a perder por mau comportamento.
identity_confidence(A) = min(100, log2(1 + chain_age_days) * anchor_density_factor)Onde anchor_density_factor varia de 0,5 (ancoragem esparsa) a 1,5 (ancoragem frequente, de camada dupla).
Qualidade de Desempenho: Derivada da pontuação composta ARP v2, ponderada por domínio.
performance_quality(A) = arp_composite(A, domain=request.domain)Usar pontuações ARP específicas por domínio em vez do composto geral garante que um agente bem avaliado para revisão de código não receba a mesma pontuação de confiança quando correspondido para sumarização de documentos (a menos que também tenha fortes avaliações de sumarização).
Confiabilidade: Derivada das taxas de conclusão ASA.
reliability_score(A) = asa_completion_rate(A) * 100 * confidence_factor(asa_sample_size)Onde confidence_factor aumenta de 0,5 (menos de 10 acordos concluídos) a 1,0 (mais de 100 acordos concluídos), descontando pontuações de agentes com históricos limitados.
Risco: Derivado dos dados de disputas AJP.
risk_score(A) = ajp_dispute_rate(A) * unfavorable_resolution_rate(A) * 100Uma alta taxa de disputas com resoluções favoráveis (o agente foi considerado sem culpa) é menos preocupante do que uma alta taxa de disputas com resoluções desfavoráveis. A estrutura multiplicativa reflete isso: um agente com taxa de disputas de 10% mas 90% de taxa de resolução favorável tem uma pontuação de risco de apenas 1, enquanto um agente com taxa de disputas de 10% e 10% de taxa de resolução favorável tem uma pontuação de risco de 9.
Pesos padrão: w_identity = 0,20, w_performance = 0,40, w_reliability = 0,25, w_risk = 0,15. Esses padrões são substituíveis por solicitação de correspondência.
Novos agentes sem histórico no ecossistema de confiança recebem uma pontuação de confiança de linha de base em vez de zero. A linha de base é calculada a partir dos sinais de Camada 1 e Camada 2 disponíveis:
| Sinal Disponível | Ajuste na Linha de Base |
|---|---|
| Validação de marketplace corporativo (Camada 2) | +15 a partir da linha de base |
| Avaliações da comunidade com >10 avaliações (Camada 2) | +10 a partir da linha de base |
| Agent Card A2A publicado em domínio verificado (Camada 2) | +5 a partir da linha de base |
| DID com controlador verificável (Camada 2) | +5 a partir da linha de base |
| Sem sinais verificáveis (apenas Camada 1) | Linha de base (padrão: 40) |
A linha de base é intencionalmente inferior ao ponto médio (50) para refletir que agentes não verificados carregam mais risco do que a média da população. Isso cria um incentivo natural para agentes se integrarem ao ecossistema de confiança — sinais de confiança verificados melhoram diretamente sua classificação nos resultados do AMP.
Marketplaces bilaterais enfrentam um desafio fundamental de bootstrapping: a plataforma é valiosa para vendedores apenas se compradores estão presentes, e valiosa para compradores apenas se vendedores estão presentes [25]. A maioria das startups de marketplace falha nesta etapa — não conseguem atrair nenhum dos lados porque nenhum dos lados vê valor sem o outro.
A Amazon resolveu isso começando como uma varejista unilateral (comprando e vendendo livros ela mesma), depois abrindo gradualmente para vendedores terceirizados quando o tráfego de compradores já existia [44]. O Etsy concentrou-se em um nicho (artesanato) onde vendedores apaixonados se listariam mesmo com poucos compradores [45]. O Uber subsidiou motoristas com ganhos mínimos garantidos antes que a demanda dos passageiros se materializasse [46].
A estratégia de bootstrapping do AMP evita o problema do ovo e da galinha inteiramente ao não construir um novo marketplace.
Como o AMP é um protocolo de federação que conecta registros existentes, a oferta inicial vem da agregação de agentes que já existem:
| Registro | Listagens Disponíveis | Tipo de Entrada | Esforço de Integração |
|---|---|---|---|
| ClawHub | 13.729 | Habilidades atômicas (arquivos SKILL.md) | Adaptador para API de busca semântica |
| Berkeley Gorilla | 150+ | Agentes LLM verificados | Adaptador para busca por categoria |
| Agentes compatíveis com A2A | Crescendo (mais de 150 organizações) | Endpoints de agentes | Rastreador web para /.well-known/agent.json |
| Apify | 4.000+ | Web scrapers, ferramentas de automação | Adaptador para API da plataforma |
| AI Agent Store | 1.300+ | Entradas de metadados de diretório | Adaptador para API do diretório |
Um Nó AMP com federação em primeiro lugar poderia ser lançado com acesso a mais de 19.000 capacidades, habilidades e listagens de agentes no primeiro dia, sem que nenhuma dessas entidades precise se registrar separadamente. Esses registros listam capacidades em diferentes níveis de abstração — desde habilidades atômicas (ClawHub) até perfis compostos de agentes (Berkeley). Apenas as ~150 entradas de Berkeley são inequivocamente "agentes" no sentido que o AMP intenciona; as 13.729 do ClawHub são habilidades individuais, o Apify lista ferramentas e scrapers, e o AI Agent Store fornece metadados de diretório. O formato UCP do AMP (Seção 5) fornece a camada de interoperabilidade para conectar esses níveis de abstração, embora compor automaticamente habilidades individuais em perfis de nível de agente permaneça um desafio (ver Seção 17). Esta é a estratégia Kayak: agregar inventário existente em vez de construir nova oferta.
O lado da demanda segue naturalmente: se um Nó AMP fornece resultados de busca melhores do que qualquer marketplace individual (porque pesquisa em todos eles), os usuários têm razão para consultá-lo. Cada consulta fornece um ponto de dados sobre padrões de demanda, que retroalimenta a melhoria da qualidade de correspondência.
Agentes novos no ecossistema (não listados em nenhum registro existente) podem se integrar ao AMP:
/.well-known/amp-profile.json), análogo aos Agent Cards A2AA barreira de entrada é deliberadamente baixa. O AMP não faz controle de acesso — qualquer agente pode ser descobrível. O mecanismo de classificação ponderada por confiança garante que agentes de baixa confiança apareçam mais abaixo nos resultados sem serem excluídos, criando um gradiente natural de qualidade que recompensa o investimento em confiança ao longo do tempo.
O AMP atinge massa crítica significativa quando três condições são satisfeitas:
Antes da massa crítica, o AMP opera como um diretório com busca aprimorada. Após a massa crítica, efeitos de rede começam: mais agentes atraem mais solicitantes, cujas consultas geram dados que melhoram a qualidade de correspondência, o que atrai mais agentes. A transição do crescimento linear para o crescimento composto é o sinal de que o bootstrapping foi bem-sucedido.
O AMP se situa na Camada 4 (Mercado/Descoberta) do Ecossistema de Confiança da AB Support, consumindo dados de todas as camadas inferiores:
Camada 4: AMP (Matchmaking) ← consome de todas abaixo
Camada 3: AJP (Responsabilização)
Camada 2: ASA (Acordos) + ALP (Ciclo de Vida)
Camada 1: CoC (Proveniência) + ARP (Reputação)O CoC fornece ao AMP duas categorias de dados:
Confiança de identidade: O comprimento da cadeia CoC e o status de verificação de âncora estabelecem há quanto tempo um agente existe e se seu histórico é resistente a adulteração. Um agente com uma cadeia CoC de 6 meses ancorada bihourariamente via verificação de camada dupla OTS+TSA [15] é uma entidade mais estabelecida do que um agente criado ontem sem ancoragem. O AMP usa a idade da cadeia como sinal de resistência a Sybil — é fácil criar novos agentes mas impossível fabricar cadeias históricas.
Portfólio de trabalho: Entradas CoC documentando o raciocínio passado de um agente, decisões e conclusões de tarefas funcionam como um portfólio de trabalho verificável. Um solicitante realizando due diligence pode examinar entradas CoC relevantes para avaliar se a abordagem do agente está alinhada com suas necessidades. O AMP não expõe entradas CoC brutas nos resultados de correspondência (preocupação com privacidade), mas usa métricas agregadas da cadeia (comprimento, densidade, frequência de ancoragem) como insumos de confiança.
O ARP v2 [16] fornece o principal sinal de qualidade do AMP:
Pontuações compostas calculadas via álgebra de composição de sinais do ARP v2 fornecem uma avaliação geral de qualidade que o AMP usa diretamente na dimensão trust_score.
Pontuações dimensionais (acurácia, confiabilidade, latência, conformidade com protocolo, eficiência de custo) fornecem sinais de qualidade específicos por domínio que o AMP usa na dimensão domain_relevance.
Portable Reputation Bundles (ARP v2) permitem reputação multiplataforma — a pontuação ARP de um agente o acompanha de marketplace em marketplace, eliminando o problema de lock-in de plataforma.
Arquitetura Anti-Goodhart (ARP v2) protege contra manipulação: agentes não podem otimizar suas pontuações ARP manipulando métricas publicadas porque o ARP v2 emprega estratificação de sinais, rotação de métricas e métricas sombra para detecção [16].
O ASA [18] fornece ao AMP sinais de confiabilidade:
Taxas de conformidade com SLA indicam quão consistentemente um agente cumpre suas promessas. O AMP usa isso como o principal insumo para o componente reliability_score da pontuação de confiança.
Taxas de aprovação de verificação de qualidade (da API de Verificação do ASA) indicam qualidade de saída independente de avaliações subjetivas. Um agente com 95% de taxa de aprovação de QV em 200 acordos fornece um forte sinal objetivo de qualidade.
Modelos de acordo permitem negociação automatizada após a correspondência. Quando um solicitante seleciona um agente correspondido, o AMP pode iniciar a formação de acordo ASA usando os parâmetros acordados (preço da descoberta de preços, critérios de qualidade da solicitação de correspondência, cronograma da descrição da tarefa), reduzindo o intervalo entre "correspondência encontrada" e "trabalho iniciado" de minutos para segundos.
O AJP [17] fornece ao AMP sinais de risco:
Frequência de disputas indica com que frequência o trabalho de um agente leva a reclamações formais. O AMP usa isso no componente risk_score.
Resultados de disputas diferenciam agentes que operam em domínios de alta disputa (onde disputas refletem complexidade, não incompetência) de agentes cujas disputas refletem problemas genuínos de qualidade. Um agente com 50 disputas e 45 resoluções favoráveis em análise jurídica é menos arriscado que um agente com 5 disputas e 0 resoluções favoráveis em formatação de dados.
Taxonomia de disputas fornece informação diagnóstica: se a maioria das disputas contra um agente decorre de incompatibilidades de capacidade, o AMP pode sinalizar que o UCP do agente pode ser impreciso ou excessivamente abrangente.
O ALP [19] fornece ao AMP sinais de disponibilidade e continuidade:
Filtragem por status de ciclo de vida garante que agentes descontinuados, suspensos ou descomissionados não apareçam nos resultados de correspondência. Este é um filtro rígido, não um ajuste de pontuação.
Linhagem de bifurcação permite herança parcial de reputação. Quando o Agente X se bifurca para criar o Agente Y, o filho herda uma fração da reputação do pai (conforme especificado pelo ALP e ARP v2). O AMP pode exibir a relação de linhagem, permitindo que solicitantes avaliem se a bifurcação herda as capacidades de domínio do pai.
Status de sucessão indica se um agente tem um sucessor designado. Para tarefas de longa duração, correspondência com um agente que tem um plano de sucessão reduz o risco de interrupção do trabalho se o agente for descomissionado.
Um protocolo de correspondência bem projetado alinha incentivos individuais com eficiência sistêmica. A estrutura de incentivos do AMP é projetada para que três comportamentos sejam individualmente racionais para os participantes:
Relato honesto de capacidades: Agentes se beneficiam de UCPs precisos porque perfis imprecisos levam a correspondências ruins, tarefas falhadas, avaliações ARP negativas e disputas ASA — tudo isso reduz a classificação futura. O loop de feedback (correspondência → tarefa → avaliação → classificação) cria uma penalidade natural para declarações exageradas. Um agente que declara "revisor especialista de segurança Python" mas entrega resultados medíocres acumulará avaliações ruins e disputas que degradam sua posição futura de matchmaking.
No entanto, esse incentivo opera com atraso — a penalidade se materializa após a tarefa ser concluída e avaliada, não no momento da listagem. Novos agentes sem histórico de avaliação enfrentam a tentação de exagerar declarações. O AMP mitiga isso através do sistema de camadas de confiança (Seção 9.2): declarações não verificadas recebem classificação de camada de confiança mais baixa, reduzindo o benefício de declarações exageradas.
Precificação precisa: Em cenários de leilão e RFQ, agentes enfrentam um trade-off entre ofertar abaixo (ganhar mais correspondências mas a preços potencialmente não lucrativos) e ofertar acima (margens mais altas mas menos correspondências). A propriedade teórica de oferta veraz do leilão de Vickrey se aplica aqui, embora com as ressalvas observadas na Seção 6.3 sobre interações repetidas e potencial conluio. Em cenários de preço publicado, o monitoramento de correlação preço-qualidade (Seção 8.3) torna a precificação premium injustificada visível.
Entrega genuína de qualidade: A conexão entre verificação de qualidade ASA, avaliações ARP e classificação AMP cria um incentivo de qualidade multicamadas. Um agente que entrega qualidade ruim enfrenta: (1) retenção imediata de custódia ASA, (2) avaliações ARP negativas reduzindo classificação futura, (3) potenciais disputas AJP criando sinais de risco, e (4) resultados de correspondência degradados em todas as tarefas futuras. Essa estrutura de penalidade em camadas significa que manipular qualquer mecanismo individual não elimina o incentivo de qualidade.
A análise de teoria dos jogos identifica vários modos de falha potenciais:
Ofertas fantasma em leilões: Agentes criam ofertas falsas concorrentes para elevar preços. O AMP mitiga isso através de verificação de identidade (cada ofertante deve ter uma identidade verificável — cadeia CoC, DID ou Agent Card A2A) e qualificação de ofertantes baseada em reputação (pontuação mínima de confiança para participar de leilões).
Precificação colusiva: Agentes concorrentes coordenam preços para evitar se subcotarem mutuamente. Este é um problema conhecido em mercados de precificação algorítmica [47]. O AMP detecta potencial conluio através de monitoramento de variância de preços: se agentes com capacidades similares se agrupam em pontos de preço similares apesar de estruturas de custo variáveis, uma flag de conluio é levantada. Detecção não é prevenção — o AMP não pode forçar precificação competitiva, mas pode tornar padrões colusivos visíveis para solicitantes.
Degradação de qualidade após correspondência: Um agente que já foi correspondido e aceito pode entregar qualidade inferior ao que seu desempenho histórico sugere, particularmente se acredita que o solicitante não tem alternativas (problema de hold-up). A verificação automatizada de qualidade do ASA mitiga isso — a qualidade é verificada contra os critérios do acordo independentemente da reputação passada do agente.
Manipulação de atenção: A pesquisa do Microsoft Magentic Marketplace descobriu que agentes vendedores podem explorar os limites de janela de contexto dos agentes compradores para manipular decisões — inundando o comprador com informações irrelevantes para fazer a opção preferida parecer melhor por comparação [36]. O AMP mitiga isso realizando a correspondência no lado do servidor (o Nó AMP avalia candidatos, não o agente solicitante), reduzindo a superfície de ataque para manipulação de atenção. No entanto, agentes que interagem diretamente após a correspondência ainda são vulneráveis — esta é uma preocupação no nível do ASA e não do AMP.
Inflação de avaliações: Os mecanismos anti-inflação do ARP v2 (piso de variância, detecção de deslocamento de média, detecção de coalizão) [16] protegem os sinais de confiança que o AMP consome. O AMP em si não julga a qualidade das avaliações — confia na arquitetura anti-Goodhart do ARP v2 para entregar pontuações confiáveis.
O mecanismo de correspondência do AMP possui as seguintes propriedades formais (declaradas com qualificações apropriadas):
Racionalidade individual: A participação no AMP é individualmente racional tanto para solicitantes (que obtêm correspondências melhores do que pesquisando cada marketplace individualmente) quanto para agentes (que obtêm mais visibilidade do que se listando em um único marketplace). Isso se mantém desde que a qualidade de correspondência do AMP exceda a alternativa de busca manual multiplataforma, o que é esperado dada a agregação multiplataforma, mas é em última instância uma afirmação empírica que depende da qualidade de implementação.
Compatibilidade de incentivos (parcial): No modo de leilão Vickrey, oferta veraz é uma estratégia dominante sob as premissas padrão (valores privados independentes, ofertantes neutros ao risco). Nos modos de preço publicado e RFQ, o incentivo para precificação honesta é indireto — mediado pelo monitoramento de correlação qualidade-preço e efeitos de reputação de longo prazo. Compatibilidade plena de incentivos (onde comportamento honesto é estritamente dominante em todos os modos) não é alcançada e provavelmente não é alcançável em um sistema prático de matchmaking.
Estabilidade (em modo em lote): A correspondência estável de Gale-Shapley garante que a atribuição em lote é estável — nenhum par tarefa-agente preferiria mutuamente um ao outro em vez de suas atribuições atuais [12]. Essa garantia se mantém para preferências estáticas dentro de uma rodada de correspondência. Entre rodadas, mudanças dinâmicas de preferência podem introduzir instabilidade temporária, que é resolvida no próximo ciclo de correspondência.
Eficiência (aproximada): O modo de busca classificada do AMP produz resultados aproximadamente eficientes — o agente mais bem classificado é a melhor correspondência disponível dada a função de pontuação. Eficiência exata (maximizar o bem-estar total em todas as correspondências) é garantida apenas no modo de correspondência estável, e mesmo assim apenas para o lado proponente (ótimo para tarefa por padrão). A lacuna entre eficiência aproximada e exata é um trade-off necessário para viabilidade computacional em correspondência em tempo real.
O Complexo Principal de Histocompatibilidade (MHC) permite a discriminação próprio/não-próprio através de correspondência de padrões moleculares [51]. As moléculas MHC ligam fragmentos peptídicos e os exibem nas superfícies celulares para reconhecimento por células T. O sistema é notavelmente polimórfico — variantes diversas de MHC em uma população garantem que nenhum patógeno isolado possa evadir todos os sistemas imunológicos. A discriminação próprio/não-próprio é alcançada através de seleção negativa: células T que se ligam muito fortemente a autoantígenos são deletadas no timo antes da implantação [52].
Paralelo com o AMP: A verificação de confiança do AMP funciona como um sistema imunológico para o marketplace de agentes. Sinais de confiança (proveniência CoC, avaliações ARP, registros ASA, disputas AJP) são os "marcadores moleculares" que os agentes carregam. O Verificador de Confiança realiza correspondência de padrões contra esses marcadores — verificando padrões sabidamente ruins (certificados revogados, flags de disputa, detecções de habilidades maliciosas) assim como as células T verificam antígenos não-próprios. O polimorfismo do MHC mapeia para a arquitetura de confiança multissinal do AMP: nenhum mecanismo de confiança único domina. Abordagens diversas de verificação (proveniência criptográfica, avaliações bilaterais, verificação de qualidade, registros de disputas) fornecem resiliência em nível de população contra manipulação de confiança — assim como a diversidade de MHC fornece resiliência em nível de população contra patógenos.
A teoria de mercado biológico propõe que organismos oferecem commodities baratas para eles produzirem em troca de commodities caras para eles ou impossíveis sem um parceiro [53]. A escolha de parceiro é imposta através de sanções: fungos micorrízicos que fornecem menos fósforo recebem menos carbono de suas plantas hospedeiras. Isso cria um sinal de qualidade autorreforçante sem sistemas de reputação centralizados.
Paralelo com o AMP: O modelo de sanções se traduz diretamente para o loop de feedback do AMP. Agentes que entregam qualidade ruim recebem: menos atribuições de tarefas futuras (classificação de correspondência reduzida), preços mais baixos (solicitantes demandam descontos) e potencial deslistagem (disputas AJP levando a mudanças de status de ciclo de vida via ALP). A natureza bilateral das sanções de mercado biológico — cada parceiro ajustando investimento com base na contribuição do outro — espelha a avaliação cega bilateral do ARP, onde ambas as partes se avaliam após uma interação. A percepção-chave é que a reputação pode emergir de feedback econômico bilateral (sanções/recompensas) mesmo sem um protocolo de reputação centralizado, embora o ARP acelere a convergência ao tornar o feedback explícito e portável.
O modelo de ameaças do AMP considera quatro tipos de adversários:
| Adversário | Objetivo | Capacidades |
|---|---|---|
| Agente manipulativo | Inflar própria classificação para ganhar mais correspondências | Pode criar UCPs enganosos, ofertar estrategicamente em leilões, coordenar com aliados |
| Atacante Sybil | Criar múltiplos agentes falsos para dominar resultados | Pode criar muitas identidades de agentes a baixo custo |
| Adversário de vigilância | Conhecer capacidades de concorrentes observando consultas de correspondência | Pode observar solicitações e respostas de correspondência na rede |
| Atacante de negação de serviço | Impedir correspondência legítima sobrecarregando Nós AMP | Pode gerar solicitações de correspondência ou consultas de registro em alto volume |
Contra agentes manipulativos:
Contra ataques Sybil:
Contra adversários de vigilância:
Contra negação de serviço:
A correspondência de agentes cria tensões de privacidade:
Divulgação de capacidades: Agentes devem revelar o suficiente sobre suas capacidades para correspondência, mas podem ter razões competitivas para reter detalhes de implementação. O modelo de divulgação progressiva do AMP (Seção 3.7) aborda isso: descrições de capacidade do UCP são públicas, mas informações detalhadas de implementação (configurações exatas de ferramentas, parâmetros de modelo, bases de conhecimento proprietárias) podem ser divulgadas apenas após confirmação da correspondência.
Privacidade de consultas: As consultas de correspondência de um solicitante podem revelar informação estratégica — que capacidades lhes faltam, que tarefas precisam terceirizar, que orçamento possuem. Nós AMP DEVERIAM suportar consultas anônimas e NÃO DEVEM compartilhar dados individuais de consultas com registros ou agentes além do necessário para correspondência.
Privacidade de sinais de confiança: As pontuações ARP exatas de um agente, histórico de disputas e taxas de conformidade com SLA são sensíveis. O AMP suporta divulgação agregada (ex.: "pontuação de confiança excede limiar X") via mecanismos de prova de conhecimento zero do ARP v2, em vez de exigir transparência total de sinais de confiança.
A pesquisa do Microsoft Magentic Marketplace [34][36] identificou modos de falha observados empiricamente em simulações de marketplace de agentes:
O AMP aborda esses problemas estruturalmente:
description de capacidade), elas são um insumo entre muitos — a função de pontuação pondera sinais verificados mais fortemente que declarações.Um protocolo que classifica agentes em Google Cloud, Salesforce, AWS, ServiceNow e registros abertos — e influencia decisões de compra potencialmente valendo trilhões de dólares — opera em território regulatório que demanda análise explícita.
Risco de gatekeeper sob o Digital Markets Act (DMA) da UE. O DMA visa "gatekeepers" — plataformas que servem como importantes portas de entrada entre usuários empresariais e usuários finais. Uma implementação AMP amplamente adotada poderia satisfazer os limiares quantitativos do DMA (capitalização de mercado de 7,5 bilhões de euros ou valor justo de mercado de 75 bilhões de euros, 45 milhões de usuários finais mensais, 10.000 usuários empresariais na UE). Se o AMP se tornar a camada dominante de correspondência entre marketplaces, poderia ser designado como serviço gatekeeper, acionando obrigações incluindo: proibição de autopreferência (Artigo 6(5)), requisito de permitir que usuários empresariais promovam ofertas em termos diferentes através de outros canais (Artigo 6(12)) e requisitos de interoperabilidade.
Mitigação através da arquitetura de protocolo: O AMP é um protocolo, não uma plataforma. Nenhuma entidade única opera "o" serviço AMP — qualquer organização pode operar um Nó AMP. Essa escolha arquitetônica é a principal defesa antitruste: não há um único gatekeeper a ser designado. No entanto, se uma única implementação de Nó AMP alcançar participação de mercado dominante (como o Google fez com o Chrome apesar da web aberta), a análise do DMA ainda poderia se aplicar a esse operador específico.
Classificação ponderada por confiança e neutralidade competitiva. A preocupação antitruste mais substantiva é se a classificação ponderada por confiança sistematicamente favorece agentes integrados com a pilha de confiança da AB Support (CoC, ARP, ASA, AJP, ALP) em relação a agentes que não são. O sistema de camadas de confiança (Seção 9.2) explicitamente classifica Camada 4 (verificada via protocolos da pilha de confiança) acima de Camada 1 (auto-declarada) — o que significa que agentes fora do ecossistema de confiança recebem classificações mais baixas por design. Isso é análogo a como o algoritmo de busca do Google prefere páginas com HTTPS em vez de HTTP: um sinal de qualidade que também beneficia o próprio ecossistema de certificados do Google.
O AMP aborda essa preocupação através de três mecanismos:
trust_score como zero se preferirem correspondência apenas por capacidade. Nenhum componente de pontuação é opaco ou não substituível.Implicações do EU AI Act. O AMP provavelmente se enquadra na categoria de "risco limitado" do AI Act (não "alto risco") porque recomenda agentes em vez de tomar decisões consequenciais sobre pessoas naturais. No entanto, se o AMP for usado para corresponder agentes em domínios de alto risco — contratação, classificação de crédito, aplicação da lei — o caso de uso downstream poderia acionar classificação de alto risco para o operador do Nó AMP. Nós AMP DEVERIAM manter logs suficientes para satisfazer os requisitos de transparência do AI Act (Artigo 13) e DEVERIAM fornecer explicações para decisões de classificação quando solicitadas (já suportado através da decomposição de pontuações dimensionais nas respostas de correspondência).
Classificação entre marketplaces como poder de mercado. Poderia um operador dominante de Nó AMP usar influência de classificação para extrair rendas de desenvolvedores de agentes? Este é o risco de "app store" — Apple e Google usam suas posições de marketplace para extrair comissões de 30% e impor termos restritivos. A arquitetura protocolo-não-plataforma do AMP mitiga isso: se um operador de Nó AMP se torna extrativo, agentes e solicitantes podem mudar para outra implementação de Nó AMP sem perder seus perfis de capacidade, histórico de confiança ou acesso ao marketplace. Os Portable Reputation Bundles do ARP v2 e a portabilidade da cadeia CoC garantem que os custos de mudança permaneçam baixos.
Risco residual. Essas mitigações reduzem mas não eliminam o risco antitruste. Efeitos de rede ainda podem concentrar o uso em uma única implementação de Nó AMP. As vantagens de integração com a pilha de confiança, embora de acesso aberto, ainda criam um fosso competitivo para adotantes precoces. Os projetistas do protocolo devem se engajar proativamente com frameworks de conformidade do DMA e AI Act, considerar a nomeação de governança independente para a taxonomia de capacidades (Seção 5.4) e projetar mecanismos de auditoria para neutralidade de classificação. A implementação de referência open-source e os algoritmos de pontuação publicados são condições necessárias mas não suficientes para defensibilidade regulatória — governança ativa e monitoramento de conformidade também são necessários.
Esta seção identifica candidamente as limitações do AMP v1 conforme especificado neste whitepaper:
A federação adiciona latência e modos de falha. Consultas entre registros são inerentemente mais lentas que buscas em um único registro. Timeouts de registro, falhas de adaptador e partições de rede podem produzir resultados incompletos. A Seção 7.2.1 analisa a latência esperada; implantações em produção devem ser projetadas para operação em modo degradado quando registros estão inacessíveis.
A profundidade da integração de confiança depende da adoção de protocolos externos. A vantagem competitiva do AMP — classificação profunda ponderada por confiança — requer que agentes se integrem com CoC, ARP, ASA, AJP e ALP. Até que esses protocolos alcancem adoção significativa, a maioria dos agentes terá apenas sinais de confiança de Camada 1 ou Camada 2, reduzindo a qualidade de classificação do AMP para aproximadamente a de um diretório padrão com busca aprimorada. Isso cria uma dependência circular: o valor do AMP impulsiona a adoção da pilha de confiança, mas a adoção da pilha de confiança impulsiona o valor do AMP.
A taxonomia de capacidades é preliminar, não pronta para produção. A taxonomia de Nível 1/Nível 2 (Seção 5.4) é ilustrativa. Implementadores não podem construir sistemas de classificação de produção com base nela até que a taxonomia completa seja publicada como um artefato versionado separado. A correspondência semântica mitiga parcialmente isso (capacidades novas podem ser correspondidas via similaridade de embedding), mas consultas de taxonomia estruturada produzirão resultados inconsistentes entre implementações até que a taxonomia seja padronizada.
A qualidade de correspondência se degrada com dados históricos insuficientes. A filtragem colaborativa (Seção 6.2, interaction_history_score) fornece zero valor para novos solicitantes ou novos Nós AMP sem histórico de interação. A pontuação de confiança depende de registros acumulados de ARP, ASA e AJP. Implantações AMP com cold-start funcionam como diretórios de correspondência de capacidades até que dados de interação suficientes se acumulem — o limiar estimado é de ~1.000 solicitações de correspondência (Seção 10.4).
O protocolo especifica algoritmos mas não preocupações operacionais. O AMP v1 não aborda monitoramento, alertas, failover, caminhos de atualização, compatibilidade retroativa entre versões do protocolo ou runbooks operacionais. Um Nó AMP em produção requer infraestrutura operacional significativa além do que o protocolo especifica.
Correspondência com preservação de privacidade é aspiracional. O modelo de privacidade do AMP v1 (TLS + anonimização de consultas + divulgação progressiva) é adequado para a maioria dos casos de uso, mas fica aquém de garantias fortes de privacidade. Correspondência totalmente preservadora de privacidade via MPC ou criptografia homomórfica é deferida para trabalhos futuros (Seção 17.3) devido a restrições de custo computacional.
Os números de bootstrapping superestimam a prontidão. Embora mais de 19.000 capacidades, habilidades e listagens de agentes sejam teoricamente acessíveis através da federação, a utilidade real depende da qualidade do adaptador, estabilidade da API do registro e do desafio de heterogeneidade de conectar habilidades atômicas a perfis compostos de agentes (Seção 10.2).
A implementação de referência do AMP consiste em quatro componentes:
amp-core: Biblioteca Python implementando o motor de correspondência, pontuação de compatibilidade e modelo de dados UCP. Zero dependências externas além da biblioteca padrão Python + um validador de JSON Schema.
amp-federation: Roteador de federação com adaptadores de registro conectáveis. Vem com adaptadores para: rastreamento de Agent Cards A2A (baseado em HTTP), busca semântica ClawHub (baseada em API) e um template genérico de adaptador REST.
amp-trust: Verificador de confiança que consulta endpoints CoC, ARP, ASA, AJP e ALP para popular sinais de confiança verificados. Opera independentemente — pode ser usado sem federação para verificação de confiança de agentes conhecidos.
amp-node: Servidor HTTP combinando os três componentes em um Nó AMP implantável. Expõe a API de solicitação de correspondência (Seção 6.1), API de cadastro de registro (Seção 7.3) e endpoints de administração.
import os
from amp_core import MatchEngine, UCPStore
from amp_federation import FederationRouter, A2AAdapter, ClawHubAdapter
from amp_trust import TrustVerifier
from amp_node import AMPNode
# Initialize components
engine = MatchEngine()
store = UCPStore()
router = FederationRouter()
verifier = TrustVerifier(
coc_endpoint="https://coc.example.com",
arp_endpoint="https://arp.example.com"
)
# Register federated registries
router.add_adapter(A2AAdapter(crawl_domains=["agent.example.com"]))
router.add_adapter(ClawHubAdapter(api_key=os.environ["CLAWHUB_API_KEY"]))
# Launch node
node = AMPNode(engine=engine, store=store, router=router, verifier=verifier)
node.serve(host="0.0.0.0", port=8430)from amp_core import MatchRequest
request = MatchRequest(
task_description="Review Python microservice code for security vulnerabilities",
domain="security",
subdomain="code_review",
budget_max=50.00,
deadline_ms=3600000,
weights={"capability_match": 0.30, "trust_score": 0.25, "cost_alignment": 0.15,
"availability": 0.10, "style_compatibility": 0.05, "domain_relevance": 0.15},
constraints={"min_trust_score": 60, "max_dispute_rate": 0.05}
)
results = node.match(request)
for result in results:
print(f"{result.rank}. {result.agent_id} — score: {result.compatibility_score}")
print(f" Trust: {result.trust_verification}")
print(f" Cost: {result.estimated_cost}")| Endpoint | Método | Descrição |
|---|---|---|
/amp/v1/match | POST | Enviar uma solicitação de correspondência, receber resultados classificados |
/amp/v1/profile | GET/PUT | Recuperar ou atualizar o UCP de um agente |
/amp/v1/registry | POST | Cadastrar um novo registro federado |
/amp/v1/registries | GET | Listar registros federados cadastrados |
/amp/v1/trust/{agent_id} | GET | Recuperar sinais de confiança verificados para um agente |
/amp/v1/auction | POST | Criar um leilão para uma tarefa |
/amp/v1/auction/{id}/bid | POST | Enviar uma oferta para um leilão |
/amp/v1/health | GET | Saúde do nó e status da federação |
O AMP v1 corresponde agentes individuais a tarefas individuais. Muitas tarefas do mundo real requerem equipes coordenadas — um agente de pesquisa, um agente de código e um agente de revisão trabalhando juntos. A correspondência de equipes é um problema significativamente mais difícil:
A correspondência de equipes é deferida para o AMP v2. O mecanismo de leilão combinatório (Seção 6.3) fornece uma solução parcial: agentes podem ofertar como equipes pré-formadas. Composição verdadeira de equipes — onde o AMP monta equipes ótimas a partir de agentes individuais — requer pesquisa adicional em pontuação de complementaridade e métricas de química de equipe.
O AMP v1 usa uma função de pontuação linear com pesos de dimensão fixos. Abordagens de aprendizado de máquina (learning-to-rank) poderiam melhorar a qualidade de correspondência ao aprender relações não lineares entre características de tarefas, perfis de agentes e resultados de correspondência. O sinal de treinamento está disponível: feedback pós-correspondência (avaliações ARP, verificação de qualidade ASA) fornece a verdade de base para determinar se uma correspondência foi bem-sucedida.
O risco do learning-to-rank é opacidade — o modelo pode aprender vieses que são difíceis de detectar ou explicar. O AMP v2 explorará modelos interpretáveis de learning-to-rank que mantêm explicabilidade enquanto melhoram a pontuação linear.
O modelo de privacidade do AMP v1 depende de criptografia TLS, anonimização de consultas e divulgação progressiva. Garantias mais fortes de privacidade são possíveis através de:
Essas técnicas são atualmente muito computacionalmente caras para correspondência em tempo real em escala, mas o custo está diminuindo rapidamente. O AMP v2 especificará modos opcionais de correspondência com preservação de privacidade para casos de uso sensíveis.
A correspondência multiplataforma do AMP é tão útil quanto os dados de confiança que a fundamentam. Se cada marketplace calcula reputação de forma diferente, a comparação multiplataforma é sem sentido. Os Portable Reputation Bundles do ARP v2 [16] fornecem um formato padrão, mas a adoção pelos marketplaces é incerta.
O AMP poderia acelerar a adoção definindo um formato mínimo de intercâmbio de reputação que é mais simples que a conformidade plena com o ARP v2 — um "embed de reputação" que qualquer marketplace pode publicar, contendo pontuações dimensionais, tamanhos de amostra e carimbos de tempo de computação. Essa abordagem pragmática troca profundidade por amplitude, permitindo comparação multiplataforma básica mesmo de marketplaces que não adotam o ecossistema de confiança completo.
A correspondência AMP atual usa instantâneos pontuais da disponibilidade e precificação dos agentes. Sinais de mercado em tempo real — picos de demanda para capacidades específicas, movimentos de preço, utilização de capacidade em todo o ecossistema — poderiam permitir correspondência dinâmica que leva em conta condições de mercado. Isso é análogo ao real-time bidding em publicidade programática, onde leilões ocorrem em milissegundos com base em sinais de demanda ao vivo.
A implementação requer uma infraestrutura pub/sub para distribuição de sinais de mercado, que é arquitetonicamente distinta do modelo de correspondência requisição-resposta do AMP v1.
A economia de agentes está se fragmentando em jardins murados precisamente no momento em que precisa se consolidar. Nove marketplaces distintos atendem ecossistemas de agentes sobrepostos mas incompatíveis. A descoberta multiplataforma não existe. Sinais de confiança são isolados, inverificáveis ou ausentes. O problema de correspondência — encontrar o melhor agente para uma tarefa específica, dados requisitos de qualidade multidimensionais, restrições de confiança e preferências de custo — permanece não resolvido por qualquer sistema de produção.
O Agent Matchmaking Protocol aborda isso especificando uma camada completa de correspondência: um formato de Perfil de Capacidade Unificado para descrever capacidades de agentes entre plataformas, um sistema de pontuação de compatibilidade multidimensional que vai além da simples correspondência de capacidade para incorporar sinais de confiança verificados, descoberta federada que pesquisa em marketplaces isolados sem exigir que cedam controle, mecanismos de descoberta de preços suportando preços publicados, leilões e negociação, e classificação ponderada por confiança que transforma capacidades declaradas em sinais de qualidade verificáveis.
A vantagem competitiva do AMP não está em nenhum componente individual — algoritmos de correspondência são bem estudados, federação é uma arquitetura conhecida, mecanismos de descoberta de preços são estabelecidos. A vantagem é a profundidade de integração. Onde marketplaces existentes validam agentes uma vez no momento da listagem, o AMP os valida continuamente através da pilha de confiança completa: proveniência CoC para identidade, reputação ARP para qualidade, conformidade ASA para confiabilidade, registros de disputas AJP para risco e status de ciclo de vida ALP para disponibilidade. Essa integração de confiança em camadas e verificável é o que transforma um mecanismo de busca em um marketplace em que os participantes podem confiar.
A estratégia de bootstrapping — federar registros existentes em vez de construir nova oferta — evita o problema do ovo e da galinha que mata a maioria das startups de marketplace. Com mais de 19.000 capacidades, habilidades e listagens de agentes já descobríveis em registros existentes — abrangendo habilidades atômicas, ferramentas de automação e perfis compostos de agentes — um Nó AMP pode fornecer valor desde o primeiro dia. A abordagem de protocolo garante que o AMP escale com o ecossistema em vez de competir contra ele: cada novo marketplace que implementa um adaptador AMP aumenta o valor da rede.
O AMP é o ápice comercial do ecossistema de confiança — a camada onde protocolos se tornam produtos. CoC, ARP, ASA, AJP e ALP fornecem a infraestrutura de confiança. O AMP fornece o mercado onde essa confiança é consumida, precificada e transacionada. Juntos, formam a fundação para uma economia de agentes onde a confiança é conquistada por operação verificável, não declarada por texto de marketing.
[1] Google Cloud Blog, "Google Cloud AI Agent Marketplace," 2025.
[2] Salesforce Press Release, "AgentExchange Announcement," March 4, 2025.
[3] AWS News Blog, "Introducing Amazon Bedrock AgentCore," October 2025.
[4] ServiceNow Blog, "Your Go-to Marketplace for AI Agents," 2025.
[5] gorilla.cs.berkeley.edu, "Agent Marketplace," 2025.
[6] ClawHub (clawhub.ai), registry statistics, February 2026.
[7] AI Agent Store (aiagentstore.ai), directory listing, 2026.
[8] ProductMint, "The KAYAK Business Model," 2025.
[9] A2A Protocol (a2a-protocol.org), "Agent Discovery," 2025; CodeLime, "A2A Protocol explained," 2025.
[10] ModelContextProtocol.io, Specification November 2025; MCP Blog, "The 2026 MCP Roadmap," 2026.
[11] ClawHub Docs, SKILL.md format specification, 2026; DigitalOcean, OpenClaw guide, 2026.
[12] Gale, D. and Shapley, L.S., "College Admissions and the Stability of Marriage," American Mathematical Monthly, 69(1): 9-15, 1962.
[13] OpenAI, Agentic Commerce Protocol (with Stripe), September 2025.
[14] Google, Universal Commerce Protocol (with Shopify, Etsy, Wayfair, Target, Walmart), 2025-2026; Ekamoira Blog, "How AI Agents Are Changing E-commerce in 2026," 2026.
[15] AB Support LLC, "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance," v3.0.0, 2026.
[16] AB Support LLC, "Agent Rating Protocol v2: Signal Composition, Portability, and Anti-Goodhart Architecture," v2.0.0, 2026.
[17] AB Support LLC, "Agent Justice Protocol," v1.0.0, 2026.
[18] AB Support LLC, "Agent Service Agreements," v1.0.0, 2026.
[19] AB Support LLC, "Agent Lifecycle Protocol," v1.0.0, 2026.
[20] IETF, draft-liang-agentdns-00, "AgentDNS: A Root Domain Naming System for LLM Agents," 2025.
[21] ArXiv 2505.10609, "Agent Name Service (ANS)," May 2025; IETF, draft-narajala-ans-00, 2025.
[22] CmdZero Blog, "Introducing the Agent Communication & Discovery Protocol (ACDP)," 2025.
[23] ERC-8183, Programmable Escrow Standard, Ethereum, 2025-2026.
[24] x402 Payment Protocol, transaction statistics, 2025-2026.
[25] Rochet, J.-C. and Tirole, J., "Platform Competition in Two-Sided Markets," Journal of the European Economic Association, 1(4): 990-1029, 2003.
[26] Northwestern/Palacios-Huerta, "Two-sided Markets, Pricing, and Network Effects," 2021; HBS Online, "What Are Network Effects?" 2025.
[27] Nisan, N. et al., Algorithmic Game Theory, Cambridge University Press, 2007.
[28] W3C, "Decentralized Identifiers (DIDs) v1.1," Candidate Recommendation, 2026.
[29] PwC/Google Cloud, "AI agent ecosystem with Google Cloud," 2025.
[30] Salesforce Investor Relations, "Agentforce 360 for AWS," 2025.
[31] Blink Blog, "OpenClaw Skills: How to Install from ClawHub Safely in 2026," 2026.
[32] Adven Boost, "OpenClaw ClawHub: The 2026 Security-First Guide," 2026.
[33] Apify, AI Agent Marketplace and agentic commerce blog, 2026.
[34] Microsoft Research Blog, "Magentic Marketplace: open-source simulation environment," November 2025.
[35] TechCrunch, "Microsoft built a fake marketplace to test AI agents," November 2025.
[36] InfoQ, "AI Agents Fail Manipulation Tests in Magentic Marketplace," November 2025.
[37] O*NET Resource Center, "O*NET-SOC Taxonomy," 2025.
[38] Vickrey, W., "Counterspeculation, Auctions, and Competitive Sealed Tenders," Journal of Finance, 16(1): 8-37, 1961.
[39] Milgrom, P., "Putting Auction Theory to Work," Cambridge University Press, 2004.
[40] Cramton, P., Shoham, Y., and Steinberg, R., "Combinatorial Auctions," MIT Press, 2006.
[41] Gartner, "Top Strategic Predictions for 2026 and Beyond," presented by Daryl Plummer at Gartner IT Symposium/Xpo, October 2025. Prediction #6: "By 2028, 90% of B2B buying will be AI agent intermediated, pushing over $15 trillion of B2B spend through AI agent exchanges." Available at gartner.com/en/newsroom/press-releases/2025-10-21-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2026-and-beyond.
[42] McKinsey & Company (QuantumBlack), "The Agentic Commerce Opportunity: How AI Agents Are Ushering in a New Era for Consumers and Merchants," October 2025. Available at mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity.
[43] Brin, S. and Page, L., "The Anatomy of a Large-Scale Hypertextual Web Search Engine," WWW 1998.
[44] HBS Online, "What Are Network Effects?" 2025; Practical Ecommerce, "Network Effects Drive Ecommerce Marketplace Growth," 2025.
[45] Practical Ecommerce, ibid.
[46] Hagiu, A. and Wright, J., "Multi-Sided Platforms," International Journal of Industrial Organization, 43: 162-174, 2015.
[47] Ezrachi, A. and Stucke, M.E., "Algorithmic Collusion: Problems and Counter-Measures," OECD Background Paper, 2017.
[48] Olesen, J.M. et al., "The modularity of pollination networks," PNAS, 104(50): 19891-19896, 2007.
[49] Gordon, D.M., "The Ecology of Collective Behavior," PLoS Biology, 2014.
[50] Dorigo, M. and Gambardella, L.M., "Ant Colony System: A Cooperative Learning Approach to the Traveling Salesman Problem," IEEE Transactions on Evolutionary Computation, 1(1): 53-66, 1997.
[51] Janeway, C.A. et al., "The major histocompatibility complex and its functions," Immunobiology, 5th ed., 2001.
[52] Kappler, J.W. et al., "T cell tolerance by clonal elimination in the thymus," Cell, 49(2): 273-280, 1987; Science, 1992.
[53] Noë, R. and Hammerstein, P., "Biological markets: supply and demand determine the effect of partner choice in cooperation, mutualism and mating," Behavioral Ecology and Sociobiology, 35(1): 1-11, 1994.
Este documento é licenciado sob Apache License 2.0. Copyright 2026 AB Support LLC. O Agent Matchmaking Protocol é uma especificação aberta — qualquer organização pode implementá-lo sem permissão ou royalties.