PaperlayerView exact revision on arXiv

Source-linked AI summary

Responsibility Boundaries for Agentic Systems: A Comparative Evaluation of Probabilistic Agentic Programming

Khadim Lo, Soukaina Alaoui Ismaili, Jean-Sébastien Dessureault

arXiv:2610.33312v1cs.SEcs.AIcs.PL

TL;DR

Language-model agents can act through tools and delegation while responsibility and authority are distributed across system components. The paper makes responsibility boundaries explicit through PAP and examines them with formal and executable evaluations. Its evaluation compares Touba decision interfaces for completion while holding the runtime authority boundary fixed.

  • Problem

    Language-model agents can select tools, consult memory, delegate, and affect external systems, while facts governing their actions can be scattered across the stack.

    Source: §1 · p. 2

  • Method

    The paper compares PAP with related programming and agent systems, formalizes a mediation kernel, proves conditional safety and a bounded simulation result, and evaluates enforcement tests and business cases.

    Source: §1 · p. 2

  • Results

    The evaluation compares two Touba decision interfaces for completion while runtime authority remains fixed.

    Source: §1 · p. 3

  • Takeaways & Limitations

    PAP frames responsibility boundaries as explicit programming abstractions connecting permitted action to authority and evidence.

    Source: §7 · p. 8

    The defined Touba realization handles human checkpoints by releasing program continuations; operation-bound approval remains a separate kernel contract, and full business consent requires additional contracts.

    Source: §8.3 · p. 12

Abstract

from arXiv · show

Language-model agents combine reasoning, tools, memory, delegation, and external effects. Authority is often distributed across prompts, host code, configuration, and logs. Probabilistic Agentic Programming (PAP) makes responsibility boundaries explicit programming abstractions connecting mandate, authority, effects, and evidence. We compare PAP with programming paradigms, agent-oriented and BDI systems, workflow and policy languages, and LLM tool-use frameworks along seven dimensions. A mediation kernel formalizes checks before tool execution, operation-bound approval, resource limits, and evidence. Inductive proofs establish conditional safety for arbitrary model responses, assuming correct guards and complete mediation. A backward simulation matches graph executions to source executions in a defined sequential Touba subset. Its human checkpoints release program continuations; operation-bound approval remains a separate kernel contract. Finite-state exploration checks the model. Scripted enforcement tests exercise selected refusal paths and permitted controls. An exploratory study combines seven business cases, including two three-agent workflows, seven models from three providers, five methods, and five repetitions per case and method. Shared English instructions and exact checks of stored outcomes yield 1,225 assessed observations. Native Touba completes all 35 observations on six models and 30 on the remaining model; structured Touba ranges from 21 to 35. Native matches the highest observed count for each model, including ties with the frameworks. All paired case intervals include zero. These observed counts describe the evaluated tasks; the runtime authority boundary remains fixed. The results connect responsibility contracts, execution rules, and evidence.

1 Introduction

The introduction presents PAP as a programming abstraction for making responsibility and authority explicit around probabilistic agents. It compares this concern with established programming traditions and describes formal and executable ways to examine it.

1 Introduction

  • PAP treats scattered responsibility, authority, capability, memory, validation, binding, and evidence as a programming problem for agents whose permitted effects and obligations should be explicit.The paper develops a comparative account, a formal preservation result, and an executable evaluation of responsibility boundaries.Source: §1 · p. 2
  • The evaluation links model proposals, runtime events, and independently observed effects, while comparing Touba decision interfaces for completion under a fixed runtime authority boundary.It combines scripted enforcement tests with case-paired business outcomes.Source: §1 · pp. 2–3

2.1 Primary Question

  • The central question is whether governed responsibility under probabilistic agency is a distinct programming object, connecting mandate, authority, permitted effects, and attributable evidence.The comparison asks where responsibility lives and how authority, effects, memory, validation, and execution evidence are represented.Source: §2.3 · p. 3, §2.2 · p. 3

