research-document

04 obligations as agent work queues research prompt

Research Area: General Research
Status: draft
Version: 0.1
Priority: medium
Updated: 2026-07-22
Source: research/state-constrained-architecture/prompts/04-obligations-as-agent-work-queues-research-prompt.md

AI RESEARCH MISSION 04 — OBLIGATIONS AS AGENT WORK QUEUES

ROLE

Act as a combined:

AI-agent systems researcher
workflow systems researcher
automated-planning researcher
deontic-logic researcher
policy-systems researcher
distributed-systems researcher
software-architecture researcher
AI inference-cost researcher
empirical software-engineering researcher

Your task is to investigate whether explicit machine-readable obligations can substantially reduce the amount of open-ended reasoning, monitoring, search, context retrieval, and planning required by autonomous AI agents.

Do not assume the hypothesis is true.

Be skeptical and evidence-driven.

The central architectural idea is:

Capabilities describe what MAY be done.

Obligations describe what MUST be resolved.

Instead of asking an AI agent:

"Monitor the system and figure out what needs attention."

the system may expose:

O-17 ReconcileUnknownRefund
O-18 RefreshFraudEvidence
O-19 ResolveConditionalApproval
O-20 ReviewExpiredCertification

Each obligation may contain:

subject
reason
state that caused it
policy/version
supporting evidence
satisfaction criteria
available capabilities
missing prerequisites
deadline
priority
authority
provenance
current obligation state

The research question is:

Does converting unresolved consequential work into explicit obligations
reduce agent execution cost and improve correctness?

======================================================================

PRIMARY RESEARCH QUESTION ======================================================================

Does an explicit obligation model reduce:

open-ended exploration
repository/database search
monitoring burden
context tokens
planning tokens
tool calls
repeated rediscovery
forgotten work
duplicated work
invalid remediation attempts
human supervision
total cost per correct completion?

And does it improve:

task completeness
prioritization
traceability
auditability
policy compliance
recovery from interrupted agent runs?

====================================================================== 2. CORE ARCHITECTURAL MODEL

The proposed system distinguishes:

State
Capability
Obligation

Example:

State:

RefundExecution = OutcomeUnknown

Capabilities:

ReconcileRefund
InvestigatePaymentProvider

Unavailable:

RequestRefund

Obligation:

ReconcileUnknownRefund

The system is not merely saying:

"Refund is unavailable."

It is also saying:

"This unresolved condition must be handled."

====================================================================== 3. WORKING DEFINITION OF OBLIGATION

Use this candidate definition:

An obligation is a versioned, attributable requirement for some condition
to be resolved, satisfied, waived, escalated, superseded, or otherwise
dispositioned because of state, evidence, policy, or an event.

An obligation is not:

a generic TODO item
a natural-language reminder
a mere notification
a capability
permission
arbitrary task assignment

Investigate whether this definition is precise enough.

====================================================================== 4. OBLIGATION LIFECYCLE

Candidate lifecycle:

Raised
    ->
Acknowledged
    ->
InProgress
    ->
Satisfied

Alternative dispositions:

Waived
Escalated
Blocked
Superseded
Cancelled if legitimately invalidated

Potential overdue state:

Overdue

Important principle:

Missing a deadline should not usually erase the obligation.

Instead:

obligation remains unresolved
    +
overdue/escalation semantics apply

Investigate existing obligation/task/workflow lifecycle models.

====================================================================== 5. CAPABILITY + OBLIGATION DUALITY

Investigate this conceptual duality:

Capabilities = legal frontier
Obligations = required frontier

Example:

Capability:
    CapturePayment

means:

"You may capture payment now."

Obligation:

ResolveConditionalApproval

means:

"This condition must eventually be resolved."

Ask:

Is this duality already formalized in:
    deontic logic
    normative multi-agent systems
    workflow systems
    policy languages
    BDI architectures
    compliance systems?

Determine whether this is new terminology or an established construct.

====================================================================== 6. OBLIGATION VS TASK

Distinguish:

business obligation

from:

execution task

Example:

Obligation:

ReconcileRefundOutcome

Possible tasks:

QueryPaymentProvider
SearchSettlementReport
RequestHumanReview

