DeepSeek's recent decision to drastically cut pricing on its V4-Pro model by 75% should have been unequivocally good news for enterprise AI vendors and developers. Instead, many are discovering that cheaper models don’t automatically translate into healthier margins.

The reason is simple: While inference costs plummet, agent systems are voraciously consuming tokens faster than prices are declining. For the last 2 decades, software economics was dictated by the same rule. Infra became cheaper every year whereas applications became more capable. AI was initially hypothesized to follow the same pattern. As frontier models improved and token prices dropped, many assumed inference would become a negligible operating expense.That assumption has begun crumbling exponentially. 

A chatbot usually turns one user question into one model call. An agent turns it into a chain of planning, retrieval, tool use, verification, summarization, and follow-up decisions. The user sees one answer. The vendor pays for the loop. That is the 100x problem: The same user-visible request can cost a lot  more to serve as an agentic workflow than as a chatbot or retrieval-augmented generation (RAG) response. In longer-running workflows, the multiplier is higher. Falling model prices help, but they do not fix a product architecture that turns one prompt into dozens of billable operations.

The scale of what is now at stake is clear in how model providers themselves are pricing developer relationships. OpenAI's proposed program to give every Y Combinator startup $2 million in API credits — a number that would have funded an entire seed round in any prior tech cycle, and when the same cohort got by on a few thousand dollars of AWS credits — is less a recruiting perk than an admission of what it now costs to run an AI-native company through its first year of product. For established enterprises retrofitting agents into existing product lines, the absolute numbers are larger still.

What token amplification is

In a single-turn chatbot, one user message produces roughly one model call. Input-to-billed ratio is about 1:5.

In a multi-step agent rolled out across customer support, sales operations, finance, legal review, and engineering, that ratio routinely lands at 1:700 or higher. Every loop iteration carries forward the cumulative conversation, tool outputs, and reasoning traces. Each step appends; nothing is dropped.

A "simple" agent query like “What did our top customer ask about last week?” typically touches seven priced operations before returning an answer:

1. User prompt (~50 tokens)

2. System prompt and tool definitions (~3,000 tokens, repeated on every call)

3. Retrieval (~5,000 tokens of context)

4. Model call #1 — tool selection (8,000 in / 200 out)

5. Tool execution (~4,000 tokens returned)

6. Model call #2 — summarization (12,000 in / 400 out)

7. Model call #3 — follow-up decision (12,400 in / 100 out)

One sentence in, roughly 35,000 input tokens billed. Somewhere between $0.10 and $0.40 per query on a frontier model. Multiply that by a million queries a month — the table-stakes volume for any enterprise B2B feature — and the line item is six figures.

Why this breaks the existing AI business model

The dominant pricing story for enterprise AI has been seat-based SaaS: Pay per-user per-month, deliver agent capability, capture margin. That model assumes a reasonably bounded cost-per-user.

Token amplification breaks the assumption. A power user running 50 agent invocations a day on a $40/seat plan can cost more in inference than the plan charges. Token amplification shatters the traditional SaaS pricing model. When a power user’s daily agent activity costs more in inference than their monthly subscription fee, vendor gross margins turn negative, a paradox that compounds as customers deepen their agent adoption, the very usage curve vendors are selling to their boards. Several vendors are now privately reporting negative gross margins on heavy users, mirroring recent cloud expenditure reports from the Bessemer 'Supernova' cohort, where the correlation between AI-agent adoption and gross margin contraction has moved from a theoretical risk to a primary P&L headwind.

The visible symptoms have started leaking into public coverage. Bloomberg this week documented a widening gap between Salesforce's Agentforce marketing demos and the capabilities actually shipping to customers. This is the kind of gap that opens predictably when promised functionality is technically possible but uneconomical to serve at the price the seat plan implies. Salesforce is the most-watched case, not a unique one.

"For my team, the cost of compute is far beyond the costs of the employees." — Bryan Catanzaro, VP of Applied Deep Learning, Nvidia

The strategic implication is not "AI is expensive." It is that the dominant business model assumed by most AI-native company plans does not survive contact with agentic workloads.

A simple example

