Responsibility, Delegation, and Authority

Responsibility exists before execution

A system can decompose work correctly and still fail because nobody can say who owns the outcome. For every material region, the architecture must distinguish parent accountability, execution responsibility, Decision authority, redelegation rights, verification responsibility, acceptance authority, and the Actors who must be consulted or informed. Those positions may belong to different participants. A coding Resource can implement a change while a security reviewer verifies one set of Obligations, a human retains architecture and release authority, and the Agent identity remains accountable for the user-facing Commitment. Responsibility therefore has its own topology. The Responsibility Graph need not mirror the Work decomposition, and neither graph needs to resemble the runtime tree of agents.

Actor, Principal, Resource, and Role describe different things

An Actor can participate in work, responsibility, Decision, Observation, or effect: a human, organization, service, Agent identity, model-backed executor, or external institution. A Principal is the Actor whose legitimate authority is represented or exercised, such as the user, organization, account owner, or project owner. A Resource contributes cognition, knowledge, Observation, computation, or execution; it may be a model, human expert, compiler, database, browser worker, or organization. A Role is an abstract responsibility contract such as Researcher, Designer, Operator, Controller, or SecurityReviewer. A Resource may fulfill a Role for one assignment without becoming a permanent persona. This matters because current multi-agent systems often infer responsibility from agent identity: the component named Reviewer is assumed to review, or the Planner is allowed to redefine work because planning is its persona. Persistent Semantic Agency assigns responsibility explicitly and treats the selected Resource as replaceable.

Capability, Ability, Authority, and Eligibility are independent

A Capability formally describes an operation or cognitive function. Ability means a Resource can technically perform it. Authority means an Actor or assignment is permitted to perform it within a scope. Eligibility means the Resource may be selected for this responsibility now.

SEMANTIC LOGICAbility ≠ Authority
Capability available ≠ Capability authorized

Eligibility may require Ability, Authority, policy compliance, scope compatibility, availability, budget, privacy compatibility, and the necessary independence. A strong model may be technically able to review its own output and still be ineligible because the Obligation requires independent verification. A human may hold valid Decision authority but be unavailable before the relevant deadline. Resource selection is therefore a governed systems decision rather than model routing.

Delegation is compiled from responsibility

A valid delegation answers three separate questions:

SEMANTIC LOGICWHAT responsibility should move?
WHO is eligible to receive it?
HOW should it be represented for that Resource?

Only the third question may produce a prompt, API task, human decision package, or work order. The canonical object is a DelegationContract with stable identity, revision, provenance, acceptance, and lineage. A representative contract can express the full boundary:

YAMLdelegation:
  parent_work: W-17
  delegator: Agent
  assignee: security-reviewer

  responsibility:
    determine whether the proposed session architecture
    satisfies the security obligations

  purpose:
    independent review before architecture approval

  expected_outcome:
    schema: SecurityReviewV1

  scope:
    include:
      - session lifecycle
      - credential storage
      - account recovery
    exclude:
      - billing

  authoritative_inputs:
    - architecture D-18
    - requirements R-7
    - threat-model TM-3

  invariants:
    - no reusable credentials in model context

  known_unknowns:
    - U-23

  allowed_capabilities:
    - repository.read
    - security_reference.search

  forbidden_capabilities:
    - repository.write
    - deployment.modify

  budget:
    reasoning: high
    time: bounded

  evidence_required:
    - finding-to-source mapping
    - obligation coverage

  escalation:
    target_ambiguity: NEEDS_DECISION

  redelegation:
    research: allowed
    final_review: forbidden

  completion:
    assignee_may_submit_result: true
    assignee_may_close_parent: false

The Resource-specific prompt is a rendering of this object. It is not the object itself.

Context follows the assignment

