Presented by Zeta

Every forward-deployed engineering (FDE) pitch sounds identical for the first ten minutes: an engineer embedded on-site, a workflow encoded within weeks, a demo that finally works on the customer’s real data. What differs is what happens in the following months, and most vendors will not tell you until you ask directly.

FDE has become one of enterprise AI’s most consequential operating models. Vendors are building entire go-to-market motions around engineers who embed with customers, wire products into operating environments, and make the demo real. Investors often read FDE headcount as a growth signal and buyers read it as a promise of speed. Neither tells you whether the work is becoming a product advantage or simply accumulating as delivery labor.

The test is simple: after an FDE engagement, does the next customer start with more product and fewer unknowns — or just a new services team?

FDE is not one thing. At its weakest, it papers over a product that cannot yet stand on its own, translating by hand what the software should eventually understand. At its strongest, it is a disciplined product-learning function: it finds the edge cases of an AI-native architecture and turns them into reusable capability. The org chart looks the same, but the economics and trajectory do not.

FDE is valuable because it creates automation that powers a system of intelligence. A system of intelligence is more than software that executes workflows. It captures enterprise context, incorporates what it learns from every deployment, and improves the quality of future decisions. Forward-deployed engineers are how that context enters the system in the first place.

The engineers are the context layer

Model choice still matters in some domains. But in many enterprise workflows, the bigger constraint is not the model, it is what the enterprise knows about itself including business rules, exceptions, workflow logic, and definitions that took a decade of operating history to settle. Access to data is not the same as understanding the business.

In one large telecommunications deployment, an initial definition of a “high-intent” customer did not survive contact with the operating systems. The model’s signal said one thing while the retention team’s actual save-desk criteria said another. Those criteria were built from years of which offers actually worked, on which tenure bands, in which regions. No schema documented that logic; it lived in the judgment of people who’d been doing the job for a decade. An engineer had to sit with them, extract the knowledge, and encode it before the intelligence layer we were building could be trusted to trigger an action instead of just a score.

Once that logic was encoded into the intelligence layer, new acquisition and retention use cases could move from idea to execution in days rather than months. Rather than rebuilding the integration each time, teams were adding decisions to a shared foundation.

That kind of work produces more than an answer for one customer. Properly captured, it can become a semantic mapping, a policy module, a workflow template, a connector, or an evaluation that guards the decision in future deployments. The FDE is the context layer delivered first as a person, who then translates and delivers it as product.

Sandbox, mud, and what happens to the learning

The useful question in a diligence call or renewal conversation is not whether a vendor has FDEs. It’s whether an engineer touching your environment is playing in a sandbox of tools, or trying to dig you out of the mud.

In the sandbox, FDEs use a general-purpose engine in specific, gnarly environments. Their job is to find where the engine needs a new part, install it, and feed the learning back so that part can ship again. In the mud, the engineer manually constructs a missing capability one customer at a time, and there is no engine underneath waiting to receive the part; instead, it’s another custom build.

Do not mistake these for a clean binary, though. Most companies live somewhere in the middle: reusable playbooks and connectors for the common cases, bespoke judgment for everything else. From the outside, sandbox, mud, and the middle can all look identical: a smart engineer, on-site, writing code against your data. The tell is what happens to what they learn. Either the next deployment begins with fewer unknowns, less custom code, and better tests, or it begins from zero with a prettier deck.

The strategic version of FDE treats every engagement as a disciplined learning loop. It starts with observing the exception in the field, codifying it into a reusable artifact, validating it with an evaluation and security review, releasing it into the product, then measuring whether the next deployment actually got easier. That last step is where most companies quietly fail. Not every field discovery belongs in the core product. Some customer logic is proprietary, temporary, or too idiosyncratic to generalize. Good teams know the difference between three things that get lumped together under “FDE”: product intelligence that compounds across every customer, configurable customer logic that’s reusable for one account but shouldn’t ship broadly, and one-off services work that is exactly what it looks like.

