Autonomie bornée

Dans Touba, un agent choisit ses actions dans un périmètre déclaré : capacités, appelants, données accessibles et budgets.

Touba vise l’autonomie bornée. Un agent peut être invoqué par un caller autorisé, lister les capacités déclarées dans uses, demander une décision à un provider configuré, exécuter une capacité sélectionnée, réutiliser le résultat comme observation pour une décision suivante et refuser tout choix qui ne figure pas dans uses.

Le provider utilise une interface structurée ou les appels d’outils natifs du fournisseur. Dans les deux cas, Touba vérifie la cible, les arguments et callable_by pour une délégation, puis trace la décision. Le tutoriel provider présente ces deux interfaces sous le même contrat d’autorité.

La boucle de décision de chaque agent reste séquentielle. Plusieurs invocations peuvent cependant s'exécuter en parallèle dans un groupe parallel déclaré par une stratégie ou une skill. Chaque branche conserve ses données, son caller et ses scopes ; les compteurs de run et l'annulation sont partagés. La concurrence n'autorise aucune capacité supplémentaire. Voir Strategy.

Ce qui borne un agent

Le périmètre observable vient de plusieurs contrats :

Contrat	Rôle
uses	responsabilités que l’agent peut exécuter
callable_by	stratégies ou agents autorisés à l’invoquer
scopes de secrets	handles de secrets accessibles quand l’agent est actif
scopes de mémoire	mémoires logiques lisibles ou modifiables
manifest	handlers, grants, secrets et limites accordés
trace	événements d’autorisation, de refus et de pause

Syntaxe

source.tb

agent AgentName
    description "Selects a declared capability for this responsibility."
    responsibility "Selects a declared capability for this responsibility."
    uses SomeSkill
    callable_by strategy StrategyName

strategy StrategyName
    description "Runs the governed agent entry point."
    uses AgentName
    do
        AgentName

uses déclare ce que l’agent peut exécuter. callable_by déclare qui peut l’invoquer.

Lorsqu’une décision d’agent est fournie au runtime, Touba trace :

• les capacités autorisées par uses ;
• la décision reçue ;
• la capacité sélectionnée ;
• ou le refus si la capacité demandée est hors périmètre.

Lorsqu’un decision provider est configuré, le runtime trace aussi :

• la demande de décision courte avec digest rédigé ;
• la demande de catalogue complet si le provider la formule ;
• l’appel provider tenté, le retour du provider et les retries bornés ;
• les metadata provider non secrètes ;
• la présence d’arguments fournis pour la capacité sélectionnée, sans tracer les valeurs brutes.

Sans décision explicite ni provider, un agent avec une seule capacité peut être sélectionné automatiquement. Un agent avec plusieurs capacités exige une décision structurée.

Exemple

source.tb

type DatasetRequest
    query is Text

type DatasetBrief
    summary is Text

tool SearchDatasets
    description "Search public dataset records for the requested topic."
    takes request as DatasetRequest
    gives DatasetBrief
    requires network

skill BuildDatasetBrief
    description "Prepare a governed dataset brief from declared search capabilities."
    takes request as DatasetRequest
    gives DatasetBrief
    uses SearchDatasets
    do
        SearchDatasets
            with request as request
            into result
        give result

agent Researcher
    responsibility "Fulfill the declared Researcher responsibility using only authorized capabilities."
    uses BuildDatasetBrief
    callable_by strategy RunDatasetResearch

strategy RunDatasetResearch
    uses Researcher
    do
        Researcher

Dans cet exemple, Researcher peut exécuter BuildDatasetBrief. Il n’est pas libre d’appeler n’importe quel tool ou n’importe quel autre agent. La stratégie RunDatasetResearch est le caller autorisé.

Décision humaine

Touba distingue deux situations :

• une validation humaine obligatoire dans le flux ;
• une review humaine déclenchée par une logique agentique.

Dans les deux cas, la pause et la reprise sont explicites. Une validation humaine ne transforme pas automatiquement un résultat en preuve formelle.

Contrat Runtime

Le contrat d’autonomie bornée couvre :

• autorité d’invocation explicite ;
• sélection de capacité explicite ;
• refus runtime avant exécution hors périmètre ;
• décisions provider traçables ;
• boucles agentiques séquentielles bornées et groupes parallèles explicitement déclarés ;
• aucun accès implicite aux tools, mémoires, secrets ou handlers hors graphe déclaré.

Complétez ce périmètre avec les budgets de coût fournisseur et le profil d’exécution durci, selon les contraintes de votre application.