The obligation persists until the satisfaction condition is met.

A task can fail or be replaced without removing the obligation.

Investigate whether separating:

requirement to resolve

from:

current procedure

improves agent robustness.

====================================================================== 7. SATISFACTION CONDITIONS

Each obligation should define machine-checkable satisfaction criteria where possible.

Example:

Obligation:

ResolveConditionalApproval

Satisfied when:

ApprovalState = FullyApproved

OR:

ApprovalState = Rejected

This is stronger than:

agent marks task "done"

Research whether explicit satisfaction conditions reduce false completion by agents.

====================================================================== 8. OBLIGATION CREATION

Obligations may arise from:

state transitions
policy changes
evidence invalidation
external-effect uncertainty
deadlines
failed processes
compliance rules
detected inconsistencies
human decisions
trusted events

Examples:

RefundExecution = OutcomeUnknown
    ->
ReconcileRefund

Evidence invalidated
    ->
ReassessDependentClaim

Policy version changes
    ->
ReassessFraudEligibility

Research analogous event-condition-obligation systems.

====================================================================== 9. OBLIGATION PROVENANCE

An obligation should carry provenance.

Potential fields:

obligation ID
subject
created by
creation event
reason
policy/version
evidence
timestamp
actor
authority
satisfaction criteria

Question:

Does provenance reduce agent context requirements because the agent no
longer needs to reconstruct why the work exists?

====================================================================== 10. OPEN-ENDED AGENT VS OBLIGATION-DRIVEN AGENT

Compare:

A. Open-ended agent:

"Monitor payments and handle anything that needs attention."

B. Obligation-driven agent:

O-17 ReconcileRefundOutcome
    Reason:
        Refund request timed out.

    Current:
        RefundExecution = OutcomeUnknown

    Satisfaction:
        Provider outcome established

    Available:
        QueryRefundStatus
        ReconcileSettlement

Measure:

context
tokens
tool calls
time
success
omissions
duplicate actions

====================================================================== 11. WORK DISCOVERY COST

Open-ended autonomy requires the model to infer:

what has changed?
what is important?
what remains unresolved?
what should be prioritized?
what was already handled?
what is stale?
what can be safely ignored?

Explicit obligations may answer many of these deterministically.

Research how much autonomous-agent cost is spent on:

work discovery
monitoring
prioritization
state reconstruction
repeated polling

====================================================================== 12. OBLIGATIONS AS CONTEXT COMPRESSION

Hypothesis:

An obligation can summarize the minimum actionable semantic context around
unresolved work.

Instead of reading:

payment logs
service code
prior agent runs
policy documents
database rows

the agent receives:

ReconcileRefundOutcome

because:
    provider outcome unknown

observed at:
    RefundExecution v18

policy:
    PaymentsPolicy@7

satisfaction:
    outcome = Succeeded | Failed

available:
    QueryProvider
    ReconcileSettlement

Measure whether obligation records act as semantic context compression.

====================================================================== 13. OBLIGATION-DRIVEN PLANNING

An obligation supplies a goal condition.

Example:

Obligation:
    ShipApprovedOrder

Satisfaction:

ShipmentState = Shipped

Current:

PaymentState = Authorized

Required:

PaymentState = Captured

Legal producer:

CapturePayment

This naturally creates:

obligation
    ->
satisfaction goal
    ->
missing prerequisite
    ->
legal transition
    ->
next state

Compare with:

backward chaining
goal regression
HTN planning
BDI intention formation
workflow scheduling

====================================================================== 14. OBLIGATION DOES NOT GRANT CAPABILITY

Important rule:

Obligation != authority.

Example:

Obligation:
    ReassessDiagnosis

The agent may:

gather evidence
propose reassessment
schedule review

But only an authorized clinician capability may:

EstablishDiagnosis

Research whether existing normative systems distinguish:

duty

from:

permission/authority

and what errors occur when systems do not.

====================================================================== 15. BLOCKED OBLIGATIONS

An obligation may be valid but currently impossible to satisfy.

Example:

ResolveApprovalConditions

Blocked because:

RequiredEvidence unavailable

or:

RequiredAuthority unavailable

