La raison d’être de Touba
Un agent utile doit aussi avoir une responsabilité compréhensible, des accès maîtrisés et des actions vérifiables. Touba permet d’inscrire ces règles dans le programme qui l’exécute.
Des modèles plus capables, une autorité explicite
L’intelligence des modèles élargit ce que les agents savent faire. La gouvernance définit ce qu’ils sont autorisés à faire. Touba relie ces deux dimensions dans un cadre programmable, traçable et auditable.
À mesure que les modèles progressent, ils peuvent prendre en charge des tâches qui exigeaient auparavant une orchestration complexe. La valeur du cadre d’exécution, ou harness, tient alors autant à sa capacité à organiser le travail qu’à rendre les actions gouvernables, traçables et auditables. Plus nous déléguons aux modèles, plus il devient essentiel de définir leur autorité, leurs limites et les conditions de leur intervention. Touba permet d’exprimer ce cadre dans le programme, selon les principes de PAP.
Du « devrait » au « peut »
« L’agent devrait demander une validation avant de payer » exprime une intention. Le programme doit aussi établir si l’agent peut atteindre l’outil de paiement et sous quelles conditions.
Touba sépare ces deux questions. La responsabilité guide le modèle ; les contrats contrôlent les capacités accessibles, les appels, les validations et les limites. La trace montre ce qui a été exécuté ou refusé.
Un cadre partagé
| Pour qui ? | Ce que Touba apporte |
|---|---|
| Développeurs | Des agents composables, des contrats relisibles et des tests de résultats comme de refus |
| Organisations | Des leviers techniques pour appliquer les règles représentées : accès, approbations, budgets et conservation des preuves |
| Utilisateurs | Des points d’intervention explicites et des traces que l’application peut restituer sous une forme compréhensible |
L’organisation choisit ses règles, les développeurs les expriment et les testent, et l’application hôte atteste les identités et fournit les intégrations.
Exemple : traiter un remboursement
Le workflow distingue préparation du dossier, décision et paiement :
| Étape | Responsable | Contrôle |
|---|---|---|
| Préparer le dossier | Agent de revue | Accès aux pièces utiles, sans capacité de paiement |
| Valider la proposition | Approbateur désigné | Rôle requis, délai et identité attestée par l’application |
| Exécuter le paiement | Tool autorisé | Contrat d’appel, permissions et reçu d’effet |
| Vérifier le déroulement | Équipe d’exploitation | Trace corrélée au programme et à ses décisions |
L’approbation permet de poursuivre le chemin prévu ; le tool reste soumis à ses propres permissions. Le tutoriel d’approbations montre comment programmer ce parcours.
Des règles à l’exécution
| Question | Levier Touba |
|---|---|
| Quelle mission porte l’agent ? | responsibility |
| Quelles capacités peut-il choisir ? | uses |
| Qui peut l’appeler ? | callable_by |
| Quand une personne intervient-elle ? | human.approve et human.review |
| Quelles ressources peut-il consommer ? | Scopes, permissions et budgets |
| Que s’est-il passé ? | Traces d’exécution et d’audit |
La déclaration de mission rend l’intention explicite. Les garanties exécutoires portent sur les contrats contrôlés par le compilateur et le runtime ; la qualité du résultat métier se vérifie avec les tests de l’application.