Customization is expected. The failure lies in not labeling which bucket the work is in, or in losing the learning from the parts that can compound.

This is the difference between a company that gets better at deploying and a product that gets better at understanding. The former can build a capable services business; its advantage lies in execution and relationships. The latter builds compounding product capability that persists after the engineer leaves.

The best FDE organization changes shape

The uncomfortable conclusion for teams building FDE functions is that human translation should shrink per unit of value delivered, even as absolute headcount grows. A fast-growing company may keep adding FDEs while still making each deployment materially lighter because more of the required logic already exists in the product. Each deployment should require less custom engineering than the last, with engineers spending more time extending reusable capabilities than rebuilding the same integrations, workflows, and decision logic.

Track four things:

• engineers per live workflow

• engineering hours per deployment

• time-to-value by vertical

• and the share of implementation work that gets reused rather than rebuilt.

Track one more that matters just as much and gets watched far less: the productization lag, the time between a field discovery, and a tested capability available to the next customer. Over time, that lag should fall, custom engineering should decline, and reuse should increase. If none of these are improving, the organization is delivering, without learning whatever the headcount chart says.

FDE is scaffolding only when it stays outside the building. The goal isn’t to eliminate the people doing the work; it’s to ensure more of what they learn becomes load-bearing product capability.

Three questions that get past the pitch

1. How is FDE priced?

Pricing is a signal rather than a verdict. A separate professional-services line may reflect honest transparency, bundled FDE may be a loss leader paid for by utilization. The more useful question is whether the contract, renewal, and margin story make clear which work is repeatable productization and which is bespoke delivery.

2. Where does field learning go?

Don’t infer this from résumés alone. Ask who owns the handoff from FDE to product, what artifacts are produced, and how quickly they become tested, supported capabilities. The organizational interface is what reveals whether learning compounds, not the job title.

3. What got faster on the last repeat deployment?

Ask for a specific vertical and a specific delta such as fewer engineering hours, fewer weeks to value, fewer custom integrations, or a higher reuse rate. A credible vendor can name what changed and how it was measured. General claims about “learnings” and “playbooks” are not enough.

Enterprise AI creates lasting advantage when every deployment leaves behind more than a satisfied customer. It leaves behind a deeper understanding of how enterprises operate. The goal isn’t simply to deploy AI. It’s to build a system of intelligence that captures enterprise context, converts customer learnings into reusable capability, and compounds over time.

Neej Gore is Chief Data Officer at Zeta.

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.

When large language models (LLMs) hallucinate, developers typically assume the model lacks the required facts. Engineering teams diagnose the error as missing knowledge. The standard response is to increase model size, expand training data, or build complex retrieval architectures.

A new study by researchers at Google Research and Technion demonstrates that the knowledge is often not missing. The model has the information encoded parametrically but fails to surface it during generation. 

Their experiments show that frontier models like GPT-5 and Gemini-3 encode 95-98% of tested facts. This indicates that in many cases, recall, rather than encoding, is the primary bottleneck for factual accuracy. 

By understanding how to unlock existing knowledge through inference-time computation, engineering teams can build more reliable applications without necessarily relying on larger models or external databases.

Knowledge profiling: measuring what models actually know

To map this gap between storage and retrieval, the researchers propose shifting the evaluation focus from question-level accuracy to fact-level profiling. Instead of simply scoring whether an LLM answers an isolated prompt right or wrong, fact-level profiling tests a single underlying piece of information across multiple conditions, evaluating whether the fact is stored in the model’s parameters at all, whether it can be queried from different directions and phrasings, and what computational effort is required to retrieve it.

This framework distinguishes between whether a fact is parametrically “encoded” and whether it is “known”. A model encodes a fact if it can accurately reproduce it when primed with its original training context. A model knows a fact if it can reliably answer questions about it across varied phrasings and directions.