Consider an enterprise software vendor charging $40 per-user per-month for an AI-enabled support assistant. A traditional chatbot might cost only a few cents per user per day in inference, leaving healthy gross margins.

Now replace that chatbot with a fully agentic workflow capable of investigating tickets, querying internal systems, drafting responses, validating outputs, and escalating exceptions. If a heavy user executes 50 to 100 agent requests per day, inference consumption can increase by an order of magnitude. What was once a negligible infrastructure cost becomes a material operating expense.

This creates an unusual dynamic: The customers receiving the most value from the product are often the customers generating the highest inference costs. In extreme cases, vendors can find themselves with their most engaged users contributing the least profit. The result is a growing realization across enterprise software that agent adoption and margin expansion are no longer automatically aligned.

Agent orchestration is the new moat

The technical responses are known and converging. They are not novel, but they are critical for survival

• Cost-aware routing: This technique involves a small classifier model that decides which tier (Haiku, Sonnet, Opus equivalents) handles each query. Well-tuned routers cut inference bills by around 60% without any degradation in quality

• Prompt caching: Anthropic, OpenAI, and Google now offer 75 to 90% discounts on cached prefixes. 

• Context discipline: You can truncate tool outputs, prune reasoning traces, and cap tool depth to prevent your agent from going down a rabbit hole

• Speculative decoding: for self-hosted deployments, this technique guarantees 2 to 3X effective throughput on the same GPUs.

"Organizations using orchestration-led governance report stronger productivity gains — a holistic orchestration layer is associated with six times greater productivity impact than compliance‑only approaches" — IBM

The companies building this layer well are starting to look less like microservice operators and more like financial trading systems: Every routing decision priced, every path with its own P&L, every tenant on a metered budget.

What enterprise leaders should actually do

Four moves separate the companies that will still have margin in 24 months from the ones that won't:

1. Make inference cost a first-class metric. Track it per-feature, per-tenant, per-query class the same way cloud cost was tracked starting in the mid-2010s.

2. Budget like a media buyer. Set cost-per-thousand-queries ceilings per feature. Cap them. Alert on overruns. Engineering will not enforce this on its own.

3. Treat the router as core infrastructure, not an optimization. It is the new load balancer.

4. Audit prompts quarterly. A 4,000-token system prompt that grew organically over six months is a six-figure bill in slow motion. Most teams have never read their own production prompts end to end.

5. Negotiate volume commits early. Frontier-model vendors now offer reserved-instance-style prepaid commits at substantial discounts. List price is the worst price any enterprise will ever pay.

The next 24 months

The structural shift underneath agentic AI is not that it is expensive. As DeepSeek's price cut today underscores, frontier inference unit costs are dropping roughly 3X per year, and the curve is not slowing.

The shift is that amplification is outrunning the price cuts. Cutting per-token costs 75% does not help a company whose agents are doing 700X more tokens per user query than its pricing model assumed. For the first time since the cloud era began, architecture decisions are again financial decisions in real time. A prompt redesign is a margin event. A poorly bound agent loop is an outage with a credit card attached.

The companies that survive the next 24 months of AI infrastructure pricing will not be the ones running the cheapest model. They will be the ones whose agents are smart and know what they cost to think.

That is the 100X problem. And it is arriving faster than the price cuts can hide it.

Maitreyi Chatterjee is a senior software engineer at a big tech company.

Devansh Agarwal works as an ML engineer at a leading tech company.

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.

The most serious test to date of open source AI’s viability is happening right now. I’ve seen many waves of anti open-source AI rhetoric come and go since ChatGPT was launched, but none of them had obvious analogues in their potential enforcement to real action already in place targeting the peer, closed models of the day. It is more real because new forms of regulation are being tested and implemented, with minimal oversight. I will be doing far more policy-facing writing than usual until this passes.

As of writing this, many sources are citing White House discussions on how to manage open models via a new executive order. There is no official information here, and it would likely impact a) Chinese-origin models and b) government uses only, but this is how the dominoes start to fall.

Open models lack the central economic champion to represent the potential downside of action against them. From recent coverage of the events surrounding model licensing agreements for Fable (and then GPT-5.6), more was said about what unfolded on June 9th:

