Studio agentique via MCP

Décision en une phrase

Le composeur de Claude, ChatGPT ou d’un autre agent peut devenir l’interface de création ; Orbit reste le contexte, l’autorité et le moteur d’exécution ; Studio reste la capacité créative ; MCP reste un port mince vers ces capacités.

Nous ne construisons pas un nouvel éditeur vidéo pour rendre Studio agentique. Nous ne transformons pas non plus Orbit en simple proxy vers Veo, Seedance, Kling ou un autre fournisseur.

L’objectif est qu’un utilisateur puisse connecter Orbit une fois, puis demander dans son agent habituel :

Crée une vidéo de lancement de 25 secondes pour ce projet. Utilise le contexte de la marque, montre le vrai produit et garde un rythme premium.

L’agent orchestre. Orbit exécute. L’utilisateur ne doit pas avoir à choisir un provider, gérer une timeline, écrire un prompt technique ou comprendre Remotion.

État réel au 2 octobre 2026

La fondation nécessaire existe déjà dans le runtime Orbit :

• le MCP public est disponible sur https://orbit.easyconnector.app/api/mcp avec OAuth 2.1 + PKCE et clés orb_… ;
• le Brain expose déjà contexte, recherche et écriture gouvernée ;
• le MCP sait déjà lister et lire les projets Studio ;
• Studio possède un moteur commun de génération image, vidéo, voix et composition ;
• les vidéos longues passent par des jobs asynchrones ;
• les générations payantes passent par le ledger et l’idempotence ;
• le moteur sait router plusieurs modèles vidéo, dont Veo, Seedance et Kling ;
• Product Visual Context fournit un Visual IR à partir du produit réellement rendu ;
• Cinema conserve une horloge et un mouvement déterministes ;
• Remotion reste le compositeur déterministe actuel ;
• le QC doit juger l’artefact final, en particulier le MP4 réellement rendu.

La lacune n’est donc plus « trouver un moteur vidéo ». La lacune est une frontière de capability headless suffisamment propre pour que l’UI Studio, MCP, REST et de futurs agents internes appellent la même exécution.

Expérience cible

L’expérience externe doit rester conversationnelle.

Utilisateur
  ↓
Claude / ChatGPT / agent MCP
  ↓
Orbit MCP
  ↓
Studio capability
  ↓
job asynchrone
  ↓
asset + QC
  ↓
agent
  ↓
éventuelle révision

Exemple :

1. l’utilisateur demande une vidéo dans Claude ;
2. Claude lit le projet et, si nécessaire, le contexte des Spaces liés ;
3. Claude appelle une capability de création Studio avec une intention compacte ;
4. Orbit crée un run durable, applique les permissions, le ledger et l’idempotence, puis lance le pipeline ;
5. Claude vérifie le statut ;
6. Orbit renvoie l’asset final et les findings QC ;
7. Claude peut accepter le résultat ou demander une révision ciblée sans demander à l’utilisateur de manipuler un éditeur.

Le cockpit Studio web reste une surface de premier niveau. Il n’est pas supprimé. Il devient simplement une interface parmi plusieurs pour le même moteur.

Répartition des responsabilités

L’agent hôte est le creative director

Claude, ChatGPT ou un autre agent doit pouvoir décider :

• l’angle créatif ;
• le hook ;
• la structure narrative ;
• ce qui mérite d’être montré ;
• le ton ;
• les priorités entre plusieurs messages ;
• si une révision est nécessaire après lecture du QC ou inspection du rendu.

L’agent ne doit pas piloter des détails d’infrastructure comme un provider précis, un callback, une clé Blob ou des paramètres FFmpeg.

Orbit possède le contexte et l’autorité

Orbit décide et garantit :

• quels Spaces et projets le credential peut lire ;
• quel contexte est autorisé ;
• les permissions relues en base ;
• l’isolation du workspace ;
• les limites et scopes ;
• le ledger, les holds, settlements et refunds ;
• l’idempotence ;
• la provenance et les write-backs futurs.

Le Brain reste la source de contexte canonique. Studio ne recrée pas de mémoire parallèle.

Studio possède l’exécution créative

Studio transforme l’intention en production :

• récupération du contexte utile ;
• Visual IR et preuves visuelles du produit ;
• plan de scènes ;
• génération des assets nécessaires ;
• voix et médias optionnels ;
• Cinema ;
• composition déterministe ;
• rendu ;
• QC ;
• asset final ;
• observation exploitable par le Brain.

Les providers restent des adapters

Veo, Seedance, Kling, un futur modèle vidéo ou un moteur de voix sont des dépendances remplaçables.

Le contrat externe ne doit pas devenir :

generate_with_veo()
generate_with_kling()
generate_with_seedance()

Il doit rester centré sur l’intention :

studio_create()
studio_revise()

Changer de provider ne doit pas casser le contrat MCP.

Architecture cible

La frontière MCP est volontairement mince. Elle ne contient ni logique de génération, ni logique de coût, ni logique de planning créatif.

Une capability headless avant de nouveaux tools

Le prochain invariant à obtenir est :

Tout geste Studio important peut s’exécuter sans dépendre d’un composant React, d’un état du Composer ou d’un handler spécifique au navigateur.