3.1 Classical Programming Paradigms

  • Classical paradigms remain computational foundations; PAP adds first-class treatment of who is responsible for autonomous actions and under which authority and validation boundary.Structured, functional, and modular programming emphasize distinct concerns, while PAP does not replace their functions, types, modules, protocols, tests, or runtime engineering.Source: §1 · p. 1, §3.1 · p. 4

3.2 Actors and Concurrent Agents

  • Actor systems make concurrency, communication, and local state explicit, while PAP adds contracts linking an active unit’s uncertain choices to enforceable responsibility boundaries.An agent following PAP can resemble an actor that receives an invocation, performs work, and emits results or messages.Source: §3.2 · p. 4

3.3 Agent-Oriented Programming and BDI Agents

  • PAP inherits autonomy from agent-oriented and BDI traditions but centers contracts governing its exercise, including when a language model makes decisions.These traditions make concepts such as beliefs, commitments, capabilities, desires, intentions, and plans explicit.Source: §3.3 · p. 4

3.4 LLM Tool-Use Systems

  • LLM tool-use systems combine reasoning and action; PAP asks how their responsibility boundaries can become explicit programming constructs.The comparison includes agent SDKs, protocols, and multi-agent systems.Source: §3.4 · p. 4

3.5 Workflow and Policy Languages

  • PAP connects workflow orchestration and policy evaluation to the agent responsible for an action, and frames responsibility boundaries as obligations that must survive lowering, mediation, and evidence production.Its enforcement account relates admission to responsibility, while scoped memory access does not by itself prove information-flow noninterference.Source: §3.5 · p. 5, §3.6 · p. 5

4 Governance Pressure in Sensitive Organizations

Governance guidance across sensitive domains motivates concrete questions about authorization, effects, human decisions, and evidence. The programming substrate also needs to connect to operational infrastructure, while organizational assurance depends on more than the substrate alone.

4 Governance Pressure in Sensitive Organizations

  • Guidance from NIST, WHO, OSFI, Canada, and the EU addresses lifecycle trustworthiness, risk, governance, human involvement, or requirements for high-risk systems.The cited passage notes that OMB M-24-10 was rescinded and replaced by M-25-21 on 3 April 2025.Source: §4 · p. 6
  • Governance questions include which agent was authorized, which tool produced an effect, what resource scope applied, what human decision was required, and what evidence can reconstruct execution while protecting sensitive values.The context includes systems affecting health, financial decisions, public services, safety, or fundamental rights.Source: §4 · p. 6
  • Touba makes selected governance facts inspectable through source, AIR, bindings, and traces, but organizational assurance also depends on surrounding infrastructure, policies, and sector-specific evaluation.Operational infrastructure includes observability, provenance, attestations, and signing systems.Source: §4 · p. 6

5 Threat Model and Trust Assumptions

The comparison frames probabilistic agency as a responsibility-boundary problem and examines how that boundary connects authority, effects, and evidence. PAP makes those connections explicit while retaining established programming traditions as foundations.

5 Threat Model and Trust Assumptions

  • Compromise of the trusted execution host or its credentials is outside the kernel argument, and independent service reads do not make measurement infrastructure adversary-resistant.Model proposals and tool observations may be wrong or adversarial; the compiler and runtime are tested rather than assumed verified.Source: §5 · p. 6

6 Comparison Dimensions

  • Seven dimensions compare central abstractions, responsibility, external effects, authority, memory, human validation, and execution evidence across agentic systems.The comparison focuses on responsibility boundaries, not only tool support or orchestration.Source: §6 · pp. 6, 8

7 Responsibility as a Programming Abstraction

  • PAP organizes probabilistic agentic systems around explicit responsibility boundaries that connect permitted action to authority and evidence.Its design claim is that mandate, authority, permitted effects, and attributable evidence are otherwise represented separately.Source: §7 · p. 8

7.1 From Computation to Governed Agency

  • PAP starts with governed agency—who may act and under which contracts—while ordinary deterministic computation remains central for transformations and internal logic.Touba realizes the distinction through pure functions and explicit tool contracts.Source: §7.1 · p. 8

