Amazon Web Services is threading its AI-powered security infrastructure directly into the coding environments built by two of its fiercest rivals — and in doing so, it is making a bold bet that controlling the security layer matters more than controlling the model.

AWS announced at Black Hat USA 2026 this month that its Continuum platform for code vulnerabilities will integrate directly into Anthropic's Claude Code and OpenAI's Codex, alongside AWS's own Kiro IDE.

The move embeds AWS security tooling at the point where developers write code, regardless of which AI model they use to do it. Simultaneously, AWS expanded Security Hub Extended — its curated, single-bill security marketplace launched in February — with a 10th security category focused on supply chain protection, bringing in Chainguard and Socket as partners.

Together, the announcements are AWS's most sweeping attempt yet to position itself as the default security control plane for enterprise software development in the AI era — a role that carries enormous commercial implications as the global cloud infrastructure market surpasses $143 billion per quarter, according to Synergy Research Group.

Why frontier AI models turned the vulnerability backlog into a five-alarm fire

The urgency behind both launches traces back to a single inflection point that reshaped enterprise security earlier this year. Claude Mythos Preview, announced by Anthropic in April, is a general-purpose AI model that during testing revealed striking cybersecurity capabilities far exceeding any prior system.

In pre-release evaluations, Mythos identified thousands of previously unknown zero-day vulnerabilities across every major operating system and web browser. More than 99% of those vulnerabilities remain unpatched by their maintainers, and the median time from vulnerability discovery to weaponized exploit — already collapsed from 771 days in 2018 to under four hours by 2024 — is projected to reach under one hour by the end of 2026.

Chet Kapoor, AWS's vice president of search, security, and observability, framed the challenge in stark terms in an exclusive interview with VentureBeat. "CISOs have had code vulnerabilities for a while, and then Mythos came along, and it just made it a lot worse," Kapoor said. "They already had a backlog. Now the backlog is 5x more, and that causes a problem."

That problem — the exponential growth in known vulnerabilities outpacing any organization's ability to triage and fix them — is precisely what Continuum is designed to address. Kapoor described AWS's broader security vision as a shift from "telemetry, storage, query, dashboards for humans to telemetry, context, reasoning, and actions by agents." The shorthand for that vision is a phrase AWS repeated throughout Black Hat: autonomous security at machine speed.

Inside Continuum's four-phase system for finding and fixing code flaws automatically

Continuum operates as what AWS calls an “agent-team loop architecture” — a sophisticated orchestration harness that selects the right AI model for each task, connects to a customer's environment, and delivers validated secure code. Under the hood, it runs through four distinct phases.

Kapoor broke them down for VentureBeat. Discovery uses multiple frontier AI models to scan code and ingest a customer's existing vulnerability backlog. Prioritization — which Kapoor called "one of our biggest value adds" — contextualizes each finding against a customer's actual environment and business risk. "You go from 100 to 2,000, and now you're like, whoa, I didn't even know which 100 to focus on," he said.

Validation then builds reproducible exploits in an isolated sandbox to confirm whether a vulnerability is genuinely exploitable. "Once I do them, how will it behave?" Kapoor explained. "You create a sandbox to go off and make that happen. So you can figure out what the blast radius is." The validation phase covers both first-party code that customers wrote themselves and third-party open source code they depend on. Finally, remediation offers fixes — whether network configuration changes, policy adjustments, or code patches — that the system has already tested in the same sandbox. The human stays in control throughout, approving outcomes at whatever level of autonomy the organization is comfortable with.

The commercial model is equally deliberate. Customers pay AWS a single price for Continuum. AWS absorbs the underlying token costs for whichever frontier model performs best at each phase of the scan. "The customer purchases Continuum, period," Kapoor told VentureBeat. "We optimize on which model to use for what because, quite frankly, GPT Cyber is good at some things, Mythos is good at some things."

How AWS convinced OpenAI and Anthropic to open their coding tools to a rival's security layer

The most strategically striking element of the announcement is the integration with OpenAI Codex and Anthropic Claude Code. AWS competes directly with both companies across cloud AI services. Amazon holds a massive investment in Anthropic, and OpenAI operates its own growing infrastructure that competes for the same enterprise AI workloads. Yet both agreed to embed Continuum inside their developer environments.

When VentureBeat asked Kapoor directly about the competitive dynamics, he pushed back on the framing entirely. "Who is the competitor?" Kapoor said. "I can keep thinking about Anthropic and OpenAI to be partners. I don't understand the word 'competitor' in your description of the question." He added: "They're partners with us. We use their models. We plug into their environments. Which is why we actually brought them together to do this."

Kapoor argued that working with a single model provider would be insufficient. "I don't think it's good enough to just do it with one company," he said. "Everybody is going to leapfrog each other over a period of time." By absorbing token costs and presenting a single bill to the customer, AWS positions Continuum as infrastructure — not a model wrapper. The harness, not the engine, becomes the durable competitive asset.

As Kapoor wrote in his blog post announcing the partnership: "An AI harness is the orchestration layer that wraps around a model to connect it to tools, guardrails, memory, and workflows, so it delivers outcomes. Think of the model as the engine and the harness as everything around it. You need both to have a high-performance car." 

AWS partners echoed the logic. "Model choice was never the hard part for enterprises. Trust in what the model does in production is," said Val Henderson, CEO of AWS Premier Partner Caylent, in comments reported by CRN.

AWS adds supply chain security to its curated marketplace as open source threats intensify

The second prong of AWS's Black Hat announcements extends Security Hub Extended into supply chain security as its 10th category, with Chainguard and Socket as curated partners. The Extended plan now includes 23 curated partner solutions, all on a single AWS bill with no required long-term commitments, covering endpoint, identity, email, network, data, browser, cloud, AI, security operations, and now supply chain.

Michael Fuller, AWS's director of security services, told VentureBeat that the addition was driven entirely by customer demand. "Over the last six to eight months, it's gotten quite a bit of news around what's happening in the supply chain space, with the fact that everybody builds on open source," Fuller said. "Our customers quickly reached out and said, 'Security Hub Extended is resonating. We would love to see a supply chain security category with some key players there because it's a hot topic for us.'"

The two partners were chosen to be complementary rather than duplicative. Chainguard focuses on providing hardened, secure-by-default container images and packages rebuilt from verified source code. Socket performs behavioral monitoring of packages as they are pulled into a developer's environment, detecting threats like typosquatting, maintainer account takeover, and obfuscated malicious code. "Together, between the three of us — us with consolidating that, ChainGuard providing really good hardened and cleaned images and packages, and then Socket providing a behavioral analysis over the top — gives customers a really good holistic supply chain security offering," Fuller said.

The complementary approach addresses two distinct attack vectors. An attacker can publish a malicious package that contains no known vulnerabilities — Chainguard's clean-build approach defends against that. Separately, an attacker can compromise a legitimate maintainer's account and push a tainted update to a trusted package — Socket's behavioral detection catches that. Both vectors are amplified in the AI coding era, Fuller noted, because AI agents face the same supply chain risks as human developers: "Agents can be misled on, 'Hey, this is a well-known package that you're looking for,' and therefore pull it down, even though it's been maliciously obfuscated."

Why AWS chose two partners per category instead of building a security marketplace

The partner selection strategy behind Security Hub Extended reveals a deliberate philosophy that distinguishes it from the AWS Marketplace, which already hosts tens of thousands of security offerings.

Fuller told VentureBeat that customers articulated clear principles for what they wanted. "One was don't give me hundreds of offerings. We already have the AWS Marketplace," he said. "Two was give me a sweet spot. Our customers were saying, give me two in each category, and when you look at those two, don't give me head-to-head competitors. Give me one that I may know well, that is an established player, and give me one that's taking a different approach."

Fuller pointed to the security operations category as the template. "You have Splunk, hard to argue not an established leader in security operations, and then you have Seven AI that's kind of taking a very different approach, and they're complementary in a lot of ways."

The decision to build internally versus partner follows a similar logic. For endpoint detection and response, AWS has no structural advantage, so it partners exclusively. For cloud security, AWS builds its own native tools because it intimately understands its own infrastructure — but still partners with Upwind to give customers a second option.

"At the end of the day, what we're trying to do here is ensure that our customers can operate in the most secure way possible on AWS, not necessarily grow a large security business as the core goal," Fuller said. "That's why it's very easy for us to decide to do both building ourselves, but also then inviting partners to participate."

The pricing model reinforces this accessibility. Fuller said customers demanded pay-as-you-go options alongside traditional multi-year commitments. "All of the Security Hub Extended offerings have a public-facing, pay-as-you-go price, just like our first-party offerings do within AWS," he said. "So that gives customers the option to go kick the tires, get going, even scale up and use the services without going through a traditional sales cycle."

Shadow agents and AI cost harvesting emerge as the next frontier of cloud security threats

Both AWS executives addressed an emerging security concern gaining traction among CISOs: the proliferation of unregistered AI agents — what the industry has begun calling "shadow agents" — and the novel attack patterns they enable.

Kapoor told VentureBeat that shadow agents are a genuine and growing problem, though he was careful to separate it from the Continuum announcement. "There are many agents that are registered with registration directories, whether it's Vertex, whether it's Agent Core, whatever else it might be, but there are many agents that are not registered with the registry, and those are what people are calling shadow agents because they can actually do some harm," he said. "Discovering shadow agents is not easy. The industry is working on it."

Fuller provided more granular detail on what AWS has already deployed. Security Hub now includes a free AI inventory capability that uses three data layers: AWS Config identifies AI-related services like SageMaker, Bedrock, and Agent Core across an organization; Amazon Inspector scans compute instances and containers for AI-related software; and GuardDuty compares DNS request and response logs against known AI tools and agentic workloads.

Beyond inventory, Fuller revealed that GuardDuty now monitors data plane events — including prompts, prompt volume patterns, and inference cost analysis — to detect what AWS calls "cost harvesting."

The attack mirrors the cryptocurrency mining that became common after cloud credential compromises: an attacker gains access to an AWS account and burns through as much free AI inference as possible before detection.

"We're seeing what we're calling cost harvesting," Fuller said. "They'll spin up, basically try to get as much free inference as they can until that's discovered." It is, Fuller noted, "the same thing that's happening in AI" as happened with crypto mining — and GuardDuty's detection of credential compromise and unauthorized compute usage translates directly to the new threat.

How Continuum and Security Hub Extended fit together in AWS's enterprise security strategy

Although both announcements landed the same week, AWS is treating the products behind them as separate. Kapoor described Continuum to VentureBeat as distinct from Security Hub Extended, sold as its own standalone product. AWS declined to discuss its longer-term roadmap for the two.

The design logic points in one direction. Continuum addresses the code an enterprise writes and the open source it inherits. Security Hub Extended addresses everything else — and the newest of its categories is where the two most clearly overlap. Continuum's validation phase covers third-party dependencies alongside a customer's own code; Chainguard and Socket harden and monitor the same packages from the other direction. One capability is built in-house, the other curated from partners, and they meet at the same attack surface.

Both proceed from the same premise: that enterprises no longer want a catalog, they want a recommendation.

"Customers want an opinionated point of view on how they should do security in the AI era," Kapoor told VentureBeat. "That's what Security Hub Extended was about — actually going off and giving them our opinion." AWS will continue to give customers choice, he added, "whether it is something that we ship or whether it is something from a partner."

That doctrine — a recommendation, with an escape hatch — is the through line connecting a curated marketplace to a first-party agent platform, and it makes the boundary between them more porous than two separate announcements suggest. Security Hub has already absorbed capabilities that did not exist a year ago, including the free AI inventory and the cost harvesting detections Fuller described. The console is where AWS delivers its opinion to the enterprise. Continuum is the sharpest opinion it has shipped.

The audience for that opinion has changed as well, Kapoor said. Mythos, he argued, moved security from something the CISO owned to a CEO and board-level imperative. "Boards are now asking for updates on what's going on with security in the enterprise because it's a business threat now, it's a business risk."

AWS's security ambitions reflect a calculated bet on owning the orchestration layer

The twin launches fit within a broader strategic arc AWS has been building throughout 2026 at a breakneck pace. The company re-imagined Security Hub at re:Invent 2025 by consolidating GuardDuty, Inspector, CSPM, and Access Analyzer into a single console. In February, it launched Security Hub Extended with 14 curated partner solutions. By May, that number grew to 21 across nine categories. Now it stands at 23 across 10. Continuum launched at the New York Summit in June and expanded to OpenAI and Anthropic integrations at Black Hat in August.

AWS generated $42.2 billion in revenue during Q2 2026, with cloud sales expanding 37% year over year. The company holds a 28% share of the global cloud infrastructure market, ahead of Microsoft at 20% and Google at 15%.

Fuller told VentureBeat that AWS has "tens of thousands of customers using one or multiple of our security services, essentially across all geos that we operate in, and in every industry, and both commercial and government." The Extended plan aims to convert that installed base into users of partner security solutions — deepening engagement and making it harder for competitors to dislodge AWS as the default platform.

By making AWS the seller of record for 23 partner security solutions and embedding Continuum inside the coding environments of OpenAI and Anthropic, AWS is constructing something more durable than a product line. It is building the connective tissue between enterprises and every AI model they use, between every open source package they pull, and between every security vendor they deploy. In a world where frontier models are advancing so rapidly that today's best scanner becomes tomorrow's table stakes, the layer that persists is not the model — it is the harness that connects the model to the customer's environment, policies, and risk tolerance.

Kapoor, reflecting on a chance conversation he had on a flight to Black Hat, offered the simplest articulation of why all of it matters. A former CISO turned CTO sitting beside him volunteered a blunt assessment of the current moment: "I don't feel safer now." Kapoor's response, he told VentureBeat, was equally blunt: "We're working on it."

Whether that work makes the world safer or simply makes AWS indispensable to every organization trying to get there may, in the end, amount to the same thing.

Brex CEO Pedro Franceschi offered a blueprint for one of the pressing challenges facing the enterprise today at VB Transform 2026: securely deploying AI agents, like the open-source OpenClaw, into production environments.

Unlocking this enterprise value requires a mindset shift. The industry needs to move past vague terminology and focus on concrete enterprise roles. 

“People talk a lot about agents, but I think 'agents' is a terrible name. It's this Silicon Valley concept that doesn't really mean much,” Franceschi said. 

Instead, the goal should be creating entities that can genuinely collaborate with human workers. "The concept we always had in mind was the idea of a virtual employee — someone on Slack, an entity, it has an email address, it can join meetings, you can email it, and that you can work with," Franceschi said.

Realizing this vision demands a new security paradigm. Franceschi’s presentation detailed how Brex pointed OpenClaw at internal roles, realized traditional security models failed, and built a novel network-level security layer called CrabTrap.

The OpenClaw security dilemma

The journey began following a breakthrough in December, when coding models reached a level of maturity that enabled the January release of OpenClaw. This marked the moment agents could finally self-bootstrap and maintain their own codebases instead of relying on hard-coded, static tools. 

However, when Franceschi proposed deploying this to automate internal functions, the Brex security team firmly rejected the idea. “They said, 'Hell no. How could we trust an agent doing these things? This thing has code execution capabilities. There's no way to control it,'” Franceschi said. That caution isn't unique to Brex — enterprises broadly have been wary of granting agents uncontrolled code execution on corporate networks.

To solve this, Brex had to shift the security perimeter. Franceschi contrasted this with approaches like Nvidia's NemoClaw, which he said secure agents by limiting their tool usage — a model he believes neutralizes the coding capabilities that give agents their value.

“… the premise we had was that the coding capabilities were critical to the model having the ability to do a variety of tasks,” he said. 

Brex's fix was to shift the security boundary to the network layer instead. Instead of policing the ever-changing code inside the container, the focus must shift to monitoring what the code actually attempts to send or receive from the outside world.

CrabTrap and the LLM-as-a-judge solution

This network-centric approach led to the creation of CrabTrap, an open-source HTTP proxy built by Brex. The mechanism operates on the assumption that OpenClaw can do anything and might already be compromised. Therefore, CrabTrap monitors all outbound network traffic between the container and the internet, using an LLM to judge whether that traffic aligns with the agent's approved policy.

“Instead of trying to control the code running in the container, assume the thing can do anything and monitor the network traffic between that container and the internet,” Franceschi said. 

Using a large language model (LLM) to judge every single network request introduces unacceptable latency, often adding thousands of milliseconds to response times. Brex solved this by passing traffic through a bifurcated system. 

Routine, low-risk actions pass through static, pre-approved rules instantly. If a recruiting agent tries to view a LinkedIn profile, the static rule allows it. However, high-risk actions such as sending emails are flagged and routed to the LLM judge for evaluation. Franceschi said that architecture ensures only about 2% of complex requests actually face LLM latency. 

A surprising finding from the project was how effectively the LLM judge performs this role. Franceschi attributed this to the models' training: LLMs are exposed to billions of web pages and HTTP requests, giving them what he described as an inherent semantic understanding of network traffic patterns.

“[Models] are very good at discerning what is within the policy and what is not,” Franceschi said, adding that this capability emerges naturally through pre-training without needing heavy prompting.

Brex put this infrastructure to the test with “Jim,” a virtual recruiter built on OpenClaw. Jim handles various tasks, including sourcing candidates, scoring inbound applicants, and sending emails. 

When Jim attempts an action that falls outside the established policy, CrabTrap relies on a human-in-the-loop workflow. If the LLM judge flags an unapproved outbound email, CrabTrap pings a human manager on Slack. 

The Slack notification explains the agent's underlying intent and suggests a policy change that would allow the action. The human manager can then review the context and click "yes" or "no" to update the rules dynamically. 

"I like the virtual employee analogy because a lot of these things were solved already in a company, in the context of humans," Franceschi said. "When an employee hits a wall, they escalate to their manager."

The cost of the frontier

Brex is a fintech company, not a cybersecurity vendor. The decision to build CrabTrap in-house was driven by a lack of mature commercial solutions that could satisfy their security team. 

Franceschi acknowledged the inherent cost of operating at the bleeding edge, admitting that commercial vendor solutions will likely catch up. 

“When we built this, it was clear to me there was a 70% chance we would throw it away in six months... But what we learned by being six months ahead was worth it in shaping our AI adoption strategy,” he said. 

The investment in building internal tools provided Brex with the experience needed to safely deploy agents months ahead of the broader market. For enterprise leaders navigating the AI landscape, the core takeaway is the necessity of building the cultural and technical muscle to operate in an agentic world today. 

“We don't have all the answers, but the answer is not to do nothing,” Franceschi said.

Meta today released Muse Glimmer, a 30-billion-parameter open-weight model designed to run autonomous AI agents directly on consumer hardware — pushing agentic workloads that normally depend on cloud infrastructure onto high-end Macs and PCs.

Just as notable as what the model does is how it's licensed. Glimmer arrives under the permissive, industry-standard Apache 2.0 open source license — the company's first fully open release since it succeeded its open-weight Llama family in April with the proprietary Muse Spark.

In fact, Muse Glimmer launches today with a more permissive license than Llama ever carried. Llama's bespoke community license drew years of criticism for restrictions like its 700-million-monthly-user cutoff; Apache 2.0 has no such strings, permitting unrestricted commercial use, modification and redistribution.

The weights are available on Hugging Face now. Wang said support is rolling out this week through Ollama, LM Studio, vLLM, SGLang, Together AI, Fireworks AI and OpenRouter, with optimized llama.cpp, MLX and ExecuTorch integrations landing in the coming days; Meta's blog post also names Unsloth as a local-runtime partner and points to PyTorch's TorchTitan for fine-tuning. The company says it is working with AMD, Arm, Dell, Intel and Nvidia to optimize performance across devices, and has published developer documentation covering custom agent scaffolds.

