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.

Every enterprise software vendor is currently selling some version of the same thing: AI agents grounded in enterprise context and governed by a central control plane. SAP, ServiceNow, Salesforce — they all have one. 

At its ONE conference in Amsterdam in June, OutSystems unveiled its version, and its CEO, Woodson Martin, agrees that they all look quite similar on the surface, but unsurprisingly, he also believes that OutSystems has a very different approach.

Martin tells The New Stack that, in his view, “It would be very easy to just look at the market today and say all enterprise software players are offering exactly the same thing.” The reason for that, he says, is that enterprise agent orchestration, “is sort of greenfield today. Everybody’s aiming for it. Everybody’s got a great story about why they’ll be a leader or a player.”

For OutSystems, the story is neutrality. While SAP and Salesforce pitch agent orchestration from within their ecosystems, where they are also the systems of record, the 25-year-old former low-code company, which now describes itself as an agentic systems platform, wants to be the layer that coordinates across all of them without owning the underlying data.

The advantage of not being a system of record

Martin says the company has been playing some version of this for a long time. “We’re glue between commercial off-the-shelf solutions,” he says. “We’re the thing that makes the enterprise their own enterprise, as opposed to an SAP enterprise or a Salesforce enterprise.”

One asset management customer, he says, has used OutSystems as the orchestration engine across about 80 systems for fund onboarding for the past six or seven years. That wasn’t for any agentic systems yet, of course, but OutSystems’ role in this isn’t all that different. “We’re already playing that orchestrator role,” Martin says. “In other cases, we don’t have that position yet in the account, and we’ll have to fight for it.”

Tiago Azevedo, OutSystems’ CIO, makes the same argument. “We are agnostic to all of those things.” The OutSystems platform doesn’t create most of the data it touches, he notes. Instead, its focus was always on integrating existing systems. “Our happy place is when we bring several of those systems all together into a form that makes sense for a process,” he says.

Open to Claude, Codex, and Kiro

At the ONE conference, the company launched the OutSystems Agent Experience, a platform layer that exposes Model Context Protocol (MCP) and Agent2Agent (A2A) services. Developers can now build, publish, and extend OutSystems applications with third-party coding tools like Claude Code, Codex, Cursor, and Kiro, AWS’s spec-centric IDE. 

The first of those services is now live on the OutSystems Developer Cloud (ODC), the cloud-native, current-generation platform. Support for OutSystems 11, the older self-managed platform where a large part of the installed base still runs, launched in early access

“Existing customers that live on O11, they’re like: what I would love to do was to be able to use Claude or Codex or whatever to evolve my applications in O11,” Azevedo says. “So we made that possible. “[…] We made a lot of people happy.” 

And indeed, when this was announced in the keynote, it drew more applause than some of the other large product announcements.

He sees no alternative to opening up the platform, given how freely developers now move between coding tools. “I strongly believe in open systems,” he says. “You close those environments, you’re gone.”

Other launches at the conference include the Agentic Enterprise Orchestration service and the next-generation OutSystems Agent Workbench, which is now generally available and adds agent evaluations, guardrails, semantic search, and Amazon Bedrock support. 

There is also a preview launch of a new modernization service, built on AWS Transform and Kiro, for migrating COBOL and Lotus Notes systems onto the platform, as well as a pre-packaged agentic solution for loan origination, the first of a family of packaged agentic industry solutions, which arrives later this year.

The new bane of IT departments: shadow AI

Shadow IT has returned as shadow AI, Azevedo says. And while he has always managed to stay ahead of internal technology demands with previous platform shifts, that’s getting harder now. “With AI it’s impossible,” he says. “It’s literally impossible. It’s not humanly possible.”

The way he describes it, a central team can build maybe 10 large agentic workflows that solve company-scale problems. “Those are what we call the big bets,” he says, and these bets exhaust the team’s capacity. Everything else means letting the rest of the organization build its own agents, and every one of those requests immediately raises questions of who gets to touch which company data and through which MCP servers. Demand from every department, he says, is growing almost exponentially.

The token bill

Unsurprisingly, this is now also coupled with the question of how much all these tokens cost. 

