How Does a Semantic Layer Unlock Your Data for Agentic AI
Yuri Pontes | Jul 20, 2026
Summary
- AI implementation failures typically stem from data quality, fragmented systems, and process issues rather than model selection, with 77% of enterprise AI deployments studied by Stanford's Digital Economy Lab facing these challenges Compliance, legacy system mapping, and workflow documentation must be addressed architecturally from the start rather than retrofitted later, as early infrastructure decisions in week one create a ceiling for everything that follows Most AI initiatives fail in the gap between demo and production, since demos use clean sample data while production involves real data, real users, and unanticipated failure modes The core lessons—diagnose before building, map before automating, architect before deploying—apply consistently across regulated and data-heavy industries including fintech, energy, manufacturing, and logistics
There is a version of the AI story the technology industry tells very well. New model. New benchmark. New capability that was not possible six months ago. The rate of change is real. The progress is documented.
The version that does not get told as often happens at month 8 — when a mid-market company discovers that the data it needed is split across four systems, two with no API, and one still running on a server in a closet in the Chicago office.
We have fixed that problem across payments companies, financial advisors, energy grid operators, field service businesses, industrial manufacturers, and logistics platforms. Across twelve years and projects on four continents. Technology changes. The infrastructure problem underneath it does not.
What follows is what we have learned specifically — the things that separate AI implementations that run in production from the ones that produce impressive demos and very little else. Every lesson here came from a room like that one in Chicago.
Where we have seen this
Our work spans payments, financial services, energy, industrial operations, IoT, and logistics. The industries are different. The data problems are remarkably consistent. Below is a representative sample of the work that informs the lessons in this article.
| Client | What we built | Why it was harder than it looked |
| MoneyGram Payments / Fintech | Cross-border payment infrastructure and digital customer experience in a regulated, multi-currency environment. | Payment data compliance requirements vary by jurisdiction. The integration layer had to be built for 200+ regulatory environments simultaneously. |
| AES Corporation Energy / Utilities | Grid intelligence platform for a Fortune 500 energy company. Virtual power plant infrastructure and real-time operational data systems. | Utility-grade reliability requirements leave no margin for data pipeline failures. Infrastructure had to be built for 99.99% uptime from day one, not retrofitted later. |
| Knapsack AI / Fintech | AI platform built specifically for strict financial compliance environments. Auditability, explainability, and regulatory traceability built into the architecture. | Standard AI deployment frameworks assume flexibility. Financial compliance requires determinism. Every model output needed an auditable reason. |
| Camio AI / Industrial | AI-powered video surveillance and event detection system processing 4 million+ events per day across commercial and industrial environments. | Real-time AI inference at this scale requires edge architecture decisions made in week one. Retrofitting edge compute after the fact is effectively a rebuild. |
| Birdnest Field Operations / Industrial | Field operations platform for water and wastewater utilities. Technician routing, work order management, and compliance reporting. | Utility field operations have regulatory reporting requirements that interact with every workflow. The compliance layer had to be designed into the data model, not added afterward. |
| Bemis Manufacturing | End-to-end software delivery for a mid-market manufacturing client. Full engagement from discovery through production deployment. | Manufacturing data lives at the intersection of OT (operational technology) and IT systems that were never designed to communicate. The integration challenge was the project, not an obstacle to it. |
These are not AI-hype projects. They are operational systems that run in production, process real transactions, serve real customers, and carry real consequences if they fail. That context is where the lessons come from.
Six things we have learned that most firms get wrong
1 – The failure is almost never the model. It is the data underneath it
In 77% of enterprise AI deployments studied by Stanford’s Digital Economy Lab, the hardest challenges were data quality, process redesign, and change management — not model selection. We see this consistently.
The model chosen at the start of a project rarely determines whether the project succeeds. The state of the data that feeds it almost always does.
A company with clean, centralized, queryable data and a mediocre model will outperform a company with fragmented, siloed data and access to the best model in the world. Every time. The diagnostic has to start with data, not with model evaluation.
2 – Compliance is an architectural decision you make at the beginning
This is the lesson that regulated industries teach most harshly. Financial services, energy, healthcare, legal — in every one of these sectors, there are compliance requirements that interact with the data model, the API layer, the audit trail, and the user interface.
When teams treat compliance as a final review step rather than a design constraint, they build systems that have to be substantially rebuilt when the compliance review reveals what should have been obvious from day one. We build compliance into the architecture from the first sprint. It costs more upfront and far less overall.
3 – Legacy systems are not the problem, Unmapped legacy systems are
Every mid-market company we have worked with in the last twelve years has legacy systems. The ones that succeed with AI are not the ones that replaced everything before they started — almost no company can afford that. They are the ones that mapped their legacy landscape honestly before they built anything new.
Which systems contain which data. Which systems have APIs and which do not. Which can be integrated and which have to be replaced. Which data is clean and which requires transformation before it can be used.
This map does not exist in most mid-market companies when we arrive. Building it is the first real deliverable of any serious AI engagement.
4 – Workflows have to be mapped before they can be automated
The most common source of failed AI automation projects is automating what people say they do rather than what they actually do. These are different things. The stated workflow is the one in the process documentation.
The actual workflow is the one that involves the spreadsheet someone built three years ago that everyone uses and nobody talks about, the email chain that substitutes for a system that was never built, and the five manual steps that happen between the ERP entry and the customer notification.
AI automation built on the stated workflow breaks immediately when it meets reality. We map the actual workflow, including the exceptions, the workarounds, and the human judgment calls, before we write a line of automation logic.
5 – Infrastructure decisions made in week one create the ceiling for everything that follows
In AI implementation, early architecture decisions compound in both directions. A well-chosen data architecture makes every subsequent feature easier to build.
A poorly chosen one creates friction that accumulates with every sprint. The teams that skip the infrastructure design phase to get to the interesting AI work faster are the ones that spend months six through eighteen paying down technical debt that was entirely predictable.
We have learned to be slow about architecture and fast about everything else. The time invested in week one is recovered many times over by month six.
6 – The gap between a demo and production is where most AI initiatives die
A demo is a proof of concept built with clean sample data, a controlled environment, and no edge cases. Production is a system that runs with real data, real users, real volume, and failure modes that nobody anticipated.
The distance between those two things is where most AI initiatives fail — not because the concept was wrong, but because the path from concept to production was never engineered. We have seen this in payments, energy, and manufacturing.
Building for production from the first sprint rather than retrofitting a demo after the fact is the discipline that separates implementations that actually ship from those that do not.
What this means for mid-market companies pursuing AI in 2026
The AI market in 2026 is producing an enormous volume of confident-sounding advice about how to implement AI. Most of it is directionally correct and operationally incomplete. It tells you what to do. It rarely tells you what is true about your specific infrastructure, your specific data, and your specific workflow complexity before you try to do it.
“The companies that collect the value from AI are not the ones with the best model. They are the ones who did the foundational work before they deployed it.”
The six lessons above are not exclusive to the industries we have worked in. They apply to any mid-market company in any regulated or data-heavy sector attempting to implement AI in a meaningful way. The industries differ. The underlying pattern does not.
What changes by industry is the specific compliance environment, the legacy system landscape, and the workflow complexity. What does not change is the sequence: diagnose before you build, map before you automate, architect before you deploy.
| What transfers across industries |
| Fintech → Manufacturing — Compliance-aware architecture design, data model discipline, and audit trail requirements are structurally identical. The regulation is different; the design pattern is the same. |
| Energy → Industrial operations — High-reliability infrastructure requirements, edge compute architecture, and operational technology integration challenges translate directly between grid operations and industrial manufacturing systems. |
| Payments → Logistics — Multi-party data reconciliation, real-time processing requirements, and exception handling logic built for payment networks apply directly to supply chain event management. |
| Field service → Manufacturing — Work order management, technician routing, compliance reporting, and IoT sensor data integration are structural parallels regardless of whether the field is wastewater utilities or industrial equipment maintenance. |
An honest note about where we are
We are not claiming to have all of this perfectly figured out. The AI landscape is moving faster than any firm’s internal capability can fully track, including ours. What we can claim is twelve years of delivery in environments where the stakes were real, the data was genuinely messy, and shipping something that did not work was not an acceptable outcome.
Half of our engineering team has hands-on LLM integration experience. We have staff-level AI architects. We have production systems running in financial services, energy, and field operations environments. We have data platform relationships with Snowflake, Databricks, and DBT Labs. We know what the infrastructure underneath Artificial Intelligence needs to look like because we have built it repeatedly in environments that could not afford to get it wrong.
What we have learned most fundamentally is this: the companies that succeed with AI are not the ones who moved first. They are the ones who diagnosed honestly before they built, mapped carefully before they automated, and chose implementation partners who had been in the room when the infrastructure problem was real — not just when the demo looked clean.
The best AI strategy starts with an honest answer to the question: what is actually true about our data, our systems, and our workflows right now?
If you do not yet have that answer, the AI strategy can wait. The diagnostic cannot.
FAQ
What is the most common reason AI implementations fail?
The failure is almost never the model itself. In 77% of enterprise AI deployments studied by Stanford's Digital Economy Lab, the hardest challenges were data quality, process redesign, and change management, not model selection. A company with clean, centralized, queryable data and a mediocre model will outperform a company with fragmented, siloed data and access to the best model in the world.
When should compliance be addressed in an AI project?
Compliance should be an architectural decision made at the beginning, not a constraint added at the end. Compliance requirements interact with the data model, API layer, audit trail, and user interface. Treating compliance as a final review step leads to systems that must be substantially rebuilt when the review reveals issues that should have been addressed from day one.
How should legacy systems be handled before building AI solutions?
Legacy systems themselves are not the problem; unmapped legacy systems are. Companies that succeed with AI map their legacy landscape honestly before building anything new, identifying which systems contain which data, which have APIs, which can be integrated, which must be replaced, and which data requires transformation. Building this map is the first real deliverable of any serious AI engagement.
Why do AI automation projects often break after deployment?
AI automation projects commonly fail because they automate the stated workflow from process documentation rather than the actual workflow, which includes spreadsheets, email chains, manual steps, and workarounds that people actually use. Mapping the actual workflow, including exceptions and human judgment calls, before writing automation logic is necessary to avoid this failure.
What separates a working AI demo from a production-ready AI system?
A demo is built with clean sample data, a controlled environment, and no edge cases, while production involves real data, real users, real volume, and unanticipated failure modes. Most AI initiatives fail in the gap between demo and production because the path to production was never engineered from the start, rather than because the underlying concept was wrong.
About the author.