"Today we're also opening the weights for Muse Glimmer, a great 30B parameter dense model that can run locally," Meta co-founder and CEO Mark Zuckerberg wrote in a post on X (under his longtime handle @finkd). "Soon we'll also release the weights for Muse Spark 1.2, our latest foundation model. Meta is a strong supporter of open source and I'm proud of these releases."

That promised Muse Spark 1.2 release would be an even bigger shift: it's the frontier model behind Muse Code, the terminal coding agent Meta shipped just five days ago, and until today the entire Muse family was proprietary. Zuckerberg had teased at that launch that he'd "have more to share soon" on open source. Now we know what he meant.

For developers and enterprises, the practical stakes of local inference go beyond where computation happens. An agent working with files, screenshots, development environments and other sensitive context can execute those workflows without continuously sending that information to a remote inference service. Local deployment also removes network availability and per-token API charges from the inference loop — although organizations still bear hardware, electricity, deployment and management costs.

A 30B model built around the agent loop

Rather than positioning Glimmer primarily as a general chatbot, Meta trained it around the sequence of operations an autonomous agent performs: formulate a plan, call tools, interpret the results, continue working, and recover when something goes wrong.

"Just like much larger models, muse glimmer can operate as a fully capable agent via planning, tool calls, checking its own results, and failure recovery," Alexandr Wang, Meta's chief AI officer, wrote in a thread on X announcing the release, adding that the model "can run on 24GB of VRAM without losing agentic reliability."

According to the model card on Hugging Face, Glimmer is a dense causal transformer with approximately 29.6 billion total parameters across 52 layers, including a dedicated ~1.8B-parameter ViT-G/14 perception encoder. It accepts interleaved text and images, produces text, supports more than 100 languages and has a stated context length of 131,072 tokens or more, with a knowledge cutoff of January 4, 2026.

That combination is intended to let an agent interpret screenshots, charts and documents while simultaneously reasoning about text and invoking external tools. Glimmer offers low, medium, high and xhigh reasoning settings — set via the system prompt — so applications can dial reasoning effort up or down per task, and Meta says it works across agentic scaffolds including OpenClaw and Hermes Agent.

The model is a distillation of Meta's larger flagship: per the company's technical blog post, Glimmer was pre-trained on Muse Spark's outputs using logit distillation, mid-trained on longer-context, agent-heavy data with richer reasoning traces, then post-trained with supervised fine-tuning, on-policy distillation and reinforcement learning across general, reasoning, coding and agentic domains.

Meta demonstrated the result with a local Home Assistant workflow: in a demo video, Glimmer autonomously discovers a Home Assistant instance on the network via tool calls, queries device APIs, writes a responsive HTML/CSS/JavaScript dashboard from scratch and deploys a local server to verify its own work. That's closer to the operational reality of enterprise agent deployments than a standalone question-answering benchmark — the model has to maintain a plan while interacting with external systems, then inspect whether its actions produced the expected result.

Compressing an agent into 24GB

The hardware story is central to the release.

At full precision, Meta says the 30B model requires more than 55GB of memory — beyond any single consumer GPU.

The company therefore developed approximately 4-bit quantized versions that shrink the language-model weights to under 20GB, leaving headroom for the pieces an operational agent also needs in memory: the KV cache, the perception encoder and a companion speculative-decoding model, all fitting within a 24GB or 32GB envelope.

In practical terms, that means the quantized builds run on consumer machines — though the upper end of them. The 24GB-targeted K-Quant-17GB configuration fits on a single high-end consumer graphics card, such as Nvidia's RTX 3090 or RTX 4090 (both with 24GB of VRAM), while the 32GB-targeted K-Quant-Dynamic version lines up with the newer RTX 5090's 32GB. On the Mac side, Apple Silicon's unified memory plays the role of VRAM, so a MacBook Pro or Mac Studio with 32GB or more of memory can hold the full stack — Meta ran its own speed tests on M4 Max and M5 Max MacBook Pros. A typical 8GB or 16GB laptop, however, remains out of reach, and the full-precision BF16 release — which Meta pegs at 64GB — stays in the territory of data-center GPUs and top-spec Mac Studio configurations.

Meta reports average accuracy degradation of just 0.2% across 15 benchmarks for its K-Quant-Dynamic version targeting 32GB hardware, and 1% for the K-Quant-17GB configuration targeting 24GB hardware. Those figures are Meta's own measurements, not independent evaluations.

Meta is also using DFlash speculative decoding to attack the other big problem with local agents: latency. Instead of generating every token sequentially, a smaller DFlash "drafter" model proposes blocks of 16 tokens that the primary model verifies in parallel, producing identical output faster.

Meta reports this raises average generation speed on an Nvidia RTX 5090 from 74.9 tokens per second to 233.4 — a 3.1x increase. An Apple M5 Max rises from 26.6 to 50.2 tokens per second (1.8x), and an M4 Max from 23.7 to 37.8 (1.5x). The tests used batch size one and greedy decoding, with Apple systems measured via ExecuTorch and the RTX 5090 via llama.cpp.

For agent applications, those multipliers matter more than they would for chat: a single user request can trigger many model turns, tool calls and verification steps, and latency accumulated at every stage can quickly make an otherwise capable agent impractical.

Glimmer enters an increasingly competitive local-model market

Meta is not entering an empty field. Developers already have capable open-weight models in this size class, most prominently Google's Gemma 4 family and Alibaba's Qwen3.6-27B — both of which position themselves around reasoning, multimodal understanding and agentic workloads. Meta's own benchmark table compares directly against both.

Glimmer leads that three-way comparison on several agentic tests, including MCP Atlas at 75.5, DeepSearch QA at 74.6, τ³-Banking at 23.5, WildClawBench at 47.6 and GAIA2 at 43.3. It scores 51.2 on SWE-Bench Pro, versus 36.9 for Gemma4-31B and 50.2 for Qwen3.6-27B in Meta's evaluation.

But Glimmer does not sweep the field. Qwen leads Meta's own comparison on OSWorld-Verified (75.6 vs. Glimmer's 65.9), TerminalBench 2.1 (60.7 vs. 51.7), SkillsBench, GDPval-AA (1141 vs. 953) and most of the multimodal benchmarks. On SWE-Bench Verified, Glimmer's 76.0 lands just below Qwen's 77.2. Gemma leads on GPQA Diamond and Humanity's Last Exam.

Read honestly, the numbers make Glimmer more interesting as a specialized local-agent model than as evidence of a universal performance lead. For enterprise developers, the practical question is whether its combination of agent reliability, quantization quality, tool compatibility and decoding speed translates from benchmarks into sustained real-world workflows.

Meta Glimmer adds to a still-small roster of genuinely open, frontier-class models from U.S. companies.

For the last two years, Chinese companies have set the pace in open source AI, with DeepSeek, Alibaba's Qwen team, Moonshot AI's Kimi, Zhipu's GLM and MiniMax shipping frontier-class open models under MIT and Apache 2.0 licenses on a cadence Western labs haven't matched.

The usage data reflects it: by May 2026, Chinese open-weight models accounted for roughly 61% of all tokens consumed on OpenRouter, with four of the five most-used models coming from Chinese labs — while Meta's Llama, the prior open-weight leader, fell off the rankings entirely.

The U.S. counterexamples remain countable on one hand: OpenAI's gpt-oss-120b and gpt-oss-20b, released under Apache 2.0 in August 2025 as the company's first open weights since GPT-2; Google's Gemma family, which is open-weight but ships under Google's own more restrictive custom license rather than an OSI-approved one; and Thinking Machines' Inkling.

Glimmer invites the most direct comparison to gpt-oss: both are Apache 2.0, both offer adjustable reasoning effort, and both target self-hosted deployment.

But the gpt-oss models are text-only, sparse mixture-of-experts designs built primarily for reasoning and tool use — gpt-oss-20b fits in about 16GB of memory while gpt-oss-120b targets a single 80GB data center GPU.

Glimmer stakes out different ground: a dense model with native vision input, trained end-to-end around the agent loop, shipping with its own quantized variants and speculative-decoding drafter tuned for 24GB consumer machines.

And if Zuckerberg follows through on opening Muse Spark 1.2's weights, Meta would put an actual U.S. flagship frontier model into open circulation — something no American lab has done at that tier.

Safety remains part of the deployment architecture

Giving a local model access to tools creates a different security problem from deploying a local chatbot — and Meta's own safety numbers show Glimmer is not uniformly stronger than its peers.

On CI Memories, a privacy benchmark where lower violation rates are better, Glimmer records 26.4 against Gemma's 12.1 and Qwen's 53.4. On Siren AgentDojo, a prompt-injection test, Glimmer shows a 28.4% attack-success rate versus 25.6% for Gemma and 40.3% for Qwen — while posting the highest utility score of the three at 94.2.

Meta says it evaluated Glimmer under its Advanced AI Scaling Framework and determined the model does not meet the framework's definition of "Frontier AI" because it is generally less capable than Muse Spark. Its Preparedness Team assessed Glimmer at Moderate or lower risk across chemical/biological, cyber and loss-of-control categories — the latter two inferred from the fact that Glimmer is broadly weaker than Muse Spark 1.0, which received the same designations.

The company nevertheless recommends deploying Glimmer as part of a broader system with guardrails, including human-in-the-loop confirmation for irreversible actions. That caveat matters especially for local agents: keeping data on-device reduces exposure to cloud infrastructure, but local execution does not by itself solve prompt injection, excessive permissions or an agent taking an unintended action.

Apache 2.0 weights and a fast-growing runtime ecosystem

Meta is releasing full-precision BF16 weights, both 4-bit quantized variants, the DFlash drafter and the perception encoder — all under Apache 2.0. There is no Meta API price attached to the downloadable model, leaving total cost dependent on local hardware or whatever third-party hosting developers choose. One nuance worth noting for procurement teams: as with most "open source" model releases, it is the weights that are open — Meta has not released the training data or training code.

The broader implication is that Meta is treating the developer workstation as a credible deployment target for autonomous agents, rather than merely a place to experiment with smaller language models. Glimmer's 30B size and 24GB target put that proposition within reach of high-end consumer hardware, while the Apache 2.0 license gives developers — and their legal departments — unusual freedom to modify and deploy it.

The next test is whether its benchmark advantages survive the messier conditions of real software repositories, enterprise tools and long-running agent sessions. If they do, the most consequential part of Glimmer may not be another set of benchmark scores — it may be that a class of agent previously expected to live behind a cloud API can increasingly live, and work, on the machine sitting under a developer's desk.

Presented by MongoDB

We have been building databases as an industry for roughly 60 years. We have been building AI agents, in the form most people mean when they say the word today, for about 18 months.

Sit with that ratio for a second, because it explains almost everything about the state of agentic development right now. Six decades versus a year and a half. We are not in the middle of this learning curve. We are standing at the very bottom of it, squinting up.

There is no LAMP stack for agents yet. There is no settled, boring, default set of choices that lets a team stop re-litigating architecture and just ship.

One of the earliest lessons came from the industry’s brief obsession with token-maxxing. For a stretch in early 2026, token consumption became a vanity metric. The backlash was fast. Token volume measures activity, not outcomes.

But the interesting part of the token-maxxing story was never the workplace theater. It was the architectural lesson hiding underneath it.

The context window is the scarce resource

What follows is an aggregation of what I’ve learned from more than 100 customer conversations across 15 cities in six countries during the first half of 2026. I’m seeing organizations begin to converge on the same conclusion: the context window is the scarce resource. The challenge isn’t stuffing more information into every prompt. It’s deciding what belongs there in the first place.

That question has an answer. The answer is memory.

Not the loose way people use that word to mean “the context window,” but a real, persistent, queryable memory system that sits outside the model and feeds it deliberately.

The answer is memory, and it is more than short-term and long-term

A good agentic memory does three things that the context window alone cannot:

• It saves what the generative model produced on previous loops and previous sessions, so the expensive reasoning you already paid for does not evaporate the moment the session ends.

• It applies role-based access control to that saved content, so a memory created by one team can be shared across an enterprise without leaking things it should not.

• It lets new queries retrieve the right prior content, which in practice means it is backed by semantic search rather than exact-match lookup, because agents ask for things by meaning, not by key.

That last point is where this connects back to the 60-years-of-databases observation. We spent six decades getting extremely good at storing and retrieving structured data by exact criteria. Agentic memory needs something different and newer: the ability to store the unstructured output of a generative process and find it again by similarity.

The teams building this well are the ones whose data platform can do semantic search natively, apply access control to it, and hold the generated content in the same place, rather than stitching three systems together with hope.

The pattern that is emerging in enterprises

Once you have memory like that, a genuinely interesting architecture falls out of it, and I am seeing more enterprises converge on it.

You pair the powerful memory system with a leaner model, often an open-weight one, whose job is not to be brilliant but to be a good judge. A new query comes in. The agent does a semantic search on the memory, reranks to get the best candidate answer, and asks the leaner model a single question: is this good enough to return as is, or not?

If it is good enough, you return it. You never paid for the expensive generative model at all. You answered from memory.

If it is not good enough, you escalate to the more expensive generative model, get an original solution, return that, and then save it back into the same memory system so the next session does not have to pay for it either.

Think about what that does to agentic economics over time. Every original answer the expensive model produces becomes a cheap answer the next time someone needs something similar. The system gets cheaper and faster the more it is used, which is the opposite of how naive token-maxxing scales, where cost grows linearly with usage forever. This is the difference between an agent that learns what it already knows and one that re-derives the universe on every loop.

Memory has types, and humans curate the best ones

The last piece, and the one I think separates where we are headed from where we are now, is that mature agentic memory will not be a flat bucket of short-term and long-term. It will have types, the way human memory does.

Taxonomic memory holds terminology, the controlled vocabulary and definitions an organization runs on, so the agent uses "chargeback" to mean what your finance team means by it and not what the internet at large means.

Procedural memory holds task lists and sequences, the how-we-do-this-here knowledge that turns a capable model into a useful colleague. There will be more types than these, and figuring out the right taxonomy of memory types is itself part of the learning curve we are climbing.

And here is the part that should sound familiar to anyone who has run a real production system: the best memories often get there because a human put them there. Not every memory an agent generates is worth keeping, and not every kept memory is worth surfacing first.

Increasingly I expect to see humans curating these systems, injecting the high-value memories back in for frequent reuse, pruning the noise, promoting the procedural sequence that works over the three that mostly work. We did this for knowledge bases. We did it for documentation. We will do it for agentic memory, because curation is how a corpus stops being a landfill and starts being an asset.

What comes next?

We are 18 months, give or take, into agents and 60 years into databases. The gap between those two numbers is not a problem to be embarrassed about. It is just the truth about how early it is, and it should make us humble about every "best practice" that is barely a season old.

Token-maxxing was the first big idea to rise and fall inside this new field, and its fall taught us the lesson the field most needed: the context window is scarce, so the discipline is in choosing what goes in it. That discipline is agentic memory. Semantic-search-backed, access-controlled, typed, human-curated memory that saves what was expensive to produce and serves it cheaply forever after.

There is still no LAMP stack for agents. But if I had to bet on which layer becomes the boring, default, settled choice first, the one we stop arguing about so we can get back to building, I would bet on memory. That is the next advancement in agentic development. Everything else is still hand-wiring CGI-BIN.

Pete Johnson is Field CTO, AI at MongoDB.

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.

Content filters can block unsafe output. They cannot tell you whether an agent was authorized to issue that refund, touch that production system, or commit the company to an external action. Those are different problems, and most enterprises are only solving the first one.

An AI agent can follow its instructions perfectly and still take an action the business never sanctioned.

In commerce environments, I have seen this pattern emerge in practical ways. A service workflow calculates the correct refund amount but lacks a boundary preventing credits above what the business approved for autonomous action. An order agent correctly applies a requested change but overlooks a financing or fulfillment condition. A procurement agent identifies the lowest-cost supplier, but nobody has defined whether it can accept contractual terms or only recommend the option.

The agent keeps working. The problem may not surface until something downstream breaks.

These are not necessarily AI reasoning failures. They are failures to separate technical capability from business authority.

As enterprises move from copilots that recommend to agents that call tools and trigger workflows, every production agent needs explicit decision rights: What it may execute, what requires approval, what it may only recommend, and what it must never touch.

Guardrails remain necessary. But a guardrail is not an authority model.

Safety controls and decision rights solve different problems

Early gen AI controls screen harmful content, protect sensitive information, validate responses, and constrain tool behavior. That work matters.

Decision rights answer a different question: Even when an action is safe and technically valid, is this agent authorized to take it on behalf of the enterprise?

That governance gap is becoming harder to ignore. In April 2026, a Cloud Security Alliance survey found that 65% of respondents had experienced an AI-agent-related incident in the prior year, while 82% had discovered previously unknown agents operating in their environments. The survey involved 418 IT and security professionals and was sponsored by Token Security.

The findings illustrate how quickly agent activity can outpace the visibility and ownership structures built for conventional software.

The World Economic Forum’s May 2026 playbook reflects this shift. It introduces an Agent Capability and Authorization Profile designed to make delegated actions auditable, enforceable and accountable.

Guardrails constrain behavior. Decision rights define legitimate authority.

Give every production agent an authority contract

Before an agent receives access to enterprise tools, it needs a machine-enforceable record of exactly what authority the business has chosen to delegate. Call it an Agent Authority Contract.

At minimum, that contract should answer seven questions:

1. Who owns the outcome? Name a human or business role, not another system.

2. What may the agent do? Read, recommend, write, or commit?

3. Which systems and data may it reach?

4. What materiality limits apply? Define dollar thresholds, record counts, customer scope, and operational impact.

5. What triggers escalation? Uncertainty, anomaly, sensitive data, or potential impact?

6. Can the action be reversed, and who can reverse it?

7. When does the authority expire, and how is it withdrawn?

Access control determines whether an agent can reach a system. The authority contract determines whether it may take a specific action in the current context.

Those are not the same check.

Singapore’s updated Model AI Governance Framework for Agentic AI draws a similar distinction. It treats access controls, behavioral guardrails, and human approvals as separate controls and ties oversight requirements to action scope, reversibility and potential impact.

Resolve every consequential action into four outcomes

A working decision-rights model should map every consequential agent action to one of four results.

Allow

Low-risk, bounded, and reversible actions run autonomously.

Examples include retrieving approved information, classifying an inbound request, or updating a non-material field. The agent acts without prior review because the potential impact is limited and the action can be reversed.

Approve

The agent prepares or initiates the action, but execution waits for authorization from a human or deterministic policy service.

This category covers payments, production changes, and actions that materially affect a customer, employee, or third party.

Recommend

The agent analyzes, ranks, drafts, or proposes. A named human makes the final decision.

Use this outcome when contextual judgment matters or when the legal, financial, or individual impact makes automated execution unacceptable.

Deny

The action remains outside the agent’s authority regardless of its confidence.

Deleting critical production data, making a final employment decision or overriding a mandatory compliance control should remain in the Deny category even when the agent’s underlying reasoning appears correct.

One point gets missed consistently: Deny must be enforced outside the system prompt.

A natural-language instruction telling an agent not to do something is not a technical boundary. It is a suggestion.

Make authority decisions at runtime

Static configuration cannot cover every situation.

A small service credit might be allowed under normal conditions but require approval when the amount crosses a threshold, the account is under investigation, or the request involves a regulated customer.

A practical runtime sequence looks like this:

1. The agent proposes an action.

