En bref : agency-agents est la plus grande collection organisée de personas d'agents IA sur GitHub, avec 149 312 étoiles au 1er septembre 2026. Il fournit plus de 300 fichiers de définition d'agents répartis dans environ 20 dossiers de catégories et les installe dans Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Windsurf, Aider, et une douzaine d'autres outils avec une seule commande. Ce que vous obtenez, c'est un cadre, pas une capacité. Les personas modifient la façon dont votre agent aborde une tâche ; ils ne lui donnent pas de faits qu'il n'a pas, et ils ne perdent pas leur effet après la session.
Ceci est un examen approfondi d'un outil de notre sélection de cinq outils d'agents IA open source à installer en 2026.
Votre agent de codage a une seule personnalité : celle d'un généraliste serviable. Demandez-lui de revoir un flux d'authentification et vous obtiendrez des conseils sensés mais oubliables. Demandez à un réviseur de sécurité avec un modèle de menace et une liste de contrôle, et vous obtiendrez des constatations.
C'est cette lacune qu'agency-agents comble. Cela a commencé comme un fil de discussion Reddit sur la spécialisation des agents et a évolué vers une liste suffisamment vaste pour que l'installation de tout cela fasse planter au moins un runtime d'agent populaire. Voici ce qu'il contient réellement, comment installer les parties que vous souhaitez, et les deux choses qu'une bibliothèque de personas ne peut pas faire pour vous.
Ce que vous installez réellement
Chaque agent est un fichier Markdown. Pas une invite système d'une ligne, ni un plugin avec du code. Un fichier contient une identité et une personnalité, une mission principale, un processus de travail, des livrables techniques avec des exemples, et des métriques de succès.

En comptant les fichiers Markdown dans l'arborescence du dépôt au 1er septembre 2026, il y en a 312 répartis dans 20 dossiers de catégories de premier niveau, ou 306 si l'on exclut le répertoire examples/. La distribution est asymétrique en faveur de la construction de choses :
| Division | Fichiers d'agents |
|---|---|
| engineering | 59 |
| specialized | 58 |
| marketing | 36 |
| game-development | 21 |
| integrations | 18 |
| strategy | 16 |
| gis | 13 |
| security | 12 |
| design | 10 |
| sales | 9 |
| testing | 9 |
| paid-media | 7 |
| project-management | 7 |
| academic | 6 |
| spatial-computing | 6 |
| support | 6 |
| finance | 5 |
| product | 5 |
| healthcare | 3 |
Il est à noter que le README du dépôt annonce toujours « 230+ agents ». Cette information est obsolète. L'arborescence a dépassé les 300.
La division ingénierie est celle par laquelle la plupart des développeurs commenceront, et la spécificité est plus élevée que ce que l'on attendrait d'une collection de prompts. À côté des entrées évidentes de Développeur Frontend et d'Architecte Backend, il y a un Ingénieur Réseau ciblé sur Cisco IOS-XE, Juniper Junos et Palo Alto PAN-OS, un Ingénieur Firmware Embarqué pour les cibles ESP32, STM32 et Nordic, un Commandant de Réponse aux Incidents pour les post-mortems et la préparation aux astreintes, et un Ingénieur d'Intégration de Codebase conçu pour explorer un dépôt en lecture seule et énoncer des faits à son sujet plutôt que de proposer des modifications.
Ce dernier exemple illustre bien le fonctionnement du modèle. Un persona en lecture seule avec un mandat explicite de non-édition est un outil véritablement différent de votre agent par défaut, et il ne coûte rien d'autre qu'un fichier.
Installer sans casser votre configuration
Le dépôt fournit des scripts de conversion et d'installation. Le chemin interactif détecte ce que vous avez installé et vous demande ce que vous voulez :
git clone https://github.com/msitarzewski/agency-agents.git
cd agency-agents
./scripts/install.sh
Cibler un outil spécifique et un sous-ensemble de divisions est le comportement par défaut le plus sensé :
# tout, dans Claude Code
./scripts/install.sh --tool claude-code
# seulement deux divisions
./scripts/install.sh --tool claude-code --division engineering,security
# seulement les agents nommés
./scripts/install.sh --tool cursor --agent frontend-developer,ui-designer
# voir ce qui existe avant de s'engager
./scripts/install.sh --list teams
./scripts/install.sh --tool opencode --division engineering --dry-run
Les cibles prises en charge incluent Claude Code, Cursor, Codex, Gemini CLI, OpenCode, GitHub Copilot, Windsurf, Aider, Kimi Code, Hermes, Antigravity, Osaurus et Mistral Vibe. Il existe également une application de bureau native sur agencyagents.app pour macOS, Linux et Windows qui permet de parcourir la liste, d'installer en un clic et de se mettre à jour automatiquement, ainsi qu'un paquet Homebrew.
Lisez ceci avant d'installer tout. Le runtime d'OpenCode n'enregistre actuellement qu'environ 119 agents et ignore les autres silencieusement, ce que le dépôt documente comme un bug en amont. L'installation d'un sous-ensemble avec --division vous maintient sous la limite, et l'installateur vous avertit lorsqu'une sélection la dépasserait. La troncation silencieuse est le pire mode de défaillance qui soit, car l'agent que vous vouliez est manquant et rien ne vous le signale.
Même en dehors de ce bug spécifique, installer 300 personas est une mauvaise idée. Une liste que vous ne pouvez pas mémoriser est une liste que vous n'utiliserez pas. Installez les deux divisions dans lesquelles vous travaillez, lisez quatre ou cinq fichiers, et supprimez ceux qui ne correspondent pas au fonctionnement réel de votre équipe.
Ce qu'un persona change, et ce qu'il ne change pas
Un persona est un cadre. Il définit ce que l'agent recherche, le format qu'il produit et ce qu'il considère comme accompli. Cela vaut plus que ce que cela paraît, car une grande partie des mauvaises sorties d'agents ne vient pas d'une erreur du modèle, mais du fait que le modèle optimise pour la mauvaise forme de réponse.
Ce qu'un persona ne peut pas faire, c'est fournir des informations que le modèle n'a pas. C'est la limite que les gens découvrent après une semaine, et elle est la plus évidente avec les API.
Chargez l'Architecte Backend et demandez-lui d'écrire un client pour votre service de facturation interne. Il produira un code propre et idiomatique en se basant sur une forme de réponse qu'il a inventée. Il n'a aucun moyen de savoir que votre service renvoie un 409 avec une enveloppe d'erreur différente lorsqu'une clé d'idempotence se répète, ou que le curseur de pagination est opaque plutôt qu'un offset. Le persona a rendu le code mieux organisé. Il ne l'a pas rendu correct.
La même limite s'applique à la division de test. Un persona QA écrit des tests exhaustifs basés sur son propre modèle mental de l'API, de sorte que les tests passent et ne prouvent rien. Nous avons abordé la raison pour laquelle cette boucle spécifique est dangereuse dans le test des agents IA non déterministes, et ce qui se passe lorsque la forme réelle évolue dans ce qui se passe lorsque les changements d'API cassent les agents IA.
La solution consiste à donner le contrat à l'agent au lieu d'espérer que le persona compense. Si votre API est conçue dans Apidog, la spécification OpenAPI est la source de vérité : schémas réels, codes de statut réels, enveloppes d'erreur réelles. L'agent les lit plutôt que de les reconstruire à partir des points d'appel. Les mocks sont générés à partir de cette même spécification, y compris les branches d'erreur qu'un persona ne penserait jamais à simuler, et la suite de tests échoue bruyamment en CI lorsque la réalité et la spécification divergent.

