Rédigé avant la mise en production, calculé ensuite
Une installation JetStore comporte deux parties. La plateforme est le logiciel de JetStore : un moteur de chaînes de traitement de données, un moteur de règles, une base de données et les services qui les entourent. L'espace de travail est ce qui fait d'une installation la vôtre. La place de l'IA dépend du moment dont il est question — pendant la rédaction de votre espace de travail, ou une fois qu'il s'exécute.
-
Votre espace de travail
Ce qui le rend vôtreUn ensemble de fichiers déclaratifs — modèle de données, règles, tables de référence, chaînes de traitement, configuration des processus et rapports — compilés et versionnés. Chaque fichier énonce ce qui doit être vrai ou ce qui doit se produire, et la plateforme fait le reste. Vos données sont définies une seule fois, et les tables et les règles de la plateforme sont construites à partir de cette définition unique.
-
Rédigé à l'installation
Avant la mise en productionArtiSoft utilise un modèle de pointe pour rédiger l'essentiel de vos règles, de vos chaînes de traitement et de vos gabarits — le travail qui a toujours rendu un moteur de règles coûteux à adopter. Chaque fichier de règles, modèle de données et configuration de chaîne de traitement qu'il rédige passe par le même compilateur et le même validateur que le travail d'une personne, et rien n'est déployé avant que vos équipes ne l'aient révisé et approuvé. Le modèle travaille sur votre configuration et n'a pas besoin d'accéder aux données des membres.
-
Exécuté par la plateforme
Après la mise en productionUne fois votre espace de travail approuvé, le travail du modèle de pointe est terminé. Les règles et les chaînes de traitement calculent : les fichiers sont analysés, mis en correspondance et épurés par les étapes de la chaîne de traitement, et les règles dérivent les faits de chaque membre. Lorsqu'une étape a besoin d'un modèle, c'est un modèle que vous hébergez, et rien n'est envoyé à un fournisseur externe d'IA. Certains produits n'utilisent aucun modèle à l'exécution — AgentBrief construit la fiche synthèse de chaque membre avec des règles et un gabarit fixe.
Un modèle de pointe rédige l'essentiel de l'espace de travail avant la mise en production. Après la mise en production, la plateforme l'exécute, et un modèle que vous hébergez est circonscrit aux étapes qui en ont besoin. La question n'est plus qui, ici, sait écrire cette règle, mais est-ce la règle que nous voulons.
Deux moteurs, et une frontière nette entre les deux
Un système agentique appliqué aux opérations de données demande cinq couches : observation, raisonnement, supervision, action et audit. Dans JetStore, quatre des cinq correspondent déjà à du code qui s'exécute — les couches déterministes, c'est la plateforme. La couche de raisonnement est ce que les travaux agentiques ajoutent, et la frontière entre elle et tout le reste, c'est là que se joue la conception.
-
Observation
DéterministeLe registre d'exécution appartient à la plateforme elle-même : état des exécutions, détail d'exécution par nœud, erreurs de traitement, registres des intrants et des sessions. C'est un portrait presque complet de ce qu'une chaîne de traitement a fait, et un portrait partiel de ce qui s'y est mal passé — et ce qui se construit par-dessus est conçu en tenant compte de cet écart plutôt qu'en le contournant.
-
Raisonnement
CognitifUn serveur d'inférence sur GPU, et un opérateur de chaîne de traitement qui l'appelle une fois par enregistrement. Autour d'eux se trouve l'environnement d'exécution pour lequel ces travaux ont été conçus : le registre d'outils, les contrats du modèle de domaine, le point d'application des paliers, le banc d'évaluation et une boucle proposer–vérifier–corriger. Aucun cadre agentique n'est une dépendance de quoi que ce soit là-dedans.
-
Supervision
PartagéeLes utilisateurs, les rôles et les vérifications par capacité se trouvent déjà dans le serveur d'API, et l'autorité d'un agent est conçue pour s'appuyer sur ce même modèle de capacités : l'identité d'un agent est un utilisateur doté d'un ensemble de capacités, de sorte que ce qu'il ne peut pas faire découle du modèle d'accès plutôt que de ses instructions. La moitié tournée vers l'agent — là où une étape autonome est classée par palier et approuvée — est ce que les travaux agentiques ajoutent.
-
Action
DéterministeExécution du DAG Compute Pipes, compilation de l'espace de travail, orchestration. Une étape qui a une seule bonne réponse est calculée ici plutôt qu'inférée, au volume réel auquel les données arrivent. Rien dans cette couche n'est inféré.
-
Audit
PartagéUn journal d'audit dédié, dont les points d'appel écrivent avant la vérification d'accès et avant l'action, dans un flux de journalisation qui ne peut pas être modifié après coup. Rendre ce registre durable en cas de panne, porteur du résultat de l'action et interrogeable par le produit lui-même.
Rien dans cette liste ne demande à un modèle de faire le travail d'une plateforme de calcul. Ce qui coûte cher et se prête aux erreurs, dans le traitement des données de réclamations, ce n'est pas la rédaction : c'est l'assemblage, à partir de flux bruts, d'une vue longitudinale juste, dédoublonnée, codifiée et dotée des calculs d'observance. Les règles font cela, de façon déterministe. Il reste au modèle à mettre en forme un intrant déjà juste, ou à raisonner là où aucune réponse déterministe n'existe.
Un modèle de pointe se rend utile à un autre moment : avant la mise en production, en rédigeant l'essentiel de votre espace de travail, comme le décrit plus haut comment se construit une installation. Il ne se trouve pas dans la chaîne de traitement à l'exécution.
Le modèle est un opérateur de la chaîne de traitement
L'inférence n'est pas un service externe que la chaîne de traitement appelle en espérant une réponse. C'est une étape du DAG, avec la même surface de configuration, le même traitement des erreurs et les mêmes contrôles de coûts que toutes les autres étapes — et elle est construite et testée plutôt que planifiée.
-
L'inférence par enregistrement, avec la plomberie déjà autour
Des gabarits d'invite avec espaces réservés par colonne et par enregistrement complet, compilés au moment de la construction. Sortie structurée par schéma JSON. Report de la réponse dans l'enregistrement par chemin pointé, avec conversion typée. Un bassin de travailleurs, des reprises avec attente progressive, un canal d'erreurs dédié — et un plafond sur le nombre d'enregistrements envoyés au modèle, de sorte que le coût d'une exécution est borné ; les enregistrements au-delà du plafond poursuivent leur chemin sans la réponse du modèle.
-
Un modèle de domaine, déclaré une seule fois
Le modèle de domaine est déclaré une seule fois et compilé dans les tables de la base de données, les types du moteur de règles et les registres de la plateforme. Pour la couche agentique, chaque entité est écrite une seule fois et six artéfacts en sont générés — la classe du langage de règles, un schéma JSON, une table de base de données, des marqueurs de classification des données, des signatures d'outils et un fichier de métadonnées —, avec une vérification qui fait échouer la construction s'ils divergent.
-
Encadré à la sortie, vérifié à l'entrée
La réponse d'une étape de modèle est encadrée par une forme déclarée, et ce schéma est écrit avec la chaîne de traitement. Chaque valeur reçue est vérifiée et convertie au type qu'attend sa colonne. Un enregistrement en échec est signalé sur un canal d'erreurs, et l'auteur de la chaîne de traitement décide s'il est écarté, s'il arrête l'exécution ou s'il poursuit son chemin sans la réponse du modèle.
-
Un moteur de rendu déterministe, quand un gabarit est la meilleure réponse
Parfois, le constat est que l'inférence n'est pas du tout le bon moteur de rendu. Une étape de rendu pilotée par configuration applique un gabarit à un enregistrement dans la chaîne de traitement en cours, et toutes les défaillances que ce moteur admet sont des échecs de construction plutôt que d'exécution. C'est un constat sur lequel la plateforme peut agir au lieu de le contester, et c'est le constat derrière AgentBrief.
Le compilateur est le réviseur
Presque personne, parmi ceux qui construisent un produit agentique, ne dispose d'un vérificateur gratuit, déterministe et à fort signal pour les artéfacts que son agent est censé rédiger. Un compilateur de règles et un validateur de configuration de chaîne de traitement sont exactement cela. Bâtir toute la stratégie de modèle autour d'eux, c'est la différence entre une démonstration et quelque chose que vous pouvez présenter à un ingénieur.
-
Un contrat de sortie
Tout artéfact rédigé par un agent — une configuration de chaîne de traitement, un modèle de domaine, un fichier de règles — passe par un compilateur qui décide s'il est bien formé. La qualité est mesurable dès le premier jour, sans bibliothèque de cas de référence, sans historique d'incidents et sans fonction d'évaluation à inventer d'abord.
-
Un signal de correction au moment de l'inférence
Générer, compiler, renvoyer le texte d'erreur du compilateur lui-même sous forme d'invite de correction structurée, reprendre dans une limite fixée d'itérations. Ces messages font de bonnes invites de correction parce qu'ils ont été écrits pour des personnes : nommez une colonne qu'un gabarit ne possède pas, et l'erreur de construction énumère celles qu'il possède.
-
La vérification s'exécute en parallèle, donc la génération aussi
Les deux moteurs de règles valident en simultané, avec isolation des sessions : un lot de candidats peut donc être vérifié d'un coup. Échantillonner plusieurs candidats et garder ceux qui compilent vaut généralement mieux, pour un budget de jetons fixe, que plusieurs tours de correction sur un seul candidat, parce que les échecs sont des tirages indépendants plutôt qu'une même erreur corrigible.
-
La rédaction est vérifiée par la machine avant d'être vue par une personne
Les règles et les configurations de chaîne de traitement sont écrites avec un copilote dont la sortie passe d'abord le compilateur : le réviseur consacre donc son attention à savoir si la logique est juste, non à savoir si le code s'analyse. Ici, la révision humaine est structurelle — une propriété du flux de travail, pas un contrôle ajouté par-dessus.
-
Un seul catalogue d'outils, deux consommateurs
La frontière d'outils est MCP — un protocole de communication relevant de l'Agentic AI Foundation de la Linux Foundation, avec une garantie de compatibilité v1 sur son SDK Go, adopté comme protocole et non comme cadre dans l'environnement d'exécution. Un seul registre d'outils nommés, typés d'après les entités du domaine, sert un modèle de pointe pendant la conception des travaux, et le modèle interne lorsqu'ils s'exécutent.
Évalué par rapport au code le 11 septembre 2026 : deux des trois rôles du vérificateur sont réalisés, soit le contrat de sortie et le signal de correction. Le troisième — le même compilateur utilisé comme signal d'entraînement pour le modèle interne — n'attend qu'une dépendance plutôt qu'une décision, et nous préférons le nommer que le compter.
Une inférence que vous hébergez, et un point de jonction s'il vous faut autre chose
ArtiSoft recommande JetStore Agentic AI : la couche de raisonnement s'exécute sur une inférence que vous hébergez, de sorte qu'aucun fournisseur externe de LLM n'est requis et qu'aucun renseignement de santé protégé (PHI) ne quitte votre VPC.
Lorsque les exigences d'un client appellent un modèle différent ou externe, la couche d'inférence se trouve derrière une interface de moteur d'inférence : le modèle est alors un choix de configuration par agent plutôt qu'une reconstruction.
-
La neutralité à l'égard des fournisseurs est le produit, pas un réglage
Aucun fournisseur externe de LLM. Aucun renseignement de santé protégé ne quitte votre VPC. C'est déjà l'essentiel de la réponse à une revue de sécurité, et c'est la raison pour laquelle la couche de raisonnement a été bâtie pour s'exécuter sur une inférence que vous hébergez — un cadre provenant d'un grand fournisseur, installé dans l'environnement d'exécution, c'est une réponse à donner à chaque revue, pour une capacité que vous auriez pu écrire vous-même.
-
Un modèle de pointe enseigne ; votre inférence sert
La place du modèle de pointe est en amont — concevoir les règles, les invites, les gabarits et les cas de référence, là où sa production est révisée avant de s'exécuter plutôt qu'après. Comme le catalogue est exposé au moyen de MCP, il peut faire ce travail avec les véritables outils, et les artéfacts sont transférés au modèle local sans réécriture.
-
Le moteur d'inférence est un point de jonction, et ce point de jonction est livré
La plomberie d'inférence commune — bassin de travailleurs, reprises, canal d'erreurs, report des réponses — a été extraite derrière une interface commune : une pile de service devient un choix de configuration à une seule frontière plutôt qu'une modification à faufiler dans toute la chaîne de traitement. Comme les agents s'exécutent comme des étapes de la chaîne, deux variantes peuvent traiter les mêmes données et être comparées par la mesure au lieu de faire l'objet d'un débat.
-
Un périmètre défini, et énoncé
Un petit modèle hébergé chez vous n'égalera pas le raisonnement d'un modèle de pointe sur une analyse des causes fondamentales ouverte, et cette plateforme ne prétend pas le contraire. La conception limite le modèle local aux tâches pour lesquelles un vérificateur existe, et dit explicitement quelles tâches restent à une personne. C'est une promesse plus étroite que la parité, et bien plus défendable.
Ce qui est livré, c'est l'interface. Quel modèle, quelle pile de service et quelles étapes restent humaines sont des décisions de cadrage propres à votre déploiement — nous préférons les régler avec vos données et votre processus de révision plutôt que de cocher une case ici.
Il s'exécute dans votre environnement, à l'intérieur du périmètre que vous maintenez déjà
JetStore se déploie dans votre propre compte infonuagique. Les données que vous contrôlez y restent, et aucun renseignement de santé protégé (PHI) ne parvient à ArtiSoft — ce qui écourte considérablement la discussion sur la conformité.
-
Votre périmètre de conformité, pas un second
Comme JetStore s'exécute dans votre environnement, il fonctionne à l'intérieur des contrôles et du périmètre de vérification que vous maintenez déjà. Nous accompagnons des clients qui maintiennent la certification HITRUST CSF, et JetStore s'exécute dans ce périmètre au même titre que le reste de leur pile.
-
ArtiSoft ne détient aucune certification HITRUST, et n'en a pas besoin
La certification vise un environnement qui traite les données. ArtiSoft ne traite pas les vôtres : aucun PHI ne nous est transmis, il n'existe donc aucun périmètre du côté d'ArtiSoft qu'une certification pourrait couvrir. Un fournisseur qui vous dit le contraire décrit une autre architecture.
-
Aucun fournisseur externe de modèle dans le parcours
La couche de raisonnement s'appuie sur une inférence que vous hébergez. Rien d'une exécution n'est envoyé à une API de modèle tierce : aucun sous-traitant à ajouter à un schéma de flux de données, aucune sortie de données à justifier.
-
L'accès est contrôlé par capacité, action par action
Les utilisateurs, les rôles et les vérifications par capacité sont déjà dans le serveur d'API, et l'autorité des agents est conçue pour s'appuyer sur ce même modèle de capacités plutôt que sur un modèle parallèle.
Ceci décrit où le logiciel s'exécute et ce qu'il ne reçoit pas. Il ne s'agit pas d'un avis juridique : la conclusion pour votre déploiement appartient à votre équipe de conformité.