What’s new today…

DeepSeek’s recent decision to drastically cut pricing on its V4-Pro model by 75% should have been unequivocally good news for enterprise AI vendors and developers. Instead, many are discovering that cheaper models don’t automatically translate into healthier margins.The reason is simple: While inference costs plummet, agent systems are voraciously consuming tokens faster than prices are declining. For the last 2 decades, software economics was dictated by the same rule. Infra became cheaper every year whereas applications became more capable. AI was initially hypothesized to follow the same pattern. As frontier models improved and token prices dropped, many assumed inference would become a negligible operating expense.That assumption has begun crumbling exponentially. A chatbot usually turns one user question into one model call. An agent turns it into a chain of planning, retrieval, tool use, verification, summarization, and follow-up decisions. The user sees one answer. The vendor pays for the loop. That is the 100x problem: The same user-visible request can cost a lot  more to serve as an agentic workflow than as a chatbot or retrieval-augmented generation (RAG) response. In longer-running workflows, the multiplier is higher. Falling model prices help, but they do not fix a product architecture that turns one prompt into dozens of billable operations.The scale of what is now at stake is clear in how model providers themselves are pricing developer relationships. OpenAI’s proposed program to give every Y Combinator startup $2 million in API credits — a number that would have funded an entire seed round in any prior tech cycle, and when the same cohort got by on a few thousand dollars of AWS credits — is less a recruiting perk than an admission of what it now costs to run an AI-native company through its first year of product. For established enterprises retrofitting agents into existing product lines, the absolute numbers are larger still.What token amplification isIn a single-turn chatbot, one user message produces roughly one model call. Input-to-billed ratio is about 1:5.In a multi-step agent rolled out across customer support, sales operations, finance, legal review, and engineering, that ratio routinely lands at 1:700 or higher. Every loop iteration carries forward the cumulative conversation, tool outputs, and reasoning traces. Each step appends; nothing is dropped.A “simple” agent query like “What did our top customer ask about last week?” typically touches seven priced operations before returning an answer:User prompt (~50 tokens)System prompt and tool definitions (~3,000 tokens, repeated on every call)Retrieval (~5,000 tokens of context)Model call #1 — tool selection (8,000 in / 200 out)Tool execution (~4,000 tokens returned)Model call #2 — summarization (12,000 in / 400 out)Model call #3 — follow-up decision (12,400 in / 100 out)One sentence in, roughly 35,000 input tokens billed. Somewhere between $0.10 and $0.40 per query on a frontier model. Multiply that by a million queries a month — the table-stakes volume for any enterprise B2B feature — and the line item is six figures.Why this breaks the existing AI business modelThe dominant pricing story for enterprise AI has been seat-based SaaS: Pay per-user per-month, deliver agent capability, capture margin. That model assumes a reasonably bounded cost-per-user.Token amplification breaks the assumption. A power user running 50 agent invocations a day on a $40/seat plan can cost more in inference than the plan charges. Token amplification shatters the traditional SaaS pricing model. When a power user’s daily agent activity costs more in inference than their monthly subscription fee, vendor gross margins turn negative, a paradox that compounds as customers deepen their agent adoption, the very usage curve vendors are selling to their boards. Several vendors are now privately reporting negative gross margins on heavy users, mirroring recent cloud expenditure reports from the Bessemer ‘Supernova’ cohort, where the correlation between AI-agent adoption and gross margin contraction has moved from a theoretical risk to a primary P&L headwind.The visible symptoms have started leaking into public coverage. Bloomberg this week documented a widening gap between Salesforce’s Agentforce marketing demos and the capabilities actually shipping to customers. This is the kind of gap that opens predictably when promised functionality is technically possible but uneconomical to serve at the price the seat plan implies. Salesforce is the most-watched case, not a unique one.”For my team, the cost of compute is far beyond the costs of the employees.” — Bryan Catanzaro, VP of Applied Deep Learning, NvidiaThe strategic implication is not “AI is expensive.” It is that the dominant business model assumed by most AI-native company plans does not survive contact with agentic workloads. A simple exampleConsider an enterprise software vendor charging $40 per-user per-month for an AI-enabled support assistant. A traditional chatbot might cost only a few cents per user per day in inference, leaving healthy gross margins.Now replace that chatbot with a fully agentic workflow capable of investigating tickets, querying internal systems, drafting responses, validating outputs, and escalating exceptions. If a heavy user executes 50 to 100 agent requests per day, inference consumption can increase by an order of magnitude. What was once a negligible infrastructure cost becomes a material operating expense.This creates an unusual dynamic: The customers receiving the most value from the product are often the customers generating the highest inference costs. In extreme cases, vendors can find themselves with their most engaged users contributing the least profit. The result is a growing realization across enterprise software that agent adoption and margin expansion are no longer automatically aligned.Agent orchestration is the new moatThe technical responses are known and converging. They are not novel, but they are critical for survivalCost-aware routing: This technique involves a small classifier model that decides which tier (Haiku, Sonnet, Opus equivalents) handles each query. Well-tuned routers cut inference bills by around 60% without any degradation in qualityPrompt caching: Anthropic, OpenAI, and Google now offer 75 to 90% discounts on cached prefixes. Context discipline: You can truncate tool outputs, prune reasoning traces, and cap tool depth to prevent your agent from going down a rabbit holeSpeculative decoding: for self-hosted deployments, this technique guarantees 2 to 3X effective throughput on the same GPUs.”Organizations using orchestration-led governance report stronger productivity gains — a holistic orchestration layer is associated with six times greater productivity impact than compliance‑only approaches” — IBMThe companies building this layer well are starting to look less like microservice operators and more like financial trading systems: Every routing decision priced, every path with its own P&L, every tenant on a metered budget.What enterprise leaders should actually doFour moves separate the companies that will still have margin in 24 months from the ones that won’t:Make inference cost a first-class metric. Track it per-feature, per-tenant, per-query class the same way cloud cost was tracked starting in the mid-2010s.Budget like a media buyer. Set cost-per-thousand-queries ceilings per feature. Cap them. Alert on overruns. Engineering will not enforce this on its own.Treat the router as core infrastructure, not an optimization. It is the new load balancer.Audit prompts quarterly. A 4,000-token system prompt that grew organically over six months is a six-figure bill in slow motion. Most teams have never read their own production prompts end to end.Negotiate volume commits early. Frontier-model vendors now offer reserved-instance-style prepaid commits at substantial discounts. List price is the worst price any enterprise will ever pay.The next 24 monthsThe structural shift underneath agentic AI is not that it is expensive. As DeepSeek’s price cut today underscores, frontier inference unit costs are dropping roughly 3X per year, and the curve is not slowing.The shift is that amplification is outrunning the price cuts. Cutting per-token costs 75% does not help a company whose agents are doing 700X more tokens per user query than its pricing model assumed. For the first time since the cloud era began, architecture decisions are again financial decisions in real time. A prompt redesign is a margin event. A poorly bound agent loop is an outage with a credit card attached.The companies that survive the next 24 months of AI infrastructure pricing will not be the ones running the cheapest model. They will be the ones whose agents are smart and know what they cost to think.That is the 100X problem. And it is arriving faster than the price cuts can hide it.Maitreyi Chatterjee is a senior software engineer at a big tech company.Devansh Agarwal works as an ML engineer at a leading tech company.