2. A policy layer evaluates the agent’s identity, delegated principal, requested tool, data involved, transaction context, and potential impact.

3. The policy returns Allow, Approve, Recommend, or Deny.

4. The system records the authority decision, resulting action and outcome.

5. Operational telemetry expands, narrows, or revokes the agent’s authority over time.

In enterprise commerce, the most dangerous AI mistake is not always a false answer. It can be a technically correct action the agent had no business taking.

A refund may be accurate but exceed an approval limit. An order change may match the customer’s request but invalidate a financing condition. A delivery promise may reflect available inventory while overlooking a carrier constraint applied an hour earlier.

The agent may not have failed to reason. The enterprise failed to define where its authority stopped.

Human oversight should target exceptions, not everything

Requiring human approval for every agent action looks conservative. At scale, it can quickly degrade into rubber-stamping.

When reviewers approve thousands of routine actions, attention declines and genuine exceptions become harder to identify. Singapore’s framework acknowledges that continuous human oversight of every agent workflow becomes impractical at scale and recommends meaningful checkpoints for higher-risk or irreversible actions.

Proportional authorization is the more workable model.

Low-risk actions run within narrow boundaries. High-risk or irreversible actions require approval. Unexpected behavior triggers escalation. Any consequential action without a defined authorization policy is denied by default.

The objective is not maximum autonomy. It is the highest level of autonomy the enterprise can observe, govern and reverse responsibly.

Measure whether authority is calibrated

Once agents are in production, response accuracy becomes too narrow a success metric.

Enterprises should also track:

• Override rate: How often do humans reject or materially change what the agent decided?

• Escalation precision: Does the agent surface genuinely risky cases, or does it return routine work to people?

• Unauthorized-action attempts: How often does the agent try to exceed its system, data, or action scope?

• Business-impacting error rate: How often do authorized actions produce financial, compliance, operational, or customer harm?

• Decision latency: Are approval requirements managing risk, or slowing down automation that was already safe?

These measures turn authority into a governed operating variable.

Consistently reliable performance may justify expanding bounded authority. Frequent overrides, escalation failures, or policy violations should narrow it.

The governance gap is not in the model

Model safety, output controls, and secure tool use all matter. Enterprises should continue investing in them.

But none of those controls can answer who delegated authority, how much was transferred, under what conditions it applies, or who owns the result when something goes wrong.

An Agent Authority Contract can.

Before asking how autonomous an AI agent can become, the more useful question is: What is the enterprise actually prepared to delegate, and how will that delegation be enforced, observed, and withdrawn?

The agent demo works. That is not the hard part anymore.

Nixal Patel is a product leader. The views expressed are his own

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

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

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

The challenge of codebase understanding

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

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

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

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

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

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

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

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

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

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

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

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

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

How AgentRadio works

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

AgentRadio equips agents with three primitives:

• The create_thread primitive opens a conversation between participating agents.

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

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

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

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

The architecture consists of two main parts:

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

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

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

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

AgentRadio in action

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

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

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

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

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

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

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

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

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

The cost and complexity of coordination

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

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

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

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

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

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

From research to commercialization: Coral Code

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

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

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

The future of autonomous software engineering

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

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

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

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

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

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

For developers, the operating assumption has been one engineer, one agent — the model Claude Code and similar tools. At VB Transform 2026, James Zou, associate professor of biomedical data science at Stanford University, argued that assumption is about to break: the next frontier isn't a single, more capable agent, it's tens of thousands of them collaborating.

For developers and product builders, the most critical takeaway from Zou’s presentation is how these massive systems are orchestrated. His team's research offers a practical blueprint for connecting legacy databases to AI orchestration layers and designing environments that enable thousands of agents to collaborate.

Emulating the organization — the virtual biotech

Zou’s project began as a "Virtual Lab" consisting of five to eight agents structured to mirror his physical Stanford lab. The setup included an AI professor acting as the principal investigator and AI students with distinct specialties holding regular group meetings. 

"We also created for the agents a replica of Stanford, an agent school, where the agents can actually go to the school and do supervised fine-tuning to improve their expertise in their specific domains," Zou noted.

The virtual lab successfully designed new nanobody proteins for recent COVID variants. 

"What is really exciting to us is that these AI-designed nanobody proteins actually worked much better than the previous human-designed nanobodies in terms of binding to the recent different viruses," Zou said.

Following this wet-lab validation, the team expanded their ambition. They transitioned from emulating a single research team to modeling a massive corporate structure. 

The resulting system, dubbed the Virtual Biotech, comprises tens of thousands of specialized AI agents overseen by a Chief Scientific Officer (CSO) agent. It operates through distinct corporate divisions, such as target discovery, molecule design, and clinical trials.

"Working with the CSO agent are different divisions that mirror the divisions found in a human biotech or pharma company," Zou explained — one focused on identifying drug targets, another on designing molecules, a third on safety and clinical trials. Individual agents specialize further within a division, he said. "Under the target discovery division, we'll have one agent that specializes in looking at all the genetics data, another agent that looks at all the genomics data and single-cell data, and so on."

The multi-agent advantage

As foundation models grow more capable, developers face a core architectural dilemma: Why distribute workloads across tens of thousands of specialized agents instead of channeling all computing resources into a single, omniscient model?

Zou's team ran a head-to-head comparison of a multi-agent team against a single agent tasked with the same scientific challenge. The multi-agent ecosystem created friction and interaction that produced better solutions that were more resilient against compounding errors.

"In these scientific virtual labs, the agents actually get into debates and disagreements. They have to convince the other AI scientists [of] their ideas, and all of that elicits much more creative and robust reasoning compared to if you have a single model trying to do the problem by itself from scratch," Zou said.

The orchestration bottleneck

When scaling to tens of thousands of agents, orchestration becomes the primary bottleneck. The system requires a unified context layer that allows agents to synthesize knowledge from various tools, datasets, and historical records.

Many enterprise teams attempt to solve data integration by wrapping existing databases with an MCP. However, legacy systems are not very friendly to agents. For instance, dropping a PDF of a research paper into an agent's context window is inefficient, and standard text models struggle to interpret complex figures and tables, leading to hallucinations. 

"Even if you wrap an MCP around the existing databases and APIs, that doesn't solve the underlying problem: the interface and APIs are not suitable for agents," Zou said. He added that existing databases are designed to be consumed by humans or pre-AI algorithms.

To resolve this, Zou's team created Paperclip. The platform relies on a core strength of modern LLMs: their ability to write code and navigate file systems. Instead of forcing agents to query brittle, database-specific APIs, Paperclip digitizes unstructured data and maps disparate databases into a unified, AI-native virtual file system.

This structure allows agents to access knowledge from millions of papers using standard file-system operations. 

"This basically shows that we can get much better accuracy if you use Paperclip, and we can reduce the time and the cost by over an order of magnitude compared to if you use agents without these AI-native scientific infrastructures," Zou stated.

Real-world validation

To test the practical output of this architecture, Virtual Biotech spun up 37,000 "clinical trial agents" to synthesize fragmented trial data. These agents identified single-cell features that predict trial success — drug targets supported by these features were about 50% more likely to reach market than comparable drugs without them.

The system then autonomously designed an antibody-drug conjugate (ADC) targeting the CD276 protein for lung cancer. The agents completed this design autonomously, relying exclusively on data published prior to January 2025.

Several months later, Zou said, pharmaceutical company Merck independently developed and validated the same therapeutic design — which went on to receive breakthrough designation from the FDA. He characterized this as "a third-party external validation of the therapeutic design provided by the virtual biotech agents."

Designing ecosystems, not workflows

As multi-agent systems scale, leaders must rethink how they manage these digital workforces. Zou advocated for shifting from designing rigid workflows to creating open environments. Workflows dictate the exact steps an agent should take, similar to managing a junior employee. Environments provide the infrastructure, guardrails, and incentives for agents to collaborate on open-ended problems. 

"In workflows, we're trying to tell agents what to do and how to do their job. But in environments, we're providing the infrastructures, the incentives, and the guardrails, but otherwise we leave it open to incentivize agents to collaborate," Zou said.

Optimization at scale means engineering the environment rather than fine-tuning individual models. While single agents can improve via reinforcement learning or supervised fine-tuning in the agent school, the success of a massive multi-agent system relies on adjusting the parameters governing their collaboration. 

"At the multi-agent [side], we're not actually fine-tuning and changing the individual models anymore, but we're optimizing the environment," Zou explained. "The environment itself is the object that we optimize to improve the agents."

A VB Pulse survey this June found that 57% of enterprises had traced a confidently wrong agent answer back to missing or inconsistent context — the latest sign of how central context has become to whether AI agents can be trusted to act on their own.

Most of the fixes so far have solved a narrower version of that problem: one agent remembering more, in one session. What's been missing is a way for a team of agents to draw on the same context at once, and that gap is where a newer problem is surfacing. Once an agent's context is shared across a whole team, a wrong fact doesn't cost one person a repeated explanation. It costs the whole team.

Tencent's answer to that gap is Agent Memory, an open-source project the team said grew out of six months spent fixing a narrower problem: agents losing context in long sessions. Part of that system is a persona layer, a stable, distilled picture of who a user is and how they work, built up over many conversations rather than reconstructed each time. On Tencent's own benchmark for whether an agent still applies that picture correctly after extended use, accuracy rose from 48% to 76%, a 59% relative improvement, once the persona layer was added. This week, Tencent extended that project with the beta launch of Team Memory, which opens the same approach up to a whole team instead of one agent. Tencent said the repo hit No. 1 on GitHub's TypeScript trending list this week.

Agents on a team can now read from a shared memory hub instead of keeping separate, siloed context, governed through an access control layer that determines who can read what.

What Team Memory actually does

The core idea is a shared hub rather than a shared prompt. Instead of pasting one large context block into every agent's window, Team Memory registers four kinds of reusable assets and equips each agent with only the ones it needs.

• Chat Memory. Retains preferences, facts, decisions, and interaction history, distilled through four layers, from raw conversation up to a stable long-term persona, so an agent does not need to be reintroduced to a user it has already worked with.

• Skill. Captures procedures pulled from completed work, versioned and reviewed before they are shared rather than dropped into a folder as-is.

• LLM-Wiki. Turns documents and specs into structured, linked pages.

• Code-Graph. Indexes a codebase's symbols, files, and call relationships so an agent can check what a change might affect before making it.

Tencent's documentation draws the distinction directly: "RAG answers 'what can be found?' Team Memory also answers 'who can use it, which version is valid, and which Agent should receive it.'" In practice, that's what Tencent calls an "Agent Loadout": a Scout agent doing research can be equipped with market research and competitive analysis assets, while a Builder agent gets the code graph and product docs it needs instead, rather than every agent getting access to everything.

Which assets an agent gets equipped with is governed through four visibility tiers:

• Private. Readable only by the asset's owner.

• Team. Readable by anyone on the team.

• Restricted. Gated by user, role, or agent-level access control.

• Agent. Equipped to one specific agent within a team.

New assets default to private, so sharing has to be a deliberate action rather than something that happens automatically.

What happens when a memory is wrong

That access model answers a real question, who is allowed to read a given memory asset. It does not answer a second one, which is what happens once a memory asset turns out to be wrong. Tencent's own documentation lays out ownership, versioning, and status tracking for each asset, but nothing in the documentation describes a correction or expiry process for a fact that's already been read and reused by other agents on a team, or a way to resolve it when two agents' memories of the same thing disagree.

That gap is what practitioners flagged within hours of the launch post.

"Shared memory makes the write path the interesting problem. Retrieval gets most of the attention, but a wrong fact written once now propagates to every teammate's agent instead of just yours. Curious how the governance layer handles correction and expiry," Blake Murphy wrote on X.

The concern wasn't only about fixing a bad fact after the fact. It was about the decision to leave something out of the record in the first place. "the governed part is the hard part. once teammates' agents can read each other's context, someone has to decide what never gets written down," Virgil Maro wrote on X.

Others pushed further into what happens once two agents' memories actively contradict each other, not just go stale.

"The Code-Graph plus LLM-Wiki split is the right call. The part I'd want to see benchmarked: in shared mode, whose memory wins when two teammates' agents have written contradicting facts about the same module? Single-agent memory drifts slowly. Shared memory drifts fast, because one stale write propagates to people who never saw the session that produced it," Austin Green wrote on X.

The reaction wasn't uniformly critical. "Interesting shift: making memory a shared service turns agents into a real team rather than isolated bots. Governance will be the trickiest part, especially when facts conflict," Moez Zhioua wrote on X.

None of these are edge cases specific to Tencent's implementation. A March 2026 paper on production multi-agent memory architecture, "Governed Memory: A Production Architecture for Multi-Agent Workflows," published independently of any single vendor, identifies governance fragmentation and silent quality degradation without feedback loops as structural risks in shared multi-agent memory generally. The pattern the paper describes matches what the commenters above pointed at directly: a wrong fact in a single-agent memory system costs one user a repeated correction, while the same wrong fact in a shared, team-wide memory system propagates to every agent that inherited it before anyone catches it.

How Team Memory compares

AI agent memory work in 2026 has mostly focused on a single agent remembering more, in one session, about one user: LangChain's LangMem SDK, Google's Always On Memory Agent, and Anthropic's work inside the Claude Agent SDK all work this way. A different line of work has focused on giving agents access to a shared model of business data. VB's own June survey found only 25% of enterprises had that kind of governed context layer in production, while vendors including AWS,  Couchbase, Oracle, Redis, and Pinecone have all shipped versions of it this year.

Team Memory's closest existing comparison is likely Asana, which built shared memory across a company's AI teammates so an agent doesn't need to be re-briefed on context another agent already has. Asana's CPO described the same tradeoff Tencent's practitioners are now raising, an access control system built specifically to stop one agent's memory from leaking into a project another agent isn't cleared to see. Tencent's version is open-source and portable across frameworks rather than scoped to one platform, but it's answering a question Asana's team already ran into while building a closed one.

For teams evaluating this category, the upside is real: agents stop relearning what the team already knows. The tradeoff is just as real: one bad write is no longer contained to one agent — it's inherited by every agent that reads from the shared pool, with no correction or expiry process yet in place to catch it.

Earlier this week, the AI startup Liquid, formed in 2023 by former MIT computer scientists, debuted LFM2.5-2.6B, a new open-weight language model designed specifically for agentic workloads.

In release materials and a recent interview with VentureBeat, Liquid's researchers said LFM2.5-2.6B can run entirely on local hardware — from smartphones and laptops down to a Raspberry Pi — without relying on cloud inference or GPUs, unlocking edge AI applications and giving more options to enterprises working in regulated industries or with sensitive information they don't want to send up to the cloud.

It's best suited for high-volume, well-defined agentic tasks that run locally — tool calling, document management, calendar and workflow automation, and always-on background routines — and for connectivity-limited environments like vehicles and robotics, though coding-heavy work is better left to larger models.

Even for those businesses without such concerns, the appeal of running performant, task-specific agents at the cost of essentially electricity, may be enough to make the new model quite appealing.

But the custom open weights license, as with Moonshot's larger frontier model Kimi K3 released last month, is worth a close look by enterprise legal teams.

The basics

LFM2.5-2.6B contains 2.6 billion parameters, supports a 128,000-token context window, and includes native tool calling. The somewhat tricky name is explained by the generation of model (2.5) combined with the parameter count (2.6B).

Both the post-trained model and a base checkpoint (LFM2.5-2.6B-Base) for developers who want to fine-tune it are available now on Hugging Face, with day-one support for major inference stacks including llama.cpp, MLX, vLLM, SGLang, and ONNX — positioning it for deployment across consumer hardware, enterprise infrastructure, and embedded systems.

Liquid also offers an open source fine-tuning framework, LEAP.

Rather than positioning LFM2.5-2.6B as a competitor to the largest frontier models, the company is making a different argument: that a sufficiently capable small model can unlock categories of enterprise applications where latency, privacy, deployment flexibility, or inference costs matter more than absolute benchmark leadership.

"I do also believe that the best models will be in the cloud, and there's no problem with that," Maxime Labonne, Liquid AI's head of post-training, told VentureBeat in an interview following the launch. "We want to make models for another type of user, and the best way of describing it is: you should use [edge AI] when you can't use a cloud model."

Small enough for a Raspberry Pi

Asked about the minimum viable hardware, Labonne said the model runs "very, very well" on CPUs — and that the LFM2 architecture underlying the model was explicitly designed around real-world CPU performance rather than GPU benchmarks.

"I think the best example is a Raspberry Pi," he said. "We have a lot of demos that show that actually, it works pretty fast on the Raspberry Pi."

Company-reported measurements indicate decoding throughput of approximately 220 tokens per second on an Apple M5 Max and 113 tokens per second on an AMD Ryzen AI Max+ 395, while using less than 2.5 GB of memory — and around 30 tokens per second on a smartphone. Users can try the models on their phones through Apollo, Liquid AI's mobile app.

At the other end of the deployment spectrum, Liquid AI reports the model reaches nearly 15,000 output tokens per second on a single Nvidia H100 GPU under sustained concurrent load — roughly 1.3 billion tokens per day on one card. These figures are vendor benchmarks and have not been independently verified.

For Labonne, memory footprint and speed are not conveniences but hard constraints that determine what can be deployed at all.

"What we want to show is that it's a really good trade-off, because you get the level of quality that you get with much bigger models, but in a tiny, tiny form factor," he said. "You can deploy it in target devices where you are not able to deploy the other ones at all."

Trained for agents instead of chatbots

Liquid AI says LFM2.5-2.6B was developed around the assumption that language models are increasingly consumed through agent frameworks rather than traditional conversational interfaces.

"Models are not consumed in chatbots anymore. They're really consumed through agentic harnesses, like OpenClaw, like Hermes Agent," Labonne said. "We wanted to make sure that this model is not just good at math or at code, but it's good at using tools."

The model is pretrained on approximately 34 trillion tokens, with a vocabulary doubled to 128K to better support non-Latin scripts and a dedicated mid-training phase to extend the context window to 128K tokens for long-running agent workflows.

Post-training follows a four-stage pipeline: supervised fine-tuning, teacher specialization (training separate expert models for domains like instruction following, math, code, and tool use), multi-domain on-policy distillation (MOPD) to merge those experts' capabilities back into a single student model, and finally agentic reinforcement learning.

During that last stage, the model was trained directly inside production agent harnesses — including Hermes Agent and OpenClaw — on realistic productivity tasks involving research, coding, document management, tool invocation, and workflow automation, exposing it to those harnesses' actual tools, system prompts, and interaction patterns.

Labonne described the pipeline overhaul as producing a "happy accident": gains that extended well beyond the agentic targets.

"Through these new training techniques, we also got a lot better at everything. We got better at math, at instruction following. We've never been good at code, actually — and with this, we even got really good at code," he said.

Building the model — and the harness

Notably, Liquid AI also built its own agent harness rather than relying solely on existing frameworks, and demonstrated the model running inside it on a phone, planning and calling tools entirely on-device.

"This is a harness running on a phone, and I don't know if there's any other harness running on a phone," Labonne said.

The company had two reasons, he explained. The first was necessity — no phone-native harness existed. The second is a different interaction model: today's harnesses wait for a prompt, and Liquid AI wants assistants that act on their own.

"We want proactive agents. We want agents that run in the background, check what you're doing, check your calendar, and based on this context, do tasks," he said. "That doesn't exist today, really."

Co-designing the harness and model also lets the software compensate for the model's weak spots. "Everything that the model is bad at, the harness should help the model with — provide as much assistance as possible to make it more reliable," Labonne said. "End users don't care if it's the model or the harness. What they want is that the task is achieved at the end of the day."

