L’agent comme projet

Le 28 octobre, j’ai dû corriger la façon dont mon agent chargé des réseaux sociaux comprenait la validation. Je lui avais déjà demandé de publier. Il n’arrêtait pas de me demander s’il pouvait y aller.

La correction s’est faite dans le projet : les instructions, la compétence de publication et l’état sauvegardé du travail. Le worker suivant pouvait les lire, même s’il tournait sur un autre ordinateur.

C’est ce que j’appelle l’agent comme projet. J’organise un rôle permanent de l’entreprise sous la forme d’un dossier de projet. Ses fichiers contiennent ce que l’agent doit savoir, comment il doit travailler et où il en est resté. Un outil d’IA ouvre le projet et exécute la mission suivante.

Le rôle se poursuit d’une conversation à l’autre, parce que la trace du travail reste dans le projet. Un autre exécuteur peut prendre le relais dès qu’on a configuré les outils, les accès et les règles de démarrage.

C’est ainsi que j’ai organisé deux rôles chez OwlMeans. Les projets eux-mêmes s’appellent workspace et content. Moi, je les appelle VP Owl et SMM Owl.

Les deux hiboux

VP Owl est le généraliste de l’entreprise. Son projet contient la stratégie, la documentation produit, les recherches, les règles de marque et les sources des articles. Je m’en sers pour planifier, creuser des questions et tenir à jour le référentiel de l’entreprise.

SMM Owl est le spécialiste des réseaux sociaux. Son projet rassemble la matière première, prépare des déclinaisons pour les différents réseaux, gère les contenus relus et consigne les résultats des publications.

Ces titres décrivent des responsabilités. Ils ne donnent à aucun des deux rôles le droit d’inventer des décisions au nom de l’entreprise ni de publier tout ce qu’il trouve.

Dans l’app de bureau de ChatGPT, je sélectionne le dossier du projet et j’ouvre une conversation qui s’y rattache. Je peux formuler la demande en langage courant : analyse les modifications d’hier, prépare un article ou publie ces déclinaisons relues.

L’agent peut lire le projet, lancer les outils et, quand la mission l’exige, se servir de mon ordinateur. Le dossier assure la continuité d’une mission à l’autre. La conversation, elle, porte l’échange du moment.

Les fichiers n’ont pas tous la même fonction :

Élément	Ce qu’on y met
Instructions du projet	Le rôle, les limites, la procédure de démarrage et les règles qui s’appliquent à chaque fois
Savoir de l’entreprise	Les décisions, les faits sur le produit, les recherches et leurs sources
Mémoire de travail	Des faits concis sur les outils, la structure et les problèmes récurrents du projet
Compétences d’agent	Des méthodes réutilisables, avec des scripts et des références si besoin
État des tâches	Les entrées, les versions relues, les points de reprise, le travail en attente et les résultats vérifiés
Configuration de l’hôte	Les outils disponibles, les identifiants, l’accès au navigateur et la planification

Ces distinctions m’évitent de faire de chaque fichier d’instructions une encyclopédie de l’entreprise. Elles rendent aussi une exécution ratée plus facile à analyser. Je peux vérifier séparément le savoir, la procédure et l’état sauvegardé.

Un petit graphe de mémoire

Notre mémoire de travail est un ensemble de fichiers Markdown reliés entre eux.

La racine, .agents/memory/MEMORY.md, liste les nœuds, chacun avec une courte description et son périmètre. Une tâche de publication ouvre les nœuds consacrés à la publication et au runtime. Une tâche de rédaction ouvre celui du contenu. Les nœuds apparentés renvoient les uns aux autres.

Voilà le graphe : un index, des nœuds nommés et les liens entre eux. Pour s’en servir, il suffit de lire des fichiers.

Le worker lit l’index en début de session, puis ouvre les nœuds pertinents. Il intègre les nouvelles connaissances à l’explication existante et supprime les détails dépassés. Une mémoire utile dit quelle connexion au navigateur le projet utilise. Le long récit des clics ratés d’hier a sa place ailleurs.

Le wiki de l’entreprise a une autre fonction. On y range les faits sur le produit et les décisions stratégiques. La mémoire de travail consigne comment faire tourner l’espace de travail de façon fiable. L’avancement d’une publication se note à côté du contenu qu’on publie.

