Aller au contenu principal
Version: 1.0.0

Enjeux agentiques

Les applications agentiques combinent raisonnement, planification, outils, mémoire, données externes et actions. Cette combinaison crée une nouvelle surface d’ingénierie : l’autonomie devient un contrat à exprimer, borner, tester et observer.

Cette page présente les enjeux que Touba traite par son langage, son runtime et ses artefacts de gouvernance.

Contrôle de l’autonomie​

Un agent peut recevoir un objectif large ou disposer d’un périmètre d’action important. Touba répond par une architecture déclarative :

  • les agents utilisent des skills déclarées ;
  • les stratégies orchestrent explicitement les agents ;
  • callable_by définit qui peut invoquer un agent ;
  • les tools déclarent leurs besoins ;
  • le runtime refuse les appels hors contrat.

Les politiques de gouvernance s’appuient sur ce socle : autorité déclarée, contrat AIR, manifests et traces.

Autorité d’accès​

Un agent connecté à plusieurs outils doit agir avec des droits explicites.

Touba sépare :

  • ce que le tool demande ;
  • ce que l’hôte accorde ;
  • ce que l’agent actif peut utiliser ;
  • ce que le runtime exécute ou refuse.

Cette séparation rend les refus observables et relie l’autorité à des artefacts relisibles.

Secrets et données sensibles​

Les secrets ne circulent pas comme du texte ordinaire. Touba utilise des handles opaques : le code Touba déclare qu’un tool a besoin d’un secret, tandis que la valeur réelle est résolue hors du programme et tenue à l’écart de l’AIR et des traces.

Le handler reste le point d’intégration avec le système hôte. Son contrat est donc rendu explicite par le manifest, les grants et les traces.

Supply chain des handlers​

Un tool utile appelle souvent du code hôte, via un handler JavaScript ou Python. Touba contrôle cette frontière par des artefacts explicites :

  • le manifest dit quel handler est autorisé ;
  • le runtime ne découvre pas les handlers automatiquement ;
  • le SDK aide à écrire le handler sans devenir source d’autorité ;
  • la vérification supply chain des handlers fournit des digests et un lock explicite pour détecter les dérives entre AIR, manifest, handlers, métadonnées SDK, identité déclarée handler_package, fichiers de paquet handler et artefacts de dépendances déclarés.

Les packages regroupent les composants partageables. Leur manifeste, leurs exports et leur contenu sont vérifiés à l’installation.

Prompt injection​

Les sources externes peuvent contenir du texte qui ressemble à une instruction. Touba traite ce risque comme un problème de frontières : tools, secrets, payloads, données métier, instructions agentiques et traces doivent rester distinguables.

La séparation données/instructions rend les confusions visibles, testables et auditables. Elle s’intègre avec les types nominaux, les contraintes de payload, les handlers et les traces.

Mémoire​

La mémoire agentique devient gouvernable quand l’on sait qui lit, écrit ou modifie le contexte.

Touba introduit des mémoires logiques avec scopes. Une mémoire n’est pas un fichier, une base de données ou un handler ; elle représente un espace de contexte gouverné, accessible par des tools déclarés.

La provenance et l’intégrité mémoire ajoutent une distinction entre le droit d’accès et les métadonnées de contenu : origine déclarée, writer, run, horodatage, digest reporté ou evidence d’intégrité.

Auditabilité​

Un système agentique doit pouvoir expliquer ce qui s’est passé.

Touba s’appuie sur l’AIR et les traces pour reconstruire les événements importants :

  • appels ;
  • refus ;
  • validations humaines ;
  • accès mémoire ;
  • utilisation de tools ;
  • erreurs runtime.

L’audit des traces relie la trace à l’AIR et à la source, déclare une politique de rétention, calcule des digests d’artefacts et produit un export contrôlé.

Surfaces de gouvernance​

Les contrôles ont une valeur pratique lorsqu’ils sont lisibles par les développeurs, reviewers, opérateurs et responsables de gouvernance.

Touba expose ces informations dans ses surfaces :

  • inspection du source, de l’AIR, du manifest, des traces, refus, budgets et locks ;
  • diagnostics et navigation dans VS Code ;
  • états et événements exposés par le serveur de projet ;
  • demandes d'approbation structurées consommables par l'application hôte.

Ces surfaces affichent les artefacts explicites : source .tb, AIR, manifest, lock, rapport, options runtime, trace ou export d’audit.

Voir aussi : Surfaces de gouvernance des risques.

Consommation de ressources​

Un agent peut consommer du temps, des appels ou du budget. Touba dispose de limites d’exécution comme les timeouts de handlers, les limites de payload, les boucles bornées et les budgets d’autonomie.

Ces budgets couvrent la durée d’un run, le nombre d’étapes, le nombre d’appels tools, le nombre d’invocations agents, le nombre d’appels au decision provider agentique et les quotas de triggers.

Les budgets fournisseurs réservent une estimation de coût avant chaque requête, puis rapprochent cette réservation de l’usage retourné par le fournisseur.

Arrêt contrôlé​

Un système agentique doit pouvoir être stoppé ou annulé sans confondre pause normale, refus, échec et annulation.

Touba distingue :

  • un run actif ;
  • un run en pause ;
  • une annulation demandée ;
  • une annulation effective ;
  • un échec ;
  • une fin réussie.

L’arrêt contrôlé est disponible côté runtime et CLI : annulation demandée, timeout global, kill switch d’exécution, dispatch refusé après cancel et état terminal cancelled sont représentés dans les traces. Les déploiements distribués ajoutent control plane et intégrations d’exploitation autour de ce contrat.

Déclenchements automatiques​

Les triggers rendent Touba réactif au monde réel tout en conservant le modèle d’exécution gouverné.

Structure
événement -> validation -> contexte borné -> exécution -> trace

Les tranches schedule -> strategy et request -> strategy sont disponibles avec limites explicites, manifest, état TD-1 et traces trigger_*. Le runner supporte les intervalles every <n>s, every <n>m et every <n>h; le service webhook route les requêtes HTTP déclarées vers le runtime via une queue durable, un contrat payload explicite et une signature HMAC optionnelle, sans stocker le payload brut.

Sources​

Les enjeux ci-dessus sont alignés avec des références publiques :

Ces sources guident l’évolution de Touba autour de risques concrets.