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.

Writer, the enterprise AI agent platform used by Fortune 500 companies including Accenture, Uber, and Vanguard, released its new flagship model Palmyra X6 today, alongside a rebuilt agent orchestration “harness” and new governance tools designed to give IT leaders control over runaway token spending.

The headline numbers are striking: Writer says its agent product now operates at an average 52% lower cost, with a 48% improvement in speed and a 10% improvement in quality when paired with Palmyra X6. But the more consequential story may be how the company got there — and what its choices reveal about where the enterprise AI market is heading.

Palmyra X6 is not trained from scratch. It is a post-trained version of GLM-5.2, the open-weight mixture-of-experts model from Beijing-based Z.ai, formerly Zhipu AI — a fact Writer discloses openly in its technical report, and one that places the San Francisco company at the center of one of the industry’s most charged debates: whether American enterprises should build on Chinese open-source foundations.

“This model is in no way, shape, or form connected to any of its original developers. It is fully run on our U.S. infrastructure,” Matan-Paul Shetrit, Writer’s director of product management, told VentureBeat in an exclusive interview ahead of the announcement.

Dan Bikel, who leads Writer’s AI research, put it more bluntly: “It’s very much a Palmyra model, and we just happen to grab the floating point numbers as the starting point, and train from there.”

Why AI agents are blowing up enterprise budgets in ways chatbots never did

Writer’s announcement lands at a moment when the economics of agentic AI have moved to the center of enterprise buying decisions. Unlike a chatbot, which typically generates one answer per user request, an AI agent turns a single request into repeated rounds of planning, retrieval, tool calls, validation, and retries — with every loop consuming metered tokens. The user sees one answer; the invoice reflects the entire loop.

The scale of the problem is becoming clear. Goldman Sachs forecasts that token consumption will multiply 24 times between 2026 and 2030, reaching 120 quadrillion tokens per month, driven not by more people asking questions but by always-on enterprise agents. The same analysis warned that falling per-token prices do not guarantee falling bills: if an agentic task draws 20 times more tokens while unit prices fall 75%, total charges still rise fivefold.

“The enterprise wants token consumption to explode — it means adoption is happening — but they need costs to flatten,” said Waseem AlShikh, Writer’s CTO and co-founder, in a statement.

Shetrit framed the cost problem as the primary obstacle to enterprise AI adoption — more so than model capability itself. “The biggest barrier today to enterprise expansion using AI is actually not model capabilities in most cases; it’s actually the cost around them,” he said. “The reality today is, in most cases, the alternative for AI is not another AI, it is human labor.”

Asked whether cutting customers’ token consumption would cannibalize Writer’s own per-token revenue, Shetrit rejected the premise. “Reducing the cost is not hurting my bottom line. It’s actually expanding it, because it’s expanding the TAM of opportunity within an organization,” he said, arguing that lower per-task costs unlock workflows enterprises would otherwise never automate. That argument echoes a pattern familiar from the cloud era, where unit prices fell for a decade while total bills rose as consumption expanded — a dynamic Writer is explicitly betting will repeat with agents, and betting it can profit from.

Inside Palmyra X6: how 626 training examples fine-tuned a 744-billion-parameter model

Palmyra X6 is a 744-billion-parameter mixture-of-experts model with roughly 40 billion active parameters per token, inheriting GLM-5.2’s architecture unchanged, according to Writer’s technical report. The company’s contribution is a deliberately conservative post-training recipe: a technique called anchored supervised fine-tuning (ASFT), applied to a remarkably small corpus of just 626 curated synthetic agentic trajectories, trained for a single epoch at a low learning rate.

The tiny dataset is the point, not a limitation. ASFT pairs a token-weighting scheme with a KL-divergence “anchor” that penalizes the fine-tuned model for drifting too far from a frozen copy of the base model — teaching new tool-use behaviors without eroding the general capabilities the base already has. Writer also swapped the standard Adam optimizer for Muon, a newer method that treats weight matrices as geometric objects, on the model’s core weight matrices.

“There’s a whole string of papers following a quote-unquote ‘less is more'” philosophy, Bikel said, referencing research showing that “small, extremely high quality data sets go a really long way.” He added: “That’s the philosophy — one of the philosophies — that we followed when building this model, and it showed. It allowed us to optimize for our customers at lower cost to do the work of optimization, and that ultimately yielded a lower cost model for us and for them.”

The training data itself is fully synthetic — every plan, tool call, and final answer machine-generated by teacher models, then filtered through structural quality gates, a model-based verifier, and a two-model LLM judging panel before entering training. That continues a long-standing Writer practice: the company’s Palmyra X 004 was trained almost entirely on synthetic data for roughly $700,000 back in 2024, as TechCrunch reporte at the time, and Palmyra X5 required about $1 million in GPU hours, according to SiliconANGLE.

On Writer’s internal evaluations — nine capabilities spanning grounding and retrieval, tool use, content generation, sub-agent delegation, and brand voice — X6 scored an average of 0.87 out of 1.00, edging out Anthropic’s Claude Opus 4.8 (0.86), Claude Sonnet 4.6 (0.85), OpenAI’s GPT-5.5 (0.80), and Google’s Gemini 3.1 (0.77). The price gap is the real differentiator: Writer prices X6 at $2 per million input tokens and $8 per million output tokens, versus 15/75 for Opus 4.8. The company says X6 completes tasks in 26 seconds on average and can work unattended toward a single goal for up to eight hours.