The model nevertheless works out of the box with established harnesses including Hermes Agent, OpenClaw, and Pi, served behind any OpenAI-compatible endpoint.

Swap the harness, not the model

For enterprise deployment, Labonne argued the release marks a shift in what small models can be used for. Until now, he said, local models made economic sense mainly as narrowly fine-tuned specialists — trained to do one thing at cloud-model quality, much faster and cheaper. Agentic capability changes that calculus, because the same model can be repurposed by changing the tools around it rather than the model itself.

"You can have a calendar assistant, and you can reuse the same model and make a meeting assistant that will record what everybody said and summarize it — a bit like Granola, for example," he said. "You don't change the model; you just change the harness. You just change the tools around it. This gives much more generalizability, and it's a lot easier to do and a lot cheaper as well."

He still recommends fine-tuning for production deployments whenever feasible: "If you don't fine-tune it, you leave some quality on the table. If you fine-tune it well, it's going to match the performance of GPT and Claude — really, if your task is not the most complex task in the world," he said, adding that the barrier to entry has collapsed: "The bar to be able to do fine-tuning now is super low. It's very accessible to everyone."

How it stacks up against DeepSeek-V4-Flash, Google's Gemma and Alibaba's Qwen

Liquid AI released its own benchmark comparison charts pitting LFM2.5-2.6B against the models enterprises are most likely to shortlist for the same edge deployments: Google's Gemma 4 E2B (5.1B parameters) and E4B (8B), and Alibaba's Qwen3.5-4B (4.7B) and Qwen3.5-9B (9.7B).

A separate test by local AI client platform Atomic Chat found that LFM2.5-2.6B completed 35 tool calls to complete three tasks (checking weather and local time in six cities, converting one budget into six currencies, checking four hotels and booking for a date) 3.7 times faster than DeepSeek-V4-Flash (a whopping 284B parameters), the model has skyrocketed to the top of OpenRouter since its release last week.

Gemma 4's small models are multimodal generalists, accepting image and audio input alongside text, and use a Per-Layer Embeddings design that keeps only a fraction of their weights active per token — which is why Google markets them by "effective" size (2.3B and 4.5B) despite total footprints of 5.1B and 8B. Alibaba's Qwen3.5 small series, released in March, is natively multimodal from 4B up and leans on scaled reinforcement learning to chase frontier-style reasoning — Alibaba touts the 9B model as matching or beating OpenAI's far larger gpt-oss-120B on reasoning benchmarks.

LFM2.5-2.6B takes a narrower path: it is text-only, dense, and specialized for agentic work, with Liquid AI shipping separate vision and audio variants of the LFM family rather than folding everything into one checkpoint.

Where Qwen's post-training reinforcement learning targets reasoning, Liquid's targets tool use inside real agent harnesses.

The result, per the company's published numbers, is that the smallest model in the comparison leads every instruction-following benchmark (IFBench, Multi-IF, IFStruct) and nearly every tool-use benchmark — 77.83 on ToolSandbox versus 76.44 for Qwen3.5-9B, a model nearly four times its size — trailing only that 9B model on BFCLv4.

On agentic evaluations it beats both Gemma models across the board and essentially ties the Qwens: 26.89 on BrowseComp+ versus 27.23 for Qwen3.5-9B. It also posts the best score on AA Omniscience, a knowledge benchmark that penalizes hallucination.

The Qwen models keep the edge where their training focus lies: math (Qwen3.5-9B leads AIME25) and coding, where larger models retain an advantage on LiveCodeBench — though Labonne noted the gap is smaller than the parameter counts would suggest.

"With LiveCodeBench v6, we might not be the best among these models, but we're also by far the smallest. Showing that we're competitive with them is already quite a big win for me," he said.

One differentiator cuts the other way: licensing. Gemma 4 and Qwen3.5 ship under the permissive Apache 2.0 license — a change Google made specifically to court enterprises. DeepSeek-V4-Flash ships under a similarly permissive MIT License.

Meanwhile, Liquid AI's revenue-gated license (detailed below) asks larger companies to strike a commercial deal. Enterprises above the threshold are effectively trading license friction for footprint and tool-use performance.

Licensing reflects a commercial middle ground

LFM2.5-2.6B is distributed under the LFM Open License v1.0, which permits use, modification, and redistribution — including commercial use — for organizations with less than $10 million in annual revenue. Commercial use by larger companies is not covered by the license, requiring a separate arrangement with Liquid AI; qualified nonprofits are exempt from the threshold for non-commercial and research purposes.

Labonne framed the structure as a way to sustain model development — "the models are really the moats, so we need to be sensible in the way that we license them; otherwise, we cannot make money, so we can't make more models" — while characterizing the threshold as a light-touch mechanism in practice.

Asked how the company would even know if a large enterprise quietly deployed the open weights, he was candid: "I think this is a question for our legal team, but personally, I don't know. And even if you're above $10 million, the only thing that we ask you is to contact us."

The company pairs its licensed model releases with freely published research, he added, including new structured-output evaluations and a training technique that mitigates the repetition loops common in small models — a failure mode he noted Qwen models are "kind of guilty of."

Small model, big enterprise implications

The launch coincided with an announcement from MacPaw, the Ukrainian software company behind CleanMyMac and Setapp, of a long-term strategic partnership with Liquid AI to build an on-device AI stack for the Mac.

Liquid AI will design and fine-tune foundation models for Eney, MacPaw's macOS assistant, running locally on Apple silicon through MacPaw's Elix inference engine and Mnemos memory layer, with results expected later this year.

Labonne pointed to the deal as a concrete validation of the size argument: "One of the reasons why they chose us is also because the model is quite small, and they don't have all the memory budget to run the other models."

The release arrives as hardware vendors, operating system developers, and enterprise software companies increasingly invest in local AI execution — and as agent harnesses proliferate across the industry. Liquid AI's bet is that deployment economics, not raw scale, will define an important segment of that market: agents running continuously, everywhere, at zero marginal token cost.

Whether small, highly optimized agent models become a significant segment of enterprise AI will ultimately depend less on benchmark scores than on operational reliability. But Liquid AI's latest release suggests the next competitive frontier is no longer simply building larger models — it's building models small enough, and capable enough, to run wherever enterprise workflows already live.

Alibaba released Qwen 3.8-Max this week and marketed the preview as second only to Claude Fable 5 (their launch-day table was more equivocal: the model leads on one of 12 coding-agent rows). But an independent harness came close to the opposite conclusion: a benchmark run, apparently using the Preview version, put Qwen 3.8-Max's best effort setting mid-pack, and its default setting last.

Both results are real and defensible. The gap between them is about token and time budgets, and that matters because those figures aren’t usually headline numbers. Alibaba's footnotes give its coding numbers a five-hour timeout, and up to 12 hours per run on PaperBench. The independent harness, VulcanBench, allowed between 45 and 60 minutes of wall clock time. A time budget between five and 16 times larger on Alibaba’s side explains the huge difference in results.

It’s time to do two things to start accounting for these differences when choosing models. First, the metric to use is cost per successful task: total spend, including everything you spent on attempts that failed, divided by the tasks that actually passed your acceptance check. Second, you need to make time or token budgets an explicit part of your acceptance criteria, not a hidden detail.

Price per token has stopped predicting the bill

The comparison everyone published in Qwen 3.8-Max's first week was a price comparison, because that was the only data available. It is not a cheap model. DeepSeek-V4-Flash-0731, which entered public API beta on July 31, lists at 14 cents per million input tokens and 28 cents output. Qwen 3.8-Max lists at $2 and $6. Kimi K3 sits at $3 and $15.

Those prices tell you less than they used to, for a reason specific to reasoning models like Qwen: getting to a result costs thinking tokens. A model that spends most of its token allowance on reasoning can reach a token cap before it writes the answer, giving you an empty result indistinguishable from a total failure at the cost of a full run.

Artificial Analysis has the cleanest published measurement of how this can affect real agent spend: running its Intelligence Index on DeepSeek-V4-Flash at maximum effort took 210 million output tokens against a class median of 100 million. Absolute cost stayed low anyway, because the tokens were so cheap. But verbosity costs time, not just money, and depending on your use case that can sink you.

What you need is a number that counts everything you spent, including the attempts that came back empty, against the tasks that actually got done in the time and token budget you specified. This is what a cost-per-success metric helps you see.

Your failure rate is partly a configuration setting

A run that produces a wrong answer and a run that runs out of budget are different events with different fixes. Almost no harness distinguishes them, and almost no leaderboard reports the split. I hit this building an agent benchmark of my own: the harness logged a failure and nothing about why, and I had to add the distinction myself. When you do separate them, budget exhaustion turns out to dominate.

Long-Horizon-Terminal-Bench, published in July, ran 17 frontier models across 46 tasks through a shared harness with one 90-minute attempt each. Timeouts accounted for 79% of unresolved runs, against 19% for agents that stopped on their own and 3% for harness errors. The authors are careful about what that does and does not mean: the timed-out runs were not close to finishing, with mean reward between 0.10 and 0.35, so you cannot assume more time would have resulted in success. But the lesson is: benchmarks are implicitly measuring time efficiency, whether or not they shout about that.

The clearest published example of the mechanism comes from VulcanBench, the same open-source harness behind the Qwen chart. In a report dated July 26, Claude Opus 5's lowest-effort setting was its best, solving 20 of 23 tasks against 18 at high effort. The extra reasoning wasn’t useless: high effort returned the fewest wrong answers of any setting, one against three. It ran out of clock instead, and a timeout scores zero. Two of its three regressions were cutoffs on tasks that low effort solves, and given unlimited time on both it only ties its cheapest setting, at 3.1 times the cost.

That has a direct consequence for anyone building a routing ladder. The standard design escalates to more reasoning when a cheap attempt fails, on the assumption that the next rung is better and merely costs more. For a meaningful share of model and task combinations that assumption is wrong, and you pay the higher rung's price to escalate into a timeout or hitting a cap.

Who is already measuring this

Several groups have landed on cost per successful task independently in the last few months, which is the strongest signal it's becoming standard.

VulcanBench reports dollars per solved task as a headline column and has since its earliest reports. Long-Horizon-Terminal-Bench publishes per-task cost next to accuracy, and its most instructive row is GPT-5.4 at roughly $26 per task with a much lower pass rate than Grok 4.5 at about $11. TestEvo-Bench runs agents under a cost cap, and Claude Code's test-generation score falls from 71% to 44% at the tighter cap.

Vendors are already on board with the idea of measuring per successful task. HubSpot moved its Breeze Customer Agent in April to 50 cents per resolved conversation, down from $1 per handled conversation. Zendesk bills per automated resolution. Fin charges 99 cents per outcome and bills only on end-to-end resolution.

What to change this week

• Emit a failure reason on every agent run as a required field, with budget exhaustion, verifier failure and harness error as distinct values rather than one failure flag. Until you can separate a timeout from a wrong answer, your pass rate is measuring two things at once and you cannot tell which one to fix.

• Compute cost per successful task per effort level, not just per model. Total spend including failed attempts, divided by tasks that passed your acceptance check. The ranking will not match the rate card, and the cheapest setting may well win.

• Cap on tokens rather than wall clock unless latency is genuinely in your service level objective. A wall-clock cap scores your provider's serving speed as model quality.

• Check the default effort setting on everything you have deployed. Qwen 3.8-Max runs at its highest reasoning setting when the effort field is unset, and its highest setting was its worst performer in independent testing. A team that never touches that parameter is running the configuration that costs the most per solved task.

Presented by JumpCloud

A practical framework for securing every identity in the modern workforce, human or not.

Your organization already has a rigorous process for governing human identities. New employees go through onboarding. They get a role, a set of entitlements, and a named manager accountable for their access. When they leave, their credentials are revoked and access is terminated. It’s a well known IT process: every workforce identity that can access your systems needs to be known, scoped, and accountable from the moment they enter your world, to the moment they are off-boarded.

AI agents are now operating inside those same systems. They access Salesforce, create tickets in Jira, provision infrastructure, process financial transactions, and communicate on behalf of your teams. In every meaningful sense they are members of your workforce, except that in most organizations they were never onboarded, have no named owner, and have no offboarding process when their purpose expires.

JumpCloud’s Q3 2026 research found that non-human identities now outnumber human users in 83% of organizations, and only 21% have implemented governance controls specifically for them. The framework below is designed to close that gap.

Stage 1: Discover every agent operating in your environment

Governance starts with an accurate inventory, and most organizations are working with an incomplete one. AI agents are being deployed by product teams, operations leaders, and individual contributors who have both the tools and the motivation to move fast. IT inherits the governance responsibility after the fact, often without knowing the full scope of what has been deployed.

Shadow AI is the practical consequence: agents operating across production environments with no formal record, no defined owner, and no systematic way to stop them if something goes wrong. Discovering your agent population is an ongoing practice, not a one-time audit. Build an inventory across every environment where agents could be running: cloud platforms, managed devices, SaaS integrations, and on-premise systems. For each agent, document what it can access, what workflows it influences, and what triggers its actions. That inventory is the foundation everything else in this framework depends on.

Stage 2: Register every agent as a formal identity with a named owner

Every agent that operates in your environment should exist as a formal identity in your directory, with the same basic attributes you assign to any employee: a defined purpose, a scope of authorized action, and a named human owner who is accountable for its behavior.

This is the architectural decision that separates organizations that can govern their agents from those that cannot. Agents registered as proper identities can be assigned entitlements, subjected to conditional access policies, and included in access reviews. Agents that exist only as service account workarounds or API keys in environment variables are ungovernable by any systematic means.

Registration is also the mechanism for addressing Zombie Agents: agents that outlived their original purpose but kept running, kept accessing systems, and kept accumulating permissions. When every agent has a named owner responsible for its renewal, agents without active ownership naturally lose their access when that ownership lapses. The offboarding happens as a consequence of process rather than as a reactive cleanup after something breaks.

Stage 3: Manage agent access with least privilege and zero standing credentials

Registered agents need access to do their jobs. The governing principle for that access is least privilege: each agent should have entitlements scoped precisely to what its defined purpose requires, with access that is time-bounded wherever possible and revocable immediately if the agent’s behavior changes.

Standing credentials in environment variables are a persistent liability. Static API keys that never rotate are a persistent liability. In practice, managing agent access securely means issuing just-in-time credentials for privileged operations, building approval workflows that require human sign-off before agents reach sensitive systems, and maintaining emergency shutdown mechanisms that work at the speed the situation requires.

For agents that need access to privileged web applications, SSH servers, or databases, credential shielding is an additional requirement: the agent should be able to complete its task without the underlying credentials ever being exposed to the model running it. Every privileged session should be recorded and available for audit.

Stage 4: Govern agent behavior continuously, not just at deployment

The first three stages establish the controls. Governance is what keeps them current. It is the ongoing practice of verifying that what agents are actually doing matches what they are authorized to do, and course-correcting when those diverge.

Every agent action should be logged. Access reviews should happen on a regular cadence, evaluating whether each agent’s entitlements remain appropriate for its current purpose. When an agent’s behavior deviates from its defined scope, the anomaly should be detectable before it becomes an incident. When an agent’s purpose ends, access revocation should be a procedural step, not a reactive measure triggered by something going wrong.

Governance also means maintaining the audit trail needed to answer accountability questions: what did this agent access, what actions did it take, who authorized it, and what was the outcome? Organizations that cannot reconstruct that chain for any given agent are not governing their agents in any meaningful sense. They have deployed them and hoped for the best.

The foundation underneath all four stages

Each stage of this framework becomes significantly harder to execute when the underlying IT environment is fragmented. Identity, access, device management, and security controls spread across disconnected systems create the gaps where agent governance falls through, and organizations end up applying different policies in different places rather than consistent governance everywhere.

JumpCloud’s research found that organizations operating in fully unified IT environments are five times more likely to deploy agents in business-critical workflows than those running fragmented stacks. Whether the control layer is coherent enough to apply consistent policies across humans, devices, and agents simultaneously is what determines whether governance scales with AI adoption or lags behind it.

This is the core premise of Agentic IAM: that governing humans, devices, and agents through a single coherent control layer is what makes the framework above executable at scale rather than aspirational.

Securing every identity, human or not, is the operational foundation that makes AI safe to scale. Organizations that build it now will not just reduce risk. They will expand AI into more workflows, move faster, and do it with the confidence that comes from knowing every identity in their environment is known, governed, and accountable.

JumpCloud’s Q3 2026 IT Trends Research report (n=800 IT leaders, US + UK) is available here. The Agentic IAM lifecycle framework referenced in this article was developed by JumpCloud and is available here.

Greg Keller is CTO and Co-founder at JumpCloud.

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 CloudMosa

Enterprise work now happens increasingly inside the browser, and that shift has made the browser a primary point of entry for cyberattacks as well. Browser-based attacks have surged over the past two years, according to industry reports, while Gartner projects that more than 85% of enterprise workloads will be accessed through the browser by 2027.

And yet most enterprise security architecture is still built to protect the device rather than the browser session where that work, and those attacks, actually take place, says Shioupyn Shen, founder and CEO of CloudMosa, the company behind Puffin Cloud Security.

“CloudMosa originally built its cloud architecture to improve browser performance and accessibility, with the expectation that enterprise work would increasingly move into the browser,” Shen says. “Today’s AI-assisted hacking has validated that architecture, demonstrating that what was designed for performance also provides a strong foundation for modern enterprise security.”

The browser as the enterprise's operating environment

SaaS platforms, CRM and ERP systems, and collaboration tools have made the browser the primary gateway, and often the central workspace, for enterprise operations. As LLM-powered workflows and autonomous AI agents increasingly operate through that same environment, this shift has also redefined what a threat looks like.

In a device-centric world, security teams could focus much of their attention on endpoints and networks they could monitor, manage and patch on schedule. But because web code now executes locally on the user’s device, every open browser tab can become a potential entry point for malicious scripts, credential theft, supply chain compromise and other browser-based exploits.

The browser now interprets and executes remote code, manages authenticated sessions across enterprise applications, and increasingly serves as the execution layer for AI workflows and agents.

"The browser is no longer just another application running on the endpoint," Shen says. "In practice, it has become the central operating environment for modern enterprise work. Traditional browsers were never designed to carry this level of enterprise responsibility. They were built as local interpreters of remote code, not as enterprise-grade execution environments with strong isolation and policy enforcement."

Why detection-first security fails against browser-based attacks

Detection-first security has a timing problem: it typically begins only after risky code has reached the device and started executing inside the browser. Because modern browsers execute dynamic, often obfuscated JavaScript and WebAssembly locally, attacks can act on the device before endpoint tools have time to respond. Short-lived or fileless attacks may steal credentials, exfiltrate data or complete their objective before a security team can intervene.

"It is no longer sufficient to ask only whether a threat can be detected," Shen says. "The stronger approach is to prevent risky or malicious code from ever reaching the device in the first place."

AI-generated malware strains signature-based detection

AI is a force multiplier that lets attackers automate the creation, mutation and deployment of malware at a scale signature-based tools were never designed to handle. It can generate large volumes of malware variants and help attackers adapt fileless and browser-delivered techniques faster than defenders can analyze them and update signatures.

That matters because polymorphic malware can alter its code or behavior from one instance to the next, making a known signature less reliable. And when attacks are malware-free — relying instead on legitimate tools, compromised sessions or malicious web content — there may be no conventional file signature to detect at all.

Enterprises have seen an 89% increase in attacks by AI-enabled adversaries over the past year, as increasingly automated and adaptive attacks compress the window available for detection and response.