“I also have my CFO saying, what about the token usage? And what about the budget? And who’s gonna pay for that?” he says. “If you look at, let’s say, 500 euros or dollars a month, times 12, times, let’s say, 1,200 or 1,500 people, these are millions in a year.” 

For now, at OutSystems, he rations token budgets almost by hand, protecting projects that could scale and trimming those that serve an audience of one.

“It’s the most expensive software — and I managed big contracts,” says Azevedo. “The most expensive I’ve ever had in my hands.”

“It turns out my number one consumer of tokens on Anthropic in the month of April was a business value consultant in Australia … why is he burning $7,500 in tokens every week? That’s not in the budget.”

Martin tells a similar story from the CEO perspective. “It turns out my number one consumer of tokens on Anthropic in the month of April was a business value consultant in Australia,” he says. “And we’re like, why is he burning $7,500 in tokens every week? That’s not in the budget.”

Martin traces the shift to the latest generation of reasoning-heavy models, which arrived around January and February, “and we’re getting these token bills in March and April that are starting to scare everyone.”

For the overall OutSystems platform, the answer to this is model flexibility. Customers can bring their own models, swap them without touching the agent logic, and route requests through Amazon Bedrock to whatever is the cheapest option to do the job effectively. Some customers built model routers on OutSystems early on, Martin says, sending complex asks to expensive models and simple ones to cheaper ones. 

He also argues that OutSystems’ Enterprise Context Graph means that reasoning over an enterprise context graph is less token-intensive than reasoning over an application’s raw codebase.

“I think organizations are going to develop more discipline around this as we have for other elements of material spend in any enterprise,” Martin says. “This is now becoming material for almost everyone.”

OutSystems’ advantage may indeed be that it isn’t a system of record but ties into all of them. As those systems of record open up with new MCP tools, the former low-code platform may just be in the right position — and with the right customer base — to help its customers tie all of these together, even as those platforms launch their own agent builders and orchestration platforms. Sometimes you may want your agent to be close to the data, but over time, nobody wants to manage half a dozen agent orchestration platforms either. 

The post Who gets to be Switzerland in the enterprise agent wars? appeared first on The New Stack.

About a year ago, Google demoed a diffusion model at its I/O developer conference, but went quiet about the technology soon after.

On Wednesday, however, Google broke that silence with the launch of DiffusionGemma, an experimental 26B mixture-of-experts model that uses diffusion to generate text 4x faster than its existing Gemma models.

Diffusion has long been the standard for generating images (think Stable Diffusion). Instead of generating one word at a time, models like DiffusionGemma or Inception’s Mercury 2 generate words in parallel.

At first, those blocks of text don’t make sense and seem random. But then, with each new step, the model refines the text and reduces the noise until it becomes the answer you were looking for. If you’ve ever looked at a diffusion image model generate images in real-time, that’s essentially the same process, but for text.

With each step, the model denoises 256 tokens in parallel, which is why it can be much faster than a traditional autoregressive large language model. It basically iterates on the text with each step until it.

All of these tokens attend to all others, which Google says is especially helpful for use cases such as inline editing, code infilling, working with amino acid sequences, and mathematical graphs.

Google says DiffusionGemma can produce more than 1,000 tokens per second on a single Nvidia H100. And since the model uses the mixture-of-experts technique, it doesn’t have to keep the full 26 billion parameters in memory; instead, it activates only 3.8 billion during inference. This means it can easily run on a GPU with 18GB of VRAM.

There are some tradeoffs, though. On all benchmarks, the DiffusionGemma model underperforms when compared to Gemma 4 26B A4B. That’s something Google itself acknowledges. There’s no technical reason why a diffusion model couldn’t perform just as well as a more traditional large language model, but the focus here is on speed.

“For applications that demand maximum quality, we recommend deploying standard Gemma 4,” Google says in its announcement.

Availability

The model is now available on HuggingFace, with Unsloth and other quantizations available for those who want to run it locally using llama.cpp and (soon) similar local inference tools.

Google also worked with Nvidia to optimize the model for its hardware, including high-end GPUs like the  GeForce RTX 5090 and 4090, as well as the Nvidia DGX Spark and DGX Station (for those who can afford them). Nvidia NIMs are also available for the model.

