À la fin, un chat Claude lance l'un de vos Graphs osFoundry enregistrés, ces programmes d'agents en plusieurs étapes qui se ramifient, se répartissent en parallèle et réessaient, et l'exécution a lieu sur votre propre ordinateur, ni dans Claude ni sur un serveur. Claude reçoit tout de suite un ticket, vérifie où en est le run pendant que l'ordinateur travaille, puis répond avec le résultat du Graph. Si vous changez d'avis en cours de route, Claude peut l'annuler.
Qui fait quoi
| Côté Claude | Côté osFoundry | |
|---|---|---|
| Connexion | Votre compte Claude, inchangé | La connexion que vous avez approuvée, ajoutée à un projet |
| Ce qu'il voit | Nom, description, slug, version et statut de chaque session de Graph partagée | Le programme du Graph, ses agents et vos fichiers restent sur l'ordinateur |
| Quels Graphs | Choisit parmi list_graph_sessions
|
Uniquement les sessions que vous avez cochées pour ce projet dans l'app de bureau |
| Où ça s'exécute | Nulle part. Claude ne fait que mettre en file et lire | Sur votre ordinateur, qui récupère le run en file et l'exécute en local |
| Attente | Appelle get_graph_run jusqu'à un statut final |
Renvoie un seul résultat borné à la fin du run |
| Validations | La demande d'autorisation d'outil de Claude avant run_graph_session
|
Les outils réglés pour demander à chaque fois sont refusés pendant le run ; personne n'est là pour cliquer |
Mise en place
On part du principe que le connecteur Claude existe déjà (icône de clé → Connected → Add assistant, puis https://api.osfoundry.io/api/v1/external-mcp ajouté comme connecteur personnalisé dans Claude).
1. Avoir une session de Graph enregistrée sur l'ordinateur
Les Graphs vivent sur l'appareil. Vous les écrivez ou les modifiez via Maestro, un agent ou osStudio, et chacun, une fois enregistré, reçoit un ID de session de la forme gs_ suivi de 32 caractères hexadécimaux. L'écran Graph de l'app de bureau les liste. Un Graph que vous n'avez vu que dans le navigateur ne peut pas être partagé, car le navigateur ne peut pas l'exécuter.
Exemple : l'écran Graph de l'application de bureau avec des sessions Graph enregistrées
2. Ajouter la connexion Claude à un projet
Dans icône de clé → Connected, sélectionnez la connexion Claude. Sous Projects, choisissez un projet et cliquez sur Add to project (ajouter au projet). Ce projet est le seul endroit où Claude cherchera des Graphs.
Exemple : La section Projects d'une connexion Claude, avec un projet ajouté
3. Partager la session de Graph dans ce projet
Plus bas dans le même onglet Connected, uniquement dans l'app de bureau, se trouve une section appelée Share desktop Graph sessions (partager les sessions de Graph du bureau). Chaque projet dont vous êtes propriétaire y figure, avec les sessions de Graph enregistrées sur cet appareil sous forme de cases à cocher :
Share desktop Graph sessions
Choose the saved Graph sessions to share with each project, then enable that project.
Your desktop must be open and signed in.
Launch plan · workspace [ Share selected Graphs ]
[x] Weekly KPI digest
[ ] Release notes draft
Exemple : Share desktop Graph sessions avec une session cochée pour un projet
Cochez d'abord les sessions, puis cliquez sur Share selected Graphs. Si rien n'est coché, l'app vous arrête avec "Choose at least one Graph session for this project first." Partager un projet ne partage pas tous les Graphs de l'appareil. Chaque session est une décision à part, projet par projet.
4. Laisser l'app de bureau ouverte
L'app de bureau vérifie toutes les 20 secondes si des runs attendent dans le projet, et immédiatement quand vous modifiez ce qui est partagé. Si l'app est fermée, la demande de Claude attend dans la file jusqu'à sa réouverture.
5. Demander à Claude
In osFoundry, run the Weekly KPI digest Graph in the Launch plan project
for week 2026-W45, and tell me the three biggest changes.
Un vrai run
Le projet, le Graph et les chiffres ci-dessous sont des données d'exemple. Les noms d'outils et d'arguments sont ceux que le serveur en production liste dans tools/list. Dans Claude Code, les mêmes outils apparaissent sous la forme mcp__osfoundry__run_graph_session et ainsi de suite.
Exemple
Claude → list_granted_resources {}
← projects: Launch plan
Claude → list_graph_sessions {"project_id": "<Launch plan>"}
← Weekly KPI digest (gs_3f…, weekly-kpi-digest v3, ready)
Release notes draft n'apparaît pas : il n'a jamais été coché
Claude → run_graph_session {"graph_session_id": "gs_3f…",
"arguments": {"week": "2026-W45"},
"idempotency_key": "kpi-2026-w45-a"}
[Claude vous demande d'autoriser cet appel d'outil → Allow]
← command_id "8c1e…", status queued
Claude → get_graph_run {"command_id": "8c1e…"}
← queued (l'ordinateur n'a pas encore interrogé le serveur)
Claude → get_graph_run {"command_id": "8c1e…"}
← running
Claude → get_graph_run {"command_id": "8c1e…"}
← completed
result: {"execution_id": "GR-0007L", "status": "completed",
"result": {...}, "total_tokens": 18412, "reported_cost": 0.07}
Claude : Semaine 45 : inscriptions +18 %, passage essai-payant en baisse de 9.1 % à 7.4 %,
et les tickets de support ont doublé après la release de mardi.
Le premier get_graph_run qui répond queued n'est pas un retard du côté de Claude. Rien n'est poussé vers votre ordinateur. C'est lui qui demande du travail au serveur, et jusqu'à sa prochaine vérification, le run attend simplement. Une fois récupéré, l'ordinateur exécute le Graph avec la même commande que l'écran Graph, puis renvoie le résultat. Ce que Claude lit en dernier, c'est ce résultat renvoyé, pas un flux en direct.
Le run est aussi classé sous le projet Launch plan sur l'ordinateur. Le contexte du projet et la recherche dans l'historique des chats pendant le run se limitent à ce projet, rien de plus large.
Pour l'arrêter, Claude appelle cancel_graph_run avec le même command_id. Un run encore en file est annulé purement et simplement et ne démarre jamais. Un run en cours reçoit une demande d'annulation, que l'ordinateur vérifie toutes les 3 secondes et transmet au Graph en cours d'exécution.
Où passe la limite
Le Graph ne quitte pas l'appareil. list_graph_sessions ne renvoie que des métadonnées : nom, description, slug, version et statut. Claude ne voit jamais le script, les agents qu'il appelle ni les fichiers qu'ils touchent. C'est aussi pour ça que Claude passe des arguments sans voir de schéma. Décrivez les entrées dans la description du Graph si vous voulez que Claude les remplisse correctement.
L'exécution revient à l'ordinateur, parce que les agents du Graph, les modèles locaux, les dossiers et les réglages de validation s'y trouvent tous. Le serveur ne garde que la file et le résultat final. Si l'ordinateur est hors ligne, les runs en file l'attendent. Claude ne peut pas les envoyer ailleurs.
Pendant le run, personne ne regarde. Les outils réglés pour demander à chaque fois sont refusés au lieu d'afficher une demande, car une demande à laquelle personne ne répond bloquerait le run pendant des minutes avant d'échouer de toute façon. Les outils qui ne demandent rien s'exécutent normalement. Si un Graph dépend d'un outil que vous validez à la main, lancez ce Graph vous-même depuis l'écran Graph.
Ce qui revient est borné. Le résultat contient l'ID du run, le statut, le résultat, le nombre de tokens et le coût déclaré, et seulement si cela tient dans 100,000 caractères de JSON. Un résultat plus gros revient sous forme d'ID et de statut avec result_truncated: true, et l'enregistrement complet reste dans l'historique des runs sur l'ordinateur. Les erreurs sont coupées à 2,000 caractères.
Seul l'agent qui a lancé un run peut le lire ou l'annuler. Une autre connexion qui demande le même command_id reçoit "Graph run not found or access removed", la même réponse que pour un ID qui n'existe pas.
Le partage peut être annulé à tout moment avant le démarrage du run. Si vous décochez la session ou cliquez sur Stop sharing (arrêter le partage) pendant qu'un run est en file, l'ordinateur revérifie avant d'exécuter et l'annule avec "Graph session is no longer shared with this project".
Pour la suite
Partagez un petit Graph, demandez à Claude de le lancer, puis cliquez sur Stop sharing tant qu'il est encore en file et regardez Claude signaler l'annulation. La façon dont osFoundry répartit le travail entre agents est décrite sur la page d'orchestration Maestro, et la liste des connexions elle-même sur la page Connected.



Top comments (0)