Ce couplage est le modèle mental utile. Le persona décide comment l'agent fonctionne. La spécification décide ce qui est vrai. Lectures connexes : utiliser votre spécification OpenAPI comme outils d'agent et concevoir des schémas d'outils d'API pour les agents. Si vous souhaitez intégrer une spécification en direct dans le contexte de votre agent, téléchargez Apidog et pointez-le vers votre projet existant.
La deuxième limite : un persona n'est pas une équipe
Voici ce que la métaphore de la liste promet mais ne livre pas.
L'argument est une agence complète à portée de main. En pratique, vous activez un persona lors d'une session, il effectue une tâche, et la session se termine. Demain, vous tapez à nouveau l'activation. Il n'y a pas d'équipe, car il n'y a rien de persistant : pas d'assignation, pas de trace de ce que l'évaluateur de sécurité a trouvé mardi dernier, et aucun moyen pour un collègue de voir quoi que ce soit de cela. Neuf des divisions de ce dépôt décrivent des rôles qui n'ont de sens qu'au sein d'une organisation, et l'outil qui les installe n'en a aucune notion.
Si vous voulez que l'idée de la liste survive au-delà d'une seule session de terminal, la couche manquante est la gestion du travail. Sharkly est conçu précisément pour cela, et le couplage avec agency-agents est suffisamment proche pour mériter d'être explicité.