Un nom d’architecture possible est runCapability(). Ce nom n’est pas un contrat livré ; il illustre la frontière recherchée.

runCapability({
  capability: "studio.create",
  actor,
  intent,
  projectId,
  context,
  idempotencyKey
})

L’UI Studio, MCP et REST doivent appeler cette même frontière, directement ou via un service commun.

Studio UI ─┐
MCP ───────┼─→ capability service → engine → ledger/jobs/assets
REST ──────┤
Agent ─────┘

Il faut éviter quatre implémentations parallèles de la même création.

Surface MCP cible minimale

La V1 agentique doit exposer le moins de tools possible.

studio_create

Crée une production à partir d’une intention.

Entrées conceptuelles :

• projectId ;
• prompt ou intent ;
• références facultatives ;
• contraintes de sortie facultatives comme durée et ratio.

Sortie initiale :

• runId ;
• état ;
• résumé de ce qui a été lancé.

Ce tool ne doit pas demander au client de choisir Veo, Kling, Remotion ou une route interne.

studio_status

Lit l’état d’un run long.

Il doit permettre à l’agent de savoir si le travail est :

• queued ;
• running ;
• waiting ;
• completed ;
• failed.

Le MCP actuel ne stream pas ; le polling explicite est donc la primitive la plus robuste pour commencer.

studio_get_asset

Récupère le résultat exploitable d’un run ou un asset connu.

La réponse doit pouvoir inclure :

• métadonnées de l’asset ;
• URL ou handle de lecture autorisé ;
• durée, format et ratio ;
• lineage utile ;
• findings QC structurés ;
• contact sheet ou previews lorsque la surface cliente sait les consommer.

Le tool doit rester utile même lorsqu’un client MCP ne sait pas afficher directement une vidéo : les findings QC doivent donc être structurés et lisibles par un agent.

studio_revise

Révise un asset ou un run à partir d’une instruction naturelle.

Exemples :

• « plus énergique » ;
• « coupe à 22 secondes » ;
• « montre davantage le produit » ;
• « le passage vers 00:12 est trop lent » ;
• « garde la structure mais rends le hook plus direct ».

La révision doit réutiliser le lineage et les assets existants autant que possible au lieu de tout régénérer.

Ce qui n’est pas nécessaire

Il ne faut pas créer orbit_get_context : brain_get_context existe déjà.

Il ne faut pas non plus exposer immédiatement des dizaines de tools bas niveau. Des fonctions telles que génération d’un clip, synthèse de voix, capture d’une frame ou rendu Remotion restent des détails de l’exécution tant qu’un use case externe ne justifie pas de les rendre publics.

Scopes cibles

Les scopes actuels restent inchangés tant que les tools créatifs ne sont pas livrés.

Lorsque la création Studio sera exposée, la séparation cible est :

projects:read reste un scope de métadonnées projet ; il ne doit pas devenir implicitement un droit de génération.

Comme pour le Brain, aucun scope n’en implique un autre.

Brain et contexte persistant

La différence entre un simple générateur vidéo et Orbit est le contexte durable.

Un agent peut déjà lire :

• Identity ;
• Guidelines ;
• Knowledge ;
• Items ;
• People ;
• projets Studio et Spaces liés.

À terme, Studio doit recevoir un Context Pack borné pour l’intention, plutôt que le Brain entier.

Le flux cible est :

intent
→ project
→ allowed Space bindings
→ Context Engine
→ minimal Context Pack
→ Studio capability

Le contexte doit rester sourcé, borné et permissionné.

Product Visual Context : vrais pixels d’abord

Pour les vidéos produit, l’agent ne doit pas réinventer l’interface.

Le pipeline cible conserve la décision Product Visual Context :

page réellement rendue
→ RawVisualSnapshot
→ Visual IR
→ sections / surfaces / texte utile / bounding boxes
→ sélection des scènes
→ captures ciblées

Le modèle décide quoi montrer et pourquoi.

Le runtime déterministe décide où se trouve réellement l’élément, comment le cadrer et comment le rendre dans le temps.

Cette séparation permet à un agent créatif d’être ambitieux sans inventer des pixels produit faux.

Planning créatif vs planning déterministe

Le premier Scene Planner déterministe reste une bonne fondation.

La séparation cible est :

Un agent peut enrichir ou orienter un plan, mais la validité technique du film ne doit pas dépendre de lui.

La boucle de self-review

L’amélioration qualitative la plus importante n’est pas un nouvel éditeur. C’est une boucle où le résultat est jugé après rendu.

studio_create
→ render
→ QC sur MP4
→ studio_get_asset
→ agent lit le QC / inspecte les previews
→ décision
→ studio_revise
→ render
→ QC
→ final

Le QC déterministe peut déjà ou pourra vérifier notamment :

• safe zones ;
• frames presque vides ;
• contact sheet ;
• pacing mesurable ;
• lisibilité ;
• seam de boucle ;
• durée ;
• conformité de format ;
• cohérence entre l’asset demandé et l’artefact livré.

Un agent multimodal peut ensuite interpréter ces preuves et décider si la création est créativement satisfaisante.

