The first service
The intelligence layer over the systems you already run
An intelligence layer is intelligence added to the systems a company already runs, not a new system beside them. It reads across the CRM, ERP, SaaS and documents read-only at the boundary, reconciles what they disagree about, names which source it believed, and writes the result back into the tool where the work already happens.
What an intelligence layer is
Intelligence on the software you already run. It sits above your CRM, ERP and management software and reads them where they are — no migration, no replacement, no data-warehouse project that has to finish first. It reconciles what they disagree about, carries a workflow across all of them, and writes the result back into the tool your people already have open.
It is delivered inside a services engagement — no licence, no product to install, nothing to evaluate on a trial.
What the layer sits on top of
- ERP
- CRM
- HRIS
- ITSM
- Data warehouse
- Document stores
System categories, not vendors. Named integrations go here when we can evidence them.
Read-only at the boundary
Reads across CRM, ERP, SaaS and documents — read-only, at the boundary.
At the boundary means at the system's own interface. The layer does not run inside your ERP, it is not installed into it, and it does not hold a second copy of its data. Every system of record keeps its own access controls, its own audit and its own data, and nothing is copied out to make the layer work.
That is also the answer to can an AI layer read from an ERP without write access — reading and writing are separate permissions, and the reading half needs nothing granted beyond what a reporting user already has.
What happens when two systems disagree
The layer reconciles the conflict and names which source it believed. Where an ERP says 400 and a CRM says 380, it applies the rule your team set, records the decision with that rule and that source attached, and escalates anything it should not decide alone to a person.
Source-of-truth attribution
Source-of-truth attribution is recording, per decision, which system the layer believed and under which rule. Not which system is authoritative in general — that is a master-data question and it is usually unanswerable. Per record, per decision, with the rule attached.
That is the difference between reconciliation and a report. 1 answer, when four systems disagree — and the disagreement itself stays on the record rather than being smoothed away.
Carrying one workflow across system boundaries
Carries a workflow across systems, escalating what it should not decide alone.
The same shape appears wherever the work spans systems: one answer, across erp, mes and the spreadsheet in manufacturing, inside the ticket, not beside it in professional services. Cross-system workflow automation is the general case; each of those is one instance of it.
Capturing the rules that only exist in people's heads
Captures the rules that exist only in your people's heads.
They go into plain markdown notes the layer reads on every run. One rule from a real one:
Match on SKU, never on line position. Unit price ±2%. Quantity exact, no tolerance. Freight ignored, reconciled separately in freight-accrual.
ops/vendor-onboarding.md
The whole file, field by field, is on the plain-text knowledge base it reads its rules from; the same rules as accounts-payable mechanics are on purchase order matching, rule by rule.
Writing back into the tool where the work already happens
Writes back into the tool where the work already happens.
Yes, it writes back — into the ticket, the order, the invoice record. A result that lands somewhere your people do not already look is a result nobody acts on.
Where the command center fits
The layer acts inside the tools your people already have open, which is where the work happens. The command center is oversight, for the people who need to see across everything at once — not another queue for everyone else to live in.
Both ship together for that reason. One oversight screen across every connected system covers the second half.
Data residency, and what read-only at the boundary answers
Nothing is migrated and no warehouse is built, so the systems of record stay where they are and keep the residency, the access controls and the audit they already have. That is usually the part a security review is actually asking about.
It is not a residency statement about our own processing. Hosting region, sub-processors, where inference runs and retention are described nowhere on this site, and describing them without an architecture document behind them would be the same error as a placeholder compliance badge.
What it is not: a warehouse project, a bot, a new system
Every AI programme starts by asking what you will add. But the systems you already run hold the data, the process and twenty years of decisions — the problem was never that you were short a system. It is that none of them can see the others, and the intelligence that would join them lives in four people's heads.
| What it does | When a screen changes | |
|---|---|---|
| Intelligence layer | Reads production data where it lives, disagreements and all | Reads at the interface, not the screen |
| RPA script | Replays a recorded click path | Breaks |
Two columns, not three. A third for integration platforms needs one signed-off sentence on what the layer does that an iPaaS does not, and no such line exists on this site yet. An invented column is worse than a missing one — the three-way version lives on how a layer differs from an RPA script the day it can be written honestly.
The full category argument is on enterprise intelligence, defined, and the no-migration case on integration without migration or replacement.
Questions
Straight answers.
What is an intelligence layer in enterprise software?
Intelligence added to the systems a company already runs, rather than a new system beside them. It reads the CRM, ERP, SaaS and documents read-only at the boundary, reconciles what they disagree about, applies the rules your team wrote, and writes results back into the tools people already use.
What happens when two systems disagree about the same record?
The layer applies the rule your team set, commits to one value, and records which source it believed alongside that rule. Anything it should not decide alone goes to a person instead. The disagreement stays on the record rather than being smoothed away.
What is source-of-truth attribution?
Recording, per decision, which system the layer believed and under which rule. Not which system is authoritative in general — that is a master-data question and usually unanswerable. Per record, per decision, with the rule attached, so the answer can be checked rather than trusted.
Which system is the source of truth, ERP or CRM?
Neither, in general. It depends on the field and the moment: an ERP is usually right about what was invoiced, a CRM about what was agreed. Rather than declaring one winner, the layer applies your rule per decision and records which it believed that time.
Can an AI layer read from an ERP without write access?
Yes. Reading and writing are separate permissions. The reading half needs nothing beyond what a reporting user already has, and read-only at the boundary means the layer never runs inside the system or holds a second copy of its data.
Does an intelligence layer write back into your existing systems?
Yes — into the ticket, the order or the invoice record where the work already happens. A result that lands somewhere your people do not already look is a result nobody acts on. Write-back is a separate, explicitly granted permission from reading.
Do you need a data warehouse for cross-system automation?
No. The layer reads systems where they are, so nothing has to be consolidated first. A warehouse gives you one modelled history and is a real purchase, just a different one — the trade-off is set out on the ERP integration page.
Start here
Bring us one workflow.
Tell us the process that crosses the most systems. You get a scope, a measure and a delivery plan back — and a straight answer if we think it is not worth building.
Get in touch