Microsoft is turning Fabric, its integrated data platform, into the place enterprise agents go to learn how a company works, whether that’s what happened last quarter or what’s happening on the factory floor right now.

On Tuesday, at its FabCon and SQLCon data conference in Barcelona, Spain, Microsoft outlined the next step in its vision for how the products that make up Fabric can simplify all of this information gathering.

Microsoft, for example, described how Fabric IQ, the context layer inside Fabric, now feeds Microsoft 365 Copilot by default. Outside agents can query it over MCP. Power BI will soon be able to turn the same definitions into apps. And ontologies, which add business rules to the mix, moved further into preview.

As Microsoft Fabric CTO Amir Netz said in a press briefing after the keynote, “Agents are a very, very strange animal, and I always like to say it’s like Drew Barrymore from 50 First Dates. Every time they open their eyes, they forget everything that happened before.

“They don’t know where they are, so the first thing we have to do is tell them where they are. You are now working for Microsoft. You are now working for Wells Fargo. You are now working for Emirates.”

“Agents are a very, very strange animal, and I always like to say it’s like Drew Barrymore from 50 First Dates. Every time they open their eyes, they forget everything that happened before.”

Customers tend to find this out the hard way. Yitzhak Kesselman, the corporate vice president who runs Fabric IQ, tells The New Stack that companies unify their data, run models on it, and then look at the answers.

“Customers that are more advanced on their journey have their own evals for their agent,” he says, adding that what they see sometimes isn’t what they expected. “Then [customers] will understand: ‘Okay, now I need to create the context for my agents.'”

Kesselman says he met with more than 320 companies last year, and the pressure to get there comes from the business side, which asks to “‘show me the value of those agents,'” he says, “‘the before and after.'”

Arun Ulag, Microsoft’s executive vice president for Azure Data, said in the keynote that coding agents work because they have “the code, the repos, the change history, the specs, the tests.” But outside of coding, most enterprises have nothing comparable, he argued.

Fabric IQ is one of four pieces of what Microsoft calls Microsoft IQ (this is Microsoft, after all, so there’s always a lot of different names and products involved).

Work IQ covers email, Teams, and SharePoint. Foundry IQ covers documents and manuals. Web IQ covers the public internet.

Fabric IQ, Ulag said, “focuses on the state of your business and how your business actually runs.” His announcement blog post describes it as combining “unified data from OneLake, trusted metrics from Power BI semantic models, and operational context from ontologies and real-time intelligence.”

Getting the data in

“Everyone wants to jump to AI, but then they realize, ‘Oh, I need data for it,'” Kesselman says. “They need data from their business applications, their structured data. They need to have real-time data.”

OneLake, Fabric’s storage layer, is at the core of all of this, and for the system to provide context, enterprises have to feed it data from across all the first-party and third-party services they use.

Fabric’s shortcuts and mirroring, which connect or replicate external sources into OneLake, are free of charge, and Netz said storage under management in OneLake is growing 300% year over year.

What’s new this week at FabCon and SQLCon Barcelona 2026

On Tuesday, the company announced a two-way integration with Salesforce Data Cloud 360, mirroring from Google BigQuery in general availability, a ClickHouse workload that runs that engine directly against OneLake, and dbt’s Fusion engine, due in Fabric in the next couple of weeks.

Simply copying data won’t satisfy security teams, though. Mirrored security roles, which reach public preview in the coming weeks, bring permissions along with the data. Access roles defined in Snowflake, for example, will show up in Fabric with the same members and the same table permissions.

As Microsoft’s Shireen Bahadur, who demonstrated the feature in the keynote, put it, “We’re not just solely replicating security rules. We’re actually actively enforcing and preserving those roles.”

“We’re not just solely replicating security rules. We’re actually actively enforcing and preserving those roles.”

OneLake isn’t a one-way street. Enterprises can also pull data out and use it in other tools.

OneLake data, after all, is stored in open formats and has open APIs, and Netz said on stage that any engine that reads them can use it. “If you want to use this data that we help people to get for free with our competitors’ tools, go for it. I’m not happy about it, but go for it,” he said.

IQ sharing, now in preview, lets an organization share governed tables, files, Markdown agent instructions, and RDF ontologies with another tenant without copying, with an expiration date. That’s something Fabric users have wanted for a while, and the keynote announcement drew plenty of applause from the thousands of data professionals in attendance.

Past, present, and future

“Not only what we have in the past, not only what’s happening in the present. We also want the agents to understand what we want to happen in the future,” Netz said in the keynote.

The past is semantic models. A semantic model is the layer under every Power BI report that defines how a metric like revenue is calculated, how entities relate, and which tables supply the numbers. Netz said Power BI users have already created 22 million, and Ulag called them “the core of Fabric IQ.”

The present is real-time intelligence, Fabric’s streaming and event stack, which Kesselman also runs. He recalls two CIOs telling him the same thing that day in Paris. “‘There is no AI without RTI;’ there’s no AI without real-time intelligence,” he says. “If you don’t have the streaming data… data that is fresh, you will run your LLMs on data which is like hours or days old.”

“‘There is no AI without RTI;’ there’s no AI without real-time intelligence.”

A signal on its own isn’t enough, though: “You want to take the signal that you get now… the event that comes now, and look historically, okay, is it an anomaly or not?” Kesselman says. That’s why the keynote showed batch copy jobs and event streams feeding each other, so an agent can judge what just happened against what usually happens.

The future is Fabric Planning, which went generally available in July and got a performance and feature update this week. It’s Microsoft’s tool for budgets, forecasts, and targets, the numbers a business wants to hit rather than the ones it has already recorded.

A plan is a Fabric item like a lakehouse or a notebook, and it borrows its measures from the same semantic models the reports use, so revenue means the same thing in the forecast as it does in the dashboard. In the demo, a change to the inputs cascaded through a model of about 13 million cells.

What makes these work is ontologies: Formal descriptions of the things a business deals with, how they relate, and the rules for handling them. Netz called them “semantic models plus plus” on stage, and in a later press briefing, he used an airline to explain the plus.

“If you are an airline, you have planes, you have pilots, you have ground crews, you have airports, you have luggage,” he said. Those are the entities.

