AI-Native Data Integration Without An Ontology

Kadhir Mani

(4.1 minutes)

<section data-section-id='9f131f90-28a4-4606-a2ff-12d67b3f021c'><h2 id="data-integration-amp-ontology">Data Integration & Ontology</h2>Every data integration effort (pulling data from external systems into one unified system) has historically required an ontology: a structured layer that gives disparate data a common shape and meaning. The core pattern is an ETL job that takes structured and unstructured data from an external source and pipes it into a structured system (a database). The purpose is almost always the same: enabling cross-comparison between two different types of data that would otherwise sit isolated in their own buckets. </section> <section data-section-id='e1fb7e1e-0b5c-4eb0-a2b4-b2131514425d'><h2 id="the-downside">The Downside</h2>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.<collapsible-card data-icon="clipboard" data-title="Time-consuming mapping" data-status="SLOW" data-status-color="#F59E0B" data-default-collapsed="true">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.</collapsible-card><collapsible-card data-icon="alert-triangle" data-title="No self-service adjustment" data-status="RIGID" data-status-color="#EF4444" data-default-collapsed="true">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.</collapsible-card><collapsible-card data-icon="info" data-title="Narrow, tailored fit" data-status="LIMITED" data-default-collapsed="true">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.</collapsible-card> In our experience, this dependency on repeated forward-deploy support is a key driver of client churn once business processes inevitably shift. 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. But we think AI has changed that equation. </section> <section data-section-id='a1ec33fd-f9c2-4a2d-86c8-c40960154946'><h2 id="the-problem-we-set-out-to-solve">The Problem We Set Out to Solve</h2>We stumbled onto this problem while working on something else entirely. 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. 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. As we kept staring at this problem, we realized we already had a solution, one that we were using internally. </section> <section data-section-id='de398f16-dfdb-4dd1-98ea-36c22ee6c670'><h2 id="data-integration-without-an-ontology">Data Integration Without an Ontology</h2>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. 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. So we ended up doubling down on that. Here's how our ontology-less data integration works:<ul><li value="1">Continuous ingestion — systems pull data from external sources on an ongoing basis</li><li value="2">Living documents — the pulled data goes through one of our agent harness layers, updating docs with the new content</li><li value="3">Careful versioning — every document change is tracked, preserving history as data evolves</li><li value="4">Agent-managed pruning — agents constantly prune and manage content, removing what's outdated, reorganizing as required</li><li value="5">Deep graph structure — a deep graph underlies all the documents, making it lightning fast to query across them</li></ul> </section> <section data-section-id='38a33820-e149-4a31-9829-afec674ecaa4'><h2 id="the-results">The Results</h2>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. That results in:<ul><li value="1">Cheaper, AI-native retrieval. 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.</li><li value="2">Integrations in 24 hours, not months. No ontology to design, no schema workshop. A new source goes from zero to queryable in a day.</li><li value="3">Enterprise trust from the ground up. Access controls, security, compliance, and real-time collaboration are built in, not bolted on later.</li><li value="4">It meets you where you work. Through MCP, messaging, and meetings, answers show up without anyone opening the app.</li><li value="5">Versioned and linked like code. Every piece of knowledge tracks its history and its relationships, so agents can query a point in time or follow a dependency.</li><li value="6">Familiar primitives, universal adoption. It's all just docs, so every team can use it, not just the one that owns the system.</li><li value="7">Onboarding gets easier as we grow. One account, one integration. Every new source we add becomes available automatically.</li></ul> 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. </section>

Published

August 3, 2026

Keep reading

What is a knowledge warehouse

Organizational knowledge has no authoritative home, so the same questions get re-answered, re-discovered, and re-explained by the people who can least afford the interruption. Naming the category: what a knowledge warehouse is, the five attributes that define one, and why AI coding agents make it urgent now.

Storing prototypes in the warehouse from external tools

An explanation of how we store external prototypes in the warehouse and what it took to get there.

CRDTs are not enough when your co-worker is an AI agent

CRDTs converge; they do not coordinate. That distinction becomes critical the moment an AI agent joins the editor. Why multiplayer collaboration needs a coordination layer above merge, and the section-level lease protocol we built to keep agents well-mannered.