Inception says its diffusion LLM is 10x faster than Claude, ChatGPT, Gemini

The post Google’s DiffusionGemma is 4x faster than its other Gemma models appeared first on The New Stack.

For much of the past year, GitHub has not been the stable utility developers had long gotten used to. Outages, hitting everything from search to GitHub Actions and the CI/CD pipelines that depend on it, have become too regular an occurrence. The company has logged hundreds of incidents over the past 12 months and has had to apologize in public.

The New Stack sat down with GitHub Chief Operating Officer Kyle Daigle (who is now also the CMO of Developer at Microsoft) to talk about why all of this is happening and what GitHub is doing to fix this. 

Why planning for 100% growth wasn’t enough

One thing the company has been quite open about is that it is facing unprecedented growth in this era of agentic coding — and one that goes well beyond what even a hyper-growth cloud company usually experiences.

To address this hyper growth, as Daigle put it, it’s now “all hands on deck” for GitHub.

“It’s not just about the normal scaling solution in the cloud era of let’s get a bigger machine or let’s do more machines,” Daigle tells The New Stack. “It’s now making sure that we can scale at 30 or 40 times over the course of the next year, rather than just a very impressive 100 percent year-over-year historically.”

GitHub assumed, Daigle says, going from 50 percent growth to 200 percent growth would be a surprise. “It turns out that that was the easy number and we need to go even more,” Daigle says. The engineering team at GitHub is now looking to get the system to a place where it can handle 30 times the commits, pull requests, and issues it processes today.

“It’s not just about the normal scaling solution in the cloud era of let’s get a bigger machine or let’s do more machines.”
—GitHub COO Kyle Daigle

There is maybe a bit of irony in this, given that GitHub itself helped kick off much of this era with the launch of Copilot in 2021. This, in many ways, evangelized AI code generation among developers and trained them to lean on it. Now, GitHub is buckling under the load. In all of 2025, the service processed 1 billion commits. Now it processes 1.4 billion a month. Daigle says agents alone are now creating more than 17 million pull requests a month.

What “all hands on deck” actually means

GitHub has been moving from its own data center to Microsoft’s Azure cloud to meet this demand, but Daigle notes that this isn’t just about adding capacity.

“What we’ve been really focused on is not only scaling in the normal ways of continuing to get more CPUs and doing the sort of normal horizontal and vertical scaling, but more importantly, really digging into the underlying systems, and updating them, or rebuilding them, or improving those hidden systems that do the core work,” Daigle says.

Much of the early work focused on relieving pressure on the database, as GitHub Chief Technology Officer Vlad Fedorov pointed out in a blog post earlier this year. GitHub addressed MySQL contention, moved webhooks entirely off MySQL, and redesigned its session cache and authentication flows to reduce database load. 

For GitHub Actions specifically, Daigle says the way jobs are dispatched to runners had to be rewritten. The broader architectural goal is to isolate critical services like Actions and Git from everything else, so that a struggling subsystem doesn’t take others down with it. GitHub is also moving performance-sensitive code out of its Ruby monolith and into Go.

“Most of that low-hanging fruit, we’ve conquered,” Daigle says, though he admits the gains are hard to point to. “It’s the catch-22 of improving availability,” he says. “When you’re up, there’s not an easy way of saying, look, we made this improvement.”

GitHub is leaning on Microsoft for help, too. “It’s very much all hands on deck at GitHub,” Daigle says. “We’re getting more support than ever, with experienced engineers to come help us scale quickly.” Much of that reinforcement comes from Microsoft, including engineers who have scaled systems at this magnitude before. 

“Our number one priority is having a platform that is up, that you can trust, and that’s reliable for the world’s developers,” Daigle says, “and now the world’s agents.” 

Why GitHub keeps shipping new features anyway

One question worth asking is, if availability is the priority, why is GitHub still rolling out a new Copilot app at its Build conference and other features?

Not every surface carries the same risk, Daigle argues. The CLI and the new Copilot app iterate outside the blast radius of hosted GitHub, so they can move quickly without touching the systems under repair. The backend work is “focused on stability and resilience,” and it occasionally unlocks features as a byproduct of rebuilding the underlying architecture.

