# Un agente, dodici clienti: come tenere separati brand, account e link

_2026-09-29 · Un solo agente IA per molti clienti in Shager: un workspace per cliente, cartelle di contesto, regole sui nomi e barriere contro i post nel posto sbagliato._

Un solo agente può seguire tanti clienti senza rischi, a patto che ogni cliente abbia il suo workspace in Shager, che ogni attività cominci individuando il workspace e scrivendone il nome, e che tono, informazioni e regole del cliente stiano in una cartella di contesto separata che l'agente carica a ogni sessione. Il pericolo non è che l'agente non sia all'altezza. È che una singola chiave vede tutti i workspace dell'organizzazione, quindi la separazione deve nascere dalla struttura e dalle abitudini.

L'errore che tutti temono è pubblicare l'offerta del cliente A sulle pagine del cliente B. Non è un errore tipico degli agenti: lo commettono anche le persone. Le soluzioni che seguono lo intercettano in entrambi i casi.

## Perché un workspace per cliente?

In Shager un workspace corrisponde a un cliente o a un brand. Ogni account collegato, gruppo di account, post e link tracciato vive dentro un solo workspace. Niente supera i confini di un workspace per sbaglio: una chiamata `create_post` indica un unico `workspace_id`, e i canali e i gruppi di destinazione vengono dagli elenchi di quel workspace.

Per crearne uno basta una chiamata. I campi sono `name`, un `timezone` IANA (predefinito `Asia/Jerusalem`) e `approval_required`, che impone l'approvazione del cliente prima che qualsiasi contenuto di quel workspace possa essere programmato.

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

Impostare `approval_required` cliente per cliente è il livello di dettaglio giusto. Alcuni clienti vogliono vedere ogni post. Altri hanno già approvato un piano editoriale e non vogliono venti email di approvazione a settimana. L'agente non deve ricordarsi chi è chi, perché ci pensa il workspace.

Un agente in un ambiente di prova non ancora rivendicato può creare fino a cinque workspace: abbastanza per avviare un progetto pilota con qualche cliente prima che una persona rivendichi l'organizzazione. Il flusso è descritto in [registrazione autonoma dell'agente e rivendicazione](/en/blog/agent-self-signup-and-claim).

## Collegare gli account di ogni cliente senza password

Per ogni workspace l'agente chiama `create_connect_link` con una `label` che indica a chi è destinato. Il cliente apre il link, accede di persona al social (Facebook, Instagram, YouTube, X, LinkedIn o TikTok), sceglie gli account, e quegli account compaiono in `list_channels` solo per quel workspace. Il cliente non ha bisogno di un account Shager e nessuno si scambia password.

```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"}'
```

I link di collegamento richiedono un'organizzazione rivendicata. In [link di collegamento per i clienti](/en/blog/client-connect-links) trovi cosa vede il cliente e cosa conviene inviargli insieme al link.

## La cartella di contesto: il cervello di ogni cliente

Il workspace separa i dati, non le conoscenze. Quello che l'agente sa del tono di Aurora, dei suoi prezzi e delle frasi vietate deve stare da qualche parte. Se sta in un unico, lungo file di istruzioni che contiene dodici clienti, prima o poi qualcosa trapela.

La struttura che uso io, per Claude Code o 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
      ...
