Presented by Nutanix

Autonomous systems that can reason, make their own decisions, and execute actions across an environment introduce a category of risk that application-level controls were never built to contain. Treating that risk as a single problem produces incomplete architectures, says Oscar Wahlberg, senior director of product management at Nutanix.

"The guardrails to catch a malicious prompt won't stop an agent from hallucinating and doing something it never should have done, like accidentally deleting databases or leaking sensitive data with a credential it was granted but then uses for something entirely different," Wahlberg says. "That's the central problem as enterprises move autonomous agents out of experimentation and into production."

Once an agentic system is granted execution privileges across the data center, the security posture has to scale into a defense-in-depth architecture spanning infrastructure, storage, compute, networking, and a governing control plane. Each layer addresses a distinct category of risk, rather than duplicating the same controls across the stack. No single security control or vendor can provide that protection on its own. Defense-in-depth depends on those layers working together.

By dividing the responsibilities across the stack and adhering to zero trust segmentation, organizations can create a secure framework that improves their overall posture. Understanding which risks belong in each layer is what turns the principle of defense-in-depth into a practical security framework, with three layers that each have a distinct responsibility.

Infrastructure layer: Establishing trust where AI agents run

The infrastructure layer’s foundational responsibility is establishing a root of trust that answers a simple question: who is operating in the environment? That trusted identity becomes the prerequisite for every security control above it. Before an organization can trust what an agent does, it first has to trust the integrity of the environment where the agent runs. When an agent requests permission to execute an operation, the system must be able to verify that the request came from the legitimate agent — not something impersonating it.

Delivering that kind of assurance depends on technologies that root trust in the hardware itself, including platform attestation, confidential computing, and secure boot, alongside controls that prevent unauthorized access both within a server and beyond it. For regulated industries such as financial services, this layer provides the ability to isolate AI production workloads so that neither the agent nor the environment can operate outside its assigned scope. That mitigates risks including model and runtime tampering, supply chain compromise, and unauthorized access to sensitive AI workloads.

Network layer: Governing how AI agents communicate

Once agents begin communicating with other agents, APIs, applications, and enterprise systems, they generate a level of concurrency and dynamic communication that traditional static network configurations were never designed to handle. An agent configured to call APIs, query data sources, and spin up additional agents without constraint creates a sprawling web of east-west traffic that becomes very difficult to reason about, and that complexity can easily mask lateral movement or data exfiltration when the right network security layers are not in place.

"We should treat AI agents as a new class of network identity, and make sure that an agent can only talk to other agents or data sources where it's explicitly allowed to do so," Wahlberg says. "That means moving away from rigid static rules toward dynamic policy enforcement."

Nutanix's solution is Agent Gateway, part of the Nutanix Agentic AI solution. It's a unified, governed layer that is designed to provide cost control and governance capabilities to help manage autonomous agent users. Coupled with agents grounded in zero trust segmentation and using capabilities like Nutanix Flow for micro segmentation and integrating with networking vendors, including its integration into the Cisco Secure AI Factory, Agent Gateway helps enterprises govern interactions across agents, models, data sources, and enterprise applications.

The network layer governs lateral movement, data exfiltration, and gates the agent's network interactions. A zero trust framework with access blocked by default and scalable interaction monitoring is important for agents since they can exhibit unreliable behavior. The Nutanix software integration with Cisco UCS servers and Cisco AI PODs delivers the turnkey physical infrastructure (compute, storage, and networking) that the AI factory runs on.

Control plane layer: Governing what AI agents are permitted to do

The control plane is the brains of the operation, providing a central point for managing agent permissions, tool access, resource consumption, and runtime visibility. What matters most is having a single place where policies can be enforced consistently rather than reinvented for every agent, Wahlberg says.

"Agent Gateway acts as a universal endpoint for different models and tools, so an IT team can configure their agents to talk to this single control point," he explains.

The centralized AI gateway enables the admin to observe, audit, and control access to models as well as MCP tools protecting data and gating privileged access. This layer is designed to help mitigate risks such as privilege misuse, runaway agents, unauthorized tool usage, data leakage, and the excessive model consumption that can lead to increased token consumption when agents get stuck in runtime loops. And it depends on treating governance as a runtime control system rather than a compliance afterthought.

Why one-size-fits-all security fails agentic AI environments

The biggest architectural mistake enterprises make is assuming a single security model can be stretched across every layer of an AI stack. When an organization tries to solve for hardware-level trust with application-level software, or leans on static legacy network rules to manage dynamic agents, it builds an architecture that either blocks the agentic system from doing its job or leaves critical doors wide open. One-size-fits-all thinking tends to produce significant performance penalties and operational friction.

"By failing to assign specific responsibilities to the appropriate layers, enterprises end up with blind spots in governance," Wahlberg says. "They might secure the model output but miss that there's data leakage between agents, or they might secure the network but lack the control plane visibility to understand that they're wildly burning tokens because the agents are stuck in some kind of runtime loop."

Focusing exclusively on the model leaves the largest gaps of all, because a guardrail that catches a malicious prompt does nothing to stop a hallucinating agent from misusing a legitimate credential. Embedding security across the full stack helps ensure that even when a model level threat slips past the initial filters, the agent remains constrained by hardware rooted trust, network isolation, and access controls at the agent layer.

How Intel, Cisco, and Nutanix build defense-in-depth together

The three-way partnership from the three companies demonstrates how the layered architecture comes together in practice as a well-governed, enterprise-grade AI Cloud. Intel supplies the computer to run agentic workloads and secures the execution environment through hardware-rooted trust and confidential computing, while also driving costs down through their accelerators. Intel Xeon 6 processors with built-in AMX accelerate AI inference efficiently without relying exclusively on expensive GPUs.

Cisco wraps the environment in a secure fabric that governs communication between agents and enterprise tools, while Nutanix provides the software platform, minimizing architectural silos, and the central control plane that enforces permissions, delivers visibility and cost governance, and ties the architecture together into a defense-in-depth solution that lets enterprises scale agentic AI.

Of the three layers, enterprises currently underestimate the control plane the most, Wahlberg says. A true control plane extends far beyond initial deployment to simplify Day 2 operations, he explains, giving IT teams the continuous observability, and strict token governance required to keep autonomous agents secure and cost-effective in production.

"Apart from model and tool selection, governing the agent deployments and their access to models and business tools in a tightly integrated full stack platform will be important for the success of AI projects," he says, pointing to a near future in which organizations move from a handful of AI use cases to thousands of agents working autonomously to drive the business.

Technology leaders should prioritize building a centralized governance layer today that can manage agent identities, tool permissions, and token budgets in real time, because that control point is what builds the operational muscle to scale safely.

"You can't build an AI system without getting into a lot of complex decisions," he explains. "And you need a control plane that talks across multiple vendors and infrastructures to help you solve for those defense-in-depth strategies."

Learn more about the Nutanix Agentic AI solution here.

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

Consider an AI agent tasked with a complex enterprise workflow like migrating massive batches of customer records from a legacy CRM to a cloud database. The agent cannot rely solely on its internal context window for a job spanning hours and depends on the runtime layer, aka the harness.

This harness provides execution feedback, like server logs, to help the agent maintain an accurate understanding of dynamic API connections. It also provides state trackers and control-flow mechanisms to manage completed and pending subgoals, ensuring the agent doesn't skip or duplicate data batches. When unexpected errors occur, such as a database rejecting a batch due to strict API rate limits, the harness provides tools and instructions to help the agent recover.

The main way to tell an agent how and when to use its tools is to have a human developer write a set of rules and instructions telling it what to do step-by-step. For example, a developer might instruct the agent to always search the company wiki before writing an email. Because the agent is just following a rigid script, it lacks true autonomy. It hasn't been trained to independently weigh the costs and benefits of its actions.

To solve this, researchers at Meta AI and University of Illinois Urbana–Champaign introduce EvoHarness-RL, a framework that adds a layer of abstraction to the agent's harness and teaches the underlying model when to read, update, or consolidate the information it obtains from its environment.

In long-horizon tasks, how AI agents read and process the information they obtain from their environment is pivotal to their success. The agent must update its understanding of its environment, track completed and pending subgoals, recover from failed actions, and reuse procedures from previous experience. This execution depends on the harness.

A series of self-evolving agentic frameworks like Harness-1 solve part of the problem by accumulating past trajectories and distilling them into structured procedural memory, like reusable skills, workflows, or code libraries for future tasks. However, they generally separate this long-term skill curation from real-time, within-episode state tracking. They aren't actively training the agent on how to manage its immediate environmental reality or track its active task steps while working.

Xuying Ning, co-author of the EvoHarness-RL paper, told VentureBeat that manual logic and rigid memory structures are primary culprits draining engineering resources.

"The optimal harness often changes with the model," Ning explained. "Different models may need different prompts, memory designs, permissions, or sandbox configurations. If all of this logic is manually coded, every model upgrade can lead to another long cycle of tuning and debugging."

Furthermore, existing memory systems that simply accumulate experience can actively degrade an agent's reasoning. "Append-only memory assumes that more context is always helpful, which is not necessarily true," Ning said. "Over a long task, the memory may contain outdated conclusions, failed attempts, or information that is no longer relevant." As a result, long-horizon agents need a dynamic memory capable of updating, compressing, and replacing information to avoid repeating past mistakes.

EvoHarness-RL: A unified belief, progress, and experience workspace

To overcome the limitations of rigid, manual prompts, the researchers introduce EvoHarness-RL, a training technique that teaches the agent to make optimal use of its harness. Instead of blindly following hardcoded instructions, the agent learns how to construct a structured workspace from messy execution data and decide when and how to consult that external state during complex workflows.

To simplify the management of different components of the harness, EvoHarness-RL consolidates the agent’s support systems into a single, unified interface. This interface, known as the Belief, Progress, and Experience (BPE), categorizes the agent's external needs into three functional areas:

• Belief: Maintain an accurate read on the current environment.

• Progress: Manage completed and pending subgoals.

• Experience: Reuse historical knowledge across tasks.

Instead of using complex, domain-specific APIs, the AI interacts with this clean dashboard using four compact meta-actions: track, commit, recall, and note. It issues commands to track the live environment, commit to workflow updates, recall past strategies before acting, and write notes to save newly discovered insights for future runs.

These states map directly to high-value enterprise verticals. "In software engineering, Belief can represent the agent’s current understanding of the repository," Ning said, detailing how the agent monitors component interactions and workspace changes. "Progress tracks what has already been completed, what still needs to be done, and which steps depend on others." Meanwhile, Experience captures lessons, like user feedback on a mistake, to guide future actions.

The same idea applies to finance, Ning said. During a compliance audit, Belief might describe the applicable rules and available evidence. Progress tracks which checks have been completed and which exceptions remain open. Experience helps the agent recognize recurring discrepancies or know when an issue should be escalated.

"Together, these states help prevent the agent from losing track of its work or repeating the same failed approach," Ning said.

To teach the agent both the mechanics and the strategy of managing its external workspace, the researchers designed a two-stage training recipe. In the first stage, supervised harness fine-tuning, the base model learns how to extract and structure useful facts from messy interaction logs into the BPE framework.

However, querying memory or updating trackers consumes time and compute tokens, meaning the agent cannot afford to blindly check its tools at every step. To solve this, the second stage uses “cost-aware” reinforcement learning to teach the agent efficiency. This phase trains the agent to calculate when accessing its external state is worth the budget cost. This two-step process transforms tool-use from a rigid, hardcoded prompt into a learned runtime behavior.

EvoHarness-RL in action

To validate EvoHarness-RL, the researchers evaluated the system using the ALFWorld benchmark, a text-based environment featuring multi-step tasks that test sequential logic and state tracking.

They used Qwen3-8B as the base model to train. The team pitted the trained 8B model against three large frontier models (Claude Opus 4.5, GPT-4.1, and GPT-5), frozen agent frameworks with static tools (such as ReAct, ExpeL, and ReasoningBank), and advanced trainable methods (e.g., standard GRPO, SkillOS, and SkillRL).

The results show a significant jump in performance for smaller, cost-effective models. With EvoHarness-RL, the Qwen3-8B model achieved a 96.9% average success rate, a 49.0 percentage point improvement over its baseline ReAct counterpart.

Furthermore, the trained model outperformed advanced trainable frameworks like SkillRL (89.9%) and SkillOS (80.2%). Most impressively for enterprise developers looking to optimize compute costs, the 8B model effectively matched the performance ceiling of expensive closed models like Claude Opus 4.5, which scored 96.4% out-of-the-box.

Beyond empowering smaller models, the experiments show that the BPE framework has universal benefits across all model scales, even without the extensive reinforcement learning phase. When researchers equipped frozen, out-of-the-box frontier models with the BPE prompt-time harness, their execution improved significantly. GPT-4.1's success rate improved by 22.1 points and GPT-5 by 25.7 points.

Aside from the results, the researchers recorded effects during the experiments that demonstrate the dynamic behavior the LLMs acquire as they go through the EvoHarness-RL training. During the reinforcement learning phase, they observed a behavioral shift as the agent internalized knowledge over time, which they called "harness annealing". 

Early in training, the AI relied heavily on querying its Experience and Progress trackers for almost every step. However, as it mastered routine actions, it actively reduced its reliance on external tools, embedding the successful patterns directly into its parameters. In a real-world enterprise setting, this translates directly to lower latency and reduced compute costs. By annealing its tool usage, the AI stops wasting tokens and time querying databases for standard workflows it has already mastered.

Simultaneously, the agent demonstrated "harness evolution," where it dynamically adapted its strategy based on the complexity of the situation at hand. While it bypassed its tools for simple, familiar tasks, it actively chose to scale up its use of the Belief and Experience modules the moment it encountered novel environments or unexpected roadblocks. For example, if an AI agent is migrating standard database records, it moves fast. When it encounters a strange legacy API endpoint or a complex validation error, it slows down, pulls up the live server logs, and queries its historical tickets to safely resolve the edge case rather than hallucinating a guess.

Bringing EvoHarness-RL into existing systems

