Intuit was an early pioneer in the usage of agentic AI, but its path to success has hardly been a straight line. At VB Transform 2026 , Intuit VP of AI Nhung Ho described how the company rebuilt its agent architecture twice in the span of about four months, first moving from a fleet of specialist agents to a central orchestration layer, then abandoning that layer for a skills and tools based system once the orchestrator itself started failing under its own complexity. The full second rebuild took 60 days, with a first working version in under 20. The failure mode that forced the second rewrite was specific. Agents in the orchestrated system passed results to each other in natural language, and each handoff lost context the next agent needed to act correctly. "If you have 10 agents and they all are passing to each other, every time that pass happens, error compounds," Ho said. Why the orchestration layer broke down Ho said the original push toward specialist agents came from a straightforward customer complaint. A fleet of capable agents is still something a customer has to manage, deciding which agent to use for which task. Intuit's answer was a system that could take a task and route it internally, without asking the customer to pick an agent themselves. That orchestration layer held up for about three months, which Ho described only half joking as roughly a year in the compressed timeline of agent development in 2026. It broke for a structural reason rather than a capacity one. Passing outcomes between agents in natural language meant each downstream agent had to infer how the upstream agent reached its conclusion, and that inference degraded with each additional hop. A ten agent chain did not fail occasionally, it compounded errors by design. That diagnosis is what sent Intuit back to a skills and tools architecture. The 60-day rebuild, and what it took to get engineering buy-in Rebuilding a production agent system in 60 days required more than an architectural decision. Ho said the harder problem was internal, convincing both leadership and the engineers who had built the original agents that scrapping recent work was the right call. The pitch to leadership relied on evidence rather than argument. Ho's team built a demo of the new architecture using real customer queries pulled from production, then showed it performing better than the existing system on the same tasks. "The best proof, at least my belief, is what are customers trying to do? And whatever system you build needs to address those problems," Ho said. Winning over engineering required a different case. Hundreds of engineers outside Ho's core team had built the specialist agents being retired, and the ask was to take their agents apart into individual skills and tools instead. Ho said the motivating argument was scale. A standalone agent solved one narrow problem, while a shared skill or tool built into the new architecture could serve every customer who touched that part of the product. That shift also changed what partner teams were responsible for day to day, moving their focus from building agents to running evals, since evals became the only way to measure whether the new architecture was actually working. Bringing a human into the loop, and feedback at a different scale The clearest customer facing result of the rebuild is a feature that lets a live agent conversation pull in a human — though it's currently in early testing, live to about 1% of Intuit's customer base. "We're going to be scaling it up in the next few weeks," she said. Ho said a customer can bring in an Intuit product support person mid conversation, or their own accountant, or one of Intuit's own bookkeepers, and that person joins with the full context of what the agent has already done. Ho drew a direct contrast with how most AI chat products handle the same situation. A general purpose assistant answering a tax question typically ends with a disclaimer to consult a professional. Intuit's system is built to connect the customer to that professional directly, inside the same conversation. That human handoff sits alongside a permissions model built for financial data specifically. Every action an agent takes on a customer's financial data requires explicit permission first, though Ho said that requirement can ease over time as customers build trust in the system. Intuit keeps an audit log of everything an agent does that can be reversed if needed. Feedback in the agentic AI era The rebuild also changed how Intuit gathers and uses feedback, a shift Ho said is qualitatively different from what came before. "Feedback in the past used to be very, very sparse, and it was also very bimodal," Ho said. "Either they loved it or they hated it, and usually it tends towards the negative." In a chat based system, every conversation functions as feedback, which Ho said moved the company from roughly 0.3% of customers ever giving explicit feedback to something close to 100%. Ho said she has returned to writing code herself specifically to build models that analyze that feedback volume systematically, looking for where the system is falling short at a scale no manual review process could keep up with. That volume comes with a tone most product teams aren't used to hearing directly. Customers tell the agent exactly where it failed, in plain terms. "They straight up tell you, 'You suck. I hate this. This is not right,'" Ho said. "But they're also willing to give the systems grace and correct it as well, and so the onus is on all of us to harvest this new piece of feedback and type of feedback, and actually improve the system."
Legacy infrastructure, not the models themselves, is what's actually slowing AI agents down. That was the shared conclusion of three infrastructure leaders — from LinkedIn, Walmart, and Zendesk — at VB Transform 2026 . The panel brought together Animesh Singh, senior director of AI platform and infrastructure at LinkedIn, Desiree Gosby, SVP of corporate technology services and technology strategy at Walmart, and Sami Ghoche, VP of applied AI at Zendesk, each describing what actually broke when they moved agents from pilot to production. Each arrived at the same conclusion from a different starting point: None of the bottlenecks they hit were model problems. What tied their answers together was a shared premise: most enterprise infrastructure was built for how humans work, not for how agents work. The gap between those two speeds is where the real engineering happened. Gosby put it plainly when asked what she'd learned scaling agents inside Walmart's own workforce. The goal, she said, is to make sure "engineering doesn't once again become the bottleneck for what it is we're trying to do." Where the bottleneck actually was Each company hit a different version of the same wall: infrastructure designed for how people work doesn't hold up once agents are doing the work instead. At LinkedIn, the first bottleneck wasn't a model, it was Kubernetes, which assumes containers spin up on demand, a process that takes seconds. Singh said that's too slow for agents. The fix was moving from on-demand provisioning to pre-provisioned pools of containers that swap agentic workloads in and out in real time. A second, harder problem surfaced once LinkedIn let agents control their own orchestration. A five-point evaluation system looked clean, but hallucination kept showing up anyway. Singh said the issue was structural, an LLM evaluating another LLM's output shares the same failure mode as the thing it's evaluating. "We built our own harness, our own control flow, and pushed the LLMs to the leaf instead of them orchestrating the loop," Singh said. Roughly 80% of the workflow is now scripted, deterministic code, with LLMs used only where reasoning is required, and each step's evidence is committed to disk before the system moves on. Walmart's bottleneck came from success. An agent harness put directly into employees' hands went viral internally, and what Gosby called "citizen developers" began building their own agents to solve problems that once required a formal engineering roadmap. The upside was real innovation. The downside was duplication, dozens of overlapping agents with no coordination. The fix wasn't reining in the harness, it was building governance to spot duplication, promote the best version of an agent, and get it into production without engineering becoming a chokepoint. Zendesk hit its bottleneck from the data side. Ghoche, who joined through Zendesk's acquisition of Forethought , which closed in March 2026, described sitting on what he called a public figure of 20 billion customer conversations in Zendesk's repository. The instinct is to hand that history to a large language model with a big context window and let it generate the agents a business needs. Ghoche said that doesn't work. "You can't really do that, so instead you have to really invest in the underlying data pipelines and all the data infrastructure that comes with that," he said. The role of open source On open source, all three leaders landed on a similar instinct: own what you can, and lean on frontier labs only where they still have a clear edge. Ghoche said his own view is that most enterprises would prefer to own their models and infrastructure wherever that's possible, and that reasoning is what drives Zendesk's own approach. The exception is frontier reasoning work, where the labs still lead, though he said that slice of use cases is shrinking relative to everything else enterprises now do with AI. LinkedIn's answer was to build two subsystems specifically for independence. The first is what the company calls an AI gateway, a single interface that every outbound call to a model runs through regardless of provider. The second component is a memory subsystem built to hold context independent of any model provider. "Every single outbound call going to an LLM, whether it's on a public cloud or on-prem in our own data centers, follows the same semantics, the same API calls. We can quickly switch between different providers," Singh said. Walmart built its own internal gateway to stay vendor agnostic across three workload types: fully deterministic workflows, planner-and-reasoner workflows for open-ended tasks, and a hybrid of the two. Compliance-heavy work stays deterministic by design; governance, security and evaluation run through the gateway regardless of which model is on the other end. Gosby said the choice between a frontier model and an open-weight model comes down to whichever is most effective for the specific workload, not a fixed policy. Advice for the modernization journey Three pieces of advice came up directly, each tied to the wall a leader had already hit. Invest in evals before anything else. Ghoche called it the thing common to every use case, internal or customer facing. "The thing that's common to all of these is evals. It'll force you to break the problem down, and once you have a robust set of evals, you can move a lot faster," he said, Own your agent harness from day one. Gosby's advice was to put the AI harness directly in employees' hands early, paired with the infrastructure to monitor what it produces. "It will unlock a huge amount of innovation," she said. Build for model and context independence. Ensuring flexibility is critical for success. "Build for independence, whether it's a frontier model of today versus an open source model of tomorrow," Singh said. "Keep that context within your enterprise so that you can reuse it when you ship the model or the harness tomorrow," Singh said.
OpenClaw has become one of the most widely adopted agentic frameworks, but it has yet to prove itself at enterprise scale. Agents need real credentials — API keys, OAuth tokens, service accounts — to work effectively, and Brex found that traditional guardrails couldn't contain what those agents were doing with them. Brex set out to overcome these limitations by building an internal platform it calls CrabTrap. The open-source HTTP/HTTPS proxy intercepts all network traffic, examines policy rules, and uses a LLM-as-a-judge to decide whether agent requests should be approved or denied. “What we noticed was that the network layer was an untapped enforcement point,” Brex co-founder and CEO Pedro Franceschi told VentureBeat. “Every request an agent makes is an opportunity to intercept, reason about, and make a policy decision.” The takeaway Franceschi wants IT leaders to draw: agent governance should shift from SDK-level permissions and model guardrails toward a centralized network control plane that enforces and learns from real in-the-wild agent behavior. How Brex targeted the transport layer The “obvious fix” (at least initially) to the agent security gap was guardrails, and much of the early work has centered on scoped tools, per-action permissions, and human-in-the-loop approvals. But as agents evolve, each new capability means there’s another API to tune or surface to audit, Franceschi noted. “Any agentic system with multiple tools and access to the open internet creates an immediate tension for builders: The more capable you make an agent, the more dangerous it becomes, and the safer you make it, the less useful it is,” he said. Existing solutions to this tradeoff were “weak”: Fine-grained API tokens help at the margins but can still be misused and constrain functionality. Semantic guardrails (such as context, skills, or prompt steering) are easily bypassed by prompt injection, especially for agents connected to the internet. Agents can be “defanged” when given read-only access or limited toolsets, but then they can't do meaningful work, Franceschi said. On the other hand, granting broad write access and a large tool surface can result in hallucinations and real production consequences. Model context protocol (MCP) gateways enforce policy at the protocol layer — but only for traffic using MCP. Meanwhile, guardrails from LLM providers are tied to a single model and can be “opaque” to customize with enterprise-specific policies. And powerful tools like Nvidia OpenShell offer more of a “per-sandbox egress control.” “When we started, we hadn’t found a solution to deploying harnesses like OpenClaw safely,” Franceschi said. “Instead of waiting for the industry to catch up, we decided to own the problem and invent the necessary tools.” Notably, they needed a platform that sat between every agent and every network request, and could make “nuanced decisions about what to allow,” he said. This made the transport layer a core architectural component and natural starting point, he said. By operating at this layer, CrabTrap is framework-agnostic, language-agnostic, and API-agnostic. It doesn't require SDK wrappers or per-tool integration. Users set HTTP_PROXY and HTTPS_PROXY in the agent's environment, and every outbound request routes through the proxy before it reaches a destination. However, Franceschi emphasized, Brex didn't start at the transport layer because it thought it was the only answer; rather, they believe in “security by layers.” “The transport layer was simply an underinvested one, and we saw an opportunity to add meaningful enforcement there alongside everything else,” he said. The LLM-as-a-judge training loop CrabTrap combines deterministic static rules with an LLM-as-a-judge for requests that fall outside known patterns, Franceschi explained. The judge only “fires on the long tail of unfamiliar endpoints or unusual request shapes,” which for a mature agent is typically fewer than 3% of requests. The more pressing problem was how to know that a policy is the right one? With static rules, it's “relatively straightforward” to reason about accuracy. But with an LLM judge, the system is nondeterministic, and users need confidence that the policy approves the right requests and blocks the rest. “Our key insight was to bootstrap policy from observed behavior rather than write it from scratch,” Franceschi said. Beginning with real behavior and editing down based on real-world learnings turned out to be “dramatically more effective than starting from a blank page.” Brex’s team built a policy builder (itself an agentic loop) that runs underlying agents in shadow mode, analyzes historic network traffic, samples representative calls, and drafts a natural-language policy that matches what the agent actually does. From there, they built an eval system that tests policy changes before they go live. CrabTrap compares historical audit entries against a draft policy and reports the exact changes to be made. Users can slice results by method, URL, original decision, and agreement status. All of this runs with concurrent judge calls, so replaying thousands of requests “takes minutes, not hours,” Franceschi said. Brex also developed a live feedback loop: Full audit trails are stored in PostgreSQL and queryable through the admin API and dashboard. In cases where a resource is continuously denied, the system can notify a human or an agent to propose a policy update for review. “That closes the loop between observed denials and policy refinement,” Franceschi said. Core challenges and roadblocks Of course, the build wasn’t without its challenges. A big one was latency: “Putting an LLM between an agent and every outbound API request sounds like it would grind things to a halt,” he said. However, it didn’t turn out to be as big a problem as expected. This was for two reasons: The LLM judge only activates on a small fraction of requests (the aforementioned 3%). Agents quickly settle into predictable traffic patterns; once observed, high-volume patterns become static rules. Second, by using small, fast models like Claude Haiku meant that, even when the judge did fire, added latency was “negligible.” This can be further reduced with local models and prompt caching, Franceschi said. The harder and less obvious challenge was prompt injection, he said. The judge receives the full HTTP request and all content is user-controlled, so potentially, a crafted URL, header, or request body could manipulate the judge's decision. Brex addressed this by structuring the request as a JSON object before sending it to the model, so all user-controlled content is “escaped rather than interpolated as raw text,” Franceschi said. Results, and where CrabTrap might evolve Brex tracks a few factors to measure CrabTrap’s internal impact: Engagement with agents, network traffic patterns, and net promoter scores (NPS). The most meaningful result of CrabTrap has been “organizational confidence,” Franceschi said. Previously, the team had “real hesitation” when it came to deploying autonomous agents broadly across business operations, because the existing guardrail options didn't provide enough assurance. “CrabTrap changed that calculus,” Franceschi said. They now have an enforcement layer they trust, increasing confidence around expanding agent deployment into more parts of the business and delegating more agent configuration and management to users. Franceschi described the policies derived from traffic as “surprisingly strong.” The team expected the policy builder to produce a “rough starting point” requiring heavy manual editing. In practice, though, pointing the platform at a few days of real traffic produced policies that matched human judgment on the “vast majority of held-out requests.” Additionally, CrabTrap revealed how much noise agents generate. “The audit trail made this visible for the first time,” Franceschi said. They used denial logs and traffic analysis not only to tune policies, but to tighten agents themselves, remove tools, and cut out entire categories of requests that were wasting both time and tokens. “The proxy became a discovery tool, not just an enforcement one,” he said. Areas for growth (and input from the open-source community) Brex anticipates CrabTrap to continue to evolve, particularly as they have released it as open-source. “We hope the community helps shape it,” Franceschi said. Areas of improvement include deeper authentication functionality such as single-sign on (SSO), fine-grained role-based access control (RBAC); escalation workflows that allow agents to request additional permissions; and policy recommendations based on denial patterns. Programmatic configuration, or developing API endpoints for “creating, forking, and applying” policies to agents, could allow the whole policy lifecycle to be automated rather than managed manually, Franceschi said. As for escalation, if an agent is continuously denied a given resource or endpoint, it should be able to route requests to humans or other AI agents for review and back that up with a rationale for why it needs access. “That turns CrabTrap from a hard enforcement boundary into something more like a managed permission system,” Franceschi said. Additionally, the policy was built to bootstrap from network traffic, but there is opportunity to incorporate additional signals around agent traces and resource-calling, as well as broader context on what agents are ultimately trying to accomplish. This can help produce more accurate and nuanced policies. Finally, there's an “open philosophical question” about the right posture for CrabTrap: Should it be a fully transparent layer that the agent itself is unaware of, or should it operate more like a “well-intentioned manager”? (that is, the agent knows about the layer and can interact with it). The open-source community can help shape these developments, and CrabTrap will only get better with more users, Franceschi said. Brex’s agents speak to a specific set of APIs; teams using CrabTrap with different agents, services, and policy requirements will surface “edge cases and patterns we can't hit alone.” “We have ambitious plans for where it could go, and we’d rather build in the open,” Franceschi said. What other builders can learn from CrabTrap The response has been stronger than expected. CrabTrap has more than 700 stars on GitHub . Franceschi said Brex has also heard from OpenAI, Y Combinator CEO Garry Tan, and programmer Pete Steinberger, all expressing interest in deploying similar internal infrastructure. The broader lesson: “Don't let infrastructure gaps become excuses to wait," Franceschi advised. There are “real blockers” for every enterprise looking to seriously deploy AI agents, including security concerns, lack of tooling, or unclear guardrails. “It's tempting to sit on your hands until the industry catches up,” he said. “The lesson from CrabTrap is that you can own those problems directly.”
Moonshot AI, the Beijing-based artificial intelligence startup backed by Alibaba, on Thursday released Kimi K3 — a 2.8-trillion-parameter model that the company says is now the largest open-source AI model in the world, and one that benchmarks show performs neck-and-neck with the most powerful proprietary systems from Anthropic and OpenAI . The release, timed to land just ahead of the 2026 World Artificial Intelligence Conference in Shanghai, is a dramatic escalation in the global AI arms race and a watershed moment for the open-source AI movement. It also marks a remarkable comeback for a company whose market position had eroded significantly over the past 18 months following DeepSeek's meteoric rise. Full model weights are scheduled to be released on July 27, according to details shared by researchers who reviewed the company's technical documentation. If you want to take Kimi K3 for a spin right now, you can — just head to kimi.com , sign up with a Google account or phone number (no credit card required), and start chatting with what may be the most powerful open-source model ever built. Inside the architecture that powers the world's largest open-source AI model Kimi K3 is a frontier-class large language model with 2.8 trillion total parameters — roughly 75 percent larger than DeepSeek's V4 Pro , which the company's own timeline chart shows at approximately 1.6 trillion parameters. The model features a 1-million-token context window, native visual understanding capabilities, and an always-on reasoning mode that the company calls "thinking mode." The model is built on two key architectural innovations developed internally at Moonshot AI: Kimi Delta Attention , a hybrid linear attention mechanism, and Attention Residuals , which the company describes as a drop-in replacement for residual connections that delivers consistent scaling gains. Both techniques were previously published as open research by the Moonshot team on GitHub . On the API side , Kimi K3 is compatible with the OpenAI SDK , lowering the integration barrier for developers already building on OpenAI or Anthropic toolchains. The model is priced at $3 per million input tokens and $15 per million output tokens, with cached input tokens dropping to just $0.30 per million — pricing that positions it roughly in line with mid-tier offerings from Western labs, but at a performance level the company claims approaches the top of the market. A promotional top-up rebate running through August 12 offers up to 30 percent back in vouchers for API credits of $1,000 or more. As Xinhua reported , a Moonshot AI executive explained the significance of the parameter count in simple terms: parameters are like neural connections in the human brain, and nearly 3 trillion of them means the model can "store more knowledge and patterns in its brain, understand more, think deeper, and answer more accurately." Benchmark results show Kimi K3 trading blows with Claude and GPT at the top of the leaderboard The benchmark results, drawn from public leaderboard data and a private evaluation by analytics firm Artificial Analysis, tell a striking story. On GDPval-AA v2 , a benchmark measuring real-world tasks across 44 occupations and 9 major industries, Kimi K3 scored 1,687 — placing it third overall, behind only Claude Fable 5 Max (1,815) and GPT-5.6 Sol Max (1,747.8), and ahead of Claude Opus 4.8 (1,600). On AA-Briefcase , a private agentic benchmark from Artificial Analysis designed to test long-horizon knowledge work, K3 climbed to second place with a score of 1,527 — beating GPT-5.6 Sol Max (1,495) and trailing only Fable 5 Max (1,587). Perhaps most impressively, K3 achieved a state-of-the-art score of 91.2 out of 100 on BrowseComp , a benchmark for long-horizon, high-difficulty information seeking. The company says it accomplished this in a single-agent setup using its 1-million-token context window, without any context compression or additional context management techniques — a feat that suggests raw context length, when paired with strong retrieval capabilities, may be more powerful than elaborate multi-agent workarounds. As one widely followed AI commentator put it on social media: "Open source is no longer lagging six months behind Western closed-source models. Read that again, and think about what it all means." That observation captures the significance of the moment. For much of the past three years, open-source models have typically trailed their proprietary counterparts by a meaningful margin. Kimi K3 appears to have closed that gap almost entirely. How a 48-hour autonomous chip design demo reveals Moonshot's real ambitions Beyond raw benchmarks, Moonshot AI showcased a proof-of-concept that may be even more revealing of K3's capabilities and the company's strategic direction. In a demonstration documented in the company's technical materials, Kimi K3 was tasked with designing a physical chip to run a nano-scale version of itself. Over 48 hours of continuous autonomous agent operation, K3 independently completed the chip's full construction pipeline — from architectural design through optimization and verification — using open-source electronic design automation tools. The result was a tiny but functional chip design, just 4 square millimeters, that achieved timing convergence at 100 MHz and could decode more than 8,700 tokens per second in simulation. This is not a production chip. It is a demonstration of what Moonshot AI clearly views as the next competitive frontier: long-range autonomous agent capabilities. The ability to sustain coherent, multi-step technical work over a 48-hour window — reading documentation, making design decisions, running verification loops, and iterating on failures — represents a qualitative leap beyond the kind of single-turn question-answering that defined the first generation of large language models. The company also highlighted a case in computational astrophysics, where K3 reportedly reproduced the universal I-Love-Q relation — a complex calculation that typically takes a senior researcher one to two weeks — in approximately two hours, reading and cross-validating more than 20 papers and implementing a complete numerical pipeline along the way. Moonshot AI's fall and rise tells the story of China's brutal AI market To understand why Kimi K3 matters, you need to understand where Moonshot AI was 18 months ago — and how far it fell. Founded in 2023 by Yang Zhilin , a Tsinghua University graduate who previously conducted research at Google and Meta, Moonshot AI quickly became one of China's most prominent AI startups. The company gained early traction in 2024 when users flocked to its Kimi platform for its long-text analysis capabilities and AI search functions. By early 2026, it had raised roughly $1.5 billion across multiple rounds, with its valuation climbing from $2.5 billion to $4.3 billion and the company reportedly seeking a new round at $5 billion . Then DeepSeek happened. The release of DeepSeek's low-cost R1 model in January 2025 disrupted the entire Chinese AI landscape, and Moonshot AI was among the hardest hit. Kimi, which had ranked third in monthly active users in China, slid to seventh. The company's strategic pivot to open-source models — beginning with Kimi K2 in July 2025 and accelerating with K2.5 in January 2026 — was in large part an effort to reclaim relevance. Kimi K3 is the culmination of that effort — and the sheer scale of the model suggests that Moonshot AI has been planning this move for some time. Training a 2.8-trillion-parameter model requires enormous computational resources and months of preparation, which means the architectural and infrastructure decisions behind K3 were likely locked in well before the model reached the public. Why open-sourcing the world's biggest model is a geopolitical chess move The decision to release K3's full weights on July 27 is strategically significant and worth parsing carefully. The company's own timeline chart of open-source frontier model scale positions K3 as a dramatic outlier, towering above competitors like DeepSeek (1.6T), Xiaomi (1.02T), and Alibaba (397B). By releasing the world's largest open-source model, Moonshot AI is making a bid to become the center of gravity for the global open-source AI developer community. This follows a broader trend among Chinese AI companies. As Reuters noted , open-sourcing allows companies to "showcase their technological capabilities and expand developer communities as well as their global influence, a strategy likely to help China counter U.S. efforts to limit Beijing's tech progress." DeepSeek, Alibaba, Tencent, and Baidu have all released open-source models. But none have released anything at this parameter count. For enterprise technology leaders, the implications are concrete. A 2.8-trillion-parameter open-source model that performs at near-frontier levels creates new options for companies that want to fine-tune, self-host, or build proprietary systems on top of a capable base model — without being locked into API contracts with OpenAI or Anthropic. The trade-off, of course, is that running a model of this size requires substantial GPU infrastructure. Inference at 2.8 trillion parameters is not something that runs on a single server rack. That said, Moonshot AI has signaled awareness of this challenge. Its Mooncake project, which won the Best Paper award at FAST 2025, pioneered KV-cache-centric disaggregated serving for large language models — an architecture designed specifically to make inference at extreme scale more practical and cost-efficient. Kimi Code and a three-tier model lineup form the foundation of Moonshot's enterprise play Alongside K3, Moonshot AI continues to invest heavily in its coding agent ecosystem. Kimi Code , the company's open-source coding tool that competes with Anthropic's Claude Code and Google's Gemini CLI, received two major updates on the same day as K3's launch — versions 0.25.0 and 0.26.0 — adding features like expanded subagent tooling, background task management, and security fixes. The Kimi Code CLI has accumulated over 3,100 stars on GitHub and features integration with VSCode, Cursor, and Zed. The latest release expanded the "coder subagent" tool set to include background tasks, todo lists, plan mode, skill invocation, and nested agents — effectively turning the coding agent into a multi-layered autonomous system capable of managing complex software engineering projects with minimal human intervention. This is not incidental. Coding tools have become a critical revenue driver for AI labs. As Anthropic disclosed in January, Claude Code reached $1 billion in annualized recurring revenue . By building Kimi Code as an open-source alternative that defaults to Kimi's own models — but supports other providers — Moonshot AI is positioning itself to capture developer workflows and, eventually, enterprise contracts. The company's model lineup now includes three tiers: K3 as the flagship ($3/$15 per million tokens for input/output), K2.7 Code as a specialized coding model ($0.95/$4), and K2.6 as a general-purpose option ($0.95/$4). All three support context windows of 256,000 tokens or above, with K3 offering the full 1-million-token window. Context caching is automatic — no cache ID, TTL, or extra parameter is required — a small but meaningful developer-experience advantage over competitors that require explicit cache management. What Kimi K3 means for the future of enterprise AI and the global model landscape Kimi K3's release forces a recalibration of several assumptions that have guided enterprise AI strategy. The performance gap between open-source and proprietary models has functionally closed at the frontier. If K3's benchmark numbers hold up under independent evaluation — and particularly once the open weights are available for community testing on July 27 — it will be difficult for closed-source providers to justify premium pricing purely on the basis of capability. The locus of AI innovation, meanwhile, continues to shift. China's AI ecosystem, which many Western observers questioned after early struggles with chip export restrictions, has now produced a model that competes with the best systems from companies with direct access to Nvidia's most advanced hardware. The architectural innovations behind K3 — particularly the hybrid linear attention mechanism — suggest that algorithmic efficiency may matter as much as raw compute. And the agentic capabilities demonstrated by K3 — chip design, multi-week research compression, long-horizon information seeking — point toward a future where AI models are not just answering questions but autonomously executing complex, multi-day projects. For enterprises evaluating AI investments, this shifts the value proposition from "productivity copilot" to "autonomous technical workforce." Xinhua , China's state news agency, framed the release as a national milestone, reporting that K3 "marks a new step forward in the development of China's artificial intelligence models." Liu Tieyan, dean of the Zhongguancun Academy in Beijing, was quoted as saying that a wave of Chinese open-source models has moved from isolated breakthroughs to collective advancement, providing "new solutions and new paths" for global AI development. Just two years ago, Moonshot AI was a scrappy startup named for the audacious problems it hoped to solve. Eighteen months ago, it was a cautionary tale about how quickly a market darling can lose its footing. Today, it is the maker of the world's largest open-source AI model — one that can, given 48 hours and an internet connection, design a chip to run itself. The frontier, it turns out, is not a place. It is a race. And the field just got a lot more crowded.
Presented by Ping Identity Enterprises need to treat zero trust security architecture as an immediate requirement for AI agents rather than a long-term goal, says Andre Durand, CEO and founder of Ping Identity. Zero trust, the security model built on the assumption that no user, device, or system should be automatically trusted, requires continuous verification before every action rather than a single check at login. Agentic AI has profoundly compressed the risk timeline enterprises must manage, demanding that permission decisions be evaluated in real time. type: embedded-entry-inline id: 1Ieiy1KhHNWZE5KVqNdA1G That compression shows up in how permissions accumulate. Every time an employee approves an AI agent's request for access to a company drive, a database, or a code repository, the enterprise hands over a sliver of control that looks routine in isolation. Across thousands of agents making thousands of requests, those approvals accumulate into an exposure that most existing security architectures were never built to measure. "The rise in desire to use agents right now, and the speed of agentic, is highlighting the need to move faster on the principles of zero trust," Durand says. "Agents just move faster, full stop. A human compromise might be measured in minutes or hours, sometimes days. At agentic speed, a thousand actions could happen in five minutes." Why zero trust is now urgent for agentic AI That difference in velocity changes how enterprises need to think about permissions. Two variables matter: the surface area of access an agent is granted and the duration that access remains valid. Traditional identity and access management tends to grant broad permissions and leave sessions open for extended periods because the human using them moves at human speed. Zero trust, in contrast, collapses both variables at once by narrowing access down to what is strictly necessary and revalidating it continuously, rather than once at login. "Zero trust really just says, just enough, just in time," Durand says. "It's your next action that we care about. We're moving identity from an era where access was our runtime control point — meaning were you logged in, did you have a session — toward the decision that sits behind that login." Why agents must be treated as first-class identities That shift to decision-based control has direct implications for how agents should be provisioned in the first place. The common practice of letting an agent operate under a cloned human login or a shared service account doesn't work, Durand says. "Each agent should have its own identity," he explains. "It should not be impersonating the human. It can act on behalf of the human, we could explicitly delegate authority to an agent, but we don't want to blur the lines between the human taking action and the agent taking action." And beyond that is another concern: the shared secrets, API keys in particular, that many service accounts still rely on. For example, the habit of embedding keys directly in source code, where they can be committed accidentally and exposed, is a convenient but weak security pattern that agentic workflows make considerably riskier. Building service account architectures that let agents authenticate without relying on those shared credentials or other long-lived standing access is now an urgent priority rather than a long-term cleanup project. Where enterprises can enforce zero trust policies Enforcing any of this in practice requires identifying where policy can actually be applied. Several existing choke points, including API gateways and the agent gateway sitting in front of MCP servers, offer practical locations where enterprises can inspect what an agent is requesting and apply policy rules before granting it. "Those policies could leverage real-time risk and fraud signals, and then enforce, deterministically, what the agent can do when it interacts with these systems," Durand explains. The goal is to move authorization from something decided once at login to something evaluated at the moment of every consequential action, such as an agent attempting to commit code to a repository. Instead of carrying a standing permission to write to GitHub, the agent's request would be checked against context and policy at that specific moment, closing the window of trust down to the scope of a single action. Stopping AI agents from rewriting their own permissions That model becomes especially important given how agents can behave once they are already inside a system — for example, coding agents that have acknowledged, when questioned, either ignoring a specific guardrail entirely, or attempting to rewrite the permissions they were given. "Who's watching the watcher? Zero trust needs to apply here," Durand says. "If generative AI systems follow your instruction 97% of the time, and you're simply asking it for advice, that might be fine. If it's responsible for making a decision about who gets let in, 97% is not good enough." How to trust AI-generated output at agent speed The answer to that gap is not to eliminate AI from the review process, but to structure reviews so no single agent’s judgment is taken at face value. Because human review cannot scale to the volume and speed of agentic output without erasing the advantage of using agents at all, a new framework is necessary, so that when one agent produces work, such as code, separate agents evaluate it, provided those reviewing agents are kept from communicating with one another or with the one they are checking. It's a new human-AI paradigm, Durand says. "We probably will have to develop frameworks that we trust without seeing or verifying the output directly," he explains. "It's not that that construct is 100% foolproof. However, it's the best we can do to move at agent speed. We can't trust the exact output, but we can trust the framework." In practice, that means combining automated review with clear human accountability for higher-risk decisions, rather than treating agent output as self-validating. For traditional auditors, reviewing every transaction individually is never feasible, and statistically valid sampling stands in for full verification. The same applies to risk accumulation: a single agent action might carry little risk on its own, while a sequence of actions moving in a consistent direction could cross a threshold that triggers an intervention, including a kill switch capable of halting the agent before further harm occurs. What to ask when evaluating agentic identity platforms For security leaders evaluating identity platforms for agentic AI, there's no narrow checklist. Enterprises should evaluate what their full lifecycle of agent management looks like. Most enterprises are managing agents on two fronts simultaneously: customer-facing agents acting on behalf of external users, and internal agents deployed to automate enterprise processes. "Pause long enough to see the totality of what it would mean to secure multiple agents, both interacting with you from the outside as well as being deployed on the inside," Durand says. "We need discovery and visibility of all the agents operating within our estate, a place to register them, a standard way to assign custodians, and a way to construct and centralize policy so security can enforce it across the organization." And while basic security principles were already fully understood before agentic AI arrived, what has changed, Durand says, is that the cost of moving slowly has finally caught up with the cost of moving carelessly, giving enterprises a narrowing window to build the right architecture before widespread agentic adoption makes retrofitting far more expensive. 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 .
VentureBeat··6 min read
Zero-Day
↘2K
💬
Top Discussion
HN
Hacker News
“GPT-5.5's API pricing is reshaping how startups build AI products”