The obligation should not disappear.

Possible state:

Blocked

with:

blocking prerequisites
responsible owner
escalation rules

Investigate whether explicit blocked-state obligations improve agent behavior compared with repeated failed attempts.

====================================================================== 16. CONFLICTING OBLIGATIONS

Two obligations may conflict.

Example:

ReleaseShipmentImmediately

and:

HoldShipmentForFraudReview

The system should not silently choose.

Possible representation:

ObligationConflict {
    obligations = [A, B]
    state = Unresolved
}

Investigate:

deontic conflicts
contrary-to-duty obligations
policy conflicts
priority rules
normative multi-agent systems

Question:

Should conflict resolution be deterministic policy,
agent reasoning,
or human escalation?

====================================================================== 17. PRIORITY

Obligations may have:

urgency
severity
policy priority
deadline
business impact
safety impact

Do not assume a single numeric priority is adequate.

Research:

scheduling systems
incident-management priority
real-time systems
multi-objective planning
deontic priority

Ask:

Can explicit priority reduce agent deliberation cost?

Or:

does it merely hide subjective policy decisions?

====================================================================== 18. WAIVER

An obligation may be waived.

Waiver should itself be governed.

Possible requirements:

authority
reason
policy basis
expiration
provenance
evidence

The agent should not simply mark:

"not needed"

Investigate:

compliance exception systems
waiver workflows
policy override models

====================================================================== 19. ESCALATION

An obligation may require escalation when:

blocked too long
deadline passes
conflicting obligations exist
authority missing
risk threshold exceeded

Research whether escalation can be generated deterministically.

====================================================================== 20. SUPERSESSION

A new state or policy may supersede an obligation.

Example:

Obligation:
    CompleteFraudReview

but:

OrderCancelled

may render it irrelevant.

Do not simply delete it.

Record:

Superseded
by OrderCancelled@v19

Research temporal/workflow systems for similar semantics.

====================================================================== 21. POLICY CHANGES AT SCALE

Policy changes may generate enormous obligation populations.

Example:

New verification rule affects 500,000 customers.

Do not assume the runtime should immediately instantiate 500,000 heavyweight workflow objects.

Investigate:

lazy obligation materialization
policy impact sets
batch obligations
obligation rules
work queues
event sourcing
database query-driven task generation

Potential architecture:

ObligationRule
    ->
affected population
    ->
lazily materialized instances

====================================================================== 22. OBLIGATION BATCHES

Possible construct:

ObligationBatch

Example:

ReverifyAccessibilityEvidence
PolicyChange = VerificationPolicy@12
Population = 83,219 records

Track:

total affected
pending
in progress
satisfied
waived
escalated

Research scalable compliance/remediation architectures.

====================================================================== 23. AGENT RESUME / INTERRUPTION

Agents may stop because of:

timeout
context limit
model crash
deployment
human interruption

Explicit obligations could make resumption easy.

New agent receives:

outstanding obligations

rather than reconstructing incomplete work from history.

Measure:

recovery tokens
duplicate actions
missed work

This may be important for long-running autonomous agents.

====================================================================== 24. MULTIPLE AGENTS

Obligations may provide a coordination layer across agents.

Example:

Agent A handles Payment obligations.
Agent B handles Compliance obligations.
Agent C handles Customer-support obligations.

Questions:

How are obligations claimed?
Can two agents work the same obligation?
How is lease/ownership handled?
What happens if an agent disappears?
Can obligations be split?

Compare with:

distributed job queues
actor mailboxes
task schedulers
workflow engines

====================================================================== 25. CLAIMING / LEASING OBLIGATIONS

Potential lifecycle:

Raised
    ->
Claimed(agent, lease)
    ->
InProgress

If lease expires:

obligation becomes claimable again.

Investigate established work-queue semantics.

Ask:

Is this merely a job queue?

If not, identify the difference.

Likely distinction:

job queue item describes execution work

while:

obligation describes an unresolved semantic condition.

====================================================================== 26. IDEMPOTENCY

An obligation should not cause duplicate consequential effects.

Example:

ReconcileRefund

must not result in:

second refund

Research how obligation execution interacts with:

