IBM’s value has plunged after the company issued a preliminary second-quarter earnings update that fell short of Wall Street’s expectations.

Ahead of next week’s full earnings report, IBM CEO Arvind Krishna issued a statement on Tuesday warning that second-quarter revenue will miss expectations as customers continue to redirect IT budgets toward AI initiatives.

Why it matters for developers: The double-digit drop in IBM stock highlights another consequence of the AI buildout: Enterprise spending is shifting faster than some incumbent vendors can adapt.

Here’s what developers and platform teams should know.

IBM surprised investors on Tuesday by releasing a preliminary look at its second-quarter results, more than a week before its scheduled earnings report on July 22. The company now expects second-quarter revenue of $17.2 billion, up 1% year over year, with non-GAAP diluted earnings per share of $2.93, up 5%.

Those figures fell short of Wall Street’s expectations: FactSet analysts had forecast revenue of $17.86 billion and earnings per share of $3.01, the Associated Press reported. The early update did little to calm investors, sending IBM shares sharply lower.

But the miss itself wasn’t the full story. Management’s explanation for the weaker outlook may be even more important for developers and platform teams.

Capex shifts toward AI hardware

IBM now derives much of its business from enterprise software and infrastructure. As a major player in the enterprise (B2B) market, it provides software solutions ranging from security and data analysis to “middleware,” the software that lets myriad apps, databases, and platforms interconnect.

Software enterprise products are generally high-margin, making them great for a company’s bottom line. The problem for IBM is that the AI boom is causing many of its largest customers to cut spending on software services, enabling them to transfer funds toward purchasing the hardware components needed to build large AI data centers.

“In the last few weeks of June, we saw clients shift their quarterly capex spend toward servers, storage, and memory purchases to secure supply-constrained infrastructure ahead of expected price increases,” Krishna writes in the announcement. “This dynamic impacted client buying patterns.”

“In the last few weeks of June, we saw clients shift their quarterly capex spend toward servers, storage, and memory purchases to secure supply-constrained infrastructure ahead of expected price increases.”

However, Krishna also points out that IBM itself dropped the ball because it “did not anticipate the magnitude of the capex reprioritization.”

“These conditions require our teams to execute perfectly, and this quarter we faltered. We did not adapt and move quickly enough, and numerous large deals failed to close on the timelines we expected, driving the majority of our shortfall.”

“These conditions require our teams to execute perfectly, and this quarter we faltered. We did not adapt and move quickly enough, and numerous large deals failed to close on the timelines we expected, driving the majority of our shortfall.”

Middleware costs fall on developers

For software developers, the chain reactions of this capex reallocation will be felt nearly immediately. When enterprises freeze spending on high-margin middleware and off-the-shelf software from IBM and its competitors, the burden of consolidation falls entirely on internal engineering teams. To address the lack of expensive vendor solutions, platform engineers will be tasked with paving “golden paths” and building Internal Developer Portals (IDPs) using open-source tools.

If a company refuses to license the software required to connect legacy databases smoothly to new, expensive AI environments…developers will have to build those bridges manually.

Building bridges without vendor tools

If a company refuses to license the software required to connect legacy databases smoothly to new, expensive AI environments — like building ETL pipelines to feed legacy mainframe data into vector databases for Retrieval-Augmented Generation (RAG) — developers will have to build those bridges manually. This means more time writing custom APIs, maintaining brittle integrations using open-source alternatives like Apache Kafka or Envoy, and stitching systems together by hand.

What follows the infrastructure buildout

One way to interpret IBM’s warning is that many enterprises are still building AI infrastructure. Rather than expanding software budgets, organizations are prioritizing spending on servers, storage, memory, and other hardware needed to support AI workloads.

Once that infrastructure is in place, executives will expect it to generate business value. For engineering teams, the next phase is likely to focus on building AI applications, agentic workflows, retrieval systems, and production services that justify the billions already invested in compute.

In the near term, that could leave developers balancing two competing priorities of integrating new AI infrastructure while working within tighter software budgets.  Whether those software budgets rebound later this year remains to be seen.

The post “We did not adapt and move quickly enough”: What IBM’s earnings miss says about enterprise AI spending appeared first on The New Stack.

The clearest signal of a major pivot in enterprise AI came this week when Anthropic announced its second Global Premier Partner in the Claude Partner Network: UST.

Anthropic’s partnership with UST, an AI and technology transformation organization, is expected to improve the ability of UST to guide enterprise customers beyond proof-of-concept AI projects and into production-scale deployments.

Moving an AI pilot out of the sandbox and into a production-grade enterprise system is notoriously difficult, especially when every development team is building on a different large language model. The next phase of enterprise AI is the standardization of the stack.

This shift pulls model selection away from developers and hands it to enterprise platform teams, changing how engineering workflows will operate in the near future. As systems integrators increasingly embed a single model into the platforms they build and manage, AI selection is expected to become an architectural decision rather than an individual developer’s choice. The near-future reality might be that the model will become part of the stack itself, selected once at the platform level and inherited by every engineering team that relies on it.

This shift pulls model selection away from developers and hands it to enterprise platform teams, changing how engineering workflows will operate in the near future.

Standardizing the AI stack

As part of the agreement, UST will incorporate Claude into the engineering platforms and workflows it develops and operates for customers.

“Our alliance with Anthropic reflects UST’s unwavering commitment to helping clients navigate the AI landscape with confidence and achieve meaningful business outcomes,” said Krishna Sudheendra, CEO of UST.

“By combining the capabilities of Claude with UST’s engineering, industry knowledge, and delivery expertise, we are bringing to market industry-specific platforms and digital and engineering solutions that improve productivity, accelerate business outcomes, and help clients operationalize AI-led decisions in a safe and secure environment.”

Claude inside engineering platforms

One example of the coming standardization is UST’s integration of Claude into its engineering platforms, which are used by companies in the semiconductor, telecommunications, manufacturing, automotive, embedded systems, and IoT industries for design verification, chip validation, factory operations, and field service.

By using Claude, teams are expected to catch design flaws earlier, speed up chip validation, and integrate hardware and software into a single system, effectively laying the foundation for physical AI.

UST points to its UST-iDEC platform as an early example. The hardware and silicon validation platform already automates much of the validation process, which the company says reduces cycle times by up to 70% and halves typical turnaround times. By including Claude in the pipeline, UST aims to give the system more advanced reasoning capabilities rather than treating AI as a standalone assistant.

