Pourquoi l'AI Agent Infrastructure a besoin d'un Agents Filesystem et d'un Versioned Control Filesystem
21 avril 2026Lin Ivan
Points clés
- Le prochain blocage de l'AI Agent Infrastructure n'est pas seulement la qualité du modèle, mais la gestion du contexte, des outils, des fichiers, des permissions et du rollback.
- Le stack interne de Cloudflare montre la forme d'un système d'agents en production : authentification, MCP servers, sandboxes, AGENTS.md, catalogue de services et AI code review.
- La plupart des équipes n'ont pas besoin de reconstruire toute cette plateforme immédiatement. Elles ont besoin d'une couche manquante : un Agents Filesystem.
- Un Versioned Control Filesystem est essentiel parce que les agents modifient des fichiers. Chaque écriture doit avoir identité, diff, historique, rollback et audit.
- puppyone fournit cette couche : un file workspace pour agents IA avec ingestion SaaS, accès MCP, permissions scoped, sandbox mounts, version history et audit logs.
La leçon de Cloudflare : les agents ont besoin d'une infrastructure autour d'eux
Cloudflare a publié un article sur son stack interne d'ingénierie IA : The AI engineering stack we built internally. L'article est intéressant car il ne traite pas l'adoption de l'IA comme un problème de prompt. Il la traite comme un problème d'infrastructure.
Cloudflare relie authentification, routing LLM centralisé, MCP servers, exécution sandboxée, sessions longues, catalogue de services, fichiers AGENTS.md, standards d'ingénierie et AI code review.
| Problème de production | Réponse d'infrastructure |
|---|---|
| Plusieurs clients et fournisseurs IA | Routing centralisé, politique modèle, suivi des coûts |
| Les agents ont besoin d'outils internes | MCP servers et couche portail |
| Les agents doivent exécuter du code | Environnements sandboxés |
| Les agents ont besoin du contexte repo | AGENTS.md et standards |
| Les agents ont besoin de savoir organisationnel | Catalogue de services et graphe de dépendances |
| Les sorties doivent être revues | AI code review lié aux standards |
C'est cela, une AI Agent Infrastructure de production : non pas un chatbot avec une fenêtre de contexte plus longue, mais un environnement où les agents trouvent le bon contexte, utilisent les bons outils, agissent dans les bonnes limites et laissent des traces vérifiables.
Pourquoi "ajouter MCP" ne suffit pas
MCP est une couche de protocole importante. La Model Context Protocol documentation le présente comme un standard pour connecter les modèles aux outils et sources de données.
Mais MCP ne résout pas automatiquement stockage, permissions, audit et récupération.
Si tout reste un appel API live, les mêmes problèmes apparaissent :
- les schemas d'outils consomment du contexte avant le travail ;
- l'agent n'a pas d'endroit durable pour plans, fichiers scratch, rapports ou données transformées ;
- il est difficile de diff deux runs ;
- chaque SaaS, repo ou base de données demande du glue code ;
- les résultats restent dans un chat, un répertoire temporaire ou un dossier non gouverné.
MCP est le protocole d'accès. Ce n'est pas, à lui seul, la mémoire, le storage, le permissioning, l'audit et le recovery.
Construisez une couche de contexte gouvernée pour vos agents avec puppyoneGet startedCe que signifie Agents Filesystem
Un Agents Filesystem est un workspace de fichiers conçu pour les agents IA plutôt que pour les humains.
Les systèmes de fichiers classiques supposent qu'un humain décide ce qui est sûr, actuel ou digne d'un commit. Les agents fonctionnent autrement : ils lisent ce qui est visible, écrivent là où ils peuvent et utilisent les fichiers comme partie de leur boucle de travail.
Un Agents Filesystem de production doit fournir cinq capacités :
| Capacité | Pourquoi c'est important |
|---|---|
| Contexte unifié | Accès aux données SaaS, docs repo, tickets, specs et artefacts précédents dans un même espace. |
| Accès scoped | Chaque agent ne voit que les chemins autorisés. |
| Interfaces natives | Bash, MCP, REST, CLI ou sandbox mounts selon le runtime. |
| Écritures durables | Plans, scratch files, rapports et code généré survivent à la session. |
| Traces opérationnelles | Lectures, écritures, diffs et erreurs de permission sont visibles. |
Ce n'est pas un simple dossier partagé. Dropbox, S3, Git, disque local et bases vectorielles résolvent chacun une partie, mais combinent rarement identité agent, permissions par agent, distribution MCP, sandbox mounts et versioning automatique.
Pour le détail sécurité fichier, voir filesystem design for AI agents.
Pourquoi le versioning doit être dans la couche fichiers
Les agents ne font pas que récupérer du contexte. Ils le modifient.
Ils résument des réunions, génèrent des plans, transforment des datasets, réécrivent de la documentation, créent des rapports et ouvrent des pull requests. Dès qu'un agent écrit, le système a besoin d'un modèle de récupération.
C'est le rôle d'un Versioned Control Filesystem. L'expression naturelle serait "version-controlled filesystem", mais le point est simple : le contrôle de version ne doit pas dépendre du fait que l'agent pense à commit. Il doit être dans la couche de storage.
Dans un Versioned Control Filesystem pour agents :
- chaque écriture crée une version ;
- chaque changement est attribué à un agent, utilisateur, Access Point ou workflow ;
- chaque diff est inspectable ;
- chaque dossier peut revenir à un état connu ;
- les runs risqués peuvent partir d'un checkpoint ;
- les limites de permission sont auditables.
Si un agent supprime un dossier, écrase une policy ou corrompt un dataset, l'équipe peut inspecter et revenir en arrière. Git a montré la valeur des diffs et rollbacks pour le code. Les agents ont besoin d'une sémantique similaire pour le contexte.
Architecture de référence pour AI Agent Infrastructure
Requête utilisateur ou workflow
-> client agent / orchestration
-> routing modèle et policy
-> couche MCP et outils
-> Agents Filesystem
- contexte SaaS synchronisé
- contexte repo et projet
- artefacts générés
- permissions par agent
- version history et audit logs
-> sandbox execution
-> review, approval, deployment
L'Agents Filesystem est au centre parce que le contexte y devient opérationnel. Il relie sources, MCP, sandbox et review. Sans cette couche, les équipes accumulent dossiers locaux, index vectoriels, serveurs MCP séparés, wikis, buckets et notes d'audit manuelles.
Où se place puppyone
puppyone est un file workspace pour la collaboration multi-agents. Dans cette architecture, il apporte la couche Agents Filesystem et Versioned Control Filesystem.
Concrètement :
- Notion, GitHub, Google Drive, Gmail, Airtable, Linear et les bases de données se synchronisent dans un Context Space ;
- le contexte devient Markdown, JSON, dossiers et fichiers bruts ;
- les Access Points définissent les chemins lisibles ou modifiables ;
- les endpoints MCP exposent le même workspace à Claude, Cursor et autres clients MCP ;
- les sandbox mounts ne contiennent que les fichiers autorisés ;
- version history et rollback rendent les changements récupérables ;
- audit logs indiquent qui a touché quel fichier et quand.
puppyone ne remplace pas toutes les couches du stack Cloudflare. Les politiques modèle, l'isolation runtime, la CI, le review et les standards internes restent nécessaires. Mais avec un Agents Filesystem, le contexte et les artefacts cessent d'être dispersés.
À lire aussi : MCP in Agentic AI et AI audit best practices for secure agent deployments.
Checklist pour évaluer votre stack
| Question | Si la réponse est non |
|---|---|
| Chaque agent trouve-t-il le contexte sans copier-coller ? | Il faut ingestion et normalisation. |
| Chaque agent ne voit-il que les fichiers et outils autorisés ? | Il faut scoped permissions. |
| Les fichiers générés survivent-ils à la session ? | Il faut un storage durable. |
| Peut-on diff deux runs ? | Il faut un historique versionné. |
| Peut-on rollback une mauvaise écriture ? | Il faut checkpoints et restore. |
| La sandbox monte-t-elle seulement le contexte autorisé ? | Il faut un contrôle d'accès conscient du filesystem. |
| Les humains review-ils des artefacts plutôt que des chats ? | Il faut des workflows fichier. |
C'est l'intention réelle derrière ai agent infrastructure : permettre aux agents de lire, écrire, exécuter, collaborer et être revus en sécurité.
FAQs
Q1: Un Agents Filesystem est-il la même chose que MCP ?
Non. MCP est un protocole d'accès aux outils et données. Un Agents Filesystem est la couche de contexte et de storage pour fichiers, artefacts, permissions, versions et audit.
Q2: Est-ce différent d'une base vectorielle ?
Oui. Une base vectorielle aide la recherche sémantique, mais ne fournit généralement pas un workspace lecture-écriture avec permissions par chemin, rollback, diffs et sandbox mounts.
Q3: Pourquoi parler de Versioned Control Filesystem ?
Parce que le versioning doit être natif dans le filesystem utilisé par les agents. Il ne doit pas dépendre d'un commit manuel.
Q4: Quand adopter cette couche ?
Quand les agents passent d'expériences isolées à des workflows partagés : plusieurs agents, plusieurs sources, fichiers sensibles, tâches longues, artefacts réutilisables ou review humaine.