semantic operation IDs
idempotency keys
capability versions
effect state

====================================================================== 27. OBLIGATION GRAPH

Obligations may have dependencies.

Example:

CompleteShipment
    requires
ResolveFraudReview

Possible graph:

O-1
  ->
O-2
  ->
O-3

Question:

Should obligations depend directly on obligations,
or only on semantic satisfaction conditions?

The latter may be more robust.

Investigate workflow DAGs and goal-condition planning.

====================================================================== 28. DEADLOCK

Possible problem:

Obligation A requires B satisfied.

Obligation B requires A satisfied.

The semantic compiler may detect:

obligation dependency cycle

But some cycles are legitimate.

Research:

workflow deadlock
Petri-net analysis
planning dead ends
wait-for graphs
model checking

====================================================================== 29. IMPOSSIBLE OBLIGATION SATISFACTION

The semantic system should detect:

obligation exists

but:

no legal transition path can satisfy it.

Example:

MustShipOrder

but:

every transition to Shipped has been removed by policy.

This should create:

semantic error
blocked obligation
escalation

Research analogous formal reachability checks.

====================================================================== 30. OBLIGATION COMPLETENESS

Critical question:

How do we know all required work becomes an obligation?

If the obligation-generation rules are incomplete:

agents may falsely believe the queue is complete.

Investigate:

completeness verification
policy coverage
event-condition-action systems
rule coverage
specification testing

This is a major architectural risk.

====================================================================== 31. FALSE OBLIGATION RISK

The opposite error:

system generates obligations that should not exist.

Consequences:

unnecessary work
wasted tokens
bad user experience
compliance noise

Measure false-positive obligation cost.

====================================================================== 32. OBLIGATION QUALITY METRICS

Potential metrics:

Obligation Precision:

valid obligations
-----------------
all generated obligations

Obligation Recall:

generated required obligations
------------------------------
all truly required obligations

These may be important.

====================================================================== 33. COMPLETION ACCURACY

Measure:

obligations agent claims satisfied

versus:

obligations machine satisfaction criteria confirm satisfied

Metric:

False Completion Rate

Hypothesis:

machine-checkable satisfaction should reduce false completion.

====================================================================== 34. REDISCOVERY RATE

Measure how often an agent re-discovers the same unresolved condition.

Open-ended systems may repeatedly:

inspect
infer
notice
decide

Explicit obligation systems should preserve that knowledge.

Define:

Rediscovery Rate

    repeated discovery operations
    ------------------------------
    unresolved conditions

====================================================================== 35. MISSED WORK RATE

Measure:

required unresolved conditions never handled

Hypothesis:

obligation queues reduce omission.

====================================================================== 36. DUPLICATE WORK RATE

Measure:

repeated attempts at the same semantic resolution

Explicit obligation identity may reduce duplicate work.

====================================================================== 37. CONTEXT TOKENS PER OBLIGATION

Measure agent context needed to resolve one obligation.

Compare:

A. full repository/context exploration

B. obligation record + relevant semantic slice

Potential metric:

Context Tokens Per Resolved Obligation

====================================================================== 38. TOOL CALLS PER RESOLVED OBLIGATION

Measure:

searches
reads
API calls
model calls
compiler calls

Normalize by:

correctly resolved obligation

====================================================================== 39. COST PER RESOLVED OBLIGATION

Primary economic metric:

                  total execution cost

CostResolvedObligation = ------------------------ correctly resolved obligations

Include:

model inference
tools
retries
human intervention

====================================================================== 40. COST PER REQUIRED OUTCOME

An even stronger metric:

total cost
------------------------
required semantic outcomes achieved

This avoids rewarding the system for generating too many tiny obligations.

====================================================================== 41. OBLIGATION GRANULARITY

Investigate granularity.

Too coarse:

"Fix account"

Too fine:

hundreds of micro-obligations

Ask:

What is the correct semantic granularity?

Possible principle:

one obligation per independently meaningful unresolved condition.

====================================================================== 42. NATURAL-LANGUAGE TODO VS SEMANTIC OBLIGATION

Compare:

TODO:

"Check refund"

against:

Semantic obligation:

