Traga seu próprio Claude ou use o do cliente?

Se você gerencia vários projetos de clientes em paralelo, provavelmente já se deparou com essa bifurcação em algum momento.

Quando você entrega trabalho ao Claude, você mantém um Claude seu e conecta os sistemas de cada cliente a ele? Ou você trabalha dentro de um Claude que cada cliente fornece?

Eu só fiz a primeira opção. Não era que eu não tivesse ouvido falar da segunda. Eu cheguei ao Claude como desenvolvedor, para desenvolvimento de aplicativos, e nesse mundo o ambiente de cada cliente já está separado como um repositório local. Um segundo Claude não é necessário lá — ele só atrapalharia. Mas hoje em dia eu faço mais do que desenvolvimento, e isso mudou as coisas.

A: Traga seu próprio Claude

Você possui uma assinatura do Claude e conecta as contas do Google Drive, Slack, Notion e Miro de seus clientes a ele.

Nessa configuração, você normalmente usaria o aplicativo desktop do Claude. Não há razão para se esforçar para trabalhar no navegador.

Dentro do Claude, os Projetos mantêm o contexto de cada engajamento separado: o histórico, como você gosta que as instruções sejam escritas, o material de referência. Cada um permanece dentro de seu próprio projeto, o que na prática é separação suficiente.

E como é o aplicativo desktop, você obtém o conjunto completo de recursos do Claude. Trabalhar com arquivos locais, controlar seu computador, enviar instruções do seu telefone. Esses são os recursos que tornam um agente digno de receber trabalho.

Há exatamente uma coisa que machuca. Um conector do Claude mantém uma conta por serviço. Se o Google Drive do Cliente A está conectado e você tenta adicionar o do Cliente B, você desconecta o do Cliente A. Portanto, sempre que dois clientes usam o mesmo SaaS, cada troca significa ou refazer essa configuração, ou desistir de deixar o Claude tocar nisso e colocar um humano no meio — em vez de o Claude ler um documento diretamente do drive, alguém o baixa e cola. Funciona. Também é uma sequência constante de pequenos passos irritantes.

B: Um Claude separado por cliente

Aqui você é convidado a trabalhar no espaço de trabalho do cliente e trabalha dentro dele. Para manter cada Claude do cliente separado, isso na prática significa usar o Claude no navegador e executar um perfil do Chrome separado por cliente.

Com B, o problema de A simplesmente desaparece. As contas do Claude são separadas, então não importa quanto sobreposição de SaaS haja entre os clientes. O Claude do Cliente A obtém o Google Drive do Cliente A, o Claude do Cliente B obtém o Google Drive do Cliente B. É só isso.

Você também pode deixar o cliente arcar com o custo. Não é um grande valor por mês, mas é melhor na conta deles do que na sua.

A administração também passa para o cliente. Eles emitem a conta e a revogam, então quando o engajamento termina, o acesso é cortado no mesmo dia. E os dados de nenhum cliente nunca caem em uma conta sua.

Uma coisa que vale a pena corrigir: as pessoas às vezes descrevem isso como "os dados ficam dentro do inquilino do cliente". Isso não é preciso. Em A e B, os dados estão no ambiente da Anthropic. O que B muda é apenas quem administra a conta.

Então, B é melhor? Não exatamente.

Você perde o conjunto completo de recursos do Claude. Arquivos locais, controle do seu computador, instruções do seu telefone — esses assumem o aplicativo desktop e não estão disponíveis no navegador. O Claude no Chrome lerá a aba que você já tem aberta usando apenas o navegador, mas fazer o Claude operar o Chrome para você está fora de questão.

Trazer sua própria cadeia de ferramentas também se torna mais difícil. O que é conectado ao Claude do cliente não é sua decisão. A ferramenta de anotações de reunião que você sempre usa, os servidores MCP que você escreveu, as ferramentas que você carrega em cada engajamento — cada uma se transforma em uma conversa de "por favor, me deixe instalar isso", e se a resposta for não, essa parte de como você trabalha desaparece. Você pode acabar fazendo o trabalho em um ambiente que nunca aproveita todo o poder do agente.

E dia a dia, o trabalho se torna pular entre perfis do Chrome.

Sobre o único problema de A

Eu optei por A, e o único e verdadeiro problema era o limite um-para-um do conector. "Você não pode conectar o Google Drive do Cliente B enquanto o do Cliente A está conectado" — essa era a coisa que eu queria resolver. Então eu construí algo que mantém uma única conexão com o Claude enquanto agrupa várias contas por trás dela. Eu o lancei como ProxyLoom.

Você pode manter os Google Drives do Cliente A, Cliente B e Cliente C conectados ao mesmo tempo. Nada para reconectar, então a etapa de configuração em cada troca desaparece. Instruções que abrangem engajamentos — "puxe a ata da semana passada do Google Drive do Cliente A e trabalhe nela no deck do Cliente C" — passam como escrito.

Ainda há uma coisa que não resolve: Claude no Chrome. O ProxyLoom lida com as conexões que passam pelo MCP, mas o Chrome que um único desktop do Claude pode controlar é limitado a um perfil. Isso vem de como uma extensão de navegador funciona, então nenhuma camada externa pode consertar isso. A solução parece que virá de outro lugar. O aplicativo desktop do Claude Code já envia um navegador embutido, e a OpenAI foi tão longe a ponto de aposentar o Atlas e reintegrar suas capacidades de volta ao aplicativo desktop do ChatGPT e a uma extensão do Chrome. Uma vez que a automação do navegador viva dentro do aplicativo e possa manter logins lá, a premissa de que você só tem um perfil do Chrome deixa de se aplicar.

Encerramento

Nenhuma das respostas está errada. Mas se você apoia vários clientes em paralelo e ainda não notou essa bifurcação, vale a pena refletir sobre isso uma vez. Após três engajamentos ou mais, a escolha começa a aparecer.

Se você está do lado A e cansado de reconectar conectores, experimente ProxyLoom. Ainda está em beta aberto, e estou ativamente aceitando solicitações.

ProxyLoom para Consultoria