When enterprise AI stalls in the Gulf, the post-mortem often blames the model, the prompt, or “change management.” Look closer and the wall is usually older: core systems that were never designed to be called by an agent — on-prem ERP, core banking, government registries, closed vendor modules, batch interfaces, and change windows measured in weeks.
Model capability is rarely the scarce resource. Integration with legacy systems of record is.
The demo lies about the estate
Demos assume:
- a clean REST API
- a sandbox with representative data
- write access that can be reversed with a smile
- identity that maps neatly to modern SSO
Production in many Omani and wider GCC organisations assumes something else:
- SOAP, files, terminal screens, or partner portals
- golden copies that must not be dual-written casually
- segregation of duties encoded in the host system, not in your agent graph
- maintenance nights and freeze periods that ignore your sprint board
Until the design starts from that estate, AI remains a slide adjacent to the real business.
Integration is the product surface
For agentic and retrieval systems, “integration” is not a phase-two connector story. It is the product surface:
- Read paths decide whether answers are grounded in truth or in a stale extract.
- Write paths decide whether the organisation takes irreversible risk.
- Identity paths decide whether audit can name a person and a role.
- Latency and batching decide whether the workflow feels alive or like overnight mail.
- Error semantics decide whether operations can recover without heroics.
A brilliant model sitting on a wrong or partial interface is still a wrong system.
What legacy actually looks like (qualitatively)
You do not need a vendor census to recognise the pattern:
- ERP and finance cores with partial APIs, custom Z-transactions, and documents that live beside the system of record rather than inside it
- Core banking and insurance platforms where customer state changes are gated by host rules you will not reimplement in a prompt
- Government and registry links with strict schemas, certificates, and liability when a filing is wrong
- Document and imaging stores that hold Arabic scans more often than clean HTML
- Middleware from a previous decade that already mediates traffic — and will mediate your agent whether you budget for it or not
The honest architecture question is not “can the model understand the request?” It is “which system is allowed to become true, through which contract, under whose credentials?”
Dual-write and the fear of two truths
Teams under pressure invent shortcuts: write to the new assistant’s store and to ERP; sync later; reconcile in a spreadsheet. That is how you buy a second general ledger in practice.
Prefer designs that:
- treat one system as authoritative per object type
- use the agent to prepare, validate, and stage rather than silently fork state
- make dual-write explicit, rare, and monitored when policy truly requires it
- surface reconciliation as an owned operations job, not an accident
Legacy estates punish ambiguity. Two truths will eventually disagree in public.
Change windows are a product constraint
If production writes can only land on Thursday night, your “real-time agent” is a fiction for that path. Design for it:
- queue intents with human-visible status
- separate decision time from commit time
- show users what is pending on the host
- test rollback on the same calendar the host team uses
Ignoring change windows produces demos that cannot survive the first freeze.
Human ops are part of the interface
Legacy integration always includes people:
- operators who re-key when the interface fails
- approvers who know which host code means “reject”
- vendor teams who must open a change for a new field
- audit who will ask for the host transaction id, not your chat UUID
Budget them. Train them. Put their steps in the workflow diagram. An integration design that assumes zero human exception handling is incomplete.
Design moves that respect legacy
- Map systems of record before model selection — object by object.
- Prefer read-only grounding first — prove retrieval and citation before writes.
- Wrap host actions behind narrow tools with least privilege and clear idempotency.
- Carry host identifiers through the agent trace for audit.
- Contract data shapes with the owners of ERP/core — not only with the AI vendor.
- Rehearse failure — timeout, partial post, duplicate submit, freeze period.
- Measure integration SLOs (success, reconcile lag, manual rework) as hard as model quality.
These moves are slower than a chatbot pilot. They are how you avoid a year of elegant prompts on top of a brittle pipe.
What this is not
This is not another generic “why projects fail” list. Failure modes matter; the claim here is specific: the bottleneck is legacy integration.
It is not pilot purgatory as a culture story. Culture may amplify the delay; the technical wall is still the host system.
It is not a full rehash of “implementation is the product.” Implementation is broad. Here the focus is the integration bottleneck inside that product.
A practical sequence
- Inventory write-class actions the business wants the AI to touch.
- For each action, name the system of record and the real interface (API, file, RPA, human).
- Classify risk — reversible read, staged draft, irreversible host commit.
- Build the thinnest safe tool for the highest-value read path first.
- Only then open a write path with identity, gate, and host-level audit ids.
- Fund the integration team as a peer of the model team, not as a ticket queue.
If the sequence feels unglamorous, good. Legacy does not care about glamour.
The quiet conclusion
In GCC enterprises, AI rarely fails because the model cannot parse Arabic or draft a summary. It fails when the organisation cannot safely connect intent to the systems that already run the business.
Treat legacy integration as the main design problem. Put identity, change windows, dual-write discipline, and human ops in the architecture from day one. Choose models that serve that pipe — not the other way around.
The estate was here first. The product has to meet it.