One of the companies bringing this to the forefront is Salesforce, with a new workflow platform that turns back-office workflows into a set of tasks for specialized agents to complete. Users can upload their processes or use one of the set Blueprints provided by Salesforce, and Agentforce Operations will break it down for agents. 

Salesforce senior vice president of Product, Sanjna Parulekar, told VentureBeat in an interview that the problem is that many enterprise workflows are not built for agents. “What we’ve observed with customers is that a lot of times, the brokenness in a process is probably in your product requirements document,” Parulekar said. “So when that’s uploaded into a product, it doesn’t quite work. We can optimize it and cut out some things and replace it with an agent.”

Without this control panel layer, enterprises could risk deploying agents that increase cost rather than fix their workflow problems.

Making the workflow work for agents, not just humans

Enterprises deploying agents are learning a costly lesson: Their workflows were designed around human judgment gaps, not machine execution. Processes that evolved through years of workarounds — loosely defined steps, implicit decisions, coordination that depends on individuals knowing what to do next — break when agents are asked to follow them literally.

Even with all of an enterprise’s context at its fingertips, AI systems will have difficulty completing tasks if it is not clear what it’s supposed to do. 

Parulekar said her team found that focusing on what makes the process tick and breaking it down into more explicit steps and workflows makes the system more deterministic. Then, when platforms like Agentforce Operations introduce agents, those agents already know their specific tasks.  

“It forces companies to rethink their processes and introduces observability into the mix because of the session tracing model in the system,” she said.

Parulekar said human checks can be built into the system, so the process is more transparent.

What makes this approach different from other workflow automation offerings is that it doesn’t rely on agents to decide what to do next; the system does. Unlike more traditional automation tools that route tasks and agents on probabilistic decision-making, this enforces execution on a more pre-defined, deterministic structure.

The problem it introduces

Codifying a workflow doesn't fix a broken one. If a process has flawed steps, encoding it for agents locks in the problem at scale. And once workflows are distributed across agents, the challenge shifts from execution to governance: who owns the process, who validates it, and how it evolves when business conditions change.

It puts the onus on teams to take a hard look at what works for them and what doesn’t.

Organizations need to consider that, along with the execution control plane offered by platforms like Agentforce Operations, someone should be made responsible for task completion and success. 

Brandon Metcalf, founder and CEO of workforce orchestration company Asymbl, told VentureBeat in a separate interview that the key to both humans and agents following a workflow is a shared goal. 

“You have to understand the goal or the agent or human won’t complete the task successfully,” Metcalf said. “Someone has to manage that outcome that has to be delivered. It can be a person or an agent.”

The bottleneck has moved. As Metcalf framed it, the question is no longer whether agents can reason through a task, it's whether the workflow underneath them is coherent enough to execute. For enterprises that built their processes around human judgment and institutional memory, that's a harder fix than swapping in a smarter model.

MCP's STDIO transport, the default for connecting an AI agent to a local tool, executes any operating system command it receives. No sanitization. No execution boundary between configuration and command. A malicious command returns an error after the command has already run. The developer toolchain raises no flag.

OX Security researchers Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok and Roni Bar scanned the ecosystem and found 7,000 servers on public IPs with STDIO transport active — and estimate 200,000 total vulnerable instances extrapolated from that ratio. They confirmed arbitrary command execution on six live production platforms with paying customers. The research produced more than 10 CVEs rated high or critical across LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, Bisheng, DocsGPT, GPT Researcher, Agent Zero, LettaAI and others.

Kevin Curran, IEEE senior member and professor of cybersecurity at Ulster University, independently told Infosecurity Magazine the research exposed "a shocking gap in the security of foundational AI infrastructure."

Anthropic confirmed the behavior is by design and declined to modify the protocol — characterizing STDIO's execution model as a secure default and input sanitization as the developer's responsibility. That characterization comes from OX; the only word Anthropic explicitly stated on the record is "expected." Anthropic has not issued a standalone public statement and did not respond to VentureBeat's request for comment.

OX says expecting 200,000 developers to sanitize inputs correctly is the problem. Anthropic's strongest technical counter: sanitizing STDIO would either break the transport or move the payload one layer down. Both positions are technically coherent. The question is what to do while that debate plays out.

Every major outlet covered the disclosure. None built the prescriptive product-by-product audit a security director needs to triage her own MCP deployments. This piece does.

Five questions determine whether your MCP deployments are exposed, whether your patches hold, and what to do Monday morning.

Am I exposed?

If your teams deployed any MCP-connected AI agent using the default STDIO transport, yes. The insecurity is not a coding bug in any single product. It is a design default in Anthropic's MCP specification that propagated into every official language SDK: Python, TypeScript, Java, and Rust. Every downstream project that trusted the protocol inherited it.

OX identified four exploitation families. Unauthenticated command injection through AI framework web interfaces, demonstrated against LangFlow and LiteLLM. Hardening bypasses in tools that implemented command allowlists, demonstrated against Flowise and Upsonic, where OX bypassed the allowlist through argument injection (npx -c). Zero-click prompt injection in AI coding IDEs, where malicious HTML modifies local MCP configuration files. Windsurf (CVE-2026-30615) was the only IDE where exploitation required zero user interaction, though Cursor, Claude Code, and Gemini-CLI are all vulnerable to the broader family. And malicious package distribution through MCP registries, where OX submitted a benign proof-of-concept to 11 registries, and nine accepted it without security review.

