Audit Goals, Commitments and Executable Work in a Long-Running Agent
Apply Advanced Agents Step 38 to determine whether goals, plans, commitments, queued work and executed actions are represented as distinct state with correct cancellation, retry and handoff semantics.
How to use this
- Open a repository-aware AI assistant.
- Give it access to the repository or files you want reviewed.
- Copy the prompt below and run it unchanged first.
- Use the evidence it finds to decide what to inspect or change next.
PromptCopy and run against your own project
You are reviewing a long-running agent or workflow system for semantic confusion between goals, plans, commitments, tasks and actions.
Do not assume a plan step means work has been scheduled or promised.
Reconstruct the actual state machine used by the repository.
Identify the representations for:
- user/system goal,
- proposed plan,
- selected plan,
- commitment or obligation,
- queued task,
- leased/running work,
- completed action,
- verified outcome,
- cancellation,
- failure/retry,
- supersession/replanning,
- handoff to another worker or human.
Build a state-transition table:
state | created by | durable? | side effect permitted? | cancelable? | retryable? | completion evidence | successor states
Trace one representative long-running operation from intent to verified completion.
Look for semantic collapses such as:
- plan text directly becoming executable work,
- queued task treated as completed commitment,
- retry creating duplicate commitments,
- replanning leaving old tasks live,
- cancellation not propagating to leased work,
- worker completion treated as business outcome without verification,
- model narration used as state transition,
- no distinction between logical task ID and execution attempt ID,
- handoff losing ownership/accountability,
- commitments that cannot be enumerated or discharged.
For each externally visible commitment, answer:
1. Who created it?
2. What exact intent/version does it bind to?
3. What must happen for it to be discharged?
4. What happens if the plan changes?
5. Can retries duplicate the obligation?
6. Can another process recover it after a crash?
Recommend the minimum durable model needed to separate:
goal → plan → commitment → task → attempt → action → verification
Prefer explicit persisted states and identifiers over inferred status from logs or model text.
Finish with failure scenarios for:
- crash after commitment but before enqueue,
- duplicate delivery,
- stale plan after state change,
- cancellation during execution,
- verifier failure after side effect,
- worker death and resume.
For each scenario, state whether the current design is correct, ambiguous, or unsafe, and cite the repository evidence.