```

Claude Code carica i file `CLAUDE.md` in modo gerarchico, e quelli nelle sottocartelle vengono caricati quando Claude lavora in quelle cartelle, come spiega la sua [documentazione sulla memoria](https://code.claude.com/docs/en/memory). Se avvii una sessione dentro `clients/aurora/`, l'agente riceve le regole dell'agenzia più il file di Aurora, e nulla su Beacon Dental. Codex ha una gerarchia simile con [`AGENTS.md`](https://developers.openai.com/codex/guides/agents-md), concatenati dalla radice del progetto fino alla cartella di lavoro.

La prima riga di ogni file cliente è la più importante:

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

## Le barriere contro il post nel posto sbagliato

La struttura riduce il rischio. Queste abitudini coprono il resto.

1. **Individua e ripeti.** Ogni attività inizia con `list_workspaces`, trova il cliente per nome e stampa nome e ID prima della prima scrittura. Chi scorre la trascrizione vede «Aurora Furniture (ws_aurora)» e può fermare tutto.
2. **Un cliente per sessione.** Non chiedere a un agente di «fare la settimana di Aurora e di Beacon». Due sessioni, due cartelle. Il costo in più è nullo e il contesto resta pulito.
3. **Etichette con il nome del cliente.** Ogni `create_post` ha una `label` come "Aurora w40 sofa sale". In `list_posts` e nella dashboard, un'etichetta sbagliata nel workspace sbagliato salta subito all'occhio.
4. **Una campagna per cliente.** Il campo `campaign` diventa `utm_campaign`. Mettici davanti lo slug del cliente (`aurora-sofa-sale`), così un post finito nel posto sbagliato si nota anche come riga anomala negli analytics del cliente.
5. **Una revisione separata.** Una sessione di revisione con strumenti di sola lettura confronta le bozze con l'elenco delle frasi vietate del cliente prima di qualsiasi approvazione. Il prompt è in [prompt per un agente di contenuti](/en/blog/prompts-for-a-content-agent).

## Serve una chiave API per ogni cliente?

In Shager le chiavi appartengono all'organizzazione e hanno degli ambiti: `read`, `write` e `publish`. Una chiave non limita i workspace a cui può accedere. Quindi una chiave per cliente non crea un muro invalicabile, ma aiuta comunque in due modi. Se revochi una chiave, il lavoro sulle altre non si ferma, e il registro delle chiamate degli agenti nella dashboard degli agenti è più facile da leggere quando le sessioni di ogni cliente usano una chiave propria.

Quello che non farei è dare di default una chiave `publish` a ogni sessione cliente. La maggior parte delle sessioni prepara bozze. La programmazione può avvenire con un'altra chiave, controllata da una persona. Il modello degli ambiti è spiegato in [chiavi API, ambiti e registro](/en/blog/api-keys-scopes-and-audit).

## I gruppi dentro un cliente

All'interno di un workspace, i gruppi di account permettono all'agente di indicare più account in un solo campo. Un cliente in franchising potrebbe avere gruppi per regione, per lingua o per formato di negozio. `create_group` accetta `name` e `channel_ids`; `create_post` accetta `group_ids` e aggiunge tutti i canali attivi di quei gruppi. Come tutto il resto, i gruppi appartengono a un workspace, quindi l'agente dovrebbe sempre elencarli dentro il workspace del cliente invece di riusare ID a memoria.

## Capacità e piani

I piani di Shager hanno un prezzo basato sul numero di account collegati in tutta l'organizzazione, e ogni piano include API, accesso MCP e utenti illimitati. Per un'agenzia con una dozzina di clienti, il numero da tenere d'occhio è quello degli account, non degli agenti o delle postazioni. Le fasce sono nella [pagina dei prezzi](/en/pricing).

## Domande frequenti

### Due agenti possono lavorare sullo stesso cliente contemporaneamente?

Tecnicamente sì. Entrambi vedono lo stesso workspace ed entrambi possono creare bozze. In pratica, assegna a ciascuno un compito preciso: uno scrive, l'altro rivede, oppure uno si occupa dei video e l'altro dei post di testo. Due agenti che preparano entrambi la stessa settimana producono contenuti doppi.

### E se il cliente gestisce anche lui i propri post in Shager?

Puoi aggiungerlo come utente della tua organizzazione, visto che ogni piano include utenti illimitati. Assicurati che l'agente chiami `list_posts` prima di scrivere, così vede cosa ha già programmato il cliente e non accumula post nello stesso giorno.

### Come chiudo il rapporto con un cliente?

Interrompi il lavoro dell'agente in quel workspace, annulla i post programmati con `cancel_post` e chiedi al cliente di scollegare i suoi account. Archivia la cartella di contesto fuori dalla cartella di lavoro dell'agente, così non viene caricata per errore in futuro.

## Da dove partire

Prepara subito la struttura delle cartelle, anche se hai solo due clienti. Separare a posteriori le conoscenze di dodici clienti è molto più difficile che partire puliti. Il [punto di accesso per agenti](/en/agents) contiene i dati di connessione per tutti i clienti che ti serviranno.

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