A delegate should not receive the full conversation, project, Memory store, tool catalogue, or policy corpus. The Delegation Compiler derives a ContextPack from the accepted responsibility: purpose and expected outcome, relevant Work ancestry, authoritative inputs, effective Decisions and invariants, known Unknowns and contradictions, a DomainModelSlice, sibling interfaces, applicable Procedures and Policies, available Capabilities and Authority, and the Evidence expected in return. The minimum-sufficient rule is not only a privacy measure. It improves focus, cost, independence, reproducibility, and security. A reviewer who must judge an Artifact may deliberately receive the Obligations and authoritative inputs without the producer's persuasive narrative. A specialist model may see the exact domain slice needed for one analysis while remaining unable to infer unrelated personal or organizational information.

Instructions are derived from ordered authority

A delegated instruction package should not be an improvised giant prompt assembled from whichever text happens to be nearby. Its content is compiled from ordered semantic layers:

SEMANTIC LOGICCore invariants
+ Organization Policy
+ Principal Policy
+ Module rules
+ Role contract
+ Project and Work rules
+ effective parent Decisions
+ specific ResponsibilityAssignment
→ Delegated Instruction Package

Conflicts are resolved through Authority and typed merge semantics rather than recency, textual position, or rhetorical force. Lower layers may specialize and narrow higher ones; they may not silently weaken them.

Delegation is negotiated

Sending a contract does not make it valid. A receiving Resource may accept, decline, request clarification, request redecomposition, report insufficient Authority, report unavailable Capability, or identify a conflict with an invariant.

SEMANTIC LOGICACCEPT
DECLINE
NEEDS_CLARIFICATION
NEEDS_REDECOMPOSITION
AUTHORITY_INSUFFICIENT
CAPABILITY_UNAVAILABLE
CONTRACT_CONFLICTS_WITH_INVARIANT

This challenge mechanism is important because the recipient may detect a defect invisible to the delegator: the responsibility mixes incompatible duties, omits a required source, cannot produce the requested Evidence, or asks for an outcome outside the available Authority. The Resource can expose that defect without silently redesigning the assignment.

Recursive delegation only narrows

Delegation may recurse, but every child remains inside the parent envelope:

SEMANTIC LOGICAuthority(child delegation)
⊆
Authority(parent delegation)

The same attenuation applies to data, Capabilities, credentials, budget, purpose, time, region, and redelegation power. Macaroons provide an established security precedent for delegated authorization with contextual caveats and attenuation.^{[1]Capability security and authorizationsourceOpen bibliography entry →} Biscuit similarly demonstrates offline-verifiable tokens whose rights can be narrowed without returning to the original issuer.^{[2]Capability security and authorizationsourceOpen bibliography entry →} These systems do not model semantic responsibility, but they establish a crucial mechanism: delegated power can be bounded rather than copied as ambient access.

Accountability remains continuous

Delegation transfers defined responsibility; it does not erase the accountability above it.

SEMANTIC LOGICAgent owns user Commitment
→ delegates provider research to Researcher
→ Researcher fulfills research responsibility
→ Agent still owns the user Commitment

A worker may fulfill its assignment while lacking Authority to close the parent. A reviewer may satisfy a verification Obligation without release authority. A human may accept one Result while another Obligation remains open. Keeping these facts separate prevents the familiar organizational failure in which every participant completed “its part” and nobody remained answerable for the outcome.

The model has substantial ancestry

The Contract Net Protocol formalized distributed allocation through announcement, bidding, award, and reporting.^{[3]Social commitments, interaction, and delegationsourceOpen bibliography entry →} Commitment-oriented multi-agent research moved coordination beyond internal mental states by representing social commitments and protocols over them.^{[4]Social commitments, interaction, and delegationsourceOpen bibliography entry →[5]Social commitments, interaction, and delegationsourceOpen bibliography entry →} Recent systems narrow the claim further. LoopX's accepted Semantic Work Handoff RFC preserves purpose, context, Decisions, constraints, Evidence, current Commitments, and expected return across manager-to-worker and worker-to-worker collaboration; it also distinguishes receipt, assessment, plan change, completed work, and delivered answer.^{[6]Semantic persistence and workflow/state representationssourceOpen bibliography entry →} iCORE couples observable cooperation to evolving Work and assignment Obligations, then links their transitions to Evidence-bearing audit maps.^{[7]Obligations, accountable coordination, and closed-loop governancesourceOpen bibliography entry →} The contribution here is therefore not the discovery of contracting or semantic handoff. It is the domain-independent integration of DelegationContract, Commitment lineage, Context compilation, heterogeneous Resources, purpose-bound compositional Authority, independent Assurance, hierarchical Closure, and learning over delegation quality.

