Enterprise AI has largely been built around context engineering. Teams connect enterprise systems, generate chunks and embeddings, build retrieval pipelines, and assemble the context needed by individual AI applications. While this approach works well for isolated assistants and copilots, it treats enterprise knowledge as application-specific context rather than a shared enterprise asset.

As organizations deploy more AI applications and agents, this model begins to break down. Different teams process the same documents, maintain separate embeddings and indexes, and create inconsistent representations of the same business knowledge. The challenge is no longer simply providing context to AI systems — it is managing enterprise knowledge itself.

Why building context is not enough for enterprise AI

The common approach to enterprise AI today is to build context for individual applications. Teams connect enterprise systems, process the required information, generate retrieval representations such as chunks and embeddings, and assemble the context an agent needs at runtime. While this works for a single application, it does not manage enterprise knowledge as a shared enterprise asset.

As organizations deploy more AI applications, this approach begins to break down for three reasons.

First, knowledge becomes inconsistent. Enterprise knowledge is distributed across many independent systems with different schemas, business definitions, and update cycles. The same product, customer, or business process may be described differently — or even contradict itself — across documents, Jira tickets, source code, CRM systems, and metadata. Extracting this information into context does not resolve these inconsistencies; it simply transfers them to the AI application, causing different agents to develop different understandings of the business.

Second, changes become difficult to propagate. Enterprise knowledge evolves continuously, but each application maintains its own context pipeline. As documents, code, and business definitions change, downstream chunks, embeddings, indexes, and agent context are updated independently, causing AI applications to operate on different versions of the same knowledge.

Finally, organizations repeatedly rebuild the same knowledge pipelines. Different teams process the same enterprise knowledge, generate similar embeddings, maintain separate indexes, and construct overlapping context for different applications, resulting in duplicated engineering effort, unnecessary infrastructure costs, and fragmented knowledge.

These are not fundamentally context engineering problems —they are knowledge management problems. Enterprise data platforms solved the same challenge for structured data by managing enterprise data once and sharing it across applications. Enterprise AI now requires the same architectural discipline: a shared enterprise knowledge platform that manages knowledge once and publishes reusable representations for every AI application.

A layered data and knowledge management system

An enterprise knowledge platform is the equivalent of an enterprise data platform for enterprise knowledge. Instead of treating documents, source code, Jira tickets, emails, APIs, and other enterprise systems as isolated inputs for individual AI applications, it manages them as a shared enterprise asset. It ingests, organizes, integrates, governs, and publishes enterprise knowledge through a common architecture so that every AI application consumes the same trusted knowledge foundation rather than maintaining its own context.

To achieve this, the platform separates knowledge management into four layers with distinct responsibilities. Knowledge is first preserved in its original form, then normalized into managed knowledge objects, connected into a common enterprise knowledge model, and finally published in representations optimized for different AI applications. This separation allows each stage to evolve independently while providing a consistent foundation for every downstream application.

The platform organizes enterprise knowledge into four layers:

Raw → Refined → Integrated → Serving

• Raw preserves the original enterprise sources.

• Refined transforms heterogeneous sources into managed knowledge objects.

• Integrated connects knowledge across systems into a unified enterprise knowledge model.

• Serving publishes reusable and agent-specific representations for AI applications.

Raw layer – preserve the source

The raw layer captures information from enterprise systems while preserving its original form and source identity. This may include database records and change events, PDFs and other documents, Confluence pages, Jira tickets, source code, API responses, emails, images, and event streams.

The purpose of this layer is not to make information ready for an agent. It is to maintain a reliable source from which the platform can rebuild downstream knowledge. If extraction logic changes, a model improves, or a downstream representation becomes corrupted, the information can be processed again without depending on an application-specific copy.

Refined layer – normalize enterprise knowledge

The refined layer transforms heterogeneous enterprise sources into managed knowledge objects. Each source is normalized into a consistent representation while preserving its identity, metadata, permissions, versions, lineage, and references to the original content. 

For example, a product requirement document is transformed into a structured knowledge object containing metadata such as document ID, product ID, title, source system, author, version, permissions, tags, creation time, and last modification time, together with its associated content. This representation provides a consistent way to manage enterprise knowledge regardless of whether the source is a document, Jira ticket, source code repository, email, or API.

At this stage, the platform is not trying to connect different domains. Instead, it establishes a reusable and governed representation for every enterprise knowledge source. Once each source has been normalized into structured or semi-structured knowledge objects, the integrated layer can connect them through shared business entities and relationships.

Integrated layer – build the enterprise knowledge model

The integrated layer transforms independent knowledge objects into a unified enterprise knowledge model. It serves two purposes: Connecting knowledge across systems and business domains, and modeling the business relationships that AI needs for reasoning.

Knowledge is connected using shared business identifiers (such as product or customer IDs), explicit cross-system references (such as Jira and Git links), or AI-based entity resolution when no direct relationship exists. For example, a product requirement document describing “Bulk Invoice Upload,” a Jira story titled “Implement Invoice Upload API,” and a release note announcing the same feature may all refer to the same business capability, even though no explicit relationship exists among them.

Once connected, the platform models business relationships based on business logic such as implemented_by, contains, belongs_to, affects, and depends_on, capturing how the business actually operates rather than simply how records are linked.

Unlike traditional primary and foreign key relationships, these relationships describe business workflows, dependencies, ownership, and business impact. They allow AI to trace knowledge across engineering, product, customer support, finance, and other domains using a shared understanding of the enterprise.

Serving layer – publish knowledge for AI

The serving layer is similar to the context layer used in many enterprise AI applications, but it is built on top of a managed enterprise knowledge foundation. It transforms the enterprise knowledge model into representations optimized for different AI workloads. These representations fall into two categories.

The first is shared enterprise representations, which provide a common knowledge foundation for all AI applications. Examples include SQL views, search indexes, chunks, embeddings, graph models, and APIs that are created once and reused across the organization.

The second is agent-specific representations. Instead of maintaining separate copies of enterprise knowledge, the platform dynamically assembles task-specific context from the integrated knowledge model based on the needs of each agent. A Product Agent, Revenue Agent, and Customer Support Agent may all consume the same enterprise knowledge foundation while receiving different context tailored to their responsibilities.

The diagram clearly defines the high-level model of the serving layer:

                          Enterprise Knowledge Model                                         │                 ┌─────────────────────┴─────────────────────┐                 │                                               │                 ▼                                               ▼     Shared Enterprise Representations         Agent-specific Representations   ┌───────────────────────────────┐         ┌──────────────────────────────┐   │ SQL Views                        │         │ Product Context                 │   │ Search Index                     │         │ Revenue Context                 │   │ Chunks                           │         │ Customer Context                │   │ Embeddings                       │         │ Planning Context                │   │ Graph                            │         │ Coding Context                  │   │ APIs                             │         │ ...                             │   └───────────────────────────────┘         └──────────────────────────────┘                 │                                                │                 └──────────────────────┬─────────────────────┘                                         │         ┌────────────────────────────┼────────────────────────────┐         ▼                               ▼                               ▼   Product Agent                   Revenue Agent                 Customer Agent

Managed knowledge platform: The data foundation for AI

Most current enterprise knowledge systems were built for people, not AI. Confluence pages and documents help employees record and share knowledge. Jira enables teams to plan work and collaborate. Metadata systems help analysts understand data assets. These systems organize information so that humans can search, interpret, and connect it using their own experience, knowledge, and judgment.

Large language models have fundamentally changed how enterprise knowledge is consumed. Machines can now understand natural language, reason over documents, and interact with enterprise knowledge in ways that were previously only possible for people. This shift requires more than new AI applications — it requires a new data foundation that manages enterprise knowledge as infrastructure rather than treating it as a single embedding.

This managed enterprise knowledge platform provides the data foundation for AI agents. It transforms human-oriented knowledge systems into AI-ready infrastructure by organizing enterprise knowledge into a consistent, reusable, and governed data platform. 

This foundation enables system capabilities that are difficult or impossible to achieve when every AI application builds and manages its own context.

The platform also provides the foundation for human-in-the-loop and reinforcement learning workflows in agentic systems. Feedback generated by AI agents can be ingested back into the platform, validated, governed, and integrated into the enterprise knowledge model before being published to downstream AI applications. This creates a closed feedback loop that continuously improves enterprise knowledge and enables AI agents to evolve.

The next competitive advantage is the enterprise data foundation

Ever since ChatGPT 3 was released in late 2022, the industry has invested enormous effort in foundation models, RAG architectures, vector databases, embeddings, MCP, and multi-agent frameworks. These technologies have significantly improved how AI applications are built and deployed. Today, the AI application stack is rapidly maturing.

The next bottleneck is no longer the model or the agent framework. It is the enterprise data foundation behind them. AI agents are only as capable as the data and knowledge they consume. Better models cannot compensate for fragmented documents, inconsistent business definitions, disconnected systems, or poorly managed enterprise knowledge. Like every data-driven system before it, enterprise AI ultimately follows the same principle: Garbage in, garbage out.

The most important investment for enterprises is no longer building more AI agents, but building the enterprise knowledge platform that supports every agent. Organizations that treat enterprise knowledge as shared infrastructure rather than application-specific context will build more reliable AI, develop new applications faster, and scale AI across the enterprise without repeatedly rebuilding the same knowledge foundation.

The next competitive advantage in enterprise AI will not come from building more agents. It will come from building the data and knowledge foundation that every agent depends on.

Shuhua Xu is a Lead Data Engineer.

For much of the past two years, the general belief in enterprise AI has been that more autonomy equals better performance. Build agents that can plan, decide, and act across multi-step workflows, and give them as much room to run as possible. That assumption is now being tested at scale, in real production environments — and in a lot of deployments it's failing. The companies that end up benefiting from agentic AI won't necessarily be the ones that have given their agents the most flexibility. They're the ones who create AI agents with specific responsibilities and make sure they operate within clear rules.

Two numbers tell you almost everything about where agentic AI stands in mid-2026. By Gartner's own forecast, more than 40% of the agentic AI projects running today won't survive to see 2028. Not because the models fall short; because of escalating costs, unclear business value, and inadequate risk controls. McKinsey's 2026 AI Trust Maturity Survey fits right alongside that prediction: Agentic AI deployment is accelerating across every industry, but average responsible-AI maturity sits at just 2.3 out of 4. Only about 30% of organizations have reached a maturity level of three or higher in governance and agentic AI controls specifically.  

Put those two numbers side by side, and the story tells itself. Capability is outrunning control.  

That shift is changing the competitive framing, too. The 2024-to-2025 race was about who could deploy the most autonomous agent the fastest. The 2026-to-2027 race is a trust race.  

It's not about who can build the most capable agent. It's about who can get an agent approved for production by risk, legal, and compliance teams, and keep it approved once it's live. This is a different kind of engineering challenge than most enterprises are prepared for.

Why full autonomy breaks down in production  

Gartner lays out the failure pattern as specific and repeatable. Projects launch with ambitious, broadly autonomous workflows. They hit integration complexity within weeks. Then they stall, with no defensible path to production ROI. Part of the problem is vendor noise. Gartner's own count puts it starkly: Out of the thousands of products being sold under the 'agentic AI' label, only around 130 actually have real autonomous capability behind them. The rest are largely automation or chatbots repackaged for the moment.

But even genuinely agentic systems run into a structural problem that has nothing to do with hype. Autonomy and accountability move in opposite directions.  

An agent capable of independently planning and executing a multi-step task is also an agent whose individual decisions get harder to trace after the fact. Let's say something breaks a few steps into an autonomous chain. Figuring out why the agent made that decision and who is responsible can be a complicated process, not a simple lookup.

In areas like financial reconciliations, compliance processes, manufacturing quality checks, or clinical documentation, this lack of transparency can be the difference between a manageable mistake and a serious regulatory breach. It's the reason legal, risk, and compliance teams block agentic projects from reaching production, regardless of how capable the underlying model is.  

Integration complexity keeps showing up as a leading cause of project cancellation. Bolting an autonomous agent onto a legacy workflow takes more than technical connective tissue. The workflow's existing decision points, approval chains, and audit trails all need to be rebuilt around a system that can now act without waiting for a human. Enterprises that treat this as a pure integration problem, solvable with more engineering hours, tend to be the ones that stall.  

This isn't a hypothetical risk. McKinsey's research shows how exposed most enterprises currently are. Across nearly every category of AI risk, from data privacy to intellectual property exposure, the gap between the risks organizations say they're aware of and the risks they're actually mitigating remains wide.    

Awareness has surpassed action. This gap is reflected in the businesses that report it as an obstacle to further scaling of agentic AI. Nearly two-thirds now say security and risk issues are the greatest challenge for them, surpassing regulatory uncertainty and technical barriers.    

What governed orchestration actually looks like  

The enterprises that are leading the way are not halting their AI plans. They're restructuring how autonomy is being distributed within the system. The four patterns that stand out in organizations that are governance-mature are:  

• Narrow-scope agents over general-purpose ones. Decompose end-to-end workflows into single-responsibility agents with tightly bounded mandates. A smaller scope of work results in a smaller scope of failure, and a smaller scope of failure is much easier to audit.  

• Human checkpoints at decision boundaries, before the outcome, not after it. Review agent decisions before high-stakes actions execute, not after the fact. That means checkpoints before sensitive data moves, a transaction posts, or an external system is triggered. McKinsey's framework calls for real-time, data-driven monitoring built into the agent pipeline itself, with humans retaining final accountability specifically for high-stakes decisions.  

• Decision traceability as a design requirement. A full action log and decision lineage should be available on demand for any agent, any decision. It shouldn't need to be reconstructed under pressure during an audit. Regulators are pushing the same way. The EU AI Act's human oversight requirements for high-risk systems are still coming, even though this year's Digital Omnibus agreement pushed the compliance deadline out to December 2027. Enterprises building agent systems now are effectively building toward that requirement, whether or not it's technically enforceable yet.  

• Data sovereignty does active governance work, not passive paperwork. Where an agent's data sits, and who has access to it, decides how contained a failure can be. On-premise or controlled-environment deployment limit the blast radius of a misbehaving agent and simplifies exactly the kind of audit trail regulators and boards are starting to expect.  

The risk runs in both directions, of course. Agentic AI is supposed to cut friction. An agent that needs a human to sign off on every minor task hasn't cut anything; it's just automation wearing a manual process as a costume. That quietly undercuts the whole case for building the agent in the first place. The goal isn't maximum control. It's calibrated control, concentrated where the cost of an error is actually high.  

Agent deployment is scaling roughly 8x faster than governance maturity is improving.  

A practical framework for evaluating your agent stack  

If enterprise architects are reviewing an existing agent for deployment or are considering deploying an agent, they can begin by asking four questions.  

1. Can you reconstruct, six months from now, exactly why a specific agent took a specific action?   If the honest answer requires digging through raw logs or guessing, decision lineage isn't a design feature of the system. It's an afterthought. And it will show up as a gap in the next audit.  

2. Does every agent in the stack have one clearly bounded responsibility, or is at least one agent authorized to "figure it out" across a broad task?   Broad, open-ended mandates are exactly where compounding errors and untraceable decisions originate.  

3. Are human checkpoints placed at defined decision boundaries, or only as a final review after the agent has already acted?   A review after the fact catches consequences. A checkpoint before the fact prevents them.  

4. If an agent were compromised or malfunctioning right now, how much data and how many downstream systems could it touch before anyone noticed?   This is where data sovereignty and access scoping stop being compliance line items and start functioning as containment strategy.  

These are all questions that don't need to slow down the adoption of agentic AI. They need direction on how and where autonomy is of value to their organization and how to open up to exposure. This suggests building the orchestration layer on that separation, rather than adding governance after a production incident forces the question.  

The real competitive advantage  

Gartner's 40% cancellation forecast isn't really a warning about AI capability. It's a forecast about organizational discipline. Right now, agentic AI sits at what Gartner defines as the "peak of inflated expectations," and there's a fairly straightforward explanation. Enterprises spent 2024 and 2025 optimizing almost entirely for autonomy. Now they're paying down the governance debt that approach accumulated.  

The winning position by 2027 won't belong to whoever deployed the most autonomous agents fastest. It will belong to whoever built agent systems trustworthy enough that risk, compliance, and legal teams stopped being the bottleneck. The architecture answered their questions before anyone had to ask them.  

That's a different design brief than most agentic AI roadmaps were written against. It's about making scoped autonomy, checkpointed decisions, full traceability, and data sovereignty integral to the architecture from the start, not add-ons after a pilot project has been a success.

Midhula Mariyam Jeevan is a content writer specializing in AI, enterprise technology, software engineering, and SEO.

When an agentic AI system hands a task from a small model to a larger one — or back down again — it pays a steep tax: the receiving model has to recompute the entire conversation from scratch, driving up compute costs and latency. This is a major bottleneck for enterprises building long-horizon, multi-LLM workflows.

To solve this challenge, researchers at Nvidia have introduced a cross-model KV cache transfer technique that directly maps the prefilled KV cache from a source model into the target model. This technique aligns with real-world agentic applications where large contexts accumulate across many turns. 

For real-world AI applications, cross-model KV cache transfer can reduce compute costs and latency on long-running, multi-LLM workflows — and it does so with simple linear math, not an expensive deep learning model.

Experiments show that, on compatible model pairs, this linear mapping process runs 2.7 to 25 times faster than recomputing the conversation while retaining up to 98% of the target model's standalone accuracy. 

Why swapping models mid-session is so expensive

Examining how LLMs handle memory helps understand why multi-model workflows hit a performance wall in production. When an LLM receives a prompt, it must first execute the “prefill” stage, which is the initial forward pass that computes the keys and values for all input tokens and populates the Key-Value (KV) cache. 

After that, it enters the “decode” phase, where it computes and generates the next tokens in the sequence. During this phase, the model reads from this KV cache to predict new tokens one by one, bypassing the need to re-evaluate the entire history of the conversation for each new token.

In multi-turn conversations or long-horizon agentic sessions, the context gradually becomes longer. Because the computational cost of the prefill stage scales directly with both model size and input length, processing these long sessions becomes increasingly expensive and introduces significant latency if the KV cache is invalidated.

This invalidation happens whenever the AI system tries to swap models mid-session, such as routing a complex reasoning step to a larger model or dropping to a smaller model to save costs. Because different LLMs have different architectures, they expect their cache inputs in different formats. 

As a result, any model switch forces the receiving model to repay the entire prefill cost from scratch to recompute the KV cache for the accumulated context. 

Mapping memory between models without starting over

The Nvidia researchers studied cross-model KV cache transfer to see how developers can transform the KV cache of one model into the expected format of another without running the prefill phase again. 

If solved, cross-model KV cache transfer has benefits in both directions. Small-to-large model transfer upgrades the quality of the output. For example, a cheap, small model handles the routine parts of an agentic workflow but struggles with a complex reasoning problem, and you map the KV cache to a larger model and continue the process seamlessly.

On the other hand, large-to-small model transfer reduces compute costs. A highly capable, large model might be used to unpack a massive, complex system prompt or synthesize a dense PDF at the start of a session. Once the heavy lifting is done, the session's KV cache is mapped down to a smaller, more economical model to handle the rapid-fire, conversational turns that follow.

There have been previous efforts to solve the KV cache transfer problem, but they suffer from a few key limitations. These include the need for expensive gradient-based training or very strict architectural constraints.

For this initial study, the authors restricted their focus to within-family transfers, such as transitioning between different-sized models in the Qwen, Llama, or Ministral families. These models share tokenizers, training data DNA, and core architectural styles but differ in size and depth. However, this framework leaves plenty of room for future experiments. The researchers note the technique could eventually be expanded to cross-family transfers, mismatched KV head counts, or hybrid architectures that blend standard attention with other memory mechanisms.

