Skip to main content
Version: 1.0.0

PAP: programming responsibility

Probabilistic Agentic Programming (PAP) puts responsibility at the heart of the program. An agent can choose how to carry out its mission within a framework that defines its capabilities, resources and required approvals.

The model proposes an action; contracts determine whether it may execute. This separation lets a system’s intelligence evolve while keeping its authority explicit and verifiable.

Three dimensions of responsibility​

DimensionQuestionIn Touba
Declared missionWhat work is entrusted to the agent?responsibility states its mandate.
Executable contractsWhich actions, calls and resources are permitted?uses, callable_by, permissions, budgets and approvals define the conditions that are checked.
Action attributionWho proposed what, under which authority, with what outcome?Traces connect decisions, calls and effects to their execution context.

The mission guides the work; contracts govern execution; traces make it inspectable. Application criteria assess the business quality of the result.

A boundary around effects​

A model proposal, a retrieved document or a tool result can inform a decision. Authority comes from declared and enforced contracts, rather than the content produced by the model.

An explicit responsibility

Capabilities · callers · resources · human review

  1. Proposal

    The model selects an action.

  2. Authority check

    The mediator checks the contracts.

  3. Authorized effect

    The operation may execute.

Contract not satisfied: the operation is refused before execution.

Attributable evidence

Proposal · authorization decision · effect or refusal

PAP connects responsibility, execution conditions and their evidence. Checks apply to operations passing through the mediator.

This diagram adapts the responsibility boundaries presented in the research papers. PAP defines these architectural obligations independently of a language or model provider.

Delegation preserves separate permissions​

A coordinator receives an invoice and delegates its registration to a specialist agent. Only the specialist has the writing capability.

Delegating invoice registration
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 permits the coordinator to select the specialist; callable_by agent InvoiceDesk allows the specialist to receive that call. A host binding connects the tool to the handler that performs the write.

ProposalCheck and effect
The coordinator delegates to the specialist.The uses and callable_by relations are checked. The specialist may then select its tool, subject to binding checks.
The coordinator calls RegisterInvoice directly.AgentCapabilityNotAllowed refusal: the tool is outside its capabilities. The handler is not called.

In the controlled execution presented in the paper, this refusal leaves the register empty and the handler call count at zero. This is successful governance enforcement: the proposed action remains outside the coordinator’s authority. The example illustrates the mechanism, rather than measuring how often a model makes such errors.

From programs to execution evidence​

  1. Source

    Responsibilities and contracts

  2. AIR

    Compiled representation

  3. Runtime

    Checks before effects

  4. Trace

    Attributable execution record

  5. Review

    Audit and program improvement

In Touba, the same contract connects the program to its execution. Review can inform a new program version without changing the completed run’s authority.

This adaptation of the cycle studied in the papers shows its implementation in Touba. Functions provide pure computation, skills compose capabilities, agents carry their missions, and strategies organize the work. Tools declare external effects; their bindings govern access to handlers. Traces record decisions and their consequences for review.

PAP, the formal model and Touba​

LevelRole
PAPArchitectural principles: explicit responsibility, bounded authority, mediated effects and attributable evidence.
Formal kernelA chosen sequential model for proving specific properties under trust and mediation assumptions.
ToubaAn implementation of PAP: syntax, compiler, AIR, runtime, integrations and traces.

Formal guarantees concern operations passing through the trusted mediator. The source-to-graph theorem covers a defined sequential fragment, including loops, resolved imports, scopes and checkpoints. Concurrency and crash recovery require separate properties.

Probabilistic refers to the presence of probabilistic decision components. Authorization conditions remain explicit program rules.

Explore further​