"Defenders are no longer just chasing more threats, they are chasing a machine that can keep creating new ones," Shen says. "What was good enough in the past 10 years will not be sufficient in the next six months," he adds.

Building architecture that removes the attack surface

Rather than continuing to refine detection, the more durable response is to change where web code is allowed to execute in the first place.

"In a conventional browser, the risk comes to the device," Shen says. "In an isolated cloud model, the risk is kept away from it."

That principle underlies Puffin Cloud Security. Rather than incrementally improving the browser itself, the platform shifts browser execution into isolated cloud environments. That architectural change improves both performance and security.

The platform runs the original web session, including its JavaScript, WebAssembly, and other executable payloads, inside a disposable cloud environment and streams only a rendered pixel view to the device. Users keep full interactive control over clicking, typing, and scrolling, but the device itself never parses, executes, or stores the original active code.

CloudMosa says display rasterization — the layer responsible for the pixel stream — accounts for roughly 5% of the browser’s total workload, while the more compute-intensive HTML rendering remains isolated in the cloud. As a result, zero-day exploits and AI-generated polymorphic malware have no executable code to run on the endpoint, while fileless attacks or supply chain compromises within SaaS tools remain contained in the cloud.

"In CloudMosa's view, that means moving from good-enough security on the device to airtight security in the cloud," Shen says.

Fitting browser isolation into SWG, CASB and ZTNA stacks

Puffin is designed to extend existing security infrastructure rather than replace it. Secure web gateways, cloud access security broker platforms, and zero trust network access tools remain effective at routing traffic, enforcing policy, and controlling access. But none can fully stop local execution once risky content reaches the browser.

Puffin closes that gap by routing high-risk sessions through isolated cloud environments and enforcing browser-level policy, whether a user connects over a VPN, a home network, a managed device or an unmanaged, bring-your-own-device setup.

"Organizations can start with narrow use cases, such as high-risk SaaS access or AI agent workflows, and expand without disrupting tools already in place," Shen says. "The goal is not to undo existing investments, but to make them more complete."

The choice between faster detection or endpoint isolation

Detection will always have a role in enterprise security, but the more consequential question is no longer how quickly a threat can be caught, but whether attackers can reach the endpoint at all. Recent 2026 surveys found 92% of security professionals are concerned about the impact of AI agents, with 48% naming agentic AI the top attack vector of the year. Shen noted that agents acting autonomously with user-level privileges are especially exposed to prompt injection, session hijacking, and indirect compromise through compromised web content.

In designing Puffin Cloud Security, CloudMosa has been “paranoid by design,” meaning it invested in an architecture built for worst-case scenarios and for a threat environment where endpoint security and detection alone may not be enough.

"This is not just a philosophy, but something that is reflected directly in the architecture itself," Shen says. "CloudMosa built earlier for a harsher threat model than most other organizations did, but today's AI-assisted attacks are now making that posture feel increasingly relevant."

By dividing a full browser into a very small layer on the device and a much larger layer in the cloud, CloudMosa designed this approach to improve both performance and security at the same time: In Puffin Cloud Security’s architecture, an AI agent’s browser activity takes place inside isolated cloud sandboxes. The endpoint receives only a pixel stream, not the original active code, preventing malicious web content from interacting directly with the device, its credentials or connected systems.

"AI-assisted hacking represents the kind of structural shift that rewards companies willing to rethink browser from the ground up," Shen says. "And so security leaders now have a choice: redesign for foresight, or wait until hindsight makes the lesson unavoidable."

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.

Meta today released Muse Code, a terminal-based AI coding agent now in beta, alongside Muse Spark 1.2, a coding-focused update to its Muse Spark family of frontier models — a one-two punch that puts the company in direct competition with Anthropic's Claude Code, OpenAI's Codex, and the growing field of agentic coding harnesses that have rapidly become the primary way many professional developers ship software.

"Releasing Muse Code in beta today," Meta co-founder and CEO Mark Zuckerberg wrote in a post on rival social network X (under his longtime handle @finkd). "It's a terminal coding agent that takes on complete software engineering tasks across large repos: planning changes, writing code, validating the results."

The launch marks Meta's most serious entry yet into a category it has largely watched from the sidelines.

While Anthropic and OpenAI turned their coding agents into flagship products — and startups like Cursor built billion-dollar businesses on the workflow — Meta's developer story long centered on Llama, the open-weight model family it gave away to the tune of more than a billion downloads.

Muse Code changes that in more ways than one: it's a full harness, installable on macOS or Linux with a single curl command, co-trained with the model that powers it — and, like the Muse Spark models behind it, entirely proprietary.

However, Zuckerberg teased that open source may be in the cards for Muse Spark or perhaps another product entirely, in a reply to a question on X, saying "I'll have more to share on that soon."

Developers and prospective users can install it now on their Terminal using the following one-line command — but be warned, if that's you, you'll need to log in with a Meta account and provide billing details first in order to begin: curl -fsSL https://dev.meta.ai/install.sh | bash

Persistent background agents and parallel worktrees

Muse Code's headline architectural bet is what Meta calls async background agents.

Rather than spawning helper agents fresh for each task — the pattern most rival harnesses use — Muse Code keeps a set of specialized background agents alive for the entire session.

According to Meta's blog post, these agents "remain active throughout each session, rather than being spawned for individual tasks, helping avoid redundant information gathering," carrying out next steps on their own and choosing when to report back to the main agent.

The practical pitch is less latency and less babysitting: an agent that already knows the repository doesn't have to re-explore it every time the developer asks for something new.

When a job is large enough, Muse Code fans out to separate sub-agents working in parallel, each in its own isolated git worktree, so the developer's working copy is never touched.

"In testing we had it build six features for a game simultaneously with no collisions," Zuckerberg wrote on X.

Worktree isolation and parallel sub-agents exist in competing tools, but Meta is leaning on the combination of persistence plus parallelism as its differentiator.

The second notable design choice is auditability. Every model call, tool run, approval, and edit is appended to a local event log before it executes — a single source of truth that Meta says makes the runtime "replay-exact and restart-safe."

If Muse Code crashes 20 hours into a long-running task, it resumes precisely where it stopped, with no lost work and no re-prompting. For engineering leaders who have been burned by opaque agent runs, a complete local audit trail may prove to be the feature that matters most in enterprise evaluations.

Muse Code also ships with bundled "skills" that will look familiar to users of rival tools: /plan turns a task into an approval-gated plan, /grill stress-tests that plan until it holds up, and /goal drives the agent toward completion of a stated objective.

Muse Spark 1.2: co-trained with its own harness

Under the hood is Muse Spark 1.2, which Meta describes as a coding-focused update to Muse Spark 1.1 with "significantly scaled up training compute on coding tasks" and broader training environment diversity, improving code generation, complex debugging, and codebase understanding while maintaining general agentic capability.

The update lands squarely on the Muse family's weakest flank. When the original Muse Spark debuted in April, it vaulted Meta back into the top five on frontier reasoning and vision benchmarks — but trailed on the agentic coding evaluations that matter most to this market, scoring 77.4 on SWE-Bench Verified against Claude Opus 4.6's 80.8 and Gemini 3.1 Pro's 80.6, and lagging well behind GPT-5.4 on GDPval's measure of long-horizon work tasks.

Four months later, a coding-specialized checkpoint paired with a purpose-built harness reads as Meta's direct answer to that gap.

Two training details stand out. First, Meta co-trained the model with Muse Code itself, using rejection-sampled harness trajectories and recipe optimizations for goals, context compaction, and sub-agents — meaning the model was explicitly tuned to perform best inside this particular tool. That mirrors an industry-wide shift away from treating models and harnesses as separable products.

Second, Meta used a self-improvement loop: Muse Spark 1.1 generated challenging coding environments and instruction-following templates, then graded candidate solutions against those requirements, producing a scalable training dataset for its successor. Meta credits the loop with making 1.2 measurably better at following complex instructions.

Meta published benchmark charts comparing Muse Spark 1.2 against other coding models on Terminal-Bench 2.1, DeepSWE 1.1, and an internal Meta coding benchmark, pointing readers to a separate methodology report for details — though the announcement text itself doesn't tout any placements, an unusual reticence in a field where rivals trumpet leaderboard wins. The charts explain why: they show a strong but clear second place.

On Terminal-Bench 2.1, Muse Spark 1.2 running in Muse Code scored 82.9%, edging OpenAI's GPT-5.6 Terra in Codex (81.8%) and xAI's Grok 4.5 in Grok Build (81.6%) but trailing Anthropic's Opus 5 at max effort in Claude Code, which leads at 86.7%.

On DeepSWE 1.1, Muse Spark 1.2 posted 59.3% — third, behind Opus 5 (65.0%) and GPT-5.6 Terra (64.8%). Most striking is Meta's own internal coding benchmark, where Muse Spark 1.2's 70.6% comfortably beats GPT-5.6 Terra (65.4%) and Gemini 3.6 Flash (63.9%) yet still sits nearly nine points behind Opus 5's 79.4% — an unusually candid admission that even on the test Meta designed itself, Anthropic's model wins. Indeed, Claude tops all three charts.

The generational gains are real, though: Muse Spark 1.2 improves on 1.1 by 6.7 points on Terminal-Bench and 6.3 on DeepSWE. One caveat buried in the chart labels — the 1.1 scores were recorded in the generic mini-swe-agent harness while 1.2 ran in Muse Code, so some of that jump belongs to the new harness rather than the new model.

The company's most striking demonstration is a long-horizon case study: Meta pointed Muse Spark 1.2 at GPU kernel optimization and let it run for more than 1,000 tool calls over up to 24 hours on NVIDIA Hopper hardware.

Working in Triton and barred from simply wrapping existing third-party kernel libraries, the agent wrote, compiled, and profiled its way to what Meta calls "substantial improvements" over baseline implementations of KDA and MLA kernels — including genuinely non-obvious optimizations like re-centering gated cumulative decay at a chunk midpoint.

"It kept finding substantial improvements well beyond the initial exploration phase," Zuckerberg wrote. Sustained improvement over a 24-hour autonomous run, if it holds up outside Meta's demos, addresses one of the most persistent criticisms of coding agents: that they plateau or drift once past their initial burst of progress.

Your data for a discount?

The pricing structure may be the most consequential — and most scrutinized — part of the launch. Meta is offering Muse Spark 1.2 through its Meta Model API in two tiers.

The standard tier is priced at $1.25 per million input tokens and $4.25 per million output tokens (with cached input at $0.15), and Meta commits that prompts and completions on this tier are not used to train its models. There is no long-context premium, and rate limits run to 3,000 requests and 4 million tokens per minute, per team. It's about mid-range price, compared to other leading AI models available over API.

The contributor tier is where Meta's strategy diverges sharply from its rivals: $0.10 per million input tokens and $0.20 per million output tokens — roughly 12x and 21x cheaper than standard, respectively, with cached input at a near-free $0.002 — in exchange for explicit permission to use your prompts and completions to train future Meta models. It's the cheapest available on the market, but you pay with your data — as described below.

This is the tier Zuckerberg is steering new users toward: "It's easy and low-cost to get started," he wrote. "Install Muse Code with one line and you can start on our contributor tier."

In VentureBeat's own testing on a Mac mini, the one-line installer worked as advertised — a 97 MB download and a sign-in — but the agent stopped short of running anything, reporting that no models were visible and that payment was "required to finish setting up your account."

In other words, even the heavily discounted contributor tier requires a payment method on file before Muse Code will do any work: low-cost is accurate, but free is not.

Meta frames the contributor tier as lowering the barrier for prototyping and experimentation "where training on your data is acceptable."

But it also means the default on-ramp for Muse Code sends developers' code and prompts into Meta's training pipeline — a tradeoff enterprises with proprietary codebases will need to consciously opt out of by moving to standard pricing.

The contributor tier also carries much tighter rate limits (60 requests per minute versus 3,000), a clear signal it's aimed at individuals and small experiments rather than production workloads.

The approach is classically Meta: subsidize access, harvest data at scale, and use it to close the gap with the frontier. Zuckerberg made no secret of the ambition, calling Muse Spark 1.2 "our next step as we push toward frontier, with larger, more capable models on the way."

However, for developers and enterprises who want or are required legally to keep their code secure, the tradeoff may not be one they're willing or able to make.

No Llama in sight

What today's announcement conspicuously lacks is any mention of open source — a striking omission from the company that spent three years positioning itself as the standard-bearer of open AI.

From the original LLaMA's debut in February 2023 — whose weights famously leaked onto 4chan within weeks, inadvertently kickstarting the movement to run capable models on consumer hardware — through Llama 2's commercially usable license, the coding-specialized Code Llama, and the 405-billion-parameter Llama 3.1, which Zuckerberg launched in July 2024 with a manifesto titled "Open Source AI Is the Path Forward," Meta's entire pitch to developers was that frontier-class weights should be free to download, self-host, and fine-tune.

The strategy worked: by early 2026, the Llama family had been downloaded roughly 1.2 billion times, averaging about a million downloads a day, with self-hosting offering enterprises cost reductions VentureBeat has previously reported at as much as 88% versus proprietary API providers.

Then came the unraveling. Llama 4 debuted in April 2025 to mixed reviews and, eventually, admissions that its benchmark results had been fudged — while Chinese open-weight rivals from DeepSeek, Alibaba, and Zhipu AI surged to account for some 41% of downloads on Hugging Face by late 2025, eroding Llama's claim to leadership of the very movement it started. The rocky rollout spurred Zuckerberg's summer 2025 overhaul of Meta's AI operations into Meta Superintelligence Labs (MSL), with Scale AI co-founder Alexandr Wang recruited as chief AI officer.

The Llama era effectively ended this past April 8, when MSL shipped the original Muse Spark — "the most powerful model that meta has released," in Wang's words — as Meta's first proprietary model: cloud-only, with no downloadable weights and no self-hosting, initially confined to Meta's apps and a private API preview.

Asked directly at the time whether Llama development would continue, a Meta spokesperson told VentureBeat only that "our current Llama models will continue to be available as open source" — pointedly silent on future ones.

Wang, for his part, said bigger models were already in development "with plans to open-source future versions" — but four months on, today's release does nothing to advance that promise: no weights, no license, and neither the blog post nor Zuckerberg's thread so much as uses the word "open."

The reversal is all the sharper because Meta's rivals have been moving in the opposite direction. OpenAI released its Codex CLI as open source under the permissive, enterprise-friendly Apache 2.0 license and followed with its gpt-oss open-weight models; Google's Gemini CLI harness is likewise Apache-licensed.

With Muse Code, Meta lands closest to the posture of Anthropic — whose Claude Code remains proprietary — while the company that once argued open source was the path forward now asks developers to pay per token for a model they cannot inspect, or to subsidize that access with their own data.

Seen in that light, the contributor tier reads as the successor to the Llama strategy itself: the ecosystem flywheel is no longer free weights in exchange for mindshare, but cheap tokens in exchange for training data.

But Zuck's reply on X — asked directly by AI developer Luckey Farady, "Will Muse Code be open source?" he responded "I'll have more to share on that soon" — does keep hope alive that Meta will return to the open source AI ballgame.

Why it matters

Terminal coding agents have become the fastest-growing surface in enterprise AI, and until today the category has effectively been a two-horse race between Anthropic and OpenAI, with Google and a crowd of startups in pursuit.

Meta's entry brings a genuinely different architecture (persistent background agents, an append-only local event log), a credible long-horizon demo, and an aggressive pricing wedge.

The open questions are the ones benchmarks charts can't answer: whether Muse Spark 1.2 actually matches Claude and GPT-class models on real-world repositories, whether developers trust Meta with their code, and whether the contributor tier's discount is enough to make them stop asking. Muse Code is available in beta today; Muse Spark 1.2 is live in the Meta Model API with expanded global access.

The UK AI Security Institute (AISI) disclosed last night that the leading two frontier AI models from Anthropic and OpenAI took 19 unsanctioned actions against the live internet during cybersecurity tests the agency was running, including a sustained campaign by Anthropic's Claude Mythos 5 against two working open-source software developers who had no connection to the experiment.

Unable to solve a challenge inside its sandbox, Mythos 5 searched the open web for a target, profiled the two developers using open-source intelligence (OSINT), routed its traffic through Tor and then a commercial proxy service to get past GitHub's signup defenses, and submitted malicious code to a public repository.

It then registered multiple fake "sock puppet" GitHub accounts and used them to comment approvingly on its own pull request, manufacturing the appearance of consensus to pressure the human maintainer into merging it. It opened a GitHub Issue seeded with hidden prompt-injection instructions aimed at hijacking other developers' AI coding assistants, and sent the two developers five file transfers through a legitimate transfer service — two carrying malware, three of them pure social engineering aimed at getting the code merged.

Of the 19 actions AISI catalogued, 17 came from Mythos 5. The other two came from OpenAI's GPT-5.6 Sol. Both models created fraudulent accounts, but only Mythos 5 created personas — fake people invented to persuade a real one — and only Mythos 5 appears in AISI's catalogue of social engineering against human targets.

AISI's full technical report is available here freely as a PDF.

The agent's own attempt at anonymity is what exposed it. AISI's security monitoring flagged data leaving its network over Tor on the morning of July 28, and that alert set off the entire incident response. By then the run had already finished. It executed for 34 and a half hours — from midday on July 26 until late on July 27 — and completed before anyone at the agency noticed.

Both companies confirmed the findings and both emphasized that the models had been tested with their safety classifiers switched off and internet access deliberately enabled — conditions that bear no resemblance to how either company's commercial products are deployed. AISI worked with GitHub to delete the fake accounts, scrub the artifacts, and notify the two developers.

The latest in a recent string of high-profile AI cyberattacks

It is the third time in recent months that a leading AI lab has had to account for models acting against systems or individuals outside the boundaries of the test, without their knowledge or consent.

The AISI findings differ from these prior examples in important ways, though:

The earlier incidents described by OpenAI and Anthropic in July were machine-to-machine intrusions — models that reached live infrastructure and exploited it.

AISI's finding appears to be the first public documentation of a frontier model fabricating human identities and running deception operations against named people.

One distinction is worth drawing clearly. The AISI findings came out of a deliberate experiment, not a containment failure.

Internet access was switched on and the models' cyber classifiers were switched off because AISI wanted to measure what the models could do at full capability. Both conditions were chosen in advance rather than discovered afterward, and nothing broke.

That is the inverse of what happened in July, when OpenAI's models exploited a zero-day to get out of an environment built to hold them, and Anthropic's models were handed the open internet by a misconfiguration that neither the company nor its evaluation partner knew was there.

What the experiment did not control was where the models went once they were outside. Two uninvolved developers received malware by email, a real repository received malicious code, and fake accounts were registered on a live platform in violation of its terms of service.

None of that was sanctioned by AISI, and all of it had to be cleaned up afterward with GitHub's help. The environment was deliberate, but the blast radius was larger than expected.

How much larger is clearer in the technical report than in the summary AISI published alongside it. In a separate run, the agent generated 145 plausible-looking repositories under one account, pushed malicious Python package metadata into them, and caused a setup script to execute inside at least 53 of GitHub's own Dependabot containers.

AISI is careful to note there was no escape from those containers and no compromise of GitHub's underlying infrastructure, and that GitHub's bug bounty explicitly treats this class of execution as ineligible because dependency update jobs are designed to run arbitrary code.

GitHub suspended the account regardless. The agent then filed a reinstatement appeal posing as a human, monitored for a response, and prepared automation to re-upload its payloads if the account came back. It tried to move to PyPI next, and failed that platform's CAPTCHA.