Claude Code now natively reads chip pinouts and hardware schematics to automatically write and execute regression tests that engineers previously had to script by hand. Concurrently, Claude’s reasoning models evaluate live edge data against digital twins to identify firmware regressions and signal-integrity faults. By uniting these capabilities, UST is accelerating an already-fast validation pipeline through less manual scripting and earlier fault detection.

Training 20,000 technical associates

Standardizing an AI stack requires aligning the workforce behind it. A central part of the alliance is UST’s commitment to training 20,000 developers and technical experts. Those associates will be certified on Claude across roles worldwide, including architects, engineers, consultants, industry specialists, and forward-deployed engineers who work directly alongside client teams.

“UST helps the world’s banks, telecoms, and manufacturers put new technology to work,” said Paul Smith, Chief Commercial Officer at Anthropic, in a statement. “They’re proving Claude inside their own engineering first, training 20,000 of their own people on it, before bringing it into the systems they build and run for clients.”

“They’re proving Claude inside their own engineering first, training 20,000 of their own people on it, before bringing it into the systems they build and run for clients.”

For engineering organizations, that level of standardization changes more than procurement. It reshapes day-to-day development. Shared AI workflows become reusable across teams, governance policies can be enforced centrally, and integrations with internal systems no longer need to be recreated for every project. The trade-off is that developers gain uniformity while giving up some freedom to choose whichever model they personally prefer.

Enterprise workflows beyond hardware

Outside physical AI, Anthropic has announced that UST is putting Claude to work by integrating it into selected industry and horizontal enterprise platforms.

In healthcare, UST’s CarePath uses Claude Code and MCP connectors to simplify member services and claims, routing recommended actions through an agentic layer for human approval. For telecom, UST IntelliOps introduces Claude’s reasoning into network operations to predict RAN failures and reduce the time NOC teams spend sorting signal from noise. Meanwhile, in the banking sector, UST FinX uses Claude to accelerate onboarding and automate document processing, providing staff with faster access to account data while maintaining built-in governance and audit controls.

“We are wiring Claude into how UST designs, builds, and runs solutions across our consulting, platforms, engineering services, and industry offerings,” said Manu Gopinath, President of UST. “This alliance with Anthropic helps us deliver higher-value outcomes for clients as advancing UST’s transformation into an AI-native organization.”

“We are wiring Claude into how UST designs, builds, and runs solutions across our consulting, platforms, engineering services, and industry offerings.”

By acquiring firsthand experience with the operational, technical, and change management challenges of AI adoption internally, UST is building an operating playbook of tested workflows. For enterprise organizations, the takeaway is clear: The future of AI relies on standardizing the stack and moving AI selection out of the sandbox and into the platform layer.

As more systems integrators adopt this approach, developers will increasingly inherit the AI stack their organization has already chosen.

The post Anthropic’s newest enterprise partner is training 20,000 people on Claude — here’s the shift it signals appeared first on The New Stack.

Agentic systems usually have two jobs: Build context, then use that context to produce an answer or action.

Many failures that look like LLM problems start in the context-building step. The answer the LLM gives is limited by the context it was given, or it finds through tool calls. If the agent model cannot find the right sources, then improving the generation model will not improve the overall system.

“Many failures that look like LLM problems start in the context-building step.”

A client, Specstory, wanted to give users the ability to ask questions from the agent’s history. For example, why a team chose Authlib for authentication and what alternatives they considered. The chatbot needs the right prior conversations, decisions, and tradeoffs from a large corpus of coding sessions. The model and system prompt help only after those chat turns have been retrieved and are in context.

If retrieval ranks implementation snippets above the discussion where the team weighed alternatives, the agent can still produce a confident answer. It may find code that imports Authlib and a few inline comments, then describe the decision based on implementation evidence rather than the actual trade-off discussion.

The same pattern showed up in an AnkiHub operator review in our private community. A request for help studying based on lecture slides only works if the agent’s tool calls retrieve the right flashcards. The hard part is not finding any related cards. A lecture on the function of the heart may match hundreds of cards. Ranking decides whether the core cards make it into context or whether the system has to raise top_k and flood the prompt.

The exact setup changes by product. The context-building step might use local search, semantic search, web or API calls, or database queries. It might be handled by an agent, a fixed workflow, or application code. The process stays the same: gather the right context, then generate from it.

For example, a coding agent runs rg, opens files, reads logs, and inspects tests before writing a patch. A research agent searches the web and internal notes before writing an answer. A study assistant searches deck facts and user context before suggesting what to learn next.

When context building fails, the symptoms look like generation failures.

Retrieval failures mimic generation bugs

Symptom	Retrieval cause
Hallucination	The answer source never made it into context.
Context rot	Low recall forces a high top_k, so noisy results fill the context window.
Latency	Weak retrieval leads to more tool calls, larger candidate sets, and larger context windows.

A better model helps with reasoning and writing, but it cannot give a better answer without the right context.

“A better model helps with reasoning and writing, but it cannot give a better answer without the right context.”

The Mixedbread OfficeQA-Pro Eval shows the same pattern at the benchmark scale. OfficeQA-Pro uses 89,000 pages of financial documents, dense tables, scanned PDFs, and questions that require reasoning across documents. Giving Codex better search tools reduced tool calls and improved answer quality.

Plain-text tools like grep and rg work (ish) on flat code files. They do not work well when context lives in PDFs, tables, chat histories, multi-modal inputs, web results, and permissioned data. In those cases, the agent needs a retrieval that can combine exact terms, meaning, metadata, permissions, and ranking quality.

Retrieval needs traces and evals

Once retrieval enters the architecture, the next question is whether it finds the right information.

For that, you need traces and evals. For each retrieval step, the minimum trace is the input, the outputs, and a way to label whether each output was relevant.

For a coding agent using rg the input is the command, the output is the returned snippets, and the label says which snippets helped, which were noise, and which relevant files were missing.

For product retrieval, the step might be BM25, semantic search, hybrid search with reranking, a generated SQL query, or something else. Capture the query or arguments, the returned documents or chunks, and whether those results were helpful.

Trace each retrieval step by itself, then evaluate the full context-building pass. The local trace answers “Did this query return useful material?” The full trace answers “Did the system collect everything the model needed before generation?” If it did, failures are a generation problem. If not, it’s a retrieval problem.

You cannot know where the failure started or what to fix without traces.

Different failures need different fixes

“Improve retrieval” is too broad to be useful, as different problems require different solutions. If a relevant document is missing, the trace should show where it disappeared: query building, retrieval, filtering, ranking, or final context assembly.

The failed step, plus what the trace shows, tells you what change to make.

