10 niveaux de Jev pour les ingénieurs agentiques

Un agent qui corrige un paiement passe aussi du temps à classer le ticket, sélectionner les fichiers, interpréter les tests et décider quand demander de l'aide. Ces petits jugements peuvent remplir son contexte avant même la première modification.

Jev, le modèle de décision de TypeSafe AI, permet de confier certains de ces jugements à un appel distinct. Le programme qui encadre l'agent transmet une question précise, puis lui retourne un résultat compact. Reste à choisir les décisions pour lesquelles cet appel supplémentaire vaut son coût.

La vidéo 10 Levels of Jev for Agentic Engineers d'IndyDevDan montre une progression de la classification aux questions choisies par l'agent. Nous examinons ces dix usages dans un workflow sur bureau cloud, avec leurs limites. Ce sont des pistes à évaluer, pas des fonctionnalités livrées dans SpineOS ni des mesures que nous avons reproduites.

Qu'est-ce que Jev apporte à un agent IA ?

Jev évalue un contexte fourni à partir de questions typées et retourne des décisions exploitables par du code. TypeSafe le présente comme un modèle System One. Trois primitives couvrent les propositions oui/non, le choix entre options et les notes sur une grille. Voir l'introduction officielle.

Le développeur fournit les informations et détermine ce que la réponse autorise. L'exploration du dépôt, l'exécution et la conservation d'une session restent à la charge du programme qui encadre l'agent.

1. Repérer les instructions suspectes

Une question oui/non peut signaler un contenu qui cherche à détourner l'agent de sa tâche. Un ticket peut, par exemple, demander d'ignorer les consignes et de divulguer des identifiants.

Séparez la tâche confiée, la provenance du texte et son contenu. Une demande légitime de modification de compte n'a pas la même autorité qu'une instruction trouvée dans une page consultée.

Le signal peut déclencher une revue ou limiter l'entrée du contenu dans le contexte. Les contrôles d'accès doivent empêcher la divulgation même si la détection échoue.

2. Classer les tickets avec des règles de priorité

Des questions Choice peuvent attribuer une catégorie et une priorité avant qu'un agent ouvre le ticket. Posez les deux questions sur le même état, avec des critères distincts.

Un export cassé dans un navigateur avec une solution de contournement diffère d'un paiement bloqué pour tous les clients. Écrivez ces distinctions dans les critères et prévoyez une option insufficient_information pour les signalements vagues.

C'est un bon premier essai : une personne peut vérifier le classement avant toute modification du code.

3. Décomposer le risque d'une modification

Plusieurs notes précises rendent une file de revue plus lisible qu'un jugement global. Une petite modification peut toucher les autorisations ; une grande peut concerner uniquement de la documentation générée.

Évaluez séparément l'exposition aux entrées non fiables, la portée du comportement modifié et la qualité de la vérification. Combinez les notes dans le code avec des coefficients documentés. La primitive Score accepte une grille ordonnée par question.

Gardez les obligations de revue indépendantes du total. Une modification des autorisations peut imposer une revue spécialisée même si sa moyenne est basse. Une note faible ne prouve pas la sécurité du correctif.

4. Utiliser l'incertitude pour demander une revue

L'incertitude peut décider de la suite : agir, recueillir des informations ou demander une revue. Un modèle reste ainsi utile lorsqu'il ne peut pas trancher.

Une étiquette de ticket sans effet direct peut être attribuée automatiquement. Une action destructive doit conserver ses exigences d'autorisation indépendamment de la réponse. Choisissez les seuils sur des exemples annotés et selon les conséquences d'une erreur.

La propriété confidence de Choice et Score résume leur distribution de probabilités. Ce n'est ni un intervalle de confiance statistique ni une probabilité universelle d'avoir raison. Noul retourne une probabilité de réponse positive sans champ de confiance distinct. La documentation de la confiance détaille cette différence.

5. Orienter la tâche vers le bon agent

Un routage peut sélectionner un agent capable avant de lancer le travail coûteux. Tenez compte des outils nécessaires autant que de la difficulté.

Vérifiez les capacités par du code avant le routage. Une classification ne donne ni navigateur ni autorisation d'accès. Comparez le coût de la tâche terminée, y compris les réorientations, au prix du premier appel.

6. Vérifier l'intention avant un appel d'outil

Jev peut signaler une intention risquée dans une commande ou une écriture, en complément des permissions d'exécution. Transmettez le répertoire de travail et les informations utiles sur les ressources concernées.

Supprimer des dépendances reproductibles diffère de supprimer l'unique historique d'une session. La commande seule ne permet pas toujours de distinguer ces situations.

Un classifieur n'est pas une frontière de sécurité. Expansions du shell, scripts, liens symboliques et changements du système de fichiers peuvent rendre une commande destructive. Appliquez les restrictions au moment de l'exécution, conservez les exigences d'approbation et soumettez les classifications incertaines ou indisponibles à une revue. Aucun autre outil d'exécution ne doit contourner ce contrôle.

Pour les écritures, protégez les chemins sensibles avec des permissions et une politique d'outils. Ces restrictions doivent tenir même si le modèle manque une modification suspecte.

