AI in the middle, RPA at the edges, people before irreversible effects

Financial reconciliation does not need to choose between “all RPA” and “one agent does everything.” Both extremes combine incompatible work. RPA is strong at repeating a known sequence; AI can interpret an ambiguous exception; a person should retain authority over a posting or value movement that is hard to reverse. The reference architecture puts RPA at deterministic edges, AI in the ambiguous middle, and people before irreversible effects.

The design decision is not about which technology is newer. It depends on variability, verifiability, and reversibility. A step with structured input, a stable rule, and a testable result does not need probabilistic reasoning. An exception with free text and incomplete evidence should not be forced through a rigid macro. Neither technology should approve its own material effect.

The hybrid reference architecture

The flow can be organized into eight layers with explicit contracts:

1. Capture and batch lock. An API or RPA collects files and confirms source identity, period, and fingerprint.
2. Deterministic normalization. Rules convert dates, currencies, references, and codes into a common schema; invalid input enters quarantine.
3. Deterministic matching. Exact keys, approved tolerances, and source states resolve explainable cases without AI.
4. Exception preparation. The system creates an object containing the difference, available evidence, preliminary reason, and permitted actions.
5. AI-assisted classification. The model interprets text or context, proposes a category, and names the evidence supporting its recommendation.
6. Policy gate. Rules outside the model verify amount, segregation, state, confidence, permissions, and prohibitions.
7. Approval and execution. A person authorizes the material effect; an API or RPA records it idempotently.
8. Verification and ledger. An independent read confirms remote state and links input, decision, execution, and outcome.

The OMG BPMN 2.0.2 specification provides a formal notation for processes containing tasks, events, gateways, and human participation. It does not mandate this architecture, but it supplies an important discipline: explicitly model where the work type changes and who receives control.

A rule for assigning each step

Classify a step before choosing its technology:

Condition	Primary mechanism	Reason
Structured input and stable rule	Rule or API	Reproducible result that is easy to test
Legacy system without an API, stable interaction	RPA	Automates the edge without delegating the decision
Unstructured evidence with several plausible interpretations	Assistive AI	Summarizes and proposes without hiding uncertainty
Material or hard-to-compensate action	Person behind a technical gate	Preserves authority and segregation
Post-action confirmation	Rule or independent read	Verifies the effect in the system of record

Model-reported confidence does not make an exception deterministic. Transition must also depend on evidence completeness, difference type, current policy, and reversibility. A polished recommendation can still be wrong.

The reconciliation-object contract

Every layer should operate on the same identity. A minimum object includes:

Field	Control purpose
reconciliation_id	Joins the case across systems and runs
source_items	Immutable references to transactions and documents
observed_at	Separates business time from capture time
difference	Amount, currency, field, or state that does not reconcile
reason_code	Stable category even when explanation changes
evidence_refs	Artifacts supporting classification
proposed_action	Permitted verb and parameters
policy_version	Rules applied before authorization
decision	Approval, rejection, or information request
execution_ref	Idempotent identity for the write
verified_state	State read after execution

The W3C PROV Data Model distinguishes entities, activities, and agents, along with derivation and responsibility relationships. Applied here, transactions are entities; normalization, classification, and posting are activities; software and people are agents with different roles. That structure prevents model explanation from becoming the only lineage.

Illustrative example: an ambiguous reference

Assume a bank transaction contains an abbreviated reference that does not exactly match an account receivable. The identifiers and conditions are illustrative. Normalization validates date, currency, and amount; exact matching finds no key. Rather than trying combinations through RPA, the flow creates an exception.

AI compares the text with authorized documents and proposes a candidate account, citing the artifacts it used. The gate checks that the account is open, the amount is compatible, and the agent lacks permission to apply the payment. An analyst accepts or rejects. Only then does the robot open the legacy system, record the application with an idempotency key, and exit. An independent read confirms state; if it differs, the case stays open.

Each technology performed the work it could demonstrate. AI did not write, RPA did not interpret ambiguity, and the person did not have to gather all evidence manually.

Failure is isolated by layer

The architecture also defines continuity:

• when a schema changes, quarantine occurs before classification;
• when the model is unavailable, the ambiguous queue waits while exact matches continue;
• when the policy gate fails, no material write is released;
• when RPA loses confirmation, remote state is queried before retry;
• when no approver is available, escalation does not become approval;
• when verification disagrees, the object is not marked reconciled.

The NIST AI Risk Management Framework Core calls for defined human-AI roles, oversight, and controls for third-party components and data. Separate layers make it possible to apply controls to the component introducing risk instead of treating the agent as one box.

Representing the architecture in Quantum

The public daily reconciliation capability provides business context. In Quantum Automation Center, the object can bring together status, runs, timelines, artifacts, logs, and human approval. The public Quantum ontology documentation helps preserve one business identity across agents and automations.

Quantum does not turn interpretation into a deterministic fact or replace financial policy. Its value here is exposing the boundaries: which component proposed, which one validated, who approved, which robot executed, and which read verified.

The counterargument: an end-to-end agent is simpler

On the surface, yes. One interface that reads, decides, and posts reduces initial orchestration. But that simplicity concentrates classification, permissions, retries, and evidence. When a write is uncertain, the team must reconstruct whether interpretation, policy, or execution failed. The hybrid architecture accepts more contracts in exchange for localized testing and recovery.

Do not add layers for aesthetics. If a step can be a rule, keep it a rule. If an API replaces brittle screen interaction, retire RPA. If the person always rebuilds the recommendation, remove AI or improve context before adding autonomy.

When not to use this architecture

Do not use AI when stable keys and tolerances resolve every relevant case. Do not use RPA when the system provides a reliable, auditable API. Do not build an intelligent exception queue when ambiguous cases are so rare that manual review is cheaper and clearer.

And do not automate the material effect when segregation, reversal, and independent verification cannot be defined. The hybrid architecture is not a way around those decisions. It is a way to express them as executable gates and evidence that survives every component.

Sources

• OMG Business Process Model and Notation 2.0.2
• NIST AI Risk Management Framework Core
• W3C PROV Data Model