Carter Rees, VP of AI and Machine Learning at Reputation and member of the Utah AI Commission, told VentureBeat the framing needs to change entirely. "MCP stdio is a privileged execution surface, not a connector. Enterprise teams should treat it like production shell access. Deny by default, allowlist, sandbox and stop assuming downstream input validation will hold at scale," Rees said.

The IDE family deserves particular attention because it hits developer workstations, not servers. A developer who visits an attacker-controlled website can trigger a modification to their local MCP configuration file — and in Windsurf's case, the change executes immediately with no approval prompt. Cursor, Claude Code and Gemini-CLI require some form of user interaction, but if the UI presents a configuration change without surfacing the execution consequence, clicking 'approve' does not constitute informed consent.

Did my vendor patch?

Some did. Some partially. Some have not confirmed. The matrix below maps each affected product against the exploitation family, patch state, and the gap that remains. The critical column is "Protocol fix?" Every row says no.

Does the flaw survive the patch?

Yes. Every product-level patch in the matrix addresses the specific entry point in that product. None of them changes the MCP protocol's STDIO behavior. A security director who patches LiteLLM today and configures a new MCP STDIO server tomorrow will inherit the same insecure default on the new server. The patches are necessary. They are not sufficient.

This was predictable. When VentureBeat first reported on MCP's security flaws in January, Merritt Baer, chief security officer at Enkrypt AI and former deputy CISO at AWS, warned: "MCP is shipping with the same mistake we've seen in every major protocol rollout: insecure defaults. If we don't build authentication and least privilege in from day one, we'll be cleaning up breaches for the next decade." The Cloud Security Alliance independently confirmed OX's findings in a separate research note and recommended organizations treat MCP-connected infrastructure as an active, unpatched threat. The defaults did not change. The attack surface grew.

Rees argued that Anthropic's position, while internally consistent, does not survive contact with enterprise reality. "It stops being a developer mistake and starts being a distributed failure mode when the same class of failure reproduces across that many independent implementations," he told VentureBeat. "Guidance is not an architectural control. Relying on thousands of downstream implementers to consistently interpret a trust boundary is a known anti-pattern in enterprise security."

Anthropic updated its SECURITY.md file nine days after OX's initial contact in January 2026 to note that STDIO adapters should be used with caution, but made no architectural changes. The researchers' assessment of that update: "This change didn't fix anything."

Rees took a more measured view. "It's worth giving Anthropic credit where it's due," he told VentureBeat. "After the disclosure, they updated their security guidance to recommend caution with stdio adapters. That's a meaningful step even if researchers argue it falls short of a protocol-level fix."

What changed at the protocol level?

Nothing architectural. Anthropic has not implemented manifest-only execution, a command allowlist in the official SDKs, or any other protocol-level mitigation. OX recommended all three. The SECURITY.md guidance update was the only change. OX's research began in November 2025 and included more than 30 responsible disclosure processes across the ecosystem before the April 15 publication.

The disagreement is substantive. Anthropic's architectural argument deserves its full weight. STDIO is a local subprocess transport designed to launch processes on the machine that configured it. The trust boundary, in Anthropic's model, sits with whoever controls the configuration file. If you can write to the MCP config, you are by definition someone authorized to execute commands on that machine. Under that logic, what looks like command injection is a feature working as intended. Restricting what STDIO can launch at the protocol level would either break the transport's core function, since its purpose is to launch arbitrary local processes, or displace the attack surface into the launched process itself. The unopinionated-standard argument is also defensible: a universal protocol that hard-codes execution constraints stops being universal. OX's counter, from their advisory: "Shifting responsibility to implementers does not transfer the risk. It just obscures who created it."

Do not wait for a protocol-level fix. Treat every MCP STDIO configuration as an untrusted input surface, regardless of which product it sits inside.

Monday morning remediation sequence

Enumerate. Identify every MCP server deployment across dev, staging, and production. Search for MCP configuration files (mcp.json, mcp_config.json) in developer home directories and IDE config paths (~/.cursor/, ~/.codeium/windsurf/, ~/.config/claude-code/). List running processes that match MCP server binaries. Flag any using STDIO transport with public IP accessibility. OX found 7,000 on public IPs. Your environment may have instances you do not know about.

Patch. Pin every affected product to its patched release. LiteLLM v1.83.7-stable includes the fix for CVE-2026-30623. DocsGPT, Flowise, and Bisheng have also shipped fixes. Windsurf and Langchain-Chatchat remain in reported state as of May 1, 2026. Cursor was patched against an earlier related disclosure (CVE-2025-54136) but inherits the same protocol default. Check each vendor's advisory in the morning you execute this step.

Sandbox. Isolate every MCP-enabled service from the host operating system. Never give a server full disk access or shell execution privileges. The Flowise/Upsonic allowlist bypass proves that restricting commands alone is not enough.

Audit registries. Review every MCP server installed from a third-party registry. Nine of 11 registries accepted OX's proof-of-concept without a security review. Use registries with documented submission review processes. Remove any MCP server whose origin you cannot verify.

Treat STDIO config as untrusted. This step survives every future patch and every future product. The protocol-level default has not changed. Every STDIO server definition is a command execution surface. Treat it the same way you treat user input to a database query: assume it is hostile until validated.

Your exposure cannot wait for a protocol fix

Anthropic and OX Security disagree on where the responsibility for securing MCP's STDIO transport belongs. That disagreement will not be resolved this week. What can be resolved this week is whether your MCP deployments are enumerated, patched, sandboxed, and treated as the untrusted execution surfaces they are.

