Jakki Geiger, CMO at Arango in conversation with
Ravi Marwaha, Chief Product & Technology Officer at Arango
TL;DR
Graph and vector databases are both critical to modern AI—but enterprise systems break down when they live in isolation. When meaning, relationships, time, and trust are fragmented across separate graph, vector, and operational stores, AI applications are forced to reconstruct business context at query time. Each agent or co-pilot ends up operating with its own incomplete, inconsistent view of reality. As data evolves and workloads scale, this runtime reconstruction becomes brittle. Managing context as a unified layer is what enables durable reasoning, explainable outcomes, and safe, governed action in production AI.
Jakki: Many enterprise teams are combining graph databases and vector search for AI—sometimes starting with graph, sometimes with vector. Why isn’t that combination enough?
Ravi: Combining graph and vector is a strong starting point—but it’s still not enough on its own.
In most data architectures, graph and vector live in separate systems. Relationships are modeled in one place, embeddings are stored in another, and operational state, documents, and logs live somewhere else. That means every AI system has to reconstruct business context at runtime. That approach works for prototypes, but it breaks down in production.
Multimodel data platforms provide unified business context, cross-model reasoning, and built-in governance to support agentic AI beyond vector and graph silos.
As business context is reconstructed across multiple systems at runtime, latency becomes unavoidable. Each cross-system call adds delay, making real-time reasoning and decision-making increasingly difficult as AI moves into production.
Business context reconstruction gets duplicated across agents and co-pilots, drifts over time, and becomes increasingly fragile as data changes and use cases grow. The missing layer isn’t another database—it’s a shared business context layer that unifies meaning, relationships, time, and trust so every AI system operates on the same version of reality in production.
Why Graph + Vector Still Isn’t Enough
Jakki: But graph databases already model relationships. Isn’t that business context?
Ravi: Modeling relationships is a critical step — it’s how AI moves beyond isolated documents and records and begins to reflect how a business actually operates.
But in production, relationships alone aren’t enough. They help AI explain how things connect, but enterprise data systems also need to understand what is true now, what was true when, and why information can be trusted before agents can take action.
That’s the difference between explaining how things are connected and enabling AI to make reliable, explainable decisions as data and operations change.
Forrester on Multimodel Data Platforms
Read how analysts assess multimodel platforms as enterprises move beyond stitched-together graph and vector systems toward simpler, production-ready AI architectures.
For enterprise AI to work in production, systems need to understand:
- Meaning — shared semantics and definitions across teams
- Relationships — how customers, products, incidents, policies, and systems connect
- Time — what was true when, including change and current state
- Provenance and trust — where information came from and how it evolved
- Multimodal signals — text, code, logs, and media connected to the same context
- AI-ready delivery — retrieval, ranking, and citation that Enterprise AI can depend on
Graph databases are excellent at modeling relationships, but they’re not designed to unify all of these dimensions into a single, consistent view of the business. That’s why graph-centric architectures still struggle to support accurate, explainable, and trustworthy AI in production.
Jakki: Forrester’s The Multimodel Data Platforms Landscape, Q4 2025, led by Indranil Bandyopadhyay, highlights three takeaways:
- Stitched data architectures are brittle for AI,
- AI workloads require multiple data models, and
- Unified, current, and trusted business context is required for AI to reason and act.
How well does that align with what you’re hearing from AI and data leaders?
Ravi: It aligns almost perfectly. Teams know they need multiple data models, but most are still stitching systems together and reconstructing context at runtime.
That works early on, then breaks as AI moves into production.
What leaders consistently struggle with isn’t models — it’s getting a unified, current, and trusted view of the business that every agent and co-pilot can rely on. Until that context is shared and governed, AI remains brittle, no matter how advanced the models are.
Jakki: So if teams already use vectors for similarity and graphs for relationships, why does combining them across systems still fail at scale
Ravi: Because each approach solves a different problem — and neither solves business context on its own.
Vector search is great for similarity, but similarity alone can’t support reasoning, decisions, or action. It doesn’t understand entities, state, or what’s true right now.
Graphs add relationships, which is a big step forward, but relationships alone still don’t capture time, provenance, or trust — all of which matter once AI systems are making decisions, not just explanations.
When vectors and graphs live in separate systems, those gaps don’t disappear — they multiply. Every AI workflow has to perform business context reconstruction at runtime, stitching together similarity, relationships, and operational state on the fly — including reconciling which entities are correct and deciding what information can be trusted as data changes. That business context reconstruction gets duplicated across agents and pipelines, drifts over time, and shows up at scale as higher latency, inconsistent behavior, and increased risk.
Why Orchestration Breaks at Scale
Jakki: Isn’t this just an orchestration problem?
Ravi: That’s where most teams start — and where they get stuck.
Orchestration can connect systems, but it can’t create shared understanding. In practice, it pushes business logic into pipelines and application code, so every agent ends up reconstructing context slightly differently. That’s how Frankenstacks form — and why every new agent or workflow becomes another integration project.
A contextual data layer changes that by centralizing business context instead of wiring it together repeatedly. When agents operate on the same trusted foundation, complexity drops, answers stay consistent, and AI systems become much easier to evolve safely.
Search-centric architectures and Frankenstacks fragment business context, preventing AI systems from reasoning, deciding, and acting at scale.
Jakki: How does this affect AI agents and co-pilots specifically?
Ravi: Agents and co-pilots don’t just retrieve information — they decide, act, and are expected to deliver business outcomes.
Retrieval is about surfacing information, which works for insights. But decisions and actions require unified, current, and trusted business context. That distinction matters. Insight systems explain what happened. Agents have to reason over what’s true now, what rules apply, and whether the information they’re using can be trusted — before taking action.
That only works when structured, unstructured, and multimodal data are unified into the same business context. Otherwise, agents are forced to piece together state from different systems — customer data in one place, policies in another, conversations somewhere else, vectors elsewhere — and reconcile conflicts on the fly.
At small scale, that’s manageable. At production scale, it becomes slow, brittle, and inconsistent — exactly what you can’t afford when AI is making decisions, not just answering questions.
To act safely, agents need:
- Structured data for state and rules
- Unstructured data for human knowledge and intent
- Multimodal signals to explain what happened and why
Most importantly, all of it must be connected to the same underlying entities. Without that shared foundation, agents make decisions based on partial or outdated context — and that’s where risk shows up.
The Contextual Data Layer
Jakki: How do you define a contextual data layer?
Ravi: Check out my blog post on this topic:
The Missing Layer in Enterprise AI
Why a Contextual Data Layer Is Required for Trust, Scale, and Production
Enterprise AI Production Reality
As AI systems scale, fragmented data architectures add latency, drive up the cost of change, and fracture business context across applications and agents. That’s why many AI initiatives stall—not because models fail, but because the data foundation can’t keep up.
The Missing Layer in Enterprise AI
Why the contextual data layer is the missing foundation for enterprise AI at scale.
Graphs and vectors are essential tools—but enterprise AI succeeds in production only when they’re brought together through a unified contextual data layer.
— Ravi Marwaha, Chief Product & Technology Officer, Arango
Simplifying AI Data Architecture
Jakki: So how do teams actually move from Frankenstack architectures to something that works in production?
Ravi: They simplify their AI data architecture.
Most teams start by stitching together 15 or 20 steps—data ingestion, graph modeling, vector pipelines, orchestration, and application code—to reconstruct business context for every agent and workflow. That can work for pilots, but it’s brittle and expensive change and nearly impossible to scale reliably.
What works in production is introducing a contextual data layer that provides unified, current, and trusted business context — spanning meaning, relationships, time, and provenance. That shifts teams away from pipelines and toward three reusable architectural layers:
At the foundation, teams start with a Contextual Data Foundation that brings together graph, vector, document, key-value, and search data in a single multimodel system. Structured, unstructured, and multimodal data are unified without losing their native strengths, creating a durable base where business data lives consistently instead of being fragmented across systems.
On top of that, Contextual Operations turn this foundation into something that can run reliably in production. This layer provides the operational capabilities required to govern and manage business context at scale — including security and access control, versioning, observability, deployment flexibility, and fault tolerance — so context remains current, consistent, and dependable as data and workloads change.
Finally, Contextual Data for AI makes that governed context usable by AI systems. This layer connects data into shared business context AI can reason over — meaning, relationships, temporal state, provenance, and multimodal signals — and exposes it in AI-ready forms that support retrieval, ranking, reasoning, and citation. Because the same context is shared across agents and co-pilots, AI systems no longer need to reconstruct meaning at runtime.
Instead of rebuilding business context for every new use case, teams reuse the same trusted foundation and operational layer. That’s what keeps AI systems consistent, explainable, and reliable as they scale — and it’s the difference between an AI program that compounds value over time and one that resets with every new agent, workflow, or application.
An AI-ready data architecture unifies multimodal and multimodel data to deliver trusted, reusable business context for enterprise AI.
Jakki: Is this something every graph customer needs?
Ravi: No. If your main goal is relationship analysis or graph exploration, a standalone graph database is often sufficient.
But once you start using AI in production—where multiple data types, teams, and workflows must share the same unified, current, trusted context—the need shifts from “graph analytics” to managing business context as a unified layer, especially when outcomes carry real operational consequences.
Jakki: What does this change for organizations trying to scale AI?
Ravi: It changes whether AI consistently improves business outcomes—or creates operational risk.
With a contextual data layer, agents and co-pilots operate on a shared understanding of the business. That leads to faster resolution times, safer decisions, higher user trust, and lower operational overhead as AI expands across the organization.
Without it, teams rely on business conext reconstruction for every new use case. Accuracy degrades, trust erodes, and each new agent becomes another integration project—driving up cost, risk, and time-to-value.
For teams feeling this tension today, the challenge isn’t proving whether AI works—it’s whether the data foundation underneath is built for reliable, trusted, and scalable AI in production. In practice, that means investing in AI-ready data. Enterprise AI ultimately reflects the data strategy beneath it—when business context is fragmented across systems, AI outcomes fragment with it. When context is unified, results compound.
What’s Next?
The Definitive Guide to Agentic AI-Ready Data Architecture
If you’re actively designing or evolving your AI data stack, this guide breaks down the architectural decisions required to simplify complexity, avoid Frankenstacks, and scale AI with confidence.
Forrester on Multimodel Data Platforms
Read how analysts assess multimodel platforms as enterprises move beyond stitched-together graph and vector systems toward simpler, production-ready AI architectures.
Go Beyond Vector Databases
Start at the beginning to understand why retrieval-first approaches break down—and how the need for unified, current, and trusted business context reshapes the AI stack.