Responsibility can use compositions of Resources

Some responsibilities should intentionally assemble several independent or complementary Resources:

SEMANTIC LOGICindependent Researcher A
+ independent Researcher B
→ synthesis Resource
→ human Decision

SEMANTIC LOGICimplementation executor
→ independent verifier
→ Acceptance authority

SEMANTIC LOGICdeterministic scanner
+ specialist model
+ external reference
→ architecture Decision

A ResourceComposition records participants, Roles, information boundaries, aggregation method, conflict policy, and Closure policy. The system forms a temporary cognitive or execution arrangement appropriate to the responsibility instead of assuming one universally capable model or one permanent agent team.

Authority remains bound to purpose

Authority belongs to a Principal, purpose, responsibility, and scope. A valid credential or individually permitted Capability cannot be reused for an unrelated objective simply because it is available.

SEMANTIC LOGICEffect
must be justified by
ResponsibilityAssignment
within
Commitment and Principal Authority lineage

This Intent Binding limits prompt-injection blast radius. External content may influence a proposal; it cannot invent a new legitimate purpose for action.

Long-horizon Authority is compositional

Per-call authorization is too weak for systems that accumulate effects.

SEMANTIC LOGICread private document       allowed
send ordinary email         allowed

email private contents externally
                            not implied

Authority admission may consider the proposed action, prior effects in scope, accumulated spend, delegated purpose, resulting information flow, irreversibility, and policy thresholds. This is history-sensitive, compositional Authority. Emerging research on task-scoped authorization and propagation across multi-agent systems supports the problem statement.^{[8]Capability security and authorizationsourceOpen bibliography entry →[9]Capability security and authorizationsourceOpen bibliography entry →} The larger integration with Commitment, Responsibility, Memory, Evidence, and Closure remains the architectural synthesis proposed here.

Capabilities carry effect semantics

A Capability requires more than an input schema. Its contract may describe identity and version, input and output, effect class and scope, Authority and credential requirements, risk and reversibility, idempotency and transaction behavior, cost and latency, Evidence produced, Observation semantics, and failure or retry rules. Effect classes may distinguish pure computation, read Observation, internal mutation, reversible or irreversible external effect, financial effect, communication effect, and physical effect. Tool availability never grants Authority because the same technical operation can be legitimate in one responsibility and prohibited in another.

Credentials stay outside model context

Work semantics refer to an opaque CredentialBindingRef. Resolution occurs at the execution boundary only after checking Principal, assignment, purpose, Capability, AuthorityEnvelope, policy, and effect history. API keys, OAuth tokens, cloud credentials, SSH keys, passwords, and financial credentials therefore remain reusable secrets held by a broker rather than ordinary text available to the Reasoner. A model may request an authorized effect without receiving the power to cause arbitrary effects with the same credential.

Delegation quality can be measured

Failure analysis must distinguish executor failure, wrong Resource selection, a bad responsibility boundary, insufficient Context, contradictory instructions, insufficient Authority, a missing Evidence contract, and weak verification design. These failures require different recovery and should not be compressed into one model-quality score. Delegation quality can therefore be evaluated through coverage, ambiguity, duplication, Context sufficiency, Authority correctness, Resource suitability, independence, verification completeness, and cost efficiency. Learning may improve the Procedures that create these contracts. It may not learn that the Agent has more Authority.

The stronger delegation question

The current generation often asks which subagent should receive a prompt. Persistent Semantic Agency asks something harder:

What responsibility boundary will preserve purpose, Authority, accountability, Evidence, and Closure when this work is performed by another Resource? That question applies equally to a frontier model, a local model, a compiler, a human expert, a bank, a government office, or a physical technician.