The relationships between them “are way more than data relationships,” he said. “It’s not only to say, ‘Oh, I have a match with a foreign key and a primary key between a pilot and a plane,’ but it could be a policy relationship. Which pilot can fly which plane based on their certification, or is the pilot allowed to fly this plane right now based on the rest hours in the last 24 hours?”

But ontologies don’t only define nouns; they also define verbs. “I can ground a plane. I can redirect the plane. I can assign a plane a gate.”

Creating those ontologies, which have to map the various terms that a company might use for the same thing to a single entity, can be extremely time-consuming. But since they are so core to this project, and to allowing agents to reason over data, Microsoft built a tool to generate them automatically.

Putting it to work

Fabric IQ in Microsoft 365 Copilot Chat and Cowork, the mode for delegating multistep tasks that Microsoft built on the technology behind Anthropic’s Claude Cowork, is generally available as of Tuesday. It answers business questions from Power BI semantic models and reports; it’s on by default for Fabric and Power BI customers, and Microsoft says it doesn’t consume additional AI tokens.

But business users don’t just want to chat with these models. In this age of vibecoding, they also want to generate applications that use all of this data.

Power BI Desktop is getting an app-creation experience in preview in the coming weeks. Users start from a semantic model, describe the app, and then have Copilot generate and publish it to Fabric.

Unlike with a report, Ulag wrote, these apps “can accept inputs, write back data, preserve shared state, and support operational workflows.”

They’re Fabric Apps built on Rayfin, the open-source SDK Microsoft introduced at Build. Power BI Pro and Premium Per User customers get them with a Fabric database of up to 1GB per app at no additional cost.

Netz confirmed in the briefing that “there’s no core difference” between the two, and Ulag added, “What gets created is a Fabric app, right? And that’s it.”

For agents outside Copilot, Fabric IQ MCP is generally available now, with six read-only tools for finding semantic models and reports, reading their schemas, and running DAX queries against them.

Ontology MCP tools, currently in preview, expose ontology definitions and queries. Fabric data agents can now, also in preview, use an ontology as their context source. And the context reaches Microsoft Foundry, Copilot Studio, and GitHub Copilot through the same layer.

Developers can drive the new data engineering agent from their own tools.

Built on the Osmos technology Microsoft acquired in January, it takes on long-running work like migrations and ETL, and can be started and steered from GitHub Copilot, VS Code, Codex, and Claude Code.

Frontier models will write that code, Netz said on stage, and “it won’t fail,” but you don’t know whether the results are right.

Everyone has a context layer now

This year, Databricks shipped Genie Ontology, Snowflake shipped a Horizon Context Layer, Google shipped a Knowledge Catalog, and Salesforce shipped a headless Data 360, which it describes as a context service. Databricks CEO Ali Ghodsi summed up the pitch at his own conference in June as AI having a context problem rather than an intelligence problem.

Microsoft’s version turns on by default inside Microsoft 365 Copilot and starts from 22 million semantic models. Microsoft also said this week it will contribute to Apache Ossie, the vendor-neutral semantic metadata standard Snowflake started, and that it wants DAX, Power BI’s formula language, recognized as an Ossie query language.

When Microsoft made the context argument at Build in June, the pieces that let an agent act on that context were mostly on a roadmap. Now the answers are generally available, and the actions are in preview.

Asked how Fabric copes when the user is no longer one person running a dashboard but a fleet of agents, Kesselman points to observability.

“Fabric really allows you to have this kind of holy grail of combination of both kinds of system data, how the agent runs, but also the business data,” he says, so a company can check whether an agent did what it was supposed to do and what that did to the business. “There’s more in this area that will come in the next few months.”

The post Microsoft Fabric is where AI agents learn how the business works appeared first on The New Stack.

Databricks on Tuesday announced that it’s acquiring Electric, the startup behind the WASM-based Postgres project PGlite and the Electric sync engine, as agentic applications change how developers use databases.

The Electric team will join Neon, the serverless Postgres company Databricks acquired for about $1 billion last year and the foundation of its Lakebase database service.

The companies didn’t disclose the terms of the deal.

What Databricks bought

PGlite is a complete Postgres database in WebAssembly (WASM). It runs in the browser, a Node.js process, or inside the kind of sandboxes agents use to execute code. It supports dynamic extension loading, including pgvector, the preferred Postgres vector extension.

According to the companies, PGlite has grown from 1 million to 13 million weekly downloads over the last year.

The sync engine at the core of Electric

It’s the Electric sync engine that is core to Databrick’s interest in Electric, though. This engine keeps a central Postgres database that can then be synced in near real-time with browser tabs, mobile apps, or agents. As Databricks notes, this is the multiplayer model of Figma or Google Docs, but applied to Postgres and the agents that use it.

The Neon team, in its own announcement, notes that “complex problems like conflict resolution, partial replication, and reconnection logic make real-time sync difficult to build from scratch.” Hence why Databricks likely acquired Electric instead of trying to build this from scratch itself.

As for the future of Electric, the company’s founders James Arthur and Valter Balegas write that “everything we’ve previously open sourced stays open source.” This covers the sync engine, PGlite, Durable Streams, and TanStack DB.

What doesn’t survive the deal, however, is Electric’s hosted service. “Electric Cloud is winding down,” the founders. “Cloud users will need to self-host or move to another provider.”

The deal also extends a string of database acquisitions for Databricks that includes Neon itself and, more recently, the transactional processing startup Mooncake.

A database that lives for 10 seconds

As the Databricks team argues, traditional non-agentic applications share one database among many clients, and that database is the most permanent piece of the stack. But agent workloads change this.

In a recent post on how agentic development changes databases, Databricks’ Ippokratis Pandis, Nikita Shamgunov, and Reynold Xin write that agents now create roughly four times more databases than human users do on Lakebase. They also stress that the average project now carries about 10 database branches, and that some projects run more than 500 branch iterations deep.

For some types of applications on Lakebase, the average database compute is now alive for under 10 seconds.

Agents, as it turns out, like to branch databases the way they branch code, a pattern Neon built its architecture around.

In practice, a coding agent spins up a sandbox, instantiates PGlite inside it, builds and tests against the database, and then either throws the whole thing away or syncs the result with — in the Databricks context — a Lakebase branch. Because Lakebase separates storage from compute and keeps its data in Postgres page formats on object storage, creating that branch is a relatively cheap copy-on-write metadata operation.