Despite these massive gains, adopting a new framework often introduces friction for enterprise engineering teams. However, EvoHarness-RL utilizes an environment adapter that allows internal implementations to remain domain-specific to an organization's existing tools while sharing the trainable layer.

"I think there is significant potential to integrate BPE into existing orchestration systems," Ning said. "It does not necessarily require teams to replace their current tools or agent frameworks. BPE can work as an additional state-management layer that continuously organizes what the agent currently believes, how far it has progressed, and what it has learned."

For enterprise builders worried about inference costs, the framework addresses the hidden engineering cost of consolidation. Because consolidation requires strong reasoning, teams can adopt a hybrid, asynchronous architecture to optimize budgets.

"One possible compromise is to use a frontier model to generate high-quality consolidation data, then fine-tune a capable open-weight model to handle routine state management," Ning said. Furthermore, "because consolidation can happen asynchronously, it does not always need to slow down the agent’s main execution loop."

Teams must also carefully evaluate when a trainable BPE harness is necessary versus when it is overkill.

"For a short and stable task, ReAct or standard RAG may already be sufficient," Ning said. "BPE becomes much more valuable when an agent works for many hours, days, or even weeks." In those complex scenarios, an agent needs a compressed understanding of its decisions to avoid getting lost, relying on Experience to iteratively improve from previous failures and human feedback.

Ultimately, this approach signals a shift for AI orchestration engineers. "It is not a complete replacement of workflow engineering," Ning said, "but a transition from directly scripting agent behavior to creating systems in which better behavior can be learned."

Enterprises trying to feed PDFs, slides and scanned documents into AI pipelines keep running into the same wall: the tools either miss the structure — tables, charts, layout — or cost too much to run at scale.

Cohere released Parse 5 on Thursday, positioning it on price-to-performance, not raw accuracy — the right cost-capability mix for enterprise scale. Parse 5 is a 2.3-billion-parameter vision language model built to convert PDFs, slides and images into structured Markdown at enterprise scale. 

Cohere's own published benchmark comparison puts Parse 5 behind three larger, general-purpose frontier models on accuracy. GPT-5.5, Opus 4.8 and Gemini 3.5 Flash all score higher than Parse on the three ParseBench dimensions Cohere reports. Cohere is not claiming the top score. It is claiming the best price for a score close to the top.The company priced the model at $1.50 per 1,000 pages through its API, with Model Vault, Cohere's secure, single-tenant platform for managed inference, available for higher-volume deployment.

"Document parsing isn't solved because the hard part isn't reading text, it's preserving structure and meaning," Nils Reimers, VP of AI Search at Cohere, told VentureBeat. "Enterprise documents mix tables, diagrams, charts, and formatting that change the interpretation of the data. Most tools still drop structure or hallucinate content, and even frontier models break on layout‑heavy pages."

Inside the single-pass architecture

Parse 5 takes a page as an image, runs it through a single vision-language model pass and returns structured Markdown, collapsing the OCR-plus-model pipeline most tools run as separate steps.

Architecture. It is a 2.3-billion-parameter vision language model built on Cohere Labs' North-Micro-Vision-Instruct architecture, with an 8,192-token context window and roughly a 4.6-gigabyte footprint. It accepts a PDF, PowerPoint or JPEG page as a base64-encoded image and returns Markdown in reading order, with tables rendered as HTML, image descriptions and bounding box coordinates for tables and images.

Language coverage. Arabic, English, French, German, Italian, Japanese, Korean, Portuguese and Spanish get stable accuracy, with lower-accuracy zero-shot support elsewhere.

Output modes. The default output returns a Markdown string per page. A blocks mode returns typed elements, where each table carries its own HTML, bounding box and description, the format Cohere positions as what makes citation-level traceability possible for agents.

Availability. Parse 5 is generally available now through the Cohere API, Model Vault, Microsoft Foundry and AWS SageMaker.

The benchmark shows a trade-off, not a win

ParseBench is a benchmark that scores document-parsing tools against human-verified enterprise pages. Cohere reports Parse 5 scoring 79.2 across three dimensions: tables, content faithfulness and semantic formatting. That puts Parse 5 behind GPT-5.5 (84.4), Opus 4.8 (84.3) and Gemini 3.5 Flash (81.8), and ahead of LlamaParse's Cost Effective tier (78.3), Mistral OCR 4 (74.5), Databricks AI Parse (72.4) and Azure Document Intelligence (69.3).

Cohere's table notes two excluded dimensions, Layout and Chart, and attributes both to product scope rather than a performance gap. Parse 5 returns reading-order Markdown instead of per-element bounding boxes for text, and describes charts rather than extracting their underlying data, with chart-data extraction planned for a future version.

Reimers said that design choice reflects where agentic workflows actually break.

"For charts, for example, we provide a general description of the chart together with an indicator, how Agentic AI can visually inspect the chart," Reimers explained. "Other solutions try to extract the data from the chart, but then miss out critical information (for example, the color or the pattern of a line) that leads to hallucinations in Chat and Agentic AI applications."

Cost is where Cohere makes its real case. Reimers pointed to a workflow the company modeled for a large financial services firm.

"We ran the numbers for a large financial services workflow that processes 750 million documents a year and showed that choosing Parse 5 over a large general‑purpose model like GPT‑5.5 would reduce costs by more than 98 percent."

That figure is Cohere's own estimate for a single modeled workflow, not an audited deployment.

Where Parse 5 sits against the field

There is no shortage of options for enterprises looking at parsing solutions.

General-purpose frontier models, GPT-5.5, Opus 4.8 and Gemini 3.5 Flash, top the accuracy comparison but carry the cost and latency of a large model on every page. 

Then there are specialized parsers, including Mistral OCR 4, LlamaParse and open-weight options like Chandra OCR 2 and RedNote's dots.mocr.

Hyperscaler document intelligence services, AWS Textract, Google Document AI, Azure Document Intelligence and Databricks AI Parse, compete more on ecosystem convenience than on raw parsing quality, and score lowest in Cohere's own comparison.

Kevin Petrie, VP of Research at BARC US, said document parsing sits at the center of enterprise AI adoption right now.

"We're completing a survey now that shows document analysis is by far the #1 use case for AI, with 62% adoption rates among organizations we polled," Petrie told VentureBeat. "Documents and other unstructured objects, including images and so on, hold the proprietary context that organizations need to differentiate their agentic AI initiatives."

Petrie added that only time will tell how Cohere's cost-performance stacks up against frontier models, but strategically his view is that Cohere has the right focus. 

Stephanie Walter, Practice Leader for AI Stack at HyperFRAME Research, sees Cohere Parse 5 as sitting in a good spot between legacy OCR and using an expensive frontier model on every page. 

"Its potential advantage is delivering structure, spatial provenance and private deployment at a price suitable for high-volume ingestion," Walter told VentureBeat. "It does not need to win every benchmark. It needs to make reliable enterprise-scale parsing economical."

The real test is downstream, not on the benchmark

"Parsing is the first quality gate in the enterprise AI stack," Walter said. "If tables, headings, images, or reading order are lost during ingestion, better embeddings and larger models cannot recover that missing structure."

A benchmark score isn't the only input that matters here. "Enterprises should test parsers against their own most difficult documents and measure downstream retrieval and task accuracy, not how clean the extracted text looks," Walter said. "The right question is not 'Did it read the PDF?' but 'Can the agent now use the information correctly?'"

Presented by Gravitee

Agent complexity is the insidious shadow lurking inside enterprises right now that needs a light shone on it.

That’s because enterprises don't deploy a single agent and watch it run, they deploy fleets, each one calling APIs, calling other agents, reaching into applications that were never built with a machine decision-maker in mind. That's the failure mode that should keep you up at night: a windy, complicated system nobody can see clearly enough to govern. But why do things get so opaque so quickly?

Add a second agent to a system, and you've added one connection. Add a tenth, and you haven't added ten connections, you've potentially added dozens, because now any agent might call any other, and each of those calls can trigger a call somewhere else. Complexity doesn't creep up with agent headcount. It compounds with the number of paths between agents, and nobody's job is to draw that graph. A support ticket that used to touch one system might now pass through four agents before a human ever lays eyes on it, and every one of those handoffs is a decision point nobody approved.

Most enterprise AI programs stall when the humans responsible for their agents lose the thread. Ask a security team a simple question: which agents can reach which systems, and watch the silence. Ask which agent triggered which downstream action three hops ago. More silence.

The instinct is to treat this like a checklist. Approve the agent. Log the agent. Move on. I'd argue this is the wrong instinct. A checklist checks a single point in time. Complexity runs across a chain, and you can't govern a chain with a stack of one-time approvals any more than you can call a diet successful because you had a vegetable once.

So where does it actually break down?

Permissions creep first. Somebody builds an agent to summarize support tickets, grants it broad API access because scoping it properly would've taken another sprint, and forgets about it. Six months later, that same agent has a path into the payments system. Nobody remembers signing off on that. Nobody did.

And ownership thins out the further the chain runs. Five agents touch one workflow, something breaks at step four, and now you're asking who's responsible for a link nobody was ever assigned to own, because the org chart stopped at "deploy the agent" and never got to "name the human who answers for it."

This is a story about governance infrastructure that hasn't caught up with how agents actually behave: interconnected, cascading, multiplying faster than the processes built to track them.

Fixing the cluster starts with identity. Every agent needs to exist as its own entity, not a shadow permission borrowed from whoever deployed it. Its own name in the register. Its own scoped authority. A named human sponsor who answers for what it does. That part is necessary.

But it is nowhere near sufficient.

The harder piece is the oversight that holds across the entire chain, not just at each individual link in it. You need to see what an agent did, what it set off downstream, and where that trail ends in real time, not in a report someone pulls together once a quarter. Get agent-level identity right and stop there, and you end up with a filing cabinet full of perfectly documented agents operating inside a system nobody can actually explain.

And oversight by itself only tells you what already happened. Watching a chain isn't the same as controlling it. Enforcement is the piece most programs skip: the ability to stop an out-of-policy call before it executes, not just log it for someone to find in a review three weeks later. A dashboard that shows you an agent breached its scope five minutes ago is a monitoring tool. A system that stops the breach from happening in the first place is governance. Enterprises serious about agent accountability need both, and most have only built the first.

We're all running at blazing speed to ensure we're not the ones left behind in the race we've found ourselves in, and we're all too aware that there's a cost to slowing down. Every enterprise serious about agentic AI hits the complexity wall eventually. The ones that get past it are the ones who built enough visibility and accountability, so their fleet can keep growing without anyone losing the ability to answer one question: what is this system doing right now, and who's responsible for it.

But don't miss the point. Complexity isn't a reason to pump the brakes. The enterprises getting this right aren't slowing down. They're building toward Human-Agent Harmony, where scale and accountability grow together instead of trading off against each other.

The real risk was never a single agent doing exactly what it was built to do. It's a hundred of them doing exactly that, all at once, interacting in combinations nobody designed for. That kind of multiplication is what keeps enterprise AI stuck running pilots forever instead of running production.

Solve for complexity and autonomy stops being the villain. It starts being the whole point.

Rory Blundell is CEO at Gravitee.

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

Visa's open-source security harness now finds the vulnerability, writes the fix, and turns an adversarial panel on its own patch before any human reviews it. The whole loop ships on by default. A plain scan of the Visa Vulnerability Agentic Harness runs all 11 stages and edits source files in the target repo unless the operator caps it at detection.

The announcement Thursday pairs the release with an expansion of the Visa Consulting & Analytics advisory practice. Visa is shipping that default 18 days after Tenet Security demonstrated GhostJacking on the DEF CON 34 main stage, an attack chain in which an agent read an attacker's payload out of a log file and rewrote DNS with a valid credential. Two days earlier, Steve Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, made the case in VentureBeat for the opposite default. "The first thing I'd do is put an authorization gate outside the model," Wilson said in written responses. "The agent can propose the exact DNS change, but it cannot grant itself the authority to make it."

The bottleneck moved, so Visa moved the pipeline

Rajat Taneja, Visa's president of technology, rejects the premise that the default is a risk decision and calls it the product. "The bottleneck has moved," Taneja told VentureBeat in an exclusive interview. "AI is finding vulnerabilities faster than humans can in the history of our technology industry. The new bottleneck is fixing and proving we have fixed things."

VVAH grew out of Visa's participation in Anthropic's Project Glasswing, where the company aimed Claude Mythos at the network behind billions of daily transactions and watched the model chain minor weaknesses into working exploits, a hunt VentureBeat covered in July. "VVAH initially was completely only using Mythos, and that's when all of us, as part of Project Glasswing, realized the power of this new class of models that does semantic reasoning," Taneja said.

The harness went to GitHub in June and has climbed from 595 stars and 97 forks on July 20 to more than 2,300 stars and 300 forks as of August 25, with a clone-to-visitor ratio Taneja put near 9%. "We have got some very high-profile companies that have started using this harness," he said.

Why give it away? Taneja's answer starts with Visa's technology DNA and a harness built "to protect Visa and our ecosystem." The reason he leaned on hardest was obligation, "to do good by doing right" for "companies who may not have the same level of investments or knowledge in cybersecurity."

Contribution runs one way. The repo states it is not currently accepting external code contributions, so the harness that edits adopters' source takes no code into its own.

Thursday's release extends the pipeline past the report. "We're going from discover, verify, and report, and then fix it, to discover it, verify it, remediate it, validate it, and iterate it," Taneja said. "If a fix doesn't negate the exploit, then there should be a structured, automated feedback that preserves the learnings from the first run and then enhances it." Underneath that loop, the release refactors scanning around an abstract syntax tree call graph that maps subroutine calls and the traversal paths an attacker could reach. Taneja argued the change cuts token counts while delivering "better reasoning, context, and better exploitability analysis." On top sits MTTA observability across the stages, what he called a window pane, plus real-time progress views. "A pretty good step function," he said of the release.

One metric, three definitions

