PAP : programmer la responsabilité

Probabilistic Agentic Programming (PAP) place la responsabilité au cœur du programme. Un agent peut choisir comment accomplir sa mission dans un cadre qui précise ses capacités, ses ressources et les validations requises.

Le modèle propose une action ; les contrats déterminent si elle peut être exécutée. Cette séparation permet de faire évoluer l’intelligence du système tout en conservant une autorité explicite et vérifiable.

Les trois dimensions de la responsabilité

Dimension	Question	Dans Touba
Mission déclarée	Quel travail est confié à l’agent ?	responsibility exprime son mandat.
Contrats exécutoires	Quelles actions, quels appels et quelles ressources sont permis ?	uses, callable_by, permissions, budgets et validations définissent les conditions contrôlées.
Attribution des actions	Qui a proposé quoi, sous quelle autorité, avec quel résultat ?	Les traces relient les décisions, les appels et les effets à leur contexte d’exécution.

La mission oriente le travail ; les contrats encadrent l’exécution ; les traces permettent de l’examiner. La qualité métier du résultat se vérifie avec les critères de l’application.

Une frontière autour des effets

Une proposition du modèle, un document consulté ou le résultat d’un outil peuvent informer une décision. L’autorité vient des contrats déclarés et contrôlés, pas du contenu produit par le modèle.

Une responsabilité explicite

Capacités · appelants · ressources · validations humaines

1. Proposition

   Le modèle choisit une action.

2. Contrôle d’autorité

   Le médiateur vérifie les contrats.

3. Effet autorisé

   L’opération peut être exécutée.

Contrat non satisfait : opération refusée avant son exécution.

Preuves attribuables

Proposition · décision d’autorisation · effet ou refus

PAP relie la responsabilité, les conditions d’exécution et leurs preuves. Le contrôle porte sur les opérations soumises au médiateur.

Ce schéma adapte les frontières de responsabilité présentées dans les articles de recherche. PAP définit ces obligations architecturales indépendamment d’un langage ou d’un fournisseur de modèles.

Déléguer sans transmettre tous ses droits

Un coordinateur reçoit une facture et confie son enregistrement à un agent spécialiste. Seul ce dernier dispose de la capacité d’écriture.

Délégation pour l’enregistrement d’une facture

module invoices

tool RegisterInvoice
    description "Append an invoice ID to the register."
    takes invoice as Text
    gives Text

agent InvoiceClerk
    description "Record an invoice ID and return it."
    takes invoice as Text
    gives Text
    responsibility "Register the supplied invoice ID."
    uses RegisterInvoice
    callable_by agent InvoiceDesk

agent InvoiceDesk
    takes invoice as Text
    gives Text
    responsibility "Delegate invoice registration."
    uses InvoiceClerk
    callable_by strategy ReceiveInvoice

strategy ReceiveInvoice
    takes invoice as Text
    gives Text
    uses InvoiceDesk
    do
        InvoiceDesk
            with invoice as invoice
            into registered
        give registered

uses InvoiceClerk autorise le coordinateur à sélectionner le spécialiste ; callable_by agent InvoiceDesk autorise le spécialiste à recevoir cet appel. Le handler qui réalise l’écriture est relié au tool par un binding de l’hôte.

Proposition	Contrôle et effet
Le coordinateur délègue au spécialiste.	Les relations uses et callable_by sont vérifiées. Le spécialiste peut ensuite sélectionner son tool, soumis aux contrôles du binding.
Le coordinateur appelle directement RegisterInvoice.	Refus AgentCapabilityNotAllowed : le tool ne fait pas partie de ses capacités. Le handler n’est pas appelé.

Dans l’exécution contrôlée présentée dans l’article, ce refus laisse le registre vide et le nombre d’appels au handler à zéro. C’est une réussite du contrôle de gouvernance : l’action proposée reste hors de portée du coordinateur. Cet exemple illustre le mécanisme, pas la fréquence des erreurs d’un modèle.

Du programme aux preuves d’exécution

1. Source

   Responsabilités et contrats

2. AIR

   Représentation compilée

3. Runtime

   Contrôles avant les effets

4. Trace

   Déroulement attribuable

5. Revue

   Audit et amélioration du programme

Dans Touba, le même contrat relie le programme à son exécution. La revue peut conduire à une nouvelle version du programme, sans modifier les autorisations du run terminé.

Cette adaptation du cycle étudié dans les articles montre sa réalisation dans Touba. Les fonctions portent le calcul pur, les skills composent les capacités, les agents portent leurs missions et les stratégies organisent le travail. Les tools déclarent les effets externes, dont les bindings contrôlent l’accès aux handlers. La trace permet de relire les décisions et leurs conséquences.

PAP, modèle formel et Touba

Niveau	Rôle
PAP	Principes architecturaux : responsabilité explicite, autorité bornée, médiation des effets et preuves attribuables.
Kernel formalisé	Modèle séquentiel choisi pour démontrer des propriétés précises, sous des hypothèses de confiance et de médiation.
Touba	Réalisation de PAP : syntaxe, compilateur, AIR, runtime, intégrations et traces.

Les garanties formelles portent sur les opérations passant par le médiateur de confiance. Le théorème source vers graphe couvre un fragment séquentiel défini, avec boucles, imports résolus, scopes et checkpoints. La concurrence et la reprise après panne demandent des propriétés distinctes.

Probabilistic désigne la présence de composants décisionnels probabilistes. Les conditions d’autorisation restent des règles explicites du programme.

Pour approfondir

• Les articles scientifiques : fondements de PAP, formalisation et évaluation des frontières de responsabilité.
• Les évaluations : résultats métier et contrôles de gouvernance.
• Composer plusieurs agents : passer des principes à un programme.
• Programmer les approbations : rôles, délais et intervention humaine.