At the meeting, the topic of how the program will deal with open-source AI models came up, according to a person familiar with the session. A representative from Reflection AI, a U.S.-based open-source model provider, argued that open-source models should have exemptions from the framework based on their capabilities, the person said. Currently, Chinese open-source models such as DeepSeek have a substantial lead over other available open models, and Reflection has not yet launched a public model.

A ban of any form here would be a big mistake for the long-term trajectory of AI.

The most likely incoming action is to ban or indefinitely delay any open-weights model meaningfully above the capability level in the range of GPT 5.5, Claude Opus 4.8, or GLM-5.2. With the consistent capability gap, this should be within the next 6 months.

As it stands, these would most likely be from a Chinese company, which is how this conversation of frontier open model capabilities inextricably becomes linked to other issues such as distillation. The capability threshold for a “right to review” from the government will shift over time, but once in place will likely progress far slower for open models rather than their closed counterparts. This is partially due to closed models being easier to secure but also due to the closed model companies having far more effective lobbying.

So, this leaves us in a place where there are two crucial policy discussions unfolding at once impacting open models – distillation & frontier capabilities. They’re very different in their nature, the necessity of response, and the potential response space. Still, together they represent the talking points of a surging platform of support for a potential ban of open models in the next 6 months.

The primary driver motivating regulation today is the inevitable truth that an open-weights model will soon reach the capabilities of Claude’s Mythos model. The actual performance of this openly released model will likely be more jagged, but all it takes is the model getting flagged in the nascent White House AI model checker. It’s hard to unwind new habits motivated by fear.

Share

The current distillation debates are regulatory capture and doing nothing for now is fine

Distillation is largely a regulatory capture campaign at this point, as the only solutions on the table massively benefit the organizations pushing for it.

To elaborate, the anti-Chinese models political campaign is led by Anthropic, where they are sharing a mix of blog posts and letters to representatives detailing what the Chinese companies are doing. Anthropic has detected use from foreign companies, which is people coming and paying for its API, and eventually turned off usage and then written strongly worded recommendations of policy action and shared minimal technical evidence. This campaign may have started through a genuine business concern, but it has progressed to be the definition of regulatory capture, as Anthropic would gain substantial economic security in its products if the Chinese model makers they accused were banned.

If Anthropic was presenting information in a more neutral “you decide what to do” way, the community would have a lot more sympathy. It is more of a policy recommendation than an information sharing exercise at the frontier of a rapidly evolving technology. If Anthropic’s technology is as powerful as they say it is – so powerful that open models like it should likely be banned – then they should be able to secure their API. I continue to wait for them to explain why they cannot. One of their statements would need to be walked back.

Anthropic is also pulling up the ladder for access to intelligence in other ways — so the political recommendations they make in the vein of China competition are consistent with a much broader pattern of restriction of access to competitors of related technology in the vein of safety. It is easy to buy into company culture like an extra safety focus when many employees are on track for generational wealth. I do not blame the employees for this, but Anthropic’s corporate strategy should be understood in these broad, contextual lenses. Ben Thompson’s piece, Anthropic’s Safety Superpower, is the best writing on the subject.

The action that Anthropic is effectively asking for is the wholesale banning of pretty much all the Chinese open weight models in the U.S. — as any products built around open models are predicated on their continued improvement, increasing product market fit and compute efficiency as models get better. This would demolish the open model economy that is emerging in the US with inference companies, fine tuning companies, new products, and everything in between. We as a community desperately need to hold the line that conceding anything with respect to the distillation conversation is not acceptable.

Anthropic should try to protect their IP, but they shouldn’t ask the government to cement their position and in the process potentially isolate the US from the global open-source community. There are no good solutions to distillation with the information we have, other than letting the labs self-enforce it.

I’ve written at length on distillation in particular. I’ve written directly on its impact on model capabilities and the regulatory environment, and you can search for more in between the lines mentions on Interconnects.

APIs aren’t magically secure

There’s a particular messiness to the distillation discussion, where there’s likely meaningful worry of Chinese labs distilling the narrow cybersecurity capabilities of Mythos into an open model. This paints more on the insecurity of current model APIs more than it does on the distillation risk. Even when Claude Mythos was in its most-limited private beta, Discord Sleuths Gained Unauthorized Access to Anthropic’s Mythos. To date, model APIs continue to be jailbroken and accessed in unintended ways.

