Ein Agent, zwölf Kunden: So bleiben Marken, Konten und Links sauber getrennt

Ein einzelner Agent kann problemlos viele Kunden betreuen – vorausgesetzt, jeder Kunde hat seinen eigenen Workspace in Shager, jede Aufgabe beginnt damit, den Workspace zu ermitteln und beim Namen zu nennen, und Tonalität, Fakten und Regeln des Kunden liegen in einem eigenen Kontextordner, den der Agent pro Sitzung lädt. Das Risiko liegt nicht darin, dass der Agent es nicht könnte. Es liegt darin, dass ein einziger Schlüssel jeden Workspace der Organisation sieht. Die Trennung muss also aus Struktur und Gewohnheit kommen.

Der Fehler, vor dem sich alle fürchten: Das Angebot von Kunde A landet auf den Seiten von Kunde B. Das passiert nicht nur Agenten, das passiert auch Menschen. Die folgenden Maßnahmen fangen ihn in beiden Fällen ab.

Warum ein Workspace pro Kunde?

In Shager steht ein Workspace für einen Kunden oder eine Marke. Jedes verbundene Konto, jede Kontogruppe, jeder Beitrag und jeder Tracking-Link gehört zu genau einem Workspace. Nichts überschreitet versehentlich diese Grenze: Ein create_post-Aufruf nennt genau eine workspace_id, und die Kanäle und Gruppen, auf die er zielt, stammen aus den Listen genau dieses Workspace.

Einen Workspace anzulegen ist ein einziger Aufruf. Die Felder sind name, eine IANA-timezone (Standard: Asia/Jerusalem) und approval_required. Letzteres erzwingt eine Kundenfreigabe, bevor in diesem Workspace irgendetwas geplant werden kann.

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

approval_required pro Kunde zu setzen, ist genau die richtige Ebene. Manche Kunden wollen jeden Beitrag sehen. Andere haben einen Redaktionsplan abgesegnet und wollen keine zwanzig Freigabe-Mails pro Woche. Der Agent muss sich nicht merken, wer was will – der Workspace setzt es durch.

Ein Agent in einer noch nicht übernommenen Sandbox kann bis zu fünf Workspaces anlegen. Das reicht für ein Pilotprojekt mit ein paar Kunden, bevor ein Mensch die Organisation übernimmt. Wie das abläuft, steht in Selbstregistrierung von Agenten und Übernahme.

Seitlich scrollen für das ganze Diagramm

Die Konten der Kunden einbinden – ohne Passwörter

Für jeden Workspace ruft der Agent create_connect_link mit einem label auf, das sagt, für wen der Link gedacht ist. Der Kunde öffnet den Link, meldet sich selbst beim Netzwerk an (Facebook, Instagram, YouTube, X, LinkedIn oder TikTok), wählt die Konten aus – und diese erscheinen in list_channels, aber nur für diesen Workspace. Der Kunde braucht kein Shager-Konto, und niemand teilt Passwörter.

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

Verbindungslinks setzen eine übernommene Organisation voraus. Was der Kunde zu sehen bekommt und was du ihm zusammen mit dem Link schicken solltest, erklärt Verbindungslinks für Kunden.

Der Kontextordner: das Gedächtnis jedes Kunden

Der Workspace trennt die Daten. Das Wissen trennt er nicht. Was der Agent über Auroras Tonalität, Preise und verbotene Formulierungen weiß, muss irgendwo liegen. Und wenn es in einer einzigen langen Anweisungsdatei mit zwölf Kunden steht, sickert es früher oder später durch.

Meine Struktur für Claude Code oder 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
      ...

Claude Code lädt CLAUDE.md-Dateien hierarchisch, und Dateien in Unterordnern werden geladen, sobald Claude in diesen Ordnern arbeitet – so beschreibt es die Dokumentation zum Gedächtnis. Startest du eine Sitzung in clients/aurora/, bekommt der Agent die Agenturregeln plus Auroras Datei – und nichts über Beacon Dental. Codex kennt eine ähnliche Hierarchie mit AGENTS.md, zusammengesetzt vom Projektstamm bis hinunter zum Arbeitsverzeichnis.

Die erste Zeile jeder Kundendatei ist die wichtigste:

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

Schutzmechanismen gegen Posts beim falschen Kunden

Struktur senkt das Risiko. Diese Gewohnheiten schließen den Rest der Lücke.