“As coding agents drive the cost of creation to zero,” the Neon team writes, “the number of applications explodes, and most of them are small.” A database server, even a serverless one that scales to zero, imposes a floor on what the smallest viable app costs to run. “You can’t have an age of abundance if every app requires a fixed minimum of compute,” the post argues.

‘Two halves of the same idea’

It’s worth noting that PGlite didn’t start at Electric. Instead, it began as an experiment by Neon co-founder Stas Kelvich, who compiled Postgres to WASM to see whether it could run client-side. Electric picked the work up and turned it into a production project. “That repo became the basis of PGlite,” Arthur and Balegas write.

As Databricks’ announcement notes, this now “reunites two halves of the same idea.”

The post Databricks acquires Electric to give every AI agent its own Postgres database appeared first on The New Stack.

AI agents can impress in a demo and still fumble in production. Diagrid’s Catalyst 2.0 aims to make them more resilient — and their actions tamper-evident — for high-stakes work.

With the launch of Catalyst 2.0, Diagrid on Tuesday has added a durable execution and attestation layer to agents built with LangGraph, Microsoft Agent Framework, Google’s Agent Development Kit, OpenAI Agents SDK, and other popular frameworks.

The point here, the company notes, isn’t to get developers to adopt yet another agent framework. Instead, Catalyst runs underneath the existing frameworks and turns the agent’s model calls, tool calls, and handoffs into steps in a durable workflow. Diagrid says this allows an agent to resume from its last completed step when it’s interrupted, without having to repeat the entire run from step one.

“If the agent gets a prompt and it chooses to run 100 tools for the job and it fails at the 99th, it really needs to start back up from 99,” Diagrid co-founder and CTO Yaron Schneider tells The New Stack.

Picking back up at tool call 99

Catalyst is built on the open source Distributed Application Runtime (Dapr), which the Diagrid team helped build at Microsoft, and its built-in workflow engine. For each supported agent framework, Diagrid provides a runner that intercepts the framework’s execution loop and registers its operations as workflow activities.

“We hooked into their agent runner lifecycle, and we’re essentially able to take the agentic steps that are being executed in real time and register them as workflow steps for our workflow engine in Catalyst,” Schneider says.

In a LangGraph application, for example, a developer compiles the graph as usual and passes it to Diagrid’s DaprWorkflowGraphRunner. Catalyst records the inputs and outputs of the model and tool calls. Dapr’s workflow runtime can then replay the orchestration after a crash, while returning the stored results of completed activities instead of executing them again.

It’s worth noting that for LangGraph users, this isn’t the first form of durable execution. LangGraph’s own persistence layer saves state at superstep boundaries and supports resuming from the last successful step. Its Agent Server also provides a durable task queue and persistent checkpoints.

Diagrid’s argument is that Catalyst provides the same execution model across more than 10 frameworks and extends it to individual model and tool calls, without requiring developers to build separate recovery logic for each framework. Schneider says LangGraph is “without a doubt, hands down” the most common framework among Diagrid’s customers, with AWS Strands and Microsoft Agent Framework also showing up. All the other supported frameworks, he says, are in the long tail but easy enough to support that it makes sense for Diagrid.

A signed record of the run

There is a second part to Catalyst 2.0, though, which may be just as important for many enterprise users. With this update, the tool now brings the workflow-history signing features introduced in Dapr 1.18 to the supported agent frameworks.

“We keep like a ledger, like a diary,” Schneider says. “We log the input, we log the output, we log which systems we talk to.”

He describes the result as an immutable store but also notes that Catalyst doesn’t turn an arbitrary database into a blockchain. It creates a signed history that should reveal later modification.

Dapr computes a SHA-256 digest over batches of workflow-history events, links each digest to the previous signature, and signs the result with the Dapr sidecar’s Secure Production Identity Framework for Everyone (SPIFFE) identity. It stores these signatures and certificates alongside the workflow history and verifies the chain whenever it loads the workflow state. If somebody were to modify, remove, or reorder a stored event, that verification chain breaks.

Schneider says Catalyst customers can use their own certificates and retain the encrypted history so it can be inspected even if they are no longer running Catalyst. The platform can use a customer-selected database, while the hash chain supplies the tamper evidence.

One part of the compliance problem

Diagrid is positioning that tamperproof record as useful for financial services, health care, and other regulated industries. CEO Mark Fussell says some of the financial executives the company has talked to see the lack of a verifiable record as a blocker for deploying agents in sensitive workflows.

The European Union’s AI Act is another reason Diagrid is making this argument now. Article 12 of the AI Act requires high-risk AI systems to support automatic event logging so operators can trace their behavior, identify risks, and monitor deployed systems, and a signed execution history could help with that requirement.

Fussell says Catalyst is meant to run alongside the agent services enterprises already use from the cloud providers. Teams can keep a provider’s identity, evaluation, and observability systems while using Catalyst for recovery and signed workflow history. Catalyst can run as a Diagrid-hosted service or in a customer’s environment, including air-gapped deployments.

Diagrid didn’t disclose pricing for the new release.

The post Diagrid gives failed AI agents a way to resume appeared first on The New Stack.

The models small enough to run on the box on your desk are getting good enough that the interesting question is no longer whether you can run them, but what you can do with them, and how organizations can get the most out of them.

Joey Conway, Nvidia’s senior director of generative AI software, spoke to The New Stack about how local and open models are increasingly working alongside frontier models, often with a router in between deciding which one to use, and how organizations can adapt these open models for their own needs.

“We love the world where we can use both frontier and open models together.” — Joey Conway, Nvidia

A system of models

Tasks vary in complexity, so the models handling them should vary too, Conway tells The New Stack. He points to the early open reasoning models, which would reason their way through trivial problems, mulling number lines and memory to work out what two plus two is. “I just say four,” he says.

“Being able to route those easy things to local models that are quick, and route the hard things to more sophisticated models,” Conway says, lets you “get a better outcome at a lower cost and lower time to completion.”

It’s a different picture from the one large model most people imagine doing everything. In his version, you build a bench of specialists. “You’ll have specialized agents that are really good at focused tasks because that’s what they do every day,” he says, “and they just get better and better at that task.”

To the user, none of that shows. “It’ll feel like one interface,” Conway says, “but behind that interface, there’ll be a variety of models handling a variety of tasks.”

