An AI system that cannot read from and write to your systems of record is a demo. The value appears the moment it participates in the systems where work actually happens — and that is also the moment the risk appears.
Decide which system is authoritative. This is not a technical question.
Before any integration is built, one question must be answered per entity: which system wins?
If the CRM and the ERP disagree about a customer's address, which is correct? If the agent extracts a value from a document that contradicts the ERP, what happens?
This is a business decision. Engineers cannot make it and should not guess at it. Projects stall here regularly, and the stall is useful information: it means the organisation has been running on an unresolved ambiguity that people were absorbing manually.
Write the answer down per entity. It becomes the conflict-resolution rule, and it is the difference between a system that reconciles and one that oscillates.
Read paths and write paths are not symmetrical
Reading is comparatively forgiving. A stale read produces a suboptimal answer. Annoying, rarely destructive.
Writing is where the consequences live. A write path needs, without exception:
Idempotency. Network calls fail and get retried. If the retry creates a second record, you have manufactured a duplicate invoice. Every write should carry a key that makes repetition a no-op.
Validation before the boundary. Validate against a schema on your side, before calling the vendor's API. Vendor validation errors are frequently unhelpful, sometimes partial, and occasionally arrive after a partial write.
A quarantine, not a drop. Records that fail validation go somewhere a person can inspect them. Never silently discarded — a discarded record is discovered during a reconciliation months later, by which point nobody can reconstruct what happened.
An audit trail. What was written, when, triggered by what, and — for AI-initiated writes — the reasoning behind it. This is what makes the system defensible when someone asks why a record changed.
Permissions must be enforced, not assumed
The most serious failure mode in AI integration is an agent becoming an accidental route around access control.
If a knowledge assistant indexes documents with a service account that can read everything, and then answers questions for any employee, you have built a permission-bypass tool with a friendly interface. The person asking gets content they were never authorised to see, and no access log shows a violation, because technically none occurred.
Retrieval must be filtered by the asking user's permissions at query time — not at index time, not by a broad service account. This is more work. There is no acceptable shortcut.
The same principle applies to writes: the agent should act with permissions scoped to the action, not with an administrative account that can do anything because it was easier to configure.
Adapters, not direct calls
Wrap each external system in an adapter with an interface you define. Every vendor quirk — pagination, rate limits, inconsistent field naming, the endpoint that returns 200 with an error in the body — lives inside that adapter and nowhere else.
This is not architectural purity. It is a practical response to the fact that vendor APIs change without notice and rate limits are discovered in production. When a vendor breaks something, you fix one file rather than auditing every call site.
It also makes the system testable. You cannot write reliable tests against a live ERP; you can write them against an adapter interface.
When there is no API
Plenty of valuable systems have no usable interface. Options, roughly in order of preference:
- A supported integration interface you had not found — worth looking harder than seems necessary.
- Database-level integration, read-only where possible, with the vendor's blessing where obtainable.
- Scheduled file exchange. Unfashionable, completely reliable, and often sufficient.
- A documented adapter built with the system owner.
What we avoid wherever possible is UI automation — driving the vendor's interface as though it were a user. It is brittle, it breaks on the vendor's next release, and it usually violates their terms. It is a last resort, and it should be scoped as a temporary bridge with a known end date, not as an architecture.
Rate limits are a design constraint
Vendor APIs impose limits, and they are usually discovered the first time you run a real backfill.
Design for them from the start: queue writes rather than firing them synchronously, batch where the API supports it, and make the system degrade gracefully when throttled — slower, not broken. A backfill that must run overnight is fine. A backfill that hammers an API until the vendor disables your key is a incident.
The unglamorous conclusion
Most of the difficulty in AI integration is not AI. It is the same distributed-systems discipline that has always applied: idempotency, validation, permissions, observability, graceful degradation.
The model is the interesting part. The integration is the part that determines whether it is still running in a year.