Mean Time to Adapt, the metric Visa invented alongside the harness, gets a shorter definition in this release. The short form is the time between discovery and resolution of attack paths, with some resolutions, Visa claims, shrinking from weeks to hours. Visa published a wider construction in June, and the Project Glasswing white paper tracks MTTA along three dimensions that include inventory freshness, exploitable paths per release, and validation cycle time. The repo carries a third, elapsed time from AI-discovered exploitability to a validated fix in production. Board slides will quote the shortest interval. Ask for all three, because a resolution count that skips validation is what MTTA was invented to replace.

Taneja ranks MTTA as "the most strategically important metric" because it shifts the focus from scanning to how fast an enterprise adapts. His shorthand is blunter. "It's not the finding. It's the fixing that matters," he said.

The default and the gate

Wilson's argument went past naming the gate. "We have to remember that security rules written inside prompts may shape the model's behavior, but they are still suggestions to the model, not enforceable security controls," he wrote. He also priced the control honestly. "The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation," Wilson said.

The harness ships no approval step between patch and edited file. Where the human sits was the first question VentureBeat put to Visa in writing.

The company's own June white paper sets the bar. "AI agents are identities" sits among its 12 non-negotiable practices, requiring scoped permissions, least privilege, audit trails, and IAM governance for every agent that modifies a system. VVAH's shipped default is that agent.

"A lot of the traditional systems that are used today are basically signal providers," Taneja told VentureBeat. "They are telemetry, and then it's a lot of human analysis, and your SOC and your security and incident response teams doing a lot of the heavy lifting when they respond," and that, he said, cannot work at this scale. He pointed to the Hugging Face incident and "other frontier models escaping sandboxes to do things more autonomously" as the preview. "We have seen the trailer of this movie," Taneja said, and "every company in the world should prepare and rethink their architecture."

What the harness automates is the adversarial step. Before a fix counts as validated, the panel scores whether the patch negates the exploit, Taneja's test for done, with failed fixes feeding the next attempt, the iterate step Taneja described. Stage 11 itself runs read-only, per the README, and VVAH does not compile, build, or run tests against the patched tree. Taneja calls that wrapper "the governance architecture on top of that," and chaining findings into working exploits takes threat modeling and business context, which is why he argued "the harness with a model is far more effective than somebody using the model by itself."

Visa answers the gate question

VentureBeat put its questions to Visa in writing after the interview, and the answers arrived before publication. On why remediation ships on, the response repeated the bottleneck argument, then narrowed the scope. "VVAH is meant for authorized operators running against code they own, and in a controlled environment," the company said in written responses.

The approval question drew the most specific answer. "VVAH is a harness, not a merge tool," Visa wrote. "Stage 10 writes candidate fixes to a working copy of the repo. Stage 11 then runs an adversarial validation panel that scores each fix and returns one of three verdicts: validated, validation failed or needs review. None of these bypasses your normal build, test, and code review flow." Humans, the company wrote, are "the gate in three places. Before running the tool. When reviewing the patches. And before anything gets merged." "The final call on any fix stays with the security and engineering teams. In an enterprise, trust and auditability are not optional. The default flow is built around that."

Set beside Wilson's standard, the architecture lands close to his line and the sequence does not. Wilson's gate clears an action before it happens. The default's human gates open before the run and after the write. The attack is the automated part, and the three human gates sit outside the model, the boundary Wilson drew. "Our goal is to help security teams work at AI speed, not to replace them," Visa wrote. "VVAH does the repetitive parts. It finds issues, tests whether they are real, and proposes fixes. Before a fix gets to a human, an adversarial validation panel at stage eleven tries to break it. That way the human is spending time on decisions that need judgment, not on triaging noise."

Client zero got direct confirmation. "VVAH runs against Visa code today," Visa wrote, and Taneja had volunteered the posture on the call. "We designed this and we were using it for ourselves, and we were client zero," he said, adding "only when we saw the impact and the positive effect of what we were finding, we said every company would need this." What adopters value, Visa says, is context. VVAH pulls in CMDB data, threat models, and business risk, and where "most tools stop at findings," it "tries to answer, 'which of these should you fix first, given how your business runs.'"

Model choice becomes a per-stage decision

Multi-model orchestration is the other substantive change. "Mythos has a very high recall, but the Opus model has very high precision," Taneja said. "On stage one I want to use this model. On stage two I want to use this model," is how Taneja framed the per-stage setup, with newer GPT releases in the ensemble and open-weight models where pricing stings, all through configuration rather than code changes. "The whole is greater than the sum of the parts," as he put it. The harness was model-agnostic from day one, he added, and the evolution moved that choice into configuration, with prompt tuning and caching shared underneath. One boundary moved. In June, applying a fix required Anthropic backends, and OpenAI-compatible backends ran report-only. The current README extends remediation and validation to OpenAI-compatible and open-weight models through a shared model-agnostic runtime, with no single provider as a hard dependency, and the default routing for both stages stays Anthropic.

That flexibility lands on a market already churning. VentureBeat's Q2 2026 Pulse research found 59% of enterprises plan to adopt or switch agent security tooling within the year, and 82% still rely on provider-native controls as the primary layer. Visa said Thursday it is contributing VVAH to Nvidia's Open Secure AI Alliance as a model-agnostic framework and collaborating in Project Lightwell, the $5 billion IBM and Red Hat effort to harden open-source components.

Before turning fix mode on

Consulting is the other half of Thursday's announcement. Visa Consulting & Analytics is adding executive workshops, a VVAH-informed maturity assessment scored on a NIST one-to-five scale, and a cyber risk prioritization roadmap. "We were getting a lot of calls. Hey, can you help?" Taneja said, and the practice "became very important to handhold and help those who are using it." Carl Rutstein, global head of Visa Consulting & Analytics, framed it the same way. "Finding vulnerabilities is no longer the hardest part. Speed to remediation is the new battleground."

Presented by EDB

As enterprises give AI agents more autonomy — the ability to plan, decide, and act across systems without a human approving each step — a hard question moves to the center of every architecture review: When an agent tries to complete an action that it was never authorized to do, what actually stops it?

These are your agents, running on your models, touching your data in your infrastructure — and the responsibility for what they do sits with you. That responsibility can’t be met in hindsight or with a set of abstract policies that live on paper but not in practice. Agents need rules in the context of the moment, because they don’t exercise overriding judgment of their own actions.

Consider a simple rule: Never open the car door. Followed literally, an agent could never get in or out of the car at all. But if you change the context (the car has just crashed, there’s a fire, someone is hurt and needs to get out), then the rule you actually want is the opposite. Context in the moment is everything. We are asking agents to do intelligent things; that requires intelligent rules.

The instinct is to add guardrails around the agent: instructions, policies, and monitoring layered above the model. Those mechanisms matter, but they share a structural limit: The car-door rule is plausible right up until the moment you actually have to decide whether to open the door. Controls at the agent layer are only as reliable as the agent’s output is predictable, and autonomy is precisely the property that makes that output hard to predict. Governance that depends on reviewing an action before it happens cannot keep pace with a system that acts in milliseconds, across many systems at once.

Governance has to become executable, and enforced where agents actually do their work: at the operational data layer, in the context, and exactly at the moment it is happening.

The data layer is the enforcement point

Agents create value by touching data. They query it, retrieve it, transform it, and increasingly act on it. A policy that says an agent should not reach a certain class of data is meaningful only if the system can deny that access at the moment the agent requests it. Additionally, a principle that says AI must be auditable is meaningful only if the organization can reconstruct what the agent did, what data it touched, which user it acted for, and what resulted. When governance lives at the data layer, it holds regardless of how the agent was built or how it behaves, because the control is a property of the database itself, not a promise made by the agent.

Agent behavior may be probabilistic. Governance cannot be

The enterprise should not rely on a model choosing to follow policy. The policy has to be enforced by the system. That is the difference between hoping an actor stays in bounds and constructing bounds it cannot cross to begin with.

The controls that make this real are ones many enterprises already run at the data layer: role- and attribute-based access, row- and column-level security, classification and masking, policy as code, and complete audit trails.

What agents change is not the mechanism, but who the mechanism has to recognize. Identity management has to treat the agent as a principal in its own right, with its own identity and a purpose declared when the session opens.

Once purpose is bound to identity, the policy engine can evaluate it the same way it evaluates role or department today, and the record of what happened can capture not just who acted and what they touched, but what they declared they were there to do.

In practice, this resolves into nine controls, grouped under three imperatives:

Enforce it

• Role- and attribute-based access control enforced at query time, for agents as well as users

• Dynamic column masking driven by the same policy path

• Agent identity as a first-class principal, with declared purpose bound at session start and the acting user preserved

See it and prove it

• Classification and tagging that drives policy

• Session-level audit logging that records which agent acted, for which user, and under what declared purpose

• Lineage across pipelines, so a result can be traced back to the request that produced it

Unify and harden

• Centralized, portable policy management

• Encryption at rest and in transit

• Consistent enforcement across on-prem, cloud, and sovereign or air-gapped environments

“Declared purpose is what makes the difference. It becomes an attribute the access layer already understands, evaluated in the same policy path as role and row-level security. The enforcement mechanism does not change. What changes is that the agent's purpose is part of what it evaluates, and part of what the record proves afterward,” says Priyanka Jain, VP, product management, data & AI governance, EDB.

Wherever you are in your AI adoption journey, enforcement at the data layer is what lets you move faster rather than slower. The controls are already in the database. The difference is that agents now have to pass through them.

A digital leash, not a locked door

The goal is not to stop agents from doing useful work. It is to define how far an agent can go, what it can touch, what it can change, what requires escalation, and how the organization can reconstruct events if something goes wrong. Governed this way, agents are identified, scoped, monitored, and auditable. The enterprise can adopt them faster, because security, risk, and leadership teams trust the operating model underneath.

Open, sovereign, and enforceable at the source

Built on open source Postgres, this open foundation keeps enterprises in control of where their data lives, who can reach it, and under what policy, without ceding governance to a layer they don’t own or can’t inspect. For regulated industries, that combination of data sovereignty and source-level enforcement isn’t a nice-to-have; it’s the precondition for putting agents into production at all.

Agentic systems will keep getting more capable and more autonomous. That is a reason to be deliberate about where control lives, not a reason to slow down. The enterprises that enforce governance at the data layer can move aggressively on AI, because the thing protecting their data is more than just wishful thinking.

EDB Postgres AI is an open, enterprise-grade sovereign data and AI platform that unifies transactional, analytical, and AI workloads — with governance enforced where the data lives. For the full framework, see EDB’s white paper Governing Agentic AI at Enterprise Speed.

Max Romanenko is Chief Technology Officer at EDB.

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

A week ago, a mystery model called Ox Alpha showed up on OpenRouter — one more entrant among more than 400 models, with roughly 10 new ones launching every week. What made it stand out wasn't just the free price tag; it was quietly good. Hobbyists and indie developers noticed fast, pushing several trillion tokens through it daily, with community estimates for the week ranging from single digits to over 20 trillion.

AI enthusiasts spent the next six days doing forensics and speculating who could have built it, and who could have the infrastructure to serve that many tokens for free. First the guess was a U.S. lab: the long-awaited Gemini, or Anthropic shipping a good-enough middle tier, or Elon sitting on so much capacity he dropped Ox Alpha (note the naming). People ran tokenizer traces and networking analysis. A real Sherlock Holmes mystery week.

On August 26, Z.ai put its name on it. Ox Alpha was GLM-5.3-Flash. They'd been running it on public traffic on purpose, but the real surprise was not how good the model was (it's really good). It was served entirely on Chinese chips and infrastructure. List price is 15 cents / 50 cents per million tokens. OpenRouter's launch promo is 50% off that, 7.5 cents / 25 cents, through September 9. The weights are open (MIT), and inference is hosted by Z.ai as well as GMI Cloud, Cloudflare, and other US-based inference providers.

Artificial Analysis put the model on their intelligence-versus-cost chart the same day. GLM-5.3-Flash lands at 57 on the index for about nine cents a task. A US mid-tier like GPT-5.6 Sol (max) sits around 59 at 67 cents, meaning for two points of intelligence you are paying about 7.4x more. Take it further and Grok 4.6 is at 61 at 94 cents a task, or about 10x for a four-point gain. At this point the token economics heavily influences the consumption calculus. At the top end the curve has flattened. If we take this open-weight bait, what happens to the heavy infrastructure circular investments we made that never accounted for a strong Chinese inference contender?

American enterprises are already feeling the cost pressure. Take Uber. CTO Praveen Neppalli Naga told The Information in April he was going "back to the drawing board because the budget I thought I would need is blown away already": the company's full-year 2026 coding budget gone in four months, with Naga personally burning $1,200 in a single two-hour demo. By June, Uber had put a $1,500-per-person-per-tool cap in place. The tools were useful — but usefulness and value aren't the same thing. Uber's COO, Andrew Macdonald, still couldn't draw a line from those dashboards to "25% more useful consumer features."

McKinsey's 2026 State of AI survey says 80% of people say they're faster, 37% of companies see some EBIT, and 32% skipped at least one software purchase because they could build that feature in-house with coding agents. Organizations want to cut the bill. They cannot afford to abandon AI. The task now is to optimize usage across the org.

We cannot avoid Chinese model makers like Zhipu, Qwen, DeepSeek, and the rest. Time and again they have brought their own ingenuity to challenge SOTA labs and cut costs. On OpenRouter, Chinese models passed US token share in early June, and the top of that board is still mostly Chinese labs. The indie developer world already looks like GLM Flash, DeepSeek Flash, MiniMax, Kimi, and sometimes Grok or Claude if they already paid for a heavy subscription. If you are already subscribed to Grok or OpenAI through your company, that is now a sunk cost. Finance will start asking whether those seats still make sense if pay-as-you-go gets this cheap.

So what choices remain? Consider your coding and agentic work in three buckets, split by share of tasks and tokens run through each tier — not dollars, since GLM-5.3-Flash's much lower per-token price means an even dollar split would already send most of your volume there. At the very top you have Fable and Opus. If you need to analyze a complex strategy or write a detailed execution plan, the extra points of intelligence matter and you should spend top dollar, but only for those rare tasks you cannot skimp on — probably 5% of the task volume. The mid tier is Kimi K3, Gemini 3.7 Flash, GPT-5.6 Sol, and Grok 4.6, all sitting around 60 on the intelligence index. Kimi is a heavy hitter for coding and a fan favorite; then Grok 4.6 is a close second, though its smaller context window holds it back. Put about 50% of the volume here. For the last 45%, strongly consider GLM-5.3-Flash as the volume workhorse. Your harness, your mix (coding vs content vs marketing), and your evals will draw your own frontier. Chinese open-weight models will save you money — and they need to be in your cost calculus.