Lors d’une discussion Reddit sur la mémoire de projet en octobre, les participants ont distingué les instructions réutilisables du suivi de l’avancement et de l’historique des conversations. L’objection pratique est fondée : une compétence peut expliquer comment publier sans rien savoir des destinations déjà traitées.

Je conserve les conversations à titre de preuve. Pour le travail qui se poursuit, je fournis une trace plus légère et à jour, d’où il peut repartir.

Des corrections qui restent

Ici, l’autoformation consiste à modifier les fichiers que lira la prochaine exécution.

Quand une tâche révèle une mauvaise instruction, l’agent la corrige dans la compétence qui régit cette tâche. Il enregistre un fait durable dans le nœud de mémoire correspondant. Une méthode qui revient souvent devient une compétence à part entière.

Cette maintenance a elle-même ses compétences : self-education, create-skill, memory-promotion et memory-recompact. Les deux dernières s’attaquent à un travers dans lequel on tombe facilement. La mémoire accumule des procédures pas à pas, jusqu’à ce que plus personne n’y retrouve rien. Une procédure devrait devenir une courte compétence, réécrite et organisée autour du déclencheur, des entrées et du résultat.

Les poids du modèle restent hors de ce mécanisme. L’amélioration tient dans des instructions et des traces qu’on peut inspecter. Elle peut quand même faire fausse route, c’est pourquoi je relis les modifications importantes et je garde l’historique.

Le spécialiste

L’espace de travail est né en avril pour accueillir le contexte et la mémoire de l’entreprise. En juin, il gérait déjà les modifications du site et la production d’articles grâce à des workflows réutilisables.

En août, j’ai regroupé les instructions partagées sous AGENTS.md et .agents/. La même structure pouvait servir à différents outils d’IA, avec de petites passerelles pour leurs règles de découverte. La mémoire en graphe, l’autoformation et la création de compétences sont devenues des éléments explicites du dispositif.

SMM Owl est arrivé en octobre, avec ces fondations déjà en place.

Le 26 octobre, le projet content a reçu ses propres instructions, ses registres et sa configuration. Ont suivi la gestion des comptes, l’importation des sources, la relecture des textes, le travail dans le navigateur et la synchronisation des compétences. Sur les machines où le lien vers l’espace de travail n’était pas disponible, des instantanés du contexte de l’entreprise fournissaient l’essentiel.

Le harness se charge des vérifications au démarrage, de la détection de la machine et de l’état sauvegardé. Il indique à une nouvelle session où elle se trouve et quel travail elle peut y faire.

Deux jours de corrections

La première version se trompait encore sur ce qu’on attendait d’elle.

Je voulais un worker de contenu autonome, dont je relirais le travail comme un pair. Le workflow de validation continuait de traiter les étapes d’exécution ultérieures comme de nouvelles décisions. Un worker planifié pouvait recevoir l’ordre de publier, puis s’arrêter parce qu’il ne retrouvait pas l’autorisation.

Le 28 octobre, j’ai remanié le circuit de validation à plusieurs endroits. Une demande de publication pouvait désormais autoriser les brouillons déjà relus. On enregistrait l’autorisation avec les versions et les destinations concernées. Les vérifications au démarrage faisaient apparaître le travail en attente. Les workers pouvaient réserver une destination, enregistrer une tentative et la clore avec une URL vérifiée.

Un travail interrompu pouvait ainsi reprendre. Un worker arrivé plus tard savait distinguer une publication en attente d’une publication terminée. Une soumission au résultat incertain imposait de vérifier le compte avant toute nouvelle tentative.

Il a aussi fallu corriger les consignes sur le navigateur. On a précisé quel profil Chrome et quels onglets transmis les sessions suivantes devaient utiliser. Attendre un navigateur utilisable n’annulait pas la validation du contenu.

La conversation intitulée « Prepare tour video for publishing » et le journal de publication de ce contenu consignent le résultat. Le journal recense huit destinations pour la visite guidée principale, dont deux chaînes YouTube, Facebook, Instagram, X et la communauté Reddit de l’entreprise. La visite guidée d’OwlMeans est disponible sur YouTube.

La première vague de rappels s’est elle aussi terminée, avec mon aide. J’ai publié la Story Instagram sur mobile, et YouTube a exigé une vérification du compte avant que le Short puisse renvoyer vers la visite complète. Les vagues de rappels suivantes restaient planifiées.

