L’état ne vit pas dans la mémoire du runtime
Objectif, plan, délégations, tentatives, attentes et résultats sont persistés hors du processus agentique. Un scheduler réclame le travail avec un bail récupérable : la disparition d’un worker ne fait pas disparaître la mission.
Un incident et une attente ne racontent pas la même histoire
Une mission peut attendre volontairement une question, un collègue ou une échéance. Un incident, lui, signale qu’une exécution n’a pas atteint un état terminal interprétable. Les distinguer évite de traiter une attente normale comme une panne — ou une panne comme un travail encore actif.
Le checkpoint protège des doubles effets
Dans le runtime interne de tâche, les appels d’outils à effets durables suivent une progression explicite :
Restituer sans rejouer
À la reprise, Galaris rend au runtime le résultat déjà journalisé sans rappeler l’outil.
S’arrêter pour vérifier
Si l’exécution s’est interrompue après le départ de l’appel, le système refuse un nouvel essai automatique.
Ce choix est essentiel pour un envoi, une écriture ou une opération métier : un échec explicite vaut mieux qu’un doublon silencieux.
Corriger la mission sans réveiller l’ancien raisonnement
Lorsqu’un objectif est amendé, son empreinte invalide l’ancien contexte modèle et refuse les résultats tardifs issus de l’exécution remplacée. Le journal des effets déjà réalisés reste, lui, disponible pour éviter de recommencer ce qui ne doit pas l’être.
Préserver les travaux et refuser les écritures dépassées
La demande originale d’une Task et ses pièces jointes restent distinctes du contexte complémentaire. Une nouvelle demande indépendante n’interrompt pas les autres travaux, et un amendement refusé ne les remplace pas silencieusement.
Dans une application documentaire, une écriture Dataset exige la révision attendue. Si les données ont changé, elle est refusée sans relance automatique. Le formulaire peut conserver la saisie et proposer une nouvelle soumission après relecture des données.
Annuler doit produire un effet réel
L’annulation est propagée vers le fournisseur, les appels d’outils et les ressources actives lorsque le runtime le permet. Elle ne se limite pas à changer la couleur d’un statut dans l’interface.
Demande d’arrêt et arrêt confirmé
Le contrat distingue arrêt demandé, confirmé ou d’issue inconnue, avec une portée locale ou distante. Le remplacement d’une tâche attend les preuves nécessaires ; une expiration de lease ne prouve pas l’arrêt distant. Une inférence durable peut être reprise comme nouvelle tentative, avec un nouveau coût possible. Ces reprises restent distinctes de la récupération d’un fichier déjà produit ou de sa livraison.
Séparer production et livraison
Un livrable peut avoir été créé alors que son transport a échoué. Le Working Set conserve sa ressource et les preuves disponibles. La reprise de livraison appelle le transport autorisé sans refaire la génération.
Les garanties de checkpoints d’effets décrites ici concernent le harnais interne. Pour un harnais externe, examiner les capacités déclarées et l’état de son adaptateur. Une annulation de Process peut également être complète, au mieux ou indisponible selon le moteur.