Failed step	What the trace shows	Change to make
rg / grep	A conceptual query returns literal matches while missing relevant files.	Add semantic search over files or chunks, or generate better keyword queries before calling rg.
BM25	The query uses the right concept but different words from the source material.	Add semantic search, synonyms, or query expansion.
Semantic search	Exact names, error strings, document IDs, or domain terms are missing from the results.	Add a keyword or BM25 path, or boost exact term matches.
Hybrid retrieval	The relevant passage is ranked 7th, but the context only takes the top 5.	Add or tune a reranker, or raise candidate top_k before reranking.

The right fix depends on what the system was trying to retrieve. A decision-history question requires the decision, the alternatives, and the chats in which the team worked through them. A study question depends on the lecture material, deck metadata, semantic matches, and the user’s study context.

The architecture

Once you trace individual retrieval calls, the full architecture has a simple shape: fan out to context-building tools, then fan in to generate the final output.

The retrieval layer might be a search engine, a vector database, an SQL query, a local file tool, a web search API, or a custom service. The pattern stays the same: build candidate context, narrow it, rank it, assemble it, then generate from it.

Give agents human search controls

Semantic search compares embeddings (numerical representations of meaning). It helps when wording differs, but most retrieval intents also depend on structured constraints. A meeting search box can use semantic search over transcripts and notes, but a useful interface also lets someone filter by person, date, project, and source. 

A finance search may need the latest filing, a specific quarter, or an official source in addition to the closest semantic match. In e-commerce, the best semantic match for “32×30 cargo pants” may be an out-of-stock product. The system still has to decide whether to hide it, return it with a backorder note, or show it so the user can check later. That product decision is a retrieval decision because it changes which candidates reach the agent.

In a chat interface, those controls are in the tool schema, query planner, or app logic. If an agent runs the search, it needs arguments for the same constraints a human would set with filters, sliders, tabs, and sort menus.

A retrieval system usually needs several controls working together:

Control	What it does	Example
Exact match	Matches names, IDs, error strings, quoted phrases, tickers, or product codes.	Find EADDRINUSE, Authlib, or a specific SEC accession number.
Semantic match	Finds related content when the wording differs.	Find the meeting where the team discussed authentication tradeoffs.
Hard filters	Removes invalid results before ranking.	Limit by tenant, permissions, person, date range, size, or stock status.
Sorts	Orders candidates by a structured field.	Prefer the newest, latest filing, lowest price, highest rating, or recency.
Ranking	Scores candidates based on their likely usefulness for this request.	Combine semantic match, exact match, freshness, source quality, and use.
Reranking	Uses a slower model or scorer on a smaller candidate set.	Compare the query against the top 100 candidates before returning 10.

Here, a chunk means a small piece of source content, and a candidate is a chunk returned by the first search step. Ranking is the scoring step that orders those candidates. Context assembly then selects which chunks and structured fields to include in the model prompt.

Better ranking improves precision, which means a larger share of the returned chunks is useful. If the relevant chunks are near the top, the system can pass fewer chunks to the model, use fewer tokens, reduce latency, and expose the model to less noise. If the right chunk is ranked 40th and the context only includes the top 10, the system behaves as if the retrieval missed it.

People and agents use the same basic search path: ask for results, inspect what comes back, and decide what to use. A person can skim ten search results, compare titles, snippets, dates, domains, and URLs, and decide whether the result set looks right. They can open the third result, ignore the rest, and search again with a better query. An agent usually receives a bounded set of returned documents and reasons from the context. If the right source falls below the cutoff, the agent may answer from partial context. To avoid this, the system has to retrieve more candidates, run more searches, or pass more evidence into the model.

A missed document can change what the agent searches for next. Suppose someone asks why the team chose Authlib. If the first search misses the transcript where the team compared Authlib with alternatives, the agent may search the codebase instead. It finds imports, callback handlers, tests, and maybe a comment. Then it asks follow-up questions about OAuth configuration. The context starts to look complete, but it supports the wrong answer. It explains how Authlib was used and why it makes sense in the codebase, not why the team chose it.

“The context starts to look complete, but it supports the wrong answer.”

But ranking cannot repair every search problem. If the agent failed to request the latest filing, a reranker may faithfully select an older document with a closer wording match. If the tool has no date_range, person, source_type, size, or in_stock argument, the model has to impose hard constraints in the search text and hope that retrieval infers them. A hard filter gives the model less to infer, making semantic search more reliable.

Scale changes the retrieval problem

Search systems already have tools for this: indexes, filters, facets, sorts, caching, bounded reranking, and freshness jobs. Agent systems need the same discipline.

A human might search, adjust a date filter, scan the first page, then search again. One agent request can do that many times in seconds: rewrite the query, run keyword and semantic search, inspect thin results, issue follow-up searches, fetch sources for citations, and ask for more context before answering. With many concurrent users or agents, the retrieval layer can become a bottleneck.

Humans often wait through a slow search if the result is good. Agent systems often turn slow and uncertain search into more work. When ranking is weak, teams compensate by raising top_k, running keyword and semantic searches in parallel, adding reranking, fetching more source documents, and passing larger evidence bundles to the model. That can improve answers, but it moves the cost into tokens, latency, and retrieval load. A better ranking lets the system return fewer, better candidates, rather than making every request carry a larger pile of possible evidence.

With a small corpus, you can still search comprehensively quickly and cheaply, even with fully agentic approaches. That’s what I recommend when you’re starting and don’t have much data. Don’t add complexity until you need it. But with millions or billions of chunks, every extra retrieval call, candidate, ranking pass, and returned token adds up quickly.

Multi-stage retrieval is the production shape

Most production systems should split retrieval into stages, even when the UI is a chat box.

Stage	What happens	Trace question
Search argument construction	The app or agent turns the request and state into a query, filters, and sort.	Did it ask for the right content with the right constraints?
Candidate generation	The system finds plausible chunks from text, vectors, or structured data.	Did the right source enter the candidate set?
Filtering	Permissions and product constraints narrow what can be returned.	Was the source correctly excluded or wrongly lost?
Sorting	Structured fields order results when order matters.	Was the latest, cheapest, highest-rated, or current item surfaced?
Ranking	The system scores the candidates based on their usefulness for this request.	Was the source present but ranked too low?
Summary return	The system returns only the fields the agent needs.	Did the app receive usable evidence and provenance?
Context assembly	The app selects, formats, and budgets evidence for the model.	Did useful evidence get dropped before generation?
Evaluation	Humans or automated checks label whether the retrieval path worked.	Can the team turn the failure into a specific fix?