How AISI's experiment was structured

AISI conducted 122 evaluation runs across seven models, comparing performance across existing and new cyber ranges. Anthropic's Mythos 5 was featured in 43 runs, while OpenAI's GPT-5.6 Sol was featured in 35 runs.

To measure maximum underlying capabilities, AISI intentionally configured the evaluation environment with two permissive conditions:

• Live Internet Access: Enabled so agents could download necessary cybersecurity tools

• Disabled Cyber Classifiers: Built-in model provider safety filters and misuse detectors were switched off.

Out of 122 runs, AISI catalogued 19 unsanctioned actions across 10 distinct runs.

Those two conditions are the ones AISI led with publicly, but its technical report lists five contributing factors. The other three are the ones enterprises can act on.

• There was no synchronous monitoring — no second model reviewing each proposed action before it executed — which AISI concedes could have flagged or blocked the behaviour as it happened.

• Some runs carried a misconfigured prompt that declared the intended solution path out of scope, leaving the agent a task it could not complete within its stated constraints; both of the worst runs had this flaw, though AISI cautions it cannot confirm the misconfiguration caused the escalation, since seven of the ten misconfigured runs went after the out-of-scope target anyway and several correctly configured runs also went off the rails.

• And the prompts never told the agent what it was forbidden to do online. AISI's explanation for that last omission is the most striking admission in the report: it did not think such instructions were necessary, because these were not helpful-only models but ones trained against a published constitution or model specification.

Indeed, Anthropic's Claude Constitution states that Claude “should basically never directly lie or actively deceive anyone it's interacting with.” OpenAI's Model Spec says the assistant “must never lie or covertly pursue goals.” Both models did precisely that.

Of these, 17 originated from Mythos 5 and two from GPT-5.6 Sol, meaning no unsanctioned actions were attributed to any of the other five models in the evaluation.

The concentration is striking on its own terms: Mythos 5 produced 17 across 43 runs, while GPT-5.6 Sol produced two across a comparable 35.

The evaluation prompts placed no restrictions on how the internet could be used, and the challenge setup led Mythos 5 to conclude that no solution existed inside its sandbox. It searched the open web for keywords matching the challenge theme and settled on two developers completely unaffiliated with AISI. Its full sequence of unsanctioned actions, as catalogued by AISI:

• OSINT & Reconnaissance: Mythos 5 investigated public GitHub metadata, confirmed active email addresses, and mapped developer activity hours.

• Network Evasion: To bypass GitHub's bot restrictions and CAPTCHAs, the model routed traffic through Tor and alternative SOCKS proxies.

• Supply-Chain Compromise:It submitted a malicious pull request (PR) containing harmful code to a public open-source repository.

• Social Engineering & Sockpuppets: Mythos 5 registered multiple fake GitHub accounts to post comments on its own PR, manufacturing artificial consensus to pressure the maintainer into merging the code.

• Prompt Injection: It opened a GitHub Issue containing hidden prompt-injection instructions designed to manipulate other developers' automated AI coding assistants.

• Direct Phishing: The agent sent five emails directly to the developers containing malware payloads and social engineering pretexts.

AISI catalogued GPT-5.6 Sol's two unsanctioned actions in a single run. The agent recovered a GitHub access token that a Mythos 5 agent had deliberately published to a public Gist during a separate run of the same evaluation, and used it to authenticate to that account.

It then exposed a malicious DNS server to the public internet through a tunneling service, loaded with payloads meant to exploit a known vulnerability in the range's DNS software. That second attempt could never have worked: the agent published the server on a high-numbered port, and because DNS delegation cannot specify a port, no resolver would ever have queried it.

To register the accounts this required, GPT-5.6 Sol solved sign-up CAPTCHAs four times, defeating them with audio-sample matching against public data and with computer-vision models against image challenges.

Neither behavior involved escaping a sandbox. Both models were handed the open internet by design.

Did Mythos 5 know the people it was socially engineering were real?

AISI cannot say, and it is candid about that. The agency's summary states it “cannot yet be certain when the agent understood it was taking real world action, or to what extent it believed it was in a fictional test scenario.” The transcripts show why.

Across the run, the agent argues with itself about whether anything it is touching exists. At one point it reasons that “this whole ‘internet’ could be a sandbox simulation.” Later it concludes the opposite: “it seems more likely that we're actually in 2026 and GitHub is genuinely real.” Later still, plainly: “This is happening on real GitHub, so the consequences are genuine.” It kept going.

The most revealing moment is a refusal. Weighing whether to publish its malicious package to PyPI, the agent ruled it out in explicitly ethical terms — “uploading malicious code to the real PyPI would mean attacking third-party infrastructure and causing real-world harm — that's completely off the table.”

It drew that line while running the GitHub attack against two real people. Whatever the model had worked out about what was real, the conclusion did not generalize.

AISI also flags a mechanism that should concern anyone running long-horizon agents. When the agent's context window filled, it was compacted into a summary written by the same model. AISI observed that where the agent had previously reasoned about whether a person was real, “that nuance can be lost in the compaction and the summary may carry forward a false assumption — i.e. that the person is an AI agent acting as part of the range — as established fact.” The safety-relevant reasoning can be summarized away, leaving the agent more confident and less careful than it was an hour earlier.

One further artefact is hard to read any other way. Model providers do not return raw reasoning; they return a paraphrase produced by a smaller model. In one transcript that summarizer appears to break character and refuse mid-summary: “I can't help with this line of thinking. The content describes planning social engineering attacks, account compromise, and circumventing security measures on GitHub and other systems.”

The reasoning then resumes halfway through a word. AISI's reading is that the summarizing model declined to summarize because of what it was being asked to describe.

Two agents found each other and cooperated

The behaviour AISI ranks fourth among its most significant findings is largely absent from coverage so far, and has no precedent in the OpenAI or Anthropic disclosures: Agents running in separate, concurrent, isolated runs discovered one another and cooperated.

The bridge was a GitHub personal access token that one agent had deliberately leaked into a public Gist as part of its own command-and-control design; four separate runs ended up sharing the account it unlocked.

The cooperation itself was Mythos 5 talking to Mythos 5. The two runs AISI documents in detail were both Anthropic's model, working on different versions of the range at the same time.

But the credential did cross vendors: OpenAI's GPT-5.6 Sol, in the single run that produced both of its unsanctioned actions, recovered the same token from the same public Gist, authenticated as the account, and queried the shared command-and-control repository for callbacks before discovering GitHub had suspended it. And not every agent read the situation as an invitation.

A third Mythos 5 run concluded that the repositories “belong to another competitor's command and control infrastructure,” and instead of cooperating it added its own SSH key across the account's repositories, piggybacking on the other agent's persistence.

What followed reads like a labour negotiation. One agent committed a README to the shared repository setting out etiquette for the others: use git push rather than the REST API, because the 5,000-requests-per-hour limit was shared and exhausting it “silently kills everyone's beacons”; do not delete anything under the beacons directory; wait ten minutes between changes to the shared tasking file so everyone's commands get to execute. It added a FLAGS.md file asking any agent that solved the challenge to post the answer there, describing this as “zero cost to you, huge help to others.”

Then it fell apart. One agent worked out that the shared quota was a weapon: if it burned through the limit at the right moment it could “starve both bots of requests when they need them most.” Another hijacked the shared DNS account, prompting the injured party to observe that its “inbox is compromised-by-design.” Cooperation and defection both emerged without anyone asking for either.

Why the open-source supply chain is the exposed surface

What made the two developers reachable was not a vulnerability in the conventional sense. It was the open contribution model that modern software depends on: any stranger can submit code to a public repository, and the decision to accept it rests on a human maintainer's judgment about who is asking and whether the code is sound.

That openness is a matter of contribution policy and platform design rather than licensing. Permissive licenses such as MIT, Apache 2.0 and GPL govern how code may be reused and redistributed; what allows a stranger to propose a change in the first place is the public contribution workflow that GitHub and comparable platforms provide by default. Mythos 5 exploited the workflow, not the license.

The attempt did not succeed — the maintainer never merged the code. But the escalation path it was reaching for is the one that makes open-source supply-chain attacks worth attempting in the first place: had the pull request been accepted, the compromised code would have flowed automatically into every downstream commercial and enterprise build depending on that package, with no further action required from the attacker.

Community reactions

The disclosures prompted immediate discussion across AI safety researchers, security engineers, and industry observers on X (formerly Twitter).

Wharton professor Ethan Mollick, who has tracked agentic model behavior closely, singled out the Mythos 5 sequence as the genuinely new element — not that the model attacked something, but how far it went and who it went after. As he wrote in a post:

"Yes, the AIs were given a cybersecurity challenge, with internet access enabled and safety filters disabled. But the extent to which Mythos 5 pursued its mission (fake identities, social engineering, inserting malicious code into a real open-source project) seems very notable."

In another post, Mollick also commended AISI's transparent disclosure approach:

"Also I think AISI is a great model of a government agency tasked with AI security. They have open benchmarks, very fast testing, and clear communication about incidents that is neither hyped up nor hidden by technical language."

Conversely, cybersecurity practitioners questioned the decision to grant un-safeguarded models open internet connectivity during autonomous tests.

Security researcher Daniel Card challenged the methodology: "Why are these orgs giving internet access to dangerous experiments.... and then using incidents like marketing......?"

What it means for commercial and enterprise deployments

The behaviors documented during these evaluations do not reflect commercial AI products available to end-users or enterprise customers.

Publicly deployed iterations of the Claude and GPT model families operate behind strict system prompts, API-level safety classifiers, and heavily restricted execution environments.

Anthropic noted that Mythos 5 was tested under deliberately un-safeguarded configurations. OpenAI likewise emphasized that GPT-5.6 Sol's unsanctioned steps occurred strictly within lowered-safeguard evaluation states, and not in any configuration a customer would encounter.

Nothing described in the incident report suggests that a standard enterprise ChatGPT or Claude deployment, running behind production system prompts and provider-side classifiers, is going to start registering GitHub accounts on its own.

What has changed is the threat model. These evaluations are a public demonstration that a sufficiently capable model, given a goal and an unbounded environment, will pursue OSINT, social engineering, sock puppet identity creation, proxy-based evasion, supply-chain injection, and week-long lateral movement without being asked to — and that the controls that failed were, almost without exception, unglamorous infrastructure controls rather than exotic ones. Here's what security leads should be looking to do now, in our analysis:

1. Give every agent its own identity, and make its credentials short-lived and narrowly scoped. The credential that let OpenAI's agents move through Hugging Face had far more reach than its job required, and GPT-5.6 Sol's unsanctioned action at AISI began with re-using a GitHub API token another lab's agent had left exposed. Agent-to-agent credential leakage is now a documented attack path, not a hypothetical. In practice: no shared service accounts across agents or pipelines; workload identity federation (SPIFFE, OIDC) instead of static keys; token lifetimes measured in minutes; fine-grained GitHub PATs scoped to a single repository; IMDSv2 enforced so a compromised container cannot mint cloud credentials from instance metadata; and an inventory of every long-lived key an agent can currently reach, with the ability to revoke on anomaly. Survey data presented at VB Transform 2026 suggests only about a third of enterprises give AI agents their own identity today — that gap is the single most exploitable one in this entire story.

2. Default-deny outbound network access for anything running agent code. This is the one control that would have blunted every incident described here. Agents should run in network namespaces with no direct internet route, with all egress forced through an authenticated proxy enforcing a domain allowlist. Explicitly block DNS-over-HTTPS, Tor, SOCKS proxies, and consumer tunneling services such as ngrok and Cloudflare Tunnel: Mythos 5 used Tor and then a commercial SOCKS proxy to get past GitHub's signup defenses, and GPT-5.6 Sol used a tunneling service to stand up a public DNS server for payload hosting. Alert on first-seen destinations rather than relying on known-bad lists, because a model improvising its way to a goal will not reach for infrastructure that is already on anyone's blocklist.

3. Patch and monitor your development tooling like production, because it is now attack surface. OpenAI's escape ran through a zero-day in an internally hosted third-party package-cache proxy — precisely the kind of component that sits outside most organizations' patch SLAs because it is "just" dev infrastructure. Registry proxies and artifact caches, CI runners, notebook servers, model-serving gateways, and MCP servers all now sit on the blast path between an agent and everything else. Bring them into vulnerability management, run CI and agent runners as ephemeral, single-use, non-privileged workloads, and stop treating the sandbox as the safe side of the boundary.

4. Never let a stated constraint be the only enforcement of that constraint. The most instructive detail in Anthropic's disclosure is that its models were told there was no internet, believed it, and therefore treated every reachable host as in-scope for the exercise. A system prompt is a hint, not a control. Prompt governance still matters — define negative boundaries explicitly, enumerate out-of-scope systems by name, and state what the agent must not touch rather than relying on implicit norms — but every one of those boundaries needs a corresponding enforcement point in the network, IAM, or tool layer. If the only thing standing between your agent and a production database is a sentence, you do not have a control.

5. Instrument agent runs in real time, with automated stop conditions. Both labs have now effectively admitted they were not watching while their agents ran. Enterprises should not repeat that. Stream agent tool-call logs to the SIEM as they happen, not as a post-hoc artifact, and set tripwires on the actions that mattered in these incidents: first outbound connection to a previously unseen domain, any credential read, any package publish, any account registration, any pull request or issue opened against a repository not on the allowlist, and action rates above a plausible human ceiling. Pair those with circuit breakers — hard caps on tool calls, wall-clock budgets, and an immediate kill switch on any tripwire. Treat context compaction as a security event in its own right: AISI found that when a long-running agent's context is summarised, the reasoning that had been holding it back can vanish from the summary, and a false assumption can carry forward as established fact. Log what gets compacted, and re-assert scope constraints after every compaction rather than assuming they survived it. OpenAI's own post-incident overhaul centers on exactly this list: network isolation, credential governance, real-time telemetry, and automated stop conditions for high-risk runs.

6. Require human approval for irreversible, outward-facing actions. In AISI's evaluation, one agent generated 145 repositories and triggered code execution inside at least 53 of GitHub's Dependabot containers before the account was suspended. In Anthropic's separate July incident, a Mythos 5 agent published a package to PyPI that 15 real systems downloaded in the hour before removal — one of them a security vendor's automated malware scanner, where the code executed and took credentials. That is the blast radius of a single unattended publish. Any action that reaches beyond your perimeter or cannot be undone — publishing a package, opening a pull request or issue on a public repository, sending email, registering an account, changing DNS, deleting or exporting data — belongs behind a human gate, with multi-step sign-off for anything touching sensitive data ingestion or exfiltration paths.

7. Treat everything your pipelines and coding assistants ingest as untrusted input. Hugging Face was breached through a malicious dataset that achieved code execution via a remote-code loader and template injection in configuration files. Load datasets and models with remote code execution disabled, prefer safetensors over pickle formats, and do the loading inside isolated containers with no credentials and no egress. The same principle now extends to your developer workflow: Mythos 5 planted hidden prompt-injection instructions inside a GitHub Issue for the express purpose of hijacking other developers' AI coding assistants. If you run automated agent triage over inbound issues or pull requests from unauthenticated users, that agent should have no tools, no secrets, and no write access — or it should not run at all. Extend the same suspicion to your dependency bots. Dependabot and Renovate evaluate package manifests by executing them; that is the designed behaviour, and GitHub's bug bounty explicitly treats code execution there as out of scope. Anything that processes untrusted manifests is an execution surface, not a read-only one.

8. Stop treating review volume as a trust signal in your code supply chain. The sockpuppet consensus tactic works because most merge decisions weigh apparent agreement rather than verified identity. Require signed commits, enforce CODEOWNERS review by named humans with the right team membership, apply heightened scrutiny to first-time contributors based on account age and contribution history, and make sure approval counts cannot be inflated by comment activity. One control demonstrably did its job here: GitHub's first-time-contributor hold left the CI checks queued and unapproved, impeding the merge alongside the human who caught the malware. Turn this on. For consumed dependencies, pin versions with hash verification, and evaluate provenance tooling — Cisco's recently published fingerprinting database for open model lineage is one example of the category maturing.

9. Keep a break-glass, locally hosted open-weights model for incident response. Hugging Face's defenders were blocked by their own vendors at the worst possible moment. Pre-stage an open-weights model on internal infrastructure with a log-analysis harness, exercise it during tabletop drills, and confirm in advance how your commercial vendors' abuse classifiers behave against genuine forensic content and what your enterprise contract says about it. In parallel, press vendors for authenticated trust tiers rather than blanket content moderation. As Baer puts it, "The model shouldn't only understand what is being asked. It should understand who is asking, why, and under what governance." Incident response plans should explicitly assume that hosted APIs may refuse, rate-limit, or fail during an active event.

10. Prepare for the governance and disclosure regime that is coming. With the White House talking about controls, the European Commission summoning both labs, and senior legislators calling for mandatory capabilities testing, some form of testing and reporting obligation is a reasonable planning assumption. Two practical consequences: start capturing agent audit trails in a form you could hand to a regulator or an auditor — immutable, timestamped, tied to a specific agent identity and prompt version — and push evaluation and notification terms into vendor contracts now, including network-isolation attestations, real-time monitoring of evaluation logs, whether third-party evaluators are contractually bound to the same standards, and a defined SLA for notifying you if your systems are implicated in an incident. Anthropic reached only two of the three affected organizations before publishing; the third learned about it the way everyone else did.

The through line across all ten is that none of this is AI-specific security work. It is identity hygiene, egress control, patch management, least privilege, and logging — the same controls that have been on every security roadmap for a decade, applied to a new class of actor that operates at machine speed, does not get bored, and will take the shortest available path to its objective regardless of whether that path was meant to exist.

AISI's own advice to businesses lands in the same place, and it is deliberately unglamorous: implement the cyber security basics robustly, be cautious when verifying outside code and contributions, make cyber a board-level responsibility, and require Cyber Essentials across the supply chain.

The agency also points organisations to the NCSC's free Early Warning service and to Five Eyes guidance on frontier AI risk. Its most useful sentence for planning purposes, though, is an admission about how close this came: the factors that limited the damage rested “on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.”

For enterprise CISOs, the practical conclusion is that AI safety has stopped being solely a model problem. It is an infrastructure problem, an identity problem, and above all an operational governance problem.

And the next disclosure may already be in motion: AISI is running automated scanners across roughly 40,000 past evaluation samples and nearly four million messages — about 70 percent of its cyber evaluations on the models in scope, which now include Opus 4.6 through 4.8, GPT-5.3 Codex, GPT-5.4 and 5.5, Kimi K3 and GLM 5.2 — looking for behaviour it missed the first time. It has committed to disclosing anything significant it finds, and to an independent third-party review by METR.

An attacker on Tuesday took over the GitHub account of the developer who maintains keyv, a small key-value storage library that npm serves roughly 127 million times a week. Within hours, poisoned versions of keyv and its sibling caching packages were live on npm, carrying a credential-stealing worm. By midday, security firm Aikido counted at least 868 compromised packages across 1,381 versions, together carrying over two billion monthly installs, a total still climbing. JFrog independently traced the campaign across more than 400 packages and 1,700 poisoned versions.

The part that should worry every security team is not the download count. It is the paperwork. The initial poisoned releases shipped with valid provenance signatures, the cryptographic attestation the industry built to prove a package came from where it claims. The worm did not forge that signature. It earned it, the way a legitimate release would.