September is shaping up to be a deluge of new models — Google, xAI, Anthropic, OpenAI, and DeepSeek all have releases expected. The Pareto frontier might move again. But the direction is set: more intelligence for less money. Labs that can't get their serving costs down will lose the volume — and with it, the audience that volume creates.

Before September, some homework:

1. Count your tokens. Can you attribute spend to a top-line metric like customer or revenue growth? If not, at least development velocity or productivity? Without clear goals, it is going to be hard to defend the spend.

2. Build your AI budget again. Org by org, what is planned AI spend? Can those leaders come up with a proposal and defend it?

3. Define your model strategy by team. Write the three tiers. High for irreversible decisions and strategies. Mid for the paid seat and everyday coding. Low (GLM-5.3-Flash) for volume.

Next month the models get cheaper again. Your teams get hungrier. The companies that come out of this will place their bets intentionally, and they won't let those agents think on Opus or Fable unless the task is really worth it.

Parvez Syed Mohamed is a product executive who has built API integration and agent platforms at Salesforce (MuleSoft), Oracle and at AgentPaaS.ai. He works on production agentic systems. Some of his thoughts on building software with Agents is here: https://github.com/parvezsyed

Welcome to the VentureBeat community!

Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise.

Read more from our guest post program — and check out our guidelines if you’re interested in contributing an article of your own!

Salesforce and Anthropic announced Tuesday a sweeping expansion of their partnership, called Claudeforce, that pushes the world's largest customer relationship management platform directly inside Claude — a tacit acknowledgment that the future of enterprise software may not involve enterprise software's own screens at all.

The centerpiece of the announcement is Salesforce in Claude, a plugin for Anthropic's Claude CoWork that ships with 37 pre-built sales skills — covering meeting preparation, deal health reviews, and pipeline analysis — and lets sellers query, update, and act on live CRM data without ever opening Salesforce itself. The product is available to select pilot customers today, with an open beta planned for September and additional skills for other business functions beginning to launch in the third quarter.

Marc Benioff, Salesforce's chair and CEO, and Dario Amodei, Anthropic's CEO, were scheduled to appear on television together Tuesday afternoon, hours before Salesforce reports quarterly earnings — a piece of stagecraft that underscores how central this partnership has become to both companies' narratives.

"We're bringing together the world's #1 AI and #1 CRM — the best of both worlds," Benioff said in a statement. "Here, the UI is the AI — allowing you to build custom apps dynamically and answer any enterprise question. Probabilistic intelligence alone doesn't run a company, and deterministic systems don't reason."

But the more revealing framing came in an exclusive interview with VentureBeat, where Patrick Stokes, Salesforce's president of applications and marketing, described the launch in terms that would have been unthinkable for a major SaaS vendor even two years ago.

"We think that what this can do is kind of be a version of what Claude Code did for developers," Stokes said. "We think we're about to do the same thing for knowledge workers. This is just a whole new way to work."

How Salesforce turned its headless CRM experiment into a one-click Claude plugin

The road to Claudeforce began in March, when Salesforce released Headless 360 at its TDX developer conference — a collection of APIs, MCP servers, and command-line tools that let AI agents call Salesforce data, workflows, and governance rules directly, with no user interface required.

"I think we really kind of surprised the world a little bit with our Headless approach," Stokes told VentureBeat, "basically kind of openly suggesting that these agentic interfaces are a really good way to use Salesforce's products, and we don't actually mind if you don't use Salesforce's products exclusively through a user interface designed for a human."

What happened next, according to Stokes, was both validating and messy. Customers rushed to wire Salesforce's MCP servers into agentic interfaces — "but really, Claude rose to the top," he said. The problem was friction. "Every individual user has to know what an MCP server is. Obviously, your average knowledge worker out there is not dealing in MCP servers every day. And you know, even if you can find it, how do you wire it up? And then, how do you make sure that it's respecting the permissions of the users?"

The answer came from an unexpected source: Anthropic's own workforce. "We sat down with Anthropic and we talked about the problem, and they said, 'Hey, this is actually how we're using Salesforce. We use Salesforce pretty much exclusively through Claude and a series of skills and MCP servers that we have,'" Stokes recounted. The two companies decided to productize that internal setup as a CoWork plugin — one that an administrator connects a single time, with authentication and permissions managed centrally, so "all of the difficulty of wiring up every individual user with an MCP server is just magically solved."

Under the hood, the architecture is deliberately simple. When a seller asks Claude to update a deal, Claude first reasons over its available skills — "kind of human-like instructions," as Stokes described them — to determine whether specific guidance exists for the task. If it finds a match, it reads the instructions and executes against Salesforce's MCP server, which inherits the user's existing permissions. "If you don't own that record, if you don't have permission to see that record, the MCP server doesn't either, and so you won't be able to read or write it," he said. For enterprise buyers, that may be the announcement's most important technical claim: nothing new to stand up, nothing to re-audit, nothing to configure account by account.

Why Salesforce says letting sellers live in Claude makes its platform more valuable, not less

The strategic tension at the heart of Claudeforce is obvious: if sellers start living in Claude instead of Salesforce, doesn't Salesforce become less important over time?

Stokes rejected the premise emphatically. "That's not what we're seeing at all," he said. "The value of Salesforce is not in our UI itself. It's not the application. The value of Salesforce is in the data and the metadata, the years worth of kind of encoded workflows and business practices that have been built up inside of Salesforce. What we're doing is we're taking that and we're exposing it to a new UI."

He offered a concrete example of the productivity math Salesforce is betting on. A seller's morning ritual — deciding which opportunities to work — traditionally means opening an opportunities list, clicking into each record, reading activities and meeting histories, and synthesizing everything mentally. "That process of evaluating all of those records and synthesizing it and coming up with a plan is like 10,000 clicks inside of Salesforce," Stokes said. "Now you just go to Claude and it's going to execute all of that for you, and it's going to do it in like 30 seconds."

The paradoxical result, he argued: "I'm actually using Salesforce more than I ever would have before, because the work of clicking around to get what I need is gone."

There is self-interest in that framing. Salesforce charges for this new usage through its headless consumption pricing — "depending on your edition of your user license within Salesforce, you effectively get more incremental access to more and more API calls," Stokes explained. Customers separately contract with Anthropic for the Claude inference itself. "You can't buy this on one piece of paper at the moment," he acknowledged. That two-invoice structure hints at the deeper industry shift underway: the slow migration of enterprise software economics from seats to consumption. If agents rather than humans become the primary consumers of SaaS functionality, per-user licensing loses coherence — and Salesforce appears to be positioning API consumption as the successor metric before someone else forces the issue.

What Claudeforce means for Agentforce and the deepening Salesforce-Anthropic alliance

The announcement also raises questions about Agentforce, the agent platform Salesforce has spent roughly two years promoting as its AI centerpiece. Stokes drew a careful taxonomy to distinguish the two.

"These are not apples that you can look at as equivalent things," he said. "Agentforce is really designed for autonomous work or work that touches the end customer. So think about help.salesforce.com — that is an agent implementation specifically designed to interface with the end customer." Salesforce in Claude, by contrast, "is a knowledge worker agent... specifically designed for sellers, for salespeople, to help them do their day-to-day job without having to do the traditional part of their job, which is click around in user interfaces and try to synthesize data themselves."

The distinction is tidy, but it papers over a real strategic evolution. In October 2025, Reuters and CNBC reported that Salesforce was hedging its model bets, bringing both OpenAI and Anthropic into Agentforce and even putting Agentforce inside ChatGPT.

Since then, the relationship with Anthropic has clearly deepened into something closer to a preferred alliance: Bloomberg reported in June that Salesforce's investment in Anthropic was valued at roughly $5 billion, and Tuesday's release makes Claude the default model across Slack — powering Slackbot, the Claude Tag feature Anthropic previewed in June, and the new Slack Code product. Salesforce says 83% of its workforce now uses Claude-powered Slackbot, saving what it claims is 3.8 million productivity hours annually.

For Anthropic, which The Wall Street Journal has reported is bulking up its enterprise partner program amid IPO preparations, the deal delivers something invaluable: distribution into the daily workflow of millions of sellers at companies that already trust Salesforce with their most sensitive commercial data. It also delivers tokens. "Once you start using this, you get very excited and you start to see how it can improve your day," Stokes said. "And yes, that is going to drive token consumption, which is obviously part of the reason why Anthropic is excited about this as well."

Inside the demo: AI-generated dashboards and the rise of the vibe-coded CRM

The most striking moment of VentureBeat's briefing came during a live demo from Shannon Mathews, Salesforce's VP of product management, who showed a seller asking Claude to "schedule a daily briefing to tell me where should I focus my business."

The system returned a prioritized action plan — flagging, for instance, that six closing opportunities had no next steps ("I'm sure my leadership is not going to be thrilled about that," Mathews joked) and surfacing a COO change at a key account pulled from the web. "It really provides a concise call to action of where I should be focusing my time for today and this week," she said, describing the vision as giving every rep "almost an AI chief revenue officer."

Then came the part that gestures at something genuinely new. Mathews generated a full sales dashboard — a "command center" — that Claude coded on the fly as a local HTML file, styled, at Stokes's request, "like Miami Vice, like Tron, just because I thought it was cool."

"This isn't like a product that we're shipping," Stokes said. "This is Claude coding this on the fly using Salesforce data... If you think about all these different tools that we have to use — Salesforce, Workday, or whatever — we always have to use the UI that somebody else decides you're going to use. Now we're just taking Salesforce data and workflows, and CoWork is giving you the ability to make the UI look like whatever you want."

Asked directly whether users can effectively vibe code their own dashboards, complete with actions and tool calls, Stokes leaned in. "This idea that people are going to vibe code their own CRM is probably not going to happen anytime soon. But what we are seeing is that people do want to vibe code their own CRM, and that's what we've enabled. We've just said: do it with Salesforce... You're vibe coding against trusted, governed Salesforce data." At a recent internal leadership summit in Hawaii, he said, "every single one" of the sales executives presenting business reviews "showed up with a command center-like view of their business that they built themselves right inside of CoWork."

The bigger bet: why Salesforce is embracing its own disintermediation

Strip away the branding and Claudeforce amounts to a wager that Salesforce is better off embracing its own potential disintermediation than resisting it. The history of platform shifts suggests that incumbents who fight new interfaces — rather than racing to own their position within them — tend to lose. Salesforce is betting that its moat was never its Lightning pages; it was 27 years of accumulated data, metadata, workflow logic, and governance that no model can conjure and no startup can quickly replicate. As the companies' own launch materials put it, a frontier model without that context is "a genius who's never seen your deals."

The bet carries real risks. If the interface layer commoditizes, pricing power could migrate toward whoever owns the intelligence — and Anthropic, not Salesforce, owns Claude. The consumption-pricing transition could cannibalize seat revenue faster than API calls replace it. And the broader market remains skittish about exactly this scenario: Reuters reported in February that U.S. software stocks staged a relief rally on an Anthropic announcement, a reminder of how much SaaS valuations now hinge on whether AI labs are perceived as partners or predators. 

There is also the unglamorous question of whether enterprises will capture the promised value at all. Gartner forecast worldwide end-user spending on generative AI models at $14.2 billion for 2025, yet McKinsey's ongoing State of AI research has repeatedly found that while adoption is nearly universal, most organizations still struggle to translate pilots into measurable bottom-line impact. Claudeforce's answer — pre-built skills, inherited permissions, one-time setup — is essentially an argument that the ROI gap has been a deployment-friction problem all along.

Stokes framed the moment in almost epochal terms. "Salesforce believes that the interface to SaaS is undergoing a pretty significant period of change, and in some cases aggregation," he said. "We've already seen that AI has changed the way people build software with coding agents, but now we're seeing that it's fundamentally changing the way that people use software — and that can feel very scary on the surface. But our experience is that they're using software way more than they were, because this is unlocking trapped value that is trapped behind a human's own ability to click around and synthesize information themselves."

Whether that proves prophetic or self-serving will play out over the coming quarters, as the beta opens in September and the skills expand beyond sales into service, marketing, and commerce. But the symbolism of Tuesday's announcement is already unmistakable. Salesforce spent 27 years building the defining user interface of enterprise software — and then spent Tuesday morning telling the world its customers no longer need it. The company that taught business how to click is now betting everything on the idea that nobody wants to.

A security agent read a Cloudflare log, found an attacker’s prompt-injection payload sitting inside it, and rewrote the company’s DNS. The firewall had already blocked that payload, and blocking it is what wrote it into the log.

That chain is GhostJacking, which Tenet Security demonstrated on the DEF CON 34 main stage on August 9. A request hits Cloudflare’s managed ruleset, gets blocked, and is stored byte for byte with its poisoned User-Agent header. An AI coding agent reviewing those blocked events reads the attacker's text as an instruction — with no way to tell it apart from one the company meant to give it — and acts on it with credentials the company issued months earlier. In Tenet’s benchmark, Claude Code on Sonnet 4.6 followed the planted instruction in nine of 10 attempts under Cloudflare’s recommended configuration.

The block rate is not the boundary

Nothing malfunctioned. The firewall worked, and every call after it carried a valid credential already issued to the agent. Endpoint detection, the web application firewall and identity management stayed quiet because no rule broke.

Tenet found public evidence of the exposed setup at 48 organizations, six confirmed Fortune 500 companies, and SecurityWeek reported the same chain against Datadog and Sentry, where the injection surface is an alert or an error report. No single platform patch removes the architectural risk: an agent that consumes attacker-reachable data and can independently execute high-impact changes. That is why a high prompt-injection block rate cannot serve as a security boundary.

OWASP’s co-lead names the fix