“Encoding and recall failures are indistinguishable under accuracy metrics, yet they imply different limitations and solutions,” the researchers write. “Encoding failures call for pre-training interventions, such as scaling model size or data coverage. Recall failures suggest post-training interventions that often improve how models utilize what they already encode.”

The paper illustrates this using a sample fact: Oasis played their first gig at the Boardwalk club. Based on how models process this information, the study categorizes knowledge into five distinct profiles:

• Direct recall: The model encodes the fact and readily accesses it to answer direct questions without extra inference compute.

• Encoding failure (empty shelves): The model neither encodes nor knows the fact. It cannot complete a Wikipedia-style sentence about Oasis’s early days, nor can it answer questions about the event. This signals a need for more pre-training data or greater model capacity.

• Recall failure (lost keys): The model has the fact encoded but cannot access it. It can seamlessly complete the original training text about Oasis, but fails to answer “Where did Oasis play their first show?” even when given time to think.

• Recall with thinking: The fact is encoded, but inaccessible to direct generation. It is only successfully recalled when the model uses inference-time computation, such as Chain-of-Thought, to bridge the gap. The researchers refer to this mechanism as recall facilitation. The model might initially fail to answer the direct question. By generating intermediate thoughts about the band’s early history in Manchester, it structurally primes itself to locate and recall the locked answer.

• Inference without encoding: The model never explicitly encoded the Oasis fact. Instead, it successfully answers the question by making an educated guess or reasoning across other encoded facts it does know. It might deduce the answer by chaining together separate data points, such as “Oasis formed in Manchester,” “the Boardwalk was a famous 90s music club there,” and “the Boardwalk hosted early gigs by emerging bands.”

Scaling illusions, long-tails, and tip-of-the-tongue recoveries

The researchers evaluated 13 LLMs on over 4 million responses. They used WikiProfile, a benchmark containing 2,150 facts extracted from Wikipedia, testing each fact across formats ranging from exact context completion to multiple-choice verification.

For frontier models like GPT-5 and Gemini-3, encoding is nearing saturation. These models successfully encode 95-98% of the tested facts. However, they still fail to directly recall 26-34% of those encoded facts without thinking. 

Inference-time thinking acts as a vital recovery mechanism. Providing models with extra computational effort successfully retrieves 40-65% of the encoded facts that models initially fail to directly recall. The researchers compare this to the human tip-of-the-tongue state, where deliberate effort, such as mentally retracing context, eventually helps remember the information.

Scaling up model size does not automatically resolve this gap. For example, they found that scaling the Gemma3 model from 1 billion to 27 billion parameters decreased encoding failures from 85% to 23%. But at the same time, the share of recall failures increased, peaking at 40% without thinking. 

This suggests that scaling mainly solves the storage problem rather than the access problem. As the model memorizes vastly more facts, a larger pool of knowledge becomes trapped in an “encoded but inaccessible” state. The bulk of model errors shifts from missing data to failed recall.

“Our findings suggest that recall is tightly coupled to the conditions under which facts were learned, degrading when queries diverge from training-time patterns,” the researchers write. How a user asks a question directly dictates whether the model can unlock the stored answer.

For example, the experiments showed that rare facts are encoded at rates similar to popular facts. Yet they found a large recall gap between long-tail and highly popular facts that exceeds 25% for frontier models.

Similarly, models struggle to generate answers to reverse questions (i.e., asking for the subject instead of the object). For example, a model might easily answer that Oasis played their first gig at the Boardwalk club, but fail to answer who played their first gig at that same club. At the same time, the same models show that they know the correct answer when given the same question in multiple-choice format.

“Whereas these failures are often interpreted as limitations of memorization or bidirectional encoding, our results suggest a different picture: rare facts are often encoded but inaccessible, and reverse facts can be recognized even when they cannot be generated,” the researchers write. “This reframes both phenomena as recall failures rather than ‘missing knowledge.'”

The ROI of thinking and tips for developers

The high encoding rates of frontier models require a shift in how developers approach factuality and pipeline architecture.

