O histórico de `cabgo_my_mcp_usage` que o servidor da Cabgo gera registra duas dimensões que a maioria dos operadores nunca lê em conjunto. A primeira é o conteúdo: qual ferramenta o agente usou, com quais parâmetros, com qual tenant e com qual resultado. A segunda é o canal de origem: de qual cliente chegou aquela chamada. Claude Desktop, o plugin do ChatGPT, o cliente web do MCP, um script que alguém da equipe configurou diretamente contra a API. Quando só uma pessoa usa o agente a partir de um único cliente, essa segunda dimensão não tem interesse. Quando há três pessoas da equipe acessando a partir de clientes diferentes, a distribuição de canais revela algo que nenhuma tela do dashboard mostra: como cada membro da equipe realmente trabalha com a plataforma, e se o cliente que cada um escolheu está configurado para produzir resultados consistentes.

A tese deste artigo é que a distribuição de canais não é um dado técnico de backend sem valor operacional — é um diagnóstico do estado real de adoção do agente na equipe. As equipes que usam três canais diferentes para as mesmas tarefas costumam ter erros silenciosos em algum deles: chamadas que chegam sem tenantId explícito e usam o default do token sem aviso, sessões que misturam contexto de dois apps, prompts que funcionam no Claude Desktop mas produzem resultados inconsistentes no ChatGPT porque as instruções do sistema não estão sincronizadas entre os clientes. Ler essa distribuição uma vez por mês leva menos de dez minutos com o agente e permite distinguir entre uma equipe que acessa a partir de múltiplos canais de forma deliberada e uma que faz isso de forma descoordenada sem saber.

O que o campo de canal em cabgo_my_mcp_usage registra

Cada chamada que chega ao servidor MCP da Cabgo inclui um identificador de cliente no cabeçalho da requisição. Esse identificador fica registrado em `cabgo_my_mcp_usage` junto com o tenantId, a ferramenta invocada, o timestamp e o status da resposta. O campo de canal — que no registro aparece como `client_id` — assume valores como `claude_desktop`, `chatgpt_plugin`, `web_client` ou o identificador personalizado que um script de automação envia ao se autenticar. Na visão de histórico que o agente devolve ao pedir a auditoria de uso, esse campo está disponível em cada registro e pode ser agrupado, filtrado e comparado com o restante dos campos da chamada.

O que isso significa na prática é concreto: quando o agente consulta a lista de motoristas ativos, o servidor sabe se aquela requisição chegou pela sessão longa que o coordenador de turno mantém aberta no Claude Desktop, pelo plugin que o dono do negócio usa no ChatGPT para conferir uma métrica rápida pelo celular, ou pelo script que a área de análise tem configurado para exportar o fechamento do mês. O registro não avalia se o canal é o correto para a tarefa — registra o canal e deixa que a distribuição mensal conte a história sobre como a equipe realmente acessa os dados da operação.

Três canais com três padrões de uso diferentes

Em operações com mais de um membro da equipe acessando o agente, a distribuição de canais depois de um mês de uso tende a refletir três tipos de usuário com hábitos de acesso bem diferenciados. Conhecê-los não é um exercício acadêmico de segmentação — é a base para entender qual canal tem qual nível de configuração e onde há mais probabilidade de aparecer um erro silencioso.

Os três padrões de distribuição que aparecem depois do primeiro mês

Depois de um mês de operação com mais de um usuário ativo, a distribuição de canais no histórico tende a cair em um de três padrões. Os três têm implicações diferentes para a qualidade dos dados que a equipe está obtendo do servidor — e para a quantidade de trabalho de sincronização que ainda fica pendente.

Atrito oculto: quando o canal sem contexto introduz erros que ninguém liga à origem

O canal mais propenso a erros silenciosos não é o que tem menos uso — é o que tem mais variação em como diferentes membros da equipe o configuraram. Na prática, isso quase sempre é o plugin do ChatGPT. A razão é estrutural: configurar as instruções do sistema no ChatGPT exige uma ação deliberada por usuário — entrar na configuração do perfil, escrever o contexto da operação, incluir o tenantId correspondente ao papel. Quando diferentes membros da equipe têm contas diferentes do ChatGPT, cada um tem suas próprias instruções do sistema, ou nenhuma. Não há um mecanismo que propague a configuração de um perfil para outro.

