Cartographier les agents avant d'écrire le moteur

L'équipe qui construit votre runtime spatial doit être conçue avec autant d'intention que le runtime lui-même. RakuAI a commencé par la forme de l'équipe - un humain, une flotte d'agents - parce que l'architecture découle de qui la construit.

Ce samedi a été consacré à un exercice de tableau blanc que quiconque observerait jugerait prématuré. Le produit est loin d’être prêt à livrer. Le moteur n’est pas encore un dépôt. Il n’y a pas de code. Il n’y a pas de démo. Il y a une feuille de route matérielle, un portefeuille de brevets qui remonte à plus d’une décennie, et une thèse claire sur ce que devrait être la prochaine génération de lunettes AR. Et me voici, assis à la table de la cuisine, en train de cartographier les agents qui vont construire tout cela.

C’est voulu.

Pourquoi les agents viennent en premier

Le mouvement conventionnel à ce stade d’un projet consiste à commencer à écrire du code. Ouvrir le dépôt. Construire la preuve de concept. Embaucher des ingénieurs quand le PoC commence à réclamer de l’aide. Livrer le MVP. Itérer.

J’ai construit trois entreprises en suivant ce chemin conventionnel. J’ai décidé que celle-ci serait différente. L’équipe qui construit ce moteur sera composée d’un humain et d’une flotte d’agents IA travaillant dans des rôles définis. L’architecture du moteur, la forme du SDK, la discipline de la revue de code, la cadence de la boucle de développement, tout cela découle de la forme de l’équipe. Si je ne détermine pas d’abord la forme de l’équipe, je me retrouverai avec un moteur construit pour une équipe différente de celle qui doit réellement le construire.

Donc aujourd’hui est le jour de la forme de l’équipe.

L’effectif

L’effectif d’agents que je suis en train d’arrêter, avec le rôle que chacun est censé assumer.

Agent Product. Détient la spec. Suit les mises à jour matérielles, les feuilles de route des fournisseurs, les dépendances du SDK, le calendrier de sortie publique. L’Agent Product est la source de vérité canonique de ce que le moteur est censé faire. Les autres agents vérifient leur travail par rapport à la lecture de la spec de l’Agent Product.

Agent SDK. Détient le SDK lui-même. Documentation, parcours d’intégration, tests de compatibilité, publication de packages. L’Agent SDK est l’agent avec lequel les développeurs interagiront le plus souvent, sous forme de documentation générée, d’applications d’exemple et de messages d’erreur d’intégration. Sa production doit avoir l’allure d’une véritable fonction de relations développeurs.

Agent Studio. Détient la prospection auprès des studios de jeux et des développeurs indépendants. Préparation des démos. Supports de co-marketing. Documentation d’intégration ciblée spécifiquement pour les studios. La métrique de l’Agent Studio est la conversion : un studio qui nous a parlé puis a livré quelque chose sur le moteur. Cette métrique est loin dans l’avenir et le quotidien de l’Agent Studio est l’accumulation lente de relations qui la produisent.

Agent Marketing. Détient la surface publique. Kits presse. Actifs Kickstarter si cette voie a du sens. Suivi des influenceurs. Supports pour les événements matériels. Tests A/B sur les pages d’atterrissage. La production de cet agent est ce que le monde voit en premier. Elle doit être excellente.

Agent Operations. Détient la cadence. Stand-ups (avec moi). Gestion Notion / Gantt. Alertes de goulot d’étranglement. Résumés exécutifs. L’Agent Operations est l’agent avec lequel je fais le point au début de chaque samedi pour savoir ce que le reste des agents a fait pendant la semaine de travail pendant que j’étais ailleurs.

Agent Stratégie IA et Données. Détient le volant de données. Capture la télémétrie du SDK et des lunettes. Construit les petits modèles de langage qui vivront éventuellement sur l’appareil. Affine la douve IA. C’est l’agent dont le travail se compose le plus dans le temps, car les données et les modèles qu’il produit deviennent le différenciateur que personne ne peut reproduire.

Sous-agent Codex Dev. Écrit le code. Intègre les API du runtime. Construit les démos Unity et Unreal. Soutient l’Agent SDK sur l’intégration technique. C’est l’agent de codage autonome. Il travaille sous direction. Il ne fixe pas ses propres priorités.

C’est l’effectif de référence : sept agents dans des rôles définis, avec des interactions explicites entre eux.

