RECAST
PayDai · RUBN · MDRN · AST · DETOK / En production, vérifié

Deux comptes Discord actifs, 135 canaux cartographiés et 94 sessions actives ont transformé un espace multi-activités tentaculaire en couche de commandement gouvernée.

PayDai · RUBN · MDRN · AST · DETOK · Un portefeuille de fondateur coordonnant investisseurs, recherche, création, produit et opérations d’équipe entre plusieurs activités

En production, vérifiéMulti-agentsOpérationsServices professionnels

Une couche de commandement stabilisée sépare les environnements JoshuaAI et RUBN, route explicitement personnes et canaux autorisés, et garde le savoir de chaque activité accessible sous une surface commune.

Joshua Ajayi n’avait pas besoin d’une nouvelle fenêtre de conversation. Il lui fallait une couche de commandement fiable pour un portefeuille où le travail allait des supports investisseurs et de la recherche aux produits, à la création et à la coordination d’équipe. RECAST a stabilisé cette couche autour du fonctionnement réel de chaque activité.

Éléments probants à la publication : l’environnement actif a été inspecté le 30 mai 2026 avec deux comptes Discord actifs, 135 canaux cartographiés, 16 utilisateurs autorisés et 94 sessions actives. Ces chiffres décrivent le périmètre opérationnel vérifié, pas un résultat de revenu ou de productivité déduit.

L’entreprise

Joshua opère PayDai, RUBN, MDRN, AST et DETOK. La surface de travail du portefeuille couvre présentations et aperçus partenaires PayDai, marque et produits MDRN, création RUBN, cours AST, rapports de recherche, comptes rendus, dossiers de pilotage et sites publics ou de prévisualisation.

Une grande part convergeait dans Discord. Le serveur principal comptait plus de 100 canaux et plusieurs membres, chacun avec ses permissions et responsabilités. Discord était déjà l’endroit où l’organisation travaillait ; il fallait rendre la couche IA assez fiable pour y travailler avec elle.

La contrainte

L’échelle rendait les petites erreurs de configuration coûteuses. Un nouveau canal pouvait rester hors de la cartographie explicite et ne recevoir aucune réponse. Un profil d’authentification obsolète pouvait signaler une fausse limite de débit. Un même assistant devait aussi distinguer préparation investisseurs, création RUBN et cours AST sans mélanger les contextes.

Le goulot n’était donc pas l’accès à un modèle performant. C’était le routage fiable entre activités, personnes, canaux et mémoire.

Pourquoi les outils existants ne suffisaient pas

Un assistant traditionnel place la dernière conversation au centre. Le portefeuille de Joshua exigeait l’inverse : le système devait d’abord savoir quelle activité, quel espace, quel utilisateur et quel canal gouvernaient la demande.

Cela imposait listes blanches explicites, cartographie au niveau des canaux, identités Discord séparées et route modèle testée. Une discipline d’exploitation sur versions et authentification était également nécessaire. Sans ces contrôles, une réponse fluide pouvait arriver dans le mauvais contexte — ou ne pas arriver du tout.

Cartographie de la transformation

Avant

Cinq contextes d’activité -> plus de 100 canaux -> dérive d’authentification et d’autorisation -> Joshua/l’équipe diagnostique et reroute

Après

Utilisateur autorisé + canal cartographié -> Jarvis ou agent RUBN -> contexte propre à l’activité -> outil ou dossier -> réponse Discord visible -> état de session conservé

Le second compte Discord est une frontière, pas un élément décoratif. Jarvis sert la guilde JoshuaAI principale ; RUBN AGENT sert l’environnement RUBN OS distinct.