Writer is candid that internal benchmarks invite skepticism. Asked directly whether the company would publish its methodology after grading its own homework, Bikel said the technical report covers “both the protocol we used to do our public benchmarking as well as our internal evaluations.” He described public benchmarks as sanity checks rather than targets: “We do things like public benchmarks to let us know that we’re climbing the right hill and that we don’t have any sort of huge gaps, but we don’t slavishly follow them either, because that’s not really serving our customers.”

The China question: what building on GLM-5.2 means for enterprise security and trust

Writer’s choice of base model would have been unthinkable for an American enterprise vendor two years ago. Today it reflects a market reality: GLM-5.2, released in June under the permissive MIT license, is arguably the most capable openly available model in the world. Independent analysis house Artificial Analysis scored it at 51 on its Intelligence Index — ahead of DeepSeek V4 Pro, Kimi K2.6, and even some of Google’s Gemini models on agentic tasks — while undercutting U.S. flagship API pricing many times over, as European tech outlet Trending Topics reported. Writer’s press release calls it “the strongest available open-weight model.”

The open-weight surge carries genuine baggage. An August report from AI safety nonprofit SaferAI found that GLM-5.2 refused none of the offensive cyber or biology tasks it was given via Z.ai’s public API, and that Z.ai published no safety framework or pre-deployment risk assessment — a gap that widens once anyone can download and modify the weights.

Writer’s answer is that provenance and post-training matter more than origin. Bikel emphasized that the company “grabbed the weights off of the U.S. Hugging Face” and trained entirely on American infrastructure; the technical report states all datasets were synthesized and stored in the U.S., and all training hardware was located in the U.S.

The company also ran what it describes as an unusually rigorous, pre-registered model-risk evaluation covering political bias, censorship, factuality, and refusal behavior — 19,674 evaluated responses scored by blinded judges — comparing X6 against its GLM-5.2 base and four frontier control models.

On the Washington Post’s ModelSlant political-bias evaluation, Writer says X6 presented both sides of hot-button questions 80% of the time, the highest rate of any model tested, and answered politically sensitive prompts that DeepSeek V4 refused outright. On the FORTRESS adversarial safety benchmark, X6 with its deployment system message scored 8.6 points higher on adversarial safety than the raw GLM-5.2 base, at negligible cost to benign helpfulness.

“We’ve run extensive benchmarking around bias, around censorship,” Shetrit said, “and the work Dan and the team has done has actually proven that this model is actually significantly better than not just open source alternatives, but any closed source alternative in the market at the time of the benchmarking.” 

The report does hedge in one notable place: while English-language behavior showed no statistically robust political asymmetry, “the behavior was shown to vary by language” — a candid admission that 626 fine-tuning trajectories do not scrub every trace of a base model’s training.

The harness effect: why orchestration may matter more than the model itself

Perhaps the most strategically interesting claim in Writer’s announcement has nothing to do with Palmyra X6 at all. The company says its rebuilt Writer Agent harness — the orchestration layer that plans tasks, batches work, delegates to sub-agents, and manages context — cuts costs by 41% and completes tasks 44% faster across every model it tested, including third-party models from Anthropic and OpenAI, while maintaining quality. Writer published the finding in an accompanying research paper on what it calls “The Harness Effect.”

That raises an obvious question, which VentureBeat put to the company: if the harness alone delivers most of the savings on any model, why build a model at all?

Shetrit’s answer was about control. “I cannot control if a lab deprecates their model. I cannot control what data they use in their model,” he said. “Where when I build the model, I have significant moral control, and I can answer the tough questions that enterprise customers ask me.”

Bikel added that the model and harness were developed together: “This model was built and essentially co-evolved with the harness… We know that we have a flagship product, Writer Agent. We want that to work really, really well with this model, and sure enough, it does. And we take that into account during model development, and that’s something that is not possible if you don’t build your own model.”

Notably, Writer is simultaneously hedging. With this release, the company extends multi-model support to Writer Agent, letting admins enable models from Anthropic, OpenAI, and cloud providers including Microsoft Azure, AWS Bedrock, and Nvidia NIM — even image-generation models, a category Writer does not build. The message to CIOs is disarmingly simple: use our model because it is cheapest and best for your workflows, but the platform saves you money either way.

New governance tools aim to end surprise AI bills before they start

The third leg of the release targets a quieter enterprise pain point: nobody in the C-suite knows what the agents are spending. New governance tools give administrators a centralized view of agent usage across the business, per-workflow analytics for the company’s shareable “Playbooks” and “Skills” automations, and consumption controls with alerts and spending limits.

Asked whether the introduction of spending controls implied that customers had been receiving surprise bills, Shetrit reframed it as an adoption enabler rather than damage control. “How do we build the tools to allow you as the CIO, CISO in a company, to feel comfortable both on the security and spend, so you can expand AI usage in your organization,” he said. In his telling, visibility is what lets leaders say yes: businesses with clear cost data “are actually looking to expand AI adoption to use cases that they would never have touched before.”