1. Ermitteln und ausgeben. Jede Aufgabe beginnt mit list_workspaces, findet den Kunden über den Namen und gibt Name und ID vor dem ersten Schreibzugriff aus. Wer das Protokoll überfliegt, sieht „Aurora Furniture (ws_aurora)“ und kann notfalls eingreifen.
2. Ein Kunde pro Sitzung. Bitte einen Agenten nicht, „diese Woche für Aurora und Beacon zu erledigen“. Zwei Sitzungen, zwei Ordner. Das kostet praktisch nichts, und der Kontext bleibt sauber.
3. Labels mit Kundennamen. Jeder create_post-Aufruf bekommt ein label wie „Aurora w40 sofa sale“. In list_posts und im Dashboard fällt ein falsches Label im falschen Workspace sofort auf.
4. Eine Kampagne pro Kunde. Aus dem Feld campaign wird utm_campaign. Stell das Kundenkürzel voran (aurora-sofa-sale) – dann taucht ein falsch platzierter Beitrag zusätzlich als merkwürdige Zeile in der Analyse des Kunden auf.
5. Ein separater Prüfdurchgang. Eine Prüfsitzung mit reinen Lese-Tools gleicht die Entwürfe mit der Tabu-Liste des Kunden ab, bevor irgendetwas freigegeben wird. Den Prompt dazu findest du unter Prompts für einen Content-Agenten.

Seitlich scrollen für das ganze Diagramm

Braucht jeder Kunde einen eigenen API-Schlüssel?

Schlüssel gehören in Shager zur Organisation und haben Berechtigungsstufen (Scopes): read, write und publish. Ein Schlüssel ist nicht auf bestimmte Workspaces beschränkt. Ein Schlüssel pro Kunde zieht also keine harte Mauer ein, hilft aber trotzdem zweifach: Wird ein Schlüssel widerrufen, läuft die Arbeit für die anderen Kunden weiter. Und das Audit-Log der Agentenaufrufe im Agenten-Dashboard liest sich leichter, wenn die Sitzungen jedes Kunden mit einem eigenen Schlüssel laufen.

Was ich nicht tun würde: jeder Kundensitzung standardmäßig einen publish-Schlüssel geben. Die meisten Sitzungen schreiben nur Entwürfe. Das Planen kann mit einem anderen Schlüssel laufen, den ein Mensch kontrolliert. Das Berechtigungsmodell erklärt API-Schlüssel, Scopes und Audit.

Gruppen innerhalb eines Kunden

Innerhalb eines Workspace kann der Agent über Kontogruppen mehrere Konten mit einem einzigen Feld ansprechen. Ein Franchise-Kunde hat vielleicht Gruppen nach Region, Sprache oder Filialtyp. create_group erwartet einen name und channel_ids; create_post akzeptiert group_ids und fügt jeden aktiven Kanal dieser Gruppen hinzu. Gruppen gehören wie alles andere zu einem Workspace. Der Agent sollte sie deshalb immer im Workspace des Kunden abrufen, statt IDs aus dem Gedächtnis wiederzuverwenden.

Kapazität und Tarife

Die Shager-Tarife richten sich nach der Zahl der verbundenen Konten in der gesamten Organisation. API, MCP-Zugang und unbegrenzt viele Nutzer sind in jedem Tarif enthalten. Für eine Agentur mit einem Dutzend Kunden zählt also die Zahl der Konten – nicht die Zahl der Agenten oder Lizenzen. Die Stufen findest du auf der Preisseite.

FAQ

Können zwei Agenten gleichzeitig am selben Kunden arbeiten?

Technisch ja. Beide sehen denselben Workspace, beide können Entwürfe anlegen. In der Praxis solltest du jedem eine klare Rolle geben: Einer schreibt, der andere prüft – oder einer kümmert sich um Videos, der andere um Textbeiträge. Wenn zwei Agenten dieselbe Woche entwerfen, entstehen doppelte Inhalte.

Was, wenn ein Kunde auch selbst Beiträge in Shager verwaltet?

Du kannst ihn als Nutzer zu deiner Organisation hinzufügen, denn jeder Tarif umfasst unbegrenzt viele Nutzer. Achte darauf, dass der Agent vor dem Entwerfen list_posts aufruft. So sieht er, was der Kunde bereits geplant hat, und stapelt keine Beiträge auf denselben Tag.

Wie beende ich die Zusammenarbeit mit einem Kunden sauber?

Stoppe die Arbeit des Agenten in diesem Workspace, storniere geplante Beiträge mit cancel_post und lass den Kunden seine Konten trennen. Verschiebe den Kontextordner aus dem Arbeitsverzeichnis des Agenten ins Archiv, damit er später nicht versehentlich geladen wird.

Wie es weitergeht

Richte die Ordnerstruktur zuerst ein – auch wenn du erst zwei Kunden hast. Das Wissen von zwölf Kunden nachträglich auseinanderzudröseln ist viel mühsamer, als von Anfang an sauber zu starten. Auf der Einstiegsseite für Agenten findest du die Verbindungsdaten, die du für jeden Kunden brauchst.