osFoundry / Platform
Configs d'agents
Modifiez le nom, le modèle, les outils, le prompt et la politique de tout agent en tant qu'enregistrement versionné. Forkez, publiez, partagez.
Présentation
Une config d'agent dans osFoundry, c'est la définition complète d'un agent IA conservée comme un seul enregistrement modifiable : son nom, le modèle sur lequel il s'exécute, les outils qu'il peut appeler, son system prompt et la politique qui régit ce qu'il a le droit de faire. Au lieu d'éparpiller ces réglages entre le code, des fichiers de configuration et le tableau de bord d'un fournisseur, vous les modifiez au même endroit et chaque changement est enregistré comme une version. Vous pouvez voir à quoi ressemblaient le prompt ou la liste d'outils d'un agent il y a trois modifications, comparer avec l'état actuel et revenir en arrière si un changement l'a dégradé.
Comme osFoundry fonctionne avec vos propres clés (BYOK) et privilégie le local, la config pointe vers le modèle de votre choix : un modèle local sur votre machine, un modèle cloud via votre propre clé d'API ou un endpoint auto-hébergé, sans revendeur intermédiaire. Changer le modèle d'un agent, c'est un champ de la config, pas une réécriture : gardez le même prompt, les mêmes outils et la même politique, puis essayez-le sur un autre modèle pour comparer coût et qualité. Le champ politique est l'endroit où vous posez les garde-fous : quels outils exigent une approbation, ce que l'agent peut toucher, de sorte que le comportement et les autorisations voyagent avec l'agent au lieu de résider ailleurs.
Les configs sont faites pour circuler. Forkez n'importe quel agent pour obtenir une copie indépendante que vous pouvez modifier sans affecter l'original, publiez une version quand elle est solide et partagez-la pour qu'un collègue ou un autre espace de travail exécute le même agent. Le versionnage fait d'une config partagée un état précis et reproductible, non une cible mouvante : la personne à qui vous la remettez obtient exactement le modèle, les outils, le prompt et la politique que vous avez testés, et peut la forker pour se l'approprier.
Fonctionnalités clés
- Modifiez le nom, le modèle, les outils, le system prompt et la politique d'un agent depuis un seul enregistrement, au lieu de fichiers et tableaux de bord dispersés
- Chaque changement est enregistré comme une version : vous pouvez revoir l'historique, comparer les modifications et revenir sur un changement de prompt ou d'outils qui a tout dégradé
- Changez le modèle sous-jacent de n'importe quel agent via un seul champ et réutilisez le même prompt et les mêmes outils pour comparer modèles locaux, cloud et auto-hébergés
- Forkez n'importe quelle config en une copie indépendante, puis publiez une version et partagez-la pour que d'autres exécutent exactement l'agent que vous avez testé
- Fonctionne avec vos propres clés d'API et peut utiliser des modèles locaux : la définition d'un agent et ses données restent sur votre appareil, sans frais par siège ni marge
Cas d’usage
- Ingénieur prompt : itérez le system prompt d'un agent sur une douzaine de versions, comparez-en deux et revenez à la formulation qui a obtenu le meilleur score
- Chef d'équipe : publiez un agent de support validé avec une politique verrouillée, puis laissez chaque collègue le forker pour son propre flux sans casser l'original
- Développeur soucieux des coûts : gardez fixes le prompt et les outils d'un agent et changez seulement le modèle pour comparer un modèle local à une clé cloud sur la même tâche
Questions fréquentes
Que contient exactement une config d'agent ?
Cinq éléments dans un seul enregistrement versionné : le nom de l'agent, le modèle sur lequel il s'exécute, les outils qu'il a le droit d'appeler, son system prompt et sa politique (les règles et approbations qui régissent ce qu'il peut faire). Modifier l'un d'eux crée une nouvelle version que vous pouvez consulter ou annuler.
Puis-je changer le modèle utilisé par un agent sans le réécrire ?
Oui. Le modèle est un champ de la config. Pointez le même agent vers un modèle local, un modèle cloud via votre propre clé d'API ou un endpoint auto-hébergé, en gardant intacts son prompt, ses outils et sa politique, ce qui facilite la comparaison de modèles sur des configurations identiques.
Quelle est la différence entre forker et partager une config ?
Forker crée une copie indépendante que vous pouvez modifier librement sans toucher à l'original. Partager remet à quelqu'un une version publiée à exécuter telle quelle. Comme les configs sont versionnées, un agent partagé est un état précis et reproductible : le destinataire peut le forker s'il veut le modifier.