Service
AI integration services
An AI system that cannot reach your systems of record is a demonstration. Integration is the work of connecting it to the CRM, the ERP, the support desk, the document estate and the databases where the actual state of the business lives, with permissions and failure behaviour treated as part of the design.
The business problem
Most AI disappointment in the enterprise is an integration problem wearing a model problem's clothes. The system gives a plausible answer that is out of date, or incomplete, or drawn from a repository the asker should not have seen, because the connection to the real records was the last thing built and the least specified.
The second issue is maintenance. Bespoke connectors per platform accumulate quietly, and within eighteen months the integration surface is the thing nobody wants to touch. This is the mechanism Sculley and colleagues described as hidden technical debt in machine learning systems, and it has not changed.
We treat the seams as a design surface: one thin layer you own, open protocols where they exist, and permissions inherited rather than reimplemented.
What we connect
The systems that hold the state an AI system needs to be useful.
CRM
Accounts, opportunities and history, so an answer reflects the actual relationship rather than a generic one.
ERP
Orders, inventory, invoices and the operational truth that people currently look up by hand.
Customer support platforms
Tickets, macros and history, with draft-and-review rather than unsupervised replies.
Document repositories
SharePoint, Drive, DMS and file shares, with the permissions model preserved.
Internal databases
The systems of record behind the reports, read directly rather than through a stale export.
Communication systems
Email and chat, as an interface and as a source, with clear boundaries on what is retained.
Analytics platforms
So the AI system's effect appears in the same reporting as everything else.
Existing workflows
Approval chains, queues and handoffs, which is where cycle time actually lives.
What we will do
- Map the real flow. Which system holds the truth for each field, how current it is, and who is allowed to see it.
- Build one thin layer you own. Your abstraction, in your repository, rather than provider SDK calls scattered through the codebase.
- Prefer open protocols at the seams. Including the Model Context Protocol for tools and data sources, so a connector is not tied to one platform.
- Inherit permissions. The system sees what the requesting person or process is entitled to see; where two systems disagree, the stricter rule applies.
- Define degradation. What happens when a source is unreachable or stale, so the system reports a gap rather than answering confidently around it.
- Instrument outside the vendor. Traces and metrics through OpenTelemetry into your own store, so monitoring does not leave when a provider does.
- Fit the workflow, not around it. Delivered inside the tools people already use, because an extra tab is an adoption tax.
What you will receive
- A documented data flow: source of truth per field, freshness, and access rules.
- An integration layer in your repository, with tests, that treats providers as replaceable.
- Permission behaviour verified case by case, including the negative cases.
- Defined and tested degradation for each source system.
- Traces and metrics in your own observability stack.
- Runbooks for the failure modes that will actually occur.
Expected business outcomes
Answers that reflect reality
Drawn from the systems of record rather than from a stale copy.
No new permission model
Access governed by the entitlements you already maintain and audit.
Lower maintenance surface
One layer to change instead of a connector per platform.
Adoption without a new tool
The capability appears where people already work.
Measurable in your own reporting
Effects visible in the analytics platform the business already trusts.
Portability retained
Provider changes become configuration rather than a rebuild.
How the engagement runs
Frequently asked questions
Do you replace our existing systems?
No. The point of integration work is that the systems of record stay where they are and keep their permissions model.
What if our CRM or ERP is heavily customised?
That is normal and it is usually where the real work is. We read the actual configuration rather than the vendor documentation.
How do you handle permissions across systems?
The AI system inherits the permissions of the person or process it acts for. Where two systems disagree, the more restrictive one wins.
Will this create another integration to maintain?
One thin layer you own, at the seams, using open protocols where they exist. That is materially cheaper to maintain than bespoke connectors per platform.
What happens when a source system is down?
Defined degradation: the AI system reports what it could not reach rather than answering from stale data as if it were current.
Can this work with on-premise systems?
Yes, including cases where data cannot leave your estate. That constraint changes the architecture and should be established early.
Relevant insights
Start a conversation.
If a system works in isolation and cannot reach your records, name the two systems it has to talk to. That is where we would start.