“If I release a CLI piece of functionality, it doesn’t have the same stability and resilience characteristics as github.com,” Daigle says.

That won’t matter much when the underlying infrastructure is down, of course, but Daigle seems hopeful that this phase of GitHub’s history will soon be over.

“Hopefully each month is a little bit better than the month prior,” Daigle says, “with all the urgency that we can put against it.” 

The post How GitHub plans to win developers back appeared first on The New Stack.

At SAP Sapphire 2026 in Orlando in May, SAP made the case that the enterprise AI race will not be won by the company with the best chatbot, the flashiest agent demo, or even the most capable LLM. It will be won, SAP believes, by the platform that can provide agents with enough business context, data access, and governance to do real work within mission-critical systems.

This is a theme many enterprise software vendors are now emphasizing. Atlassian has Teamwork Graph. ServiceNow has Workflow Data Fabric. Salesforce has Data Cloud and Agentforce. SAP’s approach builds on its long-standing ERP foundation: the business processes, data models, authorizations, compliance rules, and customer-specific extensions that reside within its customers’ SAP landscapes.

At Sapphire, SAP consolidated a number of its existing services under a new banner: SAP Business AI Platform. This platform brings together the SAP Business Technology Platform, SAP Business Data Cloud, SAP Autonomous Suite, and SAP Business AI, as well as tools like Joule Work, and strengthens the company’s messaging around the “Autonomous Enterprise.”

As SAP noted at the event, the Autonomous Suite will include more than 50 domain-specific Joule Assistants that orchestrate over 200 specialized agents across finance, supply chain, procurement, human capital management, and customer experience. Joule Work, meanwhile, is SAP’s attempt to make its Joule AI agent service the front door to those workflows across SAP and non-SAP systems.

The real play here, however, is that SAP is aiming to translate its long-standing  Enterprise Resource Planning advantage — which has held up across multiple technology eras — into an AI-era context layer.

“What’s not differentiating is the LLMs… Use OpenAI models, use Anthropic models, whatever you like.”

“What’s not differentiating is the LLMs,” SAP CTO Philipp Herzig said during a post-keynote Q&A. “Use OpenAI models, use Anthropic models, whatever you like.” Coding assistants, too, are not where SAP expects to differentiate, he says. “You can use Claude Code, who cares? Use the tool you like. That’s non-differentiated. They’re all amazing.”

What matters, Herzig argued, is everything around the model. The important thing is whether an agent knows the right business entities, can find the right data, has the right access controls, and can be tested against real enterprise data rather than a few happy-path prompts.

For example, he said, too many teams do not build evals at all. They do what he calls “vibe checking.” “They just go in, and they try three things and feel happy with it,” he said.

SAP’s answer to this is to have its platform automatically generate more of that enterprise scaffolding, including product requirements, technical specifications, tests, data connections, security setup, observability, and governance.

Models are a commodity layer

This also means that SAP is very explicit about where it does not want to compete. “We’re not going to build our own large language model, to be clear,” Sean Kask, SAP’s chief AI strategy officer, said in an interview with The New Stack at Sapphire.

Kask’s view is that SAP should partner where generic technology is best available and build where SAP has unique assets. That is why SAP can lean on partner models from companies such as Anthropic, Mistral AI, and Cohere, while also investing in SAP Domain Models for specialized tasks and SAP-RPT-1.5, because it is in these areas where the company believes it has the differentiated data and domain knowledge to make a difference for its customers.

The same logic applies to agent frameworks. Kask noted that SAP agents are built on common open-source frameworks such as AutoGen and LangChain, and if another framework becomes better, SAP can switch. “It’s how we apply it to the business problem and allow those agents to talk to third-party agents,” he said.

This kind of openness is something SAP has focused on in recent years, and the company is not positioning the new Joule Studio, for example, as a siloed SAP-only development environment. Instead, the company is emphasizing that developers can use the models, coding tools, and frameworks they prefer, including no-code and pro-code workflows, n8n for visual orchestration, and Vercel for React-based front ends. And SAP is putting some money behind this strategy with its investment in n8n, too.