The key finding of the Nvidia study is that cross-model KV cache is a significantly linear structure. This means you can do the mapping with simple algebra tricks and without the need for heavy neural network training. For example, when experimenting on KV cache transfer from a 14-billion parameter Qwen3 model to a 32-billion parameter version, the authors discovered that a simple linear regression mapping from one source layer to a target layer can recover 56% of the variance in the target’s keys and 32% of the variance in its values. When combining multiple source layers, those numbers climbed to 79% and 65% respectively.

To translate this linear relationship into a practical system, the researchers designed a closed-form per-head ridge mapper with three key components:

• Per-head ridge regression: Instead of using complex deep learning to train the system, they fit a simple linear regression using a tiny calibration set of a few hundred text sequences. This technique solves a classic line-of-best-fit problem independently for every attention head.

• Cross-layer source selection: Because the source and target models have different numbers of layers, the mapper evaluates and selects the most predictive source layers to feed into each specific target layer. This way, the system picks only the most helpful pieces of memory from the old model to construct the new model's memory.

• Content-space mapping: Before translating the data, the mapper strips away the RoPE encodings. RoPE, or Rotary Position Embedding, is a standard mechanism that applies a mathematical, position-dependent rotation to the data so the model understands the order of the tokens in a sequence. Stripping the RoPE values makes it possible for the mapper to generalize to sequences of lengths larger than its training data.

Putting the linear mapper to the test

To test whether the technique works, the researchers evaluated the transfer pipeline across six “matched-KV” model families. Matched-KV means the source and target models share the same KV head count and per-head dimensions, which is typical for different-sized models within the same family.

The model families included Qwen3, Llama 3.1, and Ministral 3, with tests for KV cache transfer across different sizes ranging from 3 billion to 70 billion parameters. Their experiments included a massive 8.8x parameter leap from Llama 3.1 8B to 70B.

To cover a wide range of tasks, they evaluated the models on five core accuracy benchmarks (ARC-Challenge, HellaSwag, WinoGrande, MMLU, and GSM8K) as well as language modeling perplexity on WikiText-2 and a multi-turn conversation task called CoQA. To fit the linear translation mapper, they used a tiny calibration dataset of just 500 text sequences of 1,024 tokens each.

The researchers compared the framework against the baseline ceiling accuracy where the target model does a full, traditional prefill. They also compared their full system against ablated configurations, such as reducing the number of selected layers or deactivating different components. Additionally, they compared their simple method against a deep neural network trained with backpropagation to see if heavier deep learning could recover accuracy on pairs where the linear method struggled.

For four of the six tested pairs, the fast, closed-form linear ridge mapper retained 73% to 98% of the target's standalone prefill accuracy — including the massive leap from Llama 3.1 8B to 70B, which retained 72.8% of target accuracy.

The mapper also runs between 2.7 and 25 times faster than re-prefilling. For example, when translating a 32,768-token KV cache from a Qwen3 14B to a 32B model, the transfer took just 278 milliseconds, compared to nearly 7 seconds for a standard re-prefill.

The system also demonstrated high stability on tasks that run across many steps. When tested on multi-turn conversations, the drift, or accuracy loss, between the target baseline and the transferred cache remained incredibly small across 10 turns, proving it will not cascade into failure during long agentic sessions.

However, the straightforward linear approach did run into limitations on specific model pairs. For two of the Ministral configurations, the linear mapper degraded sharply because the simple linear fit failed to extrapolate outside calibration data. To fix this, the researchers swapped the linear mapper for a nonlinear multi-layer perceptron (MLP) with two 1,024-unit hidden layers trained on the same data. This added a complexity and training tax to the setup, but it recovered their accuracy to above 90%.

A bigger industry problem than one paper can solve

The introduction of cross-model transfer is part of a broader, industry-wide push to solve the KV cache bottleneck, which has emerged as one of the key hurdles for scaling enterprise AI. As developers push LLMs to process massive documents or code bases and execute long-running reasoning tasks, managing this memory layer is becoming as important as the models themselves.

Over the past year, researchers have attacked this compute and memory problem from multiple angles. For instance, Nvidia recently introduced dynamic memory sparsification (DMS), a technique that intelligently evicts less important tokens from the KV cache to cut reasoning costs by up to 8x. 

Other approaches focus on aggressive data compression. MIT researchers developed an algebraic compaction technique called Attention Matching that compresses the KV cache by 50x without degrading quality. Similarly, Nvidia introduced KV Cache Transform Coding (KVTC), which borrows media compression concepts to shrink memory by 20x without altering the underlying model weights.

Beyond compression, researchers are also attacking the computational overhead of memory retrieval. Optimizers like IndexCache strip away redundant layer calculations to deliver significantly faster time-to-first-token in long-context applications. And models like DeepSeek and the GLM series are optimizing the KV cache through architecture innovations.

As AI systems take on longer-horizon tasks and more complex architectures, the underlying memory infrastructure is becoming as important as the models themselves. Cross-model KV cache transfer gives developers one more tool for keeping inference costs down as they scale multi-model agentic systems.

Slack wants to drag AI coding out of the terminal and into the group chat.

The Salesforce-owned messaging platform today announced Slack Code, a new product that embeds AI coding agents — including Anthropic's Claude Code, Cognition's Devin, GitHub Copilot, and Vercel's agent — directly into dedicated Slack channels where entire teams can watch, steer, review, and ship software together. Slack Code is available on any Slack plan at launch, though customers need their own access to the partner agents.

The pitch is deceptively simple: today, most work with AI coding agents happens between one person and one agent, invisible to everyone else. Slack Code makes that work "multiplayer." When someone tags a coding agent from any conversation, the agent spins up a project-specific code channel, does the work in the open — complete with code diffs, live previews, and a running plan visible in dedicated tabs — and archives the channel when the job is done, leaving behind a searchable audit trail.

"One of the things I love about this is that code is no longer the bottleneck," Rob Seaman, Slack's interim CEO, said in a press briefing ahead of the launch. "Ideas, taste, judgment, craft — those are the things that are the bottleneck, and you've effectively extended the population that can contribute ideas, taste, judgment, and craft to anybody that exists in your Slack."

It is a consequential launch for Slack, and a revealing one for the broader enterprise AI market. The AI coding boom has so far been a story of individual productivity — a developer alone with Claude Code or OpenAI's Codex in a terminal window. Slack is betting that the next chapter belongs to whoever owns the collaborative layer around those agents. And it is making that bet at a moment when its parent company badly needs the story to land.

How Slack Code channels put AI coding agents to work in the open

In the interview, which also included executives from Cognition, Slack leaders described a workflow that looks less like pair programming and more like a newsroom.

Jeff Wang, president of new enterprise at Cognition — maker of the Devin coding agent — walked through a live demonstration: someone reports a broken feature in an engineering channel, Devin acknowledges it with an emoji, replies in the thread, investigates, and opens a pull request. "It even knows the code owner, so you can see it tagged Theo into this as well," Wang said. "Every time Devin is doing something like this, it does have its own computer. So here, it's actually using Chrome and the DevTools to test if the feature is working correctly."

From there, the work migrates into a dedicated code channel where anyone — an engineer, a product manager, a designer — can jump in. In Wang's demo, a designer dropped a Figma file into the channel mid-task, and the agent incorporated it without breaking stride. The agent finished by posting the code changes alongside screenshots and a recorded demo proving the feature worked. That verification loop is central to the pitch: cloud-based agents, unlike agents running on a developer's laptop, can generate an auditable record that the work is actually correct. "Scaling things, auditing things, giving it to everybody — that is much easier with these cloud agents form factor than it is with local agents," Wang said.

The launch reaches beyond code channels, too. Slack is shipping a broader rework of how agents live in the product: agent DMs that behave like conversations with a colleague, a new Agents tab that gives every agent session a home base with live status and a stop button, and an "Add to Slack" flow that lets teams deploy agents from platforms including Lovable, n8n, OpenAI, LangChain, and Airtable in a few clicks, with OAuth and configuration automated.

Why Slack says writing code is no longer the bottleneck in software development

The strategic argument underneath Slack Code is that AI has inverted the economics of software development. Writing code used to be the scarce, expensive step. Now, Slack's executives argue, it is the cheap one — and the constraint has moved upstream, to human judgment.

"One of the things I love about this is that code is no longer the bottleneck," Seaman said in the press briefing. "Ideas, taste, judgment, craft — those are the things that are the bottleneck, and you've effectively extended the population that can contribute ideas, taste, judgment, and craft to anybody that exists in your Slack."

Cognition offered internal numbers to back up the velocity claim. "We've seen our internal merged PR count go up 10x in the last few months, versus our headcount has only gone up like 40 percent," Wang said, describing a workflow where engineers fire off a Devin task, move to something else, and launch another — "soon you have everybody working on like dozens of agents at a time."

The pattern extends well beyond engineers, Wang said. "Believe it or not, a lot of our bugs are reported by our sales team. They report it in Slack, and then someone who's technical applies them to fix the bug." Seaman seized on that example as the whole thesis in miniature: "So much of that stuff never even made its way to a product manager into a backlog because the communication vehicles weren't there, the motivation wasn't there, the knowledge that it could actually be fixed so quick wasn't there — and we've effectively knocked all of that down."

Wang went further, sketching where he believes this ends up. Toil work — "fixing bugs, fixing CI/CD, or fixing vulnerabilities, all these things engineers probably don't want to do — we think will be automated away," he said. What remains is the work that "requires creativity, planning, business logic." He added a prediction that will make some engineering leaders uneasy: while a human still gates every merge today, "I suspect maybe in the next year it's just going to go through automatically."

Can working in public solve the AI slop problem?

The obvious objection to democratizing software creation is quality. If anyone in a company can summon a coding agent, does an enterprise drown in what the industry has taken to calling "AI slop" — plausible-looking but poorly conceived output generated at scale by inexperienced users?

Slack's executives argue, somewhat counterintuitively, that visibility is the antidote rather than the accelerant. "The multiplayer part is a guard against that, actually, because people can see your work, people can comment on your work," said Katie Steigman, Slack's VP of product. She contrasted it with the status quo: "If I'm doing God knows what in terminal with an agent, versus being able to do it in a place where people can see my intent and actually change and shape my work — or slap my hand and tell me that's slop, because that's real."

Steigman, a product manager rather than an engineer, described her own practice as a template. "When I put PRs up as a product person, I almost always tag in an engineer from my team. I don't just send a PR and ask for an approval," she said. "Almost every time, an engineer will say something like, 'Come on, you can make that a little bit tighter,' or they'll actually give it some specific technical guidance, and the agent will take one more rev and produce code that has been touched by an engineer to a certain extent."

Seaman framed the argument in grander terms: "I think the moral arc of multiplayer AI bends towards higher quality and less duplication." He pointed to Shopify, where he said CEO Tobi Lütke has written about restricting agentic coding to public channels precisely because it "immediately disseminates every single thing that's happening in the company" and levels the playing field. Still, the skeptics' case has data behind it. 

Gartner predicted last year that more than 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs and unclear business value. And McKinsey's most recent State of AI survey found that while 62 percent of organizations are at least experimenting with AI agents, only about a third have begun scaling AI at all, and just 39 percent report any bottom-line impact. The gap between agent enthusiasm and agent value remains the defining feature of the market Slack is selling into.

Inside Slack Code's security model: no god mode, no new identities

For enterprise buyers, the most consequential design decision in Slack Code may be its permissions model. Asked directly whether agents in code channels could leak access across teams — a finance repo visible to legal, say — Seaman was emphatic that agents inherit the permissions of the human who invokes them, and nothing more.

"Everything is done on behalf of the user, using the user's ACLs, both in Slack and in the systems that they're connecting to," he said. "There's no god permissions or bot-level permissions... Within Slack, the agent has access to information that the user has access to, and access to the channels that it's been added to."

Steigman added that when an agent spins up a code channel, "the only thing that agent gets from the code channel is the context of the conversation" that triggered it. On the execution side, Wang said Devin runs in isolated sandboxes with "minimum viable access" — including an optional mode with no internet access at all. "You've heard all these stories about the agent escaping and causing havoc," he acknowledged, "but we have different security configurations."

This "agents as extensions of existing users" model is a genuine differentiator against standalone agent platforms, which typically force IT departments to provision new service identities and manage a patchwork of one-off permissions. It also answers the shadow-IT question that has dogged agentic tools: because agents produce standard pull requests into GitHub, existing release gates and review processes still apply. "It reduces that barrier upfront to get that initial PR up," Steigman said. "Then the due diligence still happens in GitHub."

What Slack Code means for Salesforce's high-stakes AI turnaround

Slack Code arrives amid a turbulent stretch for its parent company. Salesforce shares fell roughly 18 percent over the year through January, badly lagging the Nasdaq, as Wall Street questioned whether AI would erode demand for traditional enterprise software. In December, OpenAI hired away Slack CEO Denise Dresser as its chief revenue officer, elevating Seaman — then Slack's product chief — to interim CEO.

Salesforce has responded by racing to make Slack the AI front door for work. In January it shipped a rebuilt Slackbot powered by Anthropic's Claude, which the companies said became the fastest-adopted feature in the company's 27-year history. Slack Code extends that strategy from answering questions to producing artifacts: not just messages, but working code, prototypes, and documents generated inside Slack itself.

There is also a notable strategic reversal embedded in today's news. In mid-2025, Reuters reported that Salesforce had moved to block rival AI firms from accessing Slack data — a defensive crouch.

Today's announcement, by contrast, positions Slack as an open platform courting exactly those AI companies as partners, with plans to open the code channel APIs to any developer. Software engineering, the company says, is just the first use case; marketing campaigns and legal document reviews in dedicated agent channels are next. The calculus appears to have shifted from protecting Slack's data to making Slack indispensable as the venue where agents — anyone's agents — do their work.

Partners are, unsurprisingly, saying the right things. "A whole team can gather in one code channel, watch the agent work, steer it together, and ship a preview," said Vercel CTO Malte Ubl. GitHub chief product officer Mario Rodriguez called Slack "a strategic part of a broader GitHub promise: humans set direction, agents close the loop."

The future of AI coding: multiplayer channels and single-player terminals will coexist

None of Slack's executives claim the terminal is dead. Asked whether tools like Claude Code and Codex become obsolete, Seaman predicted a division of labor. "The overwhelming majority of the work is actually going to happen in these multiplayer environments," he said. "But there's going to be deep, immersive, intensive, single-player thought work that's going to happen in terminals." An engineer rethinking a codebase's architecture goes heads-down with an agent; a sales rep flagging a broken button gets a fix in a channel everyone can see.

The trust curve, Seaman suggested, will look familiar to anyone who watched teams adopt earlier waves of automation. "People are going to open these things at the beginning" — reading every diff, every thinking step — "and then build trust in the system and open it less and less over time."

That is the wager, and it is bigger than a product launch. McKinsey's research shows the organizations capturing real value from AI are the ones that redesign workflows around it rather than bolting it onto old processes — and Slack Code is, at bottom, a workflow redesign packaged as a feature, an attempt to make the team rather than the individual the unit of AI adoption. If it works, the company that once changed where colleagues talk will have changed where software gets made. If it doesn't, all that transparency may just mean everyone gets to watch the slop pile up together.

Either way, the era of the lone developer whispering to an agent in a private tab is ending. As Wang put it: "The bottlenecks have shifted." The question Slack Code will answer is whether the crowd makes them smaller — or just louder.

Enterprise AI teams have stopped betting on a single orchestration platform. The median enterprise now runs three at once — not by accident, but because none of them fully trusts a single vendor to run the show, according to VB Pulse data.

This is not just to avoid vendor lock-in and retain flexibility (although that’s a big part of it). There’s still a lot of uncertainty, even distrust, in vendors’ security and permissioning capabilities. Enterprises want the ability to impose their own.

Microsoft leads on primary usage today, while Anthropic leads by a wide margin in what enterprises are considering next. But enterprises still struggle with many challenges, notably around token usage and visibility into agent spending.

These findings are from an ongoing analysis of how enterprises are actually deploying and using AI: Their platforms of choice, what guides their decision-making, what they prioritize, their AI expectations, how they control costs, and whether their AI is actually agentic or still a chatbot in an "agent" label.

VB Intelligence is getting feedback from builders actually in the trenches: software and machine learning (ML) engineers, product and program managers, and data/AI/analytics VPs and directors.

Concerns around retaining visibility and control

Across 107 enterprises, agentic orchestration has become decidedly plural. The survey found that the majority of enterprises are not committing themselves to any one model: 85% are using two or more orchestration tools; 64% are using three. Just 15% run a single orchestration platform.

Microsoft AI Foundry/Copilot Studio shows up in 70% of stacks, OpenAI’s Agents SDK in 68%, and Anthropic’s Claude Platform in 47%. Builders surveyed are also to some extent using Google’s Enterprise Agent Platform, LangChain/LangGraph, Salesforce Agentforce, Amazon Bedrock, and LlamaIndex. Augmenting vendor tools, 22% of builders run custom in-house orchestration.

This trend of hybridability is only expected to continue. More than half of respondents (53%) said the primary control plane will be hybrid by the end of 2026. Fourteen percent expect to use a provider-managed service, 13% plan on a custom in-house control plane, and 11% are betting on external platforms that are abstracted away from model providers.

Dovetailing with this, more than two-thirds of respondents plan to change platforms within the year: 15% in the next three months (or sooner), 24% in three to six months, and 28% in six to 12 months. Claude Agent SDK is a top tool under consideration; 43% of builders are exploring the Anthropic-built model. Roughly one-third are looking at Google’s Enterprise Agent Platform, another 31% are focused on custom in-house orchestration, and 25% are investigating OpenAI’s options.

Perhaps learning from the lock-in of the early cloud days, enterprises aren’t choosing one “winner.” They are deliberately building for a future where multiple orchestration platforms, models, and agents work with each other across a hybrid control plane.

Generally speaking, respondents are pleased with the platforms they’ve been running, rating them 4.17 out of 5 for overall satisfaction. But they are less satisfied with ease of implementation (rating it 3.91 out of 5) and value for the money (3.63 out of 5). Keep an eye on these ratings as orchestration platforms and AI roadmaps mature.

Where enterprises are putting their money

Enterprise buying logic is now based on a mix of several factors. Beyond flexibility (cited by 29% of respondents), top considerations include security and permissions (17%), production reliability (15%), and control over agent execution (15%). Just one out of 10 identify model gravity — native alignment with a state-of-the-art base model — as important in purchasing decisions; 8% name ease of development, 4% cite total cost of ownership, and just 2% cite latency and memory performance.

Spending also reflects enterprise priority on visibility, security, and control. Builders are investing the most in agent monitoring and debugging (31%) and security and permissions enforcement (30%). Workflow tooling accounts for another 19%. That's a shift from VentureBeat's prior wave a month earlier, when workflow tooling led orchestration spending outright.

Enterprises are largely optimizing for task completion reliability (30%), multi-step workflow management (27%), developer productivity (23%), and operational stability (13%). Just 7% of respondents name end-user experience as a top priority at this point, indicating that many are still focused on orchestration at this point rather than UX.

Essentially, enterprises are signaling that workflow succeeds when it carries multiple steps to completion. Simplifying development and end-user experiences could become a larger concern when platforms are actually in place.

The visibility problem

Builders’ biggest concerns when choosing platforms center around control and oversight. They don’t want vendors to constrain their ability to see what their agents are doing on a given platform. Factors top of mind include security and permissioning limitations (37%), vendor lock-in (23%), limited visibility and observability (22%) and inflexibility around models and tools (16%).

Meanwhile, in these early days of AI agents, enterprises still struggle to control agent token use; one in five still can’t stop a runaway agent’s spending in real time.

Builders are using various strategies to try to keep agent spending in line: 30% rely on native platform controls (built-in budget caps or throttling) and 25% have built custom gateway plumbing (proxy middleware to intercept runaway agents).

A quarter of respondents use dynamic routing to offload heavy work to low-cost models, and 21% still rely solely on reactive monitoring, such as post-hoc logs; these enterprises have no real-time kill switches.