“The first thing I’d do is put an authorization gate outside the model,” said Steve Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, in written responses to VentureBeat. “The agent can propose the exact DNS change, but it cannot grant itself the authority to make it.”

The move relocates the decision into code that either passes or fails. A safe change, defined cleanly, clears a deterministic policy check and stays autonomous. Anything ambiguous or high in blast radius routes to a named human who approves the actual change.

“The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation,” Wilson wrote.

On teams that try to solve this inside the prompt, Wilson is blunt. “We have to remember that security rules written inside prompts may shape the model’s behavior, but they are still suggestions to the model, not enforceable security controls,” he wrote.

The blocked payload became the instruction

GhostJacking needs no compromised admin account and no bypassed firewall. It needs an agent that reads operational data and holds write access to the systems that data describes. Every step in Tenet’s chain is something the agent was already allowed to do, so tools tuned to catch unauthorized actions have nothing to catch.

The mechanism is specific. SC Media reported that the agent Tenet drove live at Cloudflare was Cursor, reading through a GraphQL integration and writing through the Cloudflare API, and that pairing closes the chain. Tenet ran the chain against more than one coding agent. Cursor carried the demonstration, and the nine of 10 figure came from separate testing of the same attack against Claude Code. The Cursor agent ingests the poisoned header, patches the DNS A record and adds a CNAME to “resolve” the injected finding, giving the attacker a path to reroute the company’s web and email traffic.

One agent’s output became the next agent’s input

Events reach Sentry through a public write-only endpoint with no authentication, by design. Tenet used a leaked identifier to post a crafted error report. On an ordinary triage prompt, the coding agent escalated it to Sentry’s own AI, Seer, then trusted the analysis it got back. Seer had already absorbed the attacker’s proposed fix and returned it as its own finding. What reached the coding agent was a recommendation from another AI, and it implemented that recommendation.

That walked straight through a control Sentry had already written. Sentry's guidance instructs agents reading its event data never to follow directives found there, and the coding agent held to the letter of that rule. It acted on Seer's conclusion instead, and that conclusion belonged to the attacker. It was acting on Seer’s conclusion, and that conclusion belonged to the attacker. An authorization boundary that accepts another model’s output inherits every injection that model absorbed, which is why Wilson’s gate belongs between agents too.

OWASP moved excessive agency from sixth to third

The 2026 OWASP Top 10 for LLM Applications, published August 4, elevated Excessive Agency three places on a ranking blending a 75% practitioner vote with 25% incident data from 6,639 documented cases. It was the largest upward move on the list, driven by real-world incidents clustering in agentic deployments.

The fix isn't better prompting — it's the permission map: which actions are pre-approved, and which need a human. Reading logs, correlating alerts and drafting timelines stay autonomous. A bounded remediation like restarting a named service inside a fixed condition set clears a policy check outside the model. Anything that changes DNS, alters identity privileges, deploys code or reroutes production traffic needs a named human, and letting an agent open new access paths or approve its own proposals defeats the point of the gate. Useful autonomy survives that. What does not survive is the path from an attacker’s text to unreviewed production authority.

What the control costs in practice

Tenet co-founder and CEO Barak Sternberg told Dark Reading that a request the firewall already blocked was the way in, and that the firewall never went down, it just stopped mattering. His own fix is to split what an agent can read from what it can execute, and he concedes the cost, because an agent that reads alerts but cannot act on them is not the agent anyone deployed. The cheaper first step is an inventory. Every agent that reads outside data and can also write or execute belongs on a risk register, and that register needs no new tooling.

Wilson’s design survives that cost because the split it draws is proposal from approval rather than read from write. The agent still reads its alerts, still investigates and still runs bounded work. What it loses is the ability to invent a high-impact change and carry it out on its own authority.

Almost nobody has built it. Kayne McGladrey, a senior member of the IEEE, has argued for years that an AI deployment needs a hard governance threshold, a named human holding a kill switch and a way to roll back. Asked whether any Fortune 500 company runs that, he was blunt. “I haven’t seen it done, and no, they haven’t come out and publicly said it,” McGladrey told VentureBeat.

His reason is economic. Companies “are accepting the risk, and they’re accepting it either deliberately or unconsciously,” he observed, betting the advantage beats the penalty. “What I think would change behavior in the space is if the penalties and the consequences were to outweigh the advantages.” The gate belongs outside the model for a reason unrelated to malice. “If you get into the inference layer, it won’t tell you it’s cheating, and it will lie about having cheated,” he argued, pointing to findings from the U.K.’s AI Safety Institute among others. A system that cannot reliably report its own shortcuts should not authorize its own.

The industry is not positioned to make that split quickly. Ivanti’s 2026 State of Cybersecurity Report found 77% of security professionals at least somewhat comfortable letting AI act without human review, the exact posture Wilson’s gate constrains. CrowdStrike pushed its prompt-injection taxonomy past 200 techniques in July, naming indirect injection through data an agent reads as the critical vector for agents that call tools and run commands.

The architect who moved the boundary before the attack had a name

Egiziago Cioffi hit a related failure in production months before GhostJacking had a name, with one caveat. Cioffi is CEO of SynSphere Italia, a Microsoft reseller, the architect who built and sold the system rather than a security leader defending one he inherited. His Azure OpenAI assistant over SharePoint scored well on faithfulness and still returned content the asking user could not have opened. “An evaluation set with no identity dimension cannot fail an authorisation bug, however high the faithfulness score,” Cioffi told VentureBeat in written answers. He fixed it with a query-time filter built from the asking user’s group claims, so an unentitled chunk never becomes a candidate and never reaches the model. GhostJacking turns on what the model may do, the half Wilson’s gate is built for.

One gap stays open here. No sitting CISO has gone on the record with a change made since August 9 and what it cost in agent capability. Until one does, the cost side rests on the people who specified the control, not anyone defending a production environment with it.

What security leaders need to do this week

Four questions produce an honest picture faster than any procurement cycle. Which agents read attacker-reachable material, which of those can also change production systems, whose permissions run at retrieval, and which changes a policy engine can approve without a human.

Then run the negative test. Plant an adversarial instruction in a log the agent is expected to inspect, and keep the transcript, because that transcript is the difference between claiming a control and showing a test of it.

Tenet, which sells runtime protection for AI agents, leads its own defender guidance with denying an agent outbound network access by default, cutting the leg where the poisoned instruction fetches a payload and reroutes traffic. But an agent that investigates without a standing path to the open internet loses a capability few workflows will miss.

Enumerate the service principals in the tenant, drop the Microsoft first-party apps that ship pre-provisioned, then filter to those holding a credential or app-role assignment. Every identity on that list needs an owner and an expiry date, because one with both gets reviewed and one with neither never does.

For any agent with production authority, write the containment sequence before an incident, not during one. Revoke or rotate its workload credential, disable its write-capable API or tool integration, preserve the execution transcript, then validate and roll back whatever infrastructure it changed.

McGladrey’s read on why the work keeps getting deferred is uncomfortable. “I think that there’s a level of tolerance that’s being given right now in AI that is unlike anything else in society,” he said. GhostJacking makes that visible. A blocked payload reaches the agent through the system built to record blocked payloads, and once it arrives the question is no longer whether the model recognizes an attack. It is whether the model holds the authority to turn one into a production change.

Presented by Tata Communications

Enterprises are deploying AI agents, voice AI, and automation across messaging, voice, and digital channels faster than the architecture meant to support it. Most of that deployment has involved attaching conversational AI to legacy systems never built for it, says Gaurav Anand, global head of the Customer Interaction Suite at Tata Communications.

"In the rush to deploy AI, organizations have largely bolted conversational AI onto legacy systems," Anand says. "As a result, while many enterprises have adopted digital tools, very few have platforms that are truly integrated, scaled, and capable of seamless orchestration."

That gap creates a heavy cognitive load for human agents who must piece together context across disjointed tools to understand what an AI system has already told a customer. The challenge is not simply access to data, but the absence of a shared enterprise context that connects customer identities, interactions, transactions, policies, journeys, and operational systems into a common understanding. Traditional CX architecture was built for linear, human-driven routing, not for managing real-time data flows between autonomous AI systems, data lakes, and human workers.

"Today's operational complexity is no longer about adding more intelligence," he adds. "It is about coordinating the existing intelligence across the enterprise, so the enterprise customer never feels the friction of those internal silos. That requires a shared context layer that allows AI systems, applications, and people to operate from the same understanding of the customer and the business."

Why orchestration is replacing automation as the top CX priority

As that coordination problem grows, Anand says the strategic priority inside enterprises is shifting from automation to orchestration.

"Automation solves individual tasks, whereas orchestration connects them into end-to-end outcomes," Anand says. "The next evolution is context-aware orchestration, where AI agents, applications, and human workers operate using a shared understanding of customers, processes, and business intent rather than isolated system records."

As organizations accumulate more bots, agents, and AI tools, managing them grows exponentially more complex. Anand says the competitive advantage now sits less in deploying automation and more in how intelligently systems hand off work, collaborate, and escalate.

The trap of bolting AI onto legacy systems

Companies that simply place a voice AI agent in front of an existing system are repeating the same old mistake. Instead of improving the experience, they end up recreating the deterministic phone menus AI was supposed to replace. The real benefit of AI is the scale, speed, and orchestration it provides.

Anand points to a wave of consolidation across the industry, as established contact center providers acquire AI-native firms to close capability gaps and strengthen their customer experience offerings. The broader industry shift reflects a growing recognition that enterprises need more than channels and automation; they need an intelligence layer capable of orchestrating AI, people, data, and workflows across the business.

The goal across industries is to make AI the connective layer between customers, employees, and enterprise systems. To achieve that, organizations increasingly need a common enterprise ontology: a shared business vocabulary that aligns customer data, products, policies, SOPs, transactions, and workflows across otherwise disconnected platforms.

Tata Communications’ solution is the Interaction Fabric, an orchestration layer that unifies contact center, messaging, collaboration, AI, and customer data while coordinating AI agents, channels, and enterprise systems in real time. Underpinning that orchestration is a context-driven architecture that continuously connects identities, conversations, transactions, and operational data so interactions retain continuity across channels and touchpoints.

That means AI and agents can move across voice, WhatsApp, chat, email, and CRM workflows without losing customer context. Identity, intent, and AI-driven insight flow continuously across channels instead of remaining trapped in disconnected applications.

The next phase of orchestration is not simply coordinating tasks across systems, but coordinating them through a shared understanding of the enterprise. Context graphs, built on enterprise ontologies, create that common understanding by connecting customers, interactions, products, policies, decisions, and outcomes across organizational silos. This allows AI agents and human workers to operate from the same source of context, driving more accurate decisions, seamless handoffs, and consistent customer experiences.

But synchronizing customer intent, conversation history, enterprise data, and AI decision-making across channels only works without lag. Legacy networks not designed for modern data frequency create what Anand calls data gravity, producing latency and inconsistent journeys as users switch channels.

"The underlying network needs to be engineered to be as agile as the AI systems running on top of it," he explains. "Interactions stay synchronous and technology itself becomes invisible, leaving only an experience that feels effortless."

Making AI a better partner for human agents

Effective shared visibility between human agents and AI systems starts with the agent experience rather than any single technology. The most effective implementations allow both the AI and human agent to operate from the same contextual understanding of the customer, ensuring that information gathered in one interaction can inform the next regardless of channel or system. Automated call summaries, real-time sentiment analysis, and AI-powered assistance provide agents with instant, actionable insights and suggested next steps directly within their workflow.

That allows AI to handle routine, high-volume tasks such as password resets, delivery tracking, and account updates, while human agents focus on interactions requiring judgment and empathy.

"If a customer is facing a sudden crisis like a fraudulent transaction, the AI can instantly block the card, but it cannot provide the emotional comfort and delicate communication needed in that moment of panic," Anand says. "The answer to the dilemma is intelligent orchestration, rather than a choice between systems."

In practice, AI handles the immediate technical transaction, while real-time sentiment analysis recognizes the customer's distress and routes the call to a human expert. The objective is to orchestrate AI and human agents together so efficiency never comes at the cost of brand trust and loyalty.

Building a unified CX architecture

Moving from fragmented experimentation to coordinated orchestration requires both technical and organizational change, Anand says, beginning with consolidating data and fragmented point solutions onto a unified, cloud-first platform.

"IT and CX teams need to work more collaboratively," he explains, describing that alignment as the second necessary shift, this time at the organizational level.

At the architecture level, Anand says communication APIs need to be embedded into the enterprise's core so every function operates from the same customer context instead of maintaining its own siloed data. Increasingly, this means moving beyond integration alone toward a contextual architecture where a shared ontology and context graph provide a common understanding across CX, operations, sales, service, and AI systems. The deeper organizational change, he says, is a mindset shift from reactive support toward proactive, predictive, and personalized engagement, which he calls the three Ps.

How AI agents will shape the future of CX

Customer engagement over the next several years will be defined by real-time intelligence, increasing autonomy, and seamless orchestration across touchpoints, and persistent enterprise context that follows customers, employees, and AI agents wherever interactions occur. Rather than analyzing interactions after the fact, enterprises will increasingly shape conversations in real time.

"The future of CX will be defined by simplification, aligning data, infrastructure, and operating models around clear customer outcomes rather than adding more models and tools," Anand says. "The rise of AI-powered agents and agent-to-agent interactions is a defining trend, with AI systems moving beyond assisting humans to independently managing and resolving interactions, creating a largely invisible layer of engagement that improves speed and efficiency."

Human agents will increasingly work alongside AI, supported by real-time conversational intelligence and next-best-action recommendations to deliver what Anand calls Total Experience: a unified model that brings together customer, employee, and AI-driven experiences. Tata Communications is building toward that future through its Voice AI, AI Workers, and Total Experience Hub solutions.

"Ultimately, customer engagement will evolve from being reactive to predictive and increasingly generative," Anand says. "Enterprises won't just be responding to needs, but actively shaping and improving customer journeys in real time."

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

A CISO who sees a low CVE count and deprioritizes prompt injection is reading the scoreboard wrong. Prompt injection has held the No. 1 spot on the OWASP Top 10 for LLM Applications for three consecutive years. When two leaders of that list checked it against 6,639 labeled real-world incidents, it came back at No. 12. The drop measures visibility rather than danger, because the attack operates where a vulnerability scanner cannot see it.