As Rees put it: "The core question here is architectural policy, not exploit payloads." Baer warned in January that insecure defaults would produce exactly this outcome. OX documented 200,000 servers running with a configuration field that doubles as an execution surface. The protocol's designer says it is working as intended. Your Monday morning question is not who is right. It is which of your servers are exposed.

“As a result, there's less of a need for frameworks to actually help users compose these deterministic workflows in a light and shallow manner,” Jerry Liu, co-founder and CEO of LlamaIndex, explains in a new VentureBeat Beyond the Pilot podcast. 

Context is becoming the moat

Liu’s LlamaIndex is one of the foremost retrieval-augmented generation (RAG) frameworks connecting private, custom, and domain-specific data to LLMs. But even he acknowledges that these types of frameworks are becoming less relevant. 

With every new release, models demonstrate incremental capabilities to reason over “massive amounts” of unstructured data, and they’re getting better at it than humans, he notes. They can be trusted to reason extensively, self-correct, and perform multi-step planning; Model Context Protocol (MCP) and Claude Agent Skills plug-ins allow models to discover and use tools without requiring integrations for every one independently. 

Agent patterns have consolidated toward what Liu calls a "managed agent diagram" — a harness layer combined with tools, MCP connectors, and skills plug-ins, rather than custom-built orchestration for every workflow.

Further, coding agents excel at writing code, meaning devs don’t need to rely on extensive libraries. In fact, about 95% of LlamaIndex code is generated by AI. “Engineers are not actually writing real code,” Liu said. “They're all typing in natural language.” This means the layers between programmers and non-programmers is collapsing, because “the new programming language is essentially English.” 

Instead of manual coding or struggling to understand API and document integration, devs can just point Claude Code at it. “This type of stuff was either extremely inefficient or just would break the agent three years ago,” said Liu. “It's just way easier for people to build even relatively advanced retrieval with extremely simple primitives.”

So what’s the core differentiator when the stack collapses? 

Context, Liu says. Agents need to be able to decipher file formats to extract the right information. Providing higher accuracy and cheaper parsing becomes key, and LlamaIndex is well-positioned here, he contends, because of its developments with agentic document processing via optical character recognition (OCR). 

“We've really identified that there's a core set of data that has been locked up in all these file format containers,” he said. Ultimately, “whether you use OpenAI Codex or Claude Code doesn't really matter. The thing that they all need is context.”

Keeping stacks modular

There’s growing concern about builders like Anthropic locking in session data; in light of this, Liu emphasizes the importance of modularity and agnosticism. Builders shouldn’t bet on any one frontier model, or overbuild in a way that overcomplicates components of the stack. 

Retrieval has evolved into “agent-plus-sandbox,” as he describes it, and enterprises must ensure that their code bases are tech debt free and adaptable to changing patterns. They also have to acknowledge that some parts of the stack will eventually need to be thrown away as a matter of course. 

“Because with every new model release, there's always a different model that is kind of the winner,” Liu said. “You want to make sure you actually have some flexibility to take advantage of it.”

Listen to the podcast to hear more about: 

• LlamaIndex’s beginnings as a ‘toy project’ with initially only about 40% accuracy; 

• How SaaS companies can tap into complicated workflows that must be standardized and repeatable for average knowledge workers;

• Why vertical AI companies are taking off and why ‘build versus buy’ is still a very valid question in the agent age. 

You can also listen and subscribe to Beyond the Pilot on Spotify, Apple or wherever you get your podcasts.

Last night, xAI shipped a new, proprietary base large language model (LLM), Grok 4.3, and a new voice cloning suite on the web.

The new products arrive after months of tumult from xAI that saw all of Musk's 10 original co-founders of the lab and dozens more researchers exit the firm and Grok was eclipsed on performance by many new competing LLMs from the likes of OpenAI, Anthropic, Google, and Chinese firms DeepSeek, Moonshot (Kimi), Alibaba (Qwen), z.ai, and others.

While Grok 4.3 does mark a significant leap in performance on third-party benchmarks over its direct predecessor Grok 4.2, according to the independent AI model evaluation firm Artificial Analysis, it still remains below the state-of-the-art set by OpenAI and Anthropic's latest models.

But the marquee feature of the Grok brand has — other than Musk's stated opposition to "wokeness" and its more freewheeling personality and image generation policy — increasingly been its low price point when accessed by developers and users via the xAI application programming interface (API), a trend only furthered by Grok 4.3, which costs $1.25 per million input tokens and $2.50 per million output tokens (up to 200,000 input tokens, at which point costs double, a common pricing strategy of leading AI labs) compared to its direct predecessor Grok 4.2's initial API pricing of $2/$6 per million input/output tokens.

According to xAI's release notes, Grok 4.3 began beta testing in April for subscribers to xAI's SuperGrok ($30 monthly) plan, and those of its sibling social network, X, through its Premium+ plan ($40 monthly with 50% for first two months). Now it's available to all through the xAI API and through partner OpenRouter.

Reasoning baked-in and agentic tool-use capabilities

At the core of Grok 4.3 is a fundamental shift in how the model processes information. Unlike previous iterations where "chain-of-thought" or reasoning could often be toggled or configured by effort levels, Grok 4.3 is built with reasoning as an active, permanent state.

This means the model is designed to "think" before it speaks for every query, a strategy intended to maximize factual accuracy and the handling of complex, multi-step instructions.

The model’s memory is equally expansive, featuring a 1 million-token context window. To put this in perspective, a million tokens is roughly equivalent to several thick novels or the entire codebase of a mid-sized application.

This allows Grok 4.3 to maintain coherence over massive datasets, though xAI has implemented a "Higher context pricing" structure for requests that exceed the 200,000-token threshold.

