Cas métier multi-agents : optimiser la diffusion GAM (forecast + formats)

Jusqu'ici, un agent. Passons à un vrai cas métier ad-ops multi-agents : estimer le potentiel de diffusion et recommander des formats pour le CTR, en parallèle, puis fusionner le tout en un plan actionnable — le tout en lecture seule, via les vrais outils OrbiAds.

L'architecture

Trois agents, orchestrés par l'ADK :

SequentialAgent("gam_optimizer")
├─ ParallelAgent("specialists")          # async
│  ├─ forecast_agent   -> output_key = "forecast_result"
│  └─ format_agent     -> output_key = "format_result"
└─ synthesis_agent     # reads {forecast_result?} + {format_result?}

forecast_agent

Estime le potentiel d'impressions (trafic / forecast).

format_agent

Calcule le CTR par taille et signale les tailles héritées.

synthesis_agent

Fusionne en un plan : potentiel → formats → tailles à abandonner.

Piège ADK : le templating d'instruction {var} est strict et lève un KeyError si la clé d'un sous-agent n'est pas encore présente. Utilisez la forme optionnelle {var?}.

L'honnêteté avant le remplissage

Sur un réseau de test sans trafic, il n'y a pas de CTR à calculer. Un bon prompt fait répondre l'agent « donnée manquante » plutôt qu'inventer. C'est ce que montre la trace : le forecast est « non chiffrable » faute de données, et le format_agent remonte les vrais freins GAM au lieu de fabriquer un résultat.

Multi-agents async : forecast ∥ format → synthèse — Multi-agents asynchrone : deux spécialistes en parallèle (forecast ∥ format/CTR) → un agent de synthèse. Un livrable métier composé.

Les vrais freins GAM (à connaître)

AD_REQUEST_SIZES est incompatible avec IMPRESSIONS/CLICKS dans le rapport historique par défaut.
Le paramètre dateRange n'est pas accepté tel quel par run_custom_report — l'agent s'adapte et le signale.
Les tailles responsive/fluid remontent en width=0/height=0 : ce ne sont pas des tailles obsolètes, et l'agent ne les confond pas.

La discipline de prompt

Le multi-agent ne vaut que si chaque agent est fiable. Les règles qui font la différence : nommer l'action exacte de l'outil, interdire les noms d'outils inventés et les placeholders entre crochets, exiger un chiffre réel ou l'absence explicite de donnée, et n'appeler que des outils en lecture seule. On ajoute un NETWORK CHECK pour ne jamais lire un réseau de production par erreur. Le modèle, lui, reste un choix : c'est l'approche qu'on valide, pas un modèle précis.

La suite

Dernier épisode : faire parler le standard d'achat AdCP à un agent — valider et prévisualiser un media buy GAM, toujours en lecture seule.

Questions fréquentes

Comment faire tourner plusieurs agents en parallèle puis fusionner ?

Avec l'ADK : un SequentialAgent enchaîne un ParallelAgent (qui lance les spécialistes en async) puis un agent de synthèse. Chaque spécialiste écrit son résultat dans un output_key ; la synthèse les lit via un templating optionnel {var?} pour éviter un KeyError si une clé manque encore.

Que fait l'agent si l'inventaire de test n'a pas de données ?

Il le dit. Sur un réseau sans trafic, il n'y a pas de CTR à calculer : un prompt bien écrit fait répondre « donnée manquante » au lieu d'inventer un chiffre ou des placeholders. L'honnêteté du livrable prime sur le remplissage.

Quels freins GAM réels rencontre-t-on sur le reporting par format ?

Deux concrets : la dimension AD_REQUEST_SIZES est incompatible avec IMPRESSIONS/CLICKS dans le type de rapport historique par défaut ; et les tailles d'inventaire « responsive » remontent en width=0/height=0 — ce sont des formats fluides, pas des tailles obsolètes.

Comment éviter que le LLM invente des outils ou des chiffres ?

Par la discipline de prompt : nommer l'action exacte, interdire les noms d'outils inventés et les placeholders entre crochets, exiger un chiffre réel ou l'absence explicite de donnée, et n'appeler que des outils en lecture seule. On ajoute aussi un NETWORK CHECK pour ne jamais lire un réseau de production par erreur.

Cas métier multi-agents : optimiser la diffusion GAM