Getting there is largely a routing problem, and one Conway says is still in its early days. Nvidia’s own contribution, for now, sits lower in the stack, in inference-serving software like its open-source Dynamo, which steers each query to the GPU that handled it most recently. Which model is best for which job, Nvidia leaves to a wider field of routers, some of them models in their own right that weigh budget, latency, and modality. But Conway also leaves the door open for Nvidia to build more of that routing itself before long.

Nvidia points to its collaboration with LangChain, whose Deep Agents harness ran on Nemotron 3 Ultra, Nvidia’s 550-billion-parameter open model, and matched top closed models on business tasks at up to a 10x lower cost, as Conway notes. It required no retraining; the gains came entirely from tuning the harness around it: its prompts, tool descriptions, and middleware.

You’re not going to run a 550-billion-parameter model on your desktop anytime soon, but running relatively large models locally is now a real possibility, as long as you have some beefy hardware at your disposal. For enterprises, setting up a fleet of accelerators in a data center isn’t exactly cheap either, but it does mean full control and no surprise token bills.

Bringing AI to where the data lives

Running models yourself can save money, but Conway thinks control matters more. Enterprises already decide where their data lives and what they hand to outside vendors, and open models give them even more control. “Move AI to where your data lives,” he says, “or move AI to where your employees are.”

Companies want to keep their data — and especially their intellectual property — in-house, and Conway argues a fine-tuned open model is the place to put it. “It’s like an employee,” he says. “You hire them, and they’re part of your company.”

The local half runs on hardware like Nvidia’s DGX Spark, a $4,699 Grace Blackwell machine with 128GB of unified memory that handles models up to roughly 200 billion parameters without anything leaving your desk. (There is also the DGX Station, its bigger, pricier sibling with 748 GB of RAM for running even larger models.)

“It’s like a system sitting right there next to you,” Conway says, one where “you don’t think about network latencies.” To run those agents securely, Nvidia offers NemoClaw, a reference stack that wraps an open agent harness like OpenClaw in a sandbox called OpenShell, with policy controls and local Nemotron inference.

When you need more power for a broader problem, you reach for a frontier model in the cloud. For Nvidia, that’s all good news: a system of models runs on its silicon one way or another, on your desk or in the cloud.

The post “We love the world where we can use both”: How Nvidia thinks about local and frontier models appeared first on The New Stack.

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.

Thomas Dohmke, who stepped down as GitHub’s CEO last year to become a founder again, is opening a preview of a distributed Git network on Wednesday that is designed to keep fleets of AI coding agents from overwhelming a single central server — and one that may soon compete directly with GitHub’s core service.

Entire, Dohmke’s post-GitHub startup, is launching a preview of this on Wednesday (but for now, it is behind a waitlist). With this, developers can mirror an existing GitHub repository onto Entire’s own infrastructure in one step.

“In the era of agents, centralized Git hosting has become a fundamental constraint, as the strain of billions of agents and developers hammering a central server shows up in the form of rate limits, high latency, or even outages,” says Dohmke in today’s announcement. “Today, we begin to return Git to its original promise, with a distributed, and soon fully decentralized and open-source network of interconnected nodes around the world. By doing so, we enable any developer or agent to host their code in-region, pushing, pulling, and cloning close to where they operate, fast and without bottlenecks, while still part of a global, collaborative network.”

The key here is that the code stays on GitHub, as Entire stresses, but coding agents can work with the Entire mirror and, as the company notes, “build without rate limits.”

Entire’s mirror is meant to absorb the constant flow of traffic that a fleet of agents can generate. That traffic, after all, is part of the reason GitHub is often buckling under pressure these days and startups like Entire have an opening.

Centralized Git hosting, Dohmke says in an interview with The New Stack, has become “a fundamental constraint” now that billions of agent and developer operations land on the same servers, showing up as rate limits, latency, and outages.

Given GitHub’s recent availability issues, it’s no surprise that startups are trying to get into this space. Entire is one — and it has the pedigree — but in June, Cursor also announced Origin, its own Git forge rebuilt for swarms of agents that are cloning and committing against a single repository in parallel.

Entire is starting with active regions in the United States, the European Union, and Australia, but the team says that now that is has spun up its first few regions, it will add more soon.

‘Git as a database’

To build its network, Entire rewrote the server part of git. GitHub, GitLab, and Bitbucket all wrap the server-side of the Git binary and build their infrastructure around it. Entire started from scratch.

“We see Git really as a database,” Dohmke says. The open source Git project has two halves, he explains: the client that an agent uses to talk to a repository, and the server a host runs to manage storage. Rather than build on that stock server, like most companies would do, “we made the decision of not going that route, and instead implemented our own Git backend.”

That only makes sense if Entire’s version has significantly better performance than the stock Git server, of course. Entire says its benchmarks have pushed the network to a sustained rate of 570,000 clones per hour, 586 pushes per second, and roughly 470 combined clone-and-push operations per second.

Pushing to a native Entire branch can run up to 25 times faster than pushing through to GitHub, Dohmke says.

Entire it will open-source both the git backend and the benchmark suite.

The foundation layer, now real

When Dohmke first described Entire’s plans to The New Stack in February, he described a three-layer platform that included a Git-compatible database at the bottom, a semantic reasoning layer in the middle, and an interface on top. Even then, he said that the database, unlike a centralized Git host, could be a globally distributed network of nodes.

But in February, Dohmke also said Entire wouldn’t necessarily end up competing with GitHub, and that code repositories would stay central to the pitch.

Pressed on whether that still holds now that Entire hosts its own copy of the GitHub repo, he calls the mirror complementary, in part because Entire can offer enterprises the ability to keep their code in a local region to fulfill local regulations. He also notes that GitHub has a huge ecosystem and an extended feature set.

“I think the question for the buyer really is, is it not better for me from an availability and reliability perspective, that I have both of these products, so if one of them is down — there’s always going to be single points of failure and human errors — then I have my mirror on the other side,” he says. “But we certainly will, in deals, compete for the dollar spent at a much smaller scale compared to the multi-billion-dollar business that is GitHub today.”

For now, that keeps the two complementary. Dohmke argues that GitHub remains the “source of truth,” or “cold storage,” while the working copy lives on Entire. But he also says that Entire will launch native repositories in the coming months, and those wouldn’t need GitHub underneath at all. All of this will be open-sourced as well.