This tiering suggests that while the "long-term memory" is available, the computational cost of managing that much information remains a significant overhead.Technically, the model accepts both text and image inputs, outputting text.

It is specifically optimized for agentic workflows—scenarios where an AI is not just answering a question but acting as an autonomous agent to complete a task.

For the first time, Grok has access to the same tools and environments a human professional would use. Evidence of this shift is visible in early user interactions:

• Spreadsheet Engineering: In one instance, the model spent 6 minutes and 22 seconds in a "thought" phase to build a comprehensive OSRS Sailing Combat DPS analyzer. The resulting .xlsx file wasn't a simple table but a multi-sheet dashboard including a "Reference_Data" set and a complex "DPS_Calculator" with formulaic auto-calculations.

• Professional Documentation: Grok now generates formatted PDFs, such as 12-page reports on SpaceX products. These documents incorporate branding, logos, hero images, and structured tables, moving well beyond the markdown blocks of previous iterations.

• Visual Presentations: The model can design 9-slide PowerPoint decks, utilizing a "Sandwich Structure" (dark titles/conclusions with light content) and integrating data-driven decision matrices and humor.

However, its knowledge of the world is not infinite; the release notes list a knowledge cut-off date of December 2025. Yet, thanks to built-in web search, Grok can reference and use up-to-date information.

In fact, Grok 4.3 arrives with an enhanced ecosystem of tools designed to make it a functional digital employee. The xAI platform now offers a robust set of server-side tools that the model can invoke autonomously based on the complexity of the query.

• Web and X Search: These tools allow Grok to bypass its knowledge cutoff by browsing the live internet or searching X (formerly Twitter) posts, user profiles, and threads.

• Code Execution: The model can run Python code in a sandboxed environment to solve mathematical problems or process data.

• File and Collections Search: A built-in Retrieval-Augmented Generation (RAG) system allows users to query uploaded document collections or search through specific file attachments.

xAI's Custom Voices let you clone your voice at high quality in a minute or two

Beyond text, xAI has introduced Custom Voices, a sophisticated voice-cloning API and web-based voice cloning creation suite.

This product allows developers to clone a voice from a reference audio clip as short as 120 seconds. Once cloned, the "voice ID" can be used across xAI’s Text-to-Speech (TTS) and Voice Agent APIs.

xAI's documentation emphasizes that this is not merely about timbre; the model is designed to pick up delivery patterns.

If a user records a reference clip in a "customer support" style, the resulting AI voice will mimic that helpful, professional inflection.

Despite the creative potential, xAI has placed strict geographic limits on this feature, making it available only in the United States, with a notable exception for Illinois due to regional biometric and privacy regulations.

While the console playground is open for general use, programmatic access via the POST /v1/custom-voices endpoint is currently gated to teams on an Enterprise plan.

I tried it myself and after moving through the requisite voice sampling screens on the web — the tool asks you to read aloud several passages of unrelated dialog — I indeed had a copy of my voice that sounded eerily identical to mine and accurately pronounced new words the same way I would when reading allowed from a new script it was given.

You can delete your custom voices in one click on xAI's Custom Voices web application and create up to 30 new ones at a time.

In terms of licensing, the Custom Voices feature is strictly "scoped to your team" and is never made available to other users, ensuring a private, commercial license for corporate assets.

Access to the new Voice Agent API (grok-voice-think-fast-1.0) is billed at a flat rate of $3.00 per hour ($0.05 per minute) for speech-to-speech interactions. This is on the low-medium end of costs for other competing voice agents, according to my research:

Complementing this is the standalone Text-to-Speech (TTS) service, which offers five distinct voices (Eve, Ara, Rex, Sal, and Leo) and is priced at $4.20 per 1 million characters.

For transcription needs, the Speech-to-Text (STT) API provides real-time streaming at $0.20 per hour, while batch processing is available at a discounted rate of $0.10 per hour.

To ensure security for client-side applications, xAI utilizes Ephemeral Tokens, allowing for secure WebSocket connections without exposing primary API keys.

Once created, these voices are private to the user's team and can be used across all voice APIs by referencing a unique 8-character alphanumeric voice_id.

For highly regulated sectors, xAI maintains production-ready standards, including SOC 2 Type II auditing, HIPAA eligibility for healthcare workloads, and GDPR compliance.

Aggressively low API pricing as a differentiator

The most aggressive aspect of the Grok 4.3 announcement is its pricing structure. Bindu Reddy, CEO of enterprise assistant startup Abacus AI noted on X that the model is "as smart as Sonnet 4.6 and 5x cheaper and faster".

The standard API rates are set at $1.25 per million input tokens and $2.50 per million output tokens. This reflects a significant reduction in cost compared to its predecessor, Grok 4.20, with Artificial Analysis reporting an approximately 40% lower input price and 60% lower output price.

According to our calculations at VentureBeat, that places Grok-4.3 firmly in the lowest cost half of all major foundation models, far closer to Chinese open source offerings than its U.S. proprietary rivals:

However, the "reasoning" nature of the model introduces a new billing category: Reasoning tokens.

These are tokens generated during the model's internal thinking process and are billed at the same rate as standard completion tokens. Effectively, users pay for the AI to "think" before it provides the final answer. xAI has also introduced several unique fee structures:

• Prompt Caching: Repeated prompts are significantly cheaper, at $0.20 per million tokens, incentivizing developers to reuse context.

• Tool Invocations: While token usage for tools is billed at standard rates, the act of invoking a tool carries a flat fee—$5.00 per 1,000 calls for Web Search or Code Execution, and $10.00 for File Attachments.