7. Choisir quand compacter le contexte

Un modèle de décision peut repérer une bonne frontière de compaction après un seuil de contexte déterministe. Une investigation terminée suivie d'une nouvelle tâche constitue un moment plus adapté qu'un échec encore en cours d'analyse.

Envoyez un état réduit : occupation du contexte, objectif actif, étapes inachevées et transitions récentes. Demandez si le travail atteint un point stable. Le programme peut ensuite déclencher son mécanisme de résumé.

Conservez une limite dure pour éviter l'épuisement de la fenêtre. Le résumé doit préserver objectif, preuves, décisions en attente et références nécessaires à la reprise. Notre article sur le nettoyage de mémoire avec Jev traite des connaissances périmées entre sessions.

8. Trier les fichiers avant leur lecture par l'agent

Une classification par fichier peut présélectionner les lectures utiles. Un outil lit le fichier candidat, envoie son contenu à Jev et retourne une réponse courte à l'agent principal.

Demandez, par exemple, si un fichier calcule les arrondis de facturation ou quelle couche applicative il représente. L'agent lit ensuite les fichiers retenus avant de les modifier.

Le contenu reste hors du contexte principal, mais il est lu et transmis à un autre fournisseur. Appliquez les règles de traitement des données avant l'envoi. Ne transmettez pas un fichier suspecté de contenir des identifiants pour déterminer s'il en contient : commencez par les contrôles locaux et scanners approuvés.

Associez la réponse à une référence et à l'empreinte du fichier. Une classification ancienne ne décrit pas nécessairement le contenu actuel.

9. Analyser plusieurs fichiers avec une concurrence bornée

La même question peut filtrer un ensemble de candidats lorsque leur pertinence s'exprime mal par une recherche textuelle. Commencez par réduire le dépôt avec les noms, recherches et dépendances, puis classez les fichiers restants.

Limitez concurrence, taille des fichiers et total de tokens. Mettez les résultats en cache selon l'empreinte du contenu, la version de la question et celle du modèle. Signalez les fichiers ignorés, tronqués ou en échec : ils restent inconnus.

Mesurez le rappel : à quelle fréquence la sélection contenait-elle le fichier finalement nécessaire ? Un filtre rapide qui masque ce fichier peut rallonger le diagnostic. Pour trouver des marqueurs TODO explicites, une recherche textuelle suffit.

10. Laisser l'agent poser des questions sur les résultats

Un outil ask_jev limité peut aider l'agent à classer une sortie de test ou examiner une hypothèse. Il reçoit des références de sources approuvées et des questions bornées ; le programme résout leur contenu.

Après un test en échec, l'agent peut distinguer une assertion incorrecte, une dépendance indisponible et un dépassement de délai. Il inspecte ensuite les preuves pertinentes avant de proposer un correctif. Gardez la sortie brute accessible.

Le statut de sortie du processus reste le résultat d'exécution. Une réponse « tests réussis » ne remplace pas un processus en échec et ne démontre pas la couverture du comportement. L'accord de deux modèles sur une même entrée incomplète apporte aussi peu de vérification indépendante.

Limitez les appels par tâche pour éviter une boucle de validation sans fin.

À quoi ressemble une requête JSON Jev ?

Une requête transmet un état et des questions nommées avec leurs critères. Cet exemple illustratif de routage suit le format Choice documenté. Il ne présente pas un résultat d'appel réel.

{
  "model": "jev-1.13.0",
  "state": {
    "task": "Télécharger la facture du mois dernier sur le portail fournisseur.",
    "available_capabilities": ["repository", "browser"],
    "account_access": "À vérifier avant exécution"
  },
  "questions": {
    "worker": {
      "type": "choice",
      "instructions": "Quelle capacité cette tâche nécessite-t-elle ?",
      "criteria": {
        "coding": "Inspecter ou modifier le dépôt sans utiliser de site web.",
        "browser": "Interagir avec un site web pour accomplir la tâche.",
        "clarify": "Informations insuffisantes pour sélectionner un agent."
      }
    },
    "needs_account": {
      "type": "noul",
      "instructions": "Cette tâche nécessite-t-elle l'accès à un compte utilisateur ?"
    }
  }
}

Chaque réponse porte l'identifiant de sa question. Le routage sélectionne un candidat ; le code vérifie ensuite ses accès. Fixez la version évaluée pour éviter qu'un alias mobile change silencieusement le comportement. Consultez les versions dans la référence des modèles.

Combien coûte un million d'appels Jev ?

Au tarif direct publié de 0,042 $ par million de tokens d'entrée, un million de requêtes de 500 tokens facturables chacune coûte 21 $. Les tokens de sortie sont gratuits à ce tarif, vérifié le 15 octobre 2026. Source : tarification TypeSafe.

coût d'entrée = requêtes × tokens d'entrée facturables par requête
                ÷ 1 000 000 × prix par million de tokens

Comptez l'état et les définitions des questions. Les grands fichiers, nouvelles tentatives, modèles de secours et éventuels frais d'intermédiaire changent le total. « Un million d'appels pour 20 $ » correspond à une petite entrée, pas à un tarif fixe par requête.

