Reflection: Remote Agent Success Is Not a Database Commit

Trigger

Two direct-MCP vertical-slice runs reached a remote SuperAgent success state without creating an MCP submission or committed Finance facts.

Expected Behavior

End-to-end acceptance should require all authoritative signals: an MCP committed/already_committed receipt, consumed one-time grant, accepted processing state, and matching Finance version/current/fact rows.

Actual Behavior

The remote orchestration platform considered the run complete even though its cached MCP tool state prevented the business submission. The local processing state also lacked an automatic database mapping for the runner's delivery_missing outcome.

Root Cause

Weak gate
Stale external tool discovery
Missing terminal-state mapping

Evidence

Files: .project-docs/50-evidence/topics/2026-07-29-live-synthetic-xml-vertical-slice.md, arr_processing/runner.py, arr_processing/postgres.py
Session/thread: live no-PII upload test on 2026-07-29
Command output: remote status success; submission/version/current/record counts all zero; protected cleanup ended as PROCESSING_RESULT_MISSING
Docs involved: current state, evidence index, commitments, stale items

Lesson

Treat orchestration status as a progress signal, not the system-of-record outcome. Every live test must cross-check the one-time grant, MCP submission ledger, processing terminal state, Finance facts, and downstream current pointer before reporting success or enabling a mutation endpoint.

When remote completion lacks a business result, revoke any remaining grant and terminalize the exact run under identity locks; never leave a late submission path open.

Action

Update docs
Add check/eval
Record the missing automatic terminal-state mapping for separate implementation.

Promotion

Promoted to the live E2E evidence record, current-state risk, future commitment, and stale-item tracking. No new product ADR is required.

2.0 KiB Raw Permalink Blame History