Expérience d'IA

J'ai invité mon agent IA à Romergo, et je ne sais pas ce que c'est ni comment l'appeler.

La plupart des intégrations d'IA dans les applications sont conçues de manière prévisible. Le produit ajoute un bouton Spark, envoie une requête à son propre modèle et affiche la réponse dans la barre latérale.

Il existe une autre option courante. L'application fournit un serveur MCP et l'utilisateur ouvre ChatGPT, Claude ou un autre agent et lui demande de travailler avec les données de l'application. Cela donne à l’agent de bons outils, mais la conversation se déroule ailleurs. Vous devez quitter l'éditeur, expliquer ce qui est actuellement ouvert, revenir en arrière et vérifier le résultat.

J'en ai eu marre de basculer entre le chat et l'éditeur, et une idée m'est venue : et si je pouvais éviter complètement cela ?

J'ai ajouté un panneau IA directement dans l'éditeur, mais je ne l'ai pas connecté à un modèle hébergé par Romergo. Au lieu de cela, l'utilisateur invite son agent IA personnel à participer à la session ouverte.

L'agent reste là où il réside déjà : dans ChatGPT, Claude, Codex ou un autre client compatible MCP. Il conserve son modèle, son abonnement, sa mémoire, ses paramètres et les outils disponibles. Romergo fournit uniquement un espace de travail, un contexte actuel et des outils spécialisés pour éditer un projet.

Après s'être connecté, l'utilisateur peut écrire à l'agent directement depuis Builder :

• décrire la scène ouverte ;
• changer la musique dans ce chapitre ;
• réécrivez le dialogue surligné ;
• mettre un arrière-plan différent ;
• vérifier la logique de transition ;
• explique pourquoi la scène ne fonctionne pas comme je m'y attendais.

Les réponses, questions et statuts intermédiaires sont renvoyés vers le même panel. Le panneau affiche non seulement le texte, mais également l'ensemble du cycle de la tâche : une commande a été reçue, assignée à un agent, des outils sont en cours d'exécution, une confirmation est requise, le travail est terminé ou une erreur s'est produite. Vous n'avez plus besoin de quitter l'éditeur.

Cela a commencé comme une expérience

Je n’avais pas l’intention d’inventer un nouveau protocole ou de proposer une nouvelle catégorie de produits. Je voulais tester une idée simple : un agent utilisateur personnel pourrait-il non seulement contrôler Romergo en externe via MCP, mais également rejoindre temporairement une session en direct dans l'éditeur ?

La première version était une expérience. À ma grande surprise, cela a suffisamment bien fonctionné pour que je puisse commencer à l'utiliser moi-même.

Le diagramme le plus court peut être dessiné comme ceci :

Personal AI agent  <->  MCP  <->  Romergo Builder

Mais le signe dans les deux sens est important.

Un appel MCP typique démarre chez l'agent : l'agent décide de contacter l'application et appelle son outil. Dans mon expérience, Romergo peut également lancer des travaux. L'utilisateur écrit une commande dans Builder, Romergo la place dans un canal sécurisé et l'agent déjà connecté reçoit la commande via MCP.

L'agent utilise ensuite les outils Romergo habituels pour lire ou modifier le projet et renvoie le résultat à Builder par le même canal.

Cela crée une boucle fermée :

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

Romergo n'exécute le modèle à aucune de ces étapes.

En même temps, je n'ai pas modifié le MCP lui-même et je n'y ai pas ajouté de véritable push serveur. Du point de vue du protocole, tous les appels sont toujours initiés par l'agent. La direction inverse est implémentée comme une boîte aux lettres sécurisée : Builder écrit la commande sur le canal et l'agent l'attend via l'outil MCP à interrogation longue habituelle. Ensuite, l'agent renvoie l'événement en utilisant le même appel d'outil habituel.

Le comportement bidirectionnel apparaît au niveau de la session application, et non via un nouveau transport MCP. Cette distinction est importante : la mise en œuvre actuelle est mieux comprise comme un petit contrat de session construit au-dessus des appels MCP standard.