Mesurez aussi la latence complète dans vos conditions réseau et de concurrence. Un appel court peut ralentir la tâche s'il ajoute une attente avant chaque outil.

Comment utiliser ces cas d'usage dans SpineOS ?

Exécutez le client Jev depuis son bureau cloud, puis exploitez ses résultats dans vos tâches. SpineOS fournit l'ordinateur, les fichiers et l'interface de tâches ; vous ajoutez le compte TypeSafe et l'intégration personnalisée. Les usages décrits ici ne correspondent pas à un bouton Jev à activer.

Commencez par un programme qui produit des rapports. Ajoutez routage et contrôles après évaluation.

Installer un programme de classement en lecture seule

Un petit programme suffit pour essayer le tri de tickets et la sélection de fichiers sans modifier le moteur de l'agent.

1. Ouvrez un bureau SpineOS contenant le projet. Depuis son terminal, créez un programme qui accepte des références de fichiers autorisées ou un ticket, appelle TypeSafe et enregistre les réponses structurées. Ce programme est à développer ; ce n'est pas une commande fournie par SpineOS.
2. Configurez sa clé TypeSafe hors des prompts, du dépôt et des rapports. Limitez les données transmissibles et examinez les conditions du fournisseur avant d'envoyer des fichiers privés.
3. Fixez questions, limites de fichiers et de tokens, délai d'attente et résultat inconnu en cas d'échec. Au départ, autorisez uniquement la production de rapports.
4. Créez une tâche Prompt dans Mission Control pour ce bureau. Demandez à l'agent d'utiliser le programme pour une présélection, puis de lire lui-même les fichiers retenus. Voir Créer des tâches.
5. Conservez JSON brut et journaux de tests sur ce bureau. Si d'autres agents ont besoin des conclusions, écrivez un résumé dans la base de connaissances partagée, avec références, empreintes, versions des questions et du modèle, et échecs.

Le programme doit lire les fichiers directement et ne retourner que classifications et références à l'agent principal. Lui demander de copier tout le contenu dans une requête Jev consommerait déjà le contexte que vous souhaitez économiser.

Relier chaque usage à une tâche SpineOS

Chaque usage nécessite un point d'intégration précis. Un prompt guide l'utilisation des outils ; un contrôle avant exécution exige une intégration dans le mécanisme qui les exécute.

La revue d'une tâche diffère de l'approbation d'une commande. Le workflow d'approbation documenté place une tâche en revue après son exécution. Il n'annule pas les commandes déjà effectuées. Pour une suite potentiellement destructive, faites produire uniquement un plan par la première tâche, examinez-le, puis autorisez une tâche d'exécution séparée avec des permissions effectives.

Exemple : examiner un échec d'arrondi de facturation

Utilisez un bureau pour les tests et un programme en lecture seule pour choisir les fichiers candidats. Une fois le programme installé, la tâche peut être :

Examine l'échec d'arrondi de facturation dans ce projet. Lance les tests pertinents et conserve leur sortie originale et statut de sortie. Utilise notre programme Jev installé pour classer l'échec et les fichiers candidats après une recherche classique. Ne transmets ni identifiants ni données clients sans rapport. Lis les sources retenues avant de proposer un correctif. Enregistre un rapport avec références, incertitudes et preuves de test. Arrête-toi au rapport : aucune modification ni mise en ligne.

Vérifiez si la sélection contenait le bon fichier et économisait du temps. Une seconde tâche peut appliquer le correctif examiné et relancer les tests. L'agent doit toujours comprendre le code qu'il modifie ; Jev réduit le tri préliminaire.

Par quel usage commencer dans un workflow SpineOS ?

Commencez par un classement de tickets ou une présélection de fichiers en lecture seule, en mode observation. Enregistrez les recommandations sans modifier les décisions du workflow existant. Comparez-les aux choix des personnes qui terminent les tâches.

SpineOS fournit des bureaux cloud persistants pour agents IA. L'agent peut y conserver dépôt, outils et rapports entre sessions. Un programme utilisant Jev pourrait aussi y conserver les classifications, avec leurs références de sources et versions de modèle. Cet article propose ce fonctionnement ; il n'annonce pas une intégration Jev native.

Avant tout routage automatique, mesurez erreurs, abstentions, rappel, latence et coût total. Définissez le comportement en cas d'indisponibilité du fournisseur. Augmentez l'autonomie là où les résultats le permettent.

Si votre agent passe surtout du temps à décider quoi lire, cet essai est concret. Découvrez les bureaux cloud SpineOS et choisissez une décision bornée à évaluer.

Lectures complémentaires et sources

• Nettoyer la mémoire des agents avec Jev
• Environnements persistants pour agents IA
• Frontières d'isolation des agents IA
• Dépôt Ten Levels of Jev d'IndyDevDan, compagnon de la vidéo qui inspire cet article
• Référence Noul de TypeSafe

Les exemples sont des propositions de conception. Les coûts sont calculés au tarif publié, pas mesurés sur un usage SpineOS.