Aller au contenu principal

Concepts fondamentaux

Cinq mots portent tout le produit. Tout le reste de cette documentation est bâti dessus.

Organisation​

La frontière de facturation et de gouvernance. Elle détient les membres et leurs rôles, les identifiants des fournisseurs de modèles, les secrets et le journal d'audit. Toute donnée métier appartient à exactement une organisation, et le client de base de données ajoute cette organisation à chaque requête qui la touche. Les lectures inter-organisations ne sont pas une permission que l'on peut accorder. Chaque rôle est détenu dans une organisation et n'agit que sur elle.

L'édition Community autorise une seule organisation. Héberger plusieurs organisations sur une même instance relève d'Enterprise.

Projet​

L'espace de travail d'une équipe à l'intérieur d'une organisation, avec ses propres agents, collections de connaissances, serveurs MCP, skills et clés d'API. Un projet a ses propres membres et son propre propriétaire : on peut donc donner un espace à une équipe sans lui donner l'organisation.

Agent​

Ce que vous configurez : des instructions, un modèle principal, des modèles de repli facultatifs, les connaissances qu'il peut lire, les outils qu'il peut appeler, les skills qu'il peut charger et les garde-fous qui l'encadrent. On n'exécute jamais un agent directement : ce qui s'exécute est toujours une version.

Version​

Un instantané gelé de la configuration d'un agent, avec un auteur, une date et une note facultative. Les versions sont immuables : on ne les modifie jamais, et restaurer une ancienne version en crée une nouvelle au lieu de revenir en arrière. Les skills sont résolus à la création de chaque exécution : l'exécution enregistre les versions de skill qu'elle a reçues, et un rejeu refait exactement ce qu'elle a fait. Une nouvelle version d'un skill s'applique aux exécutions suivantes, même sous une version d'agent inchangée.

C'est ce qui rend un agent auditable. Des mois plus tard, vous pouvez retrouver la version exacte sur laquelle une conversation a tourné, et chaque exécution conserve les accès qui lui ont été donnés.

Exécution​

Chaque fois qu'une version travaille, par exemple pour répondre à un message, ce travail est une exécution, enregistrée comme une suite d'événements en ajout seul. Une exécution porte ses propres droits, gelés à sa création : si vous élargissez les accès d'un agent pendant qu'une exécution est en cours, celle-ci conserve les accès avec lesquels elle a démarré.

Les exécutions résistent aux pannes. Le moteur repose sur un journal d'événements, avec une clé d'idempotence par étape : une exécution rejouée après une panne ne répète pas un effet de bord déjà produit.

Comment ils s'emboîtent​

NiveauContientCloisonné par
OrganisationMembres, rôles, fournisseurs, secrets, journal d'auditRien au-dessus
ProjetAgents, collections, serveurs MCP, skills, clés d'APISon organisation
AgentVersions et droitsSon projet
VersionUne configuration geléeSon agent
ExécutionÉvénements, étapes, coûtsSa version
La règle à retenir

La configuration change, l'historique non. Vous pouvez modifier un agent quand vous le voulez : chaque enregistrement crée une nouvelle version, et les versions et exécutions déjà enregistrées restent telles qu'elles étaient.