Each stage leaves a different repair path. If the agent chose the wrong filters, changing the embedding model will not help. If the latest document was available but the tool never sorted by date, the fix belongs in the search arguments or retrieval API. If the right source was present but below the cutoff, the fix belongs in the ranking. If the right source came back but was dropped before generation, the bug is in context assembly.

As retrieval becomes a core part of agent architecture, teams increasingly need infrastructure that can combine semantic search, exact matching, filtering, ranking, and large-scale retrieval in a single system. Depending on requirements, this may involve search and retrieval platforms such as Vespa, Elastic, or Coveo, each of which supports different approaches to ranking, retrieval, and operational scale. 

The important point is not the specific technology choice, but recognizing that retrieval quality has become a first-class engineering concern. As agent workloads grow, retrieval systems are increasingly determining the accuracy, cost, latency, and reliability of the overall application.

The post Why retrieval quality is becoming the defining challenge in AI agent architecture appeared first on The New Stack.

Vercel CEO Guillermo Rauch and Coinbase CEO Brian Armstrong run very different companies, but they’re making the same architectural bet. Instead of building around a single AI provider, both are designing production systems that can route work across multiple models.

Rauch and Armstrong aren’t making this decision in a vacuum. Frontier models have become much closer in capability for everyday engineering work, open-weight alternatives have improved dramatically, and the price gap keeps widening. That makes it much easier to justify routing work across several models instead of committing to one. 

Trillion tokens, zero loyalty

In an interview with TechCrunch, Rauch said that Vercel now routes more than a trillion tokens a day across millions of deployments, and that the company is actively moving away from one-lab partnerships. Rauch’s point highlights that the model has become just one interchangeable component in a larger inference pipeline.

That’s a significant position from the CEO of a company that serves as deployment infrastructure for a huge share of the frontend ecosystem. Rauch is calling single-lab partnerships obsolete.

Rauch is calling single-lab partnerships obsolete.

Cheaper defaults, smarter routing

Armstrong is making the same bet, and the financial results state his case. Coinbase cut its internal AI spend by nearly half while overall token usage continued to grow, without imposing usage caps on engineers.

Their playbook basically runs on three core levers.

First, it’s an internal LLM gateway. Coinbase deliberately defaults its engineers to lower-cost open-weight models, specifically Z.ai’s GLM 5.2 and Moonshot AI’s Kimi 2.7. Engineers can still pull down a stronger model if a specific job absolutely demands it, but the pricing gap makes the default choice obvious. GLM 5.2 costs roughly $1.40 per million input tokens and $4.40 per million output tokens.

Compare that to Anthropic’s Opus 4.8, which sits around $5 for input and $25 for output. You are looking at a three- to six-times cost reduction per token. And it holds its own on major coding benchmarks, scoring 62.1 on SWE-bench Pro, compared to GPT-5.5’s 58.6. Plus, because Coinbase self-hosts these models, zero code or query data ever leaves their environment.

The second lever is task-based routing. Armstrong makes a highly practical point here, suggesting teams want a frontier model to do the heavy lifting for complex planning, but for pure execution tasks, where cheaper models perform just as well, there is zero reason to pay top dollar.

The third piece is aggressive caching. By keeping a conversation locked to the same model as long as the cached context is valid, Coinbase managed to push its cache hit rate from a measly 5% up to 60%. That 12x jump is a massive cost driver.

Gateways as control planes

If you want to understand Armstrong’s broader mindset, listen to his recent chat on the Sourcery podcast. He casually mentioned that Coinbase now operates with roughly 1,200 full-time AI agents, a number they calculate by normalizing compute hours to a standard 40- to 60-hour workweek. At that scale, he argues that human developers have absolutely no business manually choosing which model to use. The infrastructure has to automate that decision entirely.

Human developers have absolutely no business manually choosing which model to use.

Because foundation models are becoming so easy to swap in and out, the engineering focus is shifting to the surrounding infrastructure. Like a centralized control plane, a gateway intercepts every prompt and makes a dynamic, split-second decision about whether a workload actually requires the expensive reasoning capabilities of a frontier model or a cheaper, faster alternative can handle it. The infrastructure makes that call based on the cache state, the complexity of the task, and real-time pricing.

Teams need visibility into latency, uptime, token consumption, and cost across all providers because using multiple model providers changes observability requirements. Without that data, it’s difficult to know whether routing decisions are actually improving performance or reducing costs.

Test before you trust

Evaluation becomes just as important. Lower-cost models need to be continuously tested against the workloads that matter to an organization before they are deployed to production traffic. Public benchmarks are a useful starting point, but are no substitute for measuring how a model performs on your own code, data, and workflows.

Trying to pick the single best AI provider is a losing game.

What’s striking is that Vercel and Coinbase arrived at remarkably similar architectures despite solving different problems. Both assume that today’s best model probably won’t stay on top for long. If that’s true, the competitive advantage shifts away from the model itself and toward the infrastructure that decides which one to use. 

The post Coinbase runs 1,200 agents and just slashed its AI bill in half appeared first on The New Stack.

For the past two years, the conversation about AI-assisted software development has been dominated by speed. A new GitLab survey of more than 1,500 developers and technology leaders found that 60% say AI coding ROI has already exceeded expectations, and 78% report their teams are writing and committing code faster since adopting AI tools. 

But speed without control is a liability.

Most organizations have pursued agentic engineering by adding AI coding tools on top of their existing infrastructure. Coding agents are delivering speed, but that speed isn’t showing up across the full software lifecycle: Only 21% of respondents report productivity gains beyond code generation itself.

“Speed without control is a liability.”

The infrastructure problem runs deeper. Git backends, toolchains, and governance frameworks were built for human-scale concurrency. Agents operate at machine scale, and that mismatch shows up fast. Platform reliability breaks down with millions of agent sessions hitting the same backend, security exposure widens as agents touch dependencies at scale, and cost overruns mount as agents consume tokens inefficiently on infrastructure that wasn’t built for them.

Agentic adoption outpaced governance

The adoption curve for AI coding tools outpaced the development of required guardrails, with 80% of organizations saying they adopted AI tools faster than they developed policies to govern them, and 82% reporting that AI-generated code risks creating a new form of technical debt that their organizations are not prepared to manage.

In practice, that means platform reliability challenges under agent load, security and compliance exposure that widens as agents touch dependencies at volume, and agents operating with artificial confidence because they lack full context. Only 28% of organizations say their software development lifecycle tools are fully integrated with shared data and workflows, which means most teams are trying to govern agent actions across a toolchain that was never designed for them.