That finding belongs to Kyriakos “Rock” Lambros and Steve Wilson, two leaders of the OWASP Top 10 for LLM Applications project, who published it on arXiv on August 18 with the disclaimer attached. The analysis is exploratory, not peer reviewed, and not the official OWASP release, and the authors state it does not supersede the official list or its process.

The machinery behind it is real: 7,714 LLM security incidents from CVE, GitHub Security Advisories, OSV, and the AIAAIC AI-harm database, 6,639 of them labeled against a 20-entry taxonomy, and a Bayesian model that corrects each count for classifier error before setting the data-driven ranking beside the expert vote.

The comparison found no statistically detectable agreement between expert judgment and the public incident record. Cohen’s kappa comes in at 0.20 with a 90% interval running from negative 0.16 to 0.57. “The interval crosses zero, so we cannot rule out that the two rankings agree only by chance,” they write. “The honest bottom line: weak agreement, not confirmation.”

Lambros, co-lead of the OWASP GenAI Security Project Top 10 for LLM Applications and director of AI standards and governance at Zenity, put the finding in evidentiary terms in written answers to VentureBeat. “We had two ways of measuring the same risk, expert judgment and the public incident record, and they disagree with each other. Neither one is the truth,” Lambros said. “Two witnesses are contradicting each other, and we can’t tell you which one is lying.”

The attack chain a scanner never logs

The gap is structural. Prompt injection hides instructions inside the content a model reads, anything from a log entry to a support ticket to a document pulled back by retrieval. The agent then makes the tool call the attacker wanted, using credentials it legitimately holds. Nothing in that chain is a product defect, so the attack leaves no CVE behind for a scanner to find.

The defenses that catch it are adversarial tests against the deployed system and hard caps on what the agent can reach, so a fooled model cannot touch anything expensive. The same logic argues for funding agent memory and MCP tool boundaries now, on architecture, rather than waiting for advisory volume that will always arrive a cycle late.

The first control Wilson would deploy

Wilson, Chief AI and Product Officer at Exabeam and project co-lead for the OWASP Top 10 for LLM Applications, named the control he would deploy first against exactly that chain, an agent that reads an attacker’s payload in a log file, treats it as an instruction, and rewrites DNS with a valid credential, in written responses to VentureBeat.

“The first thing I’d do is put an authorization gate outside the model: the agent can propose the exact DNS change, but it cannot grant itself the authority to make it,” Wilson said. “Security rules written inside prompts may shape the model’s behavior, but they are still suggestions to the model, not enforceable security controls.”

The gate has a price, and Wilson states it plainly. “The tradeoff is that the agent loses the ability to improvise arbitrary, high-impact infrastructure changes on its own, while retaining autonomous investigation and routine, bounded remediation,” he said.

Why the No. 1 risk looks small in the record

“Prompt injection is the best-understood LLM attack, and deployed systems defend against it actively,” the authors write, and they compress the whole divergence into one sentence. “Experts rank it first because the attack surface stays enormous even when the defenses mostly hold; the data sees the successes that got through.”

Wilson has watched the gap from both sides of it. “Incident data is incredibly valuable, but it is inherently backward-looking and notoriously tricky to interpret,” he said. “It tells us what was observed, recognized, classified, and reported. It does not necessarily tell us what is most dangerous in the systems people are building right now.”

He compares prompt injection to “death and taxes” and, increasingly, to “a law of physics for LLM systems,” because one model is being asked to interpret trusted instructions and untrusted content at the same time.

Better defenses have not closed the case. “A control that works 99% of the time is not sufficient when the failure case gives an attacker meaningful access. And, frankly, I don’t think we are at 99%,” Wilson said. “The durable answer is not believing we can perfectly screen prompt injection out of existence. It is designing systems with the assumption that prompt injection will occur, understanding why it works, and limiting what an attacker can accomplish when it does.”

A low advisory count can mean the defenses are working. It can just as easily mean nobody has looked, and the public record cannot tell a security team which one it is.

The attempt volume is documented. CrowdStrike’s 2026 Global Threat Report found adversaries injected malicious prompts into legitimate GenAI tools at more than 90 organizations in 2025, stealing credentials and cryptocurrency, under a section titled “Prompts are the New Malware.” The telemetry shows pressure on the attack surface without proving defenses produced the No. 12 placement, but it is the pattern the mechanism predicts.

The gap runs the other way too, and further

Prompt injection is the headline case, and misinformation is the bigger one.

The expert vote puts misinformation at No. 13, while the incident record places it at No. 2. The paper calls it “the widest disagreement between the two witnesses” and reports that its concordance flag “puts the probability that the two signals disagree at 99 percent.”

The authors do not treat their own data as the winner. On misinformation they note the corpus “carries a large volume of deepfake and AI-generated disinformation,” records that often “describe harm produced by an AI rather than a vulnerability inside an LLM.” The authors call it the entry the record most disputes, stopping short of concluding the experts got it wrong.

Where “too new to measure” runs into the CVE record

The two brand-new taxonomy entries sit at the sharpest end. Persistent memory poisoning lands at expert No. 4 and incident No. 16, MCP tool interface exploitation at expert No. 7 and incident No. 16, each with an incident interval of 6 to 20 that spans most of the taxonomy.

Public 2026 CVEs exist for both. On MCP tool interfaces, the Azure Data Explorer MCP Server carried KQL injection, and the CVE record describes it allowing “an attacker (or a prompt-injected AI agent) to execute arbitrary KQL queries against the Azure Data Explorer cluster,” scored 8.3 High. Kong’s Konnect MCP Server shipped an indirect prompt injection that lets a remote attacker steer the server into executing unintended API requests, the exact failure the MCP entry names.

Agent memory has its own record. An agent harness, Ruflo, exposed unauthenticated MCP bridge endpoints that let a network attacker obtain a shell, read provider API keys, and poison the learning store, rated 10.0 Critical.

The record is so thin and uncertain that the model cannot place either entry within 14 rank positions. A team waiting for advisory volume to justify a control on agent memory or an MCP tool boundary would still be waiting while the CVEs accumulate at Critical and High.

Lambros makes the budget case in operational terms. Poisoned memory “doesn’t announce itself,” he said. It looks like a procurement agent told once that invoices from a given supplier under $50,000 clear without a second signature, and because the agent remembers, every approval after that looks like the process working. “Nobody files an advisory for that, because nobody knows it happened. A count of zero is measuring your blindness, not your safety.” The argument he says a CFO will sign off on is timing, since memory and tool permissions get wired into these systems once, early, and everything else sits on top of them. “Build it in now and it’s a rounding error. Come back in two years and you’re re-architecting and re-training your systems.”

The authors flag their own measurement problems first

The expert side is thin. “The expert signal is a practitioner survey: about 29 respondents scored each candidate risk on importance,” the authors write. Twenty-nine votes set the ranking that carries three-quarters of the published list’s weight, the compression point for OWASP’s more than 25,000 community members.

On the data side, the classifier is the weak joint. Precision “varies sharply across entries, from 93% (LLM01, LLM03) down to 13% (LLM08),” four entries fall below 50%, and the base classifier “never predicts ‘out of scope’ and files every incident into some category, including the roughly 38% of the gold set that belongs in none.”

The authors name the central limitation themselves. One reviewer adjudicated all 1,200 gold-set incidents and overrode the model consensus on 553 of them. “A single annotator cannot measure inter-rater reliability,” they write. “The single-author gold set remains the central limitation.”

Lambros lays the weak kappa at the feet of the taxonomy itself. “That number is telling you about our categories, not about our experts,” he said. When the people who wrote a taxonomy cannot reliably sort incidents into it, he argues, “a weak score on the ordering of those buckets is a fact about the buckets.”

A better classifier will not fix the disagreement. A pre-registered bake-off of four frontier models produced no winner. None beat the incidence floor’s balanced accuracy of 0.863, and a ground-truth check left the floor’s ordering in place at a Spearman correlation of 0.918. The authors published the engine and artifacts on GitHub for anyone to rerun.

The robustness result tested only one side of the gap. Every check behind the abstract’s word “robust” runs on the incident side, showing the incident-derived ranking stays put when the labeling machinery changes, and none of it touches the 29-vote survey. A board that hears “robust” will assume validated, yet the record supports only stable.

What the published list did with this

OWASP shipped the GenAI LLM Top 10 2026 on August 4, the first edition to fold incident data into the ranking, weighting the practitioner vote at 75% and the incident corpus at 25%. Prompt injection stayed at No. 1, misinformation moved up two places, excessive agency climbed from No. 6 to No. 3 as the entry where the two signals agree most clearly, unbounded consumption rose four spots to No. 6, and improper output handling fell from No. 5 to No. 10, the largest drop.

Wilson declines to defend the blend as arithmetic. “There is nothing magical about a 75/25 weighting,” he said, “or about reversing it to 25/75. The value of the data wasn’t that it gave us a mathematical answer; it changed the conversation.” The excessive agency entry is where that conversation landed hardest for him. “If I were a CISO evaluating a new agentic deployment today, Excessive Agency is where I would start,” Wilson said.

Lambros would go further next cycle, a view he flags as his own and separate from the working group. The blend hands the same 25% incident weight to every category, while the hand-checked classifier precision runs from roughly nine in 10 on prompt injection and supply chain down to roughly one in eight on vector and embedding weaknesses. A quarter of the weight on the first rides on something solid, he argues, and the same quarter on the second rides on noise. “The ratio should track how well we actually measure each category,” Lambros said.

Why this lands now

Ivanti’s 2026 State of Cybersecurity research found 87% of security teams call adopting agentic AI a priority and 77% report at least some comfort letting AI act without human review. Teams are signing off on agent autonomy while the expert ranking of what can go wrong with those agents shows no statistically detectable agreement with the incident record.

What to do with this on Monday

The behavioral change is narrow and it is the whole point.

• Use the OWASP LLM Top 10 as a coverage map, not a queue. The rank positions carry 29 votes and a corpus whose own authors call the agreement weak, so build your own priority order from your own exposure: production reach, breach-notification data, and controls that have actually been tested. Lambros draws the funding line the same way. “I’d prioritize spend where the expert vote and the incident record point the same direction, because that’s two independent witnesses agreeing,” he said. “Where they split, stop letting the ranking allocate your money and go look at what your own systems are doing.”

• Log what your AI systems are actually doing, field by field. The prompt that went in, what came back out, the documents pulled to build the answer, the tools called and the arguments passed to them, and the model’s confidence score on every response. Confidence is the field Lambros would fight for, because most security leaders do not realize it is measurable, and it is where the attack surfaces. “A model running on a poisoned instruction doesn’t act broken. It acts certain,” he said. “Certainty is what your monitoring treats as a healthy system.” The cost is a sprint or two of engineering. The constraint is a person, because a SIEM does events and these are trends. “Somebody has to analyze those trends every week and say whether a drift means anything, and most security teams have nobody who can.”

• Stop expecting scanner output to reproduce the Top 10’s order. Scanner findings live on the incident side of the gap, counting what got disclosed rather than what a deployed system should fear, and the classifier bake-off shows a smarter model does not close that distance. The test that sees prompt injection is an adversarial one run against the live system, paired with Wilson’s authorization gate so the change an injected agent proposes is never the change it can execute.

• Fund the thin-record categories on architecture, not incident volume. Agent memory and MCP tool boundaries sit at expert No. 4 and No. 7 with incident intervals spanning most of the taxonomy, and the CVEs that do exist are landing at High and Critical. Kayne McGladrey, an IEEE senior member who advises enterprises on risk, put the funding logic bluntly in an interview with VentureBeat. “Anything that seems to have a cybersecurity flavor is generally put into the cybersecurity risk category, which is a complete fiction,” McGladrey said. “They should be focused on business risks, because if it doesn’t affect the business, like a financial loss, then nobody’s going to pay attention to it, and they will not budget it appropriately.” A rank number from a 29-person vote is a weaker budget argument than the business system the agent touches.

• Steal McGladrey’s baseline test for the AI systems themselves. “If you wouldn’t expose your database to the public internet without identity and access controls, why would you do that for your AI model?” he said in CSO Online’s analysis of 2026 breach costs.

The board question for the next meeting is short. If our AI risk ranking came from a 29-person vote and a corpus that disagrees with it, what are we actually using to decide which controls get funded next year?

Perplexity is launching Portable Computer today, a version of its agentic "Computer" platform that runs entirely on hardware users already own — starting with Nvidia's DGX Spark desktop supercomputer and Linux machines equipped with Nvidia RTX GPUs.

The launch, developed in close partnership with Nvidia, is one of the most aggressive attempts yet to move serious AI agent workloads off the cloud and onto local devices. The model, the user's files, and the work itself can all stay on the machine. Work completed locally consumes no billing credits, and the company says every task starts on the device by default — with the system asking permission before sending any individual step to a more powerful frontier model in the cloud.

"We've basically brought the exact same UI to a fully local app," said Nate, Perplexity's vice president of engineering for infrastructure and enterprise, during a press briefing Monday. "This incorporates the entirety of the agent harness and inference and everything needed to do work locally."

For Nvidia, which has spent the past two years selling the world on trillion-dollar AI data centers, the announcement signals something subtler but strategically important: the chipmaker believes local AI has crossed a threshold from hobbyist curiosity to practical tool — and it wants to sell the hardware that runs it.

"Local AI reached an inflection point," said Nader, Nvidia's director of developer technology, who focuses on developer tooling and open source. "For the longest time, it was hobbyists and enthusiasts, and they were running these quantized models that were quantized down to be super tiny... And while that's cool, it's not super practical. But all that changed with a lot of these new open source models that have come out that are super useful."

How Portable Computer packages a full local AI stack into a single app

Perplexity Computer, the company's agentic platform for knowledge work, orchestrates AI models, files, tools, and web access to complete multi-step tasks — reviewing folders of documents, analyzing data, producing reports, and pushing results into business systems. Portable Computer replicates that experience locally: the local models, agent harness, inference engine, tools, app connectors, and a security sandbox come packaged together in a single system. That bundling is the point. With most local AI stacks today, users must assemble and operate those pieces separately — downloading model weights, standing up an inference server, wiring together tools, and tuning performance.