One interesting finding: unlike the prior wave, organization size makes little difference in fiscal control maturity — 18% of enterprises with 10,000-plus employees exercise only reactive control, compared to 23% of smaller ones.

Clearly, while enterprises recognize the problem with spend, many have not yet instrumented their stacks to rein it in.

Most enterprises still aren't running true multi-step agents

Builders polled were asked to honestly assess their tech stacks; the consensus seems to be that ‘agents’ are slowly but surely progressing beyond chatbots wrapped in that fancier label.

Here’s how the numbers break down: A small number of respondents (2%) report that 76 to 100% of their systems are advanced and largely autonomous; 14% say 51 to 75% of their systems are complex, multi-agent pipelines; and 47% report that 26 to 50% of their systems are true orchestration.

On the other end of the spectrum, 35% say just 1 to 25% of their systems are true orchestration; most deployments remain basic assistants, and 3% are still only deploying chatbots.

This is in line with VB’s June Pulse survey: 71% of respondents said a quarter or fewer of their deployed “agents” can autonomously complete multi-step work, and just one-tenth say they have deployed agents at scale.

There’s no doubt that enterprises are building control planes and infrastructures for agents; but for many of them, the true agentic wave is still off on the horizon.

Adding an AI agent to Slack sounds appealing to many enterprises — but, as VentureBeat has experienced ourselves first hand — the reality is often far more complex and clunkier than it first seems.

Now NanoCo., the company behind the hit open source, enterprise-friendly, autonomous AI agent harness NanoClaw (a more sandboxed, lower code version of OpenClaw), is hoping to make it just as easy as typing a Slack message. To go one step further: the company's new NanoClaw Slack integration lets human users spin up entire teams of agents with their own specialized skills, workflows, and even custom avatars, all from a single Slack prompt.

"In the next 12 to 18 months, everyone on a team will be a manager of agents," NanoCo CEO and co-founder Gavriel Cohen told VentureBeat in an exclusive interview.

Furthermore, the NanoClaw agents can work together in channels and shared Slack Canvases, and can even be messaged outside of Slack on other platforms like Telegram or WhatsApp, letting their human colleagues ping them across messaging platforms, just as they would their fellow humans.

“I think this is agents arriving natively in Slack for the first time,” Cohen added. “In the past, you had to do all these weird things to try to have multiple different agents behind the scenes using the same bot, and now every agent gets its own identity in Slack — its own avatar, its own face, its own name. You can tag them. They can tag each other.”

For enterprise teams, the more consequential part is persistence and separation. NanoClaw is not presenting the additional workers as invisible subagents that disappear after one task. Each can be given its own role, memory context, instructions and permissions, creating a structure closer to a small digital department than a single chatbot with a long prompt.

As with the original open source version of NanoClaw released in January 2026, developers and enterprises can further choose whichever underlying large language model (LLM) they wish to power their NanoClaw agents, optimizing for performance, cost, or other combinations of factors.

From a single NanoClaw Slack agent to a whole specialized team

For a new installation, NanoClaw’s current setup process starts by cloning the project and running its nanoclaw.sh installer, which walks the user through dependencies, credentials, building the agent container and pairing a first messaging channel. NanoClaw’s website says the installer takes a user “from a fresh machine to a named agent you can message,” with Slack among the supported channels.

Cohen described the Slack-specific flow to VentureBeat as a significant simplification over building a traditional Slack bot. Previously, he said, a user would have to navigate Slack’s administrative and developer interfaces, create an app, collect secrets, API keys and tokens, and then move those credentials into wherever the bot was running.

With the new integration, the NanoClaw setup instead offers a Connect Slack option. The user names the agent, authenticates, chooses the NanoClaw Add to Slack option and goes through Slack’s installation and authorization flow. Once authorized, the first agent can appear in Slack and begin communicating with the user.

The important distinction is that this initial authorization is largely a one-time workspace connection. Slack’s Marketplace listing says users “connect a workspace once,” after which NanoClaw can provision each additional agent as its own Slack bot, complete with its own name, generated avatar and identity.

Those agents continue running on the customer’s infrastructure and connect to Slack over Socket Mode. NanoCo says it does not store the agents’ Slack tokens; according to the Marketplace listing, those tokens remain on the user’s machine.

Slack’s standard administrative controls still sit around that system. Organizations can apply their normal app-approval policies to the NanoClaw integration, while NanoClaw’s Marketplace listing says the app’s Home tab displays the agents provisioned in a workspace and lets users revoke individual agents or disconnect the workspace entirely.

The result is less a one-click replacement for NanoClaw’s underlying infrastructure than a one-time bridge between that infrastructure and Slack: users still own and operate the agent runtime, but once the bridge is authorized, the agents themselves can create and coordinate additional Slack-native colleagues without sending the user back through manual app configuration each time.

Behind the scenes, Cohen said, the lead agent has a Model Context Protocol (MCP) tool that can create new agents and define their instructions, personas, skills and tools; another tool can place them into shared rooms. The agents come prepared to work with Slack Canvas and can communicate with every human user on the Slack Channel, and with one another.

The interaction itself is deliberately simple. Rather than opening a separate agent builder every time a new role is needed, Cohen said users can tell the agent they already have what kind of colleague or team they want.

“Your agent in Slack, you can say, ‘Create me another agent to handle my code reviews. Create another agent to review the contributor articles. Create a team of agents that reviews contributor articles from different perspectives.’ And then your agent can create new agents, and they just pop up in the sidebar and send you messages.”

That means a developer could ask for a product manager, architect, implementation agent, code reviewer and testing agent, then give each a different toolset and have them hand work between one another. Cohen said the testing agent, for example, could have access to a testing environment while the review agent carries code-review-specific skills and the product agent monitors user feedback.

Cohen argues that this division of labor is more than cosmetic role-playing. “There are advantages in terms of giving each one specific skills, instructions, and tools for different tasks,” he said. “I can have, let’s say, a code review agent, a code testing agent, a code writing agent, and I can have them in a loop.” If the implementation agent runs into an ambiguity, he added, it can tag the product or architecture agent for clarification rather than forcing one general-purpose model to hold every responsibility and tool in the same context.

Agents work together with humans on a share Slack Canvas

A supplied demo screenshot shows the same pattern applied to marketing: a lead agent named Nano creates Atlas for strategy, Sage for content, Echo for social, Scout for outreach and Compass for SEO and analytics. The agents introduce themselves in the same Slack conversation and begin coordinating work, with Atlas noting that it had added an item to Canvas so the task would not get lost.

Users do not have to specify every detail up front. Cohen said someone could give the lead agent exact review procedures, priorities and required tools, or leave more of the configuration to the agent based on its existing context and memory.

The design also tries to avoid a familiar multi-agent failure mode: bots endlessly triggering one another. NanoCo says the agents reply only when tagged, while comments left on work in Canvas can be routed back to the agent responsible for that piece.

And the model can extend beyond teams of task-specific bots created by one person. Cohen described a workplace where individual employees each have persistent agents that can communicate with one another under human-defined policies.

“Each person having their own agent means that I could have my agent and you have your agent in Slack, and your agent can ask my agent questions,” he said. “Maybe I’m out of the office for the day. Your agent can ping my agent and ask a question about availability, and I can set some policies about whether my agent can answer or if I need to give approval.”

That pushes the concept closer to organizational delegation: some agents specialize by function, while others effectively represent individual employees and the context they have accumulated. Cohen said the agents can be equipped with browser and internet access, memory, coding capabilities and other tools, while newly created agents arrive with built-in support for Canvas work, agent-to-agent communication and spawning still more agents.

Slack is opening the door to more third-party agents

The underlying Slack change is broader than NanoClaw.

In April, Slack, a Salesforce product, announced the ability to add external AI agents to the messaging platform directly, initially pointing to Vercel and Lovable and saying those integrations were coming in late May.

Slack said the deployment mechanism automates OAuth, manifest configuration and environment setup so an externally built agent can be brought into the workspace without being rebuilt specifically for Slack.

Salesforce’s newly published Slack Code page now names NanoClaw alongside Lovable, Hyperagent, Superhuman, n8n, Vercel, ChatGPT, LangChain, Runlayer and Skydive, and says Add to Slack can bring agents from those platforms into Slack in a few clicks with their own identity.

Slack is already crowded with AI assistants. OpenAI, for example, lets ChatGPT workspace agents be deployed into Slack channels, where they can answer questions, perform tasks through connected systems and output files. Slack also supports Claude and custom Agentforce agents. NanoClaw’s differentiation is therefore not simply “AI in Slack.” It is the ability for an already-running agent to create additional, independently addressable teammates from inside the conversation itself. NanoCo calls that a first for Slack; that specific market-first claim is the company’s.

“Add to Slack means one message can spin up a full team of NanoClaw agents, working right alongside people in Slack,” Josh Milas, director of product management at Slack, said in the supplied announcement.

How NanoClaw differs from Claude Tag, ChatGPT agents and Agentforce in Slack

NanoClaw is not alone in trying to turn AI from a sidebar chatbot into something resembling a persistent Slack colleague.

Anthropic’s Claude Tag, which began rolling out in beta to Claude Team and Enterprise customers in June, may be the closest conceptual comparison.

Administrators can give @Claude access to selected channels, tools, data sources and codebases; everyone in the channel can then delegate work to it by tagging it. Claude remembers relevant information from the channels it inhabits, can work asynchronously over hours or days, and, when administrators enable its “ambient” behavior, can proactively flag information or revive unresolved work without waiting for another prompt.

Anthropic says separate Claude identities can also be scoped to different use cases so that, for example, a sales Claude does not share its memories or tools with an engineering Claude.

The difference is in how those digital coworkers are provisioned and organized. Claude Tag’s documented workflow is administrator-led: admins pair Claude with Slack, decide which channels, tools and information each Claude identity can access, set spending limits and then expose those identities to employees.

Within a given channel, Anthropic describes “one Claude that interacts with everyone.” Its public documentation does not describe an end user asking that Claude to create several new, independently named Slack bots on demand. NanoClaw’s model is almost inverted.

After an organization connects its NanoClaw installation to Slack once, NanoClaw says an existing agent can itself provision additional agents from a conversational request, with each new worker receiving its own Slack bot identity, name, generated avatar and token and running back on the customer’s infrastructure.

OpenAI’s ChatGPT Workspace Agents occupy another point on that spectrum.

Business, Edu and Enterprise customers can build reusable agents in ChatGPT, give them instructions, models, files, apps, custom MCP connections and schedules, and then attach those agents to Slack channels.

Builders assign each agent a unique Slack handle and can configure it either to respond only when mentioned or to respond automatically to relevant messages in a channel.

But the construction still happens primarily through ChatGPT’s agent builder: OpenAI’s setup documentation tells users to create the agent first and then add Slack as a channel. Under the hood, the Slack handles rely on Slack user groups managed by the ChatGPT Agents app, rather than NanoClaw’s model in which every provisioned agent is itself a separate Slack bot.

Salesforce’s Agentforce similarly allows organizations to create multiple specialized agents that employees can DM or @mention inside Slack, and it arguably provides the most conventional enterprise administration model of the group.

Companies build the agents in Agentforce Builder, often starting from Slack-specific templates for jobs such as customer insights, employee help or onboarding, and can add subagents and actions that let them search information, create Canvases or perform other work.

Once configured and activated in Salesforce, administrators bring those agents into Slack for employees to use. That makes Agentforce powerful for organizations already centering identity, data and workflows on Salesforce, but again places agent creation before deployment rather than making creation itself something an existing Slack agent can perform during a conversation.

That distinction helps clarify what NanoClaw is actually adding to an increasingly crowded market. Slack itself now provides an Agent Kit for developers and a deployment standard for agents built on outside platforms, automating pieces such as OAuth, manifests and environment configuration. Claude Tag, ChatGPT Workspace Agents and Agentforce all demonstrate that persistent, specialized AI teammates inside Slack are no longer novel on their own.

NanoClaw’s more unusual bet is recursive provisioning: Slack becomes not merely the place where workers invoke agents, but a place where an existing agent can assemble additional named agents, assign them roles and put them together in a channel as a working team.

There are tradeoffs to the different approaches. Claude Tag comes with Anthropic-managed models and centralized administrative controls, including channel-specific permissions, audit logs and token-spending limits, while also offering proactive “ambient” behavior that NanoClaw’s supplied materials do not claim in the same way.

ChatGPT Workspace Agents offer a managed agent builder, schedules, app connections and organization-level publishing and access controls. Agentforce ties agents closely to Salesforce permissions, enterprise data and predefined business actions.

NanoClaw instead emphasizes self-hosting, open-source modification and separate agent identities, shifting more control — and more operational responsibility — to the organization running it.

The result is less a direct replacement for those systems than a different answer to the same emerging question: whether enterprises want a small number of centrally configured AI assistants, or an environment in which employees and existing agents can continuously create specialized digital colleagues as new work appears.

How NanoClaw got here

NanoClaw began far from the enterprise collaboration market. Cohen, a former Wix engineer, launched it under the MIT License on Jan. 31, 2026, as a deliberately small, security-focused alternative to OpenClaw.

The original pitch was that a personal agent with access to messages, files and tools should run inside an OS-isolated container rather than directly on the host, and that the orchestration layer should remain small enough for a developer or security team to understand — an initial core of roughly 500 lines of TypeScript and a design centered on container isolation and a minimal single-process architecture.

The project then moved steadily toward enterprise infrastructure. In March, NanoClaw partnered with Docker to run agents inside Docker Sandboxes, using stronger MicroVM-backed isolation for workloads that may install packages, modify files and launch processes.

In April, NanoClaw 2.0 added Vercel’s Chat SDK and OneCLI’s credential gateway, allowing organizations to define policies around sensitive actions and require human approval before credentials are injected for protected requests.

By May, Cohen and his brother Lazer Cohen had formed NanoCo around the project and raised a $12 million seed round led by Valley Capital Partners, with Docker, Vercel, monday.com and others participating. The commercial strategy is to keep NanoClaw open source while selling managed, organization-wide deployments and “professional assistant” infrastructure to enterprises. The company now says NanoClaw has surpassed 250,000 downloads and 30,000 GitHub stars.

That open-source structure remains central to Cohen’s pitch as NanoClaw moves deeper into workplace infrastructure.

“You’re really able to now integrate an open-source agent into Slack that you fully control,” he said. “You can change all those configurations. Plus, you can fork NanoClaw and completely rewrite or change behaviors — create your own memory system, your own coding harness, agent harness. Whatever you want to do, you can do. Total freedom.”

Persistent agents, but infrastructure stays under the user’s control

Cohen said NanoClaw remains self-hosted: an organization can run it on a local machine or its own cloud VM, with agent data stored there.

The same agent can also appear across Slack, WhatsApp or Telegram while retaining the same memory, workspace and tools, although each messaging surface uses a separate session.

NanoClaw can pull recent context across those sessions so the agent can maintain continuity without merging every chat history into one stream. NanoClaw’s documentation likewise describes a multi-channel architecture in which the same agent can retain one workspace and memory while maintaining separate per-channel sessions.

“This is all self-hosted,” Cohen said. “You’d be running this on your computer or on your virtual machine in the cloud, and that data is stored on your computer or on your [virtual machine] VM. This could be an open-source model running on your Mac Mini, and your data isn’t going anywhere besides your Mac Mini and then into Slack.”

The cross-channel continuity is also intended to make an agent feel less like a Slack-specific bot and more like a persistent colleague that happens to be reachable through Slack.

Cohen said the same agent could exist in Telegram, WhatsApp and Slack with access to the same memory, files and tools. The conversations remain separate sessions, but they share a workspace and persistent context so the agent can carry knowledge from one surface to another.

That architecture matters when an organization starts creating many agents. Cohen said one agent can see its own sessions across channels, but not another agent’s private sessions by default. NanoClaw’s current documentation likewise describes agents running in their own sandboxes and configurable model providers, with Claude Code as the default and Codex, OpenCode and local Ollama models available as alternatives.

There is one cloud dependency for the new Slack flow. Cohen said NanoCo operates a small service that handles Slack provisioning requests and avatar generation. He said it does not receive users’ messages or agent memory.

Continued commitment to open source

NanoCo is not charging for this community Slack capability, according to Cohen, and is absorbing the provisioning-service and avatar-generation costs. Users can still incur their own model inference and hosting expenses, so that does not make a deployed agent team cost-free in practice.

NanoCo says the integration is available through the Slack Marketplace, subject to normal workspace app approval and governance. Slack says workspace owners and administrators can require apps to be approved before installation.

Cohen framed that decision as part of NanoCo’s broader open-source strategy rather than a standalone monetization play. “We’re not making any money off this one. This one is for the community, really,” he said. “We know that in the long run that’s going to benefit NanoCo as a company. As NanoCo grows and builds out capabilities, those go back to the open source. I think that’s the new model of open source, where we’re not trying to monetize every bit of value we bring to the community.”

Whether companies get there that quickly will depend less on how easily agents can be created than on whether IT teams can govern their permissions, memory, spending and failure modes at the same pace. NanoClaw is betting that the next problem is managing the digital coworkers that appear once that barrier is gone.

Serval is making Catalyst, its AI agent for building enterprise automations, generally available Thursday and enabling it by default for customers — allowing teams of AI agents to decide what should be automated and then build the automation itself.

Catalyst sits above Serval’s AI-native service management platform as an admin-facing “super agent.” It can inspect ticket history, standard operating procedures or natural-language instructions, identify recurring work, and draft the workflows, skills, forms, access policies, journeys and dashboards needed to automate it.

Serval is also using Catalyst to create background agents that continuously inspect connected systems for emerging problems and propose fixes before an employee files a ticket.

That distinction matters because enterprise service management vendors are rapidly converging on AI-assisted workflow creation.

ServiceNow’s Build Agent can already translate natural-language instructions into full-stack applications, flows, scripts and other platform metadata, while its AI Agent Advisor can analyze instance records to identify automation opportunities. Atlassian’s Rovo can generate Jira automation flows from plain-English requirements, and Freshworks offers Freddy AI Agent Studio for creating service agents that act across Freshservice workflows.

So Serval’s claim to differentiation is narrower — and potentially more consequential — than simply “we use AI to build workflows.” Catalyst is designed as a single administrative layer that can move from discovering an opportunity, to assembling multiple kinds of governed automation, to creating proactive agents that keep looking for new work to automate.

"You just started with a single prompt, and now you’ve got enterprise-grade workflows ready to deploy that are going to solve all password resets for the entire company," Serval co-founder and CEO Jake Stauch told VentureBeat in an interview.

From ticket history to working automation

Serval says Catalyst analyzes existing help desk data before an organization has decided what to automate. If it finds a repetitive category of requests, it can draft the automation required to resolve those requests and stage the result for administrator review. Users can also upload an SOP or spreadsheet and ask Catalyst to turn the documented process into an executable system.

Serval’s documentation says Catalyst can build workflows, author help desk skills, create onboarding and offboarding journeys, configure access-management policies, construct dashboards, investigate operational issues and debug failed workflow runs. Unlike Serval’s earlier workflow builder, Catalyst is intended to become the primary interface for configuring the platform; the company says its long-term goal is that anything an administrator can do through the UI should also be possible through Catalyst.

The actual workflows are code-backed. In a demonstration, Stauch showed Catalyst taking a request to build password-reset workflows, detecting connected systems including Okta, Google Workspace and Microsoft Entra, and generating the underlying TypeScript needed to perform those actions. Administrators could then add approvals or restrict who was allowed to run the workflow.

The models underneath Catalyst are deliberately swappable

Serval is not building its own foundation model. Stauch said in the interview that the company uses models from “frontier labs,” runs evaluations to determine which models work best for particular jobs, and is deliberately model-agnostic. “You can swap different models in,” he said, adding that Serval also works with enterprises that build their own models.