Entire raised its $60 million seed round in February, when it had 15 employees. Felicis led it, with Microsoft’s venture arm among the backers. The company is now past 40 people and aiming for 60 by the end of the year.

Entire beyond Git: the semantic memory layer

Entire is building its middle layer — the semantic reasoning layer — in parallel with the Git platform.

The semantic layer now integrates with every major coding agent, including Claude Code, Codex, Cursor, Factory AI, and GitHub Copilot, and records each session, prompt, and tool call in the repository alongside the code.

Having this data is useful for agents, and it was the first core service the company launched. Now, it is also building more services on top of that history.

The company is adding Entire Blame, for example, which shows not just who last touched a line but the agent session and prompt behind it. There is also Entire Review, which fans out several agents for an intent-aware review, and the company is adding a code and semantic search feature that lets agents (and developers) search across code changes and the reasoning that produced them.

“Session logs are now the second most important artifact in software development, and they belong in the repository alongside the code,” Dohmke says.

The post Entire is building a Git network for agents appeared first on The New Stack.

When Subquadratic launched earlier this year, it could build a sparse-attention model that could handle a 12-million token context window and be significantly faster than today’s large language models. But it didn’t launch the model widely and it didn’t publish benchmarks.

Given the company’s large claims, that created quite a bit of skepticism. In June, Subquadratic published its first model card and benchmarks for its small model, SubQ 1.1, supplied third-party verification from data firm Appen, and started talking about its first design partners who now have access to its model.

So far, however, few people have actually used its model. To talk about the company, why its model isn’t widely available yet, and what it has in store for the near future, we met up with Subquadratic co-founder and CTO Alex Whedon.

“We’re not a sparse attention company either.” — Alex Whedon, Subquadratic.

One thing Whedon definitely wanted to clear up is that the company’s current model may be based on sparse attention, but that isn’t its full mission.

“We’re not a sparse attention company either,” Whedon tells The New Stack. “We’ve been working on non-attention architectures for quite a while as well. We think that we will be the first people to leapfrog ourselves in terms of the next model architecture.”

We’ll get back to that.

What the model card shows

It’s the company’s SubQ 1.1 Small model that people are talking about now. This model is built on Subquadratic Sparse Attention (SSA), an attention mechanism the company says scales close to linearly with context length instead of quadratically.

“In the case of Subquadratic Sparse Attention specifically, which is one of a couple model architectures we worked with, the idea is that not all of the token relationships matter,” Whedon explains. “Token relationship compute is why you see this quadratic scaling law.” This means there are almost a million possible two-token relationships in a 1,000-token input in a full attention matrix.

For SubQ 1.1 Small, the strongest results are in long-context retrieval, which makes sense, given that this is where the architecture should have its biggest edge.

On the needle-in-a-haystack test, SubQ 1.1 Small scores near-perfect from 1 million tokens out to 12 million, even though it was trained mostly at 1 million. It hits 99.12 percent on Nvidia’s harder RULER test, which asks the model to trace and aggregate facts across a 128,000-token context rather than just find one.

On general capability, it lands just below the mid-tier frontier models, at 85.4 on GPQA Diamond against 87.5 for Sonnet 4.6. On the LiveCodeBench coding benchmark, it scores 89.7, below Opus 4.8 and GPT-5.5, but slightly better than Sonnet 4.6.

Efficiency is where the model shines, though. The company says that at 1 million tokens, SubQ uses 64.5x less compute than dense attention and runs 56x faster than FlashAttention-2 on a single attention layer. At the full 12-million-token window, it puts the attention compute reduction at close to 1,000x.

“Even in full dense attention, the relative importance of over 99 percent of tokens is very low, attention scores are below 0.1,” Whedon says. “We actually show this in our model card. So clearly we’re just wasting compute most of the time, and in fact we’re maybe making the modeling task harder, because we’re introducing noise.”

“Transformers are a brute-force approach to the problem of text modeling,” he says. “You could say, ‘I’m going to compare every single individual token to every other possible individual token.’ That’s what transformers do. Very brute force, very naive. It just assumes that the first needs to look at the second, the third, the 50th, and the 5,000th. That’s not how humans read text.”

SSA also differs from retrieval-augmented generation, which drops chunks of text before the model sees them. “Every token of the text is being seen by the model,” he says. “It’s just not being redundantly compared to every other token of the text.”

On capability, SubQ 1.1 Small lands roughly in Sonnet 4.6 territory, sometimes a bit above, sometimes below. But its edge, the company says, is size and cost.

“What we posted publicly was fewer than 100 billion parameters,” Whedon says about the size of the model. “I would venture to say that our model is smaller than any of the models offered by OpenAI or Anthropic. But our next model will not be.”

Smaller, cheaper, built for enterprises

Subquadratic is also making the pitch that its model’s capabilities will be especially interesting for enterprises.

“We think that’s a pretty interesting enterprise offering,” he says. “We’ve seen a lot of people in the enterprise space talking about using the mid-tier models as opposed to the frontier for large data-processing tasks, which is exactly where we’re trying to plug in.”

Given that a lot of enterprise problems start with searching through large heaps of data, this makes sense. You can pack a lot of documents into a 12-million token context window, after all. Most of today’s models break down well before the user fills their million-token windows, but with its near-perfect retrieval scores, SubQ may be a good answer for these problems.

As Whedon noted, the model’s first users are design partners, not the public. “We’re giving access to the model to design partners now, and these are mostly enterprises, largely with eight- to nine-figure spend,” Whedon says. “This is a core market that we really care about. It has been since day one.” A limited individual-access release will follow before any general availability.

The launch led with claims instead of benchmarks by choice.

“We were announcing mostly research,” he says. “We could have maybe messaged the launch a little bit differently. There was some debate about how we were going to message it.”

Built on an existing model

One question from May hasn’t gone away, though. The model card states that Subquadratic “started with an existing open-weight frontier model by replacing its dense attention with Subquadratic Sparse Attention (SSA),” and then ran roughly one trillion tokens of long-context continued pretraining on books, documents, and repository-scale code.