• Usage Guideline Violation Fee: In a move that may set a new industry precedent, xAI charges a $0.05 fee for requests that are blocked by their safety filters before generation even begins.

The model itself remains accessible via a standard commercial API, with xAI recommending that all developers migrate to grok-4.3 as their "most intelligent and fastest model".

Third-party benchmark evaluations and analysis

The reception of Grok 4.3 has been polarized, depending largely on the specific use case. Professional benchmarkers and developers have highlighted a "stark gap" between the model's domain-specific strengths and its general reasoning consistency.

According to independent AI evaluation firm Vals AI, Grok 4.3 has taken the top spot on several specialized indices. It currently ranks #1 on CaseLaw v2 (79.3% accuracy) and #1 on CorpFin.

This 25-point jump in legal reasoning over Grok 4.20 suggests that the "always-on reasoning" architecture is particularly well-suited for the dense, logical structures of law and finance.

Artificial Analysis corroborated this performance, noting a massive improvement in agentic tasks, scoring an Elo of 1500 on the GDPval-AA benchmark, surpassing competitors like Gemini 3.1 Pro and GPT-5.4 mini.

Conversely, users focused on general-purpose agents and coding have highlighted deficiencies.

AI automated brick-and-mortar retail company Andon Labs reported that Grok 4.3 is a "big regression" on the Vending-Bench 2, which measures an AI's ability to take consistent actions in a simulation.

They colorfully described the model as having "narcolepsy problems," preferring to remain inactive for multiple simulation days rather than taking the required actions.

The sentiment was echoed by Vals AI, which noted that while the model improved in some coding areas, it remains weak on general coding tasks and "struggles with difficult math problems," scoring only 11% on ProofBench.

Should your enterprise use Grok 4.3?

The launch of Grok 4.3 represents a calculated bet by xAI that the market wants specialized brilliance and extreme cost efficiency over a perfectly balanced generalist.

By achieving a score of 53 on the Artificial Analysis Intelligence Index while remaining on the "Pareto frontier" of cost-per-intelligence, xAI is positioning itself as the "value" leader for enterprise applications in legal and financial tech.

The "always-on reasoning" is a double-edged sword. While it provides the depth needed to navigate complex case law, the community reports of "narcolepsy" suggest that a model that is always "thinking" may occasionally think itself into a state of paralysis, or at least a state of excessive caution that inhibits agentic action.

In addition, prior Grok model scandals including an X chatbot version referring to itself as "MechaHitler" and posting antisemitic content, sexualized deepfake imagery generation and investigations, and references to racial conflicts and right-wing dog whistle framing of social issues — which appear to mirror many of founder Musk's own positions, to the point that the model was at one point, checking Musk's own X account before responding in its X implementation — nearly certain to give some enterprises pause when considering adoption. It's unclear whether any of those issues remain with Grok 4.3, but one user did note that Grok's system prompt appears to instruct it "you do not assign broad positive/negative utility functions to groups of people."

For developers, the decision to adopt Grok 4.3 will likely come down to the nature of their data. For those needing to process a million tokens of legal documents at a fraction of the cost of Claude 4.6 or GPT-5.5, Grok 4.3 is a clear front-runner.

For those building high-frequency autonomous agents or complex math solvers, the "narcolepsy" and coding regressions suggest that xAI's latest model may still need a few more "tuning passes".

As OpenRouter noted on X upon making the model live, the "large jump in agentic performance" at a lower price point is an undeniable milestone. Whether that performance can be sustained across all domains remains the primary question for the summer of 2026.

Enterprise technology failures are largely invisible. Research from TeamViewer, based on a global survey of 4,200 managers and employees, finds that the majority of digital dysfunction never reaches the IT help desk.

Employees work around slow applications, failed logins, and intermittent glitches rather than reporting them, leaving organizations without an accurate picture of how their technology is performing. The cumulative cost is significant: employees lose an average of 1.3 workdays per month to digital friction, with impacts ranging from delayed projects and lost revenue to increased employee turnover.

The research, which surveyed managers and employees across nine countries, confirms what many have long suspected: the productivity loss from digital friction is significant, and most of it never surfaces in an IT support queue, says Andrew Hewitt, VP of strategic technology at TeamViewer.

“Enterprise outages are visible because they trigger clear, system-level failures,” Hewitt says. “But much of the real disruption happens earlier, in the form of digital friction: slow apps, login issues, or intermittent glitches that don’t cross alert thresholds. These smaller issues often go unreported or are normalized by employees, even though they quietly drain productivity.”

What is digital friction and why does it go unreported?

The most common sources of friction — connectivity failures, software crashes, hardware problems, and authentication issues — aren’t edge-case scenarios, but everyday experiences employees have learned to absorb without escalating. Connectivity problems were the most widespread, with nearly half identifying them as the top productivity killer among common technology issues.

That tendency to absorb rather than report is central to the problem. Many workers don’t trust their IT team to resolve issues quickly or effectively, so when a login fails or an application stalls mid-task, the path of least resistance is to restart the device, switch tools, or use a personal phone.

“Employees are under more pressure than ever to prove output,” Hewitt says. “When reporting feels unlikely to result in a quick resolution, it creates a false sense of stability at the system level while the employee experience quietly deteriorates.”

How much productivity does digital friction cost organizations?

The business consequences extend beyond inconvenience. Many organizations report delays in critical operations, revenue loss, and lost customers as a result of IT dysfunction. Most respondents lose time each month, and few expect improvement, citing increasing complexity of workplace technology as a primary concern.