Les trois que j’ajoute

L’effectif de référence nous mène la majeure partie du chemin. Il y a trois rôles que je juge nécessaires mais qui n’étaient pas dans l’ébauche originale. Je les ajoute ce samedi.

Agent Relations Développeurs. Issues GitHub. Discord. Reddit. L’agent qui répond quand un développeur pose une question et que l’Agent SDK n’a pas encore de documentation pour ça. C’est du travail de conciergerie. C’est aussi du travail d’évangélisation. La bonne personne dans ce rôle (ou le bon agent) construit une confiance avec les studios et les développeurs indépendants d’une manière qu’aucun support marketing ne peut reproduire.

Agent Partenariats Stratégiques. Prospection B2B. Conversations de licence. Accords de co-marketing avec des cybercafés, des salles d’e-sport, partout où le produit pourrait être expérimenté d’abord par quelqu’un d’autre qu’un studio. C’est l’agent qui poursuit les canaux de revenus qui ne sont pas grand public.

Agent Gouvernance des Agents. L’agent qui surveille les autres agents. Propose des mises à niveau. Gère le versionnage. Gère le retour arrière quand un agent prend une mauvaise décision. C’est la récursion que je considère comme le véritable déverrouillage pour ce type de flux de travail. Sans elle, les agents dérivent. Avec elle, ils s’améliorent avec le temps parce que quelqu’un surveille les surveillants.

À quoi ressemble la carte des interactions

La version tableau blanc, simplifiée :

• La supervision exécutive (moi) se trouve au sommet.
• L’Agent Gouvernance des Agents se trouve en dessous de moi et surveille tout ce qui est en dessous de lui.
• Product, SDK et Codex Dev forment un triangle de travail technique.
• Studio et Relations Développeurs forment la surface orientée développeurs.
• Marketing et Partenariats Stratégiques forment la surface orientée extérieur.
• Operations et IA/Données se trouvent en dessous comme préoccupations transversales.

Chaque agent a des interactions explicites avec les autres. SDK parle à Codex Dev. Studio parle à Marketing. Operations parle à tout le monde. L’Agent Gouvernance surveille l’ensemble et intervient quand la production d’un agent commence à dériver de son rôle.

Ce n’est pas l’organigramme d’une entreprise traditionnelle. C’est l’organigramme d’un flux de travail où la plupart des cases sont des agents IA et la plupart des connexions entre elles sont des transmissions automatisées. Le seul humain dans l’organigramme est au sommet, faisant le cadrage et le travail de jugement. Tous les autres sont des agents.

Pourquoi c’est le bon moment pour faire cela

Trois raisons.

L’architecture du moteur sera façonnée par l’équipe. Les préoccupations transversales comme la documentation, les tests et la revue de code doivent être conçues dans la base de code dès le premier jour si les agents doivent y participer. Si j’écris d’abord la base de code et que j’essaie ensuite d’y intégrer des agents, je devrai faire la plupart du travail deux fois.

Le portefeuille de brevets me donne la marge pour planifier soigneusement. Les brevets qui ancrent ce produit sont des antériorités vieilles d’une décennie. Le timing concurrentiel n’est pas « livrer dans trois mois ou quelqu’un d’autre le fait ». C’est « livrer la bonne chose au bon moment, ce qui est plus proche que ça ne l’a été à tout moment des dix dernières années mais permet encore un trimestre de planification ». J’utilise ce trimestre.

Les agents eux-mêmes doivent être conçus. Chacun a besoin d’un prompt système, d’un ensemble d’outils, d’un ensemble de garde-fous. Écrire le moteur avant d’écrire les agents revient à embaucher l’équipe après que le travail a commencé. C’est ainsi que les projets de moteur finissent avec des agents casés de force dans des rôles que la base de code n’était pas conçue pour supporter.

La suite

Le samedi prochain sera consacré à la conception du SDK. Structure de dossiers, surface des modules, à quoi ressemble l’interaction du développeur avec chaque pièce. Le samedi suivant sera consacré à la suite de démos : quelles sont les applications d’exemple canoniques, ce qu’elles prouvent, ce qu’elles enseignent. D’ici la fin de l’été, la phase de conception devrait être terminée et le véritable dépôt pourra s’ouvrir.

C’est une construction lente selon les standards traditionnels du rythme de capital-risque. Elle ne paraîtra pas lente une fois terminée.