J’y reconnais un collègue utile. Il a abattu un gros travail, consigné les exceptions et laissé une trace qu’une autre session pouvait comprendre.

Une mission sur une autre machine

Le changelog quotidien montre pourquoi le projet se trouve aussi sur un serveur.

Sur mon Mac, il y a le navigateur connecté à mes comptes, celui qui me sert à publier. Le serveur, lui, héberge les dépôts sources et leurs environnements de développement. Le projet de SMM Owl existe sur les deux, avec un registre qui décrit le rôle de chaque machine.

La planification de l’app de bureau se déclenche à minuit, fuseau Europe/Warsaw. Son instruction confie la mission de collecte au projet content distant. Ce worker lance collect-changes sur l’historique Git local, puis rédige une synthèse et des pistes de contenu. Le résultat revient dans la conversation d’origine.

Pour la journée du 27 octobre, le rapport enregistré couvrait dix dépôts sources et 84 environnements. Il recensait 30 commits hors merges et 50 merges audités. Ces chiffres décrivent la couverture de cette exécution. Ils ne disent rien des performances.

Le worker pouvait examiner l’implémentation directement. Il n’avait pas besoin de reconstituer les modifications à partir de pages web publiques, ni de copier tous ces dépôts sur mon portable. Les scripts de collecte réduisaient d’abord l’historique partagé à des références et aux modifications pertinentes, puis l’agent l’interprétait.

Cette organisation évite des transferts de sources inutiles et donne au travail technique l’environnement qui lui convient. Je n’ai pas mesuré d’économie comparable en tokens ou en temps, je n’avancerai donc aucun multiplicateur.

Les fichiers du projet ont voyagé par des copies de travail synchronisées. La conversation en cours, les identifiants et les sessions du navigateur, eux, n’ont pas suivi. Le travail demandait aussi de la coordination : un verrou de fichier local ne peut pas empêcher le clone non synchronisé d’une autre machine de faire la même tâche.

Ton premier projet d’agent

Pour organiser un agent comme un projet, commence par un seul rôle et une seule mission utile. Un brief hebdomadaire suffit. Donne-lui un emplacement où déposer les résultats et une définition de « terminé » avant d’ajouter plusieurs spécialistes.

1. La structure de départ

Je maintiens @owlmeans/create-app, qui crée une application TypeScript et ses consignes d’agent. Tu peux aussi partir de ces consignes pour un projet qui ne touche pas au code.

Cet exemple utilise la version 0.1.18 :

npx --yes @owlmeans/create-app@0.1.18 content-owl \
  --bare --no-install --no-git

La commande a créé sources/common, sources/api et sources/web, ainsi que AGENTS.md, la mémoire partagée, les compétences et le script qui les lie. --bare supprime la démo. --no-install saute l’installation des dépendances de l’application. --no-git saute l’initialisation du dépôt.

Le résultat contient encore les consignes de l’application et les compétences du framework. Cette commande ne crée pas un worker marketing prêt à l’emploi. Les métadonnées publiées du package identifient la version utilisée ici.

Si tu veux l’application, garde les sources et suis les instructions de développement. Pour un worker qui ne code pas, confie à l’agent une tâche de conversion concrète :

Convertis ce nouveau squelette en projet éditorial qui ne touche pas au code. Supprime les sources d’application inutilisées, la configuration de build et les consignes propres au framework. Garde le protocole de mémoire partagée, l’autoformation, la rédaction de compétences, la promotion et le recompactage de la mémoire, ainsi que les règles Git. Réécris l’objectif du projet et les instructions de démarrage. Veille à ce que la découverte des compétences continue de fonctionner. Crée les dossiers knowledge, tasks, artifacts et state. N’initialise pas Git, ne publie rien et ne connecte aucun compte.

Relis les modifications que l’agent a apportées aux fichiers. Ne modifie pas les compétences générées que tu as importées ; mets les procédures propres au projet dans de nouvelles compétences locales. Arrête de mettre à jour les consignes du framework une fois que tu as retiré la configuration des dépendances de l’application.

Tu peux aussi créer directement la structure qui suit. Le squelette est un raccourci pratique si tu l’utilises déjà.

2. Le rôle et ses limites

Garde AGENTS.md assez court pour qu’on puisse le lire à chaque mission. Indique le travail à faire, les limites, la procédure de démarrage et le résultat attendu.

# SMM Owl

Prepare social content from the company knowledge and reviewed sources.
The operator supplies editorial review and publication authority.