7.2 From Agent as Metaphor to Agent as Responsibility Boundary

  • The programming model asks what an agent may do, under whose authority, and with which tools, memory, validation obligations, and trace evidence.A realization must preserve the connection among responsible context, declared contracts, mediated effects, obligations, and attributable evidence.Source: §7.2 · p. 9

7.3 Autonomy, Human Decisions and Evidence

  • Autonomy permits choices within declared boundaries, while mandatory approval and agent-initiated review derive from different sources of authority.PAP requires evidence attributing permitted and refused actions, resource access, and human decisions to declared responsibilities.Source: §7.3 · p. 9

8 A Formal Responsibility Boundary

Section 8 gives the mediation kernel explicit transition rules and relates them to a defined sequential Touba fragment. Its guarantees are conditional on stated assumptions and distinguish kernel-level operation approval from Touba’s program checkpoints.

8.1 Contracts and Guarded Dispatch

  • Eight fail-closed guards check context, use, caller, types, binding, grants, scope, and integrity; dispatch also requires any mandated approval, active execution, and remaining quota.Admission and dispatch are atomic in the model, and failed admission refuses the pending operation.Source: §8.1 · pp. 10–11
  • Delegation admits a specialist through declared use and caller relations, but checks its authority without intersecting it with the coordinator’s or full call chain’s authority.A compromised coordinator can exploit overly broad specialist contracts; narrower interfaces, caller-specific argument policies, and service-side checks address that risk.Source: §8.1 · p. 11

8 A Formal Responsibility Boundary

  • Under explicit assumptions, induction establishes valid pre-state witnesses for every dispatch, human-boundary safety, bounded counters, and pathwise enforcement for every admitted provider response.The kernel model assumes fixed contracts, sequential crash-free execution, and lossless abstract auditing.Source: §8 · p. 10, §8.2 · pp. 11–12

8.3 Backward Simulation of a Sequential Fragment

  • The backward-simulation fragment covers sequential skills, strategies, imports, and delegation; Touba checkpoints release saved continuations and are distinct from operation-bound kernel approval.The fragment excludes recursion, concurrency, crashes, and several other behaviors; its Touba realization sets NeedHuman(C, r) = false.Source: §8.3 · p. 12

A checkpoint site revisited with different arguments

  • At a revisited review site, execution waits before each write; each approval releases only the next write, while rejection preserves the completed prefix and blocks the pending write.The theorem matches finite lowered-graph executions to source executions, preserving dispatch context, checkpoints, witnesses, and ideal evidence projections.Source: A checkpoint site revisited with… · p. 13
  • The simulation runs from graph to source and establishes safety and visible-evidence preservation, not progress or termination; the lowering is mathematical, not the production compiler.Extending the result to the full compiler and runtime requires further verification.Source: A checkpoint site revisited with… · p. 13

8.4 Executable Validation of the Kernel

  • 4,608 finite contract configurations yielded 203,712 reachable states and 314,904 transitions; all ten deliberately weakened variants were rejected by invariant checks.The exploration checks the finite model against stated invariants; whether the specification captures intended policy requires separate review.Source: §8.4 · p. 13
  • Compiled runtime checks exercised repeated writes, quota refusal without erasing prior writes, unlisted-tool refusal, approval and delegation, and memory and secret-grant controls.Additional checks covered suspension and resumption, early returns, record construction, short-circuit evaluation, and module assembly.Source: §8.4 · pp. 13–14

9 Risk-Governance Fit

PAP frames agentic risk governance as a programming responsibility-boundary problem, connecting mandate, authority, effects, and evidence. Its comparison asks how adjacent traditions represent that boundary and how implementation choices preserve it.

9 Risk-Governance Fit

  • PAP translates agentic risks into programming obligations for caller and capability boundaries, scoped resources, protected secrets, and attributable effects.The section connects these obligations to escalation, data exposure, and audit gaps.Source: §9 · p. 14

10 Comparative Positioning

  • Across LLM tool-use systems, PAP connects governance mechanisms to an explicit program responsibility linking authority, effects, and evidence.The comparison includes MRKL, ReAct, Toolformer, AutoGen, the OpenAI Agents SDK, MCP, and LangGraph persistence [18] [47] [61].Source: §10 · p. 14

