A user asks an AI agent:
“Pay this invoice, update the records, and let the supplier know when it’s done.”
It sounds like one business operation.
From the user’s perspective, it is one request.
From the system’s perspective, it may be five different transactions.
User Request
|
v
AI Agent
|
+----> Validate Invoice
|
+----> Reserve Funds
|
+----> Execute Payment
|
+----> Update Business State
|
+----> Notify Supplier
Each step may belong to a different system.
Each may have its own transaction boundary.
Each may succeed or fail independently.
There is no single transaction that can simply roll everything back.
This is not a new problem.
Financial systems have dealt with distributed business operations for decades.
What changes with an AI agent is who decides what happens next.
The workflow is no longer necessarily a completely predetermined sequence.
A probabilistic decision-maker is now sitting inside a process that still requires deterministic business correctness.
That creates a particularly interesting distributed transaction problem.
One User Request Is Not One Transaction
The first mistake is confusing a business intent with a database transaction.
The user expresses one intent:
Pay the invoice.
But the business operation may involve:
Invoice System
|
v
Payment System
|
v
Ledger
|
v
Settlement
|
v
Notification
These systems may have different ownership, different transaction boundaries, and different failure modes.
A local transaction can guarantee something within its own boundary.
It cannot automatically guarantee that every other system completes successfully.
Suppose:
Create Payment ✓
Ledger Entry ✓
Invoice Update ✗
Supplier Notification —
The payment happened.
The invoice still says unpaid.
The supplier hasn’t been notified.
There is no single database rollback that magically restores the entire business operation.
The system now has to deal with reality.
The Illusion of One Transaction
Traditional application thinking often encourages this mental model:
BEGIN
|
+-- Step 1
+-- Step 2
+-- Step 3
+-- Step 4
|
COMMIT
That model works when the operations genuinely belong to one transactional boundary.
But once the workflow crosses independent systems, the reality is more like:
Transaction A
|
v
Transaction B
|
v
Transaction C
|
v
Transaction D
|
v
Transaction E
Each transaction can commit independently.
The business operation therefore needs something above the individual transactions.
It needs a workflow-level notion of correctness.
That distinction becomes critical with AI agents.
What Does the Agent Actually Own?
An AI agent may appear to own the whole process.
It receives the request.
It reasons about the task.
It decides which action to take.
It observes the result.
It decides what to do next.
But should it own the transaction?
I would argue no.
The agent may own the intent and coordination of the conversation.
It should not become the authoritative owner of financial state.
That distinction can be represented as:
Business Intent
|
v
AI Agent
|
proposes actions
|
v
Workflow Boundary
|
+------------+------------+
| | |
v v v
Payment Ledger Invoice
System System System
The agent can help coordinate the journey.
The underlying systems remain responsible for the correctness of their own state.
The Five-Transaction Problem
Consider a simple payment workflow.
The agent decides that five business actions are required:
1. Validate the invoice
2. Reserve the funds
3. Execute the payment
4. Mark the invoice as paid
5. Notify the supplier
Now imagine:
1. Validate invoice ✓
2. Reserve funds ✓
3. Execute payment ✓
4. Mark invoice paid ✗
5. Notify supplier —
What should happen?
The naïve answer is:
“Roll everything back.”
But the payment may already have crossed a boundary that cannot simply be reversed.
The money may have moved.
A ledger entry may already exist.
An external payment network may already have accepted the transaction.
The correct response may therefore be compensation, not rollback.
That is a fundamentally different concept.
Rollback and Compensation Are Not the Same
A rollback says:
Pretend this transaction never happened.
Compensation says:
The transaction happened. Perform another valid business operation to correct its effect.
For example:
Payment Completed
|
v
Invoice Update Failed
|
v
Retry Invoice Update
If that cannot be repaired automatically, the business may need a compensating action.
But compensation itself can fail.
It can also be delayed.
It can also require authorization.
It may even be impossible.
That is why distributed business workflows cannot be designed around the assumption that every failure can simply be undone.
The Agent Makes Compensation More Interesting
In a traditional workflow, the sequence might be explicitly programmed:
Step 1
↓
Step 2
↓
Step 3
↓
Step 4
The recovery logic is usually known when the workflow is designed.
An AI agent can introduce a different model.
The agent may observe:
Payment succeeded.
Invoice update failed.
and then decide what action appears appropriate.
That creates a new boundary:
Should the agent be allowed to decide the compensation?
In financial systems, that is a dangerous question.
An agent can help reason about the situation.
But compensation rules that affect financial state should be constrained by deterministic business policies.
For example:
Payment succeeded
|
v
Invoice update failed
|
v
Known recovery policy?
|
+---+---+
| |
Yes No
| |
v v
Execute Escalate
Recovery for review
The agent can assist.
The system must still control what actions are permitted.
The Saga Is Still Relevant
This is where the classic Saga idea becomes useful.
A Saga treats a long-running business operation as a sequence of local transactions.
Instead of:
One giant transaction
we have:
Local Transaction
|
v
Local Transaction
|
v
Local Transaction
|
v
Local Transaction
Each completed step becomes part of the business history.
If something fails later, the workflow executes an appropriate recovery or compensating action.
For example:
Reserve Funds
|
v
Create Payment
|
v
Update Invoice
|
v
Notify Supplier
If the invoice update fails:
Update Invoice
X
|
v
Recovery
|
+--> Retry
|
+--> Compensate
|
+--> Escalate
The important point is that the Saga is not merely a technical pattern.
It is a way of representing business progress across independent transaction boundaries.
The Agent Does Not Make the Saga Disappear
There is a temptation to think:
“The agent can figure out the workflow dynamically, so we don’t need explicit orchestration.”
That is where things can go wrong.
A financial workflow cannot rely entirely on the model remembering:
What has completed?
What failed?
What can be retried?
What can be compensated?
What requires approval?
Those facts need durable representation.
The agent may participate in deciding the next step.
The workflow still needs an authoritative record of what has already happened.
For example:
Workflow: INV-78421
Invoice Validated ✓
Funds Reserved ✓
Payment Executed ✓
Invoice Updated ✗
Supplier Notified —
This is much more useful than relying on the agent’s conversational context.
Business State Is More Important Than Agent State
An agent may have a conversation state.
A business workflow has business state.
They are related.
They are not the same.
Consider:
Agent State:
"I think the payment succeeded."
Business State:
"Payment transaction P-98231 is COMPLETED."
The second statement is authoritative.
The first is an interpretation.
This distinction becomes critical when recovering from failures.
If the agent restarts, its reasoning can start again.
The business state must not start again.
What If the Agent Chooses the Wrong Next Step?
This is where AI introduces something genuinely different.
Suppose:
Payment completed.
Invoice update failed.
A traditional workflow might have a defined recovery path.
An agent might reason:
“The invoice update failed, so I should retry it.”
That may be correct.
But suppose the failure was actually caused by:
Invoice already marked as paid
The retry may be unnecessary.
Or suppose:
Invoice was cancelled after payment.
Now the situation may require a completely different business process.
The agent can interpret the situation.
But interpretation should not become authority.
A safer architecture separates:
Observed State
|
v
Possible Actions
|
v
Business Policy
|
v
Allowed Action
The agent can help with the first two.
The policy determines the last one.
Distributed Transactions Have Partial Success
One of the hardest things about distributed transactions is that failure isn’t binary.
You can have:
Nothing happened.
You can have:
Everything happened.
But you can also have:
Some things happened.
That third state is where most of the architectural difficulty lives.
For example:
Invoice VALIDATED
Funds RESERVED
Payment COMPLETED
Ledger RECORDED
Notification FAILED
Is the business operation successful?
Possibly.
Is it complete?
Not yet.
Does the payment need to be reversed?
Probably not.
Does the notification need to be retried?
Possibly.
This is why the system needs explicit business states rather than a simple:
SUCCESS / FAILURE
Unknown Is Still a Valid State
There is another important scenario.
Suppose the agent asks the payment system to execute a payment.
The payment system processes it.
The response disappears.
The agent sees:
UNKNOWN
It cannot safely assume:
FAILED
because the payment may have succeeded.
It also cannot assume:
SUCCESS
because the outcome hasn’t been confirmed.
The workflow might therefore become:
PAYMENT_REQUESTED
|
v
UNKNOWN
|
v
RECONCILIATION
|
+---+---+
| |
v v
SUCCESS FAILED
This is a familiar pattern in financial infrastructure.
The important lesson for agentic systems is:
The agent should not resolve uncertainty by guessing.
It should transition the workflow into a state where uncertainty can be resolved.
Idempotency Protects the Boundaries
Every step in a distributed workflow needs to answer an important question:
What happens if I receive the same request twice?
This becomes even more important when an AI agent is involved because the agent may decide to retry an operation.
Consider:
Agent
|
+--> Execute Payment
|
X response lost
|
+--> Execute Payment again
The receiving system needs to recognize:
"This is the same business operation."
not:
"This is a new payment."
The same principle applies to:
- invoice updates
- fund reservations
- notifications
- external calls
- compensation actions
Idempotency is what allows the workflow to recover without turning every retry into another business event.
Exactly Once Is Not a Strategy
Distributed systems often encourage the phrase:
“We need exactly-once processing.”
But exactly once is rarely a complete answer.
What matters more is the business effect.
Suppose a payment request is delivered twice.
If the payment system safely recognizes both requests as belonging to one logical operation, the business effect can still happen exactly once.
That is more useful than trying to pretend the entire distributed workflow has one magical exactly-once transaction.
For agentic workflows, this distinction is particularly important.
The agent may repeat an action.
The architecture must make the repeated action safe.
The Agent Should Not Be the Transaction Manager
An agent can be a coordinator.
It should not be the final authority over transaction semantics.
Why?
Because transaction correctness involves invariants such as:
- money cannot be created accidentally
- money cannot be debited twice
- an unauthorized account cannot initiate an operation
- an invoice cannot become paid without the required business conditions
- a completed payment cannot be silently forgotten
- compensation must follow business rules
These are not matters of probability.
They are invariants.
They belong in deterministic business boundaries.
The Agent Can Coordinate Intent
A useful distinction is:
Intent
|
v
Agent
|
v
Proposed Workflow
|
v
Business Rules
|
v
Authorized Operations
|
v
Transactions
The agent is very good at understanding intent.
For example:
“Pay the latest approved invoice from the marketing supplier.”
The agent can help identify:
- which invoice the user means
- what information is missing
- what sequence of actions may be necessary
But once the operation approaches a financial boundary, deterministic systems must take control.
The invoice system determines whether the invoice is approved.
The authorization system determines whether the user can pay it.
The payment system determines whether the payment is valid.
The ledger determines the financial truth.
What Happens When a Compensation Also Fails?
Now consider a harder situation.
Reserve Funds ✓
Payment ✓
Invoice Update ✗
Compensation ✗
The system has reached a state where automatic recovery is no longer possible.
This is where mature financial systems distinguish between:
technical failure
and
business exception.
The workflow may need:
AUTOMATIC RECOVERY
|
X
|
v
EXCEPTION STATE
|
v
RECONCILIATION
|
v
HUMAN DECISION
This is not a failure of automation.
It is often the correct result.
A financial system should prefer an explicit unresolved state over silently making an unsafe decision.
Human Intervention Is Part of the Architecture
AI agents can reduce manual work.
They do not eliminate the need for human intervention in every exceptional case.
Imagine a workflow where:
Payment completed
Invoice cancelled
Customer disputes payment
External provider unavailable
Automatic compensation unavailable
An agent may be able to gather the relevant information and explain the situation.
But the final action may require a human decision.
The workflow can therefore move into:
EXCEPTION_REVIEW_REQUIRED
This is an important design principle:
A system that can safely stop is often more reliable than a system that must always decide.
The Agent Changes the Nature of Orchestration
Traditional orchestration generally knows:
Step A
↓
Step B
↓
Step C
An agent can introduce:
Goal
|
v
Observe
|
v
Decide
|
v
Act
|
v
Observe
|
v
Decide again
That makes orchestration more flexible.
It also makes the boundaries more important.
The workflow must distinguish between:
What the agent proposes
and
what the system has actually committed.
Those are not the same thing.
A Useful Mental Model: Intent vs. Commitment
I find this distinction particularly useful.
An AI agent operates primarily in the world of:
INTENT
Financial systems operate in the world of:
COMMITMENT
For example:
Agent:
"Let's pay invoice 4812."
is intent.
This:
Payment P-78219
Amount: $50,000
Status: COMPLETED
is commitment.
Between those two worlds are the controls that matter:
Intent
|
v
Validation
|
v
Authorization
|
v
Execution
|
v
Commitment
The agent can help move the process forward.
It should not collapse these boundaries.
The Real Problem Is Not the Transaction
The deeper problem is business consistency across independent commitments.
A user thinks in terms of:
“Pay this invoice.”
The system may have to maintain consistency across:
- invoice state
- account state
- payment state
- ledger state
- settlement state
- notification state
Those states may not change at the same moment.
The system therefore needs a definition of what “correct” means during the transition.
That is where workflow design, reconciliation, compensation, and explicit state become more important than the model itself.
AI Makes the Boundary More Dynamic
This is where AI genuinely changes the problem.
In traditional distributed systems, the workflow is often known before execution.
With an agent, the next action may depend on what the agent observes.
For example:
Invoice found
|
v
Agent evaluates situation
|
+----> Missing information
|
+----> Requires approval
|
+----> Ready for payment
|
+----> Suspicious condition
That flexibility is powerful.
But every possible path still needs to respect the same business invariants.
The agent can choose among allowed actions.
It should not invent new transaction semantics.
The Architecture I Would Trust
For consequential financial workflows, the boundary I would want is roughly:
User Intent
|
v
AI Agent
|
Proposed Action
|
v
+---------------------+
| Business Policy |
| Authorization |
| Validation |
+----------+----------+
|
v
+---------------------+
| Durable Workflow |
| State |
+----------+----------+
|
+------------+------------+
| | |
v v v
Payment Invoice Ledger
Boundary Boundary Boundary
| | |
+------------+------------+
|
v
Reconciliation
The agent brings flexibility.
The workflow brings durability.
The business rules bring control.
The transaction boundaries bring correctness.
Reconciliation brings recovery from reality.
What AI Should and Should Not Do
AI is useful for:
- interpreting user intent
- identifying relevant information
- proposing workflow steps
- explaining failures
- summarizing business state
- assisting operators
- identifying potential anomalies
- helping determine which permitted action may be appropriate
AI should not silently become the authority for:
- financial truth
- authorization
- transaction completion
- accounting state
- irreversible business commitments
That distinction is more important than the choice of any particular AI technology.
The Five Boundaries Are the Point
Return to the original request:
“Pay this invoice, update the records, and let the supplier know when it’s done.”
It sounded like one operation.
But perhaps the architecture actually contains:
1. Invoice Transaction
2. Funds Transaction
3. Payment Transaction
4. Ledger / Business-State Transaction
5. Notification Transaction
There is no single commit button for all five.
There is only a business workflow connecting them.
The system therefore needs to know:
What happened?
What is still pending?
What failed?
What can be retried?
What can be compensated?
What requires reconciliation?
What requires human intervention?
Those questions existed before AI.
AI simply makes them more visible because the component coordinating the workflow can now reason dynamically.
Final Takeaway
An AI agent can make a distributed workflow feel like a single conversation.
The user says:
“Pay this invoice.”
The agent can make the complexity disappear from the user’s perspective.
But underneath that simple sentence may be multiple independent transactions, asynchronous events, external dependencies, and irreversible financial commitments.
The danger is believing that because the agent understands the business intent, it therefore controls the business transaction.
It doesn’t.
A reliable architecture separates the two.
The agent understands and coordinates intent.
Deterministic systems enforce business rules.
Individual systems own their transaction boundaries.
The workflow records what actually happened.
Idempotency makes retries safe.
Compensation handles completed work that cannot simply be rolled back.
Reconciliation resolves what the system cannot know immediately.
And when automation reaches the edge of what can be safely determined, the workflow should be able to stop and ask for human intervention.
That is the real distributed transaction problem in AI agents.
The hard part is not getting an agent to execute five actions.
The hard part is ensuring that when those five actions cross five transaction boundaries, the business remains correct even when the agent, the network, a dependency, or one of the transactions fails.
That is where agentic architecture meets the realities of financial systems.