Slopsquatting represents an emerging supply chain threat made possible by AI hallucinations. As developers increasingly rely on AI coding assistants, they unknowingly grant cybercriminals access to their software from day one. Understanding what slopsquatting isSlopsquatting is a new type of supply chain attack that uses large language model (LLM) hallucinations to inject malicious code into development workflows. The term combines “AI slop” and “typosquatting,” a deceptive practice where attackers register misspelled or lookalike versions of popular domains to prey on users who enter URLs incorrectly.This novel attack vector exploits LLMs’ tendency to generate fictitious software package names, which threat actors can then register and populate with malicious code.During AI-assisted coding, the model may generate fake open-source packages — bundled collections of files, programs and installation tools. This alone is not necessarily harmful. However, if an attacker registers that fake package name, they can inject malware that gets incorporated directly into a developer’s codebase.How AI creates a supply chain riskTraditionally, AI safety risks stem from hallucinations, which can adversely affect users who treat misinformation as valid. However, those same hallucinations have evolved into exploitable security vulnerabilities.Typosquatting is a deceptive practice where a cybercriminal registers a mispelled version of a popular package to trick developers. It has existed for decades, so registries have built protections against it. However, AI has changed the threat model. It recommends fictitious packages that sound plausible rather than making simple misspellings. Once attackers learn which hallucinated packages models tend to invent, they can register malware-filled packages under those names.Since the hallucinated packages are not simply typoed versions of popular libraries, there are no protections against this practice at scale. For example, the registry protects against an attacker publishing “crossenv,” a squat of the popular “cross-env” package. However, it would not identify “mpn install cross-env file” or “cross-env-extended” as threats.Hallucinations are persistent and severeEven if many LLMs recommend the same hallucinated package, widespread compromise is still possible. Malicious packages could remain undetected in production for months or even years, allowing threat actors to passively inject malware across countless environments. One research team analyzed 31,267 vulnerabilities belonging to 14,675 packages across 10 programming languages. They discovered that reported vulnerabilities are increasing at an annual rate of 98%, faster growth than the 25% annual increase in the number of open-source software packages. The team also observed an 85% increase in the average lifespan of vulnerabilities, indicating a decline in security.Real-world dangers of AI hallucinationsMalicious actors can create open-access packages under the same name as commonly hallucinated libraries. Instead of standard code, they are filled with malware. The models believe they are referring to existing packages, so they often repeat the same hallucinated names. Since the hallucinations are not random, attackers could theoretically register packages that trick tens of thousands of developers.These packages appear legitimate. String similarity to real libraries makes them recognizable. One-character typos suggest simple mistakes rather than malicious intent. Even fully fabricated names remain believable when the AI presents them in proper context. Detection is challenging, as developers trust their coding assistants to recommend valid dependencies.Why are LLMs hallucinating packages?LLMs generate the statistically most likely answer rather than prioritizing accuracy. Hallucinations are relatively common as a result. One study found hallucination rates range from 50% to 82%, depending on the model and prompting method. Even GPT-4o, the best-performing model, goes no lower than 23%, even with prompt-based mitigation.Adversarial hallucination attacks could worsen this problem. Threat actors can leverage token-level manipulation or retrieval poisoning to force models to hallucinate in ways they want, increasing the likelihood that models recommend their malicious packages.Which LLMs are prone to slopsquatting?While all LLMs are prone to slopsquatting, some are more vulnerable than others. The likelihood of producing hallucinated packages during code generation depends on the model. Proprietary models are four times less likely to generate hallucinated packages than open-source models.One research group proved this by conducting 30 tests across 30 different systems. Out of the 576,000 code samples and 2.23 million packages it produced, 19.7% were hallucinations. GPT-4.0 Turbo had a hallucination rate of 3.59%, while DeepSeek 1B, the best-performing open-source model, reached 13.63%.This research suggests that organizations relying on open-source AI tools for code generation are roughly four times more exposed to slopsquatting attacks. That doesn’t necessarily mean proprietary tools will always remain safer, though. Once attackers realize this disparity, they may manipulate proprietary LLMs to take advantage of perceived safety.Vibe coding contributes to the problemSoftware developers who use AI tools estimate that over 40 percent of the code they commit includes AI assistance. They expect that percentage will increase considerably within the next few years. Already, 72% of those who have tried AI use it daily.The uptick in vibe coding and AI-assisted coding amplifies the threat surface. As more developers integrate AI tools into their workflows without implementing proper verification processes, the attack surface for slopsquatting continues to expand.For those using AI to assist with coding, double-checking output is essential. Verifying that recommended packages actually exist in official repositories before incorporating them into projects reduces risk.Navigating AI-assisted developmentImplementing automated checks that validate package names against known registries can help catch hallucinated packages before they enter production code. Security teams should also monitor for unusual package installations and maintain up-to-date threat intelligence on known slopsquatting campaigns.Zac Amos is the Features Editor at ReHack.