This proliferates the risk of capabilities falling to bad actors far more rapidly than anything that involves complex fine-tuning of a 1T+ parameter model. I’m not a cybersecurity expert, but the dichotomy that only open-weight models are insecure and APIs are safe has been very overblown in recent years. APIs in concept should be able to be more secure, but that is yet to be demonstrated.

If Anthropic has a truly dangerous capability in their models, the only coherent action would be to not host it in a directly queryable API — before the discussion of it being distilled.

Ready or not, open models are coming

Where this becomes hard is that at the same time as these distillation questions, we’re staring down the barrel of “how do we handle frontier open weight models at the general capability level of Mythos?” This is a hard question, and it’s a natural human tendency to want to take a proposed solution to another problem (distillation) and apply it to the new, far more real problem (frontier capabilities).

We need to figure out the right policy for open frontier capabilities, but a flat out ban is likely not the answer. If the models are not banned in China as well, it is VERY easy for a bad actor to still use said banned open weight model, which negates the safety potential.

At the same time, if we alone ban the import of certain models, the global open-source community will continue. A world where the U.S. bans these models before China, or other more risk-sensitive cultures, would likely indicate that a form of AI fearmongering (or other social, political momentum) pushed the U.S. government to act early. It feels like speedrunning dystopia in the U.S., as our tech industry – the crown jewels of the economy – looks far more like a Chinese system with control and government investments. These are very bad outcomes!

The only way to add a ceiling on open-source progress is a global agreement on the management of risks of AI models, which we aren’t close to. Other delays make the AI rollout less predictable in the US and increasingly messy. It’ll feel a lot like the GPT-5.6 rollout, but instead of just limiting the upsides of open, cheaper intelligence to a few companies all the bad actors will immediately have access, too. Open models increase safety by broad access and understanding, not kneecapping the positive actors only.

In reality, there is no stopping the open-source ecosystem. The people building the best models are assessing risk as well, as China is very risk-sensitive and for example Z ai is already a public company exposed to a comprehensive set of pressures – keeping their rocketing stock up, for one. There will only continue to be more models that cross worrying levels of capabilities. Training AI models is not magic, and we haven’t seen access to building them drop off as the required investment has increased (yet).

One of the short-term off-ramps for this policy death spiral for open-source, a double-helix of related and complementary, scary issues, is for a company in the U.S. to release a similarly capable open model. This will shift the focus away from “only China is building the open models via distillation” to “we’re all in this together, and we should focus on the complex, moving frontier issues within our ecosystem.” This is an existential priority for open-source, and the companies who have the business reasons to release open-weight models like Microsoft and Meta (commoditizing their complements) should do it ASAP. I have less faith in Meta, with the new leadership, but they benefit from mass access to AI and should not get in their own way. If Reflection is sitting on an okay, but not frontier, model, they may need to release it to save their proposed business direction.

The shorter term solution than training a new model is to build the coalition. Open-source is a diffuse technology, without clear ownership, but the benefits will be shared by so many. This “everyone else” outside the frontier labs needs to start working today, on how to continue the safe rollout of open-weight models (and lobby for their principles and values) to the powers that be.

Rising temperatures in the AI discourse

Read more

Microsoft recently took the wraps off Brain, the internal AI system that continuously monitors Azure’s health and, increasingly, acts on what it finds — declaring outages, pausing harmful rollouts, and notifying affected customers.

Azure CTO Mark Russinovich first wrote about the system in a blog post, “Meet Brain: The AI system behind Azure reliability,” the first in a planned multi-part series about the Azure team’s reliability and resiliency tooling.

To dive deeper, The New Stack sat down with Russinovich, who is also Azure’s deputy CISO and a technical fellow, to talk about how the Brain project came to be and how it evolved over time.

Brain, as Microsoft describes it, is Azure’s centralized AIOps system for cloud health. It operates as an intelligent layer on top of Azure Resource Graph (ARG), and together, the company says, the two form a real-time digital twin of Azure’s health.

A real-time digital twin