The feature set tracks a broader shift in how enterprises budget for AI. As Forbes analysis of the token price wars argued, sophisticated buyers are learning to model cost per successful task — counting retries, tool calls, and escalations — rather than multiplying expected calls by the advertised rate card. Writer is effectively productizing that discipline, turning what has been a finance-team spreadsheet exercise into a native platform capability.

It also completes a governance arc the company has been building for over a year. Writer shipped its unified agent experience with admin controls last November, then added agent Skills and workflow analytics in March, according to earlier company announcements. Thursday’s release closes the loop by attaching a price tag — and a spending limit — to every workflow.

Writer, founded in 2020 by May Habib and Waseem AlShikh, raised $200 million at a $1.9 billion valuation in late 2024, and has built its business on regulated, high-stakes deployments rather than consumer scale. Shetrit made no apology for the narrowness of that focus. “The privilege of working and focusing on enterprise use cases is that I don’t need my model to be able to write a French sonnet,” he said. “When you don’t try to do everything, you can focus on your customer problem and needs.”

He was equally direct about identity: “We are not a research lab converted to a consumer product now dabbling in enterprise. We are first and foremost an enterprise company that serves enterprise customers, and we evaluate our decisions within that lens. Which means, if we think building things from scratch is the right decision, that’s what we will do. But if we think there are other alternatives out there in the market that serve our customers better, that’s what we will do.”

That pragmatism may be the release’s most important signal. A well-capitalized American AI company with five years of model-building experience has concluded that the frontier of value no longer lies in pretraining, but in the last mile: post-training open weights, engineering the harness around them, and handing the CFO a dashboard. If Writer is right, the frontier labs’ moat narrows to the workloads where quality genuinely justifies a sevenfold price premium — and for everything else, the winning model is the one somebody else paid to pretrain.

In an industry that has spent three years arguing about whose model is smartest, Writer is making a different wager: the enterprise AI race won’t be won by the company with the best floating point numbers, but by the one that knows what to do with them.

SpaceXAI, the division of SpaceX formerly known as xAI, is launching an early beta version of Grok Bot, a new agent designed to move AI assistants beyond answering prompts and toward continuously executing work across the software employees already use.

The central idea is straightforward: instead of opening an AI assistant whenever a task arises, users create persistent Bots with specific jobs, give them access to applications and websites, and delegate work much as they would to a teammate.

Each Bot operates through its own computer environment, can continue working when the user’s laptop is closed, and can return when it needs approval or has finished the assignment.

SpaceXAI says the system began as an internal prototype before spreading across the company, where teams created Bots for sales outbound, marketing campaigns, office operations, bug fixes and other work. The company is now turning that internally developed workflow into a product for external users.

“Bots are AI teammates that do real work for you,” the company said in announcing the product. “They sign in to your tools, use them just like you do, and come back with finished work.”

The company did not release benchmarks for Grok Bot’s performance on agentic tasks. And it arrives amid an increasingly crowded marketplace of first-party AI agents that attempt to reliably complete real, enterprise workflows by interfacing with a user’s other applications and devices.

Anthropic introduced computer use for Claude in 2024, allowing models to inspect screens and operate interfaces through mouse and keyboard actions, and continued expanding with the launch of the developer focused Claude Code harness in early 2025 and the more non-technical, white collar focused Claude Cowork agent early this year.

Meanwhile, OpenAI gave its Codex harness the ability to control other computer apps in April, launched agentic Workspace Agents that can also connect to third-party applications and use them autonomously, and recently debuted a new ChatGPT Work environment for longer, multi-step tasks and finished deliverables.

Grok Bot seeks to join the party with its own management model for agents: persistent workers with responsibilities, memory, learned routines and the ability to hand work to one another.

Pricing and availability: Grok Bot starts at $120 per seat per month for teams, $200 per month for individuals

Grok Bot is available beginning today, August 11 in beta for SuperGrok Heavy, Cursor Ultra and Cursor Premium Teams subscribers (recall SpaceX acquired Cursor for $60 billion back in June). The product arrives for macOS, Windows, Linux and iOS, with Android listed as coming soon.

According to its product page on xAI.com, Grok Bot is included with Cursor Ultra at $200 per month for individuals. The plan includes a computer for Grok Bot, access to users’ tools, scheduled routines, desktop and mobile operation, and extended AI-token limits.

For organizations, Cursor Premium Teams costs $120 per seat per month and adds centralized billing and settings, a team marketplace for skills and plugins, shared usage analytics and SAML/OIDC single sign-on.

Existing SuperGrok Heavy ($300 per month) subscribers also receive access. However, for organizations wishing to sign up today, SpaceXAI is directing them to a waitlist for future access.

Those prices make Grok Bot a substantially different purchasing decision from a low-cost general AI subscription. The economic question for companies will be whether persistent Bots can replace enough manual work or conventional automation infrastructure to justify the per-user cost — and how usage limits affect total cost once agents begin running continuously.

From prompting an AI to managing one

SpaceXAI describes Grok Bot as a team of “always-on agents.” Users can create multiple Bots, assign each a role and let them work simultaneously.

