Comment fonctionne Genesis

Genesis est un orchestrateur multi-agent de livraison logicielle. Vous décrivez un résultat attendu en langage courant ; Genesis planifie le travail, le découpe en tasks, dépêche des agents de codage IA pour l'exécuter, applique les gates de gouvernance et de review, suit chaque dollar dépensé en modèles et expose l'ensemble du pipeline aux humains via un tableau de bord, une API REST et un large catalogue d'outils MCP. Il est multi-tenant : un même déploiement héberge de nombreux Tenants clients isolés, chacun avec ses propres projects, missions, agents, conversations, coûts et posture de compliance.

Cette page est la carte. Elle explique les grandes pièces et la façon dont elles s'articulent, puis renvoie vers une page dédiée à chaque sous-système. Chaque page de sous-système est écrite sous deux angles : la surface opérateur / produit (ce qu'il fait et comment vous le pilotez — outils MCP, contrôleurs REST, pages du tableau de bord) et l'architecture interne (les services, le modèle de données et les rouages d'exécution).

La forme du système

Genesis est organisé en une hiérarchie d'intention qui se resserre de la stratégie vers l'exécution :

• Tenant — la frontière d'isolation de plus haut niveau (un client). La control-plane database contient le registre des Tenants, les environnements et tous les catalogues partagés (fournisseurs LLM / presets / routage, workflows système, le catalogue des exigences/contrôles de compliance, les règles constitutionnelles, les profiles de fleet). Chaque Tenant dispose ensuite de ses propres données opérationnelles (missions, tasks, agents, conversations, coûts, reviews, connaissances) dans une tenant database. La ténance est implicite via la base de données par Tenant — il n'y a pas de colonne TenantId (ADR-008).
• Project — une unité de travail à l'intérieur d'un Tenant, généralement liée à un ou plusieurs dépôts Git. Les projects regroupent les missions, portent une arborescence de fichiers/modules enregistrée, appliquent une politique de frontière et constituent la portée pour les coûts, les connaissances et la configuration de fleet.
• Charter → Matter → Mission → Task — la hiérarchie de travail. Un Charter est une initiative stratégique (il porte une Vision et des critères d'acceptation). Un Matter est un épic stratégique sous un Charter. Une Mission est un élément concret de travail livrable qui se décompose en Tasks, les unités atomiques que les agents exécutent réellement.
• Track — chaque mission et chaque conversation s'exécute dans l'une de quatre tracks qui cadrent le type de travail : Governance (politique), Research (stratégie / investigation), Planning (commande / décomposition) et Build (exécution). (Du code plus ancien persiste cette information sous un nom de champ hérité ; elle désigne toujours la Track.)

Les deux pierres angulaires

Deux sous-systèmes sont le cœur de Genesis et disposent de leurs propres guides détaillés.

• Agents — les travailleurs autonomes. Un Strategic Orchestration Agent natif (et un Compliance agent permanent) s'exécutent sur un cœur événementiel (agent_instances + agent_event_queue) et sont auto-cadencés : un AgentDispatcher en arrière-plan fait avancer chaque instance Active, l'agent lit son journal d'événements, planifie via un appel LLM à provenance enregistrée, puis entreprend des actions typées et gouvernées. Les agents de type mission (Feature, Research, Review, onboarding, etc.) enveloppent ce cœur pour mener une mission spécifique jusqu'à son terme. Le travail de codage est délégué aux coders — des outils CLI conteneurisés (Claude, Copilot, Codex, Gemini, Aider, Octofriend) instanciés par task. Consultez le guide Agents pour le cycle de vie complet, le modèle d'événements, les budgets et les rouages de dispatch.
• Workflows — un graphe réutilisable et versionné d'étapes typées (stocké sous forme de GraphJson, avec un cycle de vie Draft → Published et une somme de contrôle de contenu). Invoquer un workflow publié compile le graphe en une mission dont les tasks portent le câblage des étapes ; les étapes de type gate deviennent des décisions d'approbation en attente que des humains résolvent, et la mission enregistre workflowId@version + la somme de contrôle comme provenance de compliance. Les workflows peuvent embarquer des contrôles de compliance issus d'un catalogue versionné (avec des dérogations par exécution). Consultez le guide Workflows pour le modèle de nœuds/pins, le compilateur, les gates, les contrôles, les déclencheurs et les rouages d'exécution.

Les couches transversales

Trois couches s'exécutent sous tout ce qui précède :

• Dialogue — des conversations stratégiques avec le modèle qui peuvent proposer des missions à l'approbation humaine (la principale rampe d'accès de l'idée au travail).
• La couche de routage LLM — chaque appel de modèle est attribué à un call site nommé (p. ex. Missions:Decomposition, ReviewEngine:Architecture). Un preset rattaché à ce site résout, au moment du dispatch, le fournisseur, le modèle, la chaîne de routage (avec ses fallbacks), la politique d'outils, l'échantillonnage / les limites et l'overlay de prompt. Les Modes appliquent atomiquement tout un lot de rattachements de sites. Consultez LLM Configuration & Prompt Overlays.
• Coûts & gouvernance — chaque appel écrit un enregistrement de coût (tokens, cache, tarification batch, USD estimés) attribué à sa mission / task / project ; les budgets, quotas, règles constitutionnelles et gates de compliance contraignent ce que les agents ont le droit de faire. Consultez Costs & Budgets.

Guide des sous-systèmes