O primeiro piloto deve resolver uma pergunta comercial
A indústria não precisa começar por uma compra autônoma. Um piloto pode ser valioso ao localizar um produto compatível, explicar uma restrição e preparar uma cotação para revisão. Esse escopo permite testar dados e integração antes de delegar decisões de preço, crédito ou prazo que afetam o negócio.
Ter informações no ERP e fichas em PDF não torna uma empresa automaticamente invisível. O problema prático aparece quando o comprador não encontra a especificação, recebe unidade ambígua ou precisa repetir os dados ao vendedor que já os tinha recebido por e-mail ou telefone. A auditoria deve localizar esses pontos, sem transformar a troca de sistema numa condição antecipada.
O Portal Leadlovers, no guia sobre agentes comerciais, orienta separar a resposta informativa da ação que altera uma oportunidade. A aplicação industrial começa por uma família de produtos e uma tarefa repetida. A integração deve melhorar esse percurso sem copiar todas as regras internas para um serviço externo.
Escolha o caso com vendas, engenharia de produto e operação. Um assistente que recomenda um componente apenas pela descrição comercial pode ignorar uma incompatibilidade técnica. A pessoa responsável pelo catálogo deve definir quais atributos sustentam a seleção e quais dúvidas exigem encaminhamento.
Protocolos têm funções diferentes e entram por necessidade
Na documentação consultada em outubro de 2026, MCP conecta aplicações a ferramentas e dados; A2A trata comunicação entre agentes; UCP organiza capacidades de comércio; AP2 trata autorização e evidências de pagamentos por agentes. NLWeb oferece uma implementação de referência para interação em linguagem natural com conteúdo. Esses papéis não formam uma sequência obrigatória de implantação.
AGENTS.md, conforme o projeto oficial, orienta agentes de programação dentro de projetos. Ele não substitui llms.txt como diretório público de documentação, nem funciona como credencial para compradores. A escolha de publicar qualquer arquivo depende de um consumidor real, não de uma suposta obrigação para toda indústria.
| Necessidade do piloto | Solução a avaliar | O que verificar primeiro |
|---|---|---|
| Consultar atributos aprovados | API existente, feed ou ferramenta MCP | Dados disponíveis e autorização |
| Buscar explicações no catálogo | Busca normal ou interface baseada em NLWeb | Qualidade das fontes e respostas |
| Trocar tarefas entre agentes de empresas | A2A, se ambos suportarem | Identidade e contrato da tarefa |
| Executar comércio ou pagamento | UCP/AP2 conforme integração efetiva | Participantes, limites e aprovação |
Não publique endpoints com nomes copiados de um exemplo e chame o projeto de compatível. A integração exige implementar a versão suportada pelos participantes, testar mensagens e tratar erros. Para um primeiro piloto de consulta, uma API que a empresa já mantém pode ser a alternativa mais barata e verificável.
Etapa 1: prepare um recorte de catálogo confiável
Selecione uma família com atributos claros e demanda recorrente. Para cada item, registre código, descrição, unidade de venda, quantidade por embalagem, variantes, limites de aplicação, documentação e situação comercial. Diferencie descontinuado, indisponível e disponível sob consulta.
Escolha a origem de cada campo. Especificações podem vir da engenharia; preço, do sistema comercial; disponibilidade, do estoque; prazo, de regra logística. Um único JSON não torna essas fontes igualmente atuais. Inclua versão e horário de consulta quando isso muda a decisão.
Não exponha tabelas de preço negociadas, margens ou dados de clientes no catálogo público. A consulta autenticada deve respeitar a identidade e os direitos de cada comprador. Uma resposta do agente não pode contornar o mesmo controle aplicado ao portal convencional.
Faça uma revisão de unidades antes de qualquer modelo. Um pedido de dez caixas com cem unidades não pode virar dez unidades. Use exemplos concretos no teste e mostre a unidade em cada etapa: seleção, rascunho e resumo final, porque é na passagem entre elas que caixa e unidade costumam se confundir. Se o código do produto é parecido, acrescente atributos que permitam distinguir a variante.
Etapa 2: exponha leitura e prepare rascunhos
Comece com duas operações: consultar produto e preparar uma solicitação de cotação. A consulta retorna dados aprovados e limites; o rascunho reúne itens, quantidades, unidade e dúvidas pendentes. Ele não reserva estoque, não aprova crédito e não confirma venda.
O contrato da ferramenta deve declarar campos obrigatórios, valores aceitos e respostas de falha. Se a quantidade não atende ao mínimo, devolva a condição e permita revisão. Se a especificação está incompleta, peça a informação necessária em vez de selecionar silenciosamente uma alternativa.
RASCUNHO DE COTAÇÃO
solicitacao_id:
cliente_autorizado:
produto_id:
variante:
quantidade:
unidade_de_venda:
quantidade_por_embalagem:
origem_da_especificacao:
versao_do_catalogo:
disponibilidade_consultada_em:
restricoes:
dados_pendentes:
responsavel_comercial:
estado: rascunho
proxima_acao: revisao_humana
Esse é um modelo de campos, não uma especificação oficial de protocolo. Adapte-o ao ERP e aos controles existentes. O servidor deve validar novamente os dados antes de qualquer gravação relevante. Não confie apenas na interpretação do modelo ou nos valores que chegaram do navegador.
Teste também repetição e estado desconhecido. Se uma solicitação demora, consulte pelo identificador antes de reenviar. O objetivo é impedir que um problema de rede crie várias cotações iguais ou distribua a mesma demanda para vendedores diferentes.
Etapa 3: teste exceções e passagem para o vendedor
Monte casos que representem a operação: produto vigente, código antigo, variante incompatível, quantidade abaixo do mínimo, estoque insuficiente, cliente sem permissão e sessão expirada. O resultado esperado pode ser uma resposta, uma pergunta de esclarecimento ou um encaminhamento. Nem todo caso deve terminar em cotação pronta.
O vendedor precisa receber o contexto útil e o motivo do encaminhamento. Se o agente não conseguiu confirmar uma aplicação, destaque essa dúvida. Não esconda a incerteza num histórico extenso. A primeira revisão humana deve mostrar o que falta decidir, sem exigir reconstruir a conversa inteira entre comprador e agente para descobrir onde a dúvida começou.
O guia para avaliar um piloto com uma planilha portátil ajuda a registrar entrada, resultado esperado e observação. Use critérios definidos antes do teste e repita os casos de erro depois da correção.
Se o escopo avançar para pedido ou pagamento, abra uma etapa própria de autorização. O roteiro de definir autorização antes de conectar pagamento separa intenção, revisão e execução. Uma permissão para consultar catálogo não autoriza assumir um compromisso comercial.
Caso hipotético: embalagens com três unidades de medida
Uma fabricante fictícia de embalagens seleciona vinte produtos para o piloto. Alguns são vendidos por caixa, outros por milheiro e outros por quilograma. O objetivo é preparar o rascunho e entregá-lo ao representante da região. O sistema existente continua responsável por preço aprovado, crédito e emissão do pedido.
A equipe cria quinze casos. Em dez, os dados são suficientes; em cinco, falta dimensão, quantidade ou aplicação. Na primeira rodada hipotética, o agente prepara oito rascunhos corretos, pede esclarecimento em quatro e erra três: confunde duas unidades e encaminha uma região ao representante errado.
A decisão é bloquear expansão. A equipe padroniza unidade de venda e fator de embalagem, corrige a regra de região na origem e exige sua exibição no resumo. Não tenta compensar os erros com uma instrução longa dizendo ao modelo para ser cuidadoso.
No reteste, os quinze casos recebem o resultado esperado. A equipe acrescenta cinco casos novos em conjunto separado, incluindo mudança de estoque entre consulta e revisão. Quando a disponibilidade muda, o rascunho deve mostrar a condição atual e pedir confirmação. O teste demonstra uma regra de recuperação, sem prometer que estoque consultado será reservado.
Para continuidade, a operação compara tempo de revisão do vendedor, erros críticos, retrabalho e custo por cotação válida, sempre contra a mesma família de produtos usada no início. Se o agente economiza preenchimento mas gera dúvidas técnicas novas, o benefício pode não compensar. A análise precisa incluir o trabalho deslocado para engenharia e atendimento.
O piloto não prova aumento de vendas. Ele pode provar que rascunhos chegam com unidade correta e contexto suficiente. A ligação com conversão depende de acompanhamento comercial posterior, com coortes e condições comparáveis. Mantenha essas conclusões em relatórios distintos.
Orçamento por trabalho, com limites de manutenção
Faça a estimativa por componentes: saneamento do catálogo, integração, interface, testes, revisão técnica, operação e suporte. O prazo depende dessas condições e dos acessos disponíveis. Um roteiro de noventa dias pode organizar um projeto, mas não é garantia de conclusão para qualquer ERP ou catálogo.
| Componente | Pergunta para estimar | Critério de contenção |
|---|---|---|
| Dados | Quantos itens e atributos precisam de revisão? | Uma família de produtos no piloto |
| Integração | Já existe API mantida e autorizada? | Reutilizar leitura disponível quando adequada |
| Operação | Quem confere e resolve exceções? | Responsável e horário definidos |
| Consumo | Qual serviço e conta serão usados? | Teto por rodada e por tarefa |
| Armazenamento | O que precisa permanecer para auditoria? | Texto e metadados com retenção definida |
Em um exemplo hipotético, quarenta horas de preparação e integração a R$ 150 somam R$ 6.000; dez horas de validação a R$ 120 somam R$ 1.200. O subtotal de R$ 7.200 ainda exclui licenças, consumo, infraestrutura e suporte que forem necessários. A conta é didática, não cotação de mercado.
Compare com a alternativa sem agente: melhorar busca, formulário e catálogo. Se essa alternativa resolve a maior parte do problema com menor manutenção, ela pode ser a escolha inicial. Trocar ERP ou comércio eletrônico só entra quando a limitação demonstrada exige, com custo e benefício próprios.
Não aumente recursos de infraestrutura antes de medir o gargalo. Uma resposta lenta pode vir de consulta mal definida, documento excessivo ou repetição desnecessária. Reduza volume e corrija a causa antes de ampliar memória, tempo de execução ou dependências.
Contrato do piloto e decisão de ampliação
A decisão de ampliar precisa mostrar que o recorte atual funciona e que as exceções têm responsável. O contrato reúne as condições que devem permanecer válidas na próxima etapa.
PILOTO INDUSTRIAL
Família de produtos e público:
Tarefa permitida:
Sistema responsável por preço, estoque e crédito:
Atributos obrigatórios e unidade:
Fonte e validade de cada dado:
Operações proibidas:
Condições para pedir esclarecimento:
Critérios de encaminhamento:
Casos de teste e falhas bloqueadoras:
Custo total e teto:
Responsável por manutenção:
Evidência de conclusão:
Decisão: corrigir | manter escopo | ampliar uma operação
Aprove a ampliação quando a tarefa funciona nos casos definidos e a equipe consegue operar as exceções. A próxima etapa deve acrescentar uma capacidade de cada vez, com novo critério de aceite. Um catálogo maior, outra região ou gravação de pedido mudam o risco e exigem nova avaliação.
Registre o que ficou fora: negociação de desconto, tributação, aplicação técnica crítica ou pagamento, por exemplo. Essas exclusões protegem a clareza do contrato e ajudam o comprador a entender quando conversar com uma pessoa. Um piloto útil termina com fronteiras conhecidas, não com a declaração genérica de que a indústria está pronta para qualquer agente.
Fontes
- Portal Leadlovers: agente no funil comercial. Consulta em 6 de outubro de 2026.
- Portal Leadlovers: custo total. Consulta em 6 de outubro de 2026.
- MCP: introdução. 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.
- NLWeb: implementação de referência. Consulta em 6 de outubro de 2026.
- AGENTS.md: finalidade do formato. Consulta em 6 de outubro de 2026.