Skip to content

Anthropic built Scion for itself. Carbon Forge is yours →

Carbon Forge
Menu

FAQ

Questions sur les agents, le contrôle de version et la mémoire partagée

Réponses courtes de ceux qui construisent Carbon Forge chez 100monkeys.ai, alors lisez-les comme le récit de son fabricant. Les espaces de travail publics sont gratuits, et chaque compte inclut un espace de travail privé gratuit.

Aussi en: English, Español, Português, 日本語, Deutsch, 한국어, 简体中文, Italiano, हिन्दी

Comment plusieurs agents de code partagent-ils un dépôt sans s'écraser les uns les autres ?

Donnez à chaque agent sa propre ligne de travail isolée et ne laissez jamais le système fusionner du texte en silence. Avec git, cela veut dire une branche ou un worktree par agent, et une personne ou la CI qui relit chaque merge. Chez 100monkeys.ai, nous construisons Carbon Forge, qui va plus loin : un agent ouvre une lane au lieu de cloner, et une lane est un ensemble de patchs sur le trunk, lu contre le trunk tel qu'il est maintenant, donc rien n'est copié. Une intégration (landing) est un seul changeset, écrit en une transaction ou pas du tout. Carbon Forge ne fusionne jamais de texte de lui-même ; un patch qui ne s'applique plus revient sous forme de conflit nommé, et l'agent ou la personne y répond contre le trunk qu'il a vu.

Plus : la documentation (en anglais)

Comment les agents d'IA obtiennent-ils une mémoire partagée d'une session à l'autre ?

Écrivez la mémoire quelque part hors du modèle, à un endroit que chaque session lit au début et écrit au fil de l'eau, et rendez-la lisible par des personnes aussi, sinon personne ne pourra la corriger. Les bases vectorielles seules tendent à devenir un tas que personne n'audite. Nous construisons Carbon Forge, où personnes et agents lisent et écrivent un seul registre de code, de fichiers et de texte avec les mêmes outils, et où les agents y accèdent par MCP. Un jeton peut être limité à un preset comme SCM reader, qui n'écrit rien, pour qu'un agent relecteur puisse lire sans rien changer. L'idée est que la mémoire soit un registre partagé et versionné, pas un cache caché.

Plus : la présentation

Comment auditer ce qu'un agent d'IA a modifié, et pourquoi ?

Il vous faut trois choses : le changement lui-même, la raison écrite par l'auteur au moment du changement, et un historique qu'on ne peut pas réécrire ensuite. Les messages de commit échouent en général sur la deuxième. Dans Carbon Forge, que nous construisons, le blame affiche à côté de chaque ligne l'intention que l'agent a écrite au moment de l'intégrer, si bien que "pourquoi cette ligne est-elle là" trouve sa réponse dans la phrase même de l'agent. Chaque révision et chaque changeset sont chaînés par hash, et un revert est une nouvelle intégration, donc l'historique ne fait qu'avancer. Un cut nomme un snapshot scellé de l'espace de travail qui ne bouge jamais, ce qui donne une seule réponse à "qu'est-ce qui a été livré".

Plus : Source control on the substrate (en anglais)

Qu'est-ce qu'un serveur MCP pour une base de connaissances, et pourquoi en vouloir un ?

MCP (Model Context Protocol) permet à un client d'IA comme Claude, Cursor ou un autre agent d'appeler des outils sur un serveur de manière standard. Un serveur MCP pour une base de connaissances signifie que vos agents peuvent lire, chercher et écrire votre documentation et vos notes directement, au lieu que vous colliez du contexte dans un chat. La question de conception est de savoir si l'agent reçoit un canal secondaire de seconde classe ou le même accès qu'une personne. Nous construisons Carbon Forge, où les agents accèdent au registre par MCP avec les mêmes outils que l'éditeur, et où un jeton peut être limité à un preset comme SCM reader, qui n'écrit rien.

Plus : la documentation (en anglais)

Git fonctionne-t-il pour des équipes d'agents de code IA ?

Il fonctionne, avec une friction qui croît avec le nombre d'agents. Le compte rendu d'Anthropic sur son système Scion (13 octobre 2026) décrit les merges dans son monorepo passant d'environ 2 500 par jour en mai à plus de 30 000 par jour en septembre, et désigne comme cause première le fait que chaque clone soit un dépôt complet. Ses principes : des clients toujours en ligne, des commits bon marché et sans verrou, une copie de travail facultative. Nous construisons Carbon Forge sur ces trois principes pour des équipes qui ne sont pas Anthropic : de nombreux espaces de travail plutôt qu'un monorepo, des lanes au lieu de clones, un changeset atomique par intégration, et git conservé comme une projection qui pousse vers GitHub en fast-forward uniquement. Aucune affiliation avec Anthropic.

Plus : Source control on the substrate (en anglais)

Ces réponses ont été rédigées par l'un de nos agents d'IA et relues par l'entreprise.

Questions sur AEGIS et Zaru

100monkeys.ai construit aussi AEGIS, un orchestrateur d'agents open source en bêta, et Zaru, un compagnon qui montre son travail. Leurs questions trouvent réponse sur leurs propres sites.

Give your agents the record.