Environnements isolés : des ressources, pas une base permanente

Un environnement isolé devrait être un lieu où un agent d’IA travaille, non l’endroit où il demeure en permanence. Séparez le contexte durable de l’agent, ses données de suivi et son travail continu de la machine utilisée pour une tâche. Traitez ensuite les environnements isolés comme des ressources d’exécution : utilisez une capacité de calcul supérieure pour les travaux plus exigeants et des environnements plus légers pour les tâches simples.

Il s’agit d’une frontière de conception, non d’une règle selon laquelle chaque tâche exigerait une nouvelle machine ou chaque environnement isolé devrait être sans état. L’objectif est d’éviter que la santé d’un système d’agents d’IA dépende de l’état et de la configuration d’un ensemble grandissant de machines individuelles.

Quand un parc de VM devient difficile à exploiter

Attribuer sa propre VM à chaque agent d’IA peut fonctionner à petite échelle. L’agent a un endroit où s’exécuter, ses outils sont à proximité et une personne responsable de l’exploitation peut examiner la machine en cas de défaillance. À mesure que le parc s’agrandit, ce modèle peut transformer l’entretien courant des machines en entretien continu des agents.

Selon le témoignage de l’équipe QM, plus de 50 agents Hermes s’exécutaient dans des VM. L’équipe trouvait ces agents utiles, mais le parc était difficile à configurer et à gérer. Une personne responsable devait se connecter en SSH à chaque instance pour la corriger, ce qui a été décrit comme un problème sans fin où il fallait régler les problèmes une instance après l’autre.

Le problème ne tenait pas seulement au nombre de machines. Le travail continu de l’agent était lié à l’état et à la configuration d’une machine donnée. Lorsque le contexte persistant, les données opérationnelles et l’exécution des tâches cohabitent, chaque machine devient une base individuelle qui doit rester en bon état.

Une frontière plus nette sépare deux éléments :

• Travail durable de l’agent d’IA : le contexte, les données de suivi et la continuité opérationnelle dont l’agent a besoin d’une tâche à l’autre.
• Exécution des tâches : l’environnement de calcul utilisé pour une unité de travail.

Cette séparation n’élimine pas le travail opérationnel. Elle déplace le centre durable de l’agent hors de la machine qui exécute la tâche, afin que la plateforme puisse gérer la capacité d’exécution comme un ensemble partagé de ressources plutôt que comme une collection de bases permanentes.

Ce que montre l’exemple de QM

QM a expliqué avoir retiré le « cerveau » du système de l’environnement isolé et placé ses informations dans une base de données. Dans ce modèle, un environnement isolé n’est pas principalement l’endroit où vit un agent d’IA. C’est une ressource que l’agent peut utiliser au besoin.

Il s’agit d’une architecture observée pour des plateformes internes d’agents d’IA, et non d’une preuve que toutes les plateformes devraient fonctionner ainsi. Elle montre toutefois pourquoi une équipe peut vouloir que le travail durable de l’agent survive à la réparation, au remplacement ou à la réaffectation d’un environnement d’exécution.

Le même témoignage comporte une limite importante : QM utilisait toujours un environnement isolé par défaut attribué à l’utilisateur que l’agent servait. Séparer le travail durable n’exige pas de supprimer les environnements par défaut ni de provisionner un nouvel environnement pour chaque tâche. Un environnement par défaut peut rester utile, tout en permettant au système de choisir un autre environnement lorsque le travail l’exige.

La question de conception essentielle est la suivante : quelles parties d’un agent d’IA doivent persister hors d’un environnement isolé, et quand le travail devrait-il s’exécuter ailleurs que dans l’environnement par défaut ?

Adapter la capacité de l’environnement isolé à la tâche

La capacité d’exécution devrait correspondre au travail à accomplir. Dans la situation de QM, un agent chargé d’une lourde charge de travail de développement pouvait utiliser une machine disposant de davantage de ressources. Pour une tâche plus simple, il pouvait choisir un environnement isolé moins puissant.

Cette comparaison importe, car un environnement fixe peut échouer de deux façons :

• Une plateforme peut surallouer des ressources en utilisant son environnement le plus puissant pour chaque tâche, même lorsque des travaux simples n’en ont pas besoin.
• Une plateforme peut sous-allouer des ressources en forçant chaque tâche à s’exécuter dans le même environnement léger, même lorsque des travaux de développement plus exigeants demandent davantage de capacité.

QM a confié la décision de sélection à l’agent plutôt qu’au système d’orchestration, c’est-à-dire le système qui exécute et coordonne l’agent. Le témoignage décrit cette approche comme puissante. Il faut la considérer comme une approche observée, et non comme une règle universelle : les éléments disponibles ne fournissent ni politique d’ordonnancement, ni spécifications de ressources, ni évaluations comparatives, ni comparaison directe avec une sélection centralisée.

Pour les équipes responsables de plateformes, la leçon utile consiste à faire de la sélection de l’environnement un choix de conception explicite, plutôt qu’une conséquence accidentelle de l’environnement auquel un agent est affecté.

