Approche technique

L’OS agentique pour vos applications et vos agents

Galaris fournit un socle commun aux modèles, agents, services et applications. Vos systèmes peuvent utiliser ses API et vos messageries peuvent accéder à vos agents.

Un socle utilisable depuis plusieurs interfaces

Les six niveaux de l’OS agentique relient infrastructure, fournisseurs de modèles, accès aux inférences, exécution des agents, services partagés et applications. Un client externe peut appeler la passerelle LLM sans adopter l’interface Galaris ; Nextcloud Talk, Matrix, OneBot et Telegram peuvent servir d’entrée à vos agents.

Les API et Janus donnent accès au niveau utile. Janus se configure comme un seul modèle frontal dans un client compatible, puis passe la main à l’agent sélectionné. Les canaux et outils expliquent comment combiner ce socle avec vos systèmes métier.

Voir tout l’écosystème

Pour une tâche, le harnais exécute. Galaris garde la responsabilité.

Le contrôleur conversationnel reste interne ; seules les tâches passent par le harnais affecté à l’agent.

Avant le run d’une tâche, Galaris résout l’agent, le modèle, l’effort, le contexte, les droits, les outils et la politique d’exécution. Le harnais reçoit ensuite une enveloppe bornée et sans secrets. Il peut diffuser des événements, mais doit rendre exactement un résultat terminal.

Le choix du harnais appartient à la configuration de tâche de l’agent. Sa politique borne le Planner, le Briefing, le workspace, les outils, le streaming et l’annulation de ce travail durable. Il n’intervient jamais dans un round conversationnel. Changer de harnais ne déplace donc ni la mission, ni la mémoire, ni les fichiers, ni l’audit vers un nouveau silo.

Les invariants qui font la différence en production

Invariant Mise en œuvre Effet concret
Un travail est durable État, tentative, bail, attente, annulation et résultat vivent dans PostgreSQL. Un redémarrage ne transforme pas une mission en conversation perdue.
Un effet n’est pas rejoué au hasard Dans le harnais interne, les appels à effets durables sont journalisés avant et après l’exécution. Un envoi ou une écriture dont l’issue est inconnue bloque la reprise automatique.
Un outil interdit reste invisible Le catalogue d’une tâche croise RBAC, agent, connexion, fonction, harnais et portée. La conversation possède sa propre projection bornée. La découverte différée ne devient pas un canal latéral d’accès.
Un livrable doit exister Le Working Set distingue source, version, artefact, destination et reçu. Le texte du modèle ne peut pas, seul, déclarer un fichier livré.
Un résultat terminal est unique Le contrat de stream accepte des événements puis exactement un résultat final. Les consommateurs ne devinent jamais si l’exécution est réellement terminée.
Le coût garde son contexte Les appels conservent l’usage et les coûts disponibles, avec leur qualification : connus, estimés ou incomplets. Les arbitrages deviennent possibles par agent, surface, harnais de tâche et résultat utile.

Trois machines adaptées à trois temporalités

Galaris ne force pas toutes les interactions dans une boucle universelle.

Temps court

Conversation sans harnais

Le contrôleur interne gère fraîcheur, déduplication et admission explicite d’une tâche ou d’un Process.

Temps durable

Tâche avec harnais

Après sa création, un scheduler, le harnais résolu, les baux, tentatives, plans et checkpoints encadrent le travail de fond.

Temps réel

Voix

Une machine dédiée traite latence et interruption sans transformer chaque prise de parole en erreur de tâche.

Une conversation ou un appel vocal peut créer une tâche ou un Process. Le harnais de l’agent n’est appelé qu’ensuite, et seulement pour la tâche nouvellement persistée. Il ne traite jamais le round conversationnel ou vocal qui l’a créée.

Mémoire, fichiers et contexte restent des domaines séparés

La mémoire n’est ni un historique de chat ni le stockage principal de tous les documents. Pour une tâche, Galaris compose avant le harnais un contexte commun : historique canonique, mémoires autorisées et Working Set versionné. Le contrôleur conversationnel compose séparément son propre contexte. Les ACL s’appliquent avant la similarité, et les ressources circulent par URI canoniques plutôt que par chemins hôte remis au modèle.

  • La session n’est pas la mémoire. Le récent sert l’échange ; le durable exige provenance, utilité future et droits.
  • La mémoire n’est pas la source métier. Tâches, objectifs et processus restent propriétaires de leurs données.
  • Le fichier temporaire n’est pas une identité. Les octets sont streamés ou matérialisés dans un espace borné, puis nettoyés.
  • Un graphe ne contourne pas les ACL. Les liens confirmés réappliquent les mêmes frontières d’accès.

Objectifs, processus et amélioration contrôlée

Un objectif récurrent crée des cycles discrets, chacun sous la forme d’une tâche ordinaire. Un juge séparé enregistre preuves, progression et décision de poursuivre ou d’arrêter. Une question humaine devient une attente durable avec rappels bornés, pas un worker immobilisé.

Les processus externes longs possèdent leur propre identifiant, leur clé d’idempotence et leurs événements. Le Lab, lui, transforme des exécutions réelles en évaluations versionnées et reprenables : une panne du candidat, une sortie faible et une panne du juge restent trois situations distinctes.

Exploiter le système, pas seulement lancer une démo

La stack de référence est conteneurisée. PostgreSQL et pgvector portent l’état durable, les baux, la mémoire et les traces. Les identifiants relient tâche, tentative, run, appel de modèle, outil, processus, message et livrable. Les contrôles de santé distinguent les composants critiques des bridges facultatifs dégradés.

La supervision des harnais expose une façade commune — statut, démarrage, arrêt, redémarrage, mise à jour et logs — tout en laissant chaque bridge responsable de son protocole et de sa configuration native.

La frontière d’architecture

Le contrôleur converse, le harnais exécute une tâche, Galaris conserve l’autorité.

Le contrat commun conserve la mission et son résultat. La reprise d’effets, l’isolation et les capacités doivent être qualifiées pour chaque harnais.

Approfondir l’évaluation

Maturité et limites

Galaris évolue rapidement. Plusieurs familles de harnais de tâches existent derrière les mêmes contrats, mais leur niveau de validation, leurs capacités et leur mode de déploiement peuvent différer. Les intégrations, politiques d’approbation, limites de charge, sauvegardes, restaurations et engagements d’exploitation doivent être vérifiés sur l’instance évaluée.

Une plateforme à évaluer sur ses frontières

Les modèles peuvent être servis à des clients externes ; les agents peuvent aussi être exposés comme modèles, avec exécution adossée à une tâche. L’endpoint MCP d’un agent expose ses capacités autorisées. Ces trois accès ont des responsabilités distinctes.

Les fichiers gardent leur provider d’origine, les processus leur moteur, et Galaris conserve les objets de coordination. Ce découpage permet d’examiner droits, coûts et reprise à chaque frontière.

Inventaire des outils · Comparaison des approches

Les inférences durables ajoutent requête figée, tentatives, flux relisible et commandes de contrôle à la passerelle de modèles. Cette couche reste distincte de la tâche, de ses outils et de la livraison de ses fichiers.

Applications documentaires et médias natifs

Le SDK navigateur galaris.datasets relie les pages HTML aux données JSON sous droits et consentement versionné. Il est distinct des 131 fonctions MCP natives. Les entrées multimodales du moteur interne croisent capacités du modèle et du transport. API et SDK · Modèles et moteurs.