That confirms what some of the skeptics suspected at launch, when OpenAI researcher Will Depue wrote that SubQ was “almost surely a sparse attention finetune of Kimi or DeepSeek.” What’s new here then is the SSA mechanism and the long-context training recipe, not a model trained from scratch. The company has not said which open-weight model it started from.

The biggest lever on long-context retrieval was pretraining on very long sequences, Whedon says, something SSA’s efficiency made cheap enough to run as routine.

“Nobody’s talking about multimillion-token pretraining,” he says.

Why hybrids don’t go far enough

There have, of course, been attempts to improve on quadratic scaling, but Whedon thinks most of those attempts only go — almost literally — halfway. Hybrid models such as Nvidia’s Mamba-based Nemotrons, Qwen’s Gated DeltaNet layers, and the various linear-retention designs swap out some of the attention layers, but they don’t go all the way.

“If 80 percent of the layers are not quadratically scaling, then your maximum payoff is like a 5x increase as you scale toward infinity,” he says. “We see a 60x increase at 1 million tokens, almost 1,000x at 12 million. That is the type of payout that you only get if you actually change the scaling law, as opposed to a scalar win.”

He actually credits DeepSeek’s own sparse attention mechanism with making his company’s pitch easier.

“They showed that you could dynamically select relationships without a significant quality trade-off,” Whedon says. “However, they did so by redundantly using a smaller but still full-attention model that ends up using the vast majority of the compute at scale.”

Subquadratic ran its own benchmark against GLM 5.2. “At 1 million tokens, 58 percent of the prefill latency comes from that selection mechanism,” Whedon says. “So that selection mechanism, which is supposed to be seen as cheap, actually dominates the compute, because it’s a quadratically scaling component.”

Beyond sparse attention

It’s also why Whedon pushes back on the “sparse attention company” label. Subquadratic has been working on what he calls “zero attention,” architectures that drop the attention mechanism altogether.

“Attention is kind of similar to RAG in that you have queries, keys, and values that represent information about the tokens that you’re processing,” Whedon says. “There’s this discreteness of representation, where everything is represented within these nice little boxes. That’s super convenient. It’s easy to build a brute-force solution around it. But it also means your ability to compress information is limited. If you had a more continuous, abstract way of representing the information, then you could compress it further, which means you can make smaller models, or you could just scale things up again to create another leap in intelligence.”

He traces the idea to world models and to Yann LeCun’s work. “The stuff we’re doing takes a lot of inspiration from world models, not the video modality in this case, but some of the things LeCun is talking about,” he says. “Rethinking how to represent long-range dependencies, how to keep a long-range state, how to rethink the objective function.” He stops there. “That’s probably all I could say for now.”

Subquadratic has also marketed only one of the three kinds of efficiency it says it is chasing. “We care about compute, sample, and memory efficiency,” Whedon says. “We’ve done a lot of work on all three, but have only really talked about the compute efficiency publicly.”

The near-term plan

The near term plan for Subquadratic, however, is more modest. “Over time, yes,” Whedon says, when asked whether Subquadratic could rival OpenAI and Anthropic on raw quality in the long run. “In the shorter term, we have to be strategic. If we try to boil the ocean on much less capital, it’s not going to go well for us.”

The next model, he says, will likely be a mid-tier size rather than a frontier-class one (think SubQ 1.2 Medium), that he expects to outperform most of the competition in its tier.

How the team will bring the model to market, though, remains to be seen. I wouldn’t be surprised if the team launched its model on one of the hyperscaler’s large model platforms, but Whedon remained tight-lipped about the company’s plans.

The fact that we met with the Miami-based Whedon in San Francisco, though, gives you a bit of a hint of what the team is currently up to.

The post What comes after attention? This startup says it already knows. appeared first on The New Stack.

Workday, the payroll and HR data platform, has been pursuing AI and agents for a while, but while other businesses may allow a little room for error, getting a payroll run in Workday 99% right is not exactly good enough.

Gabe Monroy, Workday’s chief technology officer, tells The New Stack that enterprise AI has to clear this bar before anyone will let it near their HR and finance data.

“There aren’t many systems that are more critical — or less forgiving — than ones that are dealing with people and money,” he says. There’s no tolerance for “well, it works most of the time,” Monroy says in an interview.

At its DevCon developer conference in early June, Workday laid out its plans to clear this correctness bar. The company introduced Agent-Ready Tools, a set of connectors that let agents act across the platform over the Model Context Protocol (MCP), a Developer Agent that lets people build apps and agents on Workday in plain language, and Agent Passport, which tests and verifies agents before they go into production and keeps monitoring them after, with Cisco as the first attestation partner.

Guardrails belong in the inference engine

Monroy spent most of his career in infrastructure and the developer space: at Deis, Microsoft, DigitalOcean, and, most recently, Google. At Google, he focused on building infrastructure for large AI labs to run inference at scale. For someone so focused on infrastructure, coming to Workday might seem a bit like an odd move, but Monroy argues that, at this point, LLM safety is — or at least should be — part of the core infrastructure for enterprises.

“The stakes are higher … in the world of people and money”

“The stakes are higher in the world of Workday and in the world of people and money, and that’s something that I was really excited about tackling at Workday specifically — and I do look at it as a core infrastructure,” he says. “A lot of what I’ve been doing in my recent past has been building infrastructure for large AI labs to do inferencing at scale, and what you pick up pretty quickly is that inferencing is probabilistic.

“[Inferencing] involves prefill and decode, and a whole bunch of really technical machinery in place to stream tokens out to end users, but what is nowhere in that stack today is the concept of native LLM-level enforced guardrails — guardrails that are part of the core inference.”

In his view, making it safe for enterprises to operate inference at scale has to be done at the inference engine layer. Agent gateways and similar add-ons that wrap the model from the outside sit at the wrong layer, he argues.

For a system of record like Workday, the system must strictly enforce guardrails on who the user is, what their budget authority is, and where they sit in the org chart. Those constraints, Monroy says, can be wired deep into the inference rather than checked after the fact. “These are things that we have the opportunity to wire deeply into the inferences at a very, very low level, in a way that produces much safer outcomes,” he says.

Workday’s recent acquisition of Pipedream partially plays into this. With Pipedream, an agent can reach out to third-party systems outside Workday to, for example, pull a policy document from Google Drive, and the platform can then verify that this specific agent has all necessary access rights to do so.

“Bring it to our shop”