Ne pas imposer une clé Anthropic à Orbit

Le modèle hôte peut être Claude, ChatGPT ou un autre client. Orbit ne doit pas obliger l’utilisateur à fournir une seconde clé LLM uniquement pour orchestrer la création.

Le chemin préféré est :

• l’agent externe raisonne ;
• Orbit exécute et mesure ;
• Orbit renvoie des preuves/QC ;
• l’agent externe décide de la prochaine action.

Un critic multimodal serveur pourra exister plus tard comme capability optionnelle derrière le moteur, mais il ne doit pas devenir une dépendance structurelle du MCP.

Boucle automatique, mais bornée

« L’utilisateur n’a rien à faire » ne doit jamais signifier « dépenses non bornées ».

Toute boucle automatique doit respecter :

• le ledger Studio ;
• les plafonds déjà en place ;
• l’idempotence ;
• un nombre d’itérations borné ;
• un budget maximal ou une politique de coût ;
• l’arrêt immédiat si une amélioration ne justifie plus une nouvelle génération.

Par défaut, une seule révision automatique est plus sûre qu’une boucle ouverte.

Jobs asynchrones

Une production complète peut déclencher plusieurs générations puis un rendu. Elle ne doit pas garder une requête MCP ouverte pendant toute la durée du travail.

Le pattern cible est :

studio_create
→ { runId, status: "queued" }

studio_status
→ { status: "running", progress... }

studio_status
→ { status: "completed", assetId }

studio_get_asset
→ asset + QC

Il faut réutiliser les primitives de journal, jobs, callbacks et sweep existantes.

Si une production multi-étapes nécessite une enveloppe de workflow durable au-dessus de plusieurs StudioGeneration, créer la plus petite abstraction possible. Ne pas dupliquer le ledger ni le lifecycle de jobs.

Remotion reste un détail d’implémentation

Il n’y a aucune raison de remplacer Remotion pour livrer cette capacité.

Le contrat externe devient :

agent
→ Orbit
→ Studio capability
→ Cinema / generation / compositor
→ asset

Si, plus tard, un autre moteur de composition devient meilleur, il peut remplacer ou compléter Remotion derrière cette frontière.

Le MCP, les scopes et l’expérience utilisateur ne doivent pas changer pour cette raison.

C’est précisément pourquoi le bon investissement est la capability boundary, pas la recherche permanente d’un « meilleur Remotion ».

Ce que nous ne construisons pas

Cette décision exclut explicitement :

• un clone de Premiere Pro ;
• une timeline obligatoire pour les clients MCP ;
• une nouvelle UI uniquement pour piloter l’agent ;
• un sélecteur public de providers ;
• un Video MCP générique qui ne ferait que relayer des APIs tierces ;
• une logique métier dupliquée dans mcp-tools.ts ;
• une mémoire Studio parallèle au Brain ;
• un nouveau ledger ;
• une runtime vidéo supplémentaire sans besoin démontré ;
• une dépendance obligatoire à un LLM serveur pour rendre un film valide.

Ordre d’implémentation

1. Frontière headless — isoler un service/capability commun pour les gestes de création et de révision.
2. Run durable — réutiliser les jobs existants ; ajouter une enveloppe multi-étapes seulement si nécessaire.
3. Create / status / asset — rendre la création appelable hors UI.
4. Revise — permettre une révision naturelle avec lineage.
5. QC enrichi — renvoyer des findings structurés et des previews exploitables.
6. Scopes Studio — introduire studio:read et studio:write avec consentement OAuth et clés orb_….
7. Tools MCP — brancher les quatre tools sur la capability commune, sans logique de génération dans l’adapter MCP.
8. Parité REST — exposer la même capability à l’API pour éviter une dépendance MCP.
9. Boucle agentique bornée — permettre à Claude/ChatGPT d’enchaîner inspection et révision avec garde de coût.
10. Learning — transformer les verdicts utiles en observations puis Memory Proposals gouvernées.

Critères de sortie

La première version est considérée saine si :

• une création complète peut être lancée sans ouvrir /studio ;
• le même service de création est utilisé par l’UI et MCP ;
• le credential ne peut agir que dans son workspace ;
• une création et une révision passent par le ledger existant ;
• le même idempotency key ne provoque pas un second appel payant ;
• un run long est récupérable après coup ;
• le provider choisi n’apparaît pas dans le contrat public par défaut ;
• le produit réel est capturé via Visual Context lorsqu’il doit être montré ;
• le QC travaille sur l’artefact final ;
• une révision peut réutiliser le lineage existant ;
• aucune boucle automatique n’est illimitée ;
• Remotion peut rester ou être remplacé sans breaking change MCP.

Avantage produit

Le moat recherché n’est pas « avoir accès au dernier modèle vidéo ».

Les modèles vont changer rapidement.

L’actif durable est la combinaison :

Brain / contexte
+ goût et skills
+ preuves visuelles du vrai produit
+ orchestration
+ exécution déterministe
+ QC
+ learning

Orbit devient ainsi moins un « générateur vidéo » qu’une capacité créative persistante que n’importe quel agent autorisé peut utiliser.