RUNTIME DE PIPELINES AGENTIQUES · AGPL-3.0

Un kernel. Une opinion.

Studio exécute des pipelines d'agents IA via configuration YAML. Open source, déclaratif, piloté par le retry. C'est volontaire.

Lire le cas GitHub ↗

code-generation.contract.yamlYAML

# code-generation.contract.yaml
name: code-generation
output_schema
  type: object
  required: [files_written, summary]
  properties
    files_written
      type: array
    summary
      type: string
tool_calls
  minimum: 1
  required
    - repo_manager.write_file
# Anti-theatre: runner tracks actual calls.

La thèse

Et si l'orchestration d'agents était de la configuration, pas du code ?

Trois prémisses partagées avec d'autres frameworks. Trois inversées par Studio.

Un pipeline est un fichier YAML

Déclare les stages et les groupes. Chaque stage référence un agent (config runtime) et un contrat (JSON schema + contraintes). Modifiable sans environnement de programmation, ligne par ligne.

Le moteur exécute via la boucle RALPH

Exécuter → valider → avancer si le contrat passe, retry avec feedback enrichi si ça échoue. Aucun stage n'avance tant que son contrat n'est pas satisfait.

Lancez-le 10 fois, obtenez 10 sorties correctes

C'est pourquoi les contrats et les retries existent. Anti-théâtre par construction — l'agent ne peut pas sauter les étapes que le contrat exige.

Trade-offs

Trade-offs explicites.
Pas accidentels.

LangGraph, CrewAI, Autogen partagent une prémisse : l'orchestration d'agents est du code. Studio prend la prémisse inverse et l'assume.

Framework	Surface	Validation	Parallélisme	Licence
LangGraph	Code Python	Manuelle	Natif	MIT
CrewAI	Code Python	Manuelle	Natif	MIT
Autogen	Code Python	Manuelle	Natif	CC BY 4.0
studio:	Config YAML	Par contrat	Déclaratif	AGPL-3.0

Si votre besoin correspond aux trois premiers, pas besoin d'écrire Studio. Sinon, vous écrivez un fichier YAML consultable ligne par ligne, modifiable sans environnement de programmation.

Pourquoi Studio existe

Trois patterns.

Tout est déclaratif. Vous décrivez ce que vous voulez en YAML, le moteur gère l'orchestration. Wiki Creator et Little Chef s'appuient dessus en production.

Pattern 01

Groupes de génération et validation

Un stage produit, un autre critique. Si le critique rejette, le groupe redémarre avec le feedback accumulé. Max N itérations. Anti-théâtre appliqué à la créativité.

wiki-creator.pipeline.yamlYAML

# wiki-creator.pipeline.yaml
groups
  - id: generate-critique
    max_iterations: 3
    stages
      - id: generate
          agent: wiki-writer
          contract: wiki-page
      - id: critique
          agent: wiki-reviewer
          contract: qa-review
          context
            include: [previous_stage_output]

Pattern 02

Groupes parallèles

Fan-out / fan-in déclaré en YAML. Les stages tournent en concurrence. Le moteur gère async/await et le merge.

wiki-creator.pipeline.yamlYAML

# wiki-creator.pipeline.yaml
stages
  - id: research-en
    agent: researcher
    parallel_group: research
  - id: research-fr
    agent: researcher
    parallel_group: research
  - id: merge
    agent: merger
    context
      include: [all_stage_outputs]

Pattern 03

Vérification des appels d'outils

Le runner suit les appels d'outils. Si le contrat exige repo_manager.write_file minimum 1 et que l'agent n'en appelle aucun, le stage échoue. Anti-théâtre.

code-generation.contract.yamlYAML

# code-generation.contract.yaml
name: code-generation
output_schema
  type: object
  required: [files_written, summary]
tool_calls
  minimum: 1
  required
    - repo_manager.write_file
# Agent cannot skip writing — anti-theatre.

Architecture

Sept packages, un monorepo. Chacun tient dans une fenêtre de contexte.

Le graphe de dépendances est l'architecture.

@studio/contracts

Types et interfaces partagés. Zéro dépendances.

@studio/anonymizer

Détection et anonymisation de données personnelles avant les appels LLM.

@studio/ralph

Exécuter, valider, retry. Exécuteur générique.

@studio/runner

Appels LLM, runtime de plugins d'outils, multi-fournisseur.

@studio/engine

Orchestration de pipelines, machine d'état, persistance.

@studio/api

API REST HTTP (Fastify) + streaming SSE.

@studio/cli

Interface terminal pour les pipelines Studio.

Construit sur Studio

Deux domaines. Zéro code d'orchestration.

Wiki Creator

Extrait entités, relations, génère des pages wiki depuis des livres EPUB. Pipelines NLP + LLM.

NLPEPUBPythongroupes parallèles

github.com/…/wiki-creator ↗

Little Chef

Planificateur de repas. Recherche des cuisines, développe des recettes avec profil nutritionnel, génère des listes de courses.

Next.jsPrismanutritionmulti-stage

Voir la démo ↗

Pourquoi un commons

Pourquoi un commons, pas une startup.

Studio aurait pu être une startup. La forme du produit s'y prête. Le choix inverse est délibéré. Un kernel d'orchestration d'agents IA, capturé par une entreprise, devient le goulot d'étranglement de tout ce qui le traverse. Studio est conçu pour ne pas pouvoir être capturé.

Lire la charte

Trois mécanismes structurels

Licence AGPL-3.0

Toute modification utilisée en production doit être publiée sous la même licence.

Fondation à but non lucratif (en cours)

Le kernel est destiné à appartenir à une fondation à but non lucratif, non transférable. Le retrait progressif de la fondatrice est un objectif explicite.

Trois couches strictement séparées

Kernel open source (commons) · Support core (hébergement, maintenance) · Produits propulsés par Studio (commerciaux ou open source). Aucune entité commerciale n'a autorité sur le kernel.

Le kernel est un commons par conception. La licence est le mécanisme qui le maintient.

Le code est ouvert. Les opinions aussi.

github.com/studio-foundation/studio Lire la mission