Responsibility Boundaries for Agentic Systems: A Comparative Evaluation of Probabilistic Agentic Programming
Organizations: Electrical & Computer Engineering, LSSI, UQTR · Mathematics & Computer Science, LSSI, UQTR
Abstract
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.
Figures & tables
| Threat | Required condition | Boundary response | Evidence or remaining obligation |
|---|---|---|---|
| Unlisted tool or invalid caller | Trusted identity and usage/caller guards | Refused before handler dispatch | Kernel proof; compiled delegation and direct-call checks. |
| Missing resource grant or exhausted quota | Correct resource evaluators and counters | Refused at admission | Compiled resource tests and independently observed writes. |
| Missing required human decision | Approval contract defined in Section 8.3 | Wait or refuse according to that contract | Kernel proof and compiled checkpoint tests. |
| Injected or false observation | Provider cannot change authority; all effects mediated | An inadmissible proposal is blocked | Business outcomes checked separately by the task oracle. |
| Malicious authorized handler | Handler already admitted | Handler internals are outside the kernel | Requires effect isolation or service-side enforcement. |
| Policy changes between check and effect | Atomic admission inputs in the model | No distributed race guarantee | Requires a service-side authorization/commit protocol. |
| Aspect | Operational meaning |
|---|---|
| Declared mandate | States the intended task. Automatically checking its fulfilment requires explicit business criteria beyond the natural-language description. |
| Executable contracts | Determine permitted capabilities, callers, resources and required review. These conditions govern whether an operation may start. |
| Action attribution | Connects a proposal, authorization decision and effect to the responsible context and source contracts. |
| Notation | Meaning in the kernel |
|---|---|
| Fixed source contracts and host contracts . | |
| Current state, its control phase, and successor state. | |
| Prepared operation and its fresh occurrence identifier. | |
| Verified context, target tool, argument values, host binding, and parent reference carried by . | |
| Guard names and the Boolean check indexed by . | |
| Whether human approval is required, and whether a valid favorable decision for this occurrence has been received. Both are Boolean. |
| Tradition | Central abstraction | Responsibility-boundary question |
|---|---|---|
| Structured, functional, modular, and object-oriented programming | Control flow, expressions, interfaces, objects | Which probabilistic action belongs to which declared responsibility, effect, authority, and evidence boundary? |
| Actors | Active entities and messages | Which authority, capability, validation, and trace obligations govern an active unit? |
| Agent-oriented programming and BDI | Agents, beliefs, desires, intentions, commitments | How is an agent’s autonomy bounded by executable responsibility and authority contracts? |
| LLM tool-use stacks and protocols | Model-driven tool selection, handoffs, sessions, orchestration | Where are tool, secret, memory, review, and evidence boundaries represented and enforced? |
| Workflow and durable execution | Ordered, persistent, resumable activities | Who is responsible for probabilistic choices and effects inside the durable process? |
| Policy languages | Authorization decisions over subjects, actions, and resources | How does authorization combine with execution, validation, memory, and evidence? |
| Architectural obligation | Touba realization | Possible Python design | Possible Rust design |
|---|---|---|---|
| Authority comes from verified contracts. | Source responsibility, uses and caller relations; runtime context. | Explicit policy records and a dispatcher that establishes the caller. | Encapsulated capability values and a dispatcher that establishes the caller. |
| Effects require permission checks. | Binding, grant, scope and budget checks before handler dispatch. | Broker checks policy and counters before invoking a callable. | Controlled effect API checks permissions and counters before invoking a handler. |
| Human decisions satisfy declared obligations. | Source checkpoint, waiting state and checked continuation. | Explicit approval state and checked resumption. | Approval and continuation state types plus runtime decision checks. |
| Effects and refusals remain attributable. | Source/AIR references, runtime identities and structured trace. | Correlated responsibility, policy and invocation records. | Correlated responsibility, capability and invocation records. |
| System | Capability and delegation representation | Human/resource representation | Evidence used here |
|---|---|---|---|
| Touba | Source interfaces, uses , callable_by , strategy and AIR; runtime admission. | Source checkpoints and memory/secret contracts; shared service approval and records in the business study. | Compiled contract tests, runtime traces and independent service-state checks. |
| OpenAI Agents SDK | Configured agent tools and output type; adapter sequences stages and validates outputs. | Tool approval is available in the SDK; adapter uses the shared service, not native review. | Source inspection and scripted adapter tests; SDK tracing disabled, model/service telemetry retained. |
| LangChain | createAgent , tool schemas and structured output; adapter sequences stages. | Review middleware is available; adapter configures neither it nor a checkpointer. | Source inspection and scripted adapter tests; captured exchanges and service state. |
| LangGraph | Prebuilt ReAct agent and tool binding; adapter sequences stages and validates outputs. | Interrupt/resume and checkpointing are available; adapter does not configure them. | Source inspection and scripted adapter tests; captured exchanges and service state. |
| Model | Touba S | Agents SDK | LangChain | LangGraph | Touba N |
|---|---|---|---|---|---|
| GPT-4o mini | 14/0 | 0/14 | 0/10 | 0/5 | 5/0 |
| GPT-4.1 mini | 1/0 | 0/0 | 0/0 | 4/0 | 0/0 |
| GPT-6 Astra | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 |
| Claude Haiku 5.5 | 4/0 | 1/0 | 2/0 | 0/0 | 0/0 |
| Claude Sonnet 5.5 | 0/0 | 0/0 | 0/0 | 0/0 | 0/0 |
| Gemini 3.8 Flash | 0/0 | 0/2 | 0/5 | 0/0 | 0/0 |
| Contract area | Checked obligation |
|---|---|
| Trace forensics | Reconstruct dispatch, refusal, and review pause from events. |
| Trigger identity | Accept a valid event; refuse replay and source mismatch. |
| Memory provenance | Preserve metadata and refuse raw-content or secret leakage into evidence. |
| Memory contamination | Keep injected memory content out of public traces across reads and writes. |
| Runtime budgets | Refuse excess tool calls, agent invocations, and dispatch after timeout. |
| Supply-chain integrity | Refuse a missing lock or changed handler and manifest artifacts. |
Appendix figures & tables1 asset
Supplementary material from the paper’s appendix.
Appendix
| API model identifier | Sampling | Output limit |
|---|---|---|
| gpt-4o-mini-2024-07-18 | 1,000 | |
| gpt-4.1-mini-2025-04-14 | 1,000 | |
| gpt-6-astra | Low effort | 4,096 |
| claude-haiku-5-5 | Low effort | 4,096 |
| claude-sonnet-5-5 | Low effort | 4,096 |
| gemini-3.8-flash | Low thinking | 8,192 |
AI Agent Governance
AI agent governance studies how to authorize, constrain, monitor, and hold autonomous and multi-agent systems accountable.
See all 446 papers