The integration question used to be about data movement. Get the order from the storefront into the ledger, get the payment status back, reconcile nightly. It was a problem of mapping and scheduling, and the failure modes were duplicates and gaps. Agents change the shape of it. An agent does not read a table and write a row; it decides to take an action, and the interesting engineering question is what happens when it decides to take the same action twice, or half of one, or the right action against the wrong entity.
Integration used to move records between systems. Agentic integration grants the authority to change them, and authority needs a shape that a data mapping never required
Here is the design that makes this survivable in a financial system.
The four properties every agent-facing interface needs
Idempotency, enforced server-side. Every write operation must carry a client-supplied key such that repeating it produces the same single effect. Agents retry — on timeout, on ambiguous error, on their own re-evaluation — and an interface that creates a second payment run on a retry is not safe at any level of model quality. Operations rather than tables. Expose "post journal entry", "create supplier invoice", "release order", each with its own validation and authorisation. Do not expose the ledger tables. An agent given table access will construct transactions that satisfy the schema and violate the accounting. Scoped, narrow permissions with their own identity. The agent is not the person who configured it. Give it its own credential, restricted to the specific operations, entities, value bands and periods it needs, and never inherit an administrator's rights for convenience. Reversibility, or refusal. Every operation should be classifiable as reversible, compensatable or irreversible. Reversible operations can be autonomous. Compensatable ones need a defined compensating transaction written before go-live. Irreversible ones — outbound payments, statutory submissions, contract execution — stay behind human confirmation regardless of confidence.
| Operation class | What must be specified |
|---|---|
| Reversible | The tested reversal, authorised scope and action record. |
| Compensatable | The compensating transaction and its owner before enablement. |
| Irreversible | The human confirmation at the external action boundary. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The pattern that fails
Wrapping a general database interface in a tool definition and calling it integration. It demonstrates beautifully and it has no authorisation model, no idempotency and no way to explain afterwards what happened or why. This is the most common architecture in production today and it is the source of most of the incidents.
What auditors will ask for
A record, per action, of which agent took it, under whose authority, on what input, and what the resulting posting was. That is not logging in the conventional sense; it is an accounting trail with an actor field that has no employee number. Design it now — retrofitting attribution into an existing agent integration is substantially harder than building it in.
Practical Guidance for Agentic Integration Design
- Require client-supplied idempotency keys on every write.
- Expose operations, never tables.
- Give each agent its own identity and its own scope.
- Classify every operation as reversible, compensatable or irreversible.
- Write the compensating transaction before enabling the operation.
- Cap value and volume per agent, per period.
- Log actor, authority, input and result for each action.
- Rehearse the rollback before you need it.
The Regional Angle
The first regional consideration is that the irreversible category is larger here than the generic guidance assumes, because so many actions terminate in a government platform. A Saudi e-invoicing submission, an Emirati tax filing or a wage protection instruction is not a database write that can be reversed with a correcting entry — it is an external event with a regulatory record. Classify every integration that reaches a government endpoint as irreversible by default, and put the human confirmation at the submission boundary rather than somewhere upstream where it feels less disruptive. The second concerns who builds these integrations in this market, which is usually a systems integrator rather than an internal platform team. That has a direct architectural consequence: idempotency, scoping and operation-level interfaces are design disciplines that cost the integrator time and are invisible in a demonstration, so they get dropped unless they are written into the statement of work. Specify the four properties as contractual acceptance criteria, because a fixed-price integration project has no incentive to build the safety you did not ask for. The third is about payment mechanics, where regional practice adds a wrinkle worth naming. Post-dated cheques, cheque-based settlement and manual bank portal instructions remain common in Gulf commercial practice, and none of them offer the clean reversal semantics that an electronic transfer does. An agent that can prepare a cheque run is operating in a space where the compensating transaction is a phone call to a bank branch. Keep that boundary firmly human, and be explicit with your integrator that the automation stops at preparation.
The objection worth taking seriously
The strongest objection is that this is over-engineering for a problem the platforms will solve. Every major vendor is building agent frameworks into its own product, with native authorisation, native audit and native idempotency, and organisations that spend this year designing bespoke agent integration patterns will find their careful work superseded by a platform capability in the next release cycle. The disciplined answer is to wait for the vendor rather than build integration architecture on a moving target. That is a reasonable read of where the platforms are heading, and for organisations whose agents operate entirely within one vendor's suite it is probably correct advice. It breaks down at the boundary, which is where almost everything interesting happens. Native frameworks govern agents acting inside their own product; the integrations that matter commercially cross between the enterprise resource planning system, the customer platform, the banking interface and whatever the operations team runs, and no vendor's framework governs that span. Notice also that three of the four properties here — idempotency, operation-level interfaces, scoped identity — are simply good interface design that benefits every consumer, agent or not. Building them is not a bet on an agent architecture. It is the work you would want done anyway, which is the cheapest kind of preparation.
Common Questions
Can an agent have write access to the general ledger?
To defined posting operations with validation and limits, yes. To the ledger tables, no, and the distinction is the whole design.
How do we handle an agent that takes a wrong action?
By having decided in advance whether that operation was reversible and, if it was compensatable, by having written the compensating transaction. Improvising this after the fact is how small errors become restatements.
Should each agent have its own credential?
Yes. Shared credentials destroy attribution, and attribution is the only thing that makes the audit trail meaningful.
What should we expect over the next twelve months?
Expect vendors to ship native agent authorisation that works well inside their own products and not across boundaries. Expect auditors to begin asking for per-action attribution. Expect the first publicised incidents to involve retries rather than bad reasoning. And expect idempotency to become a standard procurement question for integration platforms.
Agentic Integration Design — we make the four properties contractual acceptance criteria before your integrator writes a line of code.