Os operadores que têm táxi e delivery ativos na Cabgo costumam chegar à mesma conclusão depois das primeiras semanas com o agente: precisam de duas instâncias separadas, uma para cada app. A lógica parece sólida — são dois negócios com motoristas distintos, tarifas distintas e, em muitos casos, zonas que não se sobrepõem. O problema é que essa lógica produz um sistema desnecessariamente complicado: dois clientes de chat, dois tokens, duas bibliotecas de prompts para manter em paralelo. A tese deste artigo é que um único agente com um único skill instalado pode gerenciar ambos os verticais na mesma conversa, e que a única variável que muda entre uma tarefa de táxi e uma de delivery é o tenantId que aparece no prompt.
Este artigo é para o operador que já tem o skill da Cabgo instalado e ativou um segundo vertical na plataforma. Cobrimos como o servidor MCP resolve o tenant em cada chamada, qual é o erro mais comum em operações multi-vertical, como estruturar os prompts para que o agente saiba a todo momento com qual app está trabalhando, e um padrão que pouquíssimos operadores exploraram: as consultas paralelas que produzem um resumo comparativo de ambos os verticais em uma única resposta do agente.
Como o servidor MCP decide com qual tenant o agente está falando
O skill da Cabgo define uma hierarquia de três camadas para resolver o tenant em cada chamada. A primeira é o tenantId explícito no prompt: se o operador escreve «para o app de delivery, liste os motoristas disponíveis», o agente extrai esse contexto e o passa diretamente na chamada ao servidor. A segunda é o tenantId pré-carregado nas instruções de sistema do cliente de chat — no Claude Desktop ou nas instruções de perfil do ChatGPT, o operador pode incluir «meu tenant de táxi é [id]» como contexto fixo que o agente usa quando o prompt não especifica nada diferente. A terceira é o tenant vinculado ao token de autenticação: se nenhuma das duas camadas anteriores especifica um tenant, o servidor usa o associado ao token, que na maioria das instalações é o primeiro tenant que o operador ativou.
O perigo da terceira camada — o default silencioso do token — é que ele se ativa sem sinal visível. Em uma operação de um único vertical isso não importa porque sempre há um tenant correto. Em uma operação bi-vertical, o default pode fazer com que uma consulta de delivery aponte para o tenant de táxi sem que o agente o indique: retorna dados no formato esperado, mas do negócio errado. Esse tipo de erro é mais difícil de detectar do que um explícito porque o output parece correto na forma. A auditoria semanal do histórico de `cabgo_my_mcp_usage` é o único lugar onde esse padrão fica visível: se 90% das chamadas da semana foram ao tenant de táxi quando o operador se lembra de ter trabalhado com delivery vários dias, o desequilíbrio aponta o problema.
O erro mais comum: mudar de vertical sem mudar de tenant
A maioria dos problemas em operações multi-tenant não ocorre no início da sessão — ocorre no meio. O operador começa o chat revisando a frota de táxi e depois, na mesma conversa, pergunta sobre as zonas ativas de delivery. Essa mudança de assunto não atualiza automaticamente o tenantId que o agente usa nas chamadas seguintes: o agente mantém o contexto do tenant anterior a menos que o novo prompt o mude de forma explícita. O resultado é que o operador pergunta por zonas de delivery e recebe as do tenant de táxi — dados com a mesma aparência, mas do negócio errado.
O erro passa despercebido porque o agente não anuncia quando manteve o tenant da chamada anterior em vez de atualizar para o novo. Pode acontecer várias vezes em uma sessão longa antes de o operador notar uma discrepância — por exemplo, que o número de motoristas ativos não bate com o que ele vê no app. A essa altura, várias decisões do turno já foram tomadas com dados do tenant errado. A forma de interromper esse ciclo não é revisar cada resposta do agente com desconfiança, e sim instalar o hábito de nomear o tenant no início de cada bloco de trabalho dentro da conversa.
Estruturar os prompts para que o tenant não se perca na mudança de contexto
A solução não requer configuração técnica adicional — requer um hábito de prompt. O princípio é simples: cada vez que você muda de vertical dentro de uma conversa, a primeira mensagem do novo bloco inclui o tenant. Não como instrução especial ao agente, e sim como contexto natural: em vez de «quantos motoristas ativos o delivery tem esta tarde?», você escreve «Mudando para delivery [tenant_id]: quantos motoristas ativos ele tem esta tarde?». Duas palavras a mais são suficientes para que o agente resolva o tenant correto em todas as chamadas desse bloco. Há quatro convenções que tornam esse hábito consistente sem adicionar fricção ao trabalho diário:
- Nomear o tenant no início de cada bloco de trabalho, não só no início da sessão: uma sessão de uma hora pode ter três blocos distintos — abertura de turno no táxi, revisão de zonas no delivery, fechamento de turno no táxi — e cada um requer sua própria âncora de tenant para evitar herança de contexto
- Incluir o tenantId nos prompts salvos da biblioteca: se o operador tem um prompt de resumo de turno, salvar uma versão para táxi e outra para delivery com os tenantIds já incluídos elimina a necessidade de lembrar de adicioná-los ao usar o template
- Usar o nome do app além do ID técnico quando o contexto é novo: «Delivery [nome_app] [tenant_id]» é mais rápido de ler no meio de uma conversa do que só o ID numérico, especialmente em operações com mais de dois apps
- No fechamento de turno, especificar o tenant mesmo que seja o mesmo do default: um fechamento que nomeie explicitamente o tenant encerra o contexto da sessão sem ambiguidade e facilita a leitura posterior do histórico de `cabgo_my_mcp_usage`
Consultas paralelas: um relatório que cobre ambos os verticais em uma resposta
O padrão mais eficiente para o operador bi-vertical não é alternar entre tenants na mesma conversa, e sim pedir ao agente que faça as duas consultas em paralelo e retorne os resultados em formato comparativo. O servidor MCP da Cabgo aceita chamadas simultâneas a tenants distintos dentro do mesmo contexto de conversa — o agente pode chamar uma ferramenta de leitura duas vezes na mesma mensagem, uma por tenant, e combinar os resultados em uma tabela. Para que isso funcione, o prompt deve especificar ambos os tenants e o formato de saída esperado na mesma solicitação: «Consulte o status de frota de táxi [tenant_taxi] e delivery [tenant_delivery] em paralelo. Retorne uma tabela com colunas: vertical, motoristas ativos, corridas completadas hoje, taxa de disponibilidade no pico. Uma linha por vertical.»
O limite desse padrão é o contexto acumulado da sessão: se o chat leva várias horas de trabalho com um dos tenants, a consulta paralela pode produzir um resultado enviesado para esse tenant porque ele tem mais histórico no contexto do que o outro. Esse viés não aparece como erro explícito — aparece como assimetria nos dados: as métricas do tenant dominante têm mais detalhe do que as do secundário. A auditoria semanal do histórico de `cabgo_my_mcp_usage` o detecta como uma distribuição de tenantIds desbalanceada na semana, e é o sinal para ajustar quando a consulta paralela é lançada ou para dividi-la em sessões separadas quando a diferença de contexto entre tenants é grande.
Campanhas por vertical com verificação cruzada
Uma das vantagens do agente único multi-tenant é que o contexto de um vertical pode informar decisões do outro. O caso mais claro é o das campanhas de demanda: se o operador considera lançar um bônus de delivery para um fim de semana com evento na cidade, a disponibilidade histórica do táxi nesse mesmo período é relevante. Se a frota de táxi esteve com 65-70% de disponibilidade nos últimos três fins de semana semelhantes e há motoristas que operam em ambos os serviços, ativar um bônus de delivery que desloque esses motoristas pode criar um déficit de oferta no táxi que nenhum dos dois apps antecipa separadamente. Com dois agentes distintos, essa verificação cruzada requer consultas manuais a ambos os clientes. Com um agente multi-tenant, o prompt pode pedi-la explicitamente antes de propor os parâmetros do bônus.
A forma de incluir essa verificação no prompt de desenho de campanha é direta: «Antes de propor os parâmetros do bônus de delivery, consulte a disponibilidade histórica de táxi [tenant_taxi] nos mesmos horários durante as últimas quatro semanas. Se a disponibilidade caiu abaixo de 70% em algum desses períodos, ajuste o limite do bônus de delivery para não competir por motoristas que já estavam cobertos pelo serviço de táxi.» Essa instrução condicional dá ao agente o critério para calibrar o incentivo entre ambos os verticais em vez de desenhá-lo como se o outro app não existisse. Não é uma funcionalidade especial do servidor — é o resultado direto de ter os dois tenants disponíveis no mesmo contexto de conversa.
Quando faz sentido, sim, separar os agentes
A tese do agente único tem exceções concretas. A primeira é a escala de equipe: se o operador tem dois coordenadores distintos — um para táxi e outro para delivery — e cada um usa o agente de forma independente, faz sentido dar-lhes tokens separados e agentes separados, não por razões técnicas, mas de responsabilidade operacional. Misturar as sessões de dois coordenadores sob o mesmo tenant torna o histórico de `cabgo_my_mcp_usage` difícil de interpretar quando é preciso determinar quem executou qual ação e quando. Dois agentes com tokens distintos produzem históricos que atribuem as ações ao coordenador correto.
A segunda exceção é a geografia: se táxi e delivery operam em cidades distintas e não compartilham motoristas nem zonas, o benefício das consultas cruzadas é baixo e o custo de especificar o tenant em cada prompt é constante. Nesse caso, dois agentes com o contexto de cidade fixo em suas instruções de sistema são mais simples de operar do que um agente multi-tenant que requer especificação explícita em cada bloco de trabalho. A regra prática: um agente por operador quando os dois negócios compartilham motoristas ou zonas; dois agentes quando os papéis humanos ou as geografias são completamente distintos e o contexto cruzado não agrega valor real.
Passei dois meses com um chat para táxi e outro para delivery porque presumia que o agente iria se confundir se eu misturasse os dois apps na mesma conversa. Quando entendi como o tenantId funciona, consolidei tudo em uma única sessão fixa no Claude Desktop. A única coisa que mudei foi adicionar o nome do app e o tenant no início de cada bloco de prompts. Agora levo menos tempo revisando o status dos dois verticais do que levava antes para trocar entre janelas.
O resumo diário multi-tenant: um prompt para dois negócios
O caso em que a gestão multi-tenant no mesmo agente mais se justifica é o resumo diário. Em vez de revisar dois apps separadamente toda manhã, o operador pode ter um único prompt salvo que produz o status de ambos os verticais em uma resposta estruturada. O prompt tem que fazer três coisas: especificar ambos os tenants, pedir as mesmas métricas de cada um para que a comparação seja direta, e pedir formato tabular em vez de narrativo. Um exemplo funcional: «Resumo do turno de hoje. Para táxi [tenant_taxi] e delivery [tenant_delivery]: motoristas ativos agora, corridas completadas nas últimas 12 horas, avaliação média da semana, e uma linha de alerta se alguma métrica estiver fora da faixa dos últimos 7 dias. Retorne uma tabela com os dois verticais nas linhas e as quatro métricas nas colunas.» Salvo como instrução de sistema ou na biblioteca de prompts, esse template substitui a revisão manual dos dois apps toda manhã.
Gerenciar dois verticais a partir do mesmo agente não é uma otimização técnica — é a forma direta de aproveitar que o agente tem acesso a ambos os contextos ao mesmo tempo. O tenantId no prompt é o mecanismo de controle, e o hábito de nomeá-lo no início de cada bloco de trabalho é a única diferença entre um agente que retorna dados corretos e um que os mistura em silêncio. Se você tem táxi e delivery ativos e ainda usa dois chats separados, a ação concreta esta semana é revisar os prompts salvos e adicionar o tenant explícito em cada um — duas ou três palavras por template é o custo dessa mudança. O histórico de `cabgo_my_mcp_usage` vai lhe mostrar uma distribuição de tenantIds que reflete como você realmente usa os dois apps, em vez de uma concentração no default que indica que a especificação se perdeu em algum ponto da sessão.