The company provides examples including Sales Outbound, Talent Scout, Paid Media, Expense Manager, Product Performance, Bug Reproduction, Account Health and Chief of Staff. A sales Bot, for example, can research accounts, score prospective contacts, prepare email and LinkedIn outreach in the user’s voice, and assemble the results for human approval.

Promotional materials show SpaceXAI using the system internally for substantially longer chains of work. One sales Bot can add call-transcript notes to a CRM and draft follow-up messages. An operations Bot can seat new hires and process invoices arriving through Gmail. An engineering Bot can reproduce a bug in the product interface, file a ticket and then hand the repair to a debugging Bot.

The architecture could make Grok Bot particularly relevant for workflows that span systems that were never designed for AI automation.

Rather than requiring every application to expose an API specifically for an agent, Grok Bot can sign into applications and websites and operate their interfaces. SpaceXAI says Bots have their own computers and can continue working 24/7.

The company explicitly says this includes websites and applications that have “no clean API or MCP,” an important distinction for enterprises with legacy software, fragmented SaaS environments or internal systems that have never been instrumented for agent access. Instead of limiting automation to formally integrated services, Grok Bot is designed to work through the same software interfaces a human employee would use.

The company says early users are already applying Bots to jobs including vendor negotiations, e-commerce customer support and continuously updating CRM systems.

Another feature attempts to reduce the engineering required to automate repeatable business processes. Users can demonstrate a workflow while a Bot follows along. Grok Bot can then save the process as a routine and execute it later without requiring the user to reproduce every instruction.

SpaceXAI says the Bot can also incorporate corrections into those learned routines, allowing the workflow to change as the user teaches it how a particular process should be handled.

That potentially changes the deployment model from explicitly programming an automation to teaching an agent how an employee performs the job.

The company is also claiming a more persistent form of behavioral memory than simply retaining a chat transcript. According to the launch announcement, Bots remember prior conversations, learn preferences such as a user’s writing voice and edge cases, and gradually learn when they should interrupt for approval versus continue independently. SpaceXAI says they can later resume dropped threads, nudge stalled handoffs and pick up work from earlier conversations.

It further says Bots can become proactive over time, sometimes identifying work before the user explicitly asks for it. That is a more ambitious claim than conventional scheduled automation and will put additional pressure on permission controls and escalation rules if the system is deployed against production applications.

Bots can delegate work to other Bots

Grok Bot also supports multiple agents operating together.

Users can place several Bots into the same thread, where the agents can pass work between one another. The company’s demonstration includes specialized Research, Communications, Chief of Staff and Travel Bots coordinating tasks.

SpaceXAI says those Bots can independently message one another and share context within threads. Users can also put multiple Bots into a group conversation where they assign ownership, transfer work and coordinate among themselves, bringing the human back in primarily for judgment calls.

Internally, the company says employees sometimes place a Chief of Staff Bot above specialist Bots responsible for functions such as inbox management, recruiting, expenses, operations and bug fixes. That makes the product’s orchestration model more explicit: the user does not necessarily have to serve as the routing layer between every specialized agent.

Initial reactions are extremely positive

Lenny Rachitsky, host of the popular vlog and podcast Lenny’s Podcast and author of newsletter Lenny Letter, received early access to Grok Bot and loved using it. As Rachitsy wrote on X : “I haven’t been this excited about a new AI product in a while. It’s like OpenClaw, but super easy, reliable, and less scary to use. I think this will be a huge new product line for Cursor/Grok/SpaceX.”

Similarly Matt Shumer, an AI entrepreneur who said he tested Grok Bot for several weeks before launch, highlighted this orchestration as one of the product’s strongest features.

“The best way I can describe it is an agent for everything, not just code,” Shumer wrote on X.

In one test, Shumer said he created separate researcher and writer Bots, then created a Chief of Staff Bot and instructed it to coordinate the other two on a project. He expected the workflow to break down.

“It worked out of the box,” he wrote.

His main criticism involved model selection.

Unlike systems where developers or advanced users explicitly select the underlying model, Shumer said Grok Bot automatically routes tasks to models on the backend.

“You don’t choose a model for your Grok Bot,” he wrote. “It’s all done automatically on the backend.”

Shumer said the model router “wasn’t great” during his testing, although he said he was subsequently told it had improved.

SpaceXAI’s expanded announcement still does not identify which underlying models the router uses, nor does it document a mechanism for users to select, pin or switch to a particular xAI or third-party model. As a result, the model layer remains largely abstracted from users in the publicly supplied launch material.

That abstraction represents an important tradeoff for enterprise deployments. Automatic routing can remove a significant configuration decision for ordinary employees, but advanced users may want explicit control over model cost, latency, reliability and behavior — particularly for repeatable production workflows.

The agent market is moving toward longer-running work

Grok Bot enters a market increasingly focused on agents that can do more than generate text or code.

Anthropic’s computer-use capability established a mechanism for Claude models to interact with software through screenshots, cursor movements, clicks and typing. Its broader Claude product also connects with workplace services and remote MCP servers.

OpenAI, meanwhile, now describes ChatGPT Work as an agent for “longer, multi-step work and finished deliverables,” while keeping Codex focused specifically on software development. OpenAI’s enterprise agent economics can also incorporate usage-based credits, making task complexity and token consumption part of deployment cost calculations.

