The real gap in enterprise AI isn’t who has access to models. It’s who has learned how to build retrieval, evaluation, memory, and governance into boring, repeatable systems. Credit: Yatzek Photography/Shutterstock This week in New York, my Oracle team ran workshops for enterprise developers on building retrieval-augmented generation and agentic applications. Interest was so strong that we quickly had to figure out how to double the room’s capacity (much to the fire marshal’s chagrin). Interest in AI was clearly off the charts. But AI fluency was not. It was a different vibe (and audience) from what we’ve seen in a course we built with DeepLearning.ai, which attracts a more advanced audience ready to build memory-aware agents. I recently argued that enterprise AI is arriving unevenly across companies and even across teams within the same company. But after watching developers plow through these different workshops, I believe this uneven adoption points to something even more telling: uneven engineering capability. Put differently, the real divide in enterprise AI isn’t just between companies moving fast and companies moving slow. It’s between teams treating AI as a prompt-driven demo and teams learning, often painfully, that production AI is mostly a data and software engineering problem. Enterprise AI isn’t really in the agent era yet. We’re in the prerequisite era. Building the building blocks What do I mean by “engineering capability”? I definitely don’t mean model access. Most everyone has that—or soon will. No, I mean the practical disciplines that turn a model into a system: data modeling, retrieval, evaluation, permissions, observability, and memory. You know, the unsexy, “boring” stuff that makes enterprise projects, particularly enterprise AI projects, succeed. This informed how my team built our workshops. We didn’t start with “here’s how to build an autonomous employee.” We started with the AI data layer: heterogeneous data, multiple representations, embeddings, vector indexes, hybrid retrieval, and the trade-offs among different data types (relational, document, etc.). In other words, we started with the stuff most AI marketing tries to skip. Much of the AI world seems to think AI starts with a prompt when it actually begins with things like multimodel schema design, vector generation, indexing, and hybrid retrieval. That matters because enterprise data isn’t tidy. It lives in tables, PDFs, tickets, dashboards, row-level policies, and 20 years of organizational improvisation. If you don’t know how to model that mess for retrieval, you won’t have enterprise AI. You’ll simply achieve a polished autocomplete system. As I’ve pointed out, the hard part isn’t getting a model to sound smart. It’s getting it to work inside the weird, company-specific reality where actual decisions are made. For example, the industry talks about retrieval-augmented generation as if it were a feature. It’s not. It’s an engineering discipline. Chunking strategy, metadata design, retrieval quality, context packing, precision and recall, correctness and relevance: those aren’t implementation details to clean up later. They’re the thing. The whole point. If your retriever is weak, your model will confidently elaborate on bad context. If your chunking is sloppy, your answer quality degrades before the model ever starts reasoning. If your metadata is thin, filtering breaks. And if you have no evaluation loop, you won’t know any of this until a user tells you the system is wrong. This is also where permissions and observability are so critical. In a demo, nobody asks the annoying questions like where an answer came from, or what the agent was authorized to touch. But in real-world production, those questions are the whole game. An enterprise agent with vague tool access isn’t sophisticated. It’s a massive security problem. In short, using AI tools is not the same thing as knowing how to build AI systems. Plenty of teams can prompt, but far fewer can measure retrieval quality, debug context assembly, define tool boundaries, or create feedback loops that improve the system. Catching up with the enterprise The contrast with the recent DeepLearning.AI short course on agent memory is useful here. That course is explicitly aimed at developers who want to go beyond single-session interactions, and it assumes familiarity with Python and basic concepts of large language models. In other words, that audience is already up the curve, talking about memory-aware agents as a next step. By contrast, my NYC enterprise-heavy audience was generally earlier in the journey. That’s not a criticism of enterprise developers. It’s a clue. Much of the “AI gap” in enterprise isn’t about willingness. It’s about how much explicit learning the teams still need before the tools become muscle memory. That, in turn, is why I keep coming back to a much older argument I’ve made about MLops. Back then, I wrote that machine learning gets hard the moment it leaves the notebook and enters the world of tools, integration, and operations. That was true in 2022, and it’s even more true now. Agentic AI has not repealed the basic law of enterprise software. It has simply added more moving parts and a bigger blast radius. The demo may be easier than ever, but the system is emphatically not. I’d also caution that you probably shouldn’t tell enterprises they’re “behind” because they haven’t yet embraced multi-agent architectures or whatever the current fashion demands. In many cases, they’re learning exactly what they need to know: how to structure data for retrieval, how to evaluate outputs, how to constrain tools, how to inspect failures, and how to manage state. That may not make for sexy conference talks. It does, however, look suspiciously like how real platforms get built. As I’ve noted, most teams don’t need more architectural cleverness but do need much more engineering discipline. So yes, uneven adoption is still a real thing. But I think the deeper, more useful story is this: Uneven adoption is mostly the surface expression of uneven AI engineering literacy. The real winners in AI will be those that teach their teams how to ground models in business data, evaluate what those models return, constrain what agents can do, and remember only what matters. That is, the winners will be those that know how to make AI boring. Right now, boring is still very unevenly distributed. Artificial IntelligenceData EngineeringAnalyticsCareersPythonProgramming LanguagesSoftware Development