Du brief client aux publications en ligne : une semaine entière menée par un agent, appel par appel
Une semaine client dans Shager, pas à pas : brief, import des médias, brouillons par compte, relecture, validation client, programmation, contrôle et rapport.
Pour passer d'un brief client à des publications en ligne avec un agent, il faut huit étapes : confirmer l'accès et l'espace de travail, vérifier les comptes connectés, importer les médias, planifier, rédiger avec des légendes par compte, relire, obtenir la validation du client, puis programmer et contrôler. À chaque étape, l'agent abat le travail de volume. Un humain prend trois décisions : valider le plan, accorder le droit de publier et, quand le client le souhaite, apporter la validation du client lui-même via un lien de validation.
Voici une semaine réaliste pour un client fictif, avec chaque appel Shager que fait l'agent, dans l'ordre. Le client, Harbor Coffee, compte 14 cafés, chacun avec une Page Facebook et un compte professionnel Instagram, plus une chaîne YouTube pour la marque.
Lundi matin : le brief arrive
Le chargé de compte dépose un brief dans le dossier de contexte du client : une nouvelle boisson d'automne, un lancement jeudi, 20 % de réduction le premier week-end, une vidéo verticale de 25 secondes et deux photos hébergées sur le CDN du client. Rien d'autre. Les instructions permanentes de l'agent lui interdisent d'inventer quoi que ce soit qui ne figure pas dans le brief : la réduction, la date et le nom du produit sont les seuls faits qu'il utilisera.
La session démarre dans le dossier du client : l'agent a donc chargé les règles de l'agence et le fichier de ton de Harbor Coffee, et rien qui concerne d'autres clients. Pourquoi c'est important, c'est l'objet de un agent, plusieurs clients.
Étape 1 : confirmer qui et où
whoami -> organization, claimed or sandbox, key scopes
list_workspaces -> "Harbor Coffee" (ws_harbor), timezone Europe/London
whoami répond à deux questions avant tout travail : cette organisation est-elle revendiquée, et la clé a-t-elle publish ? S'il s'agit d'une sandbox non revendiquée, l'agent peut quand même importer et rédiger, mais la programmation et les demandes de validation échoueront avec une erreur explicite tant qu'un humain ne l'aura pas revendiquée. La procédure de revendication est décrite dans /auth.md.
Étape 2 : vérifier les comptes
list_channels ws_harbor -> 29 channels: 14 Facebook, 14 Instagram, 1 YouTube
list_groups ws_harbor -> "All cafes FB", "All cafes IG", "Brand YouTube"
L'agent examine le statut de chaque canal. Un compte Instagram apparaît déconnecté. Plutôt que de rédiger sans lui en silence, l'agent crée un lien de connexion pour le responsable de ce café :
{
"tool": "create_connect_link",
"arguments": { "workspace_id": "ws_harbor", "label": "Harbor Quayside, Instagram reconnect" }
}
Le chargé de compte transfère le lien. Le responsable du café se connecte à Instagram par ce lien, sans compte Shager, et le compte réapparaît dans list_channels dans la journée.
Étape 3 : importer les médias
Trois appels, un par fichier. La vidéo est accompagnée de ses dimensions et de sa durée, pour que la validation des Reels et des Shorts se fasse dès maintenant plutôt qu'au moment de publier.
{
"tool": "upload_media_from_url",
"arguments": {
"workspace_id": "ws_harbor",
"url": "https://cdn.harbor-coffee.example/autumn/launch.mp4",
"file_name": "autumn-launch.mp4",
"width": 1080, "height": 1920, "duration_ms": 25000
}
}
Les deux photos sont importées de la même manière, sans les champs propres à la vidéo.
Étape 4 : planifier, puis attendre
L'agent propose un plan au lieu de rédiger tout de suite :
| Jour | Publication | Format | Cible |
|---|---|---|---|
| Mar. | Photo teaser | FEED | All cafes FB, All cafes IG |
| Jeu. | Vidéo de lancement | REEL / SHORT | All cafes FB, All cafes IG, Brand YouTube |
| Sam. | Photo de rappel de la réduction | FEED | All cafes FB, All cafes IG |
Le chargé de compte répond « go », en avançant la publication du samedi au vendredi après-midi. Un seul message, et un plan bancal ne se transforme jamais en 85 légendes par compte.
Étape 5 : rédiger avec des légendes par compte
Chaque publication prévue devient un appel create_post sans schedule_at, ce qui enregistre un brouillon. La publication de lancement montre la structure complète :
{
"tool": "create_post",
"arguments": {
"workspace_id": "ws_harbor",
"group_ids": ["grp_all_fb", "grp_all_ig", "grp_brand_yt"],
"media_ids": ["med_launch"],
"caption": "The autumn drink is here. 20% off this weekend.",
"youtube_title": "Harbor Coffee autumn drink, first pour",
"youtube_privacy": "public",
"cta_url": "https://harbor-coffee.example/autumn",
"campaign": "autumn-launch",
"label": "Harbor autumn launch video",
"first_comment": "Find your nearest Harbor and the weekend offer: https://harbor-coffee.example/autumn",
"per_channel": [
{ "channel_id": "ch_fb_quayside", "format": "REEL",
"caption": "Quayside regulars, it's here. Autumn's first pour, 20% off this weekend." },
{ "channel_id": "ch_ig_quayside", "format": "REEL",
"caption": "First pour at Quayside. 20% off all weekend, details in bio." },
{ "channel_id": "ch_yt_brand", "format": "SHORT",
"caption": "The new Harbor autumn drink, poured for the first time." }
]
}
}
Dans l'appel réel, per_channel contient 29 entrées, chaque légende ancrée dans son café. Au moment de la publication, chaque URL des légendes et des commentaires devient un lien court propre au compte, avec utm_content qui identifie le compte : l'agent écrit donc des URL brutes. L'art de varier les légendes est expliqué dans varier les légendes par compte avec l'IA.
Étape 6 : relire dans une passe séparée
Une seconde session, qui exécute un prompt de relecteur avec des outils en lecture seule, appelle list_posts avec status à DRAFT, puis get_post sur chaque publication. Elle traque les légendes en double, les faits absents du brief, les liens placés là où ils ne seront pas cliquables et les formats vidéo appliqués à des médias non verticaux. Cette fois, elle signale deux légendes Instagram qui disent « lien ci-dessous » alors que le lien est dans la bio. L'agent de rédaction les corrige en créant des brouillons rectifiés, et les anciens sont écartés de la programmation.
Étape 7 : validation client
L'espace de travail de Harbor Coffee a approval_required activé : rien ne peut être programmé tant que le client n'a pas validé. L'agent envoie chaque brouillon en validation :
{
"tool": "request_approval",
"arguments": {
"workspace_id": "ws_harbor",
"post_id": "pst_launch",
"reviewer_name": "Dana, Harbor Coffee marketing",
"reviewer_email": "dana@harbor-coffee.example",
"send_email": true
}
}
Le client ouvre le lien, relit la publication et la valide sans se connecter. Le statut de la publication passe par IN_REVIEW puis APPROVED, ou CHANGES_REQUESTED : dans ce cas, l'agent révise et soumet à nouveau. La conception de bonnes règles de validation est traitée dans la validation humaine des publications d'agents.
Étape 8 : programmer et contrôler
Une fois la validation obtenue, l'étape de programmation s'exécute avec une clé qui possède le scope publish. L'agent calcule chaque horaire dans le fuseau de l'espace de travail, avec le décalage correspondant à cette date :
{
"tool": "schedule_post",
"arguments": {
"workspace_id": "ws_harbor",
"post_id": "pst_launch",
"schedule_at": "2026-10-15T08:30:00+01:00"
}
}
Avec 14 comptes sur Facebook et 14 sur Instagram, et l'échelonnement par défaut de 30 à 90 secondes, l'envoi prend environ 13 minutes par réseau, les deux réseaux tournant en parallèle. Jeudi à 9 h 15, l'agent appelle get_post. Vingt-huit comptes apparaissent publiés, avec leurs URL en ligne. Un seul affiche une erreur d'autorisation. L'agent signale le compte par son nom et propose un nouveau lien de connexion ; il ne relance pas à l'aveugle.
Le lundi suivant : le rapport
La semaine se clôt sur le rapport : list_posts pour ce qui est parti, get_post pour le résultat compte par compte, et get_analytics pour les clics par compte et par publication sur la semaine, rapprochés des prospects du CRM via utm_content quand le client les partage. La mise en place complète, y compris l'exécution sans surveillance, est décrite dans le rapport client hebdomadaire par un agent.
Qui a fait quoi
| Étape | Agent | Humain |
|---|---|---|
| Accès et espace de travail | Vérifie et le confirme | |
| Comptes | Repère le compte défaillant, crée le lien | Transfère le lien |
| Médias et plan | Importe, propose | Dit « go » |
| Brouillons et relecture | Rédige 85 légendes, les relit | |
| Validation | Envoie les liens | Le client valide |
| Programmation | Calcule les horaires, programme | A accordé publish une fois |
| Diffusion et rapport | Contrôle, rend compte | Lit le rapport |
FAQ
Combien de temps une telle semaine prend-elle à un humain ?
Dans cet exemple, les décisions humaines se résument à quelques messages et une validation. Le temps exact dépend du client et du nombre d'allers-retours sur le plan. Ce qui change, c'est la nature du travail : relire et décider, au lieu de taper des légendes et de fabriquer des liens.
L'agent peut-il se passer de la validation client pour les publications courantes ?
Seulement si l'espace de travail ne l'exige pas. approval_required se règle par espace de travail : un client qui valide un plan mensuel peut le désactiver, tandis qu'un client prudent le garde activé. L'agent ne peut pas modifier seul ce réglage pour un espace de travail existant.
Et si le client demande des modifications après validation ?
Si la publication n'a pas commencé à partir, l'agent appelle cancel_post, qui la ramène à l'état de brouillon validé, puis crée une version corrigée et la renvoie en validation. Une fois la publication lancée, les modifications sur les réseaux eux-mêmes se font à la main.
Pour aller plus loin
Déroulez cette séquence sur un client avec un petit groupe de comptes avant de l'appliquer partout. Si votre agent n'est pas encore connecté, la page d'accueil des agents présente le serveur MCP, l'API REST et l'auto-inscription.