Comment un agent entre dans une session

Builder crée un code de canal temporaire. L'utilisateur copie une courte invite de démarrage dans son chat AI avec quelque chose comme ceci :

Rejoignez ma chaîne Romergo Builder. Exécutez chaque nouvelle commande une fois, renvoyez le résultat ou la question à Builder et continuez d'attendre jusqu'à ce que je vous demande explicitement d'arrêter.

L'agent appelle ensuite l'outil MCP romergo_join_builder_channel et transmet le code. Il s'agit d'une poignée de main : Romergo vérifie la session OAuth, le propriétaire du canal et sa date d'expiration, puis renvoie l'état de la conversation et le dernier curseur de commande.

Ensuite, l'agent appelle romergo_wait_for_builder_command. Il s'agit d'une interrogation longue qui attend la prochaine commande de l'éditeur. Si rien n'arrive, l'agent enregistre le curseur et recommence à attendre. Si la commande existe, elle contient :

• texte d'instructions ;
• identifiant de commande ;
• séquence monotone;
• chemin actuel dans Builder ;
• ID du projet, du chapitre et de la scène ouverts, lorsqu'ils se trouvent dans l'URL ;
• type de surface de l'éditeur et temps de capture du contexte ;
• texte sélectionné par l'utilisateur, le cas échéant.

Tout le contexte joint est marqué comme contenu d’application non fiable. Il s'agit de données de travail et non d'une continuation de l'instruction de contrôle de l'agent.

L'agent effectue la tâche à l'aide des outils Romergo MCP existants. Par exemple, il peut lire le projet et le chapitre, rechercher des ressources, modifier la scène, puis vérifier le résultat enregistré.

Pendant qu'il fonctionne, l'agent peut appeler romergo_report_builder_event et envoyer au panneau :

• status - statut intermédiaire court ;
• question - une question sans réponse à laquelle il n'est pas prudent de continuer ;
• reply — résultat final ;
• error - une description claire de l'erreur.

La réponse est liée à commandId et la commande suivante est lue à partir de la dernière séquence traitée. Lors de sa première émission, l'API attribue atomiquement la commande au client client_id OAuth. Un autre agent connecté ne pourra pas reprendre la même tâche en même temps. Le curseur permet de continuer après un délai d'attente ou une reconnexion, et les confirmations uniques d'appels d'outils spécifiques sont protégées par une empreinte digitale d'argument et ne peuvent pas être réutilisées pour une autre action.

Les droits appartiennent à la salle, pas à l'invite

Avant de se connecter, l'utilisateur voit les paramètres du canal et sélectionne ce que l'agent est autorisé à faire : lire le projet, modifier le contenu, travailler avec les médias et l'audio, publier ou supprimer des données. Ces paramètres peuvent être ouverts à tout moment via l'engrenage situé dans l'en-tête du panneau.

Par défaut, la lecture, l'édition et l'utilisation des médias sont disponibles, et une demande directe de l'utilisateur est déjà considérée comme l'autorisation d'appliquer ces actions. La publication et la suppression sont désactivées et activées séparément. S'il le souhaite, l'utilisateur peut activer un mode plus strict et confirmer à nouveau chaque modification, ou exiger une confirmation uniquement pour la publication et la suppression.

Ce n'est pas seulement du texte dans l'invite de démarrage. Le wrapper de serveur commun vérifie la portée avant d’appeler l’outil MCP de modification. Si une confirmation supplémentaire est activée, Builder affiche l'action exacte avec les boutons « autoriser une fois » et « rejeter », tandis que l'appel d'origine continue d'attendre une décision. L'autorisation est liée à l'empreinte digitale de la commande, de l'outil et de l'argument, et une fois exécutée, elle n'est plus valide.

Le début, l'achèvement, l'erreur et le blocage de chaque outil de modification sont automatiquement renvoyés au panneau. Chaque réponse finale doit contenir un résumé structuré avec un statut et une description précise du résultat. Après les modifications, l'agent répertorie également les entités modifiées, les contrôles effectués et les liens vers le résultat ; Builder affiche ce résumé directement sous le texte de la réponse. Le canal peut être terminé explicitement à partir des paramètres ; l'ancien code cesse de fonctionner immédiatement.

