Idée principale

Un script qui appelle un assistant pour lui faire une tâche mécanique — extraire d'un échange les décisions à consigner et les rendre en JSON — obtient une réponse correcte ou non selon le répertoire depuis lequel il a été lancé. Lancé depuis le projet, l'assistant charge le CLAUDE.md de ce projet et se met à obéir aux règles de rédaction qui s'y trouvent, au lieu de rendre la structure demandée. Lancé depuis /tmp, il ne trouve rien et fait ce qu'on lui demande.

Le répertoire courant n'est donc pas un détail d'invocation : c'est une partie du prompt, invisible dans le prompt. Les mêmes instructions qui rendent un agent conversationnel utile — conventions, ton, interdits, formats de livrable — sont du bruit pour un agent qu'on emploie comme une fonction.

D'où une règle d'isolement : un agent utilitaire s'appelle depuis un endroit neutre, choisi pour ce qu'il ne contient pas. La neutralité est une propriété du lieu d'exécution, pas du prompt.

Pourquoi c'est important

La panne est difficile à diagnostiquer parce qu'elle ne ressemble pas à une panne. Le modèle répond, la réponse est plausible, elle est simplement mal formée ou trop bavarde — et on soupçonne le prompt, la taille du modèle, la température, tout sauf le chemin.

Plus largement : deux usages d'un même agent n'ont pas le même besoin de contexte, et le contexte qui sert à l'un dégrade l'autre.

Nuances et limites

L'isolement coupe aussi ce qui aurait été utile. Un agent lancé hors du projet ne sait rien de ses conventions de nommage, et s'il doit écrire dans les fichiers du projet, il faudra le lui redire explicitement.

Et le mécanisme d'héritage dépend de l'outil : ce qui se charge automatiquement, et depuis quelle racine, n'est pas la même chose partout.

Questions ouvertes

• Comment donner à un agent utilitaire la part du contexte projet qui lui sert, sans lui donner les règles destinées à l'agent conversationnel ?