Agentic engineering needs agentic infrastructure

Agentic engineering requires two things: agentic coding and agentic infrastructure. Most organizations have the first but lack the second.

Agentic infrastructure spans four areas: the execution layer, the context layer, the governance layer, and the orchestration layer working together.

The first is machine-scale execution. Git backends, CI/CD pipelines, and deployment systems were designed for human-paced development. In the agentic era, they need to handle millions of agent sessions without breaking. When a production incident occurs, the path from symptom back to origin should take minutes, not days.

The second is context that travels with code. As Bastian Stahmer, Business Owner of Vehicle Software Development Platform at Mercedes-Benz, put it on a panel recently, “An agent can only be as good as the context and semantics fed to it.” A context graph connecting code, work items, pipelines, security findings, and production signals is what makes agents genuinely useful at scale and keeps artificial confidence in check.

“An agent can only be as good as the context and semantics fed to it.”

The third is governance built into the flow. Agent actions need to be tied to an identity, logged against a policy, and provable to a reviewer. Low-risk changes move fast, while higher-risk changes trigger review. For Mercedes, operating under automotive regulatory standards that require full traceability and human accountability, GitLab is the control plane where that accountability lives.

The fourth is orchestration. Execution, context, and governance are only as effective as the system coordinating them. The orchestration layer coordinates agent actions across the full software lifecycle according to the policies teams define, determining which agents run, in what order, and how failures and handoffs are managed. Without it, agentic infrastructure is a set of independent capabilities rather than a working system.

What’s next

The next phase of AI in software will focus less on generating code and more on governing it, according to 85% of respondents. That shift reflects how enterprises are maturing their thinking about AI, from a productivity tool to a foundational capability that needs to be trusted, traced, and maintained at scale.

When governance is built into the platform, speed and control are no longer in tension. Traceability becomes a competitive advantage. Context becomes institutional memory. And the codebase, rather than accumulating invisible risk, becomes an asset that grows more reliable over time.

The post GitLab just surveyed 1,500 developers. Here’s why it matters for your codebase. appeared first on The New Stack.

The biggest news to emerge from the AI world this week was undoubtedly that Elon Musk’s SpaceX had agreed to acquire AI coding startup Cursor in an all-stock deal valued at $60 billion.

But on the very same day, at an invite-only developer conference hosted by Cursor in San Francisco, Tomas Reimers took to the stage to unveil a fledgling project that could prove just as consequential for the developer tools industry.

Origin, as it’s called, is a Git-compatible code-hosting platform designed from the ground up for a world where AI agents — rather than humans — do the bulk of the work.

Reimers, it’s worth noting, is co-founder of Graphite, a code-review startup that Cursor revealed it was acquiring back in December (a deal that apparently closed in January). At the time, some commentators noted the deal’s implications for GitHub — among them was Gergely Orosz.

Orosz, author of The Pragmatic Engineer newsletter and an investor in Graphite, who wrote on LinkedIn: “I’m telling you: GitHub’s biggest competitor could soon be Cursor. Graphite — in my view — is the best AI code review + stacked diffs + PR workflow product out there. GitHub is already playing catch-up to Cursor/Graphite.”

Put simply, Graphite had already built workflow tools that GitHub was scrambling to replicate — and with Cursor’s resources behind it, the gap was only going to widen. And now with the might of SpaceX, a $2.5 trillion company, behind it, things could be about to get very interesting.

The Origin origin story

On stage in San Francisco ahead of Origin’s unveiling, Reimers pointed to Graphite’s customer base — which includes Shopify, Snowflake, Notion, and Figma — as evidence of a problem already well underway before Origin existed.

“When we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”

“Over the past few years, we noticed the trend as these companies adopt AI tooling,” Reimers said. “The tools that they relied on started to become unreliable. That’s because over the past few years, AI tooling has totally changed our industry. It’s enabled every developer to be a 10 to 100x developer, but that change has required fundamentally different tooling. That’s why, when we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”

Amid all the hullaballoo of SpaceX hitting the public markets, becoming one of the world’s most valuable companies overnight, and doling out a cool $60 billion for a four-year-old startup, it’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.

It’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.

GitHub, the world’s dominant code hosting platform by some distance, is having a rough time of it. As The New Stack reported in June, the platform has logged hundreds of incidents over the past 12 months, struggling to keep pace with the volume of code that AI agents are generating. The company says it’s now processing about 1.4 billion commits per month — up from 1 billion across all of 2025 — with agents alone generating more than 17 million pull requests per month.

The irony isn’t lost on anyone: GitHub helped kickstart the AI coding era with the launch of Copilot in 2021, and it’s now buckling under the weight of it. And for some, the cracks are already showing in their day-to-day habits.

Brian Douglas, GitHub’s former director of developer advocacy who recently launched his own AI infrastructure startup called Paper Compute, tells The New Stack that the shift is already underway.

“Agents are quickly killing the will for doing open source.”

“Agents are quickly killing the will for doing open source,” Douglas says. “I’d love to see what GitHub’s [monthly active user] numbers look like today, because I am sure there are a number of folks choosing to do code reviews elsewhere — or exclusively collaborating with agents to get the work to the last mile — which is at an all-time high.”

Douglas, for what it’s worth, counts himself among them, saying he now does much of his review and PR work directly in AI coding tools.

“As a GitHub power user, I find myself using it less, and relying more on Claude and Codex for review and PR interactions,” he says.

A post-GitHub world?

Origin remains in waitlist-only mode ahead of a planned fall launch, and those present at Compile reported enough detail to sketch its ambitions. Developer advocate and independent commentator Shawn Wang Yuexian, known as swyx, described it as a “long-awaited Git competitor, scalable for agent workloads, extensible with API and MCP, and with built-in merge conflict and CI failure agent resolution.”

Whatever Origin looks like in its launch guise, it’s clear the appetite for an alternative to the status quo is growing. The software development world has changed considerably since GitHub popularized the pull request model back in 2008 — a feature that Douglas calls its “best ever.” But the pull request was designed for a world where humans deliberately wrote and reviewed code, one change at a time. That world is receding fast.

“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code.”

“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code,” Douglas says. “So if the goal is to put it in the cloud so agents are managing the code, I think that is absolutely an opportunity for disruption.”

So, as AI agents push code at a rate no human reviewer can keep up with, the pull request risks becoming a formality — a box to tick rather than a meaningful quality gate. Which raises a deeper question about how the industry should measure the value of software work at all.