Stauch provided more detail in a May 2026 interview with Sequoia Capital, saying Serval was using both OpenAI and Anthropic models. He said OpenAI’s GPT models had performed best for end-user interactions and tool calling, while Anthropic’s Sonnet and Opus models were producing the strongest results for the code-generation side of Serval’s automation system — the workload most directly relevant to Catalyst. Serval continuously runs evals rather than automatically moving every workload to the newest model release, Stauch said.

That architecture makes the underlying LLM less central to Serval’s differentiation. The company’s own documentation now lets organization administrators supply their own OpenAI or Anthropic API keys, including a compatible custom endpoint, while Stauch said the broader architecture can accommodate different models.

The materials do not, however, establish that every Catalyst user gets a self-service menu for arbitrarily choosing an individual model. Serval’s pitch is instead that its proprietary value sits in the harness around those models: enterprise context and memory, integrations, generated code, permissions, approvals and the controls governing what an agent can actually do.

That code-generation model is central to Serval’s pitch against ServiceNow. Stauch argues that legacy ITSM deployments often accumulate custom tables, business rules, workflows and platform-specific expertise that make seemingly simple automation changes expensive to implement. Serval, by contrast, wants administrators and business teams to describe the outcome they need and let the model generate the implementation.

But ServiceNow is no longer standing still on that front. Its current Build Agent similarly creates applications and code from natural-language prompts, supports flow design and testing, and operates inside ServiceNow’s governance framework. ServiceNow’s AI Agent Studio lets customers create agents and agentic workflows, while AI Agent Advisor is explicitly designed to analyze operational records for automation candidates.

The competitive question is therefore shifting from “who has generative AI?” to how many separate tools, configuration concepts and specialists are required to get from an observed operational problem to a production automation.

Serval is effectively arguing that Catalyst compresses those steps into one conversational surface and a smaller platform model. ServiceNow, by comparison, now has a powerful but broader set of AI and development surfaces spanning Build Agent, AI Agent Studio, AI Agent Advisor, Workflow Studio and AI Control Tower. That breadth is an advantage for customers already deeply invested in ServiceNow, but it also illustrates the complexity Serval is attacking. ServiceNow itself notes that Build Agent is aimed at admins and developers who understand and can support what it generates.

Atlassian is moving in the same direction from a different starting point. Rovo can generate “if this happens, then that happens” automation flows from natural-language descriptions, while Jira Service Management increasingly supports agents that triage, investigate and execute service work.

Freshworks’ Freddy AI Agent Studio likewise emphasizes agents that resolve requests end-to-end, with prebuilt IT and HR agents and more than 30 workflow templates.

Catalyst’s differentiator, then, is not that rivals cannot generate an automation from a sentence. It is Serval’s attempt to make the entire automation lifecycle itself agentic.

Building agents that look for trouble before a ticket exists

That approach becomes clearest with Serval’s background agents.

Rather than waiting for a help desk request, a background agent can run on a schedule across connected systems, correlate signals and draft a remediation. In one customer example provided by Serval, an agent correlated network incidents across two offices using switch telemetry, DHCP data and historical tickets, ruled out hardware and wireless interference, traced the issue to configuration drift, and generated a remediation workflow for an administrator to approve.

“Most AI agents today wait for an employee to ask a question or submit a ticket,” Stauch said. “We believe the future is AI that acts before an employee ever submits a request.”

That framing also highlights a philosophical difference in Serval’s pitch. The startup does not want service management to revolve around creating, routing and tracking better tickets. It wants the system to eliminate as many requests as possible by turning repeated support work into executable automation.

"A lot of the code written in enterprises has nothing to do with software engineering," Stauch explained. "It’s actually internal automations and other scripts for the company, and so we use that technology to build a better service management platform."

Serval's pitch to enterprises is that it can largely automate those scripts. And the governance model is critical because Catalyst can generate code and potentially initiate changes across production systems. Serval says Catalyst inherits the permissions of the user operating it and remains scoped to that user’s team workspace.

Everything it builds starts as a draft, and organizations can restrict publishing privileges or require formal review and approval before an automation becomes active.

Customer data remains customer-owned, with several deployment options

Those controls also extend to the enterprise data Catalyst examines. Stauch said Serval is intended to operate as the customer’s system of record and told VentureBeat that “they own all the data.”

Serval’s current Master Services Agreement is more precise: customers retain rights, title and interest in both their “Customer Materials” — a category that includes records, documents, workflows, prompts, inputs and configurations — and the output Serval generates from them. Serval receives the rights necessary to process that information to provide, maintain, support and secure the service.

Serval also says it does not retain or use customer materials, inputs or outputs to train, fine-tune or improve its own or third-party AI models.

Its Data Processing Addendum identifies Serval as the processor of customer personal data and allows processing for operating the service, responding to support requests, diagnosing issues and protecting the platform, while authorized subprocessors can also be involved. Serval’s acceptable-use terms say it maintains a current list of AI subprocessors and model providers for customers.

Where that data resides can vary by deployment. Stauch said customers can use Serval as a cloud SaaS service, run it on-premises or place it in their own VPC. Serval’s self-hosting documentation now describes two fuller options: a Serval-managed single-tenant deployment inside an AWS account owned by the customer, or a self-managed deployment on the customer’s Kubernetes cluster in any cloud or on-premises environment.

In the AWS option, Serval says it operates the installation without persistent IAM access to the customer’s AWS account.

There are therefore two distinct access boundaries for enterprise buyers to consider.

1. At the Catalyst level, the agent can only reach data, integrations and automations available to the user and team workspace under which it is operating.

2. At the platform level, Serval and authorized subprocessors necessarily process customer information to deliver and support the service, subject to the company’s contractual confidentiality and data-processing terms.

That makes Stauch’s informal statement that Serval “doesn’t touch” customer data better understood as an ownership and deployment claim, rather than a literal assertion that the service never processes it.

Ramp and other customers provide an early test

Customer deployments provide some evidence that the faster-build thesis can translate into operational changes, although the metrics come from Serval’s own case studies.

Corporate expense and financial technology firm Ramp says in a Serval case study that Catalyst has made workflow building 50% faster and helped extend Serval across roughly 10 teams, including IT, finance, facilities, people and talent, legal and business operations. In one hardware replacement program, Serval says Ramp automated 600 laptop replacements and saved 150 hours, leaving approval as the principal human step.

The more telling Catalyst example may be what happened afterward. Ramp had already automated laptop replacement when Catalyst suggested splitting its shipping logic into separate office and home workflows to reduce errors. The company also says employees outside IT now use Catalyst for analytics, bulk ticket operations, workflow troubleshooting and HR process automation.

Other Serval deployments show the broader operating environment Catalyst is meant to configure. Mercor says it has onboarded more than 4,000 external experts through Serval automations and expanded the platform across seven teams. Together AI says Serval automates 95% of its just-in-time infrastructure access requests, with approval and auditing controls around sensitive access. Perplexity says Serval automatically handles more than half of its incoming IT requests and all employee onboarding.

Those deployments extend beyond Catalyst itself, but they demonstrate the type of cross-system automation substrate Catalyst is now being asked to build and maintain.

Serval says more than 90% of customers adopted Catalyst as their starting point for automation during beta. Catalyst is generally available Aug. 20 and will be enabled by default for all Serval organizations.

Pricing and the battle with ServiceNow

Pricing is customized depending on the size of the deployment and is not publicly listed on Serval's website or documentation.

Serval describes a single platform fee and typically runs a pilot to determine expected deployment and usage.

Stauch said the software license can be similar to ServiceNow’s, but argues total cost of ownership can be substantially lower because customers require fewer implementation and maintenance services.

"The total cost of ownership is going to be dramatically less — usually half as much, sometimes 10 to 20% of the total cost of ownership of ServiceNow," Stauch said. "But the actual software license fee is not necessarily going to be all that different."

Serval's origin story and history

Serval was founded in 2024 by Stauch and CTO Alex McLeod, former Verkada product and engineering leaders, after they repeatedly heard IT customers complain about overburdened help desks and the limitations of established IT service-management software.

Serval has positioned itself as an AI-native alternative to platforms such as ServiceNow and Jira Service Management, combining help-desk ticketing, access management, asset management and workflow automation within a single system.

Serval and Sequoia Capital describe the company’s goal as moving IT software beyond merely recording and routing requests toward resolving them automatically.

The company can operate as an organization’s primary IT service-management system or add automation to an existing one. Its publicly identified customers include Perplexity, Mercor, Clay, Verkada and Together AI.

Serval says customers can automatically resolve more than half of their incoming IT requests; its Together AI case study reports automation of 95% of that customer’s just-in-time access requests.

Investor interest accelerated rapidly in late 2025. Serval announced a $47 million Series A led by Redpoint Ventures in October, bringing its funding at that point to $52 million.

In December, it raised another $75 million in a Sequoia-led Series B at a $1 billion valuation, lifting total capital raised to approximately $127 million; Redpoint, Meritech Capital and General Catalyst also participated.

Serval told Reuters that revenue had grown 500% since August 2025 and that it was expanding beyond IT into operational work performed by human resources, finance and legal departments.

The big test for enterprise customers

For enterprise buyers, Catalyst’s biggest test will be whether its compression of the automation lifecycle survives contact with large, messy, highly customized environments.

ServiceNow can now generate applications and discover automation opportunities with AI. Atlassian and Freshworks are adding increasingly capable agentic automation to their own service platforms. Serval therefore cannot rely on natural-language creation alone as its moat.

Its stronger wager is that an AI-native platform can make the administrative layer itself agentic: continuously finding repetitive work, building the necessary resources across the service stack, exposing generated code for review, and proposing the next automation before an administrator has opened a workflow designer.

If Catalyst works at that scope, the competitive unit is no longer the ticket — or even the workflow. It is the system that keeps turning an enterprise’s operational history into new automation.

Another day, another new AI agent harness is released.

Only this time, it's one that aims to solve a growing enterprise problem as AI agents proliferate: enabling greater developer control of agents and tools, while reducing cost.