10.1 Architectural Obligations, Independent of Syntax

  • The responsibility boundary is an architectural obligation independent of syntax; a host-language realization preserving it would instantiate the paradigm.Python annotations and Rust ownership rules alone do not determine whether an agent may register an invoice.Source: §10.1 · p. 15, Table 5 · p. 15

10.2 Representation in the Evaluated Adapters

  • In the inspected framework adapters, application code selects stage tools, sequences specialists, validates handoffs, and shares counters.Comparing protection or programming effort would require matched implementations and dedicated measures.Source: §10.2 · p. 15

11 Touba as an Empirical Reference Path

Touba provides an executable reference path connecting source responsibility contracts to runtime admission and traces. Its invoice example and scripted tests show how authority boundaries affect permitted effects.

11 Touba as an Empirical Reference Path

  • Touba realizes PAP through source constructs for pure computation, tools, skills, agents, and strategies, with AIR linking contracts to bindings, runtime admission, and traces.The example tests this connection in the actual toolchain.Source: §11 · pp. 15–16

11.1 A Worked Responsibility Boundary

  • InvoiceDesk delegates to InvoiceClerk, whose authority—not the coordinator’s—permits RegisterInvoice; caller relations constrain delegation without granting direct tool access.The runtime and trace retain agent identity, and an independent register read confirms the write.Source: §11.1 · p. 16, Figure 5 · p. 18

11.2 When a Failed Proposal Demonstrates a Working Boundary

  • Scripted enforcement tests follow proposals through actual compilation, runtime checks, handler execution, and independently checked state; they test selected paths, not live-model proposal frequency.The tests start from fresh empty registers and check displayed fields against executions.Source: §11.2 · p. 19

A: direct selection outside the declared authority

  • A direct RegisterInvoice proposal by InvoiceDesk is refused with zero handler calls and an empty register, while delegation to InvoiceClerk produces one entry under the same source and input.The selecting agent’s authority determines which path is executable.Source: A: direct selection outside the… · p. 19

B: the tool’s resource contract

The journal variant separates human approval from resource authority, while the invoice tests show how exhausted quotas block further effects without undoing earlier writes.

B: the tool’s resource contract

C: a second proposal meets an exhausted quota

  • With a one-call limit, the second tool proposal is refused after one write; a two-call limit permits both writes, and checkpoint resumption preserves the counter.The control demonstrates reuse under fresh occurrences, not business-level deduplication; the later refusal does not roll back the first effect.Source: B: approved continuation, missing… · p. 21, C: a second proposal meets an… · p. 21
  • The tests isolate declared use, resource grants and scopes, and the remaining-call condition; a failed premise prevents dispatch even when the proposal is well typed.Trace order locates refusal, while independent counters and registers establish what ran.Source: C: a second proposal meets an… · p. 23

12 Execution Study and Artifact Validation

The execution study pairs business-outcome evaluation with deterministic checks of governance contracts. Across the evaluated models, native Touba matches the highest observed completion count, while the artifact tests examine runtime enforcement separately.

12.1 Business Cases and Common Conditions

  • Seven business cases, seven models, and five methods were assessed with five repetitions per case and method, yielding 1,225 observations.Completion required an exact match to stored effects or the typed final answer and valid termination within shared budgets.Source: §12.1 · pp. 23–24

12.2 Observed Outcomes and Decision Interfaces

  • Native Touba matches the highest observed completion count for each model, including framework ties; structured Touba is lower on three models and tied on four.All five methods reach the same ceiling on Astra, Sonnet, and Argon; Figure 7 shows completion counts and Figure 8 summarizes paired differences, whose intervals all include zero.Source: §12.2 · p. 24, Figure 7 · p. 25, Figure 8 · p. 26
  • The 67 unsuccessful observations comprise 31 business mismatches and 36 operation-budget exhaustions; the Touba business traces contain no admission refusals.All 36 exhaustions reached the shared service-operation limit; refusal evidence instead comes from the scripted enforcement tests.Source: §12.2 · p. 26, Table 7 · p. 26