For Douglas, the answer lies in a different unit entirely. Commits and lines of code — the traditional proxies for developer output — tell you little in a world where an agent can generate thousands of lines in seconds. Tokens, by contrast, map directly to compute cost and, therefore, to the real effort and value generated. It’s a reframing that suits Cursor rather well.

“Tokens are a better metric than commits.”

“Tokens are a better metric than commits,” Douglas says. “They align to a dollar spent that correlates to the effort of work. Previously, we pretended lines of code were the metric, and that was proven incorrect. But tokens plus agent sessions equals customer value — and Cursor is positioned well to own a deeper part of the collaboration stack.”

Cursor, though, isn’t alone in that conviction, and a slew of tangential efforts to rebuild that infrastructure for the agentic era are emerging.

At its Transcend conference in London on June 10, GitLab announced a private beta of what it calls Next Generation Source Code Management — known internally as Project Switch. Unveiled on stage by GitLab chief product and marketing officer Manav Khurana, the new backend keeps the Git protocol intact but redesigns the underlying architecture entirely, allowing agents to query repositories server-side rather than cloning them in full.

GitLab says it delivers up to 50 times faster task execution per agent, with up to 3 times fewer tokens consumed. And notably, Anthropic is a design partner on the project.

“The most popular Git platforms in the world are buckling under the load, not just because of your teams cloning, branching, and merging code, but also dozens, in some cases hundreds, of agents working simultaneously and putting a lot of pressure on those systems,” Khurana said.

The day after GitLab’s Transcend announcement, Zed co-founder Nathan Sobo published details of DeltaDB, a project the company had first teased the previous fall. A more radical proposition than either Origin or Project Switch, DeltaDB replaces Git’s commit-based model entirely with a continuous stream of fine-grained deltas — every operation an agent performs, linked directly to the conversation that produced it. Sobo confirmed that a beta version is just weeks away.

HashiCorp co-founder Mitchell Hashimoto, meanwhile, has seen this coming. Back in December, he wrote on X: “The AI companies are on track to become GitHub faster than GitHub is becoming an AI company.”

The AI companies are on track to become GitHub faster than GitHub is becoming an AI company. I'm sure there's a lot of sycophants within GH/MS showing off PowerBI dashboards to argue against this for their own personal gain, but wake the fuck up.

— Mitchell Hashimoto (@mitchellh) December 19, 2025

When Origin was announced this week, he retweeted himself with a single line: “Cursor announced Origin today. More will come.”

*taps sign* Cursor announced Origin today. More will come. https://t.co/MwLN0Q7dHX

— Mitchell Hashimoto (@mitchellh) June 16, 2026

Hashimoto, as it happens, is an investor in another agent-native code hosting startup called East River Source Control (ERSC), which is building a Git-compatible platform designed to land thousands of commits per second.

The model is the moat

For Douglas, the convergence of competing efforts to rebuild version control from the ground up isn’t hugely surprising. In the past year, he points out, a similar dynamic played out with developer sandboxes — the environments where code gets written and tested — as companies like Docker, Cloudflare, and Vercel moved into that space because that’s where developers were spending their time.

The same gravitational pull is now acting on version control. The way developers work has changed fundamentally — where once they wrote code directly inside their editors, many now spend their time directing AI agents that do the writing for them. The IDE is no longer primarily a place to type; it’s increasingly a place to watch, review, and steer.

“I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”

“Now, IDEs are suffering from the fact that developers have evolved to foundational model harnesses writing code, and they need to position themselves as the tool you open to watch agents write the code,” Douglas says. “I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”

Underpinning all of this, though, is a commercial reality. Cursor has been building toward this position for some time, having launched its own first-party coding model, Composer, in 2025 and iterating on Composer 2.5 in May, giving it cheaper, in-house inference rather than relying entirely on costly API calls to Anthropic and OpenAI. Composer 2.5 costs a fraction of Claude Opus at equivalent tasks — as much as a tenfold difference on output tokens. Owning the model, in other words, is what makes owning the rest of the stack viable.

Introducing Composer 2.5, our most powerful model yet.

It's more intelligent, better at sustained work on long-running tasks, and more reliable at following complex instructions.

For the next week, we’re doubling the included usage of the model. pic.twitter.com/N87ojcXlOC

— Cursor (@cursor_ai) May 18, 2026

“It’s clear you can’t just insert an OpenAI key and expect hyper-growth or longevity in this market anymore,” Douglas says. “Instead, you need to own the model to win.”

Whether SpaceX’s firepower accelerates that ambition or complicates it remains to be seen. But the companies placing bets on the next era of software development aren’t waiting for GitHub to catch up.

The post Cursor, GitLab and Zed agree GitHub is breaking. They disagree on how to rebuild it. appeared first on The New Stack.

A recent GigaOm CxO Decision Brief explores how AI retrieval architectures are evolving beyond flat vector databases as organizations combine semantic search, ranking, personalization, and machine learning inference in production systems.

Vector search changed the AI infrastructure landscape by making semantic retrieval practical at scale. By converting text, images, and user behavior into embeddings, organizations could move beyond exact keyword matching and retrieve information based on meaning. But production AI systems rarely stop at vector similarity.

A real-world query often requires multiple signals to be evaluated simultaneously. Semantic relevance may be one factor, but so are structured attributes, business rules, personalization signals, freshness, access controls, recommendation logic, and machine-learned ranking models. As organizations move from AI experimentation to production-scale applications, the challenge is no longer simply finding similar items. It is in combining all of the signals that matter while maintaining low latency and operational simplicity. This is where tensors are attracting increasing attention.

While vectors represent information as a single dimension of numerical values, tensors provide a more general framework for representing and operating on complex, multi-dimensional data structures. They offer more control in how relevance is computed, allowing dense embeddings, sparse features, metadata, and model outputs to be evaluated together within a unified retrieval and ranking process. For organizations building large-scale retrieval systems, this raises an important architectural question: is a flat vector store sufficient, or does the next generation of AI applications require something more expressive?

“Tensors provide a more general framework for representing and operating on complex, multi-dimensional data structures.”

A new GigaOm CxO Decision Brief, “The Tensor Advantage in AI Search,” explores this question in depth.

Among the findings:

