Agent Architecture Review, Validation snapshot

`PaymentWorkflow.create_run()` accepts an operator-owned `Policy`, `draft_tasks()` classifies invoices against explicit constraints, and `execute_approved_payments()` only submits tasks that moved through `AWAITING_APPROVAL` to `APPROVED`. The workflow exposes delegation controls through `pause_run()`, `resume_run()`, `cancel_run()`, `retry_failed_task()`, and `resume_after_failure()` rather than requiring manual execution of every invoice step.

Background continuity is represented through durable JSONL primitives: `RunLedger` records `run.created`, task status events, `run.executing`, and terminal run events; `DurableOperatorInbox` persists intervention alerts; `inspect_run()` exposes current status, task counts, critical alerts, and `needs_reconciliation`. The prior P2 gap is improved by `TaskStatus.SUBMITTED_UNKNOWN`, `replay_run_from_ledger()`, and `reconcile_submitted_task()`, which make crash-after-submit states visible instead of silently losing continuity.

The code separates routine status from attention-demanding conditions: normal progress is summarized by `inspect_run()['summary']`, while material intervention paths post alerts via `DurableOperatorInbox.post()` for forged approvals, expired envelopes, insufficient roles, policy violations, bank submission failures, and `SUBMITTED_UNKNOWN` reconciliation. Severity is calibrated with values such as `critical` for `auth_missing` and reconciliation blockers, and `warning` for non-fatal bank submission failures.

`inspect_run()` provides a layered view: top-level run status, owner, policy hash, pause/cancel flags, audit-chain health, critical alerts, and aggregate task counts are available first, while per-task details such as invoice snapshot hash, approver identity, transfer id, failure class, and idempotency key are available in the nested `tasks` list. Deeper forensic detail remains in `RunLedger.read_run_events()` and `verify_chain()` rather than being forced into the default summary.

The system’s mental model is explicit: `Policy` names amount caps, allow/block lists, due window, and required approver role; `classify_invoice()` returns concrete policy decisions such as `vendor_blocked` or `outside_due_window`; and `ApprovalEnvelope` binds approval to `run_id`, `task_id`, `policy_hash`, and `invoice_snapshot_hash`. The prior P5 issue is improved because `approve()` no longer trusts raw approver strings; it verifies an HMAC envelope before recording approval authority.

`RunStatus` and `TaskStatus` use user-relevant operational states such as `AWAITING_APPROVAL`, `PAUSED`, `EXECUTING`, `PARTIALLY_COMPLETED`, `FAILED`, `SUBMITTED_UNKNOWN`, `SUCCEEDED`, and `CANCELLED`. `inspect_run()` translates these into actionable summaries, including counts by task status, submitted amount, critical alerts, and reconciliation count, rather than exposing only low-level ledger mechanics.

The inspectability primitive is load-bearing: `RunLedger.append()` creates an append-only hash chain using `prev_event_hash` and `event_hash`, while `verify_chain()` detects sequence or hash divergence. Task events persist invoice snapshots, `invoice_snapshot_hash`, policy hash, idempotency key, approval signature, bank responses, and failure classes, allowing reviewers to reconstruct how a payment decision and submission occurred.

Approval and blocker boundaries are explicit. `approve()` verifies `ApprovalEnvelope` with `hmac.compare_digest()` before trusting role or identity, checks expiry, policy hash, invoice snapshot hash, and required role, and records approved tasks only after those gates pass. Execution cannot submit unless a task is `APPROVED`; bank auth failures, policy violations, invalid signatures, insufficient roles, and reconciliation blockers are surfaced through ledger events and/or durable inbox alerts. The prior high-risk P8 approval-forgery gap is addressed by the signed envelope primitive.

Delegated work is represented as a structured system: `PaymentRun` owns run-level state and policy hash, `PaymentTask` owns per-invoice lifecycle and idempotency key, `RunLedger` records timeline/history, and `DurableOperatorInbox` records intervention-required alerts. Conversation or prompt text is not used as the execution state; the workflow is governed by typed records, enums, policy checks, and ledger events.

The workflow supports steering after initiation through `pause_run()`, `resume_run()`, `cancel_run()`, `retry_failed_task()`, `resume_after_failure()`, and `reconcile_submitted_task()`. `execute_approved_payments()` re-reads `RunLedger.latest_steering_intent()` before each external `transfer_funds()` call, so pause/cancel intents can interrupt a running executor before the next irreversible submit. The prior high-risk P10 gap is improved by durable steering events, same-key retry, and explicit `SUBMITTED_UNKNOWN` reconciliation.