O resultado mais comum em operações com três ou mais pessoas usando o agente: o coordenador principal tem o tenantId e os limiares da operação corretamente carregados nas instruções do seu perfil; o segundo coordenador, que começou a usar o plugin duas semanas depois, nunca configurou as suas. As chamadas do segundo coordenador chegam ao servidor sem tenantId explícito, o servidor usa o default do token de autenticação, e se esse default não corresponde ao tenant com o qual estão trabalhando naquele momento, os dados devolvidos são do app errado. O output tem o formato correto — uma tabela limpa, números razoáveis — e ninguém questiona até que uma métrica não bate com o que o app mostra. A essa altura, várias decisões do turno já foram tomadas com dados do tenant incorreto.

Quando padronizar um canal e quando padronizar o contexto

A resposta intuitiva ao problema de distribuição fragmentada é padronizar um único canal. Isso funciona quando todos os membros da equipe têm o mesmo tipo de tarefa com o agente. Em uma operação regional com um coordenador de turno, um supervisor e o dono do negócio, os três têm necessidades diferentes: o coordenador precisa de sessões longas com contexto acumulado; o supervisor precisa de acesso rápido a métricas específicas de onde estiver; o dono do negócio precisa do resumo diário sem atrito técnico. Obrigar os três a usar o mesmo cliente não resolve o problema — desloca o atrito para o usuário cujo fluxo não encaixa no canal padrão.

A alternativa mais eficaz não é a padronização do canal, e sim a padronização do contexto. Se todos os clientes ativos na equipe têm carregadas as mesmas instruções do sistema — o tenantId correto para cada papel, os limiares da operação, o critério de escalonamento — o canal específico deixa de ser a variável que determina a consistência. As chamadas de qualquer canal chegam ao servidor com o enquadramento que produz dados corretos. A distribuição de canais no histórico mensal se torna então o indicador de verificação: se 85% ou mais das chamadas chegam com o tenantId correto independentemente do canal, o contexto está bem replicado. Se há um canal com mais de 30% de chamadas resolvidas pelo default do token, alguém da equipe trabalha sem contexto pré-carregado, e esse é o ajuste concreto — não o canal em si.

A auditoria de canal: como ler a distribuição em dez minutos

A leitura da distribuição de canais não exige acesso direto ao backend nem relatórios especiais da plataforma. O agente pode gerar a análise com uma chamada ao histórico de `cabgo_my_mcp_usage` e um prompt bem estruturado. Na primeira vez que se roda essa análise, o objetivo é identificar três coisas: quais canais estão ativos, qual tem a taxa mais alta de chamadas sem tenantId explícito, e se essa taxa corresponde a um usuário específico ou está distribuída entre vários. Com isso já basta para determinar se há um ajuste de configuração pendente ou se a distribuição atual é deliberada e consistente.

A análise que esse prompt devolve é direta de interpretar. Um canal com 90% de chamadas com tenant explícito indica uma configuração sólida no cliente que o usa. Um canal com 40% de tenant explícito indica que quem o usa trabalha sem contexto na maior parte do tempo — não intencionalmente, mas porque as instruções do sistema nunca foram completadas ou ficaram desatualizadas quando a operação mudou de tenant ou de cidade. O ajuste posterior é sempre o mesmo: sincronizar o contexto do canal problemático com o que já funciona bem no canal principal. Esse trabalho leva entre cinco e quinze minutos por cliente, dependendo de quantos campos de contexto seja preciso copiar das instruções originais.

A distribuição de canais em `cabgo_my_mcp_usage` não é um dado técnico de backend — é o estado real de como a equipe acessa o agente. Uma equipe onde todos os clientes ativos têm o mesmo contexto carregado produz resultados consistentes independentemente do canal que cada membro prefira. Uma equipe onde a configuração foi replicada só no cliente do operador principal tem uma fonte de erros silenciosos nos canais secundários que ninguém liga ao canal até que apareça na distribuição mensal ou em um ticket de suporte com sintomas que não se conseguem replicar.

A ação concreta depois de ler a distribuição de canais não é mudar qual cliente cada membro da equipe usa — é verificar que as instruções do sistema estão sincronizadas entre todos os clientes ativos. Se o histórico mostra 30% de chamadas resolvidas pelo default do token a partir do plugin do ChatGPT, essa porcentagem tem uma solução direta: abrir a configuração de perfil do usuário nesse cliente e adicionar o contexto que já funciona no canal principal. Não é preciso migrar ninguém nem mudar hábitos de acesso. Basta garantir que o canal que cada pessoa já usa chegue ao servidor com o mesmo enquadramento que produz dados corretos. A distribuição do mês seguinte confirma se o ajuste funcionou.