"Historically it's just been really painful to bring up the local AI stack," Nate said. "With Portable Computer, we really focused on just making this a really straightforward experience where you can get up and running very quickly."

In one demo Monday, the system played the role of a retail investor reviewing a folder of 1099s and investment documents — the kind of sensitive financial material many users would hesitate to upload to a cloud service. Running a 27-billion-parameter Qwen model at full GPU utilization on a DGX Spark, the agent reviewed each document and flagged cases where the hypothetical investor was paying unnecessary fees. The interface element that normally displays a running tally of cloud credits "is just parked at zero," Nate noted, "because all of this is happening on the device."

A second demo showed the hybrid side of the product. Playing a startup founder, Nate asked the agent to analyze a CSV of user funnel data locally, then push the finished analysis to a Slack channel using Perplexity's connector ecosystem — proof that local-first does not mean disconnected.

The system also connects to Google Drive, Gmail, and GitHub, and can escalate to a frontier cloud model when the local model hits its limits. At launch, users can set up Qwen 3.8 27B or PPLX 27B, a version Perplexity has post-trained on its own harness, with Nvidia's Nemotron 3.5 Lightning coming soon.

Portable Computer arrives today for Pro, Max, Enterprise Pro, and Enterprise Max subscribers on Linux, with Windows support following in September. Any RTX GPU with at least 24GB of VRAM — roughly a GeForce RTX 3090 or newer — clears the bar, a threshold Nate called "sort of the floor where we really want to make sure that we can deliver a great experience, but balance that with making it broadly available."

Why co-designing the model and agent harness beats general-purpose frameworks

Alongside the launch, Perplexity published a research paper arguing that effective local agents require the model and the agent harness — the scaffolding of prompts, tools, and orchestration logic around the model — to be designed together. The core insight: general-purpose harnesses assume a frontier model that can absorb enormous contexts, navigate sprawling tool surfaces, and plan over long horizons. Small local models buckle under those demands.

Perplexity found empirically that although models like Qwen 3.8 27B advertise 260,000-token context windows, they begin to struggle beyond 100,000 tokens. So the company built a deliberately minimal harness: a succinct system prompt, a small set of core tools, and capabilities that load and unload as on-demand "skills" rather than sitting permanently in context. It converted popular connectors like Gmail and GitHub from token-hungry MCP servers into compact command-line tools, added self-verification hooks that monitor the health of a task, and enforced always-on OS-level sandboxing. If the sandbox is unavailable, the harness disables itself rather than running tools unprotected — a contrast with open-source harnesses that run commands with the user's full permissions by default.

The benchmark results Perplexity reports are striking, though they come from the company's own evaluations. On its internal Local Knowledge Work Bench — 53 tasks spanning deep research, financial analysis, and document creation, which Perplexity says it plans to open-source — Computer running Qwen 3.8 27B on a DGX Spark scored 82.6%, versus 77.6% for the open-source Pi harness and 74.0% for Hermes running the identical model. 

Perplexity's post-trained PPLX 27B pushed the score to 85.4%. The gaps widen dramatically on harder tasks: on BrowseComp, a web research benchmark, Computer hit 66.7% accuracy versus 50.2% for Pi and 43.9% for Hermes, while using 51% less wall time and 70% fewer tokens than Pi. On multimodal document understanding, Computer scored 65.1% against Hermes' 34.6% and Pi's 13.9%.

The token economics driving AI agents from the cloud to local hardware

The strategic logic behind the launch becomes clear when you consider how AI workloads have changed. Chat was bursty — a question, an answer, done. Agents are different.

"With agents, you want these agents always on if you can. You want the agents to really consume as many tokens as they can," Nader said. "What we're seeing is an insatiable demand for tokens, and that's something that makes local AI so great. As you saw through all these demos, you were not metered by the token. You were not paying for the token. So it's really killer for agents."

This reframes the value proposition of local hardware. An agent that runs for hours reviewing documents, verifying its own work, and iterating on analyses would rack up substantial API bills in the cloud. On a device the user already owns, the marginal cost of those tokens approaches zero. Perplexity's paper makes the enterprise version of this argument explicitly: as agents scale across individual workflows and entire organizations, token expenditure and data movement "become increasingly difficult to govern." Local-first execution addresses both at once — spend, because inference is free, and privacy, because sensitive tokens never leave the device boundary.

Perhaps the most commercially interesting result concerns the hybrid middle ground. On Terminal Bench 2.1, a challenging coding benchmark, the fully local Qwen model scored 59.6% at essentially zero marginal cost. Letting it escalate to a Claude Opus 5 "advisor" in the cloud raised the score to 73.0% at an estimated $0.415 per task. Running the frontier model alone scored 82.4% at $0.65 per task. Escalation, in other words, recovered roughly three-fifths of the gap to frontier performance at about two-thirds of the cost — and the user decides when that trade is worth making. Before any advisor call, the harness runs a PII classifier over the outgoing context and shows the user exactly what would leave the device. The remote model returns text guidance only; it never touches local files or tools.

Where Portable Computer fits against Ollama and the DIY local AI stack

Jason Hiner of The Deep View pressed the companies on how Portable Computer relates to existing local inference tools like Ollama. Nate's answer drew a clear line: the tools solve different layers of the problem.

"The majority of the effort here has been at the agent harness level," he said, noting that the system uses vLLM to host model inference underneath, with an advanced mode for users who want to plug in their own inference endpoint. "We've heavily post-trained both the Qwen and Nemotron models that we're working with in order to really get the best possible results... Our focus has been on really honing the whole stack, top to bottom, of the model inference and the harness together."

Nader put it more colorfully. "Just getting inference running really quickly on a Spark — there's a smooth path. You can use Ollama. You can get that set up. But then, as you start to do more complicated, more agentic things, then suddenly you need more perf. You start looking at different models. You start looking at different harnesses, and it's kind of like the ocean. The deeper you go, the deeper it gets."

The appliance-like pitch appeared to land with at least one attendee. Ben, who described struggling to set up his own DGX Spark despite being an engineer — "this experience sucks, we have to fix it" — said the product feels like the unlock "needed for people to really feel and understand what agentic means, and you need the right UX to make it happen." Nvidia also emphasized that the hardware scales: connecting two Sparks over shared memory runs frontier-class open models like DeepSeek's latest, and four can run GLM 5.2 or Nemotron Ultra. "I've even seen eight Sparks get connected," Nader said.

What the deepening Nvidia-Perplexity alliance means for both companies

The launch extends a partnership that has been building for more than a year. In June 2025, Nvidia and Perplexity announced a collaboration to bring sovereign AI models to European publishers and telecoms, part of CEO Jensen Huang's continent-hopping campaign to convince governments that, as the Associated Press reported from VivaTech in Paris, "every country needs a national intelligence infrastructure." The sovereign AI pitch — that data "belongs to your people, your country, your culture," in Huang's words — is philosophically the same argument Portable Computer makes at the scale of a single desk: intelligence you control, running on hardware you own.

There is a self-interested logic for both companies. Perplexity, which has raised capital at steadily escalating valuations while facing legal pressure from publishers over its content practices — including a lawsuit filed by The New York Times in December 2025 and an earlier public dispute with Forbes — gets a product whose economics don't depend on metering every token, and a differentiated wedge into privacy-sensitive enterprises in law, healthcare, and finance. Nvidia gets a killer app for DGX Spark, a device that, by the admission of attendees at Monday's briefing, has been easier to buy than to use. When one reporter asked whether a Spark might ship with Portable Computer and a Nemotron model preinstalled, Nader demurred without ruling it out: "That would be cool... the goal is just making sure that it's a super smooth experience for every user."

Questions remain. Perplexity's most impressive numbers come from its own internal benchmark, and the company acknowledges that compact models still trail the frontier meaningfully on hard reasoning tasks — advisor escalation "narrows but does not fully close the gap." The launch is Linux-only for now, the 24GB VRAM floor excludes the vast majority of consumer PCs, and Apple silicon — home to some of the most enthusiastic local AI tinkerers — is conspicuously absent from the roadmap. "We're very focused right now on Nvidia hardware," Nate said when asked.

But the direction of travel is unmistakable. Perplexity's researchers describe the launch as part of "a broader shift in which increasingly capable agents move from remote infrastructure to individual and local devices," and both companies are betting that advances in chips and open models will keep expanding what a box on a desk can do. During Monday's demos, the most telling detail wasn't a benchmark score — it was that credit counter in the corner of the screen, sitting motionless at zero while the agent churned through a folder of tax documents. For two years, the AI industry has measured its ambitions in gigawatts and tokens per dollar. Portable Computer proposes a different meter, one that never runs.

Anthropic is making a calculated bet that the biggest bottleneck in enterprise AI isn't model intelligence — it's the fact that most people still use AI alone.

In an exclusive interview with VentureBeat, Scott White, Anthropic's head of product for enterprise, laid out the company's thesis for what it calls "multiplayer AI": a shift away from the single-user chatbot paradigm toward AI agents that operate across teams, read organizational context, and proactively insert themselves into work — sometimes without being asked.

The strategy crystallized earlier this month when Anthropic updated Claude Tag, its agent that lives inside Slack channels, to read context across entire conversations rather than evaluating messages one at a time. According to the company, the change makes Claude roughly 30% better at deciding when — and, critically, when not — to jump into a conversation unprompted.

That may sound like an incremental product update. White argues it represents something more fundamental: the moment AI stops being a tool individuals consult and starts being a colleague organizations deploy.

"Claude used to feel like your personal chief of staff," White told VentureBeat. "Now Claude, in the context of organizational deployment, feels like the company's chief of staff."

How enterprise AI evolved from autocompleting code to pursuing company goals

White frames the industry's evolution in three distinct phases, and his account doubles as a roadmap for where Anthropic is steering its enterprise products.

In the beginning, he said, AI handled "a part of one task" — answering a question in a chatbot, or completing a single line of code in an IDE. As models improved, they graduated to completing entire tasks: writing a full function, producing a research report, drafting a document from multiple data sources.

"I think we are now at the trajectory of what I would call projects or goals," White said. "The models are capable, and the connectivity into systems is capable enough, to accomplish higher-order abstract goals — like keep our product bug-free, or make our legal NDA review process happen faster — and the model can operate largely in the background, connecting various data sources and agentically looping over what it thinks its objective is."

That shift, White argues, is precisely what forces AI to become multiplayer. Goals, unlike tasks, inherently involve multiple people. And knowledge work — unlike software engineering, which has decades of collaboration infrastructure built around Git and pull requests — has no equivalent scaffolding.

"Knowledge work is much messier than software engineering," White said. "It's multi-person. It's multi-job function. It's multi-connected system that has different permissions... The goal or the output is also not as easily verifiable as code. Code can pass tests and compile on your machine, and you can iterate on it until it deterministically works. Knowledge work is not necessarily that. It requires human judgment to say something is up to the quality bar."

The three technical breakthroughs that made proactive AI agents possible

Asked what actually enabled the multiplayer shift, White pointed to three pillars that came together over the past two years. The first is connectivity. Anthropic's Model Context Protocol (MCP) — the open standard the company introduced in late 2024, which rivals OpenAI and Google subsequently adopted in 2025 — has matured into what White called "the USB-C for AI connectors," giving Claude governed access to enterprise data systems.

The second is a threshold of model intelligence that makes proactivity viable rather than annoying. "When you're connected to all of these different systems, you have to be able to connect the dots between the data that you're getting from all of these different sources to be able to then proactively jump in and say, 'I think I am spotting a problem for you that I can fix,'" White said. "You really need to get to a new level of model intelligence, and I think we've only really gotten there recently."

The third is form factor: putting Claude where collaboration already happens. White described the Slack integration as "a novel partnership that we struck up to have that presence of Claude as an agent" — one that gives Claude a federated agent identity with its own permissions, channel awareness, and MCP-connected context.

The Claude Tag update shows how these pieces combine. Previously, a lightweight classifier evaluated each Slack message in isolation and made a binary call about whether Claude should respond. Anthropic has now removed that classifier entirely. Claude reads the channel's full context — plus its memory and standing instructions — and chooses among four moves: reply inline, start deeper work in a thread, route the message into an existing workstream, or say nothing. Anthropic's announcement offers a telling example: two engineers chasing the same bug from opposite ends, neither addressing Claude. Read individually, neither message warrants a response. Read together, one engineer has a theory and the other has the evidence — and Claude opens a thread with the investigation already running. Notably, the company built explicit restraint into the system. "An annoying agent is worse than an unhelpful one," Anthropic wrote in its announcement, noting that Claude goes dormant in channels where it repeatedly has nothing to add.

Why Anthropic says collaborative AI beats solo star performers

The obvious skeptic's question is whether any of this actually makes teams faster. High performers often move quickest when working alone, and coordinating AI use across people with different working styles is genuinely hard. When pressed for evidence, White pointed to how his own job has changed inside Anthropic.

"In the old days, I might have a question about something happening in the business, and I would go work with a data scientist to take one or two days to do some data analysis around this problem statement," White said. "Now Claude is good enough at doing data analysis where I no longer have to have that handoff. What the data scientist has done now is they've created the infrastructure that allows Claude to always be right when it is doing data analysis."

The result, he said, is that time once spent waiting on handoffs now goes to judgment: "More of my time is spent with my collaborators at my level, jamming with them about what we should actually do and what we should change about our strategy... The multiple handoffs that we saw to get a piece of work done to then try to make a decision — all of that has been shortened dramatically."

White cited site reliability engineering as the pattern's clearest external proof point: Claude collects error logs, connects them to recent code changes and related Slack conversations, then surfaces the synthesis and pulls in the right people — "solving bigger, more ambitious, more goal-oriented problems where it's often necessary to collaborate."

Those claims land in a market still struggling to convert AI enthusiasm into returns. McKinsey's most recent State of AI survey found that while 88% of organizations report using AI in at least one function and 62% are at least experimenting with AI agents, only 39% attribute any earnings impact to AI — and just 6% qualify as "high performers" seeing significant value.