The human cost runs parallel. Workers link digital friction to frustration, decreased motivation, and burnout, and many believe it contributes to turnover, with onboarding replacements stretching to eight weeks or more.

"Employees are happiest when they feel productive and accomplished at the end of the day," Hewitt says. "When people can't make progress in their day-to-day work, frustration builds and burnout follows. Great technology might not be a main attractor of talent, but bad technology can certainly play a role in driving it away."

Why employees use personal devices and unauthorized tools instead of reporting IT problems

When workplace technology consistently fails to meet employee needs, workers find alternatives, with a substantial share of respondents admitting to using personal devices or unauthorized applications as workarounds. That's the entry point for shadow IT, or the use of unapproved hardware, software, or cloud services outside IT's visibility and control. While employees turn to these tools simply to stay productive, they introduce security vulnerabilities, data leakage risks, and compliance gaps that IT teams may not discover until a breach occurs.

“Quite simply, it demonstrates that the IT environment is not meeting the employees’ needs,” Hewitt said. “While this helps maintain short-term productivity, it introduces significant risks and pushes work outside of IT’s visibility and control.”

TeamViewer ONE addresses this by combining remote connectivity with real-time endpoint monitoring, giving IT teams the ability to detect and resolve device and application issues before employees reach for an alternative. When the underlying environment is stable and support is fast, the impulse to work around it diminishes.

How fragmented IT infrastructure creates blind spots across devices, apps, and networks

Addressing digital friction at scale requires more than faster help desk response times. Traditional metrics such as mean time to resolution and ticket volume capture only a fraction of actual issues. A more complete picture requires measuring lost time, interrupted workflows, and employee sentiment across devices, applications, and network environments.

“Leaders need to move beyond measuring performance through IT tickets alone,” Hewitt said. “Performance should be viewed through the lens of employee experience and real-time digital workplace data.”

Fragmented infrastructure makes this difficult. When devices, applications, and networks operate in separate silos, IT teams struggle to trace root causes or identify systemic issues before they spread, often responding to symptoms rather than underlying problems.

TeamViewer ONE is designed to close that gap, integrating digital employee experience analytics, remote support, and device management into a single platform. Instead of piecing together signals from disconnected tools, IT teams get a consolidated view of endpoint health, application performance, and network conditions across the entire organization.

How organizations can shift from reactive IT support to proactive system monitoring

Achieving proactive IT is not a single-step transformation. Hewitt describes it as a progression: starting with endpoint management and security, building toward real-time visibility into the digital employee experience, and ultimately using automation and AI to resolve issues before they reach employees.

TeamViewer AI is built to support each stage of that progression, using continuous monitoring to surface anomalies and correlate signals across the digital environment, identifying patterns of poor experience before they escalate. When issues are detected, it suggests remediations, generates scripts to fix problems autonomously, and handles routine tasks such as common troubleshooting without requiring IT intervention, shifting the workload from reactive firefighting toward proactive oversight.

And while AI's effectiveness depends on the completeness of the data it works with, consolidating onto a platform like TeamViewer ONE removes that limitation by giving AI a complete, real-time data foundation to work from.

How system performance lays the foundation for productivity, retention, and competitive advantage

TeamViewer ONE isn't a wholesale replacement of existing IT infrastructure, but a unifying layer that connects insight with action, which enables organizations to ramp up productivity, improve retention, and ultimately realize a significant competitive advantage. It begins with visibility into what is actually causing friction across their environment. From there, leaders can use that data to prioritize fixes, and then scale remediation through automation as confidence and capability grow.

"Reducing digital friction isn't about overhauling everything at once," Hewitt said. "Leaders should start small, gain visibility into what's actually causing friction, fix the biggest pain points, then scale those improvements through automation and AI. Even incremental progress can make an impact on employee engagement and productivity."

Dig deeper: Fix it before they feel it from TeamViewer.

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.

To overcome this challenge, researchers at Alibaba introduced Hierarchical Decoupled Policy Optimization (HDPO), a reinforcement learning framework that trains agents to balance both execution efficiency and task accuracy. 

Metis, a multimodal model they trained using this framework, reduces redundant tool invocations from 98% to just 2% while establishing new state-of-the-art reasoning accuracy across key industry benchmarks. This framework helps create AI agents that are not trigger-happy and know when to abstain from using tools, enabling the development of responsive and cost-effective agentic systems.

The metacognitive deficit

Current agentic models face what the researchers call a “profound metacognitive deficit.” The models have a hard time deciding when to use their internal parametric knowledge versus when to query an external utility. As a result, they blindly invoke tools and APIs, like web search or code execution, even when the user's prompt already contains all the necessary information to resolve the task.

This trigger-happy tool-calling behavior creates severe operational hurdles for real-world applications. Because the models are trained to focus almost entirely on task completion, they are indifferent to latency. These agents frequently hit exorbitant tool call rates. Every unnecessary external API call introduces a serial processing bottleneck, turning a technically capable AI into a sluggish system that frustrates users and burns through tool budgets.

At the same time, burning computational resources on excessive tool use does not translate to better reasoning. Redundant tool interactions inject noise into the model’s context. This noise can distract the model, derailing an otherwise sound chain of reasoning and actively degrading the final output.

To address the latency and cost issues of blind tool invocation, previous reinforcement learning methods attempted to penalize excessive tool usage by combining task accuracy and execution efficiency into one reward signal. However, this entangled design creates an unsolvable optimization dilemma. If the efficiency penalty is too aggressive, the model becomes overly conservative and suppresses essential tool use, sacrificing correctness on arduous tasks. Conversely, if the penalty is mild, the optimization signal loses its value and does not prevent tool overuse on simpler tasks.