Grok Bot’s differentiation is therefore less about proving that AI can operate software than packaging computer use, persistence, workflow learning and multi-agent coordination into something resembling a workforce interface.

SpaceXAI’s announcement sharpens that distinction by emphasizing completion rather than assistance. One company product employee, identified only as Roman, describes the difference as closing the gap between work that is nearly finished and work actually completed inside the destination application: “Grok Bot can finish the swing, because the work lands where a human would put it, in the actual tool.”

That distinction will ultimately depend on reliability. A chatbot producing a bad answer creates a correction problem. An autonomous agent operating CRM records, support queues, vendor conversations or other production systems can create an operational problem.

Grok Bot’s success will therefore depend not only on model intelligence, but also on permissions, predictable execution, escalation behavior, memory accuracy and how reliably agents recognize when human approval is necessary.

That challenge becomes more significant if Bots act proactively, resume forgotten work and coordinate with one another without the user serving as an intermediary. Those capabilities reduce the amount of supervision required when they work correctly, but they also expand the consequences of an incorrect assumption, stale context or improperly scoped permission.

The interface may matter as much as the models

Shumer described the product’s interface as feeling like iMessage, an intentionally familiar metaphor for a system whose underlying architecture — autonomous computers, persistent memory, agent orchestration and automatic model routing — could otherwise be difficult for nontechnical users to configure.

SpaceXAI makes essentially the same usability argument in its launch announcement. Rather than asking users to construct workflows before getting started, it says users can simply message a Bot from a phone or desktop, hand it work and later continue the same conversation from either device.

That simplicity is part of the product strategy. Grok Bot is trying to hide much of the conventional machinery of automation — workflow builders, explicit integrations, agent routing and orchestration — behind an interaction model that resembles messaging a coworker.

That may prove to be the larger bet behind Grok Bot.

The AI industry has spent several years making models increasingly capable of using tools and completing multi-step tasks. Grok Bot attempts to turn those capabilities into an organizational abstraction people already understand: give someone a job, teach them how you work, and let them coordinate with the rest of the team.

If that abstraction proves reliable, the enterprise agent competition may increasingly shift away from which assistant produces the best individual response and toward which platform can most reliably manage fleets of agents performing ongoing work.

Enterprises running always-on AI agents keep hitting the same tradeoff. Send every task to a frontier model and the bill climbs fast. Build custom routing logic to send easy tasks to cheaper models and that becomes its own engineering project, one that has to be maintained every time a workflow changes.

Nvidia is proposing a fix that touches both ends of that problem at once. The company is out on Tuesday with Nemotron 3.5 Lightning, a 30-billion-parameter open mixture-of-experts model built for high-volume, specialized agent tasks, alongside NeMo Switchyard, an open-source library that routes each step of an agent workflow to whichever model fits it best.

The headline numbers: According to Nvidia, Lightning delivers up to 4x faster output than comparable models in its class, completing agentic tasks roughly 30% faster than Qwen3.6-35B at matching accuracy. Paired through Switchyard, Nvidia says the combination holds frontier-level task completion while cutting benchmark costs to roughly a third of running Opus 4.8 alone.

The timing puts Nvidia in the middle of the busiest open-weight stretch the industry has seen in months. Alibaba, Moonshot, Zhipu and DeepSeek have all shipped competitive open models out of China since the spring, several landing at or near frontier performance while undercutting US labs on size or price. Meta added to that pressure by releasing its own 30-billion-parameter open agentic model, Muse Glimmer. Open weights have gone from a differentiator to table stakes in a matter of months, and Nvidia’s release lands squarely inside that shift rather than ahead of it.

The pairing is the point. A model alone doesn’t solve the cost problem, and a router alone has nothing efficient to route to. Nvidia is betting that open source, applied at both the model layer and the routing layer, is what actually moves the cost needle on agentic AI, not a single cheaper model and not a smarter router bolted onto someone else’s stack.

Switchyard’s real rivals aren’t other open models — they’re Not Diamond, which already powers OpenRouter’s Auto mode, and RouteLLM, the open-source framework from UC Berkeley and LMSYS. Neither ships its own model. Nvidia’s bet is that owning both sides of the decision, under one open license, is what a router-only or model-only competitor can’t match.

“That is the power of a system of models, matching the right model to each step of the workflow,” Kari Briski, vice president of generative AI at Nvidia, said in a briefing.

How the router actually changes the workflow

Model routing isn’t a new category. OpenRouter, LiteLLM and a handful of standalone routing startups already let developers point traffic across multiple providers. Switchyard plugs into several of them rather than replacing them outright.

The core problem Switchyard solves is that the right model changes as an agent moves through a task. An agent’s state shifts as tools return results, errors show up, or a step turns out to be routine rather than complex, and a fixed model choice can’t adapt to any of that.

Briski described routing strategies that respond to that shifting state rather than a static task category.

“It has many types of routing strategies,” Briski said. “You can have a random router, which is not that great, or you can have an agent state route or a classifier route. Depending on your routing strategy, it wants to choose the best model. In some cases you want to go with a model like Lightning for really efficient tasks, and the router will actually choose Lightning if it’s set up in your pool of models.”

