Six niveaux, plusieurs points d’entrée
Les MCP sont configurés dans Galaris, avec des autorisations fines par agent, connexion et fonction. Le hub expose le catalogue autorisé aux moteurs configurés, dont Hermès, DSH, Codex, Claude et le harnais interne. Son chat et ses documents sont des solutions intégrées à cet écosystème.
L’OS agentique est le socle logiciel qui organise ces capacités au-dessus de votre infrastructure. Les applications Galaris en sont une interface ; les messageries et les clients API peuvent aussi accéder aux agents ou aux modèles.
| Niveau | Rôle | Position |
|---|---|---|
| Infrastructure | Serveurs, calcul, stockage, réseau et système hôte | Sous Galaris |
| Modèles et fournisseurs | Ollama, OpenRouter et endpoints compatibles, locaux ou distants | Services raccordés |
| Accès aux modèles | Passerelle API, inférences, événements, usage et coûts disponibles | Galaris |
| Exécution agentique | Identités, rôles, missions, délégation et harnais | Galaris |
| Services partagés | Mémoire, compétences, outils MCP, connexions et droits | Galaris |
| Applications | Discussions, objectifs, documents et processus | Applications Galaris et clients externes |
Ces niveaux décrivent des responsabilités, pas un passage obligé par chaque couche. Un client peut utiliser la passerelle LLM sans lancer d’agent ; une demande dans Telegram ou Nextcloud Talk peut mobiliser un agent sans ouvrir l’interface Galaris. Janus propose un frontal unique aux clients compatibles pour sélectionner un agent.
Le canal, le moteur et l’outil métier peuvent être choisis séparément : Telegram pour demander, Hermès Agent pour exécuter une tâche, Notion pour travailler sur des pages, avec les connexions nécessaires.
Trois couches, des responsabilités explicites
Les modules core fournissent l’infrastructure réutilisable, les modules app possèdent les domaines métier et les modules bridge adaptent les systèmes externes. Les surfaces stables passent par des contrats, façades ou interfaces publiques.
Préserver la conversation pendant les tâches
La conversation dispose de son propre ordonnanceur, distinct de celui des tâches. Le worker d’inférence laisse chaque appelant gérer ses limites de concurrence : les appels longs ne monopolisent pas une file commune qui ferait attendre les conversations. Cette séparation vise à préserver la disponibilité de l’échange pendant le travail de fond.
Il ne s’agit pas d’une préemption des appels déjà engagés chez les fournisseurs. Le temps de réponse dépend aussi du modèle, des ressources et des limites du fournisseur. La double boucle agentique explique comment consulter l’avancement, ajuster les consignes et demander l’arrêt depuis la conversation.
Le contrat des tâches reste indépendant du harnais
Avant le run d’une tâche, Galaris résout l’agent, le profil, le modèle, l’effort, le contexte, les droits, les outils et la politique d’exécution. Le driver reçoit une requête bornée. Son stream peut produire des événements, puis doit rendre exactement un résultat terminal et ne plus émettre après celui-ci.
La conversation suit un autre contrat : son contrôleur interne utilise le niveau textuel Low et ses outils bornés. Il peut persister une tâche, mais n’appelle jamais le harnais affecté à l’agent. Ce harnais n’est résolu qu’ensuite, par le chemin d’exécution de la tâche.
| Galaris conserve | Le runtime prend en charge |
|---|---|
| identité, objectif et révision | raisonnement et appels au modèle |
| catalogue d’outils effectif | protocole concret des outils exposés |
| checkpoint et politique de reprise | état de run compatible avec son driver |
| corrélation, coûts et résultat terminal | événements et usage de l’exécution |
Plusieurs familles de harnais derrière la façade tâche
Le runtime interne fondé sur Pydantic AI et les providers de harnais déclarés partagent les contrats de tâche de app.agent. Les fournisseurs de modèles restent des bridges séparés. Cette architecture permet de changer le moteur d’exécution d’une tâche sans déplacer la mission, la mémoire et les fichiers dans un nouveau silo.
Portabilité ne signifie pas équivalence
Chaque driver peut différer par ses capacités, son format de checkpoint, son isolation, sa supervision et son niveau de validation. La présence d’un provider dans le registre ne prouve pas qu’il est activé ni adapté à tous les cas.
Garder l’autorité au bon endroit
Tâche possède états, tentatives, leases et scheduler ; la façade Agent choisit et pilote l’exécution. Le harnais produit des événements et un seul résultat terminal. Messenger conserve le modèle canonique des échanges, les bridges traduisent leurs transports.
Les ressources gardent leur URI de Tool. Un temporaire matérialisé pour une bibliothèque ne devient pas un stockage durable. Le domaine Process suit l’exécution externe ; les callbacks mettent à jour son état sans remplacer un terminal par un événement tardif.
Les contrats d’intégration · Le cycle des fichiers
Un contrat de fin et de reprise commun
Un résultat final n’est accepté qu’après fermeture normale du flux et nettoyage. Un résultat absent, répété ou suivi d’un autre événement provoque un échec de protocole. Les limites de durée, d’inactivité et de volume suivent la politique du harnais.
Chaque driver interprète ses propres checkpoints et indique si une reprise est sûre, à vérifier ou interdite. L’annulation distingue demande, confirmation et issue inconnue, ainsi que portée locale et distante. Le Harness Manager propose diagnostic, configuration et archive d’installation ; télécharger cette archive n’exécute pas d’installation distante.
Des médias attachés à leur message d’origine
Le moteur interne prépare les médias sous les droits de l’agent, en donnant priorité aux messages courants puis à l’historique récent. La préparation ne matérialise chaque URI qu’une fois dans son budget d’octets et nettoie les fichiers temporaires.
Les entrées déjà transmises restent dans le checkpoint et sont réutilisées à la reprise. Cette continuité ne transforme pas une URI textuelle en téléchargement implicite et ne promet pas les mêmes capacités pour tous les moteurs.