While Brain today uses many AI tools, the project is actually much older than the generative AI boom, and to get started, the team had to build a solid foundation first. “At the heart of this system is Azure Resource Graph, which started as ‘let’s create a digital twin of Azure, so we can understand the relationship between the different resources in Azure,’” Russinovich tells The New Stack.

That internal digital twin became a public service at the urging of what Russinovich calls whale customers, those “that have huge estates across many different tenants and subscriptions that wanted to do easy queries across the whole thing, like, ‘What Linux VMs do I have, and what versions of Linux are they on?'”

It was actually the root cause analysis on top of that graph that Brain really began with. “Many times you can just trace dependencies and say, well, these services all depend on this other service that has gone unhealthy, and so that I think was the genesis of having Brain go and start to have a lot of ML-driven algorithms to identify root cause on top of the graph,” Russinovich explains.

Around the same time, Microsoft kept encountering a measurement gap: A service team’s own health metrics indicated everything was fine, but customers saw failures. Russinovich says that could happen because the Azure team wasn’t “measuring what customers are experiencing, or because they’re aggregating at scopes that hide customer-specific problems.”

So Microsoft decided to standardize. “We decided, let’s go standardize on the way that we measure health,” Russinovich says, “and we came up with service level indicators, SLIs.”

Getting services across Azure to actually emit them through shared libraries that conformed to the schema was a complex task that took several years.

“It’s kind of a whole bunch of different things that happened in parallel that all have come together,” he says. “There’s just a tremendous amount of data engineering that goes into this, and trying to keep it as automated as possible.”

Three signals feed Brain

In his blog post, Russinovich writes that Azure’s reliability challenge isn’t a lack of tooling but a “comprehension problem,” with a hyperscale cloud now producing more signal than humans can read.

Azure runs hundreds of services across more than 80 regions, 500+ data centers, and 800,000+ kilometers of fiber and subsea cable. And yet, he writes, Microsoft still sometimes learns about a quietly degrading service from a customer before its own systems detect it.

Today, Brain pulls from three classes of signals. The standardized SLIs come first. Service teams also build and register their own domain-specific monitors, which run alongside telemetry-like deployments, support volume, and cross-service dependency signals. Third-party indicators make up the rest.

Brain produces the same four outputs for any subject, whether that’s a service, a region, a deployment unit, or a customer’s resources.

Based on this, Brain produces the same four outputs for any subject, whether that’s a service, a region, a deployment unit, or a customer’s resources. It reports the health state, how severe the issue is, who is impacted, and — crucially — why it reached that conclusion.

Those conclusions then drive alerts and remediations. Brain declares outages based on blast radius, Russinovich notes, and scopes customer notifications to the impacted subscriptions and regions. The system automatically routes incidents to the appropriate service team and sends deployment-gate signals to pause rollouts causing the issues.

Russinovich says the system is “very pluggable in terms of what signals go into it, and includes even things like customer support tickets that have been opened, and social media posts that mention Azure.” He says Brain is “primarily monitoring,” but “it also can take automated repair actions, too. So for some incidents, teams can specify if, when this happens, go try these things, and Brain kicks those off as well.”

He says the SLIs are “emitted at the scale unit level, so that we can do aggregations for overall health. We can pinpoint specific customers that are being impacted, because we know what customers map to which scale units, and that’s the way that the auto notification triggers off that.”

Why ML sets the thresholds

Microsoft’s original plan for turning SLIs into health determinations was the textbook one, asking every service team to define its own SLOs. It didn’t work.

Russinovich says the schema work itself was hard enough, but “even more challenging is coming up with an SLO that is actually a good SLO.” Teams sandbagged their thresholds, he says.

“[Everyone] wants to be very conservative because they don’t want to get paged or have customers told that things are unhealthy when they’re not, so they’re like, ‘You know what, my SLO is 5% of API queries can fail, and then let’s call it unhealthy,’ when actually that’s not a good way to determine health or regressions as rollouts happen, so we decided, ‘Let’s just stop asking them to define their SLOs.'”

“Everyone wants to be very conservative because they don’t want to get paged… so we decided, ‘Let’s just stop asking them to define their SLOs.'”

Instead, ML models now derive the thresholds from each service’s own behavior, per scale unit and per region.