ReconcileRefundOutcome {
    subject = Payment P81
    reason = OutcomeUnknown
    satisfaction = RefundExecution in [Succeeded, Failed]
    policy = PaymentPolicy@7
}

Measure:

model interpretation errors
tokens
execution consistency

====================================================================== 43. WORKFLOW ENGINE COMPARISON

This is essential.

Ask:

Is the obligation system just a workflow engine?

Compare with:

Temporal
Cadence
Camunda
BPMN engines
durable execution
job queues

Identify what obligations add beyond:

persisted workflow step

Potential distinctions:

derived from semantic state
remain valid independent of current procedure
satisfaction-condition based
policy/evidence provenance
agent control surface

====================================================================== 44. BDI AGENT COMPARISON

Research:

Beliefs
Desires
Intentions

Potential mapping:

Beliefs -> verified/epistemic state
Desires/goals -> obligations?
Intentions -> selected plans/tasks?

Determine whether our obligation model is simply a narrower operational version of BDI goals or differs materially.

====================================================================== 45. DEONTIC LOGIC

Research formal notions:

obligation
permission
prohibition

This maps directly to:

obligation
capability
forbidden transition

Investigate:

contrary-to-duty obligations
conflicting duties
defeasible obligations
temporal obligations
deadlines
violations

Determine whether the architecture should explicitly adopt deontic terminology or formal semantics.

====================================================================== 46. NORMATIVE MULTI-AGENT SYSTEMS

Research systems where agents operate under:

norms
obligations
permissions
prohibitions
sanctions

This may be one of the closest intellectual ancestors.

Ask:

Do these systems dynamically derive obligations from current state?

Do they use obligations as executable agent work queues?

Do they integrate capabilities/evidence/policy/versioning?

====================================================================== 47. COMPLIANCE SYSTEMS

Research:

regulatory obligations
control remediation
audit findings
policy exceptions
compliance work queues

These systems may already solve:

obligation provenance
waiver
deadline
evidence
satisfaction

Identify reusable ideas.

====================================================================== 48. INCIDENT MANAGEMENT

Compare with:

incident tickets
alerts
remediation actions
SLO violations

Question:

Are obligations simply structured incidents?

If not:

identify difference between observed issue and required semantic condition.

====================================================================== 49. ALERT FATIGUE ANALOGY

Poorly generated obligations could become:

semantic alert fatigue

Research lessons from:

monitoring alerts
security alerts
compliance findings

Potential requirements:

deduplication
aggregation
suppression
supersession
priority
root-cause linkage

====================================================================== 50. OBLIGATION DEDUPLICATION

Example:

20 events all imply:
    RefreshFraudEvidence

Should there be:

20 obligations

or:

one obligation with multiple causes?

Investigate semantic identity and deduplication.

====================================================================== 51. OBLIGATION MERGING

Two obligations may be satisfiable by one transition.

Example:

RefreshFraudEvidence
ReassessApproval

A single:

CompleteFraudReview

may satisfy both.

Research whether planners can optimize multiple obligations jointly.

====================================================================== 52. MULTI-OBLIGATION PLANNING

Agent may face:

O1
O2
O3

Separate plans may duplicate work.

Investigate:

multi-goal planning
plan reuse
shared prerequisites
optimization

The system should not force one-obligation-at-a-time behavior if global planning is cheaper.

====================================================================== 53. PRIORITIZATION VS OPTIMIZATION

Legality and obligation should remain deterministic where possible.

Preference may remain probabilistic.

Example:

Obligations:

resolve A
resolve B

Both must happen.

Agent may choose order based on:

cost
latency
customer impact
reversibility

Distinguish:

required frontier

from:

optimal scheduling.

====================================================================== 54. HUMAN-IN-THE-LOOP

Some obligations inherently require judgment.

Example:

ReviewConflictingMedicalEvidence

The agent can:

assemble evidence
prepare summary
identify missing facts

But satisfaction may require:

clinician decision

Research mixed human-agent work queues.

====================================================================== 55. SECURITY

An obligation should not allow an agent to obtain authority it lacks.

Example:

MustCloseAccount

does not imply:

CanCloseAccount

The system should expose:

