An agent looks sharp in the demo and stalls in production the moment you ask for the real status of an order. McKinsey reported in August that nearly two thirds of companies have experimented with agents, while fewer than 10% have scaled them to tangible value. In its analysis of the foundations for agentic AI, eight in ten firms name data limitations as the obstacle to scaling. The model rarely fails. The record the agent needs sits in an ERP that speaks SOAP, a SQL database from fifteen years ago and three spreadsheets nobody reconciles.
Why the agent stalls once it leaves the demo
Cramming more documents into the context window does not answer an operational question. How many units of a part are left, whether a customer is behind on payments, what terms were agreed in the last renewal. That requires reading transactional systems, not an index of PDFs.
A 2026 Harvard Business Review study on AI value (What Drives AI Value) found that 70% of business leaders struggle to integrate agents with their systems, and say their agents lack access to the right data.
Salesforce's State of Agentic AI in the Enterprise survey, with 2,025 decision makers, adds a useful nuance. Only 31% of companies running agents in production unified their data before launch. Those that unified the data relevant to their use case reached payback in 7.3 months, against 8.8 months for teams that shipped first and patched gaps afterwards. You do not need one unified company, only the slice your use case touches.
An access layer over the systems you already run
The market is skipping the ERP migration and building a middle layer that translates model language into queries against existing systems. RavenDB shipped Quill on September 8, a context layer that connects to PostgreSQL, SQL Server or MySQL without moving the system of record. ERP vendors are moving the same way from inside. SAP showed its Autonomous Suite at Sapphire 2026 with more than 200 agents, and IFS added Agent Studio so business users can configure their own digital workers.
Any layer of this kind needs three things settled before you connect anything:
- Readable semantics. An agent that reads
customer_case_linkunderstands less than one that reads "this customer has an open case". Joe Inzerillo, president of Enterprise & AI Technology at Salesforce, puts it plainly: the semantic layer is what unlocks the value. - Permissions inherited from the user. The agent acts with the permissions of whoever starts the request, not with a service account that reaches everything. The EMA report Agents Without Guardrails found that close to half of companies cannot easily reconstruct what an agent did in the last 30 days.
- A record per action. Gartner expects more than 40% of agentic AI projects to be cancelled before the end of 2027 over rising costs, unclear value and weak risk controls.
How to start without touching the migration
- Pick a use case whose data already sits behind an API or a reachable SQL instance. Your three main systems are enough for the first prototype.
- Write the ten questions the agent has to answer and find the system that holds each answer. Whatever is missing from that list is data work, and you want to know that before signing anything.
- Expose those records through your own layer instead of wiring the agent to each system separately. The day you swap model or framework, the layer stays.
- Launch read only, with narrow permissions and a log of every query. Add write access once the team knows which cases escalate to a person and which close on their own.
A prototype like this fits in weeks. RavenDB puts a typical in-house AI stack at 18 to 24 months of build time, and no steering committee survives that timeline.
At Luxion we build assistants wired to systems that already run, like the one we shipped for BigBuy, and we start with the case that takes the least effort and shows up fastest. You see the prototype working before you commit a budget.