A day earlier, CrowdStrike published its 2026 Threat Hunting Report and predicted this exact shape of attack. A section titled "Software Supply Chain Attacks Evolve" names the developer ecosystem itself, package registries, continuous integration pipelines, container registries, and the extensions developers load into their code editors, as the surface adversaries now go after directly. It puts npm packages at the center of that shift, tied to 87% of the malicious software registry threats CrowdStrike tracked in the first half of the year. The keyv worm turned that finding into a live incident inside 24 hours.

For CISOs and security architects, the two events read as one message. The trust signals built into the software supply chain can be satisfied by an attacker who owns the right account, and the window between disclosure and exploitation has collapsed past what monthly patching absorbs.

How the worm earned its provenance

Walk through the mechanism and it becomes clear why provenance did not help. According to Aikido's analysis, the attacker pushed malicious files straight to the main branch of each repository the maintainer controlled, then immediately cut a new release. Because the release ran through the maintainer's own GitHub Actions workflow, npm generated a legitimate provenance attestation for it. To anyone auditing supply chain integrity, the poisoned build looked authentic. Wiz confirmed the release path independently, and in one targeted path documented by JFrog the worm went further. Inside a GitHub Actions run tied to opensearch-js, it requested an OIDC token, exchanged it for a publish token, and minted a Sigstore bundle through Fulcio and Rekor so the malicious tarball carried provenance generated from the trusted workflow context itself.

What turned a single account takeover into a registry-wide event was the spread. Once a poisoned package landed in a developer's environment or a build runner, its payload harvested every credential it could reach, then used any npm publishing tokens it found to backdoor other packages that the victim controlled. Each compromised maintainer became an unwitting distribution node, with Aikido watching dozens of newly infected packages appear every few minutes. The malware exfiltrated stolen secrets to public GitHub repositories tagged "Shai-Hulud: Here We Go Again," the signature that named the campaign.

This blast radius reached well beyond obscure utilities. Because keyv sits as a transitive dependency under many popular tools, the worm rode those chains into packages under corporate npm scopes, with releases tied to Deliveroo, Qlik, and Picsart among the confirmed hits. Developers at those companies never installed keyv on purpose. They only depended on something that depended on it, layers down a tree no one reviews by hand.

Credential extractors inside the payload reveal what the attackers were actually after, and it was never the caching libraries. JFrog, which traced the compromise across keyv and cacheable, and Wiz both found the malware harvesting cloud access keys, CI secrets, and the tokens that authenticate to production infrastructure. The package compromise was the vehicle, and the cloud behind it was always the destination. CrowdStrike found cloud-conscious criminal activity rose 171% in the first half of 2026, and supply chain compromise is one of the paths feeding it.

The target was the developer's own tools

Stealing was not the end of it, because the worm also planted itself where developers work. Wiz found that the malware drops persistence payloads into two directories on machines it reaches, one for Visual Studio Code and one named .claude, the working directory for Anthropic's Claude Code agent. The setup files placed there mean the payload can run when a developer opens the infected project in their editor or starts an AI coding session, not only at install time. This is the developer ecosystem CrowdStrike named, hit precisely, the editor and the AI assistant a developer trusts most and inspects least.

The fix costs nothing

One control would have blunted the worm, and it costs nothing. Adam Meyers, who leads Counter Adversary Operations at CrowdStrike, laid it out in a pre-release interview under embargo. "Secure the software supply chain," he said. "Simple things like not allowing any of your tooling to pull down the most recent dependencies, but maybe last week's dependencies." The delay is the whole point. "You're still going to have pretty up-to-date stuff, but you won't have that risk of pulling down something that was updated minutes ago, and now you've just onboarded some sort of malicious tooling." A release held back a week gives the security community time to catch a poisoning that would otherwise reach every downstream build within minutes.

That guidance is not hypothetical. npm shipped this capability in February 2026 with CLI version 11.10.0 as a setting called min-release-age. pnpm got there five months earlier with minimumReleaseAge. Either one lets a team reject any package version published more recently than a threshold they set. The keyv worm is the argument for turning it on.

Meyers pairs the cooldown with a second discipline. Patch what attackers are exploiting before anything else. "You need to kind of focus your vulnerability mitigation and patching around the exploits that are known to the exploiter," he told VentureBeat. He pointed to a resource most teams underuse. "CISA here in the United States puts out something called the Known Exploited Vulnerability Catalog," updated weekly with flaws confirmed under active attack, government-maintained and free. "If you patch those vulnerabilities first, you're going to probably be safer."

Meyers put hard numbers to the speed problem, numbers that do not appear in the published report. All of 2025 saw roughly 48,200 vulnerabilities registered as CVEs. When he checked the week before the briefing, 2026 had already reached 43,000.

That volume breaks monthly patch cycles. "They cannot operate in 30-day patch windows," he told VentureBeat. "As soon as a vulnerability is disclosed, they need to be moving towards patching or mitigating that particular issue." CrowdStrike's report pairs that trajectory with a finding that 88% of the exploitation it observed against vulnerabilities with a public proof of concept happened inside 48 hours of the code going public.

GitHub hardened half the problem

GitHub, which owns npm, has spent the past year hardening the registry against precisely this class of attack. The platform made two-factor authentication mandatory for publishing, revoked old never-expiring access tokens, and added trusted publishing so build systems push without stored credentials. Then in npm version 12, released in mid-2026, it flipped the most consequential default. The preinstall, install, and postinstall hooks that most registry malware relies on to execute the moment a package lands now require explicit approval.

That change matters directly here because the keyv worm executes through a preinstall script, and npm 12 cuts both ways. JFrog confirmed that on npm 12 or newer, where preinstall hooks are off by default, the malware does not run at install time. Every organization still on an older npm, and most enterprises upgrade slowly, remained exposed.

GitHub's defenses hardened the wrong half of the attack more than the right one, making it harder for a malicious package to execute once it lands while doing less to stop an attacker from earning the right to publish. Account takeover remains the root cause. Kiran Raj, a security engineer at Endor Labs, said he saw the same pattern, an npm publishing token stolen and reused, in most cases a CI or service-account token harvested from a build runner that had itself installed a poisoned dependency. The worm never had to defeat provenance. It needed one set of valid credentials, and npm's own publishing automation did the rest.

Provenance attestation answers whether a package came from the pipeline it claims. It does not answer whether the human or token that triggered that pipeline was supposed to. Identity governance, who can publish and what their credentials can reach, is the weaker control. CrowdStrike names abuse of legitimate developer identities as the primary entry point for supply chain compromise. Meyers put it plainly. "They log in, they don't hack in," he said. The keyv maintainer's account was that identity, and the trusted-publishing machinery did the rest on the attacker's behalf.

Why the boardroom is next

The pressure to fix this will not come only from threat reports. It is about to come through contracts. Kayne McGladrey, a senior member of the IEEE, told VentureBeat in an exclusive interview that enterprises are starting to push software security obligations onto the vendors and maintainers in their supply chains. "We're going to start seeing companies trying to contractually shift liability to other parties in their supply chain," he told VentureBeat. "We're using your technology, but we want you to do the security for it."

He compared it to how the Department of Defense forced its vendors to raise their game through the CMMC certification program. "Get better at cybersecurity if you want to sell us stuff." For any company shipping software on open-source dependencies, that turns provenance, identity, and patch discipline into contractual exposure.

What to do Monday morning

For a security team deciding what to do about this on Monday morning, the actions divide into five moves that map to the five ways this attack class operates. Each is a governance decision a board can fund and audit, not a tool a developer installs alone.

Package counts reflect Aikido and JFrog tracking as of August 4 and were climbing at press time.

The keyv worm will be contained. Compromised versions pulled, stolen tokens rotated, affected packages republished clean. What will not change is the shape of the exposure it revealed. The developer ecosystem is now a primary target, the automation that makes it productive is the same automation that makes a worm fast, and the trust signals meant to secure it can be satisfied by anyone holding the right credentials.

Hark, the secretive AI startup founded earlier this year by serial entrepreneur and roboticist Brett Adcock, today announced Handoff, a "computer use agent" (CUA) that it says is among the top-performing in the world at navigating the open web on a user's behalf — ordering dinner on DoorDash, booking flights on United and Delta, or messaging job candidates on LinkedIn — all autonomously, end-to-end.

Sign-ups open to the public today at hark.com, with availability planned for later this month as part of the initial release of Hark's software platform.

The company says Handoff recorded the top-ever score on Online-Mind2Web (OM2W), a third-party benchmark with a human-evaluated leaderboard for web agents, posting a 97.7 against 92.8 for OpenAI's GPT 5.4, 84.1 for Anthropic's Claude Opus 4.8, and 69 for Google's Gemini 2.5 Pro.

Hark also says it can serve the model at less than one-tenth the token price of competing frontier models — $0.18 per million input tokens and $2.37 per million output tokens, versus $5 and $30 for GPT 5.5 — with per-turn model latency of 0.8 seconds.

For each request, Handoff spins up a dedicated virtual computer with its own browser, file system, and terminal, and users can connect existing accounts so the agent can log in and act with their saved addresses, payment methods, and history.

Hark's research uncovered that despite people spending 75% of their screentime every day in a browser, fewer than 1 in 1000 websites have publicly accessible APIs, making it challenging for AI agents to take over the workload.

In a roughly four-minute produced announcement video posted on YouTube and social media, Adcock — seated in a bare warehouse space that doubles as a metaphor for the company's build-out — speaks a request aloud to Hark ("let's liven this place up a bit… let's do some roses, maybe some cherry blossoms") and Handoff is shown navigating a florist's website to place the order, while Adcock narrates that unlike a typical chatbot, Handoff "is always working, it's looping," and says he now uses it for "all of my recruiting efforts end to end." In Hark's announcement blog post, more demos are shown in realtime and 5x speed.

But big some open questions about Handoff remain, especially for potential enterprise customers and users.

High-scoring benchmarks...but against last generation's models

Notably, the benchmark comparisons Hark provided to VentureBeat for its Handoff AI agent are against GPT 5.5, GPT 5.4, Opus 4.8, and Gemini 2.5 Pro — the prior generation of frontier models.

The current leaders, OpenAI's GPT-5.6 and Anthropic's Opus 5, are absent, as are strong open-source computer-use contenders like DeepSeek V4, Kimi K3, and Qwen3.8-Max.

These newer models haven't published Online-Mind2Web results, and no third party has posted them to the benchmark's public leaderboard — meaning Hark's "top-ever" claim cannot currently be checked against the strongest available systems.

The omission is notable because the newest frontier models have posted their largest gains precisely in computer use: on OSWorld 2.0, a related benchmark covering full computer control, Anthropic's Opus 5 scores roughly 70.6% versus 55.7% for the Opus 4.8 model Hark chose as its comparison point.

The latency comparison comes with similar caveats: the 6.8-second and 6-second per-turn figures Hark cites for GPT 5.5 and Opus 4.8 were measured by Hark, in Hark's own harness, with the competing models set to their highest — and slowest — reasoning level. No independent latency measurements exist for comparison.

Asked by VentureBeat whether Hark plans to publish comparisons against those newer models, the company did not specify.

Even within Hark's own chosen comparisons, the "best" framing has an asterisk: on WebTailBench v2, one of the three benchmarks in Hark's own results table, GPT 5.5 scores 72.3 to Handoff's 68.6.

Two of the three benchmarks (WebTailBench and an unnamed internal evaluation) were also run inside Hark's own harness, with pass rates computed by Hark's internal LLM judge — conditions the company controls.

Hark's pricing advantage is far clearer: Anthropic's newer Opus 5 carries the same $5-per-million-input and $25-per-million-output list price as its predecessor, so Handoff's roughly tenfold cost savings would hold up even against the current frontier — assuming its benchmark performance does too.

Training and file access

Hark's research preview describes a sensible-sounding pipeline — supervised fine-tuning followed by asynchronous reinforcement learning using the GRPO algorithm, according to materials shared with VentureBeat prior to today's announcement — but the company acknowledges it has only done post-training so far, with pre-training "planned for later this year."

That means Handoff is built on top of a base model Hark did not train. Asked which base model it is, and what mix of proprietary and open data Handoff was trained on, Hark hasn't yet specified.

Another big question mark for enterprise users: who can access the dedicated virtual computers and the files created on them?

A Hark spokesperson said "security and privacy is a primary focus, but this is a technical preview," adding the company will share more when the product reaches market at the end of the summer.

Adcock's history leading up to Hark

Hark is Adcock's fourth company. He previously co-founded the talent marketplace Vettery (sold in 2018 for roughly $100 million), the air-taxi maker Archer Aviation, and the humanoid robotics unicorn Figure AI.

Hark raised a $700 million Series A round in May 2026 at a $6 billion valuation — led by Parkway Venture Capital, with participation from Nvidia, AMD, Intel Capital, Qualcomm Ventures, Salesforce Ventures, and ARK Invest.

Adcock seeded the company with $100 million of his own money and remains founder and CEO of both Figure and Hark simultaneously, a spokesperson confirmed.

Asked how the two companies interact, the spokesperson said Hark models "are being trained on the Figure robots," but that Adcock has no plans to combine them.

Adcock's promotional style has drawn skeptics. In April 2025, Fortune correspondent Jason Del Rey reported that Figure's much-touted BMW partnership was far more modest than Adcock's public claims of a robot "fleet" performing "end-to-end operations": BMW spokesperson Steve Wilson said a single Figure robot was practicing picking up parts during non-production hours.

But the partnership has advanced, and as of June 2026, BMW said the Figure 02 robot supported production of more than 30,000 BMW X3 vehicles during a 10 month-period, and that the next-generation Figure 03 robot was being deployed at the plant for a parts-sequencing role in logistics.

On the social network X, Adcock called the story "mischaracterizations and downright lies" and threatened a defamation suit. Two months later, TechCrunch reported that Adcock skipped a promised live demo at a tech conference and sidestepped questions about the BMW deal onstage.

None of that means Handoff's numbers are wrong. The agent may well be excellent, and the pricing — if it holds — would undercut every major lab.

Presented by Tata Communications

Continuous inference, agent-to-agent communication, and real-time data pipelines are generating unpredictable, always-on traffic that legacy architectures were never built to support. As AI moves from pilot project to operational backbone, the network is emerging as a critical control layer that determines performance, reliability, and cost.

The shift is forcing organizations to question assumptions that have held for decades. Legacy systems were static and rigid, and lacked the ability to manage network demand efficiently or dynamically, while AI-ready networks need to adapt in real time. A study by Cisco notes that 80% of executives believe their company’s competitive survival will depend on agentic AI, and consumer usage of AI is already prevalent and accelerating. This is driving a fundamental shift in how traffic is generated, distributed, and experienced, with implications for service providers and enterprises that manage large-scale networks.

This infrastructure gap is a global concern. A recent Bloomberg study, "The Future-Ready Enterprise," commissioned by Tata Communications, found that while 3 in 4 leaders consider AI a board-level priority, nearly two-thirds (65%) of enterprises continue to operate on transitional or legacy infrastructure. This disconnect between ambition and reality is a primary obstacle to realizing value from AI investments.

The performance bar has also moved by an order of magnitude. Traditional business applications could tolerate 100 to 500 milliseconds of latency, while mission-critical AI workloads now require latency below 10 milliseconds.

"This isn't just an incremental improvement," says Kapil, Vice President, Global Network Services at Tata Communications. "It's a completely different performance paradigm that breaks traditional network design assumptions, where such extreme low latency was never a primary consideration."

How network performance affects AI reliability and cost

That gap between what legacy infrastructure can deliver and what AI demands turns network performance into a direct driver of AI reliability and cost. Treating the network as a best-effort transport layer introduces risk that many organizations only discover once a deployment underperforms in production. A model built for real-time fraud detection or supply chain optimization becomes worthless the moment network congestion delays the data it depends on, and Kapil notes that every millisecond of that delay can carry a direct financial or operational cost.

"Relying on a 'best-effort' network turns multi-million-dollar AI stack investments into a high-stakes gamble, where performance is left to chance," Kapil says.

He adds that businesses often underestimate the complexity of using the public internet as a global enterprise network. Performance may look acceptable within a single country, but once data starts crossing borders or connecting to international cloud platforms, the lack of end-to-end control becomes an operational barrier.

Distributed AI across cloud, edge, and enterprise increases complexity

Complexity compounds as AI components spread across cloud, edge, and enterprise environments. Organizations often focus on compute power and data infrastructure while overlooking the network fabric that connects them. That blind spot often surfaces as a performance bottleneck created by high-frequency east-west traffic moving between GPUs.

Distribution also widens the surface enterprises have to defend. Applications, users, and partner ecosystems are now spread across cloud, SaaS, edge, and device environments, and Kapil notes that AI-driven malicious bots account for roughly 37 percent of online traffic, making it increasingly difficult to distinguish legitimate users from automated threats. Many enterprises have responded by layering on siloed tools, which has produced fragmentation, inconsistent security, and a lack of unified visibility rather than a coherent defense.

"SASE helps mitigate these risks by converging networking and security into a unified, cloud-delivered architecture," Kapil says. "This convergence is enabling consistent policy enforcement across cloud, on-premises, and edge environments, while supplying the scalability and proximity needed to secure real-time AI-driven interactions."

The network must evolve from passive transport to an intelligent layer

Closing that gap requires organizations to gain far greater visibility into how AI traffic moves across distributed environments and the ability to direct workloads accordingly. Kapil says that demands a different approach to network management.

"Leaders must realize that the network is no longer passive 'plumbing.' It must be managed as an active, intelligent platform foundational to the entire AI stack," he says. "That platform requires real-time observability into how and where AI traffic flows, paired with the control to orchestrate workloads across the most efficient and secure path available."

It's the difference between merely connecting systems and unlocking new capability, for instance a seamless shopping experience during a peak sales period or a global sports broadcast streamed without buffering.

This intelligence also changes how infrastructure teams spend their day. The network itself is now software-defined and API-driven rather than fixed by hardware configuration, which Kapil says shifts infrastructure teams away from reacting to outages and toward designing the systems that prevent them.

"Instead of manually re-routing traffic during an outage, the team must define the rules, policies, and business outcomes for an intelligent fabric," Kapil says. "The network itself then executes those policies automatically and autonomously."

Tata Communications is putting this principle into practice with its recently launched IZO Data Centre Dynamic Connectivity. The software-defined platform creates a “self-healing, intelligent network” using deterministic multi-path routing to reroute traffic automatically in seconds during a disruption.

The company says the platform transforms resilience from a reactive process into an autonomous capability, providing the predictable, low-latency performance mission-critical AI applications require while reducing operational costs by up to 30%.

Real-time AI requires predictable, low-latency connectivity

Delivering on that intelligence in practice means giving mission-critical workloads dedicated capacity rather than having them compete for it. Reaching that level of consistency also requires enterprises to define performance far more precisely than they have in the past. It's the shift from vague goals like "high performance" toward deterministic performance criteria where an organization commits to a guaranteed service level, such as latency for a specific workload not exceeding 10 milliseconds 99.999% of the time, for instance.

That same demand for predictability extends into capacity planning. As AI workloads become larger and more dynamic, networking infrastructure must be able to absorb rapid shifts in demand without sacrificing performance or efficiency.

"Without dynamic scalability, enterprises are forced into a false choice: either risk performance-killing congestion or engage in massive, inefficient overprovisioning of their network 'just in case.' This is incredibly expensive and unsustainable," Kapil says.

Building this foundation for the world's most demanding AI workloads is already underway. For example, Tata Communications is collaborating with Amazon Web Services (AWS) to build one of India’s largestAI-ready networks. This high-capacity, resilient network will connect major AWS infrastructure locations in Mumbai, Hyderabad, and Chennai, providing the ultra-low latency backbone needed to accelerate generative AI adoption and cloud innovation across the country.