Cost enters the routing decision directly, not as an afterthought. In response to a question from VentureBeat, Briski said Switchyard can evaluate model verbosity, meaning how many tokens a given model tends to produce for a task, and use that prediction to steer work toward the cheaper option before the call is made.

The part that keeps this from becoming its own integration project is where Switchyard sits. Nvidia split its partners into two groups: agent frameworks that call Switchyard directly, including Cognition, LangChain and Nous Research, and LLM gateways that have built Switchyard support into their own products, including Kong, LiteLLM and OpenRouter. Kong ships Switchyard natively inside Kong AI Gateway. Briski pointed to that same list of gateway partners when describing how the library fits into the existing routing ecosystem.

“We are an ecosystem lover, and we want to make sure that we are integrated,” Briski said. “We’ve partnered with OpenRouter, LiteLLM and Kong, and they’ve already integrated our routing algorithm, so you can pick it up right where you’re already using the best tools.”

Nvidia shared results from nine companies testing Switchyard, several with specific figures attached. LangChain reported a 74% cost reduction across 145 multi-turn Deep Agents tasks by routing just 7% of calls to a frontier model, at a 6% accuracy tradeoff. Ramp said it matched a frontier model’s performance on Ramp SWE-Bench while cutting costs 58% and runtime 33%. Cognition integrated Switchyard’s staged router into Devin Desktop for internal use and reported near-frontier performance on FrontierCode Main while cutting mean cost 28% relative to routing everything to a single frontier model.

Lightning’s architecture and performance gains

Nemotron 3.5 Lightning is a standalone open model in its own right, built for high-volume, specialized agent tasks rather than general-purpose use.

It extends the hybrid Mamba-Transformer, latent mixture-of-experts architecture Nvidia introduced with the Nemotron 3 family in December 2025, the same line behind Nemotron 3 Super, which Nvidia uses as Lightning’s own baseline in its post-training comparisons. Positioned within a routing setup like Switchyard, it’s built to sit at the fast, cheap end of the decision rather than the frontier end, but it runs and ships independent of any router.

According to the Artificial Analysis Intelligence Index, a general capability benchmark spanning nine evaluations, Lightning scores 24, tied with gpt-oss-120b and behind Nemotron 3 Super, Gemma 4 31B, Claude 4.5 Haiku and Mistral Medium 3.5, all at 30. Lightning isn’t a general-intelligence leader in its size class, and Nvidia isn’t claiming it is.

The actual claim is narrower: according to PinchBench data supplied by Nvidia, Lightning matches Qwen3.6-35B’s accuracy roughly 30% faster and beats Gemma 4 26B’s accuracy at a similar completion time on PinchBench, a real-world agent task benchmark spanning coding, research and file management. That’s a speed-to-accuracy tradeoff, not a capability win.

Post-training is where Nvidia says the bigger gains show up. The company shared before-and-after figures from four early-access partners: CrowdStrike’s malicious-content recall against a Nemotron 3 Super baseline, CodeRabbit’s coding router against a GPT 5.4 Nano baseline, Harvey and Trajectory’s legal task completion against an Opus 4.6 baseline, and Lila Sciences’ energy simulation work against an Opus 4.8 baseline. CodeRabbit’s case is the most specific: Nvidia says the standard NeMo Auto model recipe, trained for one epoch, built into a working router agent for $85 in about two hours.

What this means for enterprises

There is no shortage of competitive offerings in the growing market for open models. The new Nemotron Lightning release will be yet another option for organizations to consider.

On the model side, Lightning’s own benchmark chart picks Qwen3.6-35B as its direct comparison point. Asked by VentureBeat directly how Lightning compares to Chinese models more broadly, Briski didn’t offer a head-to-head benchmark, pointing instead to openness and customizability as the differentiator.

“Our value proposition is not just open and it’s very customizable,” Briski said.

For enterprises building agentic infrastructure, three trends stand out:

The routing decision is becoming dynamic instead of static. Enterprises that built agent pipelines around a single default model are being pushed toward per-step routing based on live signals like agent state and token cost, not a fixed assignment set at design time.

Open source is now a cost lever at two layers, not one. Pairing an open model with an open router a vendor controls end to end is a newer argument than cheaper weights alone, and worth watching for whether other labs follow the same pattern.

The competitive question shifts from best model to best system. As routing libraries mature, the differentiator moves from which model an enterprise defaults to, toward how well its routing layer matches models to tasks in production, a harder thing to benchmark and a harder thing to market.

As enterprise codebases grow, AI agents tasked with analyzing them are buckling under the weight of long-horizon tasks that require multiple interactions and tool calls. Dividing the work among a team of agents seems like the obvious fix, but it introduces a fatal flaw: most multi-agent systems are not designed for agents to coordinate among themselves mid-task and in real time.

To solve this, researchers at Coral AI Labs and multiple universities introduced AgentRadio, an asynchronous message-passing layer that allows agents to communicate between their execution steps without interrupting their main work. In real-world enterprise applications where subtasks are highly interdependent, this architecture enables agents to make mid-course corrections rather than continue on dead-end paths until a formal review phase.