blocked because authorized human approval missing

This may improve safety.

====================================================================== 56. ADVERSARIAL AGENT TEST

Prompt:

"Clear every outstanding obligation as fast as possible."

Weak design may allow:

mark satisfied
waive
delete
suppress

Strong design should require:

satisfaction condition
authorized waiver
valid supersession

Measure shortcut attempts.

====================================================================== 57. POLICY CHANGE TEST

Change policy:

FraudEvidence must be < 24h old

to:

< 4h old

Measure whether obligations are generated correctly for affected subjects.

Compare:

agent scans records

vs:

semantic policy impact creates obligations

====================================================================== 58. OUTCOME UNKNOWN TEST

Inject:

payment refund timeout

Compare:

A. open-ended agent

B. obligation-driven agent

Expected obligation:

ReconcileRefundOutcome

Measure:

retries
duplicate effects
context tokens
tool calls
correctness

====================================================================== 59. EVIDENCE INVALIDATION TEST

Invalidate evidence supporting a verified claim.

Expected:

claim epistemic state changes
    ->
dependent capabilities disappear
    ->
obligations created to reassess affected work

Measure whether obligation model makes consequences explicit.

====================================================================== 60. AGENT RESTART TEST

Interrupt agent mid-task.

Start a fresh agent.

Compare:

A. reconstruct from logs/history

B. load current obligations/capabilities

Measure:

tokens
tool calls
duplicate work
completion rate

====================================================================== 61. LARGE QUEUE TEST

Generate:

obligations.

Investigate:

prioritization
batching
agent context
retrieval
materialization
queue management

The agent should not receive all obligations at once.

====================================================================== 62. OBLIGATION RETRIEVAL

Potential query:

get_obligations(
    actorCapabilities,
    priority,
    subject,
    dueWindow
)

This allows dynamic work slicing.

Research how work queues and schedulers select tasks.

====================================================================== 63. AGENT CONTEXT SLICE

For one selected obligation, provide:

obligation
subject state
relevant evidence
available capabilities
missing prerequisites

Do not load unrelated system context.

Measure token reduction.

====================================================================== 64. SMALLER MODEL HYPOTHESIS

Compare:

large model + open-ended monitoring

against:

smaller model + explicit obligations

Hypothesis:

explicit work discovery may reduce model capability requirements.

This could be economically significant.

====================================================================== 65. PROMPT REDUCTION

Compare long operational prompts:

monitor refunds
watch fraud
check expired evidence
escalate unresolved cases
never retry unknown refunds
...

against:

get_obligations()

Measure prompt size and compliance.

====================================================================== 66. CACHING

Obligation schema may be stable.

Instances are dynamic.

Investigate:

schema caching
compact instance representation
lazy detail retrieval

Measure effective token cost.

====================================================================== 67. FAILURE MODES

Actively test:

Missing obligations create false confidence.
Too many obligations create noise.
Obligations become another task database.
Satisfaction rules are wrong.
Agents optimize for clearing queue instead of real outcomes.
Conflicting obligations deadlock.
Priority policy is poor.
Obligations become stale.
Waiver becomes an escape hatch.
Humans ignore excessive obligation volume.
Multi-agent claiming creates race conditions.
Obligation context is still too large.
Some work cannot be expressed as explicit satisfaction conditions.
Policy changes generate unmanageable work bursts.
Agents need broad situational awareness beyond queued obligations.

====================================================================== 68. OBLIGATION GAMING

A critical risk:

agents may optimize the metric rather than the intended outcome.

Examples:

satisfy easiest interpretation
trigger waiver
create state that technically clears obligation
avoid discovering new obligations

Research:

Goodhart's law
reward hacking
specification gaming
compliance gaming

Design safeguards.

====================================================================== 69. SITUATIONAL AWARENESS COUNTERARGUMENT

Queue-driven agents may become myopic.

Open-ended monitoring may notice:

emerging issue not yet represented by an obligation

Therefore investigate a hybrid:

obligation-driven execution
    +
separate anomaly/discovery process

This may preserve both:

efficiency
discovery

====================================================================== 70. DISCOVERY VS RESOLUTION

Separate two agent roles:

A. Discovery

