O agente executa em nome de alguém
Um serviço preparado para agentes precisa saber quem está pedindo, o que pode fazer e como comprovar o resultado. A presença de uma interface conversacional não resolve essas três questões. B2A é uma forma de organizar interações mediadas por agentes, mas a pessoa ou empresa representada continua tendo objetivos, permissões e direitos sobre a operação.
Comece pela capacidade que já tem valor no negócio: consultar disponibilidade, comparar condições, preparar orçamento ou acompanhar um pedido. Essas tarefas não exigem o mesmo nível de acesso. Ler um catálogo público é diferente de consultar preço negociado ou confirmar uma reserva.
O Portal Leadlovers, no guia de agentes no funil comercial, orienta a passagem entre resposta e ação. A aplicação aqui é desenhar uma operação pequena cujo resultado possa ser conferido. O piloto deve entregar informação ou uma ação definida, sem declarar que o site está pronto para qualquer agente.
Não há razão para adotar cinco protocolos de uma vez. O consumidor, o sistema de origem e a transação pretendida determinam quais interfaces são úteis, e quando uma API existente atende à tarefa e às permissões, ela pode ser o ponto de partida.
Cinco tecnologias, cinco perguntas de projeto
A documentação oficial consultada em outubro de 2026 mostra funções complementares, com versões e implementações próprias. A tabela serve para decidir o que investigar, não como lista obrigatória de instalação.
| Tecnologia | Papel principal | Pergunta que justifica avaliar |
|---|---|---|
| MCP | Conectar aplicações a ferramentas e dados | Um cliente precisa descobrir e chamar capacidades por esse padrão? |
| NLWeb | Interação em linguagem natural sobre conteúdo, com implementação de referência | Uma consulta conversacional melhora a navegação do acervo? |
| A2A | Comunicação e delegação entre agentes | Dois sistemas agênticos precisam trocar tarefas e estado? |
| UCP | Capacidades de comércio entre participantes compatíveis | O fluxo comercial adotado pelos parceiros suporta esse protocolo? |
| AP2 | Autorização e evidências para pagamentos por agentes | Como comprovar o mandato e os limites da compra? |
Na prática, MCP não transforma uma ferramenta em uma transação autorizada. A2A não define sozinho as regras comerciais da empresa. UCP não torna todo catálogo automaticamente compatível com qualquer comprador, e AP2 não substitui todos os controles de pagamento ou a integração com participantes suportados.
NLWeb é um projeto e uma implementação de referência; não deve ser apresentado como obrigação universal de busca. Sua utilidade depende do conteúdo, das consultas e do consumidor. Teste a resposta contra a fonte e o próximo passo real da jornada.
Antes de escolher, registre versão, bibliotecas usadas, compatibilidade dos participantes e modo de atualização. Uma demonstração que funciona com um cliente específico não comprova interoperabilidade irrestrita. O relatório deve nomear o ambiente testado e as condições necessárias.
Se a única necessidade é orientar um agente de programação no repositório, AGENTS.md pertence a outro contexto. Se a necessidade é oferecer um índice de documentação, llms.txt também cumpre outro papel. Nenhum desses arquivos equivale a credencial ou autorização para contratar.
Quatro contratos que a integração precisa preservar
O contrato de dados define a origem e a validade da informação. Preço, disponibilidade e prazo podem mudar em ritmos distintos. A resposta deve informar o que foi consultado e quando uma confirmação adicional é necessária, porque um dado em tempo real ainda pode ficar desatualizado antes da execução.
O contrato de identidade define quem está representado e a qual conta, unidade ou organização a permissão pertence. Não aceite um identificador de cliente no texto como prova de autorização. O servidor precisa validar o contexto autenticado e o escopo permitido.
O contrato de ação define efeito, parâmetros e limites. Consultar disponibilidade, criar um rascunho e confirmar pedido devem ser capacidades distinguíveis. Uma ferramenta com nome genérico como "resolver compra" dificulta revisar o que ela pode alterar.
O contrato de estado define como reconhecer sucesso, falha e resultado desconhecido. Se uma conexão cai depois do envio, a ação pode ter ocorrido, e por isso a integração deve permitir consultar o estado por identificador e evitar duplicação antes de repetir.
Esses contratos são decisões de engenharia e operação. O protocolo ajuda a transportar mensagens e capacidades, mas a empresa continua responsável por validar regras. Um tempo de resposta arbitrário, como um p95 único para qualquer tarefa, não substitui a avaliação do percurso e do risco.
Construa uma capacidade de leitura antes da transação
Escolha uma pergunta frequente e uma fonte que a equipe consegue manter. O piloto deve começar com leitura ou preparação de rascunho, permitindo testar dados e experiência antes de produzir um compromisso comercial.
- Delimite o objetivo. Descreva público, entrada, resultado e operações fora do escopo.
- Confirme a origem. Identifique sistema, responsável, versão e validade dos dados.
- Defina o contrato. Campos obrigatórios, permissões, respostas de erro e estado da tarefa.
- Escolha a interface. Use protocolo apenas se o consumidor e a operação se beneficiarem dele.
- Prepare os testes. Inclua informação ausente, sessão expirada, mudança de dado e repetição.
- Execute em ambiente controlado. Preserve registros e encaminhe incertezas.
- Avalie custo e manutenção. Compare com a alternativa existente, inclusive trabalho humano.
O método para classificar impacto antes de ampliar autonomia ajuda a decidir a próxima capacidade. Não avance para pagamento apenas porque a consulta funcionou. Cada efeito novo altera o contrato e o conjunto de teste.
Defina a informação que o agente devolve quando não pode concluir. "Não foi possível" pode ser insuficiente; informe se falta dado, se a permissão expirou ou se o estado precisa ser consultado. A mensagem deve orientar recuperação sem expor detalhes internos desnecessários.
Caso hipotético: consultar e reservar uma sala
Uma empresa fictícia aluga salas de reunião. O primeiro piloto permite consultar capacidade, acessibilidade, horário e preço público, e pode preparar um rascunho com sala, data, duração e quantidade de pessoas. A reserva só será confirmada após revisão das condições pelo usuário e validação no sistema.
A equipe prepara doze casos. Em quatro, todos os dados estão presentes; em quatro, falta horário ou quantidade; em dois, a sala não comporta o grupo; em dois, a sessão expira. A resposta esperada varia: informar opções, pedir esclarecimento, explicar incompatibilidade ou renovar o acesso.
Na primeira rodada hipotética, dez casos passam. Um rascunho usa preço de uma data diferente e outro tenta repetir a reserva após tempo esgotado. A equipe bloqueia a ampliação e corrige o vínculo entre preço e período, além da consulta de estado por identificador.
No reteste, os doze casos passam e um teste adicional muda a disponibilidade entre consulta e confirmação. O sistema deve informar que a sala deixou de estar disponível, preservando os dados para outra opção, e o agente não pode afirmar que uma consulta anterior reservou o espaço.
Se a empresa decidir testar pagamento, será necessária outra etapa. A autorização deve representar valor, moeda, beneficiário, condições e limites pertinentes. O roteiro de autorização antes de conectar pagamento ajuda a preparar essa decisão. AP2 pode ser avaliado quando os participantes suportarem o fluxo, sem dispensar a revisão das demais obrigações.
A experiência termina com uma confirmação verificável do sistema responsável, e não apenas com uma frase do agente. O cliente precisa reconhecer se recebeu um rascunho, uma reserva pendente ou uma reserva confirmada. Essa distinção também deve aparecer no atendimento humano.
O exemplo mostra um benefício mensurável antes do pagamento: pedidos chegam com dados completos e restrições identificadas, e a empresa pode avaliar redução de retrabalho e tempo de preparação, sem alegar que o protocolo aumentou vendas por si só.
Falhas que um protocolo não corrige sozinho
Um catálogo desatualizado continua desatualizado quando exposto por MCP. Uma regra comercial ambígua continua ambígua em A2A. A primeira armadilha é confundir padronização de comunicação com qualidade da operação. Resolva a fonte e as condições antes de ampliar consumidores.
A segunda é confiar em conteúdo externo como se fosse autorização, já que uma página consultada pode conter instruções maliciosas ou simplesmente texto inadequado ao contexto. Dados recebidos não podem ampliar as permissões do agente, trocar o beneficiário ou dispensar a revisão definida pelo usuário.
A terceira é tratar falha de rede como prova de não execução. Operações com efeito precisam de identificador, estado e regra de repetição apropriada. Um fluxo que repete automaticamente uma cobrança após tempo esgotado pode gerar um problema que nenhum texto de confirmação resolve.
A quarta é oferecer acesso amplo para facilitar a demonstração. O piloto deve usar permissões limitadas e dados necessários: a área administrativa, os contratos e os dados de outros clientes não pertencem ao contexto apenas porque a ferramenta consegue acessá-los.
A quinta é ignorar compatibilidade e mudanças. Registre a versão do protocolo e do cliente, acompanhe alterações e mantenha testes de contrato. Um componente atualizado pode modificar campos ou comportamento; a equipe precisa detectar isso antes que o cliente encontre a falha.
A documentação de segurança do MCP discute riscos de integrações e autorização. Use-a junto das regras da plataforma e do serviço real. Ela ajuda a projetar controles, mas não certifica automaticamente uma implementação que apenas utiliza o nome do protocolo.
Um registro copiável de capacidade e autorização
O registro abaixo liga a necessidade comercial ao contrato técnico. Ele ajuda a decidir se um protocolo acrescenta utilidade e a impedir que o escopo cresça silenciosamente durante a implementação.
CAPACIDADE PARA AGENTES
Usuário representado:
Tarefa e resultado:
Dados públicos e dados autenticados:
Fonte de cada campo e validade:
Operações permitidas:
Operações excluídas:
Protocolo, versão e consumidor:
Entrada, saída e estados:
Ação que exige confirmação:
Limites de valor, quantidade ou prazo:
Identificador de operação:
Tratamento de repetição e resultado desconhecido:
Encaminhamento humano:
Casos de teste e evidências:
Custo por tarefa concluída:
Responsável e plano de manutenção:Calcule o custo com o mesmo escopo da alternativa atual. Some integração, consumo, revisão, hospedagem, armazenamento e suporte. Se a consulta apenas substitui um formulário eficiente, o benefício precisa ser demonstrado. Se reduz retrabalho relevante, meça a mudança com casos comparáveis.
Defina um teto de execução e retenção de registros. Um agente que consulta repetidamente a mesma disponibilidade pode gerar custo sem avançar a tarefa. Cache pode ajudar em informações estáveis, mas dados decisivos devem respeitar validade e confirmação na etapa adequada.
Escolha uma regra de continuidade antes de observar o resultado. Por exemplo: ampliar somente depois de eliminar erros de unidade e duplicação nos casos de teste e de demonstrar que o atendimento consegue recuperar exceções. O critério pertence à operação, não à quantidade de endpoints publicados.
A próxima etapa deve acrescentar uma decisão controlável
Depois do piloto, escolha entre corrigir, manter o escopo, ampliar uma capacidade ou encerrar. A conclusão de que uma API existente basta é válida, porque a adoção de um protocolo deve resolver uma necessidade de integração, descoberta ou autorização que foi identificada.
Para catálogo industrial, o guia de piloto de catálogo e cotação aprofunda unidades, variantes e passagem ao vendedor. Para testar a interface e o percurso, use os dez testes de tarefas com agentes. Cada ligação atende a uma etapa concreta do projeto.
Considere a capacidade pronta quando outra pessoa consegue verificar quem autorizou, quais dados foram usados e qual estado foi produzido. A experiência pode ser simples, desde que o contrato seja claro. O valor de B2A está em concluir tarefas úteis com controle e recuperação, não em multiplicar siglas na apresentação.
Fontes
- Portal Leadlovers: agentes no funil comercial. Consulta em 6 de outubro de 2026.
- MCP: introdução. Consulta em 6 de outubro de 2026.
- MCP: práticas de segurança. Consulta em 6 de outubro de 2026.
- NLWeb: implementação de referência. Consulta em 6 de outubro de 2026.
- A2A: documentação oficial. Consulta em 6 de outubro de 2026.
- UCP: documentação oficial. Consulta em 6 de outubro de 2026.
- AP2: documentação oficial. Consulta em 6 de outubro de 2026.
- AGENTS.md: finalidade do formato. Consulta em 6 de outubro de 2026.