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

_2026-09-29 · Como uma agência usa um só agente de IA para vários clientes no Shager: um workspace por cliente, pastas de contexto, regras de nome e travas contra erros._

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.

```json
{
  "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](/en/blog/agent-self-signup-and-claim).

## 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.

```bash
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](/en/blog/client-connect-links) 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:

```text
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](https://code.claude.com/docs/en/memory). 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`](https://developers.openai.com/codex/guides/agents-md), concatenado da raiz do projeto até a pasta de trabalho.

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

```text
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](/en/blog/prompts-for-a-content-agent).

## 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](/en/blog/api-keys-scopes-and-audit).

## 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](/en/pricing).

## 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](/en/agents) tem os dados de conexão de que você vai precisar para cada cliente.

---
Source: https://shager.ai/pt/blog/one-agent-many-clients