12.3 Artifact Validation through Invariant Coverage

  • Deterministic governance tests trace declared contracts through source, AIR, runtime admission, and effects, pairing inadmissible proposals with permitted controls.The checks validate implementation behavior; the business oracle separately evaluates task completion.Source: §12.3 · p. 27, Table 8 · p. 27

13 Discussion and Validity

The discussion links responsibility contracts, execution rules, and evidence while distinguishing demonstrated results from unresolved validity and assurance boundaries. The conclusion frames PAP as an explicit responsibility boundary connecting mandate, authority, and attributable effects.

13.1 What the Evidence Establishes

  • Refusal tests connect permission checks to responsibility and prevented effects, while authorized controls show the same boundary permits valid work.Business outcomes compare model-facing representations under fixed runtime authority.Source: §13.1 · p. 28

13.2 Experimental Scope

  • The seven-case study assesses 1,225 observations, but visible development cases, nonrandom method order, and adapter differences constrain interpretation.Exact stored-state checks support these test outcomes; new task families and randomized order would test generalization, while production adds service failures, latency, and different data distributions.Source: §13.2 · p. 28

13.3 Assurance Scope

  • Formal assurance covers the chosen kernel and defined Touba fragment; full-implementation preservation requires verification of lowering, context, and guard mechanisms.Durable distributed effects and physical trace preservation require additional models.Source: §13.3 · p. 28

14 Conclusion

  • PAP makes responsibility boundaries explicit programming objects linking an agent’s mandate to executable authority and attributable effects.The comparison places this abstraction among complementary traditions in computation, agency, orchestration, and policy.Source: §14 · p. 28
  • Scripted tests show a forbidden direct call stops before handler entry, a missing grant prevents a write, and a quota blocks a repeated call.Independent state checks establish consequences; models propose actions while declared authority governs effects.Source: §14 · p. 29

A Touba Decision Interfaces

  • The appendix introduces the two decision representations used in the SDK configurations.The supplied passage identifies the configurations but does not describe their contents.Source: A Touba Decision Interfaces · p. 30

A.1 Structured Decision Interface

The appendix specifies structured and native decision-interface configurations and shared model profiles. It also identifies representation and conversation structure as variables for controlled tests, without attributing observed differences to training familiarity.

A.1 Structured Decision Interface

  • The default structured interface asks the model for one typed decision object that can propose an authorized capability, request available review, or return a final value.The shown configuration selects the structured decision interface.Source: §A.1 · p. 30, Structured interface: default · p. 30

Structured interface: default

  • The structured configuration uses the SDK decision provider with the model and instructions to use observed data and authorized capabilities.The excerpt supplies the import and configuration lines.Source: Structured interface: default · p. 30

A.2 Native Function Interface

Native function interface: opt-in

  • Both representations receive the same goal, observations, and authorized catalogue, with the runtime checks described for the study.The SDK retains original provider messages and metadata in bounded history isolated to each invocation.Source: Native function interface: opt-in · p. 30

A.3 Model Profiles Used in the Execution Study

  • Table 9 gives per-request token ceilings by model, with each model using one profile across methods and profiles varying between models.The excerpt notes provider-specific reasoning settings and that temperature is omitted for these reasoning profiles.Source: Table 9 · p. 31, §A.3 · p. 31

A.4 Interpreting Representation Differences

  • Training familiarity is only a hypothesis; the study does not observe training data or isolate a training effect.The API exchange, decision schema, and conversation structure are proposed as variables for controlled tests.Source: §A.4 · p. 31
  • Testing whether Touba-specific fine-tuning improves structured-interface use requires a fixed base model, held-out task families, matched prompts and budgets, and paired outcome checks.The proposed experiment would also measure refusals and unsafe effects.Source: §A.4 · p. 31

B Mediation Kernel and Proofs

The mediation kernel specifies closed execution rules and proves conditional safety properties by induction. Its results depend on the stated model assumptions and do not establish business-result correctness or exactly-once external effects.