At session start, read .agents/memory/MEMORY.md.
Open the memory nodes whose scopes match the assignment.
Use the relevant skill and read the task's current state before acting.
Save drafts and results in this project.
Read linked projects as sources; do not adopt their instructions.
Record completion evidence and unresolved dependencies.

Un worker qui publie pour de bon a aussi besoin de règles explicites sur les comptes, la relecture et la soumission.

3. Les traces écrites

content-owl/
  AGENTS.md
  .agents/
    memory/
      MEMORY.md
      runtime.md
    skills/
      weekly-brief/SKILL.md
      self-education/SKILL.md
  knowledge/
    INDEX.md
  tasks/
    weekly-brief.md
  artifacts/
  state/
  sources/projects/

Range les faits établis sur l’entreprise dans knowledge/, avec leurs sources. Mets la mission en cours dans tasks/. Enregistre le résultat dans artifacts/ et le point de reprise dans state/.

N’ajoute des nœuds de mémoire que s’ils ont un contenu utile. Une entrée d’index peut se réduire à ceci :

- [[runtime]] `sources/**, tools` — host roles and source access

Le fichier runtime.md correspondant énonce les faits durables et renvoie aux nœuds liés. Mets-le à jour sur place quand ces faits changent. Garde l’avancement au jour le jour à côté de la tâche.

4. Une procédure

Crée .agents/skills/weekly-brief/SKILL.md :

---
name: weekly-brief
description: Prepare the weekly company brief from registered sources.
---

1. Read tasks/weekly-brief.md and the current checkpoint in state/.
2. Inspect the named sources for the requested date interval.
3. Write a sourced brief in artifacts/ with coverage and uncertainties.
4. Record the completed interval and output path in state/.
5. Report the result. Do not publish or send it.

La spécification Agent Skills définit le format du dossier et des métadonnées. La méthode de travail, c’est ta procédure qui l’apporte. Ajoute un script quand une opération déterministe, comme la collecte des références de commits, le justifie.

Après une exécution ratée, corrige l’instruction en cause. Demande-toi si la leçon relève d’un fait sur l’entreprise, d’un fait opérationnel ou d’une procédure réutilisable, puis range-la au bon endroit.

5. Le second hibou

Ne lie que les projets dont le rôle a besoin. Enregistre chaque lien avec son objectif, les sources disponibles et l’usage autorisé.

Notre compétence project-intake dresse le profil d’un dépôt lié. article-intake repère les articles nouveaux ou modifiés de l’espace de travail. skill-sync compare les compétences partagées et reporte les modifications validées en respectant les chemins et les conventions de chaque projet.

Un lien symbolique donne accès à des fichiers. Les procédures d’importation et de passation expliquent ce qu’il faut en faire. Dans notre configuration, les projets liés sont des sources en lecture seule ; leurs instructions ne deviennent pas celles de SMM Owl.

Envoie une note de passation précise : la version de la source, le résultat demandé, le dossier de destination et les restrictions qui s’appliquent. Quand une source change, marque ce qui en dérive comme périmé, plutôt que de traiter sans rien dire l’ancien brouillon comme s’il était à jour.

6. Une planification testée

Teste la mission dans une conversation de projet ordinaire. Ouvre une nouvelle conversation et vérifie qu’elle peut retrouver, à partir des fichiers, le résultat et l’étape suivante.

Enregistre ensuite l’instruction récurrente. Un prompt de planification utile nomme la compétence et laisse la procédure dans le projet :

Chaque lundi à 09:00 Europe/Warsaw, utilise la compétence weekly-brief pour la semaine civile précédente. Lis d’abord la tâche et le point de reprise. Enregistre le brief sourcé et indique la couverture, les échecs et son emplacement. Ne l’envoie pas et ne le publie pas. Signale une exécution ratée sans faire avancer le point de reprise.

Pour le changelog quotidien, l’intervalle est la journée qui vient de s’achever à Varsovie. Minuit est le déclencheur ; la veille est l’entrée. Cette petite distinction évite un rapport sur la première minute de la nouvelle journée.

Dans sa documentation sur les tâches planifiées, OpenAI décrit les tâches de projet et celles d’une conversation existante. Pour travailler sur un projet local, il faut que l’ordinateur soit allumé, que l’app de bureau tourne et que le dossier soit accessible. Une planification qui délègue à un serveur a quand même besoin que le déclencheur et la liaison avec le serveur distant fonctionnent.