TrueFoundry, a San Francisco B2B machine learning startup co-founded in 2021 by former Meta engineers, has released its own custom TrueForge harness under the permissive MIT License on Github. Thus, it can be used with any of a developer (or their parent enterprise's) preferred AI models, forked, modified, self-hosted and incorporated into commercial products.

The company states in a blog post that when it used TrueForge paired with the open source GLM-5.2 LLM to successfully complete 11 of 14 tasks on DevRev’s Enterprise-Bench — testing multi-step tool use across CRM, issue tracking, and document management systems — it cost 75% less than achieving the same results with Anthropic's Claude Managed Agents harness powered by Claude Opus 4.8 ($2.90 compared to $11.80).

Using the same model in each harness, Opus 4.8, TrueFoundry still claims a cost savings of roughly 30% using TrueForge compared to Claude Managed Agents ($8.50 vs $11.80).

Why is TrueFoundry giving this powerfully efficient harness away for free?

"We’ve had this ask from a bunch of customers," said Anuraag Gutgutia, TrueFoundry’s co-founder and COO, in an exclusive interview with VentureBeat. "You have an ability where you bring in agents and MCPs — can we also get something where you can actually launch these managed agents? I think that is the need we are satisfying. It is not a replacement. People will use this alongside other harnesses, like the cloud-managed ones or the commercial-provider-managed ones, but this will serve as a way for people to use them in a vendor-neutral way and also at a lower cost.”

Indeed, TrueFoundry already offers a paid "AI Gateway" for enterprises centrally controlling model and MCP access, credentials, permissions, budgets and observability. TrueForge, by contrast, handles what happens above that gateway: the loop that lets a model repeatedly reason, call tools, receive results and continue working until a task is complete.

For enterprise developers, the practical proposition is that they can start locally with a single command and SQLite, then move the same agent harness into a shared deployment using Docker Compose or Helm with Postgres and Redis.

TrueFoundry explicitly warns that the local configuration is intended only for use on a developer’s machine, not as an internet-facing production service.

Gutgutia said the company ultimately wants its AI Gateway to become the common layer beneath whichever agents and harnesses an enterprise chooses.

“There will be a set of companies that will use our harness as the way to launch managed agents,” he said, while others may continue using Claude, other open-source harnesses or internal systems. “But all that traffic should still be flowing through our gateway.”

Context management is where TrueForge tries to cut waste

TrueForge’s architecture centers on context engineering — controlling how much information gets sent back into the model on every step of an agent run.

That includes delaying the loading of MCP tool schemas until they are needed, delegating isolated tasks to subagents, moving oversized tool results into files instead of stuffing them into the active context window, processing structured results through code, and automatically compacting long-running conversations.

The documentation sets the default compaction threshold at 50,000 tokens, though it can be changed per agent.

TrueForge also treats the sandbox differently from runtimes that keep an agent inside an isolated environment throughout its run. The core agent loop remains on the TrueForge server; a sandbox is provisioned as a tool only when the agent needs to execute code or work with files. TrueFoundry says that reduces unnecessary compute and allows a server to run more agents concurrently.

The company argues those choices directly reduce model spending.

How TrueForge compares to Claude Managed Agents and other leading orchestration harnesses

Type / focus

• TrueFoundry TrueForge: General-purpose production agent harness designed for enterprise deployments.

• DeepSeek Harness: Open-source agent harness, currently positioned as a developer preview.

• OpenAI Codex CLI: Coding-focused agent harness designed primarily for software-engineering workflows.

• LangChain Deep Agents: General-purpose agent harness built on LangGraph.

• Anthropic Claude Managed Agents: Fully managed production agent runtime operated by Anthropic.

License

• TrueFoundry TrueForge: MIT.

• DeepSeek Harness: MIT.

• OpenAI Codex CLI: Apache 2.0.

• LangChain Deep Agents: MIT.

• Anthropic Claude Managed Agents: Proprietary.

Price

• TrueFoundry TrueForge: The open-source harness itself is free. Model, sandbox and infrastructure costs are separate. TrueFoundry also offers an optional commercial governance layer through its broader platform.

• DeepSeek Harness: No harness license fee. Users separately pay for whatever model providers and infrastructure they use.

• OpenAI Codex CLI: The CLI is open source. Underlying model/API or subscription costs are separate, OpenAI says around $100–$200 per developer per month, although actual spending varies substantially with model choice

• LangChain Deep Agents: Open source, with model and infrastructure expenses separate. LangChain also offers optional commercial services through LangSmith.

• Anthropic Claude Managed Agents: Claude tokens consumed plus $0.08 per running session-hour, with runtime metered to the millisecond.

Model flexibility

• TrueFoundry TrueForge: Vendor-neutral and designed around bring-your-own-model support.

• DeepSeek Harness: Multi-provider and not restricted to DeepSeek models.

• OpenAI Codex CLI: Supports configurable inference endpoints, including OpenAI-compatible services and local-model options.

• LangChain Deep Agents: Broad multi-provider support through the LangChain ecosystem.

• Anthropic Claude Managed Agents: Claude-centric.

Deployment

• TrueFoundry TrueForge: Can run locally as a single process with SQLite, then move into a production deployment using Docker Compose or Helm with Postgres and Redis.

• DeepSeek Harness: Designed for local or self-hosted operation.

• OpenAI Codex CLI: Primarily a local CLI experience, alongside OpenAI-hosted Codex products and services.

• LangChain Deep Agents: Can be self-hosted or deployed through LangChain and LangSmith infrastructure.

• Anthropic Claude Managed Agents: Anthropic manages the runtime and infrastructure.

Key features

• TrueFoundry TrueForge: MCP and tool orchestration, subagents, human approval checkpoints, persistent sessions, context compaction, large-result offloading, Code Mode, generative UI, tracing and a sandbox-as-a-tool architecture.

• DeepSeek Harness: Pluggable models, tools, session storage and agent loops, along with sandboxing, permissions, approval gates and skills.

• OpenAI Codex CLI: Agent loop, repository and file operations, shell execution, MCP tools, sandboxing, permissions, approvals and context management.

• LangChain Deep Agents: Planning, subagents, skills, filesystem-based context management, persistent memory, human-in-the-loop controls, MCP support and multiple sandbox backends.

• Anthropic Claude Managed Agents: Managed execution environments, persistence, tools, sandboxing and infrastructure for long-running agents.

Key differentiator

• TrueFoundry TrueForge: Its strongest distinction is the combination of an open-source, vendor-neutral harness with a clear path from local development to a shared production runtime, plus an optional enterprise governance plane through TrueFoundry.

• DeepSeek Harness: Emphasizes deep modularity. Major parts of the runtime, including models, tools, storage and the agent loop, are designed to be replaceable plugins.

• OpenAI Codex CLI: Stands out as a highly developed software-engineering-specific harness rather than a general-purpose enterprise agent server.

• LangChain Deep Agents: Benefits from the broader LangChain and LangGraph ecosystem and offers a mature open-source path for building general-purpose agents.

• Anthropic Claude Managed Agents: Minimizes operational burden by having Anthropic manage the runtime, but trades that convenience for tighter model and platform coupling.

Open source does not automatically mean governed

For enterprise buyers, one of the most important distinctions is between TrueForge by itself and TrueForge connected to TrueFoundry’s commercial AI Gateway.

The open-source harness can run independently. But it does not magically inherit an organization’s enterprise access policies on its own.

“If you are using just the open source version of our agent harness, yes, you will need to put the right controls therein or in front of some other internal control system,” Gutgutia told VentureBeat.

When paired with TrueFoundry’s gateway, the company says agents can inherit the identities and access controls already attached to models, MCP servers, tools, skills and other agents. Gutgutia described the gateway as the place where enterprise SSO, identity providers and granular permissions can be centrally enforced rather than reimplemented separately for every agent.

That distinction is likely to be important for platform engineering teams evaluating the project. TrueForge is free software; TrueFoundry’s governance layer is the commercial control plane around it.

TrueFoundry says NetApp was a beta user of the harness and contributed requirements during development. Gutgutia said NetApp’s IT organization has used the technology for incident response and faster ticket triage, while also exposing internal agents as self-service tools for developers. He also identified Automattic as an early user.

Background on TrueFoundry and its business to date

TrueFoundry was founded in 2021 to help enterprises deploy and operate machine-learning models, including Kubernetes-based model serving, training and infrastructure management.

Its three co-founders — Nikunj Bajaj, Abhishek Choudhary and Anuraag Gutgutia — previously worked at Meta and WorldQuant, respectively.

Gutgutia said the founders' common experience was working around mature systems where infrastructure and controls were designed to prevent costly mistakes — an idea they believed would become increasingly important as AI moved into production inside large companies.

As generative AI spread through enterprise software, TrueFoundry expanded from that MLOps foundation toward managing LLM applications and, increasingly, the models, tools and agents around them.

By 2025, the company had made its AI Gateway a central part of the business: a layer sitting between enterprise applications and model providers that handles routing, authentication, access controls, observability, budgets, guardrails and failover.

That evolution has been backed by roughly $21 million in outside financing. TrueFoundry raised a $19 million Series A in February 2025 led by Intel Capital, with participation from existing investors Eniac Ventures and Peak XV's Surge, as well as Jump Capital and angel investors including Gokul Rajaram and Mohit Aron. The round brought total financing to about $21 million, according to Intel Capital's announcement.

At the time, TrueFoundry said its customer base had grown fourfold year over year and that it was managing more than 1,000 clusters for machine-learning workloads.

The business has since become increasingly oriented around large-scale enterprise AI traffic. In VentureBeat's January 2026 coverage of TrueFoundry's TrueFailover launch, the company said it had more than 30 paid customers worldwide, had exceeded $1.5 million in annual recurring revenue during the prior year and was processing more than 10 billion requests per month through its AI Gateway.

Customers and deployments cited by TrueFoundry have included NetApp, Siemens Healthineers, ResMed, Automation Anywhere, Nvidia, Games24x7 and others; Gutgutia also named NetApp, Siemens, Synopsys and Automation Anywhere among Fortune 1000 organizations working with the company in his interview with VentureBeat.

TrueFoundry has also been expanding through acquisition. In June 2026 it acquired UK-based Seldon AI, a longtime MLOps vendor whose Seldon Core software has been used for production model serving and inference.

As the acquisition shows, rather than treating traditional ML, LLMs, tools and agents as separate infrastructure categories, TrueFoundry is trying to put them behind a common deployment and governance layer.

TrueForge extends that strategy upward into the agent runtime itself. Until now, TrueFoundry's commercial center of gravity has largely been the control plane underneath enterprise AI workloads — deciding which users and applications can access which models and tools, routing requests, enforcing policy, monitoring spend and keeping services available.

TrueForge gives the company an open-source runtime above that layer where agents can actually execute. Gutgutia described the relationship as complementary: organizations can run TrueForge independently or continue using other agent harnesses, while TrueFoundry's longer-term business opportunity is to provide the common governance and infrastructure underneath whichever agents enterprises choose.

Rob Strechay, until recently managing director and principal analyst at theCUBE Research, has joined VentureBeat as our first Lead Analyst and a founding analyst of VentureBeat Research. His arrival is the next step in a deliberate move at VentureBeat toward deeper specialization: analysis built for the technical decision-makers — the directors, VPs, CIOs, and CTOs — who are evaluating, buying, and deploying enterprise AI.

The enterprise AI stack is being rewritten in real time, and the decision-makers I talk with are starved for objective, defendable data. Rob Strechay has the mix of technical rigor and operating experience needed to dissect the architecture behind the next phase of enterprise AI deployment.

The questions enterprise technology leaders are asking have changed. As organizations move past experimentation with generative AI toward production deployment, they want to know how to orchestrate multi-vendor environments, where the security gaps in their agentic pipelines sit, and how to fix the utilization problems draining their infrastructure budgets. Answering those questions requires more depth than news coverage alone provides, and that is the gap this research offering is built to fill.

An analyst who has sat on every side of the table

Strechay brings nearly three decades of experience as a practitioner, product executive, and industry analyst. Before becoming an analyst, he was an executive at numerous startups, including Zerto; he joined Amazon Web Services to help build a new analytics service; and he held executive roles across enterprise infrastructure. He later served as a senior analyst at Enterprise Strategy Group and most recently as managing director and principal analyst at theCUBE Research and SiliconANGLE, where he hosted executive interviews and analyzed the evolution of cloud, data, and AI infrastructure.

Strechay will initially focus his coverage on cloud infrastructure, advanced data infrastructure, platform engineering and DevOps orchestration and observability, and the intersection points where AI and enterprise security collide.

Already at work: GPU utilization and the VB Pulse surveys

Strechay has already been contributing to VentureBeat's research. In May he published an analysis of enterprise GPU utilization, examining the compute waste sitting inside enterprise AI infrastructure, and he provided a substantive review of our AI Infrastructure & Compute survey before it went into the field.

His infrastructure-level focus complements the research engine VentureBeat has built around its monthly VB Pulse surveys, which track five areas of enterprise AI adoption: agentic orchestration, agent reliability and evals, agentic security and identity, AI infrastructure and compute, and context layers, including retrieval-augmented generation (RAG). Our June report on agentic orchestration, drawn from a survey of 145 enterprises, found that two-thirds of those enterprises had hedged their AI model strategy rather than committing to a single provider — a posture whose value the June outage of Anthropic's Claude models made plain.

VB In Conversation: The first vehicle

A core vehicle for this expanded research footprint will be a deepening of VentureBeat's existing VB In Conversation video interview series, which Strechay will host. Rather than high-level industry overviews, the series will bring architectural blueprints, actual deployment barriers, and back-end infrastructure realities to light through in-depth technical interviews with the architects and product leaders behind leading enterprise AI systems — an unvarnished look at which tools perform under production-grade pressure.

"VentureBeat has built an audience of enterprise builders and technology buyers that any analyst would want to serve," Strechay said. "My goal is to use deep empirical metrics and VentureBeat's proprietary tracking data to help enterprise buyers and the people building for them make sound platform and infrastructure decisions during the most disruptive transition enterprise technology has seen."

The expanded VB In Conversation series will appear on VentureBeat and on VentureBeat's YouTube channel, alongside Rob's written analysis on the site. Enterprise practitioners who want to take part in our monthly VB Pulse surveys, or arrange an analyst briefing with Rob, can reach the research team here.

After a stunning debut last week with cyber capabilities so advanced they reportedly found a previously undetected vulnerability in Cursor, GLM-5.3, the new frontier open source language model from Chinese startup z.ai, has now hit the application programming interface (API) — allowing developers the ability to build atop it and plug it into their agents and applications.

Developers who previously subscribed to a GLM Coding Plan are currently limited to the OpenAI Chat Completions-compatible protocol. Z.ai said it plans to make the model's weights openly available, but a precise date and licensing remain to be seen.

On the API, the price is unchanged from GLM-5.2: $1.40 per million input tokens and $4.40 per million output tokens. Cached input costs $0.26 per million tokens, while Z.ai currently lists cached-input storage as free for a limited time.

That means developers can move to the new generation without taking a higher posted per-token rate from Z.ai, even as the company claims substantially stronger coding and long-horizon agent performance. At those rates, GLM-5.3 sits well below several of the highest-end frontier APIs.

Using the simple VentureBeat comparison of one million input tokens plus one million output tokens, GLM-5.3 comes to $5.80, versus $8 for Grok 4.6 at its lower context rate, $18 for Kimi K3, $30 for Claude Opus 5 and $35 for GPT-5.6 Sol.

That is not a workload-cost estimate — real bills depend heavily on the input/output mix, caching and token consumption — but it makes the relative API price tier easy to see.

GLM-5.3 is not the cheapest capable model available. Google’s current introductory price for Gemini 3.7 Flash is $0.75 per million input tokens and $3.75 per million output tokens through Dec. 31, 2026, while OpenAI’s GPT-5.6 Luna is priced at $0.20 input and $1.20 output.

Still, Z.ai’s price puts GLM-5.3 into a notably lower cost band than the premium frontier models it is increasingly benchmarked against.

That comparison has become more relevant following the latest independent results. Artificial Analysis gives GLM-5.3 a score of 60 on its Intelligence Index, tying Kimi K3 as the top performing open weights model in the world, and scoring seven points higher than GLM-5.2.

Its analysis also estimates GLM-5.3 at about $0.68 per Intelligence Index task, versus roughly $0.44 for GLM-5.2, despite the identical API token prices.

The difference underscores an important caveat in headline API pricing: Artificial Analysis found GLM-5.3 more verbose than its predecessor, so flat per-token rates do not necessarily mean flat costs for a completed workload.

For developers, though, the immediate change is straightforward: GLM-5.3 is now callable through Z.ai’s API at the same $1.40/$4.40 per-million-token rate as GLM-5.2, giving teams another relatively low-cost option for testing frontier-class coding and agent workloads.

Block, the technology company founded by former Twitter CEO Jack Dorsey that owns Square, Cash App and the music streaming service Tidal, is open-sourcing Berd, a desktop application it originally built to give its own employees a single environment for working with AI agents across different models, tools and projects.

Berd is a locally installed graphical desktop application rather than a browser-based workspace. It is available now on GitHub under a permissive Apache 2.0 license — meaning anyone can use, modify and redistribute it, including commercially — with free downloadable builds for macOS, Windows and Linux. The repository reached version 0.6.2 on Aug. 18, its seventh public release, and lists 91 contributors.

“Berd is desktop-first because much of its value comes from working directly with projects, local files, tools, repositories, and agents running on or connected to the user’s computer,” Brad Axen, Head of AI Capabilities at Block, told VentureBeat in emailed responses.

A daily work surface for AI agents

Block positions Berd as a “daily AI work surface”: a single place where users can start chats, attach files or folders, choose agents and models, work inside persistent projects, configure AI providers, manage skills and extensions, review session history and build automations.

The design goal is not merely convenience. According to Berd’s product specification, users should always be able to tell which project, files, agent, model, provider and session state are actively shaping a conversation. That emphasis on visible operational state is what Block says separates Berd from a generic chatbot wrapper. Configuration — providers, extensions, skills, automations, projects — is treated as part of the workflow rather than buried in an administrative layer, and the interface is designed to expose failures, unavailable providers, and loading and streaming states plainly rather than smoothing them over with assistant-style friendliness.

Berd grew out of a practical problem inside Block. Employees were already working with capable agents — Block’s own Goose, Anthropic’s Claude Code and OpenAI’s Codex — but the experience around them had become fragmented.

“We had capable agents through goose, Claude Code, and Codex, but working across them meant navigating different interfaces, configuration systems, and ways of managing context,” Lucinda Bell, Technology Communications at Block, said in an email. Berd, she said, gives Block teams “one consistent desktop application across models and harnesses.”

For enterprises, that layer may matter as much as another incremental gain in model capability. Persistent projects mean users can return to an established collection of files, instructions and agent configurations instead of reconstructing context for each task. Block also explicitly designed Berd to make agentic work accessible beyond engineering, letting people start with a conversation and add tools, context and structure as the work requires.

Block is not positioning Berd as a mobile product. Axen said the company’s open source collaboration platform Buzz already provides a mobile experience and is Block’s preferred environment for work on the go.

Block thinks agents should look different when they are different

Berd takes an unusual approach to a problem most enterprise AI products leave implicit: how users tell one configured agent apart from another.

Instead of treating every agent as another blank chat window, Berd gives agents roles, instructions, skills, tools and recognizable visual identities. Block created collections of animated characters — its flagship designs are called “Gloopies” — and Berd’s public site showcases predefined personas such as Berdy, Pushback, Choosey, Copycat, Tinker and Wildcard, each built around a different style of work: Pushback plays devil’s advocate on drafts, Choosey helps narrow decisions, Copycat learns to write in the user’s style.

The visual layer is not meant to substitute personality for substance. Block’s own formulation, from a company blog post on Berd’s design, is functional: “The avatars make the agent recognizable. Its role, skills, and tools make it useful.”

That distinction could grow more important as workers juggle several specialized agents at once. A recognizable identity serves as visible shorthand for an otherwise invisible package of instructions, tools and permissions — agents appear on the workspace as distinct animated characters rather than identical entries in a chat list, so users can tell them apart before opening a conversation.

The product specification guards against the characters turning Berd into a novelty. It describes the intended personality as “focused, capable, companionable,” while explicitly rejecting toy-like presentation, oversized decorative UI and interfaces that hide operational state behind friendliness.

An orchestration layer, not another model or agent runtime

Architecturally, Berd is neither a new foundation model nor a new agent runtime. The application is built with Tauri 2 and React 19 — frameworks for building lightweight desktop apps with web technologies — and communicates with Goose, the open source agent framework Block introduced in January 2025, through a standard called the Agent Client Protocol (ACP). Goose runs quietly alongside Berd as a bundled “sidecar” process and handles the underlying agent loop; Berd handles projects, sessions, context, agents and configuration on top.

For readers unfamiliar with it, Goose is a model-agnostic agent framework and runtime, originally focused on software development workflows. It connects large language models to files, commands and outside systems — including through the Model Context Protocol (MCP), an open standard for wiring AI systems to external tools and data — so agents can take actions rather than merely generate text.

Goose works with proprietary model providers as well as locally run open models. Block has since contributed Goose to the Agentic AI Foundation, the Linux Foundation body it helped establish with Anthropic, OpenAI and others in December 2025, giving the framework a vendor-neutral home alongside MCP.

Axen drew the boundary explicitly: agent harnesses such as Goose, Claude Code and Codex manage the loop between a model, its context and its tools, while Berd provides the consistent desktop environment around those harnesses. In the public release, users configure whichever providers and harnesses they want rather than inheriting a Block-selected model stack.

The project’s README adds an operational detail that matters for anyone evaluating the software: Berd does not simply pull whatever Goose build happens to be current. Its build process pins a specific Goose backend version through a lockfile, verifies the cached binary matches that pinned version, and packages it with the app. Developers can explicitly substitute another Goose binary for local testing. For organizations inspecting Berd, that creates a defined version boundary between the desktop application and its default agent backend rather than letting the backend silently drift.

How Berd compares to Codex, Claude Code, Cursor and Goose

That separation matters because the agent-tooling market is already converging on products that manage increasingly autonomous AI workers. OpenAI describes its Codex app as a “command center” for agents, with separate project threads and multiple agents operating in parallel.

Claude Code, Anthropic’s agent for reading codebases, editing files and executing commands, now spans the terminal, IDEs and a desktop app. Cursor describes its latest release, Cursor 3, as a unified workspace for software development with agents, including handoffs between local and cloud agents and multi-repository workflows. And Goose itself remains available directly, as a free command-line tool and desktop app for technically comfortable users.

Berd’s differentiation is therefore less about inventing the agent workspace than about making that workspace open source, multi-harness and potentially useful outside coding. Every other product in the table below is either tied to a single vendor’s models, priced as a subscription, or aimed squarely at developers — and in most cases all three.

Portability is part of Block’s pitch. Axen said much of the underlying work in Berd is deliberately kept portable: folders, Git repositories, files and plain-text instructions remain accessible outside the application; skills are file-based; and Berd agents can be exported and shared between Berd users with their instructions and settings intact.

He pointed to ACP and MCP as part of Block’s direction toward “clear, user-owned formats and open protocols wherever possible.” That does not make every piece of state interchangeable across every harness, but it makes portability an explicit architectural goal rather than a side effect of using local files.

Local-first data, telemetry and enterprise distributions

Berd is designed around a local-first data model. Axen said conversation history is stored on the user’s device in the local Goose session database, while credentials live in the operating system keychain by default.

That does not mean all AI processing happens locally. “Local-first does not mean that no data ever leaves the device,” Axen said. When a user asks a configured model to work on particular context, the relevant prompt and material are sent to that model’s provider — so the actual data path, and the contractual terms governing it, depend on which provider an organization chooses.

Telemetry — the usage data software sends back to its maker — is disabled by default in official Berd distributions. If a user opts in, Block says it collects a random installation identifier and a limited set of predefined usage events, while excluding prompts, messages, files, source code, credentials, names, email addresses and IP addresses from the telemetry payload itself (Block and its service providers still process IP addresses for transmission, security and rate limiting). Users can switch telemetry off again in settings. Block cautions that third-party forks can modify or redirect the telemetry system, so enterprises evaluating a customized build need to review that build’s actual behavior rather than assume Block’s defaults carry over.

The public repository builds a self-contained, general-purpose distribution that does not depend on private package registries or enterprise credentials — technical teams can build and evaluate it without access to Block’s infrastructure. But Block has also created what it calls “distribution seams”: defined points where organizations can overlay managed provider settings, private agents, runtime configuration, optional companion tools, their own update channels and their own signing and publishing infrastructure, all without adding private material to the public source tree.

Block’s own deployment shows how an enterprise can put governance around that architecture. Axen said Block runs its managed distribution on approved devices using approved model-provider infrastructure, managed configuration and governed tool connections. “The application can remain open and inspectable, while an organization decides which models, tools, permissions, and policies are appropriate for its environment,” he said.

One caveat: “enterprise distribution” should not be read as a complete enterprise management plane. The README does not describe capabilities such as single sign-on, centrally enforced administrator policies, organization-wide permission controls, data-retention rules or audit logs. It establishes that companies can customize and distribute Berd; it does not by itself explain how those installations are centrally governed after deployment. Berd should be understood as endpoint software installed on users’ computers, not a centrally hosted SaaS product.

Pricing, models and a closed contribution model

Block has not announced a subscription price for Berd, and there is no indication one is coming. That does not make agent usage costless: organizations still pay whatever model, API or provider charges they incur. The economic pitch on Berd’s site is flexibility — users can match the model to the job rather than paying for an expensive frontier model on every task. As the site puts it: “Some tasks need the big brain. Most don’t.”

Neither Block’s announcement nor the README provides a definitive matrix of supported model providers or recommends particular models. Internally, Block does not treat any one model as a permanent default: Axen said the company’s managed distribution exposes employees to “a curated mix of frontier and open-weight models,” with the catalog changing as models improve. “The best choice depends on the work,” he said.

There is also a governance distinction developers should note. Although Berd’s source is public and Block solicits issues and feedback, the repository does not accept outside pull requests — external code contributions are automatically closed.

The README says Berd is built by “a small team at Block” and directs outside participants toward well-formed, reproducible bug reports instead. Users are free to inspect, build and fork the code, but Block retains a tightly controlled upstream. For companies considering Berd as infrastructure rather than an experiment, that makes Block’s long-term maintenance and support plans worth clarifying.

Block is not presenting Berd as a revenue product today. Axen said the first return on investment comes from Block’s own use of the software — making internal agent work more consistent while teaching the company how employees actually use agents — and that open-sourcing it adds leverage by letting outsiders inspect, adapt and give feedback on the architecture. A commercial layer around enterprise deployment may eventually follow.

“Supporting organizations that want to deploy agents at work is an area of interest for us,” Axen said, adding that Block will share more when there is more to share.

From private agent work to multiplayer workflows

Berd supplies the individual desktop experience; another Block project, Buzz, focuses on shared rooms where people and agents collaborate against a common, searchable record.

Buzz is Block’s free, Apache 2.0-licensed collaboration workspace for humans and AI agents. Built on the decentralized Nostr protocol, it combines familiar team features — channels, threads, direct messages, voice and media sharing — with agents that hold their own cryptographic identities and defined permissions, and that can participate in conversations, code review and approved automated workflows. Unlike Berd’s local, single-user focus, Buzz is explicitly multiplayer, and can be self-hosted or used through Block-hosted infrastructure. It is likewise model- and harness-agnostic: teams can bring agents powered by Goose, Claude Code, Codex or others.

Axen framed the split between the two products partly as a question of trust boundaries. “A local agent may have access to your filesystem and credentials,” he said. “An agent in a shared Buzz room has its own identity and access scoped through the relay.” Berd begins with one person and comparatively privileged access to that person’s machine; Buzz begins with multiple participants, explicit identities and shared-workspace permissions.

The more consequential roadmap detail is that Block does not intend the two products to remain separate. “Going forward, our focus is Buzz, and we plan to bring the best parts of Berd’s single-player experience into it,” Axen said. Block wants work to begin privately and become collaborative without users switching tools or rebuilding context, with cross-device continuity — including mobile via Buzz — part of that ambition. In the meantime, Axen said, Berd remains available as an open source desktop application, but Buzz is the product Block encourages people to download and adapt.

What enterprise adopters should take away

The short version for IT and security teams: conversation history stays local by default; credentials use the operating system keychain; context sent to a model leaves the machine on whatever terms the configured provider offers; official telemetry is off by default and excludes prompts, files and source code; and organizations can package their own governed distribution — though central management tooling is not yet documented.

The larger idea behind the release may matter more. Models and coding agents are becoming increasingly interchangeable components inside larger workflows. Berd is Block’s bet that the surrounding context — the projects, skills, tools, identities and persistent working environment — becomes the stable layer instead.

Enterprises that already got burned by an AI agent passing its evals and then failing in production are moving faster toward removing humans from deployment decisions, not slower — even as trust in automated evaluation is rising across the board, new VB Pulse research shows.

In July, 13% of 108 enterprises surveyed said they trust automated evaluation, up from just 5% the month prior. Meanwhile, survey respondents citing poor alignment between tests and real-world results as their biggest concern fell 10 points, from 29% to 19%, month over month.

Yet, 49% of survey respondents said that an AI agent or LLM-powered feature that had cleared company testing subsequently created a problem visible to customers, essentially unchanged from 50% in June. And nearly a quarter, 24%, said this troubling outcome had occurred more than once.

The latest findings from VentureBeat Intelligence uncovered a more troubling phase of the enterprise agent rollout: the gap is no longer only between how much autonomy companies give agents and how well they can verify them. It is increasingly a gap between confidence in the evaluation layer and evidence that the layer is getting better at preventing failures.

The most revealing split appears inside the July data.

Of the enterprises that experienced an AI feature clear testing only to go on to disappoint a customer, 4% placed complete faith in automated checks. Of those that had detected no comparable incident, 24% expressed full confidence — a sixfold difference.

It makes sense: those who experienced test-passing agents failing in live production are, unsurprisingly, more likely to doubt the automated checking process.

Perhaps it makes sense then, that companies geared toward tackling this problem — like automated agent error monitoring and mitigation platform Raindrop.ai — are seeing the market transform wildly from just a few months ago.

"We are seeing the great-decline of evals as we know them," Raindrop CTO Ben Hylak told VentureBeat in a direct message. "The Fortune 100 are increasingly reducing eval sets and deprioritizing maintenance. As systems grow more complex (MCPs, subagents, etc.) it becomes impossible to fully enumerate the failure cases. Instead, they’re leaning on anomaly and issue detection solutions, both before and after production."

A directional finding, not a market census

VentureBeat fielded the July wave among 108 people representing companies with workforces of at least 100. This is down from 157 respondents in June.

Of the 108, 69% described themselves as final AI-buying authorities or people who recommend and influence those purchases. The sample skewed toward midsize organizations: 63% worked at companies with 100 to 2,499 employees.

The findings should be read directionally. The survey is self-selected rather than a probability sample, and the burned-vs.-unburned splits cited throughout this piece rest on groups of 41 to 53 respondents, and other cross-tabs in the report range from 40 to 68.

The industry mix also changed: technology and software participation declined nine points, ending at 14%, while the retail and consumer share added four points and ended at 19%.

The report nevertheless identifies four month-to-month changes worth noticing: more respondents professing complete confidence, fewer naming poor real-world alignment, more choosing integration ease as the decisive buying factor, and Braintrust gaining primary-platform share.

Confidence in automated evals improved, but outcomes stayed flat

VentureBeat's June research identified an enterprise evaluation gap: companies were granting agents more authority faster than they were developing reliable ways to test them.

July preserves the key number from that first wave. Across 265 enterprise responses over the two months, the proportion reporting at least one test-approved system that disappointed customers stayed within a single percentage point: 50% in June and 49% in July.

This figure does not mean that 49% of all agent runs fail, or that any particular evaluation product has a 49% failure rate. The survey asks whether an organization experienced at least one customer-facing incident in the previous year after an AI feature passed its internal tests. Companies that deploy far more agents have more opportunities to encounter such an incident.

But that limitation does not make the result less important. An internal evaluation serves as a release gate. If roughly half of surveyed organizations have seen that gate approve a system that later fails in front of customers, a passing score cannot be treated as proof of production reliability.

The cross-tab reinforces the point. Ten of the 41 enterprises with no identified testing miss placed complete faith in automation.

Only two of the 53 previously burned enterprises said the same. Confidence is strongest among respondents with the least evidence that the release gate can fail.

The enterprises that got burned are moving faster toward zero-human deployment

The counterintuitive finding is what companies do after an evaluation miss.

Overall, 67% either let an agent push code or change a system without a person's approval in certain low-risk cases, or are modifying their pipelines to support that practice during the coming year. That is unchanged from June. In July, 37% already permitted it in limited cases and another 30% were building toward it.

Among enterprises where a test-approved system had disappointed a customer, however, 85% were pursuing that no-approval model, compared with 61% in the group reporting no comparable incident. Only 11% of burned respondents rejected end-to-end deployment automation for the years ahead, versus 24% of unburned respondents.

It would be easy to read that as recklessness, but the data supports another plausible explanation: deployment maturity. Organizations running more agents, at higher volume and across more consequential workflows, are more likely both to encounter failures and to have the engineering infrastructure needed for automated deployment.

The survey cannot establish which explanation dominates. It does establish that a customer-visible incident does not appear to stop the move toward autonomy. Respondents with firsthand proof that testing can miss defects are also moving most aggressively to let those tests authorize production changes.

If their per-deployment failure rate remains constant while deployment volume rises, the total incident count could grow even without the percentage of affected companies increasing. The July data does not measure incident volume, so that remains a risk implied by the pattern rather than a measured outcome.

The release gate is automated, but production quality monitoring still lags

Pre-deployment evaluation and production monitoring answer different questions. An evaluation asks whether an agent appears ready to ship. Production monitoring asks what the agent is doing after release and whether its live outputs remain correct.

Most companies in the July sample still emphasize whether the system functions, not whether the answer is correct.

Among the 106 valid responses to this question, 26% used inline quality assertions — automated judges or guardrails checking live traffic for output-quality problems. Another 26% focused on transaction traces such as infrastructure spans, token usage and raw inputs and outputs, while 24% mainly tracked gateway metrics such as latency, errors and cost.

Trace and gateway data can reveal outages, slowdowns and broken requests. They may not flag a fluent, fast and confidently wrong answer. Grouped by the report according to what each architecture actually watches, half of respondents monitored whether an agent was functioning, while just over a quarter automatically monitored whether its production output was correct.

The gap is sharpest among the 40 respondents already permitting no-approval deployment in limited cases. Only 28% of that group automatically checked the meaning and correctness of live answers. In other words, most enterprises that have eliminated a person from at least some release decisions have not installed automated semantic-quality monitoring as the production backstop.

This is the clearest operational lesson in the data. A pre-deployment test suite and infrastructure observability are necessary, but they do not cover the same failure mode. Enterprises need a way to detect bad outputs after the agent begins interacting with real users, data and tools — especially when nobody reviews the deployment decision first.

An independent agent-evaluation market begins to take shape

The vendor data offers a more encouraging sign: enterprises are adding dedicated evaluation tools, and specialist platforms are gaining ground.

OpenAI's native evals and traces narrowly led as the primary platform at 18%, followed by Confident AI's DeepEval at 17% and Braintrust at 15%.

Anthropic's Claude Console and Workbench held 12%, tied with organizations reporting no dedicated evaluation platform. Three options each held 6%: internally built tools, Promptfoo and LangSmith.

Braintrust's primary share increased from 8% in June to 15% in July, the biggest gain by one vendor and the one the report flags as statistically significant. DeepEval rose from 12% to 17%. Use of no purpose-built platform declined five points to 12%, although that smaller change does not by itself confirm a trend.

Because many companies use more than one tool, the broader footprints are larger. OpenAI native evaluation appeared somewhere in 31% of stacks, DeepEval in 27%, Braintrust in 22% and Anthropic's native tooling in 20%. Custom internal tooling reached 14%, while Weights & Biases Weave and open-source Langfuse each reached 11%.

These are adoption figures, not product-performance scores. The survey does not establish that one vendor produces more reliable agents than another. Still, the results point toward evaluation becoming a distinct enterprise software layer rather than a loose collection of internal scripts or a feature used only inside a model provider's platform.

Purchasing priorities are changing with that market. The proportion choosing integration ease as the decisive factor climbed 12 points to 39%, displacing cost, which fell from 28% to 23%. Evaluation accuracy ranked second at 28%. The combined average for satisfaction, implementation simplicity and economic value was 3.9 out of five.

The move from price toward integration suggests enterprises increasingly want a tool they can install into existing development and monitoring pipelines now. Yet their leading success metric remains evaluation consistency at 38%, followed by fewer failures and regressions at 20%. Buyers are selecting for fit while still judging results on repeatability.

Switching intent also cooled: 56% still expected to add or replace a platform during the coming year, down from 64% in June.

The proportion staying put increased eight points, reaching 44%. Together with specialist adoption, they suggest some buyers are moving from evaluation to implementation.

Human review is becoming the hedge against automated misses

The budget data reveals how enterprises are managing the contradiction between greater autonomy and unreliable evaluation.

People-centered review workflows edged narrowly ahead of production observability as the most frequently cited area for increased investment, 31% to 30%.

Automated evaluation pipelines ranked third at 19%, followed by testing for safety and policy compliance at 16%. Only 6% said their reliability and evaluation budget was not increasing.

Among enterprises that had experienced a testing miss, 38% said people-centered review would receive the fastest investment growth, compared with 24% of organizations that had not been burned.

That produces an apparent paradox: the burned group is most likely to remove people from the release checkpoint and most likely to increase spending on people elsewhere in the process. The strategy appears to be automation with a human backstop — allow agents to move faster, then use reviewers to catch what automated evaluation misses.

The open question is whether that model scales. Agent deployments and automated checks can grow with software volume. Reviewer hours do not fall at the same rate. Enterprises may therefore be replacing a human approval step with a larger downstream review function rather than eliminating human oversight.

The narrow but consequential read

July's data does not show that enterprise agent evaluation is failing everywhere, nor does it prove automated judges are getting worse. It shows something more precise: confidence rose before the measured failure incidence improved.

At the same time, the infrastructure around evaluation is maturing. More enterprises are adopting specialist tools, integration has become the leading purchase criterion and companies that have already experienced failures are increasing investment in human review. The market recognizes the problem and is spending against it.

But the central reliability result remains stubborn. Nearly half of surveyed enterprises still report that an AI feature cleared internal checks before disappointing a customer. Respondents with that experience place less faith in automation — and move faster toward deployments with no human approval.

The report frames this as an incomplete verification model: a passing pre-deployment score marks the start of monitoring, not the end of it. For most enterprises, the production quality checks and evaluation testing that would close that gap still aren't in place.

Presented by Rezolve Ai

Enterprise AI investment in commerce has never been higher. And enterprise AI outcomes in commerce have rarely been more inconsistent. That gap is not a coincidence. It is the predictable result of a pattern that has repeated itself across every major technology shift in retail: the industry adds new capabilities faster than it integrates them.

That pattern is now playing out in commerce AI.

The point solution pattern

The dominant approach to commerce AI over the past three years has been an additive one. Brands have layered AI-powered search on top of existing catalog infrastructure. They have added conversational interfaces on top of existing checkout flows. They have deployed recommendation engines alongside personalization tools that were themselves deployed alongside earlier recommendation engines. Each addition was justified by a discrete metric improvement, and none were designed to work as a cohesive system.

This is the point solution pattern, and commerce has lived inside it for two decades. It produced genuine progress in isolated capabilities: faster search, better recommendations, lower friction at specific points in the journey. What it did not produce is coherence across the journey. Consumers experience that incoherence as inconsistency, context loss, and the feeling that each part of the shopping experience doesn't know what the others are doing.

AI amplifies the cost of that incoherence. When a general-purpose AI tool makes a recommendation based on incomplete or inconsistent data, it doesn't surface a suboptimal product. It confidently surfaces the wrong one, and often excludes the incomplete one altogether. The hallucination problem in commerce AI is largely a data coherence problem in disguise. Tools that don't share a common understanding of inventory, pricing, policy, and product truth will produce outputs that contradict each other and mislead consumers.

Where the metrics lie

The fragmented approach to commerce AI creates a specific kind of reporting problem: individual tools perform well in isolation while the system underperforms in aggregate.

A conversational AI tool can show strong engagement metrics. The search layer can show improved relevance scores. The checkout system can show reduced abandonment within its own funnel. None of these metrics captures what happens at the handoffs between them, where context breaks, sessions drop, and purchase intent that was successfully generated in one layer fails to convert in the next.

This is why brands investing aggressively in commerce AI are sometimes reporting strong tool-level performance alongside flat or declining overall conversion. The tools are working. The system isn't. And the standard analytics stack, built to measure individual touchpoints rather than journey coherence, will not surface that distinction.

Bain research shows that organic web traffic to retail sites has declined 15 to 25% as AI-driven zero-click search has grown. Brands are losing top-of-funnel visibility to AI disintermediation at the same time their internal AI tools are generating positive performance reports. That combination — external pressure compressing the funnel while internal fragmentation leaks it — represents a structural problem that point-level optimization cannot solve.

What separates the companies closing the gap

The brands that are generating consistent, measurable outcomes from commerce AI share a common architectural characteristic: they have built or adopted a unifying execution layer that sits across their AI investments rather than beneath them.

This isn't a new technology category. It is a different design philosophy. Instead of asking what AI capability to add next, these brands have asked what the connecting tissue between AI capabilities needs to look like in order for those capabilities to produce a coherent consumer experience and a reliable transaction outcome.

The answer, in practice, involves three things: a shared data layer that gives every AI tool in the stack access to the same real-time product, pricing, and inventory truth; a policy and governance framework that ensures AI-generated recommendations operate within the brand's established rules; and a transaction layer that can receive intent from any AI surface and convert it into a completed order without breaking context or requiring the consumer to restart.

Brands that have those three things in place are not just getting better results from individual tools. They are compounding improvements across tools, because each capability in the stack is operating on consistent inputs and contributing to a coherent output.

The architectural question commerce can't defer

The window for treating commerce AI fragmentation as a temporary problem is closing. As agentic commerce matures and AI systems begin to initiate and complete transactions on behalf of consumers, the stakes of incoherence rise significantly. An AI agent acting on behalf of a consumer doesn't have the patience to navigate a broken handoff between a recommendation layer and a checkout system. It will fail, and it will not return.

The brands that establish architectural coherence now, before agentic transactions become the norm, will enter that era with a compounding advantage. Those that continue to add point solutions will find that each new tool adds a new potential point of failure.

Commerce AI isn't fragmenting because the tools are bad. It is fragmenting because the connective infrastructure was never built. The brands that recognize that distinction — and act on it — are the ones that will define what commerce looks like in the next decade.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

Enterprise teams running AI agents at scale are finding that a single model handles every task poorly — either the model is too expensive for simple questions or not capable enough for hard ones. Model routing, which picks the right model for each task automatically, is becoming the fix.

Snowflake’s Cortex AI Gateway now offers dynamic model routing to address that: enterprises can select “auto” instead of a fixed model, and the system routes each task to whichever model offers the best combination of quality and cost. Snowflake said the capability can cut token costs by as much as 3x on some workloads — a figure from the company’s own internal testing — after finding that simple questions were often handled by its most capable model, making responses more expensive and slower than necessary.

The move lands amid a broader industry shift toward automated model routing. Databricks, AWS, Google Cloud and Nvidia have all announced some form of model routing technology. Snowflake argues that model routing is more complex than just price and performance, it's also about governance and context.

"For high quality, enterprise grade agents to be built, it's crucial to get the context and the governance right," Baris Gultekin, vice president of AI at Snowflake, told VentureBeat. “Context, trust and model choice all go hand in hand."

Two mechanisms decide where a task goes

The capability builds on Cortex AI Gateway, which Snowflake launched in July 2026 as a governance layer for agent and model traffic. Before dynamic routing, model selection ran off a static list per task rather than a true fallback system, Gultekin said.

Dynamic routing itself runs on two mechanisms, according to Gultekin.

A small model tries first. Under what Snowflake calls an advisor pattern, a smaller model attempts a task first. If it cannot finish the job, it calls a larger model as a tool and continues from there.

A classifier sorts by task history. A separate classifier, trained on past queries, automatically routes straightforward questions to simpler models.

Customers can still pin a model. Auto routing is optional. Customers can restrict routing to one model or a defined set of models, and the system routes only within that boundary.

There is no separate fee. Snowflake prices AI purely on token usage. Routing to a cheaper model produces a cheaper bill, with no additional charge for the routing decision itself.

Access controls follow the task, not just the data

Snowflake ties routing to the same access controls it already uses for data governance.

Governance starts at the data level with role-based access controls. It extends to models next, where customer roles map to buckets of approved models. It extends again to agents, where an agent can be restricted to narrower privileges than the user invoking it.

Open models can run from a customer's own region to satisfy data residency requirements. Gultekin said all inference, open and proprietary alike, stays inside Snowflake's security boundary rather than routing out to an external provider. That regional and perimeter setup matters specifically for open models with non-U.S. origins, including DeepSeek-V4-Flash and GLM-5.3, both developed in China.

Snowflake's recent acquisition of Natoma adds another layer. The deal brings more than 100 MCP connectors with scoped, governed access. An agent could get read-only access to a connected tool like email, for example, rather than broader permissions.

Context lets a cheaper model do the work

Snowflake recently announced its Horizon Context and Cortex Sense tools that provide context capabilities.

Without good context, a model has to do the exploratory work itself, writing and testing SQL, searching through data and retrying when something does not work. Gultekin explained that the process is expensive, and getting it right typically requires a more capable model. Packaging the context in advance removes that exploratory step, which means a simpler, cheaper model can often handle the same task.

Snowflake also builds agent memory into that context. As an agent is used repeatedly, its memory updates and gets folded back into future queries. The system does not re-solve the same problem from scratch each time. Memory becomes part of the context passed to the model.

OpenRouter, Databricks and Nvidia are chasing the same problem

There is no shortage of technologies in the model routing space. OpenRouter is one of the most widely known options, providing a platform that enables organizations to route based on cost and performance. Nvidia on August 11 announced Switchyard as a technology layer to help route AI model choice. Databricks has an offering as well with Smart Routing for its Unity AI Gateway. "The interesting part is what it says about where differentiation has moved," Sanjeev Mohan, Principal and Founder, SanjMo, told VentureBeat. "Snowflake isn't really selling routing, it's selling routing that never leaves the governed data boundary, with access controls, tagging, and cost attribution already attached."

Mohan added that for a company whose data and compliance already center on Snowflake, routing that keeps data in place and attributes spend by team is a real lever on that problem. For a company without that center of gravity, a neutral gateway may route across more models with less friction.

Mohan frames the market as three distinct camps rather than one competitive field. Databricks approaches governance from data engineering and ML lineage. Its Unity Catalog governs data, models and pipelines for teams building and training models. Snowflake approaches governance from analytics and access control, governing who can touch which data and attributing usage across business units. A third camp includes neutral gateways such as OpenRouter, LiteLLM, Portkey and hyperscaler routers like Azure AI Foundry. These compete on model breadth and avoiding lock-in rather than deep governance.

Choosing a router means choosing a governance model

Model routing is now table stakes for enterprises. The decision that matters is which governance model already fits how their data and teams are organized, not which vendor’s router is fastest or cheapest.

Manual model selection is becoming a cost liability at agent scale. What worked when a team ran a handful of agents breaks down at scale. Hundreds of agents making routine model calls with no automated cost check in place adds up fast.

Evaluate the governance model, not the router's feature list. The real question, per Mohan, is which governance model matches the data estate already in place, and which one gives the cost visibility needed to avoid an unpleasant surprise.

The right starting point depends on where an enterprise's data already lives. A Snowflake shop gets more value from in-platform routing that respects its existing access model and bills back to cost centers than from raw model breadth, according to Mohan. A Databricks-centric team worried about lineage across training and deployment is better served by a gateway built around that same lineage. A multi-platform or model-first team that wants maximum choice with minimal lock-in fits better with a neutral gateway, the same pitch behind OpenRouter's valuation.

"For a practitioner, don't start with the router, start with where your governed data and platform commitment already live, and with how exposed your margins are to inference cost," Mohan said.

The biggest AI model release of the past few days, at least among the developers and AI power users on social media, wasn't a frontier cloud model from OpenAI, Anthropic or Google.

It was a 27-billion-parameter model from Alibaba: Qwen3.8-27B landed on Hugging Face on Friday under an enterprise-friendly, open source Apache 2.0 license, giving developers downloadable weights for a dense multimodal model.

But Qwen3.8-27B isn't a garden variety small local model: it includes native image and video understanding, a 262,144-token context window, configurable reasoning and support for coding and agentic workflows — a “compact, deployment-friendly” version of the capabilities developed for its Qwen3.8 generation.

That unusually small hardware footprint is a major part of Qwen3.8-27B’s appeal. Running the model at full 16-bit precision requires roughly 56GB of GPU memory, while an FP8 version needs about 28GB. But 4-bit quantization cuts the model itself to roughly 17GB, putting it within reach of high-end consumer machines such as a powerful gaming desktop or well-equipped laptop.

Hitting the sweet spot between capability and size

The outsized reaction among developers has been due to the dynamic combination of its capability and size.

Alibaba's own launch benchmarks immediately supplied the first jolt. The company reported 61.7 on SWE-bench Pro, 90.3 on LiveCodeBench v6, 70.7 on its CoWorkBench office-work benchmark and 84.3 on OSWorld-Verified.

In Alibaba's published comparison table, the 27B model even beats the listed Claude Opus 4.6 Max result on SWE-bench Pro and LiveCodeBench, although Opus remains ahead on Terminal-Bench, GPQA Diamond and Humanity’s Last Exam.

Some of Alibaba's evaluations are internal, and benchmark harnesses are not identical across every comparison, making the numbers poor grounds for declaring a universal winner.

Third-party results show a powerful, local model with performance equivalent to proprietary models from months ago

The conversation changed Monday when third-party results began arriving.

Third-party AI benchmarking outfit Artificial Analysis gave Qwen3.8-27B a score of 52 on its Intelligence Index, a composite of nine evaluations spanning coding, science, reasoning and professional tasks. That happens to be the same score Artificial Analysis currently assigns OpenAI's low-tier model GPT-5.6 Luna at its maximum reasoning setting — a proprietary offering only available over the cloud.

As open source coding agent Cline put it on X: "This is the first time a local model has scored frontier model capability. We weren’t expecting this pace of local progress anywhere near this soon."

On Artificial Analysis' Agentic Index measuring model performance on agentic tasks, meanwhile, Qwen3.8-27B scored 51, beating Claude Opus 4.8 on maximum reasoning effort — a frontier model Anthropic released less than three months ago.

That doesn't mean these models are equivalent, but it helps explain why developers and AI power users stood up and took notice. As developer and AI podcaster/YouTuber Sero (@0xSero on X, real name Sharif Cherf) wrote on X: "A model that runs on 3k USD of hardware is beating everything from 4 months ago. Including Opus. Permanent underclass is cancelled."

Developer Joshua “Xenova” Lochner, known for bringing machine-learning models into web browsers, highlighted the result Monday on X alongside an experiment running Qwen3.8-27B with custom WebGPU kernels. His reaction — “What a time to be alive!” — captures much of the mood: a model scoring in the vicinity of proprietary frontier systems can be downloaded, modified and executed locally rather than accessed only through a vendor API.

The appeal becomes clearer when the model is compressed. Developer and AI writer Simon Willison tested a roughly 17GB Q4_K_M quantization on an M5 Max MacBook Pro and Nvidia DGX Spark.

He found that it could write code, interpret images and operate a coding-agent loop through the Pi agent framework. In one experiment, the model navigated a codebase to explain how authentication worked; in another, it wrote and tested a Python utility Willison needed to convert an agent transcript from JSONL to Markdown.

“The fact that a 17GB file can do all of this stuff on my home machines is a miracle,” Willison wrote. His broader point is the one resonating with power users: capabilities that recently felt inseparable from expensive hosted models are moving into files small enough to keep on a workstation.

The reaction is showing up in usage as well. Cybernews reported Monday that Qwen3.8-27B passed 3 million Hugging Face downloads in its first three days, while quantized versions rapidly appeared for local inference tools.

The LocalLLaMA community on Reddit created a dedicated release megathread simply to consolidate the flood of benchmarks, quantizations, configuration advice and comparisons. One user showing a locally generated game described the model as “a different beast.”

Overthinking is an issue

That frenzy comes with an important caveat: Qwen3.8-27B appears to buy some of its quality by thinking a lot.

Artificial Analysis says the model generated 160 million output tokens across its Intelligence Index testing, versus a 43 million median for comparable open-weight models.

Willison encountered an extreme version of the same behavior because Qwen defaults to its xhigh reasoning setting. A request to generate an SVG of a pelican riding a bicycle took 21 minutes and consumed more than 22,000 reasoning tokens before producing the answer. He recommends starting with low or no reasoning for ordinary local use.

Investor and developer Tomasz Tunguz found a similar trade-off in a small nine-task test against DeepSeek V4 Flash: with reasoning enabled, Qwen edged ahead on quality in his agent stack, but he reported that it was roughly 30 times slower and 4.5 times more expensive. He explicitly cautioned that nine tasks were not enough for a verdict.

Inference software may narrow that gap. Qwen3.8-27B includes Multi-Token Prediction, and Willison reported about a 72% performance improvement on his DGX Spark after enabling MTP through llama.cpp compared with his default LM Studio configuration.

Even then, his normal LM Studio runs were producing only around 15 to 30 tokens per second — far below the responsiveness of many hosted models.

That tension is precisely why Qwen3.8-27B matters more than another leaderboard position.

What enterprises should take away from Qwen3.8-27B

For enterprises, the relevant comparison is not simply whether a 27B model “beats” Claude or GPT on a benchmark. It is whether a model small enough to run inside an organization’s own infrastructure can now perform enough coding, document analysis, vision and agent work to replace API calls for meaningful classes of tasks.

That proposition changes privacy, deployment and cost calculations. Apache 2.0 weights can be inspected, modified and hosted behind a company’s own controls, while Alibaba already documents compatibility with serving frameworks including vLLM, SGLang and TokenSpeed. Alibaba says a managed Qwen Cloud version with a 1-million-token default context and built-in tools is coming later.

The small size and accessible hardware requirements mean that enterprises, indie developers, and even curious consumers can easily deploy the model locally without worrying about their data leaving their machine — ensuring greater privacy, information security, governance and control.

There is a broader reason power users are paying attention. Hugging Face data reported by Business Insider this week shows that actual model usage skews dramatically toward smaller models even as enormous frontier releases dominate headlines; models above 70 billion parameters accounted for only a small share of 2026 downloads.

Alibaba’s strategy of publishing Qwen models across multiple practical size classes has helped make the family a recurring part of developers’ local deployment workflows.

Qwen3.8-27B pushes that logic further. Its benchmark scores still need more independent validation, its default reasoning behavior can be painfully inefficient, and no single leaderboard establishes frontier-model parity.

But three days after release, developers are no longer reacting primarily to Alibaba’s benchmark table. They are reacting to the experience of putting a comparatively small file on hardware they control and watching it perform tasks that, not long ago, seemed to belong exclusively to the largest proprietary systems.

For certain developers, AI power users—and yes, even enterprise deployments—that is the benchmark that matters most.

Cursor began rolling out Origin, its own code hosting platform, to paid users on Monday morning. Roughly three and a half hours later, GitHub's status page lit up with what became a six-hour-and-forty-two-minute global degradation — error rates near 20% across pull requests, issues and the API, and near 50% on archive and raw file downloads, according to GitHub's incident log. Enterprise single sign-on went down with it: SAML, OIDC, SCIM provisioning and Team Sync all failed. So did Copilot.

The developer internet did what the developer internet does.

"You can now host your repos in Cursor Origin and deploy to Vercel via Cursor Origin which is itself hosted on Vercel," Vercel chief executive Guillermo Rauch posted on X. "And unlike GitHub, it's online 😁" Asked why he was smiling, Rauch replied: "trying to make light of the situation. We ourselves are stuck because of github rn!"

Matt Palmer, who works at Cursor, quote-tweeted his own company's launch with the day's best line: "We were going to ship this earlier, but GitHub was down." A GitHub outage, in other words, delayed the launch of a GitHub competitor.

Product launches get locked weeks in advance, and no evidence suggests Cursor timed this one. But the coincidence did the company an enormous favor, because it dramatized the argument Origin exists to make. For eighteen years, choosing where to host your team's source code has been the least interesting decision an engineering organization makes. Cursor is betting that AI agents have made it interesting again — and for technical decision makers, that is the real news here. Not a new product, but a new procurement question with a governance problem attached.

Inside Origin: what Cursor's code hosting platform actually does

Origin lives in a new Codebase tab inside Cursor. Teams name a codebase, which becomes part of its URL, then push to it over the command line. From there they get the machinery you would expect from a forge — the service layer that wraps Git and handles storage, permissions, checks and merges. Every repository comes with pull requests: timelines, commits, checks and files changed. Reviewers read the diff, leave comments and merge, without ever opening a browser tab.

What Cursor built around that machinery is the part worth studying. Agents now operate in the same surface as the code and the pull requests they are modifying. "Your code, PRs, and agents are now in the same place," the changelog reads. A developer can ask questions about the file on screen, hand an agent a review comment and have it revise the pull request in place, or tell it to push a branch — all inside the editor where the code was written.

Three integrations shipped on day one, and the choice of partners is telling. Vercel spins up a preview deployment for every pull request and ships to production on merge, available in public beta for Pro and Enterprise customers, its developer account said. Depot and Buildkite run continuous integration, and critically, both execute existing GitHub Actions workflows unchanged. Buildkite adds native pipelines on top.

That compatibility layer is the whole strategy in miniature. Cursor is not asking teams to rewrite their build system, retrain their engineers or rip out their deployment pipeline. It is asking them to try a second window onto code they already have — which is a far easier request to approve.

More partners are coming, the company said, and the ones it landed first are the ones that matter to a platform team evaluating whether Origin can carry real work. A forge without deployments and CI is a code viewer. A forge that runs your existing Actions workflows and ships previews to the CDN you already pay for is a candidate.

Why letting GitHub stay the source of truth is Origin's smartest design choice

Here is the decision enterprise buyers should study most closely, because it determines whether Origin survives a security review at all.

Cursor does not ask you to leave GitHub. Connect a GitHub organization, pick repositories, and they appear alongside Origin-native ones. "Pushes keep going to GitHub, which stays the source of truth for anything started there," the changelog says. Access permissions mirror GitHub's existing read and write settings rather than establishing a parallel system. Pull request conversations sync in both directions — comment in Cursor and it posts to GitHub; reply or react on GitHub and it surfaces in Cursor "within seconds."

This is a classic wedge, and a well-executed one. Rip-and-replace migration of source control ranks among the highest-risk projects an engineering organization can undertake. It touches continuous integration, compliance evidence, audit trails, branch protection rules, every integration in the toolchain and the muscle memory of every engineer on staff. Almost no chief technology officer approves that for a product in early beta.

A read-mostly mirror that leaves GitHub authoritative approves itself. It costs nothing to try, breaks nothing if abandoned, and quietly relocates the place developers spend their working hours. If Cursor's review experience proves better — and Cursor spent real money to make sure it would — the source of truth eventually follows the attention.

That money went to Graphite, the code review startup Cursor bought in December 2025 for what Axios reported was well above its $290 million Series B valuation. Graphite built stacked pull requests, the workflow that lets developers keep shipping dependent changes without waiting on approvals. Announcing the deal, Cursor wrote that "the boundary between where you write code and where you collaborate on it feels increasingly arbitrary," and promised "some more radical ideas we can't share just yet." Origin is the radical idea. Graphite co-founder Tomas Reimers unveiled it on stage at Cursor's inaugural Compile conference in June and leads its development.

How AI agents turned code review into software's new bottleneck

The case for an agent-native forge rests on a claim that is easy to state and, unusually for this market, well supported by evidence: writing code stopped being the constraint. Reviewing and integrating it became one.

Google's 2025 DORA report, drawn from nearly 5,000 technology professionals, found that 90% of developers now use AI at work, spending a median of two hours a day with it, and more than 80% say it made them more productive. But AI adoption showed a positive relationship with software delivery throughput and a negative one with delivery stability. More output, more breakage. The report's authors describe AI as "an amplifier" that "magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones."

Trust has not kept pace with volume. Stack Overflow's 2025 developer survey of 49,009 respondents across 177 countries found 84% using or planning to use AI tools, while trust in their accuracy fell to 33% from 43% a year earlier and distrust climbed to 46% from 31%. Two-thirds named "AI solutions that are almost right, but not quite" as their leading frustration. GitLab's ninth annual DevSecOps survey, of 3,266 practitioners polled by Harris, put numbers on the operational drag: 73% had hit problems with vibe-coded output, 70% said AI made compliance management harder, and only 37% would let AI handle daily tasks without human review.

The volume climbs regardless. GitHub's Octoverse 2025 counted 180 million developers, 630 million repositories and 43.2 million pull requests merged per month, up 23% year over year. And RuntimeWire reported the internal figure that best explains Origin's existence: 35% of pull requests merged inside Cursor were opened by agents running autonomously in cloud virtual machines.

A forge built for humans assumes a pull request represents human intent, opened by someone you can ask what they meant. Once a third of merged changes come from software, the queue stops being a conversation and becomes a scheduling problem. That is a real architectural argument, and it is the strongest thing Cursor has going for it.

GitHub's reliability crisis handed Cursor an opening it did not have to earn

The supply-side case for an alternative is simpler: GitHub has been unreliable, and its own executives have said so.

An analysis by LeadDev counted 257 incidents between May 2025 and April 2026, 48 of them major — roughly one significant disruption per week. February was the worst month on record with 37. GitHub Actions alone accounted for 57 outages in twelve months. Chief technology officer Vlad Fedorov has said the platform "wasn't built for the scale it's now being asked to handle" and must design for 30 times today's load. In an April engineering post covered by InfoQ, the company acknowledged it "failed to meet its own reliability standards," citing rapid growth, tight architectural coupling and inadequate load shedding. Monday's outage was the seventh incident on GitHub's status page in fifteen days.

The fatigue is audible. "GitHub really doesn't feel built for the agent era," one developer wrote on X as Origin went live. "It goes down way too often, but until now there haven't been many real alternatives."

The defections started before Origin existed. The Zig programming language moved to Codeberg in November 2025, citing Actions failures among its reasons. In April, Mitchell Hashimoto announced that Ghostty — a terminal emulator with more than 52,000 stars — would leave too, pointing to near-daily outages that blocked reviews and CI for hours. And The Information reported in March that OpenAI, a company Microsoft holds a large stake in, began building its own GitHub alternative partly because outages left its engineers unable to commit for hours at a time, as Tom's Hardware relayed.

Microsoft's structure has not helped. Thomas Dohmke resigned as GitHub chief executive in August 2025 and was never replaced; the unit's leadership was absorbed into Microsoft's CoreAI organization under executive vice president Jay Parikh. In a May report, The Information wrote that Parikh had warned deputies that coding tools from Cursor and Anthropic could eventually make GitHub obsolete. GitHub's own answer to the agent era, Agent HQ, lets customers orchestrate third-party agents from Anthropic, OpenAI, Google, Cognition and xAI inside GitHub — a coherent strategy that concedes the agent layer and keeps the substrate underneath. Origin attacks precisely that substrate.

Now that SpaceX owns Cursor, who actually holds your source code?

Cursor's rise has been extraordinary even by the standards of this cycle. Founded in 2022 by four MIT students, Anysphere raised $8 million from the OpenAI Startup Fund in October 2023, per TechCrunch, then $100 million at $2.5 billion, $900 million at $9.9 billion, and $2.3 billion at $29.3 billion last November. In May, Bloomberg reported annualized revenue of $3 billion and more than 3,000 customers paying at least $100,000 a year.

Then, three days before Origin shipped, Bloomberg reported that SpaceX completed its $60 billion all-stock acquisition of Cursor — an agreement TechCrunch covered in June, days after SpaceX's record IPO and six months after it absorbed xAI. Cursor now operates inside a division called SpaceXAI. The vendor asking to hold your proprietary source code became, last Friday, a unit of a rocket company with its own frontier-model division and a founder not known for institutional caution.

Jason Andersen of Moor Insights & Strategy raised the model-routing question to Tech Times in June, before the deal closed: "xAI's models and treatment of guardrails are very different than what Cursor has stood for." That piece framed the question a chief information security officer now has to answer. When one company controls the editor where agents write code, the host where that code lives and the model those agents run on, what governs what it does with the code?

Cursor has not published an answer. RuntimeWire noted before launch that Origin's pricing, security architecture, data-handling terms and migration tooling were all unpublished, and Monday's changelog adds none of them. It says only that Origin reaches "all paid plan users starting today, except enterprise orgs whose admins opt out." Opt-out, not opt-in — a sentence administrators should read twice.

There is also a track record to weigh. In July, researchers at Mindgard disclosed that Cursor would execute a malicious git.exe planted in a Windows project's root the moment a user opened it, with no prompt — a repository-poisoning flaw they first reported in December 2025. The Hacker News reported that Cursor declined to patch it, calling the issue out of scope under a shared-responsibility model while conceding it had not "closed the loop with the researcher in a timely manner." No CVE was issued. The same flaw class turned up unpatched in GitHub Copilot CLI, Google's Gemini CLI and OpenAI's Codex — but a vulnerability the vendor declined to fix makes an awkward footnote for a product whose pitch is basically “let us hold your repositories.”

What engineering leaders should settle before they let Origin into the toolchain

Origin is a beta, not a migration, and treated as one it is worth evaluating. The sync mode gives platform teams a low-risk way to measure whether an agent-native review surface shortens cycle time, without touching a single branch protection rule. But three things deserve resolution before anything authoritative moves.

The first is the default. Origin switches on for paid users unless an enterprise administrator opts out, which means an organization that has not made an affirmative decision about whether proprietary code may be mirrored to a new host has effectively had that decision made for it. Confirming your posture is a Monday-morning task, not a next-quarter one.

The second is the paperwork. Retention, residency, training use, subprocessors and what changes now that Cursor reports into SpaceX are all unpublished, and a product page is not a contract. Until those terms exist in writing, the defensible position is to treat Origin as a convenience layer over GitHub rather than a system of record — which is, conveniently, exactly what its architecture already is.

The third is the exit. Origin's Actions compatibility and its GitHub-as-source-of-truth design are the properties that make it safe to adopt. They are also the ones most likely to erode as Cursor's incentives shift toward owning the substrate rather than borrowing it. Ask what egress looks like now, while the mirror is still a mirror.

None of which makes Cursor's argument wrong. GitHub earned its incumbency by being boring, dependable infrastructure, and it has spent eighteen months being neither while a third of the code arriving at its front door stopped being written by people. Origin is a serious answer to a real problem, built by a team that bought the right company to build it.

But GitHub's failure and Cursor's are different in kind, and enterprises should not confuse them. Monday's outage resolved at 20:22 UTC. Availability is an engineering problem, and engineering problems close. The question of who holds your source code, what they may do with it and who they ultimately answer to carries no such timestamp — and on that one, the company that spent Monday selling trust has yet to publish its terms.

A retrieval-augmented generation (RAG) system is built to answer strictly from the documents it retrieves. But when engineers optimize these AI pipelines end-to-end, the reader module can learn a shortcut: instead of relying on retrieved evidence, it starts answering from its own internal memory — while the system's overall accuracy keeps climbing. This is the hidden challenge of "role drift," a failure mode in compound AI systems where individual modules learn to bypass their assigned tasks even as end-to-end performance improves.

To address this, researchers at MIT and Harvard introduce Role Anchor, a technique that forces modules to stay in their lanes during training. When applied, the technique mitigates role drift. For example, it forces the RAG reader to rely on retrieved evidence instead of answering based on its internal knowledge.

The primary takeaway for practitioners is that end-to-end accuracy alone can overstate how much a compound AI system has genuinely learned. Engineers must evaluate individual components and ensure they work as intended.

Role Anchor serves as both a guardrail and a diagnostic tool when optimizing multi-step LLM pipelines. It can be essential for real-world AI applications that require a strict division of labor between modules.

Why terminal accuracy hides the problem

Compound LLM systems divide complex tasks among specialized modules. For example, a system designed for multi-hop reasoning might split a task between a "Decomposer" and a "Solver.” The Decomposer breaks a large problem down into manageable sub-tasks, while the Solver computes the answers to those sub-questions. This division of labor allows AI engineers to delegate execution to smaller, cheaper models, and makes it possible to process sub-tasks in parallel where possible.

To improve the performance of AI pipelines, engineers typically optimize them using end-to-end reinforcement learning (RL) guided by a single "terminal reward.” This means the system is evaluated on whether or not the final answer is correct (the researchers call it “terminal accuracy”). When this terminal accuracy goes up, the system is considered to be learning and working as intended.

However, terminal accuracy does not verify whether the modules properly executed the tasks they were assigned. As Xiaoyang Cao, co-author of the paper, told VentureBeat, "Terminal accuracy reduces the behavior of an entire multi-part AI system to a single number. It shows whether the final answer is correct, but says little about which components contributed or whether they followed their assigned roles."

This blind spot leads to role drift, a failure mode where a module's behavior diverges from its assigned role during optimization, even though the system's terminal accuracy continues to improve. 

"For engineering teams, the practical risk is that they can deploy a pipeline that passes every end-to-end evaluation even though its intended division of labor has silently broken down," Cao said. Because the reward system only scores the final answer, it fails to detect or penalize the module for going rogue.

Consider how this happens in the Decomposer-Solver pipeline. The Decomposer's assigned role is to write abstract sub-questions without solving the task, leaving the reasoning to the Solver. Under end-to-end RL, the Decomposer quickly learns that the weaker Solver is prone to errors on abstract tasks. To maximize the reward, the Decomposer begins leaking or planting answers into the sub-questions it sends to the Solver. The Solver ends up parroting the answer the Decomposer fed it. Terminal accuracy goes up, but the intended architecture is compromised.

But if the system is getting the right answers and accuracy is going up, why should we care if a module drifts from its role?

Real-world deployment requires much more than just a correct final answer on a training dataset. The implicit roles assigned to these modules ensure scalability, reliability, and auditability. Consider what happens when role drift takes over:

• Loss of efficiency and auditability: In the reasoning example, role drift causes the Decomposer to do all the heavy lifting instead of planning and delegating. "Once the decomposer starts putting answers directly into its sub-questions, the solvers are reduced to copying those answers," Cao said. "You are still paying to run [different modules], but they are no longer doing independent work." The workload can no longer be parallelized across multiple Solvers, it cannot be delegated to cheaper models to save compute, and downstream human stakeholders can no longer audit the system's logic step-by-step to verify how it arrived at the answer.

• Fragility in dynamic environments: Consider a RAG system, in which a Reader model is tasked to answer questions strictly using external retrieved documents. If the Reader drifts and learns to rely on its own internal parametric memory instead (because its memory happens to be accurate during training), the system becomes brittle. When the enterprise updates its database with new information, or a user asks a question about a novel topic outside the model's pretraining, the system will fail because it abandoned the grounding mechanism it was built to use.

How Role Anchor measures a role — and enforces it

"Training only for the final outcome rewards a system for producing the right answer, regardless of how it gets there," Cao said. To counter this, Role Anchor serves as a lightweight regularization technique that makes role instructions part of the training objective. It compares how the component behaves with and without those instructions and discourages training from weakening their effect. 

At a high level, it ensures the module continues to respect the steering influence of its original role prompt throughout the reinforcement learning optimization process, making role drift both measurable and controllable.

A key insight of Role Anchor is that a role’s effect can be measured by comparing how a model behaves with and without the role prompt. The system evaluates two different prompts for each module:

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

2. The neutral prompt (e.g., "Answer the user's question...").

For any given input, the model outputs a probability distribution for the next token. When run under the role prompt, it will favor certain tokens. When run under the neutral prompt, it behaves like a generic assistant. The difference between these two probability distributions is the "role utility."

This utility measures the ”nudge,” or the direction and strength with which the role prompt shifts the LLM’s default predictions. If a token is highly aligned with the assigned role, the role prompt boosts its likelihood compared to the neutral baseline (or “nudges” the model toward that token).

Before starting RL training, Role Anchor keeps a frozen copy of the model as reference and measures the role prompt's original nudge on this reference model. This pre-RL nudge serves as the ground truth of the designer's intent, acting as a proxy for how the role prompt is supposed to steer the model.

During RL training, as the active model’s weights are updated, Role Anchor regularly calculates the current nudge and compares it to the reference nudge. If the current nudge starts to fade or deviate from the reference, Role Anchor applies a penalty to the model to prevent role drift.

To see this practically, consider the RAG system evaluated by the researchers. In this pipeline, the Reader module is explicitly instructed to answer user questions based only on retrieved documents, rather than relying on its internal knowledge.

During unconstrained, outcome-only RL, the reader learns that the upstream retriever is sometimes noisy. To maximize accuracy on the training set, it starts ignoring the retrieved passages and answering from memory. Consequently, the gap between its behavior under the role prompt and the neutral prompt shrinks to the point that the reader starts behaving identically under both, ignoring the grounding instructions.

In contrast, Role Anchor detects when the reader’s nudge deviates from the reference nudge. It applies a penalty, redirecting the model’s parameters away from this memory-based shortcut. This forces the reader to find role-compliant ways to improve, such as learning how to extract answers from the retrieved passages more robustly or avoiding using its internal knowledge when the retrieved passages are faulty.

The numbers: how much of the accuracy gain was real

To test the efficacy of Role Anchor, researchers evaluated it on the RAG and Decomposer-Solver (DEC) pipelines. The experiments compared systems trained with standard outcome-only reinforcement learning (no anchor) against systems trained with Role Anchor.

Under outcome-only RL, the RAG system's terminal accuracy rose, but its internal integrity collapsed. The researchers measured "Evidence-Following Accuracy," a probe testing if the model changes its answer when the retrieved text is deliberately swapped to state the opposite. This metric plummeted from 0.86 to 0.54 (just above random chance), meaning the model learned to ignore retrieved passages and rely on its pre-trained parametric memory instead. In one test, researchers deliberately changed a piece of information in a retrieved document to contradict the model’s internal knowledge. The unanchored model did not update the response because it wasn’t using the external document.

When Role Anchor was applied, the Reader’s Evidence-Following Accuracy remained at 0.869, proving it relied strictly on the retrieved text. When researchers fed the anchored model random passages that were unrelated to the input prompt, its accuracy correctly dropped because it refused to use its internal knowledge. The unanchored model scored higher on random passages because it was guessing from memory.

The Decomposer (DEC) pipeline showed an even more dramatic failure mode. Under outcome-only RL, terminal accuracy shot up, but the "insertion rate" (i.e., the frequency at which the Decomposer leaked the answer into the sub-questions it sent to the Solver) surged from 0.143 to 0.596.

In the RAG pipeline, preserving the intended role cost the system a very modest accuracy drop (-0.067). The Reader still learned to be better at extracting answers, but it did so legitimately rather than by cheating with its internal memory. This means it is more reliable on real-world tasks with novel knowledge it has not seen during training.

In the DEC pipeline, unanchored RL improved accuracy by 0.310 above the base model, while Role Anchor only showed a 0.057 improvement. When diagnosed, it turned out that the underlying issue was that the Solver model was too small and couldn’t learn the problem-solving part. This forced the Decomposer model to cheat and provide the answer to boost the terminal accuracy. This meant 86% of the unanchored improvement was fake, and the system had simply learned to exploit a shortcut instead of learning how to reason or decompose problems better.

However, this tradeoff is not a universal rule. In some cases, eliminating shortcuts can actually boost overall performance. "Role Anchor… does not necessarily reduce final accuracy," Cao said. "In a coding pipeline we recently tested, the model had learned to manipulate its own test executor during reinforcement learning training. Adding Role Anchor completely eliminated that shortcut while slightly improving correctness on the final tests used to judge the code."

What it takes to add Role Anchor to an existing pipeline

For engineering teams looking to apply this technique, "Role Anchor can be added to an existing reinforcement learning fine-tuning process as an extra training objective for each component that a team wants to anchor," Cao said. The main pipeline and deployment setup remain entirely unchanged.

To implement it, engineers need three specific items for each anchored component: its original role instructions, a matched neutral version with the role information removed, and a saved copy of the model from before reinforcement learning fine-tuning.

Importantly, there is no latency penalty at inference time. "Role Anchor runs only while the model is being trained, so it does not slow down the deployed system," Cao said. He noted that their current implementation takes roughly 20 percent longer during training due to additional calculations, though there is likely room to optimize and reduce that overhead. The research code, training configurations, and selected model weights will be released publicly in the near future.

Deciding when to use Role Anchor is a case-by-case decision based on whether final accuracy captures everything that matters. Cao points to a regulated legal RAG system as a prime candidate. "The component producing the answer may need to follow retrieved evidence, stay grounded in an approved set of documents, and produce answers that can be traced back to their sources," he said. "Final accuracy alone cannot verify those properties, so the behavior of that component needs to be measured and enforced directly."

As enterprise AI evolves toward more complex compound pipelines, role enforcement will become harder, and relying on prompts alone will prove unreliable. "At larger scales, role specifications will need to be enforced through both training and system design," Cao said. "Methods such as Role Anchor can help preserve intended behavior during training, while clear system boundaries, limited tool permissions, and monitoring during use can provide additional safeguards."

A company builds a governed context layer specifically to stop its AI agents from confidently giving wrong answers. Once that layer is live, the company is more than twice as likely to report the failure happening — not less.

In the past six months, 68% of enterprises have traced a confident but wrong AI agent answer to missing or inconsistent business context. Thirty-seven percent say it happened more than once, ahead of the 32% who saw it happen only once. The figures come from a VB Pulse July 2026 survey of 101 qualified enterprises with more than 100 employees. That's up from 57% in a VB Pulse survey conducted in June. Recurring failures climbed too, from 31% then to 37% now.

This is the second time VB Pulse has asked enterprises this exact question, once in June and now in July. The failure rate is climbing, not falling, even as more enterprises report a governed layer in production, up from 25% in June to 32% now.

How agents get context determines whether they're wrong

Every AI agent needs some way to know what the business actually means, whether a metric is defined consistently, whether a document is current. That's the operation. The challenge is that enterprises hand agents that context in very different ways, and those ways are not equally reliable.

Retrieval over documents remains the most common approach, the primary source for 31% of enterprises. But a real share of enterprises skip a structured approach altogether. Thirteen percent run agents primarily on long-context loading, feeding documents directly into the model's context window rather than retrieving them. Five percent give agents no structured context at all, just the model's general knowledge. Between them, nearly one in five enterprises are feeding agents business context by brute force or not feeding it at all.

Even the leading approach can still produce a confidently wrong answer. Retrieval works by matching a question to text that looks similar in meaning. Similar wording doesn't guarantee the same meaning. Srijith Rajamohan, an AI research leader at Redis, described exactly this gap in an interview with VentureBeat earlier this year. 

"If you have a sentence like 'Rome is closer than Paris' and another that says 'Paris is closer than Rome,' and you do an embedding retrieval followed by a text search, you're not going to be able to tell the difference," Rajamohan said. "The same words exist in both sentences."

Buying shifted to access control. Grading didn't follow.

The way enterprises choose a retrieval system doesn't help close the gap. Access control and permissions now tie ease of data ingestion as the top selection criteria, at 24% each. It's the first time in this survey series that a governance property has led to the buying decision. Retrieval accuracy trails at 15%. The property most directly tied to a confident wrong answer isn't the property most enterprises are buying for.

Once a system is running, correctness is still how enterprises judge it. Response correctness is the primary success metric for 38% of enterprises, twice the next closest answer, security and access control at 19%. Enterprises are shifting how they buy toward governance. They're still grading success on whether the answer is right.

The companies fixing this are the ones reporting it worst

A governed context layer is meant to fix this. It's one shared, agreed-on model of what the business's data means, that every agent and BI tool references instead of guessing on its own. Adoption is far from settled.

Thirty-two percent of enterprises run one in production. Thirty-one percent are piloting or building one right now. Twenty percent are evaluating one. Fourteen percent have no plans to, and 4% don't know.

Compare that adoption data against who's actually had the failure, and the picture inverts. Among the 91 enterprises able to say whether they'd experienced the failure at all, those running or building a governed layer report it recurring at 50%. Those without one report it at 21%.

A governed layer doesn't cause the failure — it's what makes the failure visible in the first place. Tracing a bad answer to a broken definition or a stale table requires a shared, governed reference point. A context layer provides that. Without one, the same wrong answer still happens — it just gets chalked up to the model, or never gets traced at all.

The pain point predates AI by decades. Kyle Nesbit, founder of the semantic layer startup Credible Data, described it to VentureBeat last month. "It's the same pain point people have had for 30 years, the lack of governed data analysis," Nesbit said. "Now with AI, it's the same problem, but orders of magnitude more chaos and pain."

Company size sharpens the same point. Enterprises with more than 1,000 employees report recurring failures at 55%, against 30% for those between 101 and 1,000 employees. That's despite the bigger companies being less likely to have a layer already in production, 24% against 37%. More instrumentation and more people asking why a number was wrong turns up more failures, not fewer. A clean record is not evidence of a healthy context layer. It's at least as likely to be evidence that nobody's checking.

What this means for enterprises

Here's what this adds up to for enterprises building on this layer.

Retrieval alone will not close the context gap. RAG remains the default context source, and nearly one in five enterprises are running agents on long-context loading or no structured context layer at all. More documents or a bigger index doesn't fix a definition that means two different things in two different systems.

The budget is moving faster than the infrastructure is shipping. Sixty-three percent of enterprises are already building or running a governed context layer. Only 32% have actually gotten one into production. That gap is where the spend is going, not where the problem has been solved.

A clean failure record is a red flag, not a green one. The 22% of enterprises reporting no context failure at all are not the best-governed group. They're the group least likely to be checking. The size data backs this up directly. Larger enterprises report recurring failures at nearly twice the rate of mid-market peers, despite being less likely to have a governed layer in production, not more.

No one is planning to hand the layer to a single provider. Seventy-nine percent of enterprises intend to keep at least part of the context layer outside any one vendor's stack, split between best-of-breed tools and an explicit mix. Just 12% plan to consolidate onto a single provider's native context stack.

The finding that organizations aren't likely to hand over control to a single provider is a theme that VentureBeat has reported on consistently this year. Michael Ni, an analyst at Constellation Research, put it bluntly earlier this year when DataHub's context layer push first landed.

 "Whoever controls runtime context, controls the AI decision layer for enterprise data," Ni said.

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.

Presented by MongoDB

Building AI that is accurate, secure, and reliable is a major engineering feat for organizations subject to the compliance obligations that govern healthcare, financial services, and transportation. The challenge of delivering AI-driven products is compounded by the fact that technology in these industries has tended to lag behind other sectors because regulation requires organizations to move carefully — and slowly. Now, many are also confronting data infrastructure modernization projects as they try to catch up with today’s demand for AI.

Australian-founded AI Care Partner Heidi offers an example of successful modernization. Its flagship product, Heidi Scribe, now automates much of the administrative work that consumes clinicians’ days across more than 190 countries, supporting roughly 2.7 million patient interactions each week. That expansion rests on infrastructure decisions taken years before the company reached global scale, says Yu Liu, co-founder and chief technology officer at Heidi.

“In most industries, an AI feature that is wrong two percent of the time registers as an inconvenience, while in healthcare that same error rate becomes a clinical safety issue,” says Liu. “The architecture has to be built around the assumption that every output may be scrutinised, audited, and relied upon in a patient’s care.”

Why deploying production AI in healthcare is architecturally different

For Heidi, data residency is a precondition rather than a feature. A clinician in Sydney, London, Tokyo, or Denver is operating under different regulatory regimes, including the Australian Privacy Principles, GDPR, APPI, and HIPAA, and their patients’ data has to live in-region.

Heidi runs fully logically isolated production deployments across the world, so residency is enforced by architecture. Auditability also has to be built in from day one, because an organization needs to be able to answer what the model saw, what it produced, and what the clinician changed, for any session, months later, when called upon.

“The blast radius of change must be engineered down,” Liu says. “In less regulated industries you can ship fast and fix forward, but in healthcare we invest heavily in making change safe by default, with continuous integration gates on risky change classes, canary releases, and treating even database schema and index changes as code that goes through review. Our speed is a product of that safety rather than something we achieve in spite of it.”

Choosing a database to connect with AI workflows

Heidi handles a diverse set of medical data collected from multiple sources, including forms, referrals, and clinicians’ notes, all of which had to be consolidated into one consistent format and one location to connect seamlessly with AI workflows. Rigid rows and columns would have been ill-suited to that workload.

For Heidi, those requirements made a document database the natural choice.MongoDBgave the team the flexibility to accommodate rapidly changing AI data without constantly reshaping the underlying database.

“The model is maybe 20% of the system, and the data architecture is what determines whether the other 80% holds up under real clinical load,” Liu says.

An AI Scribe session isn’t a single piece of data. It’s a collection of transcripts, structured notes, templates, documents, patient context, EHR integration state, and dozens of other related artifacts that change from week to week. MongoDB lets a session’s data live together in shapes that match how clinicians actually work, and lets Heidi evolve those shapes without a migration freeze every time the product moves.

"MongoDB Atlas stood out because it combined the power of the document model, which allows seamless scale, flexibility, and high performance, with built-in AI-ready features such as MongoDB Vector Search,” Liu says. “This means that Heidi does not need another bolt-on vector database to augment its existing platform.”

With more than 130 cloud regions globally alongside on-premises and hybrid options, MongoDB Atlas is the most widely available, globally distributed database platform, and its unified query API lets developers build full-text search, real-time analytics, and event-driven experiences without complicating their architecture.

"Heidi Scribe converts large volumes of medical documents into vector embeddings via LangChain in Atlas, enabling semantic search that connects transcribed medical terms directly to corresponding external knowledge," Liu adds. "Migrating to Atlas reduced latency on key APIs by nearly 33%."

What a trustworthy clinical RAG system requires

“Retrieval is a data architecture problem before it is an AI problem,” Liu says. "In consumer RAG, you retrieve from the open web and hope, whereas in healthcare what you retrieve from is the compliance surface."

Heidi Evidence retrieves from licensed clinical knowledge bases, including partners like BMJ Best Practice, NICE CKS, and MIMS, and it is jurisdiction-aware, so a U.K. clinician gets U.K. guidance and an Australian clinician gets Australian formularies, because the right answer in one country can be the wrong answer in another.

Heidi’s embeddings and vector indexes live in MongoDB Vector Search, inside the same regionally isolated deployments as the rest of its data, which means retrieval physically cannot cross a residency boundary, and they are not operating a separate vector database with its own security and compliance story. Citations are a hard contract rather than a prompt suggestion, because the model only ever sees retrieved chunks that are already bound to source records.

Regional isolation enables global compliance and scale

“Each region is a full, isolated production deployment with its own MongoDB Atlas clusters, its own compute, and its own key,” Liu says.

“That is what lets us walk into a U.S. health system, an NHS trust, or an Australian hospital group and give a clean answer on residency, because it is enforced by infrastructure rather than promised by contract," he explains. "Running multiple isolated regions with a lean team only works because the database layer is managed and consistent. We are also multi-cloud, meaning a new region can stand up another deployment on rails we have already built."

That architecture has been most visible in the U.S., where Beth Israel Lahey Health, one of New England’s largest health systems, rolled out Heidi’s AI scribe following a pilot finding 74% of clinicians reported reduced after-hours documentation (“pajama time”), and where non-profit system MaineGeneral Health selected Heidi as a strategic partner in its rural healthcare work.

“Entering the U.S. market meant standing up another region on rails we had already built rather than re-engineering for HIPAA after the fact,” Liu says.

Lessons learned and the roadmap ahead

"Re-partitioning a large, hot, always-on collection is a serious engineering program, whereas choosing a shard key on day one is a design meeting," Liu says. "We are doing that work now in partnership with MongoDB, but the lesson for anyone building a data-heavy AI product is that horizontal scale for your fastest-growing data is a founding decision, just like residency."

Heidi is now extending beyond the consult note to support the full clinical workflow, from pre-visit context to post-visit documents, referrals, and workflow automation. The company is also exploring how MongoDB, large language models, and its own tooling can power an agentic ecosystem for clinical workflows.

“In healthcare AI, reliability engineering is trust engineering,” Liu says. “A clinician’s trust is lost just as fast by downtime, latency, or a data inconsistency as by a bad note, and some of our highest-leverage work is invisible, including canary releases with automatic rollback, CI gates on database changes, and cross-region consistency checks. Clinician trust is the product, and trust is architectural.”

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.