Most companies do not need an AI product. They need AI inside the systems they already run, acting on data they already have, without replacing anything that currently works.
That is integration, and it is a different problem from building an AI product. This covers what it actually involves, where it goes wrong, and how to tell whether your business is ready for it.
Why integration is the hard part
A language model knows nothing about your business. It has not seen your customer records, your pricing rules, your inventory, or the exception your operations team makes for one large account every quarter.
Give it a question about any of those and it will produce a confident answer built from nothing. That is the core problem integration solves: putting the right information in front of the model at the moment it acts, and giving it a safe way to act.
The model is a commodity. Several are good enough for most business tasks, and switching between them is a smaller job than teams expect. The integration layer is where the work and the value are, and it mostly survives a change of model.
The five layers
Data access. Your information lives in a CRM, an ERP, a document store, a database, and several spreadsheets nobody admits to. Integration starts by making the relevant parts reachable through an interface, with permissions intact. This is usually the longest step, and the one that surfaces problems nobody knew about.
Retrieval. Reachable is not enough. The system has to find the right records for each request and present them in a form the model can use. Retrieval quality determines answer quality more than model choice does. A weaker model with good retrieval beats a stronger one guessing.
Actions. Reading is half of it. A system that can look up an order but not update one is a search box with extra steps. Useful systems write back, which means authentication, permissions, validation, and a plan for what happens when a write fails halfway.
Boundaries. What may the system do without a human? Which actions need approval? What must it never touch, and how does it hand off when it is out of its depth? Systems deployed without explicit answers here are the ones that generate incidents.
Evaluation. Without a way to measure whether output is correct, you cannot tell whether a change helped. Teams that skip this tune prompts by feel and cannot answer whether last month’s edit made things better or worse.
Skip any layer and the project usually still demos well. It just does not survive contact with real usage.
Where integration projects actually fail
The data is not reachable. The information lives in a system with no API, a PDF archive nobody indexed, or an employee’s judgment. This is the most common blocker and it surfaces late, after budget is committed, unless someone checks in week one.
Nobody can describe the process. If your team cannot explain how the decision is made today, no system can learn it from the same absence of documentation. This is worth discovering early, because the documentation exercise often delivers value on its own.
No definition of correct. Without agreement on what a good output looks like, the project has no finish line. Every review becomes an opinion.
Permissions treated as an afterthought. An AI system that can read anything will eventually surface something to someone who should not see it. Permissions belong in the design, not in a hardening pass afterwards.
Cost discovered in production. Token spend scales with usage. Systems that were cheap in testing become expensive at real volume, usually because every request goes to the most capable model when most requests do not need it.
What good integration looks like
It starts with one process. Not “AI for the business”. One workflow, with a measurable current cost in hours or errors, and a clear definition of better.
It leaves the existing system in place. The AI layer reads from and writes to what you already run. Replacing working software to accommodate AI is how a six-week project becomes a nine-month one.
It keeps a person in the loop initially. Route the output to a human for review, measure agreement, and expand autonomy where the numbers earn it. Starting fully autonomous means discovering problems in production.
It is measured against the old way. You should be able to state what changed. Hours saved, error rate, turnaround time. Without a baseline captured before you start, you cannot.
It routes work by difficulty. Simple requests go to a small cheap model, hard ones to a capable one. This one decision often halves running cost with no quality loss.
Is your business ready?
Five questions about a specific process:
- Can the data this process needs be reached programmatically today?
- Can someone describe how the decision is made, even roughly?
- Is there agreement on what a correct output looks like?
- Does a person currently spend meaningful time on it?
- Is there a review step, or could one exist?
Four or five yeses means the process is ready to cost out. Fewer means the honest first step is fixing the process, the data access, or the documentation. That work is not wasted. It is a prerequisite, and it is cheaper to do before a build than during one.
The realistic sequence
A first integration on a well-scoped process typically moves through the same phases: confirming data access and capturing a baseline, connecting retrieval and testing whether the system finds the right information, adding the write-back actions with permissions and validation, running alongside a human reviewer to measure agreement, then expanding autonomy where the measurements support it.
The phase that overruns is almost always the first one, because data access problems are discovered rather than planned. Budget accordingly, and check it before committing to the rest.
Ethersofts does integration work. We connect AI to the systems a business already runs, including retrieval over your own data, writes back into your CRM or ERP, permissions and boundaries for autonomous action, and evaluation so you can prove it works.
If you have a process in mind and want to know whether the data behind it is reachable, talk to an engineer. That is the question worth answering first.