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.

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 fo…

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.

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.

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:

1. The specialized, instruction-heavy role prompt (e.g., “You are a careful Reader. Use the retrieved passages to answer the user’s questions…”).

2. 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.”

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.

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.

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.

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.