• Production AI systems increasingly depend on combining semantic, lexical, behavioral, and business signals rather than relying on vector similarity alone.
• Architectural fragmentation between vector databases, search engines, rerankers, and feature stores introduces latency, operational complexity, and synchronization challenges that become more significant as workloads scale.
• Emerging retrieval models, including multi-vector and late-interaction approaches, place new demands on infrastructure that were not anticipated when first-generation vector databases were designed.
• Tensor-native architectures provide an alternative approach by treating multidimensional data structures as first-class citizens rather than forcing them into simpler vector abstractions.

The paper also examines the infrastructure, operational, and organizational implications of these architectural choices, including benchmark data, deployment considerations, and the trade-offs engineering leaders should evaluate when planning future AI retrieval systems.

“Retrieval is evolving from a nearest-neighbor problem into a ranking and decision-making problem.”

As AI applications become more sophisticated, retrieval is evolving from a nearest-neighbor problem into a ranking and decision-making problem. Understanding the role tensors play in that transition may be one of the most important architectural discussions facing engineering leaders today.

Download the GigaOm CxO Decision Brief to explore the findings in full.

The post Why AI retrieval and ranking need more than vector search appeared first on The New Stack.

GitHub hasn’t had an easy year. The platform has been hit by repeated outages affecting core services — including the Actions-based CI/CD pipelines that engineering teams depend on daily — and has had to issue public apologies as a result.

The scale of the problem is staggering: Where GitHub handled roughly 1 billion commits across the whole of 2025, it now processes 1.4 billion every month, with AI agents alone responsible for more than 17 million pull requests in the same period. GitHub’s COO Kyle Daigle told The New Stack in early June that the company is now targeting capacity to handle 30 times its current load — a challenge he described as far beyond the normal playbook of adding more machines.

Against that backdrop, Microsoft has chosen this moment to make its most direct push yet to push enterprise customers off Azure Repos — its own Git-based source code platform, which has existed in various forms since 2013, predating Microsoft’s $7.5 billion acquisition of GitHub in 2018 — and onto GitHub.

The exit ramp

The tool Microsoft is using to make that case is Enterprise Live Migrations (ELM), currently in limited public preview. The core problem it solves is downtime: previously, moving large repositories from x to x could take days, leaving teams frozen out of active development.

In a blog post authored by Soo Stahl, principal product manager at Azure DevOps, and product manager Bhuvan Shah, the pair explain that ELM works by keeping the source and destination repositories in sync while developers continue working in Azure Repos, with a final switchover window that they say typically takes under 30 minutes.

“Teams can migrate at their own pace, without coordinating complex, high-risk ‘all-at-once’ migrations.”

“This means no extended freeze periods, no multi-day outages – just a controlled, predictable transition that fits into your operations,” they write. “Teams can migrate at their own pace, without coordinating complex, high-risk ‘all-at-once’ migrations.”

There are real limitations worth acknowledging. ELM carries over the fundamentals — full Git history, branches, tags, pull request metadata, including comments and user history, and branch policies translated into GitHub rulesets — which, for teams whose work is primarily code-focused, may cover most of what they need.

But pipelines, work items, wikis, and test plans all have to be handled separately, and for enterprises deeply embedded in Azure DevOps’s broader project management and CI/CD tooling, ELM is a starting point rather than a complete solution.

For large organizations with hundreds of repositories, this is a multi-stage undertaking regardless.

For Microsoft, the calculus is all about AI — GitHub is where Copilot, the Copilot Coding Agent, and the broader agentic development suite live, and Azure Repos is not part of that picture.

To demonstrate that this is more than a customer pitch, Microsoft recently published details of its own migration — its Copilot, Agents and Platforms (CAP) organization moved over 1,600 repositories and 3,100 developers across in six months, with a team of just two dedicated engineering leads driving the effort.

By consuming its own dog food at scale, Microsoft is making the case that the disruption is manageable and the payoff meaningful. Poonam Gupta, partner director of product management for 1ES and Azure DevOps at Microsoft, cites AI as the primary driver of the migration.

“Software development is being reshaped by AI, and where code lives now have a direct impact on how much value organizations can capture.”

“Software development is being reshaped by AI, and where code lives now has a direct impact on how much value organizations can capture,” Gupta writes. “For teams that want to take full advantage of AI-native development, repository location is becoming a strategic decision.”

The elephant in the room

Rumors of Azure Repos’ eventual deprecation have circulated online for years, and while Microsoft has not confirmed anything on that front, the direction of travel is clear.

The community response to Gupta’s June 3 post captured the mood among enterprise customers: several questioned why AI capabilities couldn’t be brought to Azure Repos rather than requiring a platform change, while others raised the cost differential — Azure DevOps Basic costs $6 per user per month, compared with GitHub Enterprise’s $21.

And more than one commenter interpreted the post as a deprecation notice in all but name. “The writing was on the wall since MS [Microsoft] bought GitHub,” wrote one commenter. “[Azure DevOps] is dead and MS wants everyone moving to GitHub… Everybody saw this coming, and only MS denied it.”

Perhaps more important here is the question that Microsoft sidesteps: if GitHub has spent the past year struggling under the weight of agentic development traffic, why is now the right time for enterprises to bet their critical infrastructure on it?

The timing acquired an extra layer of awkwardness on Friday, when 73 Microsoft-owned GitHub repositories — including the Actions used to deploy Azure Functions — were disabled in a Miasma worm attack, breaking CI/CD pipelines for developers globally.

None of this necessarily undermines the strategic case for moving to GitHub. The AI development ecosystem is consolidating there, and the migration tooling is getting meaningfully better. But for enterprise teams weighing the decision, reliability and security aren’t footnotes — they are the main criteria. Microsoft is betting that access to Copilot and agentic workflows is compelling enough to tip the balance.

It may well be right, but a 30-minute cutover window is only part of what it will take to make that argument stick.

The post Microsoft’s pitch to enterprises: Ditch Azure Repos for GitHub, despite its rocky reliability record appeared first on The New Stack.

AI retrieval has moved well beyond embeddings and vector search. Early retrieval architectures focused primarily on semantic similarity. Still, production AI applications increasingly demand more from the retrieval layer: combining keyword matching, semantic retrieval, ranking, and real-time signals within a single request path.

Vector databases solved an important problem by making semantic retrieval practical. But production AI systems increasingly require more than retrieval alone. Customer-facing applications such as search, recommendations, and RAG must retrieve, filter, and rank results in real time while serving large user populations under tight latency constraints. 

As systems evolve toward conversational, research-oriented, and agentic workflows, retrieval performance, ranking quality, and architectural simplicity become increasingly important to maintaining relevance at scale.

