Artificial Intelligence

AIOpen Source

How NTT DATA AIVista closes the last mile of agentic AI for enterprise agents

Presented by NTT DATA AIVista At VB Transform 2026 , NTT DATA AIVista CEO Bratin Saha joined VentureBeat CEO and editor-in-chief Matt Marshall to discuss the last-mile challenge of operationalizing frontier models in regulated production, where reliability, context, guardrails, and security determine whether AI delivers enterprise value. The conversation centered around the question facing every enterprise now pouring money into AI: how to convert that spending into real, tangible value. "It's not just a model, you're building a system around the model," Saha said. The last mile is the work of wrapping a frontier model in an enterprise's own data, workflows, and guardrails. In the end, regulated production turns on more than just technology, Saha said. Today, most enterprise AI projects fail during implementation because of poor integration, domain specialization gaps, lack of governance, and unclear ownership of outcomes. Last-mile specialization turns a capable foundation model into an enterprise agent shaped by domain-specific workflows, risk appetite, client classifications, regulatory interpretations, and institutional knowledge. Why frontier models stall in enterprise workflows Frontier models fall well short of production-grade accuracy on many real-world insurance workflows, Saha said, but last-mile specialization can lift them to the reliability enterprises need. Out of the box, those models struggle with the complexity of regulated workflows such as multinational insurance claims. "These forms are pretty complex, often have handwriting, lots of checkboxes, and so on," he said, and that complexity is why frontier models like Fable 5, Opus 4.8, and GPT-5.5 fall short out of the box. Saha said the biggest gains come from specializing the entire AI system, not just the foundation model. That system gets specialized with the customer's data, workflow and, in many cases, the tribal knowledge that never made it into an operating procedure document. "The biggest bang for the buck comes from the specialization and then these specialized guardrails," he said. The work has three components: capturing the enterprise’s context and making it consumable by AI running an ensemble of models so cost does not go through the roof and adding specialized guardrails that check the model and force a redo when it gets something wrong. What the last mile of agentic AI actually requires None of this involves fine-tuning. VentureBeat’s latest enterprise survey found it ranked last among companies’ model-selection priorities. Instead, the last mile centers on domain knowledge and undocumented workflows that companies would never expose publicly without losing their competitive edge. "The last mile is about taking data that's proprietary to you and using that to build a system around the model that can steer the model in the right way that can put the appropriate guardrails around it," Saha said. In the end, enterprise AI is about moving a workflow from point A to point B rather than deploying a technology, and NTT's advantage comes from pairing AI experts with subject domain experts. "The only reason is because we go and talk to those human workers and we say, 'How do you actually do the work,'" he said. That expertise is then encoded into an agent. Success in insurance, manufacturing, and other regulated industries relies on three things at once, he added. "You need technology, you need the domain expertise, and you need the change management expertise," he explained, adding that across his team's clients, technology is not the bottleneck. How enterprises turn AI investment into tangible value For enterprises weighing large AI budgets, Saha's said the payoff comes not from the model but from the work built around it. "When you're deploying AI in the enterprise, you're not deploying a technology," he said. "You are taking a workflow that exists and taking it from point A to point B." The value is created by the workflow that gets moved, not the model that helps move it. That reorders where money should go. "Technology is not the bottleneck," Saha said, pointing instead to the domain expertise and change management wrapped around the model, and to the discipline of commiting to all three together. Spending aimed only at the model leaves most of the return on the table. Enterprises don’t have to choose between embedding AI into existing workflows and redesigning those workflows from scratch. NTT sees the two as successive stages of the same journey. "We are starting with embedding in the workflow because it's easier change management," he said, noting that customers running mission-critical operations will not let a vendor rip out a working process midstream. "Once that happens, then we go into, how can we now reimagine this? And that really is where the biggest bang is." Where enterprise AI stays bespoke and where it becomes scalable Keeping intelligence in the surrounding system rather than the model also preserves swappability and lets enterprises take advantage of open-weight and open-source models as they mature. Saha’s team runs an ensemble that mixes frontier and open-source models, and he expects the industry to lean on open weights wherever the cost of a mistake is low while reserving frontier reasoning for the cases that demand it. "In many situations, especially in regulated industries where mistakes are very expensive, that last extra couple of percent matters," he said. The platform follows the same pattern: Guardrail generation and neurosymbolic models scale across customers, while capturing each organization’s tribal knowledge remains bespoke. Saha pointed to NTT DATA’s position as one of the world’s largest insurance third-party administrators as an advantage in acquiring that expertise. "The ability to take that knowledge and trust that has been built over 20 years is very hard to replicate instantly, and I do think that is a durable aspect of what we have," he said. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com .

