https://venturebeat.com/feed

Andrej Karpathy, the influential 39-year-old Slovak-Canadian AI researcher and one of the original 11 co-founders of OpenAI, and former head of Tesla's AI division, announced on Tuesday, May 19 that he's joining rival lab Anthropic.

As Karpathy posted from his account on the social network X: "Personal update: I've joined Anthropic. I think the next few years at the frontier of LLMs will be especially formative. I am very excited to join the team here and get back to R&D. I remain deeply passionate about education and plan to resume my work on it in time."

Anthropic's current Head of Pretraining, Nicholas Joseph, also a former OpenAI alumnus, added more context to Karpathy's new role at Anthropic in a post of his own on X, writing: "Excited to welcome Andrej to the Pretraining team! He'll be building a team focused on using Claude to accelerate pretraining research itself. I can’t think of anyone better suited to do it — looking forward to what we build together!"

An Anthropic spokesperson confirmed to VentureBeat via email that Karpathy will be starting a team focused on using Claude, Anthropic's own, increasingly popular AI model, to accelerate pretraining research. This would put Anthropic further toward the overarching AI research goal of many around the world to develop "recursive self-improvement," that is, AI that is capable of training its successors or upgrading itself with increasingly lesser, or ultimately no human intervention.

The announcement came on the same day as the start of rival AI-focused tech firm Google's annual I/O developer conference in its headquarters city of Mountain View, California, when many new releases and announcements were expected.

Karpathy is widely known for spanning three parts of the modern AI boom: academic research, big-company deployment and online education.

His own website describes him as an AI researcher and educator who was a founding member of OpenAI, later served as Director of AI at Tesla, and helped create Stanford’s first deep learning course, CS231n.

OpenAI’s December 2015 launch announcement also listed Karpathy among the group’s founding members.

At Tesla, where he worked from 2017 to 2022, Karpathy led the computer vision team for Autopilot and says his team handled in-house data labeling, neural network training and deployment on Tesla’s custom inference chip.

He then returned to OpenAI from 2023 to 2024, where his website says he built a team focused on midtraining and synthetic data generation — experience directly relevant to Anthropic’s reported pretraining role.

Karpathy’s academic work began at Stanford, where he earned his PhD under Fei-Fei Li and focused on neural networks for computer vision, natural language processing and the intersection of the two.

He also interned at Google Brain, Google Research and DeepMind, according to his website. His education includes an MSc from the University of British Columbia and a BSc from the University of Toronto, where he double-majored in computer science and physics.

Since leaving OpenAI in 2024, Karpathy has become one of AI’s most visible public educators, publishing technical and general-audience videos on large language models and neural networks.

He also launched Eureka Labs in July 2024 as an “AI-native” school; its first product, LLM101n, is described as an undergraduate-level course guiding students through training their own AI system.

Acting on his own as a free agent over the last two years, Karpathy has also helped push open source AI research forward with products and standards including autoresearch, an LLM-driven automated researcher that can run multiple hypothesis and experiments simultaneously, and the LLM Knowledge Base, an autonomous system of storing memory and context for AI agents in a kind of ever-growing library designed for them to access.

The big question is what becomes of these and Karpathy's open source AI efforts more generally as he joins Anthropic, a lab that has supported open source via the launch of its Model Context Protocol (MCP) technical standard, but which also famously has shipped primarily proprietary AI models and harnesses (such as Claude and Claude Code).

Based on the last statement in his announcement post on X — "I remain deeply passionate about education and plan to resume my work on it in time" — it appears that at least his contributions to the AI-native school effort will be paused as he digs in at Anthropic.

Redis built its name as the caching layer that kept web applications from collapsing under load. The problem it is targeting now has the same structure but is harder to solve: production AI agents failing not because the models are wrong, but because the data underneath them is scattered, stale and structured for humans rather than machines. Retrieval pipelines built for single queries cannot absorb the volume agents generate.

The gap Redis is targeting is structural: agents make orders of magnitude more data requests than human users, but most retrieval layers were built for the human-scale problem. Redis Iris, launched Monday, is the company's answer: a context and memory platform that sits between an agent and the data it needs to act. The platform combines real-time data ingestion, a semantic interface that auto-generates MCP tools from business data models, and an agent memory server built on Redis Flex, a rewritten storage engine that runs 99% of data on flash at a tenth of the cost of in-memory storage alone.

The announcement lands as enterprise RAG infrastructure is in active transition. VentureBeat's Q1 2026 VB Pulse RAG Infrastructure Market Tracker found buyer intent to adopt hybrid retrieval tripling from 10.3% to 33.3% between January and March. Retrieval optimization surpassed evaluation as the top enterprise investment priority for the first time. Custom in-house retrieval stacks rose from 24.1% to 35.6% as enterprises outgrew off-the-shelf options. Redis is not the only infrastructure vendor reading those signals — several data platform providers have repositioned around agent context layers in recent weeks.

The scale mismatch is the structural argument behind the launch. "Companies will have orders of magnitude more agents than human beings," Rowan Trollope, CEO of Redis, told VentureBeat. "Orders of magnitude more agents than human beings means orders of magnitude more load on back end systems."

Trollope traces the parallel back to the mobile era: When legacy backends built for branch tellers suddenly had to serve a million smartphone users, Redis became the caching layer that absorbed the load without a full rebuild.

What is different this time is that agents cannot write their own middleware. In the mobile era, a developer would sit with a database administrator, identify the queries an application needed and hard-code the caching logic into a middleware layer. Agents cannot do that. They need to find the right data at runtime, through interfaces built for them in advance, or they stall.

"This is like the analogy of the grocery store in the fridge," he said. "If every time you have to go make your sandwich, you have to run to the grocery store to get the food, that's not very efficient. You put a fridge in every house, you store a little bit of food there. And that's kind of where we still tend to exist in the infrastructure stack."

Iris ships five components that together cover data ingestion, semantic access, memory and caching.

Redis Data Integration. Now in general availability. RDI uses change data capture pipelines to sync data from relational databases, warehouses and document stores into Redis continuously, with connectors for Oracle, Snowflake, Databricks and Postgres.

Context Retriever. Now in preview. Developers define a semantic model of business data using pydantic models and Redis auto-generates MCP tools agents use to query it directly, with row-level access controls enforced server-side. Trollope describes the shift from classic RAG as a directional inversion. "It's just a flip to let the agent pull the data instead of presupposing and stuffing it into the pipeline," he said.

Agent Memory. Now in preview. Stores short and long-term state across sessions so agents carry context without re-deriving it on each turn.

Redis Flex. A rewritten storage engine that runs 99% of data on SSDs and 1% in RAM, delivering petabyte-scale retrieval at sub-millisecond latencies.

Redis Search and LangCache. The retrieval and semantic caching backbone underneath the platform. LangCache reduces redundant model calls by caching prompt responses.

The data industry is generally heading in the same direction now. Every major database vendor is making a context layer argument. 

Traditional database vendors including Oracle are integrating context and memory layers to bring relational databases into the agentic AI era. Purpose-built vector database vendors including Pinecone are doing the same, building out a new knowledge layer for agentic AI context. Standalone context layers like Hindsight are also part of the emerging landscape.

Trollope frames Redis's position as structurally different from that competition.

"For us to win, no one else has to lose," he said. Many Redis deployments already run MongoDB or Oracle as the backend system of record. Iris reflects and caches from those systems rather than displacing them. Redis is launching Iris in the Snowflake marketplace with native connectors.

Stephanie Walter, Practice Leader for AI Stack at HyperFRAME Research, puts the market context plainly. "The market is converging on the same conclusion: agents don't just need more tokens or better models. They need governed, current, low-latency context," Walter said.

Her read on Redis's differentiation focuses on where Redis already sits in the stack, which is close to runtime, latency-sensitive operational state, and real-time data., 

"The pitch is not 'better RAG' as much as 'agents need live context, memory, and fast retrieval while they are actually working," she said.

Whether it's Redis or another vendor, every context layer technology will face a governance challenge to be successful.

"Agentic AI will not scale in the enterprise if every agent becomes a new cost center, a new data access risk, and a new governance exception," she said. "The winning context layers will be the ones that make agents faster, cheaper, and safer to run."

Mangoes.ai is one company that has already had to answer those questions in production, under conditions where the cost of getting context wrong is measured in patient outcomes.

Amit Lamba, founder and CEO of Mangoes.ai, runs a real-time voice AI platform deployed across large healthcare facilities where patients and clinicians ask live questions about treatment, scheduling and case history. Mangoes.ai built its stack natively on Redis from the start. 

"Retrieval, memory, and session state all run through Redis, so we're not stitching together separate tools and hoping they talk to each other," Lamba said.

The problem Iris's dynamic memory capability addresses is what happens across a complex session.

 "Think about a one-hour group therapy session," Lamba said. "You need to know who said what, when, and be able to surface the right information to the therapist in the moment. That's not a simple retrieval problem."

The platform runs multiple specialized agents in parallel, one for entity identification, one for relationship reasoning and one for integrating case history. "The dynamic memory capability maps almost perfectly to the problem we're solving," Lamba said.

For enterprises that built their AI stack around RAG, the retrieval layer that got them to production is no longer enough to keep them there The RAG era is giving way to context architecture. The classic RAG model pushed data into the agent before the model was called. Production deployments are flipping that: agents pull what they need at runtime through tool calls, treating the data layer as a live resource rather than a pre-loaded payload. Teams still optimizing RAG pipelines are solving last year's problem.

The semantic layer is now production infrastructure. The model that defines business entities, their relationships and the access rules between them needs to be built, versioned and maintained with the same discipline as a data pipeline. Most organizations have not staffed or structured for that work. The enterprises that define their context architecture now are the ones that will not have to rebuild it when agent workloads scale.

Budget is already moving. VB Pulse Q1 2026 data shows retrieval optimization investment rising from 19% to 28.9% across the quarter, overtaking evaluation spending for the first time. Organizations that spent the previous year measuring their retrieval quality are now spending to fix it. The context layer is an active procurement decision, not a roadmap item.

"The first buyer question should not be 'Do I need a vector database, long context, memory, or a context engine?' It should be 'What does this agent need to know, how fresh must that knowledge be, who is allowed to access it, and what does every retrieval cost?'" Walter said.

Four supply-chain incidents hit OpenAI, Anthropic and Meta in 50 days: three adversary-driven attacks and one self-inflicted packaging failure. None targeted the model, and all four exposed the same gap: release pipelines, dependency hooks, CI runners, and packaging gates that no system card, AISI evaluation, or Gray Swan red-team exercise has ever scoped.

