PathruleAgent IR
Ce que Pathrule livre à un agent de codage pour une tâche, ce qu'il écarte délibérément, comment une mémoire arrive en entier ou par son titre, comment l'autorité est préservée à la livraison et en quoi les canaux diffèrent d'un client à l'autre.
Sur cette page
Agent IR est le nom que Pathrule donne à ce qu'un agent reçoit pour une tâche : la frontière entre tout ce que sait Pathrule et une exécution donnée par un agent donné.
Cette frontière compte. Il s'agit de connaissances sélectionnées pour une tâche, puis mises en forme pour un client, et non d'une requête accolée à un prompt. Ce que reçoit un agent est assemblé pour le travail qu'il a devant lui, et sa forme relève d'un choix de conception, pas de ce qu'une recherche a pu renvoyer par hasard.
Ce qu'il contient
Pour une tâche, dans un périmètre donné :
- Les règles qui s'appliquent, en tant que règles, dans leur propre section.
- Les mémoires les plus importantes pour le chemin et le prompt, en entier, et les autres qui s'appliquent, listées par titre.
- Les skills qui s'appliquent, par leur nom, pour que l'agent puisse charger la procédure quand il en a besoin.
- Vos préférences personnelles, dans les clients dotés d'un hook de prompt, sous un intitulé qui maintient en premier les exigences de l'espace de travail. Voir User Intelligence.
- Les constats que des agents ont consignés sur le code, présentés comme des conseils à vérifier, dans le contexte que demande un agent. Voir l'apprentissage du projet.
- Les patterns d'équipe vérifiés, sur Pathrule Cloud. Les suggestions que personne n'a vérifiées ne sont pas livrées.
Ce qu'il laisse délibérément de côté
Tout ce qui n'améliore pas l'exécution.
Aucun champ de suivi interne, aucun identifiant interne dont l'agent n'a que faire, aucune connaissance liée à d'autres parties du dépôt, et rien qu'une personne n'a approuvé lorsqu'une approbation est requise. Une suggestion, une préférence candidate ou une contrainte de règle non approuvée ne sont pas livrées.
Trois propriétés porteuses
La nature est préservée. Un correctif passé est livré comme un correctif passé, et une règle comme une règle. Ramener les deux à un simple « retiens ceci » fait perdre ce qui rendait chacun utile.
L'autorité est encodée, pas aplatie. Un conseil est placé à un endroit clairement subordonné au lieu d'être concaténé après une règle stricte avec le même poids. Un agent qui lit la livraison distingue une exigence d'une suggestion, parce que la livraison a indiqué laquelle était laquelle. Voir Knowledge IR.
Le texte intégral est toujours à une lecture près. Une mémoire qui ne tient pas dans le budget par prompt est listée par son titre au lieu d'être écartée, et la lire par son nom renvoie tout ce que votre équipe a écrit.
Comment une mémoire parvient à l'agent
Une mémoire parvient à un agent de l'une de trois façons.
- En entier, pour le prompt. Dans les clients dotés d'un hook de prompt, Claude Code et Codex, Pathrule sélectionne les mémoires utiles pour le chemin et le prompt, les priorise et livre les plus pertinentes en entier avant que l'agent ne commence, dans la limite d'un budget par prompt. Une mémoire déjà livrée pendant la session n'est pas renvoyée.
- Par titre. Les mémoires qui s'appliquent mais ne tiennent pas dans le budget sont listées par titre, pour que l'agent sache qu'elles existent et puisse lire n'importe laquelle avec
pathrule_read_memory. - Dans les fichiers d'instructions. Les fichiers que Pathrule compile pour chaque client contiennent les connaissances de l'espace de travail, ou un index de celles-ci, aux chemins qu'elles régissent : même un client sans hooks part donc de ces connaissances.
Lire une mémoire par son nom n'est pas une livraison. Cela renvoie toujours le texte intégral, car une lecture explicite est une demande de la source.
Ce qui arrive en entier, et ce qui arrive sous forme de nom détaille le budget, et le fonctionnement de la récupération explique comment se fait la sélection.
Où s'applique la livraison compilée
La part de tout cela qui arrive sans que l'agent la demande dépend des hooks du client.
| Client | Ce qui arrive automatiquement |
|---|---|
| Claude Code, Codex | Les fichiers d'instructions au démarrage de la session, plus une livraison par prompt via le hook de prompt. |
| Cursor, GitHub Copilot | Les fichiers d'instructions, plus du contexte via les hooks de session et d'outil. Pas de hook de prompt. |
| Windsurf | Son fichier de règles. Pas de hooks ; le contexte plus approfondi passe par MCP. |
| Clients Remote MCP | Rien d'automatique. L'agent fait ses demandes via les outils MCP. |
Remote MCP est un endpoint d'outils hébergé. Il n'installe aucun hook et n'écrit aucun fichier local : un client distant qui demande des connaissances n'est donc pas la même chose qu'un hook local qui les livre au moment où l'agent agit. Quel que soit le canal, tout agent peut en demander davantage avec pathrule_get_context.
Indépendant du moteur
Ce qui est sélectionné ne dépend jamais de l'agent qui va s'exécuter. Les mêmes connaissances sont mises en forme une seule fois, et chaque client les reçoit par son propre mécanisme natif : ses fichiers d'instructions, ses hooks lorsqu'il en a, et MCP. Voir le fonctionnement des hooks.
C'est ce qui rend l'indépendance vis-à-vis des agents structurelle plutôt que théorique. Il n'existe pas de connaissances taillées pour Claude ni de connaissances taillées pour Codex, seulement les connaissances et l'enveloppe dans laquelle elles sont livrées. Ce qui diffère d'un client à l'autre, c'est la part qui peut arriver sans être demandée, ce que le tableau ci-dessus rend explicite.