AI-native data integration without an ontology

Kadhir Mani argues that AI-native data integration can eliminate the need for traditional ontologies, which have historically required slow, rigid ETL jobs that lock clients out of self-service expansion. Mani claims AI changes the equation by enabling direct querying and cross-comparison of disparate data without a predefined schema, reducing dependency on forward-deployed engineering and client churn.

AI-Native Data Integration Without An Ontology by Kadhir Mani 4.1 minutes <section data-section-id='9f131f90-28a4-4606-a2ff-12d67b3f021c' <h2 id="data-integration-amp-ontology" <span style="white-space: pre-wrap;" Data Integration & Ontology</span </h2 <p <span style="white-space: pre-wrap;" Every data integration effort pulling data from external systems into one unified system has historically required an </span <b <strong style="white-space: pre-wrap;" ontology</strong </b <span style="white-space: pre-wrap;" : a structured layer that gives disparate data a common shape and meaning.</span </p <p <br </p <p <span style="white-space: pre-wrap;" The core pattern is an </span <b <strong style="white-space: pre-wrap;" ETL job</strong </b <span style="white-space: pre-wrap;" that takes structured and unstructured data from an external source and pipes it into a structured system a database .</span </p <p <br </p <p <span style="white-space: pre-wrap;" The purpose is almost always the same: enabling </span <b <strong style="white-space: pre-wrap;" cross-comparison between two different types of data</strong </b <span style="white-space: pre-wrap;" that would otherwise sit isolated in their own buckets.</span </p <p <br </p </section <section data-section-id='e1fb7e1e-0b5c-4eb0-a2b4-b2131514425d' <h2 id="the-downside" <span style="white-space: pre-wrap;" The Downside</span </h2 <p <span style="white-space: pre-wrap;" Ontology-first integrations have three recurring costs: they are slow to build, they lock clients out of their own system, and they never deliver true self-service expansion.</span </p <p <collapsible-card data-icon="clipboard" data-title="Time-consuming mapping" data-status="SLOW" data-status-color=" F59E0B" data-default-collapsed="true" <p <span style="white-space: pre-wrap;" The client is the expert on how their own systems work, and the integrator is the expert on the target system. Closing that gap means deeply learning the client's processes, mapping them into a series of schemas and objects, and only then starting the ETL build. That discovery-and-mapping cycle is slow, and it repeats for every new client.</span </p </collapsible-card </p <collapsible-card data-icon="alert-triangle" data-title="No self-service adjustment" data-status="RIGID" data-status-color=" EF4444" data-default-collapsed="true" <p <span style="white-space: pre-wrap;" Clients rarely understand the ontology layer they're running on. When their business processes inevitably change, they can't modify the system themselves and must request more forward-deployed engineering time.</span </p </collapsible-card <collapsible-card data-icon="info" data-title="Narrow, tailored fit" data-status="LIMITED" data-default-collapsed="true" <p <span style="white-space: pre-wrap;" Because the system is built to support only the few use cases identified during integration, it's heavily customized to those cases rather than being genuinely self-service — clients can't ask new, complicated questions on their own.</span </p </collapsible-card <p <br </p <p <span style="white-space: pre-wrap;" In our experience, this dependency on repeated forward-deploy support is a key driver of client churn once business processes inevitably shift.</span </p <p <br </p <p <span style="white-space: pre-wrap;" Stepping back, the real question we've been asking is why an ontology is needed at all. It's typically to power a custom UI or query data in a fast, specific way, and the only mechanism we knew to do that was to load everything into a database with a schema.</span </p <p <br </p <p <span style="white-space: pre-wrap;" But we think AI has changed that equation.</span </p <p <br </p </section <section data-section-id='a1ec33fd-f9c2-4a2d-86c8-c40960154946' <h2 id="the-problem-we-set-out-to-solve" <span style="white-space: pre-wrap;" The Problem We Set Out to Solve</span </h2 <p <span style="white-space: pre-wrap;" We stumbled onto this problem while working on something else entirely.</span </p <p <br </p <p <span style="white-space: pre-wrap;" We originally set out to rethink AI-native SDLC, focused on collaboration and communication for this new era. But wherever we looked, we kept running into the same wall, over and over: people needed access to the knowledge.</span </p <p <br </p <p <span style="white-space: pre-wrap;" We've seen a lot of setups now to tackle this. Some orgs continue to rely on the human-driven process, usually through meetings and chat. Other more AI-forward organizations have a pile of MCP servers and a process for each person to get access to all the accounts they need to make it work. Though more and more of them are realizing that new user onboarding, latency, cost, and query quality are becoming real issues.</span </p <p <br </p <p <span style="white-space: pre-wrap;" As we kept staring at this problem, we realized we already had a solution, one that we were using internally.</span </p <p <br </p </section <section data-section-id='de398f16-dfdb-4dd1-98ea-36c22ee6c670' <h2 id="data-integration-without-an-ontology" <span style="white-space: pre-wrap;" Data Integration Without an Ontology</span </h2 <p <span style="white-space: pre-wrap;" Months of fixing and augmenting collaboration and communication led to a discovery: our docs layer was fantastic at storing knowledge in a format agents, humans, and graphs could understand natively.</span </p <p <br </p <p <span style="white-space: pre-wrap;" We were already using it to sync our GitHub regularly so our agents could easily answer questions, particularly helpful for answering questions from our auditors about compliance.</span </p <p <br </p <p <span style="white-space: pre-wrap;" So we ended up doubling down on that. Here's how our ontology-less data integration works:</span </p <ul <li value="1" <b <strong style="white-space: pre-wrap;" Continuous ingestion</strong </b <span style="white-space: pre-wrap;" — systems pull data from external sources on an ongoing basis</span </li <li value="2" <b <strong style="white-space: pre-wrap;" Living documents</strong </b <span style="white-space: pre-wrap;" — the pulled data goes through one of our agent harness layers, updating docs with the new content</span </li <li value="3" <b <strong style="white-space: pre-wrap;" Careful versioning</strong </b <span style="white-space: pre-wrap;" — every document change is tracked, preserving history as data evolves</span </li <li value="4" <b <strong style="white-space: pre-wrap;" Agent-managed pruning</strong </b <span style="white-space: pre-wrap;" — agents constantly prune and manage content, removing what's outdated, reorganizing as required</span </li <li value="5" <b <strong style="white-space: pre-wrap;" Deep graph structure</strong </b <span style="white-space: pre-wrap;" — a deep graph underlies all the documents, making it lightning fast to query across them</span </li </ul <p <br </p </section <section data-section-id='38a33820-e149-4a31-9829-afec674ecaa4' <h2 id="the-results" <span style="white-space: pre-wrap;" The Results</span </h2 <p <span style="white-space: pre-wrap;" At our core, we have a carefully designed underlying data model that allows agents, humans, and our graph to read, write, and reason over at once, without translation layers.</span </p <p <br </p <p <span style="white-space: pre-wrap;" That results in:</span </p <ul <li value="1" <b <strong style="white-space: pre-wrap;" Cheaper, AI-native retrieval.</strong </b <span style="white-space: pre-wrap;" We pre-process and index at write time, so retrieval is a fast database lookup instead of an LLM call. At scale, that's the difference in economics.</span </li <li value="2" <b <strong style="white-space: pre-wrap;" Integrations in 24 hours, not months.</strong </b <span style="white-space: pre-wrap;" No ontology to design, no schema workshop. A new source goes from zero to queryable in a day.</span </li <li value="3" <b <strong style="white-space: pre-wrap;" Enterprise trust from the ground up.</strong </b <span style="white-space: pre-wrap;" Access controls, security, compliance, and real-time collaboration are built in, not bolted on later.</span </li <li value="4" <b <strong style="white-space: pre-wrap;" It meets you where you work.</strong </b <span style="white-space: pre-wrap;" Through MCP, messaging, and meetings, answers show up without anyone opening the app.</span </li <li value="5" <b <strong style="white-space: pre-wrap;" Versioned and linked like code.</strong </b <span style="white-space: pre-wrap;" Every piece of knowledge tracks its history and its relationships, so agents can query a point in time or follow a dependency.</span </li <li value="6" <b <strong style="white-space: pre-wrap;" Familiar primitives, universal adoption.</strong </b <span style="white-space: pre-wrap;" It's all just docs, so every team can use it, not just the one that owns the system.</span </li <li value="7" <b <strong style="white-space: pre-wrap;" Onboarding gets easier as we grow.</strong </b <span style="white-space: pre-wrap;" One account, one integration. Every new source we add becomes available automatically.</span </li </ul <p <br </p <p <span style="white-space: pre-wrap;" Together, these are why onboarding, cost, latency, and quality all move in the right direction at once: it's the same graph layer and the same format doing the work each time, not four separate fixes.</span </p <p <br </p </section