Don’t treat every factual failure as a retrieval problem: The default enterprise reaction to hallucinations is often to deploy Retrieval-Augmented Generation (RAG), scale up vector databases, or ingest more domain documents. While necessary for real-time updates or entirely absent data, this study shows up to 95-98% of standard facts are already parametrically encoded. Many failures can be recovered without external retrieval.

Use inference-time reasoning selectively: Thinking recovered 40–65% of encoded facts that models failed to directly recall. However, thinking is computationally expensive. A practical architecture involves a fast first-pass model call, followed by a higher-reasoning-effort retry when confidence is low. Teams can optimize costs by dynamically routing challenging conditions, like rare entities or reverse questions, to thinking models.

Test semantic access, not just benchmark accuracy: Standard accuracy metrics mask underlying model capabilities. Evaluation sets should probe the same underlying fact across different phrasings, contexts, and directions to truly understand what a model knows versus what it can reliably access.

Leverage query reformulation and retries: Because recall is highly context-dependent, query framing dictates success. Changing the structure of a prompt, generating relevant intermediate context, or prompting the model to generate a reasoning chain before answering are legitimate reliability mechanisms that surface information direct prompts miss.

Limitations and practical takeaways

The WikiProfile benchmark relies on encyclopedic Wikipedia facts. These findings might not perfectly generalize to proprietary or highly specialized enterprise domains. A model’s ability to store and recall a niche internal company metric may behave differently than its handling of public encyclopedic data.

Fully profiling a frontier model on the WikiProfile suite costs approximately $500. Developers can significantly reduce this cost by omitting multiple-choice variants or using fewer response samples per question. 

Teams can access the WikiProfile benchmark on Hugging Face to evaluate their own systems and build custom knowledge profiles. Identifying whether an enterprise application suffers from empty shelves or lost keys is the first step toward fixing it.

Perplexity today launched hybrid compute for its agentic platform, Computer, a system that lets a single AI agent split its work between frontier models running in the cloud and smaller open-weight models running locally on Apple silicon Macs — routing sensitive data to the local machine so it never leaves the device.

The company says it is the first time an AI agent can begin a task in the cloud and dynamically hand off the confidential portions of that same task to a model running on the user’s own hardware, without restarting the job or losing context. The feature becomes available today through Perplexity’s desktop app for enterprise customers that opt in, as well as Pro and Max subscribers, on any Apple silicon Mac running macOS 15 or later.

“Hybrid is really compelling because it’s often the work that requires confidentiality that is the most important to get right, and so the accuracy really, really matters,” Jon Staff, who leads Perplexity’s macOS and iOS engineering teams, said during a press briefing attended by VentureBeat. “By combining these two together, we can get that maximum intelligence from the frontier models, but we also get the security and the privacy that comes with local.”

How Perplexity’s on-device privacy gate keeps sensitive data off the cloud

The architecture works like a dispatcher. A frontier model in the cloud breaks a task into subtasks and routes each one to the appropriate place. Web research, long-horizon planning and heavy reasoning run in the cloud, while anything touching private files, local data or actions on the device gets delegated down to a subagent running on the Mac itself.

The linchpin is what Perplexity calls a Privacy Gate: a company-trained classifier that runs on the device and scans for personally identifiable information — names, addresses, account numbers, secrets — before anything is transmitted to the cloud. When the gate flags sensitive content, the user chooses whether that portion of the task runs locally or gets shared.

“What we wanted to do is make sure anything that’s shared to that cloud orchestrator is safe,” Staff said. “We built and trained our own PII classifier that integrates directly into the Mac app.”

He described the handoff in detail: “The cloud orchestration will break down the task based on the prompt and figure out how to route it to different subagents… it’s going to delegate that down to a sub-agent running on your Mac, and then that portion of the task is run entirely local. None of those tokens go to the cloud.”

The economics matter, too, for a company that meters cloud usage through credits. Tokens generated locally cost nothing. “You’re paying for the electricity, you’re paying for the hardware, so we’re not charging you for that,” Staff said. “The only thing the credits are used for is the orchestration and the delegation.”