All of those agents need to be managed, of course, and while many SaaS companies are currently building out their own agent platforms and agent orchestration services, seemingly all offering the same services, Monroy argues that orchestration should happen close to the data sources.

“If you’re trying to run an agent interaction that is integrating with people and money, that orchestration loop should probably happen closer to Workday, ideally on the Workday,” he says. “I do think there is something to be said for inference engines having proximity to the underlying system, because when it comes to a low-level inference engine and runtime perspective, there are some differentiated things you can do at the inference engine level that are only possible due to proximity to.”

“I do think there is something to be said for inference engines having proximity to the underlying system…”

He likened it to car repair. If somebody hands you a toolbox, you may or may not be able to fix your car’s problem. “Maybe you’ll get the outcome, but I tell you what, if you really want your car repair done right, bring it to our shop. We got the hydraulic lift, we got the trained engineers who know how to do this stuff, and we got the tools — but our tools are the best in the industry.”

For the part of an agent’s orchestration loop that has to run next to HR and finance data, “you really should be running that in our shop.”

For more general-purpose workflows, though, he believes there is room for general-purpose platforms. Not everything needs to run on Workday, after all, and Workday does offer MCP servers that third-party tools can tap into to access its data and tools as well.

To some degree, every system-of-record vendor is making some version of the proximity-and-context case right now. Owning the context for AI agents to work with is a major moat for these companies, after all, even as APIs and MCP servers allow agents to pull in data across vendors.

Meanwhile, there is also a group of other companies positioning themselves as neutral parties benefiting from the fact that these other vendors are now opening their platforms to third-party agents. It seems unlikely that, in the long run, enterprises will want to manage multiple agent platforms, but at this point, it is still far from clear in which direction this pendulum will swing.

Happy to lose the tooling fight

If proximity is where Workday thinks it can win, there is one area where the company doesn’t want to compete: developer tools.

“We’re not going to differentiate Workday on building better tools for developers,” Monroy says. “We’re going to differentiate on safety, on trust, on the inference engine.” It’s telling that the demos at DevCon ran on Claude Code, Cursor, OpenAI’s Codex, and Google’s Antigravity rather than on anything Workday-branded. “On the tooling front, I’m happy to have Claude Code and Codex and others,” he says.

It’s no secret that developer loyalty to AI tools doesn’t really exist at this point. Developers definitely don’t want a one-off tool from a single vendor, and Monroy notes that he isn’t going to ask them to adopt one. Instead, Workday wants to own skills, which he calls “the underlying lingua franca that we’re using to converge across the system.”

Workday is happy to be the system of record for its vertical and to let others fight over the tools.

The post “Bring it to our shop”: Workday’s pitch for keeping AI agents close to your most valuable data appeared first on The New Stack.

The Linux Foundation on Tuesday declared its intent to launch the Agent Name Service (ANS), an open standard that gives AI agents verifiable identities by tying them to the internet’s domain name system (DNS).

The idea behind the ANS has actually been around for a while. It began as a research paper published in May 2025 by the OWASP GenAI Security Project, written by a group of application-security researchers. Its authors include Ken Huang, the CEO of security consultancy DistributedApps.ai and a co-author of the widely cited OWASP Top 10 for LLM Applications that chronicles the top security risks related to LLMs, and Akram Sheriff, an AI security engineer at Cisco.

ANS is a bit of a redesign of the original idea, which has gone through a few iterations since it was published. The 2025 original described ANS as a “universal directory” — basically a central registry with naming borrowed from DNS. A second version, published as an individual draft at the Internet Engineering Task Force in April, takes this a step further and ties each agent instead to a real domain its operator already controls.

How it would work

The design essentially copies how websites already prove who they are today. An operator demonstrates control of a domain like example.com through ACME, the automated protocol behind Let’s Encrypt, and a registration authority issues the agent a pair of certificates. Every change to the agent’s status, from registration to renewal to revocation, is written to an append-only log. A client checking an agent can choose how much assurance it wants, from a basic certificate check to a tier that also consults the log.

It’s worth noting that the ANS system separates identity from discovery and hands the job of finding agents to other services built on top.

The DNS industry and AI agents

Discovery is actually handled by DNS-AID, a separate discovery standard the foundation took in on May 27. It lets agents publish their endpoints as DNS records so other agents can find them. DNS-AID was originally built by Infoblox, and GoDaddy, which is also involved in ANS, is among its backers.

Agent identity and discovery projects based on DNS aren’t limited to these two Linux Foundation projects, though. Including those two, there are now at least four similar proposals. There is DNSid, for example, a durable-identity scheme from the registry operator Identity Digital, and AID, a minimal discovery draft that came out of the developer community.

Vineeth Sai Narajala, a co-author of ANS now with OWASP, says in the announcement, “we didn’t need to reinvent the wheel, we needed to extend the foundational trust of the internet to a new generation of autonomous technology.”

Not reinventing the wheel also means basing this system on the registrars and certificate authorities that come with it and the trust hierarchy they built, which security researchers have long considered fragile.

Maybe it’s no surprise that many agent identity and discovery solutions are coming out of the domain industry. GoDaddy, after all, registers domains, Identity Digital operates top-level domains, and Infoblox, which backs ANS, sells DNS infrastructure. For all of them, DNS-linked agent identity and discovery extends a (profitable) business they already run.

What about A2A and co.?

As is so often the case, the Linux Foundation is playing host to several alternative systems. Google’s A2A protocol, for example, gives agents a signed “Agent Card” they can publish at a known web address, with an agent registry on its roadmap. Cisco’s AGNTCY ships an agent directory and its own cryptographic identity service. Outside the foundation, Microsoft’s Entra Agent ID and Okta for AI Agents, both generally available since the spring, treat an agent as an identity managed inside the corporate directory, with short-lived tokens that tie each action back to the person who authorized it.

And while Cisco is backing both ANS and AGNTCY, some names are missing here, including major players like Google, Anthropic, Microsoft, and Amazon. Given their outsized role in the agent ecosystem, it’ll be interesting to see if they’ll join in this effort or decide on their own standards (insert obligatory xkcd comic here).

The post Can DNS become the basis for AI agent identity? appeared first on The New Stack.