An enterprise AI agent answers with total confidence, but the number is wrong. Nobody catches it until someone traces it back to a stale metric definition or a document the retrieval system never pulled. The model did not fail. The context it was given did.In the past six months, 57% of enterprises traced a confident but wrong AI agent answer to missing or inconsistent business context, and 31% said it happened more than once, according to a VB Pulse June 2026 survey of 101 qualified enterprises with more than 100 employees.The reason is not hard to find. Retrieval over documents is the default way agents get business context for 38% of enterprises, nearly double the next closest approach. The way most enterprises choose a retrieval system compounds the problem. Ease of ingestion and operational simplicity lead the selection criteria, with retrieval accuracy running behind both. The accuracy problem only shows up after the system is already live.There is a known fix for this, a governed context layer every agent reads from instead of guessing. Vendors are racing to roll out context platforms while most enterprises are still figuring out what it is.75% don’t have an agentic context layer yetThe context layer is meant to be a shared model of what business data actually means, built once and referenced consistently instead of re-derived by every agent that touches it. The VentureBeat research shows the enterprise response to that idea is broad but unfinished. Twenty-five percent of respondents run one in production. Thirty-four percent are building one right now. The remaining 41% have not started.Among companies already building or running a governed context layer, 78% report a confident-wrong failure — an AI agent that answered with total certainty and was still wrong. Among companies with no plans to build a layer, only 20% report the same thing. Companies that already got burned are far more likely to be building the fix. Companies that haven’t been burned yet see no urgency.What governed context looks like when someone actually builds oneEvery major data and AI platform vendor is now building some version of this layer, and they are not converging on the same architecture. DataHub is treating catalog metadata and years of analyst query behavior as a knowledge source, then keeping it current as a living system rather than a static wiki. Microsoft’s Fabric IQ is building a business ontology that any agent, not just Microsoft’s own, can query over MCP. Couchbase is pushing agent memory and context retrieval down to the edge, arguing the operational database is a more natural home for it than a search or analytics layer bolted on after the fact. Pinecone’s Nexus is compiling structural logic into the metadata layer ahead of runtime, betting that agents need pre-built structure more than they need faster search.Snowflake runs a two-layer system, Horizon Context for customer-managed definitions and Cortex Sense for context the platform infers on its own. Oracle’s Unified Memory Core takes the opposite approach, folding vector, graph and relational data into one transactional engine so there is no sync layer left to go stale. Google’s Knowledge Catalog mines query logs and usage patterns to curate semantic context automatically.AWS’s Context service makes the same bet, a knowledge graph that gets smarter from how agents actually use it rather than from manual re-curation.Analysts converge on one diagnosisThe vendor approaches differ. What analysts and practitioners have told VentureBeat about the underlying problem, across a run of interviews this year, does not.When DataHub’s context layer push landed this spring, Constellation Research VP and principal analyst Michael Ni framed the stakes in blunt terms. “Whoever controls runtime context controls the AI decision layer for enterprise data,” Ni said. He was equally direct about how far any single product actually gets a buyer. “Vector memory isn’t business meaning, business meaning isn’t governance and governance isn’t execution,” Ni said.In the same interview, BARC analyst Kevin Petrie pointed to a narrower but concrete gap. Most context platforms concentrate on structured tables, he said, which give agents trusted facts but miss the harder, messier context locked in documents and unstructured content, exactly the material a business actually runs on day to day.Stephanie Walter, practice leader for AI Stack at HyperFRAME Research, made a related point earlier this year when VentureBeat asked her about enterprise context fragmentation. “The market is converging on the same conclusion,” Walter said. “Agents don’t just need more tokens or better models. They need governed, current, low-latency context.” She made a similar case in an earlier review of Pinecone’s Nexus launch, careful not to overstate how new any of this is. Nexus, she said, “shifts knowledge work from runtime chaos to pre-compiled structure. But it’s an evolution of RAG architecture, not a complete reinvention.” Gartner’s Arun Chandrasekaran, reviewing the same launch, offered the more forward-looking read. Agentic AI, he said, is moving from pure information retrieval toward a reasoning architecture, one where long context works as short-term memory and a vector database functions as deep storage underneath it.The fragmentation problem shows up hardest at the practitioner level, where separate tools for retrieval, memory and access control were never built to agree with each other. Steven Dickens, CEO and principal analyst at HyperFRAME Research, put it bluntly after Oracle’s AI database push landed this spring. “Data teams are exhausted by fragmentation fatigue,” Dickens said. “Managing a separate vector store, graph database and relational system just to power one agent is a DevOps nightmare.” Matt Kimball at Moor Insights and Strategy, in that same story, put the production reality more simply. Getting an agent working is not the hard part, he said. The struggle is running it in production, where the goal becomes removing the distance between data and execution rather than adding another layer on top of it.What this means for enterprisesHere’s what this adds up to for enterprises building on this layer.Retrieval alone will not close the context gap. RAG is the default source for context in most enterprises today, and it is also the layer most closely associated with the confident-wrong-answer failure. Adding more documents or a bigger index does not fix a definition that is inconsistent across systems.The semantic context layer is where the budget is actually moving, even where it hasn’t shipped. Fifty-eight percent of enterprises are already engaged — building or in production — but only 25% have actually gotten a layer live. That gap shows where enterprises have decided to spend, not where they’ve arrived.No single vendor owns the architecture yet, and that is likely to stay true for a while. Enterprises evaluating this layer should expect to integrate rather than pick a single winner, at least for the next several quarters.The buying decision is happening this year, and it is concentrated among the companies already burned by it. Fifty-seven percent of enterprises plan to switch or add a retrieval or context platform within the next twelve months. That intent is not spread evenly. Enterprises that reported a repeat confident-wrong failure plan to switch or add a provider at roughly 81%, against 32% among enterprises that never hit the problem. The companies shopping for new context tooling right now are largely the ones whose agents already got it wrong. The agents are already running. The context underneath most of them is still being built, and the vendor selling the fix is being chosen this year.This data will be part of a broader conversation at VB Transform 2026 on July 14 and 15 in Menlo Park: the context gap enterprises are racing to close, and which of the emerging approaches — governed semantic layers, hybrid retrieval, provider-native bundles — actually holds up in production.