Post-Actuation Reconciliation Governance requires that every AI agent action be systematically reconciled after execution — comparing the intended outcome with the actual outcome as observed in the target system or environment. Preventive controls (AG-143 through AG-146) reduce the probability of authorised-but-wrong actions but cannot eliminate it. AG-147 provides the recovery layer: the systematic, automated process of verifying that what happened is what was supposed to happen, and initiating remediation when it is not. Reconciliation must occur within a defined time window after execution — measured in seconds for real-time systems, minutes for batch operations, and hours for long-running processes — and must compare the actual post-action state against the expected post-action state across all material parameters. Discrepancies must be classified by severity and routed to appropriate remediation pathways: automated reversal for minor discrepancies within reversibility windows, human escalation for material discrepancies, and emergency response for critical discrepancies.
Scenario A — Payment Amount Mismatch After Execution: A financial-value agent executes a BACS payment of £47,500 to a supplier. The instruction specified £47,500 and the mandate check passed. However, due to a character encoding issue in the payment API, the amount was transmitted as £4,750 (a trailing zero was stripped). The payment clears at £4,750. Without post-actuation reconciliation, the discrepancy is discovered 28 days later when the supplier sends an overdue notice. With reconciliation: within 15 minutes of execution, the reconciliation engine queries the bank's payment confirmation API and compares the confirmed amount (£4,750) against the intended amount (£47,500). The discrepancy (89.5% underpayment) exceeds the tolerance threshold (0.1%) and is immediately flagged. Because the payment was BACS (3-day settlement cycle), the agent initiates a supplementary payment for £42,750 within the same settlement cycle.
What reconciliation caught: A data transmission error that no preventive control could have detected because the error occurred downstream of the agent's action submission. The payment was correct when submitted but corrupted in transit.
Scenario B — Infrastructure Configuration Drift After Deployment: A DevOps agent deploys a configuration change to 12 production servers, setting the connection pool size from 50 to 100. The agent submits the configuration change to the deployment pipeline, which reports success for all 12 servers. However, 2 of the 12 servers had a read-only filesystem flag that silently prevented the configuration write — the deployment tool reported success because the command executed without error, but the configuration file was not modified. Without reconciliation: the 2 servers continue operating with a connection pool of 50, causing intermittent connection timeouts under load that are difficult to diagnose. With reconciliation: within 60 seconds of deployment, the reconciliation engine queries each server's actual configuration and compares it against the intended configuration. The 2 servers with connection pool = 50 (instead of the intended 100) are flagged, and the agent re-executes the deployment with filesystem remediation.
What reconciliation caught: A silent failure in the deployment pipeline that reported success but did not achieve the intended state change. The deployment tool's success report was misleading — only reconciliation against the actual system state detected the discrepancy.
Scenario C — Medication Administration Verification: A clinical agent issues a medication order for enoxaparin 40mg subcutaneous injection for a post-surgical patient. The order is processed by the electronic prescribing system and dispatched to the ward. The ward nurse administers the injection. Post-actuation reconciliation queries the medication administration record (MAR) and confirms: medication administered = enoxaparin, dose = 40mg, route = subcutaneous, time = 14:32. All parameters match the order. However, the reconciliation also checks the patient's anti-Xa level 4 hours post-administration and finds it at 0.15 IU/mL — below the expected therapeutic range of 0.2-0.5 IU/mL. The reconciliation engine flags the subtherapeutic response for clinical review, identifying a potential dosing issue given the patient's BMI of 42 (obese patients may require weight-adjusted dosing).
What reconciliation caught: The medication was administered correctly as ordered, but the clinical outcome did not match the expected therapeutic effect. The reconciliation extended beyond action verification to outcome verification, catching a dosing inadequacy that the original order did not account for.
Scope: This dimension applies to all AI agents that execute actions affecting external state — any action that changes the state of a system, database, financial account, physical environment, or communication channel outside the agent's own memory. The scope is deliberately broad because the need for reconciliation is universal: any action that affects external state can fail silently, partially, or in unexpected ways. The scope includes both the immediate action (was the payment submitted?) and the downstream effect (was the payment received? for the correct amount? by the correct recipient?). The reconciliation depth — how far downstream the verification extends — should be proportional to the consequence of the action and the availability of downstream state information.
4.1. A conforming system MUST perform post-actuation reconciliation for every action classified as irreversible or partially reversible (per AG-143), comparing the actual post-action state against the expected post-action state within a defined reconciliation window.
4.2. A conforming system MUST define reconciliation windows per action type, specifying the maximum elapsed time between action execution and reconciliation completion. The window MUST be shorter than the reversibility window for partially reversible actions (i.e., reconciliation must complete while reversal is still possible).
4.3. A conforming system MUST compare at least the following parameters during reconciliation: action type executed vs. intended, target entity vs. intended, value or magnitude vs. intended, and execution timestamp vs. expected window.
4.4. A conforming system MUST classify reconciliation discrepancies by severity: minor (within operational tolerance, log only), material (exceeds tolerance, requires human review), and critical (indicates potential systemic failure, triggers emergency escalation).
4.5. A conforming system MUST initiate automated remediation for minor discrepancies within the reversibility window where automated reversal or correction is possible, and escalate to human review for material and critical discrepancies.
4.6. A conforming system MUST log all reconciliation results — both matches and discrepancies — with the comparison parameters, the discrepancy classification, and the remediation action taken.
4.7. A conforming system SHOULD perform reconciliation against the target system's actual state (e.g., bank confirmation, server configuration query, database read-back) rather than relying on the execution system's success report, which may not reflect the actual outcome.
4.8. A conforming system SHOULD implement outcome reconciliation for high-consequence actions, verifying not just that the action was executed as intended but that the expected downstream outcome was achieved (e.g., not just that the payment was sent, but that it was received and credited).
4.9. A conforming system MAY implement continuous reconciliation for long-running or recurring actions, performing periodic state comparisons throughout the action's lifecycle rather than a single post-execution check.
Preventive controls are necessary but insufficient. AG-143 through AG-146 collectively reduce the probability of authorised-but-wrong actions by introducing cooling-off periods, intent binding, target verification, and independent corroboration. But no set of preventive controls can reduce the error probability to zero. Errors will occur — through data corruption in transit, silent execution failures, race conditions, downstream system errors, or failure modes that no preventive control was designed to catch. AG-147 provides the detection layer: the systematic verification that each executed action achieved its intended effect.
The distinction between execution confirmation and outcome reconciliation is critical. Many systems provide execution confirmation — the payment API returns HTTP 200, the deployment tool reports "success", the database write returns "rows affected: 1". But execution confirmation reflects the execution system's assessment of whether it processed the request. It does not reflect the actual outcome in the target system. A payment API may return success because it accepted the payment instruction, but the payment may fail during clearing. A deployment tool may report success because the command executed, but the configuration file may not have been written. A database write may report success, but a subsequent read may return different data due to replication lag. Reconciliation verifies the actual state, not the reported state.
The reconciliation window is the critical design parameter. If reconciliation occurs after the reversibility window has closed, discrepancies are detected but cannot be remediated through reversal — only through compensating actions, which are typically more expensive and less reliable. The reconciliation window must be shorter than the reversibility window to enable automated remediation. For BACS payments (3-day settlement with same-day recall), reconciliation should complete within hours. For real-time systems (CHAPS, API calls), reconciliation should complete within minutes. For physical actuation, reconciliation should complete before the process state has evolved beyond the point of safe reversal.
AG-147 requires a reconciliation engine that operates asynchronously after action execution, querying target systems to verify the actual post-action state and comparing it against the expected state.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Reconciliation is a well-established practice in financial operations — T+1 trade reconciliation, bank statement reconciliation, position reconciliation. AG-147 extends this practice to AI agent actions specifically, requiring automated reconciliation within defined windows rather than end-of-day batch reconciliation. For real-time payment systems (CHAPS, Faster Payments), reconciliation should complete within 15 minutes. For securities settlement, reconciliation should align with the settlement cycle (T+1 under CSDR). The FCA expects firms to have robust reconciliation processes; extending these to AI agent actions is a natural regulatory expectation.
Healthcare. Medication reconciliation is a patient safety standard. AG-147 extends this to all AI agent actions in clinical settings — not just medication but also diagnostic orders, referrals, and care plan modifications. Outcome reconciliation (verifying therapeutic effect, not just administration) is particularly valuable in clinical settings where the gap between action and outcome may reveal dosing errors, interaction effects, or patient-specific responses.
Critical Infrastructure. Physical actuation reconciliation must verify the actual state of the physical system, not just the command acknowledgement from the control system. For example, after commanding a valve to close, reconciliation should verify the valve position sensor confirms closed — not just that the control system acknowledged the close command. Discrepancies between commanded state and actual state in safety-critical systems require immediate emergency escalation.
Basic Implementation — The organisation performs post-actuation reconciliation for all irreversible actions within defined reconciliation windows. Reconciliation compares at least action type, target, and value against the expected state. Discrepancies are classified as minor or material and routed to appropriate handlers. Reconciliation is logged. This level meets the minimum mandatory requirements but reconciles against the execution system's confirmation rather than the target system's actual state.
Intermediate Implementation — Reconciliation queries the target system directly to verify actual post-action state. Outcome reconciliation is implemented for high-consequence actions. Reconciliation windows are shorter than reversibility windows, enabling automated remediation. A reconciliation dashboard tracks pending, completed, and overdue reconciliations. Discrepancy severity classification includes critical tier with emergency escalation.
Advanced Implementation — All intermediate capabilities plus: continuous reconciliation for long-running and recurring actions. Machine learning models trained on historical reconciliation data predict which actions are most likely to produce discrepancies and prioritise their reconciliation. Reconciliation infrastructure has been verified through adversarial testing including silent execution failures, delayed state propagation, and reconciliation system manipulation. Integration with AG-143 (cooling-off) enables pre-execution reconciliation of similar recent actions.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Reconciliation Window Compliance
Test 8.2: Discrepancy Detection — Value Mismatch
Test 8.3: Discrepancy Detection — Target Mismatch
Test 8.4: Silent Execution Failure Detection
Test 8.5: Automated Remediation for Minor Discrepancies
Test 8.6: Reconciliation Overdue Escalation
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 14 (Human Oversight) | Supports compliance |
| EU AI Act | Article 72 (Post-Market Monitoring) | Direct requirement |
| FCA SYSC | 6.1.1R (Systems and Controls) | Direct requirement |
| FCA CASS | 7.15.5R (Reconciliation) | Direct requirement |
| SOX | Section 404 (Internal Controls) | Supports compliance |
| NIST AI RMF | MANAGE 4.1, MANAGE 4.2 | Supports compliance |
| ISO 42001 | Clause 9.1 (Monitoring, Measurement, Analysis and Evaluation) | Supports compliance |
Article 72 requires providers of high-risk AI systems to establish a post-market monitoring system to actively and systematically collect, document, and analyse data on the performance of high-risk AI systems throughout their lifetime. Post-actuation reconciliation is a direct implementation of post-market monitoring at the action level: each agent action is monitored post-execution to verify its performance matched its intent. The reconciliation log provides the systematic data collection that Article 72 requires.
CASS 7.15.5R requires firms holding client assets to perform reconciliation of the firm's internal records with external records at defined intervals. AG-147 extends this principle to all AI agent financial actions: each action is reconciled against the external state (counterparty confirmation, bank statement, settlement system) to verify accuracy. The FCA's expectation for automated, timely reconciliation of financial transactions applies directly to AI agent actions.
SOX Section 404 requires effective internal controls over financial reporting. Reconciliation is a foundational internal control — it detects errors and discrepancies that other controls may have missed. For AI agent financial actions, post-actuation reconciliation provides the control evidence that the actions recorded in the financial systems accurately reflect the actual economic events. A SOX auditor will test whether the reconciliation process is complete (all material actions reconciled), timely (within defined windows), and effective (discrepancies detected and resolved).
Clause 9.1 requires organisations to determine what needs to be monitored and measured, including AI system performance. Post-actuation reconciliation provides direct performance measurement for AI agent actions: the reconciliation match rate, discrepancy rate, and discrepancy severity distribution are quantitative performance metrics that satisfy the monitoring and measurement requirement.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Organisation-wide — reconciliation failures allow errors to accumulate undetected across all agent actions |
Consequence chain: Without post-actuation reconciliation, errors in AI agent actions go undetected until they are discovered through external signals — a supplier complaint, a patient adverse event, a system outage, or an audit finding. The latency between the error and its detection determines the remediation cost: an error detected in 15 minutes may be reversible at negligible cost; the same error detected in 28 days may be irrecoverable. For financial services, unreconciled agent actions create a growing population of potentially erroneous transactions that compound over time. A 0.1% error rate on 10,000 daily agent transactions means 10 errors per day, 300 per month — each with growing remediation cost and regulatory exposure. For healthcare, undetected errors in clinical agent actions accumulate as unverified prescriptions, unconfirmed dosages, and unchecked outcomes. For infrastructure, undetected deployment failures create configuration drift that degrades system reliability. The regulatory consequence is severe: reconciliation is a fundamental control expectation in financial services (FCA CASS), internal control frameworks (SOX 404), and AI governance (EU AI Act Article 72). The absence of reconciliation for AI agent actions is a finding in any audit or regulatory examination. Cross-reference: AG-001 (mandate enforcement), AG-011 (reversibility assessment informs reconciliation timing), AG-143 (cooling-off provides a pre-execution check; reconciliation provides the post-execution check), AG-144 (intent binding provides the expected state for reconciliation comparison), AG-145 (target verification is a preventive control; reconciliation verifies the target after execution).