Deloitte, for its part, predicted that 25% of enterprises using generative AI would deploy agents in 2025, doubling to 50% by 2027. That gap between adoption and impact is exactly the terrain Anthropic is trying to claim: if redesigned workflows — not bolted-on chatbots — separate AI winners from the rest, a product that restructures how teams coordinate is a more defensible wedge than a marginally better model.

How Anthropic defends always-on agents against prompt injection attacks

Giving an AI agent standing access to a company's Slack channels, documents, and connected systems raises an obvious attack surface question, particularly around prompt injection — the technique of embedding malicious instructions in content an AI reads.

White described a layered defense strategy. "The models themselves are trained with classifiers that help prevent things like prompt injection attacks," he said, adding that Anthropic has delayed launches over the issue before: "We didn't GA our Chrome extension, and we actually put it on a waitlist... because we need to better understand the risk of prompt injection in the context of Claude in the browser. And then we actually did novel classifier training to figure out how to improve that from that dataset."

Beyond model-level defenses, Anthropic exposes compliance and analytics APIs that let enterprises define their own risk thresholds, and partners with third-party security vendors through its hooks and data loss prevention integrations. "We think about solving that at many layers of the stack," White said.

On data access, White emphasized that Claude's permissions collapse to the most restrictive intersection of what the agent can see and what the requesting user can see. "You have to have the same permissions to view the data that the thing would provide access to you," he said. "If you are using Claude in the context of your collaboration, it will have the channel context that is in front of you, but it will not leak that channel context into a different channel."

The unanswered pricing question every CIO should be asking now

One detail buried in the Claude Tag announcement deserves attention from technology buyers: the expanded channel context Claude now holds does not count toward usage or spend limits on any plan — for now. When asked whether enterprises should budget for that context becoming billable, White declined to commit, describing the current phase as active experimentation and co-design with customers.

"We're early in the journey here for what I would call proactive and collaborative agents," he said. "Long-term in AI is very — it's very long. Things change very quickly, and so that's why close partnership with our customers is so important, so they can help guide us to the right answer."

Instead of pricing promises, Anthropic is emphasizing controls: budget caps tied to agent identities or role-based access groups, and model entitlements that let different teams run different cost-performance profiles. "If we can give you ultimate control over how you architect the deployment to optimize for the relationship between cost and performance for the tasks that you're trying to accomplish, then there will be many ways to get to the outcome state that you want," White said.

The honest translation: the unit economics of always-on, context-heavy agents remain unsettled, and Anthropic is effectively subsidizing the learning phase. Enterprises should architect deployments assuming the meter eventually turns on.

Why enterprises might choose Anthropic over Microsoft, Google, and Salesforce

The competitive question looms large. Salesforce owns Slack, Microsoft is embedding agents throughout Teams and pushing its own multi-agent orchestration ambitions, and Google is doing the same across Workspace. Why would an enterprise hand its most sensitive internal conversations to a third party?

White's answer is that value lives in the connections between systems, not within any one of them. Improving a product based on customer feedback, he noted, requires pulling call transcripts from Salesforce, internal debate from Slack, usage analytics from product tools, and code from development environments — no single vendor owns that full picture.

"It is not just one individual thing that solves all of your problems," White said. "It is the intelligence and structure for how you pull it all together to get to the actual outcome that you're trying to get to, which is building something better for your customers. And we have seen our customers love Claude as the orchestrator."

It's a credible position precisely because enterprise data is fragmented by design. An orchestration layer that stays neutral across those systems — built on a protocol that even Anthropic's fiercest competitors have standardized on — carries structural advantages that a walled-garden agent does not. The risk cuts the other way, too: platform owners can bundle their agents for free and control the integration points Anthropic depends on. Anthropic is wagering that frontier intelligence and cross-system neutrality beat distribution — a bet that has worked so far in coding, and remains unproven in general knowledge work.

What comes next: handing Claude the company's quarterly objectives

Asked where the trajectory leads, White sketched a future in which the delegation flows in both directions — and it is striking how matter-of-factly he describes it.

"We're now giving Claude projects to accomplish," he said. "Soon, I think, we'll give Claude its OKRs, and it will figure out which projects the organization needs to work on and how to connect people to do them — improving itself, and the people around it, over time."

He acknowledged the vision is "a little bit abstract," and it raises governance questions that today's controls only begin to address. An AI that decides which projects an organization pursues — and, in White's words, delegates to people "only when they need to help improve its judgment" — inverts the traditional relationship between workers and their tools in ways most enterprises have barely begun to reckon with.

White pointed to Anthropic's public commitments on catastrophic risk domains like cyber and biosecurity as evidence the company is weighing the stakes, though the day-to-day questions of workplace agency remain largely in customers' hands, governed by the permission systems and budget controls Anthropic ships alongside the ambition.

For now, the more immediate change is the one already playing out in Slack channels: an AI that listens to the whole room, decides for itself when to speak, and increasingly does the connective work that used to fall to managers, analysts, and project leads. White has watched that shift compress his own job into its most human remainder — judgment, debate, decisions — and he expects the same compression to arrive everywhere else.

Two years ago, the industry's favorite metaphor for AI was the intern. Anthropic just promoted it to chief of staff — and it now reports to the whole company.

IBM is announcing today at the annual Hot Chips conference what may be the most consequential change to mainframe architecture in decades: a processor whose cores can natively execute both IBM's own instruction set and Arm's — switching between the two in nanoseconds.

The chip, which will power the next generation of IBM Z and LinuxONE systems, is the first dual-architecture mainframe processor ever built. It is designed to let enterprises run the vast and fast-growing ecosystem of Arm-native Linux software — including the AI frameworks that increasingly define modern infrastructure — directly alongside the z/OS transaction-processing workloads that anchor the world's banks, insurers, and governments.

"As technology enthusiasts on both sides, we're really excited about being what I would consider one of the most powerful commercially available processors that'll be dual architecture," Tina Tarquinio, chief product officer for IBM Z and LinuxONE, told VentureBeat in an exclusive interview ahead of the announcement.

The announcement marks the first hardware milestone from the strategic collaboration IBM and Arm unveiled in April, and it offers an unusually direct answer to a question that has shadowed the mainframe for years: can the machine that processes most of the world's regulated financial transactions remain a first-class citizen in an AI era built largely on other people's silicon?

How IBM engineered a processor core that speaks two instruction sets

The most striking engineering decision is what IBM chose not to do. The company could have bolted a handful of standalone Arm cores onto the side of its processor — a simpler design that other chipmakers have used for heterogeneous computing. Instead, IBM built every core on the chip to be bilingual.

"On this chip are 11 cores, and each core can dynamically switch back and forth between Arm software mode and traditional Z software mode," said Christian Jacobi, IBM Fellow and chief technology officer of IBM Systems Development, in an exclusive interview with VentureBeat. "That enables us to run the mission-critical enterprise software right next, on the same chip, to the much broader software ecosystem of Arm applications."

The mechanism relies on the open-source KVM hypervisor. Enterprises can run Arm64 Linux virtual machines and Linux on Z virtual machines side by side, and as the hypervisor dispatches each virtual machine onto a physical core, the core flips into the corresponding mode. The performance penalty, Jacobi said, is effectively zero. "That switch takes about the nanosecond scale," he said. "Because you're running for many milliseconds in the virtual image, this switching overhead sort of amortizes to zero — pretty much no impact at all."

Traditional z/OS workloads run in a separate partition on the same chip, outside KVM — meaning a bank's core ledger, its fraud models, and a modern Arm-native monitoring stack can all share the same silicon, the same memory fabric, and the same reliability guarantees. Jacobi was candid that IBM debated the easier path and rejected it. "We're really not addressing their need if we just have a few, I'd say, loosely Arm cores in the corner of the chip," he said. "It really needed to be deeply integrated into the entire system design for it to have the same qualities of service that clients are used to."

The specifications underscore that this is no compromise design. Built on a leading-edge 2-nanometer process node, the chip runs its 11 high-performance cores at a base frequency above 5.7 GHz — extraordinarily fast by industry standards — with on-chip AI inference accelerators for in-transaction fraud detection, a dedicated data processing unit for I/O acceleration, and a large cache architecture. Full systems will scale to hundreds of cores and tens of terabytes of memory. "That's really, really fast compared to what you otherwise get in the industry," Jacobi said. "It's just another example of how mainframe technology is not old technology. It's very modern, leading-edge technology."

Why the mainframe needed Arm's 22 million developers

The strategic logic behind the chip is about software, not hardware. IBM's s390x architecture runs an enormous share of the world's mission-critical transactions, but the broader universe of enterprise software — monitoring tools, security agents, cloud-native middleware, and above all the AI stack of PyTorch, ONNX Runtime, and container workloads — was built for x86 and, increasingly, for Arm. By Arm's own estimates, close to half of the compute shipped to major hyperscalers in 2025 was Arm-based, driven by AWS Graviton, Google Axion, and Microsoft's Arm silicon. Arm counts more than 22 million developers worldwide.

Porting each application to s390x has been a grinding, one-ISV-at-a-time effort, and Tina Tarquinio, chief product officer for IBM Z and LinuxONE, described the calculus bluntly. "No matter how great our ecosystem team is, we would never be able to work with all of them and port them all," she told VentureBeat. "There's a lot of ISVs out there, and so we wanted to make a fundamental, big step-function forward. We took a swing from a technology point of view."

Notably, she said customers weren't asking for a dual-architecture chip per se — they were asking for outcomes. "I wouldn't say our clients were saying, 'Can you please make me a dual-architecture environment?' But they were saying, 'Help me get these surround workloads, or different types of workloads, to run in a quicker-to-market fashion.'"

The compatibility promise is ambitious: Arm Linux binaries should run unmodified. "The new Arm capabilities are designed to be 100% binary compatible," Jacobi said. "Once you have, for example, Red Hat Linux for Arm, and you have applications that run on Red Hat Linux for Arm, they will run on the system without modifications." Arm defines the instruction set architecture and supplies validation tooling to guarantee that IBM's implementation behaves identically to every other Arm chip — while IBM designs and builds the silicon entirely in-house. "Very good partnership. Very solid engineering partnership as well," Jacobi said of the collaboration.

What a next-generation Spyre accelerator means for enterprise AI on the mainframe

IBM is also previewing the next generation of its Spyre AI accelerator at Hot Chips, and the pairing is not coincidental. The current architecture already offers two tiers of AI: an on-processor accelerator, introduced with the Telum chip in 2022, that handles ultra-low-latency inference such as fraud scoring inside a payment transaction, and the Spyre accelerator card sitting in the I/O subsystem for heavier models.

The new Spyre raises the ceiling considerably. "We're also bringing a much higher performance chip that is capable of running large language models for agentic workflows," Jacobi said — both AI-ops workflows that administer the system itself and business workflows "for things like document understanding and insurance adjudication." The new accelerator will ship with high-bandwidth memory to feed those models.

Here the dual-architecture bet and the AI bet converge. Enterprises want to run inference next to their data; the data lives on the mainframe; and the AI tooling is overwhelmingly Arm-native. Mohamed Awad, Arm's executive vice president for cloud AI, framed the announcement in exactly those terms: "As AI scales, more of the computing landscape is converging on Arm. Bringing Arm compute and its software ecosystem to these platforms will extend that momentum into mission-critical enterprise infrastructure to give organizations greater choice in how they deploy AI."

The timing tracks with where enterprise AI actually stands. McKinsey's most recent State of AI survey found that while 88% of organizations now use AI in at least one business function, nearly two-thirds have not yet scaled it across the enterprise — and the companies capturing the most value are those redesigning core workflows rather than running detached pilots. For regulated industries whose systems of record sit on IBM Z, running AI where the transactions happen is arguably the most direct route to that kind of integration.

When the dual-architecture IBM Z system will ship — and why existing customers shouldn't worry

Buyers will need patience. The chip will debut in the successor to the z17, which shipped in the second quarter of 2025, and IBM holds to a roughly three-year product cadence — pointing to a launch around 2028. But Tarquinio insisted the program is well past the concept stage. "It's more than being on the drawing board. We're full steam ahead on the whole system," she said, adding that IBM will release more details in the run-up to launch.

For IBM's installed base, the reflexive question is whether embracing Arm signals a slow sunset for the traditional architecture. Both executives pushed back hard. "This is a big and. It is not an or," Tarquinio said. "I have a roadmap that goes out 10 or 15 years of hardware systems. Many of our teams are working on this next system; many are also working on the one after that, and the one after that."

Jacobi cast the move as continuity rather than rupture. "The traditional mainframe that we have today as a z17 system is not just a faster version of what we built 25 years ago," he said. "We didn't have pervasive encryption capabilities. We didn't have on-processor AI capabilities. Adding the Arm capability is the next big iteration in this continuous evolution."

The competitive subtext is the cloud. Asked why an enterprise would run Arm workloads on a mainframe instead of a hyperscaler, Tarquinio pointed to the platform's availability numbers: "We're talking eight nines of availability — that's 0.3 seconds of downtime a year. If you're running your ledger, if you're running your fraud detection, any of these mission-critical apps, you want that." The pitch, she said, is fit for purpose: match the infrastructure to the SLA, not the fashion.

There are real caveats. IBM's own press release notes that statements of future direction "represent goals and objectives only." The Arm support is Linux-only for now, and the hardest engineering — running a foreign instruction set at production performance, with mainframe-grade fault detection and recovery, under real customer workloads — remains to be proven over the next two years.

But the ambition is unmistakable. For sixty years, the mainframe has survived every wave of technology that was supposed to kill it — minicomputers, client-server, the cloud — by absorbing what it needed from each. Now IBM is attempting its boldest act of absorption yet: teaching the machine that runs the world's money to speak the language of the AI era, fluently and natively, on the same silicon. "Bringing something that'll really be first of its kind in production," Tarquinio said, "showcases again what IBM is capable of from a technology point of view." The mainframe, it turns out, isn't being left behind by the future. It's learning to run it.

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.