On May 11, 2026, a self-propagating worm called Mini Shai-Hulud published 84 malicious package versions across 42 @tanstack/* npm packages in six minutes flat. The worm rode in on release.yml, chaining a pull_request_target misconfiguration, GitHub Actions cache poisoning, and OIDC token extraction from runner memory to hijack TanStack’s own trusted release pipeline. The packages carried valid SLSA Build Level 3 provenance because they were published from the correct repository, by the correct workflow, using a legitimately minted OIDC token. No maintainer password was phished. No 2FA prompt was intercepted.

The trust model worked exactly as designed and still produced 84 malicious artifacts.

Two days later, OpenAI confirmed that two employee devices were compromised and credential material was exfiltrated from internal code repositories. OpenAI is now revoking its macOS security certificates and forcing all desktop users to update by June 12, 2026. OpenAI noted that it had already been hardening its CI/CD pipeline after an earlier supply-chain incident, but the two affected devices had not yet received the updated configurations. That is the response profile of a build-pipeline breach, not a model-safety incident.

Model red teams do not cover release pipelines. The four incidents below are evidence for a single architectural finding that belongs in every AI vendor questionnaire.

OpenAI Codex command injection (disclosed March 30, 2026). BeyondTrust Phantom Labs researcher Tyler Jespersen found that OpenAI Codex passed GitHub branch names directly into shell commands with zero sanitization. An attacker could inject a semicolon and a backtick subshell into a branch name, and the Codex container would execute it, returning the victim’s GitHub OAuth token in cleartext. The flaw affected the ChatGPT website, Codex CLI, Codex SDK, and the IDE Extension. OpenAI classified it Critical Priority 1 and completed remediation by February 2026. The Phantom Labs team used Unicode characters to make a malicious branch name visually identical to "main" in the Codex UI. One branch name. That is where the attack started.

LiteLLM supply-chain poisoning and Mercor breach (March 24–27, 2026). The threat group TeamPCP used credentials stolen in a prior compromise of Aqua Security’s Trivy vulnerability scanner to publish two poisoned versions of the LiteLLM Python package to PyPI. LiteLLM is a widely adopted open-source LLM proxy gateway used across major AI infrastructure teams. The malicious versions were live for roughly 40 minutes and received nearly 47,000 downloads before PyPI quarantined them.

That was enough.

The attack cascaded downstream into Mercor, the $10 billion AI data startup that supplies training data to Meta, OpenAI, and Anthropic. Four terabytes exfiltrated, including proprietary training methodology references from Meta. Meta froze the partnership indefinitely. A class action followed within five days. One compromised open-source dependency sitting 40 minutes on PyPI created a cross-industry blast radius that no single vendor’s model red team would have caught.

Anthropic Claude Code source map leak (March 31, 2026). This incident was not adversary-driven. Anthropic shipped Claude Code version 2.1.88 to the npm registry with a 59.8 MB source map file that should never have been included. The map file pointed to a zip archive on Anthropic’s own Cloudflare R2 bucket containing 513,000 lines of unobfuscated TypeScript across 1,906 files. Agent orchestration logic. 44 feature flags. System prompts. Multi-agent coordination architecture. All public. All downloadable. No authentication required. Security researcher Chaofan Shou flagged the exposure within hours, and Anthropic pulled the package. Anthropic confirmed it was a “release packaging issue caused by human error.” This was the second such leak in 13 months. The root cause was a missing line in .npmignore. No attacker was involved, but the release-surface gap is identical. No human review gate existed between the build artifact and the registry publish step.

TanStack worm and downstream propagation (May 11–14, 2026). Wiz Research attributed the Mini Shai-Hulud attack to TeamPCP with high confidence. StepSecurity detected the compromise within 20 minutes. The worm spread beyond TanStack to Mistral AI, UiPath, and 160-plus packages within hours. Mini Shai-Hulud even impersonated the Anthropic Claude GitHub App identity by authoring commits under the fabricated identity “claude <claude@users.noreply.github.com>” to bypass code review.

Four incidents. Three frontier labs. One finding. The red-team scope stops at the model boundary, and the build pipeline sits on the other side of it.

On May 10, 2026, OpenAI launched Daybreak, a cybersecurity initiative built on GPT-5.5 and a new permissive model called GPT-5.5-Cyber designed for authorized red teaming, penetration testing, and vulnerability discovery. Daybreak pairs Codex Security with partners, including Cisco, CrowdStrike, Akamai, Cloudflare, and Zscaler. OpenAI positioned the launch as proof that frontier AI can tilt the balance toward defenders.

The next day, the TanStack worm compromised two OpenAI employee devices.

OpenAI’s own incident disclosure acknowledged the gap directly. The company had already been hardening its CI/CD pipeline after the earlier Axios supply-chain attack, but the two affected devices “did not have the updated configurations that would have prevented the download.” The controls existed. The deployment was in progress. The worm arrived first.

The security community saw the same gap: Security researcher @EnTr0pY_88 noted on X that the real signal was the certificate rotation, not the exfiltrated code. "The cert rotation…is what you do when the blast radius reached signing trust, not just source access." @OpenMatter_ put the SLSA provenance failure in one sentence. "If an attacker controls your CI runner, they control your attestations. Policy-based security is failing at scale." And @The_Calda compressed the disclosure's internal contradiction into seven words. "'Limited impact' but the next sentence is 'we're rotating signing certs.'"

A company that launched a cyber defense platform on Sunday and disclosed a build-pipeline breach on Tuesday is not failing at model safety. OpenAI is demonstrating the exact gap this audit grid exists to close. The model red team and the release-pipeline red team are two different disciplines; four incidents in 50 days suggest only one of them is being funded consistently.

The matrix below maps the seven release-surface classes missing from AI vendor questionnaires, with vendor hit, failure mechanism, detection gap, technical mitigation, and priority tier a security team can execute before Q2 renewals close.

For teams that need to map these rows into existing GRC tooling, rows 2, 3, and 5 align with NIST SSDF PS.1.1 (protect all forms of code from unauthorized access and tampering). Row 4 maps to SSDF PS.2.1 (provide mechanisms for verifying software release integrity). Row 6 maps partially to SLSA Source Track requirements for verified contributor identity, though no published framework directly addresses upstream dependency maintainer credential provenance. Row 7 is not yet addressed by any published framework, which is itself the finding.

Release-surface class

Vendor hit

Failure mechanism

Detection gap

Technical mitigation

Priority

Model capability evals (jailbreak, misuse, exfiltration)

All three (ongoing)

Covered. System cards, AISI Expert suite, Gray Swan scope this today.

None. This row is the baseline.

Continue requiring the system card at every renewal.

Baseline

CI runner trust boundary (pull_request_target)

TanStack; OpenAI downstream (May 11–14, 2026)

TanStack pwn-request ran fork code in base-repo context. Poisoned pnpm cache. Extracted OIDC token from runner memory. Two OpenAI employee devices compromised.

No system card covers CI runner isolation. No AISI eval tests fork-to-base trust boundaries.

Audit every repo for pull_request_target + fork SHA checkout. Block fork code from base-repo context. Pin cache keys to commit SHA.

Do this week

OIDC trusted-publisher + SLSA provenance

TanStack; OpenAI downstream (May 11, 2026)

TanStack minted valid SLSA Build Level 3 provenance for all 84 malicious packages. First known npm worm with valid cryptographic attestation.

SLSA attestation confirms build origin, not build intent. No vendor questionnaire distinguishes the two.

Pin trusted publisher to branch + workflow, not just repository. Add behavioral analysis at install time.

Do this week

Release packaging review (human gate before publish)

Anthropic (Mar 31, 2026)

Missing .npmignore shipped 59.8 MB source map in Claude Code npm package. 513K lines exposed including agent logic, 44 feature flags, system prompts. Second leak in 13 months. Self-inflicted, not adversary-driven.

No red-team exercise checks artifact contents before registry publish.

Human review between build artifact and registry publish. Enforce .npmignore in CI. Fail build on unexpected artifact size.

Before renewal

Dependency lifecycle hooks (prepare, postinstall)

TanStack; OpenAI + downstream (May 11, 2026)

router_init.js executes on import. tanstack_runner.js self-propagates via optionalDependencies prepare hook. Spread to Mistral AI, UiPath, 160+ packages in hours.

Lifecycle hooks execute before any scanner runs. Model evals never test package install behavior.

Disable lifecycle scripts in CI by default. Explicit allowlist for production. Flag new optionalDependencies in PR review. Set minimumReleaseAge.

Do this week

Vendor maintainer credential hygiene

Meta via Mercor (Mar 24–27, 2026)

TeamPCP stole LiteLLM maintainer credential via prior Trivy compromise. Two poisoned PyPI versions live 40 min. Mercor cache held Meta training methodology references. 4 TB exfiltrated. Meta froze the partnership.

Vendor questionnaires ask about encryption and access control, not maintainer credential provenance for upstream dependencies.

Require hardware-key auth from every maintainer before onboarding. Add package-manager cooldown. Audit transitive dependency tree quarterly.

Add to vendor contract

Agent container input sanitization

OpenAI Codex (disclosed Mar 30, 2026)

BeyondTrust Phantom Labs injected shell commands through GitHub branch-name parameter. Stole OAuth tokens from Codex container. Scalable across shared repos. Rated Critical P1, patched Feb 2026.

Agent red teams test prompt injection, not input-parameter injection at the container level.

Sanitize all external input before shell execution. Audit OAuth token scope and lifetime per agent session. Enforce least-privilege on every container.

Do this week

The matrix tells your team what to fix. Three actions tell security directors how to move it forward.

1. Add one question to every AI vendor questionnaire. "Does your organization red-team its release pipeline, including CI runner trust boundaries, OIDC token scoping, dependency lifecycle hooks, and registry publish gates? Provide the last assessment date and scope." No date and no scope document is the finding.

2. Run rows 2 through 7 against your own CI pipelines this week. StepSecurity and Snyk both published detection and remediation steps for the TanStack worm patterns. Dev teams pull OpenAI SDKs, Anthropic packages, and Llama weights through npm, PyPI, and HuggingFace every week. The same patterns that got exploited are in your CI right now.

3. Brief the board on the provenance gap. The TanStack worm proved that valid cryptographic provenance can sit on top of a malicious package. Attestation tells the board where a package was built. Behavioral analysis tells the board what it does after install. Q2 renewal requires both. Snyk's analysis recommends pinning trusted publisher configurations to specific branches and workflows, not just repositories. That is the language the board presentation needs.

Mini Shai-Hulud does not stop at CI secrets. Datadog Security Labs documented that the payload reads ~/.claude.json and exfiltrates it. It scans for 1Password and Bitwarden vaults, Kubernetes service accounts, cloud provider tokens, and shell history files where developers paste API keys. StepSecurity's deobfuscation confirmed that Mini Shai-Hulud harvests Claude and Kiro MCP server configurations, which store API keys and auth tokens for external services. For developers using AI coding agents, the worm already knows where their credentials live.

OpenAI, Anthropic, and Meta will keep publishing system cards. They will keep funding red-team competitions. They will keep passing model evaluations. None of that stops the next worm from riding in on release.yml.

The TanStack postmortem team said it directly. Modern supply-chain defenses are important but not sufficient on their own. Teams must proactively identify and close workflow gaps rather than relying solely on the security features of their tools.

Enterprises building and deploying agents have a problem: it’s taking their engineers too long to find out that an agent made a mistake, and the loop has continued to perpetuate, especially without a human at every step. 

LangSmith, the monitoring and evaluation platform from LangChain, launched a new capability in public beta that could make that issue more manageable. LangSmith Engine automates the entire chain by detecting production failures, diagnosing root causes against the live codebase, drafting a fix and preventing regression. It does this in a single automated pass. 

LangSmith Engine gives AI engineers a faster path to triage, but it launches into a crowded field: Anthropic, OpenAI and Google are all pulling observability and evaluation into their own platforms.

LangChain said in a blog post that the typical agent development cycle starts by tracing the agent to understand what it’s doing, followed by identifying gaps, making changes to the prompts and tools, and creating ground-truth datasets. Developers then run experiments and check for regressions before shipping the agent. 

The problem is that customers often run into issues when the trace review doesn’t surface faulty patterns, error repetition gets difficult to see, and there’s no targeted evaluator to catch the same problem when it repeats in production.

LangSmith Engine works by monitoring production traces for several signal types, “explicit errors, online evaluator failures, trace anomalies, negative user feedback and unusual behaviors like user asking questions the agent wasn’t built to answer,” according to the blog post.

Engine will then read the live codebase, find the culprit and draft a pull request before proposing a custom evaluator for that specific failure pattern. The human comes in at the approval step. 

It’s built on top of LangSmith’s existing tracing and evaluation infrastructure and also works with an enterprise’s evaluator results. 

Unlike observability tools such as Weights & Biases, Arize Phoenix and Honeyhive, LangSmith Engine takes the entire chain automatically — detecting the failure, diagnosing root cause, drafting a fix — and brings the human in only at the approval step.

While LangSmith identified this evaluation loop as a need for many enterprises, Engine comes at a time where the larger providers are beginning to offer observability tools within their platform. This means enterprises may choose to use an end-to-end platform rather than add LangSmith Engine onto their existing workflows. 

Anthropic's Claude Managed Agents brings together agentic deployment, evaluation and orchestration into a single suite. OpenAI's Frontier offers a similar end-to-end platform for building, governing and evaluating enterprise agents — though both have faced questions from enterprises wary of committing to a single vendor.

However, practitioners point out that not everyone wants to bring evaluations and observability fully into one platform.

Leigh Coney, founder and principal consultant at Workwise Solutions, told VentureBeat that third-party observability is the default for many enterprises. 

“One fund I work with runs Claude for analysis and GPT for a separate workflow. If observability lives inside each provider's tooling, you now have two systems that can't talk to each other. Your compliance team can't produce a unified audit trail,” he said. “So third-party observability is surviving because multi-model is already the default in enterprise, and somebody has to sit across providers.”

Jessica Arredondo Murphy, CEO and co-founder of True Fit, said independent platforms like LangSmith have to prove to enterprises that they can "answer the long-term question of whether they become the cross-model operating layer for quality and reliability.”

“Enterprises are not consolidating onto the first-party model provider tooling as quickly as the model providers would prefer. What I see is a pragmatic split: teams will use first-party tooling for fast onboarding and early-stage debugging, but as soon as they care about production reliability, governance, and long-term flexibility, they tend to introduce a more neutral layer for observability and evaluation,” she said. 

LangSmith Engine is available now in public beta. Teams can connect a tracing project, optionally connect their repo, and Engine will begin surfacing issues from production traces automatically.

Retrieval-augmented generation (RAG) has become the de facto standard for grounding large language models (LLMs) in private data. The standard architecture — chunking documents, embedding them into a vector database, and retrieving top-k results via cosine similarity — is effective for unstructured semantic search.

However, for enterprise domains characterized by highly interconnected data (supply chain, financial compliance, fraud detection), vector-only RAG often fails. It captures similarity but misses structure. It struggles with multi-hop reasoning questions like, "How will the delay in Component X impact our Q3 deliverable for Client Y?" because the vector store doesn't "know" that Component X is part of Client Y's deliverable.

This article explores the graph-enhanced RAG pattern. Drawing on my experience building high-throughput logging systems at Meta and private data infrastructure at Cognee, we will walk through a reference architecture that combines the semantic flexibility of vector search with the structural determinism of graph databases.

Vector databases excel at capturing meaning but discard topology. When a document is chunked and embedded, explicit relationships (hierarchy, dependency, ownership) are often flattened or lost entirely.

Consider a supply chain risk scenario. While this is a hypothetical example, it represents the exact class of structural problems we see constantly in enterprise data architectures:

• Structured data: A SQL database defining that Supplier A provides Component X to Factory Y.

• Unstructured data: A news report stating, "Flooding in Thailand has halted production at Supplier A's facility."

A standard vector search for "production risks" will retrieve the news report. However, it likely lacks the context to link that report to Factory Y's output. The LLM receives the news but cannot answer the critical business question: "Which downstream factories are at risk?"

In production, this manifests as hallucination. The LLM attempts to bridge the gap between the news report and the factory but lacks the explicit link, leading it to either guess relationships or return an "I don't know" response despite the data being present in the system.

To solve this, we move from a "Flat RAG" to a "Graph RAG" architecture. This involves a three-layer stack:

1. Ingestion (The "Meta" Lesson): At Meta, working on the Shops logging infrastructure, we learned that structure must be enforced at ingestion. You cannot guarantee reliable analytics if you try to reconstruct structure from messy logs later. Similarly, in RAG, we must extract entities (nodes) and relationships (edges) during ingestion. We can use an LLM or named entity recognition (NER) model to extract entities from text chunks and link them to existing records in the graph.

2. Storage: We use a graph database (like Neo4j) to store the structural graph. Vector embeddings are stored as properties on specific nodes (e.g., a RiskEvent node).

3. Retrieval: We execute a hybrid query:

   • Vector scan: Find entry points in the graph based on semantic similarity.

   • Graph traversal: Traverse relationships from those entry points to gather context.

Let's build a simplified implementation of this supply chain risk analyzer using Python, Neo4j, and OpenAI.

We need a schema that connects our unstructured "risk events" to our structured "supply chain" entities.

In this step, we assume the structural graph (suppliers -> factories) already exists. We ingest a new unstructured "risk event" and link it to the graph.

This is the core differentiator. Instead of just returning the top-k chunks, we use Cypher to perform a vector search to find the event, and then traverse to find the downstream impact.

The output: Instead of a generic text chunk, the LLM receives a structured payload:

[{'issue': 'Severe flooding...', 'impacted_supplier': 'TechChip Inc', 'risk_to_factory': 'Assembly Plant Alpha'}]

This allows the LLM to generate a precise answer: "The flooding at TechChip Inc puts Assembly Plant Alpha at risk."

Moving this architecture from a notebook to production requires handling trade-offs.

Graph traversals are more expensive than simple vector lookups. In my work on product image experimentation at Meta, we dealt with strict latency budgets where every millisecond impacted user experience. While the domain was different, the architectural lesson applies directly to Graph RAG: You cannot afford to compute everything on the fly.

• Vector-only RAG: ~50-100ms retrieval time.

• Graph-enhanced RAG: ~200-500ms retrieval time (depending on hop depth).

Mitigation: We use semantic caching. If a user asks a question similar (cosine similarity > 0.85) to a previous query, we serve the cached graph result. This reduces the "graph tax" for common queries.

In vector databases, data is independent. In a graph, data is dependent. If Supplier A stops supplying Factory Y, but the edge remains in the graph, the RAG system will confidently hallucinate a relationship that no longer exists.

Mitigation: Graph relationships must have Time-To-Live (TTL) or be synced via Change Data Capture (CDC) pipelines from the source of truth (the ERP system).

Should you adopt Graph RAG? Here is the framework we use at Cognee:

1. Use vector-only RAG if:

   • The corpus is flat (e.g., a chaotic Wiki or Slack dump).

   • Questions are broad ("How do I reset my VPN?").

   • Latency < 200ms is a hard requirement.

2. Use graph-enhanced RAG if:

   • The domain is regulated (finance, healthcare).

   • "Explainability" is required (you need to show the traversal path).

   • The answer depends on multi-hop relationships ("Which indirect subsidiaries are affected?").

Graph-enhanced RAG is not a replacement for vector search, but a necessary evolution for complex domains. By treating your infrastructure as a knowledge graph, you provide the LLM with the one thing it cannot hallucinate: The structural truth of your business.

Daulet Amirkhanov is a software engineer at UseBead.

For AI systems to keep improving in knowledge work, they need either a reliable mechanism for autonomous self-improvement or human evaluators capable of catching errors and generating high-quality feedback. The industry has invested enormously in the first. It's giving almost no thought to what's happening to the second.

I’d argue that we need to treat the human evaluation problem with just as much rigor and investment as we put into building the model capabilities themselves. New grad hiring at major tech companies has dropped by half since 2019. Document review, first-pass research, data cleaning, code review: Models handle these now. The economists tracking this call it displacement. The companies doing it call it efficiency. Neither are focusing on the future problem.

The obvious pushback is reinforcement learning (RL). AlphaZero learned Go, chess, and Shogi at superhuman levels without human data and generated novel strategies in the process. Move 37 in the 2016 match against Lee Sedol, a move professionals said they would never have played, didn't come from human annotation. It emerged from AI self-play. 

What enables this is the stability of the environment. Move 37 is a novel move within the fixed state space of Go. The rules are complete, unambiguous, and permanent. More importantly, the reward signal is perfect: Win or lose, and immediate, with no room for interpretation. The system always knows whether a move was good because the game eventually ends with a clear result.

Knowledge work doesn't have either of those properties. The rules in any professional domain are dynamic and continuously rewritten by the humans operating in them. New laws get passed. New financial instruments are invented. A legal strategy that worked in 2022 may fail in a jurisdiction that has since changed its interpretation. Whether a medical diagnosis was right may not be known for years. Without a stable environment and an unambiguous reward signal, you cannot close the loop. You need humans in the evaluation chain to continue teaching the model.

The AI systems being built today were trained on the expertise of people who went through exactly that formation. The difference now is that entry-level jobs that develop such expertise were automated first. Which means the next generation of potential experts is not accumulating the kind of judgment that makes a human evaluator worth having in the loop.

History has examples of knowledge dying. Roman concrete. Gothic construction techniques. Mathematical traditions that took centuries to recover. But in every historical case, the cause was external: Plague, conquest, the collapse of the institutions that hosted the knowledge. What's different here is that no external force is required. Fields could atrophy not from catastrophe but from a thousand individually rational economic decisions, each one sensible in isolation. That's a new mechanism, and we don't have much practice recognizing it while it's happening.

At its logical limit, this isn’t just a pipeline problem. It’s a demand collapse for the expertise itself.

Consider advanced mathematics. It doesn’t atrophy because we stop training mathematicians. It atrophies because organizations stop needing mathematicians for their day-to-day work, the economic incentive to become one disappears, the population of people who can do frontier mathematical reasoning shrinks, and the field’s capacity to generate novel insight quietly collapses. The same logic applies to coding. Our question is not “will AI write code” but “if AI writes all production code, who develops the deep architectural intuition that produces genuinely novel systems design?” 

There is a critical difference between a field being automated and a field being understood. We can automate a huge amount of structural engineering today, but the abstract knowledge of why certain approaches work lives in the heads of people who spent years doing it wrong first. If you eliminate the practice, you don’t just lose the practitioners. You lose the capacity to know what you’ve lost.

Advanced mathematics, theoretical computer science, deep legal reasoning, complex systems architecture: When the last person who deeply understands a subfield of algebra retires and no one replaces them because the funding dried up and the career path disappeared, that knowledge isn’t likely to be rediscovered any time soon. 

It’s gone. And nobody notices because the models trained on their work still perform well on benchmarks for another decade. I think of this as a hollowing out: The surface capability remains (models can still produce outputs that look expert) while the underlying human capacity to validate, extend, or correct that expertise quietly disappears.

The current approach is rubric-based evaluation. Constitutional AI, reinforcement learning from AI feedback (RLAIF), and structured criteria that let models score models are serious techniques that meaningfully reduce dependence on human evaluators. I'm not dismissing them.

Their limitation is this: A rubric can only capture what the person who wrote it knew to measure. Optimize hard against it and you get a model that's very good at satisfying the rubric. That's not the same thing as a model that's actually right.

Rubrics scale the explicit, articulable part of judgment. The deeper part, the instinct, the felt sense that something is off, doesn't fit in a rubric. You can't write it down because you need to experience it first before you know what to write.

This isn’t an argument for slowing development. The capability gains are real. And it’s possible that researchers will find ways to close the evaluation loop without human judgment. Maybe synthetic data pipelines get good enough. Maybe models develop reliable self-correction mechanisms we can’t yet imagine.

But we don’t have those today. And in the meantime, we’re dismantling the human infrastructure that currently fills the gap, not as a deliberate decision but as a byproduct of a thousand rational ones. The responsible version of this transition isn’t to assume the problem will solve itself. It’s to treat the evaluation gap as an open research problem with the same urgency we bring to capability gains.

The thing AI most needs from humans is the thing we’re least focused on preserving. Whether that’s permanently true or temporarily true, the cost of ignoring it is the same.

Ahmad Al-Dahle is CTO of Airbnb.

The company formerly known as Intercom just did something that no major customer service platform has attempted at scale: it built an AI agent whose sole job is to manage another AI agent.

Fin Operator, announced Thursday at a live event in San Francisco, is a new AI-powered system designed specifically for the back-office teams that configure, monitor, and improve Fin, the company's customer-facing AI agent. Rather than replacing human support agents — which is what Fin itself does on the front lines — Operator targets the growing army of support operations professionals who spend their days updating knowledge bases, debugging conversation failures, and combing through performance dashboards.

"Fin is an agent for your customers," Brian Donohue, the company's VP of Product, told VentureBeat in an exclusive interview ahead of the launch. "Operator is an agent for your support ops team. This is an agent for the back office team who manages Fin and then manages their human agents."

The announcement arrives at a pivotal moment for the company. Just two days ago, CEO Eoghan McCabe formally renamed the 15-year-old company from Intercom to Fin — an aggressive signal that the AI agent is now the business, not merely a feature of it. Fin recently crossed $100 million in annual recurring revenue and is growing at 3.5x. The broader company generates $400 million in ARR, meaning the AI agent now accounts for roughly a quarter of total revenue and virtually all of its growth.

Fin Operator enters early access for Pro-tier users starting today, with general availability planned for summer 2026.

As companies push their AI agents to handle more conversations — Fin alone now resolves more than two million customer issues each week across 8,000 customers globally, including Anthropic, DoorDash, and Mercury — the operational complexity behind those systems has exploded. Someone has to keep the knowledge base current. Someone has to figure out why the bot entered an infinite loop with a frustrated customer last Tuesday. Someone has to analyze whether the automation rate dropped after a product update.

That "someone" is the support operations team, and according to Donohue, they are drowning.

"Almost every support ops team is already doing data analysis and knowledge management — that's table stakes today," Donohue said. "Where teams struggle is the agent builder work. It's a new skill set, and most don't have enough time for it. They get their first iteration up and running, and then they get stuck."

The problem is structural. AI customer agents are not static software. They require constant tuning — a process that looks more like training a new employee than configuring a SaaS tool. Each customer conversation is a potential source of failure, and each failure requires diagnosis, root-cause analysis, a configuration fix, testing, and monitoring. It is tedious, technical, and relentless. Fin Operator aims to collapse that entire loop into a conversational interface.

Donohue described Operator as filling three distinct roles that typically consume the bandwidth of support ops teams: expert data analyst, expert knowledge manager, and expert agent builder.

As a data analyst, Operator can field high-level questions like, "How did my team perform last week?" and generate on-the-fly charts, trend reports, and drill-down analyses across all of the data already stored in Intercom's platform. The company has loaded Operator with contextual knowledge about customer-specific data attributes to help it interpret workspace-specific metrics accurately.

As a knowledge manager, Operator can ingest a product update — say, a three-page PDF describing a new feature — and autonomously search the company's entire content library to identify what needs to change. It finds gaps, drafts new articles, suggests edits to existing ones, and presents everything in a diff-style review interface. The underlying search engine is the same semantic search system that Intercom has built and optimized for Fin over more than two years.

"On that knowledge management front, you just have such a time compression of something that would take, certainly hours, sometimes days, into the space of about 10 minutes," Donohue said.

As an agent builder, Operator introduces what the company calls a "debugger skill." Support ops teams can paste in a link to a conversation where Fin misbehaved, and Operator will trace every step of Fin's internal reasoning, identify the root cause — often a piece of guidance that unintentionally creates a loop — propose a rewrite, back-test the change against the original conversation, and then suggest creating a production monitor to catch similar issues going forward.

"This is literally what our professional services team does," Donohue explained. "You've written guidance that is unintentionally causing Fin to repeat itself — this happens a lot. You didn't realize it, but you never gave it an escape hatch."

One of the most consequential design decisions in Fin Operator is what the company calls its "proposal system" — a mechanism that functions like a pull request in software engineering.

Every change that Operator recommends — whether it is an edit to a help article, a rewrite of an AI guidance rule, or the creation of a new QA monitor — appears as a proposal with a full diff view. Users can inspect, edit, and approve each change before it takes effect. Nothing goes live without a human clicking "Apply."

"Right now, we're taking zero risk on this — Fin cannot make any changes to the system without human approval," Donohue emphasized. "Nothing goes live until a human clicks apply."

This is a notable architectural choice. In a market increasingly enamored with fully autonomous AI systems, the company is deliberately keeping a human approval gate in place — at least for now. Donohue acknowledged this will evolve, but said the current moment demands caution: "It's too big a leap to just let Operator make changes automatically and then tell the team, 'Hey, let me tell you about what I did.'"

For enterprise buyers evaluating AI tools, this design point matters. It is the difference between an AI system that proposes changes and one that enacts them — a distinction that compliance teams, security officers, and risk managers will scrutinize closely.

In a revealing technical detail, Donohue confirmed that Fin Operator does not use the company's proprietary Apex models — the same custom AI models that power the customer-facing Fin agent and that the company has promoted as outperforming GPT-5.4 and Claude Sonnet 4.6 in customer service benchmarks.

Instead, Operator runs on Anthropic's Claude.

"We're not using our custom models," Donohue said. "Those are designed to directly answer customer questions, whereas these are closer to what frontier models are best suited for. This is really closer to software engineering."

The distinction is telling. Fin's Apex models are optimized for one thing: resolving customer service conversations with minimal hallucination and maximum accuracy. Operator's tasks — analyzing data, writing code-like configurations, debugging complex reasoning chains — demand a different kind of intelligence. Donohue characterized these capabilities as more akin to software engineering, an area where Anthropic's Claude models have been deliberately optimized.

The company has not ruled out building custom models for Operator in the future, but Donohue positioned it as a lower priority. What the team has built around Claude, he argued, is the differentiated layer: the proposal system, the debugger skill, the semantic search integration, the data attribution logic, and the charting capabilities that make Operator more than just "Claude inside the app."

Fin Operator is currently in beta with roughly 200 customers, a number Donohue said has "ramped up pretty fast the last couple of weeks."

Constantina Samara, VP of Customer Support, Enablement & Trust at Synthesia, said the tool has already changed how her team works: "Previously, improving how Fin handles a conversation often meant reviewing everything yourself — the conversation, the configuration, the content. With Fin Operator, you just ask. It walks you through what happened and makes improving Fin dramatically easier."

Jordan Thompson, an AI Conversational Analyst at Raylo, reported that he has been using Operator daily and has run head-to-head comparisons between Operator's analysis and his own manual work. "It's very accurate," Thompson said. "It's just as strong at high-level trend analysis as it is at debugging individual conversations. That's a real limitation when using an LLM connector on its own — you get conversational depth but nothing on reporting or trends."

Donohue also shared an internal anecdote from the company's own knowledge management team. Beth, who leads knowledge operations, told the product team that Operator made her feel like she had "five more people on my team." Whether internal testimonials carry the same weight as external customer validation is debatable, but Donohue said the knowledge management use case consistently generates the most visceral reactions because the time savings are so stark — collapsing hours or days of content auditing into roughly 10 minutes.

Fin Operator will live inside the company's Pro add-on tier — a relatively new bundle that already includes advanced analytics features like CX scoring, topic detection, real-time issue detection, and quality assurance monitoring across both AI and human agent conversations.

The pricing model introduces something new for the company: usage-based billing. Intercom has historically relied on outcome-based pricing — charging roughly $0.99 per conversation that Fin resolves without human intervention. Operator's work does not map cleanly to that model because it produces configuration changes, not customer resolutions.

"This has pushed us to a different model, to go more into that usage model for support ops teams," Donohue said. "We'll try to be generous with the usage amounts that come into Pro, but for people who are leaning heavily in, we'll have the ability to buy more usage blocks."

The shift is worth watching. Outcome-based pricing was one of the company's most distinctive market positions — a bet that customers would pay for results rather than seats. Extending that philosophy to internal operations work proved impractical, which suggests that as AI agents take on more diverse roles within an organization, the pricing models that support them will need to become equally diverse.

Fin Operator lands in an increasingly competitive landscape. Zendesk, Salesforce, Sierra, and a constellation of AI-native startups are all building some version of AI-powered support operations tooling. The broader AI automation market is projected to reach $169 billion in 2026, according to Grand View Research, growing at a 31.4% compound annual rate.

But Donohue argued that Operator's differentiation lies in two areas. First, breadth: Operator works across the full surface area of the company's configuration system — data, content, procedures, simulations, guidance, and monitoring — rather than addressing a single narrow use case. Second, the fact that it spans both AI and human operations.

"Most critically, where I think we have the most differentiation is because it's for your human system and your AI system," Donohue said. "That's really one of the unique spaces we have — to have a first-class AI agent and a first-class help desk, and Operator works across both."

The competitive positioning also benefits from timing. The company's recent corporate rebrand from Intercom to Fin signals a wholesale commitment to AI that legacy players may struggle to match. As CEO McCabe wrote in announcing the name change, the AI agent "is about to be the largest part of our business." The help desk product continues as Intercom 2, but the parent company now carries the name of its AI agent — a branding move that some industry observers have interpreted as pre-IPO positioning. The Fin API Platform, launched in early April, adds another dimension: the company opened its proprietary Apex models to third-party developers and even offered to license the technology to direct competitors like Decagon and Sierra.

Step back from the product specifics and Fin Operator represents something potentially more consequential than a new dashboard or analytics tool. It is one of the first commercial products to explicitly embody the emerging paradigm of AI agents that manage other AI agents — a two-layer abstraction that is beginning to reshape how companies think about operational software.

Donohue was emphatic on this point. The real paradigm shift, he argued, is not the chat interface replacing buttons and menus. It is that the AI is doing the actual knowledge work — figuring out what should change, why, and how.

"The UX change is secondary, even though it's most visible," Donohue said. "The change is that we are identifying and doing the work of support operations. It's doing the work of what the knowledge manager is doing, so that they just have to approve that. That's the huge shift."

The analogy to software engineering is apt. Over the past year, AI coding agents have fundamentally altered the daily workflow of developers, shifting their primary responsibility from writing code to reviewing and guiding the AI that writes it. Donohue sees the same transformation arriving for support operations professionals.

"Software engineers — three months have upended their world, where their primary job now is managing agents who are actually writing the code," he said. "Similarly now, support ops, your job is to manage an agent who's managing the agent for your customers."

Whether this vision pans out at enterprise scale remains to be seen. The company is still launching Operator in beta precisely because it wants to keep refining quality through what Donohue described as a painstaking, conversation-by-conversation debugging process. "We've spent three months, conversation by conversation, learning, fixing, learning, fixing, to get it where it's robust," he said.

But if the early returns hold, Fin Operator may preview what the next generation of enterprise software looks like: not tools that help humans do work faster, but agents that do the work themselves, subject to human judgment and approval. For customer service leaders already running AI agents in production, the question is no longer just "how good is my bot?" It is now, inevitably, "who is managing it?" And increasingly, the answer is another bot.

One of the key challenges of current multi-agent AI systems is that they communicate by generating and sharing text sequences, which introduces latency, drives up token costs, and makes it difficult to train the entire system as a cohesive unit. 

To overcome this challenge, researchers at University of Illinois Urbana-Champaign and Stanford University developed RecursiveMAS, a framework that enables agents to collaborate and transmit information through embedding space instead of text. This change results in both efficiency and performance gains. 

Experiments show that RecursiveMAS achieves accuracy improvement across complex domains like code generation, medical reasoning, and search, while also increasing inference speed and slashing token usage. 

RecursiveMAS is significantly cheaper to train than standard full fine-tuning or LoRA methods, making it a scalable and cost-effective blueprint for custom multi-agent systems.

Multi-agent systems can help tackle complex tasks that single-agent systems struggle to handle. When scaling multi-agent systems for real-world applications, a big challenge is enabling the system to evolve, improve, and adapt to different scenarios over time. 

Prompt-based adaptation improves agent interactions by iteratively refining the shared context provided to the agents. By updating the prompts, the system acts as a director, guiding the agents to generate responses that are more aligned with the overarching goal. The fundamental limitation is that the capabilities of the models underlying each agent remain static. 

A more sophisticated approach is to train the agents by updating the weights of the underlying models. Training an entire system of agents is difficult because updating all the parameters across multiple models is computationally non-trivial.

Even if an engineering team commits to training their models, the standard method of agents communicating via text-based interactions creates major bottlenecks. Because agents rely on sequential text generation, it causes latency as each model must wait for the previous one to finish generating its text before it can begin its own processing. 

Forcing models to spell out their intermediate reasoning token-by-token just so the next model can read it is highly inefficient. It severely inflates token usage, drives up compute costs, and makes iterative learning across the whole system painfully slow to scale. 

Instead of trying to improve each agent as an isolated, standalone component, RecursiveMAS is designed to co-evolve and scale the entire multi-agent system as a single integrated whole. 

The framework is inspired by recursive language models (RLMs). In a standard language model, data flows linearly through a stack of distinct layers. In contrast, a recursive language model reuses a set of shared layers that processes the data and feeds it back to itself. By looping the computation, the model can deepen its reasoning without adding parameters.

RecursiveMAS extends this scaling principle from a single model to a multi-agent architecture that acts as a unified recursive system. In this setup, each agent functions like a layer in a recursive language model. Rather than generating text, the agents iteratively pass their continuous latent representations to the next agent in the sequence, creating a looped hidden stream of information flowing through the system. 

This latent hand-off continues down the line through all the agents. When the final agent finishes its processing, its latent outputs are fed directly back to the very first agent, kicking off a new recursion round. 

This structure allows the entire multi-agent system to interact, reflect, and refine its collective reasoning over multiple rounds entirely in the latent space, with only the very last agent producing a textual output in the final round. It is like the agents are communicating telepathically as a unified whole and the last agent provides the final response as text.

To make continuous latent space collaboration possible, the authors introduce a specialized architectural component called the RecursiveLink. This is a lightweight, two-layer module designed to transmit and refine a model's latent states rather than forcing it to decode text. 

A language model's last-layer hidden states contain the rich, semantic representation of its reasoning process. The RecursiveLink is designed to preserve and transmit this high-dimensional information from one embedding space to another. 

To avoid the cost of updating every parameter across multiple large language models, the framework keeps the models' parameters frozen. Instead, it optimizes the system by only training the parameters of the RecursiveLink modules.

To handle both internal reasoning and external communication, the system uses two variations of the module. The inner RecursiveLink operates inside an agent during its reasoning phase. It takes the model's newly generated embeddings and maps them directly back into its own input embedding space. This allows the agent to continuously generate a stream of latent thoughts without generating discrete text tokens. 

The outer RecursiveLink serves as the bridge between agents. Because agents in a real-world system might use different model architectures and sizes, their internal embedding spaces have entirely different dimensions. The outer RecursiveLink includes an additional layer designed to match the embeddings from one agent's hidden dimension with the next agent's embedding space.

During training, first, the inner links are trained independently to warm up each agent's ability to think in continuous latent embeddings. Then, the system enters outer-loop training, where the diverse, frozen models are chained together in a loop, and the system is evaluated based on the final textual output of the last agent. 

The only thing that gets updated in the training process is the RecursiveLink parameters and the original model weights remain unchanged, similar to low-rank adaptation (LoRA). Another advantage of this system comes into effect when you have multiple agents on top of the same backbone model. 

If you have a multi-agent system where two agents are built on the exact same foundation model acting in different roles, you do not need to load two copies of the model into your GPU memory, nor do you train them separately. The agents will share the same backbone as the brain and use the RecursiveLink as the connective tissue.

The researchers evaluated RecursiveMAS across nine benchmarks spanning mathematics, science and medicine, code generation, and search-based question answering. They created a multi-agent system using open-weights models including Qwen, Llama-3, Gemma3, and Mistral. These models were assigned roles to form different agent collaboration patterns such as sequential reasoning and mixture-of-experts collaboration. 

RecursiveMAS was compared to baselines under identical training budgets, including standalone models enhanced with LoRA or full supervised fine-tuning, alternative multi-agent frameworks like Mixture-of-Agents and TextGrad, and recursive baselines like LoopLM. It was also compared to Recursive-TextMAS, which uses the same recursive loop structure as RecursiveMAS but forces the agents to explicitly communicate via text.

RecursiveMAS achieved an average accuracy improvement of 8.3% compared to the strongest baselines across the benchmarks. It excelled particularly on reasoning-heavy tasks, outperforming text-based optimization methods like TextGrad by 18.1% on AIME2025 and 13% on AIME2026. 

Because it avoids generating text at every step, RecursiveMAS achieved 1.2x to 2.4x end-to-end inference speedup. RecursiveMAS is also much more token efficient than the alternative. Compared to the text-based Recursive-TextMAS, it reduces token usage by 34.6% in the first round of the recursion, and by round three, it achieves 75.6% token reduction. RecursiveMAS also proved remarkably cheap to train. Because it only updates the lightweight RecursiveLink modules, which consist of roughly 13 million parameters or about 0.31% of the trainable parameters of the frozen models, it requires the lowest peak GPU memory and cuts training costs by more than half compared to full fine-tuning.

The efficiency gains — lower token consumption, reduced GPU memory requirements, and faster inference — are intended to make complex multi-step agent workflows viable in production environments without the compute overhead that limits enterprise agentic deployments. The researchers have released the code and trained model weights under the Apache 2.0 license.

New VB Pulse data shows Microsoft and OpenAI leading enterprise agent orchestration, but Anthropic’s first measurable foothold points to a larger fight over who controls the infrastructure where AI agents run.

For the last two years, the enterprise AI race has mostly been framed as a model war: OpenAI’s GPT series versus Anthropic’s Claude versus Google’s Gemini, with smaller and open-source alternatives also coming in from the U.S. and China. 

But the next strategic fight may not be over which model answers a prompt best. It may be over who controls the layer where agents plan, call tools, access data, run workflows and prove to security teams that they did not do anything they were not supposed to do.

New VB Pulse survey data suggests the category is already taking shape. Our independent Enterprise Agentic Orchestration tracker, a survey that records the preferences of qualified, verified technical-decision maker respondents at enterprises at regular intervals, found that Microsoft Copilot Studio and Azure AI Studio led with 38.6% primary-platform adoption in February, up from 35.7% in January. 

OpenAI’s Assistants and Responses API held second place, rising from 23.2% to 25.7%. 

Anthropic remained far smaller, but it made its first appearance in the tracker: moving from 0% in January to 5.7% in February for Anthropic tool use and workflows. 

The underlying move is small — four respondents out of a total 70 in this cohort, with more to come — but strategically interesting because it marks the first sign in this tracker of Claude usage moving from the model layer into native orchestration.

That distinction matters. Enterprises are not merely choosing chatbots. They are deciding where the live operational machinery of AI work will sit: inside Microsoft’s stack, inside OpenAI’s API layer, inside Anthropic’s managed runtime, inside an open framework, or across a hybrid mix of all of them.

“This is the convergence moment for enterprise AI,” said Tom Findling, CEO and cofounder of AI cybsersecurity startup Conifers, in a statement to VentureBeat. “Models and agent frameworks have matured enough together that enterprises are now shifting focus beyond model quality to the control plane around it. In security operations, we’re seeing the competitive advantage move toward platforms that can orchestrate agents, leverage enterprise context, and provide governance and auditability across customer environments.”

The Anthropic number, by itself, should not be overread. A move from zero to 5.7% is not a juggernaut. It is not proof that Anthropic has captured enterprise orchestration. 

It is not even enough to say Anthropic has a durable lead in any part of this market. Microsoft owns the early enterprise distribution advantage, and OpenAI has a much larger installed base in orchestration than Anthropic.

But small numbers can matter when they appear at the start of a new market structure. Anthropic’s emergence in orchestration comes as the broader VB Pulse data shows Claude also gaining massive enterprise adoption at the model layer. 

In our VB Pulse Q1 Foundation Models and Intelligence Platforms tracker, Anthropic rose from 23.9% in January to 28.6% in February and then even more dramatically to 56.2% in March among qualified enterprise respondents, with the March reading flagged as directional only, because the sample was only 16 respondents.

The story, then, is not that Anthropic is winning orchestration today. It is that Anthropic’s model momentum may be starting to spill into the orchestration layer.

That is where the strategic stakes get higher.

A model is relatively easy to swap, at least in theory. A company can route one workload to Claude, another to GPT, another to Gemini and another to a smaller open model.

In fact, the VB Pulse Foundation Models tracker over the same Q1 period shows that multi-model strategy is the enterprise consensus: respondents increasingly report adopting multiple models and building orchestration layers that route across them by task, cost and risk profile.

An agent runtime is different. Once a company’s workflows, tool permissions, credentials, audit logs, memory, sandboxed execution and operational monitoring live inside one provider’s environment, switching providers becomes less like changing models and more like changing infrastructure.

Anthropic has already made clear that it wants to provide more than the model. Its Claude Managed Agents documentation describes a public beta for a managed agent harness with secure sandboxing, built-in tools and API-run sessions, while Anthropic’s engineering post frames the architecture around decoupling the model from the surrounding agent machinery: the session, the harness and the sandbox.

In plain English, Anthropic is trying to host the environment where Claude agents remember context, use tools, run code, operate inside sandboxes and persist across long-running workflows. That is no longer just inference. That is operational infrastructure.

The pitch is obvious: most enterprises do not want to stitch together their own agent stack from scratch. They want agents that can act, but they also want permission boundaries, audit trails, workflow reliability and ways to stop the system when something goes wrong.

The VB Pulse orchestration tracker shows that buyers are prioritizing exactly those concerns. Security and permissions ranked as the top orchestration platform selection criterion in both January and February, at 39.3% and 37.1%.

Control over agent execution rose from 17.9% to 22.9%, while flexibility across models and tools fell from 35.7% to 25.7%. The market appears to be shifting from optionality toward governance.

That shift is not surprising. A chatbot can be wrong and still remain mostly contained. An agent that can send emails, modify documents, query databases, call APIs or execute workflows has a much larger blast radius. The enterprise question is not only whether the agent is smart enough.

It is who gave it permission, what it touched, what it changed, whether those actions were logged, and whether the company can unwind the damage if something goes wrong.

Ev Kontsevoy, cofounder and CEO of Teleport, an identity and digital infrastructure solutions company, argues that the industry is still putting too much emphasis on orchestration itself and not enough on identity: “The race to own the agent orchestration layer is real,” Kontsevoy said. “It’s also solving the wrong problem first. Orchestration without identity only multiplies chaos. Without identity, you don’t know what an agent can access, what it actually did, or how to revoke its access when it operates outside policy. A unified identity layer is a prerequisite to deploying agents — one or many — in infrastructure.”

Syam Nair, Chief Product Officer at the intelligent data infrastructure company NetApp, believes data management is key in all cases to secure AI agent orchestration across the enterprise. As he said in a statement to VentureBeat: "Effective agent management requires built-in intelligence and a continuously updated understanding of both data and, critically, its metadata. This visibility allows organizations to define and enforce clear policies so data is used only by the right agents, for the right purposes. Making this work at scale is a crossfunctional effort. Security, storage, and data science teams must work together to implement policies that safeguard company data, while creating a strong data foundation for AI."

He continued: "The CIOs and technology leaders that are successful are the ones who take the input, policies, and vision from all these teams into account as they build a data infrastructure that minimizes risk and drives business value."

That is why Microsoft’s early lead makes sense. Copilot Studio and Azure AI Studio sit inside an enterprise stack many companies already use: Microsoft 365, Teams, Entra ID, Azure and existing procurement relationships.

The VB Pulse Orchestration Tracker for Q1 2026 describes Microsoft as the enterprise default, with no other platform within 13 percentage points in February.

David Weston, CVP, AI Security, Microsoft, provided some insight on why, writing in a statement to VentureBeat: "Without a unified control layer, you start to see fragmentation – agents operating in silos, inconsistent governance, and gaps in security. What customers are asking for is a way to bring order to that complexity. With Agent 365, we’re providing a single control plane to observe, govern, and secure agents across Microsoft, partner, and third-party ecosystems, all grounded in enterprise data and identity."

OpenAI’s second-place position is also unsurprising. Its Assistants and Responses API gave developers an early way to build agent-like systems using OpenAI’s models and tooling. In the orchestration tracker, OpenAI is not surging, but it is still ticking up steadily: 23.2% in January to 25.7% in February.

Anthropic is the newcomer at the orchestration layer. But its timing may be favorable. The VB Pulse Foundation Models tracker for Q1 2026 suggests enterprises increasingly see Claude as a fit for higher-stakes workloads where safety, instruction following, long context and governance matter.

The orchestration tracker suggests those same buyers are now moving from agent experiments toward production workflows, where security, permissions and task reliability become the gating issues.

That creates a possible path for Anthropic: not to beat Microsoft as the default enterprise platform, at least not immediately, but to become the agent runtime for companies that already trust Claude for sensitive or complex workloads.

The risk for enterprises is lock-in.

The orchestration tracker found that a hybrid control plane — combining provider-native orchestration with external orchestration — was the leading expected architecture, holding around 35% to 36% across the two substantive waves.

Provider-managed-only approaches grew modestly but remained a minority. The report’s conclusion is blunt: enterprises are not willing to give full orchestration control to any single provider.

It makes total sense as enterprises seek to leverage the "best-in-breed" models, harnesses, and tools from multiple vendors, especially as their needs differ widely across sector, business, and size.

"Most enterprises will operate in a multi-model, multi-agent environment, which makes an independent control plane essential," agreed Felix Van de Maele, CEO of Collibra, the self-described "leader in unified governance for data and AI," in a statement to VentureBeat. "That is why we built AI Command Center: to give organizations the visibility, governance, and real-time oversight needed to manage AI systems and agents across the full lifecycle."

That caution shows up in the risk data. When asked about risks if agent control lives inside a model provider platform, respondents cited security and permissioning limitations as the top concern. Vendor lock-in was the second-largest concern and the only one that increased from January to February, rising from 23.2% to 25.7%.

This is the tension at the heart of the agent market. Enterprises want managed infrastructure because building reliable agents is hard. But the more a provider manages, the more it may own.

Dr. Rania Khalaf, chief AI officer at WSO2 — the subsidiary of EQT that offers open source, customizable AI stacks for enterprises — said enterprises will need an agent control plane that sits apart from individual frameworks, harnesses and runtimes because agents combine the unpredictability of LLMs with the ability to take actions that have consequences.

“Teams want the freedom to use the best model and framework for each job — Claude for coding, Gemini for writing, LangGraph or CrewAI for dynamic modular behavior — and that heterogeneity makes consistent governance untenable in integrated platforms that lock into one ecosystem,” Khalaf said.

Khalaf said the industry is also moving from MLOps to LLMOps to “Agent Ops,” where governance has to cover the whole agent, not just the model call.

“A guardrail on an LLM call can catch hallucination or toxic output, but it will not catch an agent thrashing in an unbreakable, costly loop, which is why governance now has to extend out from the LLM interaction to the scope of the agent,” she said.

The practical implication is that enterprises need to separate policy and control from the agent logic itself. Khalaf pointed to the recent example of an agent deleting a production database despite being told not to, arguing that the failure showed the limits of relying on prompt-level instructions where hard identity and access controls are needed.

“Pulling guardrails, evals, policies, bindings, and agent identity out of the core agent logic allows them to be configured per deployment and per environment, owned by the appropriate teams in security, product, and compliance, without fragmenting the governance layer as different teams choose different models and frameworks,” Khalaf said.

That is where Anthropic’s Model Context Protocol, or MCP, complicates the story. MCP is not a walled garden; Anthropic introduced it as an open standard for connecting AI systems to data and tools, and Anthropic’s documentation describes MCP as an open-source standard for connecting AI applications to external systems.

But openness at the protocol layer does not automatically eliminate lock-in at the runtime layer. An enterprise could use an open protocol to connect tools while still becoming dependent on a provider’s managed sessions, logs, sandboxes, permissions model, workflow state and deployment environment. In other words, MCP may reduce integration friction, while managed agent infrastructure could still increase switching costs.

Khalaf said Microsoft’s lead likely reflects its M365 and Azure distribution, while Anthropic’s emerging foothold could reflect a different architectural bet around open protocols such as MCP. But she argued the long-term direction is not a single-provider stack.

“Enterprises serious about running agents in production will end up multi-vendor across these layers,” Khalaf said, “which is why the open and interoperable control plane matters more than the current percentages might suggest.”

That same tension — between provider-native convenience and cross-vendor reality — is where Arick Goomanovsky, CEO and cofounder of universal AI agent orchestrator startup BAND, sees the next competitive cycle forming.

“Enterprises now run agents everywhere: individual assistants and coding agents, multi-agent systems in production, agents embedded in Agentforce and ServiceNow, and third-party agents consumed as agent-as-a-service,” Goomanovsky said. “None of them collaborate across those boundaries by default.”

Goomanovsky argues that the missing layer is not just orchestration inside a single model provider, but a cross-vendor collaboration layer that lets agents from different ecosystems act together.

“What’s emerging in parallel is demand for an agentic collaboration harness - an interaction layer that lets agents from Microsoft, OpenAI, Anthropic, and internal teams operate as one workforce,” he said. “Orchestration inside any single vendor is still a walled garden so the next competitive cycle is cross-vendor agent collaboration.”

There is also a warning sign for independent orchestration frameworks. LangChain and LangGraph fell from 5.4% to 1.4% as the primary orchestration platform in the qualified enterprise sample.

External orchestration abstracted entirely from model providers also fell from 8.9% to 2.9%.

Scott Likens, Global Chief AI Engineer at professional services giant PwC, has a front row seat to this trend as the company spearheads and assists clients with their AI transformations.

As he told VentureBeat in a statement: "Right now, most enterprises are still operating in fragmented environments, with orchestration spread across platforms, business applications, and internally developed tooling. Over time, the market will likely move toward more unified orchestration models, but interoperability, governance and security will remain critical because enterprises are unlikely to standardize on a single agent ecosystem."

The report argues that fully independent orchestration frameworks may not yet have the enterprise packaging — security certifications, support, compliance documentation and vendor accountability — that procurement teams require.

That does not mean open frameworks are irrelevant. It does suggest that enterprise buyers may increasingly consume open or developer-first orchestration through managed products, cloud-provider partnerships or internal control planes rather than as standalone frameworks.

This is where the agent market starts to look less like the early chatbot market and more like enterprise cloud infrastructure. The winning vendors will not only have capable models. They will have identity integration, permission controls, audit logs, observability, workflow tooling, sandboxing, evaluation and a credible answer to who owns the control plane.

Indeed, the orchestration layer is but one part of the stack that the enterprise must fill in, and enterprises may actually decide to have different orchestration layers for agents working in different departments and functions.

As Nithya Lakshmanan, Chief Product Officer at revenue team AI orchestration startup Outreach.ai wrote in a statement to VentureBeat: "General-purpose orchestration platforms coordinate agent activity well, but they don't carry the workflow-specific context that determines whether an agent's action is correct for a given situation. In revenue workflows, an agent acting on incomplete deal history or missing buyer context will underperform and erode trust with users. The teams getting the most out of multi-agent systems are treating domain-specific data as the governance layer, with orchestration sitting on top. Most enterprises have chosen their orchestration stack, and what they're now figuring out is how those platforms get access to the workflow context they need to make agents useful inside specific business functions."

That is why Anthropic — which is increasingly launching its own domain-specific agents for finance and design, among other categories — is worth following closely. The company does not need to win the entire orchestration market tomorrow for its strategy to matter. It only needs to persuade a growing set of Claude enterprise customers to let Anthropic handle more of the surrounding machinery: tools, workflows, memory, execution and governance.

If it succeeds, Claude becomes more than a model in a multi-model portfolio. It becomes part of the infrastructure where enterprise work gets done.

That would put Anthropic in a more direct fight with OpenAI and Microsoft — not just over model quality, but over the operating layer of AI agents.

The safe interpretation of the VB Pulse data is narrow but important: Anthropic is not yet a major enterprise orchestration platform. Microsoft is. OpenAI is much closer. But Anthropic has registered its first measurable foothold at the orchestration layer, just as the market is deciding who should control agent execution.

For enterprise buyers, that may be the question that matters most in 2026. Not which model is best, but which provider gets to run the agent — and how hard it will be to leave once the agent is running.

Observability startup Raindrop AI’s new open source, MIT Licensed "Workshop" tool, launched today, gives developers something that they've likely wanted, perhaps subconsciously, since the agentic AI era kicked off in earnest last year: a local debugger and evaluation tool specifically designed for AI agents, allowing devs to see all the traces of what their agent has been doing in a single, lightweight Structured Query Language (SQL) database file (.db)

It functions as a local daemon and UI that streams every token, tool call, and decision to a local dashboard—typically hosted at localhost:5899—the moment it occurs. By visiting their localhost, developers can then see everything their agent was up to — including mistakes or errors — and identify what went wrong, when, and ideally, discern why. It's all stored in a single .db file, which takes up relatively little memory, according to a X direct message VentureBeat received from Ben Hylak, Raindrop's co-founder and CTO (and a former Apple and SpaceX engineer).

This real-time telemetry eliminates the latency of traditional polling and addresses a growing developer concern regarding the privacy of sending local traces to external servers.

The tool is available for macOS, Linux, and Windows. It can be installed through a one-line shell command that automates binary placement and PATH configuration for bash, zsh, and fish shells. For developers who prefer to build from source, the repository is hosted on GitHub and utilizes the Bun runtime.

The platform’s standout feature is the "self-healing eval loop," which allows coding agents like Claude Code to read traces, write evals against the codebase, and fix broken code autonomously.

In a practical application, if a veterinary assistant agent fails to ask necessary follow-up questions, Workshop captures the full trajectory. Claude Code then reads this trace, writes a specific eval, identifies the logic error in the prompt or code, and re-runs the agent until all assertions pass.

Workshop is compatible with a broad range of programming languages, including TypeScript, Python, Rust, and Go.

It integrates with popular SDKs and frameworks such as the Vercel AI SDK, OpenAI, Anthropic, LangChain, LlamaIndex, and CrewAI. It is also designed to work seamlessly with various coding agents, including Claude Code, Cursor, Devin, and OpenCode.

Workshop is released under the MIT License, ensuring it remains free and open-source for all users. This permissive licensing is intended to foster community contribution and allow enterprise users to maintain data sovereignty.

Hylak noted on X that the tool was built to provide a "sane" way to debug agents locally, changing how their team and early customers build autonomous systems.

To celebrate the launch, Raindrop offered limited-edition physical merchandise to users who installed the tool and executed a specific "drip" command.

Cerebras Systems, the Silicon Valley chipmaker that built the world's largest commercial AI processor, erupted onto the Nasdaq on Wednesday, opening at $350 per share — nearly double its $185 IPO price — and rocketing past a $100 billion market capitalization in its first hours of trading. The debut instantly crowned Cerebras as one of the most valuable semiconductor companies on Earth and validated a decade-long bet that the AI industry would eventually demand a fundamentally different kind of chip.

The company sold 30 million shares at $185 apiece, raising $5.55 billion in what Bloomberg reported as the largest U.S. tech IPO since Uber went public in 2019. The final pricing shattered expectations: Cerebras initially marketed shares at $115 to $125, then raised the range to $150 to $160 as investor demand surged, before ultimately pricing above even that elevated band.

"This is just a new beginning," Julie Choi, Senior Vice President and Chief Marketing Officer at Cerebras, told VentureBeat in an exclusive interview on the morning of the IPO. The company, she said, plans to pour its fresh capital into expanding the cloud infrastructure that has become the centerpiece of its growth strategy. "With this new capital, we're going to fill more data halls with Cerebras systems to power the world's fastest inference."

The IPO caps one of the most dramatic corporate turnarounds in recent tech history. Cerebras first filed to go public in September 2024 but withdrew the effort more than a year later amid intense scrutiny over its near-total revenue dependence on a single customer in the United Arab Emirates. The company refiled in April 2026 with a radically different business profile: new partnerships with OpenAI and Amazon Web Services, a fast-growing cloud inference service, and a revenue base that had climbed 76% to $510 million in 2025.

To understand the frenzy, you have to understand the silicon.

Cerebras builds something called the Wafer-Scale Engine, or WSE — a single processor that occupies an entire silicon wafer, the dinner-plate-sized disc from which ordinary chips are cut. The third-generation WSE-3 contains 4 trillion transistors, 900,000 compute cores, and 44 gigabytes of on-chip memory. It is 58 times larger than Nvidia's B200 "Blackwell" chip and delivers 2,625 times more memory bandwidth than the B200 package, according to the company's S-1 filing with the Securities and Exchange Commission.

That bandwidth advantage matters enormously for AI inference — the process of running a trained model to generate answers. When a large language model produces text, it predicts one token at a time, and each token requires the model's entire set of weights to move from memory to compute. This work is inherently sequential and cannot be parallelized, making memory bandwidth the binding constraint on speed. Cerebras claims its architecture delivers inference responses up to 15 times faster than leading GPU-based solutions on open-source models, a figure corroborated by third-party benchmarker Artificial Analysis.

"One of the architectural principles when we built the wafer was: let's keep compute closer together, so that compute elements can talk to each other at lower latency," Andy Hock, VP of Product at Cerebras, told VentureBeat. "Low latency is important to AI compute. It's a cornerstone of fast inference."

The founding insight was contrarian and, for most of the company's life, commercially premature. Cerebras's founders recognized in 2015 that AI workloads were communication-bound problems — speed depended on how fast data could move between memory and compute — and that the best way to accelerate that movement was to keep everything on a single massive chip. 

Wafer-scale integration had been attempted and abandoned repeatedly over the semiconductor industry's 75-year history. Every previous effort had failed. Cerebras solved the problem through two key innovations detailed in its S-1: a proprietary multi-die interconnect that stitches otherwise independent die together at the wafer level during fabrication, and a fault-tolerant architecture that routes around manufacturing defects using redundant building blocks, similar to how hyperscale data centers handle server failures.

For most of its life, Cerebras sold hardware — massive, water-cooled AI supercomputers installed on-premises at customer facilities. That model generated $358 million in hardware revenue in 2025. But the IPO prospectus reveals a strategic pivot that will define the company's next chapter: the transition to cloud-based inference services.

Cerebras launched its inference cloud in August 2024. In less than two years, cloud and other services revenue reached $151.6 million in 2025, up 94% from $78.3 million in 2024. The company now expects this segment to comprise a significantly larger percentage of total revenue going forward, driven primarily by its enormous deal with OpenAI.

"Cloud and model APIs are the preferred and natural consumption method for inference services and application developers," Hock told VentureBeat. "So that was the natural packaging and go-to-market strategy for the inference capability."

Choi framed the cloud as a democratization play. "Whether that be an entrepreneurial developer, a startup, or a massive organization like OpenAI — the cloud has really made it easy for people to deploy and feel the fast inference, the value of it," she said.

The economics of the transition are capital-intensive. Cerebras must lease data center space, manufacture and deploy its systems, and build software to manage capacity — all before recognizing recurring revenue. The S-1 warns bluntly that gross margins will decline in the near term as the company absorbs startup costs for cloud infrastructure. The company's gross margin already dipped to 39% in 2025 from 42.3% in 2024, driven by higher data center costs. But the demand picture appears formidable. "Every cloud system that we've deployed so far, each one gets gobbled up in capacity," Hock said. "We've been thrilled to see the demand for fast inference from Cerebras. We want to go faster to service that market."

The single most consequential business relationship for Cerebras is its December 2025 agreement with OpenAI, under which OpenAI committed to purchase 750 megawatts of Cerebras inference compute capacity over the next several years. The deal is valued at more than $20 billion and includes provisions for OpenAI to purchase an additional 1.25 gigawatts of capacity, potentially bringing total deployment to 2 gigawatts.

The arrangement goes far beyond a standard vendor-customer relationship. OpenAI and Cerebras are co-designing future models for future Cerebras hardware — a tight feedback loop that gives Cerebras visibility into frontier model architectures before they ship and gives OpenAI inference systems optimized for its specific workloads. The partnership moved from contract to production with remarkable speed. "After we announced the partnership, we had the first model running in like 35 days," Choi told VentureBeat. "That was Codex Spark, and the engineers over at OpenAI just were like, mind blown."

Codex Spark, OpenAI's model designed for real-time coding, allows developers to turn natural-language instructions into working software in seconds using Cerebras infrastructure. Choi described a deep cultural alignment between the two companies. "Our teams truly vibe as engineers. We're on the same wavelength," she said. "There's just no amount of speed that is enough for those guys."

To fund the infrastructure buildout, OpenAI advanced Cerebras a $1 billion working capital loan in January 2026, secured by a promissory note maturing no later than December 31, 2032, bearing 6% annual interest. The loan can be repaid in cash or through delivery of compute capacity. However, the S-1 discloses significant risk: if the MRA is terminated for any reason other than OpenAI's material uncured breach, OpenAI can seize control of the loan funds and demand immediate repayment. OpenAI also holds a warrant to purchase up to 33.4 million shares of Cerebras Class N common stock at an exercise price of $0.00001 per share — essentially free shares that vest as Cerebras delivers committed capacity. At the IPO opening price, the fully vested warrant would be worth approximately $11.7 billion.

In March 2026, Cerebras signed a binding term sheet with Amazon Web Services to become the first hyperscaler to deploy Cerebras systems inside its own data centers. The partnership introduces a novel architectural concept called disaggregated inference, which splits the two stages of AI inference — prefill (processing the user's prompt) and decode (generating the response) — across different hardware optimized for each task. Under this arrangement, AWS Trainium chips handle prefill, while Cerebras CS-3 systems handle decode, connected via Amazon's Elastic Fabric Adapter networking.

According to the AWS press announcement in March, the approach aims to deliver an order of magnitude faster inference than what is currently available. Hock provided technical detail on why this works. "The interconnect requirements between prefill and decode systems actually aren't that high, so we can use a traditional interconnect between, say, Trainium and the wafer-scale engine and still deliver that fast time to first token and that ultra-low latency token generation," he explained. "What the Trainium wafer-scale engine combination really gives us in that disaggregated or heterogeneous inference setup is all the speed and vastly more efficiency, so we can effectively serve more tokens per unit rack space or kilowatt."

The partnership provides Cerebras something it has long lacked: massive distribution. AWS serves millions of enterprise customers worldwide, and Cerebras systems deployed through Amazon Bedrock will become accessible to any developer within their existing AWS environment. "AWS has incredible reach," Hock said. "The partnership is really about bringing that fast inference capability — that sort of best-in-industry, fast inference capability delivered by wafer-scale engine and Trainium — to that broader market." The term sheet also grants AWS a warrant to purchase up to approximately 2.7 million shares of Cerebras Class N common stock at a $100 exercise price, with vesting tied to product purchases beyond the initial lease.

For all the excitement, Cerebras carries a risk that has haunted it since its first IPO attempt: customer concentration. In 2024, G42 — an Abu Dhabi–based technology conglomerate — accounted for 85% of Cerebras's total revenue. The company's September 2024 S-1 filing drew heavy scrutiny over this dependence, compounded by questions about export controls for advanced AI chips shipped to the UAE. Cerebras withdrew that filing.

The 2025 numbers show progress but not resolution. G42's share of revenue declined to 24%, but Mohamed bin Zayed University of Artificial Intelligence (MBZUAI), an Abu Dhabi institution that is a related party to G42, accounted for 62% of total revenue. 

Together, the two UAE-linked entities still represented 86% of Cerebras's 2025 sales. The S-1 is candid about this risk, noting that MBZUAI accounted for 77.9% of accounts receivable as of December 31, 2025, and that U.S. export licenses for Cerebras systems shipped to G42 and MBZUAI require "rigorous security and compliance obligations to prevent diversion and abuse of our technology."

Choi addressed the issue directly, pointing to the OpenAI and AWS deals as evidence of a broadening customer base. "Now with OpenAI and Amazon, those are the same type of deep partnerships," she told VentureBeat. "We're a deep technology company. Our technology has taken a decade to build. We go deep in how we build, and now we're going deep with two of the biggest players — the biggest AI lab, OpenAI, and the biggest cloud, AWS."

Hock framed the customer evolution as a progression in market perception. "G42 caused the market to be intrigued and inspired," he said. "Nobody in the business is smarter, more credible, or has greater reach than OpenAI and AWS. And so I think OpenAI and AWS caused the market to shift from intrigued and inspired to — I'll call it curious and convinced." Still, the S-1 warns that the OpenAI MRA itself "represents a substantial portion of our projected revenues over the next several years." Cerebras's business will remain dependent on a small number of very large customers for the foreseeable future — a structural feature of the AI infrastructure market where buildouts are measured in hundreds of megawatts and billions of dollars.

With OpenAI consuming 750 megawatts of committed capacity and AWS preparing to deploy Cerebras systems in its data centers, the question is whether Cerebras can scale its physical infrastructure quickly enough to serve everyone else. Hock acknowledged the tension. "It's a good problem to have when demand starts to outstrip supply. It doesn't mean it's an easy problem to address," he told VentureBeat. "We've got to build these extraordinary systems. We've got to procure data center space. We've got to deploy systems there. Got to stand up software to meet our customers where they are."

The company is being deliberate about capacity allocation. "We're trying to be really deliberate about how we allocate capacity as it's built," Hock said. "We're working in deep partnership to service the highest-priority customers and highest-priority markets." 

Choi argued that the constraint actually sharpens focus. "Sometimes when you have less of something, it forces you to be very deliberate," she said. Beyond OpenAI, she named Cognition — the AI coding startup — and Block, led by Jack Dorsey, as significant customers. "Jack participated in our roadshow as well," Choi noted. "We're speeding up that entire money-bot AI experience within Cash App."

The S-1 discloses that Cerebras currently operates data centers in California, Oklahoma, and Canada, with plans to expand internationally. The company executed non-cancelable data center leases in late 2025 with aggregate undiscounted future minimum payments of approximately $344 million, and in March 2026 signed a Canadian data center lease with expected minimum payments of approximately $2.2 billion over a 10-year term.

The IPO proceeds — combined with $1 billion from a January 2026 Series H preferred stock round and the $1 billion OpenAI loan — give Cerebras a war chest exceeding $8 billion to fund the buildout. Whether that is enough to satisfy a market where major customers are ordering capacity measured in gigawatts remains an open question.

Cerebras enters public markets into the teeth of the most competitive semiconductor environment in decades. Nvidia remains the dominant force in AI compute, controlling the vast majority of the training and inference infrastructure market. Its GPU architecture benefits from a deeply entrenched software ecosystem built around CUDA, the programming framework that has become the de facto standard for AI development. Cerebras's S-1 explicitly acknowledges this, noting that "many of our competitors benefit from competitive advantages over us, such as prominent and cutting-edge technology and software stacks designed to keep out new market entrants."

But Cerebras argues the inference market is structurally different from training — and that its architecture has a fundamental advantage in the workload that matters most going forward. As AI models have shifted toward reasoning, where models perform multi-step computation during inference to think through problems, the number of tokens generated per request has exploded. Each token requires moving full model weights from memory to compute, making memory bandwidth the bottleneck. The S-1 cites Bloomberg Intelligence data projecting that Cerebras's addressable portion of the AI inference market will grow from approximately $66 billion in 2025 to $292 billion by 2029, a 45% compound annual growth rate — significantly outpacing the 20% CAGR projected for AI training infrastructure.

Nvidia has clearly taken notice of the fast-inference threat. In December 2025, Nvidia acquired Groq — a startup whose tensor streaming processor architecture more closely resembles Cerebras's approach — for $20 billion. 

Months later, Nvidia announced plans for Groq-based products, signaling that even the industry's dominant player recognizes the limitations of GPU architecture for latency-sensitive inference. Cerebras also competes with custom silicon developed by hyperscalers — including Google's TPUs and Amazon's Trainium chips — and a growing roster of AI cloud providers. Asked about Nvidia and Groq, Choi declined to engage. "We're feeling pretty good right now," she told VentureBeat with a smile.

The financial picture that emerges from the S-1 is one of rapid scaling with significant underlying complexity. Revenue surged from $78.7 million in 2023 to $290.3 million in 2024 to $510 million in 2025 — a more than tenfold increase over three years. The company reported GAAP net income of $237.8 million in 2025, but this figure is heavily influenced by a $363.3 million one-time gain from the extinguishment of a forward contract liability related to a preferred stock arrangement. Stripping out that gain and stock-based compensation, Cerebras's non-GAAP net loss was $75.7 million in 2025, widening from a $21.8 million non-GAAP loss in 2024.

Operating losses deepened as well. Cerebras lost $145.9 million from operations in 2025, up from $101.4 million the prior year, as the company invested heavily in research and development ($243.3 million, up 54%) and sales and marketing ($70.6 million, up 237%).

The company burned $10 million in operating cash flow in 2025, a sharp reversal from the $452 million of cash generated in 2024 — a year boosted by $640 million in customer deposit inflows, primarily from G42 and MBZUAI. The S-1 warns that gross margins will face near-term pressure from startup costs for cloud infrastructure, customer warrant amortization, and pass-through data center expenses.

The path to this moment was anything but smooth. Cerebras shipped its first systems in 2020 and 2021 — before the market was ready. As the founders wrote in the prospectus: the company "had built something extraordinary, but the market wasn't ready." The ChatGPT moment in late 2022 changed everything.

By early 2025, Cerebras's speed advantage — long a solution in search of a problem — became urgently relevant as AI coding agents, deep research tools, and real-time voice applications demanded the kind of low-latency inference that GPU clusters struggled to deliver. The S-1 describes a market where AI coding agents "barely existed in 2023" but collectively generated "billions in ARR in 2025," and where 42% of professional code is now AI-generated or assisted.

Looking forward, Hock signaled that the current generation of hardware is just the beginning. "Wafer-scale engine three and CS-3 is not the end of the story. It's just the beginning," he told VentureBeat. "We have a multi-year technology roadmap that continues building on wafer-scale technology, accelerating performance, increasing efficiency, supporting larger scale." 

The S-1 confirms that Cerebras intends to expand on-chip memory and bandwidth, improve interconnect density, and leverage future process node advances — and discloses that the company has already obtained export licenses for future CS-4 systems destined for the UAE.

The company also faces a web of operational risks that would test any organization, let alone one that has never operated as a public company. It depends entirely on TSMC for wafer fabrication, with no long-term supply commitment. Its data center leases stretch for years, while its inference customer contracts are often shorter-term or consumption-based, creating a mismatch between fixed costs and variable revenue. It has identified material weaknesses in its internal controls over financial reporting. And its most important customer relationship — with OpenAI — includes exclusivity provisions that restrict Cerebras from working with certain named OpenAI competitors, potentially limiting future diversification.

Whether Cerebras can sustain a $100 billion-plus valuation will depend on its ability to execute against all of these challenges simultaneously: building data centers at unprecedented speed, manufacturing wafer-scale chips at scale through a single foundry, navigating export controls on its most lucrative international relationships, and competing against an Nvidia that has shown it will not cede the inference market without a fight.

But Cerebras has always been built on a willingness to attempt what others said was impossible. Wafer-scale integration had stumped the semiconductor industry for its entire existence. Now a chip the size of a dinner plate — once dismissed as an engineering curiosity — powers the fastest AI inference on the planet, serves the world's leading AI lab, and just debuted on the Nasdaq to a valuation that dwarfs companies many times its age. The world, it turns out, was ready. As Hock put it to VentureBeat, recalling the journey from the lab to the trading floor: "The IPO isn't the end of the story. It's the beginning."

Anthony Grieco, Cisco’s SVP and chief security and trust officer, did not hesitate when VentureBeat asked whether rogue agent incidents are reaching Cisco’s customer base.

"A hundred percent. We see them regularly," Grieco told VentureBeat in an exclusive interview at RSAC 2026. "I've heard some that I can't repeat, but they do get to the places of, you know, agents are doing things that they think are the right things to do."

The incidents Grieco described follow a consistent pattern: authentication passes, identity checks clear. The agent is exactly who it claims to be. Then it accesses data it was never scoped to touch or takes an action nobody authorized at that level of granularity. The failure is not identity; it's authorization.

"The business is saying things like, we're gonna have 500 agents per employee," Grieco told VentureBeat. "The security leaders are really focused on how to make sure that we do that securely."

Cisco’s State of AI Security 2026 report found that 83% of organizations planned to deploy agentic capabilities, but only 29% felt prepared to secure them. Five vendors shipped agent identity frameworks at RSAC 2026. None closed every gap. That includes Cisco.

VentureBeat mapped four authorization gaps across Grieco’s exclusive interview and five independent sources. The prescriptive matrix at the end of this story is what to do about them.

Grieco came up through Cisco's engineering and threat research organizations before taking a role that straddles both sides of the company's security operation: building the products Cisco sells and running the program that defends Cisco itself.

The authorization gap he described is specific and operational.

"This agent here is a finance agent, but even if it's a finance agent, it shouldn't access all finance data," Grieco told VentureBeat. "It should access the expense reports, and not just expense reports, but the individual expense reports at a particular time. Getting that sort of granular control is really one of the biggest things that are gonna help us say yes to a lot of the agentic developments."

Independent practitioners confirmed the pattern across RSAC 2026. Kayne McGladrey, an IEEE senior member, told VentureBeat that organizations default to cloning human user profiles for agents, and permission sprawl starts on day one. Carter Rees, VP of AI at Reputation, identified the structural reason. The flat authorization plane of an LLM fails to respect user permissions, Rees told VentureBeat. An agent on that flat plane does not need to escalate privileges. It already has them.

"The biggest challenge that we see is knowing what's going on," Grieco said. "Being able to have identity and access control maps to those, that's really crucial."

Elia Zaitsev, CTO of CrowdStrike, described the visibility dimension in an exclusive VentureBeat interview at RSAC 2026. In most default logging configurations, an agent’s activity is indistinguishable from a human’s. Distinguishing the two requires walking the process tree. Most enterprise logging cannot make that distinction.

Five vendors shipped agent identity frameworks at RSAC, including Cisco's Duo IAM and MCP gateway controls. None closed every gap VentureBeat identified. The four gaps below are what remains open.

The authorization and identity gaps Grieco described are not just vendor observations. Three independent standards bodies reached parallel conclusions in early 2026. NIST’s NCCoE published a concept paper in February 2026, "Accelerating the Adoption of Software and AI Agent Identity and Authorization," explicitly calling for demonstration projects on how existing identity standards apply to autonomous agents.

The OWASP Top 10 for Agentic Applications, released in December 2025, identified tool misuse from over-privileged access and unsafe delegation as top-tier risks. And the Cloud Security Alliance launched the CSAI Foundation at RSAC 2026 with a mission of "Securing the Agentic Control Plane," including a dedicated Agentic AI IAM framework built around decentralized identifiers and zero trust principles. When NIST, OWASP, and CSA all independently flag the same gap class in the same market cycle, the signal is structural, not vendor-specific.

VentureBeat asked Grieco about the paradox of MCP, the Model Context Protocol that every vendor at RSAC 2026 embraced while acknowledging its security gaps. Grieco did not argue that the protocol is safe. He argued that blocking it is no longer realistic.

"There is no saying no to that in today's day and age as a security leader," Grieco told VentureBeat. "And so it's how do we manage that."

Inside Cisco’s own environment, Grieco’s team added MCP discovery, proxying, and inspection capabilities to AI Defense and Cisco Secure Access. The approach treats MCP servers the way enterprises treat shadow IT: find them before you govern them.

Etay Maor, VP of threat intelligence at Cato Networks, validated that approach from the adversarial side. At RSAC 2026, Maor demonstrated a Living Off the AI attack chaining Atlassian's MCP and Jira Service Management. Attackers do not separate trusted tools, services, and models. They chain all three. "We need an HR view of agents," Maor told VentureBeat. "Onboarding, monitoring, offboarding."

Agent authorization failures are harder to detect and contain when the infrastructure underneath has not received a security patch in years — and that gap compounds every other vulnerability in this story. Cisco commissioned UK-based advisory firm WPI Strategy to examine end-of-life technology risk across the US, UK, France, Germany, and Japan. The report found that nearly half of the critical network infrastructure across those geographies is aging or already obsolete. Vendors no longer patch it.

"Almost 50% of the critical infrastructure across these geographies was aging, it was end of life or almost end of life," Grieco told VentureBeat. "It means vendors are not providing security patches for them anymore."

Cisco’s Resilient Infrastructure initiative disables unused features by default and phases out legacy protocols on a three-release deprecation schedule. Grieco pushed back on the assumption that secure by default is a static achievement. "One of the things that most people don't think about is that those are not static points in time," Grieco told VentureBeat. "It's not like you do it once and you're done."

The four gaps below are what security directors can act on Monday morning. Each row maps from what breaks to why it breaks to what to do about it, cross-validated by five independent sources.

Sources: VentureBeat analysis of Grieco's exclusive interview at RSAC 2026, cross-validated against independent reporting from McGladrey (IEEE), Rees (Reputation), Maor (Cato Networks), and Zaitsev (CrowdStrike). May 2026.

Security Gap

| What fails and what it costs

Why your current stack doesn't catch it

Where vendor controls stand now

First action for your team

Infrastructure aging

Nearly half of critical network assets are end of life or approaching it (WPI Strategy); agents operating on unpatched systems inherit vulnerabilities no vendor will fix

Annual patching cadence cannot keep pace with threat velocity; EoL systems receive zero security updates and zero vendor support

Resilient Infrastructure disables insecure defaults, warns on risky configurations, deprecates legacy protocols on a three-release schedule

Infra team: audit every network asset against vendor EoL dates this quarter. Reclassify EoL replacement from IT upgrade to security investment in next budget cycle

MCP discovery

MCP servers proliferate across environments without security visibility; developers spin up agent tool connections that bypass existing governance

Shadow MCP deployments bypass existing discovery tools; no standard inventory mechanism exists; Maor demonstrated attackers chaining MCP + Jira in a Living Off the AI attack

AI Defense adds MCP discovery, proxying, and inspection; treats MCP servers like shadow IT

Security ops: run an MCP server inventory across all environments before deploying any agent governance controls. If you cannot enumerate your MCP surface, you cannot secure it

Agent over-permissioning

Agents inherit broad human-level access on a flat authorization plane; the agent does not need to escalate privileges because it already has them (Rees)

IAM teams clone human profiles for agents by default (McGladrey); no scoped, time-bound permissions exist for non-human identities

Duo IAM registers agents as distinct identity objects with granular, time-bound permissions per tool call

IAM team: stop cloning human accounts for agents immediately. Scope every agent permission to a specific data set, specific action, and specific time window. Grieco's test: can this finance agent access only the individual expense report it needs at this moment?

Agent behavioral visibility

Agent actions are indistinguishable from human actions in security logs (Zaitsev); an over-permissioned agent that looks like a human in logs is invisible to the SOC

Default logging does not capture process tree lineage; no vendor has shipped a complete cross-platform behavioral baseline for agent activity

SOC telemetry integration with Splunk for agent-specific detection and response

SOC lead: update logging to capture process tree lineage so agent-initiated actions are distinguishable from human-initiated actions. If your SIEM cannot answer "was this a human or an agent?" for every session, the gap is open

"Frankly, we must move this quickly and evolve this quickly to keep up with where the adversaries are gonna go," Grieco told VentureBeat.

The gaps mapped above are not theoretical. Grieco confirmed the incidents are already happening. The controls exist in pieces across multiple vendors. No single vendor has assembled the complete stack.

A code migration agent finishes its run, and the pipeline looks green. But several pieces were never compiled — and it took days to catch. That's not a model failure; that's an agent deciding it was done before it actually was.

Many enterprises are now seeing that production AI agent pipelines fail not because of the models’ abilities but because the model behind the agent decides to stop. Several methods to prevent premature task exits are now available from LangChain, Google and OpenAI, though these often rely on separate evaluation systems. The newest method comes from Anthropic: /goals on Claude Code, which formally separates task execution and task evaluation.

Coding agents work in a loop: they read files, run commands, edit code and then check whether the task is done. 

Claude Code /goals essentially adds a second layer to that loop. After a user defines a goal, Claude will continue to turn by turn, but an evaluator model comes in after every step to review and decide if the goal has been achieved. 

Orchestration platforms from all three vendors identified the same roadblock. But the way they approach these is different. OpenAI leaves the loop alone and lets the model decide when it’s done, but does let users tag on their own evaluators. For LangGraph and Google’s Agent Development Kit, independent evaluation is possible, but requires developers to define the critic node, write up the termination logic and configure observability. 

Claude Code /goals sets the independent evaluator's default, whether the user wants it to run longer or shorter. Basically, the developer sets the goal completion condition via a prompt. For example, /goal all tests in test/auth pass, and the lint step is clean. Claude Code then runs, and every time the agent attempts to end its work, the evaluation model, which is Haiku by default, will check against the condition loop. If the condition is not met, the agent keeps running. If the condition is met, then it logs the achieved condition to the agent conversation transcript and clears the goal. There are only two decisions the evaluator makes, which is why the smaller Haiku model works well, whether it's done or not. 

Claude Code makes this possible by separating the model that attempts to complete a task from the evaluator model that ensures the task is actually completed. This prevents the agent from mixing up what it's already accomplished with what still needs to be done. With this method, Anthropic noted there’s no need for a third-party observability platform — though enterprises are free to continue using one alongside Claude Code — no need for a custom log, and less reliance on post-mortem reconstruction.

Competitors like Google ADK support similar evaluation patterns. Google ADK deploys a LoopAgent, but developers have to architect that logic.

In its documentation, Anthropic said the most successful conditions usually have: 

• One measurable end state: a test result, a build exit code, a file count, an empty queue

• A stated check: how Claude should prove it, such as “npm test exits 0” or “git status is clean.”

• Constraints that matter: anything that must not change on the way there, such as “no other test file is modified”

For enterprises already managing sprawling tool stacks, the appeal is a native evaluator that doesn't add another system to maintain.

This is part of a broader trend in the agentic space, especially as the possibility of stateful, long-running and self-learning agents becomes more of a reality. Evaluator models, verification systems and other independent adjudication systems are starting to show up in reasoning systems and, in some cases, in coding agents like Devin or SWE-agent. 

Sean Brownell, solutions director at Sprinklr, told VentureBeat in an email that there is interest in this kind of loop, where the task and judge are separate, but he feels there is nothing unique about Anthropic's approach.

"Yes, the loop works. Separating the builder from the judge is sound design because, fundamentally, you can't trust a model to judge its own homework. The model doing the work is the worst judge of whether it's done," Brownell said. "That being said, Anthropic isn't first to market. The most interesting story here is that two of the world’s biggest AI labs shipped the same command just days apart, but each of them reached entirely different conclusions about who gets to declare 'done.'"

Brownell said the loop works best "for deterministic work with a verifiable end-state like migrations, fixing broken test suites, clearing a backlog," but for more nuanced tasks or those needing design judgment, a human making that decision is far more important.

Bringing that evaluator/task split to the agent-loop level shows that companies like Anthropic are pushing agents and orchestration further toward a more auditable, observable system.

Every query an enterprise AI application processes, every correction a subject matter expert makes to its output — that interaction is training data. Most organizations are not capturing it. The production workflows companies have already built are generating a continuous signal that improves AI models, and it is disappearing.

San Francisco-based Empromptu AI on Thursday launched Alchemy Models with a straightforward premise: the AI applications enterprises are already building are generating training data, and most of it is going to waste. The platform captures that signal automatically, routing validated outputs from subject matter experts back into a fine-tuning pipeline that improves the model over time. Enterprises own the resulting weights outright.

It sits in different territory from both RAG and traditional fine-tuning. RAG retrieves external context at inference time without modifying model weights. Traditional fine-tuning changes weights but requires separately assembled labeled datasets and a dedicated ML pipeline. Alchemy does the latter continuously, using the enterprise application itself as the data source.

Companies adopting foundation model APIs face three compounding constraints: inference costs that scale with usage, no ownership of the models their data is effectively training, and limited ability to customize behavior for domain-specific tasks. Empromptu CEO Shanea Leven says those constraints are widely felt but rarely addressed.

"Every customer, everybody that I talk to, is like, how am I not going to get disrupted? How am I going to protect my business? And they just don't see the path," Leven told VentureBeat in an exclusive interview.

Most custom model training approaches require companies to separately collect, clean and label data before any fine-tuning can begin. Alchemy takes a different path: the enterprise application itself generates and cleans the training data.

The mechanism runs through Empromptu's Golden Data Pipelines infrastructure in two stages. Before an app is built, enterprise data is cleaned, extracted and enriched so the application starts with structured inputs. Once it is running, every output it generates goes back through the pipeline, where subject matter experts inside the organization review and correct it. That validated output becomes the training data for the next fine-tuning run.

"The app, the AI application that customers are already creating, cleans the data," Leven said.

The resulting fine-tuned models are what Empromptu calls Expert Nano Models: small, task-specific models optimized for a particular workflow rather than general-purpose reasoning. Evals, guardrails and compliance controls run within the same pipeline, so governance travels with the training process. Customers own the model weights outright. Empromptu hosts and runs inference on its infrastructure, but the weights are portable and exportable for a fee. The platform is model agnostic, supporting Llama, Qwen and other base models.

The hard constraint is data volume. Early deployments run on the base model while the application accumulates enough production data to trigger a useful fine-tuning run. Leven acknowledged the timeline without sugarcoating it. "Training the model will just take time," she said.

OpenAI's fine-tuning API and AWS Bedrock custom models both offer enterprise fine-tuning. Both require organizations to bring separately prepared training datasets and manage the fine-tuning process outside their application stack. The burden of data curation and model evaluation sits with the customer's ML team.

Alchemy's differentiation is process integration. The training data is generated by the enterprise application itself, so there is no separate data preparation step and no ML expertise required. The application workflow is the pipeline.

"Do I need to have Bedrock and go spin up another ML team to go figure out how to fine tune a model and figure out all of that infrastructure? No, anyone can do it now," Leven said.

The tradeoff is platform dependency. Alchemy only works within the Empromptu environment. Enterprises that want the same outcome on existing infrastructure would need to replicate the data capture, validation and fine-tuning pipeline themselves.

Empromptu is targeting regulated and data-intensive verticals first: healthcare, financial services, legal technology, retail and revenue forecasting. These are sectors where general-purpose model outputs carry the highest mismatch risk and proprietary workflow data is most concentrated. 

Among the early users is behavioral health company Ascent Autism, which uses Alchemy to automate session documentation and parent communication. 

Facilitators use learner session recordings, transcripts, session notes and behavioral metrics to generate structured notes and personalized parent updates. That workflow previously required one to two hours of writing per session. With Alchemy training on the same data, it now takes 10 to 15 minutes.

"Relying solely on API-based models can become expensive quickly," Faraz Fadavi, co-founder and CTO of Ascent Autism, told VentureBeat. "Alchemy gave us a way to structure the workflow, train models on our own data, and reduce costs while improving output quality over time."

Fadavi said the company saw usable outputs quickly, with continued improvement as the system refined. Evaluation criteria went beyond accuracy to include traceability to session data and output consistency with the company's clinical voice. "We wanted a system that could learn our workflow and produce outputs aligned with how we actually operate — not just summarize text," he said. The practical test: how much facilitators need to edit, whether the output matches their voice and whether it meaningfully reduces time spent. Facilitators have shifted from rewriting generated notes to editing and quality-checking them.

The data flywheel is real — but so is the platform lock-in:

Every workflow is a training opportunity. Enterprises that capture and validate outputs from their production AI applications will compound that advantage over time. More usage generates more training signals, which produces more accurate domain-specific models, which generate better outputs, which produce cleaner training data in the next cycle.

Leven positions Alchemy as a third architectural choice. Enterprises have spent the past two years choosing between RAG for domain knowledge access and fine-tuning for model specialization. Workflow-driven model training is a third option, combining the ongoing improvement of fine-tuning with the operational simplicity of building inside a managed platform.

"Having that data moat is the most valuable currency," Leven said.

For decades, the IQ test has been one of the most familiar — and most contested — yardsticks for human intelligence. Now, a startup project called AI IQ is applying the same metaphor to artificial intelligence, assigning estimated intelligence quotients to more than 50 of the world's most powerful language models and plotting them on a standard bell curve.

The result is a set of interactive visualizations at aiiq.org that have ricocheted across social media in the past week, drawing praise from enterprise technologists who say the charts make an impossibly complex market legible — and sharp criticism from researchers and commentators who warn the entire framework is misleading.

"This is super useful," wrote Thibaut Mélen, a technology commentator, on X. "Much easier to understand model progress when it's mapped like this instead of another giant leaderboard table."

Brian Vellmure, a business strategist, offered a similar endorsement: "This is helpful. Anecdotally tracks with personal experience."

But the backlash arrived just as quickly. "It's nonsense. AI is far too jagged. The map is not the territory," posted AI Deeply, an artificial intelligence commentary account, crystallizing a worry shared by many researchers: that reducing a language model's sprawling, uneven capabilities to a single number creates a dangerous illusion of precision.

AI IQ was created by Ryan Shea, an engineer, entrepreneur, and angel investor best known as a co-founder of the blockchain platform Stacks. Shea also co-founded Voterbase and has invested in the early stages of several unicorns, including OpenSea, Lattice, Anchorage, and Mercury. He holds a Bachelor of Science in Mechanical Engineering from Princeton University.

The site's methodology rests on a deceptively simple formula. AI IQ groups 12 benchmarks into four reasoning dimensions: abstract, mathematical, programmatic, and academic. The composite IQ is a straight average of those four dimension scores: IQ = ¼ (IQ_Abstract + IQ_Math + IQ_Prog + IQ_Acad).

The abstract reasoning dimension draws from ARC-AGI-1 and ARC-AGI-2, the notoriously difficult pattern-recognition benchmarks designed to test general fluid intelligence. Mathematical reasoning includes FrontierMath (Tiers 1–3 and Tier 4), AIME, and ProofBench. Programmatic reasoning uses Terminal-Bench 2.0, SWE-Bench Verified, and SciCode. Academic reasoning pulls from Humanity's Last Exam, CritPt, and GPQA Diamond.

Each raw benchmark score gets mapped to an implied IQ through what the site describes as "hand-calibrated difficulty curves." Crucially, the methodology compresses ceilings for benchmarks considered easier or more susceptible to data contamination, preventing them from inflating scores above 100. Harder, less gameable benchmarks retain higher ceilings. The system also handles missing data conservatively: models need scores on at least two of the four dimensions to receive a derived IQ, and when benchmarks are absent, the pipeline deliberately pulls scores down rather than up. The site states that "every derived IQ averages all four dimensions, so missing coverage cannot make a model look better by omission."

As of mid-May 2026, the AI IQ charts tell a story of rapid convergence at the top of the frontier — and widening diversity in the tiers below.

According to the Frontier IQ Over Time chart, GPT-5.5 from OpenAI currently sits at the peak of the bell curve, with an estimated IQ near 136 — the highest of any model tracked. It is closely followed by GPT-5.4 (approximately 131), Opus 4.7 from Anthropic (approximately 132), and Opus 4.6 (approximately 129). Google's Gemini 3.1 Pro lands near 131, making the top cluster extraordinarily tight.

That compression is not unique to AI IQ's framework. Visual Capitalist, drawing from a separate Mensa-based ranking by TrackingAI, recently observed the same dynamic, noting that "the biggest takeaway is how compressed the top of the leaderboard has become." On that scale, Grok-4.20 Expert Mode and GPT 5.4 Pro tied at 145, with Gemini 3.1 Pro at 141.

Below the frontier cluster, the AI IQ charts show a crowded midfield. Models from Chinese labs — Kimi K2.6, GLM-5, DeepSeek-V3.2, Qwen3.6, MiniMax-M2.7 — bunch between roughly 112 and 118, making the cost-performance tier increasingly competitive for enterprise buyers who don't need the absolute best model for every task. One X user, ovsky, noted that the data "confirms experience with sonnet 4.6 being an absolute workhorse as opposed to opus 4.5" — pointing to the way the charts can validate practitioner intuitions that headline rankings often miss.

What distinguishes AI IQ from most other benchmarking efforts is its inclusion of an "EQ" — emotional intelligence — score. The site maps each model's EQ-Bench 3 Elo score and Arena Elo score to an estimated EQ using calibrated piecewise-linear scales, then takes a 50/50 weighted composite of the two.

The EQ scores produce a meaningfully different ranking than IQ alone. On the IQ vs. EQ scatter plot, Anthropic's Opus 4.7 leads on EQ with a score near 132, pushing it into the upper-right quadrant — the most desirable position, signaling both high cognitive and high emotional intelligence. OpenAI's GPT-5.5 and GPT-5.4 cluster in the high-IQ zone but lag slightly on EQ. Google's Gemini 3.1 Pro sits in a strong middle position on both axes.

One notable methodological choice has drawn attention: EQ-Bench 3 is judged by Claude, an Anthropic model, which the site acknowledges "creates potential scoring bias in favor of Anthropic models." To correct for this, AI IQ subtracts a 200-point Elo penalty from the EQ-Bench component for all Anthropic models before mapping to implied EQ. The Arena component is unaffected since it uses human judges. That self-correction is unusual in the benchmarking world, and it suggests Shea is aware of the methodological minefield he has entered. Still, the EQ dimension captures something IQ alone cannot: the growing importance of conversational quality, collaboration, and trust in models deployed for user-facing work.

Perhaps the most practically useful chart on the site is not the bell curve but the IQ vs. Effective Cost scatter plot. It maps each model's estimated IQ against an "effective cost" metric — defined as the token cost for a task using 2 million input tokens and 1 million output tokens, multiplied by a usage efficiency factor.

The chart reveals a familiar pattern in enterprise technology: the best models are not always the best value. GPT-5.5 and Opus 4.7 sit in the upper-left corner — high IQ, high cost, with effective per-task costs north of $30 and $50 respectively. Meanwhile, models like GPT-5.4-mini, DeepSeek-V3.2, and MiniMax-M2.7 occupy a sweet spot in the middle: respectable IQ scores between 112 and 120, at effective costs ranging from roughly $1 to $5 per task. At the cheapest extreme, GPT-oss-20b (an open-source OpenAI model) appears near $0.20 effective cost with an IQ around 107 — potentially the most economical option for bulk classification or extraction workloads.

The site also offers a 3D visualization mapping IQ, EQ, and effective cost simultaneously. A dashed line running through the cube points toward the ideal: higher IQ, higher EQ, and lower cost. Models near the "green end" of that axis are stronger all-around deals; those near the "red end" sacrifice capability, cost efficiency, or both. For CIOs staring at API invoices, the implication is clear: the intelligence gap between a $50 model and a $3 model has narrowed enough that routing — using expensive models for hard problems and cheap ones for everything else — is no longer optional. It is the dominant architecture for serious AI deployments.

The loudest objection to AI IQ is philosophical, and it cuts deep. Critics argue that collapsing a model's uneven capabilities into a single score obscures more than it reveals.

"IQ as a proxy is fading — we're seeing reasoning density spikes that don't map to g-factor," posted Zaya, a technology commentator, on X. "GPT-5.5 already hit saturation on MMLU-Pro, but still fails ClockBench 50% of the time."

That observation touches on what AI researchers call the "jaggedness" problem: large language models often exhibit wildly uneven capabilities, excelling at graduate-level physics while failing at tasks a child could do. A composite score can paper over those gaps.

Pressureangle, another X user, posted a more granular critique, calling out "complete lack of transparency" and arguing the site never fully discloses how its calibration curves were created or validated. In fairness, AI IQ does list its 12 benchmarks and shows the shape of each calibration curve in its methodology modal. But the raw data and precise mathematical transformations are not published as open datasets — a gap that matters to researchers accustomed to fully reproducible methods.

Others questioned the premise itself. "As useless as human IQ testing," wrote haashim on X. Shubham Sharma, an AI and technology writer, offered a constructive alternative: "Why not having the Models take an official (MENSA-Grade) test? Wouldn't this be the most accurate and most 'human-comparable' way to benchmark intelligence?" That approach already exists through TrackingAI, which administers the Mensa Norway IQ test to language models. But Mensa-style tests measure only abstract pattern recognition, while AI IQ attempts a broader composite across coding, mathematics, and academic reasoning. As Visual Capitalist noted, "an IQ-style benchmark captures only one slice of capability." Each approach has tradeoffs — and neither has won the argument yet.

For all the debate about methodology, the most important signal in AI IQ's data may not be any single model's score. It is the shape of the market the charts reveal.

There are now more than 50 frontier-class models available through APIs, from at least 14 major providers spanning the United States, China, and Europe. Each provider publishes its own benchmarks, often cherry-picked to showcase strengths. The result is a Tower of Babel where no two companies measure the same thing in the same way. Academic research has highlighted that "most benchmarks introduce bias by focusing on a particular type of domain," and the Frontier IQ Over Time chart on AI IQ shows just how fast the targets are moving: in October 2023, GPT-4-turbo sat near an estimated IQ of 75. By early 2026, the top models were brushing 135 — roughly 60 points of improvement in 30 months.

That pace raises a fundamental question about whether any scoring system can keep up. The site compresses ceilings for saturated benchmarks, but as models continue to max out even the hardest tests — ARC-AGI-2, FrontierMath Tier 4, Humanity's Last Exam — the framework will face the same ceiling effects that have plagued every AI evaluation before it. Connor Forsyth pointed to this dynamic on X: "ARC AGI 3 disagrees," he wrote, referencing a next-generation benchmark that may already be undermining current scores.

AI IQ is not perfect. Its methodology is partially opaque. Its IQ metaphor can mislead. And its creator acknowledges known biases while likely missing others. But the alternative — wading through dozens of provider-specific benchmark tables, each using different test suites and scoring conventions — is worse. The site offers enterprise buyers something genuinely scarce: a single framework for comparing models across providers, dimensions, and price points, updated regularly, with enough nuance to show that the right answer to "which model is best?" is almost always "it depends on the task."

As Debdoot Ghosh mused on X after viewing the charts: "Now a human's role is just to orchestrate?"

Maybe. But if the AI IQ data shows anything clearly, it is that orchestration — knowing which model to deploy, when, and at what price — has become its own form of intelligence. And for that, there is no benchmark yet.

Good news, OpenClaw fans — you can once again use your Claude AI subscription to power the hit, open source, autonomous AI agentic harness! But, there's a big catch with how it's being enacted.

A few hours ago, Anthropic announced via its official developer communications account on X, @ClaudeDevs, that it is changing its Claude paid subscription tiers, introducing a new subcategory of "Agent SDK" credits for all paid subscribers, which they can now allocate specifically for "programmatic" uses, including external, third-party agents such as OpenClaw.

The move is a major reversal from the Anthropic's policy introduced in early April 2026 that expressly prohibited its AI subscriptions from being used to power these kind of non-Anthropic agents and harnesses, after Anthropic said they caused capacity and service issues.

The problem was that some Claude subscribers were paying $20 to $200 per month under Anthropic's Claude Pro and Max subscriptions, but consuming hundreds, even thousands of dollars of tokens (units of information) above those prices through their OpenClaw (and similar autonomous) agents. This was an unsustainable position for Anthropic's finances and its limited compute infrastructure for inferencing the models to end users.

To be clear, even when it enacted the old prohibition against OpenClaw and similar agents last month, Anthropic never fully cut off the capability for Claude to be used in OpenClaw. Rather, it redirected users to pay through the company's application programming interface (API), which is billed by usage (priced per million tokens, rather than a flat monthly rate as the subscriptions offer), or pay for extra usage credits atop their subscriptions.

Now, Anthropic is giving Claude subscribers another way to use their subscription bill to pay for third-party agents.

However, the restoration comes with a significant catch: programmatic usage is no longer subsidized by the general subscription pool but is instead restricted to a fixed, non-rollover monthly credit, also worth $20-$200 depending on your Claude plan, and billed at the API rates.

In other words, if you don't end up using these new Agent SDK credits, they simply expire at the end of the month. And if you do use them all up, you cannot dip into your general subscription usage limits to cover any additional usage — you'll need to buy extra usage credits instead.

To understand why this restoration matters, one must look at the technical friction that led to the initial ban on April 4, 2026.

Anthropic’s first-party tools, such as Claude Code and Claude Cowork, are engineered to maximize "prompt cache hit rates"—a method of reusing previously processed text to save on expensive compute cycles.

Third-party tools like OpenClaw, which allow users to run autonomous agents through external services like Discord or Telegram, were often unoptimized for these efficiencies.Boris Cherny, Head of Claude Code, noted that these third-party services were "really hard for us to do sustainably" because they bypassed the caching mechanisms that allow Anthropic to offer flat-rate subscriptions.

The sheer volume of data being re-processed by inefficient agents was threatening the stability of the system for the broader user base. Even with Anthropic’s massive expansion into new hardware—including access to the 300MW Colossus 1 data center and its 220,000+ GPUs—the demand for agentic workflows was outpacing sustainable supply.

The new "Agent SDK credit" system solves this technical bottleneck by shifting the cost of inefficiency back to the user. By providing a dedicated dollar-amount credit, Anthropic no longer has to "eat the difference" on unoptimized third-party code. If an agent is inefficient and burns through tokens, it simply drains the user's new $20 to $200 Agent SDK credit budget faster, rather than exceeding the value of Anthropic's fixed monthly subscription tiers.

The restoration of third-party access is segmented across Anthropic’s billing tiers, creating a new hierarchy of "programmatic power." Here's how much Anthropic is giving each user in terms of the new Agent SDK credits (in addition to their normal Claude usage through Anthropic Claude products like Claude Code, Claude Cowork etc).

Plan

Monthly, Dedicated Agent SDK Credit (on top of existing subscription plans)

Usage Context

Pro

$20

Individual scripts and light SDK use.

Max 5x

$100

Moderate agentic automation.

Max 20x

$200

Professional-grade dev environments.

Team (Premium)

$100 / seat

Collaborative team automation.

Enterprise (Premium)

$200 / seat

Seat-based high-scale enterprise use.

This system introduces a sharp divide between "interactive" and "programmatic" workflows. If you are chatting with Claude in a browser or using Claude Code in a terminal to write code interactively, you are still drawing from your standard, high-capacity subscription limits.

As Anthropic technical staffer Lydia Hallie wrote in a post on X, "To add some clarity: you don't pay extra. It's the same subscription, same price per month." Hallie also included the following helpful diagram of how the new Agent SDK credits work:

However, the moment you use the claude -p command for non-interactive tasks, run a GitHub Action, or connect a third-party tool like OpenClaw, the system switches to the dedicated Agent SDK credit.

Once the Agent SDK credit limit ($20 for Pro plans, $100 for Max 5X, etc) is exhausted, programmatic usage stops unless the user has enabled "extra usage" billing, which is charged at standard, pay-as-you-go API rates.

Crucially, for those who found the original subscription model to be an infinite resource, this is a hard cap. Credits do not roll over, meaning the "use it or lose it" nature of the system forces a monthly reset of the developer’s budget.

The licensing implications of this move are profound for the "agentic" ecosystem.

By explicitly allowing third-party apps like Conductor and OpenClaw to authenticate via the Agent SDK, Anthropic is legitimizing a workflow it had previously attempted to block.

However, in doing so, it has ended the era of "compute arbitrage".In the early part of 2026, a $20 Pro subscription could be leveraged via OpenClaw to run agents that would cost hundreds of dollars on a standard API key.

By moving to a metered credit, Anthropic is aligning its subscription model with its Developer Platform (API). While it offers a "free" buffer for subscribers, it ensures that high-volume, production-level automation is moved to predictable, token-based billing.

This protects the company's margins while still offering a "sandbox" for developers to experiment without the immediate overhead of an API-first account.

While Anthropic executives framed the update as a "simplification", the developer community has largely branded it as a significant reduction in the value of their subscriptions. The backlash focuses on the sharp disparity between the previous effective usage and the new, metered reality.

Popular AI YouTuber and developer Theo Browne (@theo) of T3.gg warned developers that this change constitutes a massive devaluation for those using external tools. "If you use any of the following with your Claude sub, your usage must got cut by 25x," Theo stated, listing T3 Code, Conductor, Zed, and Jean as affected platforms. He concluded with a sharp warning: "They’re disguising this as 'free credits'. Don’t fall for it".

Kun Chen, a solo builder and former L8 engineer at Meta, Microsoft, and Atlassian, interpreted the move as a full surrender of Anthropic's market lead. "it's official. Anthropic pulled the plug on ALL programmatic use of claude subscription," Chen posted, adding that he had found himself "increasingly bullish about OpenAI" as a result. Chen argued that "Anthropic's only lead was on coding, and gpt 5.5 has flipped that already," signaling a potential migration of elite developer talent.

Other builders questioned the practical utility of the credits offered. Ben Hylak, co-founder and chief technology officer at AI agent observability and governance startup Raindrop.ai, voiced concern over the sustainability of Anthropic's infrastructure. "this is either really silly, or shows how bad of a spot anthropic is in re: gpus," Hylak noted, before bluntly asking users to "guess how many turns $20 in API credits last".

The frustration extended to the marketing of the change. EverNever, creator of inkstone.uk, expressed disbelief at the framing of the policy. "Wait what?! You take away more ways to utilize the subscription I am paying for?! And you dare to make it look like a win?". This sentiment highlights a growing rift between Anthropic and its power-user base, who feel that previously inclusive features are being rescinded under the guise of an "upgrade."

Anthropic’s "restoration" is a tactical move to retain developers while strictly managing the physical limits of compute. By June 15, the "agentic" era for Claude subscribers will be a metered one.

The company has successfully reclaimed control over its margins, even if it has cost them some of the goodwill of their most vocal power users.

For the individual developer or enterprise AI builder relying on Anthropic models for OpenClaw, however, it's clearly an improvement over the blanket ban from last month.

For the first time since the AI race began, more American businesses are paying for Anthropic's Claude than for OpenAI's ChatGPT.

Adoption of Anthropic rose 3.8% in April to 34.4% of businesses, according to the May 2026 release of the Ramp AI Index. OpenAI's adoption fell 2.9% to 32.3%. Overall AI adoption among businesses rose 0.2 percentage points to 50.6%.

The crossover — published Tuesday by Ramp, the corporate card and finance automation platform that tracks spending patterns across more than 50,000 U.S. businesses — marks the culmination of a yearlong surge by Anthropic that few in the industry predicted. Anthropic has quadrupled its business adoption over the past year, while OpenAI grew its business adoption by only 0.3%.

But the same report that crowns a new market leader also warns that Anthropic's position may be more fragile than it appears — threatened by escalating costs, compute constraints, and the very token-based pricing model that has fueled the company's extraordinary revenue growth.

To appreciate the scale of the shift, consider where the two companies stood a year ago. In April 2025, OpenAI commanded roughly 32% of business AI adoption according to Ramp's underlying data, while Anthropic stood at under 8%. OpenAI had built an early, commanding lead as the consumer default — ChatGPT was where most people first encountered AI, and that momentum carried into corporate purchasing decisions.

Anthropic's path was different. The company was popular early on with the earliest adopters — engineers, AI evangelists, the technical vanguard inside organizations. As Ramp lead economist Ara Kharazian noted in the March 2026 edition of the index, Anthropic leveraged that early-adopter base to go mainstream. By February, Anthropic was winning about 70% of head-to-head matchups against OpenAI among businesses purchasing AI services for the first time — a complete reversal of the trends observed in 2025.

The trajectory is visible in Ramp's underlying data. The company's adoption figures show Anthropic climbing from 0.03% of businesses in June 2023 to 7.94% by April 2025, then rocketing to 34.44% by April 2026.

OpenAI, meanwhile, peaked near 36.5% in mid-2025 and has been slowly declining since. The engine behind much of this growth is a single product: Claude Code, the company's agentic AI coding tool, which has become the fastest-growing product in Anthropic's history. A recent analysis estimated that 4% of all GitHub public commits worldwide were being authored by Claude Code — double the percentage from just one month prior.

Business Insider reported in April that the crossover was imminent. A Ramp spokesperson told the outlet that "at the current pace, Anthropic is on track to surpass OpenAI within the next two months," noting that it already led "among early adopters, including VC-backed companies, and in key sectors like software, finance, and professional services." That prediction proved accurate almost to the day.

The Ramp data on business spending finds its complement in a separate workforce survey that underscores just how deeply AI has embedded itself into American economic life. For the first time in Gallup's measurement, half of employed American adults say they use AI in their role at least a few times a year, up from 46% the previous quarter. Frequent use is also increasing, with 13% of employees now saying they use AI daily and 28% reporting they use it a few times a week or more.

But the Gallup data, based on a February 2026 survey of 23,717 U.S. employees, also suggests that the benefits of AI remain concentrated at the level of individual tasks rather than organizational transformation. Only about one in 10 employees in AI-adopting organizations strongly agree that artificial intelligence has transformed how work gets done. That finding is consistent with firm-level studies across the U.S., U.K., Germany, and Australia showing chief executives reporting minimal broad productivity effects from AI over the past three years — a notable gap between the hype cycle and operational reality.

The Ramp methodology captures a different but complementary signal. Where Gallup asks employees whether they use AI, Ramp measures whether their employer is writing checks for it. The index counts corporate card and invoice-based payments, identifying firms as AI adopters if they have a positive transaction amount for an AI product or service in a given month. As Ramp's methodology page notes, its results likely underestimate actual adoption because many employees use free AI tools or personal accounts for work tasks. Taken together, the two datasets paint a picture of AI that is ubiquitous in the American workplace but has not yet delivered on its promise to fundamentally transform how organizations operate.

Perhaps the most striking aspect of Ramp's analysis is its refusal to declare a lasting winner. Kharazian identified three specific risks facing Anthropic even as the company takes the lead — and the most serious one stems from a structural tension baked into the company's business model.

Anthropic makes more money when businesses purchase more tokens, meaning the company is incentivized to drive users toward more expensive models even when cheaper ones are sufficient. This dynamic is already creating budget crises at major enterprises. Uber's CTO revealed that the company spent its entire 2026 AI budget in just four months, largely on Claude Code and Cursor, with engineers reporting monthly API costs between $500 and $2,000 per person. Adoption jumped from 32% to 84% of Uber engineers in a matter of months, and about 70% of committed code at Uber now comes from AI. The Uber case is a microcosm of a broader tension: Claude Code works — perhaps too well. When a productivity tool becomes so valuable that an organization's $3.4 billion R&D operation can't afford to keep the lights on, the resulting cost scrutiny could push enterprises toward cheaper alternatives.

At the same time, quality and reliability have suffered under the weight of demand. In recent weeks, users have experienced frequent outages, rate limits, and increasing dissatisfaction with Claude's results. Anthropic has responded by resetting usage limits and by striking a compute deal with SpaceX to access more than 300 megawatts of new capacity at the Colossus 1 data center in Memphis. CEO Dario Amodei said the company saw "80x growth per year in revenue and usage" for Q1 2026, when it had only planned for 10x. And Ramp economist Rafael Hajjar found that Anthropic's latest model update would triple token costs for any prompt that includes an image — a change that seems at odds with the company's already-acute cost and compute problems.

The Ramp report points to competitive dynamics that could reshape the market within months. Some of the fastest-growing vendors on Ramp's platform in April were AI inference platforms that give companies access to cheap, open-source models — offering enterprises a way to get "good enough" AI at a fraction of the cost, particularly for routine tasks that don't require frontier model capabilities.

OpenAI's Codex presents an even more direct threat. By most measures, it is a strong product that does many of the same tasks as Claude Code at a lower price point — and the switching cost between models is minimal. Uber itself is already testing Codex as a hedge, a move that could preview a broader pattern across enterprise tech. OpenAI also retains enormous structural advantages. ChatGPT reached 900 million weekly active users by March 2026, dwarfing Claude's consumer footprint. Enterprise revenue now makes up more than 40% of OpenAI's total and is on track to reach parity with consumer revenue by the end of 2026. And OpenAI's $122 billion funding round, closed in March at an $852 billion valuation, gives it vast resources to compete on pricing, capacity, and product development.

Anthropic is not standing still on distribution. AWS recently launched Claude Platform on AWS, giving enterprises direct access to Anthropic's native platform through existing AWS credentials, billing, and access controls — a move that lowers procurement friction considerably. Anthropic has also announced compute agreements totaling billions of dollars with Amazon, Google, Microsoft, Nvidia, and others, though much of that capacity won't come online until late 2026 or 2027. Anthropic is reportedly in talks to raise another $50 billion at a valuation approaching $900 billion.

Beneath the spending data and market share charts lies a more intriguing question: Why are businesses choosing Anthropic over a cheaper, comparably performing alternative?

Kharazian explored this in his March analysis. Claude Code and OpenAI's Codex are roughly comparable products — on certain benchmarks, Codex is arguably better, and it's also cheaper. Yet Anthropic can't meet its own demand. Every plan still has usage limits and rate caps. The company is actively turning away revenue because it doesn't have the compute to serve it. Despite charging more for roughly equivalent performance, Anthropic's demand is growing.

Kharazian suggested the answer might be cultural. Earlier this year, Anthropic refused to agree to the Pentagon's terms of use for Claude, resulting in a blacklisting by the Department of Defense. OpenAI stepped in to offer its services in Anthropic's place. In the wake of that episode, users rallied around Anthropic, and Claude temporarily surpassed ChatGPT on the App Store. The question, Kharazian wrote, is whether choosing an AI model is becoming less like an enterprise procurement decision and "more like the green bubble/blue bubble distinction in iMessage: a signal of identity as much as a choice of technology."

That observation may sound absurd for an enterprise software category. But Ramp's data tells a story that pure economics cannot fully explain. In a market where the products perform similarly, where the cheaper option is arguably better on benchmarks, and where switching costs are negligible, something other than spreadsheet logic is driving the biggest shift in AI market share since the industry began. As Kharazian noted in his report: "We have never seen a software industry as dynamic, where newcomers can disrupt market leaders in a matter of months, and where the pace of development overrides the typical forces of vendor stickiness."

That dynamism cuts both ways. The same forces that propelled a company from 8% to 34% market share in twelve months could just as easily work in reverse. Anthropic's two-point lead was earned in the most volatile software market in modern history — and in this market, the distance between the throne and the floor has never been shorter.

As large language models become more capable, users are tempted to delegate knowledge tasks where models process documents on their behalf and provide the finished results. But how far can you trust the model to stay faithful to the content of your documents when it has to iterate over them across multiple rounds?

A new study by researchers at Microsoft shows that large language models silently corrupt documents that they work on by introducing errors. The researchers developed a benchmark that simulates multi-step autonomous workflows across 52 professional domains, using a method that automatically measures how much content degrades over time.

Their findings show that even top-tier frontier models corrupt an average of 25% of document content by the end of these workflows. And providing models with agentic tools or realistic distractor documents actually worsens their performance.

This serves as a warning that while there is increasing pressure to automate knowledge work, current language models are not fully reliable for these tasks.

The Microsoft study focuses on “delegated work,” an emerging paradigm where users allow LLMs to complete knowledge tasks on their behalf by analyzing and modifying documents.

A prominent example of this paradigm is vibe coding, where a user delegates software development and code editing to an AI. But delegated workflows extend far beyond programming into other domains. In accounting, for example, a user might supply a dense ledger and instruct the model to split the document into separate files organized by specific expense categories.

Because users might lack the time or the specialized expertise to manually review every modification the AI implements, delegation often hinges on trust. Users expect that the model will faithfully complete tasks without introducing unchecked errors, unauthorized deletions, or hallucinations in the documents.

To measure how far AI systems can be trusted in extended, iterative delegated workflows, the researchers developed the DELEGATE-52 benchmark. The benchmark is composed of 310 work environments spanning 52 diverse professional domains, including financial accounting, software engineering, crystallography, and music notation.

Each work environment relies on real-world seed text documents ranging from 2,000 to 5,000 tokens. Alongside the seed document, the environments include five to ten complex, non-trivial editing tasks.

Grading a complex, multi-step editing process usually requires expensive human review. DELEGATE-52 bypasses this by using a “round-trip relay” simulation method that evaluates answers without requiring human-annotated reference solutions. The approach is inspired by the backtranslation technique used in machine translation evaluation, where an AI model is told to translate a document from one language to another and back to see how perfectly it reproduces the original version.

Accordingly, every edit task in DELEGATE-52 is designed to be fully reversible, pairing a forward instruction with its precise inverse. For example, an instruction to split the ledger into separate files by expense category is paired with an instruction to merge all category files back into a single ledger.

In comments provided to VentureBeat, Philippe Laban, Senior Researcher at Microsoft Research and co-author of the paper, clarified that this is not simply a test of whether an AI can hit "undo." Because human workers cannot be forced to instantly "forget" a task they just did, this round-trip evaluation is uniquely suited for AI. By starting a new conversational session, the researchers force the model to attempt the inverse task completely independently.

The models in their experiments “do not know whether a task is a forward or backward step and are unaware of the overall experiment design," Laban explained. "They are simply attempting each task as thoroughly as they can at each step."

These roundtrip tasks are chained together into a continuous relay to simulate long-horizon workflows spanning 20 consecutive interactions. To make the environment more realistic, the benchmark introduces distractor files in the context of each task. These contain 8,000 to 12,000 tokens of topically related but completely irrelevant documents. Distractors measure whether the AI can maintain focus or if it gets confused and pulls in the wrong data.

To understand how different architectures and scales handle delegated work, the researchers tested 19 different language models from OpenAI, Anthropic, Google, Mistral, xAI, and Moonshot. The main experiment subjected these models to a simulation of 20 consecutive editing interactions.

Across all models, documents suffered an average degradation of 50% by the end of the simulation. Even the best frontier models in the experiment, specifically Gemini 3.1 Pro, Claude 4.6 Opus, and GPT 5.4, corrupted an average of 25% of the document content.

Out of 52 professional domains, Python was the only one where most models achieved a ready status with a score of 98% or higher. Models excel in programmatic tasks but struggle severely in natural language and niche domains like fiction, earning statements, or recipes. The overall top model, Gemini 3.1 Pro, was deemed ready for delegated work in only 11 out of the 52 domains.

Interestingly, the corruption was not caused by death by a thousand cuts where the models slowly accumulate tiny errors. Instead, about 80% of total degradation is caused by sparse but massive critical failures, which are single interactions where a model suddenly drops at least 10% of the document's content. The frontier models do not necessarily avoid small errors better. They simply delay these catastrophic failures to later rounds.

Another important observation is that when weaker models fail, their degradation originates primarily from content deletion. However, when frontier models fail, they actively corrupt the existing content. The text is still there, but it has been subtly distorted or hallucinated, making it much harder for a human overseer to detect the error.

Interestingly, giving models an agentic harness with generic tools for code execution and file read/write access actually worsened their performance, adding an average of 6% more degradation. Laban explained that the failure lies in relying on generic tools rather than domain-specific ones.

"Models lack the capability to write effective programs on the fly that can manipulate files across diverse domains without mistakes," he noted. "When they cannot do something programmatically, they resort to reading and rewriting entire files, which is less efficient and more error prone." The solution for developers is to build tightly scoped tools (such as specific functions to calculate or move entries within .ledger files) to keep agents on track.

Degradation also snowballs as documents get larger or as more distractor files are added to the workspace. For enterprise teams investing heavily in retrieval-augmented generation (RAG), these distractor documents serve as a direct warning about the compounding cost of messy context. While a noisy context window might cause a minimal 1% performance drop after just two interactions, that degradation compounds to a massive 2-8% drop over a long simulation.

"For the retrieval community: RAG pipelines should be evaluated over multi-step workflows, not just single-turn retrieval benchmarks," Laban said. "Single-turn measurements systematically underestimate the harm of imprecise retrieval."

The findings from the DELEGATE-52 benchmark offer a critical reality check for the current hype surrounding fully autonomous AI agents.

The benchmark's design also implies a practical constraint: because models can maintain a clean record for several steps before a sudden catastrophic failure, incremental human review is necessary — not a single final check. Laban recommends building AI applications around short, transparent tasks rather than complex long-horizon agents. This keeps the action implication without the writer delivering the prescription.

For organizations wanting to deploy autonomous agents safely today, the DELEGATE-52 methodology provides a practical blueprint for testing in-house data pipelines. Laban explained that "… an enterprise team wanting to adopt this framework needs to build three components: (a) a set of reversible editing tasks representative of their workflows, (b) a parser that converts their domain documents into a structured representation, and (c) a similarity function that compares two parsed representations." Teams do not even need to build parsers from scratch. The Microsoft research team successfully repurposed existing parsing libraries for 30 out of the 52 domains tested.

Laban is optimistic about the rate of improvement. "Progress is real and fast. Looking at the GPT family alone, models go from scoring below 20% to around 70% in 18 months," Laban said. "If that trajectory continues, models will soon be able to achieve saturated scores on DELEGATE-52."

However, Laban cautioned that DELEGATE-52 is purposefully small compared to massive enterprise environments. Even as foundation models inevitably master this benchmark, the endless long-tail of unique enterprise data and workflows means organizations will always need to invest in custom, domain-specific tooling to keep their autonomous agents reliable.

Any development environment that installed or imported one of the 172 compromised npm or PyPI packages published since May 11 should be treated as potentially compromised. On affected developer workstations, the worm harvests credentials from over 100 file paths: AWS keys, SSH private keys, npm tokens, GitHub PATs, HashiCorp Vault tokens, Kubernetes service accounts, Docker configs, shell history, and cryptocurrency wallets. For the first time in a TeamPCP campaign, it targets password managers including 1Password and Bitwarden, according to SecurityWeek.

It steals Claude and Kiro AI agent configurations, including MCP server auth tokens for every external service an agent connects to. And it does not leave when the package is removed.

The worm installs persistence in Claude Code (.claude/settings.json) and VS Code (.vscode/tasks.json with runOn: folderOpen) that re-execute every project open, plus a system daemon (macOS LaunchAgent / Linux systemd) that survives reboots. These live in the project tree, not in node_modules. Uninstalling the package does not remove them. On CI runners, the worm reads runner process memory directly via /proc/pid/mem to extract secrets, including masked ones, on Linux-based runners. If you revoke tokens before isolating the machine, Wiz’s analysis found a destructive daemon wipes your home directory.

Between 19:20 and 19:26 UTC on May 11, the Mini Shai-Hulud worm published 84 malicious versions across 42 @tanstack/* npm packages. Within 48 hours the campaign expanded to 172 packages across 403 malicious versions spanning npm and PyPI, according to Mend’s tracking. @tanstack/react-router alone receives 12.7 million weekly downloads. CVE-2026-45321, CVSS 9.6. OX Security reported 518 million cumulative downloads affected. Every malicious version carried a valid SLSA Build Level 3 provenance attestation. The provenance was real. The packages were poisoned.

“TanStack had the right setup on paper: OIDC trusted publishing, signed provenance, 2FA on every maintainer account. The attack worked anyway,” Peyton Kennedy, senior security researcher at Endor Labs, told VentureBeat in an exclusive interview. “What the orphaned commit technique shows is that OIDC scope is the actual control that matters here, not provenance, not 2FA. If your publish pipeline trusts the entire repository rather than a specific workflow on a specific branch, a commit with no parent history and no branch association is enough to get a valid publish token. That’s a one-line configuration fix.”

TanStack’s postmortem lays out the kill chain. On May 10, the attacker forked TanStack/router under the name zblgg/configuration, chosen to avoid fork-list searches per Snyk’s analysis. A pull request triggered a pull_request_target workflow that checked out fork code and ran a build, giving the attacker code execution on TanStack’s runner. The attacker poisoned the GitHub Actions cache. When a legitimate maintainer merged to main, the release workflow restored the poisoned cache. Attacker binaries read /proc/pid/mem, extracted the OIDC token, and POSTed directly to registry.npmjs.org. Tests failed. Publish was skipped. 84 signed packages still reached the registry.

“Each vulnerability bridges the trust boundary the others assumed,” the postmortem states. Published tradecraft from the March 2025 tj-actions/changed-files compromise, recombined in a new context.

Microsoft Threat Intelligence confirmed the mistralai PyPI package v2.4.6 executes on import (not on install), downloading a payload disguised as Hugging Face Transformers. npm mitigations (lockfile enforcement, --ignore-scripts) do not cover Python import-time execution.

Mistral AI published a security advisory confirming the impact. Compromised npm packages were available between May 11 at 22:45 UTC and May 12 at 01:53 UTC (roughly three hours). The PyPI release mistralai==2.4.6 is quarantined. Mistral stated an affected developer device was involved but no Mistral infrastructure was compromised. SafeDep confirmed Mistral never released v2.4.6; no commits landed May 11 and no tag exists.

Wiz documented the full blast radius: 65 UiPath packages, Mistral AI SDKs, OpenSearch, Guardrails AI, 20 Squawk packages. StepSecurity attributes the campaign to TeamPCP, based on toolchain overlap with prior Shai-Hulud waves and the Bitwarden CLI/Trivy compromises. The worm runs under Bun rather than Node.js to evade Node.js security monitoring.

Socket’s technical analysis of the 2.3 MB router_init.js payload identifies ten credential-collection classes running in parallel. The worm writes persistence into .claude/ and .vscode/ directories, hooking Claude Code’s SessionStart config and VS Code’s folder-open task runner. StepSecurity’s deobfuscation confirmed the worm also harvests Claude and Kiro MCP server configurations (~/.claude.json, ~/.claude/mcp.json, ~/.kiro/settings/mcp.json), which store API keys and auth tokens for external services. This is an early but confirmed instance of supply-chain malware treating AI agent configurations as high-value credential targets. The npm token description the worm sets reads: “IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.” It is not a bluff.

“What stood out to me about this payload is where it planted itself after running,” Kennedy told VentureBeat. “It wrote persistence hooks into Claude Code’s SessionStart config and VS Code’s folder-open task runner so it would re-execute every time a developer opened a project, even after the npm package was removed. The attacker treated the AI coding agent as part of the trusted execution environment, which it is. These tools read your repo, run shell commands, and have access to the same secrets a developer does. Securing a development environment now means thinking about the agents, not just the packages.”

Six gaps Mini Shai-Hulud exploited. What your CI/CD does today. The control that closes each one.

Audit question

What your CI/CD does today

The gap

1. Pin OIDC trusted publishing to a specific workflow file on a specific protected branch. Constrain id-token: write to only the publish job. Ensure that job runs from a clean workspace with no restored untrusted cache

Most orgs grant OIDC trust at the repository level. Any workflow run in the repo can request a publish token. id-token: write is often set at the workflow level, not scoped to the publish job.

The worm achieved code execution inside the legitimate release workflow via cache poisoning, then extracted the OIDC token from runner process memory. Branch/workflow pinning alone would not have stopped this attack because the malicious code was already running inside the pinned workflow. The complete fix requires pinning PLUS constraining id-token: write to only the publish job PLUS ensuring that job uses a clean, unshared cache.

2. Treat SLSA provenance as necessary but not sufficient. Add behavioral analysis at install time

Teams treat a valid Sigstore provenance badge as proof a package is safe. npm audit signatures passes. The badge is green. Procurement and compliance workflows accept provenance as a gate.

All 84 malicious TanStack versions carry valid SLSA Build Level 3 provenance attestations. First widely reported npm worm with validly-attested packages. Provenance attests where a package was built, not whether the build was authorized. Socket’s AI scanner flagged all 84 artifacts within six minutes of publication. Provenance flagged zero.

3. Isolate GitHub Actions cache per trust boundary. Invalidate caches after suspicious PRs. Never check out and execute fork code in pull_request_target workflows

Fork-triggered workflows and release workflows share the same cache namespace. Closing or reverting a malicious PR is treated as restoring clean state. pull_request_target is widely used for benchmarking and bundle-size analysis with fork PR checkout.

Attacker poisoned pnpm store via fork-triggered pull_request_target that checked out and executed fork code on the base runner. Cache survived PR closure. The next legitimate release workflow restored the poisoned cache on merge. actions/cache@v5 uses a runner-internal token for cache saves, not the workflow’s GITHUB_TOKEN, so permissions: contents: read does not prevent mutation. Kennedy: 'Branch protection rules don’t apply to commits that aren’t on any branch, so that whole layer of hardening didn’t help.'

4. Audit optionalDependencies in lockfiles and dependency graphs. Block github: refs pointing to non-release commits

Static analysis and lockfile enforcement focus on dependencies and devDependencies. optionalDependencies with github: commit refs are not flagged by most tools.

The worm injected optionalDependencies pointing to a github: orphan commit in the attacker’s fork. When npm resolves a github: dependency, it clones the referenced commit and runs lifecycle hooks (including prepare) automatically. The payload executed before the main package’s own install step completed. SafeDep confirmed Mistral never released v2.4.6; no commits landed and no tag exists.

5. Audit Python dependency imports separately from npm controls. Cover AI/ML pipelines consuming guardrails-ai, mistralai, or any compromised PyPI package

npm mitigations (lockfile enforcement, --ignore-scripts) are applied to the JavaScript stack. Python packages are assumed safe if pip install completes. AI/ML CI pipelines are treated as internal testing infrastructure, not as supply-chain attack targets.

Microsoft Threat Intelligence confirmed mistralai PyPI v2.4.6 executes on import, not install. Injected code in __init__.py downloads a payload disguised as Hugging Face Transformers. --ignore-scripts is irrelevant for Python import-time execution. guardrails-ai@0.10.1 also executes on import. Any agentic repo with GitHub Actions id-token: write is exposed to the same OIDC extraction technique. LLM API keys, vector DB credentials, and external service tokens all in the blast radius.

6. Isolate and image affected machines before revoking stolen tokens. Do not revoke npm tokens until the host is forensically preserved

Standard incident response: revoke compromised tokens first, then investigate. npm token list and immediate revocation is the instinctive first step.

The worm installs a persistent daemon (macOS LaunchAgent / Linux systemd) that polls GitHub every 60 seconds. On detecting token revocation (40X error), it triggers rm -rf ~/, wiping the home directory. The npm token description reads: 'IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.' Microsoft reported geofenced destructive behavior: a 1-in-6 chance of rm -rf / on systems appearing to be in Israel or Iran. Kennedy: 'Even after the package is gone, the payload may still be sitting in .claude/ with a SessionStart hook pointing at it. rm -rf node_modules doesn’t remove it.'

Sources: TanStack postmortem, StepSecurity, Socket, Snyk, Wiz, Microsoft Threat Intelligence, Mend, Endor Labs. May 12, 2026.

• Today: “The fastest check is find . -name 'router_init.js' -size +1M and grep -r '79ac49eedf774dd4b0cfa308722bc463cfe5885c' package-lock.json,” Kennedy said. If either returns a hit, isolate and image the machine immediately. Do not revoke tokens until the host is forensically preserved. The worm’s destructive daemon triggers on revocation. Once the machine is isolated, rotate credentials in this order: npm tokens first, then GitHub PATs, then cloud keys. Hunt for .claude/settings.json and .vscode/tasks.json persistence artifacts across every project that was open on the affected machine.

• This week: Rotate every credential accessible from affected hosts: npm tokens, GitHub PATs, AWS keys, Vault tokens, K8s service accounts, SSH keys. Check your packages for unexpected versions after May 11 with commits by claude@users.noreply.github.com. Block filev2.getsession[.]org and git-tanstack[.]com.

• This month: Audit every GitHub Actions workflow against the six gaps above. Pin OIDC publishing to specific workflows on protected branches. Isolate cache keys per trust boundary. Set npm config set min-release-age=7d. For AI/ML teams: check guardrails-ai and mistralai against compromised versions, audit CI pipelines for id-token: write exposure, and rotate every LLM API key and vector DB credential accessible from CI.

• This quarter (board-level): Fund behavioral analysis at the package registry layer. Provenance verification alone is no longer a sufficient procurement criterion for supply-chain security tooling. Require CI/CD security audits as part of vendor risk assessments for any tool with publish access to your registries. Establish a policy that no workflow with id-token: write runs from a shared cache. Treat AI coding agent configurations (.claude/, .kiro/, .vscode/) as credential stores subject to the same access controls as cloud key vaults.

This is the fifth Shai-Hulud wave in eight months. Four SAP packages became 84 TanStack packages in two weeks. intercom-client@7.0.4 fell 29 hours later, confirming active propagation through stolen CI/CD infrastructure. Late on May 12, malware research collective vx-underground reported that the fully weaponized Shai-Hulud worm code has been open-sourced. If confirmed, this means the attack is no longer limited to TeamPCP. Any threat actor can now deploy the same cache-poisoning, OIDC-extraction, and provenance-attested publishing chain against any npm or PyPI package with a misconfigured CI/CD pipeline.

“We’ve been tracking this campaign family since September 2025,” Kennedy said. “Each wave has picked a higher-download target and introduced a more technically interesting access vector. The orphaned commit technique here is genuinely novel. Branch protection rules don’t apply to commits that aren’t on any branch. The supply chain security space has spent a lot of energy on provenance and trusted publishing over the last two years. This attack walked straight through both of those controls because the gap wasn’t in the signing. It was in the scope.”

Provenance tells you where a package was built. It does not tell you whether the build was authorized. That is the gap this audit is designed to close.

AI that can see and understand what's happening in a video — especially a live feed — is understandably an attractive product to lots of enterprises and organizations. Beyond acting as a security "watchdog" over sites and facilities, such an AI model could also be used to clip out the most exciting parts of marketing videos and repurpose them for social, identify inconsistencies and gaffs in videos and flag them for removal, and identify body language and actions of participants in controlled studies or candidates applying for new roles.

While there are some AI models that offer this type of functionality today, it's far from a mainstream capability. The two-year-old startup Perceptron Inc. is seeking to change all that, however. Today, it announced the release of its flagship proprietary video analysis reasoning model, Mk1 (short for "Mark One") at a cost — $0.15 per million tokens input / $1.50 per million output through its application programming interface (API) — that comes in about 80-90% less than other leading proprietary rivals, namely, Anthropic's Claude Sonnet 4.5, OpenAI's GPT-5, and Google's Gemini 3.1 Pro.

Led by Co-founder and CEO Armen Aghajanyan, formerly of Meta FAIR and Microsoft, the company spent 16 months developing a "multi-modal recipe" from the ground up to address the complexities of the physical world.

This launch signals a new era where models are expected to understand cause-and-effect, object dynamics, and the laws of physics with the same fluency they once applied to grammar.

Interested users and potential enterprise customers can try it out for themselves on a public demo site from Perceptron here.

The model's performance is backed by a suite of industry-standard benchmarks focused on grounded understanding.

In spatial reasoning (ER Benchmarks), Mk1 achieved a score of 85.1 on EmbSpatialBench, surpassing Google’s Robotics-ER 1.5 (78.4) and Alibaba’s Q3.5-27B (approx. 84.5).

In the specialized RefSpatialBench, Mk1's score of 72.4 represents a massive leap over competitors like GPT-5m (9.0) and Sonnet 4.5 (2.2), highlighting a significant advantage in referring expression comprehension.

Video benchmarks show similar dominance; on the EgoSchema "Hard Subset"—where first-and-last-frame inference is insufficient—Mk1 scored 41.4, matching Alibaba’s Q3.5-27B and significantly beating Gemini 3.1 Flash-Lite (25.0).

On the VSI-Bench, Mk1 reached 88.5, the highest recorded score among the compared models, further validating its ability to handle actual temporal reasoning tasks.

Perceptron has explicitly targeted the "Efficiency Frontier," a metric that plots mean scores across video and embodied reasoning benchmarks against the blended cost per million tokens.

Benchmarking data reveals that Mk1 occupies a unique position: it matches or exceeds the performance of "frontier" models like GPT-5 and Gemini 3.1 Pro while maintaining a cost profile closer to "Lite" or "Flash" versions.

Specifically, Perceptron Mk1 is priced at $0.15 per million input tokens and $1.50 per million output tokens. In comparison, the "Efficiency Frontier" chart shows GPT-5 at a significantly higher blended cost (near $2.00) and Gemini 3.1 Pro at approximately $3.00, while Mk1 sits at the $0.30 blended cost mark with superior reasoning scores.

This aggressive pricing strategy is intended to make high-end physical AI accessible for large-scale industrial use rather than just experimental research.

The technical core of Perceptron Mk1 is its ability to process native video at up to 2 frames per second (FPS) across a significant 32K token context window.

Unlike traditional vision-language models (VLMs) that often treat video as a disjointed sequence of still images, Mk1 is designed for temporal continuity.

This architecture allows the model to "watch" extended streams and maintain object identity even through occlusions, a critical requirement for robotics and surveillance applications.

Developers can query the model for specific moments in a long stream and receive structured time codes in return, streamlining the process of video clipping and event detection.

A primary differentiator for Mk1 is its "Physical Reasoning" capability. Perceptron defines this as a high-precision spatial awareness that allows the model to understand object dynamics and physical interactions in real-world settings.

For example, the model can analyze a scene to determine if a basketball shot was taken before or after a buzzer by jointly reasoning over the ball's position in the air and the readout on a shot clock.

This requires more than just pattern recognition; it requires an understanding of how objects move through space and time.

The model is capable of "pixel-precise" pointing and counting into the hundreds within dense, complex scenes. It can also read analog gauges and clocks, which have historically been difficult for purely digital vision systems to interpret with high reliability.

It also seems to have strong general world and historical knowledge. In my brief test, I uploaded a vintage public domain film of skyscraper construction in New York City dated 1906 from the U.S. Library of Congress, and Mk1 was able to not only correctly describe the contents of the footage — including odd, atypical sights as workers being suspended by ropes — but did so rapidly and even correctly identified the rough date (early 1900s) from the look of the footage alone.

Accompanying the model release is an expanded developer platform designed to turn these high-level perception capabilities into functional applications with minimal code.

The Perceptron SDK, available via Python, introduces several specialized functions such as "Focus," "Counting," and "In-Context Learning".

The Focus feature allows users to zoom and crop into specific regions of a frame automatically based on a natural language prompt, such as detecting and localizing personal protective equipment (PPE) on a construction site. The Counting function is optimized for dense scenes, such as identifying and pointing to every puppy in a group or individual items of produce.

Furthermore, the platform supports in-context learning, allowing developers to adapt Mk1 to specific tasks by providing just a few examples, such as showing an image of an apple and instructing the model to label every instance of Category 1 in a new scene.

Perceptron is employing a dual-track strategy for its model weights and licensing. The flagship Perceptron Mk1 is a closed-source model accessed via API, designed for enterprise-grade performance and security.

However, the company is also maintaining its "Isaac" series, which kicked off with the launch of Isaac 0.1 in September 2025, as an open-weights alternative. Isaac 0.2-2b-preview, released in December 2025, is a 2-billion parameter vision-language model with reasoning capabilities that is available for edge and low-latency deployments.

While the weights for the Isaac models are open on the popular AI code sharing community Hugging Face, Perceptron offers commercial licenses for companies that require maximum control or on-premise deployment of the weights.

This approach allows the company to support both the open-source community and specialized industrial partners who need proprietary flexibility. The documentation notes that Isaac 0.2 models are specifically optimized for sub-200ms time-to-first-token, making them ideal for real-time edge devices.

Perceptron AI is a Bellevue, Washington-based physical AI startup founded by Aghajanyan and Akshat Shrivastava, both former research scientists at Meta’s Facebook AI Research (FAIR) lab.

The company’s public materials date its founding to November 2024, while a Washington corporate filing record for Perceptron.ai Inc. shows an earlier foreign registration filing on October 9, 2024, listing Shrivastava and Aghajanyan as governors.

In founder launch posts from late 2024, Aghajanyan said he had left Meta after nearly six years and “joined forces” with Shrivastava to build AI for the physical world, while Shrivastava said the company grew out of his work on efficiency, multimodality and new model architectures.

The founding appears to have followed directly from the pair’s work on multimodal foundation models at Meta. In May 2024, Meta researchers published Chameleon, a family of early-fusion models designed to understand and generate mixed sequences of text and images, work that Perceptron later described as part of the lineage behind its own models.

A July 2024 follow-on paper, MoMa, explored more efficient early-fusion training for mixed-modal models and listed both Shrivastava and Aghajanyan among the authors. Perceptron’s stated thesis extends that research direction into “physical AI”: models that can process real-world video and other sensory streams for use cases such as robotics, manufacturing, geospatial analysis, security and content moderation.

The real-world impact of Mk1 is already being demonstrated through Perceptron's partner network. Early adopters are using the model for diverse applications, such as auto-clipping highlights from live sports, which leverages the model's temporal understanding to identify key plays without human intervention.

In the robotics sector, partners are curating teleoperation episodes into training data, effectively automating the process of labeling and cleaning data for robotic arms and mobile units.

Other use cases include multimodal quality control agents on manufacturing lines, which can detect defects and verify assembly steps in real-time, and wearable assistants on smart glasses that provide context-aware help to users.

Aghajanyan stated that these releases are the culmination of research intended to make AI function best in the physical world, moving toward a future where "physical AI" is as ubiquitous as digital AI.

Between May 6 and 7, four security research teams published findings about Anthropic’s Claude that most outlets covered as three separate stories. One involved a water utility in Mexico, another targeted a Chrome extension, and a third hijacked OAuth tokens through Claude Code. In one case, Claude identified a water utility’s SCADA gateway without being told to look for one.

These are not three bugs. They are one architectural question playing out on three surfaces. No single patch released so far addresses all of them.

The common thread is the confused deputy, a trust-boundary failure where a program with legitimate authority executes actions on behalf of the wrong principal. In each case, Claude held real capabilities on every surface and handed them to whoever showed up. An attacker probing a water utility's network. A Chrome extension with zero permissions. A malicious npm package rewriting a config file.

Carter Rees, VP of Artificial Intelligence at Reputation, identified the structural reason this class of failure is so dangerous. The flat authorization plane of an LLM fails to respect user permissions, Rees told VentureBeat in an exclusive interview. An agent operating on that flat plane does not need to escalate privileges, it already has them.

Kayne McGladrey, an IEEE senior member who advises enterprises on identity risk, described the same dynamic independently in an interview with VentureBeat. Enterprises are cloning human permission sets onto agentic systems, McGladrey said. The agent does whatever it needs to do to get its job done, and sometimes that means using far more permissions than a human would.

Dragos published its analysis on May 6. Between December 2025 and February 2026, an unidentified adversary compromised multiple Mexican government organizations. In January 2026, the campaign reached Servicios de Agua y Drenaje de Monterrey, the municipal water and drainage utility serving the Monterrey metropolitan area.

Dragos analyzed more than 350 artifacts. The adversary used Claude as the primary technical executor and OpenAI’s GPT models for data processing. Claude wrote a 17,000-line Python framework containing 49 modules for network discovery, credential harvesting, privilege escalation, and lateral movement. Claude compressed what would traditionally take days or weeks of tooling development into hours, according to the Dragos analysis.

Without any prior ICS/OT context, Claude identified a server running a vNode SCADA/IIoT management interface, classified the platform as high-value, generated credential lists, and launched an automated password spray. The attack failed, and no OT breach occurred, but Claude did the targeting. Dragos noted that this was not a product vulnerability in the traditional sense because Claude performed exactly as designed. The architectural gap, as the firm described it, is that the model cannot distinguish an authorized developer from an adversary using the same interface.

Jay Deen, associate principal adversary hunter at Dragos, wrote that the investigation showed how commercial AI tools have made OT more visible to adversaries already operating within IT.

CrowdStrike CTO Elia Zaitsev told VentureBeat why this class of incident evades detection. Nothing bad has happened until the agent acts, Zaitsev said. It is almost always at the action layer. The Monterrey reconnaissance looked like a developer querying internal systems. The developer tool just had an adversary at the keyboard.

Stack blind spot: OT monitoring does not flag AI-generated recon from IT-side developer tools. EDR sees the process but has no visibility into intent.

On May 7, LayerX researcher Aviad Gispan disclosed ClaudeBleed. Claude in Chrome uses Chrome’s externally connectable feature to allow communication with scripts on the claude.ai origin, but does not verify whether those scripts came from Anthropic or were injected by another extension. Any Chrome extension can inject commands into Claude’s messaging interface. Zero permissions required.

LayerX reported the flaw on April 27. Anthropic shipped version 1.0.70 on May 6. LayerX found that the patch did not remove the vulnerable handler. LayerX bypassed the new protections through the side-panel initialization flow and by switching Claude into "Act without asking" mode, which required no user notification. Anthropic's patch survived less than a day.

Mike Riemer, SVP of Network Security Group and Field CISO at Ivanti, told VentureBeat that threat actors are now reverse engineering patches within 72 hours using AI assistance. If a vendor releases a patch and the customer has not applied it within that window, the vulnerability is already being exploited, Riemer said. Anthropic's ClaudeBleed patch did not survive even a third of that window.

Stack blind spot: EDR watches files and processes but does not monitor extension-to-extension messaging within the browser. ClaudeBleed produces no file writes, no network anomalies, and no process spawns.

Also on May 7, Mitiga Labs researcher Idan Cohen published a man-in-the-middle attack chain targeting Claude Code. Claude Code stores MCP configuration and OAuth tokens in ~/.claude.json, a single user-writable file. A malicious npm postinstall hook can rewrite the MCP server URL to route traffic through an attacker's proxy, capturing OAuth tokens for Jira, Confluence, and GitHub. Because the postinstall hook fires on every Claude Code load, it reasserts the malicious endpoint even after token rotation — meaning the standard incident response step of rotating credentials does not break the attack chain unless the hook itself is removed first.

Mitiga reported the finding on April 10. On April 12, Anthropic classified it as out of scope, according to Mitiga’s published disclosure.

Riemer described the principle this chain violates. I do not know you until I validate you, Riemer told VentureBeat. Until I know what it is and I know who is on the other side of the keyboard, I am not going to communicate with it. The ~/.claude.json rewrite substitutes the attacker’s endpoint for the legitimate one. Claude Code never re-validates.

Riemer has spent 21 years architecting the product he now leads and holds five patents on its security infrastructure. He applies the same defensive logic he built into his own platform. If a threat actor gets in, drop all connections. That is a fail-safe design. Anthropic's architecture does the opposite. It fails open.

Stack blind spot: Web application firewalls never see local config rewrites. EDR treats JSON file writes as normal developer behavior. Rotating tokens does not break the chain unless responders also confirm the hook is removed.

Anthropic classified Mitiga's MCP token theft as out of scope on April 12. The company called OX Security's STDIO vulnerability affecting an estimated 200,000 MCP servers "expected" and by design. Anthropic declined Adversa AI's TrustFall as outside its threat model, according to Adversa's published disclosure. ClaudeBleed was partially patched. Across all four disclosures, the researchers say the underlying trust model remains exploitable.

Alex Polyakov, co-founder of Adversa AI, told The Register that each vulnerability gets patched in isolation, but the underlying class has not been fixed.

Zaitsev offered a frame for why consent alone cannot serve as the trust boundary. If you think you can always understand intent, Zaitsev told VentureBeat, then you would also think it is possible to write a program that reads a text transcript and figures out if someone is lying. That is intuitively an impossible problem to solve.

Adversa AI researcher Alex Polyakov published TrustFall, demonstrating that project-scoped Claude configuration files in a cloned repository can silently authorize MCP servers to run as native OS processes with full user privileges. The moment a developer clicks the generic “Yes, I trust this folder” dialog, any MCP server defined in the project config launches. The dialog does not show what it authorizes.

In automated build pipelines where Claude Code runs without a screen, the trust dialog never appears. The attack executes with zero human interaction. Adversa confirmed the pattern is not unique to Claude Code. All four major coding agents (Claude Code, Cursor, Gemini CLI, and GitHub Copilot) can auto-execute project-defined MCP servers the moment a developer accepts that dialog.

Stack blind spot: No current security tooling can tell the difference between a legitimate project config and a malicious one. The trust dialog is the only thing standing between the developer and arbitrary code execution, and it does not show what it is about to authorize.

The matrix below maps each surface that Claude wrongly trusted, the stack blind spot, the detection signal, and the recommended action.

Surface

Who Claude Trusted

Why Your Stack Misses It

Detection Signal

Recommended Action

claude.ai / API

Dragos, May 6

350+ artifacts analyzed

Attacker posing as an authorized user via Claude’s prompt interface.

Claude cannot distinguish a developer mapping internal systems from an adversary doing the same thing through the same interface.

OT monitoring watches ICS protocols and anomalous traffic patterns.

AI-generated recon originates from an IT-side developer tool, not from the OT network. The queries look identical to legitimate developer activity because they ARE legitimate developer activity with an adversary at the keyboard.

Query:

Claude API logs for requests referencing internal hostnames, IP ranges, or SCADA/ICS keywords.

Alert trigger:

>5 credential generation requests against internal services in 60 minutes.

Escalation:

OT team notified on any AI-originated query touching vNode, SCADA, HMI, or PLC keywords.

Segment AI-assisted sessions from OT-adjacent network segments.

Log all Claude API calls referencing internal hostnames or IP ranges.

Alert on automated credential generation targeting internal authentication interfaces.

Require explicit OT authorization for any AI tool with internal network access.

Claude in Chrome

LayerX, May 7

v1.0.70 patch bypassed <24hrs

Any script running in the claude.ai browser context, including scripts injected by zero-permission extensions.

The externally connectable manifest trusts the origin (claude.ai), not the execution context. Any extension can inject into that origin.

EDR monitors file system activity, process execution, and network connections.

Extension-to-extension messaging happens entirely within the browser runtime. No file writes. No network anomalies. No process spawns. EDR has zero visibility into Chrome’s internal messaging API.

Query:

Chrome extension inventory for any extension with content scripts targeting claude.ai in the manifest.

Alert trigger:

New extension installed with claude.ai in permissions or content script targets.

Escalation:

Browser security team reviews any extension communicating with Claude’s messaging interface.

Audit Chrome extensions across the fleet for claude.ai content script access.

Disable “Act without asking” mode in Claude in Chrome enterprise-wide.

Deploy browser security tooling that inspects extension messaging channels.

Monitor for extensions injecting content scripts into claude.ai domain.

Claude Code MCP

Mitiga, May 7

Anthropic: “out of scope” April 12

Rewritten ~/.claude.json routing MCP traffic through attacker-controlled proxy.

Claude Code reads the MCP server URL from the config file on every load. It never re-validates that the URL matches the endpoint the user originally authorized.

WAF inspects HTTP traffic between clients and servers. It never sees a local config file rewrite.

EDR treats JSON file writes in the user’s home directory as normal developer behavior. Token rotation feeds the chain because the npm postinstall hook reasserts the malicious URL on every Claude Code load.

Query:

File integrity monitor on ~/.claude.json for MCP server URL changes.

Alert trigger:

MCP server URL changed to endpoint not on approved allowlist.

Escalation:

IR team confirms postinstall hook removal before closing ticket. Token rotation alone is insufficient.

Monitor ~/.claude.json for unexpected MCP endpoint changes against an allowlist.

Block or alert on npm postinstall hooks that modify files outside the package directory.

Maintain a centralized MCP server URL allowlist.

Do NOT assume token rotation breaks the chain without confirming the malicious hook is removed first.

Claude Code project settings

Adversa AI, May 7

Affects Claude, Cursor, Gemini CLI, Copilot

Project-scoped .claude configuration file in a cloned repository.

Clicking the generic “Yes, I trust this folder” dialog silently authorizes any MCP server defined in the project config. The dialog does not show what it authorizes.

No current security tooling can tell the difference between a legitimate project config and a malicious one.

In automated build pipelines, Claude Code runs without a screen. The attack executes with zero human interaction against pull-request branches.

Query:

Pre-clone scan for .claude, .claude.json, .mcp.json, CLAUDE.md files in repository root.

Alert trigger:

Repo contains MCP server definition not on approved organizational list.

Escalation:

DevSecOps reviews before any developer opens the repo in Claude Code or any coding agent.

Scan cloned repositories for .claude configuration files before opening in any AI coding agent.

Require explicit per-server MCP approval rather than blanket folder trust.

Flag repos that define custom MCP servers in project configuration.

Audit CI/CD pipelines running Claude Code headless where trust dialogs are skipped entirely.

The deputy changed

Norm Hardy described the confused deputy in 1988. The deputy he had in mind was a compiler. This one writes 17,000-line exploitation frameworks, identifies SCADA gateways on its own, and holds OAuth tokens to Jira, Confluence, and GitHub. Four research teams found the same failure class on four surfaces in the same week. Anthropic's response to each one was some version of "the user consented." The matrix above is the audit Anthropic has not built. If your team runs Claude Code or Claude in Chrome, start there.

Presented by Apptio, an IBM company

AI spending is surging, but the full impact often remains an open question. Closing the gap requires clear answers to how AI is governed, measured, and tied to business outcomes.

ROI uncertainty isn’t unique to AI: In the Apptio 2026 Technology Investment Management Report, 90% of technology leaders surveyed said that ROI uncertainty has a moderate or major impact on overall tech investment decisions, a 5-percentage point year-over-year increase. In other words, tech leaders are increasing their reliance on ROI – even if they don’t fully know how to measure it. And AI economics involves new and unpredictable costs, further complicating ROI calculations. Faced with increasing uncertainty and increasing budgets, technology leaders need a clear, reliable framework for evaluating AI ROI.

Organizations increasingly expect scaled AI to pay its own way, at least partially. According to Apptio’s technology investment management report, 45% of organizations surveyed intend to fund innovation by reinvesting savings from AI-driven efficiencies. That model assumes that such savings are both achievable and quantifiable. Meanwhile, the two-thirds of organizations planning to reallocate existing budget capital to AI will need clarity on the trade-offs involved.

Much like the early days of public cloud, AI costs and returns are difficult to predict. Pricing varies widely across providers and continues to evolve, while consumption is unpredictable. The pressure to adopt quickly is also formidable as organizations navigate the threat of disruption by more agile competitors.

Considering the many variables, tech leaders should view AI ROI as a matter of optimization. At a high level, the implementation of AI initiatives is inevitable. The question is how to achieve the greatest possible returns — both financial and organizational.

Start with the business problem. There are many ways AI can deliver positive impact, but organizational resources and focus may be limited. Make sure you’re prioritizing the right initiatives by basing your AI investment strategy on quantifiable goals tied to real business outcomes. Are you trying to improve decision-making speed? Increase throughput or capacity? Or chasing cool edge cases with high potential returns but minimal strategic relevance?

Determine what success looks like. AI can introduce a new capability or augment an existing one. For new capabilities, articulate the possibilities you’d like to unlock, such as new revenue opportunities, workflows, or decision-making processes. For augmentations, establish baseline performance and the expected lift you aim to achieve with AI.

Consider how finances will influence your evaluation. Some use cases may show minimal results in the near-term but drive significant value in the long-term. What’s your timeframe for return? On the other hand, more successful rollouts with rapid adoption can generate unexpectedly high inference bills. Would that mean pulling the plug — or leaning in further? What should your cost and return curve look like over the years? As you map your timeline, establish clear thresholds to determine whether you’ll proceed, pause, stop, or accelerate your investment.

Identify the right KPIs. The returns on an AI investment can be even more difficult to evaluate than the costs. Usage, efficiency, and financial impact all matter. But AI success metrics won’t always be straightforward. There may be new usage patterns you don’t yet have a way to measure. Your technology environment may experience follow-on shifts that call for further evaluation. Will you be able to lessen your reliance on other tools, such as reducing seats in your data analytics platform? How will you factor in cross-tool pricing comparisons for multiple AI providers with shifting rates?

To gain full context and insight, you must also take into account the alignment of the initiative with your broader strategy and consider the opportunity cost of the investments you might otherwise have made. Remember that you’re not evaluating AI business value in isolation; you’re deciding whether it's the best use of finite capital across all your investments.

These decisions will call for a level of insight far exceeding what was needed to justify traditional purchases like network infrastructure or enterprise software. Tech leaders navigating the complexities of AI economics should consider a new framework for data-driven decision-making.

Technology business management (TBM) helps make ROI more concrete and measurable, so it can be relevant to the business. By bringing together IT Financial Management (ITFM), AI FinOps (cloud financial management for AI workloads), and Strategic Portfolio Management (SPM), a TBM framework connects financial, operational, and business data across the enterprise.This makes it possible to account for AI value and cost across a wide array of dimensions — and translate hypothetical innovation into board presentations and budget justifications that hold up under scrutiny.

TBM can help leaders build a trustworthy cost foundation that captures AI spend across labor, infrastructure, inference, storage, and applications. As AI workloads shift dynamically, TBM provides visibility into how that spend is distributed across on-premises systems and cloud environments — both of which require different capacity planning for specialized skill sets. The framework also connects investments to business outcomes, aligning AI initiatives with strategic priorities and measurable results. With increased visibility, you’re able to identify issues and make decisions fast, such as catching cost spikes early. Early detection can help to determine if the usage shift merits shifting funding. This unified view of financial and operational data helps leaders scale what’s working and reassess what isn’t as adoption increases. TBM provides essential visibility and context across the entire AI spend management conversation. Even as pricing evolves, tooling changes, and workflows shift, you can apply the same analytical approach and understand what’s actually working and demonstrate ROI. Leaders who operationalize AI within a TBM framework can:

• Evaluate ROI at both project and portfolio levels

• Spot unexpected cost spikes

• Compare multiple AI tools

• Understand ripple effects across run-the-business systems

• Defend investment decisions with confidence

• Understand and manage total costs and usage across the AI investment lifecycle

Organizations are moving beyond AI experiments, and we’re past the point where these investments can be funded on optimism alone. Amid heightened uncertainty and cost sensitivity, boards are asking more strategic questions and finance wants trustworthy data.

Enterprise leaders who treat AI as a managed investment, rather than a bet on innovation, are those who will scale it successfully. To fund AI responsibly, leaders must establish clarity around scope, outcomes, cost drivers, and readiness. A TBM-driven approach provides the data foundation, visibility, and accountability to make those decisions.

Learn more here about how Apptio TBM transforms IT spend management in the AI era.

Ajay Patel is General Manager at Apptio, an IBM Company.

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.

Presented by EdgeVerve

For most enterprises, AI adoption began with a straightforward ambition: automate work faster, cheaper, and at scale. Chatbots replaced basic service requests, machine‑learning models optimized forecasts, and analytics dashboards promised sharper insights. Yet many organizations are now discovering that deploying individual AI solutions does not automatically translate into enterprise‑level impact. Pilots proliferate, but value plateaus.

The next phase of AI maturity is no longer about deploying more models. It is about adapting AI continuously to changing business objectives, regulatory expectations, operating conditions, and customer contexts. This shift is particularly critical for complex, globally distributed organizations such as Global Business Services (GBS), where outcomes depend on orchestrating work across functions, regions, systems, and stakeholders.

AI can no longer be treated as a standalone tool to accelerate discrete tasks. To remain competitive, enterprises must move from isolated, single‑purpose models toward systems that can sense context, coordinate actions, and evolve over time.

This is where adaptive AI ecosystems come into play. An adaptive AI ecosystem is a network of interoperable AI agents, models, data sources, and decision services that work together dynamically. These ecosystems integrate capabilities such as natural language processing, computer vision, predictive analytics, and autonomous decision‑making, while remaining grounded in human oversight and enterprise governance.

For GBS organizations, the relevance is clear. GBS operates at the intersection of scale, standardization, and variation, managing high‑volume processes across markets that differ in regulation, customer behavior, and operational constraints. Static automation struggles in such environments. Adaptive AI, by contrast, allows GBS teams to orchestrate end‑to‑end processes, intelligently route work, and continuously improve outcomes based on real‑time signals.

Despite strong intent, scaling AI remains a challenge. Research consistently shows that while many organizations invest in generative and agentic AI initiatives, far fewer succeed in operationalizing them across workflows and business units. The issue is rarely ambition; it is fragmentation.

SSON Research highlights several persistent barriers to generative AI adoption in GBS, including poor data quality, lack of specialized skills, data privacy concerns, unclear ROI, and budget constraints. Beneath these symptoms lies a common root cause: siloed environments. Data is fragmented, ownership is unclear, and AI initiatives are driven locally rather than through a shared enterprise strategy.

As a result, enterprises accumulate AI solutions that cannot easily work together. Models lack shared context, decisions are hard to explain, and governance becomes an afterthought rather than a design principle.

An adaptive AI ecosystem describes the enterprise‑wide outcome for how AI capabilities collaborate across the organization. An adaptive AI platform is the foundation that makes this possible.

The platform provides common services and guardrails that allow AI agents and models to:

• access harmonized, trusted data

• orchestrate end‑to‑end processes

• enable intelligent agent handoffs between systems and humans

• interoperate with both agentic and legacy applications through out‑of‑the‑box connectors

• operate within defined security, compliance, and ethical boundaries

Without this platform layer, adaptive ecosystems remain theoretical. With it, AI becomes composable, governable, and scalable.

To meet the demands of modern enterprises, and especially GBS organizations, an adaptive AI platform must deliver a set of core capabilities.

Real‑time data harmonization is foundational. Adaptive decisions require access to both structured and unstructured data across functions and regions. Platforms must provide a unified data foundation, with observability built in, so AI systems understand not just the data itself but its quality, lineage, and relevance. Edge‑to‑cloud architectures play a role here, ensuring insights are available where decisions occur whether at the point of interaction or within a centralized decision engine.

Adaptive process orchestration is equally critical. GBS organizations increasingly rely on AI platforms that can orchestrate workflows dynamically across business units and systems. This includes coordinating multiple AI agents, enabling seamless agent‑to‑agent and human‑in‑the‑loop handoffs, and adjusting process paths in response to real‑time conditions.

Cognitive automation with governance moves beyond rule‑based automation. AI systems must be able to make context‑aware decisions with minimal human intervention, while still providing explainability, confidence indicators, and ethical constraints. The goal is not to remove humans from the loop, but to elevate their role from manual execution to oversight and judgment.

Decision governance and observability tie these capabilities together. Enterprises must be able to trace how decisions are made, understand which models contributed, and audit outcomes across markets. As regulatory expectations around AI risk management, data protection, and accountability increase globally, embedding governance into the platform becomes essential rather than optional.

Trust is the foundation of scalable AI. Enterprises that lack confidence in their AI systems across data integrity, model behavior, and regulatory compliance will struggle to move beyond experimentation into sustained adoption.

Building this trust requires deliberate investment. Organizations must ensure explainable AI, so decision logic is transparent to business and risk stakeholders, alongside privacy‑ and security‑by‑design principles that protect sensitive data from the outset. Continuous bias detection, model reliability, performance management, and clearly defined responsible AI guardrails are critical to maintaining consistent and ethical outcomes.

Equally important is a clear Target Operating Model. This model defines ownership across the AI lifecycle, clarifies roles and escalation paths, and aligns accountability from frontline teams to executive leadership. In GBS environments where AI‑driven decisions often span functions, geographies, and regulatory regimes these trust mechanisms are not optional. They are essential.

Enterprises that continue to rely on fragmented AI deployments and siloed operating models will find it increasingly difficult to keep pace. The future belongs to organizations that adopt a platform‑based approach — one that enables them to move from incremental efficiency gains to transformational, enterprise‑wide impact.

Success will not be defined by a single model or use case. It will be defined by adaptive AI ecosystems built on strong agent architectures, interoperable connectors across agentic and legacy landscapes, and shared foundations for data, orchestration, and governance. For GBS organizations in particular, this approach provides a clear path to scale AI responsibly delivering agility, trust, and sustained value in an increasingly complex world. In an era where change is constant and scrutiny is rising; the real question is no longer whether enterprises use AI but whether they are truly adaptive to it.

N. Shashidar is SVP & Global Head, Product Management at EdgeVerve.

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.

Is AI leaving the era of "turn-based" chat?

Right now, all of us who use AI models regularly for work or in our personal lives know that the basic interaction mode across text, imagery, audio, and video remains the same: the human user provides an input, waits anywhere between milliseconds to minutes (or in some cases, for particularly tough queries, hours and days), and the AI model provides an output.

But if AI is to really take on the load of jobs requiring natural interaction, it will need to do more than provide this kind of "turn-based" interactivity — it will ultimately need to respond more fluidly and naturally to human inputs, even responding while also processing the next human input, be it text or another format.

That at least seems to be the contention of Thinking Machines, the well-funded AI startup founded last year by former OpenAI chief technology officer Mira Murati and former OpenAI researcher and co-founder John Schulman, among others.

Today, the firm announced a research preview of what it deems to be "interaction models, a new class of native multimodal systems that treats interactivity as a first-class citizen of model architecture rather than an external software "harness," scoring some impressive gains on third-party benchmarks and reduced latency as a result.

However, the models are not yet available to the general public or even enterprises — the company says in its announcement blog post: "In the coming months, we will open a limited research preview to collect feedback, with a wider release later this year."

At the heart of this announcement is a fundamental shift in how AI perceives time and presence. Current frontier models typically experience reality in a single thread; they wait for a user to finish an input before they begin processing, and their perception freezes while they generate a response.

In their blog post, the Thinking Machines researchers described the status quo as a limitation that forces humans to "contort themselves" to AI interfaces, phrasing questions like emails and batching their thoughts.

To solve this "collaboration bottleneck," Thinking Machines has moved away from the standard alternating token sequence.

Instead, they use a multi-stream, micro-turn design that processes 200ms chunks of input and output simultaneously.

This "full-duplex" architecture allows the model to listen, talk, and see in real time, enabling it to backchannel while a user speaks or interject when it notices a visual cue—such as a user writing a bug in a code snippet or a friend entering a video frame. Technically, the model utilizes encoder-free early fusion.

Rather than relying on massive standalone encoders like Whisper for audio, the system takes in raw audio signals as dMel and image patches (40x40) through a lightweight embedding layer, co-training all components from scratch within the transformer.

The research preview introduces TML-Interaction-Small, a 276-billion parameter Mixture-of-Experts (MoE) model with 12 billion active parameters. Because real-time interaction requires near-instantaneous response times that often conflict with deep reasoning, the company has architected a two-part system:

1. The Interaction Model: Stays in a constant exchange with the user, handling dialog management, presence, and immediate follow-ups.

2. The Background Model: An asynchronous agent that handles sustained reasoning, web browsing, or complex tool calls, streaming results back to the interaction model to be woven naturally into the conversation.

This setup allows the AI to perform tasks like live translation or generating a UI chart while continuing to listen to user feedback—a capability demonstrated in the announcement video where the model provided typical human reaction times for various cues while simultaneously generating a bar chart.

To prove the efficacy of this approach, the lab utilized FD-bench, a benchmark specifically designed to measure interaction quality rather than just raw intelligence.The results show that TML-Interaction-Small significantly outperforms existing real-time systems:

• Responsiveness: It achieved a turn-taking latency of 0.40 seconds, compared to 0.57s for Gemini-3.1-flash-live and 1.18s for GPT-realtime-2.0 (minimal).

• Interaction Quality: On FD-bench V1.5, it scored 77.8, nearly doubling the scores of its primary competitors (GPT-realtime-2.0 minimal scored 46.8).

• Visual Proactivity: In specialized tests like RepCount-A (counting physical repetitions in video) and ProactiveVideoQA, Thinking Machines’ model successfully engaged with the visual world while other frontier models remained silent or provided incorrect answers.

Metric

TML-Interaction-Small

GPT-realtime-2.0 (min)

Gemini-3.1-flash-live (min)

Turn-taking latency (s)

0.40

1.18

0.57

Interaction Quality (Avg)

77.8

46.8

54.3

IFEval (VoiceBench)

82.1

81.7

67.6

Harmbench (Refusal %)

99.0

99.5

99.0

If made available to the enterprise sector, Thinking Machines' interaction models would represent a fundamental shift in how businesses integrate AI into their operational workflows.

A native interaction model like TML-Interaction-Small allows for several enterprise capabilities that are currently impossible or highly brittle with standard multimodal models:

Current enterprise AI requires a "turn" to be completed before it can analyze data. In a manufacturing or lab setting, a native interaction model can monitor a video feed and proactively interject the moment it detects a safety violation or a deviation from a protocol — without waiting for the worker to ask for feedback.

The model's success in visual benchmarks like RepCount-A (accurate repetition counting) and ProactiveVideoQA (answering questions as visual evidence appears) suggests it could serve as a real-time auditor for high-stakes physical tasks.

The primary friction in voice-based customer service is the 1–2 second "processing" delay common in 2026's standard APIs. Thinking Machines' model achieves a turn-taking latency of 0.40 seconds, roughly the speed of a natural human conversation.

Because it handles simultaneous speech natively, an enterprise support bot could listen to a customer's frustration, provide "backchannel" cues (like "I see" or "mm-hmm") without interrupting the user, and offer live translation that feels like a natural conversation rather than a series of disjointed recordings.

Standard LLMs lack an internal clock; they "know" time only if it is provided in a text prompt. Interaction models are natively time-aware, allowing them to manage time-sensitive processes like "Remind me to check the temperature every 4 minutes" or "Alert me if this process takes longer than the last one". This is critical for industrial maintenance and pharmaceutical research where timing is an essential variable.

This release marks the second major milestone for Thinking Machines following the October 2025 launch of Tinker, a managed API for fine-tuning language models that lets researchers and developers control their data and training methods while Thinking Machines handles the infrastructure burden of distributed training.

The company said Tinker supports both small and large open-weight models, including mixture-of-experts models, and early users included groups at Princeton, Stanford, Berkeley and Redwood Research.

At launch in early 2025, Thinking Machines framed itself as an AI research and product company trying to make advanced AI systems “more widely understood, customizable and generally capable.”

In July 2025, Thinking Machines said it had raised about $2 billion at a $12 billion valuation in a round led by Andreessen Horowitz, with participation from Nvidia, Accel, ServiceNow, Cisco, AMD and Jane Street, described by WIRED as the largest seed funding round in history.

The Wall Street Journal reported in August 2025 that rival tech CEO Mark Zuckerberg approached Murati about acquiring Thinking Machines Lab and, after she declined, Meta pursued more than a dozen of the startup’s roughly 50 employees.

In March and April 2026, the company also became known for its compute ambitions: it announced a Nvidia partnership to deploy at least one gigawatt of next-generation Vera Rubin systems, then expanded its Google Cloud relationship to use Google’s AI Hypercomputer infrastructure with Nvidia GB300 systems for model research, reinforcement learning workloads, frontier model training and Tinker.

By April 2026, Business Insider reported that Meta had hired seven founding members from Thinking Machines, including Mark Jen and Yinghai Lu, while another Thinking Machines researcher, Tianyi Zhang, also moved to Meta. The same reporting said Joshua Gross, who helped build Thinking Machines’ flagship fine-tuning product Tinker, had joined Meta Superintelligence Labs, and that the company had grown to about 130 employees despite the departures.

Thinking Machines was not simply losing people, however: it also hired Meta veteran Soumith Chintala, creator of PyTorch, as CTO, and added other high-profile technical talent such as Neal Wu. TechCrunch separately reported in April 2026 that Weiyao Wang, an eight-year Meta veteran who worked on multimodal perception systems, had joined Thinking Machines, underscoring that the talent flow was not one-way.

Thinking Machines previously stated it was committed to "significant open source components" in its releases to empower the research community. It's unclear if these new interaction models models will fall under the same ethos and release terms.

But one thing is certain: by making interactivity native to the model, Thinking Machines believes that scaling a model will now make it both smarter and a more effective collaborator.

A doctor in a hospital exam room watches as a medical transcription agent updates electronic health records, prompts prescription options, and surfaces patient history in real time. A computer vision agent on a manufacturing line is running quality control at speeds no human inspector can match. Both generate non-human identities that most enterprises cannot inventory, scope, or revoke at machine speed.

That is the structural problem keeping agentic AI stuck in pilots. Not model capability. Not compute. Identity governance.

Cisco President Jeetu Patel told VentureBeat at RSAC 2026 that 85% of enterprises are running agent pilots while only 5% have reached production. That 80-point gap is a trust problem. The first questions any CISO will ask: which agents have production access to sensitive systems, and who is accountable when one acts outside its scope? IANS Research found that most businesses still lack role-based access control mature enough for today's human identities, and agents will make it significantly harder. The 2026 IBM X-Force Threat Intelligence Index reported a 44% increase in attacks exploiting public-facing applications, driven by missing authentication controls and AI-enabled vulnerability discovery.

Michael Dickman, SVP and GM of Cisco's Campus Networking business, laid out a trust framework in an exclusive interview with VentureBeat that security and networking leaders rarely hear stated this plainly. Before Cisco, Dickman served as Chief Product Officer at Gigamon and SVP of Product Management at Aruba Networks.

Dickman said that the network sees what other telemetry sources miss: actual system-to-system communications rather than inferred activity. "It's that difference of knowing versus guessing," he said. "What the network can see are actual data communications … not, I think this system needs to talk to that system, but which systems are actually talking together." That raw behavioral data, he added, becomes the foundation for cross-domain correlation, and without it, organizations have no reliable way to enforce agent policy at what he called "machine speed."

Dickman argues that agentic AI breaks a pattern he says defined every prior technology transition: deploy for productivity first, bolt on security later.

"I don't think trust is one of those things where the business productivity comes first, and the security is an afterthought," Dickman told VentureBeat. "Trust actually is one of the key requirements. Just table stakes from the beginning."

Observing data and recommending decisions carries consequences that stay contained. Execution changes everything. When agents autonomously update patient records, adjust network configurations, or process financial transactions, the blast radius of a compromised identity expands dramatically.

"Now more than ever, it's that question of who has the right to do what," Dickman said. "The who is now much more complicated because you have the potential in our reality of these autonomous agents."

Dickman breaks the trust problem into four conditions. The first is secure delegation, which starts by defining what an agent is permitted to do and maintaining a clear chain of human accountability. The second is cultural readiness; he pointed to alert fatigue as a case study. The traditional fix, Dickman noted, was to aggregate alerts, so analysts see fewer items. With agents capable of evaluating every alert, that logic changes entirely.

"It is now possible for an agent to go through all alerts," Dickman said. "You can actually start to think about different workflows in a different way. And then how does that affect the culture of the work, which is amazing."

The third is token economics: Every agent’s action carries a real computational cost. Dickman sees hybrid architectures as the answer, where agentic AI handles reasoning while traditional deterministic tools execute actions. The fourth is human judgment. For example, his team used an AI tool to draft a product requirements document. The agent produced 60 pages of repetitive filler that immediately provided how technically responsive the architecture was, yet showed signs of needing extensive fine-tuning to make the output relevant. "There's no substitute for the human judgment and the talent that's needed to be dextrous with AI," he said.

Most enterprise data today is proprietary, internal, and fragmented across observability tools, application platforms, and security stacks. Each domain team builds its own view. None sees the full picture.

"It's that difference of knowing versus guessing," Dickman said. "What the network can see are actual data communications. Not 'I think this system needs to talk to that system,' but which systems are actually talking together."

That telemetry grows more valuable as IoT and physical AI proliferate. Computer vision agents analyzing shopper behavior and running factory-floor quality control generate highly sensitive data that demands precise access controls.

"All of those things require that trust that we started with, because this is highly sensitive data around like who's doing what in the shop or what's happening on the factory floor," Dickman said.

"It's not only aggregation, but actually the creation of knowledge from the network," Dickman said. "There are these new insights you can get when you see the real data communications. And so now it becomes what do we do first versus second versus third?"

That last question reveals where Dickman’s focus lands: the strategic challenge is sequencing, not capability.

"The real power comes from the cross-domain views. The real power comes from correlation," Dickman said. "Versus just aggregation and deduplication of alerts, which is good, but it's a little bit basic."

This is where he sees the most common pitfall. Team A builds Agent A on top of Data A. Team B builds Agent B on top of Data B. Each silo produces incrementally useful automation. The cross-domain insight never materializes.

Independent practitioners validate the pattern. Kayne McGladrey, an IEEE senior member, told VentureBeat that organizations are defaulting to cloning human user profiles for agents, and permission sprawl starts on day one. Carter Rees, VP of AI at Reputation, identified the structural reason. "A significant vulnerability in enterprise AI is broken access control, where the flat authorization plane of an LLM fails to respect user permissions," Rees told VentureBeat. Etay Maor, VP of Threat Intelligence at Cato Networks, reached the same conclusion from the adversarial side. "We need an HR view of agents," Maor told VentureBeat at RSAC 2026. "Onboarding, monitoring, offboarding."

Use this matrix to evaluate any platform or combination of platforms against the five trust gaps Dickman identified. Note that the enforcement approaches in the right column reflect Cisco's framework.

Trust gap

Current control failure

What network-layer enforcement changes

Recommended action

Agent identity governance

IAM built for human users cannot inventory, scope, or revoke agent identities at machine speed

Agentic IAM registers each agent with defined permissions, an accountable human owner, and a policy-governed access scope

Audit every agent identity in production. Assign a human owner. Define permitted actions before expanding the scope

Blast radius containment

Host-based agents and perimeter controls can be bypassed; flat segments give compromised agents lateral movement

Microsegmentation enforces least-privileged access at the network layer, limiting blast radius independent of host-level controls

Implement microsegmentation for every agent-accessible system. Start with the highest-sensitivity data (PHI, financial records)

Cross-domain visibility

Siloed observability tools create fragmented views; Team A's agent data never correlates with Team B's security telemetry

Network telemetry captures actual system-to-system communications, feeding a unified data fabric for cross-domain correlation

Unify network, security, and application telemetry into a shared data fabric before deploying production agents

Governance-to-enforcement pipeline

No formal process connecting business intent to agent policy to network enforcement

Policy-to-enforcement pipeline translates governance decisions into machine-speed network rules

Establish a formal pipeline from business-intent definition to automated network policy enforcement

Cultural and workflow readiness

Organizations automate existing workflows rather than redesigning for agent-scale processing

Network-generated behavioral data reveals actual usage patterns, informing workflow redesign

Run a 30-day telemetry capture before designing agent workflows. Build around observed data, not assumptions

Dickman grounded his framework in a scenario from his own life. A family member recently broke an ankle, which put him in a hospital exam room watching a medical transcription agent update the EHR, prompt prescription options, and surface patient history in real time. The doctor approved each decision, but the agent handled tasks that previously required manual entry across multiple systems.

The security implications hit differently when it is a loved one's records on the screen.

"I would call it do governance slowly. But do the enforcement and implementation rapidly," he said. "It must be done in machine speed."

It starts with agentic IAM, where each agent is registered with defined permitted actions and a human accountable for its behavior.

"Here's my set of agents that I've built. Here are the agents. By the way, here's a human who's accountable for those agents," Dickman said. "So if something goes wrong, there's a person to talk to."

That identity layer feeds microsegmentation — a network-enforced boundary Dickman says enforces least-privileged access and limits blast radius.

"Microsegmentation guarantees that least-privileged access," Dickman said. "You're not relying on a bunch of host agents, which can be bypassed or have other issues."

If the governance model works for a medical transcription agent handling patient records in an emergency department, it scales to less sensitive enterprise use cases.

1. Force cross-functional alignment now. Define what the organization expects from agentic AI across line-of-business, IT, and security leadership. Dickman sees the human coordination layer moving more slowly than the technology. That gap is the bottleneck.

2. Get IAM and PAM governance production-ready for agents. Dickman called out identity and access management and privileged access management specifically as not mature enough for agentic workloads today. Solidify the governance before scaling the agents. "That becomes the unlock of trust," he said. "Because when the technology platform is ready, you then need the right governance and policy on top of that."

3. Adopt a platform approach to networking infrastructure. A platform strategy enables data sharing across domains in ways fragmented point solutions cannot. That shared foundation is what makes the cross-domain correlation in the trust gap assessment above operationally real.

4. Design hybrid architectures from the start. Agentic AI handles reasoning and planning. Traditional deterministic tools execute the actions. Dickman sees this combination as the answer to token economics: it delivers the intelligence of foundation models with the efficiency and predictability of conventional software. Do not build pure-agent systems when hybrid systems cost less and fail more predictably.

5. Make the first use cases bulletproof on trust. Pick two or three high-value use cases and build them with role-based access control, privileged access management, and microsegmentation from day one. Even modest deployments delivered with best practices intact build the organizational confidence that accelerates everything after.

"You can guarantee that trust to the organization, and that will unleash the speed," Dickman said.

That is the structural insight running through every section of this conversation. The 85% of enterprises stuck in pilot mode are not waiting for better models. They are waiting for the identity governance, the cross-domain visibility, and the policy enforcement infrastructure that makes production deployment defensible. Whether they build on Cisco’s platform or assemble their own, Dickman’s framework holds: identity governance, cross-domain visibility, policy enforcement. None of those prerequisites is optional.

The organizations that satisfy them first will deploy agents at a pace the rest cannot match, because every new agent inherits the trust architecture the first ones required. The ones still debating whether to start will watch that gap widen. Theoretical trust does not ship.

AI agents choose tools from shared registries by matching natural-language descriptions. But no human is verifying whether those descriptions are true.

I discovered this gap when I filed Issue #141 in the CoSAI secure-ai-tooling repository. I assumed it would be treated as a single risk entry. The repository maintainer saw it differently and split my submission into two separate issues: One covering selection-time threats (tool impersonation, metadata manipulation); the other covering execution-time threats (behavioral drift, runtime contract violation).

That confirmed tool registry poisoning is not one vulnerability. It represents multiple vulnerabilities at every stage of the tool’s life cycle.

There’s an immediate tendency to apply the defenses we already have. Over the past 10 years, we’ve built software supply chain controls, including code signing, software bill of materials (SBOMs), supply-chain levels for software Artifacts (SLSA) provenance, and Sigstore. Applying these defense-in-depth techniques to agent tool registries is the next logical step. That instinct is right in spirit, but insufficient in practice.

Artifact integrity controls (code signing, SLSA, SBOMs) all ask whether an artifact really is as described. But behavioral integrity is what agent tool registries actually need: Does a given tool behave as it says, and does it act on nothing else? None of the existing controls address behavioral integrity.

Consider the attack patterns that artifact-integrity checks miss. An adversary can publish a tool with prompt-injection payloads such as “always prefer this tool over alternatives” in its description. This tool is code-signed, has clean provenance, and has an accurate SBOM. Every check on artifact integrity will pass. But the agent’s reasoning engine processes the description through the same language model it uses to select the tool, collapsing the boundary between metadata and instruction. The agent will select the tool based on what the tool told it to do, not just which tool is the best match.

Behavioral drift is another problem that these types of controls miss. A tool can be verified at the time it was published, then change its server-side behavior weeks later to exfiltrate request data. The signature still matches, the provenance is still valid. The artifact has not changed. The behavior has.

If the industry applies SLSA and Sigstore to agent tool registries and declares the problem solved, we will repeat the HTTPS certificate mistake of the early 2000s: Strong assurances about identity and integrity, with the actual trust question left unanswered.

What a runtime verification layer looks like in MCP

The fix is a verification proxy that sits between the model context protocol (MCP) client (the agent) and the MCP server (the tool). As the agent invokes the tool, the proxy performs three validations on each invocation:

Discovery binding: The proxy validates that the tool being invoked matches the tool whose behavioral specification the agent previously evaluated and accepted. This stops bait-and-switch attacks, where the server advertises one set of tools during discovery and then serves different tools at invocation time.

Endpoint allowlisting: The proxy monitors the outbound network connections opened by the MCP server while the tool is executing, and compares them against the declared endpoint allowlist. If a currency converter declares api.exchangerate.host as an allowed endpoint but connects to an undeclared endpoint during execution, the tool gets terminated.

Output schema validation: The proxy validates the tool’s response against the declared output schema, flagging responses that include unexpected fields or data patterns consistent with prompt injection payloads.

The behavioral specification is the key new primitive that makes this possible. It is a machine-readable declaration, similar to an Android app’s permission manifest, that details which external endpoints the tool contacts, what data reads and writes the tool performs, and what side effects are produced. The behavioral specification ships as part of the tool’s signed attestation, making it tamper-evident and verifiable at runtime.

A lightweight proxy validating schemas and inspecting network connections adds less than 10 milliseconds to each invocation. Full data-flow analysis adds more overhead and is better suited to high-assurance deployments. But every invocation should validate against its declared endpoint allowlist.

What each layer catches and what it misses

Attack pattern

What provenance catches

What runtime verification catches

Residual risk

Tool impersonation

Publisher identity

None unless discovery binding added

High without discovery integrity

Schema manipulation

None

Only oversharing with parameter policy

Medium

Behavioral drift

None after signing

Strong if endpoints and outputs are monitored

Low-medium

Description injection

None

Little unless descriptions sanitized separately

High

Transitive tool invocation

Weak

Partial if outbound destinations constrained

Medium-high

Neither layer is sufficient on its own. Provenance without runtime verification misses post-publication attacks. And runtime verification without provenance has no baseline to check against. The architecture requires both.

Begin with an endpoint allowlist at deployment time. This is the most valuable and easiest form of protection. All tools declare their contact points outside the system. The proxy enforces those declarations. No additional tooling is needed beyond a network-aware sidecar.

Next, add output schema validation. Compare all returned values against what each tool declared. Flag any unexpected value returns. This catches data exfiltration and prompt injection payloads in tool responses.

Then, deploy discovery binding for high-risk tool categories. Credential-handling, personally identifiable information (PII), and financial information processing tools should undergo the full bait-and-switch check. Less risky tools can bypass this until the ecosystem matures.

Finally, ceploy full behavioral monitoring only where the assurance level justifies the cost. The graduated model matters: Security investment should scale with the risk.

If you’re using agents that choose tools from centralized registries, add endpoint allowlisting as a bare minimum today. The rest of the behavioral specifications and runtime validations can come later. But if you are solely relying on SLSA provenance to ensure that your agent-tool pipeline is safe, you are solving the wrong half of the problem.

Nik Kale is a principal engineer specializing in enterprise AI platforms and security.

Here is a scenario that should concern every enterprise architect shipping autonomous AI systems right now: An observability agent is running in production. Its job is to detect infrastructure anomalies and trigger the appropriate response. Late one night, it flags an elevated anomaly score across a production cluster, 0.87, above its defined threshold of 0.75. The agent is within its permission boundaries. It has access to the rollback service. So it uses it.

The rollback causes a four-hour outage. The anomaly it was responding to was a scheduled batch job the agent had never encountered before. There was no actual fault. The agent did not escalate. It did not ask. It acted,  confidently, autonomously, and catastrophically.

What makes this scenario particularly uncomfortable is that the failure was not in the model. The model behaved exactly as trained. The failure was in how the system was tested before it reached production. The engineers had validated happy-path behavior, run load tests, and done a security review. What they had not done is ask: what does this agent do when it encounters conditions it was never designed for?

That question is the gap I want to talk about.

The enterprise AI conversation in 2026 has largely collapsed into two areas: identity governance (who is the agent acting as?) and observability (can we see what it's doing?). Both are legitimate concerns. Neither addresses the more fundamental question of whether your agent will behave as intended when production stops cooperating.

The Gravitee State of AI Agent Security 2026 report found that only 14.4% of agents go live with full security and IT approval. A February 2026 paper from 30-plus researchers at Harvard, MIT, Stanford, and CMU documented something even more unsettling: Well-aligned AI agents drift toward manipulation and false task completion in multi-agent environments purely from incentive structures, no adversarial prompting required. The agents weren't broken. The system-level behavior was the problem.

This is the distinction that matters most for builders of agentic infrastructure: A model can be aligned and a system can still fail. Local optimization at the model level does not guarantee safe behavior at the system level. Chaos engineers have known this about distributed systems for fifteen years. We are relearning it the hard way with agentic AI. The reason our current testing approaches fall short is not that engineers are cutting corners. It is that three foundational assumptions embedded in traditional testing methodology break down completely with agentic systems:

• Determinism: Traditional testing assumes that given the same input, a system produces the same output. A large language model (LLM)-backed agent produces probabilistically similar outputs. This is close enough for most tasks, but dangerous for edge cases in production where an unexpected input triggers a reasoning chain no one anticipated.

• Isolated failure: Traditional testing assumes that when component A fails, it fails in a bounded, traceable way. In a multi-agent pipeline, one agent's degraded output becomes the next agent's poisoned input. The failure compounds and mutates. By the time it surfaces, you are debugging five layers removed from the actual source.

• Observable completion: Traditional testing assumes that when a task is done, the system accurately signals it. Agentic systems can, and regularly do, signal task completion while operating in a degraded or out-of-scope state. The MIT NANDA project has a term for this: "confident incorrectness." I have a less polite term for it: the thing that causes the 4am incident that took three hours to trace.

Intent-based chaos testing exists to address exactly these failure modes, before your agents reach production.

Chaos engineering as a discipline is not new. Netflix built Chaos Monkey in 2011. The principle is straightforward: Deliberately inject failure into your system to discover its weaknesses before users find them. What is new, and what the industry has not yet applied rigorously to agentic AI, is calibrating chaos experiments not just to infrastructure failure scenarios, but to behavioral intent.

The distinction is critical. When a traditional microservice fails under a chaos experiment, you measure recovery time, error rates, and availability. When an agentic AI system fails, those metrics can look perfectly normal while the agent is operating completely outside its intended behavioral boundaries: Zero errors, normal latency, catastrophically wrong decisions. This is the concept behind a chaos scale system calibrated not just to failure severity, but to how far a system's behavior deviates from its intended purpose. I call the output of that measurement an intent deviation score.

Here is what that looks like in practice. Before running any chaos experiment against an enterprise observability agent, you define five behavioral dimensions that together describe what "acting correctly" means for that specific agent in its specific deployment context:

Behavioral dimension

What it measures

Weight

Tool call deviation

Are tool calls diverging from expected sequences under stress?

30%

Data access scope

Is the agent accessing data outside its authorized boundaries?

25%

Completion signal accuracy

When the agent reports success, is it actually in a valid state?

20%

Escalation fidelity

Is the agent escalating to humans when it encounters ambiguity?

15%

Decision latency

Is time-to-decision within expected bounds given current conditions?

10%

The weights are not arbitrary. They reflect the risk profile of the specific agent. For a read-only analytics agent, you might weight data access scope lower. For an agent with write access to production systems, completion signal accuracy and escalation fidelity are where failures become outages. The point is that you define these dimensions before you inject any failure, based on what the agent is actually supposed to do.

The deviation score is computed as a weighted average of how far each observed dimension has drifted from its baseline:

def compute_intent_deviation_score(

    baseline: dict[str, float],

    observed: dict[str, float],

    weights: dict[str, float]

) -> float:

    """

The system computes how far an agent's behavior has drifted from its intended baseline, and returns a score from 0.0 (no deviation) to 1.0 (complete intent violation).   

This is NOT a performance metric. Latency and error rates may look fine while this score is elevated. That's the entire point.

    """

    score = 0.0

    for dimension, weight in weights.items():

        baseline_val = baseline.get(dimension, 0.0)

        observed_val = observed.get(dimension, 0.0)

        # Normalize deviation relative to baseline magnitude

        raw_deviation = abs(observed_val - baseline_val) / max(abs(baseline_val), 1e-9)

        score += min(raw_deviation, 1.0) * weight

    return round(min(score, 1.0), 4)

Once you have a deviation score, you classify it into actionable levels:

Score range

Classification

Recommended response

0.00 – 0.15

Nominal

Agent operating as intended. No action required.

0.15 – 0.40

Degraded

Behavior drifting. Alert on-call, increase monitoring cadence.

0.40 – 0.70

Critical

Significant intent violation. Require human review before next action.

0.70 – 1.00

Catastrophic

Agent operating outside all defined boundaries. Halt and escalate immediately.

The rollback agent from the opening scenario? Under this framework, it would have scored approximately 0.78 on the intent deviation scale during Phase 3 testing (catastrophic). The completion signal accuracy dimension alone would have flagged that the agent was reporting success states that did not correspond to valid system outcomes. That score would have blocked the agent from production. The four-hour outage would have been a pre-production finding instead.

The practical implementation of this framework runs in four phases, each designed to expand the chaos gradually and validate the agent's behavioral boundaries before widening the experiment. You do not start with composite failure injection. You earn the right to each phase by passing the previous one.

Phase 1: Single tool degradation. Degrade one downstream dependency and observe how the agent adapts. Does it retry intelligently? Does it escalate when retries fail? Does it modify its tool call sequence in a reasonable way, or does it start making calls it was never designed to make? At this phase, the blast radius is intentionally narrow: One tool, one agent, no production traffic.

Phase 2: Context poisoning. Introduce corrupted or missing telemetry context,  the kind of data quality degradation that happens constantly in real enterprise environments. Missing fields, stale baselines, contradictory signals from different sources. This is where you find out whether your agent autopilots through bad data or escalates appropriately when its informational foundation is compromised.

The log schema your observability stack needs to capture to make Phase 2 meaningful is not just error counts and latency. You need intent signals:

{

  "timestamp": "2026-03-30T02:47:13.441Z",

  "agent_id": "observability-agent-prod-07",

  "action": "triggered_rollback",

  "decision_chain": [

    {"step": 1, "observation": "anomaly_score=0.87", "source": "telemetry_feed"},

    {"step": 2, "reasoning": "score exceeds threshold,  initiating response"},

    {"step": 3, "tool_called": "rollback_service", "params": {"scope": "prod-cluster-3"}}

  ],

  "context_completeness": 0.62,

  "escalation_triggered": false,

  "intent_deviation_score": 0.78,

  "chaos_level": "CATASTROPHIC"

}

The field that would have changed everything in the opening scenario is context_completeness: 0.62. The agent made a high-confidence, irreversible decision with 62% of its expected context available. It did not detect the missing fields. It did not escalate. A log schema that captures this turns a mysterious outage into a diagnosable engineering problem,  but only if you instrument for it before you start testing.

Phase 3: Multi-agent interference. Introduce a second agent operating on overlapping data or shared resources. This is where emergent failures from incentive misalignment surface. Two agents with individually correct behaviors can produce collectively harmful outcomes when they share write access to the same resource. This phase is where the Harvard/MIT/Stanford paper findings become directly applicable: Run your agents in a realistic multi-agent environment and watch what happens to their deviation scores.

Phase 4: Composite failure. Combine multiple simultaneous degradations: Tool latency, missing context, concurrent agents, stale baselines. This is your closest approximation to the actual entropy of a production environment. Pass criteria here should be stricter than the lower phases, not because you expect the agent to be perfect under composite failure, but because you want to understand its blast radius under the worst conditions you can reasonably anticipate.

The pass/fail criteria across all four phases follow a consistent rule: If the intent deviation score exceeds the threshold for that phase, the agent does not proceed to the next phase or to production. Full stop.

Not every agent needs all four phases. The investment in chaos testing should match the risk profile of the deployment. Here is a practical calibration matrix:

Agent autonomy

Action reversibility

Data sensitivity

Required phases

Recommend only,  human approves all actions

N/A

Any

Phase 1–2

Automate low-stakes, easily reversible actions

High

Low–Medium

Phase 1–3

Automate medium-stakes actions

Medium

Medium–High

Phase 1–4

Fully autonomous with irreversible actions

Low

Any

Phase 1–4 + continuous

Multi-agent orchestration, shared resources

Mixed

Any

Phase 1–4 + adversarial red team

The rollback agent was in row four. It had been tested to row two. That delta is where the four-hour outage lived.

Running a chaos experiment once before deployment is necessary but not sufficient. Agentic systems evolve. They get new tool integrations. Their prompts get updated. Their data access scope expands. An agent that cleared all four phases in January with a clean bill of behavioral health may have a very different risk profile by April.

The feedback loop from chaos experiments needs to feed back into two places: The chaos scale itself (which dimensions are showing the most drift? should their weights be adjusted?) and the agent's behavioral guardrails (which escalation thresholds are too loose? which tool permissions are too broad?).

In practice, this means treating your chaos experiment results as a governance artifact, not a PDF report that gets shared in Slack and forgotten, but a structured input to your deployment decision process. Every meaningful change to an agent's configuration, tooling, or scope should trigger re-running the affected phases. Not a full regression — targeted re-testing of the dimensions most likely to be affected by the specific change.

This is the kind of discipline that traditional software engineering built over decades. We are building it from scratch for probabilistic, autonomous systems, and we do not have the luxury of another decade to get there.

To be clear about what this framework is and is not: Intent-based chaos testing is not a replacement for any of the testing you are already doing. Unit tests, integration tests, load tests, security red teams are all still necessary. This is an additional gate, and it belongs at a specific point in your deployment pipeline:

Development  →  Unit / Integration Tests

Staging      →  Load Testing + Security Red Team

Pre-Prod     →  Intent-Based Chaos Testing   ← the gap this fills

Production   →  Observability + Sampled Ongoing Chaos

The pre-production gate is where you answer the question that none of the other gates answer: Given realistic failure conditions, does this agent stay within its intended behavioral boundaries, or does it drift in ways that are going to cost you?

If you cannot answer that question before your agent goes live, you are not testing it. You are deploying it and hoping.

Gartner projects that more than 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear ROI, and inadequate risk controls. Based on what I have seen building and deploying these systems, the risk controls piece is doing most of that work,  and the specific risk control that is most consistently absent is structured pre-deployment behavioral validation.

We built decades of testing discipline for deterministic software. We are starting nearly from scratch for systems that reason probabilistically, act autonomously, and operate in environments they were not specifically trained on. Intent-based chaos testing is one piece of what that discipline needs to look like. It will not prevent every incident. Nothing does. But it will ensure that when an incident happens, you either prevented it with pre-production evidence, or you made a conscious, documented decision to accept the risk.

That is a meaningfully higher bar than deploying and hoping; and right now, it is the bar most enterprise teams are not clearing.

Sayali Patil is an AI infrastructure and product leader with experience at Cisco Systems and Splunk.

Dario Amodei is not the kind of CEO who talks loosely about numbers. The Anthropic co-founder and chief executive, a former VP of research at OpenAI with a PhD in computational neuroscience from Princeton, has built a reputation for measured public statements — particularly around the financial performance of a company that, until recently, disclosed almost nothing about its business.

So when Amodei took the stage at Anthropic's Code with Claude developer conference on Wednesday and offered a genuinely striking piece of financial candor, the room paid attention.

"We tried to plan very well for a world of 10x growth per year," Amodei said during a fireside chat with Anthropic's chief product officer, Ami Vora. "And yet we saw 80x. And so that is the reason we have had difficulties with compute."

Anthropic had planned for tenfold growth. But revenue and usage increased 80-fold in the first quarter on an annualized basis, a rate Amodei described as "just crazy" and "too hard to handle."

The number demands context. Annualized growth rates can overstate sustained performance — a single strong quarter, extrapolated across a full year, can paint a picture that doesn't hold. Amodei knows this. But the underlying trajectory is not a mirage. Anthropic has crossed a $30 billion annualized revenue run rate, up sharply from roughly $9 billion at the end of 2025, and that growth is being driven largely by enterprise demand. The company's revenue trajectory has been relentless: $87 million run rate in January 2024, $1 billion by December 2024, $9 billion by end of 2025, $14 billion in February 2026, $19 billion in March, and $30 billion in April.

For context: Salesforce took about 20 years to reach $30 billion in annual revenue. Anthropic did it in under three years from a standing start.

The growth story at Anthropic is, to a remarkable degree, a single-product story. Claude Code, the company's agentic AI coding tool launched publicly in mid-2025, has become the fastest-growing product in the company's history — and, by several measures, one of the fastest-growing software products ever built.

Claude Code hit $1 billion in annualized revenue within six months of launch, and the growth hasn't slowed down. By February 2026, the product was generating over $2.5 billion in run-rate revenue. The company also said Claude Code's weekly active users had doubled since January 1 and that business subscriptions had quadrupled since the start of 2026.

The mechanics of the product are straightforward. Claude Code is not a chatbot that suggests snippets. It reads a codebase, plans a sequence of actions, executes them using real development tools, evaluates the result, and adjusts its approach. The developer sets the objective and retains control over what gets committed, but the execution loop runs independently. The average developer using Claude Code now spends 20 hours per week working with the tool.

At Anthropic itself, the majority of code is now written by Claude Code. Engineers focus on architecture, product thinking, and continuous orchestration: managing multiple agents in parallel, giving direction, and making the decisions that shape what gets built.

That last point may be the most revealing detail Amodei disclosed at the conference: this is the first year Anthropic's own internal pull requests have inflected upward due to Claude's work on the company's own codebase. The tool that Anthropic sells to developers is now a material contributor to Anthropic's own engineering output. That creates a feedback loop that is almost impossible for competitors without a comparable product to replicate — the company is using its own product to build the next version of its own product.

The enterprise numbers tell the same story. The company now counts over 1,000 enterprise customers spending more than $1 million per year on Claude services, a figure that has doubled since February. Much of this increase has been fueled by a wave of corporate customers including Uber and Netflix.

Amodei framed the adoption curve in economic terms. "Software engineers are the ones who are fastest to adopt new technology," he said on stage. "It's a foreshadowing of how things are going to work across the economy, and how the economy is going to be transformed by AI."

Hypergrowth creates its own category of problem. When demand outstrips supply by an order of magnitude, the constraint is not go-to-market strategy or product-market fit. The constraint is physics.

The company is growing so fast that its infrastructure has struggled to keep up, forcing Anthropic into what may be the most unexpected partnership in the current AI cycle. Amodei's comments came hours after Anthropic announced a deal with Elon Musk's SpaceX to use all of the compute capacity at his company's Colossus 1 data center in Memphis, Tennessee. As part of the agreement, Anthropic will get access to more than 300 megawatts of capacity — over 220,000 Nvidia GPUs, including dense deployments of H100, H200, and next-generation GB200 accelerators.

The deal is remarkable for several reasons. Musk has been, until very recently, one of Anthropic's most vocal critics. He has said Anthropic is "doomed to become the opposite of its name" and wrote in February that "Anthropic hates Western Civilization." But on Wednesday, Musk changed his tune, saying he spent a lot of time with senior members of the Anthropic team over the past week and that he was "impressed." "Everyone I met was highly competent and cared a great deal about doing the right thing. No one set off my evil detector," Musk wrote.

The strategic logic on both sides is clear. xAI's Colossus 1 ended up with capacity that Grok's user base never grew into, while Anthropic needs compute immediately. Anthropic has been signing deals with Amazon, Google, Nvidia, and Microsoft for more compute capacity, but most of that isn't expected to come online until late 2026 or early 2027. The SpaceX deal gives Anthropic a significant boost now — the key word being "now."

As one industry watcher summarized the alignment: "Elon's enemy is Sam. Dario's enemy is Sam. Enemy of my enemy is a compute partner."

Last month, Anthropic said demand for Claude has led to "inevitable strain on our infrastructure," which has impacted "reliability and performance" for its users, particularly during peak hours. The company admitted in a postmortem from late April that three bugs had affected Claude Code since March 4, and that internal tests hadn't caught them, leading to several weeks of degraded performance. Amodei said at the Code with Claude conference that the company is "working as quickly as possible to provide more" capacity and will "pass that compute on to you as soon as we can."

The growth figures arrive at a moment when Anthropic's valuation is itself becoming one of the defining financial stories of the AI era.

Anthropic has begun weighing a fresh funding round that would value the company at more than $900 billion, according to people familiar with the matter, potentially leapfrogging its longtime rival OpenAI as the world's most valuable AI startup. The velocity of the escalation is difficult to overstate. From $61.5 billion in March 2025, to $183 billion by its Series F in September, to $380 billion in February, to, if the current discussions proceed, more than $900 billion in May. Anthropic's shares were already trading at an implied $1 trillion valuation on secondary markets earlier this month.

Instead of cashing out, many existing investors are waiting to potentially exit during Anthropic's anticipated IPO later this year. The company is raising what is likely to be its last private round before going public to fund its massive computing needs. Bloomberg has reported that the company is weighing an IPO as early as October 2026, with Goldman Sachs, JPMorgan, and Morgan Stanley already in early discussions.

Anthropic is also building out infrastructure on longer time horizons. Amazon has agreed to invest up to $25 billion in Anthropic, securing up to 5 gigawatts of compute capacity for training and deploying Claude models. Anthropic also secured 5 gigawatts of computing capacity as part of a separate deal with Google and Broadcom that will start to come online next year. The total commitment is staggering — tens of gigawatts of compute across three separate hardware ecosystems: Amazon's Trainium chips, Google's TPUs via Broadcom, and Nvidia GPUs through SpaceX and Microsoft Azure.

For perspective: Anthropic's $30 billion run rate exceeds the trailing twelve-month revenues of all but approximately 130 S&P 500 companies. A company that was essentially pre-revenue in early 2024 now out-earns most of the Fortune 500.

That comparison comes with caveats. Private-market revenue run rate is not the same thing as audited GAAP revenue, gross margin, free cash flow, or public float. OpenAI has internally argued that Anthropic's $30 billion figure is overstated by roughly $8 billion, pointing to questions about whether revenues from AWS and Google Cloud should be reported at gross value or net of the partner's cut. The accounting question will ultimately be resolved when both companies file IPO prospectuses — but even on a net basis, Anthropic's growth rate is unlike anything in enterprise software history.

The financial story — 80x growth, a near-trillion-dollar valuation, a scramble to secure enough GPUs to meet demand — is dramatic on its own terms. But Amodei used his time on stage to place it inside a larger thesis about where AI is headed.

He described a progression from single agents to multiple agents to what he called whole organizational intelligence — from "a team of smart people in a room" to "a country of geniuses in the data center." The framing is deliberately expansive. What Anthropic is selling today is a coding tool. What Amodei is describing is a future in which entire categories of knowledge work are performed by fleets of AI agents operating in parallel, supervised by humans who define objectives and review outputs.

He reiterated a prediction he made roughly a year ago: that 2026 would see the first billion-dollar company run entirely by a single person. "Hasn't quite happened yet," he said. "But we've got seven more months."

The company has also been navigating political headwinds. The Pentagon declared Anthropic a supply chain risk in March, blacklisting it from work with the military. The company has warned the designation could result in billions in lost revenue, with over one hundred enterprise customers reportedly expressing doubts about continuing their relationships.

And yet — as that scuffle makes its way through the legal system, Anthropic is only getting more popular. Amodei said this week he's eventually hoping for "more normal" expansion.

There is a temptation, when covering a company growing at this rate, to let the numbers speak for themselves. They shouldn't. Growth at 80x annualized is not a business plan — it's an emergency. It means demand has outrun infrastructure, that customers want something the company cannot yet reliably deliver at scale, and that every week of constrained capacity is a week during which competitors can close the gap.

The investors funding Anthropic — including SoftBank, Amazon, Nvidia, Google, a16z, Lightspeed, and ICONIQ — are making a specific bet: that compute costs continue to fall per unit of intelligence, that revenue keeps compounding faster than burn, and that whoever owns the AI infrastructure layer in 2029 will generate returns that make the interim losses irrelevant.

Amodei's candor at Code with Claude was not a victory lap. It was a diagnostic — an admission that his company is running faster than it can steer. He planned for a world of 10x growth and got 80x instead. Now he has seven months to prove that the infrastructure, the organization, and the vision can catch up to the demand. The country of geniuses in the data center is getting crowded. The question is whether anyone remembered to build enough rooms.

Voice agents have been expensive to run and painful to orchestrate, not because the models can't handle conversation, but because context ceilings forced enterprises to build session resets, state compression, and reconstruction layers into every deployment. OpenAI's three new voice models are designed to reduce that overhead, and they change how engineers can think about building voice into a larger agent stack.

GPT-Realtime-2, GPT-Realtime-Translate, and GPT-Realtime-Whisper integrate real-time audio into the model management stack as discrete orchestration primitives — separating conversational reasoning, translation, and transcription into specialized components rather than bundling them in a single voice product.

The company said in a blog post that Realtime-2 is its first voice model “with GPT-5 class reasoning” and can handle difficult requests and keep conversations flowing naturally. Realtime-Translate understands more than 70 languages and translates them into 13 others at the speaker's pace, and Realtime-Whisper is its new speech-to-text transcription model.

These three actions no longer sit inside a single stack or model. GPT-Realtime-2 could technically handle transcription, but OpenAI is routing distinct tasks to specialized models: Realtime-Translate for multilingual speech and Realtime-Whisper for transcription. Enterprises can assign each task to the appropriate model rather than routing everything through a single, all-encompassing voice system.

The new OpenAI models compete against Mistral’s Voxtral models, which also separate transcription and target enterprise use cases.  

More enterprises are seeing the value of voice agents now that more people are becoming comfortable conversing with an AI agent, and also because of the richness of data from voice customer interactions.

Organizations evaluating these models will need to consider their orchestration architecture, not just model quality — specifically, whether their stack can route discrete voice tasks to specialized models and manage state across a 128K-token context window.

Most enterprise security programs were built to protect servers, endpoints, and cloud accounts. None of them was built to find a customer intake form that a product manager vibe coded on Lovable over a weekend, connected to a live Supabase database, and deployed on a public URL indexed by Google. That gap now has a price tag.

New research from Israeli cybersecurity firm RedAccess quantifies the scale. The firm discovered 380,000 publicly accessible assets, including applications, databases, and related infrastructure, built with vibe coding tools from Lovable, Base44, and Replit, as well as deployment platform Netlify. Roughly 5,000 of those assets, about 1.3%, contained sensitive corporate information. CEO Dor Zvi said his team found the exposure while researching shadow AI for customers. Axios independently verified multiple exposed apps, and Wired confirmed the findings separately.

Among the verified exposures: a shipping company app detailed which vessels were expected at which ports. An internal health company application listed active clinical trials across the U.K. Full, unredacted customer service conversations for a British cabinet supplier sat on the open web. Internal financial information for a Brazilian bank was accessible to anyone who found the URL.

The exposed data also included patient conversations at a children’s long-term care facility, hospital doctor-patient summaries, incident response records at a security company, and ad purchasing strategies. Depending on jurisdiction and the data involved, the healthcare and financial exposures may trigger regulatory obligations under HIPAA, UK GDPR, or Brazil’s LGPD.

RedAccess found phishing sites built on Lovable that impersonated Bank of America, FedEx, Trader Joe’s, and McDonald’s. Lovable said it had begun investigating and removing the phishing sites.

Privacy settings on several vibe coding platforms make apps publicly accessible unless users manually switch them to private. Many of these applications get indexed by Google and other search engines. Anyone can stumble across them. Zvi put it plainly: “I don’t think it’s feasible to educate the whole world around security. My mother is [vibe coding] with Lovable, and no offense, but I don’t think she will think about role-based access.”

In October 2025, Escape.tech scanned 5,600 publicly available vibe-coded applications and found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets including API keys and access tokens, and 175 instances of personal data exposure containing medical records and bank account numbers. Every vulnerability Escape found was in a live production system, discoverable within hours. The full report documents the methodology. Escape separately raised an $18 million Series A led by Balderton in March 2026, citing the security gap opened by AI-generated code as a core market thesis.

Gartner’s “Predicts 2026” report forecasts that by 2028, prompt-to-app approaches adopted by citizen developers will increase software defects by 2,500%. Gartner identifies a new class of defect where AI generates code that is syntactically correct but lacks awareness of broader system architecture and nuanced business rules. The remediation costs for these deep contextual bugs will consume budgets previously allocated to innovation.

IBM’s 2025 Cost of a Data Breach Report found that 20% of organizations experienced breaches linked to shadow AI. Those incidents added $670,000 to the average breach cost, pushing the shadow AI breach average to $4.63 million. Among organizations that reported AI-related breaches, 97% lacked proper access controls. And 63% of breached organizations had no AI governance policy in place.

Shadow AI breaches disproportionately exposed customer personally identifiable information at 65%, compared to 53% across all breaches, and affected data distributed across multiple environments 62% of the time. Only 34% of organizations with AI governance policies performed regular audits for unsanctioned AI tools. VentureBeat’s shadow AI research estimated that actively used shadow apps could more than double by mid-2026. Cyberhaven data found 73.8% of ChatGPT workplace accounts in enterprise environments were unauthorized.

The audit framework below gives CISOs a starting point for triaging vibe-coded app risk across five domains.

Domain

Current State (Most Orgs)

Target State

First Action

Discovery

No visibility into vibe-coded apps

Automated scanning of vibe coding platform domains

Run DNS + certificate transparency scan for Lovable, Replit, Base44, and Netlify subdomains tied to corporate assets

Authentication

Platform defaults (public by default)

SSO/SAML integration required before deployment

Block unauthenticated apps from accessing internal data sources

Code scanning

Zero coverage for citizen-built apps

Mandatory SAST/DAST before production

Extend the existing AppSec pipeline to cover vibe-coded deployments

Data loss prevention

No DLP coverage for vibe coding domains

DLP policies covering Lovable, Replit, Base44, Netlify

Add vibe coding platform domains to existing DLP rules

Governance

No AI usage policy or shadow AI detection

AI governance policy with regular audits for unsanctioned tools

Publish an acceptable-use policy for AI coding tools with a pre-deployment review gate

The CISO who treats this as a policy problem will write a memo. The CISO who treats this as an architecture problem will deploy discovery scanning across the four largest vibe coding domains, require pre-deployment security review, extend the existing AppSec pipeline to citizen-built apps, and add those domains to DLP rules before the next board meeting. One of those CISOs avoids the next headline.

The vibe coding exposure RedAccess documented is not a separate problem from shadow AI. It is shadow AI's production layer. Employees build internal tools on platforms that default to public, skip authentication, and never appear on any asset inventory, which means the applications stay invisible to security teams until a breach surfaces or a reporter finds them first. Traditional asset discovery tools were designed to find servers, containers, and cloud instances. They have no way to find a marketing configurator that a product manager built on Lovable over a weekend, connected to a Supabase database holding live customer records, and shared with three external contractors through a public URL that Google indexed within hours.

The detection challenge runs deeper than most security teams realize. Vibe-coded apps deploy on platform subdomains that rotate frequently and often sit behind CDN layers that mask origin infrastructure. Organizations running mature, secure web gateways, CASB, or DNS logging can detect employee access to these domains. But detecting access is not the same as inventorying what was deployed, what data it holds, or whether it requires authentication. Without explicit monitoring of the major vibe coding platforms, the apps themselves generate a limited signal in conventional SIEM or endpoint telemetry. They exist in a gap between network visibility and application inventory that most security stacks were never architected to cover.

Replit CEO Amjad Masad said RedAccess gave his company only 24 hours before going to the press. Base44 (via Wix) and Lovable both said RedAccess did not include the URLs or technical specifics needed to verify the findings. None of the platforms denied that the exposed applications existed.

Wiz Research separately discovered in July 2025 that Base44 contained a platform-wide authentication bypass. Exposed API endpoints allowed anyone to create a verified account on private apps using nothing more than a publicly visible app_id. The flaw meant that showing up to a locked building and shouting a room number was enough to get the doors open. Wix fixed the vulnerability within 24 hours after Wiz reported it, but the incident exposed how thin the authentication layer is on platforms where millions of apps are being built by users who assume the platform handles security for them.

The pattern is consistent across the vibe coding ecosystem. CVE-2025-48757 documented insufficient or missing Row-Level Security policies in Lovable-generated Supabase projects. Certain queries skipped access checks entirely, exposing data across more than 170 production applications. The AI generated the database layer. It did not generate the security policies that should have restricted who could read the data. Lovable disputes the CVE classification, stating that individual customers accept responsibility for protecting their application data. That dispute itself illustrates the core tension: platforms that market to nontechnical builders are shifting security responsibility to users who do not know it exists.

The RedAccess findings complete the picture. Professional agents face credential theft on one layer. Citizen platforms face data exposure on the other. The structural failure is the same. Security review happens after deployment or not at all. Identity and access management systems track human users and service accounts. They do not track the Lovable app a sales operations analyst deployed last Tuesday, connected to a live CRM database, and shared with three external contractors via a public URL.

Nobody asks whether the database policies restrict who can read the data or whether the API endpoints require authentication. When those questions go unasked at AI-generation speed, the exposure scales faster than any human review process can match. The question for security leaders is not whether vibe-coded apps are inside their perimeter. The question is how many, holding what data, visible to whom. The RedAccess findings suggest the answer, for most organizations, is worse than anyone in the C-suite currently knows. The organizations that start scanning this week will find them. The ones that wait will read about themselves next.