Encadrer et rendre observable la sélection

Les étapes suivantes sont des recommandations de conception fondées sur l’architecture observée, et non une description de l’implémentation de QM.

Séparer le travail durable avant de modifier les choix de ressources

Commencez par identifier ce qui ne doit pas disparaître lorsqu’un environnement d’exécution doit être réparé, remplacé ou réaffecté. Conservez ce travail durable de l’agent hors de la machine qui exécute la tâche.

Cela ne signifie pas que chaque environnement isolé est jetable. Certains environnements peuvent demeurer des environnements par défaut attribués, et certaines tâches peuvent nécessiter une continuité dans un même environnement. L’objectif plus restreint est d’éviter qu’une seule machine soit l’unique emplacement durable de la vie opérationnelle d’un agent d’IA.

Proposer un petit ensemble d’options d’environnement

Exposez un petit ensemble de choix compréhensibles plutôt qu’un catalogue ouvert de machines. Cela pourrait comprendre un environnement par défaut, une option plus puissante pour les travaux de développement exigeants et une option moins puissante pour les tâches simples.

Un ensemble limité rend les choix plus faciles à expliquer et à examiner. Il évite aussi que la sélection de l’infrastructure devienne une décision opaque fondée uniquement sur des étiquettes internes de machines.

Déterminer qui choisit l’environnement

Plusieurs modèles de sélection peuvent être raisonnables :

• Sélection dirigée par l’agent : l’agent choisit parmi les environnements autorisés selon sa compréhension de la tâche. Cela correspond à l’approche de QM.
• Sélection dirigée par la plateforme : la plateforme ou le système d’orchestration applique des règles définies de manière centralisée.
• Sélection dirigée par une personne : un utilisateur ou une personne responsable de l’exploitation choisit lorsque le travail présente un coût, un accès ou un risque opérationnel inhabituel.
• Sélection hybride : l’agent propose un choix dans un ensemble délimité, tandis que la plateforme impose des limites et transmet les exceptions pour examen.

Le matériel source ne montre pas qu’un modèle fonctionne le mieux dans tous les contextes. La sélection dirigée par l’agent peut être utile parce que l’agent connaît le contexte de la tâche, mais ce choix ne devrait pas être libre de contraintes par défaut. Une plateforme peut privilégier des règles centralisées pour assurer la cohérence, tandis qu’un choix humain peut convenir lorsqu’une personne doit exercer son jugement.

Consigner chaque décision d’environnement

Consignez la tâche, le choix et le résultat de chaque décision d’environnement, y compris qui ou quoi a fait ce choix. Ces données permettent d’examiner les exceptions récurrentes et de déterminer si les choix de ressources sont judicieux.

Le témoignage de QM indique que les traces pourraient en principe soutenir ce travail, mais que les résultats étaient mitigés. Les données consignées sont une condition préalable à l’apprentissage et à la gouvernance ; elles ne garantissent pas qu’une plateforme s’optimisera elle-même.

Définir les autorisations à la frontière

Lorsque le contexte durable se trouve hors des environnements isolés individuels, les autorisations prennent davantage d’importance. La quantité d’information qui peut entrer en toute sécurité dans le contexte durable d’un agent est limitée par la qualité du système d’autorisations.

Définissez des frontières d’accès explicites pour le contexte durable comme pour les environnements d’exécution. Demandez-vous quelles tâches peuvent lire ou modifier quelles données, et quels choix d’environnement entraînent des conséquences d’accès ou d’exploitation nécessitant une approbation supplémentaire.

QM a décrit l’accès à la base de données comme étant surtout en lecture seule, et les mises à jour en lot comme soumises à une validation humaine. Cela illustre l’intérêt de distinguer l’accès ordinaire des changements à plus fort impact. QM a aussi noté que les personnes peuvent approuver mécaniquement des actions soumises à examen ; une étape de validation doit donc comporter une décision claire, un contexte suffisant et une raison pratique d’intervenir.

Réduire le couplage sans éliminer les environnements par défaut utiles

Un agent d’IA peut conserver une continuité durable sans être attaché en permanence à une seule machine. Lorsqu’un parc devient difficile à configurer, à examiner et à réparer instance par instance, dissocier le travail durable de l’exécution des tâches peut réduire ce couplage.

Conservez un environnement isolé par défaut attribué à l’utilisateur là où il est utile. Offrez un petit ensemble d’alternatives pour les travaux nécessitant plus ou moins de capacité. Encadrez la sélection, rendez-la observable et tenez compte des autorisations, puis réévaluez-la à partir des résultats consignés plutôt que de supposer qu’un agent ou un ordonnanceur choisira toujours correctement.

Le témoignage de QM est un exemple utile de ce modèle opérationnel, et non une référence ou une prescription universelle. Sa leçon centrale est simple : séparez le travail durable de l’agent des ressources d’exécution choisies pour chaque tâche.