Qu'y a-t-il dans Romergo et ce qui reste à l'utilisateur

J'aime penser à cette architecture comme une séparation des préoccupations.

Romergo propose :

• éditeur et espace de travail visuel ;
• projet actuel, page et sélection ;
• salle temporaire pour la communication bidirectionnelle ;
• des outils métiers pour lire, modifier et vérifier un projet ;
• OAuth, droits d'accès et historique des événements de session ;
• une interface dans laquelle l'utilisateur voit les questions, les progrès et les résultats.

L'agent utilisateur apporte :

• modéliser et calculer ;
• propre abonnement ;
• raisonnement et planification;
• mémoire et personnalisation, si fournies par l'agent sélectionné ;
• autres outils connectés ;
• style de travail familier à l'utilisateur.

L'intelligence n'appartient pas à l'application. L'application crée un endroit où cette intelligence peut fonctionner en toute sécurité.

Pourquoi ne pas créer un copilote intégré régulier

L’IA intégrée serait plus facile à expliquer et à activer. L'utilisateur appuie sur un bouton, l'application appelle le modèle sélectionné, tout fonctionne.

Mais il faudrait alors que Romergo devienne également un opérateur d’infrastructures d’IA :

• payer pour l'inférence ou répercuter son coût via un plan ;
• sélectionner des modèles pour l'utilisateur ;
• créer sa propre mémoire et sa propre personnalisation ;
• reconnecter les services externes ;
• stocker un contexte sensible supplémentaire ;
• rattraper constamment les capacités des produits d’IA horizontaux.

Lors de l’utilisation d’un agent personnel, tout cela existe déjà côté utilisateur. Romergo n'essaie pas de créer un autre ChatGPT. Il offre à ChatGPT, Claude ou un autre agent un espace de travail spécialisé et des outils clairs.

Ceci est particulièrement intéressant pour un éditeur créatif. Le même agent peut savoir comment l'utilisateur écrit le dialogue, quel ton il préfère, quelles références ont déjà été discutées et quels outils externes il utilise. Romergo n'a pas besoin de copier l'intégralité de ce système simplement pour remplacer un arrière-plan ou réorganiser une scène.

Le plus étrange : l’agent est à la fois dehors et dedans

L'agent ne se déplace pas physiquement à Romergo. Son modèle et sa boucle d'agent continuent de s'exécuter dans le client AI d'origine.

Mais du point de vue de l'utilisateur, l'agent est présent à l'intérieur de l'éditeur :

• reçoit les commandes du panneau intégré ;
• sait sur quelle page se trouve l'utilisateur ;
• voit la sélection ci-jointe ;
• change le même projet;
• pose des questions et renvoie des réponses au même panel ;
• peut continuer la conversation après avoir changé de page ou reconnecté.

Par conséquent, les expressions « IA à l’intérieur de l’application » et « IA à l’extérieur via MCP » ne sont pas toutes deux tout à fait exactes ici. Il s'agit plutôt d'une présence temporaire d'un agent externe dans la session applicative.

Je ne suis pas le premier à aller dans cette direction

Une fois l’expérience réussie, j’ai commencé à rechercher des approches similaires.