Lawyers, private equity firms and a founder in an Uber: hybrid compute in action

Perplexity built its demonstrations around exactly the kind of work most professionals would never hand to a cloud-only agent. In the first, a lawyer on deadline updated a draft brief against privileged case files stored on a Mac while a cloud agent simultaneously pulled public case law from the open web — sending out, Perplexity says, only anonymized legal questions. “At no point did their privileged information get shared to the cloud,” Staff said. “It never left the Mac.”

In the second demo, a private equity associate’s agent reworked a financial model against confidential management projections, benchmarked the deal against public comparables and produced a fifth iteration of an investment committee deck. The task ran roughly 40 minutes in the background with no human input — work that would have taken hours of manual stitching between local spreadsheets and cloud research.

The third demo emphasized continuity across devices. The founder of a pottery shop, riding in the back of an Uber, kicked off a marketing analysis from her iPhone. Computer asked permission to reach her Mac at the studio, fired up the local subagent to process her customer interviews and revenue data, and combined that with cloud research on competitors’ public pricing. “It doesn’t matter how far away she is from her computer,” Staff said.

“Tasks like this aren’t possible in a fully local or a fully cloud setup,” he added. “You need that security of the local and the privacy, but you also need the intelligence of the frontier.”

Why a Chinese-made Qwen model on enterprise Macs is raising eyebrows

The launch model lineup immediately raised a pointed question. At launch, users can choose among three local models: Google’s Gemma E4B, Alibaba’s Qwen3.6 35B-A3B, and a Perplexity post-trained version of Qwen3.6 35B — the company’s recommended option. Asked by VentureBeat whether enterprise or government customers had raised concerns about giving a Chinese-developed model access to their machines, Staff argued that local inference neutralizes the geopolitical risk.

“The great thing about these models is that they are open weight. We’re able to evaluate them ourselves,” he said. “When that model is running locally on your computer, the data is not going outside of your computer itself… You’re not actually sending those tokens to some cloud provider that’s hosted in another country. In fact, all of Perplexity’s models are U.S. hosted.”

He added that macOS’s built-in sandboxing framework, known as Seatbelt, constrains what the agent can actually do on a machine: “If local execution is trying to do something that it shouldn’t, it’ll just point blank stop it and it’ll request permission from the user.” Perplexity does not currently allow unrestricted “YOLO mode” execution, he said, though “I wouldn’t be surprised at some point if we allow certain people to do this.”

For enterprises, admins can set a single organization-wide sensitivity policy and audit a full record of what leaves each device — a feature aimed squarely at compliance teams in law, finance and healthcare. Questions remain on the consumer side, however. Pressed on how usage data feeds model training, Staff pointed to Perplexity’s incognito mode and a long-standing opt-out toggle, and said enterprise contracts can include zero-data-retention terms. A company spokesperson said Perplexity is “not using it for post training” globally and promised to follow up with specifics on non-enterprise accounts.

The enterprise privacy problem hybrid AI is trying to solve

The announcement lands amid a broader industry reckoning with a stubborn problem: the most valuable enterprise work involves exactly the data companies are least willing to send to someone else’s servers. NIST’s generative AI risk profile flags data privacy and information leakage among the technology’s central risks, and McKinsey’s research on the state of AI has consistently found that organizations struggle to move from experimentation to value capture, with data governance among the chief obstacles. Gartner, for its part, named hybrid computing among its top strategic technology trends for 2025, anticipating architectures that blend compute across environments.

Perplexity is betting that the answer is not choosing between cloud intelligence and local privacy, but building the orchestration layer that arbitrates between them in real time. It is a defensible position for a company that has always styled itself as a neutral broker — “Perplexity is like Switzerland in that we work with everyone,” a company representative said at the briefing — sitting at the application layer above whichever models happen to lead at any given moment.