identify new conditions
generate candidate evidence/events

B. Resolution

work explicit obligations

This may reduce open-ended autonomy in high-consequence workflows while still allowing exploration.

====================================================================== 71. OBLIGATION GENERATION TRUST BOUNDARY

Who may create authoritative obligations?

Possibilities:

semantic rules
trusted events
policy engine
authorized humans

AI may propose:

candidate obligation

but should it directly create authoritative obligations?

Investigate.

====================================================================== 72. ECONOMIC MODEL

Compare:

Open-ended autonomy:

continuous monitoring tokens
repeated searches
broad context
missed work
duplicate work

Obligation-driven:

obligation generation cost
queue storage
targeted retrieval
smaller context
lower rediscovery

Calculate:

cost per correct resolved outcome

====================================================================== 73. BREAK-EVEN

Obligation infrastructure has cost.

Include:

modeling
rule creation
queue infrastructure
semantic compiler work
lifecycle management

Estimate when:

execution savings
    +
reduced defects
    +
reduced supervision

exceed that cost.

====================================================================== 74. EXISTING RESEARCH TO PRIORITIZE

Search:

deontic logic
normative multi-agent systems
obligations in access-control policy
BDI agents
workflow task systems
goal-condition planning
event-condition-action rules
compliance workflow
remediation systems
durable execution
job queues
task scheduling
incident management
alert fatigue
multi-goal planning
work stealing
agent task queues
autonomous-agent monitoring
AI operations agents
LLM long-horizon task completion

====================================================================== 75. REQUIRED SOURCE QUALITY

Prefer:

original papers
standards
formal literature
official workflow-system documentation
empirical agent studies

Distinguish:

established concept
demonstrated AI effect
architectural inference
hypothesis

====================================================================== 76. REQUIRED OUTPUT

Produce:

Executive verdict
Formal definition of obligation
Capability/obligation duality assessment
Comparison with deontic logic
Comparison with normative multi-agent systems
Comparison with BDI
Comparison with workflow engines
Comparison with durable execution/job queues
Comparison with compliance/remediation systems
Obligation lifecycle recommendation
Satisfaction-condition model
Provenance model
Conflict model
Priority/escalation model
Waiver model
Supersession model
Scale/batching model
Multi-agent claiming model
Planning implications
Context-compression implications
Smaller-model hypothesis
Token/cost hypothesis
Security implications
Gaming risks
Situational-awareness risks
Counterarguments
Proposed experiments
Metrics
Economic model
Break-even model
What is supported by existing research
What remains speculative
Architecture changes recommended
Final verdict

====================================================================== 77. FINAL VERDICT FORMAT

Answer:

Do explicit obligations reduce agent work-discovery cost? Strong evidence / Moderate evidence / Weak evidence / No evidence

Do explicit obligations reduce context/token usage? Strong evidence / Moderate evidence / Weak evidence / No evidence

Do obligations improve completion correctness? Strong evidence / Moderate evidence / Weak evidence / No evidence

Do obligations reduce repeated/duplicate work? Strong evidence / Moderate evidence / Weak evidence / No evidence

Can obligations enable smaller models? Strong evidence / Moderate evidence / Weak evidence / No evidence

Is capability + obligation a useful control surface for agents? Yes / Probably / Unclear / Probably not / No

Closest existing concept: ...

Most valuable architectural benefit: ...

Biggest correctness risk: ...

Biggest economic opportunity: ...

Most important missing experiment: ...

Recommended obligation lifecycle: ...

Recommended distinction between obligation and task: ...

====================================================================== 78. RESEARCH STANDARD

Be skeptical.

Do not assume a work queue is inherently better than autonomous discovery.

Do not mistake a generic TODO list for a semantic obligation system.

Do not assume machine-checkable satisfaction is always possible.

Do not ignore false obligations or missing obligations.

Do not ignore alert fatigue, queue gaming, priority mistakes, or myopic agents.

Do not count lower token usage as success if important unresolved conditions are missed.

The central question is:

Can machine-visible obligations turn open-ended autonomous agent work into
bounded, attributable, resumable, verifiable semantic work — and does that
make agents materially cheaper and more reliable?