Furthermore, this shared reward creates semantic ambiguity, where an inaccurate trajectory with zero tool calls might yield the same reward as an accurate trajectory with excessive tool usage. Because the training signals for accuracy and efficiency become entangled, the model can’t learn to control tool-use without degrading its core reasoning capabilities.

Hierarchical decoupled policy optimization

To solve the optimization dilemma of coupled rewards, the researchers introduced HDPO. HDPO separates accuracy and efficiency into two independent optimization channels. The accuracy channel focuses on maximizing task correctness across all of the model's rollouts. The efficiency channel optimizes for execution economy.

HDPO computes the training signals for these two channels independently and only combines them at the final stage of loss computation. The efficiency signal is conditional upon the accuracy channel. This means that an incorrect response is never rewarded simply for being fast or using fewer tools. This decoupling avoids situations where accuracy and efficiency gradients cancel each other out, providing the AI with clean learning signals for both goals.

The most powerful emergent property of this decoupled design is that it creates an implicit cognitive curriculum. Early in training, when the model still struggles with the task, the optimization is dominated by the accuracy objective, forcing the model to prioritize learning correct reasoning and knowledge. As the model's reasoning capabilities mature and it consistently arrives at the right answers, the efficiency signal smoothly scales up. This mechanism causes the model to first master task resolution, and only then refine its self-reliance by avoiding redundant, costly API calls.

To complement HDPO, the researchers developed a rigorous, multi-stage data curation regime that tackles severe flaws found in existing tool-augmented datasets. Their data curation pipeline covers supervised fine-tuning (SFT) and reinforcement learning (RL) stages.

For the SFT phase, they sourced data from publicly available tool-augmented multimodal trajectories and filtered them to remove low-quality examples containing execution failures or feedback inconsistencies. They also aggressively filtered out any training sample that the base model could solve directly without tools. Finally, using Google's Gemini 3.1 Pro as an automated judge, they filtered the SFT corpus to only keep examples that demonstrated strategic tool use.

For the RL phase, the curation focused on ensuring a stable optimization signal. They filtered out prompts with corrupted visuals or semantic ambiguity. The HDPO algorithm relies on comparing correct and incorrect responses. If a task is trivially easy where the model always gets it right, or prohibitively hard where the model always fails, there is no meaningful mathematical variance to learn from. The team strictly retained only prompts that exhibited a non-trivial mix of successes and failures to guarantee an actionable gradient signal.

Metis agent: HDPO  in action

To test HDPO in action, the researchers used the framework to develop Metis, a multimodal reasoning agent equipped with coding and search tools. Metis is built on top of the Qwen3-VL-8B-Instruct vision-language model. The researchers trained it in two distinct stages. First, they applied SFT using their curated data to provide a cold-start initialization. Next, they applied RL using the HDPO framework, exposing the model to multi-turn interactions where it could invoke tools like Python code execution, text search, and image search.

The researchers pitted Metis against standard open-source vision models like LLaVA-OneVision, text-only reasoners, and state-of-the-art agentic models including DeepEyes V2 and the 30-billion-parameter Skywork-R1V4. The evaluation spanned two main areas: visual perception and document understanding datasets like HRBench and V*Bench, and rigorous mathematical and logical reasoning tasks like WeMath and MathVista.

On all tasks, Metis achieved state-of-the-art or highly competitive performance, outperforming existing agentic models — including the much larger 30-billion-parameter Skywork-R1V4 — across both visual perception and reasoning tasks.

Equally important is the anecdotal behavior Metis showed in the experiments. For example, when presented with an image of a museum sign and asked what the center text says, standard agentic models waste time blindly writing Python scripts to crop the image just to read it. Metis, however, recognizes that the text is clearly legible in the raw image. It skips the tools entirely and uses a single inference pass.

In another experiment, the model was given a complex chart and asked to identify the second-highest line at a specific data point within a tiny subplot. Metis recognized that fine-grained visual analysis exceeded its native resolution capabilities and could not accurately distinguish the overlapping lines. Instead of guessing from the full image, it invoked Python to crop and zoom in exclusively on that specific subplot region, allowing it to correctly identify the line. It treats code as a precision instrument deployed only when the visual evidence is genuinely ambiguous, not as a default fallback.

The researchers released Metis along with the code for HDPO under the permissive Apache 2.0 license.

“Our results demonstrate that strategic tool use and strong reasoning performance are not a trade-off; rather, eliminating noisy, redundant tool calls directly contributes to superior accuracy,” the researchers conclude. “More broadly, our work suggests a paradigm shift in tool-augmented learning: from merely teaching models how to execute tools, to cultivating the meta-cognitive wisdom of when to abstain from them.”

The tool aims to eliminate some of the biggest barriers and hurdles to training and using AI models today, namely, doing away with Docker packages and containerization when developing for serverless GPU infrastructure, which the company believes will speed up development and deployment of new AI models, applications and agentic workflows.

Additionally, the platform is built to serve as a critical substrate for AI agents and coding assistants—such as Claude Code, Cursor, and Cline—enabling them to orchestrate and deploy remote hardware autonomously with minimal friction.

Developers can utilize Flash to accomplish a diverse set of high-performance computing tasks, including cutting-edge deep learning research, model training, and fine-tuning.

"We make it as easy as possible to be able to bring together the cosmos of different AI tooling that's available in a function call," said Runpod chief technology officer (CTO) Brennen Smith, in a video call interview with VentureBeat last week.

