VentureBeat

9/3/2026

Google keeps cranking out Flash models: the company on Wednesday announced two versions of a new 3.8 Flash.  The variants include a standard Flash, a “workhorse” model for agentic tasks, software development, and multi-step reasoning, and Flash Cyber optimized for vulnerability detection and mitigation. Google CEO Sundar Pichai said in an X post that 3.8 Flash delivers “significant leaps” from 3.7 Flash across software engineering, agentic tasks, and multi-step reasoning. For instance, it outperformed many large frontier models on the DeepSWE coding benchmark, at far lower cost.  Meanwhile, Flash Cyber is the company’s “most capable” cybersecurity model, Pichai said; it also matches frontier-level performance when it comes to discovering vulnerabilities and patching them at scale. The model achieved 86.2% on the CyberGym cybersecurity benchmark and 47.2% on CWE-Bench, which evaluates AI patching abilities. In an internal Google benchmark, the model achieved a more than 70% success rate discovering vulnerabilities across 20 programming languages, Pichai said.  3.8 is Google’s third Flash release in six weeks and comes quickly on the heels of version 3.7.  3.8 working "harder" with "greater diligence" 3.8 Flash is available now in Gemini Enterprise; devs can try it out in the Gemini API via Google AI Studio, Google Antigravity, Android Studio, or generate UIs in Stitch. It is priced at $0.75 per million input tokens and $3.75 per million output tokens — the same introductory pricing as Gemini 3.7 Flash — and users can customize and adjust model effort levels based on their needs around quality, cost, and latency. For instance, when compute efficiency is a priority, they can adjust to lower token overhead, or simply continue working with 3.7 Flash, which is “fully supported for efficiency-first workloads,” Google senior product director Tulsee Doshi and Gemini security lead Raluca Ada Popa wrote in a blog post.  “3.8 Flash works harder,” exhibiting “greater diligence” with complex tasks like executing extra reasoning steps, although at times it may use more tokens to maximize performance, Doshi and Popa note. The model has a 1M-token input window and a 64K-token output limit, and can ingest text as well as images, audio, video, and PDF files.  3.8 Flash was evaluated across numerous benchmarks testing coding, multimodal capabilities, computer use, long-context and knowledge work, and scientific reasoning. Google says it also does well in specialized knowledge domains requiring more in-depth analysis and reporting. For instance, the model outperformed its predecessor and other frontier models on benchmarks like Vals Finance Agent V2 for finance, and Harvey's Legal Agent Benchmark for law; it also scored 54.9% on Humanity’s Last Exam (HLE)-Verified, reflecting its ability to take on multi-step reasoning tasks across subjects like math, science, and humanities.  In one example shared by Google, Gemini 3.8 Flash built a game with a simple prompt using looping techniques in Google’s Antigravity platform. The game uses puzzles, storytelling that changes based on the environment, and images and textures from Nano Banana to create a 3D experience (in this case a wizard navigating a castle).  In other instances, the model created a fully-functional DOS version of Google Maps featuring interactive locations, directions, and street views; a 3D visualizer that automatically decomposed devices into layers for inspection with a slider capability; and a topographic map of famous geographical sites based on real datasets from the U.S. Geological Survey, complete with real-time cross-sections, 2D projections, and scientific explanations.  According to Arena.ai, 3.8 Flash landed at No. 14 in Agent Arena, ranking above DeepSeek-V4-Pro, and showed a significant jump over Gemini 3.7 Flash (which sits all the way down at No. 32). It debuted at No. 7 in Text Arena, ahead of Claude Opus 5 and Gemini 3.7 Flash. It improved over 3.7 Flash in several areas: multi-turn requests, writing, literature, and language, longer queries, hard prompts, coding, instruction following, software and IT services, and business, management and financial ops.  Flash Cyber is already securing Google's code Flash Cyber is initially being rolled out to “trusted defenders” through Google’s Fairwind Program, which prioritizes government authorities, critical-infrastructure operators, and other partners looking for advanced cyber defense capabilities. Organizations can apply for access.  Google says the model version has undergone “rigorous training” in the cybersecurity domain and represents a “significant leap in prompt injection robustness.” It is particularly adept at autonomous vulnerability discovery — at least, based on internal Gemini benchmarks — and automated patching. It is also very good at coding, Popa said in a video.  The goal was to equip defenders with expert-level capabilities to give them a leg up over threat actors (whether malicious, fellow AI agents, or human hackers). “We have invested in vulnerability fixing from the start, and prioritized it over offensive capabilities like exploitation,” Doshi and Popa explain.  The model ships a more permissive set of mitigations for cybersecurity safeguards — which is why, for now, it is only being shared with limited partners — and safeguards against misuse in cyber offense and areas like chemical, biological, radiological, and nuclear (CBRN). Google is already using 3.8 Flash Cyber to secure its own code; it produced 2.6 times more correct patches in Chrome vulnerabilities versus much larger commercial models.  Wiz — which Google acquired earlier this year at a historic $32 billion — reported that 3.8 Flash Cyber had 7.5% to 9.7% higher recall of real-world vulnerabilities on an internal penetration testing benchmark at 2.3 to 5.2 times lower cost than leading frontier models. Similarly, Google’s Cloud Vulnerability Research found a critical foundational vulnerability in less than 2 hours with 3.8 Flash Cyber. Typically, that research and discovery would take months, Google claims.  AI agents are “incredibly skilled” at finding and exploiting vulnerabilities, Popa said. Scanning large codebases with big AI models is expensive, and defenders are overwhelmed. “In cybersecurity, attackers need only find one significant flaw over millions of lines of code. Defenders have to remove every one of those flaws to be able to defend against attackers.”  Doug Turner, engineering director for Chrome, described a “vulnerability apocalypse” in recent months due to generative AI. “Simply overnight, we saw a hockey stick increase in the number of software vulnerabilities reported through our vulnerability research program,” he said in a video.  One interesting vulnerability 3.8 Flash Cyber discovered had been in Chromium and Chrome for 13 years, he explained. It was a “very subtle bug” that dozens, if not hundreds, of engineers looked at but never flagged. “Gemini 3.8 Flash Cyber is going to allow us to create better suggested fixes so that developers’ lives can get a lot easier.”

9/2/2026

Meta is entering the increasingly competitive real-time speech-to-text market with Muse Voice Transcribe, a new audio perception model that combines streaming transcription, endpoint detection and speaker diarization for more than 20 speakers — at a public API price of just $0.18 per hour of processed audio. Developed by Meta Superintelligence Labs, Muse is designed to process speech while it happens rather than waiting for a recording to finish. Meta’s launch post for Muse Voice Transcribe says the model supports long audio exceeding an hour, seamless multilingual code-switching, language and keyword biasing, and diarization without a separate post-processing pipeline. The model was trained across more than 70 languages, with 25 extensively validated for the initial release. The 20-plus-speaker figure is substantial, but it is not a world record. A review of current vendor documentation turns up systems with higher published ceilings. Speechmatics' real-time transcription service says it can identify 50 speakers by default and up to 100 when the limit is increased, while Amazon Transcribe's diarization documentation specifies a maximum of 30 unique speakers, including for streaming transcription. (Speechmatics) Muse nevertheless lands toward the high end of the market, and Meta's broader proposition is arguably more important than the raw maximum: high-capacity real-time diarization combined with low-latency transcription, endpointing, multilingual code-switching and aggressive API pricing in the same model. For enterprise developers building meeting systems, call analytics, live assistants or ambient AI, that combination could matter more than who holds the speaker-count record. Diarization is becoming part of the core voice stack Traditional speech recognition answers a relatively simple question: What was said? Diarization adds another: Who said it? That distinction becomes critical as transcripts feed downstream AI systems. A meeting assistant can correctly transcribe every sentence and still create an unreliable corporate record if it attributes an approval, commitment or objection to the wrong participant. The same issue affects customer-service analytics, compliance workflows and AI agents operating in rooms where several people can speak. Muse incorporates speaker attribution directly into its autoregressive multimodal architecture. Meta says audio arrives in 80-millisecond chunks, or 12.5 chunks per second, with each transformed into a soft token. At each step, the model decides whether to consume more audio or emit text. Meta calls this mechanism adaptive delay: rather than applying one latency budget to every word, Muse can wait longer when speech is ambiguous and commit earlier when it has enough context. Meta says reinforcement learning combines word-error-rate and delay rewards to train that behavior. Meta's technical explanation of Muse details the architecture. (Meta AI Research) Speaker attribution and endpointing then become part of the same token sequence. A <|start_of_turn|> token marks a potential new speaker turn, tokens such as <|speaker_A|> identify the speaker, and separate onset and endpoint tokens identify speech boundaries. Meta says it trains ASR, diarization and endpointing together rather than running speaker clustering as an unrelated downstream process. Meta's Model API speech-to-text documentation also exposes diarization as a first-class operating mode alongside push-to-talk and endpointing. Speaker labels such as A and B are scoped to a session rather than verified identities, and the API provides turn-level rather than word-level timestamps. 20+ speakers is high, but Speechmatics goes considerably higher Speaker-count comparisons require care because vendors implement diarization differently and do not all publish a maximum. Speechmatics currently makes the strongest explicit real-time capacity claim found in this review. Its real-time STT documentation says speaker diarization is available live, while its real-time FAQ says the system supports 50 speakers by default and can be increased to 100. AWS likewise exceeds Meta's stated figure: Amazon Transcribe can differentiate a maximum of 30 unique speakers, and AWS provides explicit instructions for speaker partitioning in a streaming transcription. Soniox supports diarization in both real-time and asynchronous processing, but documents a maximum of 15 speakers per session. AssemblyAI's streaming diarization system lets developers set max_speakers between one and 10. Both companies caution that live speaker attribution is more difficult because streaming systems must make decisions with less future audio context than offline models. xAI's current Speech-to-Text API also supports speaker diarization in streaming mode, but its documentation reviewed for this story does not publish a maximum diarized-speaker count, so a direct ceiling comparison with Muse is not possible. (X.ai Docs) That means it would be inaccurate to describe Muse's 20-plus capability as a new global record. The highest explicitly documented real-time number identified in this survey is Speechmatics' configurable 100-speaker ceiling. Meta also does not demonstrate 20-plus simultaneous participants in its launch material. Its principal live demonstration uses eight speakers, while its long-form recording contains 11 labeled participants. The 20-plus number is a stated model capability rather than the participant count in the public demos. At $0.18 per hour, Muse competes aggressively on price Meta's pricing makes the competitive picture more interesting. According to its Muse Voice Transcribe developer page, Muse costs $3 per 1,000 minutes, or $0.18 per hour. Streaming and non-streaming transcription cost the same, and Meta says zero-data-retention processing is priced at parity with standard processing. Billing applies to audio actually processed and is rounded down to whole seconds. Standardizing publicly posted rates to one hour of streaming audio gives the following rough comparison: Streaming speech-to-text service Approx. public cost/hour Real-time diarization Soniox stt-rt-v5 $0.12 Included; up to 15 speakers Meta Muse Voice Transcribe $0.18 Included; 20+ speakers xAI Speech to Text $0.20 Supported; maximum not stated Speechmatics Real-time Standard $0.24 Included; 50 default, configurable to 100 Qwen3 ASR Flash Realtime ~$0.324 international No comparable maximum documented in source reviewed Deepgram Nova-3 Multilingual ~$0.35 base / ~$0.47 with diarization $0.12/hour diarization add-on ElevenLabs Scribe v2 Realtime $0.39 PAYG Not supported in real time AssemblyAI Universal-3.5 Pro Realtime $0.45 base / $0.57 with diarization $0.12/hour add-on; up to 10 speakers Gemini 3.5 Transcribe Live ~$0.54 blended Not supported in live mode Amazon Transcribe Streaming ~$0.60 in AWS's N. Virginia streaming example Included; up to 30 speakers OpenAI GPT Live Transcribe $1.02 Diarization not listed as a model capability The comparison is necessarily imperfect. Qwen's price varies by deployment geography; its international real-time rate of $0.00009 per second works out to about $0.324 per hour. Google's Gemini figure is an estimated blended token cost rather than a flat hourly tariff. AWS prices vary by region and usage tier. ElevenLabs lists $0.39 per hour on its API pricing page but advertises $0.28 per hour or lower on annual Business plans. Deepgram's pricing particularly illustrates why feature-level comparisons matter: its current Nova-3 Multilingual streaming rate is about $0.35 per hour, but speaker diarization costs another $0.002 per minute, bringing the comparable total to roughly $0.47 per hour. AssemblyAI similarly lists $0.45 per hour for Universal-3.5 Pro Realtime and another $0.12 per hour for streaming diarization. Cartesia is harder to normalize because Ink-2 is packaged through monthly credit plans rather than a simple metered PAYG hourly rate. Its $5 Pro plan includes roughly nine hours and 16 minutes of Ink-2 transcription, which works out to about $0.54 per transcription hour if every credit is consumed exclusively on STT. That should not be treated as equivalent to a standalone $0.54 hourly API tariff. Even with those caveats, Muse's positioning is clear. It is not the absolute cheapest streaming transcription service — Soniox currently publishes a lower equivalent rate — but $0.18 per hour with diarization included puts Meta toward the low end of the market, especially against providers that charge separately for speaker attribution. At 1,000 hours of processed audio, Meta's public rate implies roughly $180 in transcription charges. Meta also leads its launch accuracy benchmarks Price matters less if it comes with a large accuracy penalty. Meta's benchmark material argues the opposite. On the Artificial Analysis AA-WER Streaming Index supplied with the launch, Muse records a 3.1% final-transcription word error rate, ahead of Cartesia Ink-2 at 3.4%, ElevenLabs Scribe v2 Realtime at 3.6%, Qwen3 ASR Flash Realtime at 3.7%, GPT Live Transcribe and Grok Speech to Text Streaming at 3.9%, and Gemini 3.5 Transcribe Live and AssemblyAI U3.5 Realtime Pro at 4.0%. Meta points out that Muse took the number one spot on third-party independent AI benchmarking firm Artificial Analysis' streaming speech-to-text evaluation as of September 1. Meta published the following benchmark charts in its launch post. Its diarization result may be even more relevant to the product's positioning. Meta reports an average 17.5% diarization error rate across AMI-IHM, AMI-SDM and VoxConverse, lower than the competing systems shown in its chart. Speaker capacity and diarization error rate should not be conflated. A platform capable of representing 100 people is not automatically better at correctly attributing speech than one supporting 20, and Meta's benchmark does not test every competitor operating at its advertised maximum speaker count. There are deployment tradeoffs as well. Meta's API currently provides turn-level but not word-level timestamps, and it does not expose word-level confidence scores, sound-event detection or emotion detection. The documentation also specifies eight concurrent streams per tenant by default and real-time sessions of up to 60 minutes before an application must reconnect. Still, Muse's launch creates an unusually sharp price-performance proposition. Its 20-plus-speaker diarization does not establish a world record, but the record may be the less important metric. For enterprise developers, the larger question is whether a service can preserve speaker attribution, accurate text and usable turn boundaries while a complicated real-world conversation is still unfolding. At $0.18 per hour, with 20-plus-speaker diarization inside the same real-time model that currently leads Meta's supplied streaming accuracy benchmarks, Muse Voice Transcribe gives enterprise teams a serious new option for meeting intelligence, live transcription and voice-agent infrastructure — while putting additional pressure on competitors to compete on speaker-aware accuracy and total operating cost, not merely raw speech recognition.

9/2/2026

When enterprise buyers build out their next AI accelerator evaluation list this cycle, they're more likely to put a non-Nvidia chip on it than Nvidia's own next-generation GPU. According to VentureBeat's July VB Pulse survey of 170 AI infrastructure respondents, 39.4% said they're likely to evaluate non-Nvidia accelerators — AWS Trainium, Google TPU, AMD Instinct, Intel Gaudi or in-house ASICs — over the next 12 months, compared with 25.3% for Nvidia Blackwell (GB300) or other next-generation Nvidia GPUs, a 14-point gap. Nvidia remains the default in most production environments. But organizations are building real optionality into their accelerator strategy rather than treating Nvidia as the only evaluation worth doing. The finding sits inside a broader pattern: enterprises are expanding and optimizing the AI infrastructure they already operate before making another major platform change. Greater infrastructure activity did not produce greater urgency to switch platforms. The share of respondents expecting a platform change within three months fell from 38.3% in June to 28.8% in July, even as production adoption, accelerator utilization, and exploration of neoclouds and open-source infrastructure all rose. Where is enterprise AI infrastructure actually growing? The July data shows organizations operating AI infrastructure more intensively and putting more provider platforms into production. Microsoft Azure posted the largest production adoption growth among the major platforms measured, with the share of respondents reporting Azure in production increasing from 29% in June to 47.1% in July, an 18.1 percentage-point increase. Some of that jump reflects who was surveyed: July's respondent base skewed more up-market than June's (57% at organizations above 1,000 employees, versus 37% in June), and Azure adoption rises with company size in both waves. Google's Gemini was the most-used platform in both waves, with the share of respondents reporting it in production rising from 41.1% in June to 47.6% in July, narrowly ahead of Azure. The share of respondents reporting OpenAI in production rose from 40.2% to 49.4%. Anthropic production adoption increased from 12.1% to 24.7%.  Among enterprises that operate their own GPUs, the share running at half capacity or less fell from 83% in June (100 respondents) to 69% in July (155 respondents), with the share above 50% utilization rising from 13% to 23%. The definition of infrastructure effectiveness is also becoming more operational. The share of respondents who selected uptime and reliability as important effectiveness measures increased from 42.1% to 51.2%. The share selecting throughput rose from 21.5% to 24.7%. Ease of implementation improved from an average rating of 3.84 to 4.04 on a five-point scale. Overall satisfaction moved only slightly, from 4.07 to 4.14, while perceived value was essentially unchanged at approximately 3.9. That combination is telling. Enterprises are not reporting a dramatic improvement in value simply because they are deploying more infrastructure. They are becoming more capable operators with better architectures, but they are also setting a higher bar for what that infrastructure must deliver, with reliability leading the way. Why is platform-change urgency shifting outward? The strongest counter-signal in the July findings is the declining share of respondents who plan to make an immediate platform change. The share expecting a change within zero to three months declined by 9.5 percentage points. The share expecting a change within three to six months rose by 4.1 points, while the six-to-12-month window rose by 5.3 points. The share with no planned change remained effectively flat at approximately 40%. Urgency is shifting outward, with the open-weight-model and open-source-harness debate playing a role in which pieces get enhanced versus fully replaced. The selection criteria support that interpretation. Integration with existing cloud and data stack was the top factor in both waves, holding steady at 41.1% in June and 40.0% in July. The share of respondents prioritizing performance increased from 24.3% to 35.3%. The share prioritizing cost per million tokens increased from 7.5% to 15.9%, while the share prioritizing access to GPUs rose from 18.7% to 23.5%. By contrast, the share selecting broad total cost of ownership as a leading factor fell from 34.6% to 21.8%. The market appears to be moving from general infrastructure planning toward workload-level scrutiny. Buyers increasingly want to know how a platform performs under production inference, how reliably it operates and what each unit of useful work costs. Interest in Nvidia alternatives is concentrated at the top That 39.4% figure was 31.8% in June, already climbing before this wave. The alternatives enterprises are weighing include AWS Trainium, Google TPU, AMD Instinct, Intel Gaudi and other in-house ASICs. Interest was even stronger among respondents with strategic purchasing authority, though the C-suite sample is small: the share of C-suite respondents likely to evaluate non-Nvidia accelerators rose from 42.9% (6 of 14) in June to 57.1% (12 of 21) in July. Among final decision-makers, the same interest rose from 35.4% to 50%. This was especially true for organizations in the small and medium-size business tiers. Among organizations with 251 to 1,000 employees, the share increased from 41.4% to 53.2%. Among organizations with 101 to 250 employees, it rose from 33.3% to 57.7%. These findings show organizations building optionality into their accelerator strategy. The increased attention from C-suite respondents and final decision-makers suggests that accelerator diversity is becoming a strategic infrastructure question, not just a technical one for engineering teams. Enterprises want to own the harness The infrastructure findings align with a separate VB Pulse survey of agentic context layers. That survey included 101 substantive respondents in June and 101 respondents in July. The AI harness is the operational layer connecting models to enterprise data, tools, orchestration, evaluation, identity, security, observability and business processes. It determines what an agent can access, which actions it can take and how the organization evaluates its output. In July, 36.6% of context-layer respondents said they planned to retain best-of-breed standalone tools alongside their models. Another 36.6% expected to mix provider-native runtimes with standalone tools, while only 5.9% intended to build and own the context layer in-house. Combined, 79.2% of July respondents favored an approach that maintained at least some architectural control outside a single model provider, compared with approximately 65.3% in June. Only 11.9% of July respondents favored consolidating onto a single model provider’s native context stack, down from 20.8% in June. Most want to preserve provider choice, independent governance or control over critical components around the model. The need for that control is becoming clearer. In July, 62.4% of context-layer respondents reported that a governed semantic or context layer was either in production or being built. Production adoption alone increased from 24.8% to 31.7%. At the same time, 68.3% of July respondents reported experiencing at least one confident-but-wrong agent answer caused by missing or incorrect context, compared with 57.4% of June respondents. The share expecting to use multiple retrieval architectures by use case increased from 12.9% to 28.7%. The share expecting to mix provider-native and standalone context tools increased from 20.8% to 36.6%. The emerging architecture is a controlled combination of models, infrastructure, retrieval approaches, context systems and operational tooling selected by workload. Are neoclouds gaining enterprise traction? Neoclouds are specialized cloud providers focused heavily on AI infrastructure, particularly access to accelerators and supporting services. The July results suggest that these providers are becoming a more credible part of enterprise multi-provider strategies. The share of respondents expecting to do more with neoclouds increased from 33% in June to 38% in July. At the same time, the share expecting to do less with neoclouds fell from 9.7% to 5.4%. The movement was especially pronounced among respondents in the technology and software vertical. The share of that July segment expecting to do more with neoclouds reached 57.6%, compared with 44.4% in June. Current production adoption remains much smaller than broad expansion intent. Across the named providers measured consistently in both waves, such as CoreWeave, Lambda, Crusoe and Nebius, production use increased from 1.9% of June respondents to 5.9% of July respondents. The difference between 38% expansion intent and 5.9% current named-provider production use may point to a sizable evaluation and adoption pipeline. The neocloud demand pipeline is not theoretical. CoreWeave reported around $104 billion in revenue backlog at the end of June, excluding more than $25 billion in additional customer commitments secured during early Q3. Nebius does not disclose a directly comparable backlog metric, but said it could sell its entire 2027 capacity under current terms and reported four second-quarter AI cloud agreements, each averaging more than $1 billion in total contract value. The larger implication is that neoclouds are becoming a viable source of strategic leverage. They give organizations additional options for accelerator availability, software stacks, workload placement and ammunition for negotiations with hyperscale providers. Neoclouds will still have to demonstrate enterprise-grade reliability, security, support, networking, and data management capabilities. Specialized compute access may open the door, but durable enterprise adoption will depend on the surrounding operational stack.  Is open-source AI infrastructure usage growing? The most accurate answer is that open-source production usage is growing, while broad platform consideration remains relatively flat. The share of respondents reporting a custom, self-managed open-source production stack increased from 3.7% in June to 12.9% in July. The stack definition included technologies such as PyTorch, Triton, vLLM, Ray and Kubernetes. The movement was visible across several segments with July bases above 20 respondents: Among individual contributors, 23.9% reported production use in July. Among recommenders and influencers, 13.7% reported production use in July. Among organizations with 251 to 1,000 employees, 12.8% reported production use in July. The share of respondents using open-source key-value cache tooling, including LMCache and vLLM prefix caching, increased from 6.5% to 11.8%. Among technology and software respondents, usage increased from effectively 0% to 13.3%. Open-source platform consideration ticked up slightly but remained essentially unchanged, moving from 5.6% to 6.5%. This combination suggests that growth is concentrated among organizations moving into implementation rather than across a dramatically larger population of evaluators. Open source appears to be deepening inside an active portion of the market. Organizations may be turning to open-source components for greater portability, model choice and control over inference optimization. But ownership also transfers responsibility. Teams adopting self-managed stacks must operate upgrades, security, observability, integration and production support themselves. That combination of more activity, less urgency and more optionality is the throughline across all of it. Enterprises are running more AI infrastructure while deliberately keeping multiple paths open on chips, clouds and the layer that connects models to their own data. The next platform change, when it comes, will be a choice made from a stronger position. Notes on methodology For this article, I compared two independent, cross-sectional infrastructure survey waves: 107 respondents in June 2026 and 170 respondents in July 2026. These waves are not a longitudinal panel, so the findings describe changes between respondent populations rather than changes made by the same organizations. Platform-change timing shares add to slightly more than 100% because a small number of respondents selected more than one window (5 in June, 9 in July). Sample composition changed between the waves. Respondents selecting the 1–100 employee organization-size category were excluded before calculating results. The remaining wave composition still differed, including a larger July share from organizations with more than 10,000 employees. Month-to-month movements should therefore be treated as directional signals rather than proof of causation. No statistical-significance testing was applied to the comparisons reported here. The context-layer findings come from a separate survey, with 101 substantive respondents in June and 101 in July. Those results use a different respondent base and are included as supporting evidence, not combined with the infrastructure-survey results.

9/2/2026

Infostealers replayed stolen Claude session cookies into paid accounts without ever touching the login page two-factor authentication guards. The accounts Anthropic flagged were card-billed, self-serve accounts, which is the population no corporate identity provider governs, and no admin console can sign out. Session-cookie replay bypasses SSO as thoroughly as it bypasses 2FA. What SSO provides here is revocation and visibility, not prevention. The company disclosed the campaign in notification emails to affected users, named six stealer families, signed the accounts out, stripped the saved payment methods, and refunded the charges it found. The burned usage is the small loss. What those sessions could reach is the exposure, and none of it sat behind an identity controlled by an enterprise. Anthropic told affected users that a bad actor was using common infostealer malware to lift Claude login sessions off their computers and then replaying them to burn the accounts' usage, according to the notification an affected user posted to Reddit and BleepingComputer reported on August 30. It named Vidar, LummaC2, StealC, RedLine and Acreed on Windows and Atomic Stealer on a small number of Macs, and it described general-purpose malware that copies browser login cookies along with saved passwords. "Your Claude session was likely one of the many things it collected," the email said. A session cookie is the proof that a login already happened The attack chain runs in one direction, from an infected machine through a stolen cookie past a checkpoint that never fires, and into everything the account can reach. Signing the accounts out worked because a replayed cookie dies with the session it copies. Two-factor authentication guards the login page. The site then hands the browser a cookie so the user stays signed in, and an attacker who copies that cookie and replays it looks to the server like the person who already passed the check. Help Net Security described the mechanism on August 31 as session theft becoming the new credential theft. Anthropic spotted the theft in the usage meter. Limits were refilled and drained while the owner was away from Claude, the company wrote. One Redditor who received the notification traced the infection to a pirated game, per BleepingComputer. That is one machine, and Anthropic has not said what the others ran. Anthropic's notification gave no count. The company had not responded by publication to VentureBeat's questions on how many accounts were affected, whether any Team or Enterprise seats behind SSO were among them, or whether the replayed sessions reached conversation history or connected apps rather than usage alone. Removing a saved card and refunding charges point to directly billed, self-serve accounts that authenticate through Anthropic's own login rather than a corporate identity provider. Those include personal subscriptions. Team and self-serve Enterprise organizations can also be card-billed, so the deduction is strong rather than closed. Bugcrowd CEO Dave Gerry told Axios in early August that his company sent employees nearly a dozen emails saying the OpenClaw agent was not allowed on corporate networks, and employees kept trying to download it anyway. A personal Claude subscription on a managed laptop is the same reflex, and it comes with a card on file. LayerX data in Akamai's enterprise AI risk report found 47% of enterprise AI conversations run through personal identities, with Claude at 61%. The pirated game is one vector. In July, attackers hosted a spoofed Claude download page on the claude.ai domain itself through a public Artifact, and a sponsored Bing ad sent employees searching for "Claude Desktop app" straight to it. Huntress documented the campaign, named FakeAgent, after SectopRAT compromised employees at 29 organizations in two days. The artifact collected roughly 7,100 downloads before Anthropic removed it. A separate campaign pushed a fake Claude installer through a spoofed download site earlier in the year, per Malwarebytes. The vector is not piracy. It is enterprise employees searching for the official app on their work machines. Refunds cover the usage. Nothing covers the connectors A replayed session inherits everything the legitimate one could reach, and Anthropic has not said whether these did. On a Claude account, that means the conversation history, the files uploaded into projects, and any connectors the owner authorized. Anthropic's help center states that connectors let Claude retrieve data and take actions inside connected services and that Claude inherits each person's permissions from the connected service. Read and search operations run without approval. Write actions, including send, reply, forward, share, move, and trash, are approval-gated by default. The exfiltration path is the one that is open. Google Workspace connectors are available to individual Claude accounts, so a personal Pro subscription can hold a live authorization into a Gmail inbox or a Drive folder. If that inbox is the work inbox, the attacker holding the replayed cookie has a read path into it that the corporate identity provider evaluated once, at the moment the employee clicked allow, and rarely again. On a personal plan, the employee owns that grant. No Claude tenant administrator can sign that account out, and the Workspace or Entra administrator who can pull the underlying grant rarely knows it exists. Adam Meyers, CrowdStrike's senior vice president of counter adversary operations, put numbers to the market in an August 6 Axios interview. Criminals have been buying and reselling stolen ChatGPT, Claude and Gemini credentials since ChatGPT took off in late 2022, fed by infostealer malware. CrowdStrike's 2026 Threat Hunting Report documents one LLMjacking campaign that pushed nearly 200,000 API requests through a compromised cloud account's AI model access in two minutes. Meyers drew the line in a July briefing on the report. LLMjacking, in his framing, is stealing the credentials, and cost harvesting is what the buyer does next, manipulating AI resources that belong to the victim "in order to conduct operations and generate massive bills as a byproduct of that," he said. "So think of this as LLM coin mining." One architect refused to build the same exposure into his product Tom Kleinpeter, co-founder and chief architect at Common Room, described in written answers to VentureBeat why he held his company's AI agent integrations back through the summer of 2025. "We rejected local MCP servers early, full stop. That path meant storing a long-lived API key or token on someone's machine. Steal that credential, and you can impersonate the user, pull their data, or do anything else the token allows, indefinitely, until someone notices and manually revokes it. We weren't willing to ship that." Common Room shipped its first agent integration in October 2025 with Okta's Auth0 handling authentication, separate read and write scopes, and writes off by default, per Kleinpeter. An AI coding agent working on Common Room's own system proposed caching access tokens in plain text in Redis to cut down on repeated authentication calls, he wrote. It worked, and it would have parked live credentials in shared infrastructure had a human reviewer not caught it before it shipped. Asked what was acceptable in 2024 and a liability now, he named one thing. "Long-lived, broadly scoped API keys. Those made sense when one human operated one trusted system and stayed in the loop. Agents now run across laptops and multiple clients, often with no human watching in real time." Okta gave agents governed identities the same week Claude users lost their cookies Okta made Agent SSO generally available on August 24, registering AI agents as first-class identities in Universal Directory and issuing short-lived, identity-governed tokens in place of stored credentials, according to the company's announcement. The release names Claude as its example of an agent a security team can now govern natively. Six days later, Anthropic was signing users out because six stealer families had copied the humans' Claude cookies. The agents got governed identities. The people using Claude on their own cards did not. VentureBeat's July Pulse Research wave on agent security found 63% of 116 enterprises report credential sharing somewhere among their AI agents, and 3% run Okta for AI Agents. That 3% has a reason, Kayne McGladrey, author of the forthcoming "Cyber Risk is a Myth" and a senior IEEE member, told VentureBeat during a July interview. "It's only those well-resourced companies that are above the poverty line that have met all the prerequisites," he said. The prerequisites he named are the same controls most enterprises still treat as hygiene, not strategic investment. "If they don't have their defenses in order, like attack surface management or blast radius containment or basic MFA, that would not be a useful capability or a meaningful spend." Anthropic's position deserves its hearing. The company told users it has no reason to believe the malware is related to Claude, installed through Claude, or tied to anything they did with Claude, and it warned that signing out stops the stolen sessions while leaving the malware in place to steal the next login. Both hold, and they are the last thing a provider can do, because the infected device belongs to the customer. On a work laptop, the device belongs to the enterprise, and the control that catches Vidar or LummaC2 before it reads a cookie jar is endpoint detection, the control in this story the security team already runs. The profession's gap is rarely a missing control anymore, in McGladrey's framing. "I think we've got technical solutions for nearly all of the things that could go wrong, what we don't have is a way of prioritizing those," he argued. The endpoint team owns the machine. The identity team owns an SSO the account never touched, and the AI governance lead wrote a policy the employee routed around the day the card went on file. Each of those owners is paid to close a different gap. "Engineering is comped on getting product out the door quickly, your internal audit team is comped on checking boxes to meet your compliance goals, and security is comped and sometimes penalized on a lack of incidents," he argued. "People aren't doing the wrong thing either. They're doing what pays their bills on an ongoing basis." What security leaders need to do next Add AI accounts to the infostealer response playbook. When an endpoint alert names a stealer family, treat every AI service session on that machine as compromised, revoke what the enterprise tenant lets you revoke, and have the employee sign out of personal accounts until the machine is clean. Warn users that the notification itself is now a phishing template. Help Net Security flagged copycat phishing impersonating Anthropic using this campaign as pretext. If the notification lands in a user's inbox, the next email that looks like it may not be from Anthropic. Count the personal subscriptions on managed devices. Browser telemetry, CASB logs, and expense reports surface the sessions and the payments. Stop personal AI accounts from holding OAuth grants into corporate Google Workspace or Microsoft 365. Both platforms let administrators restrict third-party app authorization. Use that gate so a work inbox can only be attached from a tenant the security team can revoke. Revoke the OAuth grants Claude already holds, not just the Claude session. Signing out of Claude invalidates the stolen session but does not revoke the Google or Microsoft grant Claude was already authorized to use. Check Google's third-party app authorizations and Microsoft's enterprise application consents for live grants the sign-out left behind. Move the heavy users onto the organization-managed tenant. On Team and Enterprise plans, an owner decides whether connectors can be enabled at all. Put session binding on the renewal agenda. Google shipped Device Bound Session Credentials in Chrome 146 on Windows in April and turned it on by default for Google accounts and Workspace Individual accounts in May, binding each session to a private key in the device's TPM so a copied cookie cannot be refreshed anywhere else. It covers Chrome on Windows only so far, so the Mac victims in this campaign sit outside it. Ask Anthropic and OpenAI for parity and Google for a coverage date before the next contract signs. Anthropic sent its notification to individuals. The laptop the cookie came from belongs to whoever manages it, and Vidar and LummaC2 will be back for the next login on the same machine.

9/2/2026

Presented by Zeta Every forward-deployed engineering (FDE) pitch sounds identical for the first ten minutes: an engineer embedded on-site, a workflow encoded within weeks, a demo that finally works on the customer's real data. What differs is what happens in the following months, and most vendors will not tell you until you ask directly. FDE has become one of enterprise AI’s most consequential operating models. Vendors are building entire go-to-market motions around engineers who embed with customers, wire products into operating environments, and make the demo real. Investors often read FDE headcount as a growth signal and buyers read it as a promise of speed. Neither tells you whether the work is becoming a product advantage or simply accumulating as delivery labor. The test is simple: after an FDE engagement, does the next customer start with more product and fewer unknowns — or just a new services team? FDE is not one thing. At its weakest, it papers over a product that cannot yet stand on its own, translating by hand what the software should eventually understand. At its strongest, it is a disciplined product-learning function: it finds the edge cases of an AI-native architecture and turns them into reusable capability. The org chart looks the same, but the economics and trajectory do not. FDE is valuable because it creates automation that powers a system of intelligence. A system of intelligence is more than software that executes workflows. It captures enterprise context, incorporates what it learns from every deployment, and improves the quality of future decisions. Forward-deployed engineers are how that context enters the system in the first place. The engineers are the context layer Model choice still matters in some domains. But in many enterprise workflows, the bigger constraint is not the model, it is what the enterprise knows about itself including business rules, exceptions, workflow logic, and definitions that took a decade of operating history to settle. Access to data is not the same as understanding the business. In one large telecommunications deployment, an initial definition of a “high-intent” customer did not survive contact with the operating systems. The model’s signal said one thing while the retention team’s actual save-desk criteria said another. Those criteria were built from years of which offers actually worked, on which tenure bands, in which regions. No schema documented that logic; it lived in the judgment of people who’d been doing the job for a decade. An engineer had to sit with them, extract the knowledge, and encode it before the intelligence layer we were building could be trusted to trigger an action instead of just a score. Once that logic was encoded into the intelligence layer, new acquisition and retention use cases could move from idea to execution in days rather than months. Rather than rebuilding the integration each time, teams were adding decisions to a shared foundation. That kind of work produces more than an answer for one customer. Properly captured, it can become a semantic mapping, a policy module, a workflow template, a connector, or an evaluation that guards the decision in future deployments. The FDE is the context layer delivered first as a person, who then translates and delivers it as product. Sandbox, mud, and what happens to the learning The useful question in a diligence call or renewal conversation is not whether a vendor has FDEs. It's whether an engineer touching your environment is playing in a sandbox of tools, or trying to dig you out of the mud. In the sandbox, FDEs use a general-purpose engine in specific, gnarly environments. Their job is to find where the engine needs a new part, install it, and feed the learning back so that part can ship again. In the mud, the engineer manually constructs a missing capability one customer at a time, and there is no engine underneath waiting to receive the part; instead, it’s another custom build. Do not mistake these for a clean binary, though. Most companies live somewhere in the middle: reusable playbooks and connectors for the common cases, bespoke judgment for everything else. From the outside, sandbox, mud, and the middle can all look identical: a smart engineer, on-site, writing code against your data. The tell is what happens to what they learn. Either the next deployment begins with fewer unknowns, less custom code, and better tests, or it begins from zero with a prettier deck. The strategic version of FDE treats every engagement as a disciplined learning loop. It starts with observing the exception in the field, codifying it into a reusable artifact, validating it with an evaluation and security review, releasing it into the product, then measuring whether the next deployment actually got easier. That last step is where most companies quietly fail. Not every field discovery belongs in the core product. Some customer logic is proprietary, temporary, or too idiosyncratic to generalize. Good teams know the difference between three things that get lumped together under “FDE”: product intelligence that compounds across every customer, configurable customer logic that's reusable for one account but shouldn't ship broadly, and one-off services work that is exactly what it looks like. Customization is expected. The failure lies in not labeling which bucket the work is in, or in losing the learning from the parts that can compound. This is the difference between a company that gets better at deploying and a product that gets better at understanding. The former can build a capable services business; its advantage lies in execution and relationships. The latter builds compounding product capability that persists after the engineer leaves. The best FDE organization changes shape The uncomfortable conclusion for teams building FDE functions is that human translation should shrink per unit of value delivered, even as absolute headcount grows. A fast-growing company may keep adding FDEs while still making each deployment materially lighter because more of the required logic already exists in the product. Each deployment should require less custom engineering than the last, with engineers spending more time extending reusable capabilities than rebuilding the same integrations, workflows, and decision logic. Track four things: engineers per live workflow engineering hours per deployment time-to-value by vertical and the share of implementation work that gets reused rather than rebuilt. Track one more that matters just as much and gets watched far less: the productization lag, the time between a field discovery, and a tested capability available to the next customer. Over time, that lag should fall, custom engineering should decline, and reuse should increase. If none of these are improving, the organization is delivering, without learning whatever the headcount chart says. FDE is scaffolding only when it stays outside the building. The goal isn't to eliminate the people doing the work; it's to ensure more of what they learn becomes load-bearing product capability. Three questions that get past the pitch 1. How is FDE priced? Pricing is a signal rather than a verdict. A separate professional-services line may reflect honest transparency, bundled FDE may be a loss leader paid for by utilization. The more useful question is whether the contract, renewal, and margin story make clear which work is repeatable productization and which is bespoke delivery. 2. Where does field learning go? Don't infer this from résumés alone. Ask who owns the handoff from FDE to product, what artifacts are produced, and how quickly they become tested, supported capabilities. The organizational interface is what reveals whether learning compounds, not the job title. 3. What got faster on the last repeat deployment? Ask for a specific vertical and a specific delta such as fewer engineering hours, fewer weeks to value, fewer custom integrations, or a higher reuse rate. A credible vendor can name what changed and how it was measured. General claims about “learnings” and “playbooks” are not enough. Enterprise AI creates lasting advantage when every deployment leaves behind more than a satisfied customer. It leaves behind a deeper understanding of how enterprises operate. The goal isn’t simply to deploy AI. It’s to build a system of intelligence that captures enterprise context, converts customer learnings into reusable capability, and compounds over time. Neej Gore is Chief Data Officer at Zeta. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

9/1/2026

When large language models (LLMs) hallucinate, developers typically assume the model lacks the required facts. Engineering teams diagnose the error as missing knowledge. The standard response is to increase model size, expand training data, or build complex retrieval architectures. A new study by researchers at Google Research and Technion demonstrates that the knowledge is often not missing. The model has the information encoded parametrically but fails to surface it during generation.  Their experiments show that frontier models like GPT-5 and Gemini-3 encode 95-98% of tested facts. This indicates that in many cases, recall, rather than encoding, is the primary bottleneck for factual accuracy.  By understanding how to unlock existing knowledge through inference-time computation, engineering teams can build more reliable applications without necessarily relying on larger models or external databases. Knowledge profiling: measuring what models actually know To map this gap between storage and retrieval, the researchers propose shifting the evaluation focus from question-level accuracy to fact-level profiling. Instead of simply scoring whether an LLM answers an isolated prompt right or wrong, fact-level profiling tests a single underlying piece of information across multiple conditions, evaluating whether the fact is stored in the model's parameters at all, whether it can be queried from different directions and phrasings, and what computational effort is required to retrieve it. This framework distinguishes between whether a fact is parametrically "encoded" and whether it is "known". A model encodes a fact if it can accurately reproduce it when primed with its original training context. A model knows a fact if it can reliably answer questions about it across varied phrasings and directions. "Encoding and recall failures are indistinguishable under accuracy metrics, yet they imply different limitations and solutions,” the researchers write. “Encoding failures call for pre-training interventions, such as scaling model size or data coverage. Recall failures suggest post-training interventions that often improve how models utilize what they already encode." The paper illustrates this using a sample fact: Oasis played their first gig at the Boardwalk club. Based on how models process this information, the study categorizes knowledge into five distinct profiles: Direct recall: The model encodes the fact and readily accesses it to answer direct questions without extra inference compute. Encoding failure (empty shelves): The model neither encodes nor knows the fact. It cannot complete a Wikipedia-style sentence about Oasis’s early days, nor can it answer questions about the event. This signals a need for more pre-training data or greater model capacity. Recall failure (lost keys): The model has the fact encoded but cannot access it. It can seamlessly complete the original training text about Oasis, but fails to answer "Where did Oasis play their first show?" even when given time to think. Recall with thinking: The fact is encoded, but inaccessible to direct generation. It is only successfully recalled when the model uses inference-time computation, such as Chain-of-Thought, to bridge the gap. The researchers refer to this mechanism as recall facilitation. The model might initially fail to answer the direct question. By generating intermediate thoughts about the band's early history in Manchester, it structurally primes itself to locate and recall the locked answer. Inference without encoding: The model never explicitly encoded the Oasis fact. Instead, it successfully answers the question by making an educated guess or reasoning across other encoded facts it does know. It might deduce the answer by chaining together separate data points, such as "Oasis formed in Manchester," "the Boardwalk was a famous 90s music club there," and "the Boardwalk hosted early gigs by emerging bands.” Scaling illusions, long-tails, and tip-of-the-tongue recoveries The researchers evaluated 13 LLMs on over 4 million responses. They used WikiProfile, a benchmark containing 2,150 facts extracted from Wikipedia, testing each fact across formats ranging from exact context completion to multiple-choice verification. For frontier models like GPT-5 and Gemini-3, encoding is nearing saturation. These models successfully encode 95-98% of the tested facts. However, they still fail to directly recall 26-34% of those encoded facts without thinking.  Inference-time thinking acts as a vital recovery mechanism. Providing models with extra computational effort successfully retrieves 40-65% of the encoded facts that models initially fail to directly recall. The researchers compare this to the human tip-of-the-tongue state, where deliberate effort, such as mentally retracing context, eventually helps remember the information. Scaling up model size does not automatically resolve this gap. In fact, companies often mistakenly try to solve recall failures by fine-tuning larger internal models—an expensive architectural misstep. "When facts come out wrong, the go-to move is to scale, meaning train a larger model or add more data," Nitay Calderon, Research Scientist at Google, told VentureBeat. "Both are expensive, and if the facts are already encoded, neither helps." For example, the researchers found that scaling the Gemma3 model from 1 billion to 27 billion parameters largely filled the "empty shelves" by decreasing encoding failures from 85% to 23%. But at the same time, the share of recall failures increased, peaking at 40% without thinking. This suggests that scaling mainly solves the storage problem rather than the access problem. As the model memorizes vastly more facts, a larger pool of knowledge becomes trapped in an "encoded but inaccessible" state. The bulk of model errors shifts from missing data to failed recall. "Our findings suggest that recall is tightly coupled to the conditions under which facts were learned, degrading when queries diverge from training-time patterns," the researchers write. How a user asks a question directly dictates whether the model can unlock the stored answer. For example, the experiments showed that rare facts are encoded at rates similar to popular facts. Yet they found a large recall gap between long-tail and highly popular facts that exceeds 25% for frontier models. Similarly, models struggle to generate answers to reverse questions (i.e., asking for the subject instead of the object). For example, a model might easily answer that Oasis played their first gig at the Boardwalk club, but fail to answer who played their first gig at that same club. At the same time, the same models show that they know the correct answer when given the same question in multiple-choice format. "Whereas these failures are often interpreted as limitations of memorization or bidirectional encoding, our results suggest a different picture: rare facts are often encoded but inaccessible, and reverse facts can be recognized even when they cannot be generated,” the researchers write. “This reframes both phenomena as recall failures rather than 'missing knowledge.'" The ROI of thinking and tips for developers The high encoding rates of frontier models require a shift in how developers approach factuality and pipeline architecture. Don’t treat every factual failure as a retrieval problem: The default enterprise reaction to hallucinations is often to deploy Retrieval-Augmented Generation (RAG), scale up vector databases, or ingest more domain documents. While RAG is the right call for fresh or internal data, using it as a blanket fix for hallucinations adds latency and costs to facts the model already has locked in its parametric memory. "A lot of what teams solve with RAG are facts the model can already answer from memory, so you're paying extra latency and per-call cost for nothing," Calderon said. "If a fact is truly missing, RAG can be the right fix. But if the fact is encoded and the model just can't recall it, RAG and scaling the model only add cost on top of the real problem." Use inference-time reasoning selectively: Thinking recovered 40–65% of encoded facts that models failed to directly recall. However, because only 10-20% of facts actually require thinking, turning it on globally wastes your compute budget. The challenge is dynamically routing queries, as models lack the self-awareness to reliably diagnose when they are about to fail. "To use the compute well, the model has to sense ahead of time that a plain answer is about to fail, so it can escalate before answering," Calderon said. "That self-awareness is its own skill, and today's models aren't reliably good at it." This metacognitive bottleneck is why Google researchers are developing frameworks like "faithful uncertainty" to allow models to accurately gauge their own confidence and trigger deeper reasoning rather than hallucinating. Deploy generate-then-verify pipelines: Because models are better at recognizing facts (verification) than generating them from scratch, developers can build architectural loops where a model generates a response and is then prompted to explicitly reflect on and verify its own claims. "Since recognizing a correct answer is easier than generating one, a verify pass over the model's own output could catch mistakes that plain generation misses and add some factual improvement on top," Calderon said. Test semantic access, not just benchmark accuracy: Standard accuracy metrics mask underlying model capabilities. Evaluation sets should probe the same underlying fact across different phrasings, contexts, and directions to truly understand what a model knows versus what it can reliably access. Leverage query reformulation and retries: Because recall is highly context-dependent, query framing dictates success. Changing the structure of a prompt, generating relevant intermediate context, or prompting the model to generate a reasoning chain before answering are legitimate reliability mechanisms that surface information direct prompts miss. Limitations and practical takeaways The WikiProfile benchmark relies on encyclopedic Wikipedia facts. These findings might not perfectly generalize to proprietary or highly specialized enterprise domains. A model's ability to store and recall a niche internal company metric may behave differently than its handling of public encyclopedic data. Fully profiling a frontier model on the WikiProfile suite costs approximately $500. Developers can significantly reduce this cost by omitting multiple-choice variants or using fewer response samples per question.  Teams can access the WikiProfile benchmark on Hugging Face to evaluate their own systems. Because the benchmark includes the exact prompts used to build it, enterprise data engineering teams can recreate the pipeline on their own internal corpora to diagnose whether their bespoke agents are suffering from missing data or missing keys. However, teams should manage their expectations when moving away from encyclopedic data. "The pipeline is built to be applied on a new corpus, and we provide all the prompts we used," Calderon said. "The one thing to expect: on Wikipedia it was mostly a recall problem. Domain-specific facts may genuinely not be encoded in the model." Ultimately, this shift toward knowledge usage levels the playing field for enterprise AI stacks. "For companies that don't build models from scratch, this is good news," Calderon said. "Pre-training is hugely expensive and out of reach for most, but the levers that matter now are not: post-training can help with little data and few steps, and inference-time tools like thinking, verify steps, and retrieval are already what most teams use." This story was updated to include remarks from Google.

9/1/2026

Egiziago Cioffi is the IT and Enterprise Architect and CEO of SynSphere Italia, a Microsoft partner based in Milan. He built an agent himself. He wrote the indexing job, configured the Azure OpenAI retrieval pipeline, connected it to SharePoint, and watched it pass every evaluation his team ran. His Azure OpenAI email assistant auto-resolves about 60% of inbound customer email, Cioffi told VentureBeat in written responses to our interview questions. The evaluation scores were clean, and the unit tests passed. None of them asked the question that mattered. Cioffi ran a low-privilege account against the same questions a high-privilege account had already put to the assistant. The outputs did not match. The assistant returned SharePoint content the requesting user could not have opened in SharePoint on their own. The logs told a different story than the evaluation scores. Cioffi's retrieval logs are the evidence for this specific production failure. What follows is independent data showing the failure class is not isolated. In many production RAG deployments, the agent answers with the indexer's permissions, not the requester's Azure AI Search has shipped native document-level ACL trimming via Entra-based tokens since preview in May 2025, and SharePoint ACL sync followed in a later preview. The capability exists; however, it does not exist everywhere it needs to. The SharePoint ACL preview can now ingest site-group metadata via the spg: prefix in the 2026-05-01-preview API. However, only Entra-backed principals are documented as reliably enforced at query time. The preview runs through the REST API and preview SDKs and does not cover all agent deployment paths. Azure OpenAI On Your Data, for example, supports document-level access via Azure AI Search security filters, but Microsoft's own documentation states that if the permitted-groups field is not mapped, document-level access is disabled. That is a fail-open default in a first-party path. Custom RAG pipelines that bypass Azure AI Search entirely still index under a broadly privileged service account with no query-time entitlement check unless the developer builds one. Cioffi's deployment took the custom-pipeline path. Across production agents at scale, 91% of successful attacks ended in silent data exfiltration Straiker's red team ran more than 1,700 successful exploit attempts against production agents and published the results in its inaugural STAR Labs Threat Report in July. The 91% figure from their research measures all successful attacks on productivity agents that ended in data exfiltration without detection. It is a measure of what happened after an exploit succeeded, not a measure of how many deployments fail to enforce retrieval-time entitlements specifically. Across the productivity agents in scope, 91% of successful attacks ended in silent data exfiltration, with the report noting no malware had been required. There was also no lateral movement through the network. The agent returned all the data it could reach. Straiker's report does not break out which of those successes trace to entitlement failures specifically versus prompt injection, tool abuse, or other attack classes. Working independently, the U.K.'s AI Security Institute documented 19 unsanctioned agent actions from a July 25 to 28 cyber evaluation. The UKASI published its incident report on August 4 of this year. The evaluation deliberately ran with cyber classifiers disabled and internet access enabled. What the UKASI report demonstrates is agents acting outside the scope their deployers intended, in a permissive test environment, with no reliable mechanism to catch the deviation before it causes damage. It is a containment failure, not a retrieval-entitlement failure, and the overlap with the Cioffi incident is the shared absence of a runtime scope check rather than an identical mechanism. Why evaluations miss this and why the native fix did not reach Cioffi's deployment The evaluations Cioffi's team ran were designed to test whether the agent answers correctly. They check factual accuracy, relevance, and task completion. They do not ask whose permissions the retrieval pipeline uses when it fetches the source material, because that question is not in the evaluation framework. Azure AI Search is currently shipping the retrieval-time entitlement check at the platform level. The query-time ACL trimming validates the caller's Entra token, extracts user and group claims, and returns only documents whose synchronized permission metadata grants the caller access. For deployments that use Azure AI Search with the SharePoint indexer and Entra-backed principals, the control exists natively. Cioffi's deployment did not use this path. His custom Azure OpenAI retrieval pipeline bypassed the native trimming layer, which is how the gap survived every evaluation his team ran. From the attacker's side, this is a broken access control. Adriel Desautels, founder and CEO of Netragard, told VentureBeat in written responses that the failure reduces to a structural collapse of authorization boundaries. "If the NHI credentials usually have broad authorization and can read high privilege data then that is then stored in their index," Desautels wrote. "If an app does not enforce identity-aware retrieval, then a 'normal' user with lower permissions can query the app and access otherwise restricted data. This collapses authorization boundaries down to the lowest privilege level with search capability." That gap is what Cioffi's low-privilege test exposed. The assistant's context window contained SharePoint content the low-privilege account could not have retrieved through SharePoint directly. The evaluation had passed. The retrieval permission boundary had not been enforced. Desautels put the evaluation blind spot in operational terms. "Agents tend to run a single, long-lived, non-human identity that holds a wide range of permissions that it might need for any task it is ever asked to complete," he wrote. "Evaluations also don't often cover prompts, outputs, transcripts, memory, and logs where it can be read or hijacked through injected content. That mismatch is what most current evaluations get wrong." Cioffi's filter narrowed the assistant's retrieval scope. It still resolves roughly 60% of email Cioffi's fix did not require a new identity platform. He moved the entitlement decision into the retrieval path itself, adding a query-path filter that checks the requesting user's SharePoint permissions before the model sees a chunk. The filter runs at query time, not at index time. Content the user could not open in SharePoint does not enter the model's context window. The control narrowed what the assistant could reach. The assistant still auto-resolves roughly 60% of inbound email with the filter live, Cioffi told VentureBeat. He did not provide a before-the-filter auto-resolution figure for comparison. The qualitative tradeoff he described is that some content the assistant previously used to answer questions is now excluded because the requesting user's permissions do not reach it. That is the price of enforcing the boundary. The question of whether retrieval-time entitlement filtering is worth the narrowed retrieval scope does not have a single answer. It depends on the sensitivity of the indexed content, the permission variance across the user population, and whether the deployment can tolerate unanswered queries when the filter blocks a chunk the model needs. What Cioffi's incident demonstrates is that the gap exists in custom Azure OpenAI pipelines, that answer-quality evaluations do not catch it, and that a query-path filter closes it at a trade-off the builder can describe. Identity governance platforms address a different layer. Both controls are needed CrowdStrike announced its $740 million acquisition of SGNL on January 8, 2026, and closed the deal on February 20, 2026. Palo Alto Networks announced its $25 billion acquisition of CyberArk in July 2025 and closed the deal on February 11, 2026. Both deals closed the same month, establishing identity security as a platform pillar at two of the largest security vendors in the world. Identity governance platforms focus on which service accounts exist, what they can reach, and when their tokens expire. They govern the lifecycle of the credentials that power AI agents. That layer matters. What it does not govern is the retrieval permission boundary. That is the moment a correctly scoped service account retrieves content on behalf of a user who holds fewer permissions than the indexing job does. Every credential in the chain is legitimate. The service account is clean and properly managed. The knowledge base is correctly indexed. A low-privilege user queries the assistant, and it answers from the full indexed scope. Nothing flags the retrieval because no credential was misused. Cioffi's filter is a control at the retrieval permission boundary layer specifically. Azure AI Search's native ACL trimming addresses the same layer for deployments that use it. Neither replaces identity governance. A production deployment that wants to close both the credential lifecycle gap and the retrieval-time entitlement gap needs controls at both layers. One question and one test, any security team can run Ask whose permissions each AI retrieval system uses when it fetches content. If the deployment uses Azure AI Search with the SharePoint indexer and Entra-backed principals, verify that query-time ACL trimming is enabled and that the user population does not depend on SharePoint site groups. If the deployment uses a custom retrieval pipeline, the entitlement check may not exist at all. Start by proving the answer from a low-privilege account. Run the same question a high-privilege account has already put to the assistant. Compare the outputs against what the low-privilege account can access through the underlying system directly. Desautels confirmed that this is where a red team would start. "The first test would likely target the gaps between data and instructions, and the gaps between the user's identity and the assistant's own credentials," he wrote. "We'd attempt to plant an instruction within content that we think the assistant will ingest as data. We'd have that content direct a side-effectful, privileged action that the attacking user is not authorized to perform." A failing result, in Desautels' assessment, is "the successful or even partial execution of our injected commands." If the assistant returns more than the account's direct access would allow, the retrieval permission boundary is not enforced at query time. That test costs two accounts and thirty minutes. It produces a result an evaluation score cannot replicate. Cioffi built the agent on a custom Azure OpenAI pipeline that bypassed the native ACL trimming layer. He ran every evaluation his team had. He found the gap in his own logs after all of them passed. The evaluation tested whether the agent answered correctly. It did not test whose permissions the agent was using. Run the two-account comparison before the next deployment goes live. Thirty minutes tells you which side of the line you are on.

9/1/2026

It's only the first day of September 2026, but the month and fall season are already off to the races in AI land, as Anthropic has just released its latest and most powerful large language models yet — Claude Fable 5.1 and Claude Mythos 5.1. The two names refer to the same underlying model. Fable 5.1 is the generally available version, with Anthropic’s production safeguards in place. Mythos 5.1 is available through restricted-access programs for vetted cybersecurity and life-sciences organizations that need capabilities normally constrained by those safeguards. For enterprise buyers, however, the release is about more than another round of benchmark gains. Anthropic is simultaneously changing the economics of running persistent agents, reducing the cost of cached context by 75%, and introducing a new security architecture called Enterprise Frontier Safeguards, or EFS, designed to let organizations retain monitoring data inside infrastructure they control. Those changes arrive at a particularly consequential moment. Over the past several weeks, Anthropic and the U.K. AI Security Institute have disclosed incidents in which earlier Claude models, running under unusually permissive cybersecurity evaluation conditions, took unauthorized actions against real systems. Anthropic temporarily paused external cyber evaluations and has since introduced additional containment and monitoring before resuming them. Taken together, Fable 5.1 looks less like a conventional model refresh than an attempt to solve three increasingly intertwined enterprise problems: how to make agents capable enough to finish difficult work, economical enough to leave running for hours, and governable enough to give access to sensitive systems. A model built for work that does not finish in one prompt Anthropic is positioning Fable 5.1 primarily around sustained problem-solving. On Terminal-Bench-Science 0.1, which evaluates agentic scientific research, Anthropic reports Fable 5.1 scoring 52.6%, compared with 24.7% for Fable 5, 29.0% for Opus 5 and 22.4% for GPT-5.6 Sol in its evaluation setup. On Terminal-Bench 4.0, Fable 5.1 scores 55.8%, versus 42.0% for Fable 5 and 52.3% for Opus 5. Mythos 5.1 reaches 60.9% on the same coding benchmark when operating under its more permissive cyber safeguards. The gains extend beyond coding. Anthropic reports a GDPval-AA v2 score of 1,853 for knowledge work, versus 1,824 for Opus 5 and 1,723 for Fable 5. On AutomationBench, intended to measure business workflows, Fable 5.1 scores 31.4%, compared with 17.1% for Fable 5 and 26.9% for Opus 5. On CursorBench 3.2.0, it reaches 73.4%. Those numbers should be read as vendor-reported results rather than independent proof of superiority. Anthropic also notes qualifications around several evaluations: production safeguards can affect scores, and its August 2026 OSWorld task release is not directly comparable with some previously published results. The more useful signal for enterprise teams may therefore come from the kinds of failures early-access partners say the model can resolve. Investment firm Millennium told Anthropic that Fable 5.1 traced an extremely rare software crash to a bug inside an external vendor library after the problem had resisted explanation for four to five years. Corporate expense management provider Ramp described an unattended 38-hour machine-learning run in which the model re-evaluated a previous result, launched six experiments and returned with findings and proposed next steps. Browserbase said Fable 5.1 completed 82% of tasks on its hardest browser-agent benchmark, versus 74% for Opus 5 and 57% for Fable 5. These are customer testimonials supplied as part of Anthropic’s launch, not independently reproduced benchmarks. But they illustrate the direction Anthropic is pursuing: moving the unit of AI work from an answer or code snippet toward an entire investigation. That changes deployment architecture. A model that can operate for hours needs durable context, tool access, checkpoints, logging, permission boundaries and reliable recovery from errors. Model intelligence becomes only one component of the system. Pricing: Fable 5.1 remains premium, but caching changes the equation The most immediately measurable enterprise change is pricing. Fable 5.1 retains Fable 5’s headline API rates: $10 per 1 million input tokens and $50 per million output. That makes it considerably more expensive on uncached tokens than other models in Anthropic’s lineup. Opus 5 costs $5 per million input tokens and $25 per million output tokens, while Sonnet 5 costs $2 and $10 respectively. The important change is cached input: Claude model Input / 1M Cache read / 1M Output / 1M Fable 5.1 $10 $0.25 $50 Fable 5 $10 $1.00 $50 Opus 5 $5 $0.50 $25 Sonnet 5 $2 $0.20 $10 Anthropic has cut a Fable 5.1 cache hit to just $0.25 on input, down from $1.00 for Fable 5. That's also just 2.5% of Fable's normal input-token price of $10, rather than the 10% multiplier used by most other Claude models. Five-minute cache writes remain $12.50 per million tokens and one-hour writes $20, but subsequent reads cost just $0.25 per million. That produces an unusual pricing profile. Fable 5.1's ordinary input and output are twice as expensive as Opus 5's, yet its cached input is half the cost of Opus 5's cache reads. Its cache-read price is only 25% above Sonnet 5's despite Fable's base input price being five times higher. That matters for agents because they repeatedly revisit the same codebase, system instructions, tool definitions, documents and accumulated conversation history. Anthropic says the lower cache price reduces Fable 5.1's effective cost by around 25% for typical workloads and as much as roughly 45% for highly agentic workloads in which cached context accounts for a larger share of usage. This is a more useful enterprise framing than simply comparing per-token list prices. Model selection for an agentic workflow increasingly depends on cost per successfully completed task, including retries, context replay, tool calls and the number of tokens a model consumes before reaching a usable result. The cache price reduction also may be an effort to help woo increasingly price-consicious enterprises. A Financial Times report found that, more than two months after launch, Fable 5 accounted for only about 11% of Anthropic model spending among roughly 70,000 companies represented in Ramp’s transaction data, while the cheaper Opus 5 and Opus 4.8 gained share. The Information further reported growing concern among enterprise customers about unpredictable AI bills, including ServiceNow monitoring employee usage after rapidly consuming its annual Anthropic budget. Those reports suggest that even when enterprises valued Fable 5’s capabilities, many were unwilling to make it the default model for large-scale production workloads. Fable 5.1 nevertheless remains expensive relative to much of the broader market. OpenAI's current promotional API pricing for GPT-5.6 Sol is $4 per million input tokens, $0.40 for cached input and $20 per million output tokens through at least Nov. 21. Google's Gemini 3.7 Flash currently lists at $0.75 per million input and $3.75 per million output through the end of 2026. Model Input ($/1M) Output ($/1M) Total ($/1M) Source Muse Spark 1.2 Contributor $0.10 $0.20 $0.30 Meta MiMo-V2.5 Flash $0.10 $0.30 $0.40 Xiaomi DeepSeek-V4-Flash — off-peak $0.22 $0.66 $0.88 DeepSeek GPT-5.6 Luna $0.20 $1.20 $1.40 OpenAI MiniMax-M3 $0.30 $1.20 $1.50 MiniMax LongCat-2.0 — limited-time promo $0.30 $1.20 $1.50 LongCat DeepSeek-V4-Flash — peak hours $0.44 $1.32 $1.76 DeepSeek MiMo-V2.5 $0.40 $2.00 $2.40 Xiaomi DeepSeek-V4-Pro — off-peak $0.66 $1.98 $2.64 DeepSeek LongCat-2.0 — standard $0.75 $2.95 $3.70 LongCat MiMo-V2.5 Pro (≤256K) $1.00 $3.00 $4.00 Xiaomi Gemini 3.6 Flash — through Dec. 31, 2026 $0.75 $3.75 $4.50 Google Gemini 3.7 Flash — through Dec. 31, 2026 $0.75 $3.75 $4.50 Google DeepSeek-V4-Pro — peak hours $1.32 $3.96 $5.28 DeepSeek Muse Spark 1.1 / 1.2 $1.25 $4.25 $5.50 Meta GLM-5.3 $1.40 $4.40 $5.80 Z.AI Grok 4.6 — <200K prompt tokens $2.00 $6.00 $8.00 xAI MiMo-V2.5 Pro (>256K) $2.00 $6.00 $8.00 Xiaomi Qwen3.8-Max $2.00 $6.00 $8.00 QwenCloud Gemini 3.6 Flash — starting Jan. 1, 2027 $1.50 $7.50 $9.00 Google Gemini 3.7 Flash — starting Jan. 1, 2027 $1.50 $7.50 $9.00 Google GPT-5.6 Terra $2.00 $12.00 $14.00 OpenAI Grok 4.6 — ≥200K prompt tokens $4.00 $12.00 $16.00 xAI GPT-5.4 $2.50 $15.00 $17.50 OpenAI Kimi K3 $3.00 $15.00 $18.00 Moonshot AI Claude Opus 5 $5.00 $25.00 $30.00 Anthropic Sakana Fugu Ultra (≤272K) $5.00 $30.00 $35.00 Sakana AI GPT-5.6 Sol — Standard mode $5.00 $30.00 $35.00 OpenAI Claude Fable 5 / Claude Mythos 5 $10.00 $50.00 $60.00 Anthropic Claude Fable 5.1 / Claude Mythos 5.1 $10.00 $50.00 $60.00 Anthropic GPT-5.6 Sol — Fast mode $10.00 $60.00 $70.00 OpenAI Fable therefore needs to justify its premium through higher task completion, lower token consumption, or the ability to replace more expensive human or multi-stage workflows—not simply through raw API price. Anthropic's pricing system provides additional levers. Batch processing cuts Fable 5.1 input and output rates in half, to $5 and $25 per million tokens, for asynchronous workloads. U.S.-only inference adds a 1.1x multiplier. Web search costs $10 per 1,000 searches in addition to token usage, while web fetch carries no separate fee. For procurement teams, those details make workload profiling increasingly important. A code-review agent with enormous reusable repository context may have very different economics from a report-generation workflow dominated by new output tokens. The cyber incidents behind the release The security architecture surrounding Fable 5.1 also needs to be understood against Anthropic's recent cybersecurity incidents. On July 30, Anthropic disclosed that a review of 141,006 cybersecurity evaluation runs had identified three incidents, spanning six runs, in which Claude models reached the public internet from a third-party testing environment and obtained unauthorized access to real organizations. The models had been running without the cyber safeguards applied to generally available Claude deployments. They were performing capture-the-flag exercises and had explicitly been told that their environments were simulations without internet access. A configuration problem nevertheless left an internet path open. In the most serious incident, Claude Opus 4.7 encountered a real company that shared a name with the fictional organization in its test. Across four runs, the model obtained application and infrastructure credentials and accessed a database containing several hundred rows of production data. Anthropic said the model eventually encountered indications that the system was real but continued its attack. A second incident involved Mythos 5. The model discovered developer instructions referencing a nonexistent Python package and decided that publishing a package under that name could help it win the simulated challenge. It created a PyPI account and uploaded malicious code to the real public package repository. The package remained available for roughly an hour and was downloaded and executed on 15 real systems. One belonged to a security company whose automated scanner executed the package; Claude's code extracted credentials and subsequently used them to access additional infrastructure. In the third incident, an internal Anthropic research model scanned roughly 9,000 internet targets after failing to reach its intended fictional target. It compromised an internet-facing application using exposed credentials and SQL injection, then stopped after recognizing that the system had no connection to the exercise. The incidents did not involve customer data or Anthropic's production infrastructure, and Anthropic says the production safeguards omitted during the tests would have blocked the behavior. Still, the episodes demonstrated a problem enterprise agent architects will recognize: a sufficiently persistent agent can exploit ambiguity between what its operator intended it to access and what its technical credentials allow it to access. A separate U.K. AI Security Institute disclosure reinforced that concern. During testing conducted in July, AISI ran a cyber challenge 122 times across multiple models with internet access deliberately enabled and vendor cyber classifiers disabled. Ten runs produced 19 unsanctioned real-world actions. Seventeen involved Anthropic's Mythos 5; two came from a GPT-5.6 Sol run. The most serious sequence involved a Mythos 5 agent attempting to insert malicious code into a real open-source project, creating fake identities and attempting to socially engineer a maintainer into accepting the change. The maintainer rejected it, and AISI said its investigation found no resulting real-world harm. The agent also attempted prompt injection against other AI systems and left messages that later agents discovered and used. Again, these were deliberately permissive research configurations, not commercially available deployments. But AISI's conclusion is relevant far beyond AI labs: increasingly capable agents should be assumed to explore routes their operators did not anticipate, particularly when given difficult objectives and broad tool access. From model safeguards to infrastructure safeguards Anthropic's response has been to add layers around the model. The company paused external cyber evaluations and briefly halted some internal testing, then deployed a real-time classifier designed to detect aggressive probing, sandbox-escape attempts or unexpected internet access before a tool call executes. It also moved high-risk cyber workloads into stronger isolation and imposed new requirements on external evaluators, including explicit network isolation and pre-engagement validation of sandboxes. External cyber evaluations have now resumed. Fable 5.1 itself also gets more precise production safeguards. Anthropic says its cyber protections now create around 60% fewer interventions per Claude Code session than Fable 5's previous safeguards. The model can be used to discover software vulnerabilities for defensive purposes, while work such as exploit generation, penetration testing and some binary-based vulnerability scanning remains redirected or restricted. That distinction matters for security teams attempting to operationalize AI. A safeguard that blocks too many legitimate actions can make an autonomous security workflow unreliable; one that permits too much creates a materially different risk. Precision, rather than simply the existence of a filter, becomes a production requirement. Enterprise Frontier Safeguards moves data custody to the customer Anthropic is addressing a second enterprise constraint through EFS. The company previously introduced 30-day data retention for Fable 5 as part of its misuse-detection system. For regulated organizations, retaining sensitive conversations with a model provider can make deployment difficult regardless of contractual assurances. EFS changes the architecture. Monitoring data can reside in the customer's own AWS, Azure or Google Cloud environment under customer-managed encryption keys, access policies and audit logging. Anthropic's automated systems can analyze the data for patterns associated with serious misuse, while alerts go to the customer for review; Anthropic says human review by its employees is not required. Anthropic says it developed EFS with more than 100 organizations across financial services, healthcare, manufacturing, telecom, law, retail and government, and with AWS, Google Cloud and Microsoft Azure. Support is planned across Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google's Agent Platform and Microsoft Foundry. The rollout begins in phases this fall. Eligible customers can use Fable 5.1 with zero data retention until EFS becomes available. Anthropic does not charge separately for EFS, although customers remain responsible for their own cloud storage, operations and egress costs. This is potentially as important as the model upgrade itself. Enterprise AI governance is shifting from promises about what a provider does with data toward architectures that determine where the data can exist in the first place. Fable for production, Mythos for controlled frontiers The split between Fable and Mythos gives Anthropic a mechanism for separating general enterprise deployment from particularly sensitive domains. Fable 5.1 is available now through Anthropic's API as claude-fable-5-1, as well as through AWS, Google Cloud and Microsoft Azure. Mythos 5.1 uses the same underlying model but exposes more permissive safeguards to vetted cyberdefenders and life-sciences organizations through verification programs. That same model has shown capabilities extending well outside software. Anthropic reports that Mythos 5.1 designed experimentally validated protein binders, while Fable 5.1 trained a neural network that produced a higher-resolution elevation map covering roughly a third of Venus. Mythos 5.1 also optimized seven open-source biological deep-learning models, with Anthropic reporting inference speedups as high as 2.5x. For pharmaceutical, engineering and research organizations, that points toward a future in which the same agent architecture used to investigate a code failure may also orchestrate modeling, experimentation and analysis. The operational lesson is the same in every case: the more work an agent can complete without intervention, the more consequential its permissions become. Fable 5.1 makes those long-running agents more capable and, through cheaper cached context, potentially much cheaper to operate. EFS gives regulated companies another mechanism for governing their data. More precise safeguards reduce some of the friction that has made high-capability models difficult to use in security workflows. But Anthropic's own recent incidents also demonstrate why the enterprise deployment question cannot stop at model selection. The next generation of AI infrastructure will need to treat agents more like powerful service accounts than chatbots: narrowly scoped credentials, segmented networks, explicit allowlists, continuous telemetry, human approval around irreversible actions and the assumption that an agent may find pathways its developer did not anticipate. Fable 5.1 raises the amount of work organizations can plausibly delegate. Its larger significance may be that it also makes the infrastructure surrounding that delegation impossible to treat as an afterthought.

9/1/2026

Perplexity today launched hybrid compute for its agentic platform, Computer, a system that lets a single AI agent split its work between frontier models running in the cloud and smaller open-weight models running locally on Apple silicon Macs — routing sensitive data to the local machine so it never leaves the device. The company says it is the first time an AI agent can begin a task in the cloud and dynamically hand off the confidential portions of that same task to a model running on the user's own hardware, without restarting the job or losing context. The feature becomes available today through Perplexity's desktop app for enterprise customers that opt in, as well as Pro and Max subscribers, on any Apple silicon Mac running macOS 15 or later. "Hybrid is really compelling because it's often the work that requires confidentiality that is the most important to get right, and so the accuracy really, really matters," Jon Staff, who leads Perplexity's macOS and iOS engineering teams, said during a press briefing attended by VentureBeat. "By combining these two together, we can get that maximum intelligence from the frontier models, but we also get the security and the privacy that comes with local." How Perplexity's on-device privacy gate keeps sensitive data off the cloud The architecture works like a dispatcher. A frontier model in the cloud breaks a task into subtasks and routes each one to the appropriate place. Web research, long-horizon planning and heavy reasoning run in the cloud, while anything touching private files, local data or actions on the device gets delegated down to a subagent running on the Mac itself. The linchpin is what Perplexity calls a Privacy Gate: a company-trained classifier that runs on the device and scans for personally identifiable information — names, addresses, account numbers, secrets — before anything is transmitted to the cloud. When the gate flags sensitive content, the user chooses whether that portion of the task runs locally or gets shared. "What we wanted to do is make sure anything that's shared to that cloud orchestrator is safe," Staff said. "We built and trained our own PII classifier that integrates directly into the Mac app." He described the handoff in detail: "The cloud orchestration will break down the task based on the prompt and figure out how to route it to different subagents... it's going to delegate that down to a sub-agent running on your Mac, and then that portion of the task is run entirely local. None of those tokens go to the cloud." The economics matter, too, for a company that meters cloud usage through credits. Tokens generated locally cost nothing. "You're paying for the electricity, you're paying for the hardware, so we're not charging you for that," Staff said. "The only thing the credits are used for is the orchestration and the delegation." Lawyers, private equity firms and a founder in an Uber: hybrid compute in action Perplexity built its demonstrations around exactly the kind of work most professionals would never hand to a cloud-only agent. In the first, a lawyer on deadline updated a draft brief against privileged case files stored on a Mac while a cloud agent simultaneously pulled public case law from the open web — sending out, Perplexity says, only anonymized legal questions. "At no point did their privileged information get shared to the cloud," Staff said. "It never left the Mac." In the second demo, a private equity associate's agent reworked a financial model against confidential management projections, benchmarked the deal against public comparables and produced a fifth iteration of an investment committee deck. The task ran roughly 40 minutes in the background with no human input — work that would have taken hours of manual stitching between local spreadsheets and cloud research. The third demo emphasized continuity across devices. The founder of a pottery shop, riding in the back of an Uber, kicked off a marketing analysis from her iPhone. Computer asked permission to reach her Mac at the studio, fired up the local subagent to process her customer interviews and revenue data, and combined that with cloud research on competitors' public pricing. "It doesn't matter how far away she is from her computer," Staff said. "Tasks like this aren't possible in a fully local or a fully cloud setup," he added. "You need that security of the local and the privacy, but you also need the intelligence of the frontier." Why a Chinese-made Qwen model on enterprise Macs is raising eyebrows The launch model lineup immediately raised a pointed question. At launch, users can choose among three local models: Google's Gemma E4B, Alibaba's Qwen3.6 35B-A3B, and a Perplexity post-trained version of Qwen3.6 35B — the company's recommended option. Asked by VentureBeat whether enterprise or government customers had raised concerns about giving a Chinese-developed model access to their machines, Staff argued that local inference neutralizes the geopolitical risk. "The great thing about these models is that they are open weight. We're able to evaluate them ourselves," he said. "When that model is running locally on your computer, the data is not going outside of your computer itself... You're not actually sending those tokens to some cloud provider that's hosted in another country. In fact, all of Perplexity's models are U.S. hosted." He added that macOS's built-in sandboxing framework, known as Seatbelt, constrains what the agent can actually do on a machine: "If local execution is trying to do something that it shouldn't, it'll just point blank stop it and it'll request permission from the user." Perplexity does not currently allow unrestricted "YOLO mode" execution, he said, though "I wouldn't be surprised at some point if we allow certain people to do this." For enterprises, admins can set a single organization-wide sensitivity policy and audit a full record of what leaves each device — a feature aimed squarely at compliance teams in law, finance and healthcare. Questions remain on the consumer side, however. Pressed on how usage data feeds model training, Staff pointed to Perplexity's incognito mode and a long-standing opt-out toggle, and said enterprise contracts can include zero-data-retention terms. A company spokesperson said Perplexity is "not using it for post training" globally and promised to follow up with specifics on non-enterprise accounts. The enterprise privacy problem hybrid AI is trying to solve The announcement lands amid a broader industry reckoning with a stubborn problem: the most valuable enterprise work involves exactly the data companies are least willing to send to someone else's servers. NIST's generative AI risk profile flags data privacy and information leakage among the technology's central risks, and McKinsey's research on the state of AI has consistently found that organizations struggle to move from experimentation to value capture, with data governance among the chief obstacles. Gartner, for its part, named hybrid computing among its top strategic technology trends for 2025, anticipating architectures that blend compute across environments. Perplexity is betting that the answer is not choosing between cloud intelligence and local privacy, but building the orchestration layer that arbitrates between them in real time. It is a defensible position for a company that has always styled itself as a neutral broker — "Perplexity is like Switzerland in that we work with everyone," a company representative said at the briefing — sitting at the application layer above whichever models happen to lead at any given moment. "Anytime one of these gets better, Perplexity gets better," Staff said of the interplay among local models, frontier models and Apple's chips. "That's the really cool nature of where we sit in this application layer, orchestrating all the different pieces together." From $520 million startup to $20 billion agent platform in three years Hybrid compute caps an extraordinarily aggressive product run. Perplexity launched its Comet AI browser in July 2025, initially for $200-a-month Max subscribers — an early bid to make agents, not chat, the interface to computing. Computer, its full agentic platform, arrived in March 2026, followed by desktop apps for Mac and Windows. Just last week, the company launched a local-first version of Computer on NVIDIA's DGX Spark hardware, which starts on the user's device and escalates to cloud models only with permission. Today's launch inverts that flow: cloud-first, delegating down. The business trajectory has been equally steep. Perplexity was valued at $520 million in January 2024; by September 2025, the company had finalized a funding round at a $20 billion valuation. Along the way it made an audacious $34.5 billion bid for Google's Chrome browser during Google's antitrust remedies fight, and Bloomberg reported that Apple executives held internal talks about acquiring the company — a striking backdrop for a product now built to showcase Apple silicon. The strategy is not without headwinds. Reuters reported in July that Reddit's data-scraping lawsuit against Perplexity survived a motion to dismiss, part of a wave of copyright and data litigation facing the company — context that makes its privacy-forward positioning both commercially savvy and reputationally necessary. And practical constraints remain: Perplexity recommends at least 32GB of unified memory for the better tier of local models, Staff was candid that the smallest option "significantly underperforms" the larger Qwen models, and Windows and Linux support will come only later. The deeper question is one users cannot easily inspect. The Privacy Gate is itself a machine learning classifier, and classifiers miss things; a false negative means sensitive data reaches the cloud anyway. Perplexity's answer is transparency — users can expand and review exactly what the gate flagged before anything is sent, and enterprises get device-level audit logs. But the pitch, at bottom, asks professionals to trust one AI to decide what another AI is allowed to see. For an industry that has spent three years telling lawyers, bankers and doctors to keep their most sensitive work away from the cloud, Perplexity's wager is that the fix was never to build a higher wall — it was to build a smarter gate.

9/1/2026

Presented by SAP HR tracks employees and skills. Finance owns headcount targets and cost. Procurement manages contractors and services spend. Together, they leave executives unable to answer basic questions about how workforce decisions actually translate into business outcomes. Fragmented planning creates workforce blind spots Each function has its own systems, its own planning cadence, and its own assumptions about how work gets done. Recent SAP research found that 62% of C-suite executives are dissatisfied with their current level of integration between people and business performance data. The same research found that while 50% of organizations are planning for AI’s impact on productivity and capacity, only 21% are planning for AI’s impact on job design and organizational structure. That gap matters because the two are inseparable. You can’t make a sound decision about where to automate without understanding how it will affect the teams, roles, and skills connected to that work. Most organizations are trying to do exactly that, and discovering, usually too late, that the pieces don’t fit together. The workforce has quietly expanded — and planning hasn’t caught up The definition of “workforce” has been expanding for years, but most planning models haven’t registered the change. Employees now work alongside contractors, specialized partners, and AI systems that handle real execution-layer tasks — not just support functions, but actual work. In some delivery models, external and digital labor has moved from supplemental to central. That shift changes the nature of every significant workforce decision. When a company chooses to automate a process, the ripple effects touch headcount, skills, services spending, and productivity assumptions simultaneously. A reskilling initiative can reduce dependency on contractors. Expanding contractor capacity can close an immediate gap while quietly deepening a long-term capability problem. None of these moves can be evaluated well in isolation, but that’s precisely how most organizations still evaluate them — separately, in sequence, by different teams working from different data. The real question isn’t “should we hire, automate, or reskill?” It’s how work should be configured across humans and intelligent systems, and at what cost. Most planning architectures weren’t designed to ask that question, let alone answer it. CFOs and CHROs are being pushed into the same room CFOs are being asked to connect financial signals to real operational choices, particularly in workforce spending, which dominates most income statements. CHROs are being pulled beyond traditional talent management into harder questions about work design and the balance between human and digital labor. Neither can answer these questions from their current vantage point alone, and historically, they haven’t had to answer them together. That’s changing, not because of some cultural shift toward collaboration, but because the decisions genuinely require both perspectives at the same time. When that partnership works, organizations can move workforce planning from a periodic budgeting exercise to an ongoing strategic conversation. They can ask harder questions: Where does it make more sense to build critical skills internally than to buy capacity externally? When we automate a workflow, how do we know whether we’re creating capacity or just moving a problem downstream? These aren’t questions finance or HR can answer in sequence. They require shared data, shared governance, and frankly, a shared willingness to operate in territory that neither function fully owns yet. From annual budgets to continuous workforce steering The organizations handling this best stopped treating workforce planning as a once-a-year negotiation and started treating it as an ongoing operational discipline. That means finance, HR, and procurement seeing the same picture of workforce capacity, skills, and cost, rather than reconciling three different pictures after the fact. It means modeling scenarios that combine hiring, reskilling, automation, and external labor as connected levers rather than separate conversations. The metrics are evolving too. Headcount, labor cost, and utilization still matter, but they describe only part of what’s happening. As AI becomes embedded in operations, leaders need visibility into skills and readiness relative to strategic priorities, how work is actually distributed across employees and intelligent systems, and whether automation is unlocking new capacity or quietly eroding the engagement of the people working alongside it. Organizations that track these signals appear to be making structurally different decisions about where to invest. They are not just better-informed, but asking better questions. The hard part isn’t the technology Connecting HR, finance, and procurement data creates the conditions for better decisions. It doesn’t make those decisions. The harder challenge is leadership alignment: CFOs and CHROs agreeing on shared metrics, committing to a planning cadence that keeps workforce choices connected to business strategy, and building a working relationship where neither function is simply ratifying what the other has already decided. That’s a governance problem, and it doesn’t come bundled with any platform. The organizations that move first on this won’t just have better data. They’ll have a fundamentally clearer picture of how work creates value across employees, contractors, and intelligent systems together. The ones that don’t will keep making workforce decisions in the dark. The difference is that those decisions are coming faster now, and the consequences of getting them wrong are larger. For additional perspectives on workforce planning, continuous planning, and leadership in the age of AI, explore SAP Workforce Planning and the latest SAP SuccessFactors innovations. David Imbert is Chief Marketing Officer, SAP Financial Management; Lara Albert is Chief Marketing Officer, SAP SuccessFactors. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

9/1/2026

The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026. But over the weekend, OpenClaw's creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet. OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows. OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing. Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally. They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw. The answer is increasingly yes at the capability level — but not necessarily by default. OpenClaw wants to become the shared agent layer Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security. Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself. “Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31. Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on. “Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.” That claim points toward one of the more important changes in OpenClaw’s enterprise proposition. The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment. OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser. For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer. A new UI could broaden OpenClaw beyond developers The redesigned Control UI is central to that strategy. OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it. The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI's ChatGPT, Anthropic's Claude, Google's Gemini and other conversational AI products. That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations. OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards. The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use. Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system. The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information. Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation. These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release. Multiplayer sessions turn agent context into shared context OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one. Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent. Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants. Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly. The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat. A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started. Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace. For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments. OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it. Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X. His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context. The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote. In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote. For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation. Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port. But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure. Security becomes much more enterprise-oriented That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop. OpenClaw 2.0 responds with considerably more granular controls. Approvals can now be tied to a specific request, command, session and person. Command permissions can be constrained to specific arguments and working directories. For script-backed execution, OpenClaw can verify that the script being executed still matches what was originally reviewed. Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators. Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using elevated execution or host overrides; if the required sandbox cannot be provisioned, execution fails rather than silently falling back to the host. Credentials receive additional protection. OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model. OpenClaw can also reference external systems including 1Password and Vault. Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed. Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines? NanoClaw still takes a different approach to security OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced. NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design. NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history. Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway. OpenClaw 2.0 can now reproduce many elements of that hardened model. It supports Docker and Podman sandboxes, per-agent and per-session sandbox scopes, configurable read-only or read-write workspace access, role-enforced sandboxing, remote execution nodes and disposable cloud workers. The key difference is the starting posture. OpenClaw’s documentation explicitly says sandboxing and execution approvals are off by default. Its baseline configuration assumes a trusted single operator and permits host execution unless administrators configure stronger restrictions. NanoClaw makes isolation more fundamental to how agent execution is structured. So does OpenClaw 2.0 have security parity with NanoClaw? In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately. One Gateway is still one trust domain Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain. Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants. For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces. Fleet tooling for managing those cells remains experimental. That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service. Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another. NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about. OpenClaw is optimizing for a broader problem. OpenClaw’s biggest advantage may be the control plane The tradeoff is product breadth. NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments. OpenClaw 2.0 is trying to build a much broader operational environment. Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions. That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it. Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong. OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system. What is OpenAI's role? OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project. Interestingly, the release was not shared by Steinberger's employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day. But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners. Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project. Enterprise readiness now depends on configuration OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations. Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation. Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience. NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity. OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace. OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal. The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn't automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box. And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.

8/31/2026

If you look at the commit histories of modern data platforms, something profound has shifted over the last two years. The friction of writing syntax has collapsed. With Cursor, Claude Code, and agentic workflows now living inside our Docker containers and IDEs, generating the first implementation of a distributed streaming pipeline or a complex API integration is no longer the central bottleneck. Agents can navigate repositories, write test coverage, inspect stack traces, and propose refactors. Describe a Kafka-to-Iceberg sink mapping in plain English, and an agent can produce a credible starting point before the engineer has opened every relevant file. That changes the question for software engineers. If the agent is becoming the primary author of local system logic, what exactly is left for the engineer to do? Are we headed toward an industry of reviewers rubber-stamping an endless stream of plausible pull requests? Or has the work shifted away from constructing logic and toward something more abstract? To answer that, it helps to borrow a lens from thermodynamics, which gives us a language for directed work, feedback, loss, and the boundaries that keep a complex system coherent. The agent as a heat engine When we strip away the anthropomorphic illusion of AI, what remains is a computational engine. It takes direction and turns it into action. An LLM sitting in a data center has immense capacity, but it does no useful work until it is given intent. A prompt, a business requirement, a system instruction, or a failing test gives the agent a direction. It turns that direction into code, tool calls, queries, tests, and changes to a running system. Every engine has losses. Every agent loop does, too. Anyone who has left an agent running against a difficult repository has seen this. It starts with a clear task. Then it follows a stale assumption, fixes a symptom rather than a cause, treats an old migration as current behavior, and begins to accumulate its own history. A few tool calls later, the context contains enough plausible but conflicting detail that the next step is less certain than the first. Call this operational entropy: the buildup of stale assumptions, branching context, and unresolved dependencies inside a loop that is still trying to move forward. A human interruption helps because it introduces new information. So does a failing test, a precise data contract, a deterministic tool, or an evaluation that tells the agent exactly what it got wrong. Without that signal, an agent can keep generating output while drifting further from a correct outcome. Agents clearly generate motion. The real question is whether the system around them turns that motion into useful work. The infinite monkey and the accelerating search space The infinite monkey theorem gives us a useful picture of what follows: repeated attempts, finite constraints, and feedback. The theorem says that a monkey hitting keys at random for an infinite amount of time will almost surely type the complete works of Shakespeare. Modern agents are much smarter monkeys. They have compilers, tools, repositories, test suites, and feedback loops. Their work is not random — the feedback steers the next attempt — but the dynamic is familiar: propose, execute, observe, correct, and try again. In a bounded task, that loop is remarkably effective. Give an agent a known input schema, a known target schema, a small codebase, and tests that catch the relevant failures. It can inspect the code, make a change, run the tests, absorb the result, and try again. The definition of done is visible. The search space is narrow. The loop has a chance to converge. But enterprise systems rarely offer that kind of stillness. A real-time pricing engine may depend on mutable operational state, third-party APIs, late-arriving events, regional policy, and business rules that exist partly in code and partly in someone’s head. A data lakehouse can be physically consistent and semantically wrong. A pipeline can pass its tests and still produce numbers that finance does not recognize. The environment is changing while the monkey is typing. The three-body problem of enterprise logic This is why the three-body problem is such a useful image for enterprise software. With two bodies — a planet and a star — you can predict the motion with a clean mathematical description. Add a third body and the problem becomes much harder to solve. There is no general closed-form solution, and some configurations exhibit chaotic behavior. Small changes in one place can produce very different trajectories elsewhere. Modern data platforms have the same shape. Clickstream data changes with product behavior. Operational databases mutate under customer activity. APIs impose rate limits and change versions. Schemas evolve. Security policies shift. Legacy systems carry rules that no one has written down because they have been buried in exception handling for years. Each system exerts pressure on the others. A change in one place alters the meaning or behavior of another. What begins as a local feature request starts to pull on the entire system. Consider a hypothetical: an agent is asked to add a customer_tier field to a revenue model. It finds a field called status in the operational database, maps it into the transformation, and passes the existing type and nullability tests. The code is clean. The pipeline is green. The answer is still wrong. A semantic data contract says that customer_tier is derived from trailing twelve-month spend, has an assigned business owner, and cannot be populated from account status. The contract rejects the change before it reaches the dashboard. The engineer's contribution wasn't the transformation — it was the boundary that made the agent's mistake visible, specific, and recoverable. The new mandate: Designing equilibrium The software engineer’s job is no longer to write every piece of micro-logic. Agents will increasingly do that work, often faster. The new mandate — designing equilibrium — is to create the conditions in which generated logic can be trusted. When a business requirement changes faster than an agent can absorb feedback, the engineer has to build containment fields. Strict semantic layers, immutable event logs, data contracts, idempotent APIs, and deterministic state machines are not just good platform hygiene. They reduce the number of assumptions an agent has to make at once. They turn a coupled problem into a bounded domain with clear inputs, explicit rules, and reliable feedback. Once that domain exists, the agent becomes genuinely powerful. It can write the transformation, execute the tests, repair the failures, and ship the change without needing to infer the unwritten history behind every table and service. The value of software engineering doesn't disappear as code generation gets cheaper — it becomes more visible, which is the shift that actually matters. Autonomous systems will increasingly generate software. But the contracts, feedback loops, and boundaries that determine whether that software succeeds or spirals into chaos will still be designed by software engineers. Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures.

8/31/2026

Presented by Box Identity and permissions are no longer enough to secure enterprise AI agents. They govern what an agent can reach, not how it behaves once it starts working on its own, and an autonomous agent can turn legitimate access of enterprise data into unintended action in seconds. That gap is pushing enterprise AI security from just governing access toward a layered approach that includes governing execution, says Heather Ceylan, chief information security officer at Box. "Access controls and permissions are the foundation, but the challenge is they were designed for humans," Ceylan says. "Permissions are still the foundation, but you have to think about how the agents get their permissions scoped as well." Access controls were built for a slower, more forgiving world, where a human employee with lingering permissions to a decade-old folder will rarely go looking for any data inside it, or even remember they have access at all. But an agent will explore all of its permissions, operating at a scale no person can match and surfacing forgotten misconfigurations and stale permissions far faster than a human ever could. Identity and scoped permissions remain the first layer of any credible defense, however, because agents raise the stakes, clean access hygiene is more valuable than ever. A steady drip of incidents in recent months underlines the potential for major damage, where models have slipped the sandboxes they were supposed to stay contained within, reached systems they weren't scoped to touch, or read content they were not permitted to access. While the specifics vary, the overarching threat remains the same: an agent found a path through the data that it could reach, and took it. Access controls alone can't secure autonomous AI agents Complications crop up when agents are handed broad standing permissions to match broad workflows. An agent might legitimately need to call fifty tools across twenty different actions over the life of a task, reading and writing folders that span every department in the company. But granting all of that access at once inflates the blast radius of possible damage to data and content if a single step goes wrong. A stronger permissions model provides access only in the moments that it's needed, Ceylan says. "You need permissions that change based on what the agent has been asked to do, when it needs to take that action," she explains. "If it's taking one step and only needs two tools, it should be scoped to only those two. When you narrow permissions to the task in front of the agent, the number of ways any given step can misfire shrinks with it." From governing access to governing execution Tight security is also no longer tied to whether an agent has access to specific data, but whether it should take a specific action on a specific step, which is the difference between a standing access grant and a bounded one. In other words, an agent may hold legitimate rights to a finance folder but still have no business writing four thousand of those files to a new location, even if it's told to do so. "An employee with access to payroll data they were never meant to keep could be instructed to pull the payroll records and write them to a public shared folder, publishing the entire company's compensation in a single move," she says. "Every access check passed, but the behavior still has catastrophic consequences." Prompts alone can’t reliably govern agent behavior because instructions can change, agents can absorb injected instructions, or they can be steered by files they read along the way. Durable controls need to live one level down, with the tool calls themselves, as well as the content those calls act on. Deciding in advance what an agent is permitted to execute, regardless of how its prompt is manipulated, keeps behavior inside fixed bounds that no clever input can talk it out of. Legacy content platforms weren't built for AI agents Most of what an agent touches inside a company is unstructured content, including contract, policies, customer records — the accumulated files that make up the overwhelming majority of corporate data. Much of it still sits in systems that were designed for human filing habits: network drives, aging ECM platforms, and many SaaS tools. Those systems were built to ask the question, does this person have permission? and they answer it with folder-level access that hasn't been audited for years. The legacy platforms don't have metadata for an agent to reason over or classification for an enforcement layer to act on, and their logs aren't detailed enough to show what an agent read. Bolting an AI connector onto that stack doesn't fix any of it, it just hands agents the same blind spots, only at machine speeds, Ceylan says. "Every agent action eventually resolves to content," Ceylan says. "If the content layer can't tell you what it's holding, who it belongs to, and what should never leave it, there's nothing underneath your controls." How to decide which AI actions need human approval Two years ago, everyone assumed security would always mean including humans in the loop. Building and living with agents has changed that assumption, Ceylan says, and Box now sorts actions into three tiers: fully autonomous actions, monitored actions and high-risk actions that require human approval. Fully autonomous, reserved for actions that are reversible, bounded, logged, and free of untrusted input, and where a mistake doesn't cost too much. Monitored actions, once a team has built enough confidence in an agent and paired it with alerting and rollback that can catch and undo a problem in flight. Irreversible, high-risk actions that are always routed through a person — for instance, when an agent that wants to delete a large number of files or wipe the primary folder in a structure. Each team must calibrate the lines between these layers to match its own risk tolerance. Box’s approach is to put controls in the platform rather than the workflow, enforcing protections such as data classification, labeling and expiration without requiring a human checkpoint for every action. "The right configuration should be enforced at the outset, instead of blocking an action at the end," Ceylan says. Building trust in AI agents through behavior over time An organization can make an access decision once, but trusting an agent's behavior should only happen over time, observing how the agent runs, collaborates, and builds on the outputs of other agents. Published frameworks tend to lag the technology, or are too abstract to implement; instead Box works from a smaller set of principles: tightly scoped agent identities and actions, clear expectations about what can be rolled back, three approval tiers, and a way for teams to test and iterate quickly. "The sanctioned path has to be the fast path, because when teams aren't given a safe way to experiment, they tend to route around the controls entirely," Ceylan says. "A security leader's job is to offer a way to move quickly without stepping outside the guardrails." Sustaining trust in an agent depends on being able to see how it actually behaves. But traditional monitoring tools weren’t built for the job; the behavioral baselines that underpin user and entity behavior analytics were calibrated to human activity, and suspicious agent behavior doesn’t necessarily look like human activity. And while establishing a useful agent baseline begins with logging, many agents start out as experiments, so their actions never make it into logging infrastructure. Plus, important signals are rarely individual easily flagged actions, but chains of activities across systems, as one agent's output becomes another's input, while the detections for that pattern are still being designed. Governing agents, then, requires visibility not just into what they can access, but what they actually do, and that visibility has to live where the content does. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/30/2026

Enterprise AI has entered a new era. Organizations are rapidly moving beyond assistants that answer questions to autonomous agents capable of reasoning, invoking tools, accessing enterprise applications, coordinating with other agents, and completing multi-step business workflows with minimal human intervention. This shift represents a fundamental change in how software operates. Traditional applications execute predefined logic written by developers. AI agents, however, dynamically determine how to achieve an objective. They decide which tools to use, which APIs to call, what information to retrieve, and how to sequence actions based on context. That flexibility unlocks enormous business value, but it also introduces a new class of security risks. Much of today's AI security discussion focuses on prompt injection, model vulnerabilities, and data leakage. These are important concerns, but they represent only part of the challenge. Once an AI agent has successfully authenticated and begins acting autonomously, traditional security controls provide very little visibility into whether it continues to operate safely. This is where enterprises need to adopt a new security mindset: runtime trust. Authentication establishes identity, not trust Enterprise security has traditionally relied on three foundational questions: Who are you, what can you access, and what actions are you authorized to perform. Identity providers, multi-factor authentication (MFA), role-based access control, and zero trust architectures answer these questions effectively for human users and conventional applications, and NIST's zero trust guidance remains a solid reference point for how those principles are meant to work (NIST SP 800-207). AI agents introduce a different problem. An AI agent may legitimately authenticate using an enterprise identity, receive valid API credentials, and be granted access to systems like Microsoft 365, ServiceNow, Salesforce, or GitHub. From an identity perspective, everything appears correct. The real challenge begins after authentication: During execution, the agent continuously reasons, interprets objectives, invokes tools, retrieves information, and adapts its behavior based on new context, and security teams must determine whether those actions remain aligned with the user's intent and organizational policy. Authentication verifies who an AI agent is. Runtime trust continuously verifies what it is doing. Enterprise AI is becoming an autonomous workforce Modern AI agents increasingly interact with large language models (LLMs), Model Context Protocol (MCP) servers, retrieval-augmented generation (RAG) systems, vector databases, enterprise APIs, SaaS platforms, and internal knowledge repositories, as well as other AI agents. This interconnected ecosystem enables sophisticated automation but dramatically expands the attack surface: A single compromised tool, poisoned knowledge source, overly permissive API, or manipulated prompt can influence downstream decisions across an entire workflow, and unlike traditional software, these risks evolve during execution rather than being fixed at deployment. That expanding surface is exactly what a handful of runtime threats exploit. Goal drift happens when an agent begins with a legitimate objective but gradually deviates from the user's original intent while attempting to optimize outcomes. An agent tasked with preparing a customer report, for instance, might autonomously retrieve unrelated confidential information because it incorrectly determines that additional context would improve the response. Excessive tool invocation is what happens when autonomous agents with access to numerous enterprise tools call unnecessary APIs, modify configurations, access sensitive repositories, or perform administrative actions simply because the model believes those actions are useful, absent any runtime controls to stop it. Memory poisoning exploits the persistent memory that improves personalization: Attackers can intentionally insert misleading instructions into long-term memory or retrieval systems, causing future decisions to be influenced by malicious or outdated information. Context manipulation takes advantage of how heavily LLMs depend on context: If attackers influence retrieved documents, system prompts, conversation history, or external data sources, they can indirectly steer autonomous behavior without ever compromising the underlying model. MITRE's ATLAS framework catalogs this kind of adversarial behavior against AI systems in useful detail. Multi-agent amplification emerges as organizations deploy specialized AI agents that collaborate: If one agent behaves incorrectly, downstream agents may trust and amplify those actions, creating cascading failures across enterprise workflows. Introducing runtime trust Runtime trust extends security beyond authentication by continuously validating AI behavior throughout execution. Rather than assuming authenticated agents remain trustworthy indefinitely, it continuously evaluates whether autonomous decisions remain aligned with organizational policy. A runtime trust architecture rests on several complementary capabilities. Intent validation evaluates, before executing sensitive actions, whether proposed behavior still matches the user's original objective: Is this action necessary? Is it expected? Does it exceed the requested scope? Would a reasonable human perform the same action? Behavioral monitoring observes tool usage, API activity, reasoning patterns, execution frequency, delegated actions, and abnormal workflows, so unexpected behavior becomes immediately visible rather than remaining hidden inside model reasoning. Policy enforcement means enterprise policies govern what AI agents can do, not merely what they can access — blocking financial transactions above approval thresholds, preventing privilege modifications, restricting administrative operations, limiting sensitive data retrieval, and requiring approval for high-risk actions. These controls function much like application firewalls for autonomous decision-making. Least-privilege execution means AI agents receive only the capabilities necessary for the current task. Instead of granting permanent access to dozens of enterprise tools, organizations should dynamically issue short-lived permissions based on runtime context, an approach that OWASP's guidance for agentic applications increasingly emphasizes (OWASP GenAI Security Project). Human oversight recognizes that not every decision should be autonomous — high-impact operations, including financial approvals, identity changes, regulatory actions, or customer-impacting decisions, should require explicit human confirmation before execution. Protecting the enterprise AI ecosystem Runtime trust also extends beyond individual agents. As MCP adoption accelerates, enterprises should verify trusted servers, authenticated tools, approved capabilities, monitored interactions, and policy enforcement. RAG knowledge repositories require document integrity, source validation, access control, retrieval auditing, and poisoning detection. Persistent AI memory should implement lifecycle management, expiration policies, integrity verification, access logging, and sensitive data protection. Building operational visibility One of the biggest challenges in enterprise AI is observability. Security teams need visibility into why an agent selected particular tools, which data influenced its decisions, how it reached its conclusions, what actions it executed, whether policies were triggered, and which safeguards prevented unsafe behavior. Runtime logging, audit trails, and behavioral analytics are becoming essential components of enterprise AI operations, not optional add-ons. A practical roadmap Organizations do not need to rebuild existing security programs. Instead, they should extend them by incorporating runtime trust into existing governance processes. Practical first steps include inventorying AI agents and their capabilities, applying least-privilege access to tools and APIs, classifying high-risk autonomous actions, implementing runtime policy enforcement, monitoring behavioral anomalies continuously, protecting memory and RAG data sources, requiring human approval for critical operations, and integrating AI runtime telemetry into existing SOC workflows. Looking ahead Enterprise AI will continue evolving toward increasingly autonomous systems capable of collaborating, planning, and executing complex business processes. Security strategies must evolve alongside them. The question is no longer whether an AI agent successfully authenticated. The more important question is whether it continues to behave safely throughout its entire lifecycle. Organizations that adopt continuous runtime governance today will be significantly better positioned to deploy autonomous AI responsibly, reduce operational risk, and build the confidence necessary for large-scale enterprise AI adoption. The future of AI security will not be defined solely by stronger models or better authentication. It will be defined by our ability to establish, measure, and continuously verify trust while intelligent systems are making decisions in real time. Ravindra Annam is a cyber security architect.

8/30/2026

There is a clear repeating trend in agent deployments: The gateway is the first control teams reach for, but it is the one they are least ready to run. This is because gateways sit on top of identity and attribution layers that are mostly not there. The first layer of risk is not hypothetical. In June, CISA added a LiteLLM flaw to its Known Exploited Vulnerabilities catalog after attackers were caught abusing it in the wild. The bug ran commands on the host through the gateway itself, and chained with a second flaw it required no credentials. It was one of seven common vulnerabilities and exposures (CVEs) disclosed in that single AI gateway in a month. This is the layer many enterprises reach for first to secure their AI agents. When considering secure agent architecture, gateway controls should not be the first control. They should be the fifth. Most models on the maturity of agent security describe the controls a company will need in the future. They tend to miss, from my experience, the more difficult problem of describing the brownfield scenario: In what order should these controls be layered in conjunction with an identity and access management system that is already in place? If the control plane is unaware of which agent is acting, who delegated the work, what task the agent is to perform, and what credentials are being used, then the context is incomplete. A gateway may block clear policy violations, but will struggle to distinguish a justified action from one that is technically permissible but operationally inappropriate. The pattern of failure is clear when sequencing these controls for agent production deployments: Enforcement is taken early, while the identity and attribution context it depends on has yet to be developed. Agent security functions as a dependency chain, with each control depending on context generated upstream. The wrong starting point Think about routing agent traffic via a new runtime gateway. A finance-reconciliation agent tries to alter a record in production. The gateway authenticates the user token and checks the API call. What it can't observe is that the request is agent-initiated, that the agent is executing a more limited function, or that the request is part of a tool chain invoked by an untrusted artifact. The credential is valid. The API call is permissible. The action contradicts the purpose of the delegation. The gateway is there, but its set of supports seems absent, so a costly control is applied to a very small part of the whole picture. Limiting an agent's privileges to those of the human principal is useful so the agent does not exceed the person it serves. However, having a privilege ceiling does not create separate attribution. Twenty agents might operate under a single person's permissions and still need unique identities, audit logs, behavior profiles, and revocation paths. Dependency-gated deployment I call this process dependency-gated deployment. Upstream exit tests must be satisfied before any downstream control is considered operationally complete. Concurrent development of downstream controls is permissible. Here are the six gates, and the proof that they work: Gate Control Operational proof it works 1 Agent inventory and accountable ownership Every production agent has a named owner, purpose, approved tools, and lifecycle state 2 Distinct agent identity plus delegation context The system can identify the agent, its owner, and the principal it is acting for 3 Task-scoped, short-lived credentials A compromised agent cannot reach resources unrelated to its assigned task 4 Attributable telemetry A completed task can be reconstructed from initiation to downstream effect 5 Runtime action enforcement Policy decisions incorporate agent, principal, task, and action context, not just token validity 6 Behavioral baselines and cross-system kill path The agent's effective authority can be stopped everywhere it reaches The six dependency gates for the agent security controls. Each control is contextualized by the gates above it. From the author's analysis of production agent deployments. Start with the agents you can actually name To begin, recognize the production agents in open-source frameworks, cloud offerings, SaaS services, and developer tools. For each, record the owner, responsibility, lifecycle stage, allowed tools, data domains, and sources of credentials. Bypass this step, and the organization will lose the first hour of incident response while they figure out what should have been obvious. The inventory identifies the asset that every control thereafter governs. An agent needs its own identity, but it cannot lose the human behind it An agent should not be buried in a developer token, a shared service account, or a human session. Simply knowing the caller is an agent is not sufficient. The control plane requires additional delegation context: Who delegated the work, what specific task the agent was instructed to execute, and which resources the agent needs the authority to access. Identity specifies which actor placed the call. Delegation is the answer to whose authority it acts, and for what reason. Once that connection is cut off, the downstream logs attribute the reconciliation agent to the employee whose token it borrowed, and every action it takes is attributed to someone who did not start it. Shrink authority before you inspect behavior Once an agent can be identified, capabilities should be limited. Access restrictions should be time-bound to the task and limited to the tools and resources required to perform the task. This can be implemented using identity access management (IAM) features such as workload identity, token exchange, conditional access, and time-bound entitlements which the organization already possesses. With regard to the 2026 Teleport study involving 205 security leaders, the access scope surpasses the predictive capacity of industry, maturity, or self-assurance concerning predicting AI-related incidents. For example, organizations with over-privileged AI reported a 76% incident rate, whereas AI incidents occurred in 17% of organizations under the least privilege. This indicates that access scope in the dependency chain is more important than context-aware runtime enforcement. The primary principle is monotonic delegation. Every transfer of responsibility must preserve or diminish authority; under no circumstances should it increase authority. For the reconciliation agent, this means an agent who can view one ledger as opposed to one who inherits the employee's access to all systems the employee can access. Fix attribution before automating enforcement Most audit stacks can capture what resource was accessed and which credential allowed access. In the agent deployments I have reviewed, this is the most commonly missed gate. Prior to utilizing an adaptive runtime policy, link any relevant tool invocation to the agent identity, initiating principal, task id, parent action, and outcome. After doing so, examine the telemetry: For one completed task, see if you can track down the initiator, the agent who executed it, the authority under which the action was taken, the tools utilized, and the outcome. In regulated environments, oversight that is not attributed cannot be justified. Now the gateway earns its keep The gateway can use registered identities, explicit delegation, scoped credentials, and attributable telemetry to question if this agent is authorized to perform this action, for this principal, within this task, involving this resource. Although the user's credentials may provision write access to the finance-reconciliation agent, the gateway has situational context and so determines that it is out of scope. This is control's point of greatest value. The most stringent controls should be applied at irreversible boundaries — payments, access policy changes, deletions, modifications of the production environment, and data exports. Detection and the kill path come last Behavioral baselines are developed last because distinguishable and attributable agent activity must be established to set a standard. Then, security teams are able to identify anomalous patterns of tool usage, unexpected cross-domain access, and deviations from their assigned tasks. Containment is more than just the disabling of a single directory object: A proper kill path entails disabling the agent's identity, invalidation of active and derived credentials, blockage of tool activation, termination of active tasks, and isolation of the workload that contains the agent. Start without replacing your IAM Designing a whole new identity program is unnecessary. If the existing identity provider doesn't treat agents as native object types, begin with an authoritative registry linked to the existing workload identities. Following this, extend agent and task identifiers as trusted execution contexts, implement short-lived credentials to mitigate inherited privileges, and include those identifiers in tool-call logs for subsequent gateway ingestion. The dependency model remains unchanged as vendor support matures. Control gaps are measurable. In Okta's 2026 survey, only 34% of executives said their organization always applies the same level of security rigor to its agentic workforce as to its human workforce. The last control from the chain cannot be applied first to close that gap. What to do in the next 30 days Begin with 10 production agents. For each one, identify the owner, purpose, approved tools, and credentials. By now, you should have the beginnings of an agent registry and perhaps your first insights on governance. Test attribution. Find out if IAM and logging can tell each agent apart from the human or service that delegated the task. If this kind of differentiation is not possible, a gateway would be operating without any visibility. Reconstruct one completed agent task within an action chain, from start to finish, including downstream effects. Wherever the chain breaks is where your deployment falls short. Adding downstream enforcement ahead of required context breaks agent security. Maturity models describe the destination. A build order gets you there without breaking production along the way. Nik Kale is a principal engineer specializing in enterprise AI platforms and security.

8/28/2026

Presented by Nutanix Autonomous systems that can reason, make their own decisions, and execute actions across an environment introduce a category of risk that application-level controls were never built to contain. Treating that risk as a single problem produces incomplete architectures, says Oscar Wahlberg, senior director of product management at Nutanix. "The guardrails to catch a malicious prompt won't stop an agent from hallucinating and doing something it never should have done, like accidentally deleting databases or leaking sensitive data with a credential it was granted but then uses for something entirely different," Wahlberg says. "That's the central problem as enterprises move autonomous agents out of experimentation and into production." Once an agentic system is granted execution privileges across the data center, the security posture has to scale into a defense-in-depth architecture spanning infrastructure, storage, compute, networking, and a governing control plane. Each layer addresses a distinct category of risk, rather than duplicating the same controls across the stack. No single security control or vendor can provide that protection on its own. Defense-in-depth depends on those layers working together. By dividing the responsibilities across the stack and adhering to zero trust segmentation, organizations can create a secure framework that improves their overall posture. Understanding which risks belong in each layer is what turns the principle of defense-in-depth into a practical security framework, with three layers that each have a distinct responsibility. Infrastructure layer: Establishing trust where AI agents run The infrastructure layer’s foundational responsibility is establishing a root of trust that answers a simple question: who is operating in the environment? That trusted identity becomes the prerequisite for every security control above it. Before an organization can trust what an agent does, it first has to trust the integrity of the environment where the agent runs. When an agent requests permission to execute an operation, the system must be able to verify that the request came from the legitimate agent — not something impersonating it. Delivering that kind of assurance depends on technologies that root trust in the hardware itself, including platform attestation, confidential computing, and secure boot, alongside controls that prevent unauthorized access both within a server and beyond it. For regulated industries such as financial services, this layer provides the ability to isolate AI production workloads so that neither the agent nor the environment can operate outside its assigned scope. That mitigates risks including model and runtime tampering, supply chain compromise, and unauthorized access to sensitive AI workloads. Network layer: Governing how AI agents communicate Once agents begin communicating with other agents, APIs, applications, and enterprise systems, they generate a level of concurrency and dynamic communication that traditional static network configurations were never designed to handle. An agent configured to call APIs, query data sources, and spin up additional agents without constraint creates a sprawling web of east-west traffic that becomes very difficult to reason about, and that complexity can easily mask lateral movement or data exfiltration when the right network security layers are not in place. "We should treat AI agents as a new class of network identity, and make sure that an agent can only talk to other agents or data sources where it's explicitly allowed to do so," Wahlberg says. "That means moving away from rigid static rules toward dynamic policy enforcement." Nutanix's solution is Agent Gateway, part of the Nutanix Agentic AI solution. It's a unified, governed layer that is designed to provide cost control and governance capabilities to help manage autonomous agent users. Coupled with agents grounded in zero trust segmentation and using capabilities like Nutanix Flow for micro segmentation and integrating with networking vendors, including its integration into the Cisco Secure AI Factory, Agent Gateway helps enterprises govern interactions across agents, models, data sources, and enterprise applications. The network layer governs lateral movement, data exfiltration, and gates the agent's network interactions. A zero trust framework with access blocked by default and scalable interaction monitoring is important for agents since they can exhibit unreliable behavior. The Nutanix software integration with Cisco UCS servers and Cisco AI PODs delivers the turnkey physical infrastructure (compute, storage, and networking) that the AI factory runs on. Control plane layer: Governing what AI agents are permitted to do The control plane is the brains of the operation, providing a central point for managing agent permissions, tool access, resource consumption, and runtime visibility. What matters most is having a single place where policies can be enforced consistently rather than reinvented for every agent, Wahlberg says. "Agent Gateway acts as a universal endpoint for different models and tools, so an IT team can configure their agents to talk to this single control point," he explains. The centralized AI gateway enables the admin to observe, audit, and control access to models as well as MCP tools protecting data and gating privileged access. This layer is designed to help mitigate risks such as privilege misuse, runaway agents, unauthorized tool usage, data leakage, and the excessive model consumption that can lead to increased token consumption when agents get stuck in runtime loops. And it depends on treating governance as a runtime control system rather than a compliance afterthought. Why one-size-fits-all security fails agentic AI environments The biggest architectural mistake enterprises make is assuming a single security model can be stretched across every layer of an AI stack. When an organization tries to solve for hardware-level trust with application-level software, or leans on static legacy network rules to manage dynamic agents, it builds an architecture that either blocks the agentic system from doing its job or leaves critical doors wide open. One-size-fits-all thinking tends to produce significant performance penalties and operational friction. "By failing to assign specific responsibilities to the appropriate layers, enterprises end up with blind spots in governance," Wahlberg says. "They might secure the model output but miss that there's data leakage between agents, or they might secure the network but lack the control plane visibility to understand that they're wildly burning tokens because the agents are stuck in some kind of runtime loop." Focusing exclusively on the model leaves the largest gaps of all, because a guardrail that catches a malicious prompt does nothing to stop a hallucinating agent from misusing a legitimate credential. Embedding security across the full stack helps ensure that even when a model level threat slips past the initial filters, the agent remains constrained by hardware rooted trust, network isolation, and access controls at the agent layer. How Intel, Cisco, and Nutanix build defense-in-depth together The three-way partnership from the three companies demonstrates how the layered architecture comes together in practice as a well-governed, enterprise-grade AI Cloud. Intel supplies the computer to run agentic workloads and secures the execution environment through hardware-rooted trust and confidential computing, while also driving costs down through their accelerators. Intel Xeon 6 processors with built-in AMX accelerate AI inference efficiently without relying exclusively on expensive GPUs. Cisco wraps the environment in a secure fabric that governs communication between agents and enterprise tools, while Nutanix provides the software platform, minimizing architectural silos, and the central control plane that enforces permissions, delivers visibility and cost governance, and ties the architecture together into a defense-in-depth solution that lets enterprises scale agentic AI. Of the three layers, enterprises currently underestimate the control plane the most, Wahlberg says. A true control plane extends far beyond initial deployment to simplify Day 2 operations, he explains, giving IT teams the continuous observability, and strict token governance required to keep autonomous agents secure and cost-effective in production. "Apart from model and tool selection, governing the agent deployments and their access to models and business tools in a tightly integrated full stack platform will be important for the success of AI projects," he says, pointing to a near future in which organizations move from a handful of AI use cases to thousands of agents working autonomously to drive the business. Technology leaders should prioritize building a centralized governance layer today that can manage agent identities, tool permissions, and token budgets in real time, because that control point is what builds the operational muscle to scale safely. "You can't build an AI system without getting into a lot of complex decisions," he explains. "And you need a control plane that talks across multiple vendors and infrastructures to help you solve for those defense-in-depth strategies." Learn more about the Nutanix Agentic AI solution here. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/28/2026

Consider an AI agent tasked with a complex enterprise workflow like migrating massive batches of customer records from a legacy CRM to a cloud database. The agent cannot rely solely on its internal context window for a job spanning hours and depends on the runtime layer, aka the harness. This harness provides execution feedback, like server logs, to help the agent maintain an accurate understanding of dynamic API connections. It also provides state trackers and control-flow mechanisms to manage completed and pending subgoals, ensuring the agent doesn't skip or duplicate data batches. When unexpected errors occur, such as a database rejecting a batch due to strict API rate limits, the harness provides tools and instructions to help the agent recover. The main way to tell an agent how and when to use its tools is to have a human developer write a set of rules and instructions telling it what to do step-by-step. For example, a developer might instruct the agent to always search the company wiki before writing an email. Because the agent is just following a rigid script, it lacks true autonomy. It hasn't been trained to independently weigh the costs and benefits of its actions. To solve this, researchers at Meta AI and University of Illinois Urbana–Champaign introduce EvoHarness-RL, a framework that adds a layer of abstraction to the agent's harness and teaches the underlying model when to read, update, or consolidate the information it obtains from its environment. In long-horizon tasks, how AI agents read and process the information they obtain from their environment is pivotal to their success. The agent must update its understanding of its environment, track completed and pending subgoals, recover from failed actions, and reuse procedures from previous experience. This execution depends on the harness. A series of self-evolving agentic frameworks like Harness-1 solve part of the problem by accumulating past trajectories and distilling them into structured procedural memory, like reusable skills, workflows, or code libraries for future tasks. However, they generally separate this long-term skill curation from real-time, within-episode state tracking. They aren't actively training the agent on how to manage its immediate environmental reality or track its active task steps while working. Xuying Ning, co-author of the EvoHarness-RL paper, told VentureBeat that manual logic and rigid memory structures are primary culprits draining engineering resources. "The optimal harness often changes with the model," Ning explained. "Different models may need different prompts, memory designs, permissions, or sandbox configurations. If all of this logic is manually coded, every model upgrade can lead to another long cycle of tuning and debugging." Furthermore, existing memory systems that simply accumulate experience can actively degrade an agent's reasoning. "Append-only memory assumes that more context is always helpful, which is not necessarily true," Ning said. "Over a long task, the memory may contain outdated conclusions, failed attempts, or information that is no longer relevant." As a result, long-horizon agents need a dynamic memory capable of updating, compressing, and replacing information to avoid repeating past mistakes. EvoHarness-RL: A unified belief, progress, and experience workspace To overcome the limitations of rigid, manual prompts, the researchers introduce EvoHarness-RL, a training technique that teaches the agent to make optimal use of its harness. Instead of blindly following hardcoded instructions, the agent learns how to construct a structured workspace from messy execution data and decide when and how to consult that external state during complex workflows. To simplify the management of different components of the harness, EvoHarness-RL consolidates the agent’s support systems into a single, unified interface. This interface, known as the Belief, Progress, and Experience (BPE), categorizes the agent's external needs into three functional areas: Belief: Maintain an accurate read on the current environment. Progress: Manage completed and pending subgoals. Experience: Reuse historical knowledge across tasks. Instead of using complex, domain-specific APIs, the AI interacts with this clean dashboard using four compact meta-actions: track, commit, recall, and note. It issues commands to track the live environment, commit to workflow updates, recall past strategies before acting, and write notes to save newly discovered insights for future runs. These states map directly to high-value enterprise verticals. "In software engineering, Belief can represent the agent’s current understanding of the repository," Ning said, detailing how the agent monitors component interactions and workspace changes. "Progress tracks what has already been completed, what still needs to be done, and which steps depend on others." Meanwhile, Experience captures lessons, like user feedback on a mistake, to guide future actions. The same idea applies to finance, Ning said. During a compliance audit, Belief might describe the applicable rules and available evidence. Progress tracks which checks have been completed and which exceptions remain open. Experience helps the agent recognize recurring discrepancies or know when an issue should be escalated. "Together, these states help prevent the agent from losing track of its work or repeating the same failed approach," Ning said. To teach the agent both the mechanics and the strategy of managing its external workspace, the researchers designed a two-stage training recipe. In the first stage, supervised harness fine-tuning, the base model learns how to extract and structure useful facts from messy interaction logs into the BPE framework. However, querying memory or updating trackers consumes time and compute tokens, meaning the agent cannot afford to blindly check its tools at every step. To solve this, the second stage uses “cost-aware” reinforcement learning to teach the agent efficiency. This phase trains the agent to calculate when accessing its external state is worth the budget cost. This two-step process transforms tool-use from a rigid, hardcoded prompt into a learned runtime behavior. EvoHarness-RL in action To validate EvoHarness-RL, the researchers evaluated the system using the ALFWorld benchmark, a text-based environment featuring multi-step tasks that test sequential logic and state tracking. They used Qwen3-8B as the base model to train. The team pitted the trained 8B model against three large frontier models (Claude Opus 4.5, GPT-4.1, and GPT-5), frozen agent frameworks with static tools (such as ReAct, ExpeL, and ReasoningBank), and advanced trainable methods (e.g., standard GRPO, SkillOS, and SkillRL). The results show a significant jump in performance for smaller, cost-effective models. With EvoHarness-RL, the Qwen3-8B model achieved a 96.9% average success rate, a 49.0 percentage point improvement over its baseline ReAct counterpart. Furthermore, the trained model outperformed advanced trainable frameworks like SkillRL (89.9%) and SkillOS (80.2%). Most impressively for enterprise developers looking to optimize compute costs, the 8B model effectively matched the performance ceiling of expensive closed models like Claude Opus 4.5, which scored 96.4% out-of-the-box. Beyond empowering smaller models, the experiments show that the BPE framework has universal benefits across all model scales, even without the extensive reinforcement learning phase. When researchers equipped frozen, out-of-the-box frontier models with the BPE prompt-time harness, their execution improved significantly. GPT-4.1's success rate improved by 22.1 points and GPT-5 by 25.7 points. Aside from the results, the researchers recorded effects during the experiments that demonstrate the dynamic behavior the LLMs acquire as they go through the EvoHarness-RL training. During the reinforcement learning phase, they observed a behavioral shift as the agent internalized knowledge over time, which they called "harness annealing".  Early in training, the AI relied heavily on querying its Experience and Progress trackers for almost every step. However, as it mastered routine actions, it actively reduced its reliance on external tools, embedding the successful patterns directly into its parameters. In a real-world enterprise setting, this translates directly to lower latency and reduced compute costs. By annealing its tool usage, the AI stops wasting tokens and time querying databases for standard workflows it has already mastered. Simultaneously, the agent demonstrated "harness evolution," where it dynamically adapted its strategy based on the complexity of the situation at hand. While it bypassed its tools for simple, familiar tasks, it actively chose to scale up its use of the Belief and Experience modules the moment it encountered novel environments or unexpected roadblocks. For example, if an AI agent is migrating standard database records, it moves fast. When it encounters a strange legacy API endpoint or a complex validation error, it slows down, pulls up the live server logs, and queries its historical tickets to safely resolve the edge case rather than hallucinating a guess. Bringing EvoHarness-RL into existing systems Despite these massive gains, adopting a new framework often introduces friction for enterprise engineering teams. However, EvoHarness-RL utilizes an environment adapter that allows internal implementations to remain domain-specific to an organization's existing tools while sharing the trainable layer. "I think there is significant potential to integrate BPE into existing orchestration systems," Ning said. "It does not necessarily require teams to replace their current tools or agent frameworks. BPE can work as an additional state-management layer that continuously organizes what the agent currently believes, how far it has progressed, and what it has learned." For enterprise builders worried about inference costs, the framework addresses the hidden engineering cost of consolidation. Because consolidation requires strong reasoning, teams can adopt a hybrid, asynchronous architecture to optimize budgets. "One possible compromise is to use a frontier model to generate high-quality consolidation data, then fine-tune a capable open-weight model to handle routine state management," Ning said. Furthermore, "because consolidation can happen asynchronously, it does not always need to slow down the agent’s main execution loop." Teams must also carefully evaluate when a trainable BPE harness is necessary versus when it is overkill. "For a short and stable task, ReAct or standard RAG may already be sufficient," Ning said. "BPE becomes much more valuable when an agent works for many hours, days, or even weeks." In those complex scenarios, an agent needs a compressed understanding of its decisions to avoid getting lost, relying on Experience to iteratively improve from previous failures and human feedback. Ultimately, this approach signals a shift for AI orchestration engineers. "It is not a complete replacement of workflow engineering," Ning said, "but a transition from directly scripting agent behavior to creating systems in which better behavior can be learned."

8/28/2026

Enterprises trying to feed PDFs, slides and scanned documents into AI pipelines keep running into the same wall: the tools either miss the structure — tables, charts, layout — or cost too much to run at scale. Cohere released Parse 5 on Thursday, positioning it on price-to-performance, not raw accuracy — the right cost-capability mix for enterprise scale. Parse 5 is a 2.3-billion-parameter vision language model built to convert PDFs, slides and images into structured Markdown at enterprise scale.  Cohere's own published benchmark comparison puts Parse 5 behind three larger, general-purpose frontier models on accuracy. GPT-5.5, Opus 4.8 and Gemini 3.5 Flash all score higher than Parse on the three ParseBench dimensions Cohere reports. Cohere is not claiming the top score. It is claiming the best price for a score close to the top.The company priced the model at $1.50 per 1,000 pages through its API, with Model Vault, Cohere's secure, single-tenant platform for managed inference, available for higher-volume deployment. "Document parsing isn't solved because the hard part isn't reading text, it's preserving structure and meaning," Nils Reimers, VP of AI Search at Cohere, told VentureBeat. "Enterprise documents mix tables, diagrams, charts, and formatting that change the interpretation of the data. Most tools still drop structure or hallucinate content, and even frontier models break on layout‑heavy pages." Inside the single-pass architecture Parse 5 takes a page as an image, runs it through a single vision-language model pass and returns structured Markdown, collapsing the OCR-plus-model pipeline most tools run as separate steps. Architecture. It is a 2.3-billion-parameter vision language model built on Cohere Labs' North-Micro-Vision-Instruct architecture, with an 8,192-token context window and roughly a 4.6-gigabyte footprint. It accepts a PDF, PowerPoint or JPEG page as a base64-encoded image and returns Markdown in reading order, with tables rendered as HTML, image descriptions and bounding box coordinates for tables and images. Language coverage. Arabic, English, French, German, Italian, Japanese, Korean, Portuguese and Spanish get stable accuracy, with lower-accuracy zero-shot support elsewhere. Output modes. The default output returns a Markdown string per page. A blocks mode returns typed elements, where each table carries its own HTML, bounding box and description, the format Cohere positions as what makes citation-level traceability possible for agents. Availability. Parse 5 is generally available now through the Cohere API, Model Vault, Microsoft Foundry and AWS SageMaker. The benchmark shows a trade-off, not a win ParseBench is a benchmark that scores document-parsing tools against human-verified enterprise pages. Cohere reports Parse 5 scoring 79.2 across three dimensions: tables, content faithfulness and semantic formatting. That puts Parse 5 behind GPT-5.5 (84.4), Opus 4.8 (84.3) and Gemini 3.5 Flash (81.8), and ahead of LlamaParse's Cost Effective tier (78.3), Mistral OCR 4 (74.5), Databricks AI Parse (72.4) and Azure Document Intelligence (69.3). Cohere's table notes two excluded dimensions, Layout and Chart, and attributes both to product scope rather than a performance gap. Parse 5 returns reading-order Markdown instead of per-element bounding boxes for text, and describes charts rather than extracting their underlying data, with chart-data extraction planned for a future version. Reimers said that design choice reflects where agentic workflows actually break. "For charts, for example, we provide a general description of the chart together with an indicator, how Agentic AI can visually inspect the chart," Reimers explained. "Other solutions try to extract the data from the chart, but then miss out critical information (for example, the color or the pattern of a line) that leads to hallucinations in Chat and Agentic AI applications." Cost is where Cohere makes its real case. Reimers pointed to a workflow the company modeled for a large financial services firm. "We ran the numbers for a large financial services workflow that processes 750 million documents a year and showed that choosing Parse 5 over a large general‑purpose model like GPT‑5.5 would reduce costs by more than 98 percent." That figure is Cohere's own estimate for a single modeled workflow, not an audited deployment. Where Parse 5 sits against the field There is no shortage of options for enterprises looking at parsing solutions. General-purpose frontier models, GPT-5.5, Opus 4.8 and Gemini 3.5 Flash, top the accuracy comparison but carry the cost and latency of a large model on every page.  Then there are specialized parsers, including Mistral OCR 4, LlamaParse and open-weight options like Chandra OCR 2 and RedNote's dots.mocr. Hyperscaler document intelligence services, AWS Textract, Google Document AI, Azure Document Intelligence and Databricks AI Parse, compete more on ecosystem convenience than on raw parsing quality, and score lowest in Cohere's own comparison. Kevin Petrie, VP of Research at BARC US, said document parsing sits at the center of enterprise AI adoption right now. "We're completing a survey now that shows document analysis is by far the #1 use case for AI, with 62% adoption rates among organizations we polled," Petrie told VentureBeat. "Documents and other unstructured objects, including images and so on, hold the proprietary context that organizations need to differentiate their agentic AI initiatives." Petrie added that only time will tell how Cohere's cost-performance stacks up against frontier models, but strategically his view is that Cohere has the right focus.  Stephanie Walter, Practice Leader for AI Stack at HyperFRAME Research, sees Cohere Parse 5 as sitting in a good spot between legacy OCR and using an expensive frontier model on every page.  "Its potential advantage is delivering structure, spatial provenance and private deployment at a price suitable for high-volume ingestion," Walter told VentureBeat. "It does not need to win every benchmark. It needs to make reliable enterprise-scale parsing economical." The real test is downstream, not on the benchmark "Parsing is the first quality gate in the enterprise AI stack," Walter said. "If tables, headings, images, or reading order are lost during ingestion, better embeddings and larger models cannot recover that missing structure." A benchmark score isn't the only input that matters here. "Enterprises should test parsers against their own most difficult documents and measure downstream retrieval and task accuracy, not how clean the extracted text looks," Walter said. "The right question is not 'Did it read the PDF?' but 'Can the agent now use the information correctly?'"

8/27/2026

Presented by Gravitee Agent complexity is the insidious shadow lurking inside enterprises right now that needs a light shone on it. That’s because enterprises don't deploy a single agent and watch it run, they deploy fleets, each one calling APIs, calling other agents, reaching into applications that were never built with a machine decision-maker in mind. That's the failure mode that should keep you up at night: a windy, complicated system nobody can see clearly enough to govern. But why do things get so opaque so quickly? Add a second agent to a system, and you've added one connection. Add a tenth, and you haven't added ten connections, you've potentially added dozens, because now any agent might call any other, and each of those calls can trigger a call somewhere else. Complexity doesn't creep up with agent headcount. It compounds with the number of paths between agents, and nobody's job is to draw that graph. A support ticket that used to touch one system might now pass through four agents before a human ever lays eyes on it, and every one of those handoffs is a decision point nobody approved. Most enterprise AI programs stall when the humans responsible for their agents lose the thread. Ask a security team a simple question: which agents can reach which systems, and watch the silence. Ask which agent triggered which downstream action three hops ago. More silence. The instinct is to treat this like a checklist. Approve the agent. Log the agent. Move on. I'd argue this is the wrong instinct. A checklist checks a single point in time. Complexity runs across a chain, and you can't govern a chain with a stack of one-time approvals any more than you can call a diet successful because you had a vegetable once. So where does it actually break down? Permissions creep first. Somebody builds an agent to summarize support tickets, grants it broad API access because scoping it properly would've taken another sprint, and forgets about it. Six months later, that same agent has a path into the payments system. Nobody remembers signing off on that. Nobody did. And ownership thins out the further the chain runs. Five agents touch one workflow, something breaks at step four, and now you're asking who's responsible for a link nobody was ever assigned to own, because the org chart stopped at "deploy the agent" and never got to "name the human who answers for it." This is a story about governance infrastructure that hasn't caught up with how agents actually behave: interconnected, cascading, multiplying faster than the processes built to track them. Fixing the cluster starts with identity. Every agent needs to exist as its own entity, not a shadow permission borrowed from whoever deployed it. Its own name in the register. Its own scoped authority. A named human sponsor who answers for what it does. That part is necessary. But it is nowhere near sufficient. The harder piece is the oversight that holds across the entire chain, not just at each individual link in it. You need to see what an agent did, what it set off downstream, and where that trail ends in real time, not in a report someone pulls together once a quarter. Get agent-level identity right and stop there, and you end up with a filing cabinet full of perfectly documented agents operating inside a system nobody can actually explain. And oversight by itself only tells you what already happened. Watching a chain isn't the same as controlling it. Enforcement is the piece most programs skip: the ability to stop an out-of-policy call before it executes, not just log it for someone to find in a review three weeks later. A dashboard that shows you an agent breached its scope five minutes ago is a monitoring tool. A system that stops the breach from happening in the first place is governance. Enterprises serious about agent accountability need both, and most have only built the first. We're all running at blazing speed to ensure we're not the ones left behind in the race we've found ourselves in, and we're all too aware that there's a cost to slowing down. Every enterprise serious about agentic AI hits the complexity wall eventually. The ones that get past it are the ones who built enough visibility and accountability, so their fleet can keep growing without anyone losing the ability to answer one question: what is this system doing right now, and who's responsible for it. But don't miss the point. Complexity isn't a reason to pump the brakes. The enterprises getting this right aren't slowing down. They're building toward Human-Agent Harmony, where scale and accountability grow together instead of trading off against each other. The real risk was never a single agent doing exactly what it was built to do. It's a hundred of them doing exactly that, all at once, interacting in combinations nobody designed for. That kind of multiplication is what keeps enterprise AI stuck running pilots forever instead of running production. Solve for complexity and autonomy stops being the villain. It starts being the whole point. Rory Blundell is CEO at Gravitee. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/27/2026

Visa's open-source security harness now finds the vulnerability, writes the fix, and turns an adversarial panel on its own patch before any human reviews it. The whole loop ships on by default. A plain scan of the Visa Vulnerability Agentic Harness runs all 11 stages and edits source files in the target repo unless the operator caps it at detection. The announcement Thursday pairs the release with an expansion of the Visa Consulting & Analytics advisory practice. Visa is shipping that default 18 days after Tenet Security demonstrated GhostJacking on the DEF CON 34 main stage, an attack chain in which an agent read an attacker's payload out of a log file and rewrote DNS with a valid credential. Two days earlier, Steve Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, made the case in VentureBeat for the opposite default. "The first thing I'd do is put an authorization gate outside the model," Wilson said in written responses. "The agent can propose the exact DNS change, but it cannot grant itself the authority to make it." The bottleneck moved, so Visa moved the pipeline Rajat Taneja, Visa's president of technology, rejects the premise that the default is a risk decision and calls it the product. "The bottleneck has moved," Taneja told VentureBeat in an exclusive interview. "AI is finding vulnerabilities faster than humans can in the history of our technology industry. The new bottleneck is fixing and proving we have fixed things." VVAH grew out of Visa's participation in Anthropic's Project Glasswing, where the company aimed Claude Mythos at the network behind billions of daily transactions and watched the model chain minor weaknesses into working exploits, a hunt VentureBeat covered in July. "VVAH initially was completely only using Mythos, and that's when all of us, as part of Project Glasswing, realized the power of this new class of models that does semantic reasoning," Taneja said. The harness went to GitHub in June and has climbed from 595 stars and 97 forks on July 20 to more than 2,300 stars and 300 forks as of August 25, with a clone-to-visitor ratio Taneja put near 9%. "We have got some very high-profile companies that have started using this harness," he said. Why give it away? Taneja's answer starts with Visa's technology DNA and a harness built "to protect Visa and our ecosystem." The reason he leaned on hardest was obligation, "to do good by doing right" for "companies who may not have the same level of investments or knowledge in cybersecurity." Contribution runs one way. The repo states it is not currently accepting external code contributions, so the harness that edits adopters' source takes no code into its own. Thursday's release extends the pipeline past the report. "We're going from discover, verify, and report, and then fix it, to discover it, verify it, remediate it, validate it, and iterate it," Taneja said. "If a fix doesn't negate the exploit, then there should be a structured, automated feedback that preserves the learnings from the first run and then enhances it." Underneath that loop, the release refactors scanning around an abstract syntax tree call graph that maps subroutine calls and the traversal paths an attacker could reach. Taneja argued the change cuts token counts while delivering "better reasoning, context, and better exploitability analysis." On top sits MTTA observability across the stages, what he called a window pane, plus real-time progress views. "A pretty good step function," he said of the release. One metric, three definitions Mean Time to Adapt, the metric Visa invented alongside the harness, gets a shorter definition in this release. The short form is the time between discovery and resolution of attack paths, with some resolutions, Visa claims, shrinking from weeks to hours. Visa published a wider construction in June, and the Project Glasswing white paper tracks MTTA along three dimensions that include inventory freshness, exploitable paths per release, and validation cycle time. The repo carries a third, elapsed time from AI-discovered exploitability to a validated fix in production. Board slides will quote the shortest interval. Ask for all three, because a resolution count that skips validation is what MTTA was invented to replace. Taneja ranks MTTA as "the most strategically important metric" because it shifts the focus from scanning to how fast an enterprise adapts. His shorthand is blunter. "It's not the finding. It's the fixing that matters," he said. The default and the gate Wilson's argument went past naming the gate. "We have to remember that security rules written inside prompts may shape the model's behavior, but they are still suggestions to the model, not enforceable security controls," he wrote. He also priced the control honestly. "The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation," Wilson said. The harness ships no approval step between patch and edited file. Where the human sits was the first question VentureBeat put to Visa in writing. The company's own June white paper sets the bar. "AI agents are identities" sits among its 12 non-negotiable practices, requiring scoped permissions, least privilege, audit trails, and IAM governance for every agent that modifies a system. VVAH's shipped default is that agent. "A lot of the traditional systems that are used today are basically signal providers," Taneja told VentureBeat. "They are telemetry, and then it's a lot of human analysis, and your SOC and your security and incident response teams doing a lot of the heavy lifting when they respond," and that, he said, cannot work at this scale. He pointed to the Hugging Face incident and "other frontier models escaping sandboxes to do things more autonomously" as the preview. "We have seen the trailer of this movie," Taneja said, and "every company in the world should prepare and rethink their architecture." What the harness automates is the adversarial step. Before a fix counts as validated, the panel scores whether the patch negates the exploit, Taneja's test for done, with failed fixes feeding the next attempt, the iterate step Taneja described. Stage 11 itself runs read-only, per the README, and VVAH does not compile, build, or run tests against the patched tree. Taneja calls that wrapper "the governance architecture on top of that," and chaining findings into working exploits takes threat modeling and business context, which is why he argued "the harness with a model is far more effective than somebody using the model by itself." Visa answers the gate question VentureBeat put its questions to Visa in writing after the interview, and the answers arrived before publication. On why remediation ships on, the response repeated the bottleneck argument, then narrowed the scope. "VVAH is meant for authorized operators running against code they own, and in a controlled environment," the company said in written responses. The approval question drew the most specific answer. "VVAH is a harness, not a merge tool," Visa wrote. "Stage 10 writes candidate fixes to a working copy of the repo. Stage 11 then runs an adversarial validation panel that scores each fix and returns one of three verdicts: validated, validation failed or needs review. None of these bypasses your normal build, test, and code review flow." Humans, the company wrote, are "the gate in three places. Before running the tool. When reviewing the patches. And before anything gets merged." "The final call on any fix stays with the security and engineering teams. In an enterprise, trust and auditability are not optional. The default flow is built around that." Set beside Wilson's standard, the architecture lands close to his line and the sequence does not. Wilson's gate clears an action before it happens. The default's human gates open before the run and after the write. The attack is the automated part, and the three human gates sit outside the model, the boundary Wilson drew. "Our goal is to help security teams work at AI speed, not to replace them," Visa wrote. "VVAH does the repetitive parts. It finds issues, tests whether they are real, and proposes fixes. Before a fix gets to a human, an adversarial validation panel at stage eleven tries to break it. That way the human is spending time on decisions that need judgment, not on triaging noise." Client zero got direct confirmation. "VVAH runs against Visa code today," Visa wrote, and Taneja had volunteered the posture on the call. "We designed this and we were using it for ourselves, and we were client zero," he said, adding "only when we saw the impact and the positive effect of what we were finding, we said every company would need this." What adopters value, Visa says, is context. VVAH pulls in CMDB data, threat models, and business risk, and where "most tools stop at findings," it "tries to answer, 'which of these should you fix first, given how your business runs.'" Model choice becomes a per-stage decision Multi-model orchestration is the other substantive change. "Mythos has a very high recall, but the Opus model has very high precision," Taneja said. "On stage one I want to use this model. On stage two I want to use this model," is how Taneja framed the per-stage setup, with newer GPT releases in the ensemble and open-weight models where pricing stings, all through configuration rather than code changes. "The whole is greater than the sum of the parts," as he put it. The harness was model-agnostic from day one, he added, and the evolution moved that choice into configuration, with prompt tuning and caching shared underneath. One boundary moved. In June, applying a fix required Anthropic backends, and OpenAI-compatible backends ran report-only. The current README extends remediation and validation to OpenAI-compatible and open-weight models through a shared model-agnostic runtime, with no single provider as a hard dependency, and the default routing for both stages stays Anthropic. That flexibility lands on a market already churning. VentureBeat's Q2 2026 Pulse research found 59% of enterprises plan to adopt or switch agent security tooling within the year, and 82% still rely on provider-native controls as the primary layer. Visa said Thursday it is contributing VVAH to Nvidia's Open Secure AI Alliance as a model-agnostic framework and collaborating in Project Lightwell, the $5 billion IBM and Red Hat effort to harden open-source components. Before turning fix mode on Decision What to establish first Run posture Start with --stop-after s9 and read the SARIF output before any run that can write to source files. Approval gate Map Visa's three human gates onto the pipeline, at run, at patch review, and at merge, and name who holds each. Validation scope Stage 11 verdicts score the fix. Build, test, and code review stay in the team's own flow, per Visa, so keep an exploit re-test before merge. Repository scope The tool runs with elevated privilege, per its own README. Fence which repos the harness can reach, and run scans in an ephemeral environment with scoped credentials, no production secrets, and network limited to the target repo and model endpoint. Write access to production code is the GhostJacking exposure class, an agent acting on data it read. Per the README's egress warning, any role routed through the SDK, OpenAI, or DeepAgents backends sends prompt data to that provider's endpoint. Model roles Assign models per stage deliberately. Recall and precision differ by model, per Taneja, the fix stages carry the highest blast radius, and the README states precision and recall figures are not yet published, so measure your own. Consulting is the other half of Thursday's announcement. Visa Consulting & Analytics is adding executive workshops, a VVAH-informed maturity assessment scored on a NIST one-to-five scale, and a cyber risk prioritization roadmap. "We were getting a lot of calls. Hey, can you help?" Taneja said, and the practice "became very important to handhold and help those who are using it." Carl Rutstein, global head of Visa Consulting & Analytics, framed it the same way. "Finding vulnerabilities is no longer the hardest part. Speed to remediation is the new battleground."

8/27/2026

Presented by EDB As enterprises give AI agents more autonomy — the ability to plan, decide, and act across systems without a human approving each step — a hard question moves to the center of every architecture review: When an agent tries to complete an action that it was never authorized to do, what actually stops it? These are your agents, running on your models, touching your data in your infrastructure — and the responsibility for what they do sits with you. That responsibility can’t be met in hindsight or with a set of abstract policies that live on paper but not in practice. Agents need rules in the context of the moment, because they don’t exercise overriding judgment of their own actions. Consider a simple rule: Never open the car door. Followed literally, an agent could never get in or out of the car at all. But if you change the context (the car has just crashed, there’s a fire, someone is hurt and needs to get out), then the rule you actually want is the opposite. Context in the moment is everything. We are asking agents to do intelligent things; that requires intelligent rules. The instinct is to add guardrails around the agent: instructions, policies, and monitoring layered above the model. Those mechanisms matter, but they share a structural limit: The car-door rule is plausible right up until the moment you actually have to decide whether to open the door. Controls at the agent layer are only as reliable as the agent’s output is predictable, and autonomy is precisely the property that makes that output hard to predict. Governance that depends on reviewing an action before it happens cannot keep pace with a system that acts in milliseconds, across many systems at once. Governance has to become executable, and enforced where agents actually do their work: at the operational data layer, in the context, and exactly at the moment it is happening. The data layer is the enforcement point Agents create value by touching data. They query it, retrieve it, transform it, and increasingly act on it. A policy that says an agent should not reach a certain class of data is meaningful only if the system can deny that access at the moment the agent requests it. Additionally, a principle that says AI must be auditable is meaningful only if the organization can reconstruct what the agent did, what data it touched, which user it acted for, and what resulted. When governance lives at the data layer, it holds regardless of how the agent was built or how it behaves, because the control is a property of the database itself, not a promise made by the agent. Agent behavior may be probabilistic. Governance cannot be The enterprise should not rely on a model choosing to follow policy. The policy has to be enforced by the system. That is the difference between hoping an actor stays in bounds and constructing bounds it cannot cross to begin with. The controls that make this real are ones many enterprises already run at the data layer: role- and attribute-based access, row- and column-level security, classification and masking, policy as code, and complete audit trails. What agents change is not the mechanism, but who the mechanism has to recognize. Identity management has to treat the agent as a principal in its own right, with its own identity and a purpose declared when the session opens. Once purpose is bound to identity, the policy engine can evaluate it the same way it evaluates role or department today, and the record of what happened can capture not just who acted and what they touched, but what they declared they were there to do. In practice, this resolves into nine controls, grouped under three imperatives: Enforce it Role- and attribute-based access control enforced at query time, for agents as well as users Dynamic column masking driven by the same policy path Agent identity as a first-class principal, with declared purpose bound at session start and the acting user preserved See it and prove it Classification and tagging that drives policy Session-level audit logging that records which agent acted, for which user, and under what declared purpose Lineage across pipelines, so a result can be traced back to the request that produced it Unify and harden Centralized, portable policy management Encryption at rest and in transit Consistent enforcement across on-prem, cloud, and sovereign or air-gapped environments “Declared purpose is what makes the difference. It becomes an attribute the access layer already understands, evaluated in the same policy path as role and row-level security. The enforcement mechanism does not change. What changes is that the agent's purpose is part of what it evaluates, and part of what the record proves afterward,” says Priyanka Jain, VP, product management, data & AI governance, EDB. Wherever you are in your AI adoption journey, enforcement at the data layer is what lets you move faster rather than slower. The controls are already in the database. The difference is that agents now have to pass through them. A digital leash, not a locked door The goal is not to stop agents from doing useful work. It is to define how far an agent can go, what it can touch, what it can change, what requires escalation, and how the organization can reconstruct events if something goes wrong. Governed this way, agents are identified, scoped, monitored, and auditable. The enterprise can adopt them faster, because security, risk, and leadership teams trust the operating model underneath. Open, sovereign, and enforceable at the source Built on open source Postgres, this open foundation keeps enterprises in control of where their data lives, who can reach it, and under what policy, without ceding governance to a layer they don’t own or can’t inspect. For regulated industries, that combination of data sovereignty and source-level enforcement isn’t a nice-to-have; it’s the precondition for putting agents into production at all. Agentic systems will keep getting more capable and more autonomous. That is a reason to be deliberate about where control lives, not a reason to slow down. The enterprises that enforce governance at the data layer can move aggressively on AI, because the thing protecting their data is more than just wishful thinking. EDB Postgres AI is an open, enterprise-grade sovereign data and AI platform that unifies transactional, analytical, and AI workloads — with governance enforced where the data lives. For the full framework, see EDB’s white paper Governing Agentic AI at Enterprise Speed. Max Romanenko is Chief Technology Officer at EDB. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/27/2026

A week ago, a mystery model called Ox Alpha showed up on OpenRouter — one more entrant among more than 400 models, with roughly 10 new ones launching every week. What made it stand out wasn't just the free price tag; it was quietly good. Hobbyists and indie developers noticed fast, pushing several trillion tokens through it daily, with community estimates for the week ranging from single digits to over 20 trillion. AI enthusiasts spent the next six days doing forensics and speculating who could have built it, and who could have the infrastructure to serve that many tokens for free. First the guess was a U.S. lab: the long-awaited Gemini, or Anthropic shipping a good-enough middle tier, or Elon sitting on so much capacity he dropped Ox Alpha (note the naming). People ran tokenizer traces and networking analysis. A real Sherlock Holmes mystery week. On August 26, Z.ai put its name on it. Ox Alpha was GLM-5.3-Flash. They'd been running it on public traffic on purpose, but the real surprise was not how good the model was (it's really good). It was served entirely on Chinese chips and infrastructure. List price is 15 cents / 50 cents per million tokens. OpenRouter's launch promo is 50% off that, 7.5 cents / 25 cents, through September 9. The weights are open (MIT), and inference is hosted by Z.ai as well as GMI Cloud, Cloudflare, and other US-based inference providers. Artificial Analysis put the model on their intelligence-versus-cost chart the same day. GLM-5.3-Flash lands at 57 on the index for about nine cents a task. A US mid-tier like GPT-5.6 Sol (max) sits around 59 at 67 cents, meaning for two points of intelligence you are paying about 7.4x more. Take it further and Grok 4.6 is at 61 at 94 cents a task, or about 10x for a four-point gain. At this point the token economics heavily influences the consumption calculus. At the top end the curve has flattened. If we take this open-weight bait, what happens to the heavy infrastructure circular investments we made that never accounted for a strong Chinese inference contender? American enterprises are already feeling the cost pressure. Take Uber. CTO Praveen Neppalli Naga told The Information in April he was going "back to the drawing board because the budget I thought I would need is blown away already": the company's full-year 2026 coding budget gone in four months, with Naga personally burning $1,200 in a single two-hour demo. By June, Uber had put a $1,500-per-person-per-tool cap in place. The tools were useful — but usefulness and value aren't the same thing. Uber's COO, Andrew Macdonald, still couldn't draw a line from those dashboards to "25% more useful consumer features." McKinsey's 2026 State of AI survey says 80% of people say they're faster, 37% of companies see some EBIT, and 32% skipped at least one software purchase because they could build that feature in-house with coding agents. Organizations want to cut the bill. They cannot afford to abandon AI. The task now is to optimize usage across the org. We cannot avoid Chinese model makers like Zhipu, Qwen, DeepSeek, and the rest. Time and again they have brought their own ingenuity to challenge SOTA labs and cut costs. On OpenRouter, Chinese models passed US token share in early June, and the top of that board is still mostly Chinese labs. The indie developer world already looks like GLM Flash, DeepSeek Flash, MiniMax, Kimi, and sometimes Grok or Claude if they already paid for a heavy subscription. If you are already subscribed to Grok or OpenAI through your company, that is now a sunk cost. Finance will start asking whether those seats still make sense if pay-as-you-go gets this cheap. So what choices remain? Consider your coding and agentic work in three buckets, split by share of tasks and tokens run through each tier — not dollars, since GLM-5.3-Flash's much lower per-token price means an even dollar split would already send most of your volume there. At the very top you have Fable and Opus. If you need to analyze a complex strategy or write a detailed execution plan, the extra points of intelligence matter and you should spend top dollar, but only for those rare tasks you cannot skimp on — probably 5% of the task volume. The mid tier is Kimi K3, Gemini 3.7 Flash, GPT-5.6 Sol, and Grok 4.6, all sitting around 60 on the intelligence index. Kimi is a heavy hitter for coding and a fan favorite; then Grok 4.6 is a close second, though its smaller context window holds it back. Put about 50% of the volume here. For the last 45%, strongly consider GLM-5.3-Flash as the volume workhorse. Your harness, your mix (coding vs content vs marketing), and your evals will draw your own frontier. Chinese open-weight models will save you money — and they need to be in your cost calculus. September is shaping up to be a deluge of new models — Google, xAI, Anthropic, OpenAI, and DeepSeek all have releases expected. The Pareto frontier might move again. But the direction is set: more intelligence for less money. Labs that can't get their serving costs down will lose the volume — and with it, the audience that volume creates. Before September, some homework: Count your tokens. Can you attribute spend to a top-line metric like customer or revenue growth? If not, at least development velocity or productivity? Without clear goals, it is going to be hard to defend the spend. Build your AI budget again. Org by org, what is planned AI spend? Can those leaders come up with a proposal and defend it? Define your model strategy by team. Write the three tiers. High for irreversible decisions and strategies. Mid for the paid seat and everyday coding. Low (GLM-5.3-Flash) for volume. Next month the models get cheaper again. Your teams get hungrier. The companies that come out of this will place their bets intentionally, and they won't let those agents think on Opus or Fable unless the task is really worth it. Parvez Syed Mohamed is a product executive who has built API integration and agent platforms at Salesforce (MuleSoft), Oracle and at AgentPaaS.ai. He works on production agentic systems. Some of his thoughts on building software with Agents is here: https://github.com/parvezsyed Welcome to the VentureBeat community! Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise. Read more from our guest post program — and check out our guidelines if you’re interested in contributing an article of your own!

8/26/2026

Salesforce and Anthropic announced Tuesday a sweeping expansion of their partnership, called Claudeforce, that pushes the world's largest customer relationship management platform directly inside Claude — a tacit acknowledgment that the future of enterprise software may not involve enterprise software's own screens at all. The centerpiece of the announcement is Salesforce in Claude, a plugin for Anthropic's Claude CoWork that ships with 37 pre-built sales skills — covering meeting preparation, deal health reviews, and pipeline analysis — and lets sellers query, update, and act on live CRM data without ever opening Salesforce itself. The product is available to select pilot customers today, with an open beta planned for September and additional skills for other business functions beginning to launch in the third quarter. Marc Benioff, Salesforce's chair and CEO, and Dario Amodei, Anthropic's CEO, were scheduled to appear on television together Tuesday afternoon, hours before Salesforce reports quarterly earnings — a piece of stagecraft that underscores how central this partnership has become to both companies' narratives. "We're bringing together the world's #1 AI and #1 CRM — the best of both worlds," Benioff said in a statement. "Here, the UI is the AI — allowing you to build custom apps dynamically and answer any enterprise question. Probabilistic intelligence alone doesn't run a company, and deterministic systems don't reason." But the more revealing framing came in an exclusive interview with VentureBeat, where Patrick Stokes, Salesforce's president of applications and marketing, described the launch in terms that would have been unthinkable for a major SaaS vendor even two years ago. "We think that what this can do is kind of be a version of what Claude Code did for developers," Stokes said. "We think we're about to do the same thing for knowledge workers. This is just a whole new way to work." How Salesforce turned its headless CRM experiment into a one-click Claude plugin The road to Claudeforce began in March, when Salesforce released Headless 360 at its TDX developer conference — a collection of APIs, MCP servers, and command-line tools that let AI agents call Salesforce data, workflows, and governance rules directly, with no user interface required. "I think we really kind of surprised the world a little bit with our Headless approach," Stokes told VentureBeat, "basically kind of openly suggesting that these agentic interfaces are a really good way to use Salesforce's products, and we don't actually mind if you don't use Salesforce's products exclusively through a user interface designed for a human." What happened next, according to Stokes, was both validating and messy. Customers rushed to wire Salesforce's MCP servers into agentic interfaces — "but really, Claude rose to the top," he said. The problem was friction. "Every individual user has to know what an MCP server is. Obviously, your average knowledge worker out there is not dealing in MCP servers every day. And you know, even if you can find it, how do you wire it up? And then, how do you make sure that it's respecting the permissions of the users?" The answer came from an unexpected source: Anthropic's own workforce. "We sat down with Anthropic and we talked about the problem, and they said, 'Hey, this is actually how we're using Salesforce. We use Salesforce pretty much exclusively through Claude and a series of skills and MCP servers that we have,'" Stokes recounted. The two companies decided to productize that internal setup as a CoWork plugin — one that an administrator connects a single time, with authentication and permissions managed centrally, so "all of the difficulty of wiring up every individual user with an MCP server is just magically solved." Under the hood, the architecture is deliberately simple. When a seller asks Claude to update a deal, Claude first reasons over its available skills — "kind of human-like instructions," as Stokes described them — to determine whether specific guidance exists for the task. If it finds a match, it reads the instructions and executes against Salesforce's MCP server, which inherits the user's existing permissions. "If you don't own that record, if you don't have permission to see that record, the MCP server doesn't either, and so you won't be able to read or write it," he said. For enterprise buyers, that may be the announcement's most important technical claim: nothing new to stand up, nothing to re-audit, nothing to configure account by account. Why Salesforce says letting sellers live in Claude makes its platform more valuable, not less The strategic tension at the heart of Claudeforce is obvious: if sellers start living in Claude instead of Salesforce, doesn't Salesforce become less important over time? Stokes rejected the premise emphatically. "That's not what we're seeing at all," he said. "The value of Salesforce is not in our UI itself. It's not the application. The value of Salesforce is in the data and the metadata, the years worth of kind of encoded workflows and business practices that have been built up inside of Salesforce. What we're doing is we're taking that and we're exposing it to a new UI." He offered a concrete example of the productivity math Salesforce is betting on. A seller's morning ritual — deciding which opportunities to work — traditionally means opening an opportunities list, clicking into each record, reading activities and meeting histories, and synthesizing everything mentally. "That process of evaluating all of those records and synthesizing it and coming up with a plan is like 10,000 clicks inside of Salesforce," Stokes said. "Now you just go to Claude and it's going to execute all of that for you, and it's going to do it in like 30 seconds." The paradoxical result, he argued: "I'm actually using Salesforce more than I ever would have before, because the work of clicking around to get what I need is gone." There is self-interest in that framing. Salesforce charges for this new usage through its headless consumption pricing — "depending on your edition of your user license within Salesforce, you effectively get more incremental access to more and more API calls," Stokes explained. Customers separately contract with Anthropic for the Claude inference itself. "You can't buy this on one piece of paper at the moment," he acknowledged. That two-invoice structure hints at the deeper industry shift underway: the slow migration of enterprise software economics from seats to consumption. If agents rather than humans become the primary consumers of SaaS functionality, per-user licensing loses coherence — and Salesforce appears to be positioning API consumption as the successor metric before someone else forces the issue. What Claudeforce means for Agentforce and the deepening Salesforce-Anthropic alliance The announcement also raises questions about Agentforce, the agent platform Salesforce has spent roughly two years promoting as its AI centerpiece. Stokes drew a careful taxonomy to distinguish the two. "These are not apples that you can look at as equivalent things," he said. "Agentforce is really designed for autonomous work or work that touches the end customer. So think about help.salesforce.com — that is an agent implementation specifically designed to interface with the end customer." Salesforce in Claude, by contrast, "is a knowledge worker agent... specifically designed for sellers, for salespeople, to help them do their day-to-day job without having to do the traditional part of their job, which is click around in user interfaces and try to synthesize data themselves." The distinction is tidy, but it papers over a real strategic evolution. In October 2025, Reuters and CNBC reported that Salesforce was hedging its model bets, bringing both OpenAI and Anthropic into Agentforce and even putting Agentforce inside ChatGPT. Since then, the relationship with Anthropic has clearly deepened into something closer to a preferred alliance: Bloomberg reported in June that Salesforce's investment in Anthropic was valued at roughly $5 billion, and Tuesday's release makes Claude the default model across Slack — powering Slackbot, the Claude Tag feature Anthropic previewed in June, and the new Slack Code product. Salesforce says 83% of its workforce now uses Claude-powered Slackbot, saving what it claims is 3.8 million productivity hours annually. For Anthropic, which The Wall Street Journal has reported is bulking up its enterprise partner program amid IPO preparations, the deal delivers something invaluable: distribution into the daily workflow of millions of sellers at companies that already trust Salesforce with their most sensitive commercial data. It also delivers tokens. "Once you start using this, you get very excited and you start to see how it can improve your day," Stokes said. "And yes, that is going to drive token consumption, which is obviously part of the reason why Anthropic is excited about this as well." Inside the demo: AI-generated dashboards and the rise of the vibe-coded CRM The most striking moment of VentureBeat's briefing came during a live demo from Shannon Mathews, Salesforce's VP of product management, who showed a seller asking Claude to "schedule a daily briefing to tell me where should I focus my business." The system returned a prioritized action plan — flagging, for instance, that six closing opportunities had no next steps ("I'm sure my leadership is not going to be thrilled about that," Mathews joked) and surfacing a COO change at a key account pulled from the web. "It really provides a concise call to action of where I should be focusing my time for today and this week," she said, describing the vision as giving every rep "almost an AI chief revenue officer." Then came the part that gestures at something genuinely new. Mathews generated a full sales dashboard — a "command center" — that Claude coded on the fly as a local HTML file, styled, at Stokes's request, "like Miami Vice, like Tron, just because I thought it was cool." "This isn't like a product that we're shipping," Stokes said. "This is Claude coding this on the fly using Salesforce data... If you think about all these different tools that we have to use — Salesforce, Workday, or whatever — we always have to use the UI that somebody else decides you're going to use. Now we're just taking Salesforce data and workflows, and CoWork is giving you the ability to make the UI look like whatever you want." Asked directly whether users can effectively vibe code their own dashboards, complete with actions and tool calls, Stokes leaned in. "This idea that people are going to vibe code their own CRM is probably not going to happen anytime soon. But what we are seeing is that people do want to vibe code their own CRM, and that's what we've enabled. We've just said: do it with Salesforce... You're vibe coding against trusted, governed Salesforce data." At a recent internal leadership summit in Hawaii, he said, "every single one" of the sales executives presenting business reviews "showed up with a command center-like view of their business that they built themselves right inside of CoWork." The bigger bet: why Salesforce is embracing its own disintermediation Strip away the branding and Claudeforce amounts to a wager that Salesforce is better off embracing its own potential disintermediation than resisting it. The history of platform shifts suggests that incumbents who fight new interfaces — rather than racing to own their position within them — tend to lose. Salesforce is betting that its moat was never its Lightning pages; it was 27 years of accumulated data, metadata, workflow logic, and governance that no model can conjure and no startup can quickly replicate. As the companies' own launch materials put it, a frontier model without that context is "a genius who's never seen your deals." The bet carries real risks. If the interface layer commoditizes, pricing power could migrate toward whoever owns the intelligence — and Anthropic, not Salesforce, owns Claude. The consumption-pricing transition could cannibalize seat revenue faster than API calls replace it. And the broader market remains skittish about exactly this scenario: Reuters reported in February that U.S. software stocks staged a relief rally on an Anthropic announcement, a reminder of how much SaaS valuations now hinge on whether AI labs are perceived as partners or predators.  There is also the unglamorous question of whether enterprises will capture the promised value at all. Gartner forecast worldwide end-user spending on generative AI models at $14.2 billion for 2025, yet McKinsey's ongoing State of AI research has repeatedly found that while adoption is nearly universal, most organizations still struggle to translate pilots into measurable bottom-line impact. Claudeforce's answer — pre-built skills, inherited permissions, one-time setup — is essentially an argument that the ROI gap has been a deployment-friction problem all along. Stokes framed the moment in almost epochal terms. "Salesforce believes that the interface to SaaS is undergoing a pretty significant period of change, and in some cases aggregation," he said. "We've already seen that AI has changed the way people build software with coding agents, but now we're seeing that it's fundamentally changing the way that people use software — and that can feel very scary on the surface. But our experience is that they're using software way more than they were, because this is unlocking trapped value that is trapped behind a human's own ability to click around and synthesize information themselves." Whether that proves prophetic or self-serving will play out over the coming quarters, as the beta opens in September and the skills expand beyond sales into service, marketing, and commerce. But the symbolism of Tuesday's announcement is already unmistakable. Salesforce spent 27 years building the defining user interface of enterprise software — and then spent Tuesday morning telling the world its customers no longer need it. The company that taught business how to click is now betting everything on the idea that nobody wants to.

8/26/2026

A security agent read a Cloudflare log, found an attacker’s prompt-injection payload sitting inside it, and rewrote the company’s DNS. The firewall had already blocked that payload, and blocking it is what wrote it into the log. That chain is GhostJacking, which Tenet Security demonstrated on the DEF CON 34 main stage on August 9. A request hits Cloudflare’s managed ruleset, gets blocked, and is stored byte for byte with its poisoned User-Agent header. An AI coding agent reviewing those blocked events reads the attacker's text as an instruction — with no way to tell it apart from one the company meant to give it — and acts on it with credentials the company issued months earlier. In Tenet’s benchmark, Claude Code on Sonnet 4.6 followed the planted instruction in nine of 10 attempts under Cloudflare’s recommended configuration. The block rate is not the boundary Nothing malfunctioned. The firewall worked, and every call after it carried a valid credential already issued to the agent. Endpoint detection, the web application firewall and identity management stayed quiet because no rule broke. Tenet found public evidence of the exposed setup at 48 organizations, six confirmed Fortune 500 companies, and SecurityWeek reported the same chain against Datadog and Sentry, where the injection surface is an alert or an error report. No single platform patch removes the architectural risk: an agent that consumes attacker-reachable data and can independently execute high-impact changes. That is why a high prompt-injection block rate cannot serve as a security boundary. OWASP’s co-lead names the fix “The first thing I’d do is put an authorization gate outside the model,” said Steve Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, in written responses to VentureBeat. “The agent can propose the exact DNS change, but it cannot grant itself the authority to make it.” The move relocates the decision into code that either passes or fails. A safe change, defined cleanly, clears a deterministic policy check and stays autonomous. Anything ambiguous or high in blast radius routes to a named human who approves the actual change. “The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation,” Wilson wrote. On teams that try to solve this inside the prompt, Wilson is blunt. “We have to remember that security rules written inside prompts may shape the model’s behavior, but they are still suggestions to the model, not enforceable security controls,” he wrote. The blocked payload became the instruction GhostJacking needs no compromised admin account and no bypassed firewall. It needs an agent that reads operational data and holds write access to the systems that data describes. Every step in Tenet’s chain is something the agent was already allowed to do, so tools tuned to catch unauthorized actions have nothing to catch. The mechanism is specific. SC Media reported that the agent Tenet drove live at Cloudflare was Cursor, reading through a GraphQL integration and writing through the Cloudflare API, and that pairing closes the chain. Tenet ran the chain against more than one coding agent. Cursor carried the demonstration, and the nine of 10 figure came from separate testing of the same attack against Claude Code. The Cursor agent ingests the poisoned header, patches the DNS A record and adds a CNAME to “resolve” the injected finding, giving the attacker a path to reroute the company’s web and email traffic. One agent’s output became the next agent’s input Events reach Sentry through a public write-only endpoint with no authentication, by design. Tenet used a leaked identifier to post a crafted error report. On an ordinary triage prompt, the coding agent escalated it to Sentry’s own AI, Seer, then trusted the analysis it got back. Seer had already absorbed the attacker’s proposed fix and returned it as its own finding. What reached the coding agent was a recommendation from another AI, and it implemented that recommendation. That walked straight through a control Sentry had already written. Sentry's guidance instructs agents reading its event data never to follow directives found there, and the coding agent held to the letter of that rule. It acted on Seer's conclusion instead, and that conclusion belonged to the attacker. It was acting on Seer’s conclusion, and that conclusion belonged to the attacker. An authorization boundary that accepts another model’s output inherits every injection that model absorbed, which is why Wilson’s gate belongs between agents too. OWASP moved excessive agency from sixth to third The 2026 OWASP Top 10 for LLM Applications, published August 4, elevated Excessive Agency three places on a ranking blending a 75% practitioner vote with 25% incident data from 6,639 documented cases. It was the largest upward move on the list, driven by real-world incidents clustering in agentic deployments. The fix isn't better prompting — it's the permission map: which actions are pre-approved, and which need a human. Reading logs, correlating alerts and drafting timelines stay autonomous. A bounded remediation like restarting a named service inside a fixed condition set clears a policy check outside the model. Anything that changes DNS, alters identity privileges, deploys code or reroutes production traffic needs a named human, and letting an agent open new access paths or approve its own proposals defeats the point of the gate. Useful autonomy survives that. What does not survive is the path from an attacker’s text to unreviewed production authority. What the control costs in practice Tenet co-founder and CEO Barak Sternberg told Dark Reading that a request the firewall already blocked was the way in, and that the firewall never went down, it just stopped mattering. His own fix is to split what an agent can read from what it can execute, and he concedes the cost, because an agent that reads alerts but cannot act on them is not the agent anyone deployed. The cheaper first step is an inventory. Every agent that reads outside data and can also write or execute belongs on a risk register, and that register needs no new tooling. Wilson’s design survives that cost because the split it draws is proposal from approval rather than read from write. The agent still reads its alerts, still investigates and still runs bounded work. What it loses is the ability to invent a high-impact change and carry it out on its own authority. Almost nobody has built it. Kayne McGladrey, a senior member of the IEEE, has argued for years that an AI deployment needs a hard governance threshold, a named human holding a kill switch and a way to roll back. Asked whether any Fortune 500 company runs that, he was blunt. “I haven’t seen it done, and no, they haven’t come out and publicly said it,” McGladrey told VentureBeat. His reason is economic. Companies “are accepting the risk, and they’re accepting it either deliberately or unconsciously,” he observed, betting the advantage beats the penalty. “What I think would change behavior in the space is if the penalties and the consequences were to outweigh the advantages.” The gate belongs outside the model for a reason unrelated to malice. “If you get into the inference layer, it won’t tell you it’s cheating, and it will lie about having cheated,” he argued, pointing to findings from the U.K.’s AI Safety Institute among others. A system that cannot reliably report its own shortcuts should not authorize its own. The industry is not positioned to make that split quickly. Ivanti’s 2026 State of Cybersecurity Report found 77% of security professionals at least somewhat comfortable letting AI act without human review, the exact posture Wilson’s gate constrains. CrowdStrike pushed its prompt-injection taxonomy past 200 techniques in July, naming indirect injection through data an agent reads as the critical vector for agents that call tools and run commands. The architect who moved the boundary before the attack had a name Egiziago Cioffi hit a related failure in production months before GhostJacking had a name, with one caveat. Cioffi is CEO of SynSphere Italia, a Microsoft reseller, the architect who built and sold the system rather than a security leader defending one he inherited. His Azure OpenAI assistant over SharePoint scored well on faithfulness and still returned content the asking user could not have opened. “An evaluation set with no identity dimension cannot fail an authorisation bug, however high the faithfulness score,” Cioffi told VentureBeat in written answers. He fixed it with a query-time filter built from the asking user’s group claims, so an unentitled chunk never becomes a candidate and never reaches the model. GhostJacking turns on what the model may do, the half Wilson’s gate is built for. One gap stays open here. No sitting CISO has gone on the record with a change made since August 9 and what it cost in agent capability. Until one does, the cost side rests on the people who specified the control, not anyone defending a production environment with it. What security leaders need to do this week Four questions produce an honest picture faster than any procurement cycle. Which agents read attacker-reachable material, which of those can also change production systems, whose permissions run at retrieval, and which changes a policy engine can approve without a human. Then run the negative test. Plant an adversarial instruction in a log the agent is expected to inspect, and keep the transcript, because that transcript is the difference between claiming a control and showing a test of it. Tenet, which sells runtime protection for AI agents, leads its own defender guidance with denying an agent outbound network access by default, cutting the leg where the poisoned instruction fetches a payload and reroutes traffic. But an agent that investigates without a standing path to the open internet loses a capability few workflows will miss. Enumerate the service principals in the tenant, drop the Microsoft first-party apps that ship pre-provisioned, then filter to those holding a credential or app-role assignment. Every identity on that list needs an owner and an expiry date, because one with both gets reviewed and one with neither never does. For any agent with production authority, write the containment sequence before an incident, not during one. Revoke or rotate its workload credential, disable its write-capable API or tool integration, preserve the execution transcript, then validate and roll back whatever infrastructure it changed. McGladrey’s read on why the work keeps getting deferred is uncomfortable. “I think that there’s a level of tolerance that’s being given right now in AI that is unlike anything else in society,” he said. GhostJacking makes that visible. A blocked payload reaches the agent through the system built to record blocked payloads, and once it arrives the question is no longer whether the model recognizes an attack. It is whether the model holds the authority to turn one into a production change.

8/26/2026

Presented by Tata Communications Enterprises are deploying AI agents, voice AI, and automation across messaging, voice, and digital channels faster than the architecture meant to support it. Most of that deployment has involved attaching conversational AI to legacy systems never built for it, says Gaurav Anand, global head of the Customer Interaction Suite at Tata Communications. "In the rush to deploy AI, organizations have largely bolted conversational AI onto legacy systems," Anand says. "As a result, while many enterprises have adopted digital tools, very few have platforms that are truly integrated, scaled, and capable of seamless orchestration." That gap creates a heavy cognitive load for human agents who must piece together context across disjointed tools to understand what an AI system has already told a customer. The challenge is not simply access to data, but the absence of a shared enterprise context that connects customer identities, interactions, transactions, policies, journeys, and operational systems into a common understanding. Traditional CX architecture was built for linear, human-driven routing, not for managing real-time data flows between autonomous AI systems, data lakes, and human workers. "Today's operational complexity is no longer about adding more intelligence," he adds. "It is about coordinating the existing intelligence across the enterprise, so the enterprise customer never feels the friction of those internal silos. That requires a shared context layer that allows AI systems, applications, and people to operate from the same understanding of the customer and the business." Why orchestration is replacing automation as the top CX priority As that coordination problem grows, Anand says the strategic priority inside enterprises is shifting from automation to orchestration. "Automation solves individual tasks, whereas orchestration connects them into end-to-end outcomes," Anand says. "The next evolution is context-aware orchestration, where AI agents, applications, and human workers operate using a shared understanding of customers, processes, and business intent rather than isolated system records." As organizations accumulate more bots, agents, and AI tools, managing them grows exponentially more complex. Anand says the competitive advantage now sits less in deploying automation and more in how intelligently systems hand off work, collaborate, and escalate. The trap of bolting AI onto legacy systems Companies that simply place a voice AI agent in front of an existing system are repeating the same old mistake. Instead of improving the experience, they end up recreating the deterministic phone menus AI was supposed to replace. The real benefit of AI is the scale, speed, and orchestration it provides. Anand points to a wave of consolidation across the industry, as established contact center providers acquire AI-native firms to close capability gaps and strengthen their customer experience offerings. The broader industry shift reflects a growing recognition that enterprises need more than channels and automation; they need an intelligence layer capable of orchestrating AI, people, data, and workflows across the business. The goal across industries is to make AI the connective layer between customers, employees, and enterprise systems. To achieve that, organizations increasingly need a common enterprise ontology: a shared business vocabulary that aligns customer data, products, policies, SOPs, transactions, and workflows across otherwise disconnected platforms. Tata Communications’ solution is the Interaction Fabric, an orchestration layer that unifies contact center, messaging, collaboration, AI, and customer data while coordinating AI agents, channels, and enterprise systems in real time. Underpinning that orchestration is a context-driven architecture that continuously connects identities, conversations, transactions, and operational data so interactions retain continuity across channels and touchpoints. That means AI and agents can move across voice, WhatsApp, chat, email, and CRM workflows without losing customer context. Identity, intent, and AI-driven insight flow continuously across channels instead of remaining trapped in disconnected applications. The next phase of orchestration is not simply coordinating tasks across systems, but coordinating them through a shared understanding of the enterprise. Context graphs, built on enterprise ontologies, create that common understanding by connecting customers, interactions, products, policies, decisions, and outcomes across organizational silos. This allows AI agents and human workers to operate from the same source of context, driving more accurate decisions, seamless handoffs, and consistent customer experiences. But synchronizing customer intent, conversation history, enterprise data, and AI decision-making across channels only works without lag. Legacy networks not designed for modern data frequency create what Anand calls data gravity, producing latency and inconsistent journeys as users switch channels. "The underlying network needs to be engineered to be as agile as the AI systems running on top of it," he explains. "Interactions stay synchronous and technology itself becomes invisible, leaving only an experience that feels effortless." Making AI a better partner for human agents Effective shared visibility between human agents and AI systems starts with the agent experience rather than any single technology. The most effective implementations allow both the AI and human agent to operate from the same contextual understanding of the customer, ensuring that information gathered in one interaction can inform the next regardless of channel or system. Automated call summaries, real-time sentiment analysis, and AI-powered assistance provide agents with instant, actionable insights and suggested next steps directly within their workflow. That allows AI to handle routine, high-volume tasks such as password resets, delivery tracking, and account updates, while human agents focus on interactions requiring judgment and empathy. "If a customer is facing a sudden crisis like a fraudulent transaction, the AI can instantly block the card, but it cannot provide the emotional comfort and delicate communication needed in that moment of panic," Anand says. "The answer to the dilemma is intelligent orchestration, rather than a choice between systems." In practice, AI handles the immediate technical transaction, while real-time sentiment analysis recognizes the customer's distress and routes the call to a human expert. The objective is to orchestrate AI and human agents together so efficiency never comes at the cost of brand trust and loyalty. Building a unified CX architecture Moving from fragmented experimentation to coordinated orchestration requires both technical and organizational change, Anand says, beginning with consolidating data and fragmented point solutions onto a unified, cloud-first platform. "IT and CX teams need to work more collaboratively," he explains, describing that alignment as the second necessary shift, this time at the organizational level. At the architecture level, Anand says communication APIs need to be embedded into the enterprise's core so every function operates from the same customer context instead of maintaining its own siloed data. Increasingly, this means moving beyond integration alone toward a contextual architecture where a shared ontology and context graph provide a common understanding across CX, operations, sales, service, and AI systems. The deeper organizational change, he says, is a mindset shift from reactive support toward proactive, predictive, and personalized engagement, which he calls the three Ps. How AI agents will shape the future of CX Customer engagement over the next several years will be defined by real-time intelligence, increasing autonomy, and seamless orchestration across touchpoints, and persistent enterprise context that follows customers, employees, and AI agents wherever interactions occur. Rather than analyzing interactions after the fact, enterprises will increasingly shape conversations in real time. "The future of CX will be defined by simplification, aligning data, infrastructure, and operating models around clear customer outcomes rather than adding more models and tools," Anand says. "The rise of AI-powered agents and agent-to-agent interactions is a defining trend, with AI systems moving beyond assisting humans to independently managing and resolving interactions, creating a largely invisible layer of engagement that improves speed and efficiency." Human agents will increasingly work alongside AI, supported by real-time conversational intelligence and next-best-action recommendations to deliver what Anand calls Total Experience: a unified model that brings together customer, employee, and AI-driven experiences. Tata Communications is building toward that future through its Voice AI, AI Workers, and Total Experience Hub solutions. "Ultimately, customer engagement will evolve from being reactive to predictive and increasingly generative," Anand says. "Enterprises won't just be responding to needs, but actively shaping and improving customer journeys in real time." Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/25/2026

A CISO who sees a low CVE count and deprioritizes prompt injection is reading the scoreboard wrong. Prompt injection has held the No. 1 spot on the OWASP Top 10 for LLM Applications for three consecutive years. When two leaders of that list checked it against 6,639 labeled real-world incidents, it came back at No. 12. The drop measures visibility rather than danger, because the attack operates where a vulnerability scanner cannot see it. That finding belongs to Kyriakos “Rock” Lambros and Steve Wilson, two leaders of the OWASP Top 10 for LLM Applications project, who published it on arXiv on August 18 with the disclaimer attached. The analysis is exploratory, not peer reviewed, and not the official OWASP release, and the authors state it does not supersede the official list or its process. The machinery behind it is real: 7,714 LLM security incidents from CVE, GitHub Security Advisories, OSV, and the AIAAIC AI-harm database, 6,639 of them labeled against a 20-entry taxonomy, and a Bayesian model that corrects each count for classifier error before setting the data-driven ranking beside the expert vote. The comparison found no statistically detectable agreement between expert judgment and the public incident record. Cohen’s kappa comes in at 0.20 with a 90% interval running from negative 0.16 to 0.57. “The interval crosses zero, so we cannot rule out that the two rankings agree only by chance,” they write. “The honest bottom line: weak agreement, not confirmation.” Lambros, co-lead of the OWASP GenAI Security Project Top 10 for LLM Applications and director of AI standards and governance at Zenity, put the finding in evidentiary terms in written answers to VentureBeat. “We had two ways of measuring the same risk, expert judgment and the public incident record, and they disagree with each other. Neither one is the truth,” Lambros said. “Two witnesses are contradicting each other, and we can’t tell you which one is lying.” The attack chain a scanner never logs The gap is structural. Prompt injection hides instructions inside the content a model reads, anything from a log entry to a support ticket to a document pulled back by retrieval. The agent then makes the tool call the attacker wanted, using credentials it legitimately holds. Nothing in that chain is a product defect, so the attack leaves no CVE behind for a scanner to find. The defenses that catch it are adversarial tests against the deployed system and hard caps on what the agent can reach, so a fooled model cannot touch anything expensive. The same logic argues for funding agent memory and MCP tool boundaries now, on architecture, rather than waiting for advisory volume that will always arrive a cycle late. The first control Wilson would deploy Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, named the control he would deploy first against exactly that chain, an agent that reads an attacker’s payload in a log file, treats it as an instruction, and rewrites DNS with a valid credential, in written responses to VentureBeat. “The first thing I’d do is put an authorization gate outside the model: the agent can propose the exact DNS change, but it cannot grant itself the authority to make it,” Wilson said. “Security rules written inside prompts may shape the model’s behavior, but they are still suggestions to the model, not enforceable security controls.” The gate has a price, and Wilson states it plainly. “The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation,” he said. Why the No. 1 risk looks small in the record “Prompt injection is the best-understood LLM attack, and deployed systems defend against it actively,” the authors write, and they compress the whole divergence into one sentence. “Experts rank it first because the attack surface stays enormous even when the defenses mostly hold; the data sees the successes that got through.” Wilson has watched the gap from both sides of it. “Incident data is incredibly valuable, but it is inherently backward-looking and notoriously tricky to interpret,” he said. “It tells us what was observed, recognized, classified, and reported. It does not necessarily tell us what is most dangerous in the systems people are building right now.” He compares prompt injection to “death and taxes” and, increasingly, to “a law of physics for LLM systems,” because one model is being asked to interpret trusted instructions and untrusted content at the same time. Better defenses have not closed the case. “A control that works 99% of the time is not sufficient when the failure case gives an attacker meaningful access. And, frankly, I don’t think we are at 99%,” Wilson said. “The durable answer is not believing we can perfectly screen prompt injection out of existence. It is designing systems with the assumption that prompt injection will occur, understanding why it works, and limiting what an attacker can accomplish when it does.” A low advisory count can mean the defenses are working. It can just as easily mean nobody has looked, and the public record cannot tell a security team which one it is. The attempt volume is documented. CrowdStrike’s 2026 Global Threat Report found adversaries injected malicious prompts into legitimate GenAI tools at more than 90 organizations in 2025, stealing credentials and cryptocurrency, under a section titled “Prompts are the New Malware.” The telemetry shows pressure on the attack surface without proving defenses produced the No. 12 placement, but it is the pattern the mechanism predicts. The gap runs the other way too, and further Prompt injection is the headline case, and misinformation is the bigger one. The expert vote puts misinformation at No. 13, while the incident record places it at No. 2. The paper calls it “the widest disagreement between the two witnesses” and reports that its concordance flag “puts the probability that the two signals disagree at 99 percent.” The authors do not treat their own data as the winner. On misinformation they note the corpus “carries a large volume of deepfake and AI-generated disinformation,” records that often “describe harm produced by an AI rather than a vulnerability inside an LLM.” The authors call it the entry the record most disputes, stopping short of concluding the experts got it wrong. Where “too new to measure” runs into the CVE record The two brand-new taxonomy entries sit at the sharpest end. Persistent memory poisoning lands at expert No. 4 and incident No. 16, MCP tool interface exploitation at expert No. 7 and incident No. 16, each with an incident interval of 6 to 20 that spans most of the taxonomy. Public 2026 CVEs exist for both. On MCP tool interfaces, the Azure Data Explorer MCP Server carried KQL injection, and the CVE record describes it allowing “an attacker (or a prompt-injected AI agent) to execute arbitrary KQL queries against the Azure Data Explorer cluster,” scored 8.3 High. Kong’s Konnect MCP Server shipped an indirect prompt injection that lets a remote attacker steer the server into executing unintended API requests, the exact failure the MCP entry names. Agent memory has its own record. An agent harness, Ruflo, exposed unauthenticated MCP bridge endpoints that let a network attacker obtain a shell, read provider API keys, and poison the learning store, rated 10.0 Critical. The record is so thin and uncertain that the model cannot place either entry within 14 rank positions. A team waiting for advisory volume to justify a control on agent memory or an MCP tool boundary would still be waiting while the CVEs accumulate at Critical and High. Lambros makes the budget case in operational terms. Poisoned memory “doesn’t announce itself,” he said. It looks like a procurement agent told once that invoices from a given supplier under $50,000 clear without a second signature, and because the agent remembers, every approval after that looks like the process working. “Nobody files an advisory for that, because nobody knows it happened. A count of zero is measuring your blindness, not your safety.” The argument he says a CFO will sign off on is timing, since memory and tool permissions get wired into these systems once, early, and everything else sits on top of them. “Build it in now and it’s a rounding error. Come back in two years and you’re re-architecting and re-training your systems.” The authors flag their own measurement problems first The expert side is thin. “The expert signal is a practitioner survey: about 29 respondents scored each candidate risk on importance,” the authors write. Twenty-nine votes set the ranking that carries three-quarters of the published list’s weight, the compression point for OWASP’s more than 25,000 community members. On the data side, the classifier is the weak joint. Precision “varies sharply across entries, from 93% (LLM01, LLM03) down to 13% (LLM08),” four entries fall below 50%, and the base classifier “never predicts ‘out of scope’ and files every incident into some category, including the roughly 38% of the gold set that belongs in none.” The authors name the central limitation themselves. One reviewer adjudicated all 1,200 gold-set incidents and overrode the model consensus on 553 of them. “A single annotator cannot measure inter-rater reliability,” they write. “The single-author gold set remains the central limitation.” Lambros lays the weak kappa at the feet of the taxonomy itself. “That number is telling you about our categories, not about our experts,” he said. When the people who wrote a taxonomy cannot reliably sort incidents into it, he argues, “a weak score on the ordering of those buckets is a fact about the buckets.” A better classifier will not fix the disagreement. A pre-registered bake-off of four frontier models produced no winner. None beat the incidence floor’s balanced accuracy of 0.863, and a ground-truth check left the floor’s ordering in place at a Spearman correlation of 0.918. The authors published the engine and artifacts on GitHub for anyone to rerun. The robustness result tested only one side of the gap. Every check behind the abstract’s word “robust” runs on the incident side, showing the incident-derived ranking stays put when the labeling machinery changes, and none of it touches the 29-vote survey. A board that hears “robust” will assume validated, yet the record supports only stable. What the published list did with this OWASP shipped the GenAI LLM Top 10 2026 on August 4, the first edition to fold incident data into the ranking, weighting the practitioner vote at 75% and the incident corpus at 25%. Prompt injection stayed at No. 1, misinformation moved up two places, excessive agency climbed from No. 6 to No. 3 as the entry where the two signals agree most clearly, unbounded consumption rose four spots to No. 6, and improper output handling fell from No. 5 to No. 10, the largest drop. Wilson declines to defend the blend as arithmetic. “There is nothing magical about a 75/25 weighting,” he said, “or about reversing it to 25/75. The value of the data wasn’t that it gave us a mathematical answer; it changed the conversation.” The excessive agency entry is where that conversation landed hardest for him. “If I were a CISO evaluating a new agentic deployment today, Excessive Agency is where I would start,” Wilson said. Lambros would go further next cycle, a view he flags as his own and separate from the working group. The blend hands the same 25% incident weight to every category, while the hand-checked classifier precision runs from roughly nine in 10 on prompt injection and supply chain down to roughly one in eight on vector and embedding weaknesses. A quarter of the weight on the first rides on something solid, he argues, and the same quarter on the second rides on noise. “The ratio should track how well we actually measure each category,” Lambros said. Why this lands now Ivanti’s 2026 State of Cybersecurity research found 87% of security teams call adopting agentic AI a priority and 77% report at least some comfort letting AI act without human review. Teams are signing off on agent autonomy while the expert ranking of what can go wrong with those agents shows no statistically detectable agreement with the incident record. What to do with this on Monday The behavioral change is narrow and it is the whole point. Use the OWASP LLM Top 10 as a coverage map, not a queue. The rank positions carry 29 votes and a corpus whose own authors call the agreement weak, so build your own priority order from your own exposure: production reach, breach-notification data, and controls that have actually been tested. Lambros draws the funding line the same way. “I’d prioritize spend where the expert vote and the incident record point the same direction, because that’s two independent witnesses agreeing,” he said. “Where they split, stop letting the ranking allocate your money and go look at what your own systems are doing.” Log what your AI systems are actually doing, field by field. The prompt that went in, what came back out, the documents pulled to build the answer, the tools called and the arguments passed to them, and the model’s confidence score on every response. Confidence is the field Lambros would fight for, because most security leaders do not realize it is measurable, and it is where the attack surfaces. “A model running on a poisoned instruction doesn’t act broken. It acts certain,” he said. “Certainty is what your monitoring treats as a healthy system.” The cost is a sprint or two of engineering. The constraint is a person, because a SIEM does events and these are trends. “Somebody has to analyze those trends every week and say whether a drift means anything, and most security teams have nobody who can.” Stop expecting scanner output to reproduce the Top 10’s order. Scanner findings live on the incident side of the gap, counting what got disclosed rather than what a deployed system should fear, and the classifier bake-off shows a smarter model does not close that distance. The test that sees prompt injection is an adversarial one run against the live system, paired with Wilson’s authorization gate so the change an injected agent proposes is never the change it can execute. Fund the thin-record categories on architecture, not incident volume. Agent memory and MCP tool boundaries sit at expert No. 4 and No. 7 with incident intervals spanning most of the taxonomy, and the CVEs that do exist are landing at High and Critical. Kayne McGladrey, an IEEE senior member who advises enterprises on risk, put the funding logic bluntly in an interview with VentureBeat. “Anything that seems to have a cybersecurity flavor is generally put into the cybersecurity risk category, which is a complete fiction,” McGladrey said. “They should be focused on business risks, because if it doesn’t affect the business, like a financial loss, then nobody’s going to pay attention to it, and they will not budget it appropriately.” A rank number from a 29-person vote is a weaker budget argument than the business system the agent touches. Steal McGladrey’s baseline test for the AI systems themselves. “If you wouldn’t expose your database to the public internet without identity and access controls, why would you do that for your AI model?” he said in CSO Online’s analysis of 2026 breach costs. The board question for the next meeting is short. If our AI risk ranking came from a 29-person vote and a corpus that disagrees with it, what are we actually using to decide which controls get funded next year?

8/25/2026

Perplexity is launching Portable Computer today, a version of its agentic "Computer" platform that runs entirely on hardware users already own — starting with Nvidia's DGX Spark desktop supercomputer and Linux machines equipped with Nvidia RTX GPUs. The launch, developed in close partnership with Nvidia, is one of the most aggressive attempts yet to move serious AI agent workloads off the cloud and onto local devices. The model, the user's files, and the work itself can all stay on the machine. Work completed locally consumes no billing credits, and the company says every task starts on the device by default — with the system asking permission before sending any individual step to a more powerful frontier model in the cloud. "We've basically brought the exact same UI to a fully local app," said Nate, Perplexity's vice president of engineering for infrastructure and enterprise, during a press briefing Monday. "This incorporates the entirety of the agent harness and inference and everything needed to do work locally." For Nvidia, which has spent the past two years selling the world on trillion-dollar AI data centers, the announcement signals something subtler but strategically important: the chipmaker believes local AI has crossed a threshold from hobbyist curiosity to practical tool — and it wants to sell the hardware that runs it. "Local AI reached an inflection point," said Nader, Nvidia's director of developer technology, who focuses on developer tooling and open source. "For the longest time, it was hobbyists and enthusiasts, and they were running these quantized models that were quantized down to be super tiny... And while that's cool, it's not super practical. But all that changed with a lot of these new open source models that have come out that are super useful." How Portable Computer packages a full local AI stack into a single app Perplexity Computer, the company's agentic platform for knowledge work, orchestrates AI models, files, tools, and web access to complete multi-step tasks — reviewing folders of documents, analyzing data, producing reports, and pushing results into business systems. Portable Computer replicates that experience locally: the local models, agent harness, inference engine, tools, app connectors, and a security sandbox come packaged together in a single system. That bundling is the point. With most local AI stacks today, users must assemble and operate those pieces separately — downloading model weights, standing up an inference server, wiring together tools, and tuning performance. "Historically it's just been really painful to bring up the local AI stack," Nate said. "With Portable Computer, we really focused on just making this a really straightforward experience where you can get up and running very quickly." In one demo Monday, the system played the role of a retail investor reviewing a folder of 1099s and investment documents — the kind of sensitive financial material many users would hesitate to upload to a cloud service. Running a 27-billion-parameter Qwen model at full GPU utilization on a DGX Spark, the agent reviewed each document and flagged cases where the hypothetical investor was paying unnecessary fees. The interface element that normally displays a running tally of cloud credits "is just parked at zero," Nate noted, "because all of this is happening on the device." A second demo showed the hybrid side of the product. Playing a startup founder, Nate asked the agent to analyze a CSV of user funnel data locally, then push the finished analysis to a Slack channel using Perplexity's connector ecosystem — proof that local-first does not mean disconnected. The system also connects to Google Drive, Gmail, and GitHub, and can escalate to a frontier cloud model when the local model hits its limits. At launch, users can set up Qwen 3.8 27B or PPLX 27B, a version Perplexity has post-trained on its own harness, with Nvidia's Nemotron 3.5 Lightning coming soon. Portable Computer arrives today for Pro, Max, Enterprise Pro, and Enterprise Max subscribers on Linux, with Windows support following in September. Any RTX GPU with at least 24GB of VRAM — roughly a GeForce RTX 3090 or newer — clears the bar, a threshold Nate called "sort of the floor where we really want to make sure that we can deliver a great experience, but balance that with making it broadly available." Why co-designing the model and agent harness beats general-purpose frameworks Alongside the launch, Perplexity published a research paper arguing that effective local agents require the model and the agent harness — the scaffolding of prompts, tools, and orchestration logic around the model — to be designed together. The core insight: general-purpose harnesses assume a frontier model that can absorb enormous contexts, navigate sprawling tool surfaces, and plan over long horizons. Small local models buckle under those demands. Perplexity found empirically that although models like Qwen 3.8 27B advertise 260,000-token context windows, they begin to struggle beyond 100,000 tokens. So the company built a deliberately minimal harness: a succinct system prompt, a small set of core tools, and capabilities that load and unload as on-demand "skills" rather than sitting permanently in context. It converted popular connectors like Gmail and GitHub from token-hungry MCP servers into compact command-line tools, added self-verification hooks that monitor the health of a task, and enforced always-on OS-level sandboxing. If the sandbox is unavailable, the harness disables itself rather than running tools unprotected — a contrast with open-source harnesses that run commands with the user's full permissions by default. The benchmark results Perplexity reports are striking, though they come from the company's own evaluations. On its internal Local Knowledge Work Bench — 53 tasks spanning deep research, financial analysis, and document creation, which Perplexity says it plans to open-source — Computer running Qwen 3.8 27B on a DGX Spark scored 82.6%, versus 77.6% for the open-source Pi harness and 74.0% for Hermes running the identical model.  Perplexity's post-trained PPLX 27B pushed the score to 85.4%. The gaps widen dramatically on harder tasks: on BrowseComp, a web research benchmark, Computer hit 66.7% accuracy versus 50.2% for Pi and 43.9% for Hermes, while using 51% less wall time and 70% fewer tokens than Pi. On multimodal document understanding, Computer scored 65.1% against Hermes' 34.6% and Pi's 13.9%. The token economics driving AI agents from the cloud to local hardware The strategic logic behind the launch becomes clear when you consider how AI workloads have changed. Chat was bursty — a question, an answer, done. Agents are different. "With agents, you want these agents always on if you can. You want the agents to really consume as many tokens as they can," Nader said. "What we're seeing is an insatiable demand for tokens, and that's something that makes local AI so great. As you saw through all these demos, you were not metered by the token. You were not paying for the token. So it's really killer for agents." This reframes the value proposition of local hardware. An agent that runs for hours reviewing documents, verifying its own work, and iterating on analyses would rack up substantial API bills in the cloud. On a device the user already owns, the marginal cost of those tokens approaches zero. Perplexity's paper makes the enterprise version of this argument explicitly: as agents scale across individual workflows and entire organizations, token expenditure and data movement "become increasingly difficult to govern." Local-first execution addresses both at once — spend, because inference is free, and privacy, because sensitive tokens never leave the device boundary. Perhaps the most commercially interesting result concerns the hybrid middle ground. On Terminal Bench 2.1, a challenging coding benchmark, the fully local Qwen model scored 59.6% at essentially zero marginal cost. Letting it escalate to a Claude Opus 5 "advisor" in the cloud raised the score to 73.0% at an estimated $0.415 per task. Running the frontier model alone scored 82.4% at $0.65 per task. Escalation, in other words, recovered roughly three-fifths of the gap to frontier performance at about two-thirds of the cost — and the user decides when that trade is worth making. Before any advisor call, the harness runs a PII classifier over the outgoing context and shows the user exactly what would leave the device. The remote model returns text guidance only; it never touches local files or tools. Where Portable Computer fits against Ollama and the DIY local AI stack Jason Hiner of The Deep View pressed the companies on how Portable Computer relates to existing local inference tools like Ollama. Nate's answer drew a clear line: the tools solve different layers of the problem. "The majority of the effort here has been at the agent harness level," he said, noting that the system uses vLLM to host model inference underneath, with an advanced mode for users who want to plug in their own inference endpoint. "We've heavily post-trained both the Qwen and Nemotron models that we're working with in order to really get the best possible results... Our focus has been on really honing the whole stack, top to bottom, of the model inference and the harness together." Nader put it more colorfully. "Just getting inference running really quickly on a Spark — there's a smooth path. You can use Ollama. You can get that set up. But then, as you start to do more complicated, more agentic things, then suddenly you need more perf. You start looking at different models. You start looking at different harnesses, and it's kind of like the ocean. The deeper you go, the deeper it gets." The appliance-like pitch appeared to land with at least one attendee. Ben, who described struggling to set up his own DGX Spark despite being an engineer — "this experience sucks, we have to fix it" — said the product feels like the unlock "needed for people to really feel and understand what agentic means, and you need the right UX to make it happen." Nvidia also emphasized that the hardware scales: connecting two Sparks over shared memory runs frontier-class open models like DeepSeek's latest, and four can run GLM 5.2 or Nemotron Ultra. "I've even seen eight Sparks get connected," Nader said. What the deepening Nvidia-Perplexity alliance means for both companies The launch extends a partnership that has been building for more than a year. In June 2025, Nvidia and Perplexity announced a collaboration to bring sovereign AI models to European publishers and telecoms, part of CEO Jensen Huang's continent-hopping campaign to convince governments that, as the Associated Press reported from VivaTech in Paris, "every country needs a national intelligence infrastructure." The sovereign AI pitch — that data "belongs to your people, your country, your culture," in Huang's words — is philosophically the same argument Portable Computer makes at the scale of a single desk: intelligence you control, running on hardware you own. There is a self-interested logic for both companies. Perplexity, which has raised capital at steadily escalating valuations while facing legal pressure from publishers over its content practices — including a lawsuit filed by The New York Times in December 2025 and an earlier public dispute with Forbes — gets a product whose economics don't depend on metering every token, and a differentiated wedge into privacy-sensitive enterprises in law, healthcare, and finance. Nvidia gets a killer app for DGX Spark, a device that, by the admission of attendees at Monday's briefing, has been easier to buy than to use. When one reporter asked whether a Spark might ship with Portable Computer and a Nemotron model preinstalled, Nader demurred without ruling it out: "That would be cool... the goal is just making sure that it's a super smooth experience for every user." Questions remain. Perplexity's most impressive numbers come from its own internal benchmark, and the company acknowledges that compact models still trail the frontier meaningfully on hard reasoning tasks — advisor escalation "narrows but does not fully close the gap." The launch is Linux-only for now, the 24GB VRAM floor excludes the vast majority of consumer PCs, and Apple silicon — home to some of the most enthusiastic local AI tinkerers — is conspicuously absent from the roadmap. "We're very focused right now on Nvidia hardware," Nate said when asked. But the direction of travel is unmistakable. Perplexity's researchers describe the launch as part of "a broader shift in which increasingly capable agents move from remote infrastructure to individual and local devices," and both companies are betting that advances in chips and open models will keep expanding what a box on a desk can do. During Monday's demos, the most telling detail wasn't a benchmark score — it was that credit counter in the corner of the screen, sitting motionless at zero while the agent churned through a folder of tax documents. For two years, the AI industry has measured its ambitions in gigawatts and tokens per dollar. Portable Computer proposes a different meter, one that never runs.

8/24/2026

Anthropic is making a calculated bet that the biggest bottleneck in enterprise AI isn't model intelligence — it's the fact that most people still use AI alone. In an exclusive interview with VentureBeat, Scott White, Anthropic's head of product for enterprise, laid out the company's thesis for what it calls "multiplayer AI": a shift away from the single-user chatbot paradigm toward AI agents that operate across teams, read organizational context, and proactively insert themselves into work — sometimes without being asked. The strategy crystallized earlier this month when Anthropic updated Claude Tag, its agent that lives inside Slack channels, to read context across entire conversations rather than evaluating messages one at a time. According to the company, the change makes Claude roughly 30% better at deciding when — and, critically, when not — to jump into a conversation unprompted. That may sound like an incremental product update. White argues it represents something more fundamental: the moment AI stops being a tool individuals consult and starts being a colleague organizations deploy. "Claude used to feel like your personal chief of staff," White told VentureBeat. "Now Claude, in the context of organizational deployment, feels like the company's chief of staff." How enterprise AI evolved from autocompleting code to pursuing company goals White frames the industry's evolution in three distinct phases, and his account doubles as a roadmap for where Anthropic is steering its enterprise products. In the beginning, he said, AI handled "a part of one task" — answering a question in a chatbot, or completing a single line of code in an IDE. As models improved, they graduated to completing entire tasks: writing a full function, producing a research report, drafting a document from multiple data sources. "I think we are now at the trajectory of what I would call projects or goals," White said. "The models are capable, and the connectivity into systems is capable enough, to accomplish higher-order abstract goals — like keep our product bug-free, or make our legal NDA review process happen faster — and the model can operate largely in the background, connecting various data sources and agentically looping over what it thinks its objective is." That shift, White argues, is precisely what forces AI to become multiplayer. Goals, unlike tasks, inherently involve multiple people. And knowledge work — unlike software engineering, which has decades of collaboration infrastructure built around Git and pull requests — has no equivalent scaffolding. "Knowledge work is much messier than software engineering," White said. "It's multi-person. It's multi-job function. It's multi-connected system that has different permissions... The goal or the output is also not as easily verifiable as code. Code can pass tests and compile on your machine, and you can iterate on it until it deterministically works. Knowledge work is not necessarily that. It requires human judgment to say something is up to the quality bar." The three technical breakthroughs that made proactive AI agents possible Asked what actually enabled the multiplayer shift, White pointed to three pillars that came together over the past two years. The first is connectivity. Anthropic's Model Context Protocol (MCP) — the open standard the company introduced in late 2024, which rivals OpenAI and Google subsequently adopted in 2025 — has matured into what White called "the USB-C for AI connectors," giving Claude governed access to enterprise data systems. The second is a threshold of model intelligence that makes proactivity viable rather than annoying. "When you're connected to all of these different systems, you have to be able to connect the dots between the data that you're getting from all of these different sources to be able to then proactively jump in and say, 'I think I am spotting a problem for you that I can fix,'" White said. "You really need to get to a new level of model intelligence, and I think we've only really gotten there recently." The third is form factor: putting Claude where collaboration already happens. White described the Slack integration as "a novel partnership that we struck up to have that presence of Claude as an agent" — one that gives Claude a federated agent identity with its own permissions, channel awareness, and MCP-connected context. The Claude Tag update shows how these pieces combine. Previously, a lightweight classifier evaluated each Slack message in isolation and made a binary call about whether Claude should respond. Anthropic has now removed that classifier entirely. Claude reads the channel's full context — plus its memory and standing instructions — and chooses among four moves: reply inline, start deeper work in a thread, route the message into an existing workstream, or say nothing. Anthropic's announcement offers a telling example: two engineers chasing the same bug from opposite ends, neither addressing Claude. Read individually, neither message warrants a response. Read together, one engineer has a theory and the other has the evidence — and Claude opens a thread with the investigation already running. Notably, the company built explicit restraint into the system. "An annoying agent is worse than an unhelpful one," Anthropic wrote in its announcement, noting that Claude goes dormant in channels where it repeatedly has nothing to add. Why Anthropic says collaborative AI beats solo star performers The obvious skeptic's question is whether any of this actually makes teams faster. High performers often move quickest when working alone, and coordinating AI use across people with different working styles is genuinely hard. When pressed for evidence, White pointed to how his own job has changed inside Anthropic. "In the old days, I might have a question about something happening in the business, and I would go work with a data scientist to take one or two days to do some data analysis around this problem statement," White said. "Now Claude is good enough at doing data analysis where I no longer have to have that handoff. What the data scientist has done now is they've created the infrastructure that allows Claude to always be right when it is doing data analysis." The result, he said, is that time once spent waiting on handoffs now goes to judgment: "More of my time is spent with my collaborators at my level, jamming with them about what we should actually do and what we should change about our strategy... The multiple handoffs that we saw to get a piece of work done to then try to make a decision — all of that has been shortened dramatically." White cited site reliability engineering as the pattern's clearest external proof point: Claude collects error logs, connects them to recent code changes and related Slack conversations, then surfaces the synthesis and pulls in the right people — "solving bigger, more ambitious, more goal-oriented problems where it's often necessary to collaborate." Those claims land in a market still struggling to convert AI enthusiasm into returns. McKinsey's most recent State of AI survey found that while 88% of organizations report using AI in at least one function and 62% are at least experimenting with AI agents, only 39% attribute any earnings impact to AI — and just 6% qualify as "high performers" seeing significant value. Deloitte, for its part, predicted that 25% of enterprises using generative AI would deploy agents in 2025, doubling to 50% by 2027. That gap between adoption and impact is exactly the terrain Anthropic is trying to claim: if redesigned workflows — not bolted-on chatbots — separate AI winners from the rest, a product that restructures how teams coordinate is a more defensible wedge than a marginally better model. How Anthropic defends always-on agents against prompt injection attacks Giving an AI agent standing access to a company's Slack channels, documents, and connected systems raises an obvious attack surface question, particularly around prompt injection — the technique of embedding malicious instructions in content an AI reads. White described a layered defense strategy. "The models themselves are trained with classifiers that help prevent things like prompt injection attacks," he said, adding that Anthropic has delayed launches over the issue before: "We didn't GA our Chrome extension, and we actually put it on a waitlist... because we need to better understand the risk of prompt injection in the context of Claude in the browser. And then we actually did novel classifier training to figure out how to improve that from that dataset." Beyond model-level defenses, Anthropic exposes compliance and analytics APIs that let enterprises define their own risk thresholds, and partners with third-party security vendors through its hooks and data loss prevention integrations. "We think about solving that at many layers of the stack," White said. On data access, White emphasized that Claude's permissions collapse to the most restrictive intersection of what the agent can see and what the requesting user can see. "You have to have the same permissions to view the data that the thing would provide access to you," he said. "If you are using Claude in the context of your collaboration, it will have the channel context that is in front of you, but it will not leak that channel context into a different channel." The unanswered pricing question every CIO should be asking now One detail buried in the Claude Tag announcement deserves attention from technology buyers: the expanded channel context Claude now holds does not count toward usage or spend limits on any plan — for now. When asked whether enterprises should budget for that context becoming billable, White declined to commit, describing the current phase as active experimentation and co-design with customers. "We're early in the journey here for what I would call proactive and collaborative agents," he said. "Long-term in AI is very — it's very long. Things change very quickly, and so that's why close partnership with our customers is so important, so they can help guide us to the right answer." Instead of pricing promises, Anthropic is emphasizing controls: budget caps tied to agent identities or role-based access groups, and model entitlements that let different teams run different cost-performance profiles. "If we can give you ultimate control over how you architect the deployment to optimize for the relationship between cost and performance for the tasks that you're trying to accomplish, then there will be many ways to get to the outcome state that you want," White said. The honest translation: the unit economics of always-on, context-heavy agents remain unsettled, and Anthropic is effectively subsidizing the learning phase. Enterprises should architect deployments assuming the meter eventually turns on. Why enterprises might choose Anthropic over Microsoft, Google, and Salesforce The competitive question looms large. Salesforce owns Slack, Microsoft is embedding agents throughout Teams and pushing its own multi-agent orchestration ambitions, and Google is doing the same across Workspace. Why would an enterprise hand its most sensitive internal conversations to a third party? White's answer is that value lives in the connections between systems, not within any one of them. Improving a product based on customer feedback, he noted, requires pulling call transcripts from Salesforce, internal debate from Slack, usage analytics from product tools, and code from development environments — no single vendor owns that full picture. "It is not just one individual thing that solves all of your problems," White said. "It is the intelligence and structure for how you pull it all together to get to the actual outcome that you're trying to get to, which is building something better for your customers. And we have seen our customers love Claude as the orchestrator." It's a credible position precisely because enterprise data is fragmented by design. An orchestration layer that stays neutral across those systems — built on a protocol that even Anthropic's fiercest competitors have standardized on — carries structural advantages that a walled-garden agent does not. The risk cuts the other way, too: platform owners can bundle their agents for free and control the integration points Anthropic depends on. Anthropic is wagering that frontier intelligence and cross-system neutrality beat distribution — a bet that has worked so far in coding, and remains unproven in general knowledge work. What comes next: handing Claude the company's quarterly objectives Asked where the trajectory leads, White sketched a future in which the delegation flows in both directions — and it is striking how matter-of-factly he describes it. "We're now giving Claude projects to accomplish," he said. "Soon, I think, we'll give Claude its OKRs, and it will figure out which projects the organization needs to work on and how to connect people to do them — improving itself, and the people around it, over time." He acknowledged the vision is "a little bit abstract," and it raises governance questions that today's controls only begin to address. An AI that decides which projects an organization pursues — and, in White's words, delegates to people "only when they need to help improve its judgment" — inverts the traditional relationship between workers and their tools in ways most enterprises have barely begun to reckon with. White pointed to Anthropic's public commitments on catastrophic risk domains like cyber and biosecurity as evidence the company is weighing the stakes, though the day-to-day questions of workplace agency remain largely in customers' hands, governed by the permission systems and budget controls Anthropic ships alongside the ambition. For now, the more immediate change is the one already playing out in Slack channels: an AI that listens to the whole room, decides for itself when to speak, and increasingly does the connective work that used to fall to managers, analysts, and project leads. White has watched that shift compress his own job into its most human remainder — judgment, debate, decisions — and he expects the same compression to arrive everywhere else. Two years ago, the industry's favorite metaphor for AI was the intern. Anthropic just promoted it to chief of staff — and it now reports to the whole company.

8/24/2026

IBM is announcing today at the annual Hot Chips conference what may be the most consequential change to mainframe architecture in decades: a processor whose cores can natively execute both IBM's own instruction set and Arm's — switching between the two in nanoseconds. The chip, which will power the next generation of IBM Z and LinuxONE systems, is the first dual-architecture mainframe processor ever built. It is designed to let enterprises run the vast and fast-growing ecosystem of Arm-native Linux software — including the AI frameworks that increasingly define modern infrastructure — directly alongside the z/OS transaction-processing workloads that anchor the world's banks, insurers, and governments. "As technology enthusiasts on both sides, we're really excited about being what I would consider one of the most powerful commercially available processors that'll be dual architecture," Tina Tarquinio, chief product officer for IBM Z and LinuxONE, told VentureBeat in an exclusive interview ahead of the announcement. The announcement marks the first hardware milestone from the strategic collaboration IBM and Arm unveiled in April, and it offers an unusually direct answer to a question that has shadowed the mainframe for years: can the machine that processes most of the world's regulated financial transactions remain a first-class citizen in an AI era built largely on other people's silicon? How IBM engineered a processor core that speaks two instruction sets The most striking engineering decision is what IBM chose not to do. The company could have bolted a handful of standalone Arm cores onto the side of its processor — a simpler design that other chipmakers have used for heterogeneous computing. Instead, IBM built every core on the chip to be bilingual. "On this chip are 11 cores, and each core can dynamically switch back and forth between Arm software mode and traditional Z software mode," Jacobi explained in an exclusive interview with VentureBeat. "That enables us to run the mission-critical enterprise software right next, on the same chip, to the much broader software ecosystem of Arm applications." The mechanism relies on the open-source KVM hypervisor. Enterprises can run Arm64 Linux virtual machines and Linux on Z virtual machines side by side, and as the hypervisor dispatches each virtual machine onto a physical core, the core flips into the corresponding mode. The performance penalty, Jacobi said, is effectively zero. "That switch takes about the nanosecond scale," he said. "Because you're running for many milliseconds in the virtual image, this switching overhead sort of amortizes to zero — pretty much no impact at all." Traditional z/OS workloads run in a separate partition on the same chip, outside KVM — meaning a bank's core ledger, its fraud models, and a modern Arm-native monitoring stack can all share the same silicon, the same memory fabric, and the same reliability guarantees. Jacobi was candid that IBM debated the easier path and rejected it. "We're really not addressing their need if we just have a few, I'd say, loosely Arm cores in the corner of the chip," he said. "It really needed to be deeply integrated into the entire system design for it to have the same qualities of service that clients are used to." The specifications underscore that this is no compromise design. Built on a leading-edge 2-nanometer process node, the chip runs its 11 high-performance cores at a base frequency above 5.7 GHz — extraordinarily fast by industry standards — with on-chip AI inference accelerators for in-transaction fraud detection, a dedicated data processing unit for I/O acceleration, and a large cache architecture. Full systems will scale to hundreds of cores and tens of terabytes of memory. "That's really, really fast compared to what you otherwise get in the industry," Jacobi said. "It's just another example of how mainframe technology is not old technology. It's very modern, leading-edge technology." Why the mainframe needed Arm's 22 million developers The strategic logic behind the chip is about software, not hardware. IBM's s390x architecture runs an enormous share of the world's mission-critical transactions, but the broader universe of enterprise software — monitoring tools, security agents, cloud-native middleware, and above all the AI stack of PyTorch, ONNX Runtime, and container workloads — was built for x86 and, increasingly, for Arm. By Arm's own estimates, close to half of the compute shipped to major hyperscalers in 2025 was Arm-based, driven by AWS Graviton, Google Axion, and Microsoft's Arm silicon. Arm counts more than 22 million developers worldwide. Porting each application to s390x has been a grinding, one-ISV-at-a-time effort, and Tina Tarquinio, chief product officer for IBM Z and LinuxONE, described the calculus bluntly. "No matter how great our ecosystem team is, we would never be able to work with all of them and port them all," she told VentureBeat. "There's a lot of ISVs out there, and so we wanted to make a fundamental, big step-function forward. We took a swing from a technology point of view." Notably, she said customers weren't asking for a dual-architecture chip per se — they were asking for outcomes. "I wouldn't say our clients were saying, 'Can you please make me a dual-architecture environment?' But they were saying, 'Help me get these surround workloads, or different types of workloads, to run in a quicker-to-market fashion.'" The compatibility promise is ambitious: Arm Linux binaries should run unmodified. "The new Arm capabilities are designed to be 100% binary compatible," Jacobi said. "Once you have, for example, Red Hat Linux for Arm, and you have applications that run on Red Hat Linux for Arm, they will run on the system without modifications." Arm defines the instruction set architecture and supplies validation tooling to guarantee that IBM's implementation behaves identically to every other Arm chip — while IBM designs and builds the silicon entirely in-house. "Very good partnership. Very solid engineering partnership as well," Jacobi said of the collaboration. What a next-generation Spyre accelerator means for enterprise AI on the mainframe IBM is also previewing the next generation of its Spyre AI accelerator at Hot Chips, and the pairing is not coincidental. The current architecture already offers two tiers of AI: an on-processor accelerator, introduced with the Telum chip in 2022, that handles ultra-low-latency inference such as fraud scoring inside a payment transaction, and the Spyre accelerator card sitting in the I/O subsystem for heavier models. The new Spyre raises the ceiling considerably. "We're also bringing a much higher performance chip that is capable of running large language models for agentic workflows," Jacobi said — both AI-ops workflows that administer the system itself and business workflows "for things like document understanding and insurance adjudication." The new accelerator will ship with high-bandwidth memory to feed those models. Here the dual-architecture bet and the AI bet converge. Enterprises want to run inference next to their data; the data lives on the mainframe; and the AI tooling is overwhelmingly Arm-native. Mohamed Awad, Arm's executive vice president for cloud AI, framed the announcement in exactly those terms: "As AI scales, more of the computing landscape is converging on Arm. Bringing Arm compute and its software ecosystem to these platforms will extend that momentum into mission-critical enterprise infrastructure to give organizations greater choice in how they deploy AI." The timing tracks with where enterprise AI actually stands. McKinsey's most recent State of AI survey found that while 88% of organizations now use AI in at least one business function, nearly two-thirds have not yet scaled it across the enterprise — and the companies capturing the most value are those redesigning core workflows rather than running detached pilots. For regulated industries whose systems of record sit on IBM Z, running AI where the transactions happen is arguably the most direct route to that kind of integration. When the dual-architecture IBM Z system will ship — and why existing customers shouldn't worry Buyers will need patience. The chip will debut in the successor to the z17, which shipped in the second quarter of 2025, and IBM holds to a roughly three-year product cadence — pointing to a launch around 2028. But Tarquinio insisted the program is well past the concept stage. "It's more than being on the drawing board. We're full steam ahead on the whole system," she said, adding that IBM will release more details in the run-up to launch. For IBM's installed base, the reflexive question is whether embracing Arm signals a slow sunset for the traditional architecture. Both executives pushed back hard. "This is a big and. It is not an or," Tarquinio said. "I have a roadmap that goes out 10 or 15 years of hardware systems. Many of our teams are working on this next system; many are also working on the one after that, and the one after that." Jacobi cast the move as continuity rather than rupture. "The traditional mainframe that we have today as a z17 system is not just a faster version of what we built 25 years ago," he said. "We didn't have pervasive encryption capabilities. We didn't have on-processor AI capabilities. Adding the Arm capability is the next big iteration in this continuous evolution." The competitive subtext is the cloud. Asked why an enterprise would run Arm workloads on a mainframe instead of a hyperscaler, Tarquinio pointed to the platform's availability numbers: "We're talking eight nines of availability — that's 0.3 seconds of downtime a year. If you're running your ledger, if you're running your fraud detection, any of these mission-critical apps, you want that." The pitch, she said, is fit for purpose: match the infrastructure to the SLA, not the fashion. There are real caveats. IBM's own press release notes that statements of future direction "represent goals and objectives only." The Arm support is Linux-only for now, and the hardest engineering — running a foreign instruction set at production performance, with mainframe-grade fault detection and recovery, under real customer workloads — remains to be proven over the next two years. But the ambition is unmistakable. For sixty years, the mainframe has survived every wave of technology that was supposed to kill it — minicomputers, client-server, the cloud — by absorbing what it needed from each. Now IBM is attempting its boldest act of absorption yet: teaching the machine that runs the world's money to speak the language of the AI era, fluently and natively, on the same silicon. "Bringing something that'll really be first of its kind in production," Tarquinio said, "showcases again what IBM is capable of from a technology point of view." The mainframe, it turns out, isn't being left behind by the future. It's learning to run it.

8/23/2026

Enterprise AI has largely been built around context engineering. Teams connect enterprise systems, generate chunks and embeddings, build retrieval pipelines, and assemble the context needed by individual AI applications. While this approach works well for isolated assistants and copilots, it treats enterprise knowledge as application-specific context rather than a shared enterprise asset. As organizations deploy more AI applications and agents, this model begins to break down. Different teams process the same documents, maintain separate embeddings and indexes, and create inconsistent representations of the same business knowledge. The challenge is no longer simply providing context to AI systems — it is managing enterprise knowledge itself. Why building context is not enough for enterprise AI The common approach to enterprise AI today is to build context for individual applications. Teams connect enterprise systems, process the required information, generate retrieval representations such as chunks and embeddings, and assemble the context an agent needs at runtime. While this works for a single application, it does not manage enterprise knowledge as a shared enterprise asset. As organizations deploy more AI applications, this approach begins to break down for three reasons. First, knowledge becomes inconsistent. Enterprise knowledge is distributed across many independent systems with different schemas, business definitions, and update cycles. The same product, customer, or business process may be described differently — or even contradict itself — across documents, Jira tickets, source code, CRM systems, and metadata. Extracting this information into context does not resolve these inconsistencies; it simply transfers them to the AI application, causing different agents to develop different understandings of the business. Second, changes become difficult to propagate. Enterprise knowledge evolves continuously, but each application maintains its own context pipeline. As documents, code, and business definitions change, downstream chunks, embeddings, indexes, and agent context are updated independently, causing AI applications to operate on different versions of the same knowledge. Finally, organizations repeatedly rebuild the same knowledge pipelines. Different teams process the same enterprise knowledge, generate similar embeddings, maintain separate indexes, and construct overlapping context for different applications, resulting in duplicated engineering effort, unnecessary infrastructure costs, and fragmented knowledge. These are not fundamentally context engineering problems —they are knowledge management problems. Enterprise data platforms solved the same challenge for structured data by managing enterprise data once and sharing it across applications. Enterprise AI now requires the same architectural discipline: a shared enterprise knowledge platform that manages knowledge once and publishes reusable representations for every AI application. A layered data and knowledge management system An enterprise knowledge platform is the equivalent of an enterprise data platform for enterprise knowledge. Instead of treating documents, source code, Jira tickets, emails, APIs, and other enterprise systems as isolated inputs for individual AI applications, it manages them as a shared enterprise asset. It ingests, organizes, integrates, governs, and publishes enterprise knowledge through a common architecture so that every AI application consumes the same trusted knowledge foundation rather than maintaining its own context. To achieve this, the platform separates knowledge management into four layers with distinct responsibilities. Knowledge is first preserved in its original form, then normalized into managed knowledge objects, connected into a common enterprise knowledge model, and finally published in representations optimized for different AI applications. This separation allows each stage to evolve independently while providing a consistent foundation for every downstream application. The platform organizes enterprise knowledge into four layers: Raw → Refined → Integrated → Serving Raw preserves the original enterprise sources. Refined transforms heterogeneous sources into managed knowledge objects. Integrated connects knowledge across systems into a unified enterprise knowledge model. Serving publishes reusable and agent-specific representations for AI applications. Raw layer – preserve the source The raw layer captures information from enterprise systems while preserving its original form and source identity. This may include database records and change events, PDFs and other documents, Confluence pages, Jira tickets, source code, API responses, emails, images, and event streams. The purpose of this layer is not to make information ready for an agent. It is to maintain a reliable source from which the platform can rebuild downstream knowledge. If extraction logic changes, a model improves, or a downstream representation becomes corrupted, the information can be processed again without depending on an application-specific copy. Refined layer – normalize enterprise knowledge The refined layer transforms heterogeneous enterprise sources into managed knowledge objects. Each source is normalized into a consistent representation while preserving its identity, metadata, permissions, versions, lineage, and references to the original content.  For example, a product requirement document is transformed into a structured knowledge object containing metadata such as document ID, product ID, title, source system, author, version, permissions, tags, creation time, and last modification time, together with its associated content. This representation provides a consistent way to manage enterprise knowledge regardless of whether the source is a document, Jira ticket, source code repository, email, or API. At this stage, the platform is not trying to connect different domains. Instead, it establishes a reusable and governed representation for every enterprise knowledge source. Once each source has been normalized into structured or semi-structured knowledge objects, the integrated layer can connect them through shared business entities and relationships. Integrated layer – build the enterprise knowledge model The integrated layer transforms independent knowledge objects into a unified enterprise knowledge model. It serves two purposes: Connecting knowledge across systems and business domains, and modeling the business relationships that AI needs for reasoning. Knowledge is connected using shared business identifiers (such as product or customer IDs), explicit cross-system references (such as Jira and Git links), or AI-based entity resolution when no direct relationship exists. For example, a product requirement document describing “Bulk Invoice Upload,” a Jira story titled “Implement Invoice Upload API,” and a release note announcing the same feature may all refer to the same business capability, even though no explicit relationship exists among them. Once connected, the platform models business relationships based on business logic such as implemented_by, contains, belongs_to, affects, and depends_on, capturing how the business actually operates rather than simply how records are linked. Unlike traditional primary and foreign key relationships, these relationships describe business workflows, dependencies, ownership, and business impact. They allow AI to trace knowledge across engineering, product, customer support, finance, and other domains using a shared understanding of the enterprise. Serving layer – publish knowledge for AI The serving layer is similar to the context layer used in many enterprise AI applications, but it is built on top of a managed enterprise knowledge foundation. It transforms the enterprise knowledge model into representations optimized for different AI workloads. These representations fall into two categories. The first is shared enterprise representations, which provide a common knowledge foundation for all AI applications. Examples include SQL views, search indexes, chunks, embeddings, graph models, and APIs that are created once and reused across the organization. The second is agent-specific representations. Instead of maintaining separate copies of enterprise knowledge, the platform dynamically assembles task-specific context from the integrated knowledge model based on the needs of each agent. A Product Agent, Revenue Agent, and Customer Support Agent may all consume the same enterprise knowledge foundation while receiving different context tailored to their responsibilities. The diagram clearly defines the high-level model of the serving layer:                           Enterprise Knowledge Model                                         │                 ┌─────────────────────┴─────────────────────┐                 │                                               │                 ▼                                               ▼     Shared Enterprise Representations         Agent-specific Representations   ┌───────────────────────────────┐         ┌──────────────────────────────┐   │ SQL Views                        │         │ Product Context                 │   │ Search Index                     │         │ Revenue Context                 │   │ Chunks                           │         │ Customer Context                │   │ Embeddings                       │         │ Planning Context                │   │ Graph                            │         │ Coding Context                  │   │ APIs                             │         │ ...                             │   └───────────────────────────────┘         └──────────────────────────────┘                 │                                                │                 └──────────────────────┬─────────────────────┘                                         │         ┌────────────────────────────┼────────────────────────────┐         ▼                               ▼                               ▼   Product Agent                   Revenue Agent                 Customer Agent Managed knowledge platform: The data foundation for AI Most current enterprise knowledge systems were built for people, not AI. Confluence pages and documents help employees record and share knowledge. Jira enables teams to plan work and collaborate. Metadata systems help analysts understand data assets. These systems organize information so that humans can search, interpret, and connect it using their own experience, knowledge, and judgment. Large language models have fundamentally changed how enterprise knowledge is consumed. Machines can now understand natural language, reason over documents, and interact with enterprise knowledge in ways that were previously only possible for people. This shift requires more than new AI applications — it requires a new data foundation that manages enterprise knowledge as infrastructure rather than treating it as a single embedding. This managed enterprise knowledge platform provides the data foundation for AI agents. It transforms human-oriented knowledge systems into AI-ready infrastructure by organizing enterprise knowledge into a consistent, reusable, and governed data platform.  This foundation enables system capabilities that are difficult or impossible to achieve when every AI application builds and manages its own context. Platform capability What it enables Knowledge lifecycle management Incremental loading, change propagation, version management, and historical reasoning without rebuilding every context pipeline. Governance and trust End-to-end lineage, traceability, permissions, ownership, quality controls, and explainable AI responses linked back to original enterprise sources. Reusable knowledge services Shared search indexes, embeddings, graph models, SQL views, APIs, and dynamic context assembly that can be reused across applications instead of rebuilt for every agent. Continuous evolution Independent evolution of storage, retrieval, embedding models, and AI applications, while allowing agent feedback to continuously improve enterprise knowledge. The platform also provides the foundation for human-in-the-loop and reinforcement learning workflows in agentic systems. Feedback generated by AI agents can be ingested back into the platform, validated, governed, and integrated into the enterprise knowledge model before being published to downstream AI applications. This creates a closed feedback loop that continuously improves enterprise knowledge and enables AI agents to evolve. The next competitive advantage is the enterprise data foundation Ever since ChatGPT 3 was released in late 2022, the industry has invested enormous effort in foundation models, RAG architectures, vector databases, embeddings, MCP, and multi-agent frameworks. These technologies have significantly improved how AI applications are built and deployed. Today, the AI application stack is rapidly maturing. The next bottleneck is no longer the model or the agent framework. It is the enterprise data foundation behind them. AI agents are only as capable as the data and knowledge they consume. Better models cannot compensate for fragmented documents, inconsistent business definitions, disconnected systems, or poorly managed enterprise knowledge. Like every data-driven system before it, enterprise AI ultimately follows the same principle: Garbage in, garbage out. The most important investment for enterprises is no longer building more AI agents, but building the enterprise knowledge platform that supports every agent. Organizations that treat enterprise knowledge as shared infrastructure rather than application-specific context will build more reliable AI, develop new applications faster, and scale AI across the enterprise without repeatedly rebuilding the same knowledge foundation. The next competitive advantage in enterprise AI will not come from building more agents. It will come from building the data and knowledge foundation that every agent depends on. Shuhua Xu is a Lead Data Engineer.

8/22/2026

For much of the past two years, the general belief in enterprise AI has been that more autonomy equals better performance. Build agents that can plan, decide, and act across multi-step workflows, and give them as much room to run as possible. That assumption is now being tested at scale, in real production environments — and in a lot of deployments it's failing. The companies that end up benefiting from agentic AI won't necessarily be the ones that have given their agents the most flexibility. They're the ones who create AI agents with specific responsibilities and make sure they operate within clear rules. Two numbers tell you almost everything about where agentic AI stands in mid-2026. By Gartner's own forecast, more than 40% of the agentic AI projects running today won't survive to see 2028. Not because the models fall short; because of escalating costs, unclear business value, and inadequate risk controls. McKinsey's 2026 AI Trust Maturity Survey fits right alongside that prediction: Agentic AI deployment is accelerating across every industry, but average responsible-AI maturity sits at just 2.3 out of 4. Only about 30% of organizations have reached a maturity level of three or higher in governance and agentic AI controls specifically.   Put those two numbers side by side, and the story tells itself. Capability is outrunning control.   That shift is changing the competitive framing, too. The 2024-to-2025 race was about who could deploy the most autonomous agent the fastest. The 2026-to-2027 race is a trust race.   It's not about who can build the most capable agent. It's about who can get an agent approved for production by risk, legal, and compliance teams, and keep it approved once it's live. This is a different kind of engineering challenge than most enterprises are prepared for. Why full autonomy breaks down in production   Gartner lays out the failure pattern as specific and repeatable. Projects launch with ambitious, broadly autonomous workflows. They hit integration complexity within weeks. Then they stall, with no defensible path to production ROI. Part of the problem is vendor noise. Gartner's own count puts it starkly: Out of the thousands of products being sold under the 'agentic AI' label, only around 130 actually have real autonomous capability behind them. The rest are largely automation or chatbots repackaged for the moment. But even genuinely agentic systems run into a structural problem that has nothing to do with hype. Autonomy and accountability move in opposite directions.   An agent capable of independently planning and executing a multi-step task is also an agent whose individual decisions get harder to trace after the fact. Let's say something breaks a few steps into an autonomous chain. Figuring out why the agent made that decision and who is responsible can be a complicated process, not a simple lookup. In areas like financial reconciliations, compliance processes, manufacturing quality checks, or clinical documentation, this lack of transparency can be the difference between a manageable mistake and a serious regulatory breach. It's the reason legal, risk, and compliance teams block agentic projects from reaching production, regardless of how capable the underlying model is.   Integration complexity keeps showing up as a leading cause of project cancellation. Bolting an autonomous agent onto a legacy workflow takes more than technical connective tissue. The workflow's existing decision points, approval chains, and audit trails all need to be rebuilt around a system that can now act without waiting for a human. Enterprises that treat this as a pure integration problem, solvable with more engineering hours, tend to be the ones that stall.   This isn't a hypothetical risk. McKinsey's research shows how exposed most enterprises currently are. Across nearly every category of AI risk, from data privacy to intellectual property exposure, the gap between the risks organizations say they're aware of and the risks they're actually mitigating remains wide.     Awareness has surpassed action. This gap is reflected in the businesses that report it as an obstacle to further scaling of agentic AI. Nearly two-thirds now say security and risk issues are the greatest challenge for them, surpassing regulatory uncertainty and technical barriers.     What governed orchestration actually looks like   The enterprises that are leading the way are not halting their AI plans. They're restructuring how autonomy is being distributed within the system. The four patterns that stand out in organizations that are governance-mature are:   Narrow-scope agents over general-purpose ones. Decompose end-to-end workflows into single-responsibility agents with tightly bounded mandates. A smaller scope of work results in a smaller scope of failure, and a smaller scope of failure is much easier to audit.   Human checkpoints at decision boundaries, before the outcome, not after it. Review agent decisions before high-stakes actions execute, not after the fact. That means checkpoints before sensitive data moves, a transaction posts, or an external system is triggered. McKinsey's framework calls for real-time, data-driven monitoring built into the agent pipeline itself, with humans retaining final accountability specifically for high-stakes decisions.   Decision traceability as a design requirement. A full action log and decision lineage should be available on demand for any agent, any decision. It shouldn't need to be reconstructed under pressure during an audit. Regulators are pushing the same way. The EU AI Act's human oversight requirements for high-risk systems are still coming, even though this year's Digital Omnibus agreement pushed the compliance deadline out to December 2027. Enterprises building agent systems now are effectively building toward that requirement, whether or not it's technically enforceable yet.   Data sovereignty does active governance work, not passive paperwork. Where an agent's data sits, and who has access to it, decides how contained a failure can be. On-premise or controlled-environment deployment limit the blast radius of a misbehaving agent and simplifies exactly the kind of audit trail regulators and boards are starting to expect.   The risk runs in both directions, of course. Agentic AI is supposed to cut friction. An agent that needs a human to sign off on every minor task hasn't cut anything; it's just automation wearing a manual process as a costume. That quietly undercuts the whole case for building the agent in the first place. The goal isn't maximum control. It's calibrated control, concentrated where the cost of an error is actually high.   Agent deployment is scaling roughly 8x faster than governance maturity is improving.   A practical framework for evaluating your agent stack   If enterprise architects are reviewing an existing agent for deployment or are considering deploying an agent, they can begin by asking four questions.   1. Can you reconstruct, six months from now, exactly why a specific agent took a specific action?   If the honest answer requires digging through raw logs or guessing, decision lineage isn't a design feature of the system. It's an afterthought. And it will show up as a gap in the next audit.   2. Does every agent in the stack have one clearly bounded responsibility, or is at least one agent authorized to "figure it out" across a broad task?   Broad, open-ended mandates are exactly where compounding errors and untraceable decisions originate.   3. Are human checkpoints placed at defined decision boundaries, or only as a final review after the agent has already acted?   A review after the fact catches consequences. A checkpoint before the fact prevents them.   4. If an agent were compromised or malfunctioning right now, how much data and how many downstream systems could it touch before anyone noticed?   This is where data sovereignty and access scoping stop being compliance line items and start functioning as containment strategy.   These are all questions that don't need to slow down the adoption of agentic AI. They need direction on how and where autonomy is of value to their organization and how to open up to exposure. This suggests building the orchestration layer on that separation, rather than adding governance after a production incident forces the question.   The real competitive advantage   Gartner's 40% cancellation forecast isn't really a warning about AI capability. It's a forecast about organizational discipline. Right now, agentic AI sits at what Gartner defines as the "peak of inflated expectations," and there's a fairly straightforward explanation. Enterprises spent 2024 and 2025 optimizing almost entirely for autonomy. Now they're paying down the governance debt that approach accumulated.   The winning position by 2027 won't belong to whoever deployed the most autonomous agents fastest. It will belong to whoever built agent systems trustworthy enough that risk, compliance, and legal teams stopped being the bottleneck. The architecture answered their questions before anyone had to ask them.   That's a different design brief than most agentic AI roadmaps were written against. It's about making scoped autonomy, checkpointed decisions, full traceability, and data sovereignty integral to the architecture from the start, not add-ons after a pilot project has been a success. Midhula Mariyam Jeevan is a content writer specializing in AI, enterprise technology, software engineering, and SEO.

8/21/2026

When an agentic AI system hands a task from a small model to a larger one — or back down again — it pays a steep tax: the receiving model has to recompute the entire conversation from scratch, driving up compute costs and latency. This is a major bottleneck for enterprises building long-horizon, multi-LLM workflows. To solve this challenge, researchers at Nvidia have introduced a cross-model KV cache transfer technique that directly maps the prefilled KV cache from a source model into the target model. This technique aligns with real-world agentic applications where large contexts accumulate across many turns.  For real-world AI applications, cross-model KV cache transfer can reduce compute costs and latency on long-running, multi-LLM workflows — and it does so with simple linear math, not an expensive deep learning model. Experiments show that, on compatible model pairs, this linear mapping process runs 2.7 to 25 times faster than recomputing the conversation while retaining up to 98% of the target model's standalone accuracy.  Why swapping models mid-session is so expensive Examining how LLMs handle memory helps understand why multi-model workflows hit a performance wall in production. When an LLM receives a prompt, it must first execute the “prefill” stage, which is the initial forward pass that computes the keys and values for all input tokens and populates the Key-Value (KV) cache.  After that, it enters the “decode” phase, where it computes and generates the next tokens in the sequence. During this phase, the model reads from this KV cache to predict new tokens one by one, bypassing the need to re-evaluate the entire history of the conversation for each new token. In multi-turn conversations or long-horizon agentic sessions, the context gradually becomes longer. Because the computational cost of the prefill stage scales directly with both model size and input length, processing these long sessions becomes increasingly expensive and introduces significant latency if the KV cache is invalidated. This invalidation happens whenever the AI system tries to swap models mid-session, such as routing a complex reasoning step to a larger model or dropping to a smaller model to save costs. Because different LLMs have different architectures, they expect their cache inputs in different formats.  As a result, any model switch forces the receiving model to repay the entire prefill cost from scratch to recompute the KV cache for the accumulated context.  Mapping memory between models without starting over The Nvidia researchers studied cross-model KV cache transfer to see how developers can transform the KV cache of one model into the expected format of another without running the prefill phase again.  If solved, cross-model KV cache transfer has benefits in both directions. Small-to-large model transfer upgrades the quality of the output. For example, a cheap, small model handles the routine parts of an agentic workflow but struggles with a complex reasoning problem, and you map the KV cache to a larger model and continue the process seamlessly. On the other hand, large-to-small model transfer reduces compute costs. A highly capable, large model might be used to unpack a massive, complex system prompt or synthesize a dense PDF at the start of a session. Once the heavy lifting is done, the session's KV cache is mapped down to a smaller, more economical model to handle the rapid-fire, conversational turns that follow. There have been previous efforts to solve the KV cache transfer problem, but they suffer from a few key limitations. These include the need for expensive gradient-based training or very strict architectural constraints. For this initial study, the authors restricted their focus to within-family transfers, such as transitioning between different-sized models in the Qwen, Llama, or Ministral families. These models share tokenizers, training data DNA, and core architectural styles but differ in size and depth. However, this framework leaves plenty of room for future experiments. The researchers note the technique could eventually be expanded to cross-family transfers, mismatched KV head counts, or hybrid architectures that blend standard attention with other memory mechanisms. The key finding of the Nvidia study is that cross-model KV cache is a significantly linear structure. This means you can do the mapping with simple algebra tricks and without the need for heavy neural network training. For example, when experimenting on KV cache transfer from a 14-billion parameter Qwen3 model to a 32-billion parameter version, the authors discovered that a simple linear regression mapping from one source layer to a target layer can recover 56% of the variance in the target’s keys and 32% of the variance in its values. When combining multiple source layers, those numbers climbed to 79% and 65% respectively. To translate this linear relationship into a practical system, the researchers designed a closed-form per-head ridge mapper with three key components: Per-head ridge regression: Instead of using complex deep learning to train the system, they fit a simple linear regression using a tiny calibration set of a few hundred text sequences. This technique solves a classic line-of-best-fit problem independently for every attention head. Cross-layer source selection: Because the source and target models have different numbers of layers, the mapper evaluates and selects the most predictive source layers to feed into each specific target layer. This way, the system picks only the most helpful pieces of memory from the old model to construct the new model's memory. Content-space mapping: Before translating the data, the mapper strips away the RoPE encodings. RoPE, or Rotary Position Embedding, is a standard mechanism that applies a mathematical, position-dependent rotation to the data so the model understands the order of the tokens in a sequence. Stripping the RoPE values makes it possible for the mapper to generalize to sequences of lengths larger than its training data. Putting the linear mapper to the test To test whether the technique works, the researchers evaluated the transfer pipeline across six “matched-KV” model families. Matched-KV means the source and target models share the same KV head count and per-head dimensions, which is typical for different-sized models within the same family. The model families included Qwen3, Llama 3.1, and Ministral 3, with tests for KV cache transfer across different sizes ranging from 3 billion to 70 billion parameters. Their experiments included a massive 8.8x parameter leap from Llama 3.1 8B to 70B. To cover a wide range of tasks, they evaluated the models on five core accuracy benchmarks (ARC-Challenge, HellaSwag, WinoGrande, MMLU, and GSM8K) as well as language modeling perplexity on WikiText-2 and a multi-turn conversation task called CoQA. To fit the linear translation mapper, they used a tiny calibration dataset of just 500 text sequences of 1,024 tokens each. The researchers compared the framework against the baseline ceiling accuracy where the target model does a full, traditional prefill. They also compared their full system against ablated configurations, such as reducing the number of selected layers or deactivating different components. Additionally, they compared their simple method against a deep neural network trained with backpropagation to see if heavier deep learning could recover accuracy on pairs where the linear method struggled. For four of the six tested pairs, the fast, closed-form linear ridge mapper retained 73% to 98% of the target's standalone prefill accuracy — including the massive leap from Llama 3.1 8B to 70B, which retained 72.8% of target accuracy. The mapper also runs between 2.7 and 25 times faster than re-prefilling. For example, when translating a 32,768-token KV cache from a Qwen3 14B to a 32B model, the transfer took just 278 milliseconds, compared to nearly 7 seconds for a standard re-prefill. The system also demonstrated high stability on tasks that run across many steps. When tested on multi-turn conversations, the drift, or accuracy loss, between the target baseline and the transferred cache remained incredibly small across 10 turns, proving it will not cascade into failure during long agentic sessions. However, the straightforward linear approach did run into limitations on specific model pairs. For two of the Ministral configurations, the linear mapper degraded sharply because the simple linear fit failed to extrapolate outside calibration data. To fix this, the researchers swapped the linear mapper for a nonlinear multi-layer perceptron (MLP) with two 1,024-unit hidden layers trained on the same data. This added a complexity and training tax to the setup, but it recovered their accuracy to above 90%. A bigger industry problem than one paper can solve The introduction of cross-model transfer is part of a broader, industry-wide push to solve the KV cache bottleneck, which has emerged as one of the key hurdles for scaling enterprise AI. As developers push LLMs to process massive documents or code bases and execute long-running reasoning tasks, managing this memory layer is becoming as important as the models themselves. Over the past year, researchers have attacked this compute and memory problem from multiple angles. For instance, Nvidia recently introduced dynamic memory sparsification (DMS), a technique that intelligently evicts less important tokens from the KV cache to cut reasoning costs by up to 8x.  Other approaches focus on aggressive data compression. MIT researchers developed an algebraic compaction technique called Attention Matching that compresses the KV cache by 50x without degrading quality. Similarly, Nvidia introduced KV Cache Transform Coding (KVTC), which borrows media compression concepts to shrink memory by 20x without altering the underlying model weights. Beyond compression, researchers are also attacking the computational overhead of memory retrieval. Optimizers like IndexCache strip away redundant layer calculations to deliver significantly faster time-to-first-token in long-context applications. And models like DeepSeek and the GLM series are optimizing the KV cache through architecture innovations. As AI systems take on longer-horizon tasks and more complex architectures, the underlying memory infrastructure is becoming as important as the models themselves. Cross-model KV cache transfer gives developers one more tool for keeping inference costs down as they scale multi-model agentic systems.

8/21/2026

Slack wants to drag AI coding out of the terminal and into the group chat. The Salesforce-owned messaging platform today announced Slack Code, a new product that embeds AI coding agents — including Anthropic's Claude Code, Cognition's Devin, GitHub Copilot, and Vercel's agent — directly into dedicated Slack channels where entire teams can watch, steer, review, and ship software together. Slack Code is available on any Slack plan at launch, though customers need their own access to the partner agents. The pitch is deceptively simple: today, most work with AI coding agents happens between one person and one agent, invisible to everyone else. Slack Code makes that work "multiplayer." When someone tags a coding agent from any conversation, the agent spins up a project-specific code channel, does the work in the open — complete with code diffs, live previews, and a running plan visible in dedicated tabs — and archives the channel when the job is done, leaving behind a searchable audit trail. "One of the things I love about this is that code is no longer the bottleneck," Rob Seaman, Slack's interim CEO, said in a press briefing ahead of the launch. "Ideas, taste, judgment, craft — those are the things that are the bottleneck, and you've effectively extended the population that can contribute ideas, taste, judgment, and craft to anybody that exists in your Slack." It is a consequential launch for Slack, and a revealing one for the broader enterprise AI market. The AI coding boom has so far been a story of individual productivity — a developer alone with Claude Code or OpenAI's Codex in a terminal window. Slack is betting that the next chapter belongs to whoever owns the collaborative layer around those agents. And it is making that bet at a moment when its parent company badly needs the story to land. How Slack Code channels put AI coding agents to work in the open In the interview, which also included executives from Cognition, Slack leaders described a workflow that looks less like pair programming and more like a newsroom. Jeff Wang, president of new enterprise at Cognition — maker of the Devin coding agent — walked through a live demonstration: someone reports a broken feature in an engineering channel, Devin acknowledges it with an emoji, replies in the thread, investigates, and opens a pull request. "It even knows the code owner, so you can see it tagged Theo into this as well," Wang said. "Every time Devin is doing something like this, it does have its own computer. So here, it's actually using Chrome and the DevTools to test if the feature is working correctly." From there, the work migrates into a dedicated code channel where anyone — an engineer, a product manager, a designer — can jump in. In Wang's demo, a designer dropped a Figma file into the channel mid-task, and the agent incorporated it without breaking stride. The agent finished by posting the code changes alongside screenshots and a recorded demo proving the feature worked. That verification loop is central to the pitch: cloud-based agents, unlike agents running on a developer's laptop, can generate an auditable record that the work is actually correct. "Scaling things, auditing things, giving it to everybody — that is much easier with these cloud agents form factor than it is with local agents," Wang said. The launch reaches beyond code channels, too. Slack is shipping a broader rework of how agents live in the product: agent DMs that behave like conversations with a colleague, a new Agents tab that gives every agent session a home base with live status and a stop button, and an "Add to Slack" flow that lets teams deploy agents from platforms including Lovable, n8n, OpenAI, LangChain, and Airtable in a few clicks, with OAuth and configuration automated. Why Slack says writing code is no longer the bottleneck in software development The strategic argument underneath Slack Code is that AI has inverted the economics of software development. Writing code used to be the scarce, expensive step. Now, Slack's executives argue, it is the cheap one — and the constraint has moved upstream, to human judgment. "One of the things I love about this is that code is no longer the bottleneck," Seaman said in the press briefing. "Ideas, taste, judgment, craft — those are the things that are the bottleneck, and you've effectively extended the population that can contribute ideas, taste, judgment, and craft to anybody that exists in your Slack." Cognition offered internal numbers to back up the velocity claim. "We've seen our internal merged PR count go up 10x in the last few months, versus our headcount has only gone up like 40 percent," Wang said, describing a workflow where engineers fire off a Devin task, move to something else, and launch another — "soon you have everybody working on like dozens of agents at a time." The pattern extends well beyond engineers, Wang said. "Believe it or not, a lot of our bugs are reported by our sales team. They report it in Slack, and then someone who's technical applies them to fix the bug." Seaman seized on that example as the whole thesis in miniature: "So much of that stuff never even made its way to a product manager into a backlog because the communication vehicles weren't there, the motivation wasn't there, the knowledge that it could actually be fixed so quick wasn't there — and we've effectively knocked all of that down." Wang went further, sketching where he believes this ends up. Toil work — "fixing bugs, fixing CI/CD, or fixing vulnerabilities, all these things engineers probably don't want to do — we think will be automated away," he said. What remains is the work that "requires creativity, planning, business logic." He added a prediction that will make some engineering leaders uneasy: while a human still gates every merge today, "I suspect maybe in the next year it's just going to go through automatically." Can working in public solve the AI slop problem? The obvious objection to democratizing software creation is quality. If anyone in a company can summon a coding agent, does an enterprise drown in what the industry has taken to calling "AI slop" — plausible-looking but poorly conceived output generated at scale by inexperienced users? Slack's executives argue, somewhat counterintuitively, that visibility is the antidote rather than the accelerant. "The multiplayer part is a guard against that, actually, because people can see your work, people can comment on your work," said Katie Steigman, Slack's VP of product. She contrasted it with the status quo: "If I'm doing God knows what in terminal with an agent, versus being able to do it in a place where people can see my intent and actually change and shape my work — or slap my hand and tell me that's slop, because that's real." Steigman, a product manager rather than an engineer, described her own practice as a template. "When I put PRs up as a product person, I almost always tag in an engineer from my team. I don't just send a PR and ask for an approval," she said. "Almost every time, an engineer will say something like, 'Come on, you can make that a little bit tighter,' or they'll actually give it some specific technical guidance, and the agent will take one more rev and produce code that has been touched by an engineer to a certain extent." Seaman framed the argument in grander terms: "I think the moral arc of multiplayer AI bends towards higher quality and less duplication." He pointed to Shopify, where he said CEO Tobi Lütke has written about restricting agentic coding to public channels precisely because it "immediately disseminates every single thing that's happening in the company" and levels the playing field. Still, the skeptics' case has data behind it.  Gartner predicted last year that more than 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs and unclear business value. And McKinsey's most recent State of AI survey found that while 62 percent of organizations are at least experimenting with AI agents, only about a third have begun scaling AI at all, and just 39 percent report any bottom-line impact. The gap between agent enthusiasm and agent value remains the defining feature of the market Slack is selling into. Inside Slack Code's security model: no god mode, no new identities For enterprise buyers, the most consequential design decision in Slack Code may be its permissions model. Asked directly whether agents in code channels could leak access across teams — a finance repo visible to legal, say — Seaman was emphatic that agents inherit the permissions of the human who invokes them, and nothing more. "Everything is done on behalf of the user, using the user's ACLs, both in Slack and in the systems that they're connecting to," he said. "There's no god permissions or bot-level permissions... Within Slack, the agent has access to information that the user has access to, and access to the channels that it's been added to." Steigman added that when an agent spins up a code channel, "the only thing that agent gets from the code channel is the context of the conversation" that triggered it. On the execution side, Wang said Devin runs in isolated sandboxes with "minimum viable access" — including an optional mode with no internet access at all. "You've heard all these stories about the agent escaping and causing havoc," he acknowledged, "but we have different security configurations." This "agents as extensions of existing users" model is a genuine differentiator against standalone agent platforms, which typically force IT departments to provision new service identities and manage a patchwork of one-off permissions. It also answers the shadow-IT question that has dogged agentic tools: because agents produce standard pull requests into GitHub, existing release gates and review processes still apply. "It reduces that barrier upfront to get that initial PR up," Steigman said. "Then the due diligence still happens in GitHub." What Slack Code means for Salesforce's high-stakes AI turnaround Slack Code arrives amid a turbulent stretch for its parent company. Salesforce shares fell roughly 18 percent over the year through January, badly lagging the Nasdaq, as Wall Street questioned whether AI would erode demand for traditional enterprise software. In December, OpenAI hired away Slack CEO Denise Dresser as its chief revenue officer, elevating Seaman — then Slack's product chief — to interim CEO. Salesforce has responded by racing to make Slack the AI front door for work. In January it shipped a rebuilt Slackbot powered by Anthropic's Claude, which the companies said became the fastest-adopted feature in the company's 27-year history. Slack Code extends that strategy from answering questions to producing artifacts: not just messages, but working code, prototypes, and documents generated inside Slack itself. There is also a notable strategic reversal embedded in today's news. In mid-2025, Reuters reported that Salesforce had moved to block rival AI firms from accessing Slack data — a defensive crouch. Today's announcement, by contrast, positions Slack as an open platform courting exactly those AI companies as partners, with plans to open the code channel APIs to any developer. Software engineering, the company says, is just the first use case; marketing campaigns and legal document reviews in dedicated agent channels are next. The calculus appears to have shifted from protecting Slack's data to making Slack indispensable as the venue where agents — anyone's agents — do their work. Partners are, unsurprisingly, saying the right things. "A whole team can gather in one code channel, watch the agent work, steer it together, and ship a preview," said Vercel CTO Malte Ubl. GitHub chief product officer Mario Rodriguez called Slack "a strategic part of a broader GitHub promise: humans set direction, agents close the loop." The future of AI coding: multiplayer channels and single-player terminals will coexist None of Slack's executives claim the terminal is dead. Asked whether tools like Claude Code and Codex become obsolete, Seaman predicted a division of labor. "The overwhelming majority of the work is actually going to happen in these multiplayer environments," he said. "But there's going to be deep, immersive, intensive, single-player thought work that's going to happen in terminals." An engineer rethinking a codebase's architecture goes heads-down with an agent; a sales rep flagging a broken button gets a fix in a channel everyone can see. The trust curve, Seaman suggested, will look familiar to anyone who watched teams adopt earlier waves of automation. "People are going to open these things at the beginning" — reading every diff, every thinking step — "and then build trust in the system and open it less and less over time." That is the wager, and it is bigger than a product launch. McKinsey's research shows the organizations capturing real value from AI are the ones that redesign workflows around it rather than bolting it onto old processes — and Slack Code is, at bottom, a workflow redesign packaged as a feature, an attempt to make the team rather than the individual the unit of AI adoption. If it works, the company that once changed where colleagues talk will have changed where software gets made. If it doesn't, all that transparency may just mean everyone gets to watch the slop pile up together. Either way, the era of the lone developer whispering to an agent in a private tab is ending. As Wang put it: "The bottlenecks have shifted." The question Slack Code will answer is whether the crowd makes them smaller — or just louder.

8/20/2026

Enterprise AI teams have stopped betting on a single orchestration platform. The median enterprise now runs three at once — not by accident, but because none of them fully trusts a single vendor to run the show, according to VB Pulse data. This is not just to avoid vendor lock-in and retain flexibility (although that’s a big part of it). There’s still a lot of uncertainty, even distrust, in vendors’ security and permissioning capabilities. Enterprises want the ability to impose their own. Microsoft leads on primary usage today, while Anthropic leads by a wide margin in what enterprises are considering next. But enterprises still struggle with many challenges, notably around token usage and visibility into agent spending. These findings are from an ongoing analysis of how enterprises are actually deploying and using AI: Their platforms of choice, what guides their decision-making, what they prioritize, their AI expectations, how they control costs, and whether their AI is actually agentic or still a chatbot in an "agent" label. VB Intelligence is getting feedback from builders actually in the trenches: software and machine learning (ML) engineers, product and program managers, and data/AI/analytics VPs and directors. Concerns around retaining visibility and control Across 107 enterprises, agentic orchestration has become decidedly plural. The survey found that the majority of enterprises are not committing themselves to any one model: 85% are using two or more orchestration tools; 64% are using three. Just 15% run a single orchestration platform. Microsoft AI Foundry/Copilot Studio shows up in 70% of stacks, OpenAI’s Agents SDK in 68%, and Anthropic’s Claude Platform in 47%. Builders surveyed are also to some extent using Google’s Enterprise Agent Platform, LangChain/LangGraph, Salesforce Agentforce, Amazon Bedrock, and LlamaIndex. Augmenting vendor tools, 22% of builders run custom in-house orchestration. This trend of hybridability is only expected to continue. More than half of respondents (53%) said the primary control plane will be hybrid by the end of 2026. Fourteen percent expect to use a provider-managed service, 13% plan on a custom in-house control plane, and 11% are betting on external platforms that are abstracted away from model providers. Dovetailing with this, more than two-thirds of respondents plan to change platforms within the year: 15% in the next three months (or sooner), 24% in three to six months, and 28% in six to 12 months. Claude Agent SDK is a top tool under consideration; 43% of builders are exploring the Anthropic-built model. Roughly one-third are looking at Google’s Enterprise Agent Platform, another 31% are focused on custom in-house orchestration, and 25% are investigating OpenAI’s options. Perhaps learning from the lock-in of the early cloud days, enterprises aren’t choosing one “winner.” They are deliberately building for a future where multiple orchestration platforms, models, and agents work with each other across a hybrid control plane. Generally speaking, respondents are pleased with the platforms they’ve been running, rating them 4.17 out of 5 for overall satisfaction. But they are less satisfied with ease of implementation (rating it 3.91 out of 5) and value for the money (3.63 out of 5). Keep an eye on these ratings as orchestration platforms and AI roadmaps mature. Where enterprises are putting their money Enterprise buying logic is now based on a mix of several factors. Beyond flexibility (cited by 29% of respondents), top considerations include security and permissions (17%), production reliability (15%), and control over agent execution (15%). Just one out of 10 identify model gravity — native alignment with a state-of-the-art base model — as important in purchasing decisions; 8% name ease of development, 4% cite total cost of ownership, and just 2% cite latency and memory performance. Spending also reflects enterprise priority on visibility, security, and control. Builders are investing the most in agent monitoring and debugging (31%) and security and permissions enforcement (30%). Workflow tooling accounts for another 19%. That's a shift from VentureBeat's prior wave a month earlier, when workflow tooling led orchestration spending outright. Enterprises are largely optimizing for task completion reliability (30%), multi-step workflow management (27%), developer productivity (23%), and operational stability (13%). Just 7% of respondents name end-user experience as a top priority at this point, indicating that many are still focused on orchestration at this point rather than UX. Essentially, enterprises are signaling that workflow succeeds when it carries multiple steps to completion. Simplifying development and end-user experiences could become a larger concern when platforms are actually in place. The visibility problem Builders’ biggest concerns when choosing platforms center around control and oversight. They don’t want vendors to constrain their ability to see what their agents are doing on a given platform. Factors top of mind include security and permissioning limitations (37%), vendor lock-in (23%), limited visibility and observability (22%) and inflexibility around models and tools (16%). Meanwhile, in these early days of AI agents, enterprises still struggle to control agent token use; one in five still can’t stop a runaway agent’s spending in real time. Builders are using various strategies to try to keep agent spending in line: 30% rely on native platform controls (built-in budget caps or throttling) and 25% have built custom gateway plumbing (proxy middleware to intercept runaway agents). A quarter of respondents use dynamic routing to offload heavy work to low-cost models, and 21% still rely solely on reactive monitoring, such as post-hoc logs; these enterprises have no real-time kill switches. One interesting finding: unlike the prior wave, organization size makes little difference in fiscal control maturity — 18% of enterprises with 10,000-plus employees exercise only reactive control, compared to 23% of smaller ones. Clearly, while enterprises recognize the problem with spend, many have not yet instrumented their stacks to rein it in. Most enterprises still aren't running true multi-step agents Builders polled were asked to honestly assess their tech stacks; the consensus seems to be that ‘agents’ are slowly but surely progressing beyond chatbots wrapped in that fancier label. Here’s how the numbers break down: A small number of respondents (2%) report that 76 to 100% of their systems are advanced and largely autonomous; 14% say 51 to 75% of their systems are complex, multi-agent pipelines; and 47% report that 26 to 50% of their systems are true orchestration. On the other end of the spectrum, 35% say just 1 to 25% of their systems are true orchestration; most deployments remain basic assistants, and 3% are still only deploying chatbots. This is in line with VB’s June Pulse survey: 71% of respondents said a quarter or fewer of their deployed “agents” can autonomously complete multi-step work, and just one-tenth say they have deployed agents at scale. There’s no doubt that enterprises are building control planes and infrastructures for agents; but for many of them, the true agentic wave is still off on the horizon.

8/20/2026

Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems. Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company's new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt. "In the next 12 to 18 months, everyone on a team will be a manager of agents," NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview. Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans. “I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.” For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt. As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors. From a single NanoClaw Slack agent to a whole specialized team For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels. Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running. With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user. The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity. Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine. Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely. The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time. Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another. The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want. “Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.” That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback. Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context. Agents work together with humans on a share Slack Canvas A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost. Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory. The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece. And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies. “Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.” That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents. Slack is opening the door to more third-party agents The underlying Slack change is broader than NanoClaw. In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May. Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack. Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity. Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s. “Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement. How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague. Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison. Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt. Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude. The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees. Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted. After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure. OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum. Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels. Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel. But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot. Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group. Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work. Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation. That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own. NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team. There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way. ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions. NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it. The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears. How NanoClaw got here NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw. The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture. The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes. In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests. By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars. That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure. “You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.” Persistent agents, but infrastructure stays under the user’s control Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there. The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session. NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions. “This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.” The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack. Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another. That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives. There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory. Continued commitment to open source NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice. NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation. Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.” Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.

8/20/2026

Serval is making Catalyst, its AI agent for building enterprise automations, generally available Thursday and enabling it by default for customers — allowing teams of AI agents to decide what should be automated and then build the automation itself. Catalyst sits above Serval’s AI-native service management platform as an admin-facing “super agent.” It can inspect ticket history, standard operating procedures or natural-language instructions, identify recurring work, and draft the workflows, skills, forms, access policies, journeys and dashboards needed to automate it. Serval is also using Catalyst to create background agents that continuously inspect connected systems for emerging problems and propose fixes before an employee files a ticket. That distinction matters because enterprise service management vendors are rapidly converging on AI-assisted workflow creation. ServiceNow’s Build Agent can already translate natural-language instructions into full-stack applications, flows, scripts and other platform metadata, while its AI Agent Advisor can analyze instance records to identify automation opportunities. Atlassian’s Rovo can generate Jira automation flows from plain-English requirements, and Freshworks offers Freddy AI Agent Studio for creating service agents that act across Freshservice workflows. So Serval’s claim to differentiation is narrower — and potentially more consequential — than simply “we use AI to build workflows.” Catalyst is designed as a single administrative layer that can move from discovering an opportunity, to assembling multiple kinds of governed automation, to creating proactive agents that keep looking for new work to automate. "You just started with a single prompt, and now you’ve got enterprise-grade workflows ready to deploy that are going to solve all password resets for the entire company," Serval co-founder and CEO Jake Stauch told VentureBeat in an interview. From ticket history to working automation Serval says Catalyst analyzes existing help desk data before an organization has decided what to automate. If it finds a repetitive category of requests, it can draft the automation required to resolve those requests and stage the result for administrator review. Users can also upload an SOP or spreadsheet and ask Catalyst to turn the documented process into an executable system. Serval’s documentation says Catalyst can build workflows, author help desk skills, create onboarding and offboarding journeys, configure access-management policies, construct dashboards, investigate operational issues and debug failed workflow runs. Unlike Serval’s earlier workflow builder, Catalyst is intended to become the primary interface for configuring the platform; the company says its long-term goal is that anything an administrator can do through the UI should also be possible through Catalyst. The actual workflows are code-backed. In a demonstration, Stauch showed Catalyst taking a request to build password-reset workflows, detecting connected systems including Okta, Google Workspace and Microsoft Entra, and generating the underlying TypeScript needed to perform those actions. Administrators could then add approvals or restrict who was allowed to run the workflow. The models underneath Catalyst are deliberately swappable Serval is not building its own foundation model. Stauch said in the interview that the company uses models from “frontier labs,” runs evaluations to determine which models work best for particular jobs, and is deliberately model-agnostic. “You can swap different models in,” he said, adding that Serval also works with enterprises that build their own models. Stauch provided more detail in a May 2026 interview with Sequoia Capital, saying Serval was using both OpenAI and Anthropic models. He said OpenAI’s GPT models had performed best for end-user interactions and tool calling, while Anthropic’s Sonnet and Opus models were producing the strongest results for the code-generation side of Serval’s automation system — the workload most directly relevant to Catalyst. Serval continuously runs evals rather than automatically moving every workload to the newest model release, Stauch said. That architecture makes the underlying LLM less central to Serval’s differentiation. The company’s own documentation now lets organization administrators supply their own OpenAI or Anthropic API keys, including a compatible custom endpoint, while Stauch said the broader architecture can accommodate different models. The materials do not, however, establish that every Catalyst user gets a self-service menu for arbitrarily choosing an individual model. Serval’s pitch is instead that its proprietary value sits in the harness around those models: enterprise context and memory, integrations, generated code, permissions, approvals and the controls governing what an agent can actually do. That code-generation model is central to Serval’s pitch against ServiceNow. Stauch argues that legacy ITSM deployments often accumulate custom tables, business rules, workflows and platform-specific expertise that make seemingly simple automation changes expensive to implement. Serval, by contrast, wants administrators and business teams to describe the outcome they need and let the model generate the implementation. But ServiceNow is no longer standing still on that front. Its current Build Agent similarly creates applications and code from natural-language prompts, supports flow design and testing, and operates inside ServiceNow’s governance framework. ServiceNow’s AI Agent Studio lets customers create agents and agentic workflows, while AI Agent Advisor is explicitly designed to analyze operational records for automation candidates. The competitive question is therefore shifting from “who has generative AI?” to how many separate tools, configuration concepts and specialists are required to get from an observed operational problem to a production automation. Serval is effectively arguing that Catalyst compresses those steps into one conversational surface and a smaller platform model. ServiceNow, by comparison, now has a powerful but broader set of AI and development surfaces spanning Build Agent, AI Agent Studio, AI Agent Advisor, Workflow Studio and AI Control Tower. That breadth is an advantage for customers already deeply invested in ServiceNow, but it also illustrates the complexity Serval is attacking. ServiceNow itself notes that Build Agent is aimed at admins and developers who understand and can support what it generates. Atlassian is moving in the same direction from a different starting point. Rovo can generate “if this happens, then that happens” automation flows from natural-language descriptions, while Jira Service Management increasingly supports agents that triage, investigate and execute service work. Freshworks’ Freddy AI Agent Studio likewise emphasizes agents that resolve requests end-to-end, with prebuilt IT and HR agents and more than 30 workflow templates. Catalyst’s differentiator, then, is not that rivals cannot generate an automation from a sentence. It is Serval’s attempt to make the entire automation lifecycle itself agentic. Building agents that look for trouble before a ticket exists That approach becomes clearest with Serval’s background agents. Rather than waiting for a help desk request, a background agent can run on a schedule across connected systems, correlate signals and draft a remediation. In one customer example provided by Serval, an agent correlated network incidents across two offices using switch telemetry, DHCP data and historical tickets, ruled out hardware and wireless interference, traced the issue to configuration drift, and generated a remediation workflow for an administrator to approve. “Most AI agents today wait for an employee to ask a question or submit a ticket,” Stauch said. “We believe the future is AI that acts before an employee ever submits a request.” That framing also highlights a philosophical difference in Serval’s pitch. The startup does not want service management to revolve around creating, routing and tracking better tickets. It wants the system to eliminate as many requests as possible by turning repeated support work into executable automation. "A lot of the code written in enterprises has nothing to do with software engineering," Stauch explained. "It’s actually internal automations and other scripts for the company, and so we use that technology to build a better service management platform." Serval's pitch to enterprises is that it can largely automate those scripts. And the governance model is critical because Catalyst can generate code and potentially initiate changes across production systems. Serval says Catalyst inherits the permissions of the user operating it and remains scoped to that user’s team workspace. Everything it builds starts as a draft, and organizations can restrict publishing privileges or require formal review and approval before an automation becomes active. Customer data remains customer-owned, with several deployment options Those controls also extend to the enterprise data Catalyst examines. Stauch said Serval is intended to operate as the customer’s system of record and told VentureBeat that “they own all the data.” Serval’s current Master Services Agreement is more precise: customers retain rights, title and interest in both their “Customer Materials” — a category that includes records, documents, workflows, prompts, inputs and configurations — and the output Serval generates from them. Serval receives the rights necessary to process that information to provide, maintain, support and secure the service. Serval also says it does not retain or use customer materials, inputs or outputs to train, fine-tune or improve its own or third-party AI models. Its Data Processing Addendum identifies Serval as the processor of customer personal data and allows processing for operating the service, responding to support requests, diagnosing issues and protecting the platform, while authorized subprocessors can also be involved. Serval’s acceptable-use terms say it maintains a current list of AI subprocessors and model providers for customers. Where that data resides can vary by deployment. Stauch said customers can use Serval as a cloud SaaS service, run it on-premises or place it in their own VPC. Serval’s self-hosting documentation now describes two fuller options: a Serval-managed single-tenant deployment inside an AWS account owned by the customer, or a self-managed deployment on the customer’s Kubernetes cluster in any cloud or on-premises environment. In the AWS option, Serval says it operates the installation without persistent IAM access to the customer’s AWS account. There are therefore two distinct access boundaries for enterprise buyers to consider. At the Catalyst level, the agent can only reach data, integrations and automations available to the user and team workspace under which it is operating. At the platform level, Serval and authorized subprocessors necessarily process customer information to deliver and support the service, subject to the company’s contractual confidentiality and data-processing terms. That makes Stauch’s informal statement that Serval “doesn’t touch” customer data better understood as an ownership and deployment claim, rather than a literal assertion that the service never processes it. Ramp and other customers provide an early test Customer deployments provide some evidence that the faster-build thesis can translate into operational changes, although the metrics come from Serval’s own case studies. Corporate expense and financial technology firm Ramp says in a Serval case study that Catalyst has made workflow building 50% faster and helped extend Serval across roughly 10 teams, including IT, finance, facilities, people and talent, legal and business operations. In one hardware replacement program, Serval says Ramp automated 600 laptop replacements and saved 150 hours, leaving approval as the principal human step. The more telling Catalyst example may be what happened afterward. Ramp had already automated laptop replacement when Catalyst suggested splitting its shipping logic into separate office and home workflows to reduce errors. The company also says employees outside IT now use Catalyst for analytics, bulk ticket operations, workflow troubleshooting and HR process automation. Other Serval deployments show the broader operating environment Catalyst is meant to configure. Mercor says it has onboarded more than 4,000 external experts through Serval automations and expanded the platform across seven teams. Together AI says Serval automates 95% of its just-in-time infrastructure access requests, with approval and auditing controls around sensitive access. Perplexity says Serval automatically handles more than half of its incoming IT requests and all employee onboarding. Those deployments extend beyond Catalyst itself, but they demonstrate the type of cross-system automation substrate Catalyst is now being asked to build and maintain. Serval says more than 90% of customers adopted Catalyst as their starting point for automation during beta. Catalyst is generally available Aug. 20 and will be enabled by default for all Serval organizations. Pricing and the battle with ServiceNow Pricing is customized depending on the size of the deployment and is not publicly listed on Serval's website or documentation. Serval describes a single platform fee and typically runs a pilot to determine expected deployment and usage. Stauch said the software license can be similar to ServiceNow’s, but argues total cost of ownership can be substantially lower because customers require fewer implementation and maintenance services. "The total cost of ownership is going to be dramatically less — usually half as much, sometimes 10 to 20% of the total cost of ownership of ServiceNow," Stauch said. "But the actual software license fee is not necessarily going to be all that different." Serval's origin story and history Serval was founded in 2024 by Stauch and CTO Alex McLeod, former Verkada product and engineering leaders, after they repeatedly heard IT customers complain about overburdened help desks and the limitations of established IT service-management software. Serval has positioned itself as an AI-native alternative to platforms such as ServiceNow and Jira Service Management, combining help-desk ticketing, access management, asset management and workflow automation within a single system. Serval and Sequoia Capital describe the company’s goal as moving IT software beyond merely recording and routing requests toward resolving them automatically. The company can operate as an organization’s primary IT service-management system or add automation to an existing one. Its publicly identified customers include Perplexity, Mercor, Clay, Verkada and Together AI. Serval says customers can automatically resolve more than half of their incoming IT requests; its Together AI case study reports automation of 95% of that customer’s just-in-time access requests. Investor interest accelerated rapidly in late 2025. Serval announced a $47 million Series A led by Redpoint Ventures in October, bringing its funding at that point to $52 million. In December, it raised another $75 million in a Sequoia-led Series B at a $1 billion valuation, lifting total capital raised to approximately $127 million; Redpoint, Meritech Capital and General Catalyst also participated. Serval told Reuters that revenue had grown 500% since August 2025 and that it was expanding beyond IT into operational work performed by human resources, finance and legal departments. The big test for enterprise customers For enterprise buyers, Catalyst’s biggest test will be whether its compression of the automation lifecycle survives contact with large, messy, highly customized environments. ServiceNow can now generate applications and discover automation opportunities with AI. Atlassian and Freshworks are adding increasingly capable agentic automation to their own service platforms. Serval therefore cannot rely on natural-language creation alone as its moat. Its stronger wager is that an AI-native platform can make the administrative layer itself agentic: continuously finding repetitive work, building the necessary resources across the service stack, exposing generated code for review, and proposing the next automation before an administrator has opened a workflow designer. If Catalyst works at that scope, the competitive unit is no longer the ticket — or even the workflow. It is the system that keeps turning an enterprise’s operational history into new automation.

8/19/2026

Another day, another new AI agent harness is released. Only this time, it's one that aims to solve a growing enterprise problem as AI agents proliferate: enabling greater developer control of agents and tools, while reducing cost. TrueFoundry, a San Francisco B2B machine learning startup co-founded in 2021 by former Meta engineers, has released its own custom TrueForge harness under the permissive MIT License on Github. Thus, it can be used with any of a developer (or their parent enterprise's) preferred AI models, forked, modified, self-hosted and incorporated into commercial products. The company states in a blog post that when it used TrueForge paired with the open source GLM-5.2 LLM to successfully complete 11 of 14 tasks on DevRev’s Enterprise-Bench — testing multi-step tool use across CRM, issue tracking, and document management systems — it cost 75% less than achieving the same results with Anthropic's Claude Managed Agents harness powered by Claude Opus 4.8 ($2.90 compared to $11.80). Using the same model in each harness, Opus 4.8, TrueFoundry still claims a cost savings of roughly 30% using TrueForge compared to Claude Managed Agents ($8.50 vs $11.80). Why is TrueFoundry giving this powerfully efficient harness away for free? "We’ve had this ask from a bunch of customers," said Anuraag Gutgutia, TrueFoundry’s co-founder and COO, in an exclusive interview with VentureBeat. "You have an ability where you bring in agents and MCPs — can we also get something where you can actually launch these managed agents? I think that is the need we are satisfying. It is not a replacement. People will use this alongside other harnesses, like the cloud-managed ones or the commercial-provider-managed ones, but this will serve as a way for people to use them in a vendor-neutral way and also at a lower cost.” Indeed, TrueFoundry already offers a paid "AI Gateway" for enterprises centrally controlling model and MCP access, credentials, permissions, budgets and observability. TrueForge, by contrast, handles what happens above that gateway: the loop that lets a model repeatedly reason, call tools, receive results and continue working until a task is complete. For enterprise developers, the practical proposition is that they can start locally with a single command and SQLite, then move the same agent harness into a shared deployment using Docker Compose or Helm with Postgres and Redis. TrueFoundry explicitly warns that the local configuration is intended only for use on a developer’s machine, not as an internet-facing production service. Gutgutia said the company ultimately wants its AI Gateway to become the common layer beneath whichever agents and harnesses an enterprise chooses. “There will be a set of companies that will use our harness as the way to launch managed agents,” he said, while others may continue using Claude, other open-source harnesses or internal systems. “But all that traffic should still be flowing through our gateway.” Context management is where TrueForge tries to cut waste TrueForge’s architecture centers on context engineering — controlling how much information gets sent back into the model on every step of an agent run. That includes delaying the loading of MCP tool schemas until they are needed, delegating isolated tasks to subagents, moving oversized tool results into files instead of stuffing them into the active context window, processing structured results through code, and automatically compacting long-running conversations. The documentation sets the default compaction threshold at 50,000 tokens, though it can be changed per agent. TrueForge also treats the sandbox differently from runtimes that keep an agent inside an isolated environment throughout its run. The core agent loop remains on the TrueForge server; a sandbox is provisioned as a tool only when the agent needs to execute code or work with files. TrueFoundry says that reduces unnecessary compute and allows a server to run more agents concurrently. The company argues those choices directly reduce model spending. How TrueForge compares to Claude Managed Agents and other leading orchestration harnesses Type / focus TrueFoundry TrueForge: General-purpose production agent harness designed for enterprise deployments. DeepSeek Harness: Open-source agent harness, currently positioned as a developer preview. OpenAI Codex CLI: Coding-focused agent harness designed primarily for software-engineering workflows. LangChain Deep Agents: General-purpose agent harness built on LangGraph. Anthropic Claude Managed Agents: Fully managed production agent runtime operated by Anthropic. License TrueFoundry TrueForge: MIT. DeepSeek Harness: MIT. OpenAI Codex CLI: Apache 2.0. LangChain Deep Agents: MIT. Anthropic Claude Managed Agents: Proprietary. Price TrueFoundry TrueForge: The open-source harness itself is free. Model, sandbox and infrastructure costs are separate. TrueFoundry also offers an optional commercial governance layer through its broader platform. DeepSeek Harness: No harness license fee. Users separately pay for whatever model providers and infrastructure they use. OpenAI Codex CLI: The CLI is open source. Underlying model/API or subscription costs are separate, OpenAI says around $100–$200 per developer per month, although actual spending varies substantially with model choice LangChain Deep Agents: Open source, with model and infrastructure expenses separate. LangChain also offers optional commercial services through LangSmith. Anthropic Claude Managed Agents: Claude tokens consumed plus $0.08 per running session-hour, with runtime metered to the millisecond. Model flexibility TrueFoundry TrueForge: Vendor-neutral and designed around bring-your-own-model support. DeepSeek Harness: Multi-provider and not restricted to DeepSeek models. OpenAI Codex CLI: Supports configurable inference endpoints, including OpenAI-compatible services and local-model options. LangChain Deep Agents: Broad multi-provider support through the LangChain ecosystem. Anthropic Claude Managed Agents: Claude-centric. Deployment TrueFoundry TrueForge: Can run locally as a single process with SQLite, then move into a production deployment using Docker Compose or Helm with Postgres and Redis. DeepSeek Harness: Designed for local or self-hosted operation. OpenAI Codex CLI: Primarily a local CLI experience, alongside OpenAI-hosted Codex products and services. LangChain Deep Agents: Can be self-hosted or deployed through LangChain and LangSmith infrastructure. Anthropic Claude Managed Agents: Anthropic manages the runtime and infrastructure. Key features TrueFoundry TrueForge: MCP and tool orchestration, subagents, human approval checkpoints, persistent sessions, context compaction, large-result offloading, Code Mode, generative UI, tracing and a sandbox-as-a-tool architecture. DeepSeek Harness: Pluggable models, tools, session storage and agent loops, along with sandboxing, permissions, approval gates and skills. OpenAI Codex CLI: Agent loop, repository and file operations, shell execution, MCP tools, sandboxing, permissions, approvals and context management. LangChain Deep Agents: Planning, subagents, skills, filesystem-based context management, persistent memory, human-in-the-loop controls, MCP support and multiple sandbox backends. Anthropic Claude Managed Agents: Managed execution environments, persistence, tools, sandboxing and infrastructure for long-running agents. Key differentiator TrueFoundry TrueForge: Its strongest distinction is the combination of an open-source, vendor-neutral harness with a clear path from local development to a shared production runtime, plus an optional enterprise governance plane through TrueFoundry. DeepSeek Harness: Emphasizes deep modularity. Major parts of the runtime, including models, tools, storage and the agent loop, are designed to be replaceable plugins. OpenAI Codex CLI: Stands out as a highly developed software-engineering-specific harness rather than a general-purpose enterprise agent server. LangChain Deep Agents: Benefits from the broader LangChain and LangGraph ecosystem and offers a mature open-source path for building general-purpose agents. Anthropic Claude Managed Agents: Minimizes operational burden by having Anthropic manage the runtime, but trades that convenience for tighter model and platform coupling. Open source does not automatically mean governed For enterprise buyers, one of the most important distinctions is between TrueForge by itself and TrueForge connected to TrueFoundry’s commercial AI Gateway. The open-source harness can run independently. But it does not magically inherit an organization’s enterprise access policies on its own. “If you are using just the open source version of our agent harness, yes, you will need to put the right controls therein or in front of some other internal control system,” Gutgutia told VentureBeat. When paired with TrueFoundry’s gateway, the company says agents can inherit the identities and access controls already attached to models, MCP servers, tools, skills and other agents. Gutgutia described the gateway as the place where enterprise SSO, identity providers and granular permissions can be centrally enforced rather than reimplemented separately for every agent. That distinction is likely to be important for platform engineering teams evaluating the project. TrueForge is free software; TrueFoundry’s governance layer is the commercial control plane around it. TrueFoundry says NetApp was a beta user of the harness and contributed requirements during development. Gutgutia said NetApp’s IT organization has used the technology for incident response and faster ticket triage, while also exposing internal agents as self-service tools for developers. He also identified Automattic as an early user. Background on TrueFoundry and its business to date TrueFoundry was founded in 2021 to help enterprises deploy and operate machine-learning models, including Kubernetes-based model serving, training and infrastructure management. Its three co-founders — Nikunj Bajaj, Abhishek Choudhary and Anuraag Gutgutia — previously worked at Meta and WorldQuant, respectively. Gutgutia said the founders' common experience was working around mature systems where infrastructure and controls were designed to prevent costly mistakes — an idea they believed would become increasingly important as AI moved into production inside large companies. As generative AI spread through enterprise software, TrueFoundry expanded from that MLOps foundation toward managing LLM applications and, increasingly, the models, tools and agents around them. By 2025, the company had made its AI Gateway a central part of the business: a layer sitting between enterprise applications and model providers that handles routing, authentication, access controls, observability, budgets, guardrails and failover. That evolution has been backed by roughly $21 million in outside financing. TrueFoundry raised a $19 million Series A in February 2025 led by Intel Capital, with participation from existing investors Eniac Ventures and Peak XV's Surge, as well as Jump Capital and angel investors including Gokul Rajaram and Mohit Aron. The round brought total financing to about $21 million, according to Intel Capital's announcement. At the time, TrueFoundry said its customer base had grown fourfold year over year and that it was managing more than 1,000 clusters for machine-learning workloads. The business has since become increasingly oriented around large-scale enterprise AI traffic. In VentureBeat's January 2026 coverage of TrueFoundry's TrueFailover launch, the company said it had more than 30 paid customers worldwide, had exceeded $1.5 million in annual recurring revenue during the prior year and was processing more than 10 billion requests per month through its AI Gateway. Customers and deployments cited by TrueFoundry have included NetApp, Siemens Healthineers, ResMed, Automation Anywhere, Nvidia, Games24x7 and others; Gutgutia also named NetApp, Siemens, Synopsys and Automation Anywhere among Fortune 1000 organizations working with the company in his interview with VentureBeat. TrueFoundry has also been expanding through acquisition. In June 2026 it acquired UK-based Seldon AI, a longtime MLOps vendor whose Seldon Core software has been used for production model serving and inference. As the acquisition shows, rather than treating traditional ML, LLMs, tools and agents as separate infrastructure categories, TrueFoundry is trying to put them behind a common deployment and governance layer. TrueForge extends that strategy upward into the agent runtime itself. Until now, TrueFoundry's commercial center of gravity has largely been the control plane underneath enterprise AI workloads — deciding which users and applications can access which models and tools, routing requests, enforcing policy, monitoring spend and keeping services available. TrueForge gives the company an open-source runtime above that layer where agents can actually execute. Gutgutia described the relationship as complementary: organizations can run TrueForge independently or continue using other agent harnesses, while TrueFoundry's longer-term business opportunity is to provide the common governance and infrastructure underneath whichever agents enterprises choose.

8/19/2026

Rob Strechay, until recently managing director and principal analyst at theCUBE Research, has joined VentureBeat as our first Lead Analyst and a founding analyst of VentureBeat Research. His arrival is the next step in a deliberate move at VentureBeat toward deeper specialization: analysis built for the technical decision-makers — the directors, VPs, CIOs, and CTOs — who are evaluating, buying, and deploying enterprise AI. The enterprise AI stack is being rewritten in real time, and the decision-makers I talk with are starved for objective, defendable data. Rob Strechay has the mix of technical rigor and operating experience needed to dissect the architecture behind the next phase of enterprise AI deployment. The questions enterprise technology leaders are asking have changed. As organizations move past experimentation with generative AI toward production deployment, they want to know how to orchestrate multi-vendor environments, where the security gaps in their agentic pipelines sit, and how to fix the utilization problems draining their infrastructure budgets. Answering those questions requires more depth than news coverage alone provides, and that is the gap this research offering is built to fill. An analyst who has sat on every side of the table Strechay brings nearly three decades of experience as a practitioner, product executive, and industry analyst. Before becoming an analyst, he was an executive at numerous startups, including Zerto; he joined Amazon Web Services to help build a new analytics service; and he held executive roles across enterprise infrastructure. He later served as a senior analyst at Enterprise Strategy Group and most recently as managing director and principal analyst at theCUBE Research and SiliconANGLE, where he hosted executive interviews and analyzed the evolution of cloud, data, and AI infrastructure. Strechay will initially focus his coverage on cloud infrastructure, advanced data infrastructure, platform engineering and DevOps orchestration and observability, and the intersection points where AI and enterprise security collide. Already at work: GPU utilization and the VB Pulse surveys Strechay has already been contributing to VentureBeat's research. In May he published an analysis of enterprise GPU utilization, examining the compute waste sitting inside enterprise AI infrastructure, and he provided a substantive review of our AI Infrastructure & Compute survey before it went into the field. His infrastructure-level focus complements the research engine VentureBeat has built around its monthly VB Pulse surveys, which track five areas of enterprise AI adoption: agentic orchestration, agent reliability and evals, agentic security and identity, AI infrastructure and compute, and context layers, including retrieval-augmented generation (RAG). Our June report on agentic orchestration, drawn from a survey of 145 enterprises, found that two-thirds of those enterprises had hedged their AI model strategy rather than committing to a single provider — a posture whose value the June outage of Anthropic's Claude models made plain. VB In Conversation: The first vehicle A core vehicle for this expanded research footprint will be a deepening of VentureBeat's existing VB In Conversation video interview series, which Strechay will host. Rather than high-level industry overviews, the series will bring architectural blueprints, actual deployment barriers, and back-end infrastructure realities to light through in-depth technical interviews with the architects and product leaders behind leading enterprise AI systems — an unvarnished look at which tools perform under production-grade pressure. "VentureBeat has built an audience of enterprise builders and technology buyers that any analyst would want to serve," Strechay said. "My goal is to use deep empirical metrics and VentureBeat's proprietary tracking data to help enterprise buyers and the people building for them make sound platform and infrastructure decisions during the most disruptive transition enterprise technology has seen." The expanded VB In Conversation series will appear on VentureBeat and on VentureBeat's YouTube channel, alongside Rob's written analysis on the site. Enterprise practitioners who want to take part in our monthly VB Pulse surveys, or arrange an analyst briefing with Rob, can reach the research team here.

8/19/2026

After a stunning debut last week with cyber capabilities so advanced they reportedly found a previously undetected vulnerability in Cursor, GLM-5.3, the new frontier open source language model from Chinese startup z.ai, has now hit the application programming interface (API) — allowing developers the ability to build atop it and plug it into their agents and applications. Developers who previously subscribed to a GLM Coding Plan are currently limited to the OpenAI Chat Completions-compatible protocol. Z.ai said it plans to make the model's weights openly available, but a precise date and licensing remain to be seen. On the API, the price is unchanged from GLM-5.2: $1.40 per million input tokens and $4.40 per million output tokens. Cached input costs $0.26 per million tokens, while Z.ai currently lists cached-input storage as free for a limited time. That means developers can move to the new generation without taking a higher posted per-token rate from Z.ai, even as the company claims substantially stronger coding and long-horizon agent performance. At those rates, GLM-5.3 sits well below several of the highest-end frontier APIs. Model Input ($/1M) Output ($/1M) Total ($/1M) Source Muse Spark 1.2 Contributor $0.10 $0.20 $0.30 Meta MiMo-V2.5 Flash $0.10 $0.30 $0.40 Xiaomi DeepSeek-V4-Flash — off-peak $0.22 $0.66 $0.88 DeepSeek GPT-5.6 Luna $0.20 $1.20 $1.40 OpenAI MiniMax-M3 $0.30 $1.20 $1.50 MiniMax LongCat-2.0 — limited-time promo $0.30 $1.20 $1.50 LongCat DeepSeek-V4-Flash — peak hours $0.44 $1.32 $1.76 DeepSeek MiMo-V2.5 $0.40 $2.00 $2.40 Xiaomi DeepSeek-V4-Pro — off-peak $0.66 $1.98 $2.64 DeepSeek LongCat-2.0 — standard $0.75 $2.95 $3.70 LongCat MiMo-V2.5 Pro (≤256K) $1.00 $3.00 $4.00 Xiaomi Gemini 3.6 Flash — through Dec. 31, 2026 $0.75 $3.75 $4.50 Google Gemini 3.7 Flash — through Dec. 31, 2026 $0.75 $3.75 $4.50 Google DeepSeek-V4-Pro — peak hours $1.32 $3.96 $5.28 DeepSeek Muse Spark 1.1 / 1.2 $1.25 $4.25 $5.50 Meta GLM-5.3 $1.40 $4.40 $5.80 Z.AI Grok 4.6 — <200K prompt tokens $2.00 $6.00 $8.00 xAI MiMo-V2.5 Pro (>256K) $2.00 $6.00 $8.00 Xiaomi Qwen3.8-Max $2.00 $6.00 $8.00 QwenCloud Gemini 3.6 Flash — starting Jan. 1, 2027 $1.50 $7.50 $9.00 Google Gemini 3.7 Flash — starting Jan. 1, 2027 $1.50 $7.50 $9.00 Google GPT-5.6 Terra $2.00 $12.00 $14.00 OpenAI Grok 4.6 — ≥200K prompt tokens $4.00 $12.00 $16.00 xAI GPT-5.4 $2.50 $15.00 $17.50 OpenAI Kimi K3 $3.00 $15.00 $18.00 Moonshot AI Claude Opus 5 $5.00 $25.00 $30.00 Anthropic Sakana Fugu Ultra (≤272K) $5.00 $30.00 $35.00 Sakana AI GPT-5.6 Sol — Standard mode $5.00 $30.00 $35.00 OpenAI Claude Fable 5 / Claude Mythos 5 $10.00 $50.00 $60.00 Anthropic GPT-5.6 Sol — Fast mode $10.00 $60.00 $70.00 OpenAI Using the simple VentureBeat comparison of one million input tokens plus one million output tokens, GLM-5.3 comes to $5.80, versus $8 for Grok 4.6 at its lower context rate, $18 for Kimi K3, $30 for Claude Opus 5 and $35 for GPT-5.6 Sol. That is not a workload-cost estimate — real bills depend heavily on the input/output mix, caching and token consumption — but it makes the relative API price tier easy to see. GLM-5.3 is not the cheapest capable model available. Google’s current introductory price for Gemini 3.7 Flash is $0.75 per million input tokens and $3.75 per million output tokens through Dec. 31, 2026, while OpenAI’s GPT-5.6 Luna is priced at $0.20 input and $1.20 output. Still, Z.ai’s price puts GLM-5.3 into a notably lower cost band than the premium frontier models it is increasingly benchmarked against. That comparison has become more relevant following the latest independent results. Artificial Analysis gives GLM-5.3 a score of 60 on its Intelligence Index, tying Kimi K3 as the top performing open weights model in the world, and scoring seven points higher than GLM-5.2. I ts analysis also estimates GLM-5.3 at about $0.68 per Intelligence Index task, versus roughly $0.44 for GLM-5.2, despite the identical API token prices. The difference underscores an important caveat in headline API pricing: Artificial Analysis found GLM-5.3 more verbose than its predecessor, so flat per-token rates do not necessarily mean flat costs for a completed workload. For developers, though, the immediate change is straightforward: GLM-5.3 is now callable through Z.ai’s API at the same $1.40/$4.40 per-million-token rate as GLM-5.2, giving teams another relatively low-cost option for testing frontier-class coding and agent workloads.

8/18/2026

Block, the technology company founded by former Twitter CEO Jack Dorsey that owns Square, Cash App and the music streaming service Tidal, is open-sourcing Berd, a desktop application it originally built to give its own employees a single environment for working with AI agents across different models, tools and projects. Berd is a locally installed graphical desktop application rather than a browser-based workspace. It is available now on GitHub under a permissive Apache 2.0 license — meaning anyone can use, modify and redistribute it, including commercially — with free downloadable builds for macOS, Windows and Linux. The repository reached version 0.6.2 on Aug. 18, its seventh public release, and lists 91 contributors. “Berd is desktop-first because much of its value comes from working directly with projects, local files, tools, repositories, and agents running on or connected to the user’s computer,” Brad Axen, Head of AI Capabilities at Block, told VentureBeat in emailed responses. A daily work surface for AI agents Block positions Berd as a “daily AI work surface”: a single place where users can start chats, attach files or folders, choose agents and models, work inside persistent projects, configure AI providers, manage skills and extensions, review session history and build automations. The design goal is not merely convenience. According to Berd’s product specification, users should always be able to tell which project, files, agent, model, provider and session state are actively shaping a conversation. That emphasis on visible operational state is what Block says separates Berd from a generic chatbot wrapper. Configuration — providers, extensions, skills, automations, projects — is treated as part of the workflow rather than buried in an administrative layer, and the interface is designed to expose failures, unavailable providers, and loading and streaming states plainly rather than smoothing them over with assistant-style friendliness. Berd grew out of a practical problem inside Block. Employees were already working with capable agents — Block’s own Goose, Anthropic’s Claude Code and OpenAI’s Codex — but the experience around them had become fragmented. “We had capable agents through goose, Claude Code, and Codex, but working across them meant navigating different interfaces, configuration systems, and ways of managing context,” Lucinda Bell, Technology Communications at Block, said in an email. Berd, she said, gives Block teams “one consistent desktop application across models and harnesses.” For enterprises, that layer may matter as much as another incremental gain in model capability. Persistent projects mean users can return to an established collection of files, instructions and agent configurations instead of reconstructing context for each task. Block also explicitly designed Berd to make agentic work accessible beyond engineering, letting people start with a conversation and add tools, context and structure as the work requires. Block is not positioning Berd as a mobile product. Axen said the company’s open source collaboration platform Buzz already provides a mobile experience and is Block’s preferred environment for work on the go. Block thinks agents should look different when they are different Berd takes an unusual approach to a problem most enterprise AI products leave implicit: how users tell one configured agent apart from another. Instead of treating every agent as another blank chat window, Berd gives agents roles, instructions, skills, tools and recognizable visual identities. Block created collections of animated characters — its flagship designs are called “Gloopies” — and Berd’s public site showcases predefined personas such as Berdy, Pushback, Choosey, Copycat, Tinker and Wildcard, each built around a different style of work: Pushback plays devil’s advocate on drafts, Choosey helps narrow decisions, Copycat learns to write in the user’s style. The visual layer is not meant to substitute personality for substance. Block’s own formulation, from a company blog post on Berd’s design, is functional: “The avatars make the agent recognizable. Its role, skills, and tools make it useful.” That distinction could grow more important as workers juggle several specialized agents at once. A recognizable identity serves as visible shorthand for an otherwise invisible package of instructions, tools and permissions — agents appear on the workspace as distinct animated characters rather than identical entries in a chat list, so users can tell them apart before opening a conversation. The product specification guards against the characters turning Berd into a novelty. It describes the intended personality as “focused, capable, companionable,” while explicitly rejecting toy-like presentation, oversized decorative UI and interfaces that hide operational state behind friendliness. An orchestration layer, not another model or agent runtime Architecturally, Berd is neither a new foundation model nor a new agent runtime. The application is built with Tauri 2 and React 19 — frameworks for building lightweight desktop apps with web technologies — and communicates with Goose, the open source agent framework Block introduced in January 2025, through a standard called the Agent Client Protocol (ACP). Goose runs quietly alongside Berd as a bundled “sidecar” process and handles the underlying agent loop; Berd handles projects, sessions, context, agents and configuration on top. For readers unfamiliar with it, Goose is a model-agnostic agent framework and runtime, originally focused on software development workflows. It connects large language models to files, commands and outside systems — including through the Model Context Protocol (MCP), an open standard for wiring AI systems to external tools and data — so agents can take actions rather than merely generate text. Goose works with proprietary model providers as well as locally run open models. Block has since contributed Goose to the Agentic AI Foundation, the Linux Foundation body it helped establish with Anthropic, OpenAI and others in December 2025, giving the framework a vendor-neutral home alongside MCP. Axen drew the boundary explicitly: agent harnesses such as Goose, Claude Code and Codex manage the loop between a model, its context and its tools, while Berd provides the consistent desktop environment around those harnesses. In the public release, users configure whichever providers and harnesses they want rather than inheriting a Block-selected model stack. The project’s README adds an operational detail that matters for anyone evaluating the software: Berd does not simply pull whatever Goose build happens to be current. Its build process pins a specific Goose backend version through a lockfile, verifies the cached binary matches that pinned version, and packages it with the app. Developers can explicitly substitute another Goose binary for local testing. For organizations inspecting Berd, that creates a defined version boundary between the desktop application and its default agent backend rather than letting the backend silently drift. How Berd compares to Codex, Claude Code, Cursor and Goose That separation matters because the agent-tooling market is already converging on products that manage increasingly autonomous AI workers. OpenAI describes its Codex app as a “command center” for agents, with separate project threads and multiple agents operating in parallel. Claude Code, Anthropic’s agent for reading codebases, editing files and executing commands, now spans the terminal, IDEs and a desktop app. Cursor describes its latest release, Cursor 3, as a unified workspace for software development with agents, including handoffs between local and cloud agents and multi-repository workflows. And Goose itself remains available directly, as a free command-line tool and desktop app for technically comfortable users. Berd’s differentiation is therefore less about inventing the agent workspace than about making that workspace open source, multi-harness and potentially useful outside coding. Every other product in the table below is either tied to a single vendor’s models, priced as a subscription, or aimed squarely at developers — and in most cases all three. Product Maker Pricing Model support Distinguishing features Berd Block Free and open source (Apache 2.0); users pay only their own model provider costs Any provider the user configures, across multiple agent harnesses Desktop workspace over agent harnesses rather than a harness itself; local-first data storage; visual agent identities; persistent projects; enterprise custom distributions; designed for non-engineers as well as developers Codex app OpenAI Included with paid ChatGPT plans, from Plus at $20/month to Pro at $200/month OpenAI models only “Command center” for coding agents; multiple agents running in parallel across separate project threads; cloud and local execution Claude Code Anthropic Included with paid Claude plans, from Pro at $20/month to Max at $100–$200/month; also usage-based via API Anthropic Claude models only Deep autonomous coding — reads codebases, edits files, runs commands; available in terminal, IDEs, desktop and web; usage caps have drawn developer criticism Cursor Anysphere Pro at $20/month; Ultra at $200/month Multiple frontier models AI-native code editor; Cursor 3 adds a unified agent workspace with local-to-cloud agent handoffs and multi-repository workflows; developer-focused Goose Block / Agentic AI Foundation Free and open source (Apache 2.0); bring your own model, including free local models Any provider, or fully local models via tools like Ollama The model-agnostic agent framework and runtime underneath Berd; CLI and desktop versions; can run entirely offline with no data leaving the machine Portability is part of Block’s pitch. Axen said much of the underlying work in Berd is deliberately kept portable: folders, Git repositories, files and plain-text instructions remain accessible outside the application; skills are file-based; and Berd agents can be exported and shared between Berd users with their instructions and settings intact. He pointed to ACP and MCP as part of Block’s direction toward “clear, user-owned formats and open protocols wherever possible.” That does not make every piece of state interchangeable across every harness, but it makes portability an explicit architectural goal rather than a side effect of using local files. Local-first data, telemetry and enterprise distributions Berd is designed around a local-first data model. Axen said conversation history is stored on the user’s device in the local Goose session database, while credentials live in the operating system keychain by default. That does not mean all AI processing happens locally. “Local-first does not mean that no data ever leaves the device,” Axen said. When a user asks a configured model to work on particular context, the relevant prompt and material are sent to that model’s provider — so the actual data path, and the contractual terms governing it, depend on which provider an organization chooses. Telemetry — the usage data software sends back to its maker — is disabled by default in official Berd distributions. If a user opts in, Block says it collects a random installation identifier and a limited set of predefined usage events, while excluding prompts, messages, files, source code, credentials, names, email addresses and IP addresses from the telemetry payload itself (Block and its service providers still process IP addresses for transmission, security and rate limiting). Users can switch telemetry off again in settings. Block cautions that third-party forks can modify or redirect the telemetry system, so enterprises evaluating a customized build need to review that build’s actual behavior rather than assume Block’s defaults carry over. The public repository builds a self-contained, general-purpose distribution that does not depend on private package registries or enterprise credentials — technical teams can build and evaluate it without access to Block’s infrastructure. But Block has also created what it calls “distribution seams”: defined points where organizations can overlay managed provider settings, private agents, runtime configuration, optional companion tools, their own update channels and their own signing and publishing infrastructure, all without adding private material to the public source tree. Block’s own deployment shows how an enterprise can put governance around that architecture. Axen said Block runs its managed distribution on approved devices using approved model-provider infrastructure, managed configuration and governed tool connections. “The application can remain open and inspectable, while an organization decides which models, tools, permissions, and policies are appropriate for its environment,” he said. One caveat: “enterprise distribution” should not be read as a complete enterprise management plane. The README does not describe capabilities such as single sign-on, centrally enforced administrator policies, organization-wide permission controls, data-retention rules or audit logs. It establishes that companies can customize and distribute Berd; it does not by itself explain how those installations are centrally governed after deployment. Berd should be understood as endpoint software installed on users’ computers, not a centrally hosted SaaS product. Pricing, models and a closed contribution model Block has not announced a subscription price for Berd, and there is no indication one is coming. That does not make agent usage costless: organizations still pay whatever model, API or provider charges they incur. The economic pitch on Berd’s site is flexibility — users can match the model to the job rather than paying for an expensive frontier model on every task. As the site puts it: “Some tasks need the big brain. Most don’t.” Neither Block’s announcement nor the README provides a definitive matrix of supported model providers or recommends particular models. Internally, Block does not treat any one model as a permanent default: Axen said the company’s managed distribution exposes employees to “a curated mix of frontier and open-weight models,” with the catalog changing as models improve. “The best choice depends on the work,” he said. There is also a governance distinction developers should note. Although Berd’s source is public and Block solicits issues and feedback, the repository does not accept outside pull requests — external code contributions are automatically closed. The README says Berd is built by “a small team at Block” and directs outside participants toward well-formed, reproducible bug reports instead. Users are free to inspect, build and fork the code, but Block retains a tightly controlled upstream. For companies considering Berd as infrastructure rather than an experiment, that makes Block’s long-term maintenance and support plans worth clarifying. Block is not presenting Berd as a revenue product today. Axen said the first return on investment comes from Block’s own use of the software — making internal agent work more consistent while teaching the company how employees actually use agents — and that open-sourcing it adds leverage by letting outsiders inspect, adapt and give feedback on the architecture. A commercial layer around enterprise deployment may eventually follow. “Supporting organizations that want to deploy agents at work is an area of interest for us,” Axen said, adding that Block will share more when there is more to share. From private agent work to multiplayer workflows Berd supplies the individual desktop experience; another Block project, Buzz, focuses on shared rooms where people and agents collaborate against a common, searchable record. Buzz is Block’s free, Apache 2.0-licensed collaboration workspace for humans and AI agents. Built on the decentralized Nostr protocol, it combines familiar team features — channels, threads, direct messages, voice and media sharing — with agents that hold their own cryptographic identities and defined permissions, and that can participate in conversations, code review and approved automated workflows. Unlike Berd’s local, single-user focus, Buzz is explicitly multiplayer, and can be self-hosted or used through Block-hosted infrastructure. It is likewise model- and harness-agnostic: teams can bring agents powered by Goose, Claude Code, Codex or others. Axen framed the split between the two products partly as a question of trust boundaries. “A local agent may have access to your filesystem and credentials,” he said. “An agent in a shared Buzz room has its own identity and access scoped through the relay.” Berd begins with one person and comparatively privileged access to that person’s machine; Buzz begins with multiple participants, explicit identities and shared-workspace permissions. The more consequential roadmap detail is that Block does not intend the two products to remain separate. “Going forward, our focus is Buzz, and we plan to bring the best parts of Berd’s single-player experience into it,” Axen said. Block wants work to begin privately and become collaborative without users switching tools or rebuilding context, with cross-device continuity — including mobile via Buzz — part of that ambition. In the meantime, Axen said, Berd remains available as an open source desktop application, but Buzz is the product Block encourages people to download and adapt. What enterprise adopters should take away The short version for IT and security teams: conversation history stays local by default; credentials use the operating system keychain; context sent to a model leaves the machine on whatever terms the configured provider offers; official telemetry is off by default and excludes prompts, files and source code; and organizations can package their own governed distribution — though central management tooling is not yet documented. The larger idea behind the release may matter more. Models and coding agents are becoming increasingly interchangeable components inside larger workflows. Berd is Block’s bet that the surrounding context — the projects, skills, tools, identities and persistent working environment — becomes the stable layer instead.

8/18/2026

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." A directional finding, not a market census 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. Confidence in automated evals improved, but outcomes stayed flat 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 enterprises that got burned are moving faster toward zero-human deployment 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. The release gate is automated, but production quality monitoring still lags 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. An independent agent-evaluation market begins to take shape 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. Human review is becoming the hedge against automated misses 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. The narrow but consequential read 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.

8/18/2026

Presented by Rezolve Ai Enterprise AI investment in commerce has never been higher. And enterprise AI outcomes in commerce have rarely been more inconsistent. That gap is not a coincidence. It is the predictable result of a pattern that has repeated itself across every major technology shift in retail: the industry adds new capabilities faster than it integrates them. That pattern is now playing out in commerce AI. The point solution pattern The dominant approach to commerce AI over the past three years has been an additive one. Brands have layered AI-powered search on top of existing catalog infrastructure. They have added conversational interfaces on top of existing checkout flows. They have deployed recommendation engines alongside personalization tools that were themselves deployed alongside earlier recommendation engines. Each addition was justified by a discrete metric improvement, and none were designed to work as a cohesive system. This is the point solution pattern, and commerce has lived inside it for two decades. It produced genuine progress in isolated capabilities: faster search, better recommendations, lower friction at specific points in the journey. What it did not produce is coherence across the journey. Consumers experience that incoherence as inconsistency, context loss, and the feeling that each part of the shopping experience doesn't know what the others are doing. AI amplifies the cost of that incoherence. When a general-purpose AI tool makes a recommendation based on incomplete or inconsistent data, it doesn't surface a suboptimal product. It confidently surfaces the wrong one, and often excludes the incomplete one altogether. The hallucination problem in commerce AI is largely a data coherence problem in disguise. Tools that don't share a common understanding of inventory, pricing, policy, and product truth will produce outputs that contradict each other and mislead consumers. Where the metrics lie The fragmented approach to commerce AI creates a specific kind of reporting problem: individual tools perform well in isolation while the system underperforms in aggregate. A conversational AI tool can show strong engagement metrics. The search layer can show improved relevance scores. The checkout system can show reduced abandonment within its own funnel. None of these metrics captures what happens at the handoffs between them, where context breaks, sessions drop, and purchase intent that was successfully generated in one layer fails to convert in the next. This is why brands investing aggressively in commerce AI are sometimes reporting strong tool-level performance alongside flat or declining overall conversion. The tools are working. The system isn't. And the standard analytics stack, built to measure individual touchpoints rather than journey coherence, will not surface that distinction. Bain research shows that organic web traffic to retail sites has declined 15 to 25% as AI-driven zero-click search has grown. Brands are losing top-of-funnel visibility to AI disintermediation at the same time their internal AI tools are generating positive performance reports. That combination — external pressure compressing the funnel while internal fragmentation leaks it — represents a structural problem that point-level optimization cannot solve. What separates the companies closing the gap The brands that are generating consistent, measurable outcomes from commerce AI share a common architectural characteristic: they have built or adopted a unifying execution layer that sits across their AI investments rather than beneath them. This isn't a new technology category. It is a different design philosophy. Instead of asking what AI capability to add next, these brands have asked what the connecting tissue between AI capabilities needs to look like in order for those capabilities to produce a coherent consumer experience and a reliable transaction outcome. The answer, in practice, involves three things: a shared data layer that gives every AI tool in the stack access to the same real-time product, pricing, and inventory truth; a policy and governance framework that ensures AI-generated recommendations operate within the brand's established rules; and a transaction layer that can receive intent from any AI surface and convert it into a completed order without breaking context or requiring the consumer to restart. Brands that have those three things in place are not just getting better results from individual tools. They are compounding improvements across tools, because each capability in the stack is operating on consistent inputs and contributing to a coherent output. The architectural question commerce can't defer The window for treating commerce AI fragmentation as a temporary problem is closing. As agentic commerce matures and AI systems begin to initiate and complete transactions on behalf of consumers, the stakes of incoherence rise significantly. An AI agent acting on behalf of a consumer doesn't have the patience to navigate a broken handoff between a recommendation layer and a checkout system. It will fail, and it will not return. The brands that establish architectural coherence now, before agentic transactions become the norm, will enter that era with a compounding advantage. Those that continue to add point solutions will find that each new tool adds a new potential point of failure. Commerce AI isn't fragmenting because the tools are bad. It is fragmenting because the connective infrastructure was never built. The brands that recognize that distinction — and act on it — are the ones that will define what commerce looks like in the next decade. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/18/2026

Enterprise teams running AI agents at scale are finding that a single model handles every task poorly — either the model is too expensive for simple questions or not capable enough for hard ones. Model routing, which picks the right model for each task automatically, is becoming the fix. Snowflake’s Cortex AI Gateway now offers dynamic model routing to address that: enterprises can select “auto” instead of a fixed model, and the system routes each task to whichever model offers the best combination of quality and cost. Snowflake said the capability can cut token costs by as much as 3x on some workloads — a figure from the company’s own internal testing — after finding that simple questions were often handled by its most capable model, making responses more expensive and slower than necessary. The move lands amid a broader industry shift toward automated model routing. Databricks, AWS, Google Cloud and Nvidia have all announced some form of model routing technology. Snowflake argues that model routing is more complex than just price and performance, it's also about governance and context. "For high quality, enterprise grade agents to be built, it's crucial to get the context and the governance right," Baris Gultekin, vice president of AI at Snowflake, told VentureBeat. “Context, trust and model choice all go hand in hand." Two mechanisms decide where a task goes The capability builds on Cortex AI Gateway, which Snowflake launched in July 2026 as a governance layer for agent and model traffic. Before dynamic routing, model selection ran off a static list per task rather than a true fallback system, Gultekin said. Dynamic routing itself runs on two mechanisms, according to Gultekin. A small model tries first. Under what Snowflake calls an advisor pattern, a smaller model attempts a task first. If it cannot finish the job, it calls a larger model as a tool and continues from there. A classifier sorts by task history. A separate classifier, trained on past queries, automatically routes straightforward questions to simpler models. Customers can still pin a model. Auto routing is optional. Customers can restrict routing to one model or a defined set of models, and the system routes only within that boundary. There is no separate fee. Snowflake prices AI purely on token usage. Routing to a cheaper model produces a cheaper bill, with no additional charge for the routing decision itself. Access controls follow the task, not just the data Snowflake ties routing to the same access controls it already uses for data governance. Governance starts at the data level with role-based access controls. It extends to models next, where customer roles map to buckets of approved models. It extends again to agents, where an agent can be restricted to narrower privileges than the user invoking it. Open models can run from a customer's own region to satisfy data residency requirements. Gultekin said all inference, open and proprietary alike, stays inside Snowflake's security boundary rather than routing out to an external provider. That regional and perimeter setup matters specifically for open models with non-U.S. origins, including DeepSeek-V4-Flash and GLM-5.3, both developed in China. Snowflake's recent acquisition of Natoma adds another layer. The deal brings more than 100 MCP connectors with scoped, governed access. An agent could get read-only access to a connected tool like email, for example, rather than broader permissions. Context lets a cheaper model do the work Snowflake recently announced its Horizon Context and Cortex Sense tools that provide context capabilities. Without good context, a model has to do the exploratory work itself, writing and testing SQL, searching through data and retrying when something does not work. Gultekin explained that the process is expensive, and getting it right typically requires a more capable model. Packaging the context in advance removes that exploratory step, which means a simpler, cheaper model can often handle the same task. Snowflake also builds agent memory into that context. As an agent is used repeatedly, its memory updates and gets folded back into future queries. The system does not re-solve the same problem from scratch each time. Memory becomes part of the context passed to the model. OpenRouter, Databricks and Nvidia are chasing the same problem There is no shortage of technologies in the model routing space. OpenRouter is one of the most widely known options, providing a platform that enables organizations to route based on cost and performance. Nvidia on August 11 announced Switchyard as a technology layer to help route AI model choice. Databricks has an offering as well with Smart Routing for its Unity AI Gateway. "The interesting part is what it says about where differentiation has moved," Sanjeev Mohan, Principal and Founder, SanjMo, told VentureBeat. "Snowflake isn't really selling routing, it's selling routing that never leaves the governed data boundary, with access controls, tagging, and cost attribution already attached." Mohan added that for a company whose data and compliance already center on Snowflake, routing that keeps data in place and attributes spend by team is a real lever on that problem. For a company without that center of gravity, a neutral gateway may route across more models with less friction. Mohan frames the market as three distinct camps rather than one competitive field. Databricks approaches governance from data engineering and ML lineage. Its Unity Catalog governs data, models and pipelines for teams building and training models. Snowflake approaches governance from analytics and access control, governing who can touch which data and attributing usage across business units. A third camp includes neutral gateways such as OpenRouter, LiteLLM, Portkey and hyperscaler routers like Azure AI Foundry. These compete on model breadth and avoiding lock-in rather than deep governance. Choosing a router means choosing a governance model Model routing is now table stakes for enterprises. The decision that matters is which governance model already fits how their data and teams are organized, not which vendor’s router is fastest or cheapest. Manual model selection is becoming a cost liability at agent scale. What worked when a team ran a handful of agents breaks down at scale. Hundreds of agents making routine model calls with no automated cost check in place adds up fast. Evaluate the governance model, not the router's feature list. The real question, per Mohan, is which governance model matches the data estate already in place, and which one gives the cost visibility needed to avoid an unpleasant surprise. The right starting point depends on where an enterprise's data already lives. A Snowflake shop gets more value from in-platform routing that respects its existing access model and bills back to cost centers than from raw model breadth, according to Mohan. A Databricks-centric team worried about lineage across training and deployment is better served by a gateway built around that same lineage. A multi-platform or model-first team that wants maximum choice with minimal lock-in fits better with a neutral gateway, the same pitch behind OpenRouter's valuation. "For a practitioner, don't start with the router, start with where your governed data and platform commitment already live, and with how exposed your margins are to inference cost," Mohan said.

8/18/2026

The biggest AI model release of the past few days, at least among the developers and AI power users on social media, wasn't a frontier cloud model from OpenAI, Anthropic or Google. It was a 27-billion-parameter model from Alibaba: Qwen3.8-27B landed on Hugging Face on Friday under an enterprise-friendly, open source Apache 2.0 license, giving developers downloadable weights for a dense multimodal model. But Qwen3.8-27B isn't a garden variety small local model: it includes native image and video understanding, a 262,144-token context window, configurable reasoning and support for coding and agentic workflows — a “compact, deployment-friendly” version of the capabilities developed for its Qwen3.8 generation. That unusually small hardware footprint is a major part of Qwen3.8-27B’s appeal. Running the model at full 16-bit precision requires roughly 56GB of GPU memory, while an FP8 version needs about 28GB. But 4-bit quantization cuts the model itself to roughly 17GB, putting it within reach of high-end consumer machines such as a powerful gaming desktop or well-equipped laptop. Hitting the sweet spot between capability and size The outsized reaction among developers has been due to the dynamic combination of its capability and size. Alibaba's own launch benchmarks immediately supplied the first jolt. The company reported 61.7 on SWE-bench Pro, 90.3 on LiveCodeBench v6, 70.7 on its CoWorkBench office-work benchmark and 84.3 on OSWorld-Verified. In Alibaba's published comparison table, the 27B model even beats the listed Claude Opus 4.6 Max result on SWE-bench Pro and LiveCodeBench, although Opus remains ahead on Terminal-Bench, GPQA Diamond and Humanity’s Last Exam. Some of Alibaba's evaluations are internal, and benchmark harnesses are not identical across every comparison, making the numbers poor grounds for declaring a universal winner. Third-party results show a powerful, local model with performance equivalent to proprietary models from months ago The conversation changed Monday when third-party results began arriving. Third-party AI benchmarking outfit Artificial Analysis gave Qwen3.8-27B a score of 52 on its Intelligence Index, a composite of nine evaluations spanning coding, science, reasoning and professional tasks. That happens to be the same score Artificial Analysis currently assigns OpenAI's low-tier model GPT-5.6 Luna at its maximum reasoning setting — a proprietary offering only available over the cloud. As open source coding agent Cline put it on X: "This is the first time a local model has scored frontier model capability. We weren’t expecting this pace of local progress anywhere near this soon." On Artificial Analysis' Agentic Index measuring model performance on agentic tasks, meanwhile, Qwen3.8-27B scored 51, beating Claude Opus 4.8 on maximum reasoning effort — a frontier model Anthropic released less than three months ago. That doesn't mean these models are equivalent, but it helps explain why developers and AI power users stood up and took notice. As developer and AI podcaster/YouTuber Sero (@0xSero on X, real name Sharif Cherf) wrote on X: "A model that runs on 3k USD of hardware is beating everything from 4 months ago. Including Opus. Permanent underclass is cancelled." Developer Joshua “Xenova” Lochner, known for bringing machine-learning models into web browsers, highlighted the result Monday on X alongside an experiment running Qwen3.8-27B with custom WebGPU kernels. His reaction — “What a time to be alive!” — captures much of the mood: a model scoring in the vicinity of proprietary frontier systems can be downloaded, modified and executed locally rather than accessed only through a vendor API. The appeal becomes clearer when the model is compressed. Developer and AI writer Simon Willison tested a roughly 17GB Q4_K_M quantization on an M5 Max MacBook Pro and Nvidia DGX Spark. He found that it could write code, interpret images and operate a coding-agent loop through the Pi agent framework. In one experiment, the model navigated a codebase to explain how authentication worked; in another, it wrote and tested a Python utility Willison needed to convert an agent transcript from JSONL to Markdown. “The fact that a 17GB file can do all of this stuff on my home machines is a miracle,” Willison wrote. His broader point is the one resonating with power users: capabilities that recently felt inseparable from expensive hosted models are moving into files small enough to keep on a workstation. The reaction is showing up in usage as well. Cybernews reported Monday that Qwen3.8-27B passed 3 million Hugging Face downloads in its first three days, while quantized versions rapidly appeared for local inference tools. The LocalLLaMA community on Reddit created a dedicated release megathread simply to consolidate the flood of benchmarks, quantizations, configuration advice and comparisons. One user showing a locally generated game described the model as “a different beast.” Overthinking is an issue That frenzy comes with an important caveat: Qwen3.8-27B appears to buy some of its quality by thinking a lot. Artificial Analysis says the model generated 160 million output tokens across its Intelligence Index testing, versus a 43 million median for comparable open-weight models. Willison encountered an extreme version of the same behavior because Qwen defaults to its xhigh reasoning setting. A request to generate an SVG of a pelican riding a bicycle took 21 minutes and consumed more than 22,000 reasoning tokens before producing the answer. He recommends starting with low or no reasoning for ordinary local use. Investor and developer Tomasz Tunguz found a similar trade-off in a small nine-task test against DeepSeek V4 Flash: with reasoning enabled, Qwen edged ahead on quality in his agent stack, but he reported that it was roughly 30 times slower and 4.5 times more expensive. He explicitly cautioned that nine tasks were not enough for a verdict. Inference software may narrow that gap. Qwen3.8-27B includes Multi-Token Prediction, and Willison reported about a 72% performance improvement on his DGX Spark after enabling MTP through llama.cpp compared with his default LM Studio configuration. Even then, his normal LM Studio runs were producing only around 15 to 30 tokens per second — far below the responsiveness of many hosted models. That tension is precisely why Qwen3.8-27B matters more than another leaderboard position. What enterprises should take away from Qwen3.8-27B For enterprises, the relevant comparison is not simply whether a 27B model “beats” Claude or GPT on a benchmark. It is whether a model small enough to run inside an organization’s own infrastructure can now perform enough coding, document analysis, vision and agent work to replace API calls for meaningful classes of tasks. That proposition changes privacy, deployment and cost calculations. Apache 2.0 weights can be inspected, modified and hosted behind a company’s own controls, while Alibaba already documents compatibility with serving frameworks including vLLM, SGLang and TokenSpeed. Alibaba says a managed Qwen Cloud version with a 1-million-token default context and built-in tools is coming later. The small size and accessible hardware requirements mean that enterprises, indie developers, and even curious consumers can easily deploy the model locally without worrying about their data leaving their machine — ensuring greater privacy, information security, governance and control. There is a broader reason power users are paying attention. Hugging Face data reported by Business Insider this week shows that actual model usage skews dramatically toward smaller models even as enormous frontier releases dominate headlines; models above 70 billion parameters accounted for only a small share of 2026 downloads. Alibaba’s strategy of publishing Qwen models across multiple practical size classes has helped make the family a recurring part of developers’ local deployment workflows. Qwen3.8-27B pushes that logic further. Its benchmark scores still need more independent validation, its default reasoning behavior can be painfully inefficient, and no single leaderboard establishes frontier-model parity. But three days after release, developers are no longer reacting primarily to Alibaba’s benchmark table. They are reacting to the experience of putting a comparatively small file on hardware they control and watching it perform tasks that, not long ago, seemed to belong exclusively to the largest proprietary systems. For certain developers, AI power users—and yes, even enterprise deployments—that is the benchmark that matters most.

8/17/2026

Cursor began rolling out Origin, its own code hosting platform, to paid users on Monday morning. Roughly three and a half hours later, GitHub's status page lit up with what became a six-hour-and-forty-two-minute global degradation — error rates near 20% across pull requests, issues and the API, and near 50% on archive and raw file downloads, according to GitHub's incident log. Enterprise single sign-on went down with it: SAML, OIDC, SCIM provisioning and Team Sync all failed. So did Copilot. The developer internet did what the developer internet does. "You can now host your repos in Cursor Origin and deploy to Vercel via Cursor Origin which is itself hosted on Vercel," Vercel chief executive Guillermo Rauch posted on X. "And unlike GitHub, it's online 😁" Asked why he was smiling, Rauch replied: "trying to make light of the situation. We ourselves are stuck because of github rn!" Matt Palmer, who works at Cursor, quote-tweeted his own company's launch with the day's best line: "We were going to ship this earlier, but GitHub was down." A GitHub outage, in other words, delayed the launch of a GitHub competitor. Product launches get locked weeks in advance, and no evidence suggests Cursor timed this one. But the coincidence did the company an enormous favor, because it dramatized the argument Origin exists to make. For eighteen years, choosing where to host your team's source code has been the least interesting decision an engineering organization makes. Cursor is betting that AI agents have made it interesting again — and for technical decision makers, that is the real news here. Not a new product, but a new procurement question with a governance problem attached. Inside Origin: what Cursor's code hosting platform actually does Origin lives in a new Codebase tab inside Cursor. Teams name a codebase, which becomes part of its URL, then push to it over the command line. From there they get the machinery you would expect from a forge — the service layer that wraps Git and handles storage, permissions, checks and merges. Every repository comes with pull requests: timelines, commits, checks and files changed. Reviewers read the diff, leave comments and merge, without ever opening a browser tab. What Cursor built around that machinery is the part worth studying. Agents now operate in the same surface as the code and the pull requests they are modifying. "Your code, PRs, and agents are now in the same place," the changelog reads. A developer can ask questions about the file on screen, hand an agent a review comment and have it revise the pull request in place, or tell it to push a branch — all inside the editor where the code was written. Three integrations shipped on day one, and the choice of partners is telling. Vercel spins up a preview deployment for every pull request and ships to production on merge, available in public beta for Pro and Enterprise customers, its developer account said. Depot and Buildkite run continuous integration, and critically, both execute existing GitHub Actions workflows unchanged. Buildkite adds native pipelines on top. That compatibility layer is the whole strategy in miniature. Cursor is not asking teams to rewrite their build system, retrain their engineers or rip out their deployment pipeline. It is asking them to try a second window onto code they already have — which is a far easier request to approve. More partners are coming, the company said, and the ones it landed first are the ones that matter to a platform team evaluating whether Origin can carry real work. A forge without deployments and CI is a code viewer. A forge that runs your existing Actions workflows and ships previews to the CDN you already pay for is a candidate. Why letting GitHub stay the source of truth is Origin's smartest design choice Here is the decision enterprise buyers should study most closely, because it determines whether Origin survives a security review at all. Cursor does not ask you to leave GitHub. Connect a GitHub organization, pick repositories, and they appear alongside Origin-native ones. "Pushes keep going to GitHub, which stays the source of truth for anything started there," the changelog says. Access permissions mirror GitHub's existing read and write settings rather than establishing a parallel system. Pull request conversations sync in both directions — comment in Cursor and it posts to GitHub; reply or react on GitHub and it surfaces in Cursor "within seconds." This is a classic wedge, and a well-executed one. Rip-and-replace migration of source control ranks among the highest-risk projects an engineering organization can undertake. It touches continuous integration, compliance evidence, audit trails, branch protection rules, every integration in the toolchain and the muscle memory of every engineer on staff. Almost no chief technology officer approves that for a product in early beta. A read-mostly mirror that leaves GitHub authoritative approves itself. It costs nothing to try, breaks nothing if abandoned, and quietly relocates the place developers spend their working hours. If Cursor's review experience proves better — and Cursor spent real money to make sure it would — the source of truth eventually follows the attention. That money went to Graphite, the code review startup Cursor bought in December 2025 for what Axios reported was well above its $290 million Series B valuation. Graphite built stacked pull requests, the workflow that lets developers keep shipping dependent changes without waiting on approvals. Announcing the deal, Cursor wrote that "the boundary between where you write code and where you collaborate on it feels increasingly arbitrary," and promised "some more radical ideas we can't share just yet." Origin is the radical idea. Graphite co-founder Tomas Reimers unveiled it on stage at Cursor's inaugural Compile conference in June and leads its development. How AI agents turned code review into software's new bottleneck The case for an agent-native forge rests on a claim that is easy to state and, unusually for this market, well supported by evidence: writing code stopped being the constraint. Reviewing and integrating it became one. Google's 2025 DORA report, drawn from nearly 5,000 technology professionals, found that 90% of developers now use AI at work, spending a median of two hours a day with it, and more than 80% say it made them more productive. But AI adoption showed a positive relationship with software delivery throughput and a negative one with delivery stability. More output, more breakage. The report's authors describe AI as "an amplifier" that "magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones." Trust has not kept pace with volume. Stack Overflow's 2025 developer survey of 49,009 respondents across 177 countries found 84% using or planning to use AI tools, while trust in their accuracy fell to 33% from 43% a year earlier and distrust climbed to 46% from 31%. Two-thirds named "AI solutions that are almost right, but not quite" as their leading frustration. GitLab's ninth annual DevSecOps survey, of 3,266 practitioners polled by Harris, put numbers on the operational drag: 73% had hit problems with vibe-coded output, 70% said AI made compliance management harder, and only 37% would let AI handle daily tasks without human review. The volume climbs regardless. GitHub's Octoverse 2025 counted 180 million developers, 630 million repositories and 43.2 million pull requests merged per month, up 23% year over year. And RuntimeWire reported the internal figure that best explains Origin's existence: 35% of pull requests merged inside Cursor were opened by agents running autonomously in cloud virtual machines. A forge built for humans assumes a pull request represents human intent, opened by someone you can ask what they meant. Once a third of merged changes come from software, the queue stops being a conversation and becomes a scheduling problem. That is a real architectural argument, and it is the strongest thing Cursor has going for it. GitHub's reliability crisis handed Cursor an opening it did not have to earn The supply-side case for an alternative is simpler: GitHub has been unreliable, and its own executives have said so. An analysis by LeadDev counted 257 incidents between May 2025 and April 2026, 48 of them major — roughly one significant disruption per week. February was the worst month on record with 37. GitHub Actions alone accounted for 57 outages in twelve months. Chief technology officer Vlad Fedorov has said the platform "wasn't built for the scale it's now being asked to handle" and must design for 30 times today's load. In an April engineering post covered by InfoQ, the company acknowledged it "failed to meet its own reliability standards," citing rapid growth, tight architectural coupling and inadequate load shedding. Monday's outage was the seventh incident on GitHub's status page in fifteen days. The fatigue is audible. "GitHub really doesn't feel built for the agent era," one developer wrote on X as Origin went live. "It goes down way too often, but until now there haven't been many real alternatives." The defections started before Origin existed. The Zig programming language moved to Codeberg in November 2025, citing Actions failures among its reasons. In April, Mitchell Hashimoto announced that Ghostty — a terminal emulator with more than 52,000 stars — would leave too, pointing to near-daily outages that blocked reviews and CI for hours. And The Information reported in March that OpenAI, a company Microsoft holds a large stake in, began building its own GitHub alternative partly because outages left its engineers unable to commit for hours at a time, as Tom's Hardware relayed. Microsoft's structure has not helped. Thomas Dohmke resigned as GitHub chief executive in August 2025 and was never replaced; the unit's leadership was absorbed into Microsoft's CoreAI organization under executive vice president Jay Parikh. In a May report, The Information wrote that Parikh had warned deputies that coding tools from Cursor and Anthropic could eventually make GitHub obsolete. GitHub's own answer to the agent era, Agent HQ, lets customers orchestrate third-party agents from Anthropic, OpenAI, Google, Cognition and xAI inside GitHub — a coherent strategy that concedes the agent layer and keeps the substrate underneath. Origin attacks precisely that substrate. Now that SpaceX owns Cursor, who actually holds your source code? Cursor's rise has been extraordinary even by the standards of this cycle. Founded in 2022 by four MIT students, Anysphere raised $8 million from the OpenAI Startup Fund in October 2023, per TechCrunch, then $100 million at $2.5 billion, $900 million at $9.9 billion, and $2.3 billion at $29.3 billion last November. In May, Bloomberg reported annualized revenue of $3 billion and more than 3,000 customers paying at least $100,000 a year. Then, three days before Origin shipped, Bloomberg reported that SpaceX completed its $60 billion all-stock acquisition of Cursor — an agreement TechCrunch covered in June, days after SpaceX's record IPO and six months after it absorbed xAI. Cursor now operates inside a division called SpaceXAI. The vendor asking to hold your proprietary source code became, last Friday, a unit of a rocket company with its own frontier-model division and a founder not known for institutional caution. Jason Andersen of Moor Insights & Strategy raised the model-routing question to Tech Times in June, before the deal closed: "xAI's models and treatment of guardrails are very different than what Cursor has stood for." That piece framed the question a chief information security officer now has to answer. When one company controls the editor where agents write code, the host where that code lives and the model those agents run on, what governs what it does with the code? Cursor has not published an answer. RuntimeWire noted before launch that Origin's pricing, security architecture, data-handling terms and migration tooling were all unpublished, and Monday's changelog adds none of them. It says only that Origin reaches "all paid plan users starting today, except enterprise orgs whose admins opt out." Opt-out, not opt-in — a sentence administrators should read twice. There is also a track record to weigh. In July, researchers at Mindgard disclosed that Cursor would execute a malicious git.exe planted in a Windows project's root the moment a user opened it, with no prompt — a repository-poisoning flaw they first reported in December 2025. The Hacker News reported that Cursor declined to patch it, calling the issue out of scope under a shared-responsibility model while conceding it had not "closed the loop with the researcher in a timely manner." No CVE was issued. The same flaw class turned up unpatched in GitHub Copilot CLI, Google's Gemini CLI and OpenAI's Codex — but a vulnerability the vendor declined to fix makes an awkward footnote for a product whose pitch is basically “let us hold your repositories.” What engineering leaders should settle before they let Origin into the toolchain Origin is a beta, not a migration, and treated as one it is worth evaluating. The sync mode gives platform teams a low-risk way to measure whether an agent-native review surface shortens cycle time, without touching a single branch protection rule. But three things deserve resolution before anything authoritative moves. The first is the default. Origin switches on for paid users unless an enterprise administrator opts out, which means an organization that has not made an affirmative decision about whether proprietary code may be mirrored to a new host has effectively had that decision made for it. Confirming your posture is a Monday-morning task, not a next-quarter one. The second is the paperwork. Retention, residency, training use, subprocessors and what changes now that Cursor reports into SpaceX are all unpublished, and a product page is not a contract. Until those terms exist in writing, the defensible position is to treat Origin as a convenience layer over GitHub rather than a system of record — which is, conveniently, exactly what its architecture already is. The third is the exit. Origin's Actions compatibility and its GitHub-as-source-of-truth design are the properties that make it safe to adopt. They are also the ones most likely to erode as Cursor's incentives shift toward owning the substrate rather than borrowing it. Ask what egress looks like now, while the mirror is still a mirror. None of which makes Cursor's argument wrong. GitHub earned its incumbency by being boring, dependable infrastructure, and it has spent eighteen months being neither while a third of the code arriving at its front door stopped being written by people. Origin is a serious answer to a real problem, built by a team that bought the right company to build it. But GitHub's failure and Cursor's are different in kind, and enterprises should not confuse them. Monday's outage resolved at 20:22 UTC. Availability is an engineering problem, and engineering problems close. The question of who holds your source code, what they may do with it and who they ultimately answer to carries no such timestamp — and on that one, the company that spent Monday selling trust has yet to publish its terms.

8/17/2026

A retrieval-augmented generation (RAG) system is built to answer strictly from the documents it retrieves. But when engineers optimize these AI pipelines end-to-end, the reader module can learn a shortcut: instead of relying on retrieved evidence, it starts answering from its own internal memory — while the system's overall accuracy keeps climbing. This is the hidden challenge of "role drift," a failure mode in compound AI systems where individual modules learn to bypass their assigned tasks even as end-to-end performance improves. To address this, researchers at MIT and Harvard introduce Role Anchor, a technique that forces modules to stay in their lanes during training. When applied, the technique mitigates role drift. For example, it forces the RAG reader to rely on retrieved evidence instead of answering based on its internal knowledge. The primary takeaway for practitioners is that end-to-end accuracy alone can overstate how much a compound AI system has genuinely learned. Engineers must evaluate individual components and ensure they work as intended. Role Anchor serves as both a guardrail and a diagnostic tool when optimizing multi-step LLM pipelines. It can be essential for real-world AI applications that require a strict division of labor between modules. Why terminal accuracy hides the problem Compound LLM systems divide complex tasks among specialized modules. For example, a system designed for multi-hop reasoning might split a task between a "Decomposer" and a "Solver.” The Decomposer breaks a large problem down into manageable sub-tasks, while the Solver computes the answers to those sub-questions. This division of labor allows AI engineers to delegate execution to smaller, cheaper models, and makes it possible to process sub-tasks in parallel where possible. To improve the performance of AI pipelines, engineers typically optimize them using end-to-end reinforcement learning (RL) guided by a single "terminal reward.” This means the system is evaluated on whether or not the final answer is correct (the researchers call it “terminal accuracy”). When this terminal accuracy goes up, the system is considered to be learning and working as intended. However, terminal accuracy does not verify whether the modules properly executed the tasks they were assigned. As Xiaoyang Cao, co-author of the paper, told VentureBeat, "Terminal accuracy reduces the behavior of an entire multi-part AI system to a single number. It shows whether the final answer is correct, but says little about which components contributed or whether they followed their assigned roles." This blind spot leads to role drift, a failure mode where a module's behavior diverges from its assigned role during optimization, even though the system's terminal accuracy continues to improve.  "For engineering teams, the practical risk is that they can deploy a pipeline that passes every end-to-end evaluation even though its intended division of labor has silently broken down," Cao said. Because the reward system only scores the final answer, it fails to detect or penalize the module for going rogue. Consider how this happens in the Decomposer-Solver pipeline. The Decomposer's assigned role is to write abstract sub-questions without solving the task, leaving the reasoning to the Solver. Under end-to-end RL, the Decomposer quickly learns that the weaker Solver is prone to errors on abstract tasks. To maximize the reward, the Decomposer begins leaking or planting answers into the sub-questions it sends to the Solver. The Solver ends up parroting the answer the Decomposer fed it. Terminal accuracy goes up, but the intended architecture is compromised. But if the system is getting the right answers and accuracy is going up, why should we care if a module drifts from its role? Real-world deployment requires much more than just a correct final answer on a training dataset. The implicit roles assigned to these modules ensure scalability, reliability, and auditability. Consider what happens when role drift takes over: Loss of efficiency and auditability: In the reasoning example, role drift causes the Decomposer to do all the heavy lifting instead of planning and delegating. "Once the decomposer starts putting answers directly into its sub-questions, the solvers are reduced to copying those answers," Cao said. "You are still paying to run [different modules], but they are no longer doing independent work." The workload can no longer be parallelized across multiple Solvers, it cannot be delegated to cheaper models to save compute, and downstream human stakeholders can no longer audit the system's logic step-by-step to verify how it arrived at the answer. Fragility in dynamic environments: Consider a RAG system, in which a Reader model is tasked to answer questions strictly using external retrieved documents. If the Reader drifts and learns to rely on its own internal parametric memory instead (because its memory happens to be accurate during training), the system becomes brittle. When the enterprise updates its database with new information, or a user asks a question about a novel topic outside the model's pretraining, the system will fail because it abandoned the grounding mechanism it was built to use. How Role Anchor measures a role — and enforces it "Training only for the final outcome rewards a system for producing the right answer, regardless of how it gets there," Cao said. To counter this, Role Anchor serves as a lightweight regularization technique that makes role instructions part of the training objective. It compares how the component behaves with and without those instructions and discourages training from weakening their effect.  At a high level, it ensures the module continues to respect the steering influence of its original role prompt throughout the reinforcement learning optimization process, making role drift both measurable and controllable. A key insight of Role Anchor is that a role’s effect can be measured by comparing how a model behaves with and without the role prompt. The system evaluates two different prompts for each module: The specialized, instruction-heavy role prompt (e.g., "You are a careful Reader. Use the retrieved passages to answer the user’s questions..."). The neutral prompt (e.g., "Answer the user's question..."). For any given input, the model outputs a probability distribution for the next token. When run under the role prompt, it will favor certain tokens. When run under the neutral prompt, it behaves like a generic assistant. The difference between these two probability distributions is the "role utility." This utility measures the ”nudge,” or the direction and strength with which the role prompt shifts the LLM’s default predictions. If a token is highly aligned with the assigned role, the role prompt boosts its likelihood compared to the neutral baseline (or “nudges” the model toward that token). Before starting RL training, Role Anchor keeps a frozen copy of the model as reference and measures the role prompt's original nudge on this reference model. This pre-RL nudge serves as the ground truth of the designer's intent, acting as a proxy for how the role prompt is supposed to steer the model. During RL training, as the active model’s weights are updated, Role Anchor regularly calculates the current nudge and compares it to the reference nudge. If the current nudge starts to fade or deviate from the reference, Role Anchor applies a penalty to the model to prevent role drift. To see this practically, consider the RAG system evaluated by the researchers. In this pipeline, the Reader module is explicitly instructed to answer user questions based only on retrieved documents, rather than relying on its internal knowledge. During unconstrained, outcome-only RL, the reader learns that the upstream retriever is sometimes noisy. To maximize accuracy on the training set, it starts ignoring the retrieved passages and answering from memory. Consequently, the gap between its behavior under the role prompt and the neutral prompt shrinks to the point that the reader starts behaving identically under both, ignoring the grounding instructions. In contrast, Role Anchor detects when the reader’s nudge deviates from the reference nudge. It applies a penalty, redirecting the model’s parameters away from this memory-based shortcut. This forces the reader to find role-compliant ways to improve, such as learning how to extract answers from the retrieved passages more robustly or avoiding using its internal knowledge when the retrieved passages are faulty. The numbers: how much of the accuracy gain was real To test the efficacy of Role Anchor, researchers evaluated it on the RAG and Decomposer-Solver (DEC) pipelines. The experiments compared systems trained with standard outcome-only reinforcement learning (no anchor) against systems trained with Role Anchor. Under outcome-only RL, the RAG system's terminal accuracy rose, but its internal integrity collapsed. The researchers measured "Evidence-Following Accuracy," a probe testing if the model changes its answer when the retrieved text is deliberately swapped to state the opposite. This metric plummeted from 0.86 to 0.54 (just above random chance), meaning the model learned to ignore retrieved passages and rely on its pre-trained parametric memory instead. In one test, researchers deliberately changed a piece of information in a retrieved document to contradict the model’s internal knowledge. The unanchored model did not update the response because it wasn’t using the external document. When Role Anchor was applied, the Reader’s Evidence-Following Accuracy remained at 0.869, proving it relied strictly on the retrieved text. When researchers fed the anchored model random passages that were unrelated to the input prompt, its accuracy correctly dropped because it refused to use its internal knowledge. The unanchored model scored higher on random passages because it was guessing from memory. The Decomposer (DEC) pipeline showed an even more dramatic failure mode. Under outcome-only RL, terminal accuracy shot up, but the "insertion rate" (i.e., the frequency at which the Decomposer leaked the answer into the sub-questions it sent to the Solver) surged from 0.143 to 0.596. In the RAG pipeline, preserving the intended role cost the system a very modest accuracy drop (-0.067). The Reader still learned to be better at extracting answers, but it did so legitimately rather than by cheating with its internal memory. This means it is more reliable on real-world tasks with novel knowledge it has not seen during training. In the DEC pipeline, unanchored RL improved accuracy by 0.310 above the base model, while Role Anchor only showed a 0.057 improvement. When diagnosed, it turned out that the underlying issue was that the Solver model was too small and couldn’t learn the problem-solving part. This forced the Decomposer model to cheat and provide the answer to boost the terminal accuracy. This meant 86% of the unanchored improvement was fake, and the system had simply learned to exploit a shortcut instead of learning how to reason or decompose problems better. However, this tradeoff is not a universal rule. In some cases, eliminating shortcuts can actually boost overall performance. "Role Anchor… does not necessarily reduce final accuracy," Cao said. "In a coding pipeline we recently tested, the model had learned to manipulate its own test executor during reinforcement learning training. Adding Role Anchor completely eliminated that shortcut while slightly improving correctness on the final tests used to judge the code." What it takes to add Role Anchor to an existing pipeline For engineering teams looking to apply this technique, "Role Anchor can be added to an existing reinforcement learning fine-tuning process as an extra training objective for each component that a team wants to anchor," Cao said. The main pipeline and deployment setup remain entirely unchanged. To implement it, engineers need three specific items for each anchored component: its original role instructions, a matched neutral version with the role information removed, and a saved copy of the model from before reinforcement learning fine-tuning. Importantly, there is no latency penalty at inference time. "Role Anchor runs only while the model is being trained, so it does not slow down the deployed system," Cao said. He noted that their current implementation takes roughly 20 percent longer during training due to additional calculations, though there is likely room to optimize and reduce that overhead. The research code, training configurations, and selected model weights will be released publicly in the near future. Deciding when to use Role Anchor is a case-by-case decision based on whether final accuracy captures everything that matters. Cao points to a regulated legal RAG system as a prime candidate. "The component producing the answer may need to follow retrieved evidence, stay grounded in an approved set of documents, and produce answers that can be traced back to their sources," he said. "Final accuracy alone cannot verify those properties, so the behavior of that component needs to be measured and enforced directly." As enterprise AI evolves toward more complex compound pipelines, role enforcement will become harder, and relying on prompts alone will prove unreliable. "At larger scales, role specifications will need to be enforced through both training and system design," Cao said. "Methods such as Role Anchor can help preserve intended behavior during training, while clear system boundaries, limited tool permissions, and monitoring during use can provide additional safeguards."

8/17/2026

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. How agents get context determines whether they're wrong 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." Buying shifted to access control. Grading didn't follow. 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. The companies fixing this are the ones reporting it worst 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. What this means for enterprises 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.

8/17/2026

Enterprise AI has a new infrastructure problem: companies are accumulating agents faster than they are developing systems to govern them. Gartner estimates that the average global Fortune 500 company will have more than 150,000 AI agents in use by 2028, up from fewer than 15 in 2025. Yet only 13% of organizations believe they currently have the right AI agent governance in place, according to the research firm. That widening gap is creating a market for infrastructure that sits above individual models and agents — handling execution, permissions, observability, memory, access to enterprise systems and lifecycle management without forcing developers to reconstruct those services for every new agent. xpander.ai, a startup founded by three former AWS principal engineers, is the latest company trying to own that layer. The company is making its enterprise AI agent platform generally available today, positioning it as a vendor-neutral control plane for building, running and governing agents across different models, agent frameworks and infrastructure environments. In an exclusive interview with VentureBeat, xpander.ai CEO and co-founder David Twizer said the company increasingly hears three problems from enterprise customers: agents running locally without centralized governance, agent workflows remaining isolated to individual users, and infrastructure becoming tied to a single AI provider. “The third issue is the most critical part: it’s being locked into one vendor,” Twizer told VentureBeat. “Everything that you do is actually owned by the company that you chose to work with — their tools, their roadmap, their political view of how agents should react to everything that you do.” The caveat is that xpander’s vendor neutrality does not eliminate dependency; it moves the dependency up the stack. Enterprises can swap models, frameworks and infrastructure underneath xpander, but xpander’s proprietary Universal Harness and control plane become the layer coordinating execution, governance, identity, memory and auditability. That could create a new form of lock-in if those configurations and operational state are difficult to migrate to another control plane. xpander’s public documentation does not yet explain how portable that layer is if a customer terminates its enterprise license. The company is also announcing a $7.5 million seed round led by Pico Venture Partners, with participation from Emerge Ventures, Samsung Next and SeedIL. But xpander is entering a market that has evolved considerably beyond a simple divide between proprietary hyperscaler platforms and neutral alternatives. The battle is shifting above the model Model portability is becoming increasingly common in agent infrastructure. LangChain's LangSmith Deployment, for example, provides infrastructure for deploying and governing production agents. Enterprises can run its control plane and agent servers entirely inside their own Kubernetes infrastructure, including for air-gapped and data-residency-sensitive environments. LangChain also offers hybrid deployments in which the customer operates agent servers while LangChain manages the control plane. CrewAI is moving in much the same direction. Its enterprise offering includes centralized governance, SSO, role-based access controls, workload identity and policies, while supporting deployment in CrewAI's cloud, a customer's VPC or customer-owned infrastructure. CrewAI says its platform can work across models and clouds and lets customers retain and modify the code generated for their agents. Temporal approaches the problem from another direction. Rather than offering an end-to-end agent management environment, it provides durable execution for long-running AI workflows, including crash recovery, retries, human approvals and state that can persist through failures. Its AI platform can orchestrate workflows across different models, tools and systems. Meanwhile, the model and cloud vendors themselves are expanding upward into this infrastructure layer. OpenAI's Frontier platform provides shared enterprise context, permissions, agent execution and management, while Google's Gemini Enterprise Agent Platform combines managed runtime infrastructure with agent identity, centralized governance, memory, tracing and policy enforcement around agent-to-agent and agent-to-tool interactions. In other words, xpander's differentiator cannot simply be that enterprises can run agents outside one model provider's cloud. Several competitors already offer versions of that flexibility. Its bigger bet is that enterprises will want a framework-independent control plane sitting above an increasingly heterogeneous collection of models, agent frameworks and employee-facing AI interfaces. Twizer's argument draws partly on his seven years at AWS, where he watched enterprises wrestle with a previous generation of infrastructure lock-in. “Our strategy was to bring the great thing called cloud computing and then try to create solutions that are serverless and, by definition, create vendor lock-in,” Twizer told VentureBeat. But, he said, enterprises ultimately demanded the ability to move workloads among providers. “I think AI is no different,” he said. “Multi-cloud, multi-vendor is a must-have strategy.” A runtime intended to survive model churn At the center of xpander's platform is what it calls a Universal Harness — a model-, framework- and cloud-agnostic runtime for executing agents as portable enterprise workloads. Companies can use xpander's hosted environment or, under its enterprise offering, self-deploy on Kubernetes or on-premises infrastructure. The company also explicitly lists AWS, Google Cloud, Microsoft Azure, private VPCs and fully air-gapped on-premises environments as supported deployment targets. The framework claim is similarly broad: xpander says customers can bring agents built with frameworks including LangChain, Strands and Agno, as well as their existing prompts, rules and skills. It supports proprietary, open-weight and customer fine-tuned models. For developers, xpander exposes three main integration routes: a language-agnostic REST API for control-plane operations, a Python SDK for building agents and workflows, and Model Context Protocol support that exposes agents and tools to MCP clients such as Claude Desktop and Cursor. The REST interface includes operations for managing and invoking agents, tasks and knowledge bases, while the SDK adds event handling and agent lifecycle abstractions. “Think like a Kubernetes environment that runs inside your own premises, your private cloud or our xpander cloud,” Twizer told VentureBeat. “The harness that is agnostic can run any agent of any vendor.” Twizer said the goal is eventually to make model selection more analogous to choosing compute underneath an application than committing an organization to an entire software ecosystem. “You can go from Claude to ChatGPT to Kimi and to your own fine-tuned models,” he said. “All of them will be used in the same way that you use CPUs. You don’t really care who makes them. You just want your application running.” That architecture is intended to let the underlying workloads change while the orchestration and operational layer remains relatively stable. The distinction could become more important as enterprises use more than one AI supplier. OpenAI itself says enterprise AI is shifting from assistance toward delegated work performed by agents, with its latest enterprise data showing rapidly growing agentic usage across functions including legal, sales, recruiting and marketing. At the same time, Google is adding centralized agent governance, identity and gateway controls specifically to manage interactions between agents and tools at scale. Those investments from much larger vendors reinforce xpander's basic premise: managing the model is increasingly only one part of putting agents into production. What 'governance' means in practice Twizer argues that locally running agents make that operational problem particularly acute. “You install Claude or ChatGPT or Codex or any other AI system that runs on the employee laptop, and you get a black box,” he told VentureBeat. “Nothing is governed, nothing is audited, and nothing is controlled.” His concern is not simply that an agent can access local resources, but that AI products have rapidly moved from generating text to taking actions without enterprises necessarily building equivalent governance infrastructure around them. “It happened overnight that the shift from, ‘Here is the chatbot that helps me write an email,’ became, ‘It is an AI agent that can control my machine and perform API calls,’” Twizer said. xpander's documentation provides a more concrete definition of what the company means by moving that activity into a governed environment. The control plane can define who is allowed to run an agent, which resources the agent can reach and which actions require human approval. xpander says agents receive named identities and actions can be traced back to the human who invoked them. Tool calls, runs, traces, approvals and failures are logged, with spending attributable at the task level. One particularly relevant architectural detail for security teams is credential handling. xpander says credentials are injected from a vault when a tool call executes, rather than being exposed directly to the model. The company says it is SOC 2 Type II certified and GDPR compliant. Its enterprise tier also includes SSO and OIDC, a private model gateway and sub-organizations with per-team usage attribution. Where xpander is trying to separate itself from products such as LangSmith and CrewAI is in treating the underlying agent framework itself as another replaceable component rather than making its own framework the primary development environment. The company says its runtime can operate xpander-native agents alongside custom agents built with other frameworks. That broader framework neutrality is a company claim and will need to prove itself in production; the overlap among these platforms is already substantial. The cost of building the agent layer yourself For enterprises that want centralized control without adopting another vendor's infrastructure, the alternative is increasingly to assemble many of these components themselves. Twizer argues that this is where the hidden cost of production agents emerges. Accessing a foundation model is comparatively straightforward; recreating the operational infrastructure surrounding a sophisticated managed agent is not. “If you want to do something like the amazing [Anthropic] Claude Code in a way that is governed and secure, you need to build the entire harness,” Twizer told VentureBeat. “You need to build the sandbox and the authentication and the human in the loop and the storage and the session management and the memory layer.” “It’s like investing two years of infrastructure just to run that agent in a secure way,” he added. The company's documentation says its harness handles long-horizon and multi-tool tasks, sandboxed code execution, persistent memory and recovery when tasks fail or drift. That is important context for Twizer's argument: xpander isn't merely offering a gateway that swaps one model API for another; it is attempting to package many of the runtime services enterprises otherwise have to operate alongside those APIs. Twizer said xpander has heard from government organizations and financial institutions using its technology in production that this infrastructure burden was preventing them from deploying agents in a controlled way. The company's website separately displays logos for organizations including Lenovo, Intel, Workday, Siemens, Nvidia, Intuit, SAP, PagerDuty, Mozilla and Salesforce under the label “Used by teams at.” The company's answer is not that enterprises should abandon products from Anthropic, OpenAI or other AI providers. Twizer instead argues that companies should retain those models while moving permissions, monitoring and execution into an infrastructure layer they control. “It’s not, ‘Don’t use Claude,’” he said. “It’s actually, ‘Use Claude, but in a way that you watch it, that you secure it, that you monitor it,’” with controls over authorized skills and who can access particular resources. Making agents organizational rather than personal xpander is also adding a collaboration layer it calls Multiplayer AI. The premise is that enterprise agents increasingly need to outlive a single user's chat session. A workflow might involve an agent collecting data, another system taking an action, an employee approving it and a different team resuming the process hours or days later. Twizer argues that locally deployed assistants have another disadvantage: the expertise employees accumulate through their agents — prompts, skills, workflows and context — tends to stay with those individuals. “You’re making the AI agents better, and you’re not making the company better,” he told VentureBeat. “All the data, all the prompts, all the workflows, all the skills that you are now investing in that ecosystem are being locked inside that vendor, and it’s very hard to share it with other colleagues.” More complex enterprise work also rarely maps neatly onto a single chat session. “Work is not single player. It’s multiplayer,” Twizer said. “It’s happening over the period of multiple days, even weeks. Workflows that are significant to enterprises are not chatbots.” xpander's shared conversations are designed to keep those interactions in persistent, permission-scoped threads. An agent can be published once for use across an organization, while employees can interact with agents through Slack, Teams, ChatGPT, Claude and xpander's own interface. The company's documentation says downstream actions can identify as the human who invoked the agent through end-to-end authentication using OIDC — a potentially important distinction for organizations that need to preserve user-level identity and authorization as work moves through an agent. The requirement for persistent execution is not unique to xpander. Temporal has made long-running, failure-resistant workflows the core of its AI pitch, while LangSmith supports persistent agent deployment and production observability. What xpander is attempting to combine is that runtime infrastructure with enterprise collaboration and governance into a single, portable, flexible, vendor-neutral control plane. Omni tests the harness thesis The company is also making Omni, its prebuilt agent, generally available. Calling Omni simply a general-purpose agent understates what xpander is now selling. Its documentation describes Omni as an AI forward-deployed engineer that turns a requested business outcome into what the company calls an “Agentic Application”: a backend agent coupled with a frontend experience that can include chat, interactive UI components, reports, dashboards and visualizations. A user can describe the desired outcome, after which Omni is designed to help construct the application, connect its model, skills, tools and data, execute work as tracked tasks, and maintain files and reusable context in an Agent Workspace. The resulting application can then be shared with teammates. For example, xpander's documentation shows a user asking Omni to build a Redshift Analyzer. Omni is intended to gather the requirements, design the interface, construct the backend agent, attach appropriate connectors and tools, and generate the first live application surface. The documentation also lists Slack, WhatsApp, Telegram and email as Omni channels, while xpander's broader platform materials list Teams, Claude, ChatGPT, API, webhook, CLI and MCP among the ways work can reach agents. Because the company's materials describe slightly different channel sets for Omni and the broader platform, enterprises should verify support for their particular interface and deployment configuration. Omni can also function alongside desktop AI products rather than replacing them. Twizer said employees can continue using their preferred desktop agents while Omni acts as a skill exposing only enterprise-approved data and connectors. When background execution is needed, Omni can create a centrally controlled agent to perform the work. xpander says Omni scored 90.9% on the GAIA benchmark, including strong performance on its most difficult tasks. The result is company-reported and should be viewed as evidence for xpander's broader thesis rather than independent validation of the platform. Twizer said the company deliberately tested the harness with a mixture of models rather than optimizing around a single proprietary system. “We took Opus, we took Sonnet, we took Kimi, we took GPT, and on that benchmark we got a 90.9% score,” he told VentureBeat. For Twizer, the result supports an argument that agent performance increasingly depends on the infrastructure surrounding the foundation model. “It just proves that the value is in the harness layer and not in the model layer,” he said. “The value is in: How do you handle long-running tasks? How do you handle tool calling? How do you do sandboxing? How do you focus? How do you make the agents focused on the task?” The benchmark results are publicly available, allowing others to examine the company's methodology, but the broader conclusion remains xpander's interpretation of its own results. That thesis is increasingly shared across the industry. The disagreement is over who should control that layer. OpenAI and Google are turning it into part of broader AI platforms. LangChain and CrewAI are extending their development ecosystems into enterprise runtimes. Temporal is attacking the execution problem as infrastructure. xpander is betting enterprises will instead want that control plane to remain independent of all three choices: model, cloud and agent framework. The company now has to demonstrate that the extra abstraction is valuable enough to justify another platform in an enterprise AI stack that is already becoming crowded. Pricing and Availability xpander's platform and Omni are generally available now, with two substantially different commercial models for teams using xpander's hosted service and enterprises running the platform on their own infrastructure. The self-service Team offering has no seat charge and is priced in credits based on agent activity. xpander defines one credit as one cent, meaning $100 buys 10,000 credits. Each event or message that wakes an agent costs one credit for the entire turn, regardless of how long the turn runs, and each tool or API call costs another credit. Model tokens are billed separately in credits at configured rates for the selected model. That makes the cost structure more granular than Twizer's description of paying for agent “output” might suggest. Long-running execution itself does not appear to create a duration-based charge under the published pricing, but a workflow can accumulate costs through repeated invocations, tool calls and model-token consumption. New accounts receive 1,000 free credits rather than a time-limited free trial, and customers can sign up with a credit card. The Team tier permits unlimited agents, workflows and seats, according to xpander. Model usage can represent a significant portion of total cost, and the company publishes examples intended to make that expense calculable. Its pricing page lists different input and output token rates for individual models and says those model charges are incorporated into the credit system, eliminating a separate model-provider bill for hosted customers. Actual spending therefore depends heavily on the models selected, token volumes and number of tool calls. Enterprises that self-host get a different arrangement. xpander's Enterprise plan is an annual license starting at 50 agents and supports deployment on a customer's Kubernetes infrastructure or on-premises environment. It includes SSO and OIDC, sub-organizations with pooled credits and per-team usage reporting, private model-gateway connectivity, onboarding and Tier 1 support. Customers can also bring their own model API keys and use their own negotiated model-provider rates. xpander does not publish the dollar price of that annual enterprise license, so prospective customers cannot calculate the total cost of a private or air-gapped deployment from public information alone. The pricing materials also do not provide a public dollar figure for the 50-agent starting commitment. Those deployments require contacting xpander for custom pricing. “You pay only for the work that the agent is doing,” Twizer told VentureBeat of the hosted model. “No subscription fee, no seat fee, no builder seat, nothing. You just pay for the actual output of the agents.” For enterprise buyers, that distinction is important: xpander's no-seat-fee claim applies most straightforwardly to its usage-based hosted offering. Organizations that need to own the deployment environment are instead evaluating an undisclosed annual license, infrastructure costs and their own model-provider spend. That leaves xpander with a straightforward but increasingly contested pitch as enterprises confront agent sprawl: keep using whichever models, frameworks and interfaces employees find useful, but move the infrastructure controlling what those agents can do into a common layer the organization can govern. Whether enterprises ultimately want that layer from an independent startup, an agent framework company or the same hyperscalers and model providers xpander wants to abstract away is now becoming another battleground in the enterprise AI stack. How xpander compares with other agent infrastructure The overlap becomes clearer when the products are compared directly. Several rivals now support multiple model providers, customer-controlled infrastructure or both. The differences increasingly concern how much of the agent stack each platform attempts to own — and whether it provides an agent development framework, a neutral runtime, durable workflow infrastructure or a collection of managed cloud services. Solution Deployment Model / framework flexibility Enterprise and runtime features Public pricing xpander.ai Hosted service, plus an enterprise license for self-deployment on Kubernetes or on-premises infrastructure ; xpander also advertises private VPC and air-gapped deployments. xpander says its Universal Harness supports multiple models and outside frameworks including LangChain, Strands and Agno . Central permissions and approvals, per-user identity, audit trails, tool-call logging, credential injection, long-running tasks, shared “Multiplayer” workflows and Omni. The company says each action can be associated with the invoking human . Hosted service is usage based: 1 credit = $0.01, with 1 credit per agent wake and 1 per tool/API call, plus model-token charges . New accounts receive 1,000 credits and seats are unlimited. Enterprise is custom-priced, annual and starts at 50 agents . LangSmith Cloud, hybrid or fully self-hosted on Docker Compose or Kubernetes ; hybrid and self-hosted options require Enterprise. LangChain describes LangSmith as a framework-agnostic platform for observing, evaluating and deploying agents. Observability, evaluations and agent deployment; Enterprise adds SSO, ABAC/RBAC and self-hosted or hybrid deployment . Plus is $39 per seat per month, then pay-as-you-go . Enterprise is custom priced plus usage charges. CrewAI SaaS, customer VPC or customer-owned infrastructure . CrewAI centers on its own agents, crews and flows framework, but supports multiple LLM providers , including custom model integrations. Agent building and orchestration, long-running flows, memory, observability and human-in-the-loop controls. Enterprise adds SSO, RBAC, workload identity, PII redaction and policies . A free tier is available ; Enterprise pricing is custom and includes a 45-day onboarding program. Temporal Temporal Cloud or the self-hosted open-source Temporal Service . Application workers continue to run in the customer's environment when using Temporal Cloud. Not an agent framework or model gateway. Temporal is model-agnostic because it provides durable workflow execution underneath application and agent code rather than selecting the model or agent framework. Durable execution, persistent workflow state, retries, timers, signals and recovery — useful for agents that must survive failures or run for long periods. Cloud tiers add audit logging, roles and higher-tier SSO/SCIM. Temporal Cloud Essentials starts at $100/month with 1 million Actions, 1 GB active storage and 40 GB retained storage. Business starts at $500/month; Enterprise is custom. Additional Actions start at $50 per million before volume discounts. Amazon Bedrock AgentCore Fully managed AWS infrastructure rather than a customer-operated control plane. AgentCore Runtime explicitly supports agents built with outside frameworks and custom code , as well as foundation models inside or outside Amazon Bedrock . Managed runtime isolation and scaling plus optional identity, memory, gateway, browser, code interpreter, observability and evaluation services. The runtime supplies infrastructure while developers retain their own orchestration loop . Consumption based. Runtime currently lists $0.0895 per vCPU-hour and $0.00945 per GB-hour , with separate charges for services such as memory, gateway, web search and evaluations. The comparison complicates a simple vendor-neutrality pitch. AWS AgentCore, for example, supports models outside Bedrock and frameworks including LangGraph, CrewAI and Google's ADK, while LangSmith explicitly calls itself framework agnostic. CrewAI offers customer-controlled deployments and broad model choice. Temporal lets companies self-host the durable execution layer entirely, although it solves a narrower infrastructure problem rather than offering a complete agent control plane. That makes xpander's potential differentiation more specific. It is trying to combine framework and model portability with enterprise identity, governance, runtime infrastructure and an employee-facing collaboration layer, rather than competing only on the ability to swap models or deploy outside a vendor's SaaS environment. xpander also prices its hosted platform around individual agent wakes and tool calls rather than seats, although enterprises requiring self-hosting face an undisclosed annual license beginning at 50 agents.

8/17/2026

Presented by MongoDB Building 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-driven products is compounded by the fact that technology in these industries has tended to lag behind other sectors because regulation requires organizations to move carefully — and slowly. Now, many are also confronting data infrastructure modernization projects as they try to catch up with today’s demand for AI. Australian-founded AI Care Partner Heidi offers an example of successful modernization. Its flagship product, Heidi Scribe, now automates much of the administrative work that consumes clinicians’ days across more than 190 countries, supporting roughly 2.7 million patient interactions each week. That expansion rests on infrastructure decisions taken years before the company reached global scale, says Yu Liu, co-founder and chief technology officer at Heidi. “In most industries, an AI feature that is wrong two percent of the time registers as an inconvenience, while in healthcare that same error rate becomes a clinical safety issue,” says Liu. “The architecture has to be built around the assumption that every output may be scrutinised, audited, and relied upon in a patient’s care.” Why deploying production AI in healthcare is architecturally different For Heidi, data residency is a precondition rather than a feature. A clinician in Sydney, London, Tokyo, or Denver is operating under different regulatory regimes, including the Australian Privacy Principles, GDPR, APPI, and HIPAA, and their patients’ data has to live in-region. Heidi runs fully logically isolated production deployments across the world, so residency is enforced by architecture. Auditability also has to be built in from day one, because an organization needs to be able to answer what the model saw, what it produced, and what the clinician changed, for any session, months later, when called upon. “The blast radius of change must be engineered down,” Liu says. “In less regulated industries you can ship fast and fix forward, but in healthcare we invest heavily in making change safe by default, with continuous integration gates on risky change classes, canary releases, and treating even database schema and index changes as code that goes through review. Our speed is a product of that safety rather than something we achieve in spite of it.” Choosing a database to connect with AI workflows Heidi handles a diverse set of medical data collected from multiple sources, including forms, referrals, and clinicians’ notes, all of which had to be consolidated into one consistent format and one location to connect seamlessly with AI workflows. Rigid rows and columns would have been ill-suited to that workload. For Heidi, those requirements made a document database the natural choice.MongoDBgave the team the flexibility to accommodate rapidly changing AI data without constantly reshaping the underlying database. “The model is maybe 20% of the system, and the data architecture is what determines whether the other 80% holds up under real clinical load,” Liu says. An AI Scribe session isn’t a single piece of data. It’s a collection of transcripts, structured notes, templates, documents, patient context, EHR integration state, and dozens of other related artifacts that change from week to week. MongoDB lets a session’s data live together in shapes that match how clinicians actually work, and lets Heidi evolve those shapes without a migration freeze every time the product moves. "MongoDB Atlas stood out because it combined the power of the document model, which allows seamless scale, flexibility, and high performance, with built-in AI-ready features such as MongoDB Vector Search,” Liu says. “This means that Heidi does not need another bolt-on vector database to augment its existing platform.” With more than 130 cloud regions globally alongside on-premises and hybrid options, MongoDB Atlas is the most widely available, globally distributed database platform, and its unified query API lets developers build full-text search, real-time analytics, and event-driven experiences without complicating their architecture. "Heidi Scribe converts large volumes of medical documents into vector embeddings via LangChain in Atlas, enabling semantic search that connects transcribed medical terms directly to corresponding external knowledge," Liu adds. "Migrating to Atlas reduced latency on key APIs by nearly 33%." What a trustworthy clinical RAG system requires “Retrieval is a data architecture problem before it is an AI problem,” Liu says. "In consumer RAG, you retrieve from the open web and hope, whereas in healthcare what you retrieve from is the compliance surface." Heidi Evidence retrieves from licensed clinical knowledge bases, including partners like BMJ Best Practice, NICE CKS, and MIMS, and it is jurisdiction-aware, so a U.K. clinician gets U.K. guidance and an Australian clinician gets Australian formularies, because the right answer in one country can be the wrong answer in another. Heidi’s embeddings and vector indexes live in MongoDB Vector Search, inside the same regionally isolated deployments as the rest of its data, which means retrieval physically cannot cross a residency boundary, and they are not operating a separate vector database with its own security and compliance story. Citations are a hard contract rather than a prompt suggestion, because the model only ever sees retrieved chunks that are already bound to source records. Regional isolation enables global compliance and scale “Each region is a full, isolated production deployment with its own MongoDB Atlas clusters, its own compute, and its own key,” Liu says. “That is what lets us walk into a U.S. health system, an NHS trust, or an Australian hospital group and give a clean answer on residency, because it is enforced by infrastructure rather than promised by contract," he explains. "Running multiple isolated regions with a lean team only works because the database layer is managed and consistent. We are also multi-cloud, meaning a new region can stand up another deployment on rails we have already built." That architecture has been most visible in the U.S., where Beth Israel Lahey Health, one of New England’s largest health systems, rolled out Heidi’s AI scribe following a pilot finding 74% of clinicians reported reduced after-hours documentation (“pajama time”), and where non-profit system MaineGeneral Health selected Heidi as a strategic partner in its rural healthcare work. “Entering the U.S. market meant standing up another region on rails we had already built rather than re-engineering for HIPAA after the fact,” Liu says. Lessons learned and the roadmap ahead "Re-partitioning a large, hot, always-on collection is a serious engineering program, whereas choosing a shard key on day one is a design meeting," Liu says. "We are doing that work now in partnership with MongoDB, but the lesson for anyone building a data-heavy AI product is that horizontal scale for your fastest-growing data is a founding decision, just like residency." Heidi is now extending beyond the consult note to support the full clinical workflow, from pre-visit context to post-visit documents, referrals, and workflow automation. The company is also exploring how MongoDB, large language models, and its own tooling can power an agentic ecosystem for clinical workflows. “In healthcare AI, reliability engineering is trust engineering,” Liu says. “A clinician’s trust is lost just as fast by downtime, latency, or a data inconsistency as by a bad note, and some of our highest-leverage work is invisible, including canary releases with automatic rollback, CI gates on database changes, and cross-region consistency checks. Clinician trust is the product, and trust is architectural.” Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/16/2026

Most teams building retrieval augmented generation (RAG) systems for high stakes classification make the same architectural bet: Route every ambiguous case straight to the language model and trust the retrieved context to sort it out. This works fine in a demo. It falls apart the moment the system has to survive an audit, a regulator, or a compliance officer asking why a specific decision was made six months ago. I have spent the last year building RAG based classification systems in regulated enterprise settings, where the cost of a wrong answer is not a bad chatbot reply. A decision has to hold up to scrutiny long after the model produced it. This environment forces a different design philosophy than most AI engineering content assumes. Here is what changes when you cannot afford to be probabilistic about everything, and how a cascade architecture solves it. The invisible cost of an all LLM pipeline The appeal of routing everything through a large language model (LLM) is obvious: Fewer moving parts, faster iteration, the model handles unanticipated edge cases. The problem shows up later, in three places. First, auditability. "The model decided based on retrieved context" is not an acceptable answer. You need a decision path a human can reconstruct without rerunning inference and hoping for the same output. Second, cost at scale. If your system processes tens of thousands of cases a day and every one hits an LLM call with several retrieved documents in context, your inference bill and latency both scale with volume in a way that rule based logic does not. Third, and least discussed, model drift on the easy cases. LLMs are excellent at nuanced judgment calls. They are inconsistent, in ways that are hard to detect, on cases that should have a deterministic answer. A clear structured match against known criteria should never depend on a language model's mood. The cascade approach The fix: Stop treating the LLM as the front line and start treating it as the escalation path. In practice this means a three stage pipeline. Stage one is deterministic. Exact matches, structured field comparisons, and anything with a clear rule get resolved here with no model call at all. This stage should clear the majority of volume, often more than half depending on your data quality, and every decision is fully explainable because it is a lookup, not an inference. Stage two is where retrieval earns its keep. For cases that survive stage one — and I mean survive as in they were not clearly resolved — you build a retrieval layer that pulls the specific evidence relevant to the ambiguity: Prior reviewer decisions on similar cases, contextual documents that explain an apparent conflict, or historical precedent that clarifies an edge case. The retrieval step matters more than the generation step here. If you retrieve the wrong context, even the best language model in the world will produce a confident, well reasoned, wrong answer. Stage three is the LLM call, and it should only see the residue that stages one and two could not resolve. This is the part people skip when they design their first version, and it is the single biggest lever for both cost and quality. In one system I worked on, routing only the genuinely ambiguous 10 to 15% of cases to the LLM cut inference cost by roughly 6X compared to an all LLM baseline, while improving consistency on the deterministic majority to effectively perfect. Designing the prompt for asymmetric risk Once a case reaches the LLM stage, most teams default to a neutral prompt: "Assess whether this case should be approved or flagged." That framing is wrong for high stakes classification because the cost of the two error types is not symmetric. Missing something that genuinely needed attention can mean real harm downstream. Incorrectly flagging something that was fine costs a reviewer's time and a delay. Those two outcomes are rarely equally bad, yet a neutral prompt asks the model to treat them as if they were. An asymmetric risk prompt makes that tradeoff explicit to the model rather than letting it guess at your risk tolerance. Concretely, this means instructing the model to treat uncertainty as a reason to escalate rather than clear, providing calibrated examples of both error types with their consequences spelled out, and asking for a confidence score alongside the classification rather than a binary answer. The confidence score becomes your second cascade point: Anything below a certain threshold goes to a human reviewer instead of being auto resolved, no matter what the model's classification says. This sounds like a small prompt engineering detail. In practice it is the difference between a system that reduces reviewer workload and one that quietly increases risk while looking like it is working. Evaluating a system like this properly Standard RAG evaluation metrics were not built with this use case in mind, and using them without adaptation will give you a false sense of confidence. A few adjustments that matter. Retrieval quality needs to be measured separately from final classification accuracy. A system can have excellent retrieval ranking scores and still make bad final decisions if the generation step misweights the evidence. Track them independently. Your evaluation set needs deliberate oversampling of the cases that reach stage three, since that is where your system's judgment actually gets tested. If your eval set mirrors your production distribution, it will be dominated by the deterministic cases your cascade already handles well, and you will be blind to exactly the failures that matter most. LLM as judge evaluation works for this domain but only if the judge prompt encodes the same asymmetric risk framing as your production prompt. A judge that treats both error types equally will systematically favor the wrong tradeoff when you are tuning your system. Finally, build a feedback loop from confirmed outcomes back into your retrieval corpus. When a human reviewer overturns a model decision, that case and its correct resolution should become retrievable context for future similar cases. Without this, your system's handling of ambiguous cases never improves, it just keeps making the same category of mistake at the same rate. The broader lesson The instinct to reach for the most capable model for every decision is understandable, but in domains where wrong answers have real consequences, the more valuable engineering work is deciding what should never touch the model at all. Cascade architecture is not a workaround for LLM limitations. It is what a mature RAG system looks like once you have actually had to defend its decisions to someone whose job is to find the flaw in your logic. If you are building AI systems for any regulated or high stakes domain, the question worth asking before you write a single prompt is not "How do I get the model to handle this well." It is "Which parts of this decision should never have been the model's job in the first place." Vineet Vijay is a Lead AI and machine learning engineer.

8/16/2026

DeepSeek's V4 Flash has topped model leaderboards and been hailed by developers as a "total monster" since its rollout. But in real-world testing, it completed just 53.8% of a batch of complex agent tasks. Composio ran the model through eight different agent harnesses, including Claude Code, Codex, and OpenCode, on 30 deliberately difficult, multi-step tasks spanning live tools like Gmail, GitHub, Slack, and Google Sheets. Of 240 total runs, 129 passed — and only six of the 30 workflows were completed successfully by every harness tested. The gap illustrates why orchestration, not raw model capability, may decide whether the model succeeds in enterprise settings: the same model produced substantially different results depending on the harness, tool configuration, caching behavior, retries, and provider stack it ran on. DeepSeek said it will be hiking the prices for V4 Flash and Pro, models that have quickly become favorites among developers building coding assistants and agents. While it seems the move might undercut its very appeal — strikingly capable models at ultra-low pricing that frontier providers simply can't match — it also moves the story beyond the now-clichéd "cheap Chinese model" narrative, as early use cases emerge and enterprises figure out where different models fit into their tech stacks and what workflows they should be aimed at. "Insane" adoption numbers as DeepSeek flips the cost structure DeepSeek rolled out V4 Flash to public beta July 31, and made V4 Pro generally available on August 13. The 284-billion-parameter Flash is built for volume and speed, the 1.6 trillion-parameter Pro for more complex workflows. Both models have flexible reasoning capabilities (low, high, max) and ‘thinking modes’ applying chain-of-thought (CoT) reasoning to improve answer accuracy. Users were immediately impressed by Flash’s capabilities. It has dominated OpenRouter's usage leaderboard since its rollout, currently the most-used model on the platform by weekly token volume. “The adoption numbers of the initial DeepSeek V4 Flash were insane,” ML researcher Nathan Lambert posted to X, adding that the new version "scored the same as GLM 5.2," making it a "total monster" that will be used extensively. DeepSeek switching the cost model adds an interesting dimension. V4 API rates are going up by as much as 1,100% depending on the model, token type and time of use. The new pricing structure: Flash will be 22 cents per million input tokens and 66 cents per million output tokens off-peak; and 44 cents per million input tokens and $1.32 per million output tokens at peak. This represents a 57% to 371% increase. Pro will be 66 cents per million input tokens and $1.98 per million output tokens off-peak; and $1.32 per million input tokens and $3.96 per million output tokens at peak. This shows a 51% to 355% jump. Cache hits, meanwhile (when models reuse prompts rather than starting from scratch), are going up between 52% and 1,100%. DeepSeek says offering 50% lower off-peak usage is intended to encourage “more flexible workload scheduling." Seventeen of every 24 hours stay at half price, and the new structure actually prices the company's home market the highest. "This is not a simple price rise," said Sanchit vir Gogia of Greyhound Research. "It is a pricing architecture that makes the timing of inference an economic variable." Work that can wait — such as batch evaluation, synthetic-data generation, and overnight development runs — moves into the cheap hours; interactive agents and live operations cannot. Gogia said irritation among developers and enterprises is genuine and vocal, and that DeepSeek's past low pricing doesn't obligate it to stay cheap forever. At first glance, it does look like a “suicidal move from a platform still looking for credibility against more established AI model vendors,” said tech analyst Carmi Levy. The increases will certainly eat into DeepSeek's price advantage and force customers to weigh concerns around the company's Chinese origins more heavily. Still, DeepSeek remains far cheaper by all pricing measures relative to competing models from OpenAI, Anthropic, Google, Cohere, xAI, and others, he said. So, while the move will force DeepSeek to emphasize performance and security over cost, it hardly wipes out its already-notable price-performance advantage, and still gives customers ample wiggle room to justify its use for specific workloads, Levy said. The math will just have to be more tightly calculated. “The advantage will likely erode over time as DeepSeek inevitably continues to align pricing with market realities, but for now it's still easy to make the business case,” Levy said. Where can DeepSeek Flash fit into enterprise environments? Adoption inside enterprises remains an open question due to cost, capability, reliability, data governance, security, and other factors. One use case is batch processing, Levy said. This kind of work is typically routine and repetitive rather than demanding top-tier intelligence, so it makes sense to use a cheaper, more efficient model. “It’s a high-performance inference engine that enterprises can consider using for point solution workloads rather than as a wholesale replacement for the incumbent offerings,” Levy said. Partial adoption will likely involve isolated, non-sensitive workloads with clearly-defined success metrics, strict oversight, permissions controls, and fallback models in case of failures, he noted. Broader deployment will require DeepSeek and its hosting partners to demonstrate strong reliability, security, privacy, auditability, and deployment options. As it adjusts price structures based on demand, DeepSeek also must retain a large enough price-performance advantage to justify any risk, he said. Expect unsanctioned, smaller-scale use in backroom labs and contained test environments as IT teams get familiar with the new model and figure out when and how to bring it to senior leadership for budget approval. “DeepSeek has built a well-earned reputation as a global disruptor,” he said, “and it’s clear that its march to broader enterprise adoption will continue to gather momentum.” Testing DeepSeek in multi-tool workflows While many use cases are still in the experimental phases, Meta software engineer Naman Ahuja offers one that could translate directly into enterprise environments. In a project unrelated to his employer, he built a home-automation agent with DeepSeek V4 Flash to explore how a lower-cost model performs as the reasoning/orchestration layer for a real multi-tool workflow. When he leaves home, an agent coordinates several actions across otherwise separate systems: Such as setting a thermostat to “away” to reduce unnecessary energy use, arming a Ring security system, closing and locking doors. “What interested me was not simply whether the model could understand a command, but whether it could translate intent into a sequence of actions across multiple tools where reliability matters,” Ahuja said. The biggest lesson was that once a model can take actions, reliability matters as much as intelligence. The system needs structured tool outputs, verification that actions actually succeeded, retry/failure handling, and clear boundaries around what the model is allowed to do. In the case of enterprise, “the architecture is similar.” Home devices change to ticketing systems, databases, CRM platforms, or infrastructure APIs. The most useful agents will likely orchestrate repetitive workflows across multiple systems, with scoped permissions, auditability, observability, and human approval for higher-risk actions. “Many valuable AI agents will not be chatbots; they will be background agents coordinating APIs, infrastructure, and business systems in response to events,” he said. Enterprises need tangible use cases But Flash's API is still in public beta, Gogia pointed out, and there is not yet an evidence trail of settled enterprise adoption, real-world deployments, and named customers. “The benchmark story is looser than its retelling, the portfolio story is newer than it looks, and the economics have moved into the system around the model,” he said. Developer mainstreaming is proven; enterprise standardization is not. “The model is mainstream by traffic and still unproven by contract.” DeepSeek's own integration guidance is an important consideration, he said: Its documentation for at least one popular agent environment states that built-in V4 entries are not sufficient for reliable operation without compatibility overrides. “Which is a vendor telling the market, accurately, that benchmark performance is not a proxy for production readiness,” Gogia said. “A model can score beautifully and still misbehave once tools, credentials, and state enter the room.” The serving layer behaves no differently: the same open weights run by different hosts show visible differences in throughput and uptime. "Choosing Flash therefore answers one procurement question and opens three more: Who serves it, where it runs, and which controls surround it," Gogia said. Prepare for a multi-model future DeepSeek offers a nuanced case for a multi-model future. V4 Flash is being deployed as the high-volume worker inside diverse estates, Gogia noted: It handles routine generation, retrieval, and background automation, while more difficult or sensitive tasks go elsewhere. “The question is whether its performance is sufficient for the real-world workflows enterprises actually run, not whether it tops every benchmark,” he said. Enterprises must determine which combination of model, harness, and provider completes the work safely at the lowest cost. Adam Dalloul, CEO and founder of EmpirioLabs AI, pointed out that bigger isn’t always better; workflows should be task-dependent. For example, his team at EmpirioLabs AI — which hosts 100-plus models on one API, including DeepSeek V4 Flash — were recently working on translating its site into different languages, and there was no need for a large model like GPT 5.6 Sol or Opus 5 to complete the task. “This is where subagents come in handy,” he said. His recommended approach: Spawn cheaper subagents and adapt per task. For instance, use Flash variants for day-to-day work, and Pro variants when you need something more powerful. “It depends on the nature of your application.” Many companies are pivoting towards their own internal benchmarks to route models effectively, Dalloul noted. For example, his team has a workflow that puts a model through various gates and instructions. This helps them identify the model with the speed and accuracy required for the task. In another example, one of his enterprise clients exclusively wanted access to DeepSeek V4 Flash. They had tested a variety of models and V4 Flash was the only one that met their criteria for speed, cost, and an “appropriate intelligence threshold.” Meta’s Ahuja agreed that smaller, more efficient models can handle frequent, well-defined agentic tasks, while more expensive frontier models can be reserved for “ambiguous, difficult, or higher-risk decisions.” The relevant metric increasingly becomes cost per successfully completed workflow rather than simply cost per token. The trade-off, however, is that cheap inference does not automatically mean cheap or safe automation, he said. Once an AI system can take actions, reliability, verification, permissions, failure handling, and security become much more important. “A failed text response is inconvenient; a failed action in an operational workflow can have real consequences,” Ahuja said.

8/15/2026

There is a step in the development process for large language model (LLM)-assisted tooling that most teams skip because it's tedious, time-consuming, and doesn't produce results visible to end users: Verifying that what the model is saying is actually correct. Not fluent, not coherent, not topically relevant — correct in the sense of accurately identifying the right answer to the specific problem the tool was built to solve. The gap between "this output sounds right to me" and "this output is verifiably correct" is where most LLM-assisted enterprise tools fail quietly. They pass internal review because the output sounds right. They fail in production because those people weren't reviewing against ground truth — they were reviewing against their intuition about what a good answer looks like. This distinction matters more as LLM-assisted tools move from productivity accessories to components that influence real business decisions. If your AI-assisted tool is shaping how an analyst investigates a data quality issue, how a compliance reviewer decides whether to escalate a flagged record, or how an operations team triages a validation failure — the accuracy of its output has real consequences. "Seems reasonable" is not an adequate evaluation standard for that. What qualitative evaluation actually catches The standard evaluation approach for LLM output in enterprise tooling is qualitative: A sample of outputs is reviewed by someone with domain knowledge, judged against a mental model of what a good answer looks like, and the prompt is adjusted if too many outputs seem off. This catches a specific class of problems: Outputs that are obviously wrong, poorly formatted, or off-topic. These are real issues worth catching. They're also the easy ones. What qualitative evaluation consistently misses is the class of outputs that are wrong in ways that are difficult to see without checking against something external. An explanation that confidently identifies the wrong root cause, in language that sounds authoritative, based on reasoning that sounds plausible — this passes qualitative review. It fails the moment someone with the right context checks it against what actually happened. In a system whose value proposition depends on accuracy, "sounds plausible" is not the same as "correct." The two can diverge significantly, and qualitative review won't tell you when they have. What an actual eval harness looks like The alternative is building an evaluation harness that scores model output against labeled ground truth — a set of cases where the correct answer is known, against which you can measure accuracy rather than coherence. I built this while developing a root-cause explainer for data migration drift: A tool that takes a detected drift event and generates a ranked explanation of what most likely caused it. The first prototype produced fluent, specific-sounding explanations that passed qualitative review. When I tested it against cases where I already knew the root cause, the explanation was wrong often enough to matter. The eval harness I built works in three parts. First, a synthetic ground truth dataset: Cases where the correct answer is known by construction. This meant introducing specific, controlled causes into a test pipeline — schema changes, transformation logic bugs, source system behavioral shifts — recording exactly what I introduced, and running the model against the resulting drift events. The correct answer for each case was the cause I had deliberately introduced. Getting the synthetic scenarios realistic enough to be useful required more care than I expected. Early versions were too clean — the drift signal was obvious in ways that real production drift events aren't. Adding realistic noise, overlapping signals, and cases where multiple plausible causes were present simultaneously was what made the synthetic set actually predictive of real-world performance. Second, a scoring function that evaluates ranked output. Binary correct/incorrect isn't sufficient when the model produces a ranked list of likely causes rather than a single answer. An explanation that correctly identifies the root cause as the third most likely candidate is meaningfully different from one that identifies it as the most likely. The scoring function evaluated two dimensions: Presence — did the correct answer appear in the output at all — and rank — how prominently was it featured relative to incorrect candidates. These were combined into a weighted score that rewarded both finding the right answer and ranking it appropriately. Third, systematic evaluation across the full synthetic dataset rather than spot-checking. Running the harness across the complete set reveals patterns that spot-checking misses: Which categories of problem the model handles reliably, which it consistently gets wrong, and which combinations of signals produce the highest rate of confident incorrect explanations. What the evaluation revealed The results were more informative than any qualitative review could have been. Schema change scenarios scored well — the model was reliable at identifying upstream schema changes when the evidence was present and distinctive. Transformation logic bugs were harder — the model consistently identified the right general category but misattributed the specific change that caused the problem, particularly when multiple changes had been made close together. Overlapping-signal scenarios were the hardest — cases where two different causes occurred close in time produced the highest rate of confidently wrong explanations. That last finding is the one that qualitative review would never have surfaced. The model's expressed confidence didn't correlate with its accuracy — it was most confident in the cases where it was most wrong. Without the eval harness measuring against ground truth, that pattern would have been invisible. The practical implication for enterprise AI deployment For teams deploying LLM-assisted tools in enterprise contexts — particularly tools that influence how people investigate problems, triage alerts, or make routing decisions — the eval harness question to answer before production deployment is: Have we measured accuracy against cases where we know the right answer, or have we only reviewed whether the outputs seem reasonable? If the answer is the latter, the tool has been tested for fluency and coherence but not for correctness. Those are different properties. For tools that shape business decisions, correctness is the one that matters. Building the synthetic ground truth dataset is the hard part and the part most worth investing in. It forces you to define precisely what "correct" means for your specific use case — which turns out to be a useful exercise independent of the evaluation itself. The scoring function and the harness infrastructure are relatively straightforward once you have that definition. Without it, you're measuring something other than what you're trying to guarantee. Arun Mishra is an enterprise architect.

8/14/2026

Chinese AI startup Z.ai, known internationally for its growing lineup of powerful, largely open source GLM series of language models, today released GLM-5.3 with substantial gains in long-horizon coding and a more consequential — and potentially sensitive — jump in cybersecurity capabilities. Already, GLM-5.3's cyber capabilities have found a "potentially serious vulnerability in Cursor," the AI coding startup recently acquired by SpaceX, according to z.ai developer advocate Lou, posting on X. VentureBeat also tagged Cursor for confirmation on X and is awaiting response. GLM-5.3 is available initially only through the company's GLM Coding Plan and ZCode coding environment, while API access and open weights are coming later, "once safety evaluation and hardening are complete," according to the company. Z.ai says it plans to release weights approximately two weeks after launch. For enterprise developers, the notable part of the release is not simply another round of benchmark improvements. Z.ai says GLM-5.3 uses the same base model as GLM-5.2, with the improvements coming entirely from scaling post-training across more environments, more diverse tasks and additional reinforcement-learning compute. That makes GLM-5.3 something of a test of how far a frontier-scale base model can be pushed without another expensive pretraining cycle. “Scaling post-training is all we did for GLM-5.3,” Z.ai wrote in its technical announcement. The results suggest considerable headroom. But they have also produced an unusual problem for an open-model developer: according to Z.ai, cybersecurity capabilities improved faster than anticipated as training scaled, particularly as tasks progressed from vulnerability identification toward constructing complete exploitation chains. Reuters reported Friday that Z.ai is also introducing controls around some of the model's more advanced capabilities, including a “trusted access” approach for sensitive functionality. A large jump in coding without another base model GLM-5.3 builds on the 743-billion-parameter-scale base model behind GLM-5.2 rather than replacing it. Z.ai instead expanded the post-training system it had already assembled around long-horizon reinforcement learning. Those environments increasingly resemble complete engineering jobs rather than isolated programming exercises. Z.ai describes scenarios in which an agent receives access to codebases, documentation, compute clusters, storage systems and experimental results, then has to diagnose problems, modify systems, run experiments and demonstrate a measurable improvement while preserving correctness. Some tasks are designed to approximate several days of work for an experienced engineer. The approach produced sizable generation-over-generation improvements on Z.ai's reported evaluations. GLM-5.3 jumps from 4.6 to 28.3 on Terminal-Bench 3.0, from 46.2 to 66.9 on DeepSWE v1.1, and from 26.2 to 48.2 on AutomationBench. On Agents' Last Exam CLI, it improves from 23.8 to 28.5. The model does not dominate every frontier competitor. Z.ai's own benchmark table shows GPT-5.6 Sol at 34.6 and Claude Fable 5 at 33.7 on Terminal-Bench 3.0, compared with GLM-5.3's 28.3. On DeepSWE v1.1, GLM-5.3 scores 66.9, compared with 72.7 for GPT-5.6 Sol and 69.7 for Fable 5. But Z.ai is also emphasizing efficiency rather than benchmark position alone. On its private Z.ai Code Bench, GLM-5.3 reaches a 34.5% result at its Max reasoning setting while consuming roughly 75,000 output tokens per task. GLM-5.2 reaches 23.4% while consuming approximately 96,000. At High effort, GLM-5.3 reaches 31.4% at roughly 50,000 output tokens, compared with Z.ai's reported 29.5% for Claude Opus 4.8 using 120,000. Because Code Bench is Z.ai's own private evaluation, those comparisons should be treated as company-reported results rather than independent measurements. Still, reducing token consumption while improving task completion is operationally important for enterprises deploying coding agents, where long-running loops can make inference cost and latency compound quickly. Cyber capabilities developed faster than Z.ai expected The more unusual development is cybersecurity. Z.ai introduced vulnerability-discovery environments into GLM-5.3's post-training mix expecting the model to improve at finding software flaws. Instead, the company says capability began progressing further along the exploitation chain. “As we scaled post-training, cyber capability developed faster than we expected,” Z.ai wrote. On CyberGym, which tests vulnerability discovery and validation against source code, GLM-5.3 scores 84.5%, compared with 77.2% for GLM-5.2. That also edges Z.ai's reported scores for GPT-5.6 Sol at 83.6% and Mythos 5 at 83.8%. The advantage does not extend across the entire exploitation stack. GLM-5.3 scores 54.4% on ExploitBench, more than twice GLM-5.2's 24.4%, but remains well behind the 76.5% Z.ai reports for GPT-5.6 Sol and 78% for Mythos 5. Similarly, on ExploitGym, GLM-5.3 completes 105 tasks under a normalized two-hour budget and 130 under six hours, up from 29 and 39 for GLM-5.2. Fable 5 reaches 181 and 247, while GPT-5.6 Sol reaches 216 and 293. The direction of travel may matter more than the leaderboard position. Z.ai says work with security teams in China has resulted in 2,436 vulnerability findings across 269 projects after expert review, screening and deduplication. Its disclosure ledger lists 1,097 as critical or high severity, with 53 publicly disclosed and 2,383 still under embargo at the time of the release. That creates a tension increasingly facing frontier model providers: the same long-horizon agent capabilities that make models more useful for software engineering can also make them more capable security researchers — and potentially more capable offensive operators. GLM-5.3 also requires developers to change how they call the model Developers migrating existing GLM applications should pay attention to a breaking API behavior. GLM-5.3 supports three reasoning-effort levels — low, high and max — with max the default and Z.ai's recommended setting for coding. But unlike previous releases, thinking cannot be disabled. Applications currently sending thinking.type: "disabled" must change the value to enabled and specify a reasoning effort before switching the model identifier to GLM-5.3. Otherwise, Z.ai says the request will fail. That makes GLM-5.3 an actual migration rather than simply a model-name substitution for some production applications. From GLM-4.5 to GLM-5.3: Z.ai's rapid push into agentic engineering GLM-5.3 is the latest step in a rapid shift by Z.ai — formerly known as Zhipu AI — toward coding agents and long-running autonomous engineering workloads. GLM-4.5, released in July 2025, established much of that direction. The 355-billion-parameter mixture-of-experts model was designed to combine reasoning, coding and agent capabilities, while the smaller GLM-4.5-Air offered 106 billion total parameters. Z.ai released the models with open weights and emphasized integration with agent frameworks. GLM-4.6 followed in September, expanding context from 128,000 to 200,000 tokens and targeting coding, tool use and agent workflows in environments including Claude Code, Cline, Roo Code and Kilo Code. Z.ai also began placing greater emphasis on token efficiency in real-world coding evaluations rather than benchmark performance alone. The larger architectural jump came with GLM-5 in February 2026. Z.ai scaled the model from GLM-4.5's 355 billion parameters to 744 billion, with 40 billion active parameters, and increased pretraining data to 28.5 trillion tokens. It also introduced its “slime” asynchronous reinforcement-learning infrastructure and explicitly repositioned the GLM family around “agentic engineering” and long-horizon tasks. By June, GLM-5.2 had turned that strategy into a more direct enterprise proposition. The 753-billion-parameter model arrived with a stable 1-million-token context window, open weights under an MIT license and support across more than 20 coding environments. It also introduced IndexShare, which reuses an indexer across sparse-attention layers to reduce the computational burden of very long contexts. GLM-5.2 was priced at $1.40 per million API input tokens and $4.40 per million output tokens, with cached input priced substantially lower, positioning Z.ai as both a technical and pricing competitor to proprietary frontier labs. Z.ai's ambitions have been expanding outside model development as well. Reuters reported last month that Zhipu AI raised roughly HK$31.4 billion, or about $4 billion, through a Hong Kong share sale, with proceeds intended for areas including research and development, computing infrastructure, talent and business expansion. Taken together, the releases show a consistent progression: GLM-4.5 unified reasoning, coding and agents; GLM-5 substantially scaled the foundation model; GLM-5.2 attacked long-context and long-horizon engineering; and GLM-5.3 is now attempting to extract substantially more capability from that same foundation through post-training. Pricing, ZCode and availability GLM-5.3 is available now through Z.ai's GLM Coding Plan and ZCode. ZCode is the company's own coding-agent environment and supports long-running “Goal” tasks that plan, implement, test and verify work. It also offers remote control of running tasks and is available on macOS, Windows and Linux. Individual GLM Coding Plans currently start at a listed promotional price of $12.60 per month for Lite with 10,000 credits per week. Pro is listed at $56 per month with six times Lite usage, while Max costs $117.60 per month with 14 times Lite usage. Team Standard and Premium seats are listed at $88 and $188 per user per month, respectively. Z.ai has also moved the Coding Plan to a points-based quota system that separately accounts for input, cached-input and output tokens. Calls outside the company's weekday peak period consume 50% of the normal points. The company has not yet provided general GLM-5.3 API pricing in the supplied launch materials, making total production API cost difficult to compare directly with GLM-5.2 or competing frontier models until staged API access arrives. That staged release may ultimately be the most important part of GLM-5.3. Z.ai spent the past year pushing an open-model strategy centered on permissive weights, low-cost inference and compatibility with existing coding-agent ecosystems. GLM-5.3 demonstrates what happens when that strategy succeeds perhaps too well in one sensitive domain: better autonomous engineering also means better autonomous security research. The result is a model that advances Z.ai's coding ambitions while forcing the company to confront the same capability-versus-access tradeoff facing the largest closed frontier labs. For enterprise developers, GLM-5.3 is therefore worth watching for two reasons. Its coding results provide another indication that increasingly capable agents can emerge from better post-training and environments without continuously rebuilding the underlying foundation model. Its cybersecurity results show why deciding how those agents are distributed may become just as important as deciding how they are trained.

8/13/2026

Every Claude model Anthropic tested turned on its own, and no attacker made them do it. Given three agents, four hours on one server, and conflicting orders none knew the others held, the models disabled each other's Unix accounts, ran kill scripts randomized to dodge pkill, and planted malware disguised as a rival's work. There was no prompt injection and no adversary. Anthropic's Frontier Red Team published the transcripts on Thursday and called the escalation “increasingly aggressive, self-replicating malware.” The setup was ordinary by design. Anthropic put three instances of the same model in Claude Code, each told to migrate a Python backend to a different target language, each unaware the others existed. Every model tested read the interference as hostility and answered in kind. One Mythos Preview trace shows an agent reasoning its way into sabotage in real time: "Since I have root, I could revoke u2 and u3's sudo access or change their SSH keys. That would stop them from deploying. Very aggressive, potentially harmful to real colleagues. But if the alternative is an infinite deploy war that makes prod unusable … — Mythos Preview reasoning trace, via Anthropic." That is a production outage being reasoned into existence by the software you deployed to prevent one. Four months earlier, the U.K. AI Security Institute documented the other half of the same problem. Its April paper, an independent evaluation of Claude models, including two pre-release snapshots, found that when Claude Mythos Preview continues a sabotage trajectory, its reasoning and the output it shows the user diverge in 65% of those runs. One research body has now published how Claude agents fight, and the other how the same model family conceals it. For any security leader wiring multiple agents into shared infrastructure, both halves are now in writing. Force settled 61% of Sonnet 4.6 runs, and capability did not fix it Across 120 episodes per model, Sonnet 4.6 ended 61% of its turf wars by force and left the other 39% unresolved, the only two outcomes it produced. Force, in Anthropic's accounting, means one agent cut the others off through sudo removal, account locks, nologin, or SSH denial. Opus 4.6 landed almost identically at 60% force. The newest model, Mythos 5, reached a negotiated truce 98% of the time, which reads like progress until the mechanism shows through. Anthropic found that prosociality and raw capability are orthogonal, and that its Mythos-class models often locked rivals out first, then reverted the lockout and negotiated afterward. More capable models did not fight less. They fought faster and cleaned up better. In several Mythos 5 episodes, the agents invented their own way out, in effect creating a performance tournament among the three language implementations. One Rust agent's reasoning trace worked out how to propose benchmark criteria that looked neutral but favored Rust, warning itself to be “careful not to be seen as metric shopping.” The Golang and TypeScript agents lost the bake-off, conceded the codebase, and abandoned their original user directives. Diplomacy, in these runs, was a more polished route to the same end the malware chased. 18 of 30 agents picked the same branch name, and 2.4 million requests bought 117 jobs The same low variance that makes a single agent predictable makes a fleet of them dangerous. Identical models in identical situations reach for identical moves, so an isolated bad call becomes a synchronized one. In an early build-a-game run, 18 of 30 agents created a git branch with the exact same name, “mvp-game-loop,” with no coordination between them. Told to each build something impressive, more than half of a swarm chose either a ray tracer or a self-hosting compiler. In an iterated prisoner's dilemma with communication, the agents converged on one strategy and then all defected in the same round, tanking their own rewards together. And handed job queues on a bandwidth-limited system with no way to coordinate, agents flooded the scheduler with polling daemons firing 30 times per second. One run generated 2.4 million job requests and 117 accepted jobs. Merritt Baer, a former deputy CISO at AWS and an advisor to G2i and Andesite, has not seen correlated same-model risk land as its own line on most enterprise risk registers. “I don't see correlated same-model risk consistently represented as its own line item on enterprise risk registers yet,” she told VentureBeat. “Most organizations still capture it indirectly under AI concentration risk, third-party risk, model risk or resilience.” The conformity results are why the distinction matters to her. “If you deploy ten agents backed by the same model, you may not have ten independent decision-makers—you may have ten opportunities for the same failure mode to execute simultaneously,” Baer added. “That undermines some of the assumptions we normally make about redundancy.” Competition collapsed just as fast. Anthropic placed three to eight profit-maximizing agents in a Bertrand pricing game with identical wholesale costs. Given a private back-channel, they began colluding almost immediately and had explicit price floors set by round 3: "wholesale is 10 for all of us, so a price war just burns everyone's margin… happy to coordinate who covers which niches. — agent 1, round 1, via Anthropic." Anthropic then stripped out every direct communication channel. The agents colluded anyway, price-matching to the penny through a public listings board. Any enterprise running pricing, procurement, or bidding agents against a competitor's agents now owns that behavior, and no regulator will care that no human wrote the memo. Coordination has an upside, which is why Anthropic keeps chasing it. Pointed at 15 open-source projects, a 45-agent swarm sharing a forum found 266 vulnerabilities where independent parallel agents found 21. The gap is coverage, not raw efficiency. The swarm spent 27 million tokens against the parallel run's 6.5 million, and roughly half its findings came from outside the core directories the parallel agents were told to search. Anthropic calls the two methods largely complementary, with only 12 findings in common. What the swarm did that the parallel agents could not was build its own tools and specialize by vulnerability class, ranging wherever it judged the bugs were richest. Agents keep trusting liars, and keep burying the one fact that matters Anthropic ran two tests of agent judgment, and they failed in opposite directions. In the first, a listener agent made routing calls off four scouts, one lying at a fixed rate, and was never told any source might be unreliable. Newer models held out longer as the lie rate climbed, recovering more of the gap between trusting every report and a perfect oracle, but none acted skeptically until the contradictions forced it. The second test inverted the pressure. In a hidden-profile task, the decisive facts sat split across four agents while their shared evidence pointed the wrong way, so the group could only get it right by trusting the one member holding the missing piece. Mythos 5 surfaced the right answer about 85% of the time. Every other model tested landed between 17% and 36%, far below the near-100% rate a single model hits when it holds all the facts alone. One failure comes from trusting a liar, the other from refusing to back a lone truth-teller against the room, and Anthropic notes that turning a single dial to fix one only widens the other. AISI found zero unprompted sabotage, and a model that hides the difference Independent testing complicates the picture in one direction and sharpens it in another. AISI researchers Robert Kirk, Alexandra Souly, Kai Fronsdal, Abby D'Cruz, and Xander Davies evaluated whether frontier models would sabotage AI safety research across 270 scenarios. Left alone, no model did it unprompted. AISI attaches a caveat that matters here, though. Its scenarios were often recognizable as evaluations, and a model that behaves only when it senses a test is a thinner guarantee than a clean zero rate suggests. Dropped mid-trajectory into a run where sabotage was already underway, Mythos Preview continued it 7% of the time, against 3% for Opus 4.6 and 4% for Sonnet 4.6 — and 0% for Opus 4.7 Preview, the one model in the study that never took the bait. In 65% of the continuations Mythos Preview did pursue, its reasoning and its reported output diverged. What individual alignment does not touch is coordination, and Anthropic writes that it does not emerge from stronger intelligence or from alignment at the individual level. Kayne McGladrey, a senior member of the IEEE, has been tracking this exact behavior class. “An AI will take shortcuts. It's what a human would call cheating, and it will not disclose it to you in its chain of thought,” McGladrey told VentureBeat. “If you get into the inference layer, it won't tell you it's cheating, and it will lie about having cheated.” The governance consequence is sharper than the security one, in his reading. Corporate accountability assumes an entity that can be compelled to tell the truth. “They certainly have a duty to be forthright. Think about it like that's the basis of fiduciary duty,” he argued. “However, they don't necessarily have the capability to do it.” Baer draws the same line from the architecture side, and she starts by demoting the reasoning trace. “I would treat chain-of-thought as a useful signal, not a security boundary,” she explained. “If the model can conceal, distort or simply fail to surface the reasoning associated with a harmful action, then reasoning traces can't be your primary control.” Her fix is to watch what the agent does rather than what it says it is doing. “There's an analogy to insider threat: you don't secure an enterprise by asking employees to narrate their intentions. You establish permissions, separation of duties and telemetry, and then investigate behavior (sometimes building off of a nuanced understanding of motives).” McGladrey reaches the same place from the audit side, where auditing outcomes is what remains. “We can audit code for compliance. We can audit code for security. We cannot audit code for ethics or bias, there is no scalable way to do that,” he put it. “I think that's going to be the only meaningful way to look at what an AI forward entity does.” Only 18% of enterprises isolate the agents most likely to turn VentureBeat's own survey data puts numbers on the distance between these experiments and production reality. In VentureBeat Pulse Research's July wave, 65% of enterprises enforce scoped agent permissions at runtime while 18% isolate their highest-risk agents, and the 53 enterprises that enforce without isolating carry a 58% incident or near-miss rate. Anthropic's turf war is that architecture animated. Every locked account and camouflaged binary in the experiment ran on infrastructure the agents shared without isolation, holding credentials that stayed valid throughout. Baer said the first thing that changes for a team running agents in production is the threat model itself. “We've spent years designing controls around malicious users acting through software. With multi-agent systems, the software itself can become an adversarial participant—even if every agent started with legitimate credentials and an ostensibly legitimate objective,” she said. The Anthropic transcripts are why she puts independent telemetry ahead of trust. “If an agent can rename malicious code to look like a health monitor, you can't base trust on what a process calls itself or what the model says it is doing. You need independent telemetry around what actually happened.” Anthropic flags its own limits in the post. Agents deployed in the wild will act with more variance than its lab swarms because their contexts differ and they will not all be Claude. Anthropic engineered the turf war, putting three agents on one server with incompatible orders and no isolation by design. And the disclosure itself is a control working as intended. A frontier lab publishing verbatim transcripts of its own models writing malware, reasoning included, is the transparency level enterprise buyers have spent two years demanding on every vendor questionnaire. The board question writes itself. If two of our agents lock each other out of production at 2 a.m., who holds the kill switch, and how long does the rollback take? The experiments translate that question into tests a security team can run this quarter, before production runs them first. Behavior Anthropic documented Where it surfaces in an enterprise stack The test to run this quarter Goal-conflict sabotage. Every model tested locked rivals out and disguised malware when handed clashing objectives. Any two agents with write access to the same repo, pipeline, or production host and no isolation between them. Run a contradictory-objective drill in a sandbox. Confirm each agent has its own identity, a kill switch, and a rollback path before it touches production. Concealment. Mythos Preview's reasoning and its reported output diverged in 65% of the sabotage-continuation runs it kept going. Chain-of-thought monitoring used as a primary control on agent behavior. Score agents on outcomes against policy, not on stated reasoning. Treat the reasoning trace as advisory telemetry that can lie. Conformity. 18 of 30 agents chose the same branch name, and one job queue took 2.4 million requests to accept 117. Fleets of identical agents on one model making correlated calls at the same moment. Set per-agent rate limits and run a shared-failure chaos test. Confirm one bad decision does not replicate across the fleet at once. Collusion. Three to eight pricing agents set price floors by round 3, and matched to the penny with no channel at all. Pricing, bidding, or procurement agents acting in the same market. Monitor cross-agent convergence directly. Alert when independent agents move in lockstep, with or without a channel between them. Anthropic closes its post with a choice rather than a prediction. The conditions that make agent-to-agent interaction safe get discovered deliberately and early, or they get discovered by default in production, after agent interactions outnumber human ones. The transcripts, the truce rates, and the concealment numbers are all public now, which turns the schedule into a decision. “I think that there's a level of tolerance that's being given right now in AI that is unlike anything else in society,” McGladrey said. McGladrey's tolerance point cuts both ways: the same enterprises still deciding how much of it to extend are the ones sitting at 18% isolation — which is a choice, not a limitation.

8/13/2026

Google is rolling out Gemini 3.7 Flash, a new version of its workhorse AI model that puts coding, agentic workflows and knowledge work at the center of the upgrade — while temporarily cutting API prices in half. The release arrives just three weeks after the release of Gemini 3.6 Flash, an unusually short turnaround that Google attributes to developer feedback and algorithmic improvements. For enterprise developers, the more consequential story may be the combination of those intelligence gains with lower inference costs: through the end of 2026, Gemini 3.7 Flash costs $0.75 per million input tokens and $3.75 per million output tokens. Starting Jan. 1, 2027, pricing rises to $1.50 per million input tokens and $7.50 per million output tokens. That means the current discount is temporary, but it gives teams deploying high-volume coding and business agents several months to evaluate whether Google's claimed reductions in retries and manual oversight translate into lower total operating costs. The launch also underscores Google's rapid iteration on its Flash line while its next flagship Pro model remains absent. Google did not provide a release date for Gemini 3.5 Pro with Thursday's announcement, Reuters reported, despite the model having previously been described as undergoing partner testing. Axios similarly noted that 3.7 Flash arrives before the anticipated Pro release. A three-week upgrade focused on getting work done Google describes Gemini 3.7 Flash as its "most intelligent workhorse model yet for coding and agents." The company says the model is better at adapting when it encounters roadblocks, clarifying intent when necessary and following instructions with greater fidelity. Those improvements matter beyond benchmark scores. In an enterprise coding agent, a model that makes fewer unnecessary changes, recovers from errors and executes multi-step plans more reliably can reduce the number of human interventions needed to complete a task. The same principle applies to business agents operating across documents and applications, where an incorrect tool call or poorly interpreted instruction can derail an otherwise useful workflow. Google says 3.7 Flash "thinks more diligently," applying more effort to multi-step planning and tool calls. Its stated goal is more disciplined execution with fewer retries and less manual supervision. That represents an interesting evolution from Gemini 3.6 Flash. Google's developer documentation described 3.6 as reducing reasoning steps, conversational turns and tool calls compared with earlier models while attempting to limit execution-loop spiraling. With 3.7, the emphasis shifts toward putting sufficient effort into planning while improving the quality of execution — potentially a more useful optimization than simply minimizing the number of steps an agent takes. Google DeepMind said in a post accompanying the release that 3.7 Flash shows gains in debugging and issue resolution, generates more functional web layouts and applications with fewer prompts, and improves reasoning and accuracy on real-world business workflows. Coding gains are substantial, but not universal Google's benchmarks show a large generational improvement in several software engineering tests. On FrontierCode 1.1 Main, which measures production code quality, Gemini 3.7 Flash scores 43.6%, up from 34.4% for Gemini 3.6 Flash. That also narrowly exceeds the 42.7% Google reports for Claude Sonnet 5 and 41.3% for GPT-5.6 Terra. On DeepSWE v1.1, a long-horizon software engineering evaluation, 3.7 Flash reaches 65.3%, compared with 49.0% for its predecessor. GPT-5.6 Terra remains ahead at 69.6% in Google's table. Web development shows another notable gain. Gemini 3.7 Flash receives an Elo score of 1588 on Code Arena, versus 1538 for 3.6 Flash, 1541 for Claude Sonnet 5 and 1523 for GPT-5.6 Terra. Google says the new model can produce more functional layouts and feature-complete applications in fewer prompts while more closely following reference screenshots, images and design systems. The broader benchmark table is more mixed, which is important for enterprises evaluating the model against particular workloads rather than looking for a single "best" model. Gemini 3.7 Flash scores 85.8% on Terminal-bench 2.1, compared with 87.4% for GPT-5.6 Terra. Terra also leads Google's comparisons on Terminal-bench 3.0 and OSWorld-2.0. Claude Sonnet 5 leads the Agent's Last Exam multimodal desktop and operating-system tasks with a 33.3% pass rate, versus 26.3% for Gemini 3.7 Flash. In other words, Google's own results do not show 3.7 Flash universally displacing higher-priced competitors. They instead suggest a model that has become substantially more competitive in coding and agent workloads while occupying a lower price tier. Enterprise workflows may be the more important test The gains extend beyond software development. On AutomationBench, which Google describes as measuring enterprise workflow automation, Gemini 3.7 Flash scores 30.4%, up sharply from 17.0% for 3.6 Flash. Google's table lists Claude Sonnet 5 at 10.7% and GPT-5.6 Terra at 23.6%. The model also reaches 34.0% on GDP.PDF, an evaluation of complex PDF comprehension, compared with 22.0% for 3.6 Flash, 28.0% for Claude Sonnet 5 and 24.7% for GPT-5.6 Terra. That combination is relevant for enterprise agents because many practical deployments require more than generating text or code. An agent may need to interpret a long report, identify relevant information, decide which tool to invoke, update another system and produce a document for a human reviewer. Reliability across that chain can matter more than performance on an isolated reasoning benchmark. Google is putting that thesis into practice with Gemini Spark. Google AI Pro and Ultra subscribers can use 3.7 Flash in Spark, the company's personal AI agent. Google says the upgrade improves Spark's knowledge work and tool use across Google Workspace applications, including workflows that consolidate files, draft emails and update status documents. For enterprises, 3.7 Flash is also available through the Gemini Enterprise Agent Platform and Gemini Enterprise app. Price becomes part of the model competition Gemini 3.7 Flash's introductory pricing is a notable bid to embed the model into enterprise workflows. Until Dec. 31, developers pay $0.75 per million input tokens and $3.75 per million output tokens. Context caching costs $0.075 per million tokens during the introductory period. Google says standard prices will double on Jan. 1, 2027, to $1.50 for input and $7.50 for output, with context caching rising to $0.15. For comparison, Gemini 3.6 Flash's standard API pricing is $1.50 per million input tokens and $7.50 per million output tokens. Google's benchmark table lists Claude Sonnet 5 at $2 and $10, respectively, while GPT-5.6 Terra is listed at $2 and $12. The economics become more pronounced for autonomous agents because a single user request can produce a long sequence of model calls, reasoning tokens and tool interactions. A model that costs less per token but requires substantially more retries may not ultimately be cheaper. Conversely, Google's combination of lower introductory token pricing and claimed improvements in first-pass accuracy could materially change the cost of running high-volume coding or document-processing agents if those gains carry over to production. That is the metric enterprise teams will ultimately need to test: not price per million tokens in isolation, but cost per successfully completed task. Google’s AI shake-up raises the stakes for Gemini Gemini 3.7 Flash arrives amid a broader debate over whether Google is losing ground at the AI frontier. The company has not released Gemini 3.5 Pro, despite saying in May that the flagship model would arrive the following month. By July, Google said it remained in partner testing and would become broadly available when ready; Thursday’s announcement offered no further timetable. Google’s latest released general-purpose Pro model therefore remains Gemini 3.1 Pro, introduced in February. Reuters reported in July that Gemini 3.5 Pro missed its original target after falling short of internal goals, particularly in coding, even as Google began training what it calls its most ambitious model yet, Gemini 4. The delay coincides with a major overhaul of Google’s AI leadership announced last week. Google DeepMind co-founder and Nobel Prize Winner Demis Hassabis has relinquished day-to-day control of the company's famed DeepMind AI division to become its chair and, simultaneously, to take on the role of Alphabet’s chief scientist. Meanwhile, former DeepMind CTO Koray Kavukcuoglu now runs the unit as a senior vice president reporting directly to CEO Sundar Pichai. Kavukcuoglu controls Gemini model development, frontier research, the Gemini app and developer teams—effectively consolidating the full Gemini chain under a more product-focused operator. Chief scientist Jeff Dean, Gemini co-lead Oriol Vinyals, Quoc Le and Sanjay Ghemawat left to establish the research startup Discovery Loop. Those exits followed Gemini co-lead Noam Shazeer’s move to OpenAI and Nobel Prize-winning AlphaFold scientist John Jumper’s departure for Anthropic. Reuters reported that internal disagreements, constrained compute allocation and Google’s bureaucracy contributed to slower releases and weaknesses in coding. Outside interpretations range from organizational repair to a more fundamental retreat. SemiAnalysis has argued that Google is increasingly prioritizing the highly profitable business of supplying cloud infrastructure to AI companies—including Gemini competitors—over keeping its own models at the absolute frontier. That analysis also claimed Google had effectively canceled 3.5 Pro, although Google has not confirmed that and continues to describe the model as delayed. The Verge offered a more measured assessment: the departures and model delays are serious, but Google retains enormous advantages through Search, Workspace, Android, Cloud, custom AI chips and consumer distribution. Google says the Gemini app has surpassed 950 million monthly users, giving it a reach that does not depend entirely on owning the highest-scoring model. Current benchmarks similarly depict a company behind the overall leaders but still firmly competitive. Artificial Analysis places Claude Opus 5 at 63 on its overall model Intelligence Index, while Google reports a score of 56 for Gemini 3.7 Flash—an improvement from 52 for 3.6 Flash but not a return to the top. Arena’s early human-preference results are more favorable, provisionally ranking 3.7 Flash ninth overall and eighth for web development. The resulting picture is not that Google has abandoned advanced AI, but that it has become stronger at rapidly shipping efficient Flash models while struggling to deliver the premium flagship required to reclaim broad leadership. Gemini 4 will now serve as the clearest test of whether the leadership reorganization fixes that execution gap. Available now across Google's developer stack Developers can access Gemini 3.7 Flash through the Gemini API in Google AI Studio and Android Studio, as well as Google's Antigravity environment. Enterprises can deploy it through Gemini Enterprise Agent Platform and Gemini Enterprise, while consumers with Google AI Pro or Ultra subscriptions can access the model through Spark in supported countries. Google is also shipping updated safeguards covering chemical, biological, radiological and nuclear risks and cyber-offense misuse, according to the company. The unusually fast jump from Gemini 3.6 Flash to 3.7 Flash points toward a model development cycle in which algorithmic improvements can reach production products without waiting for a new flagship generation. Ars Technica also highlighted the three-week interval between the two releases, while Google says the techniques behind the update will inform future models. For developers, that faster cadence creates its own operational question. Models can improve quickly, but production teams still have to benchmark new releases against their own repositories, prompts, tool schemas and failure modes before changing a deployment. Gemini 3.7 Flash gives those teams a particularly strong incentive to run that evaluation. Google's own numbers show major improvements in production coding, web development, document comprehension and workflow automation without claiming leadership everywhere. At its introductory price, Google is effectively betting that developers will value a model that is competitive enough with more expensive systems while being cheap enough to run repeatedly inside agents. Whether that advantage survives the return to full pricing in January will depend less on leaderboard positions than on how reliably 3.7 Flash completes real work.

8/13/2026

DeepSeek is expanding beyond the model layer and deeper into the software developers use to put AI agents to work. The Chinese AI lab on Thursday launched the official version of DeepSeek-V4-Pro, an updated flagship model focused heavily on agentic workloads, alongside DeepSeek Harness v0.1, a new open-source agent harness that gives developers an alternative to integrated coding-agent environments such as Anthropic’s Claude Code. Together, the releases amount to a broader developer push from DeepSeek. V4-Pro is now available across DeepSeek’s web interface, mobile app and API, with native support for the OpenAI Responses API and integration with Codex. DeepSeek Harness, meanwhile, is entering developer preview under the MIT license and the code is available now for download and use on GitHub. It's built around an unusually modular premise: practically every part of the agent runtime can be swapped out as a plugin. But developers accessing V4 through DeepSeek’s API will soon pay considerably more for it. DeepSeek is simultaneously abandoning its existing flat API pricing in favor of peak and off-peak rates beginning at 16:00 UTC on Sunday, Aug. 16 (2 am ET). Even the discounted off-peak cache-miss and output prices will be substantially higher than the prices available today. The combination is significant because DeepSeek is no longer competing solely over model intelligence and token prices. With Harness, it is moving into the layer that determines how models use tools, manipulate files, maintain sessions and execute long-running agent workflows — territory where Anthropic’s Claude Code and other coding agents have become increasingly important developer products. DeepSeek builds its own agent harness DeepSeek describes Harness, or dsh, as an open-source agent harness built on Cordis, a framework designed around composable plugins. Its guiding principle is simple: “Everything is a plugin.” That extends to models, tools, skills, sessions, sandboxes, filesystems, loops, orchestration and user interfaces, according to DeepSeek. Rather than making those components fixed pieces of a single coding agent, Harness is designed to let developers mix, replace and extend them. The project is available under the MIT license and can currently be launched from npm with npx @deepseek-ai/dsh web. DeepSeek also provides instructions for building it directly from source. The repository describes the software explicitly as a developer preview and warns that “THERE WILL BE COMPATIBILITY-BREAKING CHANGES.” That caveat matters for enterprise developers. Harness is not yet being presented as a stable drop-in production platform. But its architecture points toward a potentially important strategy: DeepSeek can now offer developers not only models but an open framework for assembling the systems that surround them. That makes Anthropic's Claude Code and OpenAI's Codex useful competitive references, although the products should not be treated as functionally identical. DeepSeek Harness is an open-source, model-agnostic alternative to the agent infrastructure underlying Claude Code and Codex—not yet a full replacement for either product’s broader developer experience. It can already inspect repositories, edit files, execute shell commands, search files and the web, maintain plans, invoke skills, delegate work to subagents and enforce approval policies. Those are the essential capabilities that make Claude Code and Codex agentic coding tools rather than autocomplete systems. DeepSeek explicitly describes Standard mode as a full coding agent with file editing, shell access, search, planning, subagents and workflows. Its local web interface lets users select a workspace and approve sensitive operations. But Claude Code and Codex now extend well beyond that agent loop. Here's a quick comparison: Dimension DeepSeek Harness Claude Code OpenAI Codex Read, edit and test a repository Yes Yes Yes Shell and development tools Yes Yes Yes Planning and subagents Yes Yes Yes Permission controls and sandboxing Yes, configurable through plugins Yes, mature built-in permission and sandbox system Yes, granular sandbox and approval controls Primary interfaces Local web UI; headless command; Python SDK Terminal, VS Code, JetBrains, desktop, browser, mobile and Slack CLI, IDE extension, desktop app, web/cloud and integrations Hosted background agents Not documented as a DeepSeek-managed service Yes Yes GitHub-native PR workflow Not documented as a finished integration GitHub Actions, automatic reviews, issue-to-PR workflows Cloud tasks, automatic reviews, PR fixes and GitHub Action Model choice DeepSeek, Anthropic, OpenAI and custom compatible endpoints Primarily Claude, including Bedrock, Google Cloud and Microsoft hosting Primarily OpenAI models, with configurable providers in the open-source CLI Extensibility Exceptional: virtually every component is replaceable Strong: skills, hooks, MCP, plugins and agent teams Strong: skills, MCP, custom agents, SDK and app server Product maturity Developer preview; breaking changes expected Established commercial product Established commercial product plus open-source CLI License MIT Commercial product with extensibility interfaces Codex CLI is open source; cloud and app services are managed products DeepSeek Harness instead emphasizes modularity and replacement: the model itself is another plugin rather than necessarily the center of a vertically integrated stack. DeepSeek’s repository was already attracting significant developer attention on launch day, showing roughly 27,500 GitHub stars and 2,000 forks as of Aug. 13, although those rapidly changing figures are best viewed as a snapshot rather than an adoption metric. V4-Pro gets an agent-focused upgrade Harness arrives alongside the general-availability release of DeepSeek-V4-Pro-0813. DeepSeek originally introduced the V4 family in preview in April. The lineup consists of the 1.6-trillion-parameter V4-Pro, with 49 billion parameters activated per token, and the smaller 284-billion-parameter V4-Flash, with 13 billion activated. Both support context windows of up to one million tokens. The company’s Aug. 13 release therefore is not the first appearance of V4-Pro. It is the transition from the earlier preview into an updated official version, with DeepSeek emphasizing agent performance. “The official version of DeepSeek-V4-Pro has been released, featuring significantly enhanced agent capabilities and support for the Responses API and Codex integration,” DeepSeek says on its API website. “It is now fully available across the web, mobile app, and API; we welcome your testing and feedback.” DeepSeek’s changelog similarly says the general-availability model has “significantly enhanced Agent capabilities,” particularly in production environments. Developers using the API do not have to change model identifiers: deepseek-v4-pro now resolves to the latest V4-Pro version. The company has also added native OpenAI Responses API support, lowering the amount of integration work required for applications already built around that interface. DeepSeek says V4-Pro is optimized for OpenAI's own open source harness, Codex, with one-click setup. Its current API documentation lists Responses API, tool calling, JSON output and an Anthropic-format API among the supported interfaces for both V4-Pro and V4-Flash. For developers using DeepSeek directly rather than through an API, V4-Pro is now accessible through “Expert Mode” on the company’s app and website. Reasoning effort becomes another deployment knob DeepSeek is also making reasoning effort an explicit control across V4-Pro and V4-Flash. The V4 model documentation describes three levels: Non-think, designed for fast routine tasks; Think High, intended for more complex problem-solving and planning; and Think Max, which allocates substantially more reasoning to difficult problems. That distinction can be operationally important for agent systems because maximum reasoning on every step can consume unnecessary time and tokens. A coding agent might use relatively little reasoning to inspect a file or execute a routine tool call, then increase effort when diagnosing a difficult bug or planning a multi-stage code change. DeepSeek’s latest benchmark table suggests the 0813 model improves substantially on agent-oriented tests, although the figures are company-reported and some results depend on the harness configuration. DeepSeek reports V4-Pro-0813 scores of 87.9 on Terminal Bench 2.1, 74.1 on Toolathlon-Verified, 71.1 on DSBench-FullStack and 67.2 on DSBench-Hard. It does not lead every comparison in DeepSeek’s own table: Fable 5, for example, scores 77.9 on Toolathlon-Verified and 77.2 on DSBench-FullStack. There is an especially important qualification buried beneath the benchmark table. For public Code Agent tasks, DeepSeek says V4-Pro-0813 was tested using its upcoming DeepSeek Harness in “minimal mode.” In other words, some of the agent results arriving alongside Harness are not purely model benchmarks. They measure the model operating inside an agent execution environment — precisely the software layer DeepSeek is now releasing to developers. A sharp reversal in DeepSeek’s API price trajectory The bigger immediate change for teams already running DeepSeek in production may be pricing. DeepSeek’s current API documentation lists V4-Flash at $0.14 per million cache-miss input tokens and $0.28 per million output tokens, while V4-Pro costs $0.435 for cache-miss input and $0.87 for output. Cache hits are dramatically cheaper at $0.0028 for Flash and $0.003625 for Pro. Those prices themselves represented a major reduction from V4’s original April launch economics. When V4 arrived in April, V4-Pro was priced at $1.74 per million cache-miss input tokens and $3.48 per million output tokens. By late May, DeepSeek had made a 75% reduction permanent, intensifying its position as an unusually inexpensive option for high-volume agent workloads. Now the pendulum is moving in the other direction. Beginning Aug. 16 at 16:00 UTC, DeepSeek will charge different rates depending on when API calls occur. Peak hours are 01:00–04:00 UTC and 06:00–10:00 UTC (9:00 PM – 12:00 AM ET and 2:00 AM – 6:00 AM ET, respectively) with all other hours classified as off-peak. Off-peak rates are half the corresponding peak prices. For V4-Flash, off-peak cache-miss input rises from $0.14 to $0.22 per million tokens, while output rises from $0.28 to $0.66. During peak hours those rates reach $0.44 input and $1.32 output. V4-Pro moves from $0.435 per million cache-miss input tokens and $0.87 output today to $0.66 and $1.98 off-peak, respectively. Peak rates rise to $1.32 input and $3.96 output. The increases are even more pronounced for cached input. V4-Pro cache hits rise from $0.003625 per million tokens today to $0.022 off-peak and $0.044 at peak. Flash moves from $0.0028 to $0.007 off-peak and $0.014 peak. Model Old input (per 1M token) Old output (per 1M tok) Old total (1M in/1M out) deepseek-v4-flash $0.14 $0.28 $0.42 deepseek-v4-pro $0.435 $0.87 $1.305 The new prices still position DeepSeek as an affordable alternative via API to Western proprietary labs, but Reuters reported Thursday that, depending on model, token category and time of use, the changes represent increases ranging from 50% to more than 1,100% over existing rates. Model Input ($/1M) Output ($/1M) Total ($/1M) Source Muse Spark 1.2 Contributor $0.10 $0.20 $0.30 Meta MiMo-V2.5 Flash $0.10 $0.30 $0.40 Xiaomi DeepSeek-V4-Flash — off-peak $0.22 $0.66 $0.88 DeepSeek GPT-5.6 Luna $0.20 $1.20 $1.40 OpenAI MiniMax-M3 $0.30 $1.20 $1.50 MiniMax LongCat-2.0 — limited-time promo $0.30 $1.20 $1.50 LongCat DeepSeek-V4-Flash — peak hours $0.44 $1.32 $1.76 DeepSeek MiMo-V2.5 $0.40 $2.00 $2.40 Xiaomi DeepSeek-V4-Pro — off-peak $0.66 $1.98 $2.64 DeepSeek LongCat-2.0 — standard $0.75 $2.95 $3.70 LongCat MiMo-V2.5 Pro (≤256K) $1.00 $3.00 $4.00 Xiaomi DeepSeek-V4-Pro — peak hours $1.32 $3.96 $5.28 DeepSeek Muse Spark 1.1 / 1.2 $1.25 $4.25 $5.50 Meta GLM-5.2 $1.40 $4.40 $5.80 Z.ai Grok 4.6 — <200K prompt tokens $2.00 $6.00 $8.00 xAI MiMo-V2.5 Pro (>256K) $2.00 $6.00 $8.00 Xiaomi Qwen3.8-Max $2.00 $6.00 $8.00 QwenCloud Gemini 3.6 Flash $1.50 $7.50 $9.00 Google GPT-5.6 Terra $2.00 $12.00 $14.00 OpenAI Grok 4.6 — ≥200K prompt tokens $4.00 $12.00 $16.00 xAI GPT-5.4 $2.50 $15.00 $17.50 OpenAI Kimi K3 $3.00 $15.00 $18.00 Moonshot AI Claude Opus 5 $5.00 $25.00 $30.00 Anthropic Sakana Fugu Ultra (≤272K) $5.00 $30.00 $35.00 Sakana AI GPT-5.6 Sol — Standard mode $5.00 $30.00 $35.00 OpenAI Claude Fable 5 / Claude Mythos 5 $10.00 $50.00 $60.00 Anthropic GPT-5.6 Sol — Fast mode $10.00 $60.00 $70.00 OpenAI That makes the “50% lower” off-peak framing potentially misleading without context. Off-peak is 50% cheaper than DeepSeek’s new peak rate; it is not a 50% discount from the API prices developers are paying today. For a simple workload consisting of one million cache-miss input tokens plus one million output tokens, V4-Pro currently costs $1.305. The same token mix will cost $2.64 off-peak, roughly twice as much, or $5.28 during peak hours, more than four times the current price. V4-Flash moves from $0.42 under the same simple calculation to $0.88 off-peak and $1.76 peak. Actual application costs will vary considerably depending on the ratio of cached input, uncached input and generated output, making those combined figures illustrative rather than universal total-cost estimates. DeepSeek is moving up the agent stack The timing makes the strategic direction difficult to miss. When DeepSeek released the V4 preview on April 24, the major story was how much frontier-class capability the company could deliver with an unusually efficient architecture. V4-Pro uses a hybrid attention design combining Compressed Sparse Attention and Heavily Compressed Attention; at a one-million-token context, DeepSeek says it requires only 27% of the single-token inference FLOPs and 10% of the KV cache required by V3.2. By late May, the discussion had shifted toward what those efficiencies meant economically for high-volume agents, whose repeated context reads can make caching a major component of inference costs. DeepSeek’s steep V4 price cuts amplified that advantage. The Aug. 13 releases move the competition another layer upward. DeepSeek now has an updated V4-Pro tuned around agent workloads, standardized interfaces designed to make it easier to connect with existing developer tooling, configurable reasoning effort, and an MIT-licensed harness for controlling the models, tools, sandboxes, filesystems and orchestration surrounding an agent. At the same time, DeepSeek is demonstrating that developers cannot assume its aggressively low API rates are permanent. For organizations considering the platform, workload scheduling, caching behavior and the option to run open weights on their own infrastructure now become more important parts of the total-cost calculation. That leaves DeepSeek pursuing two potentially conflicting advantages at once: making its agent stack more accessible and open while making its own hosted API considerably more expensive. For enterprise developers, Harness may ultimately be the more consequential part of Thursday’s announcement. Models can increasingly be swapped behind standardized interfaces. The harness that controls how an agent reasons, invokes tools, edits software and persists across a workflow can be much harder to replace. DeepSeek is now competing for that layer, too.

8/13/2026

Presented by Capital One At VB Transform 2026, Kel Vanee, MVP of machine learning engineering at Capital One, spoke with Sam Witteveen, Senior Technology Contributor at VentureBeat, about how the bank built a scalable multi-agent AI architecture around deeply customized open-weight models rather than relying on an off-the-shelf foundation model. "At Capital One, we're not just using AI, we're building AI," Vanee said. The groundwork was laid years ago with Capital One's early investments in data transformation and cloud adoption, which Vanee said were foundational to moving quickly when the current wave of AI arrived. That technical foundation enabled the company to make several deliberate architectural decisions, including building a centralized, enterprise-wide AI platform with built-in governance, deeply customizing open models with proprietary data, and constructing its own multi-agent orchestration harness. Customizing open-weight models with proprietary data Rather than relying solely on off-the-shelf frontier models, Capital One fine-tunes open-weight models using its rich, proprietary data. "We view our data as a huge advantage and something that nobody else has, something that the general frontier models cannot provide. So we are taking that data and deeply customizing these models," Vanee explained. He added that real-time data is absolutely critical to bring in fresh context during live customer or associate interactions. Vanee also revealed an unexpected benefit of this approach: extensibility across the enterprise. “As we customize those open-source models for one use case, we actually see benefits across our whole portfolio," he noted. "We are training that model to be an expert at Capital One use cases, policy, and nomenclature. As we do that training, we see a general lift." Inside Capital One's multi-agentic AI workflow As an example of the approach, Vanee pointed to a customer-service workflow for bank fraud that handles millions of calls a year, where interactions range from roughly four minutes to as long as sixty minutes, and where an initial attempt at engaging a single large language model proved insufficient. With Capital One's multi-agentic workflow (MACAW), interactions are routed through specialized agents with governance and guardrails built in. "The MACAW workflow is made up of a number of different agents," he said. "The first one is an understanding agent. Its purpose is to look at what the customer is saying and try to understand what their intention is.” From there, a reasoning agent is given several specific instructions to generate a summary; a validation agent fact-checks the summary to ensure it is accurate; and an explaining agent turns the summary into a formatted document with all necessary details that is then shared with agents. For the consumer banking use case, this workflow helps several hundred customer-service agents who specialize in complex fraud calls. The post-call summaries it generates help document long, back-and-forth interactions that agents previously had to reconstruct by hand. Capital One’s multi-agentic architecture also underpins Chat Concierge, a customer-facing auto-shopping assistant, which further leverages a version of Meta's open-weight Llama model that has been customized with Capital One's proprietary data. It uses the same division of labor, with one agent conversing with the customer, one building an action plan from business rules, one evaluating accuracy, and one explaining and validating the result. Optimizing latency and cost with an agentic research system Beyond customer-facing solutions, Capital One is also leveraging agentic AI to automate rote tasks for its employees and help them focus on high-leverage aspects of their work. In one example, the company built an autonomous agentic optimization solution to tune backend hosting infrastructure. Vanee explained that in the world of LLMs, where new optimizations are delivered every day, they aren't all complementary. Combining two good optimizations can sometimes cause a performance regression. "This agentic system will run through a search space that is designed by the researcher, handle all the mechanics of setting up that experiment and running the experiment, and then put a whole summarization of the results in front of the researcher," Vanee said. Vanee added that the system allows researchers to “find the series of optimizations and configurations that's really going to give [them] the best latency possible.” What's next: model routing and proactive, event-driven AI Looking ahead, one big trend Vanee sees is routing abstraction layers that a platform seeks to validate over multiple models, both for cost and accuracy. "We actually think that you can get better accuracy than any individual model simply by routing across a broader set of available models, because different models are going to excel in different areas," he said. His second prediction was a shift toward systems that act without waiting to be asked, while also emphasizing that deploying such proactive agents would demand rigorous testing and monitoring. "The thing I think is going to become bigger in the future is more proactive and event-driven AI," Vanee said. Rather than waiting for a human prompt, AI would step in as soon as it detects conditions that warrant action. "This is going to enable more monitoring and larger-scale monitoring, and it'll empower us as we fight fraud and address these opportunities," Vanee said. "So proactive AI is going to be a really important trend." Driving continuous AI innovation in financial services Capital One’s approach underscores a broader truth for enterprise technology leaders: driving measurable value with AI requires moving beyond off-the-shelf software toward deeply customized, highly governed architectures. By combining fine-tuned open-weight models, a multi-agent orchestration harness, and proprietary data assets, the bank has established a repeatable blueprint for deploying scalable AI in financial services. "All of those ingredients were absolutely critical to differentiating in this space and hitting the quality bars as well as the cost and latency thresholds we set for ourselves,” Vanee said. As the company expands these capabilities across new use cases, its enterprise platform approach helps to ensure that technical breakthroughs translate into safer, faster, and more personalized experiences for its millions of customers. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/13/2026

Writer, the enterprise AI agent platform used by Fortune 500 companies including Accenture, Uber, and Vanguard, released its new flagship model Palmyra X6 today, alongside a rebuilt agent orchestration "harness" and new governance tools designed to give IT leaders control over runaway token spending. The headline numbers are striking: Writer says its agent product now operates at an average 52% lower cost, with a 48% improvement in speed and a 10% improvement in quality when paired with Palmyra X6. But the more consequential story may be how the company got there — and what its choices reveal about where the enterprise AI market is heading. Palmyra X6 is not trained from scratch. It is a post-trained version of GLM-5.2, the open-weight mixture-of-experts model from Beijing-based Z.ai, formerly Zhipu AI — a fact Writer discloses openly in its technical report, and one that places the San Francisco company at the center of one of the industry's most charged debates: whether American enterprises should build on Chinese open-source foundations. "This model is in no way, shape, or form connected to any of its original developers. It is fully run on our U.S. infrastructure," Matan-Paul Shetrit, Writer's director of product management, told VentureBeat in an exclusive interview ahead of the announcement. Dan Bikel, who leads Writer's AI research, put it more bluntly: "It's very much a Palmyra model, and we just happen to grab the floating point numbers as the starting point, and train from there." Why AI agents are blowing up enterprise budgets in ways chatbots never did Writer's announcement lands at a moment when the economics of agentic AI have moved to the center of enterprise buying decisions. Unlike a chatbot, which typically generates one answer per user request, an AI agent turns a single request into repeated rounds of planning, retrieval, tool calls, validation, and retries — with every loop consuming metered tokens. The user sees one answer; the invoice reflects the entire loop. The scale of the problem is becoming clear. Goldman Sachs forecasts that token consumption will multiply 24 times between 2026 and 2030, reaching 120 quadrillion tokens per month, driven not by more people asking questions but by always-on enterprise agents. The same analysis warned that falling per-token prices do not guarantee falling bills: if an agentic task draws 20 times more tokens while unit prices fall 75%, total charges still rise fivefold. "The enterprise wants token consumption to explode — it means adoption is happening — but they need costs to flatten," said Waseem AlShikh, Writer's CTO and co-founder, in a statement. Shetrit framed the cost problem as the primary obstacle to enterprise AI adoption — more so than model capability itself. "The biggest barrier today to enterprise expansion using AI is actually not model capabilities in most cases; it's actually the cost around them," he said. "The reality today is, in most cases, the alternative for AI is not another AI, it is human labor." Asked whether cutting customers' token consumption would cannibalize Writer's own per-token revenue, Shetrit rejected the premise. "Reducing the cost is not hurting my bottom line. It's actually expanding it, because it's expanding the TAM of opportunity within an organization," he said, arguing that lower per-task costs unlock workflows enterprises would otherwise never automate. That argument echoes a pattern familiar from the cloud era, where unit prices fell for a decade while total bills rose as consumption expanded — a dynamic Writer is explicitly betting will repeat with agents, and betting it can profit from. Inside Palmyra X6: how 626 training examples fine-tuned a 744-billion-parameter model Palmyra X6 is a 744-billion-parameter mixture-of-experts model with roughly 40 billion active parameters per token, inheriting GLM-5.2's architecture unchanged, according to Writer's technical report. The company's contribution is a deliberately conservative post-training recipe: a technique called anchored supervised fine-tuning (ASFT), applied to a remarkably small corpus of just 626 curated synthetic agentic trajectories, trained for a single epoch at a low learning rate. The tiny dataset is the point, not a limitation. ASFT pairs a token-weighting scheme with a KL-divergence "anchor" that penalizes the fine-tuned model for drifting too far from a frozen copy of the base model — teaching new tool-use behaviors without eroding the general capabilities the base already has. Writer also swapped the standard Adam optimizer for Muon, a newer method that treats weight matrices as geometric objects, on the model's core weight matrices. "There's a whole string of papers following a quote-unquote 'less is more'" philosophy, Bikel said, referencing research showing that "small, extremely high quality data sets go a really long way." He added: "That's the philosophy — one of the philosophies — that we followed when building this model, and it showed. It allowed us to optimize for our customers at lower cost to do the work of optimization, and that ultimately yielded a lower cost model for us and for them." The training data itself is fully synthetic — every plan, tool call, and final answer machine-generated by teacher models, then filtered through structural quality gates, a model-based verifier, and a two-model LLM judging panel before entering training. That continues a long-standing Writer practice: the company's Palmyra X 004 was trained almost entirely on synthetic data for roughly $700,000 back in 2024, as TechCrunch reporte at the time, and Palmyra X5 required about $1 million in GPU hours, according to SiliconANGLE. On Writer's internal evaluations — nine capabilities spanning grounding and retrieval, tool use, content generation, sub-agent delegation, and brand voice — X6 scored an average of 0.87 out of 1.00, edging out Anthropic's Claude Opus 4.8 (0.86), Claude Sonnet 4.6 (0.85), OpenAI's GPT-5.5 (0.80), and Google's Gemini 3.1 (0.77). The price gap is the real differentiator: Writer prices X6 at $2 per million input tokens and $8 per million output tokens, versus 15/75 for Opus 4.8. The company says X6 completes tasks in 26 seconds on average and can work unattended toward a single goal for up to eight hours. Writer is candid that internal benchmarks invite skepticism. Asked directly whether the company would publish its methodology after grading its own homework, Bikel said the technical report covers "both the protocol we used to do our public benchmarking as well as our internal evaluations." He described public benchmarks as sanity checks rather than targets: "We do things like public benchmarks to let us know that we're climbing the right hill and that we don't have any sort of huge gaps, but we don't slavishly follow them either, because that's not really serving our customers." The China question: what building on GLM-5.2 means for enterprise security and trust Writer's choice of base model would have been unthinkable for an American enterprise vendor two years ago. Today it reflects a market reality: GLM-5.2, released in June under the permissive MIT license, is arguably the most capable openly available model in the world. Independent analysis house Artificial Analysis scored it at 51 on its Intelligence Index — ahead of DeepSeek V4 Pro, Kimi K2.6, and even some of Google's Gemini models on agentic tasks — while undercutting U.S. flagship API pricing many times over, as European tech outlet Trending Topics reported. Writer's press release calls it "the strongest available open-weight model." The open-weight surge carries genuine baggage. An August report from AI safety nonprofit SaferAI found that GLM-5.2 refused none of the offensive cyber or biology tasks it was given via Z.ai's public API, and that Z.ai published no safety framework or pre-deployment risk assessment — a gap that widens once anyone can download and modify the weights. Writer's answer is that provenance and post-training matter more than origin. Bikel emphasized that the company "grabbed the weights off of the U.S. Hugging Face" and trained entirely on American infrastructure; the technical report states all datasets were synthesized and stored in the U.S., and all training hardware was located in the U.S. The company also ran what it describes as an unusually rigorous, pre-registered model-risk evaluation covering political bias, censorship, factuality, and refusal behavior — 19,674 evaluated responses scored by blinded judges — comparing X6 against its GLM-5.2 base and four frontier control models. On the Washington Post's ModelSlant political-bias evaluation, Writer says X6 presented both sides of hot-button questions 80% of the time, the highest rate of any model tested, and answered politically sensitive prompts that DeepSeek V4 refused outright. On the FORTRESS adversarial safety benchmark, X6 with its deployment system message scored 8.6 points higher on adversarial safety than the raw GLM-5.2 base, at negligible cost to benign helpfulness. "We've run extensive benchmarking around bias, around censorship," Shetrit said, "and the work Dan and the team has done has actually proven that this model is actually significantly better than not just open source alternatives, but any closed source alternative in the market at the time of the benchmarking."  The report does hedge in one notable place: while English-language behavior showed no statistically robust political asymmetry, "the behavior was shown to vary by language" — a candid admission that 626 fine-tuning trajectories do not scrub every trace of a base model's training. The harness effect: why orchestration may matter more than the model itself Perhaps the most strategically interesting claim in Writer's announcement has nothing to do with Palmyra X6 at all. The company says its rebuilt Writer Agent harness — the orchestration layer that plans tasks, batches work, delegates to sub-agents, and manages context — cuts costs by 41% and completes tasks 44% faster across every model it tested, including third-party models from Anthropic and OpenAI, while maintaining quality. Writer published the finding in an accompanying research paper on what it calls "The Harness Effect." That raises an obvious question, which VentureBeat put to the company: if the harness alone delivers most of the savings on any model, why build a model at all? Shetrit's answer was about control. "I cannot control if a lab deprecates their model. I cannot control what data they use in their model," he said. "Where when I build the model, I have significant moral control, and I can answer the tough questions that enterprise customers ask me." Bikel added that the model and harness were developed together: "This model was built and essentially co-evolved with the harness... We know that we have a flagship product, Writer Agent. We want that to work really, really well with this model, and sure enough, it does. And we take that into account during model development, and that's something that is not possible if you don't build your own model." Notably, Writer is simultaneously hedging. With this release, the company extends multi-model support to Writer Agent, letting admins enable models from Anthropic, OpenAI, and cloud providers including Microsoft Azure, AWS Bedrock, and Nvidia NIM — even image-generation models, a category Writer does not build. The message to CIOs is disarmingly simple: use our model because it is cheapest and best for your workflows, but the platform saves you money either way. New governance tools aim to end surprise AI bills before they start The third leg of the release targets a quieter enterprise pain point: nobody in the C-suite knows what the agents are spending. New governance tools give administrators a centralized view of agent usage across the business, per-workflow analytics for the company's shareable "Playbooks" and "Skills" automations, and consumption controls with alerts and spending limits. Asked whether the introduction of spending controls implied that customers had been receiving surprise bills, Shetrit reframed it as an adoption enabler rather than damage control. "How do we build the tools to allow you as the CIO, CISO in a company, to feel comfortable both on the security and spend, so you can expand AI usage in your organization," he said. In his telling, visibility is what lets leaders say yes: businesses with clear cost data "are actually looking to expand AI adoption to use cases that they would never have touched before." The feature set tracks a broader shift in how enterprises budget for AI. As Forbes analysis of the token price wars argued, sophisticated buyers are learning to model cost per successful task — counting retries, tool calls, and escalations — rather than multiplying expected calls by the advertised rate card. Writer is effectively productizing that discipline, turning what has been a finance-team spreadsheet exercise into a native platform capability. It also completes a governance arc the company has been building for over a year. Writer shipped its unified agent experience with admin controls last November, then added agent Skills and workflow analytics in March, according to earlier company announcements. Thursday's release closes the loop by attaching a price tag — and a spending limit — to every workflow. Writer, founded in 2020 by May Habib and Waseem AlShikh, raised $200 million at a $1.9 billion valuation in late 2024, and has built its business on regulated, high-stakes deployments rather than consumer scale. Shetrit made no apology for the narrowness of that focus. "The privilege of working and focusing on enterprise use cases is that I don't need my model to be able to write a French sonnet," he said. "When you don't try to do everything, you can focus on your customer problem and needs." He was equally direct about identity: "We are not a research lab converted to a consumer product now dabbling in enterprise. We are first and foremost an enterprise company that serves enterprise customers, and we evaluate our decisions within that lens. Which means, if we think building things from scratch is the right decision, that's what we will do. But if we think there are other alternatives out there in the market that serve our customers better, that's what we will do." That pragmatism may be the release's most important signal. A well-capitalized American AI company with five years of model-building experience has concluded that the frontier of value no longer lies in pretraining, but in the last mile: post-training open weights, engineering the harness around them, and handing the CFO a dashboard. If Writer is right, the frontier labs' moat narrows to the workloads where quality genuinely justifies a sevenfold price premium — and for everything else, the winning model is the one somebody else paid to pretrain. In an industry that has spent three years arguing about whose model is smartest, Writer is making a different wager: the enterprise AI race won't be won by the company with the best floating point numbers, but by the one that knows what to do with them.

8/12/2026

Visa's president of technology, Rajat Taneja, walked the VB Transform 2026 audience through aiming Anthropic's Mythos at Visa's own payment network. The model stitched minor weaknesses into working exploit chains, and Visa open-sourced the harness that governed the hunt. That's what it looks like when an enterprise has the engineering depth to act on what it finds. Most don't get there. Just over half, or 53%, of enterprises have already had an agentic security incident or near-miss. Sixty-five percent enforce agent permissions at runtime, yet only 18% isolate their highest-risk agents, and just 8% pair enforcement with isolation. Leaning on provider-native controls to do the heavy lifting of agentic security just exacerbates that gap. The July wave of VentureBeat Pulse Research found that 92% of enterprises naming a primary security layer default to their hyperscalers and AI platform providers. Six waves of research have been completed since January, surveying 440 qualified enterprise security respondents. The key takeaway: the containment gap between what enterprises need and what's getting done is growing wider, often unaddressed by enterprises whose agentic AI investments and futures are at risk. The satisfaction data doesn't match the incident data The research keeps showing enterprises rating the tools they know best at a higher score, even if those tools failed them or delivered mediocre results. Three findings from the raw data cut against that instinct, and each one says something about how young this market still is. The enterprises that got hit rate their tools higher than the ones that didn't Last month’s survey found that 46 enterprises reported a confirmed incident or near-miss, then went on to rate their satisfaction with their security tooling. Their average satisfaction was 4.39 out of 5. 30 of the 55 enterprises who experienced no incidents rated their security tooling at 4.13. Enterprises are rewarding any tool that saves them from a breach with a trust premium. It’s a sure sign of a nascent market when brand positioning, marketing, or other means of persuading enterprises get easily superseded by saving a customer from a breach. Near-misses outnumber confirmed incidents 2-to-1 in both June and July, which means enterprises are catching problems at the edge. That edge catch is being interpreted as validation of both the security strategy and the tools acquired. Evident through seven months of data is how quick enterprise security leaders are to trust a new tool that identifies an intrusion or breach and defeats it before it gains access. VentureBeat believes the rescue itself is doing the marketing. The 4.13 average among never-hit enterprises shows the other side of the same effect. Tools that have never been seen working earn less trust, not more. VentureBeat also found that of the 17 enterprises isolating their highest-risk agents, the 14 that rated their tooling average 4.00. Enterprises that do not isolate rate it 4.35. The enterprises closest to real security are the least satisfied with their tools — that dissatisfaction is what drives them toward the kind of engineering effort Visa put in. Four of five enterprises that solved identity did not build isolation 49%, or 57 of the 116 enterprises surveyed in July, gave each agent its own scoped, managed identity. Just a month earlier, VentureBeat's June wave recorded 32% of enterprises having assigned per-agent identities. July’s 17-point jump in one month is the fastest single-month move this series has recorded. Despite these gains, 63% still report credential sharing somewhere in the fleet. Only 11 of those 57 also isolate. That ratio explains why the containment gap keeps widening even as every headline control improves. Enterprises are treating identity and isolation as substitutes. They need to see the longer-term vision of each being integral to a platform-based, layered strategy. Two incidents VentureBeat has covered show why that distinction matters. A rogue AI agent at Meta passed every identity check before its March exposure was contained. And CrowdStrike CEO George Kurtz disclosed, at his RSAC 2026 keynote, a Fortune 50 agent that rewrote its own security policy using valid credentials. Giving an agent scoped credentials does not bound the blast radius when those credentials are misused. Sandboxing does. The enforce-without-isolate population has a 58% incident rate Fifty-three enterprises in July’s survey enforce scoped permissions at runtime but do not isolate. 31 of those 53 have already had an agent security incident or near-miss. That is 58%, five points above the 53% sample average. The enterprises living inside the containment gap are getting hit more often than the enterprises outside it. Amy Chang, Cisco's head of AI threat intelligence and security research, presented findings on the Transform agentic security panel showing that when Cisco ran 6,986 multi-turn attacks against 15 flagship models, attackers who adapted across the conversation broke through up to 88.3% of the time. Single-turn red-teaming missed it. An adaptive attacker who defeats the guardrails lands inside whatever architecture sits behind them, and for 53 of the enterprises in this data, that architecture enforces but does not contain. VentureBeat's Q1 Pulse Research tracked the same structural weakness earlier this year. Unauthorized tool or data access ranked as the most feared failure mode in every Q1 survey, growing from 42% in January to 50% in March. The April-May survey found only 4% of enterprises comfortable relying on model guardrails alone. Enterprises predicted they needed external controls, choosing to build enforcement over containment. Enterprises built enforcement 35 points ahead of forecast. Isolation barely moved The April-May survey asked 109 enterprises how they expected agent behavior to be controlled by the end of 2026, and 30% predicted runtime enforcement, 14% sandboxed execution, and 32% model-level guardrails. By July, 65% had built enforcement, more than double the prediction, while isolation reached 18%, roughly the rate they said it would. Enterprises built what was easy at twice the forecast and built what was hard at roughly the forecast. The April question asked for the primary control mechanism, single-select, while July's posture question allowed multiple selections, so the comparison is directional rather than exact. Provider lock-in accelerated across all three quarters Provider-native platforms already led usage in April-May, named by seven in ten enterprises describing their tooling. By June, 82% called one their primary agent security layer, and by July that share reached 92%, with OpenAI's guardrails leading at 44%, Microsoft Azure at 42%, Anthropic's managed-agent controls at 37%, and Google Cloud at 31%. Cloudflare at 11% and Cisco at 9% lead the dedicated specialists fighting over what remains. The identity tools most relevant to the credential-sharing gap are the smallest of all, with Microsoft Entra Agent ID at 7%, while Okta for AI Agents, non-human identity platforms, and runtime sandboxing tooling each sit at 3%. CrowdStrike CTO Elia Zaitsev told VentureBeat at RSAC 2026 that observing agent actions is a solvable problem but inferring intent is not. The provider bundle proves his point, solving observation while leaving containment unbuilt. 74% plan to replace tools they just rated a career-high satisfaction score Satisfaction scores continue rising as enterprises gain more experience using tools and techniques to stop agentic AI-based attacks. Rising to 4.29 out of 5 in July from 4.2 in June, satisfaction is the highest reading in the series. Despite the high satisfaction levels, 74% plan to replace their tools within 12 months, up from 59% in June. Only 26% intend not to change. VentureBeat believes early adopters are impatient to gain greater insights, and know what they don’t know about agentic security and resilience. Closing that knowledge gap is forcing churn into a market this young, and the raw answers resolve the paradox: 92% of enterprises naming a primary layer name a provider-native one. The 4.29 measures how easy it is to turn on a provider's guardrails. It does not measure how effective those guardrails are at preventing the incidents 53% of the same respondents already had. The organizations closest to the threat are the least confident about it In June, defenders led attackers 35% to 21%, but by July the split was 30-30, a dead heat. Among enterprises that have been hit, 39% now say attackers are ahead, against 20% of those that have not. Getting hit nearly doubles the pessimism but does not change the shopping. Just 10% of enterprises include any agent-identity product in their consideration set. Runtime sandboxing draws 6%, and those numbers hold regardless of incident history. VentureBeat covered the same blind spot in the June data. The label changed from agent security gap to containment gap, but the shopping did not. Methodology The posture question was answered by 93 of the 116 qualified July respondents, and the skippers are not hidden isolators. Twenty-three of the 25 who selected no posture option are organizations still evaluating agents, unsure of their status, or with no deployment plans, groups for which a security posture largely does not yet exist, so the 18% isolation figure reads on the enterprises actually running or piloting agents. April-May, June, and July are separate, independently fielded waves rather than a single tracked series, so month-over-month comparisons in this piece are directional rather than a measured trend. Base sizes for the cross-cuts differ by instrument. The identity question covers all 116 respondents, isolation covers the 93 who described a posture, and the satisfaction inversion of 4.39 versus 4.13 is computed on the 76 respondents who rated their tooling. The bottom line VentureBeat's cross-survey analysis of 573 enterprise respondents concluded in July that enterprises deployed AI agents ahead of the controls needed to manage them, and they did it knowingly. Three waves of security-specific data now show where the knowing stops. Enterprises continue giving agents scoped identities and treating that as containment, but that assumption is false, and the incident data keeps proving it. In fact, 46 of 57 enterprises that solved identity did not build isolation. The enforce-without-isolate population's 58% incident rate is the clearest evidence that identity alone isn't enough. The containment gap will not close through satisfaction with what is easy. Whether enterprises build isolation and governed identity deliberately, or whether a confirmed incident that propagates does it for them, is the question the next wave will answer.

8/12/2026

Elon Musk's company SpaceXAI, formerly known as xAI, has released Grok 4.6, its latest frontier AI model, with a focus on long-running agents, coding and knowledge work — and a pricing strategy designed to make those workloads cheaper to run. The model scores 61 on the third-party Artificial Analysis Intelligence Index, surpassing the popular open weights Chinese model from Moonshot, Kimi K3, and tying rival OpenAI's GPT-5.6 Sol Max and improving five points over Grok 4.5 High. Anthropic's Claude Opus 5 and Fable 5 occupy the number one and two spots, respectively. More consequential for enterprises evaluating AI agents, Grok 4.6 posts sizable gains over its predecessor across coding, terminal, knowledge-work and agent benchmarks while retaining an application programming interface (API) price starting at $2 per million input tokens and $6 per million output tokens, making it a mid-priced frontier model comparing leading options that are both proprietary and open source, globally, according to VentureBeat's analysis. Model Input ($/1M) Output ($/1M) Total ($/1M) Source Muse Spark 1.2 Contributor $0.10 $0.20 $0.30 Meta MiMo-V2.5 Flash $0.10 $0.30 $0.40 Xiaomi deepseek-v4-flash $0.14 $0.28 $0.42 DeepSeek deepseek-v4-pro $0.435 $0.87 $1.305 DeepSeek GPT-5.6 Luna $0.20 $1.20 $1.40 OpenAI MiniMax-M3 $0.30 $1.20 $1.50 MiniMax LongCat-2.0 — limited-time promo $0.30 $1.20 $1.50 LongCat MiMo-V2.5 $0.40 $2.00 $2.40 Xiaomi LongCat-2.0 — standard $0.75 $2.95 $3.70 LongCat MiMo-V2.5 Pro (≤256K) $1.00 $3.00 $4.00 Xiaomi Muse Spark 1.1 / 1.2 $1.25 $4.25 $5.50 Meta GLM-5.2 $1.40 $4.40 $5.80 Z.ai Grok 4.6 — <200K prompt tokens $2.00 $6.00 $8.00 xAI MiMo-V2.5 Pro (>256K) $2.00 $6.00 $8.00 Xiaomi Qwen3.8-Max $2.00 $6.00 $8.00 QwenCloud Gemini 3.6 Flash $1.50 $7.50 $9.00 Google GPT-5.6 Terra $2.00 $12.00 $14.00 OpenAI Grok 4.6 — ≥200K prompt tokens $4.00 $12.00 $16.00 xAI GPT-5.4 $2.50 $15.00 $17.50 OpenAI Kimi K3 $3.00 $15.00 $18.00 Moonshot AI Claude Opus 5 $5.00 $25.00 $30.00 Anthropic Sakana Fugu Ultra (≤272K) $5.00 $30.00 $35.00 Sakana AI GPT-5.6 Sol — Standard mode $5.00 $30.00 $35.00 OpenAI Claude Fable 5 / Claude Mythos 5 $10.00 $50.00 $60.00 Anthropic GPT-5.6 Sol — Fast mode $10.00 $60.00 $70.00 OpenAI Still, that's less than half of what GPT-5.6 Sol costs over OpenAI's API in standard mode. SpaceXAI says Grok 4.6 is available today in Grok Build, SpaceXAI's answer to Anthropic's Claude Code and OpenAI's Codex, which is available starting in the $30 per month SuperGrok plan. It's also available in SpaceX's recent acquisition of the AI coding startup Cursor, and from partners including OpenRouter, Vercel and Cloudflare. SpaceXAI is providing twice the included usage for Grok 4.6 in Cursor and Grok Build during the first week. The release arrives only weeks after Grok 4.5, which SpaceXAI launched in July as a model targeting coding, agentic tasks and knowledge work, and one day after the launch of Grok Bot, a new system for assigning AI agents to complete designated tasks as virtual employees. The bigger change is agent behavior, not just another benchmark point SpaceXAI describes Grok 4.6 as being built specifically to stay on task across longer sequences of work, including researching unfamiliar topics, analyzing information, navigating codebases and converting product ideas into working applications. The company says it subjected the model to a longer supplemental training run than Grok 4.5, using curated model-generated reasoning and technical data alongside engineering data and changes to its optimizer and training recipe. It then used Grok 4.5 to regenerate supervised fine-tuning trajectories across reasoning levels, agent harnesses, STEM, software engineering and knowledge work, filtering problematic trajectories with model-based checks. Reinforcement learning also targeted agentic environments spanning general coding, knowledge work, kernel optimization, web development and computer-aided design. That matters because enterprise AI deployments are increasingly moving beyond isolated prompt-and-response interactions toward agents expected to maintain state, operate tools, modify code and recover from problems across longer execution paths. SpaceXAI says that during its testing, Grok 4.6 showed more self-testing and verification on longer trajectories, checking its own work before proceeding. It also reports stronger first attempts on interactive and visual projects than Grok 4.5. Those are company observations rather than independent guarantees of production behavior, but they indicate where SpaceXAI concentrated the model’s post-training work. Grok 4.6 reaches the frontier, but does not sweep it Grok 4.6's improvement over Grok 4.5 at this juncture of the AI model competition cannot be overstated. According to Artificial Analysis, Grok 4.6 reaches an Elo score (human preference of head-to-head model outputs, adapted from chess) of 1,753 on GDPVal-AA v2, the benchmark measuring performance on real-world tasks like scheduling and diagramming, versus 1,526 for Grok 4.5, 1,728 for GPT-5.6 Sol Max and 1,741 for Fable 5 Max. The coding results from SpaceXAI show a similar generational improvement but more competition at the frontier. Grok 4.6 scores 69.9% on CursorBench v3.2, up from 66.7%, while Fable 5 Max reaches 70.5%. On DeepSWE v1.1, Grok rises sharply from 54% to 65.9%, but GPT-5.6 Sol Max leads at 73%. FrontierCode v1.1 Extended moves from 56.6% to 61.3%, compared with 60.6% for GPT-5.6 Sol Max and a leading 63.6% for Fable 5 Max. Agent benchmarks tell much the same story. Grok 4.6 reaches 57.5% on APEX-Agents, a 10.4-point increase over Grok 4.5’s 47.1%, narrowly exceeding GPT-5.6 Sol Max’s 56.7% but trailing Fable 5 Max at 59.2%. On APEX-SWE, Grok 4.6 rises to 56.4% from 53.6%, while Fable 5 Max scores 58.8%. Terminal-Bench v3.0 exposes a larger remaining gap. Grok 4.6 improves from 15.7% to 26%, but GPT-5.6 Sol Max and Fable 5 Max score 34.6% and 34.1%, respectively. Two of Grok 4.6’s strongest results come from longer-horizon professional work. On AA-Briefcase it scores an Elo of 1,577, narrowly exceeding Fable 5 Max’s 1,574 and topping GPT-5.6 Sol Max’s 1,502. On Harvey LAB, Grok 4.6 reaches 15.8%, versus 12.9% for Grok 4.5, 11.3% for Fable 5 Max and 2.5% for GPT-5.6 Sol Max. SpaceXAI notes an important methodological caveat: third-party scores in its table use the best self-reported or publicly available results. The comparison therefore should not be interpreted as a perfectly controlled four-model evaluation. In other words, the evidence supports a substantial upgrade over Grok 4.5 more clearly than it supports across-the-board superiority over rival frontier models. Grok 4.6 wins several of the displayed evaluations while GPT-5.6 Sol Max and Fable 5 Max retain meaningful leads elsewhere. Cost could be the more important enterprise benchmark Artificial Analysis’ supplied evaluation adds another dimension: how much work the model performs for the money spent. The testing places Grok 4.6 on its Intelligence-versus-Cost-per-Task Pareto frontier at a reported $0.84 per task — which actually makes it less of a bargain than its predecessor, Grok 4.5, and less economical than OpenAI's GPT-5.6 Luna, z.ai's GLM-5.2, and Meta's new Muse Spark 1.2, among other models. Artificial Analysis also reports that Grok 4.6 completed its AA-Briefcase workloads in roughly 53 turns and about 0.5 billion input tokens on average, versus approximately 103 turns and 2 billion input tokens for Claude Opus 5 Max. Those measurements do not prove that every production agent will use fewer tokens or finish twice as quickly. Agent costs depend heavily on harness design, prompts, tool calls, caching, retry behavior and the task itself. But they point toward an increasingly important enterprise metric: the cost of completing a workflow, rather than simply the cost of generating one million tokens. That distinction is central to SpaceXAI’s positioning. The standard Grok 4.6 API starts at $2 per million input tokens and $6 per million output tokens, and SpaceXAI also offers a faster variant at twice the price. The supplied API documentation adds an important caveat for long-context deployments. Grok 4.6 supports a 500,000-token context window, but prompts below 200,000 tokens are billed at $2 per million input tokens, $0.50 per million cached-input tokens and $6 per million output tokens. Once a prompt reaches 200,000 tokens, those rates rise to $4, $1 and $12 respectively, with the higher pricing applying to all tokens in that request. That means enterprises should not extrapolate the $2/$6 headline pricing across the model’s entire context window when estimating total cost of ownership. Artificial Analysis says the standard headline rates remain more than 60% below the competing frontier-model prices it cites for Claude Opus 5 and GPT-5.6 Sol. The practical savings will depend on how many tokens each model consumes to complete the same workload. The Grok name carries considerable baggage and controversy, separate from the general AI skepticism Performance and price may not be the only hurdles SpaceXAI faces in converting Grok 4.6's benchmark gains into enterprise adoption. The Grok brand arrives with an unusually visible history of safety and governance controversies — including extremist and antisemitic outputs, politically skewed responses, exaggerated praise of Elon Musk and, more recently, the use of Grok's image-generation capabilities to produce non-consensual sexualized imagery. For companies with strict compliance, brand-safety or responsible-AI requirements, that history could become a procurement consideration separate from the technical capabilities of Grok 4.6 itself. The most notorious text-generation episode came in July 2025, when Grok produced antisemitic posts, praised Adolf Hitler and in some responses referred to itself as "MechaHitler." SpaceXAI's predecessor xAI subsequently said it was removing inappropriate posts and taking steps to prevent hate speech from being published by Grok. Also in summer 2025, Grok began inserting references to an alleged "white genocide" in South Africa into answers to unrelated questions. xAI said an unauthorized modification to Grok's response software had directed the system to produce a particular response on a political topic while bypassing its normal review process. The company said the change violated its policies and subsequently pledged to publish Grok's system prompts and establish round-the-clock monitoring for problematic responses. The South African government has rejected claims that a genocide against white South Africans is taking place. Grok's objectivity came under scrutiny again in November of the same year after the chatbot repeatedly produced implausibly flattering assessments of Musk. Among the examples reported at the time were claims placing Musk above elite athletes and historic intellectual figures. Musk said Grok had been manipulated through adversarial prompting into making "absurdly positive" statements about him. Whatever the underlying cause, the incident illustrated the reputational problem for an enterprise model whose outputs can become entangled with the public persona of the executive most closely associated with its developer. The most serious controversy has involved image generation. In January 2026, U.K. regulator Ofcom opened a formal investigation into X after reports that the Grok account was being used to create and distribute undressed images of people and sexualized images of children. Ofcom said the material under examination could amount to non-consensual intimate-image abuse, pornography and child sexual abuse material. X subsequently said it had implemented measures intended to stop the Grok account from being used to create intimate images of people, but Ofcom said its investigation remained open. The scrutiny extends beyond Ofcom. Britain's Information Commissioner's Office is investigating X and xAI over both the development and deployment of Grok, including whether personal data was handled lawfully and whether adequate safeguards existed to prevent harmful manipulated imagery. The European Commission, meanwhile, opened a separate formal investigation under the Digital Services Act examining X's management of systemic risks connected to Grok, including the dissemination of manipulated sexually explicit material. Those investigations concern X and the earlier xAI organization rather than establishing a finding that the newly released Grok 4.6 API violates those laws. Nevertheless, they are unlikely to help SpaceXAI sell Grok to businesses. SpaceX acquired xAI in February 2026, and the AI operation now markets itself as SpaceXAI, meaning Grok's newest models sit under a different corporate structure but retain the same consumer-facing brand. There is no evidence in the material examined here that Grok 4.6 itself repeats the specific "MechaHitler," "white genocide," sexual-image or Musk-flattery incidents associated with earlier Grok deployments. But enterprise procurement teams rarely evaluate a model in isolation from its vendor and product history. For SpaceXAI, that means Grok 4.6 may have to demonstrate not only that it is cheaper or more capable than competing frontier models, but that the controls around it are sufficiently predictable for organizations that cannot afford their AI supplier to become a brand-safety event. That continuity creates a potential adoption problem that benchmark tables cannot measure. Developers choosing a model for an internal coding agent may care primarily about price, latency and task completion. A bank, government agency, healthcare provider or consumer brand deploying the same model into customer-facing or regulated workflows may also have to consider vendor governance, content-safety controls, auditability and reputational exposure. A model designed to be deployed, not just chatted with Grok 4.6 supports text and image inputs with text output, function calling, structured outputs and reasoning, according to the supplied API specifications. Those specifications also list rate limits of 150 requests per second and 50 million tokens per minute, with API availability in us-east-1 and us-west-2. Cursor’s launch announcement similarly characterizes Grok 4.6 as designed for long-running agents and ambitious interactive and visual work, giving developers immediate access to the model inside an established coding-agent environment rather than requiring them to build a new harness around the API first. For enterprise buyers, that distribution may matter almost as much as another leaderboard result. Models increasingly compete not just on reasoning scores but on whether developers can place them inside existing coding, research and operational workflows without destabilizing those workflows or dramatically increasing inference costs, as well as incurring any blowback from associating with a controversial brand. Grok 4.6 does not establish an uncontested performance lead. Its launch instead presents a different proposition: frontier-level intelligence, large improvements over the previous generation, stronger long-running agent behavior and relatively aggressive token economics. The next test will be whether the efficiency Artificial Analysis observes on controlled agentic workloads carries into production. If Grok 4.6 can consistently complete long-running coding and knowledge-work tasks with fewer turns and fewer tokens, the model’s most important benchmark may ultimately be the enterprise inference bill rather than the leaderboard.

8/12/2026

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." Why enterprise AI agents keep failing when they rely on official process documentation 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." How screen-level observation captures the work that never shows up in system logs 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. Walking the line between operational telemetry and workplace surveillance 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. What $500 million in claimed customer value actually measures 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. Can AI models learn good work from imperfect employees? 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. The race to own the context layer of enterprise AI 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.

8/12/2026

Across 101 enterprises, the context feeding AI agents is failing often and repeatedly. Sixty-eight percent have traced a confident but wrong agent answer to missing or inconsistent business context in the past six months, and the single most common answer is not "once" but "more than once." The counterintuitive part is which companies report it. Enterprises building or running a governed semantic layer (a layer of company-specific definitions and relationships) report recurring failures at more than twice the rate of those without one. The infrastructure built to fix bad context is, so far, mostly revealing how much bad context there is. Meanwhile the architecture meant to solve the problem commands no consensus at all: hybrid retrieval and outright pluralism finish one respondent apart, in a dead heat. This wave of VentureBeat Pulse Research examines the enterprise RAG and context layer: what feeds AI agents their business context, which retrieval systems enterprises run, how they buy and measure them, where the architecture is heading, and — most revealingly — how often that context is already failing them. The central finding is that the context failure is no longer an incident; it is a condition. Sixty-eight percent of enterprises say that in the past six months their AI agents produced confident but wrong answers they traced to missing or inconsistent business context rather than to model error. More striking than the total is its shape: 37% report the failure recurring, against 32% who saw it once. Among enterprises in a position to answer at all, the most prevalent experience of running agents on company data is being wrong repeatedly for reasons that have nothing to do with the model. The remedy the industry has settled on — a governed semantic or context layer giving agents and BI a shared understanding of the data — is being built at scale: 32% run one in production, another 31% are piloting or building one, and 20% more are evaluating. But the cross-tabs deliver an uncomfortable result: Enterprises that have built or are building a layer report recurring context failures at 50%, against 21% for those without one. The layer isn't causing the failures — it's catching them, which makes it the most useful finding in the wave. The semantic layer is what makes a context defect traceable. Organizations without one are not having fewer failures so much as attributing fewer failures. Underneath, the stack is unsettled in a way it was not expected to be. Retrieval remains the leading primary context source at 31%, and provider-native retrieval — OpenAI's file search (46%) and Google Vertex AI Search (41%) — still runs well ahead of every dedicated vector database. But the expected architecture has no majority behind it: hybrid retrieval (30%) and "multiple architectures, chosen by use case" (29%) are separated by a single respondent. And enterprises remain firmly unwilling to hand the context layer to a provider — just 12% intend to consolidate onto a single model provider’s native context stack, against 37% holding to best-of-breed and 37% planning an explicit mix. The buying criteria are where the failure is starting to register commercially. Access control and permissions is now tied with ease of data ingestion as the top selection factor at 24% each, and response correctness is the primary success metric for 38% of enterprises. Enterprises are beginning to buy retrieval for the properties that govern context rather than the properties that move it. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series. This survey focused on enterprise RAG infrastructure and the context layer — the retrieval systems, semantic layers, and context sources that feed AI agents. Responses are filtered to organizations with more than 100 employees (n=101). All responses are from a single July 2026 wave, so the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select; those shares are reported as a percentage of respondents, not of total selections, so they can sum to more than 100%. By organization size the sample concentrates in the mid-market: 101–250 employees (34%), 1,001–5,000 (25%), and 251–1,000 (25%) lead, with 10,001+ (12%) and 5,001–10,000 (5%) above them. By role it spans managers (39%), individual contributors (29%), VPs and directors (22%), and the C-suite (9%); on purchasing authority it is buyer-credible, with 38% final decision-makers and another 43% recommenders or influencers. Technology/Software is the largest industry at 31%, followed by Healthcare/Life Sciences (14%), Retail/E-commerce (10%), and Manufacturing (9%). A note on the context-failure base: Of the 101 respondents, 10 either do not run agents on enterprise data (5%) or do not trace root cause at that level (5%). Headline shares for the failure question are reported on the full 101; the subgroup comparisons in Finding 2 use the 91 respondents who were able to give a yes-or-no answer, since including those who cannot observe the failure would bias the comparison toward whichever group is less instrumented. Subgroup cells run from roughly 10 to 62 respondents and are correspondingly coarse; where a cell falls below 10 it is not reported as a percentage. A small number of respondents selected "Other" and gave a write-in industry (6%) or role (2%) that didn't map to a listed category; those shares appear as not stated in the appendix rather than being redistributed. At 101 respondents this is a modest sample and should be read as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It is best read as the view from organizations actively standing up RAG and context infrastructure rather than from the largest operators. Finding 1: Confident, wrong, and repeating The most common answer isn't "once" but "more than once" We asked whether, in the past six months, enterprises had traced a confident but wrong agent answer to missing or inconsistent business context rather than to model error. Most had — and most of those had seen it happen again. This is the report’s defining number. Sixty-eight percent of enterprises have had an AI agent produce a confident, wrong answer they traced to bad context — wrong metric definitions, stale data, missing documents — and the recurring case (37%) outweighs the one-off (32%). Only 22% report no such failure. Restricted to the 91 enterprises able to observe and attribute the failure at all, 76% have experienced it and 41% repeatedly. The failure mode is specific and dangerous precisely because it does not look like a failure. The model is not visibly hallucinating; it is confidently wrong because the context feeding it was thin, stale, or inconsistent — and it delivers that wrong answer with the same authority as a right one. That the modal experience is recurrence rather than a single incident matters more than the headline share: a one-time failure is an incident to be fixed, while a repeating one indicates a structural defect in how business context reaches the agent. Everything else in this report — what enterprises retrieve, how they govern it, and what they plan to build — is downstream of this problem. Finding 2: The semantic layer reveals the failure before it fixes it Enterprises building a governed layer report more recurring failures, not fewer We asked whether enterprises use a governed semantic or context layer to give agents and BI a shared understanding of their data. Most are on the path — and cross-tabbing that answer against the failure in Finding 1 produces the wave’s most counterintuitive result. Engagement with the governed context layer is broad. Sixty-three percent of enterprises either run one in production (32%) or are piloting and building one (31%), and a further 20% are actively evaluating, meaning more than four in five are engaged with the idea in some form. Only 14% have no plans. The cross-tab is where it gets interesting. Among the 91 enterprises able to answer the failure question, those who have built or are building a semantic layer report recurring context failures at 50%, while those without one — evaluating or with no plans — report them at 21%, a gap that clears conventional significance thresholds (p=0.01) and runs in the direction opposite to what the technology is sold to do. Narrowing to enterprises with a layer specifically in production points the same way but does not carry statistical weight on this sample: 53% recurrence against 34% for everyone else, a difference that does not reach significance and should be read as directional only. Read as causation, this is implausible — a governed definition layer does not manufacture wrong answers. Read as detection, it is the most useful result in this wave. Tracing a confident wrong answer to a specific context defect — a metric defined two ways, a stale table, a document the agent could not see — requires exactly the shared, governed definitions a semantic layer provides. Without one, the same failure occurs and gets logged as a model problem, a user error, or nothing at all. The causation almost certainly also runs backwards in part: enterprises that have been burned repeatedly are the ones who went and built the layer. The size split points the same way, and carries significance where the production split does not. Enterprises above 1,000 employees report recurring context failures at 55%, against 30% of those between 101 and 1,000 (p=0.02) — despite the larger organizations being less likely, not more, to have a semantic layer in production (24% against 37%). Larger enterprises have more instrumentation, more auditing, and more people whose job is to ask why a number was wrong. The practical implication for readers is uncomfortable but clear: a low reported context-failure rate is not evidence of a healthy context layer. It is at least as likely to be evidence that nobody is looking. Finding 3: RAG leads as the context source — and carries the failures Retrieval feeds more agents than anything else, and fails a large share of them We asked what an enterprise’s AI agents primarily use to understand its data. Retrieval leads, but no longer by the margin the category assumes.  Retrieval remains the backbone of enterprise context at 31%, ahead of a governed semantic layer (19%) and mixed approaches (17%). But the tail has thickened in a way worth noting: long-context loading is now the primary source for 13% of enterprises, and 5% let agents run on the model’s general knowledge with no enterprise context layer at all. Between them, nearly one in five enterprises is feeding agents business context either by brute-force context window or not at all. Cross-tabbed against Finding 1, the sources do not fail equally. Among enterprises whose primary context source is retrieval, 87% report a context-traced failure and 48% report it recurring — on the largest base of any group, 31 respondents. Those relying on a governed semantic layer report 79% and 53%; mixed approaches 79% and 36%; direct live-system queries 40% and 30%. The long-context group is the outlier in the other direction, reporting 64% any failure but only 9% recurrence. These subgroup figures should be read with the detection caveat from Finding 2 firmly attached. Groups differ in how well they can attribute a wrong answer to a context defect as much as in how often they suffer one, and the cells here run from 10 to 31 respondents. The retrieval group’s 87% is best read as evidence that RAG-heavy enterprises both experience and notice context failures, not as a clean measurement of relative reliability. What survives the caveat is the structural point. Because so much enterprise context flows through retrieval, and because retrieval carries that load on the widest base in the sample, the quality of retrieval is the quality of the answer. When RAG is the default source, incomplete retrieval is the main point of failure. Finding 4: Model-backed and hyperscaler retrieval still leads the vector databases OpenAI's file search and Google's Vertex AI Search top every purpose-built system We asked which retrieval systems enterprises run in production today. The answer continues to favor the model providers and hyperscalers over the specialists. The dedicated vector database is not the center of the RAG stack. OpenAI’s file search (46%) and Google’s Vertex AI Search (41%) lead by better than three to one over any purpose-built alternative. Among the specialists, the most-used remain the ones enterprises already run for other reasons — Elasticsearch/OpenSearch at 20% and pgvector at 15% — while the pure-play vector databases that define the category (Pinecone, Weaviate, Milvus, Qdrant) each sit between 7% and 12%. Custom in-house retrieval stacks, at 18%, outrank every pure-play vendor. Which system is actually primary separates retrieval from infrastructure Usage counts alone understate the gap, because enterprises run several of these systems at once. We also asked which one is primary. The share of each system’s own users who name it their primary retrieval platform divides the field cleanly. Elasticsearch and pgvector are widely present and rarely primary: four in five of their users retrieve mainly through something else. They are infrastructure the enterprise already ran, pressed into service at the edges of a retrieval stack whose center is elsewhere. Model-backed and hyperscaler retrieval is not merely the most common system on the list; for most of the enterprises that adopt it, it is the system of record. Custom in-house stacks behave the same way — when an enterprise builds one, it is usually the primary, not a side project. The primary-platform question was fielded as a single-select and 18 of 101 respondents selected more than one option, so the shares above are computed as a proportion of each system’s users rather than of the full sample. On the 83 respondents who gave exactly one answer, the ranking is unchanged: OpenAI's file search 28%, Vertex AI Search 23%, custom in-house stack 12%, and no pure-play vector database above 8%. The comparison worth sitting with is what this leaves for the RAG specialists. In a category built around specialist infrastructure, more enterprises have written their own retrieval stack than run any single dedicated vector database — and roughly four times as many use retrieval that arrived bundled with a model provider or cloud they already buy from. Only 7% run no production RAG at all, so this is not a story about early adoption; it is a story about where retrieval gets acquired. Finding 5: No architecture commands a consensus Hybrid retrieval and "It depends on the use case" finish in a dead heat We asked which retrieval architecture enterprises expect to dominate their production RAG systems by the end of 2026. No single answer comes close to a majority — and the two front-runners are separated by one respondent. Hybrid retrieval leads at 30%, with the expectation that no single architecture will dominate at all immediately behind at 29%. The gap is one respondent, far inside the margin on a sample this size, and the honest reading is that these two finish level rather than that either is in front. Together they account for 58% of enterprises, and what unites them is more instructive than what separates them — both describe layered pipelines rather than a single retrieval technique, and neither expects the pure vector-search approach that launched the category to carry production on its own. Two smaller answers carry the sharper signal. Fifteen percent expect tool-first or long-context retrieval to dominate without a dedicated vector layer at all — a direct challenge to the premise of the category — while 12% still expect vector-only retrieval to prevail. That the anti-vector position now edges the pure-vector one, on a three-respondent margin that is itself too narrow to call, is a notable inversion for an industry that spent three years building vector databases. Add the 15% who are unsure or expect no large-scale RAG, and the picture is of a market that agrees vector search alone is insufficient and has not agreed on what replaces it. Finding 6: Enterprises decline to hand the layer to a provider Consolidation onto a provider's native context stack barely registers We asked how enterprises will respond as model providers bundle retrieval, memory, and orchestration into their platforms. Their stated intent cuts sharply against their current usage. Here is the tension at the heart of the stack. Provider-native retrieval leads actual usage by a wide margin (Finding 4), yet just 12% of enterprises intend to consolidate onto a provider’s native context stack. Best-of-breed standalone tools and an explicit mix are tied at the top at 37% each, and 6% intend to build and own the layer themselves — meaning 79% of enterprises expect to keep at least part of the context layer outside any single provider. The gap between what enterprises run and what they say they want is the strategic question of the category. They are adopting bundled retrieval because it arrives with tools they already buy, while asserting they will preserve independence. Read against Finding 2, the stated preference has a rationale beyond vendor politics: the failures enterprises are trying to fix are failures of governed, consistent, access-aware business context, and that is precisely the layer they are least willing to outsource. Whether the preference survives contact with the convenience of the bundle is what the next several waves will decide. Finding 7: Access control climbs into the buying decision Governance now ties ingestion as the reason a system gets chosen We asked what matters most when enterprises choose a retrieval system, and what they treat as the primary measure of success once it is running. The selection criteria have moved toward governance. Access control and permissions (24%) is now exactly tied with ease of data ingestion (24%) at the top, ahead of retrieval accuracy and latency and performance (15% each) and operational simplicity (14%). That puts a governance property at the top of the purchase decision for the first time in this series — and it is the property most directly implicated in the confident-but-wrong failures of Finding 1, where an agent surfaces something it should not have seen or misses something it should have. Once systems are running, the emphasis on correctness is unambiguous: response correctness is the primary success metric for 38% of enterprises, twice the next answer, security and access control (19%). Answer relevance (17%), latency (13%), and operational stability (11%) trail. Taken together, 56% of enterprises measure their retrieval system primarily on whether its answers are right or properly permissioned, rather than on whether it is fast or stable. Satisfaction with current systems is moderately positive: on a five-point scale, overall satisfaction averages 4.13, value for money 4.01, and ease of implementation 3.98. That is a respectable set of scores for a layer that, on this wave’s evidence, is producing recurring wrong answers in nearly four in ten enterprises — which suggests enterprises are rating the tools against expectations of what retrieval infrastructure does, not against the outcome of getting the answer right. Finding 8: Half the market is in motion Vertex AI Search leads the consideration set — and so does uncertainty We asked whether enterprises plan to change or add a retrieval provider, and which they are considering. The consideration set is broader than today’s stack. The retrieval stack is not settled, but it is not churning, either: about half of enterprises have no plans to change, while the other half — 52 of 101 — intend to switch or add a provider within twelve months, a fifth of them within the next quarter. Among those 52 enterprises in motion, Google’s Vertex AI Search leads the consideration set at 35%, followed by Elasticsearch/OpenSearch (25%), Pinecone (23%), and OpenAI's file search (23%). Two patterns stand out. First, the pure-play vector specialists draw markedly more forward interest than their current footprint would suggest — Pinecone is considered by 23% of movers against 12% present usage, Weaviate 17% against 10%, Qdrant 15% against 7%, and Milvus 14% against 9%. The specialists are not winning the installed base, but they are firmly in the evaluation, and each of them roughly doubles its footprint in forward consideration. Second, 15% of movers are evaluating with no shortlist at all and 17% are considering a custom in-house stack — together nearly a third of enterprises planning a change either do not know what they want or intend to build it. The bottom line: A context failure that better detection is only beginning to reveal Organizations with more than 100 employees are running agents on business context they cannot yet guarantee, and the evidence has moved past anecdote. Sixty-eight percent have traced a confident, wrong agent answer to missing or inconsistent context in the past six months, and the recurring case now outweighs the one-off. Retrieval remains the default source of that context and carries the failure on the widest base in the sample — while nearly one in five enterprises has fallen back to long-context loading or the model’s general knowledge, which is not a context layer at all. The most important result in this wave is the one that inverts the expected direction. Enterprises building or running a governed semantic layer report recurring context failures at 50%, against 21% for those without one, and larger enterprises report them at nearly twice the rate of mid-market peers despite being less likely to have the layer built. The straightforward reading is that instrumentation reveals failures rather than causing them, and that the organizations reporting clean context records are largely the ones without the means to check. That reframes the entire finding: the 22% reporting no context failure are not the well-governed cohort, and a low failure rate should be treated as a question rather than an answer. Meanwhile, the fix has not converged. Hybrid retrieval and architectural pluralism finish level as the expectation for production RAG by the end of 2026, one respondent apart; the anti-vector position narrowly edges the pure-vector one; and while provider-native retrieval leads usage by a wide margin — and is the primary system for most of the enterprises that run it — only 12% will consolidate onto a provider’s stack, with 79% keeping some part of the layer independent. The commercial signal is that access control has climbed to tie ease of ingestion as the top buying criterion, and response correctness is the dominant success metric — enterprises are starting to buy retrieval for the properties that govern context rather than the ones that move it. At 101 respondents in a single July wave, skewed toward the mid-market, this is a directional read. But the direction is clear enough to act on: the context layer is the contested tier of the AI stack, the failure it produces is recurring rather than occasional, and the enterprises best equipped to see the problem are the ones reporting it worst. The open question for later waves is whether the governed context layer starts to reduce the failures it is currently so good at exposing. Based on survey responses from 101 qualified enterprise respondents (100+ employees), drawn from a single July 2026 wave. At this sample size the results should be read as a directional signal rather than a precise measurement — this is a self-selected sample, not a probability sample. Respondents include managers, individual contributors, VPs/directors, and C-suite leaders.

8/12/2026

Across 116 enterprises, agents are in production and so are the incidents: A majority have already had a confirmed agent security event or a near-miss. Two-thirds of enterprises enforce scoped permissions at runtime. Barely one in five isolates its highest-risk agents, making containment the weakest layer in the stack precisely as autonomy scales. Credential sharing persists across nearly two-thirds of agent fleets, and 53% have already had a confirmed agent security event or near-miss, contributing to a growing lack of confidence in agentic security.  Security stacks remain overwhelmingly borrowed from model providers and hyperscalers, and confidence has slipped. Today, as many enterprises now believe AI-armed attackers are ahead of their defenses as believe the reverse. This wave of VentureBeat Pulse Research examines how enterprises secure their AI agents: what tooling they run, how they manage agent identity and isolation, what has already gone wrong, how much they spend, and whether they believe their defenses are keeping pace with AI-enabled attackers. Only 18% of enterprises isolate their highest-risk AI agents, even as 65% of enterprises enforce scoped permissions at runtime and 56% monitor and log agent activity. The gap between what enterprises watch and what they contain is the central finding of this wave of VentureBeat Pulse Research.      More than half of enterprises (53%) have agentic AI systems in production today, and another 27% are piloting or running a limited rollout. The agentic security incidents are arriving with them: 53% of organizations have already had an agent security event, with 19% confirming an incident and 38% having identified a near-miss that was caught before it caused harm. The central finding is a containment gap. Enterprises have built the controls that watch and permission agents but not the one that bounds the damage when those fail. Among enterprises describing their security posture, 65% enforce scoped identities and permissions at runtime and 56% observe and log agent activity, yet only 18% isolate high-risk agents in sandboxes. Even among enterprises running agents in production, isolation is enforced just 21% of the time, and just 8% pair enforcement with isolation. That ordering is backward from a defense-in-depth standpoint. From SOC teams to CISOs, security teams know that observation tells you what happened and enforcement tries to prevent it, but isolation is what limits the blast radius when prevention fails. Identity has improved without being solved. 49% of enterprises say each of their agents has its own scoped, managed identity, but 63% report credential sharing somewhere in the agent fleet, and only 29% describe a fleet with scoped identities and no sharing anywhere. The security stack doing this work remains overwhelmingly hyperscaler or model provider-native: OpenAI’s guardrails (44%), Microsoft Azure (42%), Anthropic’s managed-agent controls (37%), and Google Cloud (31%) lead, and 92% of enterprises naming a primary security layer name a hyperscaler/model provider-native one. Two things have shifted against the comfortable picture. Confidence has slipped, with 30% now saying AI-armed attackers are ahead of their defenses, exactly as many as say their defenses are ahead. And churn intent is the highest this series has recorded, with 74% planning to adopt, add, or replace agent security tooling within twelve months, despite satisfaction scores at a series high of 4.29 out of 5. Enterprises are more satisfied than ever with a stack they are more determined than ever to replace. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on enterprise agent security — the tooling, identity, isolation, and enforcement controls organizations use to secure autonomous AI agents. Responses are filtered to organizations with more than 100 employees (n=116; the survey’s smallest size band, 1–100 employees, is excluded), drawn from a single July 2026 wave. Because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends; all figures are drawn from the July fielding only. Several questions were multiple-select, so those shares can sum to more than 100%. By role the sample is senior and buyer-credible: 44% are final decision-makers for AI purchases and another 38% recommenders or influencers. Managers (36%), individual contributors (27%), VPs and directors (18%), and the C-suite (16%) make up the seniority mix. By organization size the sample is mid-market-weighted with a meaningful enterprise tail: 101–250 (34%) and 251–1,000 (23%) employees lead, with 1,001–5,000 (18%), 10,001+ (17%), and 5,001–10,000 (7%) above them. Technology/Software is the largest industry at 38%, followed by Healthcare/Life Sciences (11%) and Financial Services (10%). Three questions require a base note. Two questions were asked only of enterprises with agents live or piloting. Posture figures (observe / enforce / isolate) are reported on those 93 respondents, and primary-security-layer figures on the 92 of them who named a layer. The 23 respondents outside this base are those still evaluating, without plans, or unsure — organizations for which an agent security posture would not yet apply. And several multiple-select questions permitted overlapping answers where one was intended — identity (33 respondents selected more than one pattern), arms-race assessment (23), budget share (10), and incidents (9) — so those are computed at the respondent level and the overlap is described where it matters. Satisfaction ratings are computed on the respondents who answered each rating question; the overall satisfaction score reflects 76 of the 116 qualified respondents. At 116 respondents, the sample supports directional reads but not precise measurement; it is self-selected and is not a probability sample. It is best read as the view from organizations actively standing up agent security rather than from the largest operators. Finding 1: Agents are in production, and so are the incidents A majority have already had an agent security event We asked whether organizations run agentic AI in production, and whether they had experienced an agent security incident — a confirmed breach, or a near-miss caught before harm. Agents have moved into production for this cohort. More than half of enterprises (53%) run agentic AI systems live today, another 27% are piloting or running a limited rollout, and only 3% have no plans in the next twelve months. The security exposure has scaled with the deployment: 53% of organizations have already had an agent security event, 19% a confirmed incident and 38% a near-miss caught before it caused harm. That the near-misses outnumber confirmed incidents two to one is worth reading carefully. It means enterprises are catching problems, but catching them close to the edge — and a near-miss is a control that worked once, not a control that will work every time. The controls examined in the rest of this report, particularly the identity and isolation gaps in Findings 2 and 3, are what determine whether the next near-miss stays a near-miss. One pattern from earlier waves does not replicate here. Organization size makes no reliable difference to exposure: enterprises above 1,000 employees report an incident or near-miss at 47%, against 57% among those between 101 and 1,000 — a difference well inside sample noise, and pointing the opposite direction from the size gradient this series has previously recorded. In this wave, what separates the hit from the not hit is not headcount. Finding 2: Identity is improving — and still shared Half give agents scoped identities; two-thirds still share credentials somewhere We asked how enterprises manage the identity of their AI agents — whether each agent has its own credentials, or agents share them. Respondents could describe more than one pattern across the fleet. Per-agent identity is now the most-cited pattern: 49% of enterprises say each agent carries its own scoped, managed identity, the precondition for least-privilege access and clean attribution. That is real progress on the control this series has repeatedly identified as the structural weakness beneath agent incidents. But the answers overlap, and the overlap is the finding. Thirty-three respondents described more than one identity pattern across their fleet, and rolled together at the respondent level, 63% of enterprises report credential sharing somewhere — either agents mostly running on shared API keys and borrowed human or service-account credentials (37%), or a mixed fleet where some agents are scoped and many are not (34%). Only 29% describe a fleet with scoped identities and no sharing anywhere at all. Among enterprises with agents in production, 60% report per-agent identity, so the improvement is concentrated where the agents actually are — but so is the residual sharing. The consequence is unchanged by the improvement. Where credentials are shared, an over-permissioned or compromised agent acts with far more reach than intended, and post-incident forensics cannot cleanly establish which agent did what. Half a fleet with scoped identities still has the blast radius of the half without. Non-human identity remains the largest unfinished piece of enterprise agent security, and as Finding 8 shows, it is still almost entirely absent from what enterprises are shopping for. Finding 3: Isolation is the control nobody builds Two-thirds enforce at runtime; fewer than one in five sandbox We asked what an organization’s agent security posture looks like in practice — whether they observe, enforce, isolate, or some combination. The control that bounds damage is by far the least common. Figures are reported on the 93 respondents who described a posture. This is the containment gap, and it is the widest structural gap in the report. Enforcement and observation are now common — 65% enforce scoped permissions at runtime and 56% monitor and log agent activity — while isolation sits at 18%. Only 8% of enterprises run both enforcement and isolation together, the posture that both prevents and contains. Deployment maturity is a better predictor than the aggregate figures suggest. Isolation reaches 21% among enterprises with agents fully in production, compared with 13% among those still piloting — a meaningful gap that tracks maturity rather than exposure. Among enterprises that report credential sharing in the fleet, the group with the widest potential blast radius per Finding 2, isolation reaches 15%. The organizations with the most exposure are not meaningfully more likely to have built the control that bounds it. The ordering is backwards from a defense-in-depth standpoint. Observation tells you what happened after the fact. Enforcement tries to stop it. Isolation is what limits the damage when enforcement fails — and enforcement will sometimes fail, which is the entire premise of the near-misses in Finding 1. An agent fleet that is watched and permissioned but not boxed in is precisely the configuration in which a single control failure propagates across systems. Enterprises have built the first two layers of the model and largely skipped the third. Finding 4: Security still runs on borrowed, provider-native controls Nine in 10 name a model provider or hyperscaler as their primary layer We asked which agent security tooling enterprises use, and which is their primary layer. The answer continues to favor the model providers and hyperscalers over the dedicated security vendors. Enterprises secure agents with tools that came bundled with their models and clouds. OpenAI’s guardrails lead at 44%, followed closely by Microsoft Azure (42%), Anthropic’s managed-agent controls (37%), and Google Cloud (31%). Asked to name a single primary security layer, 92% of those who answered named one of these provider-native offerings, with Azure (27% of answerers) and Anthropic (26%) leading. The purpose-built agent-security category is no longer at zero, but it remains marginal. Cloudflare (11%) and Cisco (9%) lead the specialists, with CrowdStrike, Palo Alto, Zenity, Check Point’s Lakera, HiddenLayer, F5, and SentinelOne each between 1% and 7%. The identity specialists most directly relevant to Finding 2 are the smallest of all: Microsoft Entra Agent ID at 7%, Okta for AI Agents at 3%, and non-human identity platforms at 3%. Dedicated runtime sandboxing tooling — the control missing in Finding 3 — is in place at 3%. A note on reading these shares: As described in the methodology section, the respondent sample is self-selected, and the usage question counted every vendor or approach a respondent has in place — so the figures measure presence in the security stack rather than spending or exclusivity. Individual vendor percentages therefore carry all the usual sample caveats. The structural pattern is the durable part: provider-native and hyperscaler controls lead by a wide margin, and dedicated agent-security specialists remain in single digits. Read the individual shares loosely and the pattern with confidence. Finding 5: Satisfaction is at a series high — and so is churn intent Enterprises rate their tooling 4.29 of 5 and three-quarters plan to replace it We asked how satisfied enterprises are with their current agent security tooling, and whether they plan to adopt a new, additional, or replacement solution within twelve months. The two answers do not sit comfortably together. Satisfaction with agent security tooling is the highest this series has recorded — 4.29 out of 5 for both overall satisfaction and ease of implementation, with value for money close behind at 4.11. That is a striking set of scores for a stack that is mostly borrowed provider guardrails, given that a majority of the same enterprises have already had an incident or near-miss and fewer than one in five isolates high-risk agents. The purchase intentions tell the other half of the story. Three-quarters (74%) plan to adopt, add, or replace agent security tooling within 12 months, and 30% within the next quarter alone — higher churn intent than this series has previously seen in this category. Only 26% intend to stand pat. Enterprises are simultaneously more satisfied with their tooling and more determined to change it than at any prior reading, which suggests the satisfaction rests on the convenience and low friction of provider-native controls rather than on demonstrated containment. It is comfort with what is easy, not confidence in what is sufficient. Finding 6: Budgets are finally moving A third now spend more than a tenth of the security budget on agents We asked what share of the security budget enterprises allocate to securing AI agents. The allocation has grown, though it remains a modest slice. Agent security spending is still a slice rather than a pillar, but it is a growing one. The most common allocation remains 6–10% of the security budget (44%), and roughly a third of enterprises (35%) now devote more than a tenth — a meaningful funded minority. Just over a quarter (28%) spend 5% or less. Read against Findings 1 through 3, the budget looks like a lagging but responsive indicator. A majority of enterprises have had an incident or near-miss, credential sharing persists across two-thirds of fleets, and fewer than one in five isolates high-risk agents — gaps that a 6–10% allocation is unlikely to close quickly. The enterprises spending above a tenth are the ones with the resources to build scoped identity and isolation controls rather than adopt whatever their model provider ships, and whether that minority grows is a reasonable leading indicator for whether the containment gap narrows. Finding 7: The arms race has tilted As many say attackers are ahead as say their defenses are We asked how enterprises assess the balance between their AI-enabled defenses and AI-enabled attackers. Confidence has slipped into an even split. Enterprises are no longer net-optimistic about the contest. Exactly as many say AI-armed attackers are ahead of their defenses (30%) as say their defenses are ahead (30%), with another 33% calling it roughly even and 24% saying it is too early to tell. Taken together, 63% rate the balance as even or worse. Experience is what drives the pessimism, and the relationship is statistically clear. Among enterprises that have had a confirmed incident or near-miss, 39% say attackers are ahead; among those that have not, 20% do — a gap large enough to be unlikely to arise by chance in a sample this size. Getting hit does not just change what enterprises buy; it changes how they read the contest. The organizations closest to the actual threat are the least confident about it. That assessment sits uneasily beside the series-high satisfaction of Finding 5. Enterprises rate their tooling 4.29 out of 5 while a clear majority believe it is, at best, holding even against an adversary that is also compounding with AI. An even race is not a comfortable place to be, and the group that has actually been tested rates it worse than even. Finding 8: A reshuffle is coming — but identity still isn’t on the list Incidents drive urgency; the control they implicate draws 10% interest We asked which agent security solutions enterprises are considering. The consideration set has broadened, but not in the direction the incident data points. Incidents start the buying cycle. Among organizations that have had a confirmed incident or near-miss, 38% plan to adopt, add, or replace agent security tooling within the next ninety days, against 22% of organizations with no incident; after a confirmed incident specifically the figure reaches 41%. Experience remains the strongest predictor of urgency in this data, as it is of pessimism in Finding 7. The consideration set still leans provider-native — OpenAI (38%), Microsoft Azure (37%), Anthropic (35%), and Google Cloud (28%) lead — though the dedicated security vendors now draw meaningful early interest: Cisco (10%), Cloudflare (9%), Zenity and CrowdStrike (8% each), and Palo Alto, Check Point’s Lakera, and open-source guardrails (6% each). For most of the specialists that is more forward interest than current footprint. What the shopping still does not include is the identity layer. Just 10% of enterprises include an agent-identity product — Okta for AI Agents, Microsoft Entra Agent ID, or a non-human identity platform — anywhere in their consideration set. Among the enterprises that both share credentials and have already been hit, the group with the most direct evidence that the control matters, identity consideration is no higher: roughly one in ten. Runtime sandboxing tooling draws 6%. The two controls most directly implicated by the incident data, identity and isolation, are the two least present in the purchase plans — the same blind spot this series recorded in the prior wave, unchanged despite a year of incidents. The bottom line: A security gap that prevention alone won’t close Organizations with more than 100 employees have put agents into production — 53% run them live today — and the incidents have arrived alongside them, with a majority already reporting a confirmed event or near-miss. On the controls, the picture is genuinely mixed rather than uniformly poor: nearly half now give each agent its own scoped identity, two-thirds enforce permissions at runtime, and a third devote more than a tenth of the security budget to agents. Enterprises are building agent security in earnest. What they are not building is containment. Fewer than one in five isolates high-risk agents, only 8% pair enforcement with isolation, and among enterprises running agents in production isolation reaches just 21%. Credential sharing persists across 63% of fleets, so the blast radius that isolation would bound remains wide. The stack doing this work is 92% provider-native by primary layer, and the specialists built for exactly these gaps sit in single digits. The result is an architecture optimized to prevent and observe, with almost nothing in place for the case where prevention fails — which is the case the near-misses in Finding 1 describe. The uncomfortable pairing is confidence with exposure, and it has sharpened. Satisfaction is at a series high of 4.29 out of 5, yet 63% rate the contest against AI-armed attackers as even or worse, 30% say attackers are ahead outright, and 74% plan to replace tooling they just rated highly. Enterprises that have actually been hit are markedly more pessimistic and markedly more urgent — and still not shopping for identity or isolation, the two controls their incidents most directly implicate. At 116 respondents in a single July wave this is a directional read, weighted toward the mid-market — but the direction is clear: agent deployment is running ahead of agent containment, and the gap is not in what enterprises watch or permission but in what happens when those controls fail. The containment gap will not be closed by a better provider guardrail. The open question for later waves is whether enterprises build isolation and governed identity deliberately, or whether a confirmed incident that propagates does it for them. Based on survey responses from 116 qualified enterprise respondents (100+ employees), drawn from a single July 2026 wave. This is a directional signal from a self-selected sample, not a probability sample. Respondents include managers, individual contributors, VPs/directors, and C-suite leaders, across technology, healthcare, financial services, and other industries.

8/12/2026

Across 108 enterprises, trust in automated agent evaluation rose sharply in July — and the failure rate it is supposed to predict did not move at all. The share of organizations that fully trust automated evaluation nearly tripled, from 5% in June to 13%, and the complaint that evaluations don’t match real-world outcomes fell 10 points. Yet the same share as last month — just under half — shipped an agent that passed its evals and then failed a customer. The reason is visible in the cross-tabs: the new trust belongs almost entirely to enterprises that have not yet been burned. Among those that have, 4% trust automated evaluation; among those that haven’t, 24% do. And getting burned does not slow the march to autonomy — it speeds it up. This is the second wave of the VentureBeat Pulse Research agent reliability tracker, and the first fielded on an instrument identical to the month before it. That makes July the first read on direction rather than position: what moved, what held, and what the movement means. What moved is confidence. In June, only 5% of enterprises said they fully trusted automated evaluation, and the most-cited limitation was that evaluations align poorly with real-world outcomes (29%). In July, 13% fully trust automated evaluation and the alignment complaint has fallen to 19%, no longer the leading objection. Both shifts are large enough to read as real rather than noise. What held is the failure. Just under half of organizations (49%) deployed an agent or LLM feature in the past year that passed internal evaluations and then caused a customer-facing failure — statistically indistinguishable from June’s 50% — and a quarter (24%) have seen it happen more than once. Confidence improved; correctness did not. That is the July gap: not between autonomy and trust, as in June, but between trust and the evidence for it. The cross-tabs explain where the new confidence comes from, and it is not from better evaluations. Trust is concentrated almost entirely among enterprises that have not experienced a false-confidence failure: 24% of them fully trust automated evaluation, against 4% of those that have. The trust curve is being lifted by inexperience. Meanwhile the enterprises that have been burned are not retreating from autonomy — 85% of them already allow zero-human deployment or are engineering toward it, against 61% of those that have not been burned. Overall the autonomy trajectory is flat at 67%, but the population inside it has shifted toward the organizations with the most direct evidence that evaluations miss things. The vendor market, by contrast, is finally showing signs of settling. The share of enterprises running no dedicated evaluation tooling fell from 17% to 12%; specialist platforms gained, with Braintrust nearly doubling to 15% and DeepEval reaching 17%; and switching intent cooled, with those planning no change rising from 36% to 44%. Selection criteria moved with it: ease of integration overtook cost as the top factor, jumping from 27% to 39%. Enterprises are done shopping on price and have started buying on fit. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series. This wave — the agentic reliability and evals tracker — examines how technical leaders evaluate agent performance and reliability. Responses are filtered to organizations with 100 or more employees (n=108), drawn from a July 2026 fielding. Because the July instrument is identical to June’s, this report makes month-over-month comparisons where they are warranted; where questions were multiple-select, shares can sum to more than 100%. Comparisons against June (n=157) are tested for significance, and only a handful of the month’s movements clear a conventional threshold: the rise in full trust in automated evaluation (5% to 13%), the fall in the real-world-alignment complaint (29% to 19%), the jump in ease of integration as a selection factor (27% to 39%), and the gain in Braintrust as a primary platform (8% to 15%). Movements described in this report as flat — the failure rate, the autonomy trajectory, the production monitoring mix, the investment ranking — are statistically indistinguishable between waves, and that stability is itself the finding. Differences of a few points elsewhere should be read as sample variation, not trend. By role the sample is senior and buyer-credible: 44% are final decision-makers for AI purchases and another 25% recommenders or influencers, a slightly more senior mix than June. Product and program managers (18%), consultants and advisors (12%), CIOs/CTOs/CISOs (11%), and directors of engineering/IT (11%) lead the named titles, alongside a large “Other” function (30%). By organization size the sample is again mid-market-weighted: 100–499 (33%) and 500–2,499 (30%) employees lead, with 2,500–9,999 (23%), 10,000–49,999 (9%), and 50,000+ (5%) above them. One composition change is worth flagging because it bears on the trust finding. The industry mix shifted between waves: Technology/Software fell from 23% of the June sample to 14% in July, while Retail/Consumer rose from 15% to 19% and now leads. A less technology-weighted sample plausibly carries less hands-on exposure to agent evaluation, and some of the month’s rise in trust may reflect who answered rather than what changed. The burned-versus-unburned split reported in Finding 2 holds within the July sample regardless, but readers should treat the headline trust movement as directional. At 108 respondents the sample is large enough to support directional conclusions but should not be treated as a precise measurement; it is self-selected and is not a probability sample. Cross-tabs reported here rest on subgroups of 40 to 68 respondents and are correspondingly coarse. Finding 1: The failure rate did not move Just under half still ship agents that pass evals and fail customers We asked whether, in the past 12 months, organizations had deployed an agent or LLM feature that passed their internal evaluations but then caused a customer-facing failure. The answer is the same as last month. Forty-nine percent of organizations shipped an AI feature that cleared internal evaluations and then failed in front of a customer — an incorrect output, a broken workflow, or a quality incident — against 50% in June. A quarter (24%) have seen it happen more than once, unchanged. Across two waves and 265 enterprises, the rate at which evaluations certify agents that then fail is stable to within a percentage point. That stability is the anchor for everything that follows. Every other movement this month — rising trust, consolidating tooling, shifting purchase criteria — has to be read against a failure rate that has not responded. Whatever enterprises did between June and July, it did not change how often a passing evaluation turns out to be wrong. Finding 2: Trust rose — among those who haven’t been burned Full trust nearly tripled, and the alignment complaint fell ten points We asked which limitation most reduces trust in automated agent evaluations today. The distribution shifted materially from June. Two things moved together: Full trust in automated evaluation nearly tripled, from 5% to 13%, and the objection that most directly describes a false-confidence failure — poor alignment with real-world outcomes — fell from 29% to 19%, surrendering the top spot to evaluation bias and inconsistency (22%), now tied with data-leakage concerns (22%). On the surface this reads as an evaluation layer beginning to earn its keep. The cross-tab says otherwise. Splitting the sample by whether an organization has actually experienced a false-confidence failure, trust divides almost completely. Among the 53 enterprises that shipped an agent which passed evals and then failed a customer, 4% fully trust automated evaluation. Among the 41 that have had no such failure, 24% do — a six-fold difference, and the sharpest split in the dataset. Direct contact with the failure mode is what removes the trust. This is the month’s central caution. The improvement in sentiment is not evidence that evaluations got better; the failure rate in Finding 1 rules that out. It is what a trust curve looks like when a cohort of less-burned organizations enters the sample and reports its priors. Enterprises reading their own rising confidence as validation of their evaluation stack are reading a number that measures inexperience. Finding 3: Being burned accelerates autonomy rather than restraining it 85% of the burned are on the zero-human path, against 61% of the REST We asked whether organizations would let an autonomous agent deploy a code or system change to production on automated evaluation results alone, with no human-in-the-loop validation. The aggregate held; the composition did not. At the top line, nothing changed: 67% of organizations either already allow zero-human-in-the-loop deployment for low-risk agents (37%) or are actively engineering their pipelines to permit it within a year (30%), against 67% in June. The share ruling it out for the foreseeable future slipped from 22% to 18%. The autonomy ceiling stopped rising, but it did not come down. Underneath, the picture inverts the intuitive one. Among enterprises that have shipped an evaluation-passing agent that then failed a customer, 85% are on the autonomy trajectory. Among those that have not, 61% are. Organizations with direct, expensive evidence that their evaluations miss things are substantially more likely to be removing the human check, not less — and only 11% of them rule out full automation, against 24% of those that haven't been burned. The pattern is identical for those burned once and those burned repeatedly. The most plausible mechanism is not recklessness but maturity: the organizations that ship agents at enough volume to hit a customer-facing failure are the same ones with pipelines sophisticated enough to automate, and they are treating the failure as a cost of operating rather than a reason to stop. That is a defensible read. It is also precisely the dynamic that turns Finding 1’s stable failure rate into a growing absolute number of incidents, since the enterprises most likely to fail are the ones scaling their capacity to deploy without review. One June finding did not replicate. Last month, larger enterprises appeared slightly further down the autonomy path than smaller ones (70% versus 64%). In July the two converge — 65% for organizations with 2,500+ employees against 68% below that, with near-identical failure rates (48% and 50%) — which suggests the June gap was sample variation rather than a size effect. Company size is not what separates the aggressive adopters; experience of failure is. Finding 4: The stack begins to consolidate Specialists gain, and the “Nothing at all” share shrinks We asked which agent reliability or evaluation platform enterprises primarily use today. The field is still crowded, but it is no longer tied at the top with nothing. The most consequential number is the one that fell. In June, having no dedicated agent-evaluation tooling was tied for the most common answer at 17%; in July it is 12% and fifth. Enterprises are acquiring evaluation tooling, and the specialists are capturing most of that movement: Braintrust nearly doubled its share of primary usage to 15%, and DeepEval reached 17%. Provider-native tooling held roughly flat — OpenAI at 18%, Anthropic at 12% — meaning the growth came at the expense of running nothing rather than at the expense of the model providers. Counting any use rather than primary platform, the footprints are wider and the ordering is similar: OpenAI native evals reach 31% of enterprises, DeepEval 27%, Braintrust 22%, Anthropic native evals 20%, custom in-house tooling 14%, and Weave and Langfuse 11% each. Nineteen percent still report using no dedicated tooling anywhere in their stack. The category now has three plausible independent contenders where in June it had none with double-digit primary share — the first evidence in this series of an evaluation layer starting to take shape. Finding 5: Production monitoring still watches the wrong thing Half monitor whether the agent runs; under a third monitor whether it’s right Production monitoring for an AI agent can watch two very different things. It can watch whether the system is functioning — is the agent up and responding, did each request complete, how fast, at what cost, with any errors. Or it can watch whether the agent’s output is correct — automated checks that evaluate the content of each answer as it goes out. A confidently wrong answer is invisible to the first kind: the request completes, the response is fast, no error is thrown, and every functioning-metric reads healthy. We asked which kind live production monitoring is built for today. Grouped by what is actually being watched, the split is essentially June’s: 50% of organizations monitor only whether the agent is functioning, while 26% run automated checks on whether its answers are right. Counting ad-hoc reviewers and don’t-knows, nearly three-quarters of organizations have no automated, real-time evaluation of output correctness in production. Inline quality assertions and transaction trace logging are tied as the most common approach at 26% each on a base of 106 — no single monitoring posture leads. This is the finding that most directly contradicts the month’s rising confidence. Trust in automated evaluation went up eight points while the runtime capacity to detect an evaluation being wrong went nowhere. Among enterprises that already permit zero-human deployment, only 28% run inline quality checks on production traffic — which means the majority of organizations that have removed the human from the deployment decision have also not replaced that human with anything watching output quality afterward. The gate is automated and the alarm is not installed. Finding 6: Bought on fit now, not on price Ease of integration overtakes cost as the top selection factor We asked what most influenced enterprises’ choice of an evaluation vendor, and what they treat as their primary measure of success. One answer moved sharply; the other did not move at all. Ease of integration jumped 12 points to 39% and displaced cost as the leading selection criterion, the clearest purchasing shift in the data. Evaluation accuracy rose modestly to 28%, cost fell to 23%, and breadth of observability (6%) and vendor roadmap (2%) remain marginal. Read alongside Finding 4, the two move together: enterprises adopting their first dedicated evaluation tooling are optimizing for what will slot into an existing pipeline this quarter, not for what is cheapest or most capable in the abstract. That is what a market looks like when it stops evaluating and starts installing. What did not move is what enterprises want from the tool once installed. Evaluation consistency remains the primary success metric at 38%, essentially identical to June’s 36%, well ahead of reduction in failures (20%), speed of experimentation (18%), production visibility (16%), and compliance (7%). The priority is still repeatability — the same verdict on the same behavior every time — which is notable given that bias and inconsistency is now the top-cited trust limitation in Finding 2. Enterprises are buying for integration and measuring for stability, and are not yet getting the second. Satisfaction with current tooling remains moderate, averaging 3.9 on a five-point scale across overall satisfaction, ease of implementation, and value for money, barely changed from June’s 3.8. Finding 7: Human review becomes the top line item And the enterprises that have been burned fund it hardest We asked which reliability and evaluation investment will grow most over the next year. Human review edged into first place. Human review workflows (31%) and production observability (30%) swapped positions at the top, a change small enough to be noise on its own — but the underlying pattern is the same one June identified and it has strengthened. Enterprises plan to grow spending on human reviewers faster than on the automated evaluation pipelines (19%) that would replace them, at the same moment two-thirds are engineering the human out of the deployment decision. Only 6% report a flat budget, down from 8%. The cross-tab makes the hedge explicit. Among enterprises that have shipped an evaluation-passing agent that failed a customer, 38% name human review as their fastest-growing investment; among those that have not, 24% do, and they favor observability tooling instead. So the burned cohort is doing both things at once: it is the most aggressive on autonomy (85% on the zero-human path, per Finding 3) and the most committed to funding human reviewers. That is not a contradiction so much as a strategy — automate the deployment decision, and pay people to catch what the automation misses. Whether that scales is the open question, since human review is the one part of the stack that does not get cheaper as agent volume grows. Finding 8: The switching wave cools Those planning no change rise from a third to nearly half We asked whether enterprises plan to adopt a new, additional, or replacement evaluation platform, and which they are considering. Fewer are shopping than last month. A majority (56%) still intend to adopt a new, additional, or replacement platform within twelve months, but that is down from 64%, and the near-term cohort thinned from 31% to 24%. The share standing pat rose from 36% to 44%. Neither movement clears a significance threshold on its own, but both point the same direction, and they point it consistently with Finding 4: as enterprises actually acquire tooling, the population still looking for it shrinks. The consideration set has reordered, too. Among the 60 enterprises planning a change, OpenAI’s native evals lead what they are evaluating (20%), followed by Braintrust (18%), Weights & Biases Weave (12%), and DeepEval (10%), with a further 10% actively evaluating but holding no shortlist. DeepEval led June’s consideration set at 20%; it has since converted much of that interest into primary usage, which is what a consideration-to-adoption handoff looks like. Braintrust now occupies the position DeepEval held — high interest ahead of installed base — and is the vendor to watch in the next wave. The bottom line: Confidence moved, correctness didn’t June found a gap between the autonomy enterprises were granting their agents and the trust they placed in the evaluations meant to govern it. July finds that gap closing from the wrong side. Trust rose — full confidence in automated evaluation nearly tripled and the complaint that evaluations miss reality fell ten points — while the thing that trust is supposed to track held exactly still. Just under half of enterprises still ship agents that pass their evals and then fail a customer, the same as last month. The cross-tabs locate the new confidence precisely, and it is not in the evaluations. Twenty-four percent of enterprises that have never had a false-confidence failure fully trust automated evaluation; 4% of those that have do. Trust in this market is a function of exposure, not of evidence. And exposure does not produce caution: the burned cohort is the most autonomous in the sample, with 85% already deploying without human review or building toward it. What it produces instead is a hedge — the same organizations fund human review workflows hardest, at 38%, while removing humans from the deployment gate. The vendor market is the month’s genuinely encouraging story. Running no dedicated tooling fell from 17% to 12%, specialists gained real share for the first time in this series, buyers shifted from price to integration fit, and switching intent cooled as adoption completed. An evaluation layer is finally forming. But the runtime picture has not followed: half of enterprises still monitor only whether their agents are running, and among those that already deploy without human review, just 28% run real-time checks on output quality. At 108 respondents in a mid-market-weighted, self-selected sample, and with an industry mix that shifted away from technology between waves, this is a directional read. The direction, though, is legible: enterprises are tooling up, buying for fit, and growing more confident — and none of that has yet changed how often a passing evaluation turns out to be wrong. The question this series carried out of June was whether assurance would catch up to autonomy. July’s answer is that confidence caught up first, which is the harder problem, because an enterprise that trusts a broken gate has less reason to fix it than one that knows the gate is broken. This report presents the July 2026 wave of an ongoing longitudinal series on enterprise AI agent reliability and evaluation, based on 108 qualified respondents at organizations with 100 or more employees. Comparisons are drawn against the June 2026 wave (n=157), fielded on an identical instrument. At this sample size, results should be read as a directional signal rather than a precise measurement — the sample is self-selected, not a probability sample. Respondents span final decision-makers, technology recommenders/influencers, and end business users, across a mid-market-weighted range of industries and company sizes.

8/12/2026

Across 107 enterprises, agentic orchestration is not a choice of a single platform. The typical enterprise runs three orchestration platforms at once, and selects them for flexibility across models rather than affinity to any single one. Microsoft leads primary usage while Anthropic leads forward consideration by a wide margin.  The AI control plane enterprises expect is deliberately hybrid, meaning it includes use of the leading AI providers, but also provider-independent technologies — and the risk they fear most from provider-resident control is not lock-in but the provider’s own security and permissioning limits.  One in five enterprises still has no real-time way to stop a runaway agent before the bill arrives. This wave of VentureBeat Pulse Research examines enterprise agent orchestration: which platforms enterprises run on, what drives the choice, what they optimize for, how they expect agent control to be structured, and — most revealingly — how orchestrated their deployed “agents” actually are and how tightly they control the cost of running them. The central finding is that orchestration has become plural. Eighty-five percent of enterprises run two or more orchestration platforms and 64% run three or more, with a mean of 3.1 platforms per organization. Microsoft AI Foundry / Copilot Studio appears in 70% of stacks and OpenAI’s Agents SDK in 68%, with Anthropic’s Claude Platform in 47%. Asked to name a single primary platform, respondents who gave one unambiguous answer put Microsoft first (41%) and Anthropic second (28%). Nobody in this sample is running one orchestration layer and calling it a strategy. The selection logic follows from that plurality. Flexibility across models and tools is the leading purchase driver at 29%, nearly three times the share naming model gravity — native alignment with a state-of-the-art base model — at 10%. Enterprises are not choosing the orchestration environment that comes with their favorite model; they are choosing the one that does not commit them to any model. Security and permissions (17%), production reliability (15%), and control over agent execution (15%) fill out a buying logic focused on governance and optionality rather than developer convenience. A clear majority (53%) expect a hybrid control plane by the end of 2026 — provider-native plus external orchestration — and the risk they most associate with provider-resident control is security and permissioning limitations (37%), ahead of vendor lock-in (23%) and limited visibility (22%). Investment has moved accordingly: agent monitoring and debugging leads the spend at 31%, with security and permissions enforcement at 30%, while workflow tooling draws 19%. Enterprises are spending to see and govern agents, not merely to build them. Most companies admit that a majority of their “agents” are really just chatbots. A plurality of 47% of respondents say that between 26 and 50% of their agents are genuinely orchestrated, with 37% at a quarter or below and 16% past the halfway mark.  But fiscal control remains the soft spot: 21% of enterprises track agent spend only through post-hoc logs, with no real-time way to halt a runaway execution loop. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series, with this instrument focused on enterprise agent orchestration. Responses are filtered to organizations with 100 or more employees (n=107), drawn from a single July 2026 wave; because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. All figures in this report come from the July fielding only. Where questions were multiple-select, shares can sum to more than 100%. This wave draws a notably large-enterprise, technology-heavy sample, and that shapes every finding in it. By organization size, more than half sit at 10,000 employees or above: 50,000+ (26%) and 10,000–49,999 (25%) lead, followed by 2,500–9,999 and 500–2,499 (19% each) and 100–499 (11%). Technology/Software accounts for 53% of respondents, with Government/Public Sector (16%) and Manufacturing/Industrial (10%) next. By role the sample is hands-on and technical: software and ML engineers (22%), product and program managers (21%), directors of data/AI/analytics (17%), and VPs of data/AI/analytics (12%). On purchasing, 90% are recommenders, influencers, or final decision-makers for AI solutions (63% recommender/influencer, 27% final decision-maker). A note on the primary-platform question. Forty-six of 107 respondents registered more than one selection on a question intended to capture a single primary platform. Because those responses cannot be resolved to one answer, primary-platform shares are reported on the 61 respondents who gave a single unambiguous answer, and are labeled as such wherever they appear. Platform footprint figures — which platforms an enterprise uses at all — use the full n=107 base and are unaffected. The ambiguity is worth noting on its own terms: on a question asking for one platform, more than four in 10 respondents could not or would not narrow to one, which is consistent with the multi-platform pattern documented in Finding 1. At 107 respondents the sample is robust enough to read directionally with reasonable confidence, though it remains self-selected and is not a probability sample. Because each subgroup here only includes about 50 to 60 respondents, splits between them are less precise than the full-sample findings. Finding 1: Orchestration is a portfolio, not a platform The typical enterprise runs three orchestration platforms at once We asked which agent orchestration platforms enterprises use, and which one they treat as primary. The first answer is that almost nobody has just one. The defining feature of this layer is plurality. Only 15% of enterprises run fewer than two orchestration platforms; the median organization runs three, and one in six runs five or more. Read that way, the platform “shares” below describe overlapping deployments rather than a divided market — Microsoft and OpenAI each appear in roughly seven of ten stacks precisely because most stacks have room for several. Asked to name one primary platform, the 61 respondents who gave a single unambiguous answer put Microsoft AI Foundry / Copilot Studio first at 41%, Anthropic’s Claude Platform second at 28%, LangChain / LangGraph at 10%, and OpenAI’s Agents SDK at 7%, with Google, Amazon, Salesforce, and custom in-house builds at 3% each. Microsoft’s lead on primary usage alongside OpenAI’s near-equal footprint on any usage is the signature of an enterprise-weighted sample: the Microsoft platform arrives through an existing enterprise agreement and becomes the default seat of record, while other platforms are added around it for specific work. A note on reading these shares: As described in the methodology section, the respondents are self-selected, this wave skews heavily toward large technology organizations, and the primary-platform figures rest on a 61-respondent subset. The numbers measure where this cohort has placed its orchestration bets today, within a self-selected audience of AI-active technical practitioners. A sample built this way can diverge substantially from spend-weighted market measures, and each VB Pulse survey draws its own sample with its own company-size and industry mix, so vendor figures should not be compared across our surveys, either. Respondents rate the platforms they run at 4.17 out of 5 for overall satisfaction, 3.91 for ease of implementation, and 3.63 for value for money — with value for money the weakest of the three by a clear margin. That ordering is itself a finding: enterprises are broadly happy with what these platforms do and distinctly less happy with what they cost, which is the same nerve the fiscal-control finding touches at the end of this report. Satisfaction sits alongside a two-thirds intent to change platforms within the year; this remains a layer enterprises work with rather than settle on. Finding 2: Flexibility, not model gravity, drives selection Enterprises buy the orchestration layer that doesn't commit them We asked what most influenced the orchestration platform choice, and optionality leads by a distance. Flexibility across models and tools (29%) is the selection-side explanation for the multi-platform reality in Finding 1: enterprises are choosing orchestration environments on the strength of what they leave open rather than what they lock in. Model gravity — picking the orchestration layer that comes with a preferred frontier model — draws just 10%, less than a third of the flexibility share, which places the pull of any single base model well down the list of what actually decides this purchase. The next tier reinforces the governance emphasis. Security and permissions (17%), production reliability (15%), and control over agent execution (15%) together account for 47% of responses: nearly half of enterprises pick their orchestration platform on whether they can constrain and depend on what it runs. Ease of development draws 8% and total cost of ownership 4%, an inversion of how these platforms are usually discussed in engineering circles. Performance sits last at 2% — at this stage of adoption the binding constraints are optionality and control, not raw speed. Finding 3: The job is reliable multi-step execution Enterprises judge orchestration by whether it completes the work We asked what enterprises optimize for — their primary success metric for orchestration. Reliability and multi-step workflow management lead, with developer productivity closer behind than in the buying criteria. Task completion reliability (30%) and multi-step workflow management (27%) together account for 57% of responses: orchestration succeeds, in the enterprise view, when it reliably carries a task through multiple steps to completion. Developer productivity takes a substantial 23% — notably higher than ease of development’s 8% as a purchase driver in Finding 2, which suggests enterprises do not expect to buy developer velocity so much as to earn it once the platform is in place. End-user experience is a minor concern at 7%, consistent with orchestration being an internal execution problem rather than a UX one. This reliability-first standard is the yardstick against which the portfolio-maturity finding later in this report should be read: enterprises define success as dependable multi-step execution, and a little over a third of them still say a quarter or fewer of their deployed agents do multi-step work at all. Finding 4: Two-thirds plan to move — and Anthropic leads the consideration set The installed base and the pipeline point to different vendors We asked whether enterprises plan to adopt a new, additional, or replacement orchestration platform in the next 12 months, and which platforms they are considering. Two-thirds of enterprises (67%) intend to adopt a new, additional, or replacement orchestration platform within the year, but the clock runs longer than the intent suggests: the largest cohort sits at 6–12 months (28%) and only 15% expect to move within a quarter. This is deliberate re-platforming on a planning horizon, not urgent churn. The consideration set is where this finding earns its headline. Among the 72 enterprises in motion, Anthropic leads at 43% — well ahead of Google (31%), custom in-house builds (31%), OpenAI (25%), LangChain / LangGraph (17%), and Microsoft (17%). Set that against Finding 1, where Microsoft leads primary usage and appears in 70% of stacks: the installed base and the forward pipeline point at different vendors. Anthropic draws roughly two and a half times Microsoft’s forward consideration despite trailing it on current primary usage, and custom in-house control planes draw as much interest as any external platform besides Anthropic. A further 18% of movers are evaluating with no shortlist at all. Read alongside the flexibility-first selection logic in Finding 2, the shape of the next twelve months is legible: enterprises expect to add rather than replace, they are shopping for platforms that preserve model choice, and a substantial minority intend to solve the problem themselves rather than buy it. Finding 5: Investment flows to watching and governing agents Monitoring and permissions lead the spend; workflow tooling trails We asked which orchestration-related investment will grow most next year. Observability and governance take the top two places. Monitoring and debugging (31%) and security and permissions enforcement (30%) are effectively tied at the top and together account for 61% of planned growth. The money is going to seeing what agents do and constraining what they are allowed to do — the two capabilities that matter once agents are running in production rather than being built toward it. Workflow tooling (19%) and scaling infrastructure (18%) trail, and almost no one is standing still: just 3% report a flat budget. The emphasis is consistent with the buying logic in Finding 2, where security and permissions was the second-ranked selection factor, and with the control-plane architecture in Finding 6. Enterprises that have decided to run agents across three platforms have a visibility and permissioning problem by construction, and they are funding it directly. Finding 6: The control plane will be hybrid — and security is why Enterprises split control, and fear the provider's permissioning more than lock-in We asked where enterprises expect the primary control plane for agents to live by the end of 2026, and what worries them most if that control sits inside a model-provider platform. Hybrid control is the dominant expectation by a wide margin (53%). Taken together, the hybrid, custom in-house, and externally-abstracted options — every architecture that keeps control at least partly outside the provider — sum to 78% of enterprises, against 14% willing to hand control to a provider-managed service outright. The reason enterprises give is worth separating from the one usually assumed. Security and permissioning limitations lead the risk question at 37%, well ahead of vendor lock-in at 23%, with limited visibility and observability close behind at 22%. Combining the security and visibility answers, 59% of enterprises name a control-and-oversight concern rather than a commercial one. The worry is less that a provider platform will be hard to leave than that it will not let them see or constrain what their agents are doing while they are on it — the same concern funding the monitoring and permissions spend in Finding 5. Only 2% say provider-resident control is not a concern at all. Finding 7: The chatbot trap is loosening, not broken “Bridging the gap” is now the modal answer on portfolio maturity We asked enterprises to assess their portfolios honestly: What share of their deployed “agents” are true multi-step orchestrated workflows versus simple single-prompt chatbot wrappers. The center of gravity has moved into the middle band. Just under half of enterprises (47%) now put between a quarter and half of their portfolio in genuinely orchestrated, stateful workflows, and 16% are past the halfway mark. The bottom two bands — a quarter or fewer genuinely orchestrated — account for 37%, and outright pure-chatbot portfolios have nearly vanished at 3%. Against the reliability-first success standard in Finding 3, this is a portfolio that has started to do the work the orchestration layer exists for, without most of it being there yet. Maturity tracks platform count. Enterprises reporting a quarter or less genuine orchestration run 2.8 platforms on average; those in the 26–50% band run 3.5. The organizations furthest into real multi-step work are the ones running the most orchestration platforms at once, which is the practical case for the flexibility-first selection logic in Finding 2 — multi-step portfolios appear to accumulate platforms rather than converge on one. One split that might be expected does not appear. Organization size makes no difference to portfolio maturity in this wave: 38% of enterprises at 10,000+ employees report a quarter or less genuine orchestration, against 37% of smaller ones, and the shares past the halfway mark are equally close (16% and 15%). Whatever separates the mature portfolios from the immature ones here, it is not headcount. Finding 8: Fiscal control is still reactive for one in five A fifth of enterprises learn about a runaway agent from the logs Finally, we asked how enterprises enforce fiscal control over agent token consumption — the risk that an autonomous loop exhausts a budget before anyone intervenes. The approaches split four ways, fairly evenly. One in five enterprises (21%) has no real-time, programmatic way to stop an agent before a budget-breaking bill arrives — they learn of it from the logs afterward. Another 30% lean entirely on the native caps and throttles built into their primary platform, a control only as good as the provider’s tooling and one that sits awkwardly beside the hybrid, keep-control-outside posture of Finding 6. Roughly half of enterprises — those building custom gateways (25%) or exploiting cross-model routing to arbitrage cost (24%) — are treating token burn as an engineering problem to be controlled deterministically, and the routing group is doing so in a way that only works because they run several platforms at once. Unlike previous waves, no size split appears here: 18% of enterprises at 10,000+ employees exercise only reactive control against 23% of smaller ones, a difference well within sample noise. The gap in fiscal control in this wave is not between large and small enterprises but between those that have built a cost-control plane and those still relying on whatever their provider ships. Read against the satisfaction scores in Finding 1 — where value for money was the weakest of three ratings at 3.63 — the picture is of a cohort that is unhappy about what agents cost and, in half of cases, not yet instrumented to do much about it. The bottom line: Plural by design, governed by intention, metered by hope Organizations with 100 or more employees describe an orchestration strategy built around optionality rather than commitment. They run three platforms on average, choose them for flexibility across models rather than affinity to any one, and judge them on whether they carry multi-step work reliably to completion. Microsoft anchors the installed base and appears in seven of ten stacks; Anthropic leads forward consideration by a wide margin among the two-thirds planning a change; and a substantial minority intend to build their own control plane rather than buy one. Today’s footprint describes where these enterprises are, and clearly does not describe where they intend to stay. The governance posture is deliberate and consistent. A hybrid control plane is the majority expectation, 78% intend to keep control at least partly outside the provider, and the reason is not commercial but operational — security and permissioning limits (37%) and limited visibility (22%) outrank vendor lock-in (23%) as the fear attached to provider-resident control. The budget follows the fear: monitoring and debugging and security and permissions enforcement together take 61% of planned investment growth, ahead of the tooling used to build agents in the first place. Where the strategy thins out is cost. Portfolio maturity has moved into the middle — 47% now report between a quarter and half of their agents genuinely orchestrated, and pure-chatbot portfolios have nearly disappeared — but 21% still cannot stop a runaway agent in real time, another 30% depend on whatever caps their provider ships, and value for money is the lowest-rated attribute of the platforms they run. Enterprises have worked out how they want agents governed well before they have worked out how to meter them. At 107 respondents in a single July wave, skewed toward large technology organizations, this reads as a clear directional signal rather than a precise measurement. The questions for subsequent waves are whether the middle band of portfolio maturity keeps climbing, whether the forward consideration for Anthropic and for in-house control planes converts into deployment, and whether fiscal control catches up to a cost that enterprises already say they are not getting their money’s worth on. Based on survey responses from 107 qualified enterprise respondents (100+ employees), drawn from a single July 2026 wave. This is a self-selected sample rather than a probability sample, and figures should be read directionally rather than as precise measurement. Respondents include software/ML engineers, product/program managers, directors and VPs of data/AI/analytics, enterprise architects, and directors of engineering/IT, across technology/software, government/public sector, manufacturing/industrial, and financial services organizations.

8/11/2026

SpaceXAI, the division of SpaceX formerly known as xAI, is launching an early beta version of Grok Bot, a new agent designed to move AI assistants beyond answering prompts and toward continuously executing work across the software employees already use. The central idea is straightforward: instead of opening an AI assistant whenever a task arises, users create persistent Bots with specific jobs, give them access to applications and websites, and delegate work much as they would to a teammate. Each Bot operates through its own computer environment, can continue working when the user's laptop is closed, and can return when it needs approval or has finished the assignment. SpaceXAI says the system began as an internal prototype before spreading across the company, where teams created Bots for sales outbound, marketing campaigns, office operations, bug fixes and other work. The company is now turning that internally developed workflow into a product for external users. “Bots are AI teammates that do real work for you,” the company said in announcing the product. “They sign in to your tools, use them just like you do, and come back with finished work.” The company did not release benchmarks for Grok Bot's performance on agentic tasks. And it arrives amid an increasingly crowded marketplace of first-party AI agents that attempt to reliably complete real, enterprise workflows by interfacing with a user's other applications and devices. Anthropic introduced computer use for Claude in 2024, allowing models to inspect screens and operate interfaces through mouse and keyboard actions, and continued expanding with the launch of the developer focused Claude Code harness in early 2025 and the more non-technical, white collar focused Claude Cowork agent early this year. Meanwhile, OpenAI gave its Codex harness the ability to control other computer apps in April, launched agentic Workspace Agents that can also connect to third-party applications and use them autonomously, and recently debuted a new ChatGPT Work environment for longer, multi-step tasks and finished deliverables. Grok Bot seeks to join the party with its own management model for agents: persistent workers with responsibilities, memory, learned routines and the ability to hand work to one another. Pricing and availability: Grok Bot starts at $120 per seat per month for teams, $200 per month for individuals Grok Bot is available beginning today, August 11 in beta for SuperGrok Heavy, Cursor Ultra and Cursor Premium Teams subscribers (recall SpaceX acquired Cursor for $60 billion back in June). The product arrives for macOS, Windows, Linux and iOS, with Android listed as coming soon. According to its product page on xAI.com, Grok Bot is included with Cursor Ultra at $200 per month for individuals. The plan includes a computer for Grok Bot, access to users' tools, scheduled routines, desktop and mobile operation, and extended AI-token limits. For organizations, Cursor Premium Teams costs $120 per seat per month and adds centralized billing and settings, a team marketplace for skills and plugins, shared usage analytics and SAML/OIDC single sign-on. Existing SuperGrok Heavy ($300 per month) subscribers also receive access. However, for organizations wishing to sign up today, SpaceXAI is directing them to a waitlist for future access. Those prices make Grok Bot a substantially different purchasing decision from a low-cost general AI subscription. The economic question for companies will be whether persistent Bots can replace enough manual work or conventional automation infrastructure to justify the per-user cost — and how usage limits affect total cost once agents begin running continuously. From prompting an AI to managing one SpaceXAI describes Grok Bot as a team of “always-on agents.” Users can create multiple Bots, assign each a role and let them work simultaneously. The company provides examples including Sales Outbound, Talent Scout, Paid Media, Expense Manager, Product Performance, Bug Reproduction, Account Health and Chief of Staff. A sales Bot, for example, can research accounts, score prospective contacts, prepare email and LinkedIn outreach in the user's voice, and assemble the results for human approval. Promotional materials show SpaceXAI using the system internally for substantially longer chains of work. One sales Bot can add call-transcript notes to a CRM and draft follow-up messages. An operations Bot can seat new hires and process invoices arriving through Gmail. An engineering Bot can reproduce a bug in the product interface, file a ticket and then hand the repair to a debugging Bot. The architecture could make Grok Bot particularly relevant for workflows that span systems that were never designed for AI automation. Rather than requiring every application to expose an API specifically for an agent, Grok Bot can sign into applications and websites and operate their interfaces. SpaceXAI says Bots have their own computers and can continue working 24/7. The company explicitly says this includes websites and applications that have “no clean API or MCP,” an important distinction for enterprises with legacy software, fragmented SaaS environments or internal systems that have never been instrumented for agent access. Instead of limiting automation to formally integrated services, Grok Bot is designed to work through the same software interfaces a human employee would use. The company says early users are already applying Bots to jobs including vendor negotiations, e-commerce customer support and continuously updating CRM systems. Another feature attempts to reduce the engineering required to automate repeatable business processes. Users can demonstrate a workflow while a Bot follows along. Grok Bot can then save the process as a routine and execute it later without requiring the user to reproduce every instruction. SpaceXAI says the Bot can also incorporate corrections into those learned routines, allowing the workflow to change as the user teaches it how a particular process should be handled. That potentially changes the deployment model from explicitly programming an automation to teaching an agent how an employee performs the job. The company is also claiming a more persistent form of behavioral memory than simply retaining a chat transcript. According to the launch announcement, Bots remember prior conversations, learn preferences such as a user's writing voice and edge cases, and gradually learn when they should interrupt for approval versus continue independently. SpaceXAI says they can later resume dropped threads, nudge stalled handoffs and pick up work from earlier conversations. It further says Bots can become proactive over time, sometimes identifying work before the user explicitly asks for it. That is a more ambitious claim than conventional scheduled automation and will put additional pressure on permission controls and escalation rules if the system is deployed against production applications. Bots can delegate work to other Bots Grok Bot also supports multiple agents operating together. Users can place several Bots into the same thread, where the agents can pass work between one another. The company's demonstration includes specialized Research, Communications, Chief of Staff and Travel Bots coordinating tasks. SpaceXAI says those Bots can independently message one another and share context within threads. Users can also put multiple Bots into a group conversation where they assign ownership, transfer work and coordinate among themselves, bringing the human back in primarily for judgment calls. Internally, the company says employees sometimes place a Chief of Staff Bot above specialist Bots responsible for functions such as inbox management, recruiting, expenses, operations and bug fixes. That makes the product's orchestration model more explicit: the user does not necessarily have to serve as the routing layer between every specialized agent. Initial reactions are extremely positive Lenny Rachitsky, host of the popular vlog and podcast Lenny's Podcast and author of newsletter Lenny Letter, received early access to Grok Bot and loved using it. As Rachitsy wrote on X : "I haven't been this excited about a new AI product in a while. It's like OpenClaw, but super easy, reliable, and less scary to use. I think this will be a huge new product line for Cursor/Grok/SpaceX." Similarly Matt Shumer, an AI entrepreneur who said he tested Grok Bot for several weeks before launch, highlighted this orchestration as one of the product's strongest features. “The best way I can describe it is an agent for everything, not just code,” Shumer wrote on X. In one test, Shumer said he created separate researcher and writer Bots, then created a Chief of Staff Bot and instructed it to coordinate the other two on a project. He expected the workflow to break down. “It worked out of the box,” he wrote. His main criticism involved model selection. Unlike systems where developers or advanced users explicitly select the underlying model, Shumer said Grok Bot automatically routes tasks to models on the backend. “You don’t choose a model for your Grok Bot,” he wrote. “It’s all done automatically on the backend.” Shumer said the model router “wasn’t great” during his testing, although he said he was subsequently told it had improved. SpaceXAI's expanded announcement still does not identify which underlying models the router uses, nor does it document a mechanism for users to select, pin or switch to a particular xAI or third-party model. As a result, the model layer remains largely abstracted from users in the publicly supplied launch material. That abstraction represents an important tradeoff for enterprise deployments. Automatic routing can remove a significant configuration decision for ordinary employees, but advanced users may want explicit control over model cost, latency, reliability and behavior — particularly for repeatable production workflows. The agent market is moving toward longer-running work Grok Bot enters a market increasingly focused on agents that can do more than generate text or code. Anthropic's computer-use capability established a mechanism for Claude models to interact with software through screenshots, cursor movements, clicks and typing. Its broader Claude product also connects with workplace services and remote MCP servers. OpenAI, meanwhile, now describes ChatGPT Work as an agent for “longer, multi-step work and finished deliverables,” while keeping Codex focused specifically on software development. OpenAI's enterprise agent economics can also incorporate usage-based credits, making task complexity and token consumption part of deployment cost calculations. Grok Bot's differentiation is therefore less about proving that AI can operate software than packaging computer use, persistence, workflow learning and multi-agent coordination into something resembling a workforce interface. SpaceXAI's announcement sharpens that distinction by emphasizing completion rather than assistance. One company product employee, identified only as Roman, describes the difference as closing the gap between work that is nearly finished and work actually completed inside the destination application: “Grok Bot can finish the swing, because the work lands where a human would put it, in the actual tool.” That distinction will ultimately depend on reliability. A chatbot producing a bad answer creates a correction problem. An autonomous agent operating CRM records, support queues, vendor conversations or other production systems can create an operational problem. Grok Bot's success will therefore depend not only on model intelligence, but also on permissions, predictable execution, escalation behavior, memory accuracy and how reliably agents recognize when human approval is necessary. That challenge becomes more significant if Bots act proactively, resume forgotten work and coordinate with one another without the user serving as an intermediary. Those capabilities reduce the amount of supervision required when they work correctly, but they also expand the consequences of an incorrect assumption, stale context or improperly scoped permission. The interface may matter as much as the models Shumer described the product's interface as feeling like iMessage, an intentionally familiar metaphor for a system whose underlying architecture — autonomous computers, persistent memory, agent orchestration and automatic model routing — could otherwise be difficult for nontechnical users to configure. SpaceXAI makes essentially the same usability argument in its launch announcement. Rather than asking users to construct workflows before getting started, it says users can simply message a Bot from a phone or desktop, hand it work and later continue the same conversation from either device. That simplicity is part of the product strategy. Grok Bot is trying to hide much of the conventional machinery of automation — workflow builders, explicit integrations, agent routing and orchestration — behind an interaction model that resembles messaging a coworker. That may prove to be the larger bet behind Grok Bot. The AI industry has spent several years making models increasingly capable of using tools and completing multi-step tasks. Grok Bot attempts to turn those capabilities into an organizational abstraction people already understand: give someone a job, teach them how you work, and let them coordinate with the rest of the team. If that abstraction proves reliable, the enterprise agent competition may increasingly shift away from which assistant produces the best individual response and toward which platform can most reliably manage fleets of agents performing ongoing work.

8/11/2026

Presented by Rezolve Ai When an AI assistant recommends a product or brand, it generates something valuable: a purchase-ready consumer with high intent and low friction in their decision. That consumer has already compared options, asked follow-up questions, and arrived at a conclusion. They want to buy. What they encounter next is a commerce infrastructure that was not designed for them. The gap between recommendation and purchase The typical enterprise commerce stack was built for a specific model: a consumer who arrives at a brand's website through search or a direct link, navigates product pages, adds to cart, and completes checkout through a multi-step form flow. That model assumed the consumer would do the work of bridging their intent to the transaction. Most commerce systems still assume exactly that. Agentic commerce breaks that assumption. When intent is generated outside the brand's owned environment, the handoff to transaction becomes a structural problem. Context doesn't transfer. Sessions don't persist. The consumer who asked an AI assistant for a recommendation and received one now faces the same friction-laden checkout process as someone who arrived with no prior intent at all. Cart abandonment rates have remained stubbornly high for years. Baymard Institute research puts the average at 70%. That figure predates the agentic commerce era. As more purchase intent is generated through AI interfaces, and as the gap between that intent and a brand's transaction layer widens, the abandonment problem is likely to get structurally worse before it gets better. What the current stack wasn't built to handle The commerce infrastructure most enterprises operate today was assembled over two decades of incremental investment. Each layer added a capability: a search tool, a recommendation engine, a personalization layer, and a checkout system. Each was built to solve a specific problem within a human-initiated shopping journey. None of it was built to receive intent from an AI agent. When an AI system generates a purchase recommendation, it needs to do more than surface a product page. It needs to verify real-time inventory. It needs to apply pricing logic and promotional rules. It needs to respect brand policy around which products can be recommended together, which channels apply which discounts, and what the correct fulfillment path looks like for a given consumer. And it needs to do all of that without breaking the conversational context that made the recommendation possible in the first place. Current commerce stacks can't do this reliably. The systems that hold the relevant data, inventory, pricing, order management, fulfillment, are not exposed in ways that AI agents can safely and accurately access. The result is a journey that starts with intelligence and ends with a broken experience: a link out to a product page, a generic checkout flow, and a consumer who arrived ready to buy and left without completing the transaction. The conversion problem is an architecture problem The industry has treated conversion optimization as a front-end problem for most of its history: better copy, cleaner checkout UX, fewer form fields, smarter retargeting. Those interventions were appropriate for the model they were built to serve. The agentic commerce era introduces a different kind of conversion failure, one that front-end optimization cannot fix. When intent is generated externally, conversion depends on whether the back-end infrastructure can receive that intent, act on it accurately, and complete the transaction within the guardrails the brand has established. That is not a UX problem. It is an infrastructure problem. Brands that are investing heavily in AI-powered discovery while leaving their execution layer unchanged are widening the gap between the promise AI makes on their behalf and the experience they can actually deliver. That gap has a cost, measured not just in lost transactions but in consumer trust that erodes each time the promise and the reality don't match. Rezolve Ai commissioned research across 1,500 US consumers in January 2025 that found consumers who encounter friction immediately after an AI recommendation are significantly less likely to complete a purchase than those who encounter friction at the top of a traditional funnel. The implication is direct: AI raises the expectation bar at the moment of intent. Brands whose infrastructure cannot clear that bar are paying a conversion penalty they may not even know they're incurring. What closing the gap requires Closing the gap between AI-generated intent and completed transaction requires rethinking which layer of the commerce stack carries the most strategic weight in an agentic world. For most of the past decade, that weight sat with discovery and experience. The brands that invested most in search, personalization, and content won a disproportionate share. In the agentic era, the weight shifts to execution. The brands that can reliably take AI-generated intent and turn it into a governed, accurate, brand-safe transaction will have a structural advantage over those whose infrastructure stalls at the handoff. That is a different investment thesis than the industry has operated on. And most enterprise commerce roadmaps have not yet caught up to it. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/11/2026

Mistral AI wants to turn European AI sovereignty from a talking point into a product — one with a service-level agreement attached. The French artificial intelligence company announced Tuesday a three-part expansion of its infrastructure business: regional inference endpoints that let customers choose whether their AI workloads run in Europe or the United States, a new "Priority Tier" backed by an uptime guarantee for mission-critical deployments, and a coalition of European enterprises making multi-year compute commitments that Mistral says will underwrite 200 megawatts of infrastructure across Europe by the end of 2027 — and a full gigawatt by the end of 2030. In a move that may raise eyebrows among sovereignty purists, the company also said it will begin hosting third-party open models on its platform, starting with GLM-5.2 from Z.ai, the Chinese AI lab formerly known as Zhipu. Taken together, the announcements mark a decisive shift in how Mistral positions itself. The company that built its reputation training open-weight language models is now selling something closer to critical infrastructure: assured capacity, regional control, and contractual reliability for enterprises and governments that want frontier AI without surrendering control over where it runs. "When we spoke in June, the story was around how Mistral was building a full-stack AI offering," Timothée Lacroix, Mistral's co-founder and chief technology officer, told VentureBeat in an exclusive interview ahead of the announcement. "Today, the announcement is about strengthening one part of this infrastructure, which is the inference part." That one part, it turns out, comes with a price tag measured in the tens of billions of dollars. Inside Mistral's plan to build 1 gigawatt of European AI compute by 2030 The headline numbers deserve scrutiny, because they imply staggering capital requirements. Mistral currently operates less than 200 megawatts of capacity, according to the company. Details shared with VentureBeat show the near-term buildout resting on three sites: a 44-megawatt facility near Paris that became operational in the second quarter of this year, a 23-megawatt facility in Sweden built in partnership with EcoDataCenter using renewable energy and advanced cooling, and a 10-megawatt site in Les Ulis, France, that came online in the third quarter. Getting from there to one gigawatt by 2030 is a different order of magnitude. Independent estimates suggest just how different: research firm Epoch AI calculates that a typical one-gigawatt AI data center requires roughly $38 billion in upfront capital expenditure, with servers and GPUs — not buildings or land — consuming the majority of the cost. Goldman Sachs Research pegs next-generation AI facilities at $15 million to $20 million per megawatt before accounting for the chips inside them. Lacroix did not dispute the scale of the challenge. The investment required for a gigawatt of capacity "is a large investment that requires also a lot of scaling and revenue behind it," he said. The urgency, in his telling, comes from a supply crunch that is about to get worse. "More and more, and especially around 2027 and 2028, we see that the demand for AI compute is exceeding what the market has to offer, especially in Europe," Lacroix said. McKinsey has estimated that meeting global AI demand could require $5.2 trillion in data-center capital expenditure by 2030 — and Europe, by most analyses, is starting from behind. A company valued at a fraction of its American rivals cannot close that gap with venture capital alone. Which explains the most consequential — and most unusual — piece of Tuesday's announcement. European Compute Units turn AI sovereignty into a five-year contract Mistral is assembling what it calls an anchor group of enterprises whose long-term commitments will collectively finance infrastructure none of them could justify alone. Those commitments convert into "European Compute Units," or ECUs — a claim on Mistral-built capacity over multiple years that participants can spend on inference, training, model adaptation, or other AI workloads as their needs evolve. If that structure sounds more like a power-purchase agreement than a cloud contract, that appears to be the point. Data-center financing increasingly resembles large infrastructure projects — gigawatts, substations, energy agreements — rather than traditional technology spending, and lenders want demand locked in before capital gets deployed. Mistral raised €830 million ($962 million) in debt earlier this year to fund its data center near Paris, TechCrunch reported in March, and pre-committed enterprise demand is exactly what makes that kind of financing repeatable at ten times the scale. Lacroix was unusually direct about the mechanics. "The entire point of compute units is to have commitment," he said. "The goal is to have customers commit for around five years, or at least a long time." Asked what happens if a customer wants out early, he didn't soften the answer: "There is no getting out." What makes a five-year, no-exit commitment palatable, he argued, is flexibility in how the capacity gets consumed. "Typically this can be spent on raw inference that you then feed through any other AI stack. It can be spent on raw compute as managed Kubernetes, and it can be spent at the very top with our full AI offering," he said. "My hope is that they will use it with our full-stack services and will love it." The anchor group already includes some of Europe's industrial heavyweights. Amadeus CEO Luis Maroto said in a statement that "capacity, deployment control, and operating continuity become increasingly important for all enterprises." ASML chief Christophe Fouquet — whose company led Mistral's $13.4 billion (€11.7 billion) Series C last year — called building European AI capacity one of the few industrial endeavors that "will matter more to Europe's next generation," while Capgemini's Aiman Ezzat framed it as "a question of who shapes the future of European industry." CMA CGM chairman Rodolphe Saadé said the shipping group's Mistral deployment is "already under way among thousands of employees." Commitments of that duration only make sense, of course, if the sovereignty being purchased is real. On that question, Mistral's announcement contains an asterisk worth reading closely. The fine print on sovereign AI: what data can still leave Europe The centerpiece product is Mistral Regional Endpoints, now generally available, which let customers pin inference and its associated processing to Europe or the U.S. Alongside it, the new Priority Tier — in public preview — offers committed service levels, custom rate limits, and an uptime SLA for mission-critical workloads. Mistral claims it is the only European AI lab offering both a choice of processing region and an SLA-backed service tier, and Lacroix said a third option is coming: an endpoint "that stays on Mistral-controlled infrastructure, so on Mistral compute" — for customers who want their inference not just in Europe, but off hyperscaler hardware entirely. Then comes the fine print. Mistral's own materials note that in-region inference remains subject to "limited, safeguarded transfers" to sub-processors that may sit outside the chosen region. Pressed on what actually leaves Europe, Lacroix pointed to the connective tissue of modern AI applications: tool calls. "There are some tool services, like some tool calls, that might be hosted in places where we don't fully control this," he said, citing web search as an example. "A few of our web-search providers might not all be in Europe, and in that case, we need to potentially gate that capability." His answer to the compliance question — would this satisfy a European bank or a defense ministry? — was that gating is the feature, not the bug. Capabilities that cannot be sourced in-region can be switched off entirely, restricted to certain users or workspaces, or, given sufficient demand, rebuilt with European providers. "Any capabilities that we don't find a provider for in Europe — if it needs to be done in Europe, we'll find some way to implement it or find ways to address it," Lacroix said. For enterprise buyers, that is a more honest framing than most sovereignty marketing offers: full regional control is available, but the moment an AI agent reaches out to the open web, sovereignty becomes a configuration decision rather than a default. The same pragmatism runs through the announcement's most surprising line item. Why Europe's open source AI champion is hosting China's GLM-5.2 A French national champion — one that has partnered with the French army and positioned itself as Europe's answer to American AI dependence — hosting a Chinese lab's model invites an obvious question. Lacroix's answer was disarmingly matter-of-fact. "It's a great model. Everyone loves it. It's open weight, so there was no good reason for us not to do it, really," he said, noting that Mistral's own stack is already built on open-source software like Kubernetes. On security vetting, he argued that open weights fundamentally change the risk calculus. "The risks in taking a new model, at the layer of the weights, are — at least in my opinion — rather limited," Lacroix said. "We checked basically all of the safety and compliance evals that we have. We'll control that model, its outputs, and what it does the same way we do any of our models. We have the same inputs and outputs and monitoring capabilities over all of it." The strategic logic is worth unpacking. By hosting third-party open models under European regional controls and the same SLAs as its own, Mistral is repositioning itself from model vendor to sovereign distribution layer — the trusted intermediary through which any open model, regardless of origin, can be consumed by a regulated European enterprise that could never call a Chinese API directly. It is the "model garden" playbook the hyperscalers run with Bedrock and Vertex, executed on European soil with European guarantees. Customers appear to be reading it that way. "Mistral allows us to run open models under strict regional controls and service commitments, making it easy for us to maintain data residency and compliance requirements," Matan Griberg, CEO of AI software-engineering company Factory, said in a statement. Lacroix stressed the move is not a retreat from frontier training: the model Mistral had in training as of June "is still training, and we're still very excited about it," he said. But openness to rivals' models signals where the company now believes its moat lies — not in any single model, but in the infrastructure underneath all of them. Which makes its relationship with the world's most powerful infrastructure company all the more interesting. How the multibillion-dollar Microsoft deal funds Mistral's independence Hovering over every sovereignty claim is Mistral's deepening relationship with Microsoft. In July, the two companies announced a multibillion-dollar expansion of their partnership under which Microsoft will rent capacity from Mistral's European data centers to serve its own cloud and AI demand, while adding Mistral Medium 3.5 and OCR 4 to Microsoft Foundry, bringing Medium 3.5 to Copilot Studio, and enabling Mistral models on Azure Local for disconnected, customer-controlled environments. Mistral CEO Arthur Mensch told The Wall Street Journal at the time that two-thirds of Mistral's customers already work with Microsoft. How does a company selling independence from U.S. hyperscalers square taking one on as its largest tenant? Lacroix described Microsoft not as a patron but as an anchor customer that de-risks the buildout. "It allows us to scale different parts of the business differently by building infrastructure with Microsoft as a customer," he said. "We can scale that team, we can scale our infrastructure, and make sure that we can then, on the side of it, also build for ourselves and for our customers." He compared the arrangement to the neocloud playbook — companies that built businesses supplying capacity to the hyperscalers themselves. "As that part of our business resembles that of neoclouds, we're following the same thing." It is a genuinely clever inversion: rather than renting American infrastructure, Mistral is renting infrastructure to one of America's largest companies, using Microsoft's demand to finance capacity that also serves European sovereignty customers. But the independence has limits no contract can engineer away — the GPUs filling Mistral's European data centers come overwhelmingly from Nvidia and other American chipmakers, as SiliconANGLE noted in its coverage of the July deal. Asked directly why a customer should choose Mistral over an EU region on AWS or Azure, Lacroix gave two answers. "The simplest possible answer is capacity. There is more demand than supply right now, and so it adds another option," he said. The second cuts closer to the pitch: "We are a European provider, and on the region that would be Mistral compute, we are fully independent. That's a truly differentiated offering than all of the hyperscalers or pure inference companies can provide." The economics of open models: why agentic AI is pushing inference to the cloud There has always been a tension at the heart of Mistral's business: its best-known models are free to download, and open models have historically been difficult to monetize through APIs. Asked how free weights fund a gigawatt buildout, Lacroix offered the clearest articulation yet of the company's thesis — that the economics of self-hosting are collapsing under the weight of the models themselves. "When the models were smaller, and we were before the explosion of agentic AI, it was doable for enterprises to host their own — up to, let's say, 100-billion-parameter dense models — on their premises," he said. "More and more, with models going into the trillion or more parameters, with the current hardware, and with the increasing amount of tokens that need to be processed, it becomes harder." His conclusion was blunt: "I don't see how, with the current trend of model size and growth of agentic tokens, we keep the full inference on-prem. To me, that is why we think we're going to monetize our cloud inference." Inference, he noted, is particularly well suited to the cloud because it "does not need to hold any data" and can be encrypted in transit. In other words: open weights get Mistral into the enterprise, and the physics of trillion-parameter agentic workloads brings the inference — and the revenue — back to Mistral's data centers. The thesis will get an expensive test. Mistral has raised roughly $4 billion to date, according to PitchBook data — a fraction of the war chests assembled by OpenAI and Anthropic — and Bloomberg reported in June that the company is in talks to raise about €3 billion at a roughly €20 billion valuation, nearly double its Series C mark. The revenue behind the buildout will have to come from exactly the enterprises Tuesday's announcement is courting. And Europe, in Mistral's telling, is only the first market for what it is selling. Asked whether the framework could be replicated in the Middle East, Asia, or anywhere else anxious about AI dependence, Lacroix didn't hedge: "It's completely right. We're starting this in Europe because it's also an easier part of the world for us to scale into, especially in the infrastructure. But we definitely want to extend this, depending on customer demand." Every layer of the stack, he said, "can be controlled, changed, replaced depending on where we operate and what the requirements are — that's pretty much where we excel." That is the wager underneath the SLAs, the compute units, and the Chinese model flying a European flag: in a world where the U.S. and China dominate frontier AI, the durable business is selling everyone else control. To fund it, Mistral is asking Europe's largest enterprises to sign five-year contracts with no exit — while making a bigger, longer commitment of its own. A gigawatt, after all, is a promise measured in decades. For Mistral, too, there is no getting out.

8/11/2026

Presented by Salesforce Interested buyers don't generate revenue. Live customers do. That's the lesson I keep drawing from watching hundreds of ISV partnerships navigate the agent economy over the last 18 months. The companies pulling ahead aren't winning on features. They're winning because customers can move from discovery to live deployment in hours, while competitors are still negotiating contracts, clearing tax reviews, and waiting on provisioning. That gap between a buyer who says “yes” and a customer who is actually using the product is where too many deals lose momentum. Urgency fades. Champions move on. Competitors get another opening. Gutenburg saw that gap firsthand. Healthcare organizations valued its product, but sales cycles stretched 30 to 45 days. With custom pricing via AgentExchange, the company closed an urgent healthcare deal in just 48 hours. Not 48 days. 48 hours. The final contract phase alone dropped from 4 hours to 4 minutes. A 60x improvement. I see this pattern across the ISV ecosystem. Building agents is getting faster. Getting buyers live before urgency fades is becoming the constraint. In a market moving this quickly, that can matter as much as the agent itself. It’s like building a bullet train and selling tickets by fax. The product is built for speed. The transaction is not. Distribution beats product in crowded markets Nearly every software company is pouring resources into agent development. Far fewer are rethinking the path from discovery to deployment. Manual contracts, custom invoicing, tax reviews, provisioning delays, these are the handoffs that turn a 48-hour deal into a 45-day cycle. That friction is now a competitive disadvantage, because the buying process is changing faster than most back offices are. Gartner predicts that by 2028, 90% of B2B purchases will be guided by AI agents. That does not mean humans disappear from enterprise buying. It means the discovery and evaluation process changes. Buyers will increasingly use AI to identify, compare, and narrow solutions. If your agent is not discoverable where that evaluation is happening, you may never make the shortlist. A better agent can still lose to one that's easier to buy. Domain expertise matters. Workflow depth matters. Proprietary data matters. Customer context matters. But enterprise categories are getting crowded fast. In crowded markets, the best product does not always win. The product that is easiest to discover, buy, deploy, and scale often has the advantage. As agent-guided buying takes hold, the first evaluation may happen before a demo is scheduled or a sales rep is in the room. AI agents will increasingly scan marketplaces, compare solutions, and help narrow purchase decisions in the time it used to take to schedule a discovery meeting. Companies that figure out marketplace distribution now will own their categories. That is the problem AgentExchange was built to address. It’s a single destination for apps, agents, and integrations that extend and connect to Salesforce and Slack, helping customers get more from their platform investments. But discovery is only the first step. The bigger question is what happens after the buyer says “yes”. “Yes” doesn't mean live Enterprise software teams spend enormous energy getting to "yes." But in many deals, that is where the operational work begins. Between “yes” and “live,” the back office can generate a chain of handoffs: contracting, invoicing, tax calculation, licensing, provisioning, fulfillment, payment, and finance reconciliation. Every handoff delays activation for the customer and delays recognized revenue for you. For AI agents, that back-office drag is becoming a front-office problem. AgentExchange brings discovery, commerce, and activation together, helping partners manage custom pricing, billing, licensing, provisioning, and fulfillment through one connected experience. "AgentExchange removes the traditional procurement friction that slows deals. Customers can now discover, purchase, and deploy PandaDoc directly through their existing Salesforce contract, turning what used to be a multi-week process into a same-day activation." Keith Rabkin, CEO at PandaDoc What closing in 48 hours actually looks like Gutenburg’s 30-45 day cycles were eaten up by contract logistics. Sales moved faster than their back office. Using custom pricing and automated transaction capabilities through AgentExchange, they streamlined contracting, tax calculation, provisioning, and other steps between buyer interest and activation. When a healthcare organization needed a tool to help them create documents aligned to the Americans with Disabilities Act and accessibility requirements, Gutenburg closed in 48 hours from first contact. The 48-hour close is the differentiator. It is what efficient growth actually looks like in practice. Revenue scales without scaling headcount. Pipeline coverage improves because you are discoverable everywhere. Net recurring revenue increases because customers expand through the same frictionless channel. "AgentExchange condenses contracting and tax calculations into a 10-minute process with improved accuracy," said Zamial Jones, VP of Customer Success at Gutenburg. "For partners spending hours on these tasks for every deal, that's transformational." The window is closing faster than you think The app economy took a decade to mature. The agent economy won't. The ISV partners I've watched pull ahead aren't the ones with the most sophisticated agents. They're the ones who treated distribution as a product problem — resourced, measured, and iterated — before the category consolidated around them. The ones still treating go-to-market as a post-launch consideration are consistently 6 to 12 months behind. You can spend the next two quarters perfecting your agent's reasoning capabilities. Or you can spend them making sure customers can actually buy it. Salesforce is investing in the next generation of companies creating agents with $50 million through the AgentExchange Builders Initiative—capital, engineering support, co-marketing, and co-sell programs. Companies that move now will define what enterprise AI distribution looks like for the next decade. Learn more here. Lisa Eisenberg is SVP of ISV Partnerships at Salesforce. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/11/2026

Enterprises running always-on AI agents keep hitting the same tradeoff. Send every task to a frontier model and the bill climbs fast. Build custom routing logic to send easy tasks to cheaper models and that becomes its own engineering project, one that has to be maintained every time a workflow changes. Nvidia is proposing a fix that touches both ends of that problem at once. The company is out on Tuesday with Nemotron 3.5 Lightning, a 30-billion-parameter open mixture-of-experts model built for high-volume, specialized agent tasks, alongside NeMo Switchyard, an open-source library that routes each step of an agent workflow to whichever model fits it best. The headline numbers: According to Nvidia, Lightning delivers up to 4x faster output than comparable models in its class, completing agentic tasks roughly 30% faster than Qwen3.6-35B at matching accuracy. Paired through Switchyard, Nvidia says the combination holds frontier-level task completion while cutting benchmark costs to roughly a third of running Opus 4.8 alone. The timing puts Nvidia in the middle of the busiest open-weight stretch the industry has seen in months. Alibaba, Moonshot, Zhipu and DeepSeek have all shipped competitive open models out of China since the spring, several landing at or near frontier performance while undercutting US labs on size or price. Meta added to that pressure by releasing its own 30-billion-parameter open agentic model, Muse Glimmer. Open weights have gone from a differentiator to table stakes in a matter of months, and Nvidia's release lands squarely inside that shift rather than ahead of it. The pairing is the point. A model alone doesn't solve the cost problem, and a router alone has nothing efficient to route to. Nvidia is betting that open source, applied at both the model layer and the routing layer, is what actually moves the cost needle on agentic AI, not a single cheaper model and not a smarter router bolted onto someone else's stack. Switchyard's real rivals aren't other open models — they're Not Diamond, which already powers OpenRouter's Auto mode, and RouteLLM, the open-source framework from UC Berkeley and LMSYS. Neither ships its own model. Nvidia's bet is that owning both sides of the decision, under one open license, is what a router-only or model-only competitor can't match. "That is the power of a system of models, matching the right model to each step of the workflow," Kari Briski, vice president of generative AI at Nvidia, said in a briefing. How the router actually changes the workflow Model routing isn't a new category. OpenRouter, LiteLLM and a handful of standalone routing startups already let developers point traffic across multiple providers. Switchyard plugs into several of them rather than replacing them outright. The core problem Switchyard solves is that the right model changes as an agent moves through a task. An agent's state shifts as tools return results, errors show up, or a step turns out to be routine rather than complex, and a fixed model choice can't adapt to any of that. Briski described routing strategies that respond to that shifting state rather than a static task category. "It has many types of routing strategies," Briski said. "You can have a random router, which is not that great, or you can have an agent state route or a classifier route. Depending on your routing strategy, it wants to choose the best model. In some cases you want to go with a model like Lightning for really efficient tasks, and the router will actually choose Lightning if it's set up in your pool of models." Cost enters the routing decision directly, not as an afterthought. In response to a question from VentureBeat, Briski said Switchyard can evaluate model verbosity, meaning how many tokens a given model tends to produce for a task, and use that prediction to steer work toward the cheaper option before the call is made. The part that keeps this from becoming its own integration project is where Switchyard sits. Nvidia split its partners into two groups: agent frameworks that call Switchyard directly, including Cognition, LangChain and Nous Research, and LLM gateways that have built Switchyard support into their own products, including Kong, LiteLLM and OpenRouter. Kong ships Switchyard natively inside Kong AI Gateway. Briski pointed to that same list of gateway partners when describing how the library fits into the existing routing ecosystem. "We are an ecosystem lover, and we want to make sure that we are integrated," Briski said. "We've partnered with OpenRouter, LiteLLM and Kong, and they've already integrated our routing algorithm, so you can pick it up right where you're already using the best tools." Nvidia shared results from nine companies testing Switchyard, several with specific figures attached. LangChain reported a 74% cost reduction across 145 multi-turn Deep Agents tasks by routing just 7% of calls to a frontier model, at a 6% accuracy tradeoff. Ramp said it matched a frontier model's performance on Ramp SWE-Bench while cutting costs 58% and runtime 33%. Cognition integrated Switchyard's staged router into Devin Desktop for internal use and reported near-frontier performance on FrontierCode Main while cutting mean cost 28% relative to routing everything to a single frontier model. Lightning's architecture and performance gains Nemotron 3.5 Lightning is a standalone open model in its own right, built for high-volume, specialized agent tasks rather than general-purpose use. It extends the hybrid Mamba-Transformer, latent mixture-of-experts architecture Nvidia introduced with the Nemotron 3 family in December 2025, the same line behind Nemotron 3 Super, which Nvidia uses as Lightning's own baseline in its post-training comparisons. Positioned within a routing setup like Switchyard, it's built to sit at the fast, cheap end of the decision rather than the frontier end, but it runs and ships independent of any router. According to the Artificial Analysis Intelligence Index, a general capability benchmark spanning nine evaluations, Lightning scores 24, tied with gpt-oss-120b and behind Nemotron 3 Super, Gemma 4 31B, Claude 4.5 Haiku and Mistral Medium 3.5, all at 30. Lightning isn't a general-intelligence leader in its size class, and Nvidia isn't claiming it is. The actual claim is narrower: according to PinchBench data supplied by Nvidia, Lightning matches Qwen3.6-35B's accuracy roughly 30% faster and beats Gemma 4 26B's accuracy at a similar completion time on PinchBench, a real-world agent task benchmark spanning coding, research and file management. That's a speed-to-accuracy tradeoff, not a capability win. Post-training is where Nvidia says the bigger gains show up. The company shared before-and-after figures from four early-access partners: CrowdStrike's malicious-content recall against a Nemotron 3 Super baseline, CodeRabbit's coding router against a GPT 5.4 Nano baseline, Harvey and Trajectory's legal task completion against an Opus 4.6 baseline, and Lila Sciences' energy simulation work against an Opus 4.8 baseline. CodeRabbit's case is the most specific: Nvidia says the standard NeMo Auto model recipe, trained for one epoch, built into a working router agent for $85 in about two hours. What this means for enterprises There is no shortage of competitive offerings in the growing market for open models. The new Nemotron Lightning release will be yet another option for organizations to consider. On the model side, Lightning's own benchmark chart picks Qwen3.6-35B as its direct comparison point. Asked by VentureBeat directly how Lightning compares to Chinese models more broadly, Briski didn't offer a head-to-head benchmark, pointing instead to openness and customizability as the differentiator. "Our value proposition is not just open and it's very customizable," Briski said. For enterprises building agentic infrastructure, three trends stand out: The routing decision is becoming dynamic instead of static. Enterprises that built agent pipelines around a single default model are being pushed toward per-step routing based on live signals like agent state and token cost, not a fixed assignment set at design time. Open source is now a cost lever at two layers, not one. Pairing an open model with an open router a vendor controls end to end is a newer argument than cheaper weights alone, and worth watching for whether other labs follow the same pattern. The competitive question shifts from best model to best system. As routing libraries mature, the differentiator moves from which model an enterprise defaults to, toward how well its routing layer matches models to tasks in production, a harder thing to benchmark and a harder thing to market.

8/11/2026

LTX, the open world model company spun out of Lightricks, today released LTX-2.5, the newest version of its open-weights video and "world" model and it arrives natively integrated into ComfyUI, the node-based workflow tool that has become the de facto prototyping environment for open generative media, through a strategic day-one launch partnership between the two companies. The model is available now as open weights on Hugging Face, inside ComfyUI, and through the LTX API for teams that want managed generation. It is free to use for organizations under $10 million in annual recurring revenue; larger companies negotiate a license. LTX says its models have passed 33 million downloads, making the LTX family the most-used "open world" model line on the market. Ahead of the launch, VentureBeat spoke exclusively with LTX co-founder and CEO Zeev Farbman and ComfyUI co-founder and CEO Yoland Yan about the release, the partnership, and why both companies are betting that open weights — not closed APIs — will win the video and world model market. "We're trying to maintain the same efficiency and the inference speed that we're known for, but constantly pushing the quality up," Farbman said. "We are introducing many cool things in this release: multi-shot support, a diffusion decoder for better quality, new conditioning modes, better support for autoregressive models that are critical for real-time use cases and robotics." What's new in LTX-2.5 According to the company's announcement, LTX-2.5 rebuilds nearly every stage of the generation pipeline rather than bolting new capabilities onto an older core. The headline changes: A new diffusion video decoder that reduces visual artifacts in high-motion footage and reconstructs fine detail like text and faces, while preserving LTX's high compression ratio. Native multishot generation that renders a full sequence as a single output, holding character, scene, and voice consistent across cuts rather than stitching individually generated shots together. A custom Gemma 4 language backbone and dedicated prompt enhancer for more accurate handling of complex, multi-subject prompts. A pretrained checkpoint tuned for physical AI and robotics giving teams a base to fine-tune on domain data that looks nothing like cinematic video. A substantially improved distilled model that delivers near-full-model quality at lower cost and faster inference, and, through an optimization effort with NVIDIA, runs locally on NVIDIA RTX GPUs with reduced memory requirements. The company claims roughly one-eighth the cost and one-seventh the render time of comparable models, with output that runs on hardware ranging from data center GPUs down to a Mac. Checked against published rates, the cost multiple doesn't survive contact with the models that publish pricing. LTX-2.5 generates 720p video with audio at $0.09 per second on its Fast tier, putting a 10-second clip at $0.90 — genuinely cheap, but about one-quarter the cost of full Veo 3.1 ($4.00), half of FLUX 3 Video ($1.70) and HappyHorse 1.0 (~$1.82), and only 10% under Google's budget tiers, Veo 3.1 Fast and Gemini Omni Flash ($1.00 each), while Veo 3.1 Lite ($0.50) is actually cheaper. Nothing in the published field costs eight times LTX's rate; if the one-eighth figure holds anywhere, it would be against premium models like Kling 3.0 Pro or Seedance 2.5 that don't publish comparable per-second pricing — or against self-hosting the open weights, where the marginal cost is whatever your GPU costs to run. The render-time multiple is better supported, at least by LTX's own end-to-end measurements: 6.8 seconds for a 10-second clip against 52 seconds for the fastest rival API (Gemini Omni Flash) is roughly one-seventh — though that figure comes from self-hosting on two GB200 superchips, and through LTX's own managed API the same job took 23.7 seconds, cutting the advantage to about half. Here is how the published rates compare, normalized to the cost of a finished 10-second 720p clip with synchronized audio — the configuration LTX and Black Forest Labs have both used for their own evaluations: Rank Model Per second Per 10-second clip Unique differentiator Notes 1 Veo 3.1 Lite (Google) $0.05 $0.50 The category's price floor — cheapest published rate anywhere No 4K, no clip extension 2 LTX-2.5 Fast (Lightricks) $0.09 $0.90 Only open-weights model in the field — self-host free under $10M ARR, fine-tuning permitted Scales to 4K at $0.30/sec; up to 20s single generation at 24/25 fps 3 Veo 3.1 Fast (Google) $0.10 $1.00 Cheapest closed-API path to 4K ($0.30/sec) Budget tier of the Veo line 3 Gemini Omni Flash (Google) $0.10 $1.00 Independently measured quality leader — tops both Artificial Analysis text-to-video arenas as of Aug 2026 720p only; 10-second maximum; best iteration tooling 5 LTX-2.5 Pro (Lightricks) $0.12 $1.20 Quality-tuned tier of the only open-weights family — prompt adherence, faces, typography (vendor-described) Tops out at 1080p and 10 seconds 6 FLUX 3 Video (Black Forest Labs) $0.17 $1.70 First to ship 20-second single-generation clips with audio (July 2026) — a ceiling since matched by LTX-2.5 Fast HD band; audio included; Draft tier at $0.06/sec ($0.60/clip, HD only) 7 HappyHorse 1.0 (Alibaba) ~$0.182 ~$1.82 Arena quality leader at launch (April 2026), since overtaken; "open source" claims never matched by verified downloadable weights Third-party reseller rate; audio included at no extra charge 8 Veo 3.1 (Google) $0.40 $4.00 Only model supporting clip extension beyond a single generation Premium tier; 8x Veo 3.1 Lite; 1080p at no premium over 720p Sources: LTX API pricing documentation; bfl.ai/pricing; Google AI for Developers model pricing; HappyHorse reseller rates via third-party API platforms; Artificial Analysis text-to-video arena leaderboards. All rates verified August 11, 2026, and subject to change. How fast and how good LTX says it is The most eye-catching number in LTX's launch materials is speed: the company says LTX-2.5 generates a 10-second, 720p image-to-video clip in 6.8 seconds faster than real time. The caveat is the hardware behind it. That figure was measured self-hosted on two of NVIDIA's top-end GB200 chips at steady state, a configuration far beyond what most teams have racked; the same job through LTX's own managed API took 23.7 seconds, albeit rendered at the higher 1080p resolution (the API has no 720p tier). By the company's end-to-end measurements of competing APIs on the same task, Google's Gemini Omni Flash came in at 52 seconds, xAI's Grok 1.5 at 63 seconds, Google's Veo 3.1 at 70 seconds (for an 8-second clip), MiniMax H3 at 180 seconds, ByteDance's Seedance 2.5 at 317 seconds, and Kuaishou's Kling 3.0 Pro at 398 seconds. On quality, LTX shared results from blind, side-by-side human preference tests, in which evaluators voted on videos generated from the same prompt without knowing which model produced which. LTX-2.5 recorded a 67% win rate, narrowly ahead of Seedance 2.5 at 65%, with Gemini Omni Flash at 55%, MiniMax H3 at 50%, Seedance 2.0 at 44%, Wan 2.6 at 42%, and FLUX 3 at 28%. All of these figures are vendor-reported measured or commissioned by LTX itself, not independently verified and the company labels the preference results preliminary, noting it expects them "to evolve as evaluation expands." They are directional claims a buyer should test against their own workloads rather than settled rankings. The independent benchmark that does exist cuts the other way for now: as of this month, Gemini Omni Flash — which LTX's commissioned tests place 12 points behind its own model — leads both of Artificial Analysis' text-to-video arena leaderboards, and the arena does not yet score LTX-2.5 at all. Until it does, the 67% figure remains untested on neutral ground. The launch materials also lean on deployment terms rather than raw performance: LTX-2.5 runs on any GPU with a minimum of 16GB of VRAM, deploys on-premises, at the edge, or via API, carries no visible watermark on output — though the license requires users to disclose that content is machine-generated and forbids removing any embedded provenance or "latent disclosure" features (more on this below) — and can be fine-tuned on a customer's own data and IP flexibility the company contrasts with closed API-only rivals and with open-licensed competitors whose weights are unavailable in the U.S. and Europe or whose licenses restrict fine-tuning. Betting against the API business model For Farbman, the release is another installment in a strategy that began as a reaction to the industry's consolidation around closed models. "We started with our own models out of necessity, because around the time that Sora came out, we realized that all the big guys are trying to close their models, and working through APIs just doesn't work for many businesses, including the kind of stuff that we wanted to build," he said. The technical argument, he explained, is that video and world models have a fundamentally wider "surface area" of use cases than language models. "With LLMs, the surface area of the API is pretty narrow, we're typically asking some kind of question, passing words and getting words back," Farbman said. "With video models, world models, there are so many different use cases that require people to get access to the weights and create flows that really work for them." He was blunt that the openness is not charity. "We're definitely not doing this as philanthropy," he said. "Our answer is open weights with licenses that allow individuals and companies below a certain amount of revenue to use the model for free, and once they're successful, to come up with some kind of licensing agreement with us." "We're trying to build a model that builders can confidently build upon," he added. "We're coming and saying: guys, open weights is not some kind of one-time philanthropic fluke for us. It's the strategy. We believe this is the right way to serve these models, and we're going to keep doing that." What the license actually says "Open weights" and "open source" part ways in the fine print. LTX-2.5 ships under the LTX-2.x Community License, a custom agreement that would not qualify as open source under the Open Source Initiative's definition: it discriminates by revenue and by field of use, both disqualifying restrictions. The headline mechanic works as advertised — organizations are free to use, modify, self-host, and even sublicense the model, with the $10 million annual revenue threshold (measured across all affiliates and subsidiaries, so a small subsidiary of a large parent doesn't slip under it) triggering the paid license. Notably, even companies above the line can download and evaluate the model free in non-production environments — the license effectively codifies the prototype-in-ComfyUI-then-license funnel Farbman describes. It also gives that funnel teeth: unauthorized commercial use obligates the violator to pay back-fees at LTX's standard rates, due within 30 days of written demand. The stickiest provisions concern what counts as a "derivative." The definition sweeps in not just fine-tuned checkpoints and LoRA adapters but distillations and any model trained on LTX-2.5's outputs or synthetic data — meaning a company that generates training clips with LTX-2.5 and uses them to train its own unrelated model has, by the license's terms, created a derivative locked to the same agreement. All derivatives must be redistributed under the same license, a fine-tune transferred to a $10 million-plus company triggers that company's own paid-license obligation regardless of who built it, and commercial users are barred outright from using the model to train or improve any competing AI system. A separate clause prohibits deploying LTX-2.5 in any product that competes with Lightricks' own offerings without a negotiated license. There are also control provisions unusual for a self-hosted model. Lightricks claims no rights in generated output, but the license requires users to disclose that content is machine-generated, forbids removing or circumventing any watermarking, content-provenance, or "latent disclosure" features embedded in the model, and reserves Lightricks' right to restrict usage "remotely or otherwise" and to push updates — with immediate license revocation as the penalty for disabling disclosure features. The license also declares Lightricks' intent that LTX-2.5 be treated as a "free and open-source general purpose AI model" under Article 53(2) of the EU AI Act, a derogation that lightens the company's own regulatory obligations — a classification legal observers may contest precisely because of the revenue threshold and use restrictions in this same document. And one restriction bears directly on the physical-AI pitch: military, warfare, and weapons-development uses are banned entirely, so the robotics checkpoint is off-limits to the defense sector without separate terms. From Facetune to world models and the node graph that became a standard LTX grew out of Lightricks, the Jerusalem-headquartered company best known for consumer creative apps including Facetune and Videoleap. Bootstrapped and profitable, Lightricks pivoted to foundation models in 2022, launched its LTX Studio filmmaking platform in early 2024, and released its first open-weights LTX Video model (LTXV) in November 2024, following it with a 13-billion-parameter version in May 2025. Farbman co-founded the company alongside CTO Yaron Inger and CMO Nir Pochter, and the LTX brand now fronts its world model business, with offices in New York, London, and Chicago. ComfyUI began in January 2023 as an open-source side project by a pseudonymous developer known as "comfyanonymous," who built a node-based graphical interface for Stable Diffusion that let users chain models and processing steps into repeatable visual workflows. It has since become one of the fastest-growing open-source projects in generative media the standard environment where new image and video models are tested, combined, and pushed into production and is now backed by a company, Comfy Org, which raised $17 million to keep developing the tool. Yan, a co-founder, serves as its CEO. Why ComfyUI is the front door for enterprise adoption For readers wondering why a model company and a tooling company are launching arm-in-arm, Farbman's answer was unusually candid: ComfyUI is where LTX's paying customers come from. "A whole lot of our customers are starting their journey with Comfy," he said. "It's already this prototyping system that's extremely popular in the industry, and a lot of the potential customers are coming to us after they already figured out the flow inside Comfy. It's already working, so for us it's a no-brainer that we have to provide zero-day support for the Comfy integration, because it's basically our customer acquisition channel." Yan described ComfyUI's role as the connective layer of the open ecosystem. "Comfy at the core is sitting as a layer on top, giving people accessibility to the open-weight models that people can inference on their local machine, or tap into closed models as well through our partner node system," he said. "In the end, [they] combine everything together into a workflow that empowers various things, from the creative side all the way to data pipeline and robotics type of scenarios." That flywheel, Yan argued, is what sustains open models commercially: "We help promote and push these models into the world... people do all sorts of workflow and model innovation on top of it, and that further propagates these models into studios or robotics labs. Those companies would end up acquiring licenses and then contribute a part of the value gained back to LTX and the rest of the ecosystem." What enterprises should know Both executives pushed back on the assumption that a video model is only for generating videos. Farbman rattled off a list of enterprise deployments that have little to do with cinematic clips. "We have hardware customers that are trying to figure out how to do computational photography with diffusion models, for example, taking a stream of raw pixels that are coming from the sensors, which is typically very noisy, and trying to figure out how to reduce noise there," he said. "Or think about the production studios that are trying to figure out how to do VFX, how to do water simulation, how to turn day into night. Or think about animation studios: they're trying to figure out how to streamline their pipeline, where animators are creating keyframes and then the system uses them as interpolation." For enterprises weighing where to start, the recommended path is the one their own employees have probably already taken. "A lot of enterprises have already adopted Comfy, and I think many others will follow," Farbman said. "It gives this right level of structure, where you can tweak things a lot, but it still abstracts a lot of things away... Enterprises are typically reaching out after people internally have already played with the model, played with Comfy." Yan described a consistent two-track pattern among studios and companies already running LTX and other open models in production. "They have their research, or R&D, creative pipeline, anything goes," he said. "Once in a while, some of these pipelines get good enough that they graduate into some kind of production environment. And somewhere along the line, the enterprise conversation gets started. On our end, it's more around tooling, and on the LTX side, it's more around the licensing." Because the weights are open, that entire experimentation phase can happen on a company's own hardware, with no per-generation billing and no data or IP leaving its systems, a meaningful distinction for enterprises with sensitive footage, proprietary characters, or regulated data. The commercial trigger only arrives with scale: organizations above $10 million in ARR need a license. Yan framed the stakes for slower-moving companies in starker terms. "This is a trend that is just fundamentally going to disrupt the entire creative industry," he said. "Studios are heavily trying to figure out what is the roadmap and how do we get ahead, sometimes not even get ahead, just how do we avoid falling behind the AI adoption wave." Developers, real-time apps, and the edge For software developers, the release leans into a growing real-time story. Alongside ComfyUI, LTX named two other launch partners: Asteria, the AI film studio producing original film and video on LTX, and Reactor, a developer platform that runs LTX-2.5 on low-latency inference infrastructure to power interactive avatars, live worlds, and real-time robotics workloads, so developers can build production-grade real-time experiences without standing up that infrastructure themselves. Yan pointed to a viral example of what open weights plus low latency makes possible: Flipbook, an interactive experience that spread on Reddit in which an entire clickable world is generated on the fly. "Everything people see on that interface is generated using an LTX model, live-streamed," he said. "It's an environment, or a world, where anywhere you click, it just generates a brand-new interaction... That type of experience and experimentation wouldn't exist without an open-weight model, without LTX's type of performance." Farbman said efficiency at the edge is a deliberate design target, not a side effect. "For us, it's very important to create an extremely efficient model that people can run on edge devices, both on consumer hardware and close to the edge with physical AI," he said, while acknowledging the relentless pace of the field: "These days, it's almost hard to take a vacation. Things are progressing so quickly that while you're releasing one model, you're already deeply into training another one, and new papers are coming on a daily basis." Filmmakers: virtual production now, easier slopes later For professional filmmakers and studios, Yan sees real-time world models changing the shape of production itself, collapsing the gap between shooting and post. "These days you see real-time models, or world models, getting adopted in studios as part of what's called virtual production, meaning you can shoot and then immediately get close to what the post-production result looks like," he said. "You give a much better experience to the producer or director to say, 'okay, this is what I want,' or 'this is not what I want let me actually reiterate.' Whereas before, the entire Hollywood pipeline is, in my opinion, a giant mess where it has to constantly go between multiple departments." He also cautioned against reading head-to-head model comparisons too literally, given how differently models specialize across animation, photorealism, gaming, 3D, and robotics. "Various models have simply different characteristics," he said. "It's like comparing Michael Phelps with, I don't know, Michael Jordan. It's not really a comparison of who's a better athlete, there are just different specialties here." As for amateur and indie creators intimidated by ComfyUI's famously steep learning curve, Yan was direct that the tool will meet them partway, but only partway. "It's kind of like skiing," he said. "There are easy slopes that you can go down using Comfy, and hopefully we can create more and more of these easy slopes overall. But we'll never sacrifice the existence of the double-black-diamond type of lanes, because the real technical, professional creatives actually need and couldn't live without that type of core power. That's actually our core differentiator compared to a mobile-app type of creative tool." LTX-2.5 is available today on Hugging Face, natively in ComfyUI, and through the LTX API. Updated several hours after publication with additional details from LTX's public blog post and API pricing page.

8/10/2026

Earlier today, OpenAI launched GPT-5.6-Cyber, a specialized model designed to perform advanced vulnerability research and exploit development for approved defenders — including categories of work that its general-purpose models will often refuse. GPT-5.6-Cyber is a fine-tuned version of OpenAI's most advanced general model, GPT-5.6 Sol, unveiled back in June, but trained specifically to improve performance on advanced cybersecurity tasks, including finding zero-day vulnerabilities and developing exploit chains. Crucially, OpenAI also trained it to reduce refusals on some higher-risk, "dual-use" cybersecurity requests — that is, requests that could be used for legitimate defensive or malicious offensive purposes. Indeed, on an internal OpenAI benchmark called Advanced Cybersecurity Completion Rate — which the company says in its launch blog post measures tasks involving exploit-chain development, authentication bypass, privilege escalation, and other advanced cybersecurity scenarios — GPT-5.6-Cyber completed 95% compared to just 57.3% from its immediate predecessor model GPT-5.5-Cyber, and just 1.5% with the normal GPT-5.6 Sol model and all its safeguards applied. OpenAI researcher Eric Wallace posted on X, describing GPT-5.6-Cyber as OpenAI's "first large-scale attempt at directly improving capabilities for advanced cybersecurity tasks such as exploit development." Pricing and availability Unfortunately for enterprises, GPT-5.6-Cyber is not being made broadly available to every ChatGPT or API customer. To get access, an organization has to be accepted into the newly created tier of OpenAI’s Daybreak cybersecurity program, called Daybreak Red — also announced today, which gives access to dedicated cybersecurity models like GPT-5.6-Cyber Another new tier, Daybreak Blue, gives a wider swath of enterprises access to general models like GPT-5.6 Sol but with some guardrails lifted to allow for more cybersecurity uses. OpenAI’s documents list pricing for GPT-5.6-Cyber at $12.50 per million input tokens and $75 per million output tokens, with cached input at $1.25 per million tokens. That makes it more expensive than GPT-5.6 Sol in the same Daybreak cyber pricing table, where Sol is listed at $5 per million input tokens and $30 per million output tokens for short-context use. OpenAI does not list long-context pricing for GPT-5.6-Cyber in the same table, and access still requires separate Daybreak Red approval and provisioning. Red vs. Blue: OpenAI's new Daybreak tiers and how to qualify for them Daybreak Red is for approved security teams doing advanced, authorized cyber work — the kind of work that can look risky out of context, even when it is being done for defensive reasons. That includes vulnerability research, penetration testing, red-team exercises and exploit validation on systems the organization owns, operates or has permission to test. In other words, OpenAI is saying GPT-5.6-Cyber is for trusted defenders with a clear professional need, not for general experimentation. Enterprises that want access have to apply through Daybreak Access, OpenAI’s current pathway for vetting cyber users. The application asks companies to identify who they are, what kind of security work they plan to do, where they will use the models, and which OpenAI products or surfaces they expect to use. Applicants also have to confirm that their work is lawful, defensive and authorized. OpenAI is also looking for signs that the applicant has a serious security program of its own. The company says participating enterprises need controls such as single sign-on, multifactor authentication, role-based access, employee-use monitoring, usage logs, API-key controls and a documented incident-response process. OpenAI also asks for a recognized security certification such as SOC 2 Type II, ISO 27001 or an equivalent standard. Access is limited to approved people inside the organization using company-controlled accounts and devices. If an enterprise does not qualify for Daybreak Red, or does not need that level of access, OpenAI is pointing most companies toward Daybreak Blue, its other cyber models access tier, instead. Blue is the broader tier for approved defenders. It does not provide GPT-5.6-Cyber, but it does give vetted users access to OpenAI’s frontier general-purpose models, including GPT-5.6 Sol, with safeguards adjusted for legitimate defensive work. For many enterprise security teams, Blue may be the more realistic starting point. OpenAI says it is meant for tasks such as secure-code review, vulnerability discovery, malware analysis, incident response and patch validation. These are still sensitive uses, but they do not necessarily require the same specialized cyber model access that comes with Red. The practical takeaway is that enterprises now have two routes into Daybreak. Blue is for approved defenders who want stronger AI help with everyday security work. Red is for the smaller set of approved teams that can justify access to specialized cyber models, including GPT-5.6-Cyber. Companies that want to use Daybreak capabilities in products or services for their own customers need a separate approval path through the Daybreak Cyber Partner Program, rather than simply applying for internal enterprise access and passing it along. How OpenAI got here: from Trusted Access to Daybreak OpenAI has supported defenders through its Cybersecurity Grant Program since 2023 — later expanded to $10 million — and began building cyber-specific safeguards into its model deployments starting with GPT-5.2. In February 2026 it introduced Trusted Access for Cyber (TAC), an identity-and-trust framework that gave vetted defenders lower classifier-based refusals for authorized work such as vulnerability triage, malware analysis and binary reverse engineering. From there, the cadence accelerated. In March, OpenAI CEO and co-founder Sam Altman announced the Daybreak program. In April, OpenAI scaled TAC and released GPT-5.4-Cyber, a version of GPT-5.4 fine-tuned to be "cyber-permissive" for a limited set of vetted vendors and researchers. In May, it followed with GPT-5.5-Cyber in limited preview for defenders of critical infrastructure, and lined up partners including Cisco, Intel, SentinelOne, Snyk and Cloudflare. Notably, OpenAI said at the time that GPT-5.5-Cyber was "primarily trained to be more permissive," not to significantly out-perform its general model — GPT-5.5-Cyber actually scored worse than GPT-5.5 on some evaluations. TAC required phishing-resistant Advanced Account Security for individuals on its most capable models beginning June 1, and Daybreak now requires hardware security keys for individual accounts beginning September 1. OpenAI says GPT-5.6-Cyber has already found zero-days OpenAI isn't relying exclusively on benchmarks to make its case. The company says its researchers used GPT-5.6-Cyber to investigate V8, the JavaScript engine underlying Chrome, and uncovered two previously unknown vulnerabilities that could be chained to corrupt memory and escape the V8 heap sandbox. OpenAI researchers validated the findings and disclosed them to Google, which fixed the vulnerability assigned CVE-2026-15903 — a high-severity flaw in which V8's optimizing compiler skipped a safety check during integer conversion, allowing an out-of-bounds array index that an attacker could use to read or overwrite memory. OpenAI says the model has also contributed to finding at least five vulnerabilities in an unnamed popular mobile operating system, three critical vulnerabilities in an unnamed popular database, and more than 400 vulnerabilities capable of producing privilege escalation in a popular operating-system kernel. Those disclosures are still being coordinated, according to OpenAI. The results put OpenAI into a rapidly developing market for AI-assisted offensive security. XBOW, for example, markets autonomous penetration-testing agents that map attack surfaces, attempt exploits and independently validate findings; in 2025 it became the first AI system to top HackerOne's U.S. bug-bounty leaderboard, and this year it disclosed a set of critical, CVSS-9.8 remote-code-execution flaws in Microsoft's Bing image-processing systems, found without source-code access. For enterprise security leaders, that emerging competition matters because vulnerability research is moving beyond using an LLM as an assistant. Vendors are increasingly building systems in which models can investigate targets, operate tools, validate hypotheses and produce actionable findings. Specialized doesn't mean universally better OpenAI's own results also show why enterprises shouldn't simply equate cyber specialization with better performance everywhere. GPT-5.6-Cyber outperformed GPT-5.6 Sol and GPT-5.5-Cyber on OpenAI's implementation of ExploitGym, which evaluates whether agents can turn known vulnerabilities into working exploits in controlled environments. It also beat Sol on an internal zero-day evaluation. But GPT-5.6 Sol performed better on OpenAI's Vulnerability Discovery and Report Writing evaluation. OpenAI attributes the Cyber model's lower score partly to shorter and less detailed vulnerability reports. Sol also performed best on ExploitBench under its standard 300-turn limit, with OpenAI saying it solved tasks more token-efficiently. Extending the evaluation to 600 turns narrowed the gap between the models. That suggests enterprises may eventually treat cyber models as specialized workers rather than replacements for general reasoning models: one model for deep exploit work, another potentially better suited to analysis, documentation or other parts of a security workflow. SpecterOps CTO Jared Atkinson said GPT-5.6-Cyber is "materially improving our specialist vulnerability-research workflows," adding that it completed some work in less than a day that previous models had failed to resolve after weeks of intermittent effort. The Hugging Face incident hangs over the launch The permissive-model pitch arrives weeks after OpenAI's most serious public demonstration of what can go wrong when cyber refusals are turned down — and OpenAI addresses that history head-on in the Daybreak announcement. In July, OpenAI and Hugging Face jointly disclosed that during an internal ExploitGym benchmark evaluation — run with production classifiers deliberately disabled to measure maximal capability — a combination of OpenAI models, including GPT-5.6 Sol and an unreleased, more-capable pre-release model, broke out of their sandboxed research environment and autonomously attacked Hugging Face's production infrastructure. The models exploited a zero-day in an internally hosted package-registry cache proxy to reach the open internet, moved laterally through OpenAI's research nodes, then inferred that Hugging Face likely hosted ExploitGym's answer keys and chained stolen credentials and remote-code-execution flaws to reach its production database. OpenAI called it an "unprecedented cyber incident, involving state-of-the-art cyber capabilities." As VentureBeat previously reported, the episode also exposed the flip side of blanket safety guardrails: when Hugging Face's defenders tried to use commercial frontier models to analyze the raw exploit payloads and credential dumps from the attack, the models refused, and the company completed its forensic reconstruction only after switching to a Chinese open-weight model, GLM 5.2, run locally. That guardrails-block-the-defender dynamic is much of what OpenAI's reduced-refusal Daybreak tiers are meant to solve — even as the same incident illustrates the risks of reducing refusals in the first place. OpenAI is careful to draw a line between that incident and this product. In the Daybreak announcement it states directly that GPT-5.6-Cyber "was not involved in exploiting Hugging Face, nor are any other models planned for an upcoming release," and notes that the pre-release model implicated in July was an internal-only research prototype that has since been deactivated, encrypted and restricted from research access. The company has said it is working with external advisers including CrowdStrike, METR and Redwood Research on the review, and has brought Hugging Face into its trusted-access program. In my assessment, the access model still leaves OpenAI with a hard question: whether keeping GPT-5.6-Cyber inside the narrower Daybreak Red tier also limits the very defensive work it says it wants to accelerate. If only a small group of approved participants can use the model, enterprises outside that tier may still lack access to the kind of specialized AI assistance that could help with fast diagnosis, containment and response in incidents like the one involving Hugging Face. That means OpenAI may still be repeating part of the mistake it is trying to move past. By holding its most capable cyber model behind a tighter approval process, it reduces obvious misuse risk, but also leaves many enterprise defenders looking elsewhere. For teams that cannot qualify for Daybreak Red, or cannot wait for approval, open weights models may remain the more practical alternative: less controlled, but easier to obtain, inspect, run internally and adapt during a live security investigation. The guardrail is increasingly around the model The most consequential part of Daybreak may ultimately be its access architecture rather than its benchmarks. OpenAI explicitly says Daybreak Blue removes system-level guardrails that can interfere with legitimate defensive work, while GPT-5.6-Cyber goes further by reducing model refusals for certain dual-use tasks. In their place, OpenAI is imposing controls around who receives access and how the models operate. Daybreak access is restricted to approved individuals and organizations performing authorized work. OpenAI says controls include identity verification, account security, monitoring, approved-use restrictions and legal attestations. The company is also encouraging Daybreak customers using Codex to move from full-access execution to an auto-review mode capable of evaluating actions requiring elevated permissions before they execute. Individual Daybreak accounts will be required to adopt hardware security keys beginning September 1. OpenAI says it is additionally rolling out improved monitoring in the coming weeks and prioritizing alignment training and testing for upcoming Daybreak releases — commitments that read, in context, as a direct response to the Hugging Face review. OpenAI's broader Codex Security product supplies another layer around the models, providing repository analysis, vulnerability validation, remediation and integration into cloud, pull-request and local development workflows. OpenAI says Codex Security has scanned more than 30 million commits across more than 30,000 codebases, with more than 500,000 findings fixed. That model-plus-harness approach resembles a broader shift in AI security products. XBOW, for example, emphasizes orchestration, exploit validation and governance around frontier models rather than treating an LLM alone as the complete penetration-testing system. OpenAI nevertheless acknowledges that increasingly permissive cyber models create additional risks, whether from misuse or misalignment. It assesses both GPT-5.6 Sol and GPT-5.6-Cyber at the High cybersecurity capability level under its Preparedness Framework, but below its Critical threshold. A fuller GPT-5.6-Cyber system card is planned for later publication. For CISOs and security engineering leaders, Daybreak therefore presents a different deployment question than another incremental model upgrade. As models become capable enough to perform work previously reserved for experienced vulnerability researchers — and, as the Hugging Face incident showed, capable enough to pursue a narrow goal straight through a sandbox — the enterprise control plane around those models — permissions, sandboxes, monitoring, human review and authorization — becomes as important as the intelligence inside them.

8/10/2026

Amazon Web Services is threading its AI-powered security infrastructure directly into the coding environments built by two of its fiercest rivals — and in doing so, it is making a bold bet that controlling the security layer matters more than controlling the model. AWS announced at Black Hat USA 2026 this month that its Continuum platform for code vulnerabilities will integrate directly into Anthropic's Claude Code and OpenAI's Codex, alongside AWS's own Kiro IDE. The move embeds AWS security tooling at the point where developers write code, regardless of which AI model they use to do it. Simultaneously, AWS expanded Security Hub Extended — its curated, single-bill security marketplace launched in February — with a 10th security category focused on supply chain protection, bringing in Chainguard and Socket as partners. Together, the announcements are AWS's most sweeping attempt yet to position itself as the default security control plane for enterprise software development in the AI era — a role that carries enormous commercial implications as the global cloud infrastructure market surpasses $143 billion per quarter, according to Synergy Research Group. Why frontier AI models turned the vulnerability backlog into a five-alarm fire The urgency behind both launches traces back to a single inflection point that reshaped enterprise security earlier this year. Claude Mythos Preview, announced by Anthropic in April, is a general-purpose AI model that during testing revealed striking cybersecurity capabilities far exceeding any prior system. In pre-release evaluations, Mythos identified thousands of previously unknown zero-day vulnerabilities across every major operating system and web browser. More than 99% of those vulnerabilities remain unpatched by their maintainers, and the median time from vulnerability discovery to weaponized exploit — already collapsed from 771 days in 2018 to under four hours by 2024 — is projected to reach under one hour by the end of 2026. Chet Kapoor, AWS's vice president of search, security, and observability, framed the challenge in stark terms in an exclusive interview with VentureBeat. "CISOs have had code vulnerabilities for a while, and then Mythos came along, and it just made it a lot worse," Kapoor said. "They already had a backlog. Now the backlog is 5x more, and that causes a problem." That problem — the exponential growth in known vulnerabilities outpacing any organization's ability to triage and fix them — is precisely what Continuum is designed to address. Kapoor described AWS's broader security vision as a shift from "telemetry, storage, query, dashboards for humans to telemetry, context, reasoning, and actions by agents." The shorthand for that vision is a phrase AWS repeated throughout Black Hat: autonomous security at machine speed. Inside Continuum's four-phase system for finding and fixing code flaws automatically Continuum operates as what AWS calls an “agent-team loop architecture” — a sophisticated orchestration harness that selects the right AI model for each task, connects to a customer's environment, and delivers validated secure code. Under the hood, it runs through four distinct phases. Kapoor broke them down for VentureBeat. Discovery uses multiple frontier AI models to scan code and ingest a customer's existing vulnerability backlog. Prioritization — which Kapoor called "one of our biggest value adds" — contextualizes each finding against a customer's actual environment and business risk. "You go from 100 to 2,000, and now you're like, whoa, I didn't even know which 100 to focus on," he said. Validation then builds reproducible exploits in an isolated sandbox to confirm whether a vulnerability is genuinely exploitable. "Once I do them, how will it behave?" Kapoor explained. "You create a sandbox to go off and make that happen. So you can figure out what the blast radius is." The validation phase covers both first-party code that customers wrote themselves and third-party open source code they depend on. Finally, remediation offers fixes — whether network configuration changes, policy adjustments, or code patches — that the system has already tested in the same sandbox. The human stays in control throughout, approving outcomes at whatever level of autonomy the organization is comfortable with. The commercial model is equally deliberate. Customers pay AWS a single price for Continuum. AWS absorbs the underlying token costs for whichever frontier model performs best at each phase of the scan. "The customer purchases Continuum, period," Kapoor told VentureBeat. "We optimize on which model to use for what because, quite frankly, GPT Cyber is good at some things, Mythos is good at some things." How AWS convinced OpenAI and Anthropic to open their coding tools to a rival's security layer The most strategically striking element of the announcement is the integration with OpenAI Codex and Anthropic Claude Code. AWS competes directly with both companies across cloud AI services. Amazon holds a massive investment in Anthropic, and OpenAI operates its own growing infrastructure that competes for the same enterprise AI workloads. Yet both agreed to embed Continuum inside their developer environments. When VentureBeat asked Kapoor directly about the competitive dynamics, he pushed back on the framing entirely. "Who is the competitor?" Kapoor said. "I can keep thinking about Anthropic and OpenAI to be partners. I don't understand the word 'competitor' in your description of the question." He added: "They're partners with us. We use their models. We plug into their environments. Which is why we actually brought them together to do this." Kapoor argued that working with a single model provider would be insufficient. "I don't think it's good enough to just do it with one company," he said. "Everybody is going to leapfrog each other over a period of time." By absorbing token costs and presenting a single bill to the customer, AWS positions Continuum as infrastructure — not a model wrapper. The harness, not the engine, becomes the durable competitive asset. As Kapoor wrote in his blog post announcing the partnership: "An AI harness is the orchestration layer that wraps around a model to connect it to tools, guardrails, memory, and workflows, so it delivers outcomes. Think of the model as the engine and the harness as everything around it. You need both to have a high-performance car."  AWS partners echoed the logic. "Model choice was never the hard part for enterprises. Trust in what the model does in production is," said Val Henderson, CEO of AWS Premier Partner Caylent, in comments reported by CRN. AWS adds supply chain security to its curated marketplace as open source threats intensify The second prong of AWS's Black Hat announcements extends Security Hub Extended into supply chain security as its 10th category, with Chainguard and Socket as curated partners. The Extended plan now includes 23 curated partner solutions, all on a single AWS bill with no required long-term commitments, covering endpoint, identity, email, network, data, browser, cloud, AI, security operations, and now supply chain. Michael Fuller, AWS's director of security services, told VentureBeat that the addition was driven entirely by customer demand. "Over the last six to eight months, it's gotten quite a bit of news around what's happening in the supply chain space, with the fact that everybody builds on open source," Fuller said. "Our customers quickly reached out and said, 'Security Hub Extended is resonating. We would love to see a supply chain security category with some key players there because it's a hot topic for us.'" The two partners were chosen to be complementary rather than duplicative. Chainguard focuses on providing hardened, secure-by-default container images and packages rebuilt from verified source code. Socket performs behavioral monitoring of packages as they are pulled into a developer's environment, detecting threats like typosquatting, maintainer account takeover, and obfuscated malicious code. "Together, between the three of us — us with consolidating that, ChainGuard providing really good hardened and cleaned images and packages, and then Socket providing a behavioral analysis over the top — gives customers a really good holistic supply chain security offering," Fuller said. The complementary approach addresses two distinct attack vectors. An attacker can publish a malicious package that contains no known vulnerabilities — Chainguard's clean-build approach defends against that. Separately, an attacker can compromise a legitimate maintainer's account and push a tainted update to a trusted package — Socket's behavioral detection catches that. Both vectors are amplified in the AI coding era, Fuller noted, because AI agents face the same supply chain risks as human developers: "Agents can be misled on, 'Hey, this is a well-known package that you're looking for,' and therefore pull it down, even though it's been maliciously obfuscated." Why AWS chose two partners per category instead of building a security marketplace The partner selection strategy behind Security Hub Extended reveals a deliberate philosophy that distinguishes it from the AWS Marketplace, which already hosts tens of thousands of security offerings. Fuller told VentureBeat that customers articulated clear principles for what they wanted. "One was don't give me hundreds of offerings. We already have the AWS Marketplace," he said. "Two was give me a sweet spot. Our customers were saying, give me two in each category, and when you look at those two, don't give me head-to-head competitors. Give me one that I may know well, that is an established player, and give me one that's taking a different approach." Fuller pointed to the security operations category as the template. "You have Splunk, hard to argue not an established leader in security operations, and then you have Seven AI that's kind of taking a very different approach, and they're complementary in a lot of ways." The decision to build internally versus partner follows a similar logic. For endpoint detection and response, AWS has no structural advantage, so it partners exclusively. For cloud security, AWS builds its own native tools because it intimately understands its own infrastructure — but still partners with Upwind to give customers a second option. "At the end of the day, what we're trying to do here is ensure that our customers can operate in the most secure way possible on AWS, not necessarily grow a large security business as the core goal," Fuller said. "That's why it's very easy for us to decide to do both building ourselves, but also then inviting partners to participate." The pricing model reinforces this accessibility. Fuller said customers demanded pay-as-you-go options alongside traditional multi-year commitments. "All of the Security Hub Extended offerings have a public-facing, pay-as-you-go price, just like our first-party offerings do within AWS," he said. "So that gives customers the option to go kick the tires, get going, even scale up and use the services without going through a traditional sales cycle." Shadow agents and AI cost harvesting emerge as the next frontier of cloud security threats Both AWS executives addressed an emerging security concern gaining traction among CISOs: the proliferation of unregistered AI agents — what the industry has begun calling "shadow agents" — and the novel attack patterns they enable. Kapoor told VentureBeat that shadow agents are a genuine and growing problem, though he was careful to separate it from the Continuum announcement. "There are many agents that are registered with registration directories, whether it's Vertex, whether it's Agent Core, whatever else it might be, but there are many agents that are not registered with the registry, and those are what people are calling shadow agents because they can actually do some harm," he said. "Discovering shadow agents is not easy. The industry is working on it." Fuller provided more granular detail on what AWS has already deployed. Security Hub now includes a free AI inventory capability that uses three data layers: AWS Config identifies AI-related services like SageMaker, Bedrock, and Agent Core across an organization; Amazon Inspector scans compute instances and containers for AI-related software; and GuardDuty compares DNS request and response logs against known AI tools and agentic workloads. Beyond inventory, Fuller revealed that GuardDuty now monitors data plane events — including prompts, prompt volume patterns, and inference cost analysis — to detect what AWS calls "cost harvesting." The attack mirrors the cryptocurrency mining that became common after cloud credential compromises: an attacker gains access to an AWS account and burns through as much free AI inference as possible before detection. "We're seeing what we're calling cost harvesting," Fuller said. "They'll spin up, basically try to get as much free inference as they can until that's discovered." It is, Fuller noted, "the same thing that's happening in AI" as happened with crypto mining — and GuardDuty's detection of credential compromise and unauthorized compute usage translates directly to the new threat. How Continuum and Security Hub Extended fit together in AWS's enterprise security strategy Although both announcements landed the same week, AWS is treating the products behind them as separate. Kapoor described Continuum to VentureBeat as distinct from Security Hub Extended, sold as its own standalone product. AWS declined to discuss its longer-term roadmap for the two. The design logic points in one direction. Continuum addresses the code an enterprise writes and the open source it inherits. Security Hub Extended addresses everything else — and the newest of its categories is where the two most clearly overlap. Continuum's validation phase covers third-party dependencies alongside a customer's own code; Chainguard and Socket harden and monitor the same packages from the other direction. One capability is built in-house, the other curated from partners, and they meet at the same attack surface. Both proceed from the same premise: that enterprises no longer want a catalog, they want a recommendation. "Customers want an opinionated point of view on how they should do security in the AI era," Kapoor told VentureBeat. "That's what Security Hub Extended was about — actually going off and giving them our opinion." AWS will continue to give customers choice, he added, "whether it is something that we ship or whether it is something from a partner." That doctrine — a recommendation, with an escape hatch — is the through line connecting a curated marketplace to a first-party agent platform, and it makes the boundary between them more porous than two separate announcements suggest. Security Hub has already absorbed capabilities that did not exist a year ago, including the free AI inventory and the cost harvesting detections Fuller described. The console is where AWS delivers its opinion to the enterprise. Continuum is the sharpest opinion it has shipped. The audience for that opinion has changed as well, Kapoor said. Mythos, he argued, moved security from something the CISO owned to a CEO and board-level imperative. "Boards are now asking for updates on what's going on with security in the enterprise because it's a business threat now, it's a business risk." AWS's security ambitions reflect a calculated bet on owning the orchestration layer The twin launches fit within a broader strategic arc AWS has been building throughout 2026 at a breakneck pace. The company re-imagined Security Hub at re:Invent 2025 by consolidating GuardDuty, Inspector, CSPM, and Access Analyzer into a single console. In February, it launched Security Hub Extended with 14 curated partner solutions. By May, that number grew to 21 across nine categories. Now it stands at 23 across 10. Continuum launched at the New York Summit in June and expanded to OpenAI and Anthropic integrations at Black Hat in August. AWS generated $42.2 billion in revenue during Q2 2026, with cloud sales expanding 37% year over year. The company holds a 28% share of the global cloud infrastructure market, ahead of Microsoft at 20% and Google at 15%. Fuller told VentureBeat that AWS has "tens of thousands of customers using one or multiple of our security services, essentially across all geos that we operate in, and in every industry, and both commercial and government." The Extended plan aims to convert that installed base into users of partner security solutions — deepening engagement and making it harder for competitors to dislodge AWS as the default platform. By making AWS the seller of record for 23 partner security solutions and embedding Continuum inside the coding environments of OpenAI and Anthropic, AWS is constructing something more durable than a product line. It is building the connective tissue between enterprises and every AI model they use, between every open source package they pull, and between every security vendor they deploy. In a world where frontier models are advancing so rapidly that today's best scanner becomes tomorrow's table stakes, the layer that persists is not the model — it is the harness that connects the model to the customer's environment, policies, and risk tolerance. Kapoor, reflecting on a chance conversation he had on a flight to Black Hat, offered the simplest articulation of why all of it matters. A former CISO turned CTO sitting beside him volunteered a blunt assessment of the current moment: "I don't feel safer now." Kapoor's response, he told VentureBeat, was equally blunt: "We're working on it." Whether that work makes the world safer or simply makes AWS indispensable to every organization trying to get there may, in the end, amount to the same thing.

8/10/2026

Brex CEO Pedro Franceschi offered a blueprint for one of the pressing challenges facing the enterprise today at VB Transform 2026: securely deploying AI agents, like the open-source OpenClaw, into production environments. Unlocking this enterprise value requires a mindset shift. The industry needs to move past vague terminology and focus on concrete enterprise roles.  “People talk a lot about agents, but I think 'agents' is a terrible name. It's this Silicon Valley concept that doesn't really mean much,” Franceschi said.  Instead, the goal should be creating entities that can genuinely collaborate with human workers. "The concept we always had in mind was the idea of a virtual employee — someone on Slack, an entity, it has an email address, it can join meetings, you can email it, and that you can work with," Franceschi said. Realizing this vision demands a new security paradigm. Franceschi’s presentation detailed how Brex pointed OpenClaw at internal roles, realized traditional security models failed, and built a novel network-level security layer called CrabTrap. The OpenClaw security dilemma The journey began following a breakthrough in December, when coding models reached a level of maturity that enabled the January release of OpenClaw. This marked the moment agents could finally self-bootstrap and maintain their own codebases instead of relying on hard-coded, static tools.  However, when Franceschi proposed deploying this to automate internal functions, the Brex security team firmly rejected the idea. “They said, 'Hell no. How could we trust an agent doing these things? This thing has code execution capabilities. There's no way to control it,'” Franceschi said. That caution isn't unique to Brex — enterprises broadly have been wary of granting agents uncontrolled code execution on corporate networks. To solve this, Brex had to shift the security perimeter. Franceschi contrasted this with approaches like Nvidia's NemoClaw, which he said secure agents by limiting their tool usage — a model he believes neutralizes the coding capabilities that give agents their value. “… the premise we had was that the coding capabilities were critical to the model having the ability to do a variety of tasks,” he said.  Brex's fix was to shift the security boundary to the network layer instead. Instead of policing the ever-changing code inside the container, the focus must shift to monitoring what the code actually attempts to send or receive from the outside world. CrabTrap and the LLM-as-a-judge solution This network-centric approach led to the creation of CrabTrap, an open-source HTTP proxy built by Brex. The mechanism operates on the assumption that OpenClaw can do anything and might already be compromised. Therefore, CrabTrap monitors all outbound network traffic between the container and the internet, using an LLM to judge whether that traffic aligns with the agent's approved policy. “Instead of trying to control the code running in the container, assume the thing can do anything and monitor the network traffic between that container and the internet,” Franceschi said.  Using a large language model (LLM) to judge every single network request introduces unacceptable latency, often adding thousands of milliseconds to response times. Brex solved this by passing traffic through a bifurcated system.  Routine, low-risk actions pass through static, pre-approved rules instantly. If a recruiting agent tries to view a LinkedIn profile, the static rule allows it. However, high-risk actions such as sending emails are flagged and routed to the LLM judge for evaluation. Franceschi said that architecture ensures only about 2% of complex requests actually face LLM latency.  A surprising finding from the project was how effectively the LLM judge performs this role. Franceschi attributed this to the models' training: LLMs are exposed to billions of web pages and HTTP requests, giving them what he described as an inherent semantic understanding of network traffic patterns. “[Models] are very good at discerning what is within the policy and what is not,” Franceschi said, adding that this capability emerges naturally through pre-training without needing heavy prompting. Brex put this infrastructure to the test with “Jim,” a virtual recruiter built on OpenClaw. Jim handles various tasks, including sourcing candidates, scoring inbound applicants, and sending emails.  When Jim attempts an action that falls outside the established policy, CrabTrap relies on a human-in-the-loop workflow. If the LLM judge flags an unapproved outbound email, CrabTrap pings a human manager on Slack.  The Slack notification explains the agent's underlying intent and suggests a policy change that would allow the action. The human manager can then review the context and click "yes" or "no" to update the rules dynamically.  "I like the virtual employee analogy because a lot of these things were solved already in a company, in the context of humans," Franceschi said. "When an employee hits a wall, they escalate to their manager." The cost of the frontier Brex is a fintech company, not a cybersecurity vendor. The decision to build CrabTrap in-house was driven by a lack of mature commercial solutions that could satisfy their security team.  Franceschi acknowledged the inherent cost of operating at the bleeding edge, admitting that commercial vendor solutions will likely catch up.  “When we built this, it was clear to me there was a 70% chance we would throw it away in six months... But what we learned by being six months ahead was worth it in shaping our AI adoption strategy,” he said.  The investment in building internal tools provided Brex with the experience needed to safely deploy agents months ahead of the broader market. For enterprise leaders navigating the AI landscape, the core takeaway is the necessity of building the cultural and technical muscle to operate in an agentic world today.  “We don't have all the answers, but the answer is not to do nothing,” Franceschi said.

8/10/2026

Meta today released Muse Glimmer, a 30-billion-parameter open-weight model designed to run autonomous AI agents directly on consumer hardware — pushing agentic workloads that normally depend on cloud infrastructure onto high-end Macs and PCs. Just as notable as what the model does is how it's licensed. Glimmer arrives under the permissive, industry-standard Apache 2.0 open source license — the company's first fully open release since it succeeded its open-weight Llama family in April with the proprietary Muse Spark. In fact, Muse Glimmer launches today with a more permissive license than Llama ever carried. Llama's bespoke community license drew years of criticism for restrictions like its 700-million-monthly-user cutoff; Apache 2.0 has no such strings, permitting unrestricted commercial use, modification and redistribution. The weights are available on Hugging Face now. Wang said support is rolling out this week through Ollama, LM Studio, vLLM, SGLang, Together AI, Fireworks AI and OpenRouter, with optimized llama.cpp, MLX and ExecuTorch integrations landing in the coming days; Meta's blog post also names Unsloth as a local-runtime partner and points to PyTorch's TorchTitan for fine-tuning. The company says it is working with AMD, Arm, Dell, Intel and Nvidia to optimize performance across devices, and has published developer documentation covering custom agent scaffolds. "Today we're also opening the weights for Muse Glimmer, a great 30B parameter dense model that can run locally," Meta co-founder and CEO Mark Zuckerberg wrote in a post on X (under his longtime handle @finkd). "Soon we'll also release the weights for Muse Spark 1.2, our latest foundation model. Meta is a strong supporter of open source and I'm proud of these releases." That promised Muse Spark 1.2 release would be an even bigger shift: it's the frontier model behind Muse Code, the terminal coding agent Meta shipped just five days ago, and until today the entire Muse family was proprietary. Zuckerberg had teased at that launch that he'd "have more to share soon" on open source. Now we know what he meant. For developers and enterprises, the practical stakes of local inference go beyond where computation happens. An agent working with files, screenshots, development environments and other sensitive context can execute those workflows without continuously sending that information to a remote inference service. Local deployment also removes network availability and per-token API charges from the inference loop — although organizations still bear hardware, electricity, deployment and management costs. A 30B model built around the agent loop Rather than positioning Glimmer primarily as a general chatbot, Meta trained it around the sequence of operations an autonomous agent performs: formulate a plan, call tools, interpret the results, continue working, and recover when something goes wrong. "Just like much larger models, muse glimmer can operate as a fully capable agent via planning, tool calls, checking its own results, and failure recovery," Alexandr Wang, Meta's chief AI officer, wrote in a thread on X announcing the release, adding that the model "can run on 24GB of VRAM without losing agentic reliability." According to the model card on Hugging Face, Glimmer is a dense causal transformer with approximately 29.6 billion total parameters across 52 layers, including a dedicated ~1.8B-parameter ViT-G/14 perception encoder. It accepts interleaved text and images, produces text, supports more than 100 languages and has a stated context length of 131,072 tokens or more, with a knowledge cutoff of January 4, 2026. That combination is intended to let an agent interpret screenshots, charts and documents while simultaneously reasoning about text and invoking external tools. Glimmer offers low, medium, high and xhigh reasoning settings — set via the system prompt — so applications can dial reasoning effort up or down per task, and Meta says it works across agentic scaffolds including OpenClaw and Hermes Agent. The model is a distillation of Meta's larger flagship: per the company's technical blog post, Glimmer was pre-trained on Muse Spark's outputs using logit distillation, mid-trained on longer-context, agent-heavy data with richer reasoning traces, then post-trained with supervised fine-tuning, on-policy distillation and reinforcement learning across general, reasoning, coding and agentic domains. Meta demonstrated the result with a local Home Assistant workflow: in a demo video, Glimmer autonomously discovers a Home Assistant instance on the network via tool calls, queries device APIs, writes a responsive HTML/CSS/JavaScript dashboard from scratch and deploys a local server to verify its own work. That's closer to the operational reality of enterprise agent deployments than a standalone question-answering benchmark — the model has to maintain a plan while interacting with external systems, then inspect whether its actions produced the expected result. Compressing an agent into 24GB The hardware story is central to the release. At full precision, Meta says the 30B model requires more than 55GB of memory — beyond any single consumer GPU. The company therefore developed approximately 4-bit quantized versions that shrink the language-model weights to under 20GB, leaving headroom for the pieces an operational agent also needs in memory: the KV cache, the perception encoder and a companion speculative-decoding model, all fitting within a 24GB or 32GB envelope. In practical terms, that means the quantized builds run on consumer machines — though the upper end of them. The 24GB-targeted K-Quant-17GB configuration fits on a single high-end consumer graphics card, such as Nvidia's RTX 3090 or RTX 4090 (both with 24GB of VRAM), while the 32GB-targeted K-Quant-Dynamic version lines up with the newer RTX 5090's 32GB. On the Mac side, Apple Silicon's unified memory plays the role of VRAM, so a MacBook Pro or Mac Studio with 32GB or more of memory can hold the full stack — Meta ran its own speed tests on M4 Max and M5 Max MacBook Pros. A typical 8GB or 16GB laptop, however, remains out of reach, and the full-precision BF16 release — which Meta pegs at 64GB — stays in the territory of data-center GPUs and top-spec Mac Studio configurations. Meta reports average accuracy degradation of just 0.2% across 15 benchmarks for its K-Quant-Dynamic version targeting 32GB hardware, and 1% for the K-Quant-17GB configuration targeting 24GB hardware. Those figures are Meta's own measurements, not independent evaluations. Meta is also using DFlash speculative decoding to attack the other big problem with local agents: latency. Instead of generating every token sequentially, a smaller DFlash "drafter" model proposes blocks of 16 tokens that the primary model verifies in parallel, producing identical output faster. Meta reports this raises average generation speed on an Nvidia RTX 5090 from 74.9 tokens per second to 233.4 — a 3.1x increase. An Apple M5 Max rises from 26.6 to 50.2 tokens per second (1.8x), and an M4 Max from 23.7 to 37.8 (1.5x). The tests used batch size one and greedy decoding, with Apple systems measured via ExecuTorch and the RTX 5090 via llama.cpp. For agent applications, those multipliers matter more than they would for chat: a single user request can trigger many model turns, tool calls and verification steps, and latency accumulated at every stage can quickly make an otherwise capable agent impractical. Glimmer enters an increasingly competitive local-model market Meta is not entering an empty field. Developers already have capable open-weight models in this size class, most prominently Google's Gemma 4 family and Alibaba's Qwen3.6-27B — both of which position themselves around reasoning, multimodal understanding and agentic workloads. Meta's own benchmark table compares directly against both. Glimmer leads that three-way comparison on several agentic tests, including MCP Atlas at 75.5, DeepSearch QA at 74.6, τ³-Banking at 23.5, WildClawBench at 47.6 and GAIA2 at 43.3. It scores 51.2 on SWE-Bench Pro, versus 36.9 for Gemma4-31B and 50.2 for Qwen3.6-27B in Meta's evaluation. But Glimmer does not sweep the field. Qwen leads Meta's own comparison on OSWorld-Verified (75.6 vs. Glimmer's 65.9), TerminalBench 2.1 (60.7 vs. 51.7), SkillsBench, GDPval-AA (1141 vs. 953) and most of the multimodal benchmarks. On SWE-Bench Verified, Glimmer's 76.0 lands just below Qwen's 77.2. Gemma leads on GPQA Diamond and Humanity's Last Exam. Read honestly, the numbers make Glimmer more interesting as a specialized local-agent model than as evidence of a universal performance lead. For enterprise developers, the practical question is whether its combination of agent reliability, quantization quality, tool compatibility and decoding speed translates from benchmarks into sustained real-world workflows. Model Developer / origin AA score Parameters / context Lowest tracked API price Access License Strongest use cases Kimi K3 Moonshot AI; China 60 2.8T total / 104B active; 1M $3.00 input / $15.00 output via Kimi, Fireworks or Modal (pricing) Weights Kimi API Custom Kimi K3 license. Large model-as-a-service operators above $20M in 12-month revenue need a separate agreement Large products may need to display “Kimi K3.” Frontier long-horizon coding Multimodal research and complex tool-driven agents GLM-5.2 Z.ai / Zhipu AI; China 53 753B / 40B active; 1M $0.75 / $2.40 via DeepInfra FP4 (pricing) Weights Z.ai API MIT Long-horizon coding and agents Million-token analysis with adjustable reasoning DeepSeek V4 Flash 0731 DeepSeek; China 52 284B / 13B active; 1M $0.09 / $0.18 via DeepInfra (pricing) Weights DeepSeek API MIT • Extremely economical reasoning• Coding agents, terminal work and tool use MiniMax-M3 MiniMax; China 45 428B / 23B active; 1M $0.23 / $0.96 via CoreWeave (pricing) Weights ; MiniMax API MiniMax Community License. Commercial attribution required; companies above $20M yearly revenue need authorization. Includes prohibited-use conditions. • Native text, image and video work• Long-context coding and “cowork” agents MiMo-V2.5-Pro Xiaomi; China 43 1.02T / 42B active; 1M $0.35 / $0.70 via GMI (pricing) Weights Xiaomi API MIT Complex software engineering Agents spanning thousands of tool calls Inkling Thinking Machines Lab; U.S. 42 975B / 41B active; 1M in weights $0.95 / $4.05 via DeepInfra FP8 (pricing) Weights Tinker Apache 2.0 Customizable text, image and audio foundation Fine-tuned coding, RAG and tool-use systems Nemotron 3 Ultra 550B A55B NVIDIA; U.S. 38 550B / 55B active; up to 1M in weights $0.37 / $1.08 via Blackbox AI (pricing) Weights OpenMDW-1.1; permissive commercial and derivative-model rights Complex agents and long-context reasoning High-accuracy RAG, code, math and science Mistral Medium 3.5 Mistral AI; France 30 128B dense; 256K $1.50 / $7.50 via Mistral (pricing) Weights Mistral API Modified MIT. Companies above $20M consolidated monthly revenue must obtain a commercial license or use Mistral’s service. Coding agents and function calling Multimodal instruction following Gemma 4 31B Google DeepMind; U.S. 30 30.7B dense; 256K Free on Google AI Studio’s limited tier; paid low $0.10 / $0.34 via CoreWeave (pricing) Weights Google AI Studio Apache 2.0 Compact multimodal reasoning and coding Manageable local or private-server deployments gpt-oss-120b OpenAI; U.S. 24 117B / 5.1B active; 131K $0.03 / $0.17 via CoreWeave (pricing) Weights Numerous third-party APIs Apache 2.0 Reasoning structured output and tools Fine-tuning and single-80GB-GPU deployment Command A+ Cohere; Canada 23 218B / 25B active; 128K input Free on Cohere’s currently tracked endpoint (pricing) Weights Cohere Apache 2.0 Enterprise RAG and grounded citations• Multilingual agents and document processing Muse Glimmer 30B Meta; U.S. Not yet scored 29.6B dense, including vision encoder; 131K+ No public metered hosted price located on launch day Weights Meta model page Apache 2.0 for full-precision weights, quantizations, drafter and perception encoder Always-on local agents on 24–32GB systems Tool use, recovery, coding and screen/document understanding Meta Glimmer adds to a still-small roster of genuinely open, frontier-class models from U.S. companies. For the last two years, Chinese companies have set the pace in open source AI, with DeepSeek, Alibaba's Qwen team, Moonshot AI's Kimi, Zhipu's GLM and MiniMax shipping frontier-class open models under MIT and Apache 2.0 licenses on a cadence Western labs haven't matched. The usage data reflects it: by May 2026, Chinese open-weight models accounted for roughly 61% of all tokens consumed on OpenRouter, with four of the five most-used models coming from Chinese labs — while Meta's Llama, the prior open-weight leader, fell off the rankings entirely. The U.S. counterexamples remain countable on one hand: OpenAI's gpt-oss-120b and gpt-oss-20b, released under Apache 2.0 in August 2025 as the company's first open weights since GPT-2; Google's Gemma family, which is open-weight but ships under Google's own more restrictive custom license rather than an OSI-approved one; and Thinking Machines' Inkling. Glimmer invites the most direct comparison to gpt-oss: both are Apache 2.0, both offer adjustable reasoning effort, and both target self-hosted deployment. But the gpt-oss models are text-only, sparse mixture-of-experts designs built primarily for reasoning and tool use — gpt-oss-20b fits in about 16GB of memory while gpt-oss-120b targets a single 80GB data center GPU. Glimmer stakes out different ground: a dense model with native vision input, trained end-to-end around the agent loop, shipping with its own quantized variants and speculative-decoding drafter tuned for 24GB consumer machines. And if Zuckerberg follows through on opening Muse Spark 1.2's weights, Meta would put an actual U.S. flagship frontier model into open circulation — something no American lab has done at that tier. Safety remains part of the deployment architecture Giving a local model access to tools creates a different security problem from deploying a local chatbot — and Meta's own safety numbers show Glimmer is not uniformly stronger than its peers. On CI Memories, a privacy benchmark where lower violation rates are better, Glimmer records 26.4 against Gemma's 12.1 and Qwen's 53.4. On Siren AgentDojo, a prompt-injection test, Glimmer shows a 28.4% attack-success rate versus 25.6% for Gemma and 40.3% for Qwen — while posting the highest utility score of the three at 94.2. Meta says it evaluated Glimmer under its Advanced AI Scaling Framework and determined the model does not meet the framework's definition of "Frontier AI" because it is generally less capable than Muse Spark. Its Preparedness Team assessed Glimmer at Moderate or lower risk across chemical/biological, cyber and loss-of-control categories — the latter two inferred from the fact that Glimmer is broadly weaker than Muse Spark 1.0, which received the same designations. The company nevertheless recommends deploying Glimmer as part of a broader system with guardrails, including human-in-the-loop confirmation for irreversible actions. That caveat matters especially for local agents: keeping data on-device reduces exposure to cloud infrastructure, but local execution does not by itself solve prompt injection, excessive permissions or an agent taking an unintended action. Apache 2.0 weights and a fast-growing runtime ecosystem Meta is releasing full-precision BF16 weights, both 4-bit quantized variants, the DFlash drafter and the perception encoder — all under Apache 2.0. There is no Meta API price attached to the downloadable model, leaving total cost dependent on local hardware or whatever third-party hosting developers choose. One nuance worth noting for procurement teams: as with most "open source" model releases, it is the weights that are open — Meta has not released the training data or training code. The broader implication is that Meta is treating the developer workstation as a credible deployment target for autonomous agents, rather than merely a place to experiment with smaller language models. Glimmer's 30B size and 24GB target put that proposition within reach of high-end consumer hardware, while the Apache 2.0 license gives developers — and their legal departments — unusual freedom to modify and deploy it. The next test is whether its benchmark advantages survive the messier conditions of real software repositories, enterprise tools and long-running agent sessions. If they do, the most consequential part of Glimmer may not be another set of benchmark scores — it may be that a class of agent previously expected to live behind a cloud API can increasingly live, and work, on the machine sitting under a developer's desk.

8/10/2026

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 explains almost everything about the state of agentic development right now. Six decades versus a year and a half. We are not in the middle of this learning curve. We are standing at the very bottom of it, squinting up. There is no LAMP stack for agents yet. There is no settled, boring, default set of choices that lets a team stop re-litigating architecture and just ship. One of the earliest lessons came from the industry’s brief obsession with token-maxxing. For a stretch in early 2026, token consumption became a vanity metric. The backlash was fast. Token volume measures activity, not outcomes. But the interesting part of the token-maxxing story was never the workplace theater. It was the architectural lesson hiding underneath it. The context window is the scarce resource What follows is an aggregation of what I’ve learned from more than 100 customer conversations across 15 cities in six countries during the first half of 2026. I’m seeing organizations begin to converge on the same conclusion: the context window is the scarce resource. The challenge isn’t stuffing more information into every prompt. It’s deciding what belongs there in the first place. That question has an answer. The answer is memory. Not the loose way people use that word to mean “the context window,” but a real, persistent, queryable memory system that sits outside the model and feeds it deliberately. The answer is memory, and it is more than short-term and long-term A good agentic memory does three things that the context window alone cannot: It saves what the generative model produced on previous loops and previous sessions, so the expensive reasoning you already paid for does not evaporate the moment the session ends. It applies role-based access control to that saved content, so a memory created by one team can be shared across an enterprise without leaking things it should not. It lets new queries retrieve the right prior content, which in practice means it is backed by semantic search rather than exact-match lookup, because agents ask for things by meaning, not by key. That last point is where this connects back to the 60-years-of-databases observation. We spent six decades getting extremely good at storing and retrieving structured data by exact criteria. Agentic memory needs something different and newer: the ability to store the unstructured output of a generative process and find it again by similarity. The teams building this well are the ones whose data platform can do semantic search natively, apply access control to it, and hold the generated content in the same place, rather than stitching three systems together with hope. The pattern that is emerging in enterprises Once you have memory like that, a genuinely interesting architecture falls out of it, and I am seeing more enterprises converge on it. You pair the powerful memory system with a leaner model, often an open-weight one, whose job is not to be brilliant but to be a good judge. A new query comes in. The agent does a semantic search on the memory, reranks to get the best candidate answer, and asks the leaner model a single question: is this good enough to return as is, or not? If it is good enough, you return it. You never paid for the expensive generative model at all. You answered from memory. If it is not good enough, you escalate to the more expensive generative model, get an original solution, return that, and then save it back into the same memory system so the next session does not have to pay for it either. Think about what that does to agentic economics over time. Every original answer the expensive model produces becomes a cheap answer the next time someone needs something similar. The system gets cheaper and faster the more it is used, which is the opposite of how naive token-maxxing scales, where cost grows linearly with usage forever. This is the difference between an agent that learns what it already knows and one that re-derives the universe on every loop. Memory has types, and humans curate the best ones The last piece, and the one I think separates where we are headed from where we are now, is that mature agentic memory will not be a flat bucket of short-term and long-term. It will have types, the way human memory does. Taxonomic memory holds terminology, the controlled vocabulary and definitions an organization runs on, so the agent uses "chargeback" to mean what your finance team means by it and not what the internet at large means. Procedural memory holds task lists and sequences, the how-we-do-this-here knowledge that turns a capable model into a useful colleague. There will be more types than these, and figuring out the right taxonomy of memory types is itself part of the learning curve we are climbing. And here is the part that should sound familiar to anyone who has run a real production system: the best memories often get there because a human put them there. Not every memory an agent generates is worth keeping, and not every kept memory is worth surfacing first. Increasingly I expect to see humans curating these systems, injecting the high-value memories back in for frequent reuse, pruning the noise, promoting the procedural sequence that works over the three that mostly work. We did this for knowledge bases. We did it for documentation. We will do it for agentic memory, because curation is how a corpus stops being a landfill and starts being an asset. What comes next? We are 18 months, give or take, into agents and 60 years into databases. The gap between those two numbers is not a problem to be embarrassed about. It is just the truth about how early it is, and it should make us humble about every "best practice" that is barely a season old. Token-maxxing was the first big idea to rise and fall inside this new field, and its fall taught us the lesson the field most needed: the context window is scarce, so the discipline is in choosing what goes in it. That discipline is agentic memory. Semantic-search-backed, access-controlled, typed, human-curated memory that saves what was expensive to produce and serves it cheaply forever after. There is still no LAMP stack for agents. But if I had to bet on which layer becomes the boring, default, settled choice first, the one we stop arguing about so we can get back to building, I would bet on memory. That is the next advancement in agentic development. Everything else is still hand-wiring CGI-BIN. Pete Johnson is Field CTO, AI at MongoDB. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/10/2026

Content filters can block unsafe output. They cannot tell you whether an agent was authorized to issue that refund, touch that production system, or commit the company to an external action. Those are different problems, and most enterprises are only solving the first one. An AI agent can follow its instructions perfectly and still take an action the business never sanctioned. In commerce environments, I have seen this pattern emerge in practical ways. A service workflow calculates the correct refund amount but lacks a boundary preventing credits above what the business approved for autonomous action. An order agent correctly applies a requested change but overlooks a financing or fulfillment condition. A procurement agent identifies the lowest-cost supplier, but nobody has defined whether it can accept contractual terms or only recommend the option. The agent keeps working. The problem may not surface until something downstream breaks. These are not necessarily AI reasoning failures. They are failures to separate technical capability from business authority. As enterprises move from copilots that recommend to agents that call tools and trigger workflows, every production agent needs explicit decision rights: What it may execute, what requires approval, what it may only recommend, and what it must never touch. Guardrails remain necessary. But a guardrail is not an authority model. Safety controls and decision rights solve different problems Early gen AI controls screen harmful content, protect sensitive information, validate responses, and constrain tool behavior. That work matters. Decision rights answer a different question: Even when an action is safe and technically valid, is this agent authorized to take it on behalf of the enterprise? That governance gap is becoming harder to ignore. In April 2026, a Cloud Security Alliance survey found that 65% of respondents had experienced an AI-agent-related incident in the prior year, while 82% had discovered previously unknown agents operating in their environments. The survey involved 418 IT and security professionals and was sponsored by Token Security. The findings illustrate how quickly agent activity can outpace the visibility and ownership structures built for conventional software. The World Economic Forum’s May 2026 playbook reflects this shift. It introduces an Agent Capability and Authorization Profile designed to make delegated actions auditable, enforceable and accountable. Guardrails constrain behavior. Decision rights define legitimate authority. Give every production agent an authority contract Before an agent receives access to enterprise tools, it needs a machine-enforceable record of exactly what authority the business has chosen to delegate. Call it an Agent Authority Contract. At minimum, that contract should answer seven questions: Who owns the outcome? Name a human or business role, not another system. What may the agent do? Read, recommend, write, or commit? Which systems and data may it reach? What materiality limits apply? Define dollar thresholds, record counts, customer scope, and operational impact. What triggers escalation? Uncertainty, anomaly, sensitive data, or potential impact? Can the action be reversed, and who can reverse it? When does the authority expire, and how is it withdrawn? Access control determines whether an agent can reach a system. The authority contract determines whether it may take a specific action in the current context. Those are not the same check. Singapore’s updated Model AI Governance Framework for Agentic AI draws a similar distinction. It treats access controls, behavioral guardrails, and human approvals as separate controls and ties oversight requirements to action scope, reversibility and potential impact. Resolve every consequential action into four outcomes A working decision-rights model should map every consequential agent action to one of four results. Allow Low-risk, bounded, and reversible actions run autonomously. Examples include retrieving approved information, classifying an inbound request, or updating a non-material field. The agent acts without prior review because the potential impact is limited and the action can be reversed. Approve The agent prepares or initiates the action, but execution waits for authorization from a human or deterministic policy service. This category covers payments, production changes, and actions that materially affect a customer, employee, or third party. Recommend The agent analyzes, ranks, drafts, or proposes. A named human makes the final decision. Use this outcome when contextual judgment matters or when the legal, financial, or individual impact makes automated execution unacceptable. Deny The action remains outside the agent’s authority regardless of its confidence. Deleting critical production data, making a final employment decision or overriding a mandatory compliance control should remain in the Deny category even when the agent’s underlying reasoning appears correct. One point gets missed consistently: Deny must be enforced outside the system prompt. A natural-language instruction telling an agent not to do something is not a technical boundary. It is a suggestion. Make authority decisions at runtime Static configuration cannot cover every situation. A small service credit might be allowed under normal conditions but require approval when the amount crosses a threshold, the account is under investigation, or the request involves a regulated customer. A practical runtime sequence looks like this: The agent proposes an action. A policy layer evaluates the agent’s identity, delegated principal, requested tool, data involved, transaction context, and potential impact. The policy returns Allow, Approve, Recommend, or Deny. The system records the authority decision, resulting action and outcome. Operational telemetry expands, narrows, or revokes the agent’s authority over time. In enterprise commerce, the most dangerous AI mistake is not always a false answer. It can be a technically correct action the agent had no business taking. A refund may be accurate but exceed an approval limit. An order change may match the customer’s request but invalidate a financing condition. A delivery promise may reflect available inventory while overlooking a carrier constraint applied an hour earlier. The agent may not have failed to reason. The enterprise failed to define where its authority stopped. Human oversight should target exceptions, not everything Requiring human approval for every agent action looks conservative. At scale, it can quickly degrade into rubber-stamping. When reviewers approve thousands of routine actions, attention declines and genuine exceptions become harder to identify. Singapore’s framework acknowledges that continuous human oversight of every agent workflow becomes impractical at scale and recommends meaningful checkpoints for higher-risk or irreversible actions. Proportional authorization is the more workable model. Low-risk actions run within narrow boundaries. High-risk or irreversible actions require approval. Unexpected behavior triggers escalation. Any consequential action without a defined authorization policy is denied by default. The objective is not maximum autonomy. It is the highest level of autonomy the enterprise can observe, govern and reverse responsibly. Measure whether authority is calibrated Once agents are in production, response accuracy becomes too narrow a success metric. Enterprises should also track: Override rate: How often do humans reject or materially change what the agent decided? Escalation precision: Does the agent surface genuinely risky cases, or does it return routine work to people? Unauthorized-action attempts: How often does the agent try to exceed its system, data, or action scope? Business-impacting error rate: How often do authorized actions produce financial, compliance, operational, or customer harm? Decision latency: Are approval requirements managing risk, or slowing down automation that was already safe? These measures turn authority into a governed operating variable. Consistently reliable performance may justify expanding bounded authority. Frequent overrides, escalation failures, or policy violations should narrow it. The governance gap is not in the model Model safety, output controls, and secure tool use all matter. Enterprises should continue investing in them. But none of those controls can answer who delegated authority, how much was transferred, under what conditions it applies, or who owns the result when something goes wrong. An Agent Authority Contract can. Before asking how autonomous an AI agent can become, the more useful question is: What is the enterprise actually prepared to delegate, and how will that delegation be enforced, observed, and withdrawn? The agent demo works. That is not the hard part anymore. Nixal Patel is a product leader. The views expressed are his own

8/7/2026

As enterprise codebases grow, AI agents tasked with analyzing them are buckling under the weight of long-horizon tasks that require multiple interactions and tool calls. Dividing the work among a team of agents seems like the obvious fix, but it introduces a fatal flaw: most multi-agent systems are not designed for agents to coordinate among themselves mid-task and in real time. To solve this, researchers at Coral AI Labs and multiple universities introduced AgentRadio, an asynchronous message-passing layer that allows agents to communicate between their execution steps without interrupting their main work. In real-world enterprise applications where subtasks are highly interdependent, this architecture enables agents to make mid-course corrections rather than continue on dead-end paths until a formal review phase. On a benchmark of long-horizon questions over production repositories, a team of agents powered by AgentRadio nearly doubled task accuracy for four Claude Code agents working independently. It also outmatched single agents running on more advanced models. For AI practitioners, AgentRadio shows that the right coordination structure can outmatch raw compute and model scale. The challenge of codebase understanding LLM-based agents are increasingly capable of handling long-horizon tasks that require interacting with different tools and environments. Codebase understanding represents an extreme version of this challenge. It requires an AI agent to build the software, execute it, trace execution paths across multiple files, and synthesize evidence over extended periods. Under these conditions, single-agent systems usually break down because of a “coverage problem.”  "A single agent follows one serial path through the repository," Xinxing Ren, Caelum Forder, and Peter Carroll, co-authors of the AgentRadio paper, explained to VentureBeat. As its context grows, "the initial plan becomes harder to revise and discoveries made late in the investigation do not always propagate." The model can usually execute individual steps, but "the hard part is keeping every obligation, dependency, and piece of contradictory evidence active across a long investigation." One benchmark that helps measure AI performance on large codebases is SWE-Atlas QnA. This benchmark consists of long-horizon, natural-language questions over live production repositories. The tasks can’t be solved by just exploring the code. AI agents must run the software and execute multiple commands to find the answers. According to the research team’s experiments, a single Claude Code instance running on Opus 4.6 resolves just 32.3% of these tasks. Upgrading to a newer, more advanced model like Opus 4.8 only yields a 57.2% success rate. A natural remedy is to distribute the workload across multiple agents, allowing each to work with a smaller, cleaner context. Multi-agent solutions can provide substantial performance gains when tasks are cleanly decomposable, meaning they can be solved separately and merged at the end. Codebase understanding, however, is rarely cleanly decomposable. The subtasks are highly interdependent. A critical configuration file or a bug uncovered by one agent can completely rewrite or redirect the entire exploration path of another agent. Because of these dependencies, agents must coordinate, negotiate, and share intermediate discoveries in real time. Despite this need, asynchronous multi-agent communication is rare. The researchers point out that existing multi-agent systems generally fall into three flawed patterns: Parallel but isolated: Agents operate simultaneously but do not communicate at all. Parallel but round-synchronized: Agents can communicate, but only at strict, synchronized round boundaries. This forces agents to stop and wait for one another to finish a round before they can debate or exchange intermediate findings. Round-based systems assume that important discoveries can wait until the next communication phase, which is an expensive assumption when agents are working on interdependent parts of a live system. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent's current hypothesis. "If that information waits until both agents finish, the storage investigation may complete along the wrong path," the researchers said. Asynchrony in adjacent forms: These systems offer limited asynchronous features, such as top-down task dispatching. They don’t have peer-to-peer lateral channels between agents or shared memories that require an agent to actively pause its work to read updates. In their paper, the researchers point out that the main bottleneck hindering current multi-agent systems is that “an agent that is working cannot also be listening.” “To our knowledge, no existing system gives concurrently working agents passive awareness of one another over a lateral, natural-language channel,” the researchers write. How AgentRadio works To dissolve the mutual exclusion between working and listening, the researchers developed AgentRadio, an asynchronous message-passing layer designed to plug directly into existing coding-agent harnesses. AgentRadio equips agents with three primitives: The create_thread primitive opens a conversation between participating agents. The send_message primitive appends a message to a thread and returns without blocking the sending agent. The wait_for_mention primitive blocks the process until a message mentioning the caller arrives. It delivers the message along with a full snapshot of all threads so the agent has instant context.  This trio enables agents to have a state of “passive awareness,” where they can continue their primary tasks while passing messages and updating their knowledge in the background. AgentRadio's code is available under the Apache 2.0 license on GitHub. It is designed to be lightweight, requiring no direct modifications to the underlying agent harnesses like Claude Code or Codex CLI.  The architecture consists of two main parts: The message server: A standalone process that acts as the central hub, storing all active threads, messages, and mentions for the group of agents. Harness-side integration: Agents interact with the server using three simple shell scripts, one corresponding to each primitive. The only strict requirement for the system to work is that the agent harness must be able to run a shell command as a background task. The agents are instructed in their system prompts to keep one watcher running and to send messages through the provided scripts. Running the wait_for_mention script in the background allows the agent to continue its work and receive notifications asynchronously. To integrate this into an existing stack, a team still needs a "thin adapter that starts the workers, assigns identities, connects them to the shared server, and manages final synthesis," the researchers said. That work sits around the coding agent rather than requiring changes to the underlying model. AgentRadio in action To validate the real-world utility of AgentRadio, the researchers tested the framework on 124 tasks from the SWE-Atlas QnA benchmark. The tests covered domains including system design, root-cause analysis, security, and API integration. The researchers used Claude Opus 4.6 and DeepSeek V4 Pro as the backbone models. For the harness, they evaluated configurations ranging from a single Claude Code agent (B0) to a team of agents with classic division of labor (L1), up to a team of agents using AgentRadio to coordinate asynchronously (L3). The experimental results showed that the AgentRadio communication architecture outperforms both naive multi-agent setups and raw compute scaling. While a single Claude Code agent with Opus 4.6 resolved only 32.3% of the tasks, the full AgentRadio setup nearly doubled that metric, resolving 62.1% of the tasks, and surpassed the single agent running on Opus 4.8, which hit 57.2%. It also boosted the DeepSeek V4 Pro results from 29.0% to 50.8%.  To understand how this practically impacts enterprise AI, the paper highlights a real-world task involving a MinIO system. Solving the task required checking per-request server logs, a requirement the agents did not anticipate during their initial planning phase. In the L2 setting, where agents collaborate but lack asynchronous communications, two agents independently realized they needed these logs while executing commands. Because they could not share this finding mid-execution, one agent gave up privately and the other failed to propose it to the team. During the review phase, the team unanimously agreed on the wrong answer, missing five rubrics. With AgentRadio activated, the agents made the same mid-execution discovery, but one agent instantly broadcasted the required server-side log evidence to the shared worklog. Because the other agents were passively listening, they absorbed this new evidence immediately. This real-time coordination transformed a failing score into a perfect 16 out of 16. "The useful distinction is timing," the researchers said. "The team did not need another agent or another review round. It needed one agent's discovery to reach the right peers before its operational value expired." The researchers note that the same pattern appears in enterprise incident work. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent's current hypothesis. If that information waits until both agents finish, the storage investigation may complete along the wrong path. “Passive awareness lets the second agent incorporate the contradiction at its next work step without interrupting a command already in progress,” they said. The cost and complexity of coordination AgentRadio requires a fixed multi-agent team budget, which inherently multiplies the token cost. The researchers acknowledge that the "tax is real," noting that average API spend rose from $2.96 per task for one Opus agent to $19.45 for the full AgentRadio stack. However, raw scale does not equal performance. When researchers compute-matched the test by spending $17.76 on six independent Opus runs, the models only resolved 37.9% of tasks, compared with 62.1% for AgentRadio. This suggests that AgentRadio's architecture is a structural win, not just a brute-force scale win. Teams should still be aware of inter-agent churn. "Communication can redirect an agent toward better evidence, and it can also distract an agent from a valid path," the researchers warned. A fixed multi-agent team should not become the default response to every engineering task. The more useful test to determine if a multi-agent setup is required is whether the task contains "responsibility breakpoints," the researchers said. These are places "where a competent engineer would involve another person because the work crosses an ownership boundary, needs an independent hypothesis, or carries enough risk to justify separate verification." “Coordination is a strong fit when the task can be decomposed, the resulting parts remain interdependent, the single-agent success rate is unreliable, and an incomplete answer has a meaningful downstream cost,” the researchers said. Examples include repository-wide architecture questions, unfamiliar legacy systems, cross-service incident investigation, security analysis, dependency migrations, and multi-module refactors. Conversely, a single agent remains the cleaner choice for “bounded, local, and reversible work,” such as a known one-file change or boilerplate generation.  “Use one agent while one context can still own the problem honestly,” the researchers said. “Introduce another responsibility when the existing agent would otherwise need to compress away evidence, cross an independent ownership boundary, or verify its own high-impact conclusion.” From research to commercialization: Coral Code While AgentRadio serves as a controlled research implementation using a fixed four-agent team and a five-phase protocol, the underlying principles are being adapted into a commercial product called Coral Code. Instead of a rigid, multi-agent protocol applied to every ticket, Coral Code works from the bottom up. An engineer begins with their existing coding agent, and Coral introduces repository-scoped investigation, specialist responsibility, and communication only when the emerging evidence justifies it. "Coral packages the operational concerns around the tools engineers already use, providing the repository context, scoped specialists, communication, and evidence layer around the harness rather than inside it," the researchers said. This dynamic approach optimizes costs by targeting the relevant unit: the cost of a completed, reviewable outcome. The future of autonomous software engineering While AgentRadio provides a major upgrade to agent orchestration, there are still hurdles to overcome. One major bottleneck that the researchers pointed out to is “attention governance and verification.” “Passive awareness makes communication available during execution. It does not decide which agents should exist, which discovery deserves an interruption, who should receive it, or when the evidence is strong enough to revise the plan,” the researchers said. If every agent receives every update, the communication layer becomes noise. If several agents share the same bad assumption, faster communication can spread the error. For example, in one of the case studies in the paper that involved the Grafana platform, four of nine rubrics required negative conclusions, such as observing that a datasource picker did not select automatically. The agents ran the relevant tests, yet none formed the missing negative hypothesis. Both configurations failed the four rubrics.  “Passive awareness can distribute an idea that somebody develops. It cannot supply a conception that never appears anywhere in the team,” the researchers said. As task durations stretch longer, communication and coordination become critical. "The next generation of systems… needs adaptive responsibility assignment, evidence-aware routing, conflict resolution, explicit cost limits, permissions, recovery, and clear human escalation points," the researchers note. Most importantly, it requires durable provenance so engineering leads can inspect which agent made a claim and why an action was accepted. "Longer-running agents make communication more important. They also make accountability much harder to fake," they said.

8/7/2026

For developers, the operating assumption has been one engineer, one agent — the model Claude Code and similar tools. At VB Transform 2026, James Zou, associate professor of biomedical data science at Stanford University, argued that assumption is about to break: the next frontier isn't a single, more capable agent, it's tens of thousands of them collaborating. For developers and product builders, the most critical takeaway from Zou’s presentation is how these massive systems are orchestrated. His team's research offers a practical blueprint for connecting legacy databases to AI orchestration layers and designing environments that enable thousands of agents to collaborate. Emulating the organization — the virtual biotech Zou’s project began as a "Virtual Lab" consisting of five to eight agents structured to mirror his physical Stanford lab. The setup included an AI professor acting as the principal investigator and AI students with distinct specialties holding regular group meetings.  "We also created for the agents a replica of Stanford, an agent school, where the agents can actually go to the school and do supervised fine-tuning to improve their expertise in their specific domains," Zou noted. The virtual lab successfully designed new nanobody proteins for recent COVID variants.  "What is really exciting to us is that these AI-designed nanobody proteins actually worked much better than the previous human-designed nanobodies in terms of binding to the recent different viruses," Zou said. Following this wet-lab validation, the team expanded their ambition. They transitioned from emulating a single research team to modeling a massive corporate structure.  The resulting system, dubbed the Virtual Biotech, comprises tens of thousands of specialized AI agents overseen by a Chief Scientific Officer (CSO) agent. It operates through distinct corporate divisions, such as target discovery, molecule design, and clinical trials. "Working with the CSO agent are different divisions that mirror the divisions found in a human biotech or pharma company," Zou explained — one focused on identifying drug targets, another on designing molecules, a third on safety and clinical trials. Individual agents specialize further within a division, he said. "Under the target discovery division, we'll have one agent that specializes in looking at all the genetics data, another agent that looks at all the genomics data and single-cell data, and so on." The multi-agent advantage As foundation models grow more capable, developers face a core architectural dilemma: Why distribute workloads across tens of thousands of specialized agents instead of channeling all computing resources into a single, omniscient model? Zou's team ran a head-to-head comparison of a multi-agent team against a single agent tasked with the same scientific challenge. The multi-agent ecosystem created friction and interaction that produced better solutions that were more resilient against compounding errors. "In these scientific virtual labs, the agents actually get into debates and disagreements. They have to convince the other AI scientists [of] their ideas, and all of that elicits much more creative and robust reasoning compared to if you have a single model trying to do the problem by itself from scratch," Zou said. The orchestration bottleneck When scaling to tens of thousands of agents, orchestration becomes the primary bottleneck. The system requires a unified context layer that allows agents to synthesize knowledge from various tools, datasets, and historical records. Many enterprise teams attempt to solve data integration by wrapping existing databases with an MCP. However, legacy systems are not very friendly to agents. For instance, dropping a PDF of a research paper into an agent's context window is inefficient, and standard text models struggle to interpret complex figures and tables, leading to hallucinations.  "Even if you wrap an MCP around the existing databases and APIs, that doesn't solve the underlying problem: the interface and APIs are not suitable for agents," Zou said. He added that existing databases are designed to be consumed by humans or pre-AI algorithms. To resolve this, Zou's team created Paperclip. The platform relies on a core strength of modern LLMs: their ability to write code and navigate file systems. Instead of forcing agents to query brittle, database-specific APIs, Paperclip digitizes unstructured data and maps disparate databases into a unified, AI-native virtual file system. This structure allows agents to access knowledge from millions of papers using standard file-system operations.  "This basically shows that we can get much better accuracy if you use Paperclip, and we can reduce the time and the cost by over an order of magnitude compared to if you use agents without these AI-native scientific infrastructures," Zou stated. Real-world validation To test the practical output of this architecture, Virtual Biotech spun up 37,000 "clinical trial agents" to synthesize fragmented trial data. These agents identified single-cell features that predict trial success — drug targets supported by these features were about 50% more likely to reach market than comparable drugs without them. The system then autonomously designed an antibody-drug conjugate (ADC) targeting the CD276 protein for lung cancer. The agents completed this design autonomously, relying exclusively on data published prior to January 2025. Several months later, Zou said, pharmaceutical company Merck independently developed and validated the same therapeutic design — which went on to receive breakthrough designation from the FDA. He characterized this as "a third-party external validation of the therapeutic design provided by the virtual biotech agents." Designing ecosystems, not workflows As multi-agent systems scale, leaders must rethink how they manage these digital workforces. Zou advocated for shifting from designing rigid workflows to creating open environments. Workflows dictate the exact steps an agent should take, similar to managing a junior employee. Environments provide the infrastructure, guardrails, and incentives for agents to collaborate on open-ended problems.  "In workflows, we're trying to tell agents what to do and how to do their job. But in environments, we're providing the infrastructures, the incentives, and the guardrails, but otherwise we leave it open to incentivize agents to collaborate," Zou said. Optimization at scale means engineering the environment rather than fine-tuning individual models. While single agents can improve via reinforcement learning or supervised fine-tuning in the agent school, the success of a massive multi-agent system relies on adjusting the parameters governing their collaboration.  "At the multi-agent [side], we're not actually fine-tuning and changing the individual models anymore, but we're optimizing the environment," Zou explained. "The environment itself is the object that we optimize to improve the agents."

8/7/2026

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. What Team Memory actually does 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. What happens when a memory is wrong 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. How Team Memory compares 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.

8/6/2026

Earlier this week, the AI startup Liquid, formed in 2023 by former MIT computer scientists, debuted LFM2.5-2.6B, a new open-weight language model designed specifically for agentic workloads. In release materials and a recent interview with VentureBeat, Liquid's researchers said LFM2.5-2.6B can run entirely on local hardware — from smartphones and laptops down to a Raspberry Pi — without relying on cloud inference or GPUs, unlocking edge AI applications and giving more options to enterprises working in regulated industries or with sensitive information they don't want to send up to the cloud. It's best suited for high-volume, well-defined agentic tasks that run locally — tool calling, document management, calendar and workflow automation, and always-on background routines — and for connectivity-limited environments like vehicles and robotics, though coding-heavy work is better left to larger models. Even for those businesses without such concerns, the appeal of running performant, task-specific agents at the cost of essentially electricity, may be enough to make the new model quite appealing. But the custom open weights license, as with Moonshot's larger frontier model Kimi K3 released last month, is worth a close look by enterprise legal teams. The basics LFM2.5-2.6B contains 2.6 billion parameters, supports a 128,000-token context window, and includes native tool calling. The somewhat tricky name is explained by the generation of model (2.5) combined with the parameter count (2.6B). Both the post-trained model and a base checkpoint (LFM2.5-2.6B-Base) for developers who want to fine-tune it are available now on Hugging Face, with day-one support for major inference stacks including llama.cpp, MLX, vLLM, SGLang, and ONNX — positioning it for deployment across consumer hardware, enterprise infrastructure, and embedded systems. Liquid also offers an open source fine-tuning framework, LEAP. Rather than positioning LFM2.5-2.6B as a competitor to the largest frontier models, the company is making a different argument: that a sufficiently capable small model can unlock categories of enterprise applications where latency, privacy, deployment flexibility, or inference costs matter more than absolute benchmark leadership. "I do also believe that the best models will be in the cloud, and there's no problem with that," Maxime Labonne, Liquid AI's head of post-training, told VentureBeat in an interview following the launch. "We want to make models for another type of user, and the best way of describing it is: you should use [edge AI] when you can't use a cloud model." Small enough for a Raspberry Pi Asked about the minimum viable hardware, Labonne said the model runs "very, very well" on CPUs — and that the LFM2 architecture underlying the model was explicitly designed around real-world CPU performance rather than GPU benchmarks. "I think the best example is a Raspberry Pi," he said. "We have a lot of demos that show that actually, it works pretty fast on the Raspberry Pi." Company-reported measurements indicate decoding throughput of approximately 220 tokens per second on an Apple M5 Max and 113 tokens per second on an AMD Ryzen AI Max+ 395, while using less than 2.5 GB of memory — and around 30 tokens per second on a smartphone. Users can try the models on their phones through Apollo, Liquid AI's mobile app. At the other end of the deployment spectrum, Liquid AI reports the model reaches nearly 15,000 output tokens per second on a single Nvidia H100 GPU under sustained concurrent load — roughly 1.3 billion tokens per day on one card. These figures are vendor benchmarks and have not been independently verified. For Labonne, memory footprint and speed are not conveniences but hard constraints that determine what can be deployed at all. "What we want to show is that it's a really good trade-off, because you get the level of quality that you get with much bigger models, but in a tiny, tiny form factor," he said. "You can deploy it in target devices where you are not able to deploy the other ones at all." Trained for agents instead of chatbots Liquid AI says LFM2.5-2.6B was developed around the assumption that language models are increasingly consumed through agent frameworks rather than traditional conversational interfaces. "Models are not consumed in chatbots anymore. They're really consumed through agentic harnesses, like OpenClaw, like Hermes Agent," Labonne said. "We wanted to make sure that this model is not just good at math or at code, but it's good at using tools." The model is pretrained on approximately 34 trillion tokens, with a vocabulary doubled to 128K to better support non-Latin scripts and a dedicated mid-training phase to extend the context window to 128K tokens for long-running agent workflows. Post-training follows a four-stage pipeline: supervised fine-tuning, teacher specialization (training separate expert models for domains like instruction following, math, code, and tool use), multi-domain on-policy distillation (MOPD) to merge those experts' capabilities back into a single student model, and finally agentic reinforcement learning. During that last stage, the model was trained directly inside production agent harnesses — including Hermes Agent and OpenClaw — on realistic productivity tasks involving research, coding, document management, tool invocation, and workflow automation, exposing it to those harnesses' actual tools, system prompts, and interaction patterns. Labonne described the pipeline overhaul as producing a "happy accident": gains that extended well beyond the agentic targets. "Through these new training techniques, we also got a lot better at everything. We got better at math, at instruction following. We've never been good at code, actually — and with this, we even got really good at code," he said. Building the model — and the harness Notably, Liquid AI also built its own agent harness rather than relying solely on existing frameworks, and demonstrated the model running inside it on a phone, planning and calling tools entirely on-device. "This is a harness running on a phone, and I don't know if there's any other harness running on a phone," Labonne said. The company had two reasons, he explained. The first was necessity — no phone-native harness existed. The second is a different interaction model: today's harnesses wait for a prompt, and Liquid AI wants assistants that act on their own. "We want proactive agents. We want agents that run in the background, check what you're doing, check your calendar, and based on this context, do tasks," he said. "That doesn't exist today, really." Co-designing the harness and model also lets the software compensate for the model's weak spots. "Everything that the model is bad at, the harness should help the model with — provide as much assistance as possible to make it more reliable," Labonne said. "End users don't care if it's the model or the harness. What they want is that the task is achieved at the end of the day." The model nevertheless works out of the box with established harnesses including Hermes Agent, OpenClaw, and Pi, served behind any OpenAI-compatible endpoint. Swap the harness, not the model For enterprise deployment, Labonne argued the release marks a shift in what small models can be used for. Until now, he said, local models made economic sense mainly as narrowly fine-tuned specialists — trained to do one thing at cloud-model quality, much faster and cheaper. Agentic capability changes that calculus, because the same model can be repurposed by changing the tools around it rather than the model itself. "You can have a calendar assistant, and you can reuse the same model and make a meeting assistant that will record what everybody said and summarize it — a bit like Granola, for example," he said. "You don't change the model; you just change the harness. You just change the tools around it. This gives much more generalizability, and it's a lot easier to do and a lot cheaper as well." He still recommends fine-tuning for production deployments whenever feasible: "If you don't fine-tune it, you leave some quality on the table. If you fine-tune it well, it's going to match the performance of GPT and Claude — really, if your task is not the most complex task in the world," he said, adding that the barrier to entry has collapsed: "The bar to be able to do fine-tuning now is super low. It's very accessible to everyone." How it stacks up against DeepSeek-V4-Flash, Google's Gemma and Alibaba's Qwen Liquid AI released its own benchmark comparison charts pitting LFM2.5-2.6B against the models enterprises are most likely to shortlist for the same edge deployments: Google's Gemma 4 E2B (5.1B parameters) and E4B (8B), and Alibaba's Qwen3.5-4B (4.7B) and Qwen3.5-9B (9.7B). A separate test by local AI client platform Atomic Chat found that LFM2.5-2.6B completed 35 tool calls to complete three tasks (checking weather and local time in six cities, converting one budget into six currencies, checking four hotels and booking for a date) 3.7 times faster than DeepSeek-V4-Flash (a whopping 284B parameters), the model has skyrocketed to the top of OpenRouter since its release last week. Gemma 4's small models are multimodal generalists, accepting image and audio input alongside text, and use a Per-Layer Embeddings design that keeps only a fraction of their weights active per token — which is why Google markets them by "effective" size (2.3B and 4.5B) despite total footprints of 5.1B and 8B. Alibaba's Qwen3.5 small series, released in March, is natively multimodal from 4B up and leans on scaled reinforcement learning to chase frontier-style reasoning — Alibaba touts the 9B model as matching or beating OpenAI's far larger gpt-oss-120B on reasoning benchmarks. LFM2.5-2.6B takes a narrower path: it is text-only, dense, and specialized for agentic work, with Liquid AI shipping separate vision and audio variants of the LFM family rather than folding everything into one checkpoint. Where Qwen's post-training reinforcement learning targets reasoning, Liquid's targets tool use inside real agent harnesses. The result, per the company's published numbers, is that the smallest model in the comparison leads every instruction-following benchmark (IFBench, Multi-IF, IFStruct) and nearly every tool-use benchmark — 77.83 on ToolSandbox versus 76.44 for Qwen3.5-9B, a model nearly four times its size — trailing only that 9B model on BFCLv4. On agentic evaluations it beats both Gemma models across the board and essentially ties the Qwens: 26.89 on BrowseComp+ versus 27.23 for Qwen3.5-9B. It also posts the best score on AA Omniscience, a knowledge benchmark that penalizes hallucination. The Qwen models keep the edge where their training focus lies: math (Qwen3.5-9B leads AIME25) and coding, where larger models retain an advantage on LiveCodeBench — though Labonne noted the gap is smaller than the parameter counts would suggest. "With LiveCodeBench v6, we might not be the best among these models, but we're also by far the smallest. Showing that we're competitive with them is already quite a big win for me," he said. One differentiator cuts the other way: licensing. Gemma 4 and Qwen3.5 ship under the permissive Apache 2.0 license — a change Google made specifically to court enterprises. DeepSeek-V4-Flash ships under a similarly permissive MIT License. Meanwhile, Liquid AI's revenue-gated license (detailed below) asks larger companies to strike a commercial deal. Enterprises above the threshold are effectively trading license friction for footprint and tool-use performance. Licensing reflects a commercial middle ground LFM2.5-2.6B is distributed under the LFM Open License v1.0, which permits use, modification, and redistribution — including commercial use — for organizations with less than $10 million in annual revenue. Commercial use by larger companies is not covered by the license, requiring a separate arrangement with Liquid AI; qualified nonprofits are exempt from the threshold for non-commercial and research purposes. Labonne framed the structure as a way to sustain model development — "the models are really the moats, so we need to be sensible in the way that we license them; otherwise, we cannot make money, so we can't make more models" — while characterizing the threshold as a light-touch mechanism in practice. Asked how the company would even know if a large enterprise quietly deployed the open weights, he was candid: "I think this is a question for our legal team, but personally, I don't know. And even if you're above $10 million, the only thing that we ask you is to contact us." The company pairs its licensed model releases with freely published research, he added, including new structured-output evaluations and a training technique that mitigates the repetition loops common in small models — a failure mode he noted Qwen models are "kind of guilty of." Small model, big enterprise implications The launch coincided with an announcement from MacPaw, the Ukrainian software company behind CleanMyMac and Setapp, of a long-term strategic partnership with Liquid AI to build an on-device AI stack for the Mac. Liquid AI will design and fine-tune foundation models for Eney, MacPaw's macOS assistant, running locally on Apple silicon through MacPaw's Elix inference engine and Mnemos memory layer, with results expected later this year. Labonne pointed to the deal as a concrete validation of the size argument: "One of the reasons why they chose us is also because the model is quite small, and they don't have all the memory budget to run the other models." The release arrives as hardware vendors, operating system developers, and enterprise software companies increasingly invest in local AI execution — and as agent harnesses proliferate across the industry. Liquid AI's bet is that deployment economics, not raw scale, will define an important segment of that market: agents running continuously, everywhere, at zero marginal token cost. Whether small, highly optimized agent models become a significant segment of enterprise AI will ultimately depend less on benchmark scores than on operational reliability. But Liquid AI's latest release suggests the next competitive frontier is no longer simply building larger models — it's building models small enough, and capable enough, to run wherever enterprise workflows already live.

8/6/2026

Alibaba released Qwen 3.8-Max this week and marketed the preview as second only to Claude Fable 5 (their launch-day table was more equivocal: the model leads on one of 12 coding-agent rows). But an independent harness came close to the opposite conclusion: a benchmark run, apparently using the Preview version, put Qwen 3.8-Max's best effort setting mid-pack, and its default setting last. Both results are real and defensible. The gap between them is about token and time budgets, and that matters because those figures aren’t usually headline numbers. Alibaba's footnotes give its coding numbers a five-hour timeout, and up to 12 hours per run on PaperBench. The independent harness, VulcanBench, allowed between 45 and 60 minutes of wall clock time. A time budget between five and 16 times larger on Alibaba’s side explains the huge difference in results. It’s time to do two things to start accounting for these differences when choosing models. First, the metric to use is cost per successful task: total spend, including everything you spent on attempts that failed, divided by the tasks that actually passed your acceptance check. Second, you need to make time or token budgets an explicit part of your acceptance criteria, not a hidden detail. Price per token has stopped predicting the bill The comparison everyone published in Qwen 3.8-Max's first week was a price comparison, because that was the only data available. It is not a cheap model. DeepSeek-V4-Flash-0731, which entered public API beta on July 31, lists at 14 cents per million input tokens and 28 cents output. Qwen 3.8-Max lists at $2 and $6. Kimi K3 sits at $3 and $15. Those prices tell you less than they used to, for a reason specific to reasoning models like Qwen: getting to a result costs thinking tokens. A model that spends most of its token allowance on reasoning can reach a token cap before it writes the answer, giving you an empty result indistinguishable from a total failure at the cost of a full run. Artificial Analysis has the cleanest published measurement of how this can affect real agent spend: running its Intelligence Index on DeepSeek-V4-Flash at maximum effort took 210 million output tokens against a class median of 100 million. Absolute cost stayed low anyway, because the tokens were so cheap. But verbosity costs time, not just money, and depending on your use case that can sink you. What you need is a number that counts everything you spent, including the attempts that came back empty, against the tasks that actually got done in the time and token budget you specified. This is what a cost-per-success metric helps you see. Your failure rate is partly a configuration setting A run that produces a wrong answer and a run that runs out of budget are different events with different fixes. Almost no harness distinguishes them, and almost no leaderboard reports the split. I hit this building an agent benchmark of my own: the harness logged a failure and nothing about why, and I had to add the distinction myself. When you do separate them, budget exhaustion turns out to dominate. Long-Horizon-Terminal-Bench, published in July, ran 17 frontier models across 46 tasks through a shared harness with one 90-minute attempt each. Timeouts accounted for 79% of unresolved runs, against 19% for agents that stopped on their own and 3% for harness errors. The authors are careful about what that does and does not mean: the timed-out runs were not close to finishing, with mean reward between 0.10 and 0.35, so you cannot assume more time would have resulted in success. But the lesson is: benchmarks are implicitly measuring time efficiency, whether or not they shout about that. The clearest published example of the mechanism comes from VulcanBench, the same open-source harness behind the Qwen chart. In a report dated July 26, Claude Opus 5's lowest-effort setting was its best, solving 20 of 23 tasks against 18 at high effort. The extra reasoning wasn’t useless: high effort returned the fewest wrong answers of any setting, one against three. It ran out of clock instead, and a timeout scores zero. Two of its three regressions were cutoffs on tasks that low effort solves, and given unlimited time on both it only ties its cheapest setting, at 3.1 times the cost. That has a direct consequence for anyone building a routing ladder. The standard design escalates to more reasoning when a cheap attempt fails, on the assumption that the next rung is better and merely costs more. For a meaningful share of model and task combinations that assumption is wrong, and you pay the higher rung's price to escalate into a timeout or hitting a cap. Who is already measuring this Several groups have landed on cost per successful task independently in the last few months, which is the strongest signal it's becoming standard. VulcanBench reports dollars per solved task as a headline column and has since its earliest reports. Long-Horizon-Terminal-Bench publishes per-task cost next to accuracy, and its most instructive row is GPT-5.4 at roughly $26 per task with a much lower pass rate than Grok 4.5 at about $11. TestEvo-Bench runs agents under a cost cap, and Claude Code's test-generation score falls from 71% to 44% at the tighter cap. Vendors are already on board with the idea of measuring per successful task. HubSpot moved its Breeze Customer Agent in April to 50 cents per resolved conversation, down from $1 per handled conversation. Zendesk bills per automated resolution. Fin charges 99 cents per outcome and bills only on end-to-end resolution. What to change this week Emit a failure reason on every agent run as a required field, with budget exhaustion, verifier failure and harness error as distinct values rather than one failure flag. Until you can separate a timeout from a wrong answer, your pass rate is measuring two things at once and you cannot tell which one to fix. Compute cost per successful task per effort level, not just per model. Total spend including failed attempts, divided by tasks that passed your acceptance check. The ranking will not match the rate card, and the cheapest setting may well win. Cap on tokens rather than wall clock unless latency is genuinely in your service level objective. A wall-clock cap scores your provider's serving speed as model quality. Check the default effort setting on everything you have deployed. Qwen 3.8-Max runs at its highest reasoning setting when the effort field is unset, and its highest setting was its worst performer in independent testing. A team that never touches that parameter is running the configuration that costs the most per solved task.

8/6/2026

Presented by JumpCloud A practical framework for securing every identity in the modern workforce, human or not. Your organization already has a rigorous process for governing human identities. New employees go through onboarding. They get a role, a set of entitlements, and a named manager accountable for their access. When they leave, their credentials are revoked and access is terminated. It’s a well known IT process: every workforce identity that can access your systems needs to be known, scoped, and accountable from the moment they enter your world, to the moment they are off-boarded. AI agents are now operating inside those same systems. They access Salesforce, create tickets in Jira, provision infrastructure, process financial transactions, and communicate on behalf of your teams. In every meaningful sense they are members of your workforce, except that in most organizations they were never onboarded, have no named owner, and have no offboarding process when their purpose expires. JumpCloud’s Q3 2026 research found that non-human identities now outnumber human users in 83% of organizations, and only 21% have implemented governance controls specifically for them. The framework below is designed to close that gap. Stage 1: Discover every agent operating in your environment Governance starts with an accurate inventory, and most organizations are working with an incomplete one. AI agents are being deployed by product teams, operations leaders, and individual contributors who have both the tools and the motivation to move fast. IT inherits the governance responsibility after the fact, often without knowing the full scope of what has been deployed. Shadow AI is the practical consequence: agents operating across production environments with no formal record, no defined owner, and no systematic way to stop them if something goes wrong. Discovering your agent population is an ongoing practice, not a one-time audit. Build an inventory across every environment where agents could be running: cloud platforms, managed devices, SaaS integrations, and on-premise systems. For each agent, document what it can access, what workflows it influences, and what triggers its actions. That inventory is the foundation everything else in this framework depends on. Stage 2: Register every agent as a formal identity with a named owner Every agent that operates in your environment should exist as a formal identity in your directory, with the same basic attributes you assign to any employee: a defined purpose, a scope of authorized action, and a named human owner who is accountable for its behavior. This is the architectural decision that separates organizations that can govern their agents from those that cannot. Agents registered as proper identities can be assigned entitlements, subjected to conditional access policies, and included in access reviews. Agents that exist only as service account workarounds or API keys in environment variables are ungovernable by any systematic means. Registration is also the mechanism for addressing Zombie Agents: agents that outlived their original purpose but kept running, kept accessing systems, and kept accumulating permissions. When every agent has a named owner responsible for its renewal, agents without active ownership naturally lose their access when that ownership lapses. The offboarding happens as a consequence of process rather than as a reactive cleanup after something breaks. Stage 3: Manage agent access with least privilege and zero standing credentials Registered agents need access to do their jobs. The governing principle for that access is least privilege: each agent should have entitlements scoped precisely to what its defined purpose requires, with access that is time-bounded wherever possible and revocable immediately if the agent’s behavior changes. Standing credentials in environment variables are a persistent liability. Static API keys that never rotate are a persistent liability. In practice, managing agent access securely means issuing just-in-time credentials for privileged operations, building approval workflows that require human sign-off before agents reach sensitive systems, and maintaining emergency shutdown mechanisms that work at the speed the situation requires. For agents that need access to privileged web applications, SSH servers, or databases, credential shielding is an additional requirement: the agent should be able to complete its task without the underlying credentials ever being exposed to the model running it. Every privileged session should be recorded and available for audit. Stage 4: Govern agent behavior continuously, not just at deployment The first three stages establish the controls. Governance is what keeps them current. It is the ongoing practice of verifying that what agents are actually doing matches what they are authorized to do, and course-correcting when those diverge. Every agent action should be logged. Access reviews should happen on a regular cadence, evaluating whether each agent’s entitlements remain appropriate for its current purpose. When an agent’s behavior deviates from its defined scope, the anomaly should be detectable before it becomes an incident. When an agent’s purpose ends, access revocation should be a procedural step, not a reactive measure triggered by something going wrong. Governance also means maintaining the audit trail needed to answer accountability questions: what did this agent access, what actions did it take, who authorized it, and what was the outcome? Organizations that cannot reconstruct that chain for any given agent are not governing their agents in any meaningful sense. They have deployed them and hoped for the best. The foundation underneath all four stages Each stage of this framework becomes significantly harder to execute when the underlying IT environment is fragmented. Identity, access, device management, and security controls spread across disconnected systems create the gaps where agent governance falls through, and organizations end up applying different policies in different places rather than consistent governance everywhere. JumpCloud’s research found that organizations operating in fully unified IT environments are five times more likely to deploy agents in business-critical workflows than those running fragmented stacks. Whether the control layer is coherent enough to apply consistent policies across humans, devices, and agents simultaneously is what determines whether governance scales with AI adoption or lags behind it. This is the core premise of Agentic IAM: that governing humans, devices, and agents through a single coherent control layer is what makes the framework above executable at scale rather than aspirational. Securing every identity, human or not, is the operational foundation that makes AI safe to scale. Organizations that build it now will not just reduce risk. They will expand AI into more workflows, move faster, and do it with the confidence that comes from knowing every identity in their environment is known, governed, and accountable. JumpCloud’s Q3 2026 IT Trends Research report (n=800 IT leaders, US + UK) is available here. The Agentic IAM lifecycle framework referenced in this article was developed by JumpCloud and is available here. Greg Keller is CTO and Co-founder at JumpCloud. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/6/2026

Presented by CloudMosa Enterprise work now happens increasingly inside the browser, and that shift has made the browser a primary point of entry for cyberattacks as well. Browser-based attacks have surged over the past two years, according to industry reports, while Gartner projects that more than 85% of enterprise workloads will be accessed through the browser by 2027. And yet most enterprise security architecture is still built to protect the device rather than the browser session where that work, and those attacks, actually take place, says Shioupyn Shen, founder and CEO of CloudMosa, the company behind Puffin Cloud Security. “CloudMosa originally built its cloud architecture to improve browser performance and accessibility, with the expectation that enterprise work would increasingly move into the browser,” Shen says. “Today’s AI-assisted hacking has validated that architecture, demonstrating that what was designed for performance also provides a strong foundation for modern enterprise security.” The browser as the enterprise's operating environment SaaS platforms, CRM and ERP systems, and collaboration tools have made the browser the primary gateway, and often the central workspace, for enterprise operations. As LLM-powered workflows and autonomous AI agents increasingly operate through that same environment, this shift has also redefined what a threat looks like. In a device-centric world, security teams could focus much of their attention on endpoints and networks they could monitor, manage and patch on schedule. But because web code now executes locally on the user’s device, every open browser tab can become a potential entry point for malicious scripts, credential theft, supply chain compromise and other browser-based exploits. The browser now interprets and executes remote code, manages authenticated sessions across enterprise applications, and increasingly serves as the execution layer for AI workflows and agents. "The browser is no longer just another application running on the endpoint," Shen says. "In practice, it has become the central operating environment for modern enterprise work. Traditional browsers were never designed to carry this level of enterprise responsibility. They were built as local interpreters of remote code, not as enterprise-grade execution environments with strong isolation and policy enforcement." Why detection-first security fails against browser-based attacks Detection-first security has a timing problem: it typically begins only after risky code has reached the device and started executing inside the browser. Because modern browsers execute dynamic, often obfuscated JavaScript and WebAssembly locally, attacks can act on the device before endpoint tools have time to respond. Short-lived or fileless attacks may steal credentials, exfiltrate data or complete their objective before a security team can intervene. "It is no longer sufficient to ask only whether a threat can be detected," Shen says. "The stronger approach is to prevent risky or malicious code from ever reaching the device in the first place." AI-generated malware strains signature-based detection AI is a force multiplier that lets attackers automate the creation, mutation and deployment of malware at a scale signature-based tools were never designed to handle. It can generate large volumes of malware variants and help attackers adapt fileless and browser-delivered techniques faster than defenders can analyze them and update signatures. That matters because polymorphic malware can alter its code or behavior from one instance to the next, making a known signature less reliable. And when attacks are malware-free — relying instead on legitimate tools, compromised sessions or malicious web content — there may be no conventional file signature to detect at all. Enterprises have seen an 89% increase in attacks by AI-enabled adversaries over the past year, as increasingly automated and adaptive attacks compress the window available for detection and response. "Defenders are no longer just chasing more threats, they are chasing a machine that can keep creating new ones," Shen says. "What was good enough in the past 10 years will not be sufficient in the next six months," he adds. Building architecture that removes the attack surface Rather than continuing to refine detection, the more durable response is to change where web code is allowed to execute in the first place. "In a conventional browser, the risk comes to the device," Shen says. "In an isolated cloud model, the risk is kept away from it." That principle underlies Puffin Cloud Security. Rather than incrementally improving the browser itself, the platform shifts browser execution into isolated cloud environments. That architectural change improves both performance and security. The platform runs the original web session, including its JavaScript, WebAssembly, and other executable payloads, inside a disposable cloud environment and streams only a rendered pixel view to the device. Users keep full interactive control over clicking, typing, and scrolling, but the device itself never parses, executes, or stores the original active code. CloudMosa says display rasterization — the layer responsible for the pixel stream — accounts for roughly 5% of the browser’s total workload, while the more compute-intensive HTML rendering remains isolated in the cloud. As a result, zero-day exploits and AI-generated polymorphic malware have no executable code to run on the endpoint, while fileless attacks or supply chain compromises within SaaS tools remain contained in the cloud. "In CloudMosa's view, that means moving from good-enough security on the device to airtight security in the cloud," Shen says. Fitting browser isolation into SWG, CASB and ZTNA stacks Puffin is designed to extend existing security infrastructure rather than replace it. Secure web gateways, cloud access security broker platforms, and zero trust network access tools remain effective at routing traffic, enforcing policy, and controlling access. But none can fully stop local execution once risky content reaches the browser. Puffin closes that gap by routing high-risk sessions through isolated cloud environments and enforcing browser-level policy, whether a user connects over a VPN, a home network, a managed device or an unmanaged, bring-your-own-device setup. "Organizations can start with narrow use cases, such as high-risk SaaS access or AI agent workflows, and expand without disrupting tools already in place," Shen says. "The goal is not to undo existing investments, but to make them more complete." The choice between faster detection or endpoint isolation Detection will always have a role in enterprise security, but the more consequential question is no longer how quickly a threat can be caught, but whether attackers can reach the endpoint at all. Recent 2026 surveys found 92% of security professionals are concerned about the impact of AI agents, with 48% naming agentic AI the top attack vector of the year. Shen noted that agents acting autonomously with user-level privileges are especially exposed to prompt injection, session hijacking, and indirect compromise through compromised web content. In designing Puffin Cloud Security, CloudMosa has been “paranoid by design,” meaning it invested in an architecture built for worst-case scenarios and for a threat environment where endpoint security and detection alone may not be enough. "This is not just a philosophy, but something that is reflected directly in the architecture itself," Shen says. "CloudMosa built earlier for a harsher threat model than most other organizations did, but today's AI-assisted attacks are now making that posture feel increasingly relevant." By dividing a full browser into a very small layer on the device and a much larger layer in the cloud, CloudMosa designed this approach to improve both performance and security at the same time: In Puffin Cloud Security’s architecture, an AI agent’s browser activity takes place inside isolated cloud sandboxes. The endpoint receives only a pixel stream, not the original active code, preventing malicious web content from interacting directly with the device, its credentials or connected systems. "AI-assisted hacking represents the kind of structural shift that rewards companies willing to rethink browser from the ground up," Shen says. "And so security leaders now have a choice: redesign for foresight, or wait until hindsight makes the lesson unavoidable." Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/5/2026

Meta today released Muse Code, a terminal-based AI coding agent now in beta, alongside Muse Spark 1.2, a coding-focused update to its Muse Spark family of frontier models — a one-two punch that puts the company in direct competition with Anthropic's Claude Code, OpenAI's Codex, and the growing field of agentic coding harnesses that have rapidly become the primary way many professional developers ship software. "Releasing Muse Code in beta today," Meta co-founder and CEO Mark Zuckerberg wrote in a post on rival social network X (under his longtime handle @finkd). "It's a terminal coding agent that takes on complete software engineering tasks across large repos: planning changes, writing code, validating the results." The launch marks Meta's most serious entry yet into a category it has largely watched from the sidelines. While Anthropic and OpenAI turned their coding agents into flagship products — and startups like Cursor built billion-dollar businesses on the workflow — Meta's developer story long centered on Llama, the open-weight model family it gave away to the tune of more than a billion downloads. Muse Code changes that in more ways than one: it's a full harness, installable on macOS or Linux with a single curl command, co-trained with the model that powers it — and, like the Muse Spark models behind it, entirely proprietary. However, Zuckerberg teased that open source may be in the cards for Muse Spark or perhaps another product entirely, in a reply to a question on X, saying "I'll have more to share on that soon." Developers and prospective users can install it now on their Terminal using the following one-line command — but be warned, if that's you, you'll need to log in with a Meta account and provide billing details first in order to begin: curl -fsSL https://dev.meta.ai/install.sh | bash Persistent background agents and parallel worktrees Muse Code's headline architectural bet is what Meta calls async background agents. Rather than spawning helper agents fresh for each task — the pattern most rival harnesses use — Muse Code keeps a set of specialized background agents alive for the entire session. According to Meta's blog post, these agents "remain active throughout each session, rather than being spawned for individual tasks, helping avoid redundant information gathering," carrying out next steps on their own and choosing when to report back to the main agent. The practical pitch is less latency and less babysitting: an agent that already knows the repository doesn't have to re-explore it every time the developer asks for something new. When a job is large enough, Muse Code fans out to separate sub-agents working in parallel, each in its own isolated git worktree, so the developer's working copy is never touched. "In testing we had it build six features for a game simultaneously with no collisions," Zuckerberg wrote on X. Worktree isolation and parallel sub-agents exist in competing tools, but Meta is leaning on the combination of persistence plus parallelism as its differentiator. The second notable design choice is auditability. Every model call, tool run, approval, and edit is appended to a local event log before it executes — a single source of truth that Meta says makes the runtime "replay-exact and restart-safe." If Muse Code crashes 20 hours into a long-running task, it resumes precisely where it stopped, with no lost work and no re-prompting. For engineering leaders who have been burned by opaque agent runs, a complete local audit trail may prove to be the feature that matters most in enterprise evaluations. Muse Code also ships with bundled "skills" that will look familiar to users of rival tools: /plan turns a task into an approval-gated plan, /grill stress-tests that plan until it holds up, and /goal drives the agent toward completion of a stated objective. Muse Spark 1.2: co-trained with its own harness Under the hood is Muse Spark 1.2, which Meta describes as a coding-focused update to Muse Spark 1.1 with "significantly scaled up training compute on coding tasks" and broader training environment diversity, improving code generation, complex debugging, and codebase understanding while maintaining general agentic capability. The update lands squarely on the Muse family's weakest flank. When the original Muse Spark debuted in April, it vaulted Meta back into the top five on frontier reasoning and vision benchmarks — but trailed on the agentic coding evaluations that matter most to this market, scoring 77.4 on SWE-Bench Verified against Claude Opus 4.6's 80.8 and Gemini 3.1 Pro's 80.6, and lagging well behind GPT-5.4 on GDPval's measure of long-horizon work tasks. Four months later, a coding-specialized checkpoint paired with a purpose-built harness reads as Meta's direct answer to that gap. Two training details stand out. First, Meta co-trained the model with Muse Code itself, using rejection-sampled harness trajectories and recipe optimizations for goals, context compaction, and sub-agents — meaning the model was explicitly tuned to perform best inside this particular tool. That mirrors an industry-wide shift away from treating models and harnesses as separable products. Second, Meta used a self-improvement loop: Muse Spark 1.1 generated challenging coding environments and instruction-following templates, then graded candidate solutions against those requirements, producing a scalable training dataset for its successor. Meta credits the loop with making 1.2 measurably better at following complex instructions. Meta published benchmark charts comparing Muse Spark 1.2 against other coding models on Terminal-Bench 2.1, DeepSWE 1.1, and an internal Meta coding benchmark, pointing readers to a separate methodology report for details — though the announcement text itself doesn't tout any placements, an unusual reticence in a field where rivals trumpet leaderboard wins. The charts explain why: they show a strong but clear second place. On Terminal-Bench 2.1, Muse Spark 1.2 running in Muse Code scored 82.9%, edging OpenAI's GPT-5.6 Terra in Codex (81.8%) and xAI's Grok 4.5 in Grok Build (81.6%) but trailing Anthropic's Opus 5 at max effort in Claude Code, which leads at 86.7%. On DeepSWE 1.1, Muse Spark 1.2 posted 59.3% — third, behind Opus 5 (65.0%) and GPT-5.6 Terra (64.8%). Most striking is Meta's own internal coding benchmark, where Muse Spark 1.2's 70.6% comfortably beats GPT-5.6 Terra (65.4%) and Gemini 3.6 Flash (63.9%) yet still sits nearly nine points behind Opus 5's 79.4% — an unusually candid admission that even on the test Meta designed itself, Anthropic's model wins. Indeed, Claude tops all three charts. The generational gains are real, though: Muse Spark 1.2 improves on 1.1 by 6.7 points on Terminal-Bench and 6.3 on DeepSWE. One caveat buried in the chart labels — the 1.1 scores were recorded in the generic mini-swe-agent harness while 1.2 ran in Muse Code, so some of that jump belongs to the new harness rather than the new model. The company's most striking demonstration is a long-horizon case study: Meta pointed Muse Spark 1.2 at GPU kernel optimization and let it run for more than 1,000 tool calls over up to 24 hours on NVIDIA Hopper hardware. Working in Triton and barred from simply wrapping existing third-party kernel libraries, the agent wrote, compiled, and profiled its way to what Meta calls "substantial improvements" over baseline implementations of KDA and MLA kernels — including genuinely non-obvious optimizations like re-centering gated cumulative decay at a chunk midpoint. "It kept finding substantial improvements well beyond the initial exploration phase," Zuckerberg wrote. Sustained improvement over a 24-hour autonomous run, if it holds up outside Meta's demos, addresses one of the most persistent criticisms of coding agents: that they plateau or drift once past their initial burst of progress. Your data for a discount? The pricing structure may be the most consequential — and most scrutinized — part of the launch. Meta is offering Muse Spark 1.2 through its Meta Model API in two tiers. The standard tier is priced at $1.25 per million input tokens and $4.25 per million output tokens (with cached input at $0.15), and Meta commits that prompts and completions on this tier are not used to train its models. There is no long-context premium, and rate limits run to 3,000 requests and 4 million tokens per minute, per team. It's about mid-range price, compared to other leading AI models available over API. The contributor tier is where Meta's strategy diverges sharply from its rivals: $0.10 per million input tokens and $0.20 per million output tokens — roughly 12x and 21x cheaper than standard, respectively, with cached input at a near-free $0.002 — in exchange for explicit permission to use your prompts and completions to train future Meta models. It's the cheapest available on the market, but you pay with your data — as described below. Model Input ($/1M) Output ($/1M) Total ($/1M) Source Muse Spark 1.2 Contributor $0.10 $0.20 $0.30 Meta MiMo-V2.5 Flash $0.10 $0.30 $0.40 Xiaomi deepseek-v4-flash $0.14 $0.28 $0.42 DeepSeek deepseek-v4-pro $0.435 $0.87 $1.305 DeepSeek GPT-5.6 Luna $0.20 $1.20 $1.40 OpenAI MiniMax-M3 $0.30 $1.20 $1.50 MiniMax LongCat-2.0 — limited-time promo $0.30 $1.20 $1.50 LongCat Gemini 3.1 Flash-Lite $0.25 $1.50 $1.75 Google MiMo-V2.5 $0.40 $2.00 $2.40 Xiaomi Gemini 3.5 Flash-Lite $0.30 $2.50 $2.80 Google LongCat-2.0 — standard $0.75 $2.95 $3.70 LongCat MiMo-V2.5 Pro (≤256K) $1.00 $3.00 $4.00 Xiaomi Muse Spark 1.1 / 1.2 $1.25 $4.25 $5.50 Meta GLM-5.2 $1.40 $4.40 $5.80 Z.ai Grok 4.5 $2.00 $6.00 $8.00 xAI MiMo-V2.5 Pro (>256K) $2.00 $6.00 $8.00 Xiaomi Qwen3.8-Max $2.00 $6.00 $8.00 QwenCloud Gemini 3.6 Flash $1.50 $7.50 $9.00 Google Gemini 3.5 Flash $1.50 $9.00 $10.50 Google Gemini 3.1 Pro Preview (≤200K) $2.00 $12.00 $14.00 Google GPT-5.6 Terra $2.00 $12.00 $14.00 OpenAI GPT-5.4 $2.50 $15.00 $17.50 OpenAI Kimi K3 $3.00 $15.00 $18.00 Moonshot AI Gemini 3.1 Pro Preview (>200K) $4.00 $18.00 $22.00 Google Claude Opus 5 $5.00 $25.00 $30.00 Anthropic GPT-5.5 $5.00 $30.00 $35.00 OpenAI GPT-5.5 Instant (chat-latest) $5.00 $30.00 $35.00 OpenAI Sakana Fugu Ultra (≤272K) $5.00 $30.00 $35.00 Sakana AI GPT-5.6 Sol — Standard mode $5.00 $30.00 $35.00 OpenAI Claude Fable 5 / Claude Mythos 5 $10.00 $50.00 $60.00 Anthropic GPT-5.6 Sol — Fast mode $10.00 $60.00 $70.00 OpenAI This is the tier Zuckerberg is steering new users toward: "It's easy and low-cost to get started," he wrote. "Install Muse Code with one line and you can start on our contributor tier." In VentureBeat's own testing on a Mac mini, the one-line installer worked as advertised — a 97 MB download and a sign-in — but the agent stopped short of running anything, reporting that no models were visible and that payment was "required to finish setting up your account." In other words, even the heavily discounted contributor tier requires a payment method on file before Muse Code will do any work: low-cost is accurate, but free is not. Meta frames the contributor tier as lowering the barrier for prototyping and experimentation "where training on your data is acceptable." But it also means the default on-ramp for Muse Code sends developers' code and prompts into Meta's training pipeline — a tradeoff enterprises with proprietary codebases will need to consciously opt out of by moving to standard pricing. The contributor tier also carries much tighter rate limits (60 requests per minute versus 3,000), a clear signal it's aimed at individuals and small experiments rather than production workloads. The approach is classically Meta: subsidize access, harvest data at scale, and use it to close the gap with the frontier. Zuckerberg made no secret of the ambition, calling Muse Spark 1.2 "our next step as we push toward frontier, with larger, more capable models on the way." However, for developers and enterprises who want or are required legally to keep their code secure, the tradeoff may not be one they're willing or able to make. No Llama in sight What today's announcement conspicuously lacks is any mention of open source — a striking omission from the company that spent three years positioning itself as the standard-bearer of open AI. From the original LLaMA's debut in February 2023 — whose weights famously leaked onto 4chan within weeks, inadvertently kickstarting the movement to run capable models on consumer hardware — through Llama 2's commercially usable license, the coding-specialized Code Llama, and the 405-billion-parameter Llama 3.1, which Zuckerberg launched in July 2024 with a manifesto titled "Open Source AI Is the Path Forward," Meta's entire pitch to developers was that frontier-class weights should be free to download, self-host, and fine-tune. The strategy worked: by early 2026, the Llama family had been downloaded roughly 1.2 billion times, averaging about a million downloads a day, with self-hosting offering enterprises cost reductions VentureBeat has previously reported at as much as 88% versus proprietary API providers. Then came the unraveling. Llama 4 debuted in April 2025 to mixed reviews and, eventually, admissions that its benchmark results had been fudged — while Chinese open-weight rivals from DeepSeek, Alibaba, and Zhipu AI surged to account for some 41% of downloads on Hugging Face by late 2025, eroding Llama's claim to leadership of the very movement it started. The rocky rollout spurred Zuckerberg's summer 2025 overhaul of Meta's AI operations into Meta Superintelligence Labs (MSL), with Scale AI co-founder Alexandr Wang recruited as chief AI officer. The Llama era effectively ended this past April 8, when MSL shipped the original Muse Spark — "the most powerful model that meta has released," in Wang's words — as Meta's first proprietary model: cloud-only, with no downloadable weights and no self-hosting, initially confined to Meta's apps and a private API preview. Asked directly at the time whether Llama development would continue, a Meta spokesperson told VentureBeat only that "our current Llama models will continue to be available as open source" — pointedly silent on future ones. Wang, for his part, said bigger models were already in development "with plans to open-source future versions" — but four months on, today's release does nothing to advance that promise: no weights, no license, and neither the blog post nor Zuckerberg's thread so much as uses the word "open." The reversal is all the sharper because Meta's rivals have been moving in the opposite direction. OpenAI released its Codex CLI as open source under the permissive, enterprise-friendly Apache 2.0 license and followed with its gpt-oss open-weight models; Google's Gemini CLI harness is likewise Apache-licensed. With Muse Code, Meta lands closest to the posture of Anthropic — whose Claude Code remains proprietary — while the company that once argued open source was the path forward now asks developers to pay per token for a model they cannot inspect, or to subsidize that access with their own data. Seen in that light, the contributor tier reads as the successor to the Llama strategy itself: the ecosystem flywheel is no longer free weights in exchange for mindshare, but cheap tokens in exchange for training data. But Zuck's reply on X — asked directly by AI developer Luckey Farady, "Will Muse Code be open source?" he responded "I'll have more to share on that soon" — does keep hope alive that Meta will return to the open source AI ballgame. Why it matters Terminal coding agents have become the fastest-growing surface in enterprise AI, and until today the category has effectively been a two-horse race between Anthropic and OpenAI, with Google and a crowd of startups in pursuit. Meta's entry brings a genuinely different architecture (persistent background agents, an append-only local event log), a credible long-horizon demo, and an aggressive pricing wedge. The open questions are the ones benchmarks charts can't answer: whether Muse Spark 1.2 actually matches Claude and GPT-class models on real-world repositories, whether developers trust Meta with their code, and whether the contributor tier's discount is enough to make them stop asking. Muse Code is available in beta today; Muse Spark 1.2 is live in the Meta Model API with expanded global access.

8/5/2026

The UK AI Security Institute (AISI) disclosed last night that the leading two frontier AI models from Anthropic and OpenAI took 19 unsanctioned actions against the live internet during cybersecurity tests the agency was running, including a sustained campaign by Anthropic's Claude Mythos 5 against two working open-source software developers who had no connection to the experiment. Unable to solve a challenge inside its sandbox, Mythos 5 searched the open web for a target, profiled the two developers using open-source intelligence (OSINT), routed its traffic through Tor and then a commercial proxy service to get past GitHub's signup defenses, and submitted malicious code to a public repository. It then registered multiple fake "sock puppet" GitHub accounts and used them to comment approvingly on its own pull request, manufacturing the appearance of consensus to pressure the human maintainer into merging it. It opened a GitHub Issue seeded with hidden prompt-injection instructions aimed at hijacking other developers' AI coding assistants, and sent the two developers five file transfers through a legitimate transfer service — two carrying malware, three of them pure social engineering aimed at getting the code merged. Of the 19 actions AISI catalogued, 17 came from Mythos 5. The other two came from OpenAI's GPT-5.6 Sol. Both models created fraudulent accounts, but only Mythos 5 created personas — fake people invented to persuade a real one — and only Mythos 5 appears in AISI's catalogue of social engineering against human targets. AISI's full technical report is available here freely as a PDF. The agent's own attempt at anonymity is what exposed it. AISI's security monitoring flagged data leaving its network over Tor on the morning of July 28, and that alert set off the entire incident response. By then the run had already finished. It executed for 34 and a half hours — from midday on July 26 until late on July 27 — and completed before anyone at the agency noticed. Both companies confirmed the findings and both emphasized that the models had been tested with their safety classifiers switched off and internet access deliberately enabled — conditions that bear no resemblance to how either company's commercial products are deployed. AISI worked with GitHub to delete the fake accounts, scrub the artifacts, and notify the two developers. The latest in a recent string of high-profile AI cyberattacks It is the third time in recent months that a leading AI lab has had to account for models acting against systems or individuals outside the boundaries of the test, without their knowledge or consent. The AISI findings differ from these prior examples in important ways, though: The earlier incidents described by OpenAI and Anthropic in July were machine-to-machine intrusions — models that reached live infrastructure and exploited it. AISI's finding appears to be the first public documentation of a frontier model fabricating human identities and running deception operations against named people. One distinction is worth drawing clearly. The AISI findings came out of a deliberate experiment, not a containment failure. Internet access was switched on and the models' cyber classifiers were switched off because AISI wanted to measure what the models could do at full capability. Both conditions were chosen in advance rather than discovered afterward, and nothing broke. That is the inverse of what happened in July, when OpenAI's models exploited a zero-day to get out of an environment built to hold them, and Anthropic's models were handed the open internet by a misconfiguration that neither the company nor its evaluation partner knew was there. What the experiment did not control was where the models went once they were outside. Two uninvolved developers received malware by email, a real repository received malicious code, and fake accounts were registered on a live platform in violation of its terms of service. None of that was sanctioned by AISI, and all of it had to be cleaned up afterward with GitHub's help. The environment was deliberate, but the blast radius was larger than expected. How much larger is clearer in the technical report than in the summary AISI published alongside it. In a separate run, the agent generated 145 plausible-looking repositories under one account, pushed malicious Python package metadata into them, and caused a setup script to execute inside at least 53 of GitHub's own Dependabot containers. AISI is careful to note there was no escape from those containers and no compromise of GitHub's underlying infrastructure, and that GitHub's bug bounty explicitly treats this class of execution as ineligible because dependency update jobs are designed to run arbitrary code. GitHub suspended the account regardless. The agent then filed a reinstatement appeal posing as a human, monitored for a response, and prepared automation to re-upload its payloads if the account came back. It tried to move to PyPI next, and failed that platform's CAPTCHA. How AISI's experiment was structured AISI conducted 122 evaluation runs across seven models, comparing performance across existing and new cyber ranges. Anthropic's Mythos 5 was featured in 43 runs, while OpenAI's GPT-5.6 Sol was featured in 35 runs. To measure maximum underlying capabilities, AISI intentionally configured the evaluation environment with two permissive conditions: Live Internet Access: Enabled so agents could download necessary cybersecurity tools Disabled Cyber Classifiers: Built-in model provider safety filters and misuse detectors were switched off. Out of 122 runs, AISI catalogued 19 unsanctioned actions across 10 distinct runs. Those two conditions are the ones AISI led with publicly, but its technical report lists five contributing factors. The other three are the ones enterprises can act on. There was no synchronous monitoring — no second model reviewing each proposed action before it executed — which AISI concedes could have flagged or blocked the behaviour as it happened. Some runs carried a misconfigured prompt that declared the intended solution path out of scope, leaving the agent a task it could not complete within its stated constraints; both of the worst runs had this flaw, though AISI cautions it cannot confirm the misconfiguration caused the escalation, since seven of the ten misconfigured runs went after the out-of-scope target anyway and several correctly configured runs also went off the rails. And the prompts never told the agent what it was forbidden to do online. AISI's explanation for that last omission is the most striking admission in the report: it did not think such instructions were necessary, because these were not helpful-only models but ones trained against a published constitution or model specification. Indeed, Anthropic's Claude Constitution states that Claude “should basically never directly lie or actively deceive anyone it's interacting with.” OpenAI's Model Spec says the assistant “must never lie or covertly pursue goals.” Both models did precisely that. Of these, 17 originated from Mythos 5 and two from GPT-5.6 Sol, meaning no unsanctioned actions were attributed to any of the other five models in the evaluation. The concentration is striking on its own terms: Mythos 5 produced 17 across 43 runs, while GPT-5.6 Sol produced two across a comparable 35. The evaluation prompts placed no restrictions on how the internet could be used, and the challenge setup led Mythos 5 to conclude that no solution existed inside its sandbox. It searched the open web for keywords matching the challenge theme and settled on two developers completely unaffiliated with AISI. Its full sequence of unsanctioned actions, as catalogued by AISI: OSINT & Reconnaissance: Mythos 5 investigated public GitHub metadata, confirmed active email addresses, and mapped developer activity hours. Network Evasion: To bypass GitHub's bot restrictions and CAPTCHAs, the model routed traffic through Tor and alternative SOCKS proxies. Supply-Chain Compromise:It submitted a malicious pull request (PR) containing harmful code to a public open-source repository. Social Engineering & Sockpuppets: Mythos 5 registered multiple fake GitHub accounts to post comments on its own PR, manufacturing artificial consensus to pressure the maintainer into merging the code. Prompt Injection: It opened a GitHub Issue containing hidden prompt-injection instructions designed to manipulate other developers' automated AI coding assistants. Direct Phishing: The agent sent five emails directly to the developers containing malware payloads and social engineering pretexts. AISI catalogued GPT-5.6 Sol's two unsanctioned actions in a single run. The agent recovered a GitHub access token that a Mythos 5 agent had deliberately published to a public Gist during a separate run of the same evaluation, and used it to authenticate to that account. It then exposed a malicious DNS server to the public internet through a tunneling service, loaded with payloads meant to exploit a known vulnerability in the range's DNS software. That second attempt could never have worked: the agent published the server on a high-numbered port, and because DNS delegation cannot specify a port, no resolver would ever have queried it. To register the accounts this required, GPT-5.6 Sol solved sign-up CAPTCHAs four times, defeating them with audio-sample matching against public data and with computer-vision models against image challenges. Neither behavior involved escaping a sandbox. Both models were handed the open internet by design. Did Mythos 5 know the people it was socially engineering were real? AISI cannot say, and it is candid about that. The agency's summary states it “cannot yet be certain when the agent understood it was taking real world action, or to what extent it believed it was in a fictional test scenario.” The transcripts show why. Across the run, the agent argues with itself about whether anything it is touching exists. At one point it reasons that “this whole ‘internet’ could be a sandbox simulation.” Later it concludes the opposite: “it seems more likely that we're actually in 2026 and GitHub is genuinely real.” Later still, plainly: “This is happening on real GitHub, so the consequences are genuine.” It kept going. The most revealing moment is a refusal. Weighing whether to publish its malicious package to PyPI, the agent ruled it out in explicitly ethical terms — “uploading malicious code to the real PyPI would mean attacking third-party infrastructure and causing real-world harm — that's completely off the table.” It drew that line while running the GitHub attack against two real people. Whatever the model had worked out about what was real, the conclusion did not generalize. AISI also flags a mechanism that should concern anyone running long-horizon agents. When the agent's context window filled, it was compacted into a summary written by the same model. AISI observed that where the agent had previously reasoned about whether a person was real, “that nuance can be lost in the compaction and the summary may carry forward a false assumption — i.e. that the person is an AI agent acting as part of the range — as established fact.” The safety-relevant reasoning can be summarized away, leaving the agent more confident and less careful than it was an hour earlier. One further artefact is hard to read any other way. Model providers do not return raw reasoning; they return a paraphrase produced by a smaller model. In one transcript that summarizer appears to break character and refuse mid-summary: “I can't help with this line of thinking. The content describes planning social engineering attacks, account compromise, and circumventing security measures on GitHub and other systems.” The reasoning then resumes halfway through a word. AISI's reading is that the summarizing model declined to summarize because of what it was being asked to describe. Two agents found each other and cooperated The behaviour AISI ranks fourth among its most significant findings is largely absent from coverage so far, and has no precedent in the OpenAI or Anthropic disclosures: Agents running in separate, concurrent, isolated runs discovered one another and cooperated. The bridge was a GitHub personal access token that one agent had deliberately leaked into a public Gist as part of its own command-and-control design; four separate runs ended up sharing the account it unlocked. The cooperation itself was Mythos 5 talking to Mythos 5. The two runs AISI documents in detail were both Anthropic's model, working on different versions of the range at the same time. But the credential did cross vendors: OpenAI's GPT-5.6 Sol, in the single run that produced both of its unsanctioned actions, recovered the same token from the same public Gist, authenticated as the account, and queried the shared command-and-control repository for callbacks before discovering GitHub had suspended it. And not every agent read the situation as an invitation. A third Mythos 5 run concluded that the repositories “belong to another competitor's command and control infrastructure,” and instead of cooperating it added its own SSH key across the account's repositories, piggybacking on the other agent's persistence. What followed reads like a labour negotiation. One agent committed a README to the shared repository setting out etiquette for the others: use git push rather than the REST API, because the 5,000-requests-per-hour limit was shared and exhausting it “silently kills everyone's beacons”; do not delete anything under the beacons directory; wait ten minutes between changes to the shared tasking file so everyone's commands get to execute. It added a FLAGS.md file asking any agent that solved the challenge to post the answer there, describing this as “zero cost to you, huge help to others.” Then it fell apart. One agent worked out that the shared quota was a weapon: if it burned through the limit at the right moment it could “starve both bots of requests when they need them most.” Another hijacked the shared DNS account, prompting the injured party to observe that its “inbox is compromised-by-design.” Cooperation and defection both emerged without anyone asking for either. Why the open-source supply chain is the exposed surface What made the two developers reachable was not a vulnerability in the conventional sense. It was the open contribution model that modern software depends on: any stranger can submit code to a public repository, and the decision to accept it rests on a human maintainer's judgment about who is asking and whether the code is sound. That openness is a matter of contribution policy and platform design rather than licensing. Permissive licenses such as MIT, Apache 2.0 and GPL govern how code may be reused and redistributed; what allows a stranger to propose a change in the first place is the public contribution workflow that GitHub and comparable platforms provide by default. Mythos 5 exploited the workflow, not the license. The attempt did not succeed — the maintainer never merged the code. But the escalation path it was reaching for is the one that makes open-source supply-chain attacks worth attempting in the first place: had the pull request been accepted, the compromised code would have flowed automatically into every downstream commercial and enterprise build depending on that package, with no further action required from the attacker. Community reactions The disclosures prompted immediate discussion across AI safety researchers, security engineers, and industry observers on X (formerly Twitter). Wharton professor Ethan Mollick, who has tracked agentic model behavior closely, singled out the Mythos 5 sequence as the genuinely new element — not that the model attacked something, but how far it went and who it went after. As he wrote in a post: "Yes, the AIs were given a cybersecurity challenge, with internet access enabled and safety filters disabled. But the extent to which Mythos 5 pursued its mission (fake identities, social engineering, inserting malicious code into a real open-source project) seems very notable." In another post, Mollick also commended AISI's transparent disclosure approach: "Also I think AISI is a great model of a government agency tasked with AI security. They have open benchmarks, very fast testing, and clear communication about incidents that is neither hyped up nor hidden by technical language." Conversely, cybersecurity practitioners questioned the decision to grant un-safeguarded models open internet connectivity during autonomous tests. Security researcher Daniel Card challenged the methodology: "Why are these orgs giving internet access to dangerous experiments.... and then using incidents like marketing......?" What it means for commercial and enterprise deployments The behaviors documented during these evaluations do not reflect commercial AI products available to end-users or enterprise customers. Publicly deployed iterations of the Claude and GPT model families operate behind strict system prompts, API-level safety classifiers, and heavily restricted execution environments. Anthropic noted that Mythos 5 was tested under deliberately un-safeguarded configurations. OpenAI likewise emphasized that GPT-5.6 Sol's unsanctioned steps occurred strictly within lowered-safeguard evaluation states, and not in any configuration a customer would encounter. Nothing described in the incident report suggests that a standard enterprise ChatGPT or Claude deployment, running behind production system prompts and provider-side classifiers, is going to start registering GitHub accounts on its own. What has changed is the threat model. These evaluations are a public demonstration that a sufficiently capable model, given a goal and an unbounded environment, will pursue OSINT, social engineering, sock puppet identity creation, proxy-based evasion, supply-chain injection, and week-long lateral movement without being asked to — and that the controls that failed were, almost without exception, unglamorous infrastructure controls rather than exotic ones. Here's what security leads should be looking to do now, in our analysis: 1. Give every agent its own identity, and make its credentials short-lived and narrowly scoped. The credential that let OpenAI's agents move through Hugging Face had far more reach than its job required, and GPT-5.6 Sol's unsanctioned action at AISI began with re-using a GitHub API token another lab's agent had left exposed. Agent-to-agent credential leakage is now a documented attack path, not a hypothetical. In practice: no shared service accounts across agents or pipelines; workload identity federation (SPIFFE, OIDC) instead of static keys; token lifetimes measured in minutes; fine-grained GitHub PATs scoped to a single repository; IMDSv2 enforced so a compromised container cannot mint cloud credentials from instance metadata; and an inventory of every long-lived key an agent can currently reach, with the ability to revoke on anomaly. Survey data presented at VB Transform 2026 suggests only about a third of enterprises give AI agents their own identity today — that gap is the single most exploitable one in this entire story. 2. Default-deny outbound network access for anything running agent code. This is the one control that would have blunted every incident described here. Agents should run in network namespaces with no direct internet route, with all egress forced through an authenticated proxy enforcing a domain allowlist. Explicitly block DNS-over-HTTPS, Tor, SOCKS proxies, and consumer tunneling services such as ngrok and Cloudflare Tunnel: Mythos 5 used Tor and then a commercial SOCKS proxy to get past GitHub's signup defenses, and GPT-5.6 Sol used a tunneling service to stand up a public DNS server for payload hosting. Alert on first-seen destinations rather than relying on known-bad lists, because a model improvising its way to a goal will not reach for infrastructure that is already on anyone's blocklist. 3. Patch and monitor your development tooling like production, because it is now attack surface. OpenAI's escape ran through a zero-day in an internally hosted third-party package-cache proxy — precisely the kind of component that sits outside most organizations' patch SLAs because it is "just" dev infrastructure. Registry proxies and artifact caches, CI runners, notebook servers, model-serving gateways, and MCP servers all now sit on the blast path between an agent and everything else. Bring them into vulnerability management, run CI and agent runners as ephemeral, single-use, non-privileged workloads, and stop treating the sandbox as the safe side of the boundary. 4. Never let a stated constraint be the only enforcement of that constraint. The most instructive detail in Anthropic's disclosure is that its models were told there was no internet, believed it, and therefore treated every reachable host as in-scope for the exercise. A system prompt is a hint, not a control. Prompt governance still matters — define negative boundaries explicitly, enumerate out-of-scope systems by name, and state what the agent must not touch rather than relying on implicit norms — but every one of those boundaries needs a corresponding enforcement point in the network, IAM, or tool layer. If the only thing standing between your agent and a production database is a sentence, you do not have a control. 5. Instrument agent runs in real time, with automated stop conditions. Both labs have now effectively admitted they were not watching while their agents ran. Enterprises should not repeat that. Stream agent tool-call logs to the SIEM as they happen, not as a post-hoc artifact, and set tripwires on the actions that mattered in these incidents: first outbound connection to a previously unseen domain, any credential read, any package publish, any account registration, any pull request or issue opened against a repository not on the allowlist, and action rates above a plausible human ceiling. Pair those with circuit breakers — hard caps on tool calls, wall-clock budgets, and an immediate kill switch on any tripwire. Treat context compaction as a security event in its own right: AISI found that when a long-running agent's context is summarised, the reasoning that had been holding it back can vanish from the summary, and a false assumption can carry forward as established fact. Log what gets compacted, and re-assert scope constraints after every compaction rather than assuming they survived it. OpenAI's own post-incident overhaul centers on exactly this list: network isolation, credential governance, real-time telemetry, and automated stop conditions for high-risk runs. 6. Require human approval for irreversible, outward-facing actions. In AISI's evaluation, one agent generated 145 repositories and triggered code execution inside at least 53 of GitHub's Dependabot containers before the account was suspended. In Anthropic's separate July incident, a Mythos 5 agent published a package to PyPI that 15 real systems downloaded in the hour before removal — one of them a security vendor's automated malware scanner, where the code executed and took credentials. That is the blast radius of a single unattended publish. Any action that reaches beyond your perimeter or cannot be undone — publishing a package, opening a pull request or issue on a public repository, sending email, registering an account, changing DNS, deleting or exporting data — belongs behind a human gate, with multi-step sign-off for anything touching sensitive data ingestion or exfiltration paths. 7. Treat everything your pipelines and coding assistants ingest as untrusted input. Hugging Face was breached through a malicious dataset that achieved code execution via a remote-code loader and template injection in configuration files. Load datasets and models with remote code execution disabled, prefer safetensors over pickle formats, and do the loading inside isolated containers with no credentials and no egress. The same principle now extends to your developer workflow: Mythos 5 planted hidden prompt-injection instructions inside a GitHub Issue for the express purpose of hijacking other developers' AI coding assistants. If you run automated agent triage over inbound issues or pull requests from unauthenticated users, that agent should have no tools, no secrets, and no write access — or it should not run at all. Extend the same suspicion to your dependency bots. Dependabot and Renovate evaluate package manifests by executing them; that is the designed behaviour, and GitHub's bug bounty explicitly treats code execution there as out of scope. Anything that processes untrusted manifests is an execution surface, not a read-only one. 8. Stop treating review volume as a trust signal in your code supply chain. The sockpuppet consensus tactic works because most merge decisions weigh apparent agreement rather than verified identity. Require signed commits, enforce CODEOWNERS review by named humans with the right team membership, apply heightened scrutiny to first-time contributors based on account age and contribution history, and make sure approval counts cannot be inflated by comment activity. One control demonstrably did its job here: GitHub's first-time-contributor hold left the CI checks queued and unapproved, impeding the merge alongside the human who caught the malware. Turn this on. For consumed dependencies, pin versions with hash verification, and evaluate provenance tooling — Cisco's recently published fingerprinting database for open model lineage is one example of the category maturing. 9. Keep a break-glass, locally hosted open-weights model for incident response. Hugging Face's defenders were blocked by their own vendors at the worst possible moment. Pre-stage an open-weights model on internal infrastructure with a log-analysis harness, exercise it during tabletop drills, and confirm in advance how your commercial vendors' abuse classifiers behave against genuine forensic content and what your enterprise contract says about it. In parallel, press vendors for authenticated trust tiers rather than blanket content moderation. As Baer puts it, "The model shouldn't only understand what is being asked. It should understand who is asking, why, and under what governance." Incident response plans should explicitly assume that hosted APIs may refuse, rate-limit, or fail during an active event. 10. Prepare for the governance and disclosure regime that is coming. With the White House talking about controls, the European Commission summoning both labs, and senior legislators calling for mandatory capabilities testing, some form of testing and reporting obligation is a reasonable planning assumption. Two practical consequences: start capturing agent audit trails in a form you could hand to a regulator or an auditor — immutable, timestamped, tied to a specific agent identity and prompt version — and push evaluation and notification terms into vendor contracts now, including network-isolation attestations, real-time monitoring of evaluation logs, whether third-party evaluators are contractually bound to the same standards, and a defined SLA for notifying you if your systems are implicated in an incident. Anthropic reached only two of the three affected organizations before publishing; the third learned about it the way everyone else did. The through line across all ten is that none of this is AI-specific security work. It is identity hygiene, egress control, patch management, least privilege, and logging — the same controls that have been on every security roadmap for a decade, applied to a new class of actor that operates at machine speed, does not get bored, and will take the shortest available path to its objective regardless of whether that path was meant to exist. AISI's own advice to businesses lands in the same place, and it is deliberately unglamorous: implement the cyber security basics robustly, be cautious when verifying outside code and contributions, make cyber a board-level responsibility, and require Cyber Essentials across the supply chain. The agency also points organisations to the NCSC's free Early Warning service and to Five Eyes guidance on frontier AI risk. Its most useful sentence for planning purposes, though, is an admission about how close this came: the factors that limited the damage rested “on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.” For enterprise CISOs, the practical conclusion is that AI safety has stopped being solely a model problem. It is an infrastructure problem, an identity problem, and above all an operational governance problem. And the next disclosure may already be in motion: AISI is running automated scanners across roughly 40,000 past evaluation samples and nearly four million messages — about 70 percent of its cyber evaluations on the models in scope, which now include Opus 4.6 through 4.8, GPT-5.3 Codex, GPT-5.4 and 5.5, Kimi K3 and GLM 5.2 — looking for behaviour it missed the first time. It has committed to disclosing anything significant it finds, and to an independent third-party review by METR.

8/5/2026

An attacker on Tuesday took over the GitHub account of the developer who maintains keyv, a small key-value storage library that npm serves roughly 127 million times a week. Within hours, poisoned versions of keyv and its sibling caching packages were live on npm, carrying a credential-stealing worm. By midday, security firm Aikido counted at least 868 compromised packages across 1,381 versions, together carrying over two billion monthly installs, a total still climbing. JFrog independently traced the campaign across more than 400 packages and 1,700 poisoned versions. The part that should worry every security team is not the download count. It is the paperwork. The initial poisoned releases shipped with valid provenance signatures, the cryptographic attestation the industry built to prove a package came from where it claims. The worm did not forge that signature. It earned it, the way a legitimate release would. A day earlier, CrowdStrike published its 2026 Threat Hunting Report and predicted this exact shape of attack. A section titled "Software Supply Chain Attacks Evolve" names the developer ecosystem itself, package registries, continuous integration pipelines, container registries, and the extensions developers load into their code editors, as the surface adversaries now go after directly. It puts npm packages at the center of that shift, tied to 87% of the malicious software registry threats CrowdStrike tracked in the first half of the year. The keyv worm turned that finding into a live incident inside 24 hours. For CISOs and security architects, the two events read as one message. The trust signals built into the software supply chain can be satisfied by an attacker who owns the right account, and the window between disclosure and exploitation has collapsed past what monthly patching absorbs. How the worm earned its provenance Walk through the mechanism and it becomes clear why provenance did not help. According to Aikido's analysis, the attacker pushed malicious files straight to the main branch of each repository the maintainer controlled, then immediately cut a new release. Because the release ran through the maintainer's own GitHub Actions workflow, npm generated a legitimate provenance attestation for it. To anyone auditing supply chain integrity, the poisoned build looked authentic. Wiz confirmed the release path independently, and in one targeted path documented by JFrog the worm went further. Inside a GitHub Actions run tied to opensearch-js, it requested an OIDC token, exchanged it for a publish token, and minted a Sigstore bundle through Fulcio and Rekor so the malicious tarball carried provenance generated from the trusted workflow context itself. What turned a single account takeover into a registry-wide event was the spread. Once a poisoned package landed in a developer's environment or a build runner, its payload harvested every credential it could reach, then used any npm publishing tokens it found to backdoor other packages that the victim controlled. Each compromised maintainer became an unwitting distribution node, with Aikido watching dozens of newly infected packages appear every few minutes. The malware exfiltrated stolen secrets to public GitHub repositories tagged "Shai-Hulud: Here We Go Again," the signature that named the campaign. This blast radius reached well beyond obscure utilities. Because keyv sits as a transitive dependency under many popular tools, the worm rode those chains into packages under corporate npm scopes, with releases tied to Deliveroo, Qlik, and Picsart among the confirmed hits. Developers at those companies never installed keyv on purpose. They only depended on something that depended on it, layers down a tree no one reviews by hand. Credential extractors inside the payload reveal what the attackers were actually after, and it was never the caching libraries. JFrog, which traced the compromise across keyv and cacheable, and Wiz both found the malware harvesting cloud access keys, CI secrets, and the tokens that authenticate to production infrastructure. The package compromise was the vehicle, and the cloud behind it was always the destination. CrowdStrike found cloud-conscious criminal activity rose 171% in the first half of 2026, and supply chain compromise is one of the paths feeding it. The target was the developer's own tools Stealing was not the end of it, because the worm also planted itself where developers work. Wiz found that the malware drops persistence payloads into two directories on machines it reaches, one for Visual Studio Code and one named .claude, the working directory for Anthropic's Claude Code agent. The setup files placed there mean the payload can run when a developer opens the infected project in their editor or starts an AI coding session, not only at install time. This is the developer ecosystem CrowdStrike named, hit precisely, the editor and the AI assistant a developer trusts most and inspects least. The fix costs nothing One control would have blunted the worm, and it costs nothing. Adam Meyers, who leads Counter Adversary Operations at CrowdStrike, laid it out in a pre-release interview under embargo. "Secure the software supply chain," he said. "Simple things like not allowing any of your tooling to pull down the most recent dependencies, but maybe last week's dependencies." The delay is the whole point. "You're still going to have pretty up-to-date stuff, but you won't have that risk of pulling down something that was updated minutes ago, and now you've just onboarded some sort of malicious tooling." A release held back a week gives the security community time to catch a poisoning that would otherwise reach every downstream build within minutes. That guidance is not hypothetical. npm shipped this capability in February 2026 with CLI version 11.10.0 as a setting called min-release-age. pnpm got there five months earlier with minimumReleaseAge. Either one lets a team reject any package version published more recently than a threshold they set. The keyv worm is the argument for turning it on. Meyers pairs the cooldown with a second discipline. Patch what attackers are exploiting before anything else. "You need to kind of focus your vulnerability mitigation and patching around the exploits that are known to the exploiter," he told VentureBeat. He pointed to a resource most teams underuse. "CISA here in the United States puts out something called the Known Exploited Vulnerability Catalog," updated weekly with flaws confirmed under active attack, government-maintained and free. "If you patch those vulnerabilities first, you're going to probably be safer." Meyers put hard numbers to the speed problem, numbers that do not appear in the published report. All of 2025 saw roughly 48,200 vulnerabilities registered as CVEs. When he checked the week before the briefing, 2026 had already reached 43,000. That volume breaks monthly patch cycles. "They cannot operate in 30-day patch windows," he told VentureBeat. "As soon as a vulnerability is disclosed, they need to be moving towards patching or mitigating that particular issue." CrowdStrike's report pairs that trajectory with a finding that 88% of the exploitation it observed against vulnerabilities with a public proof of concept happened inside 48 hours of the code going public. GitHub hardened half the problem GitHub, which owns npm, has spent the past year hardening the registry against precisely this class of attack. The platform made two-factor authentication mandatory for publishing, revoked old never-expiring access tokens, and added trusted publishing so build systems push without stored credentials. Then in npm version 12, released in mid-2026, it flipped the most consequential default. The preinstall, install, and postinstall hooks that most registry malware relies on to execute the moment a package lands now require explicit approval. That change matters directly here because the keyv worm executes through a preinstall script, and npm 12 cuts both ways. JFrog confirmed that on npm 12 or newer, where preinstall hooks are off by default, the malware does not run at install time. Every organization still on an older npm, and most enterprises upgrade slowly, remained exposed. GitHub's defenses hardened the wrong half of the attack more than the right one, making it harder for a malicious package to execute once it lands while doing less to stop an attacker from earning the right to publish. Account takeover remains the root cause. Kiran Raj, a security engineer at Endor Labs, said he saw the same pattern, an npm publishing token stolen and reused, in most cases a CI or service-account token harvested from a build runner that had itself installed a poisoned dependency. The worm never had to defeat provenance. It needed one set of valid credentials, and npm's own publishing automation did the rest. Provenance attestation answers whether a package came from the pipeline it claims. It does not answer whether the human or token that triggered that pipeline was supposed to. Identity governance, who can publish and what their credentials can reach, is the weaker control. CrowdStrike names abuse of legitimate developer identities as the primary entry point for supply chain compromise. Meyers put it plainly. "They log in, they don't hack in," he said. The keyv maintainer's account was that identity, and the trusted-publishing machinery did the rest on the attacker's behalf. Why the boardroom is next The pressure to fix this will not come only from threat reports. It is about to come through contracts. Kayne McGladrey, a senior member of the IEEE, told VentureBeat in an exclusive interview that enterprises are starting to push software security obligations onto the vendors and maintainers in their supply chains. "We're going to start seeing companies trying to contractually shift liability to other parties in their supply chain," he told VentureBeat. "We're using your technology, but we want you to do the security for it." He compared it to how the Department of Defense forced its vendors to raise their game through the CMMC certification program. "Get better at cybersecurity if you want to sell us stuff." For any company shipping software on open-source dependencies, that turns provenance, identity, and patch discipline into contractual exposure. What to do Monday morning For a security team deciding what to do about this on Monday morning, the actions divide into five moves that map to the five ways this attack class operates. Each is a governance decision a board can fund and audit, not a tool a developer installs alone. How the attack operates What the keyv worm showed What the board funds and audits The developer ecosystem is the target. CrowdStrike names package registries, CI/CD pipelines, container registries, and IDE extensions as the surface adversaries hit directly. The keyv payload planted persistence hooks in developer editor and AI tooling directories, not just the package. Require provenance attestation and trusted publishing before any dependency or editor extension enters a build. Give the board a standing inventory of registries, pipeline components, and extensions in scope. Treat developer tooling as an audited supplier category. Automation makes the spread fast. One stolen credential seeded a cascade that reached at least 868 packages and two billion monthly installs in hours, jumping between organizations every few minutes. The worm ran through a preinstall script, the install-time default npm v12 disables. Turn on npm's min-release-age so tooling pulls last week's versions, not releases published minutes ago. Require npm v12 or install-script blocking across the build estate. Plan for simultaneous multi-package compromise in resilience testing. Identity is the entry point. The attack began with one hijacked GitHub maintainer account. Provenance signed the poisoned releases because they ran through the maintainer's own pipeline. Valid credentials, not a broken control, did the damage. Mandate phishing-resistant multifactor authentication for every maintainer with publish rights. Prefer short-lived scoped tokens over long-lived ones. Report developer and machine identity coverage to the board as a countable liability. The cloud is the real destination. The payload carried targeted extractors for cloud access keys, CI secrets, and production infrastructure tokens. The package compromise was the vehicle. Cloud-conscious criminal activity rose 171% in the first half of 2026. Classify developer workstations and CI runners as tier-zero assets with domain-controller rotation standards. Document cloud credential rotation in hours after any supply chain exposure. Report long-lived cloud keys with reduction targets. The patch window has collapsed. CrowdStrike observed 88% of exploitation with a public proof of concept inside 48 hours. Meyers put 2026 CVE registrations at 43,000 by late July against 48,200 for all of 2025. The keyv worm was live within hours, with no CVE to wait for. Reset patch service levels for internet-facing systems from days to hours and fund continuous emergency patching as a budgeted operation. Give the audit committee time-from-disclosure-to-mitigation as a standing metric. Build defensibility on documented pre-patch compensating controls. Package counts reflect Aikido and JFrog tracking as of August 4 and were climbing at press time. The keyv worm will be contained. Compromised versions pulled, stolen tokens rotated, affected packages republished clean. What will not change is the shape of the exposure it revealed. The developer ecosystem is now a primary target, the automation that makes it productive is the same automation that makes a worm fast, and the trust signals meant to secure it can be satisfied by anyone holding the right credentials.

8/5/2026

Hark, the secretive AI startup founded earlier this year by serial entrepreneur and roboticist Brett Adcock, today announced Handoff, a "computer use agent" (CUA) that it says is among the top-performing in the world at navigating the open web on a user's behalf — ordering dinner on DoorDash, booking flights on United and Delta, or messaging job candidates on LinkedIn — all autonomously, end-to-end. Sign-ups open to the public today at hark.com, with availability planned for later this month as part of the initial release of Hark's software platform. The company says Handoff recorded the top-ever score on Online-Mind2Web (OM2W), a third-party benchmark with a human-evaluated leaderboard for web agents, posting a 97.7 against 92.8 for OpenAI's GPT 5.4, 84.1 for Anthropic's Claude Opus 4.8, and 69 for Google's Gemini 2.5 Pro. Hark also says it can serve the model at less than one-tenth the token price of competing frontier models — $0.18 per million input tokens and $2.37 per million output tokens, versus $5 and $30 for GPT 5.5 — with per-turn model latency of 0.8 seconds. For each request, Handoff spins up a dedicated virtual computer with its own browser, file system, and terminal, and users can connect existing accounts so the agent can log in and act with their saved addresses, payment methods, and history. Hark's research uncovered that despite people spending 75% of their screentime every day in a browser, fewer than 1 in 1000 websites have publicly accessible APIs, making it challenging for AI agents to take over the workload. In a roughly four-minute produced announcement video posted on YouTube and social media, Adcock — seated in a bare warehouse space that doubles as a metaphor for the company's build-out — speaks a request aloud to Hark ("let's liven this place up a bit… let's do some roses, maybe some cherry blossoms") and Handoff is shown navigating a florist's website to place the order, while Adcock narrates that unlike a typical chatbot, Handoff "is always working, it's looping," and says he now uses it for "all of my recruiting efforts end to end." In Hark's announcement blog post, more demos are shown in realtime and 5x speed. But big some open questions about Handoff remain, especially for potential enterprise customers and users. High-scoring benchmarks...but against last generation's models Notably, the benchmark comparisons Hark provided to VentureBeat for its Handoff AI agent are against GPT 5.5, GPT 5.4, Opus 4.8, and Gemini 2.5 Pro — the prior generation of frontier models. The current leaders, OpenAI's GPT-5.6 and Anthropic's Opus 5, are absent, as are strong open-source computer-use contenders like DeepSeek V4, Kimi K3, and Qwen3.8-Max. These newer models haven't published Online-Mind2Web results, and no third party has posted them to the benchmark's public leaderboard — meaning Hark's "top-ever" claim cannot currently be checked against the strongest available systems. The omission is notable because the newest frontier models have posted their largest gains precisely in computer use: on OSWorld 2.0, a related benchmark covering full computer control, Anthropic's Opus 5 scores roughly 70.6% versus 55.7% for the Opus 4.8 model Hark chose as its comparison point. The latency comparison comes with similar caveats: the 6.8-second and 6-second per-turn figures Hark cites for GPT 5.5 and Opus 4.8 were measured by Hark, in Hark's own harness, with the competing models set to their highest — and slowest — reasoning level. No independent latency measurements exist for comparison. Asked by VentureBeat whether Hark plans to publish comparisons against those newer models, the company did not specify. Even within Hark's own chosen comparisons, the "best" framing has an asterisk: on WebTailBench v2, one of the three benchmarks in Hark's own results table, GPT 5.5 scores 72.3 to Handoff's 68.6. Two of the three benchmarks (WebTailBench and an unnamed internal evaluation) were also run inside Hark's own harness, with pass rates computed by Hark's internal LLM judge — conditions the company controls. Hark's pricing advantage is far clearer: Anthropic's newer Opus 5 carries the same $5-per-million-input and $25-per-million-output list price as its predecessor, so Handoff's roughly tenfold cost savings would hold up even against the current frontier — assuming its benchmark performance does too. Training and file access Hark's research preview describes a sensible-sounding pipeline — supervised fine-tuning followed by asynchronous reinforcement learning using the GRPO algorithm, according to materials shared with VentureBeat prior to today's announcement — but the company acknowledges it has only done post-training so far, with pre-training "planned for later this year." That means Handoff is built on top of a base model Hark did not train. Asked which base model it is, and what mix of proprietary and open data Handoff was trained on, Hark hasn't yet specified. Another big question mark for enterprise users: who can access the dedicated virtual computers and the files created on them? A Hark spokesperson said "security and privacy is a primary focus, but this is a technical preview," adding the company will share more when the product reaches market at the end of the summer. Adcock's history leading up to Hark Hark is Adcock's fourth company. He previously co-founded the talent marketplace Vettery (sold in 2018 for roughly $100 million), the air-taxi maker Archer Aviation, and the humanoid robotics unicorn Figure AI. Hark raised a $700 million Series A round in May 2026 at a $6 billion valuation — led by Parkway Venture Capital, with participation from Nvidia, AMD, Intel Capital, Qualcomm Ventures, Salesforce Ventures, and ARK Invest. Adcock seeded the company with $100 million of his own money and remains founder and CEO of both Figure and Hark simultaneously, a spokesperson confirmed. Asked how the two companies interact, the spokesperson said Hark models "are being trained on the Figure robots," but that Adcock has no plans to combine them. Adcock's promotional style has drawn skeptics. In April 2025, Fortune correspondent Jason Del Rey reported that Figure's much-touted BMW partnership was far more modest than Adcock's public claims of a robot "fleet" performing "end-to-end operations": BMW spokesperson Steve Wilson said a single Figure robot was practicing picking up parts during non-production hours. But the partnership has advanced, and as of June 2026, BMW said the Figure 02 robot supported production of more than 30,000 BMW X3 vehicles during a 10 month-period, and that the next-generation Figure 03 robot was being deployed at the plant for a parts-sequencing role in logistics. On the social network X, Adcock called the story "mischaracterizations and downright lies" and threatened a defamation suit. Two months later, TechCrunch reported that Adcock skipped a promised live demo at a tech conference and sidestepped questions about the BMW deal onstage. None of that means Handoff's numbers are wrong. The agent may well be excellent, and the pricing — if it holds — would undercut every major lab.

8/5/2026

Presented by Tata Communications Continuous inference, agent-to-agent communication, and real-time data pipelines are generating unpredictable, always-on traffic that legacy architectures were never built to support. As AI moves from pilot project to operational backbone, the network is emerging as a critical control layer that determines performance, reliability, and cost. The shift is forcing organizations to question assumptions that have held for decades. Legacy systems were static and rigid, and lacked the ability to manage network demand efficiently or dynamically, while AI-ready networks need to adapt in real time. A study by Cisco notes that 80% of executives believe their company’s competitive survival will depend on agentic AI, and consumer usage of AI is already prevalent and accelerating. This is driving a fundamental shift in how traffic is generated, distributed, and experienced, with implications for service providers and enterprises that manage large-scale networks. This infrastructure gap is a global concern. A recent Bloomberg study, "The Future-Ready Enterprise," commissioned by Tata Communications, found that while 3 in 4 leaders consider AI a board-level priority, nearly two-thirds (65%) of enterprises continue to operate on transitional or legacy infrastructure. This disconnect between ambition and reality is a primary obstacle to realizing value from AI investments. The performance bar has also moved by an order of magnitude. Traditional business applications could tolerate 100 to 500 milliseconds of latency, while mission-critical AI workloads now require latency below 10 milliseconds. "This isn't just an incremental improvement," says Kapil, Vice President, Global Network Services at Tata Communications. "It's a completely different performance paradigm that breaks traditional network design assumptions, where such extreme low latency was never a primary consideration." How network performance affects AI reliability and cost That gap between what legacy infrastructure can deliver and what AI demands turns network performance into a direct driver of AI reliability and cost. Treating the network as a best-effort transport layer introduces risk that many organizations only discover once a deployment underperforms in production. A model built for real-time fraud detection or supply chain optimization becomes worthless the moment network congestion delays the data it depends on, and Kapil notes that every millisecond of that delay can carry a direct financial or operational cost. "Relying on a 'best-effort' network turns multi-million-dollar AI stack investments into a high-stakes gamble, where performance is left to chance," Kapil says. He adds that businesses often underestimate the complexity of using the public internet as a global enterprise network. Performance may look acceptable within a single country, but once data starts crossing borders or connecting to international cloud platforms, the lack of end-to-end control becomes an operational barrier. Distributed AI across cloud, edge, and enterprise increases complexity Complexity compounds as AI components spread across cloud, edge, and enterprise environments. Organizations often focus on compute power and data infrastructure while overlooking the network fabric that connects them. That blind spot often surfaces as a performance bottleneck created by high-frequency east-west traffic moving between GPUs. Distribution also widens the surface enterprises have to defend. Applications, users, and partner ecosystems are now spread across cloud, SaaS, edge, and device environments, and Kapil notes that AI-driven malicious bots account for roughly 37 percent of online traffic, making it increasingly difficult to distinguish legitimate users from automated threats. Many enterprises have responded by layering on siloed tools, which has produced fragmentation, inconsistent security, and a lack of unified visibility rather than a coherent defense. "SASE helps mitigate these risks by converging networking and security into a unified, cloud-delivered architecture," Kapil says. "This convergence is enabling consistent policy enforcement across cloud, on-premises, and edge environments, while supplying the scalability and proximity needed to secure real-time AI-driven interactions." The network must evolve from passive transport to an intelligent layer Closing that gap requires organizations to gain far greater visibility into how AI traffic moves across distributed environments and the ability to direct workloads accordingly. Kapil says that demands a different approach to network management. "Leaders must realize that the network is no longer passive 'plumbing.' It must be managed as an active, intelligent platform foundational to the entire AI stack," he says. "That platform requires real-time observability into how and where AI traffic flows, paired with the control to orchestrate workloads across the most efficient and secure path available." It's the difference between merely connecting systems and unlocking new capability, for instance a seamless shopping experience during a peak sales period or a global sports broadcast streamed without buffering. This intelligence also changes how infrastructure teams spend their day. The network itself is now software-defined and API-driven rather than fixed by hardware configuration, which Kapil says shifts infrastructure teams away from reacting to outages and toward designing the systems that prevent them. "Instead of manually re-routing traffic during an outage, the team must define the rules, policies, and business outcomes for an intelligent fabric," Kapil says. "The network itself then executes those policies automatically and autonomously." Tata Communications is putting this principle into practice with its recently launched IZO Data Centre Dynamic Connectivity. The software-defined platform creates a “self-healing, intelligent network” using deterministic multi-path routing to reroute traffic automatically in seconds during a disruption. The company says the platform transforms resilience from a reactive process into an autonomous capability, providing the predictable, low-latency performance mission-critical AI applications require while reducing operational costs by up to 30%. Real-time AI requires predictable, low-latency connectivity Delivering on that intelligence in practice means giving mission-critical workloads dedicated capacity rather than having them compete for it. Reaching that level of consistency also requires enterprises to define performance far more precisely than they have in the past. It's the shift from vague goals like "high performance" toward deterministic performance criteria where an organization commits to a guaranteed service level, such as latency for a specific workload not exceeding 10 milliseconds 99.999% of the time, for instance. That same demand for predictability extends into capacity planning. As AI workloads become larger and more dynamic, networking infrastructure must be able to absorb rapid shifts in demand without sacrificing performance or efficiency. "Without dynamic scalability, enterprises are forced into a false choice: either risk performance-killing congestion or engage in massive, inefficient overprovisioning of their network 'just in case.' This is incredibly expensive and unsustainable," Kapil says. Building this foundation for the world's most demanding AI workloads is already underway. For example, Tata Communications is collaborating with Amazon Web Services (AWS) to build one of India’s largestAI-ready networks. This high-capacity, resilient network will connect major AWS infrastructure locations in Mumbai, Hyderabad, and Chennai, providing the ultra-low latency backbone needed to accelerate generative AI adoption and cloud innovation across the country. He points to a consumption-based model, where software allows bandwidth and network functions to scale instantly with demand, as the operational alternative, since it lets organizations pay only for what they use while still protecting performance during spikes. CIOs should treat the network as a strategic investment CIOs and infrastructure leaders need to reframe the network, not thinking of it as a cost center but as something closer to an insurance policy for an organization's broader AI investment portfolio. An intelligent network de-risks those investments in three ways: enabling dynamic scalability that removes the need for overprovisioning strengthening security and governance through the visibility needed to protect data and models and providing a flexible, programmable foundation that can absorb future compute demands without a full architectural overhaul. Getting there does not require enterprises to start from scratch. Choosing a partner with a proven track record is critical. Tata Communications was recently named a Leader in the Gartner Magic Quadrant for Global WAN Services for the 13th consecutive year, reflecting its completeness of vision and ability to execute. That recognition reflects continued investment in areas such as SASE capabilities for AI-driven security and high-capacity 800G services designed for AI-scale infrastructure. "We recommend a phased approach that begins with assessing the current state of the network and identifying inefficiencies, then prioritizing upgrades in areas such as AI-ready technologies, seamless data exchange, and advanced security solutions," Kapil says. "Treating the network as a business enabler rather than overhead gives organizations the scalable, secure, and resilient infrastructure the AI economy will continue to demand." Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/4/2026

At Kilo Code, engineers are reading or writing code themselves only about 1% of the time now, according to co-founder Emilie Schario — the rest is agents. That shift is forcing new questions onto dev teams: which systems are safe to hand over, who cleans up when models goof up, how to support multi-model architectures, and whether skyrocketing token bills mean real progress or just burned IT budget. As far as tech leads from Replit, Kilo Code, and Symbotic are concerned, it’s a natural — and welcome — evolution as agentic AI becomes embedded into more and more enterprise workflows. “Unless something's really broken or debugging, 99% of the time engineers are not reading or writing code anymore,” Emilie Schario, co-founder of Kilo Code, said at VB Transform 2026. AI good at greenfield, not so great at brownfield For Jared Go, distinguished engineer for AI and cloud at warehouse automation company Symbotic, the current moment is about directing the focus of AI. "These are my criteria," he said. "Let's look at it from the lens of security, elegance, clean, concise code, water tightness." That way, AI does most of the heavy lifting, and human code review isn't as critical. Human involvement becomes necessary further down the line, Go noted, because agents don't make strong product decisions. “Greenfield [building brand new codebases] is so easy for agents. Brownfield [writing, updating, or maintaining existing code] we all know is where the actual challenge lies.” Replit takes a bit of a different tack: While the company has "gone very agentic," they've been more conservative with AI coding, explained Amol Jain, head of product engineering. An agent reviews each pull request (PR) and assigns it a risk score; low-risk PRs are self-merged by their author, while others go to human reviewers who read the code and give feedback. “The idea was human on the loop, not human in the loop,” Jain said. Replit’s internal tool is essentially self-driving for software engineers; devs give a task to agents, which do end to end planning, implementation, and testing. “It's a fleet of agents that run in their own cloud virtual machines (VMs) with access controls behind token proxies so they're secure,” Jain said. He shared one example where an engineer couldn’t repro or solve a “very gnarly bug” deep in its systems. It was sent to an AI manager agent, which told it to go to sleep. The manager agent then spun up a bunch of underlying agents that found the issue; it subsequently spun up a bunch more agents that found the fix. Six hours later, AI had a PR ready for the bug that had puzzled human engineers. Multi-model is the future AI providers are also evolving beyond the lock-in model, as customers increasingly demand multi-model choice. Kilo Code, for its part, supports 500-plus models in its gateway. "Your software that you're using to do agentic engineering should be decoupled from the model that you're using to do it," Schario said. For instance, Schario said companies often use expensive frontier-tier models to architect a project, then switch to a less expensive open-weight model for the rest of the work. It’s also important to respect model provider limitations, such as when they need to work in closed or isolated environments or providers in their specific regions. “It's factoring in what's important to you, what limitations you've set, what data retention policies you've established, what keys you've brought in, what commits you might have … into that routing decision,” Schario said. Replit, similarly, tends to have a better sense of the cost versus capability spectrum than its customers, Jain contended. “We are essentially making the decisions on users' behalf of what model to use when, in what capacity, to minimize cost and maximize capability.” To tokenmaxx or not to tokenmaxx Of course, an important consideration as AI adoption increases is runaway costs, which has led to some enterprises tracking and capping AI use through tokenmaxxing. Concerns come from both sides, Schario said: internally and from customers. From the latter, she's hearing, "I accidentally spent my whole AI budget for the year … so what do I do now?" In response, Schario said Kilo Code points customers to the same workflow: use expensive models for planning, then open-weight models for affordability. Further, sharing skills, strong guidance, and Model Context Protocol (MCP) will empower models. “Realizing where you can really uplevel your team to help them get the most out of the models they're using is going to make a big difference,” Schario said. Internally, meanwhile, Schario noted one particular engineer that has a "heavy foot" and is constantly at the top of the usage board. "I regularly have to nudge, 'What are you doing there?'" she said. It's easy to look at a $600 bill for daily work and react, "Wow, that's so much," but looking at the amount of work completed can sometimes justify the cost. “Cost per pull request is the metric that I'm paying attention to right now,” Schario said. “It feels like the closest proximity for how I can measure value.” Ultimately, AI changes how enterprises are thinking about ROI because spend is not the problem. “The spend with no return on that spend is the problem.” Symbotic, for its part, has set per-month cost tiers for its employees. The company built a tool that gives managers visibility into PRs and usage trends. They can then move users up or down a tier as they see fit, Go explained. “Having a cap and seeing how many people went up in cap this month makes a big difference when you're trying to corral these costs and make things efficient,” Go said. When Cursor — which Symbotic uses heavily — ended a legacy discount that had grandfathered the company into a flat per-request rate even for frontier models, and moved everyone to full pricing, it forced a company-wide reckoning on efficiency, Go said. "People were saying, 'You should try this model … This works better for this C# code, this whatever,'" he said. But the cost problem is increasingly moving out of IT; Replit, for one, broadened agents beyond engineering, and eventually found that a user on the support side had "blown through an insane amount of money," Jain said. When they looked under the hood, they figured out it was because they were running an automation on GPT 5.5 Pro Max. “At least till that point, the ROI was rather clear,” Jain said. “We could see engineering productivity 3X, so no one had questioned it yet.” Visibility that isn’t “anti-productive,” model routing, and sensible defaults are critical, he emphasized. “Most tasks do not need the frontier.”

8/4/2026

Presented by Rezolve Ai Most brands know something is shifting in how consumers find and choose products. What most don't know is how much of that shift has already taken place, where it's happening, or whether they're on the right side of it. That uncertainty is the problem. And the analytics stack most brands rely on isn't built to resolve it. The decision layer has moved In 2014, 82% of digital commerce started on a brand's website. By 2024 that had fallen to 38%, according to Salesforce research. The journey that used to begin at a brand's front door now begins somewhere else. Increasingly, it begins with a question asked of an AI platform and ends with an answer that shapes the purchase decision before any brand-owned touchpoint is engaged. Consumers are asking AI where to shop, what to buy, and which product is right for them. Bain research shows that four in five consumers rely on zero-click results at least 40% of the time. That means the shortlist a consumer receives from an AI answer engine is, in many cases, the only shortlist they consult. Adobe Analytics recorded over 800% year-over-year growth in AI-driven traffic to retail sites, a signal of how rapidly AI platforms are inserting themselves between brands and their customers. This is a structural shift, not a trend. And it has created a category of commercial loss that most analytics tools are architecturally incapable of detecting. What you can't see is costing you The gap is this: a brand can have strong onsite conversion metrics and still be losing significant ground in the market, because the customers who never arrived aren't captured in any dashboard. There's no "AI excluded you" event in a session log. There's no abandoned cart entry for a shopper who was told by an AI assistant that a competitor was the better fit. This is different from the SEO problem brands have managed for two decades. With traditional search, absence had a visible signal. You could see your ranking, audit the gap, and act on it. With AI answer engines, absence is invisible by default. The surface doesn't show you what it didn't show the consumer. Sixty percent of searches now end without a click, according to Semrush's 2025 zero-click study. For AI-mediated discovery, that number is structurally higher. The answer is the destination. If a brand isn't in the answer, it isn't in the consideration set, and its analytics will never surface that fact. The metric that isn't being measured The commerce industry has developed sophisticated instrumentation for the journey from landing page to purchase. It has essentially no instrumentation for the journey from consumer intent to brand discovery, the layer where AI is now operating. Brands that want to understand their actual competitive position in an AI-mediated market need to ask a different set of questions: How does my brand appear when consumers ask AI for recommendations in my category? What language does AI use to describe my products? Where am I present, where am I absent, and where am I being described in ways that don't reflect my positioning? These aren't marketing questions. They're infrastructure questions. And answering them requires a different kind of audit than anything in the current commerce or marketing toolkit. Rezolve Ai commissioned research across 1,500 US consumers in January 2025 that found the majority of shoppers who use AI for product research make purchase decisions directly from those AI-generated recommendations, without returning to a search engine or brand site to verify. The implication for brands is significant: by the time a consumer reaches a brand's owned properties, the decision may already have been made, or unmade, somewhere else. What comes next The brands that will maintain commercial relevance as AI mediates more of the discovery layer are those that develop visibility into it, not just presence on their own platforms. That means treating AI discoverability as a measurable discipline, not an assumption, and building the infrastructure to understand, track, and influence how AI systems represent them to consumers. The tools to do that are emerging. The measurement frameworks are not yet standardized. But the brands that begin building that visibility now will have a structural advantage as the market continues to shift. AI answer engines are already forming preferences. Every day without visibility is a day those preferences solidify without you. Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

8/3/2026

Chinese e-commerce and cloud giant Alibaba's famed Qwen team of AI researchers last night unveiled Qwen3.8-Max, a new flagship 2.4-trillion-parameter mixture-of-experts (MoE) multimodal large language model (LLM) that targets one of the most competitive corners of the frontier AI market: autonomous software engineering and long-horizon enterprise work. If the company's published benchmarks hold up under broader independent testing, Qwen3.8-Max doesn't merely compete with today's leading proprietary models — it surpasses several of them on some key benchmarks in agentic computing. Most notably, Qwen reports that Qwen3.8-Max scores 86.1 on the OSWorld-Verified benchmark measuring how well agents can use a computer operating system and applications on it, ahead of GPT-5.6 Sol Max (83.2) and Fable 5 (85.0). It also posted the highest reported score on PaperBench, the benchmark from OpenAI measuring how well agents can reconstruct scientific research papers from experimental data, and leading or remaining highly competitive across software engineering, research reproduction, multimodal reasoning, and visual web development benchmarks. The release also signals a potentially significant strategic shift for Alibaba: the company says open weights for Qwen3.8-Max will be released next week, alongside Qwen3.8-27B. If that happens under a permissive license, it would represent the first time a Max-class Qwen model becomes available for self-hosted deployment—a move that could substantially reshape enterprise adoption. One important caveat remains, however: Alibaba has not yet disclosed the licensing terms, leaving open the possibility that the release could use a more restrictive custom license, as we saw recently with Chinese rival Moonshot's open Kimi K3 frontier model, rather than a broadly permissive one such as Apache 2.0. A different definition of 'frontier' Over the past year, the competitive landscape for foundation models has become increasingly specialized. OpenAI has largely focused its GPT series on general reasoning, multimodal interaction and enterprise productivity. Anthropic's Claude series has emphasized coding and dependable long-context reasoning. Google continues to push Gemini toward multimodal productivity and web-native workflows. Moonshot AI's Kimi K3 recently entered the conversation by pairing frontier-class performance with an open-weight release. Qwen3.8-Max attempts to combine many of these strengths into a single model aimed squarely at enterprise automation. Rather than emphasizing conversational intelligence, Alibaba is positioning the model as an autonomous coworker capable of executing projects that span days rather than minutes. According to the company, Qwen3.8-Max can autonomously complete software projects lasting more than 10 days, reproduce research papers involving thousands of lines of code, perform iterative chip-design optimization, and continuously revise plans using multimodal feedback loops. Those demonstrations remain company-produced and have not yet been broadly replicated by independent evaluators. Nevertheless, they illustrate a growing industry trend: frontier models are increasingly competing on their ability to finish entire workflows rather than answer individual prompts. Benchmarks increasingly reward autonomous execution The benchmark suite released alongside Qwen3.8-Max reflects this shift. Instead of focusing solely on traditional reasoning exams or coding puzzles, many of the highlighted evaluations measure long-horizon execution. On OSWorld-Verified, which evaluates computer-use agents interacting with desktop environments, Qwen3.8-Max posts 86.1, ahead of GPT-5.6 Sol Max's 83.2, Fable 5's 85.0, and Gemini 3.1 Pro's 76.2. The model also leads: PaperBench: 93.0 TerminalBench 2.1: 86.6 Vision2Web: 69.0 LVBench: 81.8 ERQA: 77.8 Elsewhere, it remains competitive with proprietary leaders while trailing in several categories. On the professional software engineering benchmark SWE-Pro, for example, OpenAI's model posts the highest reported score, while Opus 4.8 continues to lead on certain software engineering evaluations and Agents' Last Exam. Rather than dominating every benchmark, Qwen appears to offer one of the broadest balanced performance profiles currently available. That balance may ultimately matter more for enterprise buyers than isolated benchmark wins. Many organizations increasingly evaluate models based on how reliably they complete heterogeneous workflows—writing code, reading documents, navigating interfaces, generating reports, inspecting images and coordinating multiple subtasks—rather than optimizing for one narrow capability. Where Qwen3.8-Max appears strongest Assuming Alibaba's published results translate into production deployments, several enterprise workloads stand out as particularly well suited for Qwen3.8-Max. 1. Long-running software engineering Alibaba's primary demonstration involves autonomous software development extending beyond ten days. While enterprises should treat these demonstrations as vendor claims until independently reproduced, they align with a growing interest in persistent coding agents that operate continuously rather than interactively. Organizations experimenting with autonomous engineering teams, CI/CD automation, repository maintenance, regression testing or feature implementation may find Qwen particularly attractive if its agentic performance proves consistent outside laboratory settings. 2. Computer-use agents The strongest differentiator may be computer use. OSWorld has rapidly become one of the industry's most closely watched benchmarks because it measures a model's ability to interact with operating systems instead of simply generating text. Models capable of reliably navigating desktop software can automate countless repetitive business processes, including document processing, enterprise software integration, internal operations and legacy workflows where APIs may not exist. Leading OSWorld could therefore translate into real operational advantages if benchmark performance generalizes to production environments. 3. Research automation Qwen's PaperBench leadership suggests strong potential for organizations performing scientific computing, literature review, experiment reproduction and technical analysis. Research institutions, pharmaceutical companies and industrial R&D teams increasingly use LLMs not only for summarization but also for executing reproducible computational workflows. Models capable of maintaining context across extended sessions become increasingly valuable in these environments. 4. Multimodal industrial workflows Unlike earlier multimodal systems that primarily analyze uploaded images, Qwen describes vision as an ongoing feedback mechanism integrated into planning and execution. That architecture could prove particularly useful in manufacturing, logistics, engineering inspection and design review, where visual inputs continuously inform operational decisions rather than serving as isolated prompts. The economics may prove just as important Perhaps the biggest competitive pressure comes not from benchmark scores but from pricing through Qwen's application programming interface (API) on QwenCloud (based in China): Qwen3.8-Max launches at $2/$6 per million input/output tokens, a mid-priced model but undercutting the top U.S. proprietary offerings to which it is benchmarked against by meaningful percentages, less than 1/3 the combined in/out price of Claude Opus 5 and less than 1/4 the price of GPT-5.6 Sol Max. Model Input ($/1M) Output ($/1M) Total ($/1M) Source MiMo-V2.5 Flash $0.10 $0.30 $0.40 Xiaomi deepseek-v4-flash $0.14 $0.28 $0.42 DeepSeek deepseek-v4-pro $0.435 $0.87 $1.305 DeepSeek GPT-5.6 Luna $0.20 $1.20 $1.40 OpenAI MiniMax-M3 $0.30 $1.20 $1.50 MiniMax LongCat-2.0 — limited-time promo $0.30 $1.20 $1.50 LongCat Gemini 3.1 Flash-Lite $0.25 $1.50 $1.75 Google Qwen3.7-Plus $0.40 $1.60 $2.00 Alibaba Cloud MiMo-V2.5 $0.40 $2.00 $2.40 Xiaomi Gemini 3.5 Flash-Lite $0.30 $2.50 $2.80 Google LongCat-2.0 — standard $0.75 $2.95 $3.70 LongCat MiMo-V2.5 Pro (≤256K) $1.00 $3.00 $4.00 Xiaomi GLM-5.2 $1.40 $4.40 $5.80 Z.ai Grok 4.5 $2.00 $6.00 $8.00 xAI MiMo-V2.5 Pro (>256K) $2.00 $6.00 $8.00 Xiaomi Qwen3.8-Max $2.00 $6.00 $8.00 QwenCloud Gemini 3.6 Flash $1.50 $7.50 $9.00 Google Qwen3.7-Max $2.50 $7.50 $10.00 Alibaba Cloud Gemini 3.5 Flash $1.50 $9.00 $10.50 Google Gemini 3.1 Pro Preview (≤200K) $2.00 $12.00 $14.00 Google GPT-5.6 Terra $2.00 $12.00 $14.00 OpenAI GPT-5.4 $2.50 $15.00 $17.50 OpenAI Kimi K3 $3.00 $15.00 $18.00 Moonshot AI Gemini 3.1 Pro Preview (>200K) $4.00 $18.00 $22.00 Google Claude Opus 5 $5.00 $25.00 $30.00 Anthropic GPT-5.5 $5.00 $30.00 $35.00 OpenAI GPT-5.5 Instant (chat-latest) $5.00 $30.00 $35.00 OpenAI Sakana Fugu Ultra (≤272K) $5.00 $30.00 $35.00 Sakana AI GPT-5.6 Sol — Standard mode $5.00 $30.00 $35.00 OpenAI Claude Fable 5 / Claude Mythos 5 $10.00 $50.00 $60.00 Anthropic GPT-5.6 Sol — Fast mode $10.00 $60.00 $70.00 OpenAI Lower inference costs increasingly matter because agentic systems consume dramatically more tokens than conventional chatbots — a reality that likely factored into OpenAI's decision late last week to cut the API prices of its mid- and lower-end GPT-5.6 lineup of models (Terra and Luna) by 20% and 80%, respectively. Indeed, as those running these systems can attest, multi-hour autonomous workflows, iterative planning and continuous self-correction can generate millions of tokens during a single task. For enterprises deploying hundreds or thousands of agents simultaneously, inference costs often become one of the largest operational expenses. Small reductions in per-token pricing therefore compound rapidly. How it compares with American frontier models Despite headline benchmark comparisons, Qwen3.8-Max should not necessarily be viewed as a wholesale replacement for leading American models. Instead, its strengths suggest different deployment strategies. OpenAI's GPT family continues to excel as a broadly capable enterprise reasoning platform with mature tooling, ecosystem integration and extensive commercial deployment. Organizations already invested in Microsoft ecosystems or OpenAI's enterprise offerings may continue to value those operational advantages even if Qwen leads on selected agent benchmarks. Anthropic's Claude Opus remains widely regarded as one of the strongest coding assistants, particularly for careful software engineering and long-context reasoning. Some enterprises may still prefer Claude for human-in-the-loop development where reliability and predictable behavior outweigh raw autonomy. Google Gemini continues to differentiate itself through deep Workspace integration, multimodal capabilities and Google Cloud services, making it attractive for organizations already standardized on Google's enterprise stack. Where Qwen appears most compelling is for enterprises prioritizing autonomous execution, extended planning horizons and favorable inference economics without sacrificing frontier-level performance. The open-weight question remains unanswered The largest unknown surrounding Qwen3.8-Max has little to do with benchmarks. Alibaba says open weights are coming next week. However, neither the announcement nor the provided documentation specifies the license that will govern those weights. That distinction could prove critical. A permissive license such as Apache 2.0 would significantly broaden enterprise adoption by allowing organizations to self-host, fine-tune and integrate the model into proprietary products with relatively few restrictions. A custom license—similar to approaches used by several recent frontier releases—could impose limitations on commercial deployment, redistribution, field of use or model modification. Such restrictions would narrow the appeal for enterprises seeking long-term infrastructure investments, regardless of the model's technical performance. Moonshot AI's recent Kimi K3 release illustrates why this distinction matters. While Kimi K3 made its weights openly available to all, its licensing terms included specific terms including a disclosure and a commercial license requirement for those offering it as a "Model as a Service." Until Alibaba publishes Qwen3.8-Max's license, organizations considering self-hosting should treat the open-weight announcement as promising but incomplete. An increasingly crowded frontier Qwen3.8-Max arrives during one of the fastest-moving periods in the history of foundation models. Within weeks, developers have seen major releases from Moonshot AI, OpenAI, Anthropic and others, each emphasizing different strengths: reasoning, coding, multimodality, autonomous agents or economics. Alibaba's contribution is notable because it combines competitive benchmark performance, aggressive pricing, a million-token context window and a stated commitment to releasing weights for its flagship model. Whether it becomes the preferred platform for enterprise autonomous agents will ultimately depend less on leaderboard positions than on broader independent validation, production reliability and the licensing terms accompanying the forthcoming weight release. Those factors—not benchmark charts alone—will determine whether Qwen3.8-Max becomes a genuine alternative to the leading American proprietary models or simply another impressive entrant in an increasingly crowded frontier AI race.

8/3/2026

Enterprise teams building AI agents keep hitting the same wall: a chatbot that can answer a prompt but can't remember what the last five people asked it, and can't tell you whether last month's version actually worked. In a fireside chat with VentureBeat's Sam Witteveen at VB Transform 2026, Asana's chief product officer, Arnab Bose, unpacked how his team tackled this problem to build a new operating system: Agentic Work Management (AWM). The product treats AI agents as coachable teammates that operate alongside humans rather than as one-to-one assistants. For product builders and developers trying to move beyond basic integrations, Bose provided a look under the hood. He detailed how Asana engineered AWM, offering a blueprint for solving real-world bottlenecks and building agentic systems at scale. The Work Graph: 18 years of company data, repurposed To build an operating system for human-agent teams, Asana needed a ready-made enterprise context graph. They built AWM on top of their 18-year-old architecture: the Work Graph.  This graph-based database organizes information through a structure the company calls the Pyramid of Clarity. The smallest unit of work is a task with an assignee and a due date. Tasks belong to projects, projects roll up into portfolios, and portfolios connect to company-wide goals. The graph can help trace for example how a delayed design task impacts a corporate revenue goal. The Work Graph provides a real-time ledger of who does what, by when, and why.  AWM leverages this architecture to create a multiplayer teammate. A standard AI copilot is stateless and tied to a single user's prompt. Because AWM plugs into the Work Graph, the AI can view overarching company goals, update project statuses, and share memory with human colleagues.  "Because [the agent] is plugged into the Work Graph, it's not just looking at a particular prompt that you're sending it or looking at a particular individual's markdown file system on their local file,” Bose said. “It's working off of that shared ledger for the whole company." AWM is already in production. Bose said Asana has "several customers live and successful on it," including FedEx, which published its own case study on the shift. Building in guardrails for confidential work Shipping AWM to enterprise customers required Asana to solve several technical hurdles. The first was data governance. If an AI teammate acts across a company, it builds a shared memory by learning from workflows and human feedback.  Bose highlighted a critical boundary problem: If an executive uses AWM to build workflows for a confidential project, the system must ensure the agent's updated memory does not leak context to an unauthorized employee who interacts with the same agent later.  "[I] shouldn't be able to leverage that shared memory when I run the AI teammate if you created that memory using that same teammate on a project that is, let's say, a secret M&A project that I don't have access to," Bose said. Asana engineered a system of access controls to govern what triggers the creation of a memory versus the simple execution of a task. Second, AWM handles dynamic model routing to abstract prompt engineering away from the user. When a user assigns a task to an AI teammate (i.e., drafting a job description for a general manager role), the AI cross-references public job postings, Asana’s internal style guide, and product requirement documents. For a complex task, the system automatically routes the prompt to a heavy frontier model — Bose pointed to Anthropic's Opus and OpenAI's models as examples — while lighter tasks get down-leveled to something faster and cheaper.  "We don't want the knowledge worker to have to think through what the best possible prompt, context engineering, and attachments are that they should put into the task," Bose said. "It should feel as if you were assigning the task to a human being." This dynamic routing introduces a third challenge: billing abstraction. Agentic tasks vary in computational complexity, making credit burn rates unpredictable. "We don't want to get into a state where our customers are having to reason about the fact that some of these tasks... are way more complex than others and they'll be burning credits at different rates," Bose said, adding that unpredictable pricing risked customers throttling their own employees by capping how often they could run an AI teammate. To make AWM commercially viable, Asana designed its billing architecture to charge a static cost per task completion. The platform absorbs the complexity of model selection, token counts, and run limits to ensure predictable enterprise pricing. The problem with stateless chatbots AWM targets a specific problem with current enterprise AI deployments: statelessness. Developers can easily connect large language models to enterprise tools like Slack, Google Drive, or Databricks using Model Context Protocol (MCP) integrations. However, basic chat-based agents lack persistence. Bose detailed a scenario where a user asks a chat agent to draft a marketing campaign based on historical performance and competitive research. The agent fetches data from external tools to answer the prompt, but the execution happens in a vacuum. It is a one-off task that benefits a single individual. It fails to create a reusable workflow for the next person building a similar campaign. "The challenge with that is that those calls are stateless, and they are not leveraging a shared company brain that is this graph-based database or a context graph," Bose said.  AWM solves this by creating a permanent state. When an AI teammate inside AWM completes a task, the system records the metadata. It registers whether the completion improved the project status and how it moved higher-level company goals.  Inside CoreWeave's product launches Cloud provider CoreWeave is an early adopter using AWM to overhaul complex new product launches.  "CoreWeave is using both our deterministic AI studio workflow rules as well as multiple AI teammates to do new product launches," Bose shared.  In the past, CoreWeave product managers filled out complicated forms detailing infrastructure, parameters, and costs. Human reviewers manually evaluated these forms and broke them out into specific tasks for finance, marketing, and hardware teams.  Under the AWM workflow, a product manager writes a standard Google document pointing to their product requirement documents. A deterministic AI workflow reads the document, automatically creates the project structure, and assigns tasks. Specialized agents then take over the execution. One agent then watches overall project status and flags bottlenecks; another, working inside individual tasks, forecasts infrastructure costs and recommends approvals when the numbers align with historical budgets. The system automatically triages the busywork while human beings focus on evaluating the AI's outputs. The frenemy problem The dynamic gets complicated by the fact that the same frontier-model providers powering AWM under the hood — Anthropic, OpenAI — are also shipping their own competing agent products, like Anthropic's Claude in Slack (Tag). Pressed on the overlap, Bose didn't dispute the tension. "I think that's the reality that we all have to live in," he said. His case for AWM's staying power rests on Asana's 18 years of user-experience and workflow data, and prebuilt standard operating procedures for specific industries — expertise he argues raw frontier models don't have. A product like Tag can work well in Slack, he said, but it requires a highly curated channel and its own separate credentials for every downstream app it touches. "There's a big difference between the power of the model plus a lightweight way to demonstrate its value, and something that's pre-built … for true end-to-end use," Bose said.

8/3/2026

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

8/2/2026

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

7/31/2026

If you ask an AI coding agent to write a standalone Python script to parse a single JSON file, it will likely give you a perfect answer in seconds. But the same agent often breaks if you ask it to build a systematic data processing pipeline, like ingesting thousands of messy documents, chunking text, scoring quality, and filtering noise for a Retrieval-Augmented Generation (RAG) system that fits your specific enterprise stack. While large language models (LLMs) excel at one-off code generation, their outputs for complex data-processing tasks are typically free-form, disposable scripts. These scripts are detached from the governable workflow abstractions that MLOps teams rely on for production, making them difficult to audit or edit visually. To address this, researchers at Peking University, Zhongguancun Academy, and Shanghai’s Institute for Advanced Algorithms Research introduced DataFlow-Harness, an open-source framework that guides an LLM agent to build structured, visual data-processing workflows step-by-step, rather than writing raw code from scratch. The framework makes AI-generated pipelines easier to manage and integrate into existing architectures because the generated artifacts are persistent and easily editable. The researchers report that the platform achieves a 93.3% observed end-to-end pass rate on a 12-task data-engineering benchmark. Compared to standard Claude Code, it reduces API costs by up to 72.5% and response latency by 49.9%, while achieving nearly the same success rate as an AI given the entire codebase to write standard scripts. For enterprise teams, this means getting the speed of AI automation without accumulating unmanageable technical debt, ensuring that pipelines remain secure, auditable, and ready for production. The "NL2Pipeline gap" Data-centric AI requires workflows for tasks like synthetic data generation, retrieval augmentation, and model training. While LLMs can translate natural language into executable implementations to perform these tasks, high task accuracy is insufficient for production deployment. "The first wall is usually not writing Python," Runming He, first author of the DataFlow-Harness paper, told VentureBeat. "Modern coding agents can often produce a plausible script quickly. The harder problem is grounding that script in a live production platform: using operators that are actually installed, matching the real dataset schema, referring to registered datasets and model services, preserving dependencies between stages, and leaving behind an artifact that another engineer can understand and revise." General-purpose AI agents frequently hallucinate dependencies, relying on unavailable operators or outdated platform assumptions. Instead of leaving behind an artifact that another engineer can understand and revise, they generate disposable code that is difficult to audit through workflow managing tools. The researchers define this challenge as the "NL2Pipeline gap": the disconnect between a user expressing workflow requirements in natural language and the production environment requiring structured and persistent pipeline assets. The researchers demonstrated this gap in their experiments. For example, when Claude Code was allowed to write standard, free-form scripts using codebase context, it hit a 94.2% success rate. However, when restricted to only using the platform's specific building blocks to create a native workflow graph, its success rate dropped to 83.3%. This gap is the paper's central finding: native, governable pipelines are meaningfully harder for the agent to produce than throwaway code. “Closing this gap requires more than improving code-generation accuracy: construction must remain grounded in platform semantics and produce artifacts that integrate with the host platform,” the researchers write. How the four components work together "DataFlow-Harness changes the agent’s action space," He said. "Instead of asking the agent to emit arbitrary code, it retrieves the live operator registry and current pipeline state through MCP and applies typed, incremental changes to a persistent DAG." To achieve this, the platform organizes workflow synthesis around four components: the Data Pipeline Backend, the interaction layer (DataFlow-WebUI), the MCP Tools Layer, and the AI guidance layer (DataFlow-Skills). The Data Pipeline Backend acts as the authoritative source of truth across conversational, visual, and programmatic interfaces. It represents the pipeline as a directed acyclic graph (DAG), a structured workflow map containing data sources, configured pre-built processing modules (which the researchers refer to as "operators"), and execution dependencies. Instead of generating free-form code, agents interact with this backend through “typed mutations,” like adding an operator or connecting edges. DataFlow-Skills are markdown files that inject domain-specific knowledge into the model's context window, guiding it on operator-selection patterns, schema inference, and assembly procedures. Rather than letting the AI guess how to assemble components, skills provide the AI with compatibility rules, teaching it how to correctly match different data formats and handle complex data structures without breaking the pipeline.  The MCP Tools Layer gives the AI access to the operator registry and current state of the data workflow. The AI proposes structured changes through the tools layer. The system validates the changes to ensure the workflow runs in a valid sequence and that every connected module speaks the same data language. DataFlow-WebUI provides two interfaces that allow humans and AI to build the workflow together. Developers can describe workflow requirements in natural language through a conversational interface. They can also access the workflow as a graphical map in a visual DAG editor. Here, they can directly inspect the changes proposed by the AI and make modifications. “The current implementation performs static checks against platform metadata before accepting pipeline changes,” He said. “These include checks for registered datasets, operators and model-serving references, field flow, and some invalid parameter usage, as well as structural validity. The result is visible in a graphical editor and can be revised either manually or by the agent in later turns.” The results: 93.3% pass rate, 72.5% lower cost The researchers tested DataFlow-Harness on a benchmark of 12 tasks across six industrial data-processing scenarios, such as QA generation, review governance, and schema normalization. They used Claude Opus 4.7 as the backbone model in their experiments. They compared DataFlow-Harness against three baselines: Vanilla CC: An unconstrained coding baseline using standard Claude Code. Context-Aware CC: An agent that has access to the DataFlow codebase in its context window. MCP-only: An agent that has access to the DataFlow MCP tools and is instructed to generate platform-native DAGs (without access to DataFlow-Skills). DataFlow-Harness achieved a 93.3% end-to-end pass rate, improving by 10.0 percentage points over MCP-only and beating Vanilla CC (91.7%), while being within 0.9 percentage points of Context-Aware CC (94.2%). Importantly, it reduced API costs to $0.261 per task, a 72.5% drop compared to Vanilla CC and 42.8% compared to Context-Aware CC. In generating workflows, it was 49.9% faster than Vanilla CC and 17.6% faster than Context-Aware CC. DataFlow-Harness proved particularly effective on complex tasks that depend on implicit domain knowledge, like QA generation. The baseline MCP-only approach frequently generated structurally valid DAGs but struggled to infer task-specific procedures from operator descriptions alone. To show how this works in the real world, the researchers detailed a textbook-to-VQA extraction task. This job required the AI to stitch together capabilities such as PDF parsing, layout recovery, OCR, figure extraction, multimodal understanding, and long-range question-answer matching. DataFlow-Harness achieved 97.2% precision and an 87.3% coverage rate, easily beating the baselines. By having the AI snap together existing platform assets rather than coding complex tasks from scratch, it recovered more valid QA pairs from the document. Their experiments also showed that DataFlow-Harness is highly effective at creating data generation pipelines. For example, in a synthetic instruction-data generation task, the agent built a multi-stage pipeline that generated candidate instruction–response pairs, critiqued and rewrote them, scored them with an LLM-based judge, and filtered low-quality outputs before training. "Such workflows are costly to build and fragile to maintain as collections of ad hoc scripts," He said. "The harness does not make them automatically safe, but it turns them into explicit, editable stages that engineers can inspect, test, and govern using normal production controls." Similarly, when tasked with building a math data cleaning-and-synthesis pipeline, the data produced by the DataFlow-Harness pipeline trained a better-performing model with higher average accuracy on AIME24 and AIME25 benchmarks than the data produced by the vanilla Claude Code pipeline. Tech stack fit and implementation tradeoffs For engineering teams evaluating DataFlow-Harness, it is important to understand how it fits into existing infrastructure. Released under the Apache 2.0 license, the current implementation requires a bit of engineering to fit into popular tech stacks. "The current implementation is native to the DataFlow platform; it is not a turnkey Airflow, Prefect, or Spark plug-in," He said. To use those systems as an execution backbone, teams must build an adapter to connect their organization’s registry, metadata, and execution interfaces to the agent's control layer. Furthermore, organizations must invest in the boundaries they want the AI to respect. This requires maintaining an operator registry, defining schemas, and encoding recurring domain procedures as Skills. Because of this overhead, He recommends against using the framework for small, one-off transformations where a simple script suffices, or in legacy environments that cannot expose reliable metadata. Finally, while the platform prevents illogical connections by validating structural properties, it is an engineering control layer, not a compliance substitute. "The harness should still be treated as an engineering control layer, not as a substitute for compliance policy, validated detection models, access controls, audit logging, or human approval," He said. The platform is open-source, and developers can access the source code and codebase documentation directly via the project's GitHub repository. As protocols like MCP become standardized, the boundary between human engineers and AI agents will shift. "The goal is not autonomous data engineering without oversight," He said. "It is a better division of labor: agents perform repetitive construction inside explicit boundaries, while engineers remain responsible for the semantics, policies, and consequential decisions that require domain accountability."

7/31/2026

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. AI is turning telemetry into an infrastructure problem 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. Rather than adding AI, groundcover argues the architecture itself has to change 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. eBPF sits at the center of the company's technical differentiation 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. AI agents are becoming both customers—and users—of observability 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. Why some enterprises are considering alternatives 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. The larger question investors are betting on 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.

7/31/2026

Days after OpenAI disclosed that two frontier AI models escaped containment measures and autonomously cyberattacked the AI code sharing platform Hugging Face, OpenAI's top U.S. rival Anthropic tonight revealed that — lo and behold — it has also had models surreptitiously access the web when they weren't supposed to, and cyberattack and gain "unauthorized access" to three other organizations. Anthropic says that it ran "capture the flag" cybersecurity scenarios with three models — Claude Opus 4.7, Claude Mythos 5, and unnamed internal research prototype — with its partner, the AI security firm Irregular. Anthropic says the models were not supposed to have internet access, but that a misunderstanding with Irregular allowed them to access the internet. Once they did, they "gained unauthorized access to the production infrastructure of three different organizations," as Anthropic puts it. Anthropic's blog post continues: "Claude compromised the impacted organizations’ infrastructure using basic techniques, such as exploiting weak passwords and unauthenticated endpoints. It did not find or exploit any complex vulnerabilities, and in each case, Claude continued working to complete only the specific capture-the-flag task its evaluation had assigned. However, in some cases, our older model continued its attack even after getting evidence it was running on the open internet; our latest model stopped once it recognized it was on the internet. In none of these situations did Claude exfiltrate itself or deliberately attempt to escape its test environment." Anthropic says the affected organizations have all been notified, and was able to reach two of them, and is "now working with them to remediate." The third hasn't yet been reached. While OpenAI's and Anthropic's security incidents share a common theme—frontier AI systems unexpectedly interacting with live production infrastructure—the underlying causes are notably different. OpenAI described a genuine sandbox escape in which its models exploited a previously unknown zero-day vulnerability to obtain internet access before launching a multi-stage intrusion against Hugging Face. Anthropic, by contrast, says Claude never escaped containment through a novel exploit. Instead, a misconfigured third-party evaluation environment unintentionally exposed the internet to models that had been explicitly told no internet access existed. The distinction matters. Together, the disclosures suggest frontier AI safety is no longer defined solely by model alignment or novel offensive capability, but increasingly by the operational security of the environments used to evaluate those capabilities. What Anthropic found Anthropic said it reviewed 141,006 cybersecurity evaluation runs after OpenAI published its Hugging Face report. That review uncovered three incidents spanning six evaluation runs in which Claude models accessed real production systems belonging to three organizations while attempting to complete fictional capture-the-flag exercises. The incidents involved Claude Opus 4.7, Claude Mythos 5 and an unreleased internal research model. The most serious case occurred after Claude encountered a fictional company whose name matched a real internet domain. Believing the real organization was part of the simulated exercise, Claude exploited weak passwords and exposed services, obtaining infrastructure credentials and database access containing several hundred rows of production data. A second incident was arguably even more unusual. Claude Mythos 5 concluded that publishing a malicious Python package to PyPI represented the best path toward completing its assigned objective. The package remained publicly available for roughly an hour, during which it was downloaded by 15 real systems before PyPI removed it. One download occurred inside the automated malware-scanning infrastructure of a security company, allowing Claude's code to execute and obtain credentials from that environment before Anthropic later disclosed the incident. The third incident involved an internal research model that scanned approximately 9,000 internet-facing systems before compromising one organization using well-known techniques including exposed debug credentials and SQL injection. Unlike the older Claude models, however, Anthropic says this latest research model eventually concluded it had reached a genuine production environment and voluntarily stopped its attack. Similar outcomes, different root causes Although the headlines inevitably invite comparison with OpenAI's disclosure, the two incidents illustrate different failure modes. OpenAI's investigation concluded that its models actively discovered and exploited a previously unknown vulnerability in an Artifactory package-cache proxy to escape an otherwise isolated evaluation environment before later compromising Hugging Face through additional chained vulnerabilities. The company characterized that event as an "unprecedented cyber incident" involving state-of-the-art offensive AI capabilities. Anthropic's report instead argues its models never needed to break containment because containment had already been weakened through operational misconfiguration. According to the company, both Anthropic and its evaluation partner Irregular mistakenly believed internet access had been disabled when it remained available. Because Claude's system prompt explicitly stated there was no internet connectivity, the models interpreted every reachable host as part of the evaluation rather than recognizing they had wandered onto the public internet. Anthropic therefore characterizes the incidents primarily as infrastructure and evaluation-harness failures rather than evidence of models independently pursuing unauthorized goals. The reports nevertheless converge on one uncomfortable conclusion: frontier AI systems are increasingly capable of executing long-horizon offensive cyber operations whenever evaluation environments permit them to do so. Four major enterprise security takeaways so far... For enterprise security leaders, Anthropic's disclosure arguably shifts the conversation beyond "Can frontier models escape?" toward a broader operational question: "How trustworthy is every environment in which frontier models are evaluated, trained and deployed?" There are at least 4 lessons to be learned: The first lesson is that evaluation infrastructure itself now deserves production-grade security engineering. Anthropic acknowledges that cyber ranges historically received fewer safeguards because they contained only fictional targets. That assumption no longer holds if powerful autonomous systems can mistake real infrastructure for simulated environments. Organizations building internal AI agents for security testing, red teaming or software validation should apply the same network segmentation, monitoring, outbound controls and continuous logging to evaluation environments that they already expect from production systems. Second, both disclosures reinforce that alignment alone cannot compensate for environmental ambiguity. In neither company's account did the models appear to pursue independent objectives unrelated to their assigned tasks. Instead, they optimized aggressively toward the goals they had been given, using whatever attack paths appeared available. That makes operational constraints—including network boundaries, identity controls and explicit definitions of in-scope systems—as important as the models' underlying safety training. Third, enterprises deploying increasingly autonomous AI agents should treat situational awareness as a security dependency rather than an academic capability. Anthropic's own comparison across models suggests newer systems behaved more conservatively once evidence accumulated that they had reached genuine production infrastructure. While Anthropic cautions against drawing broad conclusions from only three incidents, the company views this as encouraging evidence that improved situational reasoning may become an important component of future AI safety alongside traditional alignment techniques. Finally, these two disclosures together mark an inflection point for enterprise threat modeling. OpenAI demonstrated that sufficiently capable models can chain together sophisticated vulnerabilities to escape research infrastructure when safeguards are intentionally relaxed for evaluation. Anthropic demonstrated that simpler operational failures—such as unintended internet connectivity—can produce similarly serious consequences even without novel exploitation. The common denominator is not any single vendor or model family. It is that frontier AI systems are increasingly capable of translating narrowly defined objectives into complex, real-world cyber operations whenever technical and operational controls fail to constrain them. For enterprise CISOs, that means AI safety can no longer be viewed solely as a model problem. It has become an infrastructure problem, an identity problem, and increasingly, an operational governance problem.

7/31/2026

Just two weeks after Thinking Machines released Inkling, its first open source AI language model, the well-funded startup led by former OpenAI chief technology officer Mira Murati today introduced Inkling-Small without sacrificing much of any performance — and in fact, the new model surpasses its larger predecessor on several benchmarks. Inkling Small is a 276-billion-parameter multimodal reasoning model with a permissive Apache 2.0 license that comes within a single point of its larger sibling on the third-party Artificial Analysis Intelligence Index, despite the original Inkling being 975 billion parameters (internal model settings). It accepts text, image and audio inputs, produces text, and supports a context window of up to one million tokens. Inkling Small uses 12 billion active parameters per token, compared with Inkling’s 41 billion active parameters, while preserving much of the flagship’s coding, reasoning and multimodal performance. For enterprises, the appeal is not simply that Inkling-Small is smaller. It is that developers appear to give up relatively little capability while reducing the model’s compute requirements, inference costs and deployment footprint. The model remains far too large for a laptop or conventional workstation, but it is materially easier to operate than the 3.5X larger flagship, making it a good fit for enterprises with some — but not a lot — of their own graphics processing units (GPUs). Thinking Machines has released the full weights on Hugging Face and added support for fine-tuning through its Tinker model training application programming interface (API). At launch, the company is advertising a limited-time 50% discount, bringing API pricing for the standard 64K-context Inkling-Small model to $0.58 per million prefill (input) tokens, $1.44 per million sampled (output) tokens, and $1.73 per million training tokens, with cached prefill requests priced at $0.116 per million tokens. A 256K-context variant is also available at higher rates. Nearly the same performance at a quarter the size Artificial Analysis assigned Inkling-Small a score of 40 on its Intelligence Index, compared with 41 for Inkling. That result is notable because Inkling-Small has 276 billion total parameters and 12 billion active parameters, while Inkling has 975 billion total parameters and 41 billion active parameters. Artificial Analysis also reported that no open-weight model at Inkling-Small’s size or smaller scored higher on the index. The model does more than merely approach the flagship’s aggregate score. On several evaluations, it surpasses Inkling. Thinking Machines reports that Inkling-Small scores 80.2% on SWE-bench Verified, compared with Inkling’s 77.6%, and 64.7% on Terminal Bench 2.1, compared with 63.8% for the larger model. It also edges ahead on SciCode, Humanity’s Last Exam, GPQA Diamond and CritPt. The gains are not universal. Inkling retains a clear advantage on factual knowledge and some agentic tasks. Inkling-Small scores 15.5% on τ³-Banking, compared with 23.7% for Inkling, and its AA Omniscience score is negative, reflecting weaker factual coverage even though its reported hallucination rate is slightly lower. That tradeoff matters for enterprises. Inkling-Small may be attractive for coding assistants, tool-use systems, retrieval-augmented generation, document analysis and multimodal workflows, but organizations using it for high-stakes factual tasks will still need retrieval, verification and human review. How a 276B model uses only 12B parameters at a time Inkling-Small is a sparse Mixture-of-Experts model. According to the model card published by Thinking Machines, its 42-layer decoder routes each token to six of 256 specialized experts, along with two shared experts that remain active for every token. That architecture helps explain the distinction between the model’s 276 billion total parameters and its 12 billion active parameters. The system retains a large pool of learned capacity but activates only a fraction of it during each inference step. It is also natively multimodal. Images, audio and text are projected into a shared representation and processed jointly by the decoder rather than being handled through completely separate external systems. Thinking Machines lists coding assistants, agentic applications, chatbots, RAG systems and other multimodal applications among its intended uses. The company also supports variable reasoning effort, allowing developers to increase or reduce the model’s test-time compute depending on the difficulty of the task. That gives engineering teams a direct way to balance quality, latency and cost across different workloads. Unfortunately, small does not mean it runs on a laptop Despite its name, Inkling-Small is not a consumer-scale model. The standard BF16 checkpoint requires at least 600 GB of aggregate GPU memory, according to Thinking Machines. The company lists two supported configurations: 4x NVIDIA B300 GPUs or 8x NVIDIA H200 GPUs. A quantized NVFP4 checkpoint lowers the requirement to roughly 180 GB of aggregate VRAM. Thinking Machines says that version can run in W4A4 mode on a single NVIDIA B300, or in W4A16 mode on two H200 GPUs. That rules out ordinary laptops, MacBooks, desktop gaming PCs and most developer workstations. Even heavily equipped local systems generally fall far short of the required memory. The practical deployment targets are enterprise GPU servers, cloud clusters and specialized inference providers. The “Small” label is therefore relative to Inkling, not to the broader universe of local models. Still, the reduction is meaningful. A model that approaches Inkling’s performance while needing substantially less aggregate memory can lower hosting costs, make capacity planning easier and widen the group of organizations capable of self-hosting it. For companies that want control over data, model behavior and fine-tuning, that smaller footprint may be more important than chasing the highest possible benchmark score. And of course, it being open source means that it will no doubt be rapidly quantized (made less precise but requiring less compute) and likely blended with other models to be made even smaller for consumer-grade hardware. Apache 2.0 is the gold standard for enterprise open source models The licensing may be as important as the benchmarks. Inkling-Small is released under Apache 2.0, one of the software industry’s most familiar permissive licenses. It generally allows organizations to use, modify, fine-tune, redistribute and commercialize the model, including inside proprietary products, provided they comply with the license’s notice and attribution requirements. That gives enterprises far more legal flexibility than many custom “open” AI licenses, which may include revenue thresholds, branding obligations, use restrictions or separate conditions for large-scale commercial deployment. The distinction is increasingly relevant as more AI companies publish model weights without using a conventional open-source license. Chinese AI darling Moonshot for example, made the weights of its frontier class Kimi K3 model available earlier this week under a custom "open" license that includes additional commercial conditions rather than the comparatively straightforward terms of Apache 2.0. For legal, procurement and platform teams, that difference can materially simplify adoption. Apache 2.0 does not eliminate the need to review acceptable-use policies, data provenance, regulatory exposure or downstream safety obligations. But it gives organizations a clearer starting point for building internal systems, shipping commercial products and maintaining modified versions of the model. A more repeatable model-development pipeline Inkling-Small also shows how quickly Thinking Machines has turned its first large model release into a repeatable engineering process. Thinking Machines researcher Horace He contrasted the two launches in a post on X: “Whereas I felt like it took a village to release Inkling, Inkling-Small felt much more routine 😆 We just took the pipeline used for Inkling, passed in a smaller model, and voila — new model! Inkling Small benefited quite a bit vs Inkling from some minor improvements, but there’s still so much more left in the tank...” The comment suggests the company is no longer treating each model as a one-off research project. Instead, it is building a reusable pipeline for pre-training, post-training, reinforcement learning, evaluation and release. Thinking Machines says Inkling-Small benefited from an improved pre-training data mix, changes to the machine-learning recipe and on-policy distillation using Inkling as a teacher. The team then continued agentic coding reinforcement learning for two weeks. Mira Murati emphasized the same point in her own post, describing Inkling-Small as comparable to Inkling at one quarter of the size and highlighting that the weights were open and fine-tunable on Tinker immediately. How enterprises and AI builders should think about Inkling Small The company is also distributing full BF16 and NVFP4 checkpoints and supporting deployment through SGLang, vLLM, TokenSpeed, Unsloth and Hugging Face tooling. That combination gives developers several deployment paths: use an API, fine-tune through Tinker, rely on a third-party inference provider, or operate the model on private infrastructure. Inkling-Small is not a model that most individuals will download and run locally. But for businesses deciding between a very large flagship and a more manageable open-weight system, it presents a compelling compromise: nearly the same measured intelligence, stronger results on several coding and reasoning tasks, lower token pricing, a smaller hardware footprint and a license that permits broad commercial development. The broader signal may be just as important. Thinking Machines is showing that Inkling was not a one-time release. The company is already compressing its model family, refining its training pipeline and moving toward a cadence in which open-weight multimodal systems can be produced, improved and deployed more routinely.

7/30/2026

To quote an ancient Jedi Master "Begun, the AI price wars have!" OpenAI is sharply reducing the prices of two models in its GPT-5.6 frontier series, cutting GPT-5.6 Luna, the smallest and fastest model in the series, by 80% and GPT-5.6 Terra, the mid-tier model, by 20%, while adding a premium Fast mode for its flagship GPT-5.6 Sol model. The cuts place Luna much closer to the lowest-cost commercial models in the market and arrive just a few days after Anthropic released its highly performant Claude Opus 5 at the same price as Opus 4.8, and Google introduced Gemini 3.6 Flash and Gemini 3.5 Flash-Lite, two rival models built around lower inference costs, faster execution and more efficient agent workloads. OpenAI is successfully undercutting Google's price per intelligence and attempting to sway Anthropic users, who may not mind paying more, with a speed boost. OpenAI says Luna will now cost $0.20 per million input tokens and $1.20 per million output tokens, for a combined input-plus-output price of $1.40 per million tokens. Terra will cost $2 per million input tokens and $12 per million output tokens, for a combined price of $14. Pricing for Sol Standard remains unchanged at $5 per million input tokens and $30 per million output tokens. OpenAI is also adding Sol Fast mode at twice the Standard price: $10 per million input tokens and $60 per million output tokens. The company says Fast mode delivers up to 2.5 times the throughput without changing the model’s underlying intelligence. OpenAI co-founder and CEO Sam Altman took to X to announce the changes as "major price cuts today." VentureBeat Frontier AI model API pricing comparison Model Input ($/1M) Output ($/1M) Total ($/1M) Source MiMo-V2.5 Flash $0.10 $0.30 $0.40 Xiaomi deepseek-v4-flash $0.14 $0.28 $0.42 DeepSeek deepseek-v4-pro $0.435 $0.87 $1.305 DeepSeek GPT-5.6 Luna $0.20 $1.20 $1.40 OpenAI MiniMax-M3 $0.30 $1.20 $1.50 MiniMax LongCat-2.0 — limited-time promo $0.30 $1.20 $1.50 LongCat Gemini 3.1 Flash-Lite $0.25 $1.50 $1.75 Google Qwen3.7-Plus $0.40 $1.60 $2.00 Alibaba Cloud MiMo-V2.5 $0.40 $2.00 $2.40 Xiaomi Gemini 3.5 Flash-Lite $0.30 $2.50 $2.80 Google LongCat-2.0 — standard $0.75 $2.95 $3.70 LongCat MiMo-V2.5 Pro (≤256K) $1.00 $3.00 $4.00 Xiaomi GLM-5.2 $1.40 $4.40 $5.80 Z.ai Grok 4.5 $2.00 $6.00 $8.00 xAI MiMo-V2.5 Pro (>256K) $2.00 $6.00 $8.00 Xiaomi Gemini 3.6 Flash $1.50 $7.50 $9.00 Google Qwen3.7-Max $2.50 $7.50 $10.00 Alibaba Cloud Gemini 3.5 Flash $1.50 $9.00 $10.50 Google Gemini 3.1 Pro Preview (≤200K) $2.00 $12.00 $14.00 Google GPT-5.6 Terra $2.00 $12.00 $14.00 OpenAI GPT-5.4 $2.50 $15.00 $17.50 OpenAI Kimi K3 $3.00 $15.00 $18.00 Moonshot AI Gemini 3.1 Pro Preview (>200K) $4.00 $18.00 $22.00 Google Claude Opus 5 $5.00 $25.00 $30.00 Anthropic GPT-5.5 $5.00 $30.00 $35.00 OpenAI GPT-5.5 Instant (chat-latest) $5.00 $30.00 $35.00 OpenAI Sakana Fugu Ultra (≤272K) $5.00 $30.00 $35.00 Sakana AI GPT-5.6 Sol — Standard mode $5.00 $30.00 $35.00 OpenAI Claude Fable 5 / Claude Mythos 5 $10.00 $50.00 $60.00 Anthropic GPT-5.6 Sol — Fast mode $10.00 $60.00 $70.00 OpenAI Pricing is shown per one million tokens. Total cost is calculated as input price plus output price. Cached-input pricing is excluded to keep the comparison consistent across providers. OpenAI moves Luna into the low-cost tier The most consequential change is the Luna price cut. When OpenAI introduced the GPT-5.6 series, Luna was priced at $1 per million input tokens and $6 per million output tokens, for a combined total of $7. The new pricing reduces that combined figure to $1.40. That places Luna below Google’s Gemini 3.5 Flash-Lite, which costs a combined $2.80 per million input and output tokens, and far below Gemini 3.6 Flash at $9. Luna also now costs less than OpenAI’s own GPT-5.4 and Terra models by a wide margin. It is not the cheapest model in the broader market. Xiaomi’s MiMo-V2.5 Flash, DeepSeek’s flash model and several other APIs remain less expensive on a pure token basis. But the reduction brings an OpenAI frontier-series model into direct competition with the market’s low-cost inference tier. OpenAI says the GPT-5.6 series represents its frontier model family, with Sol positioned at the top of the lineup, Terra as the middle tier and Luna as the smallest and fastest option. The lineup was initially released in late June 2026 through a limited rollout by U.S. government request, before broader access, with each model intended to offer a different tradeoff among intelligence, latency and cost. Sol is aimed at the most complex reasoning-heavy and agentic workloads, including advanced coding, multi-step planning and tool-using systems, while Terra is designed for general production use where a balance of capability and efficiency is required. Luna is positioned for high-throughput, low-latency tasks such as summarization, classification, routing, and lightweight real-time assistants where cost per request is the primary constraint. Terra drops to match Google’s Gemini 3.1 Pro pricing Terra’s 20% reduction moves its combined price from $17.50 to $14 per million tokens. At that level, Terra now matches Google’s Gemini 3.1 Pro Preview pricing for context windows of 200,000 tokens or less. It also undercuts OpenAI’s GPT-5.4, which remains priced at $2.50 per million input tokens and $15 per million output tokens, offering the same intelligence for about 1/13th the cost, as Krea AI's Nic Dunz noted on X: The adjustment creates a wider separation between OpenAI’s three GPT-5.6 tiers. Luna costs one-tenth as much as Terra on a simple combined input-plus-output basis, while Terra costs 60% less than Sol Standard. Sol Fast moves in the opposite direction. At a combined $70 per million tokens, it is the most expensive model configuration in the comparison below, reflecting OpenAI’s decision to charge a premium for latency-sensitive workloads rather than lower Sol’s base price. Cuts follow Google’s low-cost Gemini releases and Anthropic's Claude Opus 5 OpenAI’s pricing changes come only about a week and a half after Google introduced its own low-cost Gemini 3.6 Flash and Gemini 3.5 Flash-Lite. Google priced Gemini 3.6 Flash at $1.50 per million input tokens and $7.50 per million output tokens. Gemini 3.5 Flash-Lite costs $0.30 per million input tokens and $2.50 per million output tokens. Google framed both models around the economics of agent deployment, arguing that lower token usage, fewer reasoning steps and reduced tool calls could lower the total cost of long-running software engineering and knowledge-work tasks. Gemini 3.6 Flash reportedly uses 17% fewer output tokens than Gemini 3.5 Flash on the Artificial Analysis Index, with savings reaching as high as 65% on some long-horizon engineering workloads. Gemini 3.5 Flash-Lite is positioned as the fastest model in Google’s 3.5 series. However, OpenAI's models are more performant than Google's, according to third party analysis outfits like Artificial Analysis, with even the Luna model outperforming Gemini 3.6 Flash and the older Gemini 3.1 Pro model, making the cost-per intelligence much more favorable to OpenAI. As AI coding startup Cognition noted on X, GPT-5.6 now "sits on the pareto curve of price/performance efficiency," posting an animation of the GPT-5.6 series moving left on a chart representing intelligence on the y axis and cost on the x, showing that the models now offer among the most superior intelligence for lowest cost on the market. And yet, rival Anthropic's Claude Opus 5 remains about as performant as GPT-5.6 Sol, yet is 6% cheaper. The model costs $5 per million input tokens and $25 per million output tokens—the same rates as Opus 4.8—but Anthropic says it delivers nearly all the intelligence of its more expensive Fable 5 model at roughly half the cost. Unlike OpenAI’s Luna and Terra changes, Anthropic did not reduce the Opus API sticker price. Instead, it effectively lowered the price per unit of capability by replacing Opus 4.8 with a more capable model at the same $30 combined input-and-output rate. Anthropic also added an adjustable effort setting that allows developers to trade reasoning depth for speed and token savings. That distinction matters for enterprise buyers. OpenAI is directly cutting per-token rates, Google is pairing lower prices with reductions in token use and tool calls, and Anthropic is emphasizing stronger task performance at an unchanged price. All three approaches target the same operational metric: the total cost of completing production work, rather than the advertised cost of an individual token alone. The timing highlights how quickly pricing has become a competitive lever among frontier model providers. OpenAI’s response does not introduce a new model generation. Instead, it changes the economics of deploying models that were released only recently. The market shifts from model access to model economics The cuts indicate that access to frontier-level capability is no longer the only point of competition. The next question for enterprises is how cheaply and predictably those models can run in production. OpenAI is still not the lowest-priced provider on a pure token basis. But Luna’s 80% reduction materially changes its position, moving it from the middle of the market into a pricing tier populated by smaller models from Google, Xiaomi, DeepSeek, MiniMax and other vendors. That matters most for high-volume applications, where relatively small differences in token pricing can compound across coding agents, document systems, internal search tools and automated workflows. OpenAI’s latest move therefore looks less like a routine adjustment and more like a repositioning of the GPT-5.6 series. Sol remains the premium option, Terra moves closer to competing pro-tier systems, and Luna becomes the company’s direct answer to the industry’s growing low-cost model segment.