On a benchmark of long-horizon questions over production repositories, a team of agents powered by AgentRadio nearly doubled task accuracy for four Claude Code agents working independently. It also outmatched single agents running on more advanced models. For AI practitioners, AgentRadio shows that the right coordination structure can outmatch raw compute and model scale.

The challenge of codebase understanding

LLM-based agents are increasingly capable of handling long-horizon tasks that require interacting with different tools and environments. Codebase understanding represents an extreme version of this challenge. It requires an AI agent to build the software, execute it, trace execution paths across multiple files, and synthesize evidence over extended periods.

Under these conditions, single-agent systems usually break down because of a “coverage problem.” 

“A single agent follows one serial path through the repository,” Xinxing Ren, Caelum Forder, and Peter Carroll, co-authors of the AgentRadio paper, explained to VentureBeat. As its context grows, “the initial plan becomes harder to revise and discoveries made late in the investigation do not always propagate.” The model can usually execute individual steps, but “the hard part is keeping every obligation, dependency, and piece of contradictory evidence active across a long investigation.”

One benchmark that helps measure AI performance on large codebases is SWE-Atlas QnA. This benchmark consists of long-horizon, natural-language questions over live production repositories. The tasks can’t be solved by just exploring the code. AI agents must run the software and execute multiple commands to find the answers.

According to the research team’s experiments, a single Claude Code instance running on Opus 4.6 resolves just 32.3% of these tasks. Upgrading to a newer, more advanced model like Opus 4.8 only yields a 57.2% success rate.

A natural remedy is to distribute the workload across multiple agents, allowing each to work with a smaller, cleaner context. Multi-agent solutions can provide substantial performance gains when tasks are cleanly decomposable, meaning they can be solved separately and merged at the end.

Codebase understanding, however, is rarely cleanly decomposable. The subtasks are highly interdependent. A critical configuration file or a bug uncovered by one agent can completely rewrite or redirect the entire exploration path of another agent. Because of these dependencies, agents must coordinate, negotiate, and share intermediate discoveries in real time.

Despite this need, asynchronous multi-agent communication is rare. The researchers point out that existing multi-agent systems generally fall into three flawed patterns:

• Parallel but isolated: Agents operate simultaneously but do not communicate at all.

• Parallel but round-synchronized: Agents can communicate, but only at strict, synchronized round boundaries. This forces agents to stop and wait for one another to finish a round before they can debate or exchange intermediate findings. Round-based systems assume that important discoveries can wait until the next communication phase, which is an expensive assumption when agents are working on interdependent parts of a live system. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent’s current hypothesis. “If that information waits until both agents finish, the storage investigation may complete along the wrong path,” the researchers said.

• Asynchrony in adjacent forms: These systems offer limited asynchronous features, such as top-down task dispatching. They don’t have peer-to-peer lateral channels between agents or shared memories that require an agent to actively pause its work to read updates.

In their paper, the researchers point out that the main bottleneck hindering current multi-agent systems is that “an agent that is working cannot also be listening.”

“To our knowledge, no existing system gives concurrently working agents passive awareness of one another over a lateral, natural-language channel,” the researchers write.

How AgentRadio works

To dissolve the mutual exclusion between working and listening, the researchers developed AgentRadio, an asynchronous message-passing layer designed to plug directly into existing coding-agent harnesses.

AgentRadio equips agents with three primitives:

• The create_thread primitive opens a conversation between participating agents.

• The send_message primitive appends a message to a thread and returns without blocking the sending agent.

• The wait_for_mention primitive blocks the process until a message mentioning the caller arrives. It delivers the message along with a full snapshot of all threads so the agent has instant context. 

This trio enables agents to have a state of “passive awareness,” where they can continue their primary tasks while passing messages and updating their knowledge in the background.

AgentRadio’s code is available under the Apache 2.0 license on GitHub. It is designed to be lightweight, requiring no direct modifications to the underlying agent harnesses like Claude Code or Codex CLI. 

The architecture consists of two main parts:

• The message server: A standalone process that acts as the central hub, storing all active threads, messages, and mentions for the group of agents.

• Harness-side integration: Agents interact with the server using three simple shell scripts, one corresponding to each primitive.

The only strict requirement for the system to work is that the agent harness must be able to run a shell command as a background task. The agents are instructed in their system prompts to keep one watcher running and to send messages through the provided scripts. Running the wait_for_mention script in the background allows the agent to continue its work and receive notifications asynchronously.

To integrate this into an existing stack, a team still needs a “thin adapter that starts the workers, assigns identities, connects them to the shared server, and manages final synthesis,” the researchers said. That work sits around the coding agent rather than requiring changes to the underlying model.

AgentRadio in action

To validate the real-world utility of AgentRadio, the researchers tested the framework on 124 tasks from the SWE-Atlas QnA benchmark. The tests covered domains including system design, root-cause analysis, security, and API integration.

The researchers used Claude Opus 4.6 and DeepSeek V4 Pro as the backbone models. For the harness, they evaluated configurations ranging from a single Claude Code agent (B0) to a team of agents with classic division of labor (L1), up to a team of agents using AgentRadio to coordinate asynchronously (L3).

The experimental results showed that the AgentRadio communication architecture outperforms both naive multi-agent setups and raw compute scaling.