“Anytime one of these gets better, Perplexity gets better,” Staff said of the interplay among local models, frontier models and Apple’s chips. “That’s the really cool nature of where we sit in this application layer, orchestrating all the different pieces together.”

From $520 million startup to $20 billion agent platform in three years

Hybrid compute caps an extraordinarily aggressive product run. Perplexity launched its Comet AI browser in July 2025, initially for $200-a-month Max subscribers — an early bid to make agents, not chat, the interface to computing. Computer, its full agentic platform, arrived in March 2026, followed by desktop apps for Mac and Windows. Just last week, the company launched a local-first version of Computer on NVIDIA’s DGX Spark hardware, which starts on the user’s device and escalates to cloud models only with permission. Today’s launch inverts that flow: cloud-first, delegating down.

The business trajectory has been equally steep. Perplexity was valued at $520 million in January 2024; by September 2025, the company had finalized a funding round at a $20 billion valuation. Along the way it made an audacious $34.5 billion bid for Google’s Chrome browser during Google’s antitrust remedies fight, and Bloomberg reported that Apple executives held internal talks about acquiring the company — a striking backdrop for a product now built to showcase Apple silicon.

The strategy is not without headwinds. Reuters reported in July that Reddit’s data-scraping lawsuit against Perplexity survived a motion to dismiss, part of a wave of copyright and data litigation facing the company — context that makes its privacy-forward positioning both commercially savvy and reputationally necessary. And practical constraints remain: Perplexity recommends at least 32GB of unified memory for the better tier of local models, Staff was candid that the smallest option “significantly underperforms” the larger Qwen models, and Windows and Linux support will come only later.

The deeper question is one users cannot easily inspect. The Privacy Gate is itself a machine learning classifier, and classifiers miss things; a false negative means sensitive data reaches the cloud anyway. Perplexity’s answer is transparency — users can expand and review exactly what the gate flagged before anything is sent, and enterprises get device-level audit logs. But the pitch, at bottom, asks professionals to trust one AI to decide what another AI is allowed to see. For an industry that has spent three years telling lawyers, bankers and doctors to keep their most sensitive work away from the cloud, Perplexity’s wager is that the fix was never to build a higher wall — it was to build a smarter gate.

Presented by SAPHR tracks employees and skills. Finance owns headcount targets and cost. Procurement manages contractors and services spend. Together, they leave executives unable to answer basic questions about how workforce decisions actually transla…

If you look at the commit histories of modern data platforms, something profound has shifted over the last two years. The friction of writing syntax has collapsed. With Cursor, Claude Code, and agentic workflows now living inside our Docker containers and IDEs, generating the first implementation of a distributed streaming pipeline or a complex API integration is no longer the central bottleneck.

Agents can navigate repositories, write test coverage, inspect stack traces, and propose refactors. Describe a Kafka-to-Iceberg sink mapping in plain English, and an agent can produce a credible starting point before the engineer has opened every relevant file.

That changes the question for software engineers.

If the agent is becoming the primary author of local system logic, what exactly is left for the engineer to do? Are we headed toward an industry of reviewers rubber-stamping an endless stream of plausible pull requests? Or has the work shifted away from constructing logic and toward something more abstract?

To answer that, it helps to borrow a lens from thermodynamics, which gives us a language for directed work, feedback, loss, and the boundaries that keep a complex system coherent.

The agent as a heat engine

When we strip away the anthropomorphic illusion of AI, what remains is a computational engine. It takes direction and turns it into action.

An LLM sitting in a data center has immense capacity, but it does no useful work until it is given intent. A prompt, a business requirement, a system instruction, or a failing test gives the agent a direction. It turns that direction into code, tool calls, queries, tests, and changes to a running system.

Every engine has losses. Every agent loop does, too.

Anyone who has left an agent running against a difficult repository has seen this. It starts with a clear task. Then it follows a stale assumption, fixes a symptom rather than a cause, treats an old migration as current behavior, and begins to accumulate its own history. A few tool calls later, the context contains enough plausible but conflicting detail that the next step is less certain than the first.

