Autorité d’invocation des agents

callable_by déclare qui peut invoquer un agent.

source.tb

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

Règle

Les callers autorisés sont bornés :

• strategy ;
• agent.

Un skill n’est pas un caller autorisé par callable_by.

Pour un agent importé depuis un autre module, le caller doit être nommé de façon explicite :

source.tb

agent Reviewer
    responsibility "Fulfill the declared Reviewer responsibility using only authorized capabilities."
    callable_by strategy examples.agent_app.RunReview

Pourquoi c’est utile

Sans autorité explicite, un agent pourrait être invoqué depuis un flux non prévu.

Avec callable_by, le runtime vérifie avant d’entrer dans l’agent :

Sortie

caller autorisé -> invocation acceptée
caller absent   -> invocation refusée et tracée

Trace

Les événements utiles sont :

• agent_invocation_authorized ;
• agent_invocation_refused ;
• failure_detected.

La trace montre qu’une règle a été appliquée. La fiabilité de l’agent se traite par les tests, l’audit des traces et la revue des capacités qu’il peut appeler.

callable_by ne décide pas quelle capacité l’agent utilise. Après l’entrée dans l’agent, le runtime applique le contrat uses et peut appeler un decision provider gouverné. Ce provider choisit une capacité autorisée ; le runtime refuse toute cible absente de uses.

Si l’agent consomme une capacité, le résultat peut revenir au provider comme observation pour la décision suivante. Cette boucle reste séquentielle et bornée : callable_by contrôle l’entrée dans l’agent, uses contrôle l’atelier de ressources, et le runtime garde l’autorité d’exécution.

Données et contextes séparés

Chaque invocation garde ses valeurs locales et son identité d’agent/caller. Les arguments structurés et les échanges avec un provider ou un handler sont copiés : modifier un objet JavaScript reçu ne modifie ni les droits Touba, ni les données du parent, ni les observations conservées par le runtime. Un retry du provider reçoit une nouvelle copie de la requête initiale.

Les budgets et l’annulation restent communs au run. Une délégation n’ajoute aucun droit au parent et ne remet pas les compteurs à zéro. Pour partager durablement des données, utilisez une mémoire explicitement déclarée et autorisée, pas une référence d’objet conservée par un adaptateur.

Cette isolation de données ne confine pas du code JavaScript arbitraire exécuté par l'hôte. Dans un groupe parallel, elle sépare les branches sans modifier le caller source ni accorder les droits d'une branche à une autre. Les mêmes contrôles s'appliquent aux agents importés avec une signature résolue. Voir Strategy et le tutoriel multi-agent.

Périmètre

Le contrat courant fournit des références explicites de caller, une autorisation traçable et un refus avant invocation d’agent non autorisée.

Les tokens cryptographiques signés, capabilities internes d’agent, langages de politiques riches et autorisations par module entier sont des couches d’autorisation ultérieures.