Databricks wants to erase the divide between the databases that run a business and the systems that analyze it. At its Data + AI Summit in San Francisco on Tuesday, the company introduced an architecture it calls Lake Transactional/Analytical Processing, or LTAP, built to collapse that split for AI agents.

Databricks started going down this path a while ago but made it concrete when it bought the serverless Postgres startup Neon and, later, Mooncake Labs in 2025. The bet here is that AI agents, not people, will become the primary users of the enterprise data stack, and that the infrastructure beneath them has to be rebuilt for them.

A breakthrough 40 years in the making

“For decades, complicated data infrastructure was a tax that teams were forced to pay,” said Ali Ghodsi, co-founder and CEO of Databricks, in the announcement. “Then agents arrived. In a matter of months, organizations effectively doubled their workforce, just not with humans. Agents write code, make calls, and run loops at a pace human teams never could. The infrastructure that powered the last era of computing is now the bottleneck that no one can afford. LTAP removes it.”

LTAP, Ghodsi said in his conference keynote on Tuesday, is “a breakthrough the industry has been working on for 40 years. We think we finally pulled it off.”

Historically, companies have had to run two kinds of databases. Online transactional processing systems handle the live operations of a business, like orders, payments, and inventory, in row-based formats tuned for fast writes. Online analytical processing systems then use what is essentially the same data for reporting and analysis in column-based formats specifically tuned for large scans. The two were kept apart for performance and reliability, and enterprises bridged them with ETL pipelines and replicas..

Databricks argues that agents need a different system because they can read live transactional data, reasoning over historical context, and act on both of them at once.

Earlier attempts to merge the two layers never quite worked, the company says, because hybrid transactional and analytical processing (HTAP) systems carried high costs and proprietary lock-in, while “zero-ETL” tools amounted to hidden change data capture, still leaving two copies of the data and the problem of data going stale.

What is LTAP?

LTAP unifies transactional and analytical data in a single storage layer, governed once and stored in open formats on cloud object storage, while keeping separate compute engines for each kind of work.

The design builds directly on Lakebase, the Postgres-based operational database Databricks introduced in June 2025, which the company describes as a “new category” that separates compute from storage and places the data in the lake in open formats.

Now, the company is extending Lakebase for what it calls business-critical workloads, adding native vector and full-text search, real-time event ingestion through Zerobus, part of its Lakeflow Connect ingestion service, and Git-style branching that lets an agent copy a database to experiment and then discard it.

“Agents love to just branch out and experiment with the data, try something else, and they want to do it quickly,” Ghodsi said. “They don’t want to wait ten minutes on a database to come up.”

Lakehouse//RT

The second piece is Lakehouse//RT, a real-time analytics engine, powered by a vectorized engine Databricks calls Reyden, that runs directly on Delta and Iceberg tables in the lakehouse.

Companies have long stood up separate, specialized systems to get millisecond query speeds, duplicating data into a “serving layer” that sits alongside the lakehouse. Databricks says Lakehouse//RT removes that layer, delivering millisecond-level latency on lakehouse data with no extra copies, pipelines, or governance gaps.

Databricks stresses the engines high concurrency. Mehrshad Setayesh, SVP of engineering at PointClickCare, says Lakehouse//RT “ran more than a third faster on average than our prior warehouse on our healthcare dataset, with 10x faster queries,” and that it removed the company’s need for a dedicated real-time system alongside its lakehouse.

Mooncake and Neon to the rescue

LTAP’s main pitch is that a single copy of the data can be stored once in open formats without the need for complex data pipelines. The Lakebase architecture, the company wrote last year, shares one storage layer across transactional and analytical workloads “without moving or duplicating it.”

Lakebase’s analytical speed comes from Mooncake, the startup Databricks bought to accelerate it. Mooncake mirrors Postgres changes into the lakehouse in real time, which is how transactions and analytics run on the same fresh data.

“Postgres changes are mirrored in real time to the lakehouse,” the company wrote when it announced the deal. Mirroring produces a second, columnar copy of the data, which is what makes the analytical queries fast.

Security, governance, auditing, and high availability, the company wrote, “only need to be implemented and managed once, on a single open foundation.”

The branching is the feature of this that was built specifically for agents — and a feature that is core to Neon, too. Because the data sits on object storage, an agent can fork a full database, test against it, and discard it, the way it would a Git branch. Databricks says even petabyte-scale databases can be copied in seconds, while on a traditional database, provisioning an instance takes minutes or hours and cloning production risks taking it down.

As Ghodsi noted in his keynote, agents love Postgres, but they do need better tools to work with them — and maybe better databases, too. “In the next 12 months, we’re going to see more software written than ever in the history of mankind,” he said. “All that software that your organizations are going to write using LLMs and coding tools need the database behind the scenes.”

What else is new?

LTAP was only one part of the company’s three-hour keynote. Like so many other enterprise vendors, Databricks is also thinking about how to get agent sprawl — and cost — under control. Databricks’ answer is Unity AI Gateway, a single control point for every model, agent, MCP server, and skill running in an organization. Among other features, it offers spending dashboards, budgets that can be set per team or per user, rate limits, and single sign-on across MCP servers.

The company also introduced Genie One, a general-purpose agent for business teams, fed by Genie Ontology, a new layer that builds a ranked graph of a company’s data with a PageRank-style algorithm it calls OntoRank.

Ghodsi also highlighted OpenSharing, a new protocol for sharing data, models, and agent skills across platforms (you may remember its predecessor Delta Sharing, but it is now a project under the Linux Foundation).

Databricks also debuted CustomerLake, a customer data platform aimed at marketing teams and announced an agreement to acquire Panther, a Python-based security company, to feed its Lakewatch security information and event management service.

Databricks’ moat?

It’s the data layer, though, and its data science history, where Databricks can really differentiate. At this point, it feels like every enterprise vendor, no matter their expertise, is adding agent builders, agent orchestration and governance tools. Databricks can be a relatively neutral player in this space — something Ghodsi also stressed in a press conference after the keynote.

But the company is also seemingly aware that while many of the other enterprise SaaS vendors can use their expertise and existing customer data that can feed AI agents as a moat, Databricks functions as more of a utility layer. It’s maybe no surprise then, that it is launching an industry-specific product like CustomerLake for the marketing industry that adds a pre-made product layer on data its customers already store on its platform.

The post Databricks wants to merge the two databases every company runs appeared first on The New Stack.