Sid Misra, who leads platform marketing at SAP, described this as SAP going “where the developers are.” Developers can use SAP’s own tools for SAP UI5 and Fiori, or bring in newer web and agentic tools where they fit.

For SAP, that’s all fine, because it still provides the context that grounds all of this work, and without this context, none of these AI agents and tools work all that well.

The data layer behind the agent pitch

This is also where SAP’s recent acquisitions come in. The company announced plans to acquire Dremio to make SAP Business Data Cloud an Apache Iceberg-native lakehouse for SAP and non-SAP data. It also announced plans to acquire Prior Labs, a tabular foundation model startup, and recently completed its acquisition of Reltio for master data management.

All of these make sense in a world where agents need structured business data and process knowledge.

But at the same time, relational data is “not going anywhere,” as Yaad Oren, the managing director of SAP Labs U.S. and global head of SAP Research & Innovation, put it in an interview.

Relational data is, in his words, the “bread and butter of databases,” and ERP and SAP S/4HANA systems are built on it.

Oren acknowledged that tabular models are not as flashy as video models or avatar demos, but for SAP’s customers, they obviously matter far more.

Tabular data models may not be “the most sexy thing,” he said. “But for business, more and more people will understand this is a treasure trove. If you do it right, you can have your enterprise data at scale.”

At Sapphire, SAP introduced SAP-RPT-1.5, the next version of its relational pretrained transformer (hence the acronym) for structured data. The bet is that RPT and the Prior Labs technology it has now acquired can reduce the need to build narrow predictive models for every single task and vertical, while still supporting explainability over rows and columns.

Governance as the core differentiator

Another part of SAP’s overall argument is governance. If every department can now build agents, every enterprise will soon have a compliance problem.

SAP’s answer to this is the AI Agent Hub. It is designed to discover, inventory, and govern SAP and non-SAP agents, LLMs, and MCP servers. The company will include this service for all SAP Business AI Platform customers at no extra charge, clearly indicating that it believes this has been a major roadblock to agent adoption in the enterprise.

One area here that SAP is focused on is ‘agent mining,’ which isn’t exactly a household name yet. Oren described it as an extension of process mining. While process mining gives companies a detailed view of their workflows and transactions, agent mining, as defined by SAP, does the same for agents. It catalogs what they did, what actions they took, where they were bottlenecked, and whether they behaved as expected.

Now, as agents “come to life,” as Oren put it, SAP’s customers need to have a deep understanding of what they are doing, just as they would with their human employees.

This governance message also provides context for SAP’s recently updated approach to API access. SAP recently announced a somewhat more restrictive access policy for its APIs. During the Q&A session, Herzig pushed back on the idea that this new API policy was designed to lock down customer access. He argued that in this new age of AI agents hammering these APIs, there is a new need for rate limits, better API hygiene, and a move away from old channels toward governed protocols like MCP and Agent2Agent.

Muhammad Alam, SAP executive board member for product and engineering, added that raw API access is not the same thing as safely invoking business logic. For SAP, the preferred approach is to expose that logic through orchestration and A2A, thereby preserving compliance, auditability, and statutory requirements.

This complicated SAP’s openness message. On one hand, the company is embracing MCP, A2A, n8n, Vercel, and multiple LLMs. On the other hand, SAP clearly wants the most important enterprise work to happen on an SAP-governed layer.

But maybe that’s ok. Kask, for example, does not expect one vendor to become the universal orchestrator anyway.

“Everyone wants to be like the orchestrator and uber agent. I don’t think anyone’s going to achieve that.”

“Everyone wants to be like the orchestrator and uber agent. I don’t think anyone’s going to achieve that,” he said. “You’re going to have one agent and one orchestrator talking to another agent and another orchestrator and, you know, there may be one or several governance platforms in place.”

Avoiding RPA 2.0

For all the agent talk at Sapphire, SAP’s executives also repeatedly returned to a more basic point: none of this will work well if customers simply bolt AI onto broken processes and messy data. In the Q&A, SAP COO Sebastian Steinhaeuser, for example, warned that companies could otherwise “go with light speed into an RPA 2.0 disaster,” where AI gets layered over broken processes and architecture without real governance.

The post At Sapphire, SAP makes the case that enterprise AI is a context problem appeared first on The New Stack.