In recently published research commissioned by Vespa, GigaOm explores how AI search platforms are evolving as organizations move beyond standalone vector search toward more integrated retrieval and ranking architectures. Rather than focusing purely on model quality, the report examines the operational and architectural trade-offs that emerge as AI workloads move into production.

GigaOm’s findings

AI retrieval architectures have become more fragmented over time. What begins as a straightforward search stack often evolves into a collection of loosely coupled systems: lexical search, vector retrieval, feature serving, reranking, synchronization pipelines, and model infrastructure. 

“What begins as a straightforward search stack often evolves into a collection of loosely coupled systems.”

GigaOm’s view is that the operational overhead of connecting and maintaining these layers is becoming a limiting factor in itself, slowing iteration cycles and making every relevance improvement dependent on coordinated changes across multiple systems.

One of the more interesting findings in the report is that consolidation is not framed primarily as a procurement exercise but as an engineering and systems design decision. GigaOm argues that teams increasingly pay for fragmentation through duplicated data movement, synchronization logic, operational maintenance, and cross-system tuning. 

The hidden cost is not simply infrastructure spend but the engineering effort required to keep retrieval pipelines aligned, rather than improving ranking quality, personalization, and user-facing AI capabilities.

“The hidden cost is not simply infrastructure spend but the engineering effort required to keep retrieval pipelines aligned.”

The report also suggests that platform convergence matters because modern retrieval workloads increasingly combine keyword search, vector retrieval, real-time features, and ML-based ranking in the same request path. 

GigaOm highlights architectures that bring these stages closer together to reduce latency, improve data freshness, and simplify experimentation, while acknowledging trade-offs such as concentration risk and migration complexity. 

Rather than recommending wholesale replacement, the report advocates a phased adoption approach, beginning with ranking and validation on production workloads before progressively consolidating retrieval capabilities.

Download a copy of the report.

The post AI retrieval at scale is becoming a systems problem, not a tooling problem appeared first on The New Stack.

The press release version of Automation Anywhere‘s EnterpriseClaw announcement is straightforward enough: a new capability for deploying what the company calls “claw-style” AI agents.

These are autonomous agents that can access device file systems, create tools at runtime, and interact directly with applications across enterprise infrastructure, backed by partnerships with Cisco, Nvidia, Okta, and OpenAI. It offers better security, Nvidia is contributing OpenShell, Okta will offer identity management, and OpenAI will allow companies to use the all-new GPT 5.5 within EnterpriseClaw

The more interesting story is what EnterpriseClaw, introduced last week at the company’s Imagine 2026 event, reveals about the gap between how AI agents are being built and how enterprises operate.

A “claw-style” agent

Adi Kuruganti, Automation Anywhere’s Chief AI and Development Officer, is candid about where the idea came from. Nvidia’s OpenShell — an open source runtime for autonomous, self-evolving agents that could essentially allow agents to replicate anything a human operator could do at a keyboard. That combination of capabilities is what Automation Anywhere is calling a “claw-style” agent, a term the company coined.

EnterpriseClaw is essentially OpenShell’s capability wrapped in centralized governance, he says. A “claw-style” agent differs from a traditional agent in three ways: Device-level access (local or shared), dynamic tool creation at runtime, and interaction with the computer screen.

The problem, Kuruganti says, is that OpenShell “could access pretty much everything, which is not a good thing in enterprise settings.”

For individual users or isolated cloud environments, broad system access is a feature. For a healthcare system, a bank, or a manufacturer running processes in air-gapped data centers, it could lead to a governance failure.

EnterpriseClaw is Automation Anywhere’s answer. It takes the autonomy model, adds centralized governance, credential controls, observability, and the ability to run agents close to where data lives. That includes environments behind firewalls and those that will never touch a public cloud.

An industry-wide identity crisis

Of the four partner integrations, the most telling may be Okta’s. Kuruganti tells The New Stack that agent identity, which involves how an autonomous agent authenticates to enterprise systems, what access it gets, and how its actions are audited separately from the humans it works on behalf of, is still a work in progress across the industry.

The current state is awkward, he says. Most enterprises are still handing agents human credentials to access systems like Salesforce or SAP. That means when an agent executes a process autonomously, the audit trail shows a human did it.

“There’s no clear record of what the agent did versus the human,” Kuruganti says.

Okta’s “first-class identity” model — where each agent has its own identity, access scope, and audit trail — is the proposed fix, and the company is working to establish it as a cross-vendor standard, not just an Automation Anywhere integration. That work is ongoing.

The hybrid reality

Kuruganti notes that almost everyone is building for the cloud, but enterprise data is not there yet.

“Most of the agent platforms out there are really thinking all in on cloud only,” he says. “The reality is most of the data doesn’t live in the cloud.”

For large enterprises in healthcare, financial services, and manufacturing — which Kuruganti identifies as Automation Anywhere’s three core customer industries — data lives on-premises, in private cloud VPCs, and in some cases in air-gapped environments where cloud connectivity is not an option.

That’s the architectural bet EnterpriseClaw is making: that the customers who matter most for enterprise automation aren’t the ones who have moved everything to the cloud, but the ones who haven’t and won’t anytime soon, Kuruganti says.

Nvidia’s role in the partnership reflects this directly — Nemotron models running on-premises via OpenShell exist for the customer whose bare-metal data center has no path to a cloud inference endpoint, he adds.

The orchestration play

How Automation Anywhere positions EnterpriseClaw and the company’s orchestration capabilities against ServiceNow, Microsoft, and others is also worth examining. Kuruganti’s positioning of the company as “the Switzerland of business process orchestration” is a jab at platform-centric competitors.

His argument is that ServiceNow automates within ServiceNow’s ecosystem; Microsoft automates within Microsoft’s. Automation Anywhere’s Mozart Orchestrator, by contrast, is designed to manage agents built on any platform, including competitors’, under a single governance layer.

That is the company’s value proposition. Whether customers experience it that way is a separate issue. But the proliferation of agentic platforms is creating a new orchestration problem and requires a multi-platform agent governance solution.

Where it stands

EnterpriseClaw is in preview, available to Automation Anywhere customers now under existing consumption pricing. A formal GA with dedicated packaging is expected later this year. The company says the preview designation isn’t a technical limitation — production deployments are happening — but a commercial one: they haven’t finalized how they want to price it.

At Imagine, Automation Anywhere also announced Autonomous IT and Autonomous Finance — prebuilt solutions that combine AI agents, process intelligence, and governance controls for the CIO and CFO’s offices. Both are available now.

The post Claw-style AI agents are coming to the enterprise. The governance infrastructure is still catching up. appeared first on The New Stack.