While a single Claude Code agent with Opus 4.6 resolved only 32.3% of the tasks, the full AgentRadio setup nearly doubled that metric, resolving 62.1% of the tasks, and surpassed the single agent running on Opus 4.8, which hit 57.2%. It also boosted the DeepSeek V4 Pro results from 29.0% to 50.8%. 

To understand how this practically impacts enterprise AI, the paper highlights a real-world task involving a MinIO system. Solving the task required checking per-request server logs, a requirement the agents did not anticipate during their initial planning phase.

In the L2 setting, where agents collaborate but lack asynchronous communications, two agents independently realized they needed these logs while executing commands. Because they could not share this finding mid-execution, one agent gave up privately and the other failed to propose it to the team. During the review phase, the team unanimously agreed on the wrong answer, missing five rubrics.

With AgentRadio activated, the agents made the same mid-execution discovery, but one agent instantly broadcasted the required server-side log evidence to the shared worklog. Because the other agents were passively listening, they absorbed this new evidence immediately. This real-time coordination transformed a failing score into a perfect 16 out of 16.

“The useful distinction is timing,” the researchers said. “The team did not need another agent or another review round. It needed one agent’s discovery to reach the right peers before its operational value expired.”

The researchers note that the same pattern appears in enterprise incident work. For example, an agent investigating an API symptom might uncover evidence that invalidates the storage agent’s current hypothesis. If that information waits until both agents finish, the storage investigation may complete along the wrong path. “Passive awareness lets the second agent incorporate the contradiction at its next work step without interrupting a command already in progress,” they said.

The cost and complexity of coordination

AgentRadio requires a fixed multi-agent team budget, which inherently multiplies the token cost. The researchers acknowledge that the “tax is real,” noting that average API spend rose from $2.96 per task for one Opus agent to $19.45 for the full AgentRadio stack.

However, raw scale does not equal performance. When researchers compute-matched the test by spending $17.76 on six independent Opus runs, the models only resolved 37.9% of tasks, compared with 62.1% for AgentRadio. This suggests that AgentRadio’s architecture is a structural win, not just a brute-force scale win. Teams should still be aware of inter-agent churn. “Communication can redirect an agent toward better evidence, and it can also distract an agent from a valid path,” the researchers warned.

A fixed multi-agent team should not become the default response to every engineering task. The more useful test to determine if a multi-agent setup is required is whether the task contains “responsibility breakpoints,” the researchers said. These are places “where a competent engineer would involve another person because the work crosses an ownership boundary, needs an independent hypothesis, or carries enough risk to justify separate verification.”

“Coordination is a strong fit when the task can be decomposed, the resulting parts remain interdependent, the single-agent success rate is unreliable, and an incomplete answer has a meaningful downstream cost,” the researchers said. Examples include repository-wide architecture questions, unfamiliar legacy systems, cross-service incident investigation, security analysis, dependency migrations, and multi-module refactors.

Conversely, a single agent remains the cleaner choice for “bounded, local, and reversible work,” such as a known one-file change or boilerplate generation. 

“Use one agent while one context can still own the problem honestly,” the researchers said. “Introduce another responsibility when the existing agent would otherwise need to compress away evidence, cross an independent ownership boundary, or verify its own high-impact conclusion.”

From research to commercialization: Coral Code

While AgentRadio serves as a controlled research implementation using a fixed four-agent team and a five-phase protocol, the underlying principles are being adapted into a commercial product called Coral Code.

Instead of a rigid, multi-agent protocol applied to every ticket, Coral Code works from the bottom up. An engineer begins with their existing coding agent, and Coral introduces repository-scoped investigation, specialist responsibility, and communication only when the emerging evidence justifies it. “Coral packages the operational concerns around the tools engineers already use, providing the repository context, scoped specialists, communication, and evidence layer around the harness rather than inside it,” the researchers said.

This dynamic approach optimizes costs by targeting the relevant unit: the cost of a completed, reviewable outcome.

The future of autonomous software engineering

While AgentRadio provides a major upgrade to agent orchestration, there are still hurdles to overcome. One major bottleneck that the researchers pointed out to is “attention governance and verification.”

“Passive awareness makes communication available during execution. It does not decide which agents should exist, which discovery deserves an interruption, who should receive it, or when the evidence is strong enough to revise the plan,” the researchers said. If every agent receives every update, the communication layer becomes noise. If several agents share the same bad assumption, faster communication can spread the error.

For example, in one of the case studies in the paper that involved the Grafana platform, four of nine rubrics required negative conclusions, such as observing that a datasource picker did not select automatically. The agents ran the relevant tests, yet none formed the missing negative hypothesis. Both configurations failed the four rubrics. 

“Passive awareness can distribute an idea that somebody develops. It cannot supply a conception that never appears anywhere in the team,” the researchers said.

As task durations stretch longer, communication and coordination become critical. “The next generation of systems… needs adaptive responsibility assignment, evidence-aware routing, conflict resolution, explicit cost limits, permissions, recovery, and clear human escalation points,” the researchers note. Most importantly, it requires durable provenance so engineering leads can inspect which agent made a claim and why an action was accepted.

“Longer-running agents make communication more important. They also make accountability much harder to fake,” they said.