Call this operational entropy: the buildup of stale assumptions, branching context, and unresolved dependencies inside a loop that is still trying to move forward.

A human interruption helps because it introduces new information. So does a failing test, a precise data contract, a deterministic tool, or an evaluation that tells the agent exactly what it got wrong. Without that signal, an agent can keep generating output while drifting further from a correct outcome.

Agents clearly generate motion. The real question is whether the system around them turns that motion into useful work.

The infinite monkey and the accelerating search space

The infinite monkey theorem gives us a useful picture of what follows: repeated attempts, finite constraints, and feedback.

The theorem says that a monkey hitting keys at random for an infinite amount of time will almost surely type the complete works of Shakespeare. Modern agents are much smarter monkeys. They have compilers, tools, repositories, test suites, and feedback loops. Their work is not random — the feedback steers the next attempt — but the dynamic is familiar: propose, execute, observe, correct, and try again.

In a bounded task, that loop is remarkably effective.

Give an agent a known input schema, a known target schema, a small codebase, and tests that catch the relevant failures. It can inspect the code, make a change, run the tests, absorb the result, and try again. The definition of done is visible. The search space is narrow. The loop has a chance to converge.

But enterprise systems rarely offer that kind of stillness. A real-time pricing engine may depend on mutable operational state, third-party APIs, late-arriving events, regional policy, and business rules that exist partly in code and partly in someone’s head. A data lakehouse can be physically consistent and semantically wrong. A pipeline can pass its tests and still produce numbers that finance does not recognize.

The environment is changing while the monkey is typing.

The three-body problem of enterprise logic

This is why the three-body problem is such a useful image for enterprise software.

With two bodies — a planet and a star — you can predict the motion with a clean mathematical description. Add a third body and the problem becomes much harder to solve. There is no general closed-form solution, and some configurations exhibit chaotic behavior. Small changes in one place can produce very different trajectories elsewhere.

Modern data platforms have the same shape. Clickstream data changes with product behavior. Operational databases mutate under customer activity. APIs impose rate limits and change versions. Schemas evolve. Security policies shift. Legacy systems carry rules that no one has written down because they have been buried in exception handling for years.

Each system exerts pressure on the others. A change in one place alters the meaning or behavior of another. What begins as a local feature request starts to pull on the entire system.

Consider a hypothetical: an agent is asked to add a customer_tier field to a revenue model. It finds a field called status in the operational database, maps it into the transformation, and passes the existing type and nullability tests. The code is clean. The pipeline is green. The answer is still wrong.

A semantic data contract says that customer_tier is derived from trailing twelve-month spend, has an assigned business owner, and cannot be populated from account status. The contract rejects the change before it reaches the dashboard. The engineer’s contribution wasn’t the transformation — it was the boundary that made the agent’s mistake visible, specific, and recoverable.

The new mandate: Designing equilibrium

The software engineer’s job is no longer to write every piece of micro-logic. Agents will increasingly do that work, often faster. The new mandate — designing equilibrium — is to create the conditions in which generated logic can be trusted.

When a business requirement changes faster than an agent can absorb feedback, the engineer has to build containment fields. Strict semantic layers, immutable event logs, data contracts, idempotent APIs, and deterministic state machines are not just good platform hygiene. They reduce the number of assumptions an agent has to make at once.

They turn a coupled problem into a bounded domain with clear inputs, explicit rules, and reliable feedback.

Once that domain exists, the agent becomes genuinely powerful. It can write the transformation, execute the tests, repair the failures, and ship the change without needing to infer the unwritten history behind every table and service.

The value of software engineering doesn’t disappear as code generation gets cheaper — it becomes more visible, which is the shift that actually matters.

Autonomous systems will increasingly generate software. But the contracts, feedback loops, and boundaries that determine whether that software succeeds or spirals into chaos will still be designed by software engineers.

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures.

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

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

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.

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.