VentureBeatAugust 3, 20265 min read

AIResearch

Stop graphing everything: When GraphRAG actually beats vector RAG

If you have built anything with retrieval-augmented generation (RAG) in the last two years, you have lived its central frustration: You chop your documents into chunks, embed them, retrieve the top few that look similar to the question, and hand them to the model. For “What was our Q3 refund policy?” This works beautifully. For “What are the recurring themes across two years of customer complaints?” it falls flat — because no single chunk contains the answer. The fashionable fix is GraphRAG : Instead of feeding the model isolated snippets, you first build a knowledge graph of the entities and relationships in your corpus, then use that structure as context. The pitch is seductive. But seductive pitches deserve scrutiny, so I went through the evidence — the original Microsoft paper plus four independent benchmark studies — to answer a simple question: When you swap text chunks for a context graph, do answers actually get better? The short version: Yes, substantially — but only for the right kind of question, and not for free. Let me show you the receipts. Why text chunks hit a wall Standard vector RAG retrieves the k passages most similar to your query. That design has three structural blind spots: It can’t connect the dots. When an answer requires joining facts that live in different passages through a shared entity, chunks embedded in isolation never reveal the link. It’s blind to global questions. “What are the main themes?” needs the whole corpus, but similarity search only returns the handful of chunks that superficially resemble the question. It severs context at chunk boundaries. The relationships and hierarchy that complex reasoning depends on are exactly what chunking throws away. Microsoft Research framed this crisply when they introduced GraphRAG: Baseline RAG “struggles to connect the dots” and performs poorly when asked to “holistically understand summarized semantic concepts over large data collections.” What a context graph changes GraphRAG attacks the problem before any question is asked. During indexing, a large language model (LLM) reads every chunk and extracts entities, relationships, and claims, assembling them into a weighted knowledge graph. It then runs community detection (the Leiden algorithm ) to cluster the graph into a hierarchy of related topics, and pre-writes a natural-language summary for each community. At query time, those summaries do the heavy lifting. Each relevant community drafts a partial answer (the “map” step), the partials are ranked and merged (the “reduce” step), and the model synthesizes a final response grounded in structure rather than in a few cherry-picked snippets. Variants like HippoRAG take a different route, using the graph plus a Personalized PageRank walk to find the right passages — but the core idea is the same: Let relationships, not just cosine similarity, decide what context the model sees. The evidence: Four studies, one pattern 1. Global sense making: The headline win Microsoft pitted GraphRAG head-to-head against naïve RAG on global, “make sense of the whole corpus” questions over million-token datasets, with an LLM acting as judge across three axes: Comprehensiveness, diversity, and empowerment. GraphRAG won 72 to 83% of comprehensiveness comparisons and 62 to 82% of diversity comparisons against vector RAG . Its highest-level summaries used up to 97% fewer tokens than processing the source text directly. That is not a rounding-error improvement. On exactly the kind of question that breaks text-chunk RAG, the graph wins two out of three times or better. 2. Multi-hop retrieval: The graph finds what chunks miss The second piece of evidence is about retrieval quality: Does the right supporting passage even make it into the top results? On the standard multi-hop QA benchmarks (MuSiQue, HotpotQA, 2WikiMultiHopQA), graph-guided retrieval lifts Recall@5 dramatically: Average Recall@5 climbs from 73.4% (naïve RAG) to 87.8% (graph-guided), a +19.6 point gain. The biggest jumps come on the hardest, cross-document sets: +31 points on MuSiQue and +28 points on 2Wiki . HippoRAG reports up to a 20% accuracy improvement on multi-hop QA, at 10–20× lower cost and 6–13× faster than iterative retrieval methods. 3. The controlled head-to-head - where it gets honest Here is where the story gains nuance. A 2025 study from Michigan State and Meta ran RAG against four GraphRAG families under one unified protocol — identical chunking, embeddings, and generation — and found no single winner. The two approaches are complementary: On single-hop, factual lookup (natural questions), plain RAG edged ahead (F1 64.8 vs. 63.0 for the best graph method). On multi-hop reasoning (MultiHop-RAG), graph-guided retrieval pulled in front (70.3 vs. 67.0 overall accuracy). The lesson: A context graph is not a universal upgrade. It is a specialized one that pays off precisely when questions demand reasoning across pieces. 4. When to use graphs: The task-type verdict The most recent benchmark, GraphRAG-Bench (ICLR 2026), set out to answer “In which scenarios do graph structures provide measurable benefits?” Its accuracy-by-task numbers map the boundary cleanly: Simple fact retrieval: Text chunks 60.9 vs. graph 60.1 — effectively a tie. The graph’s structure is overhead the query doesn’t need. Complex reasoning: Graph 53.4 vs. chunks 42.9 — a +10 point graph win. Contextual summarization: Graph 64.4 vs. chunks 51.3 — a +13 point graph win. The scorecard Read top to bottom, the pattern is unmistakable: The graph’s advantage grows with the reasoning depth of the question, while text chunks hold their ground on isolated facts. The catch: Cost and the LLM-judge problem Two caveats keep this from being a slam dunk, and ignoring them is how teams end up disappointed. Building the graph is expensive. Having an LLM extract entities and relationships from an entire corpus isn’t cheap. One analysis put index construction at roughly $48 against GPT-4o for a moderate corpus, far above a vanilla vector index. (Microsoft’s own follow-up, LazyGraphRAG, defers extraction to query time and cuts that to around 0.1% of the cost - a tacit admission that the original budget is impractical for many deployments.) Many of the wins are judged by another LLM — and LLM judges are biased. An independent audit found systematic flaws in this evaluation style: position bias (swapping which answer appears first can swing the win-rate by more than 30 points), length bias , and trial bias (identical comparisons disagree across runs). After correction, one popular method’s reported 66.7% win rate fell to about 39% — below the 50% break-even line. The takeaway is not “the research is wrong.” It is that the large gains — the +20% multi-hop accuracy, the +15-to-30-point recall jumps — are robust, while narrow comprehensiveness margins deserve a skeptical second look with reference-based metrics. So when should you reach for a context graph? Strip away the hype and the decision is refreshingly practical. Use a context graph when: Your questions are multi-hop, global, or sensemaking in nature; you need comprehensive, multi-perspective answers; and your corpus is richly interconnected (research libraries, case files, incident histories, knowledge bases). Stick with text chunks when: Your queries are mostly single-fact lookups; your corpus is small or flat; and indexing cost, latency, and operational simplicity outweigh a marginal quality bump. Best of all, go hybrid: The systematic studies converge on the same recommendation: route each query to the right method, or fuse evidence from both. Combining graph and chunk retrieval consistently beats either one alone. You don’t have to choose a religion; you have to build a router. The bottom line A context graph is not magic, and it is not snake oil. It is a targeted instrument. Hand it a question that requires connecting scattered facts or synthesizing a whole corpus, and it will outperform text chunks decisively. Hand it “what’s the phone number on page 3,” and you’ve paid for indexing you didn’t need. The teams that win with GraphRAG in 2026 won’t be the ones who graph everything. They’ll be the ones who know which questions deserve a graph — and build pipelines smart enough to tell the difference. Dattaraj Rao is an R&D architect at Persistent Systems

VentureBeatAugust 2, 20267 min read