Um agente, doze clientes: como evitar que marcas, contas e links se misturem

Um único agente pode atender muitos clientes com segurança, desde que cada cliente tenha seu próprio workspace no Shager, toda tarefa comece identificando o workspace e dizendo o nome dele, e a voz, os fatos e as regras do cliente fiquem numa pasta de contexto separada, que o agente carrega a cada sessão. O risco não é o agente ser incapaz. É que uma única chave enxerga todos os workspaces da organização, então a separação precisa vir da estrutura e do hábito.

O erro que todo mundo teme é publicar a oferta do cliente A nas páginas do cliente B. Isso não é exclusividade de agentes: operadores humanos também cometem. As soluções abaixo pegam o erro nos dois casos.

Por que um workspace por cliente?

No Shager, um workspace é um cliente ou uma marca. Cada conta conectada, grupo de contas, post e link rastreável fica dentro de exatamente um workspace. Nada atravessa essa fronteira por acidente: uma chamada a create_post indica um único workspace_id, e os canais e grupos de destino vêm das listas daquele workspace.

Criar um workspace é uma chamada só. Os campos são name, um timezone IANA (o padrão é Asia/Jerusalem) e approval_required, que exige a aprovação do cliente antes que qualquer coisa naquele workspace possa ser agendada.

{
  "tool": "create_workspace",
  "arguments": {
    "name": "Aurora Furniture",
    "timezone": "Europe/London",
    "approval_required": true
  }
}

Definir approval_required por cliente é a granularidade certa. Alguns clientes querem ver cada post. Outros já aprovaram um plano de conteúdo e não querem receber vinte e-mails de aprovação por semana. O agente não precisa lembrar quem é quem, porque o próprio workspace garante isso.

Um agente em um ambiente de teste ainda não assumido pode criar até cinco workspaces, o suficiente para montar um piloto com alguns clientes antes que uma pessoa assuma a organização. O fluxo está em cadastro feito pelo agente e transferência para uma pessoa.

Role para o lado para ver o diagrama inteiro

Como trazer as contas de cada cliente sem pedir senhas

Para cada workspace, o agente chama create_connect_link com um label que diz para quem é o link. O cliente abre o link, entra na rede por conta própria (Facebook, Instagram, YouTube, X, LinkedIn ou TikTok), escolhe as contas, e elas aparecem em list_channels apenas naquele workspace. O cliente não precisa de conta no Shager e ninguém compartilha senha.

curl -s https://app.shager.ai/api/v1/workspaces/ws_aurora/connect-links \
  -H "Authorization: Bearer $SHAGER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"label":"Aurora marketing manager"}'

Links de conexão exigem uma organização já assumida. O artigo sobre links de conexão para clientes mostra o que o cliente vê e o que enviar junto com o link.

A pasta de contexto: onde mora o cérebro de cada cliente

O workspace separa os dados. Não separa o conhecimento. O que o agente sabe sobre o tom da Aurora, os preços e as frases proibidas precisa ficar em algum lugar, e se isso estiver num único arquivo longo de instruções com doze clientes dentro, vai vazar.

A estrutura que eu uso, para Claude Code ou Codex:

agency/
  CLAUDE.md                 # agency-wide hard rules, no client facts
  clients/
    aurora/
      CLAUDE.md             # workspace name, voice, facts, do-not-say list
      brief-2026-w40.md
      crm/leads.csv
    beacon-dental/
      CLAUDE.md
      ...

O Claude Code carrega os arquivos CLAUDE.md de forma hierárquica, e os arquivos em subpastas são carregados quando o Claude trabalha nessas pastas, como explica a documentação de memória. Iniciar uma sessão dentro de clients/aurora/ dá ao agente as regras da agência mais o arquivo da Aurora, e nada sobre a Beacon Dental. O Codex tem uma hierarquia parecida com o AGENTS.md, concatenado da raiz do projeto até a pasta de trabalho.

A primeira linha de cada arquivo de cliente é a mais importante:

Shager workspace: "Aurora Furniture". Act on this workspace only. If any tool
call would use a different workspace_id, stop and ask.

