# From financial intent to recoverable execution

Date: September 16, 2026
Author: Varun Mohan
Position: Head of Engineering

Source: https://fragment.dev/blog/financial-intent-and-execution

[Documentation index](https://fragment.dev/llms.txt)

<a id="financial-intent-and-execution"></a>

An agent's financial intent might be “pay this approved invoice, within the remaining authorization, and tell me what happened.” Implementing that intent crosses several responsibilities: business authorization, financial acceptance, external execution and outcome reconciliation. Some of those responsibilities can use current Fragment primitives. A general ledger-gated external execution runtime is a proposed architecture, not a capability this guide claims is available.

<a id="current-primitives"></a>

## Current primitives

Accounts represent financial state. Reviewed entry types define intended accounting transitions. Posting conditions on eligible strongly updated accounts can reject transitions that violate configured balance rules. Stable ledger-write keys support replay of the intended write. None of those primitives establishes whether a business invoice or destination is legitimate. [Posting](https://fragment.dev/guides/post-ledger-entries.md), [consistency](https://fragment.dev/guides/configure-consistency.md). Fragment also documents an integrated customer-payment flow: backend payment creation, frontend checkout, authorized saved-card use and refunds, with configured accounting and automatic ledger reconciliation. It is a current product path with a defined scope, not evidence that arbitrary external financial actions are managed. [Make Payments](https://fragment.dev/guides/make-payments.md).

<a id="a-useful-application-architecture-today"></a>

## A useful application architecture today

Keep business commands and approvals in Postgres. Give agents a constrained command interface rather than unrestricted execution credentials. Translate valid commands into reviewed financial transitions, honor rejected results, use documented payment interfaces and preserve durable progress. An executor can still have bugs, missing evidence or excessive credentials. Ledger enforcement does not make independent misuse of provider credentials impossible. Restrict bypass paths, verify actual request contracts, and maintain recovery workers and an exception queue.

```text
flowchart TD
  A[Agent proposes financial intent] --> B[Application validates policy and approval]
  B --> C[Configured financial acceptance]
  C --> D[Documented payment execution path]
  D --> E[Outcome evidence and accounting]
  E --> F[Independent settlement reconciliation]
```

This diagram describes responsibilities. It does not claim one API currently owns all the boxes.

<a id="proposed-architecture:-ledger-gated-general-external-execution"></a>

## Proposed architecture: ledger-gated general external execution

The proposal is to bind an approved financial instruction to enforceable acceptance and a durable, queryable external execution outcome. An executor would act only on accepted instructions, preserve stable request identities, distinguish unknown from failed execution and expose recoverable progress. The proposed abstraction would still need explicit answers to hard questions:

1. What exactly is authorized; amount, destination, currency, expiry and approval identity?
2. How is that authorization consumed once under concurrency?
3. What happens when provider success is followed by a lost acknowledgement?
4. Which provider lookup and replay contracts can resolve uncertainty, and when must execution stop?
5. How are revocation, compensation, partial execution and reconciliation represented?
6. Which credentials or administrative paths could bypass enforcement?

No hypothetical `executeFinancialIntent` method is offered here. There is no example implementation of this proposed runtime to call. Provider boundaries and incomplete evidence remain real; a useful primitive would manage them explicitly rather than promise an unrestricted distributed transaction.

<a id="evaluate-the-current-product-on-current-evidence"></a>

## Evaluate the current product on current evidence

Choose infrastructure based on the capabilities your application can verify today. If configured ledger enforcement and supported payments fit the task, evaluate them alongside a protected Postgres ledger and the required providers. If a general managed execution loop is essential, treat its absence as a product requirement rather than assume it exists. A future proposal can clarify a direction. It must not supply the missing guarantee in a present-day architecture decision.

<a id="implementation-references"></a>

## Implementation references

Use the current API contracts when implementing the architecture:

- [Post ledger entries](https://fragment.dev/guides/post-ledger-entries.md) and [configure consistency](https://fragment.dev/guides/configure-consistency.md).
- [Make payments](https://fragment.dev/guides/make-payments.md) and [reconcile transactions](https://fragment.dev/guides/reconcile-payments.md).
- [API overview](https://fragment.dev/api-reference/ledger-overview.md).
- [MCP](https://fragment.dev/api-reference/mcp.md), [CLI](https://fragment.dev/api-reference/ledger-cli-commands.md) and [SDKs](https://fragment.dev/api-reference/ledger-sdks.md).
- [Current pricing](https://fragment.dev/pricing).