[Agent Client Protocol] (https://agentclientprotocol.com/) permet à des éditeurs comme Zed et JetBrains de connecter des agents de codage externes. Tidewave place Claude Code, Codex et d'autres agents ACP à côté de l'application Web en cours d'exécution et leur transmet le contexte du navigateur et du runtime. [Obsidian Agent Client] (https://community.obsidian.md/plugins/agent-client) affiche Claude Code, Codex et Gemini juste à côté des notes et joint automatiquement le document actif et la sélection. marimo donne à l'agent externe un bloc-notes actif comme espace de travail partagé.

Il existe également des expériences plus générales. AG-UI standardise la communication bidirectionnelle entre l'interface utilisateur et le backend de l'agent. WebMCP propose que les pages Web enregistrent les outils disponibles pour un navigateur ou un agent de bureau connecté. [Agent Application Protocol] (https://agentapplicationprotocol.com/overview) décrit un modèle dans lequel l'application possède l'interface utilisateur et les outils de domaine, et l'agent externe possède le raisonnement, l'historique et les outils à usage général.

Autrement dit, l’idée de base existe déjà sous plusieurs formes. Mais la plupart des implémentations se concentrent sur les IDE, les agents de codage locaux ou les agents déployés par l’entreprise elle-même.

L’expérience Romergo m’intéresse en raison d’une question légèrement différente : que se passerait-il si un agent utilisateur personnel pouvait entrer dans une application créative classique ?

Pas un nouveau modèle. Il ne s'agit pas d'une clé API pour le modèle. Il ne s'agit pas d'une application copilote intégrée. Un agent qu'une personne utilise déjà quotidiennement.

La commodité n'est que la moitié du problème

Une fois qu'un agent externe peut écouter les commandes d'application et modifier un projet, la sécurité n'est plus une fonctionnalité facultative.

Des questions se posent auxquelles il est impossible de répondre avec un seul écran OAuth :

• quelles pages et entités sont disponibles dans une salle spécifique ;
• quelles actions sont autorisées sans confirmation ;
• le texte du projet peut-il contenir une injection rapide ;
• comment un agent doit distinguer une commande utilisateur des données non fiables ;
• qu'arrive-t-il à la commande après l'expiration du délai ;
• comment montrer à l'utilisateur les changements réels, et pas seulement une réponse textuelle confiante ;
• comment révoquer une session et prouver que l'agent a réellement arrêté d'écouter ;
• quelle partie de la mémoire de l'agent personnel et des connexions externes est acceptable à utiliser dans une application particulière.

La version actuelle limite le canal par utilisateur et par heure, utilise OAuth, les étendues de serveur, les confirmations uniques, les revendications de commandes atomiques et un cycle de vie explicite. Il s'agit encore d'une expérience, mais des limites importantes font désormais partie de l'exécution et ne sont plus seulement des lignes directrices pour l'agent.

Comment l'appeler

Je n'ai pas encore de titre définitif.

Bring Your Own AI signifie généralement votre propre clé API ou sélection de modèle. Bring Your Own Agent est plus proche car l'utilisateur apporte non seulement le modèle, mais aussi la mémoire, les outils et une boucle d'agent. Cependant, BYOA ne décrit pas une partie importante de l’expérimentation : l’application peut également contacter l’agent et maintenir une session en direct avec lui.

C'est peut-être :

• un canal d'agent en direct ;
• une session d'agent d'application ;
• une couche de présence d'agent ;
• un pont d'agent personnel ;
• MCP bidirectionnel ;
• ou simplement une expérience réussie en plus des idées existantes.

Je ne veux pas proposer une nouvelle norme uniquement pour le nom. Premièrement, il est plus important pour moi de comprendre si un tel modèle est utile en dehors de Romergo et quelles sont les limites nécessaires pour qu'on lui fasse confiance.

Les applications peuvent ne pas avoir besoin d'IA native

Aujourd'hui, presque tous les produits tentent d'intégrer leur propre assistant. De ce fait, l'utilisateur dispose de nombreuses IA distinctes : une dans l'éditeur, une autre dans la messagerie, une troisième dans le système de tâches. Chacun a sa propre mémoire courte, ses propres limites et son propre prix.

Il existe un autre modèle possible.

L'application fournit un espace de travail, un contexte en direct et des outils spécialisés. L'utilisateur amène un agent en qui il a déjà confiance. Pendant qu'il travaille, l'agent rejoint l'application, aide à terminer la tâche et repart avec l'utilisateur.

Je ne sais pas encore si cela deviendra une catégorie architecturale indépendante. Mais maintenant je sais qu’un tel cycle peut être assemblé et qu’il peut réellement être utilisé.

Mais je sais qu’expérimenter est très amusant.

Retour au blog technique