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 par nœud, métriques, résultats, 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. Aucun modèle ne se trouve dans ce chemin.
-
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 est un travail nommé, avec un plan derrière — pas une fonctionnalité achevée, et nous préférons le dire.
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.
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 strict sur le nombre d'intrants, pour qu'une exécution ne puisse pas coûter discrètement plus que ce qui a été autorisé.
-
Un seul modèle de domaine compilé, pas une copie par invite
Les classes d'entités sont déclarées une seule fois, avec leurs propriétés typées et leurs classes de base, puis compilées dans la base de données de l'espace de travail et dans les registres de la plateforme. La même définition produit les artéfacts avec lesquels un agent travaille, y compris les schémas JSON qui encadrent ce qu'il peut retourner — un schéma et une table ne peuvent donc pas s'éloigner l'un de l'autre à la main.
-
Encadré par schéma à la sortie, validé à l'entrée
Un même schéma JSON encadre la sortie du modèle et valide la réponse reçue. Qu'un modèle ignore une consigne de format est un mode de défaillance connu ; c'est la validation côté client, contre ce même schéma, qui l'intercepte — plutôt qu'une table en aval.
-
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é.