The tool allows for the creation of sophisticated "polyglot" pipelines, where users can route data preprocessing to cost-effective CPU workers before automatically handing off the workload to high-end GPUs for inference.

Beyond research and development, Flash supports production-grade requirements through features such as low-latency load-balanced HTTP APIs, queue-based batch processing, and persistent multi-datacenter storage.

Eliminating the 'packaging tax' of AI development

The core value proposition of Flash GA is the removal of Docker from the serverless development cycle.

In traditional serverless GPU environments, a developer must containerize their code, manage a Dockerfile, build the image, and push it to a registry before a single line of logic can execute on a remote GPU. Runpod Flash treats this entire process as a "packaging tax" that slows down iteration cycles.

Under the hood, Flash utilizes a cross-platform build engine that enables a developer working on an M-series Mac to produce a Linux x86_64 artifact automatically.

This system identifies the local Python version, enforces binary wheels, and bundles dependencies into a deployable artifact that is mounted at runtime on Runpod’s serverless fleet.

This mounting strategy significantly reduces "cold starts"—the delay between a request and the execution of code—by avoiding the overhead of pulling and initializing massive container images for every deployment.

Furthermore, the technology infrastructure supporting Flash is built on a proprietary Software Defined Networking (SDN) and Content Delivery Network (CDN) stack.

Smith told VentureBeat that the hardest problems in GPU infrastructure are often not the GPUs themselves, but the networking and storage components that link them together.

"Everyone is talking about agentic AI, but the way I personally see it — and the way the leadership team at Runpod sees it — is that there needs to be a really good substrate and glue for these agents, whatever they might be powered by, to be able to work with," Smith said.

Flash leverages this low-latency substrate to handle service discovery and routing, enabling cross-endpoint function calls. This allows developers to build "polyglot" pipelines where, for instance, a cheap CPU endpoint handles data preprocessing before routing the clean data to a high-end NVIDIA H100 or B200 GPU for inference.

Four distinct workload architectures supported

While the Flash beta focused on live-test endpoints, the GA release introduces a suite of features designed for production-grade reliability.

The primary interface is the new @Endpoint decorator, which consolidates configuration—such as GPU type, worker scaling, and dependencies—directly into the code. The GA release defines four distinct architectural patterns for serverless workloads:

• Queue-based: Designed for asynchronous batch jobs where functions are decorated and run.

• Load-balanced: Tailored for low-latency HTTP APIs where multiple routes share a pool of workers without queue overhead.

• Custom Docker Images: A fallback for complex environments like vLLM or ComfyUI where a pre-built worker is already available.

• Existing Endpoints: Using Flash as a Python client to interact with previously deployed Runpod resources via their unique IDs.

A critical addition for production environments is the NetworkVolume object, which provides first-class support for persistent storage across multiple datacenters.

Files mounted at /runpod-volume/ allow for model weights and large datasets to be cached once and reused, further mitigating the impact of cold starts during scaling events.

Additionally, Runpod has introduced environment variable management that is excluded from the configuration hash, meaning developers can rotate API keys or toggle feature flags without triggering an entire endpoint rebuild.

To address the rise of AI-assisted development, Runpod has released specific skill packages for coding agents like Claude Code, Cursor, and Cline.

These packages provide agents with deep context regarding the Flash SDK, effectively reducing syntax hallucinations and allowing agents to write functional deployment code autonomously.

This move positions Flash not just as a tool for humans, but as the "substrate and glue" for the next generation of AI agents.

Why open source Runpod Flash?

Runpod has released the Flash SDK under the MIT License, one of the most permissive open-source licenses available.

This choice is a deliberate strategic move to maximize market share and developer adoption. In contrast to more restrictive licenses like the GPL (General Public License), which can impose "copyleft" requirements—potentially forcing companies to open-source their own proprietary code if it links to the library—the MIT license allows for unrestricted commercial use, modification, and distribution.

Smith explained this philosophy as a "motivating construct" for the company: "I prefer to win based on product quality and product innovation rather than legal ease and lawyers," he told VentureBeat.

By adopting a permissive license, Runpod lowers the barrier for enterprise adoption, as legal teams do not have to navigate the complexities of restrictive open-source compliance.

Furthermore, it invites the community to fork and improve the tool, which Runpod can then integrate back into the official release, fostering a collaborative ecosystem that accelerates the development of the platform.

Timing is everything: Runpod's growth and market positioning

The launch of Flash GA comes at a time of explosive growth for Runpod, which has surpassed $120 million in Annual Recurring Revenue (ARR) and serves a developer base of over 750,000 since it was founded in 2022.

The company’s growth is driven by two distinct segments: the "P90" enterprises—large-scale operations like Anthropic, OpenAI, and Perplexity—and the "sub-P90" independent researchers and students who represent the vast majority of the user base.

The platform’s agility was recently demonstrated during the release of DeepSeek V4 in preview last week. Within minutes of the model’s debut, developers were utilizing Runpod infrastructure to deploy and test the new architecture.

This "real-time" capability is a direct result of Runpod’s specialized focus on AI developers, offering over 30 GPU SKUs and billing by the millisecond to ensure that every dollar of spend results in maximum throughput.

Runpod's position as the "most cited AI cloud on GitHub" suggests that it has successfully captured the developer mindshare required to sustain its momentum.

With Flash GA, the company is attempting to transition from being a provider of raw compute to becoming the essential orchestration layer for the AI-first cloud.

As development shifts toward "intent-based" coding—where the outcome is prioritized over the execution details—tools that bridge the gap between local ideas and global scale will likely define the next era of computing.