Qlik's 2025 agentic AI study, run by Enterprise Technology Research, found that 97% of large enterprises had committed budget to agentic AI. Thirty-nine percent were planning to spend a million dollars or more.
Eighteen percent had fully deployed anything. Forty-six percent said scale was three to five years away.
Money is not the constraint. That should be clarifying, because it eliminates the explanation most vendors are selling against and most boards are asking about. Something else is holding these projects still, and it is expensive enough to absorb a million dollars without producing a deployment.
Two blockers that are one blocker
Anthropic's 2026 enterprise research puts numbers on what leaders say is in the way: integration with existing systems (46%), data access and quality (42%), and change management (39%).
The first two are usually reported as separate items on a list. They are not separate. They are the same problem described from two directions — once by the engineer who can't get a clean read, and once by the business owner who can't vouch for what the read returns.
And "integration" is doing an enormous amount of quiet work in that sentence. It sounds like a connector problem: this system speaks REST, that one speaks SOAP, somebody writes a middleware layer, done. If that were the actual problem, a million dollars and three months would fix it. It isn't, which is why they haven't.
What "integration" usually means
Ask the person who does the job — not the system owner, the person who does the job — what they actually do when they need a customer's current status. You will very often get an answer shaped like this:
"The CRM says one thing, but the status field hasn't been reliable since we migrated, so I check the shared sheet Priya maintains, and if it's a large account I message the account manager because the sheet lags by about a week."
That is not a data quality problem in the abstract. That is a functioning, load-bearing business process. It has a routing rule, a fallback, an escalation path and a service level. None of it is written down anywhere. It exists entirely in one person's judgement, and it works.
Every established company runs on some volume of this. Humans are extraordinary middleware: they absorb schema drift, reconcile contradictory sources, apply undocumented business rules, and route around broken systems silently and without a ticket. Because it's silent, it never appears in a systems diagram, never gets a line in a budget, and never shows up in the risk register.
Then a project arrives to automate the workflow, and the agent is pointed at the CRM — because the CRM is the system of record, and the org chart says so.
Why this bites AI specifically
Previous waves of automation ran into the same wall and got past it by cheating. A rules engine, an RPA bot, a report — these could all be scoped narrowly enough to sit inside a single system's worldview. If the data was bad, the output was bad in a predictable, boring way that a human downstream would catch and correct, restoring the compensation layer at a slightly different point in the process.
An agentic system doesn't behave that way, for two reasons.
It spans systems by design. That's the entire proposition — the reason you want an agent instead of a macro is that the work crosses four tools and a judgement call. Crossing systems is precisely where the undocumented reconciliation lives, so the agent lands directly on top of the thing nobody wrote down.
And it acts rather than reports. A wrong number in a dashboard is a wrong number in a dashboard. A wrong number that triggers a credit decision, a dispatch, or an email to a customer is an incident. The compensation layer used to sit between the bad data and the consequence. Automating the workflow removes the human from exactly that position while leaving the bad data in place.
This is why so many teams report that the pilot worked and the rollout didn't. The pilot ran on a curated extract, on accounts somebody had already cleaned, with an engineer watching. All three of those are the compensation layer in disguise.
What actually moves this
Map the workarounds before you map the systems. Interview the doers, not the system owners. The question is not "where does this data live" but "what do you do when the system is wrong, and how often is that?" Two days of this will change which project you fund. It is the highest-return work available in an AI programme and almost nobody does it, because it looks like it isn't building anything.
Choose the first workflow by data authority, not by ROI. The standard selection criterion is business impact, which reliably points at the messiest, most cross-functional, most politically contested process in the company. Pick instead a workflow where one system genuinely is authoritative and one named person can vouch for the fields. A smaller win that ships teaches the organisation how to do the next one. A large win that stalls teaches it that AI doesn't work here.
Fund the data work inside the AI project, not before it. This is the structural reason 46% of respondents said scale was three to five years out. Data remediation framed as a prerequisite is a cost centre with no demo, and prerequisite projects do not get funded — they get acknowledged. Framed as the first phase of a project with a named business outcome, the same work gets money in a fortnight. Same work. Different sentence.
Name owners at field level, not system level. "IT owns the CRM" is not ownership of anything that matters here. Somebody has to be accountable for whether this specific field is correct, and that person is almost always in the business, not in IT. Until each field the agent reads or writes has such a person, you don't have an integration; you have a hope with an API key.
The one-page selection test
Score each candidate workflow before you pick one. One point per yes.
One system is genuinely authoritative for the key fields | ☐ |
A named business person will vouch for those fields today | ☐ |
The doers describe no routine workaround for this data | ☐ |
Exceptions already have a documented destination | ☐ |
The write target is a system whose data owner has been consulted | ☐ |
Volume is high enough that a 5% error rate is measurable in a month | ☐ |
Someone will notice within a day if the output goes wrong | ☐ |
6–7: start here. 4–5: viable, budget for the data work explicitly. Below 4: this is a data ownership project. Run it as one, with an AI outcome attached, and stop calling it an integration.
The order that matters
The same study found that 69% of enterprises had a formal AI strategy while only 19% had a defined framework for measuring return. Those two numbers arriving in that order is a problem with a schedule attached: the ROI question turns up on a board calendar, and the plumbing is the thing that makes ROI measurable in the first place. Teams that defer the data work to look fast end up unable to answer the question that decides whether the programme continues.
Only 42% said they were confident in their internal expertise. That is worth reading not as a skills gap but as an accuracy gap — because the people who understand their own data best are usually the ones least confident that it's ready, and they are usually right.
At SymenticTech we start AI projects by finding the workarounds, because that's where the cost actually is. If you have a funded initiative that hasn't moved, we're happy to look at which workflow you should have picked.