Travas que pegam o post no cliente errado

A estrutura reduz o risco. Estes hábitos fecham o resto da brecha.

1. Identifique e repita. Toda tarefa começa com list_workspaces, encontra o cliente pelo nome e mostra o nome e o ID antes da primeira escrita. Uma pessoa passando o olho na conversa vê "Aurora Furniture (ws_aurora)" e consegue interromper.
2. Um cliente por sessão. Não peça a um agente para "fazer a semana da Aurora e da Beacon". Duas sessões, duas pastas. O custo extra é zero e o contexto fica limpo.
3. Labels com o nome do cliente. Todo create_post leva um label como "Aurora w40 sofa sale". Em list_posts e no painel, um label errado no workspace errado salta aos olhos na hora.
4. Uma campanha por cliente. O campo campaign vira o utm_campaign. Use o slug do cliente como prefixo (aurora-sofa-sale), assim um post fora do lugar também aparece como uma linha estranha no analytics do cliente.
5. Uma revisão separada. Uma sessão revisora, só com ferramentas de leitura, confere os rascunhos contra a lista de frases proibidas do cliente antes de qualquer aprovação. O prompt está em prompts para um agente de conteúdo.

Role para o lado para ver o diagrama inteiro

Cada cliente deve ter a própria chave de API?

No Shager, as chaves pertencem à organização e têm escopos: read, write e publish. Uma chave não limita quais workspaces ela alcança. Então ter uma chave por cliente não cria uma barreira de verdade, mas ajuda de duas formas: revogar uma chave não interrompe o trabalho nas outras, e o registro de auditoria das chamadas do agente, no painel de agentes, fica mais fácil de ler quando as sessões de cada cliente usam a própria chave.

O que eu não faria é dar uma chave com publish para toda sessão de cliente por padrão. A maioria das sessões só cria rascunhos. A etapa de agendamento pode usar outra chave, controlada por uma pessoa. O modelo de escopos está explicado em chaves de API, escopos e auditoria.

Grupos dentro de um cliente

Dentro de um workspace, os grupos de contas permitem que o agente mire um conjunto de contas com um único campo. Um cliente com franquias pode ter grupos por região, por idioma ou por formato de loja. create_group recebe um name e channel_ids; create_post aceita group_ids e inclui todos os canais ativos desses grupos. Os grupos pertencem a um workspace como todo o resto, então o agente deve sempre listá-los dentro do workspace do cliente, em vez de reaproveitar IDs de memória.

Capacidade e planos

Os planos do Shager são cobrados pelo número de contas conectadas em toda a organização, com API, acesso por MCP e usuários ilimitados em todos os planos. Para uma agência com uma dúzia de clientes, o número que importa é o de contas, não o de agentes ou de usuários. As faixas estão na página de preços.

Perguntas frequentes

Dois agentes podem trabalhar no mesmo cliente ao mesmo tempo?

Tecnicamente, sim. Os dois enxergam o mesmo workspace e os dois podem criar rascunhos. Na prática, dê a cada um um papel claro: um escreve, o outro revisa, ou um cuida dos vídeos e o outro dos posts de texto. Dois agentes escrevendo a mesma semana vão gerar conteúdo duplicado.

E se o cliente também gerencia os próprios posts no Shager?

Ele pode entrar como usuário na sua organização, já que todo plano inclui usuários ilimitados. Garanta que o agente chame list_posts antes de escrever, para ver o que o cliente já agendou e não empilhar posts no mesmo dia.

Como encerrar o trabalho com um cliente?

Pare o trabalho do agente naquele workspace, cancele os posts agendados com cancel_post e peça ao cliente para desconectar as contas. Arquive a pasta de contexto fora da pasta de trabalho do agente, para que ela não seja carregada por engano mais tarde.

Próximos passos

Monte a estrutura de pastas primeiro, mesmo com dois clientes. Separar o conhecimento de doze clientes depois é muito mais difícil do que começar organizado. A página para agentes tem os dados de conexão de que você vai precisar para cada cliente.