“There’s a baseline for behavior of the service in this region versus that region,” Russinovich says, “and then we can see when there’s regressions.” The resulting SLOs are dynamically adjustable and automated, he explains.

Tying a regression back to the change that caused it is harder still, he says. Brain tracks rollouts of service updates, and “we’ve got ML algorithms too that can identify with confidence this rollout is causing a regression.” But, he says, the rollout that just reached a scale unit isn’t necessarily the culprit.

“A change doesn’t necessarily show up as a regression immediately. It can have latency; it can take hours to show up, or in some cases even days… there can be many, many deployments that have happened over the last day, and you’re like, which one was it?” That’s why, he says, “there’s a lot of ML going into symptom versus change mapping and automated detection.”

Agents that fix outages

The published post keeps its results vague. Detection precision “has improved significantly”; a “substantial majority” of Brain-integrated outages were auto-communicated to customers in the past year; and time-to-notification improved “materially” over manual notifications. In the interview, Russinovich puts numbers on some of it.

He says, “The thing that frustrates customers the most is when they’ve got to call us and tell us there’s an issue, because then they’re like, you guys don’t even know that there’s a problem. I have to tell you there’s a problem. If we can tell them, hey, there’s a problem, we know about it.” Auto-notification, he says, has driven “this reduction of like four to 6x in terms of customer support tickets open, because Brain is automatically notifying them, and they know that we’re on it.”

“The second you put a human in that loop, you can blow right past the 15 minutes.”

“Our time-to-mitigate goal is 15 minutes, from some problem to actually being resolved within 15 minutes,” Russinovich says. “The second you put a human in that loop, you can blow right past the 15 minutes.”

According to Russinovich, the company hits this 15-minute notification window for 80 to 90 percent of the services on Brain. Often, it’s also much shorter and closer to five minutes.

One caveat here is that not everything runs through Brain yet. Microsoft prioritized what it calls its critical services, the foundation the rest of Azure depends on, and Russinovich puts their coverage at “like 70 or 80% of them, and then the tail’s being worked on.”

He notes the rest aren’t flying blind. “It’s not like the services that aren’t on Brain don’t have health systems and alerting and everything. Brain improves things, even for those services.”

For the engineers who do get paged, Brain assembles the picture they used to piece together by hand.

“The incident gets populated initially with an automated collection of information that will say, here’s the graphs of availability on this SLI over these scale units over the last 24 hours, here’s the list of impacted customers, this is the scale unit, here’s the other information supporting this, and so already there you’re saving the engineer huge amounts of time just in going and information gathering and just presenting it right in front of them.”

Agents on top

In the Brain announcement, Russinovich writes that “agents need something to be agentic about.” A triage agent that doesn’t know the dependency graph can’t triage anything, he argues, and the health model is “the prerequisite, not the consequence, of agentic operations at this scale.”

At this point, Microsoft has started running agents on top of Brain. A system called Triangle, which Microsoft Research also described in a 2025 paper, gives each service team an LLM-based agent trained on its historical incidents and troubleshooting guides, with an orchestrator that routes ambiguous incidents among them.

“This Triangle system has agentic representatives for the services, where the Triangle orchestrator then fans it out and says, ‘Here’s the incident; raise your hand if you think it’s yours,’” Russinovich says. Without it, tickets would bounce from team to team — something Microsoft calls handoffs — which increases response times.

“We don’t have to write down every single rule prescriptively… let the agent do things based on its own judgment.”

It’s still early days for Triangle, though. “We’re still relatively early, so there’s only a small number of services onboarded to it, but already for them the handoffs are much faster and more direct than pre-Brain,” Russinovich says.

In the long term, he wants agents to replace the deterministic remediation rules that teams write today.

“We don’t have to write down every single rule prescriptively,” he says. “And have this tree of decision making, but rather let the agent do things based on its own judgment, which has a whole bunch of benefits, like the system keeps up to date automatically. Then it can also find paths to resolution that we might miss in the deterministic rules that we’ve got.” On agents that actually fix things, he says, “We still consider ourselves at the beginning of that.”

The post Meet Brain, the AI that decides when Azure is officially down appeared first on The New Stack.