Enterprises that already got burned by an AI agent passing its evals and then failing in production are moving faster toward removing humans from deployment decisions, not slower — even as trust in automated evaluation is rising across the board, new VB Pulse research shows.
In July, 13% of 108 enterprises surveyed said they trust automated evaluation, up from just 5% the month prior. Meanwhile, survey respondents citing poor alignment between tests and real-world results as their biggest concern fell 10 points, from 29% to 19%, month over month.
Yet, 49% of survey respondents said that an AI agent or LLM-powered feature that had cleared company testing subsequently created a problem visible to customers, essentially unchanged from 50% in June. And nearly a quarter, 24%, said this troubling outcome had occurred more than once.
The latest findings from VentureBeat Intelligence uncovered a more troubling phase of the enterprise agent rollout: the gap is no longer only between how much autonomy companies give agents and how well they can verify them. It is increasingly a gap between confidence in the evaluation layer and evidence that the layer is getting better at preventing failures.
The most revealing split appears inside the July data.
Of the enterprises that experienced an AI feature clear testing only to go on to disappoint a customer, 4% placed complete faith in automated checks. Of those that had detected no comparable incident, 24% expressed full confidence — a sixfold difference.
It makes sense: those who experienced test-passing agents failing in live production are, unsurprisingly, more likely to doubt the automated checking process.
Perhaps it makes sense then, that companies geared toward tackling this problem — like automated agent error monitoring and mitigation platform Raindrop.ai — are seeing the market transform wildly from just a few months ago.
“We are seeing the great-decline of evals as we know them,” Raindrop CTO Ben Hylak told VentureBeat in a direct message. “The Fortune 100 are increasingly reducing eval sets and deprioritizing maintenance. As systems grow more complex (MCPs, subagents, etc.) it becomes impossible to fully enumerate the failure cases. Instead, they’re leaning on anomaly and issue detection solutions, both before and after production.”
VentureBeat fielded the July wave among 108 people representing companies with workforces of at least 100. This is down from 157 respondents in June.
Of the 108, 69% described themselves as final AI-buying authorities or people who recommend and influence those purchases. The sample skewed toward midsize organizations: 63% worked at companies with 100 to 2,499 employees.
The findings should be read directionally. The survey is self-selected rather than a probability sample, and the burned-vs.-unburned splits cited throughout this piece rest on groups of 41 to 53 respondents, and other cross-tabs in the report range from 40 to 68.
The industry mix also changed: technology and software participation declined nine points, ending at 14%, while the retail and consumer share added four points and ended at 19%.
The report nevertheless identifies four month-to-month changes worth noticing: more respondents professing complete confidence, fewer naming poor real-world alignment, more choosing integration ease as the decisive buying factor, and Braintrust gaining primary-platform share.
VentureBeat’s June research identified an enterprise evaluation gap: companies were granting agents more authority faster than they were developing reliable ways to test them.
July preserves the key number from that first wave. Across 265 enterprise responses over the two months, the proportion reporting at least one test-approved system that disappointed customers stayed within a single percentage point: 50% in June and 49% in July.
This figure does not mean that 49% of all agent runs fail, or that any particular evaluation product has a 49% failure rate. The survey asks whether an organization experienced at least one customer-facing incident in the previous year after an AI feature passed its internal tests. Companies that deploy far more agents have more opportunities to encounter such an incident.
But that limitation does not make the result less important. An internal evaluation serves as a release gate. If roughly half of surveyed organizations have seen that gate approve a system that later fails in front of customers, a passing score cannot be treated as proof of production reliability.
The cross-tab reinforces the point. Ten of the 41 enterprises with no identified testing miss placed complete faith in automation.
Only two of the 53 previously burned enterprises said the same. Confidence is strongest among respondents with the least evidence that the release gate can fail.
The counterintuitive finding is what companies do after an evaluation miss.
Overall, 67% either let an agent push code or change a system without a person’s approval in certain low-risk cases, or are modifying their pipelines to support that practice during the coming year. That is unchanged from June. In July, 37% already permitted it in limited cases and another 30% were building toward it.
Among enterprises where a test-approved system had disappointed a customer, however, 85% were pursuing that no-approval model, compared with 61% in the group reporting no comparable incident. Only 11% of burned respondents rejected end-to-end deployment automation for the years ahead, versus 24% of unburned respondents.
It would be easy to read that as recklessness, but the data supports another plausible explanation: deployment maturity. Organizations running more agents, at higher volume and across more consequential workflows, are more likely both to encounter failures and to have the engineering infrastructure needed for automated deployment.
The survey cannot establish which explanation dominates. It does establish that a customer-visible incident does not appear to stop the move toward autonomy. Respondents with firsthand proof that testing can miss defects are also moving most aggressively to let those tests authorize production changes.
If their per-deployment failure rate remains constant while deployment volume rises, the total incident count could grow even without the percentage of affected companies increasing. The July data does not measure incident volume, so that remains a risk implied by the pattern rather than a measured outcome.
Pre-deployment evaluation and production monitoring answer different questions. An evaluation asks whether an agent appears ready to ship. Production monitoring asks what the agent is doing after release and whether its live outputs remain correct.
Most companies in the July sample still emphasize whether the system functions, not whether the answer is correct.
Among the 106 valid responses to this question, 26% used inline quality assertions — automated judges or guardrails checking live traffic for output-quality problems. Another 26% focused on transaction traces such as infrastructure spans, token usage and raw inputs and outputs, while 24% mainly tracked gateway metrics such as latency, errors and cost.
Trace and gateway data can reveal outages, slowdowns and broken requests. They may not flag a fluent, fast and confidently wrong answer. Grouped by the report according to what each architecture actually watches, half of respondents monitored whether an agent was functioning, while just over a quarter automatically monitored whether its production output was correct.
The gap is sharpest among the 40 respondents already permitting no-approval deployment in limited cases. Only 28% of that group automatically checked the meaning and correctness of live answers. In other words, most enterprises that have eliminated a person from at least some release decisions have not installed automated semantic-quality monitoring as the production backstop.
This is the clearest operational lesson in the data. A pre-deployment test suite and infrastructure observability are necessary, but they do not cover the same failure mode. Enterprises need a way to detect bad outputs after the agent begins interacting with real users, data and tools — especially when nobody reviews the deployment decision first.
The vendor data offers a more encouraging sign: enterprises are adding dedicated evaluation tools, and specialist platforms are gaining ground.
OpenAI’s native evals and traces narrowly led as the primary platform at 18%, followed by Confident AI’s DeepEval at 17% and Braintrust at 15%.
Anthropic’s Claude Console and Workbench held 12%, tied with organizations reporting no dedicated evaluation platform. Three options each held 6%: internally built tools, Promptfoo and LangSmith.
Braintrust’s primary share increased from 8% in June to 15% in July, the biggest gain by one vendor and the one the report flags as statistically significant. DeepEval rose from 12% to 17%. Use of no purpose-built platform declined five points to 12%, although that smaller change does not by itself confirm a trend.
Because many companies use more than one tool, the broader footprints are larger. OpenAI native evaluation appeared somewhere in 31% of stacks, DeepEval in 27%, Braintrust in 22% and Anthropic’s native tooling in 20%. Custom internal tooling reached 14%, while Weights & Biases Weave and open-source Langfuse each reached 11%.
These are adoption figures, not product-performance scores. The survey does not establish that one vendor produces more reliable agents than another. Still, the results point toward evaluation becoming a distinct enterprise software layer rather than a loose collection of internal scripts or a feature used only inside a model provider’s platform.
Purchasing priorities are changing with that market. The proportion choosing integration ease as the decisive factor climbed 12 points to 39%, displacing cost, which fell from 28% to 23%. Evaluation accuracy ranked second at 28%. The combined average for satisfaction, implementation simplicity and economic value was 3.9 out of five.
The move from price toward integration suggests enterprises increasingly want a tool they can install into existing development and monitoring pipelines now. Yet their leading success metric remains evaluation consistency at 38%, followed by fewer failures and regressions at 20%. Buyers are selecting for fit while still judging results on repeatability.
Switching intent also cooled: 56% still expected to add or replace a platform during the coming year, down from 64% in June.
The proportion staying put increased eight points, reaching 44%. Together with specialist adoption, they suggest some buyers are moving from evaluation to implementation.
The budget data reveals how enterprises are managing the contradiction between greater autonomy and unreliable evaluation.
People-centered review workflows edged narrowly ahead of production observability as the most frequently cited area for increased investment, 31% to 30%.
Automated evaluation pipelines ranked third at 19%, followed by testing for safety and policy compliance at 16%. Only 6% said their reliability and evaluation budget was not increasing.
Among enterprises that had experienced a testing miss, 38% said people-centered review would receive the fastest investment growth, compared with 24% of organizations that had not been burned.
That produces an apparent paradox: the burned group is most likely to remove people from the release checkpoint and most likely to increase spending on people elsewhere in the process. The strategy appears to be automation with a human backstop — allow agents to move faster, then use reviewers to catch what automated evaluation misses.
The open question is whether that model scales. Agent deployments and automated checks can grow with software volume. Reviewer hours do not fall at the same rate. Enterprises may therefore be replacing a human approval step with a larger downstream review function rather than eliminating human oversight.
July’s data does not show that enterprise agent evaluation is failing everywhere, nor does it prove automated judges are getting worse. It shows something more precise: confidence rose before the measured failure incidence improved.
At the same time, the infrastructure around evaluation is maturing. More enterprises are adopting specialist tools, integration has become the leading purchase criterion and companies that have already experienced failures are increasing investment in human review. The market recognizes the problem and is spending against it.
But the central reliability result remains stubborn. Nearly half of surveyed enterprises still report that an AI feature cleared internal checks before disappointing a customer. Respondents with that experience place less faith in automation — and move faster toward deployments with no human approval.
The report frames this as an incomplete verification model: a passing pre-deployment score marks the start of monitoring, not the end of it. For most enterprises, the production quality checks and evaluation testing that would close that gap still aren’t in place.
A company builds a governed context layer specifically to stop its AI agents from confidently giving wrong answers. Once that layer is live, the company is more than twice as likely to report the failure happening — not less.
In the past six months, 68% of enterprises have traced a confident but wrong AI agent answer to missing or inconsistent business context. Thirty-seven percent say it happened more than once, ahead of the 32% who saw it happen only once. The figures come from a VB Pulse July 2026 survey of 101 qualified enterprises with more than 100 employees. That’s up from 57% in a VB Pulse survey conducted in June. Recurring failures climbed too, from 31% then to 37% now.
This is the second time VB Pulse has asked enterprises this exact question, once in June and now in July. The failure rate is climbing, not falling, even as more enterprises report a governed layer in production, up from 25% in June to 32% now.
Every AI agent needs some way to know what the business actually means, whether a metric is defined consistently, whether a document is current. That’s the operation. The challenge is that enterprises hand agents that context in very different ways, and those ways are not equally reliable.
Retrieval over documents remains the most common approach, the primary source for 31% of enterprises. But a real share of enterprises skip a structured approach altogether. Thirteen percent run agents primarily on long-context loading, feeding documents directly into the model’s context window rather than retrieving them. Five percent give agents no structured context at all, just the model’s general knowledge. Between them, nearly one in five enterprises are feeding agents business context by brute force or not feeding it at all.
Even the leading approach can still produce a confidently wrong answer. Retrieval works by matching a question to text that looks similar in meaning. Similar wording doesn’t guarantee the same meaning. Srijith Rajamohan, an AI research leader at Redis, described exactly this gap in an interview with VentureBeat earlier this year.
“If you have a sentence like ‘Rome is closer than Paris’ and another that says ‘Paris is closer than Rome,’ and you do an embedding retrieval followed by a text search, you’re not going to be able to tell the difference,” Rajamohan said. “The same words exist in both sentences.”
The way enterprises choose a retrieval system doesn’t help close the gap. Access control and permissions now tie ease of data ingestion as the top selection criteria, at 24% each. It’s the first time in this survey series that a governance property has led to the buying decision. Retrieval accuracy trails at 15%. The property most directly tied to a confident wrong answer isn’t the property most enterprises are buying for.
Once a system is running, correctness is still how enterprises judge it. Response correctness is the primary success metric for 38% of enterprises, twice the next closest answer, security and access control at 19%. Enterprises are shifting how they buy toward governance. They’re still grading success on whether the answer is right.
A governed context layer is meant to fix this. It’s one shared, agreed-on model of what the business’s data means, that every agent and BI tool references instead of guessing on its own. Adoption is far from settled.
Thirty-two percent of enterprises run one in production. Thirty-one percent are piloting or building one right now. Twenty percent are evaluating one. Fourteen percent have no plans to, and 4% don’t know.
Compare that adoption data against who’s actually had the failure, and the picture inverts. Among the 91 enterprises able to say whether they’d experienced the failure at all, those running or building a governed layer report it recurring at 50%. Those without one report it at 21%.
A governed layer doesn’t cause the failure — it’s what makes the failure visible in the first place. Tracing a bad answer to a broken definition or a stale table requires a shared, governed reference point. A context layer provides that. Without one, the same wrong answer still happens — it just gets chalked up to the model, or never gets traced at all.
The pain point predates AI by decades. Kyle Nesbit, founder of the semantic layer startup Credible Data, described it to VentureBeat last month. “It’s the same pain point people have had for 30 years, the lack of governed data analysis,” Nesbit said. “Now with AI, it’s the same problem, but orders of magnitude more chaos and pain.”
Company size sharpens the same point. Enterprises with more than 1,000 employees report recurring failures at 55%, against 30% for those between 101 and 1,000 employees. That’s despite the bigger companies being less likely to have a layer already in production, 24% against 37%. More instrumentation and more people asking why a number was wrong turns up more failures, not fewer. A clean record is not evidence of a healthy context layer. It’s at least as likely to be evidence that nobody’s checking.
Here’s what this adds up to for enterprises building on this layer.
Retrieval alone will not close the context gap. RAG remains the default context source, and nearly one in five enterprises are running agents on long-context loading or no structured context layer at all. More documents or a bigger index doesn’t fix a definition that means two different things in two different systems.
The budget is moving faster than the infrastructure is shipping. Sixty-three percent of enterprises are already building or running a governed context layer. Only 32% have actually gotten one into production. That gap is where the spend is going, not where the problem has been solved.
A clean failure record is a red flag, not a green one. The 22% of enterprises reporting no context failure at all are not the best-governed group. They’re the group least likely to be checking. The size data backs this up directly. Larger enterprises report recurring failures at nearly twice the rate of mid-market peers, despite being less likely to have a governed layer in production, not more.
No one is planning to hand the layer to a single provider. Seventy-nine percent of enterprises intend to keep at least part of the context layer outside any one vendor’s stack, split between best-of-breed tools and an explicit mix. Just 12% plan to consolidate onto a single provider’s native context stack.
The finding that organizations aren’t likely to hand over control to a single provider is a theme that VentureBeat has reported on consistently this year. Michael Ni, an analyst at Constellation Research, put it bluntly earlier this year when DataHub’s context layer push first landed.
“Whoever controls runtime context, controls the AI decision layer for enterprise data,” Ni said.
Presented by MongoDBBuilding AI that is accurate, secure, and reliable is a major engineering feat for organizations subject to the compliance obligations that govern healthcare, financial services, and transportation. The challenge of delivering AI-dr…
Skan AI, a startup that builds what it calls a “context graph of work” by observing how employees actually perform their jobs across enterprise software, has raised $63 million in Series C funding co-led by Cathay Innovation and Dell Technologies Capital, the company announced Wednesday.
Citi Ventures, Bloomberg Beta, State Farm Ventures, and Wipro Ventures also participated in the round, which brings the seven-year-old company’s total funding to roughly $120 million. Alongside the raise, Skan is announcing the general availability of two new products — Skan AI Blueprint and Skan AI Agents — that, together with its existing Skan AI Intelligence offering, form a complete platform for discovering, modeling, and ultimately automating enterprise workflows.
The announcement lands at a moment of deep frustration in enterprise AI. Companies have poured billions into generative AI pilots, but the results have been dismal: Gartner research cited by the company finds that only 8% of enterprises have AI agents in production, and 95% of early implementations will require a complete redesign. Those figures echo an MIT report last year, covered by Fortune, which found that roughly 95% of enterprise generative AI pilots were failing to deliver measurable returns.
Avinash Misra, Skan’s co-founder and CEO, believes the industry has misdiagnosed the problem. The models are fine, he argues. What they lack is an accurate picture of the businesses they are being dropped into.
“Everyone is obsessed with building a better driver,” Misra told VentureBeat in an exclusive interview ahead of the announcement. “We think the bigger opportunity is building a better navigation system.”
The standard playbook for grounding AI agents — feeding them process documentation, standard operating procedures, and system logs — is built on a fiction, Misra argues. The way work is documented and the way work actually happens inside a large enterprise are two different things, and the gap between them is precisely where agents fail.
That gap is what sent Misra and co-founder Manish Garg down this path seven years ago, long before agents were a boardroom obsession. “Why is it so difficult for an organization, and a large enterprise especially, to understand how its own work actually gets done?” Misra said. “Why does it need to fly in McKinsey consultants for that?”
The question has only grown more consequential as enterprises race to operationalize AI. Frontier models arrive at the company door brilliant but blind, with no knowledge of the exceptions, decisions, handoffs, and institutional habits that define how a claims department or a compliance team actually operates. Every company now stuffing agents with documentation and logs, Skan contends, is discovering the same uncomfortable truth: the source data was never the whole story. And a source data problem cannot be fixed downstream.
Skan’s answer is to go to the source itself. The company deploys observation technology on employee desktops that continuously watches how work moves across applications — the spreadsheet, the CRM, the email client, the 40-year-old mainframe — and abstracts those observations into a living model of the underlying business process.
“Think of it this way: if I were to share my screen here, and you were to observe my screen going from Excel sheet, CRM system, email client, in about two iterations you’d build a model of what I do,” Misra said. “Except you couldn’t do that at scale. You couldn’t do it 24/7, and for 1,500 people like me. Now replace yourself with our technology.”
That framing also explains how Skan positions itself against process mining vendors like Celonis, which reconstruct workflows from the data trails left in backend systems. System logs, Misra argues, only capture completed transactions — not the messy human work that produced them.
“All backend data, by definition, is a committed state of work. Work is really what happens between those committed states,” he said. “Eighty percent of what you’re interested in, from an AI point of view, in execution of work, actually lies between those systems.”
The screen, in Skan’s view, is the one place where everything converges. “It brings together human agency, it brings together the entire application landscape, and it brings together the data that matters,” Misra said. Two decades of user interface design have quietly buried enormous amounts of process knowledge in the space between a worker’s eyes and their monitor; Skan’s pitch is to bring that hidden layer back to the surface.
But watching, he insists, was never the hard part — a point aimed squarely at the incumbents who might be tempted to copy the approach. “The hard problem is not screen observation,” Misra said. “The hard problem is abstraction of what you see on the screen — the intent extraction.” A human watching a colleague’s screen can instantly tell whether a jump back to step one means a new case or rework on an old one, because humans understand the signature of the work. Teaching a model to make that same judgment, statefully and at enterprise scale, is where Skan believes its seven-year head start lives.
The result is a context model that AI can reason over and act on — the raw material for the agents that now sit at the top of the company’s product stack, and the foundation for everything else the platform does.
An approach built on continuously watching employee screens invites an obvious objection, and it is not a hypothetical one. In June, Reuters reported that Meta scaled back an internal tool that tracked employee mouse clicks after workers raised concerns — a sign that even AI-forward companies are wary of the line between operational telemetry and surveillance.
Misra says he heard the objection before he wrote a line of code. When he first pitched the concept to Delphine Icart, then chief transformation officer at AXA Mexico, her reaction was blunt. “Delphine’s first words to me were, ‘This sounds like a great idea, but you are dead on arrival,'” Misra recalled. “‘You are observing things that you shouldn’t be observing — the privacy of my operators, and the sovereignty of my data on those screens.'”
That conversation, he says, shaped the architecture. Skan aggregates rather than individuates: the system surfaces statistical patterns across hundreds of workers performing the same process, not the behavior of any one of them. “We’re not interested in what John is doing at 10 hours and 43 seconds,” Misra said. “We are interested in what hundreds of Johns put together — what are the statistical and the semantic decisions that they are making in that business process?”
Organizations control what the technology can see through an opt-in scoping model — specific applications and URLs, nothing else — and the data Skan produces never leaves the enterprise firewall. A three-tier architecture sends only anonymized metadata to the cloud. Misra points to deployments approved by European works councils, among the most privacy-protective labor bodies in the world, as evidence the model holds up under scrutiny — and credits it for clearing security review at institutions where most AI tools cannot operate.
Whether aggregation fully defuses the concern is likely to remain contested. The same telemetry that reveals a broken process can, in principle, reveal an underperforming team, and Misra acknowledged that the technology has led some customers to reduce headcount in certain processes.
Skan claims more than $500 million in cumulative customer value to date, a figure worth unpacking. Pressed on whether that represents realized savings or projections, Misra was direct that it is an envelope, not a bank balance.
“The number comes from the cumulative, across all our customers, of the quantified savings that we have brought to them — the savings that they have expected they would save,” he said. “Now they are on the roadmap of recouping those savings through a variety of interventions,” including process redesign, technology changes, and, increasingly, AI agents. In other words, $500 million is identified opportunity, some portion of which has been captured.
The more concrete evidence comes from individual deployments. At one top U.S. bank, according to the company, Skan observed 11.2 million context switches across 1,500 finance professionals and uncovered $37 million in operational friction. Turning those observations into agent-executable context cut cost per transaction by 32%, lifted throughput by 41%, and delivered $18 million in annualized savings.
Misra pointed to an anti-money-laundering operation at one bank where “60% of the cases are now being run by AI agents,” adding that the results surprised even him: “The accuracy of those agents surpasses many times over the accuracy of humans. It’s not just an argument of efficiency; it has also become an argument of quality.” Among insurers, he said, Skan typically delivers roughly 25% productivity uplift in core claims processes; one customer doubled its case volume over the past year without adding a single claims specialist.
Skan’s publicly referenceable customers include Unum, the $13.8 billion employee benefits provider, and Mitie, the U.K. facilities management company, whose chief technology and digital officer, Cijo Joseph, said Skan’s technology “gives us unprecedented operational visibility that has dramatically accelerated our AI transformation.” The company declined to share revenue but said it grew more than 300% year over year — for the second consecutive year — with net dollar retention around 150%, and now counts seven of the ten largest U.S. banks and a quarter of the Fortune 50 as customers.
Skan’s thesis rests on observing how work actually gets done — which raises an uncomfortable question. Real employees make mistakes, take shortcuts, and entrench inefficiencies. What happens when the context graph faithfully encodes bad process?
Misra’s answer reaches for the most famous precedent in modern AI. “Think for a moment what OpenAI did,” he said. “OpenAI took the totality of the world’s text and fed it into a transformer architecture, and semantic understanding emerged. OpenAI’s model has seen bad language and has seen good language, and yet it is able to have semantic understanding.”
Skan, he argues, does the analogous thing with work: treat business process execution as a language, where process steps, screen features, and handoffs stand in for words and sentences. Fed enough end-to-end executions, the model learns the full distribution of paths — efficient ones, slow ones, compliant ones — without assuming any single path is best. “The longest path may be the best path, because it is more compliant,” Misra said. An organization then constrains the model along the axes it cares about, and the model returns the path that satisfies them.
“It is not record and play — and that’s the fundamental difference between us and a lot of our competition, UiPath and so on,” he said. “It is fundamentally creating an AI model that understands work, and then constraining that model.”
He offered a concrete illustration of what that unlocks: at one large bank, Skan’s telemetry continuously compares live case execution against a 600-page controls inventory, with agents that trigger alerts when cases miss required compliance steps — turning a document no human could hold in their head into a real-time enforcement layer. It is the kind of application that only becomes possible, Misra argues, once a model genuinely understands the work rather than merely replaying it.
Skan sits at the intersection of several crowded categories, and its answer to each competitor is a variation on the same theme: scope. Process mining vendors see only what the logs record. RPA incumbents replay tasks without understanding them. And the platform giants — ServiceNow, Salesforce, Microsoft — are shipping capable agents whose vision ends at their own walls.
“The context that these agents have access to is limited to ServiceNow, limited to Salesforce, whereas work spans processes across the board,” Misra said. “Creating a customer entry is a task. To receive an email and decide whether a customer entry has to be created, or something else — that is the process, and that’s what we are after.”
The deeper strategic argument, and the one that seems to resonate with Skan’s regulated customer base, is about differentiation in a world where every enterprise has access to the same frontier models. “If every insurance company, every bank had access to the same models, then the outcomes will asymptotically decay to the outcome of the model,” Misra said. “Historically, you have competed and differentiated in the way you have organized work. That old word — process — now comes back as context for AI. But that context is protected by you. It’s not part of the model.”
That logic explains both the company’s posture toward the model makers — “the more they are successful, the more power we have,” Misra said, disclaiming any ambition to compete with them — and the Nvidia partnership featured prominently in the announcement. Skan runs on Nvidia AI Enterprise and NIM microservices, and Misra described growing demand for private appliances that can observe work, hold the context model, and execute agents entirely inside a customer’s own infrastructure. It also fits the market’s direction: venture investors surveyed by TechCrunch at the end of last year predicted enterprises would spend more on AI in 2026 but through fewer vendors — a consolidation that favors Skan’s decision to ship discovery, intelligence, and agents as a single closed loop.
Misra argues that loop matters more, not less, as automation scales, because agents demand oversight in a way humans never did. “It is an irony of sorts,” he said, “that you’ll probably need much more observation and much more understanding of work in an automated way than you would with humans.” The bet embedded in this round is that work context becomes foundational infrastructure for enterprise AI the way CRM became the system of record for customers — a comparison Cathay Innovation partner Simon Wu made explicitly, calling Skan “one of the defining platform companies of the next decade.”
Misra put the stakes more simply. “You cannot retrieve context that you do not capture,” he said. “The battleground is shifting from the smartest model to knowing how your company actually works — because everyone will have access to the smartest model.”
The frontier labs, in other words, can keep their arms race for the better driver. Skan just raised $63 million on the conviction that the money is in the map.
Presented by MongoDB We have been building databases as an industry for roughly 60 years. We have been building AI agents, in the form most people mean when they say the word today, for about 18 months.Sit with that ratio for a second, because it expla…
A VB Pulse survey this June found that 57% of enterprises had traced a confidently wrong agent answer back to missing or inconsistent context — the latest sign of how central context has become to whether AI agents can be trusted to act on their own.
Most of the fixes so far have solved a narrower version of that problem: one agent remembering more, in one session. What’s been missing is a way for a team of agents to draw on the same context at once, and that gap is where a newer problem is surfacing. Once an agent’s context is shared across a whole team, a wrong fact doesn’t cost one person a repeated explanation. It costs the whole team.
Tencent’s answer to that gap is Agent Memory, an open-source project the team said grew out of six months spent fixing a narrower problem: agents losing context in long sessions. Part of that system is a persona layer, a stable, distilled picture of who a user is and how they work, built up over many conversations rather than reconstructed each time. On Tencent’s own benchmark for whether an agent still applies that picture correctly after extended use, accuracy rose from 48% to 76%, a 59% relative improvement, once the persona layer was added. This week, Tencent extended that project with the beta launch of Team Memory, which opens the same approach up to a whole team instead of one agent. Tencent said the repo hit No. 1 on GitHub’s TypeScript trending list this week.
Agents on a team can now read from a shared memory hub instead of keeping separate, siloed context, governed through an access control layer that determines who can read what.
The core idea is a shared hub rather than a shared prompt. Instead of pasting one large context block into every agent’s window, Team Memory registers four kinds of reusable assets and equips each agent with only the ones it needs.
Chat Memory. Retains preferences, facts, decisions, and interaction history, distilled through four layers, from raw conversation up to a stable long-term persona, so an agent does not need to be reintroduced to a user it has already worked with.
Skill. Captures procedures pulled from completed work, versioned and reviewed before they are shared rather than dropped into a folder as-is.
LLM-Wiki. Turns documents and specs into structured, linked pages.
Code-Graph. Indexes a codebase’s symbols, files, and call relationships so an agent can check what a change might affect before making it.
Tencent’s documentation draws the distinction directly: “RAG answers ‘what can be found?’ Team Memory also answers ‘who can use it, which version is valid, and which Agent should receive it.'”
In practice, that’s what Tencent calls an “Agent Loadout”: a Scout agent doing research can be equipped with market research and competitive analysis assets, while a Builder agent gets the code graph and product docs it needs instead, rather than every agent getting access to everything.
Which assets an agent gets equipped with is governed through four visibility tiers:
Private. Readable only by the asset’s owner.
Team. Readable by anyone on the team.
Restricted. Gated by user, role, or agent-level access control.
Agent. Equipped to one specific agent within a team.
New assets default to private, so sharing has to be a deliberate action rather than something that happens automatically.
That access model answers a real question, who is allowed to read a given memory asset. It does not answer a second one, which is what happens once a memory asset turns out to be wrong. Tencent’s own documentation lays out ownership, versioning, and status tracking for each asset, but nothing in the documentation describes a correction or expiry process for a fact that’s already been read and reused by other agents on a team, or a way to resolve it when two agents’ memories of the same thing disagree.
That gap is what practitioners flagged within hours of the launch post.
“Shared memory makes the write path the interesting problem. Retrieval gets most of the attention, but a wrong fact written once now propagates to every teammate’s agent instead of just yours. Curious how the governance layer handles correction and expiry,” Blake Murphy wrote on X.
The concern wasn’t only about fixing a bad fact after the fact. It was about the decision to leave something out of the record in the first place. “the governed part is the hard part. once teammates’ agents can read each other’s context, someone has to decide what never gets written down,” Virgil Maro wrote on X.
Others pushed further into what happens once two agents’ memories actively contradict each other, not just go stale.
“The Code-Graph plus LLM-Wiki split is the right call. The part I’d want to see benchmarked: in shared mode, whose memory wins when two teammates’ agents have written contradicting facts about the same module? Single-agent memory drifts slowly. Shared memory drifts fast, because one stale write propagates to people who never saw the session that produced it,” Austin Green wrote on X.
The reaction wasn’t uniformly critical. “Interesting shift: making memory a shared service turns agents into a real team rather than isolated bots. Governance will be the trickiest part, especially when facts conflict,” Moez Zhioua wrote on X.
None of these are edge cases specific to Tencent’s implementation. A March 2026 paper on production multi-agent memory architecture, “Governed Memory: A Production Architecture for Multi-Agent Workflows,” published independently of any single vendor, identifies governance fragmentation and silent quality degradation without feedback loops as structural risks in shared multi-agent memory generally. The pattern the paper describes matches what the commenters above pointed at directly: a wrong fact in a single-agent memory system costs one user a repeated correction, while the same wrong fact in a shared, team-wide memory system propagates to every agent that inherited it before anyone catches it.
AI agent memory work in 2026 has mostly focused on a single agent remembering more, in one session, about one user: LangChain’s LangMem SDK, Google’s Always On Memory Agent, and Anthropic’s work inside the Claude Agent SDK all work this way. A different line of work has focused on giving agents access to a shared model of business data. VB’s own June survey found only 25% of enterprises had that kind of governed context layer in production, while vendors including AWS, Couchbase, Oracle, Redis, and Pinecone have all shipped versions of it this year.
Team Memory’s closest existing comparison is likely Asana, which built shared memory across a company’s AI teammates so an agent doesn’t need to be re-briefed on context another agent already has. Asana’s CPO described the same tradeoff Tencent’s practitioners are now raising, an access control system built specifically to stop one agent’s memory from leaking into a project another agent isn’t cleared to see. Tencent’s version is open-source and portable across frameworks rather than scoped to one platform, but it’s answering a question Asana’s team already ran into while building a closed one.
For teams evaluating this category, the upside is real: agents stop relearning what the team already knows. The tradeoff is just as real: one bad write is no longer contained to one agent — it’s inherited by every agent that reads from the shared pool, with no correction or expiry process yet in place to catch it.
The AI agent observability space is taking off — but how can enterprises be sure what observability products and solutions they need?
Observability startup groudcover (lower case “g” intentional) announced this week that it raised $100 million in a round led by One Peak, bringing its total funding to $160 million.
The company says it has more than 250 paying customers, tripled annual recurring revenue over the past year and is increasingly replacing established observability platforms inside enterprise environments. Those are company-reported figures, but together they point to growing momentum in one of enterprise software’s most competitive markets.
That market has long been dominated by companies including Datadog, Dynatrace, New Relic, Splunk and Grafana. Between them, they represent billions of dollars in annual revenue and years of product maturity. Breaking into that group has never been easy.
groundcover’s argument is that artificial intelligence has fundamentally changed the assumptions those platforms were built on.
Rather than competing feature for feature, the four-year-old company is trying to convince enterprises that the architecture underpinning observability itself needs to change as AI systems become more autonomous, produce vastly more telemetry and increasingly participate in software operations. Whether that thesis proves correct remains an open question, but it offers a compelling lens through which to examine how observability is evolving alongside enterprise AI.
Observability has traditionally been viewed as a post-production discipline. Engineers deploy applications, monitor logs, metrics and traces, investigate incidents, and improve reliability over time.
That workflow is changing.
AI-assisted software development has dramatically accelerated deployment cycles. Coding assistants generate more code, infrastructure evolves more rapidly, and organizations are deploying increasingly complex distributed systems that combine microservices, Kubernetes clusters, APIs and large language models. At the same time, enterprises are beginning to operate AI agents that execute multi-step workflows, call external tools and interact with production systems.
Each of those activities generates telemetry.
The result is an explosion of operational data that organizations increasingly want to retain rather than discard. AI applications introduce additional layers of observability beyond traditional infrastructure monitoring, including prompt execution, model latency, token consumption, retrieval pipelines, tool invocations and agent behavior. As enterprises experiment with autonomous systems, that telemetry becomes increasingly valuable because it provides the context needed to understand what an AI system actually did and why.
For many organizations, this creates tension with pricing models that charge according to the amount of data ingested.
Historically, engineers have often responded by sampling traces, shortening retention periods or limiting which data is collected. Those approaches reduce costs, but they also reduce visibility precisely when AI-driven systems demand more complete operational context.
“We’ve seen telemetry exploding,” groundcover co-founder and CEO Shahar Azulay said during a recent media briefing. “Users are frustrated by not getting all the value from Datadog and similar platforms. They’re limiting the data, siloing it, sampling it.”
Whether that frustration is widespread enough to reshape the market remains to be seen, but the underlying trend is difficult to ignore. AI is making observability less about collecting enough data and more about collecting everything organizations may eventually need.
Many observability vendors have introduced AI assistants, AI-powered root cause analysis and AI observability features over the past two years. Datadog, Dynatrace, New Relic and Grafana have all announced products aimed at helping enterprises monitor AI applications or automate operational tasks.
groundcover acknowledges those developments but argues they do not address what it sees as the more fundamental issue: where telemetry lives and how customers pay for it.
Instead of operating a conventional SaaS platform that stores customer telemetry in vendor-managed infrastructure, groundcover uses what it calls a bring-your-own-cloud (BYOC) architecture.
Customers keep the data plane—including telemetry storage and processing—inside their own AWS, Microsoft Azure or Google Cloud environments, while groundcover provides a managed control plane and user experience. A fully self-hosted deployment option is also available.
While some competitors, including Datadog and a few other observability vendors, do offer limited hybrid or customer-controlled data residency options, these are generally not equivalent to a full BYOC model. In most cases, telemetry is still processed and stored within the vendor’s managed infrastructure, with only partial controls (such as regional data residency, private links, or selective log forwarding) available.
That architectural decision influences nearly every aspect of the company’s strategy.
Because customers already pay for their own cloud infrastructure, groundcover argues it can avoid charging based on telemetry ingestion. Instead, pricing is based primarily on monitored hosts, regardless of telemetry volume.
The company believes this changes customer behavior.
Rather than deciding which logs or traces are too expensive to keep, organizations can theoretically retain complete telemetry and use it for operational analysis, compliance and AI-assisted troubleshooting.
“We don’t price by data volume,” Azulay said. “We price by the size of the infrastructure.”
The distinction matters because AI workloads tend to increase telemetry far faster than infrastructure itself.
That does not necessarily make host-based pricing universally cheaper. Organizations with relatively light workloads spread across many hosts may find different economics than dense Kubernetes environments generating enormous amounts of telemetry. The company’s own briefing notes that per-host pricing is most advantageous for organizations with high telemetry density and may be less compelling for lightly utilized fleets.
Still, the broader argument is less about cost alone than predictability. Enterprise infrastructure teams often struggle with observability bills that fluctuate alongside application growth. groundcover’s model attempts to align pricing more closely with infrastructure planning rather than data generation.
The second pillar of groundcover’s strategy is eBPF, a Linux kernel technology that has rapidly become one of the most important building blocks for modern cloud observability.
Instead of requiring developers to manually instrument applications, eBPF allows software running inside the operating system kernel to observe network traffic, system calls and application behavior with minimal code changes.
That enables faster deployment and broader visibility across infrastructure.
For organizations operating Kubernetes clusters and cloud-native applications, reducing instrumentation complexity can significantly shorten deployment times while increasing telemetry coverage.
Azulay argues this becomes especially important as AI systems generate increasingly complex interactions across services.
“Our sensor allows us to observe systems very deeply from infrastructure to application to AI workloads without developers needing to instrument code,” he said during the briefing.
eBPF itself is hardly unique. Many observability vendors now incorporate it into their platforms.
What groundcover argues differentiates its approach is combining automatic eBPF collection with customer-controlled storage, OpenTelemetry compatibility and unified pricing inside a single platform.
The company’s own research briefing acknowledges that none of these technologies individually represents a competitive moat. The claimed differentiation lies in the combination of eBPF-first collection, managed BYOC architecture, host-based economics and full-stack observability delivered together.
Perhaps the most interesting aspect of groundcover’s strategy extends beyond traditional monitoring.
The company increasingly describes observability as infrastructure for autonomous software development.
Historically, observability platforms have served human operators investigating production incidents.
groundcover believes future observability platforms will increasingly serve AI agents as well.
Its Agent Mode product allows engineers to investigate incidents using natural language across logs, metrics, traces and Kubernetes events. More importantly, Azulay envisions observability becoming the feedback mechanism that informs coding agents about what actually happened in production.
Rather than simply detecting failures after deployment, observability becomes continuous operational context that autonomous systems can use to evaluate changes, identify regressions and eventually recommend or implement fixes.
“We’re seeing observability moving from being a post-production tool… to people taking context from production and feeding it back to their coding agents so they can write code better,” Azulay said.
Today, the company emphasizes that humans remain in the loop.
Agent Mode investigates incidents and surfaces recommendations, but production changes still require human approval. Azulay expects autonomy to increase gradually as organizations become more comfortable allowing AI systems to participate in operational workflows.
That vision reflects a broader trend emerging across enterprise software, where AI agents increasingly span development, testing, deployment and operations rather than functioning as isolated assistants.
groundcover is entering an intensely competitive market populated by vendors with decades of enterprise experience.
Datadog alone generated more than $3 billion in annual revenue in 2025. Dynatrace, Cisco’s Splunk business, Grafana Labs and New Relic all maintain extensive partner ecosystems, mature integrations and enterprise support organizations that newer entrants cannot easily replicate.
groundcover is not attempting to outscale those incumbents overnight.
Instead, it argues that AI creates an architectural inflection point similar to previous transitions from on-premises infrastructure to cloud-native computing.
According to Azulay, many customers initially adopt groundcover to reduce observability costs but increasingly remain because they want unrestricted access to richer telemetry and AI-native workflows.
He says deployments typically replace incumbent platforms rather than operate alongside them, although the company has not publicly disclosed customer migration data or independent studies validating that claim.
The company’s journalist briefing also urges caution around some performance claims.
Revenue growth, customer counts and enterprise adoption figures originate from groundcover itself. Published customer case studies reporting significant cost savings are vendor-authored and should not be treated as independent validation without additional evidence. The briefing also recommends scrutinizing exactly what metadata leaves customer environments in standard BYOC deployments, rather than assuming that no operational data ever reaches vendor infrastructure.
Those caveats are important because the observability market has become crowded. Gartner currently tracks more than one hundred observability products, and nearly every major vendor now markets AI-powered operational capabilities.
Success will likely depend less on whether AI matters—which increasingly appears inevitable—and more on whether enterprises conclude that existing architectures remain sufficient.
Viewed narrowly, groundcover’s Series C is another large infrastructure funding round.
Viewed more broadly, it reflects a growing debate about what observability becomes in an era where software increasingly writes, tests and operates itself.
If AI continues generating exponentially larger volumes of operational data, traditional assumptions about telemetry collection, pricing and storage may come under increasing pressure. Vendors that built businesses around charging for data ingestion may need to evolve their economics alongside customer expectations. New entrants, meanwhile, have an opportunity to design around those changing assumptions from the outset.
groundcover believes that opportunity lies in combining customer-controlled infrastructure, automatic telemetry collection and AI-assisted operations into a platform designed for autonomous software rather than simply adding AI features to existing observability products.
Whether that architectural bet proves durable will depend on enterprise adoption over the next several years.
But the company’s latest funding round suggests at least some investors believe the next battle in observability will not be fought over dashboards or alerts. It will be fought over who builds the operational data layer that increasingly intelligent software relies upon to understand—and eventually manage—the systems it runs.
You spend weeks tuning an AI chatbot. Answers are accurate. Stakeholders sign off, and you ship it. Three months later, the system is confidently wrong about a third of what users ask. Nobody changed the model, and nobody touched the prompts. The world moved, pricing changed, a policy updated, a product spec shipped a new version, and the underlying knowledge store didn’t move with it.
This is not a hypothetical. It’s one of the most common production failure modes in enterprise AI right now, and most data engineering teams don’t have the right tooling to catch it, regardless of how the AI system retrieves the data.
An AI application doesn’t care whether it’s retrieving from a vector store, a document index, or an API call. Whatever the mechanism, nothing in a standard retrieval pipeline checks whether what it’s serving is still correct. A stale pricing document retrieves just as confidently as a current one, because the system is scoring relevance or availability, not correctness. A record with a silently missing field passes through just as cleanly as a complete one, for the same reason.
So the failure is invisible by design. Outdated or incomplete data still scores high on relevance, or passes every check a data pipeline was built to run. The model answers with full confidence because the retrieved context looks authoritative. Every dashboard you’re watching stays green. The system looks like it’s working. It’s just wrong.
I’ve watched a similar version of this happen outside the AI context, in a fintech pipeline. An upstream system changed a field without notifying downstream users. The pipeline did not fail; it simply propagated bad values into dashboards because the system only checked whether the job completed, not whether the data was still correct. The issue surfaced only when a customer noticed something inconsistent. By then, the bad data had already moved downstream.
Whether it’s a document that’s gone stale or a field that’s gone silently missing, the failure shape is the same: the absence of an error is not the presence of correctness, and without building proper validation layers, nothing in the pipeline could identify the problem.
Teams that hit this failure tend to misdiagnose it, and they tend to do it twice.
Blaming the model: The first instinct is to blame the model, try a different LLM, adjust the prompt. The real problem lies further upstream, at the data engineering layer, the same instinct behind the fintech failure above: monitoring built for the pipeline, not the data.
Blaming the retrieval layer: Once the model’s ruled out, the next instinct is to blame the retrieval or context layer instead and buy a better one. The timing isn’t a coincidence: as enterprises push these systems into the real production world, this gap is exactly what’s starting to surface, and the vendor response has been everywhere.
AWS just entered the “context layer” race with a knowledge graph that learns from agent usage.
Snowflake’s new Horizon Context and Cortex Sense target the exact symptom this piece opened with: agents giving confident wrong answers because nothing governs the business logic underneath them.
Both are real responses to a real problem, but they sit one layer above it; a knowledge graph still depends on whatever feeds it.
The real problem lies further upstream, at the data engineering layer. Teams check whether a job ran, not whether the data it moved is still true, an instinct that predates AI by years. Monitoring is built for the pipeline, not for the data.
Data observability is a well-known concept that doesn’t get enough attention in how it’s actually implemented. The relevant metric isn’t a percentage — it’s coverage: what fraction of critical datasets have lineage that’s actually queryable, versus only living in someone’s head.
Uber built a dedicated data quality and observability platform long before retrieval-augmented generation existed. Their Unified Data Quality platform supports more than 2,000 critical datasets and detects around 90% of data quality incidents before they reach downstream consumers.
Netflix solved a different piece of the same problem, building a company-wide data lineage system so anyone could answer where a dataset came from and what touched it along the way. It maps dependencies across Kafka topics, ML models, and experimentation, not just warehouse tables. Similar to Uber, the platform was built for humans and now it has become more important with the rise in AI/LLM applications.
Between them, Uber and Netflix cover two of the four things worth building for. In practice, I think about it as four dimensions, each measurable on its own terms.
Correctness: Does each record conform to the shape and rules it’s supposed to, right field types, no unexpected nulls, values in range. Tools like Great Expectations and Soda handle this well: automated row and column-level validation instead of manual checks after something breaks. Track percentage of records passing validation per run.
Freshness: Is the data still current relative to its source, not just current as of its last check. Track time since last successful update per source, with an SLA per dataset rather than one blanket threshold, since some sources need hourly refresh and others don’t.
Consistency: Does the same fact read the same way everywhere it’s stored or indexed. This fails silently, it only shows up when two systems fed by the same source start disagreeing. A periodic cross-check between downstream destinations, flagging mismatch rate above a threshold, is enough to catch it early.
Lineage: Can you trace any output back to its source and every transform it passed through, the same question Netflix built its system to answer.
None of this requires infrastructure most data teams don’t already have. I know because I’ve built it, not just argued for it.
At Socure, client data arrived in whatever shape the client felt like sending it, and occasionally, quietly wrong. The challenge was building a system where incorrect data could be identified before it propagated downstream. The same principles applied: Validate what arrived, understand where it came from, and prevent bad data from becoming someone else’s problem.
Great Expectations became part of that foundation: schema and range validation at ingestion, per-source SLAs for freshness, cross-system checks for consistency, and file-level lineage. All of it sat behind a write-audit-publish pattern, where data landed in staging, was validated, and only moved downstream if it passed the required checks.
The result showed up downstream: better accuracy across the board, in reporting, in the ML models, and in AI retrieval built on top of that same data.
If you’re running retrieval-based AI systems in production, the diagnostic question isn’t which model to try next or which retrieval architecture to migrate to. It’s four narrower questions:
Is the underlying data validated against the standards required by its consumers?
What’s the oldest piece of content currently being served with high confidence?
Would two chunks of the same source ever disagree with each other in the same retrieval result?
Could you trace where it came from if it turned out to be wrong?
If you can’t answer those questions, then the gap lies in the pipeline between your source systems and whatever your agent reads from. That’s a data engineering fix, not a model swap or a vendor migration.
Whether you’re building reporting pipelines, ML systems, or AI agents, correctness, freshness, consistency, and lineage are what make data trustworthy. AI simply exposes weaknesses that have existed in data engineering all along.
GPU memory is the most expensive resource in production AI, and it’s also the one running out fastest.
Long context windows and multi-turn conversations force AI models to repeatedly recompute information they’ve already processed, consuming GPU memory and compute that could otherwise serve additional users or generate new responses.
Instead of treating GPU memory as the limiting resource, why not extend it with much cheaper storage technologies?
Weka, for one, believes that cheap flash storage can close that gap. The company’s NeuralMesh 6 software platform, launching alongside its first self-designed hardware line, Wekapod 3, extends what Weka calls Augmented Memory Grid, an approach that aggregates NAND flash to behave like GPU memory at a fraction of the cost.
This is an active and increasingly crowded category. Dell, NetApp, Pure Storage and VAST have all repositioned toward AI infrastructure over the past two years and Weka is one of several vendors arguing it’s built for this specific moment rather than adapting to it.
“What we’re seeing now with customers is they’re chasing availability of compute, and once they get new allocation from anyone, they want to be able to grab it and start running right away,” Weka co-founder and CEO Liran Zvibel, told VentureBeat.
The potential payoff is straightforward: better utilization of existing GPU investments, lower inference costs and faster deployment of new AI workloads without waiting months for additional GPU capacity.
The technology is most relevant for organizations already operating AI at scale or expecting rapid growth in usage, particularly enterprises building internal copilots, customer service agents, software engineering assistants or retrieval systems with long context windows. Smaller deployments may see less immediate benefit than organizations where GPU utilization has already become a limiting factor.
NeuralMesh 6 adds four capabilities aimed directly at a functionality gap Zvibel says has been costing Weka deals in competitive evaluations.
Composable and virtual multi-tenancy. Composable clusters give anchor tenants full hardware-level isolation, dedicated CPU, memory, and storage. Virtual multi-tenancy runs through Weka’s RDMA fabric, delivering network-level isolation that scales past 1,000 tenants per cluster, with provisioning in under 30 minutes. Combined, a single cluster running 50 composable clusters can support up to 50,000 tenants.
Unified file and object storage. Most storage systems keep two separate paths: a file-based path (the standard way servers and applications read and write files, used heavily in training and fine-tuning pipelines) and an object-based path (S3, the format inference and cloud-native tools typically expect). Normally a gateway translates between the two, meaning the data effectively exists twice. Weka’s claim is that the same physical data on disk is directly readable through either path at once, no translation layer, no second copy. Zvibel is targeting non-AWS GPU clouds specifically, naming Lambda, Nebius, G42, and CoreWeave, with what he described as roughly two orders of magnitude higher performance than conventional S3 and a capacity-based pricing model instead of per-API charges.
Metadata-first replication. Destination environments become browsable before a full data copy arrives, with data hydrating only when accessed.
“They had to wait for all of that to make it to the other side, and this takes days or weeks, in extreme cases a month,” Zvibel said. “We now allow our customers to grab some allocation of new GPUs and get up and running within an hour.”
AlloyFlash and Always-On data reduction. TLC and QLC are two types of NAND flash memory. TLC is faster and more durable but costs more per terabyte, while QLC is cheaper and holds more data per chip but is slower. AlloyFlash mixes both within a single cluster, automatically routing latency-sensitive work to TLC while running bulk-capacity workloads on QLC, cutting cost per terabyte without a performance penalty on the work that needs speed. Data reduction now runs by default rather than as an option.
Multi-tenancy and object storage solve how enterprises and neo clouds operate the platform day to day. A harder problem sits underneath: as context windows and multi-turn interactions grow, so does the GPU compute wasted recalculating work a model has already done. Augmented Memory Grid, a NeuralMesh 6 feature built specifically for this, is Weka’s answer.
Every prompt triggers two stages. Prefill calculates attention, the core mechanism behind how large language models process input, and it’s computationally expensive. Decode converts that calculation into output and is comparatively lightweight.
The cost shows up hardest in multi-turn sessions like chat or coding, where each new turn re-triggers prefill for everything that came before it, unless that work has been cached.
“If you have 10 turns, you may overcalculate 100 times because you’re redoing all of them. If you have 20, you’ll overcalculate 400 times,” Zvibel said. “You can put two orders of magnitude more NAND than you could afford in shared memory, and we can cache 100% of the pre-calculated tokens, so you never need to redo it.”
Storage vendors have spent the past year and a half repositioning around AI, and separating genuine capability from repositioned messaging is now a real evaluation problem for buyers.
“The storage world is shifting its focus from serving bits to enterprise workloads to managing data at the speed of AI. We’ve seen that most clearly over the past 18 months from Dell, NetApp, and Pure,” Steve McDowell, chief analyst at NAND Research, told VentureBeat. “The interesting thing is that companies like Weka, and VAST, are the true AI-native data companies, solving these problems since day one.”
McDowell singled out Augmented Memory Grid as Weka’s clearest technical lead.
“Weka continues to have the most technically capable KV cache implementation on the market with its Augmented Memory Grid,” he said. ” They were early with this technology, and continue to innovate. This is critical for AI inference, as it enables a level of GPU efficiency that, without question, saves money on GPUs and memory. That’s key for today’s memory and GPU constrained market.”
He also flagged Weka’s contractual guarantee on its data reduction claims as underappreciated.
“One flying a little under the radar: Weka is putting its money where its mouth is with its contractual guarantees for its data reduction promises,” he said.
McDowell’s advice to buyers evaluating competing claims from Weka, VAST, Pure and NetApp alike was pointed suggesting that enterprise buyers should look hard at what vendors are promising versus what they’re actually delivering.
“A smart buyer will look at how competing vendors are solving real-world problems today,” McDowell said. ” They do this by talking to organizations running similar workloads at similar scale. If a vendor can’t point to that, then it should be a warning sign.”
A single AI agent conversation can look flawless scored on its own and still point to a broken product. That gap is driving a shift in how enterprises evaluate agents, away from scoring individual traces and toward comparing cohorts of users against a baseline.
At VB Transform 2026, Harrison Chase, CEO of LangChain; Hui Zhang, CTO and co-founder of Conviva; and Emmanuel Turlay, director of engineering at CoreWeave, described that shift, along with a parallel move toward cheaper, narrower judge models.
Agent-as-judge — judging one AI agent’s output with another — hasn’t replaced LLM-as-judge, which Chase said remains the default. The larger tension, Zhang said, is between automated judging, whether by LLM or agent, and human review.
“You have scalable but ungrounded, whether it’s agents as judge or LLMs as judge, you grade the outcome, you grade the work. It still is very difficult to ground it and then you use humans and that’s just not scalable,” Zhang said. “The whole industry is facing this, which poison you want to pick.”
That gap — a conversation that scores well but still signals a broken product — is what teams try to close by building an exhaustive evaluation suite before they ship anything. Chase said that doesn’t work.
“We sometimes see teams that have almost eval paralysis,” Chase said. “They’re like, this is an eval set, I can’t launch it. The best teams launch and then iterate.”
Chase framed evaluation criteria as a living specification, not a one-time test suite: a product requirements document — the standard software-development spec for what an application should do. “Evals are like the new PRD,” he said. “They define what your agent should and shouldn’t do.”
Turlay described hitting the same failure from a different angle. “I was trying to reach 100% coverage for my tests, and I still had bugs in production,” he said — a test suite that looked complete but still missed what mattered, the same gap Chase was describing with evals.
Broad, always-on monitoring, he said, catches more real failures than an exhaustive pre-launch test suite. Teams should set up wide online checks first, use those to identify failure classes as they occur, then build a targeted offline evaluation set around the problems that surface.
Even a well-built evaluation process can still score the wrong thing. Zhang’s objection is to how most teams run evaluation: sampling traces, whether 50 of them or a full population, scoring each in isolation. That approach misses a signal that only shows up when comparing cohorts of users against a baseline, a method Zhang calls contrastive analysis.
Zhang illustrated it with a retail example: a shopper asks an agent for a running shoe ahead of a half marathon, the agent asks qualifying questions, and the shopper buys a shoe. Scored individually, that interaction looks fine. But the clarification ratio, how many follow-up questions an agent asks before completing a task, came in three times higher than baseline for that shoe category across the full user population. A second metric, how often shoppers finished their purchase outside the conversation, was five times higher than baseline for the same category.
Neither number is visible from a single trace. Both point to a debuggable, category-specific problem. Zhang said the industry also lacks a second data source: what happens before, between and after the conversation, not just the trace itself.
Once contrastive analysis flags which category is actually broken, the next problem is what watches for it going forward — and at what cost. Turlay’s rule was to start with the most capable model available to prove a task is solvable, then work down. If it can’t be done with a top-tier model, he said, it won’t work with a smaller one. Once a pattern proves viable, teams can sample a fraction of traffic instead of judging every interaction, and move simpler tasks like binary classification to smaller open source models.
LangChain took that further, fine-tuning its own model to detect when a user believes the agent made a mistake, a signal Chase calls perceived error. “The model we fine-tuned was a Qwen model,” he said, referring to Alibaba’s open source family. Combining hand labeling with distillation, the result performed well. “Same as [Claude]Sonnet, for, depending on how we served it, either 10 to 100x cost reduction,” Chase said.
Not every guardrail needs a model. Chase pointed to Claude Code’s own guardrails as proof: regexes, the common programming technique for finding and validating patterns in code. “A lot of the guardrails they had were just regexes,” he said. “They weren’t small LLMs, they were just regexes.”
The bigger question is whether using LLM as a judge removes the need for a human in the loop.
Turlay pointed to accountability, drawing on his prior work at a self-driving car company. His team compressed data intake and retraining into a two-week cycle for shipping a new model to the car. Even then, someone still had to sign off.
“I felt confident on behalf of the company to say this model should go into the car,” he said. The same logic extends to legal, finance and healthcare. “Before we can remove a human to say, I endorse this and I take responsibility legally for it, it’s going to be a while before agents can do that on their own.”
Zhang agreed a human has to remain the guardian on corner cases, even as automation eventually runs at a scale that beats individual human accuracy — machines can see more at the pattern level.
Chase went further: that human check isn’t just a safety net. “Human in the loop is really important for building trust in how these agentic systems work, and also really important for memory and learning from systems,” he said. “There has to be interactions in order for the system to learn.”