Un processus de bout en bout

  1. Entrée : un membre autorisé soumet une demande investisseurs, recherche, support, produit ou création dans un canal cartographié.
  2. Contrôle d’identité et de route : compte, guilde, identifiant du canal et liste utilisateur déterminent si Jarvis ou RUBN AGENT doit agir.
  3. Assemblage du contexte : le système récupère les éléments de l’activité dans son espace et sa mémoire active sans fusionner tout le portefeuille.
  4. Exécution : navigation, recherche, dossiers projet ou ressources de contenu soutiennent la tâche dans le parcours choisi.
  5. Réponse opérationnelle : le résultat revient dans le canal de travail où l’équipe peut le vérifier et poursuivre.
  6. Continuité : état des sessions et dossiers organisés conservent le travail ; tout nouveau canal doit être cartographié volontairement par identifiant.

Ce qui a changé

  • Construit : couche Discord à deux comptes, structure d’espace consciente des activités, mémoire active et rythmes de commandement récurrents.
  • Connecté : Jarvis à la guilde JoshuaAI et RUBN AGENT à RUBN OS, avec utilisateurs et canaux explicitement cartographiés.
  • Stabilisé : authentification Codex obsolète réparée, route active clarifiée et route de proxy inutilisée retirée.
  • Testé : santé de la passerelle locale, connexion Discord et boucle d’événements vérifiées dans l’environnement actif.
  • Vérifié en production : le 30 mai, LaunchAgent fonctionnait avec deux comptes, 135 canaux, 16 utilisateurs autorisés et 94 sessions actives.
  • Utilisé activement : les sessions prouvent un espace fonctionnel et utilisé, pas 94 projets terminés ni un résultat financier.
  • Contrôle encore requis : les nouveaux canaux nécessitent une cartographie explicite par ID ; l’autorisation ne s’étend pas silencieusement avec le serveur.

Preuves

  • Preuve d’exécution : service ai.openclaw.gateway et endpoint de santé local actifs pendant l’inspection.
  • Preuve de communication : Discord sain avec Jarvis et RUBN AGENT actifs.
  • Preuve de routage : 135 canaux et 16 utilisateurs cartographiés dans JoshuaAI, avec une seconde guilde RUBN OS.
  • Signal d’usage : 94 sessions actives au point de vérification.
  • Preuve de contexte : dossiers pour publicité, ressources, cours AST, livrables PayDai, marque/produit MDRN, projets, rapports, recherche et création RUBN.

Aucune preuve conservée n’attribue revenu, amélioration de marge ou temps économisé à ce déploiement ; aucun de ces résultats n’est revendiqué.

La technologie — en dernier

La couche fonctionne sur un Mac mini avec OpenClaw 2026.5.6, deux comptes Discord, routage direct Codex, mémoire active, memory-core, outils de navigation, cron et heartbeat, accès Tailscale et gestion par launchd. À la vérification, la route utilisait un contexte de 200k, une concurrence de quatre tâches et une version OpenClaw épinglée. Ces choix rendent le routage inspectable ; la valeur réside dans la structure de portefeuille qu’ils soutiennent.

Témoignage client

Aucun témoignage textuel étayé par la source n’est publié. Les preuves sont l’environnement inspecté, la cartographie du routage et l’empreinte des sessions.

Transformation suivante

Découvrez comment la couche opérationnelle d’agence de Yannick Schatz a été durcie face aux pannes du vrai travail client. Elle applique un routage tout aussi explicite à des départements d’agence plutôt qu’à un portefeuille de fondateur.

Obtenez votre feuille de route IA

Si plusieurs activités dépendent encore de vous pour savoir quelle personne, quel système et quel contexte appartiennent à chaque demande, la contrainte est la coordination. Réservez un audit IA gratuit pour cartographier la première couche de commandement à prouver.

Sources

  • OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 18.
  • RECAST_CASE_STUDIES_2026_UPDATED.pdf, page 4, document RA-CASES-001, version 2.0.
  • RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 10.4, 11 et 58.

Où vos opérations bloquent-elles encore du temps de travail, de la capacité ou des opportunités de chiffre d’affaires ?

Obtenez votre feuille de route IA

Les catégories facultatives restent désactivées tant que vous ne les choisissez pas. Vous pouvez revenir sur cette décision depuis le pied de page à tout moment.

Strictement nécessairesToujours actif

Sécurité, navigation, langue et mémoire du consentement. Toujours actifs.