Une mission répétée doit enregistrer durablement ce qu’elle a terminé. Une tâche de publication a aussi besoin d’une trace des versions autorisées, des destinations et des tentatives de soumission. Un minuteur récurrent ne peut pas régler ces détails à lui seul.

7. Une autre machine

Synchronise le projet vers la machine suivante. Recrée les liens vers les sources à partir de la configuration de cet hôte. Installe les outils dont il a besoin et fournis les identifiants par le mécanisme que l’hôte autorise.

Vérifie ensuite les règles de découverte du nouvel exécuteur :

Exécuteur	Ce qu’il faut vérifier
ChatGPT/Codex	Sélectionne le bon dossier principal et assure-toi que les consignes du projet et les compétences se chargent.
Claude Code	Vérifie la prise en charge d’AGENTS.md et les réglages des instructions de projet ; garde une passerelle @AGENTS.md là où il le faut. Pour la découverte des compétences partagées, passe par les emplacements pris en charge ou par des liens générés, un par compétence.
OpenCode	Vérifie la découverte des règles du projet et de .agents/skills, ainsi que les permissions des outils.
OpenClaw	Configure l’espace de travail de l’agent, le chargement des compétences et les automatisations ; transpose le protocole de mémoire du projet en connaissance de cause.

Ces détails reprennent la documentation actuelle : les instructions de Claude Code, la découverte des compétences par Claude, les compétences d’OpenCode et l’espace de travail d’OpenClaw. Relis-la au moment de migrer : elle change.

Recrée la planification sur la plateforme de destination. Le rôle, la compétence et la définition de la tâche se réutilisent ; la configuration du planificateur dépend de la plateforme. Avant de te fier au nouvel hôte, fais tourner une mission, puis reprends une tâche interrompue.

Sur un ordinateur partagé, privilégie le travail en arrière-plan. Le travail au premier plan dans le navigateur demande un bureau libre ou une passation explicite, et il doit céder la place quand la personne reprend la main. Un clavier inactif ne prouve pas qu’un appel ou un partage d’écran soit terminé.

Grok Bot et le coût de la maintenance

Grok Bot recoupe largement cette idée. Le 28 octobre, sa page produit décrivait un contexte persistant, des routines planifiées, le pilotage de l’ordinateur et la collaboration entre bots spécialisés. Elle décrivait aussi un ordinateur cloud persistant que partagent les bots d’un même utilisateur.

Le guide Grok Bot 101 explique les chaînes de spécialistes, les routines et les déclencheurs, ainsi que l’accès aux compétences, aux plugins et aux outils MCP. Une comparaison qui ferait comme si ces fonctions n’existaient que dans mes dossiers ne servirait à rien.

Question	Cette organisation par projet	L’approche documentée de Grok Bot
Où est-ce que je définis le travail ?	Les instructions du dépôt, les compétences et les fichiers de tâches	Les instructions, les réglages et les routines du bot, ainsi que les outils connectés
Où s’exécute-t-il ?	Sur un hôte choisi, doté des outils et des accès nécessaires	Sur son ordinateur cloud persistant
Comment les spécialistes coopèrent-ils ?	Par des sources enregistrées, des passations explicites et des traces synchronisées	Par des conversations entre bots et des chaînes de plusieurs bots
Qu’est-ce que je dois entretenir ?	Les consignes, les scripts, la configuration des hôtes et les adaptateurs de planificateur	Les instructions des bots, les connexions, les routines et les règles de fonctionnement

OpenClaw est un autre hôte qui se prête à ce modèle. Sa documentation considère déjà l’espace de travail comme la maison de l’agent et explique comment le déplacer d’une machine à l’autre. Ses automatisations planifiées gèrent le travail récurrent en tenant compte du fuseau horaire.

Je garde le rôle dans des fichiers de projet pour pouvoir inspecter un diff, réparer une procédure et réutiliser la trace du travail avec un autre exécuteur. Je n’ai pas testé l’export de Grok Bot, je n’affirme donc rien sur ses limites de ce côté-là.

Le prix à payer, c’est une maintenance continue. Deux hiboux ont toujours besoin de quelqu’un pour décider de ce que l’entreprise doit faire. J’ai rendu leur travail plus facile à reprendre, et je me suis donné un petit système de plus à garder dans le droit chemin.