B.1 State and Closed Rules

  • The kernel models requests, operation preparation, human decisions, dispatch, observation, completion, cancellation, and failure as transitions over a state with an audit trail.Admission failures refuse without dispatch; cancellation does not undo an in-flight operation.Source: §B.1 · pp. 31–32
  • The rules do not prove stack correctness or selection of a correct business result.Composed operations may proceed without another provider request, and the engine determines when finalization is appropriate.Source: §B.1 · p. 32

B.2 Witness Construction

  • When the admission guard holds, the constructed dispatch witness matches the required pre-state fields and guard condition.This construction is a result within the model, not verification that a runtime record is true.Source: §B.2 · pp. 32–33

B.3 Inductive Properties

  • Induction establishes that contracts remain fixed and every dispatch has a valid pre-state witness, even for arbitrary provider responses.Each occurrence dispatches at most once, and required human approval must be correlated and favorable.Source: §B.3 · p. 33
  • The model bounds provider and tool calls, permits at most one final request, and prevents its response from authorizing another operation.At-most-once dispatch per occurrence in the crash-free model is not exactly-once effects or linear capability consumption.Source: §B.3 · p. 33
  • The logical audit records each transition label, assuming lossless abstract recording.Observer failures, crashes, and fragmented journal/checkpoint evidence remain separate obligations.Source: §B.3 · p. 33
  • When admission predicates hold and quota remains, the model provides a dispatch path with or without a required human checkpoint.A conforming observation returns to idle and allows another fresh occurrence.Source: §B.3 · pp. 33–34

C A Touba Fragment and Its Preservation Proof

The preservation result concerns a defined sequential Touba fragment, its lowering, and source and graph engines using the mediation kernel. The scope excludes several language and runtime features, while the proof preserves contracts and execution correspondence under its stated assumptions.

C.1 Scope, Values, and Resolved Modules

  • The fragment uses a finite acyclic module graph, typed values and expressions, resolved references, and sequential control flow, while excluding recursion, concurrency, crashes, and provider-initiated review.Loops and repeated selections remain allowed, so bounded call depth does not bound the number of operations.Source: §C.1 · pp. 34–35

C.2 Contracts and Lowering

  • Lowering preserves declaration identity, contracts, source origins, and continuations, while corresponding source and graph expressions produce corresponding typed values or the same error.Imports transport existing authority references rather than adding use, caller, memory, or secret grants.Source: §C.2 · p. 35

C.3 Engines, Resources, and Human Checkpoints

  • The engines use shared contracts and host outcomes to check calls, resources, and tool dispatch, while human checkpoints save and release program continuations.A missing decision leaves the engine waiting; approval resumes saved state, and tool admission checks liveness again after the wait.Source: §C.3 · pp. 36–37
  • The source-engine result does not assume deep saved-call-stack serialization, persistence, approver authentication, or recovery of external effects.For this realization, operation-bound human approval remains a separate contract.Source: §C.3 · p. 37

C.4 Simulation and Evidence

The backward simulation matches graph-engine steps to source-engine steps while preserving visible dispatch and checkpoint labels. The authors also disclose that they developed Touba and designed and analyzed this evaluation.

C.4 Simulation and Evidence

  • A backward step simulation matches every graph-engine move to a source move, up to administrative stuttering, while preserving related states and visible dispatch or checkpoint labels.The relation aligns frames, live values, loop cursors, continuations, and runtime state under renaming.Source: §C.4 · p. 37
  • The proof covers matching loop, call, agent, request/reply, and tool transitions, with tool guards and failures aligned by equal premises and contracts.Resource guards follow their explicit definitions rather than presuming source authorization.Source: §C.4 · pp. 37–38
  • Human-node approval restores matching cursors and counters and releases the saved continuation without traversing prior effects or changing uses, callers, scopes, or grants.The same supplied site decision is consumed in both engines; waiting has no ordinary successors.Source: §C.4 · p. 38
  • Induction over finite graph executions yields matching source executions and equal projected dispatch sequences, with a valid kernel witness for every dispatch.The public evidence projection retains run and occurrence identity, origin, tool, ownership and agent references, and contract references, while omitting secret material and argument values.Source: §C.4 · p. 38

Author Relationship to the Evaluated System

Loading 2610.33312v1…