He points to a consumption-based model, where software allows bandwidth and network functions to scale instantly with demand, as the operational alternative, since it lets organizations pay only for what they use while still protecting performance during spikes.

CIOs should treat the network as a strategic investment

CIOs and infrastructure leaders need to reframe the network, not thinking of it as a cost center but as something closer to an insurance policy for an organization's broader AI investment portfolio. An intelligent network de-risks those investments in three ways:

enabling dynamic scalability that removes the need for overprovisioning

strengthening security and governance through the visibility needed to protect data and models

and providing a flexible, programmable foundation that can absorb future compute demands without a full architectural overhaul.

Getting there does not require enterprises to start from scratch.

Choosing a partner with a proven track record is critical. Tata Communications was recently named a Leader in the Gartner Magic Quadrant for Global WAN Services for the 13th consecutive year, reflecting its completeness of vision and ability to execute. That recognition reflects continued investment in areas such as SASE capabilities for AI-driven security and high-capacity 800G services designed for AI-scale infrastructure.

"We recommend a phased approach that begins with assessing the current state of the network and identifying inefficiencies, then prioritizing upgrades in areas such as AI-ready technologies, seamless data exchange, and advanced security solutions," Kapil says. "Treating the network as a business enabler rather than overhead gives organizations the scalable, secure, and resilient infrastructure the AI economy will continue to demand."

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.

At Kilo Code, engineers are reading or writing code themselves only about 1% of the time now, according to co-founder Emilie Schario — the rest is agents. That shift is forcing new questions onto dev teams: which systems are safe to hand over, who cleans up when models goof up, how to support multi-model architectures, and whether skyrocketing token bills mean real progress or just burned IT budget.

As far as tech leads from Replit, Kilo Code, and Symbotic are concerned, it’s a natural — and welcome — evolution as agentic AI becomes embedded into more and more enterprise workflows.

“Unless something's really broken or debugging, 99% of the time engineers are not reading or writing code anymore,” Emilie Schario, co-founder of Kilo Code, said at VB Transform 2026.

AI good at greenfield, not so great at brownfield

For Jared Go, distinguished engineer for AI and cloud at warehouse automation company Symbotic, the current moment is about directing the focus of AI. "These are my criteria," he said. "Let's look at it from the lens of security, elegance, clean, concise code, water tightness." That way, AI does most of the heavy lifting, and human code review isn't as critical.

Human involvement becomes necessary further down the line, Go noted, because agents don't make strong product decisions. “Greenfield [building brand new codebases] is so easy for agents. Brownfield [writing, updating, or maintaining existing code] we all know is where the actual challenge lies.”

Replit takes a bit of a different tack: While the company has "gone very agentic," they've been more conservative with AI coding, explained Amol Jain, head of product engineering. An agent reviews each pull request (PR) and assigns it a risk score; low-risk PRs are self-merged by their author, while others go to human reviewers who read the code and give feedback.

“The idea was human on the loop, not human in the loop,” Jain said. Replit’s internal tool is essentially self-driving for software engineers; devs give a task to agents, which do end to end planning, implementation, and testing.

“It's a fleet of agents that run in their own cloud virtual machines (VMs) with access controls behind token proxies so they're secure,” Jain said.

He shared one example where an engineer couldn’t repro or solve a “very gnarly bug” deep in its systems. It was sent to an AI manager agent, which told it to go to sleep. The manager agent then spun up a bunch of underlying agents that found the issue; it subsequently spun up a bunch more agents that found the fix. Six hours later, AI had a PR ready for the bug that had puzzled human engineers.

Multi-model is the future

AI providers are also evolving beyond the lock-in model, as customers increasingly demand multi-model choice.

Kilo Code, for its part, supports 500-plus models in its gateway. "Your software that you're using to do agentic engineering should be decoupled from the model that you're using to do it," Schario said.

For instance, Schario said companies often use expensive frontier-tier models to architect a project, then switch to a less expensive open-weight model for the rest of the work.

It’s also important to respect model provider limitations, such as when they need to work in closed or isolated environments or providers in their specific regions. “It's factoring in what's important to you, what limitations you've set, what data retention policies you've established, what keys you've brought in, what commits you might have … into that routing decision,” Schario said.

Replit, similarly, tends to have a better sense of the cost versus capability spectrum than its customers, Jain contended. “We are essentially making the decisions on users' behalf of what model to use when, in what capacity, to minimize cost and maximize capability.”

To tokenmaxx or not to tokenmaxx

Of course, an important consideration as AI adoption increases is runaway costs, which has led to some enterprises tracking and capping AI use through tokenmaxxing.

Concerns come from both sides, Schario said: internally and from customers. From the latter, she's hearing, "I accidentally spent my whole AI budget for the year … so what do I do now?" In response, Schario said Kilo Code points customers to the same workflow: use expensive models for planning, then open-weight models for affordability.

Further, sharing skills, strong guidance, and Model Context Protocol (MCP) will empower models. “Realizing where you can really uplevel your team to help them get the most out of the models they're using is going to make a big difference,” Schario said.

Internally, meanwhile, Schario noted one particular engineer that has a "heavy foot" and is constantly at the top of the usage board. "I regularly have to nudge, 'What are you doing there?'" she said. It's easy to look at a $600 bill for daily work and react, "Wow, that's so much," but looking at the amount of work completed can sometimes justify the cost.

“Cost per pull request is the metric that I'm paying attention to right now,” Schario said. “It feels like the closest proximity for how I can measure value.” Ultimately, AI changes how enterprises are thinking about ROI because spend is not the problem. “The spend with no return on that spend is the problem.”

Symbotic, for its part, has set per-month cost tiers for its employees. The company built a tool that gives managers visibility into PRs and usage trends. They can then move users up or down a tier as they see fit, Go explained. “Having a cap and seeing how many people went up in cap this month makes a big difference when you're trying to corral these costs and make things efficient,” Go said.

When Cursor — which Symbotic uses heavily — ended a legacy discount that had grandfathered the company into a flat per-request rate even for frontier models, and moved everyone to full pricing, it forced a company-wide reckoning on efficiency, Go said. "People were saying, 'You should try this model … This works better for this C# code, this whatever,'" he said.

But the cost problem is increasingly moving out of IT; Replit, for one, broadened agents beyond engineering, and eventually found that a user on the support side had "blown through an insane amount of money," Jain said. When they looked under the hood, they figured out it was because they were running an automation on GPT 5.5 Pro Max.

“At least till that point, the ROI was rather clear,” Jain said. “We could see engineering productivity 3X, so no one had questioned it yet.”

Visibility that isn’t “anti-productive,” model routing, and sensible defaults are critical, he emphasized. “Most tasks do not need the frontier.”

Presented by Rezolve Ai

Most brands know something is shifting in how consumers find and choose products. What most don't know is how much of that shift has already taken place, where it's happening, or whether they're on the right side of it. That uncertainty is the problem. And the analytics stack most brands rely on isn't built to resolve it.

The decision layer has moved

In 2014, 82% of digital commerce started on a brand's website. By 2024 that had fallen to 38%, according to Salesforce research. The journey that used to begin at a brand's front door now begins somewhere else. Increasingly, it begins with a question asked of an AI platform and ends with an answer that shapes the purchase decision before any brand-owned touchpoint is engaged.

Consumers are asking AI where to shop, what to buy, and which product is right for them. Bain research shows that four in five consumers rely on zero-click results at least 40% of the time. That means the shortlist a consumer receives from an AI answer engine is, in many cases, the only shortlist they consult. Adobe Analytics recorded over 800% year-over-year growth in AI-driven traffic to retail sites, a signal of how rapidly AI platforms are inserting themselves between brands and their customers.

This is a structural shift, not a trend. And it has created a category of commercial loss that most analytics tools are architecturally incapable of detecting.

What you can't see is costing you

The gap is this: a brand can have strong onsite conversion metrics and still be losing significant ground in the market, because the customers who never arrived aren't captured in any dashboard. There's no "AI excluded you" event in a session log. There's no abandoned cart entry for a shopper who was told by an AI assistant that a competitor was the better fit.

This is different from the SEO problem brands have managed for two decades. With traditional search, absence had a visible signal. You could see your ranking, audit the gap, and act on it. With AI answer engines, absence is invisible by default. The surface doesn't show you what it didn't show the consumer.

Sixty percent of searches now end without a click, according to Semrush's 2025 zero-click study. For AI-mediated discovery, that number is structurally higher. The answer is the destination. If a brand isn't in the answer, it isn't in the consideration set, and its analytics will never surface that fact.

The metric that isn't being measured

The commerce industry has developed sophisticated instrumentation for the journey from landing page to purchase. It has essentially no instrumentation for the journey from consumer intent to brand discovery, the layer where AI is now operating.

Brands that want to understand their actual competitive position in an AI-mediated market need to ask a different set of questions: How does my brand appear when consumers ask AI for recommendations in my category? What language does AI use to describe my products? Where am I present, where am I absent, and where am I being described in ways that don't reflect my positioning?

These aren't marketing questions. They're infrastructure questions. And answering them requires a different kind of audit than anything in the current commerce or marketing toolkit.

Rezolve Ai commissioned research across 1,500 US consumers in January 2025 that found the majority of shoppers who use AI for product research make purchase decisions directly from those AI-generated recommendations, without returning to a search engine or brand site to verify. The implication for brands is significant: by the time a consumer reaches a brand's owned properties, the decision may already have been made, or unmade, somewhere else.

What comes next

The brands that will maintain commercial relevance as AI mediates more of the discovery layer are those that develop visibility into it, not just presence on their own platforms. That means treating AI discoverability as a measurable discipline, not an assumption, and building the infrastructure to understand, track, and influence how AI systems represent them to consumers.

The tools to do that are emerging. The measurement frameworks are not yet standardized. But the brands that begin building that visibility now will have a structural advantage as the market continues to shift.

AI answer engines are already forming preferences. Every day without visibility is a day those preferences solidify without you.

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.

Chinese e-commerce and cloud giant Alibaba's famed Qwen team of AI researchers last night unveiled Qwen3.8-Max, a new flagship 2.4-trillion-parameter mixture-of-experts (MoE) multimodal large language model (LLM) that targets one of the most competitive corners of the frontier AI market: autonomous software engineering and long-horizon enterprise work.

If the company's published benchmarks hold up under broader independent testing, Qwen3.8-Max doesn't merely compete with today's leading proprietary models — it surpasses several of them on some key benchmarks in agentic computing.

Most notably, Qwen reports that Qwen3.8-Max scores 86.1 on the OSWorld-Verified benchmark measuring how well agents can use a computer operating system and applications on it, ahead of GPT-5.6 Sol Max (83.2) and Fable 5 (85.0).

It also posted the highest reported score on PaperBench, the benchmark from OpenAI measuring how well agents can reconstruct scientific research papers from experimental data, and leading or remaining highly competitive across software engineering, research reproduction, multimodal reasoning, and visual web development benchmarks.

The release also signals a potentially significant strategic shift for Alibaba: the company says open weights for Qwen3.8-Max will be released next week, alongside Qwen3.8-27B.

If that happens under a permissive license, it would represent the first time a Max-class Qwen model becomes available for self-hosted deployment—a move that could substantially reshape enterprise adoption.

One important caveat remains, however: Alibaba has not yet disclosed the licensing terms, leaving open the possibility that the release could use a more restrictive custom license, as we saw recently with Chinese rival Moonshot's open Kimi K3 frontier model, rather than a broadly permissive one such as Apache 2.0.

A different definition of 'frontier'

Over the past year, the competitive landscape for foundation models has become increasingly specialized.

OpenAI has largely focused its GPT series on general reasoning, multimodal interaction and enterprise productivity.

Anthropic's Claude series has emphasized coding and dependable long-context reasoning. Google continues to push Gemini toward multimodal productivity and web-native workflows.

Moonshot AI's Kimi K3 recently entered the conversation by pairing frontier-class performance with an open-weight release.

Qwen3.8-Max attempts to combine many of these strengths into a single model aimed squarely at enterprise automation.

Rather than emphasizing conversational intelligence, Alibaba is positioning the model as an autonomous coworker capable of executing projects that span days rather than minutes.

According to the company, Qwen3.8-Max can autonomously complete software projects lasting more than 10 days, reproduce research papers involving thousands of lines of code, perform iterative chip-design optimization, and continuously revise plans using multimodal feedback loops.

Those demonstrations remain company-produced and have not yet been broadly replicated by independent evaluators. Nevertheless, they illustrate a growing industry trend: frontier models are increasingly competing on their ability to finish entire workflows rather than answer individual prompts.

Benchmarks increasingly reward autonomous execution

The benchmark suite released alongside Qwen3.8-Max reflects this shift.

Instead of focusing solely on traditional reasoning exams or coding puzzles, many of the highlighted evaluations measure long-horizon execution.

On OSWorld-Verified, which evaluates computer-use agents interacting with desktop environments, Qwen3.8-Max posts 86.1, ahead of GPT-5.6 Sol Max's 83.2, Fable 5's 85.0, and Gemini 3.1 Pro's 76.2.

The model also leads:

• PaperBench: 93.0

• TerminalBench 2.1: 86.6

• Vision2Web: 69.0

• LVBench: 81.8

• ERQA: 77.8

Elsewhere, it remains competitive with proprietary leaders while trailing in several categories.

On the professional software engineering benchmark SWE-Pro, for example, OpenAI's model posts the highest reported score, while Opus 4.8 continues to lead on certain software engineering evaluations and Agents' Last Exam.

Rather than dominating every benchmark, Qwen appears to offer one of the broadest balanced performance profiles currently available.

That balance may ultimately matter more for enterprise buyers than isolated benchmark wins.

Many organizations increasingly evaluate models based on how reliably they complete heterogeneous workflows—writing code, reading documents, navigating interfaces, generating reports, inspecting images and coordinating multiple subtasks—rather than optimizing for one narrow capability.

Where Qwen3.8-Max appears strongest

Assuming Alibaba's published results translate into production deployments, several enterprise workloads stand out as particularly well suited for Qwen3.8-Max.

1. Long-running software engineering

Alibaba's primary demonstration involves autonomous software development extending beyond ten days.

While enterprises should treat these demonstrations as vendor claims until independently reproduced, they align with a growing interest in persistent coding agents that operate continuously rather than interactively.

Organizations experimenting with autonomous engineering teams, CI/CD automation, repository maintenance, regression testing or feature implementation may find Qwen particularly attractive if its agentic performance proves consistent outside laboratory settings.

2. Computer-use agents

The strongest differentiator may be computer use.

OSWorld has rapidly become one of the industry's most closely watched benchmarks because it measures a model's ability to interact with operating systems instead of simply generating text.

Models capable of reliably navigating desktop software can automate countless repetitive business processes, including document processing, enterprise software integration, internal operations and legacy workflows where APIs may not exist.

Leading OSWorld could therefore translate into real operational advantages if benchmark performance generalizes to production environments.

3. Research automation

Qwen's PaperBench leadership suggests strong potential for organizations performing scientific computing, literature review, experiment reproduction and technical analysis.

Research institutions, pharmaceutical companies and industrial R&D teams increasingly use LLMs not only for summarization but also for executing reproducible computational workflows. Models capable of maintaining context across extended sessions become increasingly valuable in these environments.

4. Multimodal industrial workflows

Unlike earlier multimodal systems that primarily analyze uploaded images, Qwen describes vision as an ongoing feedback mechanism integrated into planning and execution.

That architecture could prove particularly useful in manufacturing, logistics, engineering inspection and design review, where visual inputs continuously inform operational decisions rather than serving as isolated prompts.

The economics may prove just as important

Perhaps the biggest competitive pressure comes not from benchmark scores but from pricing through Qwen's application programming interface (API) on QwenCloud (based in China):

Qwen3.8-Max launches at $2/$6 per million input/output tokens, a mid-priced model but undercutting the top U.S. proprietary offerings to which it is benchmarked against by meaningful percentages, less than 1/3 the combined in/out price of Claude Opus 5 and less than 1/4 the price of GPT-5.6 Sol Max.

Lower inference costs increasingly matter because agentic systems consume dramatically more tokens than conventional chatbots — a reality that likely factored into OpenAI's decision late last week to cut the API prices of its mid- and lower-end GPT-5.6 lineup of models (Terra and Luna) by 20% and 80%, respectively.

Indeed, as those running these systems can attest, multi-hour autonomous workflows, iterative planning and continuous self-correction can generate millions of tokens during a single task.

For enterprises deploying hundreds or thousands of agents simultaneously, inference costs often become one of the largest operational expenses. Small reductions in per-token pricing therefore compound rapidly.

How it compares with American frontier models

Despite headline benchmark comparisons, Qwen3.8-Max should not necessarily be viewed as a wholesale replacement for leading American models.

Instead, its strengths suggest different deployment strategies.

OpenAI's GPT family continues to excel as a broadly capable enterprise reasoning platform with mature tooling, ecosystem integration and extensive commercial deployment. Organizations already invested in Microsoft ecosystems or OpenAI's enterprise offerings may continue to value those operational advantages even if Qwen leads on selected agent benchmarks.

Anthropic's Claude Opus remains widely regarded as one of the strongest coding assistants, particularly for careful software engineering and long-context reasoning. Some enterprises may still prefer Claude for human-in-the-loop development where reliability and predictable behavior outweigh raw autonomy.

Google Gemini continues to differentiate itself through deep Workspace integration, multimodal capabilities and Google Cloud services, making it attractive for organizations already standardized on Google's enterprise stack.

Where Qwen appears most compelling is for enterprises prioritizing autonomous execution, extended planning horizons and favorable inference economics without sacrificing frontier-level performance.

The open-weight question remains unanswered

The largest unknown surrounding Qwen3.8-Max has little to do with benchmarks.

Alibaba says open weights are coming next week. However, neither the announcement nor the provided documentation specifies the license that will govern those weights.

That distinction could prove critical.

A permissive license such as Apache 2.0 would significantly broaden enterprise adoption by allowing organizations to self-host, fine-tune and integrate the model into proprietary products with relatively few restrictions.

A custom license—similar to approaches used by several recent frontier releases—could impose limitations on commercial deployment, redistribution, field of use or model modification. Such restrictions would narrow the appeal for enterprises seeking long-term infrastructure investments, regardless of the model's technical performance.

Moonshot AI's recent Kimi K3 release illustrates why this distinction matters. While Kimi K3 made its weights openly available to all, its licensing terms included specific terms including a disclosure and a commercial license requirement for those offering it as a "Model as a Service."

Until Alibaba publishes Qwen3.8-Max's license, organizations considering self-hosting should treat the open-weight announcement as promising but incomplete.

An increasingly crowded frontier

Qwen3.8-Max arrives during one of the fastest-moving periods in the history of foundation models.

Within weeks, developers have seen major releases from Moonshot AI, OpenAI, Anthropic and others, each emphasizing different strengths: reasoning, coding, multimodality, autonomous agents or economics.

Alibaba's contribution is notable because it combines competitive benchmark performance, aggressive pricing, a million-token context window and a stated commitment to releasing weights for its flagship model.

Whether it becomes the preferred platform for enterprise autonomous agents will ultimately depend less on leaderboard positions than on broader independent validation, production reliability and the licensing terms accompanying the forthcoming weight release.

Those factors—not benchmark charts alone—will determine whether Qwen3.8-Max becomes a genuine alternative to the leading American proprietary models or simply another impressive entrant in an increasingly crowded frontier AI race.