- Un Agent dans Sharkly est une configuration sauvegardée, pas une invite que vous retaper. Il contient des instructions, le runtime, les compétences, les dépôts et l'environnement. Un persona que vous avez réglé une fois est réutilisé, ce qui est la version durable de ce qu'un fichier
.mddans~/.claude/agents/cherche à accomplir. - Une Équipe (Crew) est un agent leader plus d'autres agents et personnes. C'est le concept de division avec une mécanique réelle. Les Équipes fonctionnent en mode leader-first : le leader lit le contexte de la tâche, décide quels membres faire intervenir et combine leurs résultats en un seul endroit, plutôt que chaque spécialiste ne commence en même temps et ne se précipite.
- Le travail est assigné, pas invoqué. Vous confiez une tâche à un Agent de la même manière que vous la confiez à un coéquipier. Elle vit dans un espace, un projet et un sprint, avec une synchronisation Jira si votre équipe y travaille déjà.
- L'exécution est 'apportez la vôtre'. Vous connectez un Ordinateur, qui peut être votre ordinateur portable, un serveur ou un conteneur, et Sharkly utilise le Runtime déjà installé dessus. Votre abonnement Claude Code ou Codex fait le travail ; rien ne vous revend des jetons.
- Le résultat est révisable. La progression, les appels d'outils et les résultats sont renvoyés à la tâche, et la sortie de l'agent apparaît sous forme de commentaires auxquels vous pouvez répondre. Une tâche dans le Backlog ne démarre pas une exécution, vous pouvez donc préparer le travail avant toute exécution.
En clair : agency-agents vous donne les descriptions de poste, et Sharkly vous donne l'endroit où ces postes sont assignés, exécutés et révisés. Utilisez le dépôt comme une bibliothèque de définitions de rôles pour amorcer de véritables Agents plutôt que comme un dossier que vous installez et oubliez.
Écrire les vôtres, en utilisant les leurs comme modèle
La chose la plus durable que ce dépôt vous offre est un format. Une fois que vous avez lu quelques fichiers, écrire un persona pour votre propre stack prend environ quinze minutes, et un persona spécifique à votre entreprise est toujours meilleur qu'un générique.
La structure qui se répète dans les bons fichiers :
- Identité et voix. Qui est cet agent et comment il parle. Cela semble cosmétique, et c'est la partie qui empêche l'agent de revenir au mode d'assistant générique à mi-chemin d'une longue tâche.
- Mission principale. Une phrase sur ce que signifie le succès. Le fichier de l'Ingénieur d'Intégration de Codebase en est un exemple clair : explorer en lecture seule, tracer les chemins de code, énoncer des faits sur la structure et le comportement, ne rien proposer.
- Processus de travail. Étapes ordonnées que l'agent suit. C'est la section qui vaut la peine d'être « volée ». Un persona de révision avec un processus en sept étapes produit une sortie cohérente d'une session à l'autre ; un autre sans produit ce que le modèle a eu envie ce jour-là.
- Livrables. Les artefacts concrets, avec format. Dites « un tableau Markdown de constatations avec la sévérité, le chemin du fichier et le numéro de ligne » plutôt que « un rapport ».
- Métriques de succès. Comment l'agent sait qu'il a terminé, ce qui sert aussi de point de contrôle pour son travail.
Une version interne pour le travail d'API pourrait ressembler à ceci :
# Réviseur de Contrats API
## Mission
Vérifier que les points d'API nouveaux ou modifiés correspondent à la spécification OpenAPI dans ce
dépôt avant qu'ils n'atteignent la revue. Signaler les non-correspondances. Ne pas modifier le code.
## Processus
1. Lire la spécification pour chaque point d'API affecté par le diff actuel.
2. Pour chacun, comparer le gestionnaire avec la spécification : codes de statut,
schéma de réponse, enveloppe d'erreur, en-têtes requis, style de pagination.
3. Exécuter les tests de contrat. Enregistrer les échecs mot pour mot.
4. Vérifier que les nouveaux points d'API ont été ajoutés à la spécification, et pas seulement au routeur.
5. Signaler tout champ de réponse présent dans le code et absent de la spécification.
## Livrables
Un tableau : point d'API, méthode, type de non-correspondance, ligne de spécification, ligne de code, sévérité.
Pas de résumé en prose. Pas de corrections suggérées sauf demande.
## Terminé lorsque
Chaque point d'API du diff apparaît dans le tableau avec un verdict, et la
sortie du test de contrat est incluse comme preuve.
Ce fichier est court et en fait plus pour une équipe backend que n'importe lequel des 59 personas d'ingénierie livrés dans le dépôt, car il nomme votre spécification, vos tests et votre définition de ce qui est « terminé ». L'étape trois est la partie importante : le persona est chargé de produire des preuves plutôt qu'une opinion, ce qui est la différence entre une revue sur laquelle vous pouvez agir et un paragraphe de réassurance.
Le même principe fonctionne pour la réponse aux incidents, les travaux de migration, les mises à jour de dépendances et l'intégration. Prenez la structure du fichier, conservez la discipline du processus, remplacez le contenu générique par le vôtre. Lorsque la sortie de l'agent doit survivre à un transfert à un humain ou à un autre agent, le contrat de format fait la majeure partie du travail, ce qui est le point que nous avons soulevé dans le transfert d'agent et le passage de contexte.
Les nombres d'étoiles sont-ils significatifs ici ?
149 312 étoiles, c'est beaucoup, et cela mérite une mise en garde. Les dépôts de personas collectent des étoiles plus rapidement que presque toute autre catégorie car ils sont faciles à comprendre, faciles à partager et ne coûtent rien à essayer. Une étoile signifie que quelqu'un a trouvé que c'était une bonne idée, pas qu'il l'utilise toujours.
Ce qui rend ce dépôt crédible, c'est la forme du travail plutôt que le nombre. Il a un historique de contributions réelles depuis octobre 2025, il est sous licence MIT, il documente ses propres limites, y compris le plafond d'enregistrement d'OpenCode, et les fichiers d'agents contiennent un contenu de domaine spécifique plutôt que des futilités de rôle génériques. Comparez cela aux nombreux dépôts « awesome prompts » qui ont atteint leur apogée et se sont arrêtés.
Jugez-le en ouvrant trois fichiers dans une division que vous connaissez bien. Si le fichier du Développeur Frontend dit des choses qu'un bon développeur frontend dirait, le reste est probablement bon. Si cela ressemble à une offre d'emploi, ignorez le dépôt.
Comment en tirer réellement de la valeur
Un flux de travail qui tient la route :
- Installez une seule division. Choisissez celle qui correspond à votre travail quotidien. L'ingénierie pour la plupart des lecteurs.
- Lisez les fichiers. Quatre ou cinq, du début à la fin. Vous recherchez les sections de processus, qui sont la partie à conserver.
- Modifiez-les. Ajoutez votre stack, vos conventions, votre définition de ce qui est « terminé ». Un persona décrivant un atelier React générique vaut moins que le même fichier avec vos règles de test.
- Donnez de vraies entrées aux personas modifiés. Un réviseur de sécurité avec votre spécification OpenAPI trouve des problèmes de contrat. Le même réviseur sans celle-ci produit une liste de contrôle.
- Promouvez ceux qui sont pertinents. Tout persona que vous utilisez deux fois par semaine devrait devenir un Agent sauvegardé dans un système de gestion du travail plutôt qu'un fichier que vous copiez entre machines.
Cette dernière étape est celle où les équipes soit l'adoptent à grande échelle, soit l'abandonnent discrètement.
FAQ
agency-agents fonctionne-t-il avec Cursor et Codex, ou seulement avec Claude Code ? Avec tous. Le script convert.sh génère des fichiers d'intégration par outil et install.sh --tool cible un outil spécifique. Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Copilot, Windsurf, Aider, Kimi Code et plusieurs autres sont pris en charge. Si vous comparez les clients d'agents pour le travail d'API, consultez notre examen des clients API dans Cursor et Copilot.
Dois-je installer les 300 agents ? Non. Sur OpenCode, vous ne pouvez pas, car le runtime n'enregistre qu'environ 119 agents et ignore les autres silencieusement. Sur d'autres outils, vous le pouvez techniquement, mais vous n'utiliserez jamais la plupart d'entre eux. Installez par division.
Les personas rendent-ils l'agent plus intelligent ? Ils le rendent mieux orienté. La précision sur les questions de fait, y compris ce que votre API renvoie, ne change pas. Cela nécessite une spécification réelle, ce qui est l'argument dans avez-vous encore besoin d'un outil API à l'ère des agents IA ?
Est-il sûr d'exécuter le script d'installation ? Il écrit les fichiers de définition d'agent dans les répertoires de configuration de votre outil. C'est son but. Il est sous licence MIT avec le code source complet disponible, et --dry-run vous montre ce qu'il ferait avant de le faire. Exécutez d'abord la simulation. Le principe général de ce que vous laissez les agents toucher se trouve dans les garde-fous des agents IA.
Quelle est la différence entre ceci et un framework d'agent ? Si vous voulez que les personas s'exécutent plusieurs à la fois plutôt qu'un par session, c'est Orca. Un framework comme Strands ou AgentKit vous offre une orchestration d'exécution en code. agency-agents vous donne des fichiers Markdown qui changent la façon dont un agent existant se comporte. Couche différente, pas de chevauchement.
En résumé
agency-agents est la meilleure version d'une idée spécifique : votre agent fait un meilleur travail lorsqu'il sait quel rôle il joue. Installez une division, lisez les fichiers, modifiez-les pour qu'ils correspondent à votre équipe, et vous obtiendrez une réelle valeur pour environ vingt minutes de configuration.
Soyez ensuite honnête sur les deux choses qu'il ne résout pas. Les personas ne savent pas ce que votre API renvoie, c'est à cela que sert Apidog, et ils ne persistent pas dans quelque chose qu'une équipe peut voir ou examiner, c'est à cela que sert Sharkly. Une liste est un bon début. Ce n'est pas une organisation, et ce n'est pas une source de vérité.
