As large language models evolve from mere chatbots into autonomous agents capable of reasoning, planning, and acting, they are beginning to orchestrate complex application stacks on their own. 

However, these agents are now encountering their most formidable obstacle: the database.

“Databases pose the hardest and most important challenge for agents, due to their unforgiving correctness and performance requirements,” Andy Pavlo, Associate Professor of Computer Science at Carnegie Mellon University, told attendees last week at the Percona Live 2026 conference here in Mountain View, California, at the Computer History Museum. 

In a discussion on the intersection of AI and open-source infrastructure, Pavlo contended that while coding agents can readily regurgitate standard data structures, the database remains the most difficult part of any system to automate and optimize. 

“For example, if an agent hallucinates a UI component, the page looks slightly off; if it hallucinates a query or a configuration change in a production database, the entire system can vanish,” Pavlo says.

Now THAT would be a cause for alarm.

The multi-agent tug-of-war

Pavlo identifies two primary ways AI is impacting the database world: tuning agents and coding agents. Tuning agents aim to solve the “black magic” of database optimization — automatically adjusting system knobs, physical designs (such as indexes), and query execution strategies. Historically, this required a human database administrator (DBA) to spend years developing the intuition to know which configuration would yield better latency or throughput.

“If an agent hallucinates a UI component, the page looks slightly off; if it hallucinates a query or a configuration change in a production database, the entire system can vanish.”

The challenge is that these specialized agents often operate in silos, Pavlo said. A knob-tuning agent might be unaware of what an index-tuning agent is doing, leading to local minima where the system is better than stock but far from optimal. CMU’s research into multi-round and sequential tuning aims to solve this by creating a coordinating framework, though even this faces a “curse of dimensionality,” Pavlo says.

Carnegie Mellon’s Database Group pioneered the concept of self-driving and machine-learning-driven database optimization. Sequential tuning and multi-round tuning are prime components of their autonomous database management system (DBMS) projects. 

Multi-round and sequential tuning in AI databases refers to advanced machine learning and data engineering methods in which AI models are refined for multistep reasoning, tool use, or complex conversational histories. These frameworks ensure that AI models not only respond in isolated single-turn bursts but maintain context and logic across complex interactions. 

With trillions of possible configuration combinations, the search space for a perfect database is effectively exponential.

The coding agent advantage and the optimizer wall

On the development side, coding agents are already proving to be hyper-productive collaborators. Pavlo observed that at CMU, student submissions for database projects saw a massive spike in lines of code once LLMs were permitted. “The coding agents are very good at building almost every part of a database — B+ trees, hash tables, buffer managers — because they can regurgitate standard implementations found in textbooks and open-source repos,” Pavlo said.

However, the “double black diamond” challenge, Pavlo said, remains the query optimizer. Unlike basic data structures, query optimizers are rarely available as clean, modular open-source references. They are often deeply entangled with the systems for which they were built. Furthermore, proving that an AI-generated transformation rule is semantically correct — meaning it produces the same result as the original query but faster — is an unsolved problem.

Risks include hallucinations and security

The shift toward agentic database management isn’t without significant risk. Pavlo and other industry leaders, such as Percona co-founder Peter Zaitsev, warn that delegating orchestration to agents introduces massive stability and security gaps. There are already documented cases of agents being pointed at a database and accidentally dropping the entire system or leaking sensitive information because they didn’t understand the nuance of access controls, Zaitsev said.

Furthermore, LLMs suffer from so-called AI slop, in which they generate code that is hyper-specialized to a specific query but fails to generalize. For example, if a developer uses an agent to optimize an “Extract Year” clause, the agent might build an internal data structure that breaks the moment the developer tries to enact “Extract Month.”

Automation as a collaborator, not a replacement

Despite these hurdles, Pavlo said he is optimistic about the Agent Operator model. This envisions agents handling the “3 a.m. s***’s on fire” situations — immediate performance anomalies and stability issues — while humans focus on higher-level architectural design. By using Agent Boosting techniques to bootstrap training data from previously tuned databases, the time required to optimize a system can be cut from 12 hours to under 15 minutes, Pavlo said.

In the new AI era, the goal isn’t only to have an AI that writes code, but a system that can reason about its own performance and correctness. Pavlo concludes that the database is the foundation of knowledge for any agent. “If we want autonomous systems, we must first master the unforgiving art of the autonomous database,” he says.

“If we want autonomous systems, we must first master the unforgiving art of the autonomous database.”

The post Autonomous agents have met their biggest challenge yet: The database. appeared first on The New Stack.

The biggest obstacle to enterprise AI isn’t models, data science talent, or even infrastructure.  It’s operations.

Across today’s enterprises, hybrid complexity has outpaced IT’s ability to manage it. Applications, workloads, runtimes, and infrastructure now span on‑premises environments, public clouds, edge locations, and air‑gapped sites. Each layer brings its own tools, vendors, and operational language. The result is friction everywhere and a widening gap between AI ambition and operational reality.

Latha Vishnubhotla, chief platform officer at Hewlett Packard Enterprise, tells The New Stack the challenges begin on Day 2.

“People can bring things up and make them functional very quickly,” says. “But where they spend most of their time is after the infrastructure becomes functional. Day 2 to Day N is where they spend a lot of time.”

That’s the problem enterprises are running into now. It’s not getting infrastructure up and running, but keeping it running, optimized, and reliable as AI workloads move from pilot to production.

Read on to dive into not only the Day 2 problem, but to learn how HPE’s GreenLake hybrid cloud management platform has grown to respond to this enterprise complexity — including that cross-platform infusion of agentic AI. 

Day 2 is when the hybrid cloud breaks down

In hybrid environments, operations teams aren’t managing a single stack. They’re juggling multiple runtimes, from bare metal and VMs to containers and AI‑native platforms.  Infrastructure across compute, storage, and networking often from different vendors. Workloads spread across data centers, public clouds, edge, and disconnected sites.  Legacy systems that were never designed to work together

Each layer has its own management tools and telemetry. When something goes wrong, the symptom rarely appears in the same place as the root cause.

“All these different tiers are talking to each other, but it’s not linear. You have to comb through and figure out where the issue actually is.”

“All these different tiers are talking to each other, but it’s not linear,” Vishnubhotla says. “You have to comb through and figure out where the issue actually is.”

Day Zero provisioning may be fast. Day 2 operations are where complexity compounds and teams burn time reacting rather than optimizing.

More AI is making the ops problem worse

AI not only raises the stakes but also delivers a solution.

Enterprises want to run more AI workloads, but data centers have finite capacity. Power, cooling, cost, and sustainability constraints are real. That’s why FinOps and GreenOps have become inseparable from infrastructure operations.

“When you want to run these workloads, you have to ask: what’s not being used?” Vishnubhotla says. “Why am I wasting here? Should I move something? Should I retire it?”

This is where traditional, human‑driven ops models start to break. There’s too much data, too many layers, and too many dependencies to reason about manually, especially at enterprise scale.

The ops platform as connective tissue

What enterprises need isn’t another point tool. It’s an operations platform that acts as connective tissue across the hybrid estate.

That’s the role GreenLake is designed to play.

GreenLake provides a unified platform experience for running and managing hybrid environments across on‑premises, private cloud, edge, and collocated infrastructure while preserving choice and control. Instead of hiding infrastructure behind abstraction, it makes it visible, observable, and operable from a single control plane.

“The control plane is actually running in the cloud,” Vishnubhotla says. “You get visibility across the entire estate.”

For organizations managing thousands of sites and tens of thousands of devices, that visibility is foundational. But visibility alone isn’t enough anymore.

Why agentic AI changes everything

The next step is agentic AI, AI systems embedded directly into the ops platform, trained on the context of specific infrastructure domains.

A networking agent understands networking. A storage agent understands storage. A compute agent understands compute. Each brings deep, domain‑specific intelligence to Day 2 operations.

“Each layer already has intelligence,” Vishnubhotla says. “If we can connect this intelligence, we can unleash very powerful outcomes.”

That’s where the idea of an agentic mesh comes in. Instead of siloed insights, AI agents share context across layers during provisioning, troubleshooting, and optimization. This shortens the time to root cause, reduces alert noise, and opens the door to predictive and, eventually, autonomous operations.

Predictive maintenance is a clear example. Rather than reacting to failures, AI can anticipate what’s likely to break, prioritize what actually matters, and help teams act before outages cascade.

Faster time to value for AI starts with competent ops

Agentic operations also unlock something enterprises care deeply about: faster AI ROI.

With a shared, platform‑level view, ops teams can answer questions like:

• What is connected to the estate
• Where is infrastructure deployed?
• Who’s using it—and how?
• Where is capacity being wasted?

GreenLake supports automation through copilots and MCP servers as well as UI‑driven workflows, reducing provisioning times and operational overhead. AI agents can even help predict demand and close feedback loops that used to take weeks.

“The bottleneck has always been on the ops side. Enterprises are deploying and operating infrastructure from Day Zero to Day N to unlock AI value faster.”

“The bottleneck has always been on the ops side,” Vishnubhotla says. “Enterprises are deploying and operating infrastructure from Day Zero to Day N to unlock AI value faster.”

The answer is a platform, not another tool

Hybrid complexity isn’t temporary. AI pressure isn’t slowing down. And Day 2 operations are only getting harder.

That’s why the industry is converging on a clear conclusion: the answer isn’t more tools; it’s a unified, intelligent ops platform.

GreenLake brings together visibility, agentic AIOps, and cross‑domain intelligence in a platform built for how enterprises actually run today. It connects the silos, scales operations teams, and turns infrastructure from a bottleneck into an enabler.

If AI is the future of the enterprise, operations is the gatekeeper.  And the ops platform powered by agentic AI is how that future gets unlocked.

The post Why agentic AI makes the ops platform the most important layer in the enterprise appeared first on The New Stack.

Informational and operational technology data have long been treated as separate domains.

But AI changed the game. Today, you need the capacity to regularly ingest OT data into your IT systems without a hitch. (Or a breach.) You risk being left behind as your competitors put all their data to work, or assume the risk of consistently importing data from the edge to your internal systems. 

This problem is an immediate one for any company unwilling to be left behind in the AI era: If you want to take full advantage of AI, you need quick, ready access to relevant data. And if your physical operations have hit a snag, your digital tools need to be kept in the loop regularly.

The solution is not to build a host of custom scripts or depend on legacy FTP or SFTP solutions to bring data in from the edge. Those disparate tools can degrade, leak data, and fail during later, repeated OT data extraction runs.

Instead, engineers looking to free IT and OT data from their respective siloes are turning to a managed solution that offers strong encryption, continuous transfer monitoring, and the ability to fully audit every data handoff across the pipeline

Even more, OT systems — the Programmable Logic Controllers, Supervisory Control and Data Acquisition platforms, and historian databases running protocols like Modbus and OPC UA — were designed for uptime rather than connectivity. In modern architecture, however, no operational data can be left behind.

Getting data out of these environments means working against a connectivity model that was never meant to support the polling frequency or authentication patterns that modern IT infrastructure expects. Adding to the challenge, the more tools you introduce to free the OT data, the more attack vectors they may open.

A breach at the OT boundary can affect the physical systems those networks control. That’s a risk calculus most IT security frameworks weren’t built to handle.

On at 12 p.m. Eastern/9 a.m. On Tuesday, June 23, Fortra’s Jerrod Foster & Michael Barford will join The New Stack to discuss IT and OT systems, why extracting operational technology data is challenging, and how Fortra GoAnywhere MFT can resolve both data movement and data security issues that many engineers face today.

Register here to join the conversation:

What you’ll take away:

• Why the IT/OT boundary is an AI infrastructure problem: How the connectivity gap between operational and information technology creates a hard ceiling for teams building on live operational data — and what becomes possible when that data is reliably accessible inside modern pipelines.
• Where DIY solutions break: Why custom scripts and legacy transfer tools fail under real operational conditions — brittle transfers, no visibility, and attack surfaces you can’t audit.
• What secure OT data movement actually looks like: How Fortra GoAnywhere MFT provides an encrypted, automated, and auditable data movement layer that works with the constraints of real OT environments, not against them.

The post How to get operational data off the factory floor without creating an IT breach 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 Microsoft Build on Tuesday in San Francisco, the company debuted Microsoft Scout, a new personal agent for work that uses your existing tools to understand how you work and proactively handle routine tasks. 

What Scout does

Microsoft Scout — available now for all Frontier customers, with more details and a broader rollout to come later — is built on OpenClaw and WorkIQ, the intelligence layer for Microsoft 365 Copilot.

According to Microsoft, the personal agent will work alongside users’ existing toolsets — think Teams, Outlook, and more.

Scout “understands how you work” and can proactively handle jobs, like resolving scheduling conflicts, preparing for meetings, and other routine tasks, without having to be asked. 

The technology company says Scout “understands how you work” and can proactively handle jobs, like resolving scheduling conflicts, preparing for meetings, and other routine tasks, without having to be asked. 

Why now?

In its release, Microsoft says it believes “your agents should reflect how you think and operate,” taking into account the broader scope of your work environment, including workflows, business logic, and institutional knowledge — and notes that this context should extend to always-on, autonomous agents. 

Microsoft Scout is only available to Frontier customers. Microsoft says it will share more information soon as part of a broader roll-out. 

Scout’s debut comes alongside a slew of other announcements from the company as it kicks off its two-day Build conference, including: Microsoft IQ, a new context layer that grounds agents in enterprise and world knowledge, available today across GitHub Copilot, Microsoft Foundry, and Copilot Studio; WebIQ, an AI-first web search stack and what Microsoft calls “the fastest real-world grounding you can give your agents”; plus, a family of seven new in-house models from the Microsoft AI Superintelligence Team, including the company’s first reasoning model, MAI-Thinking-1. 

At Build, Microsoft stressed the changing tides of the new agentic era, noting developers now need “ubiquitous intelligence” and a full stack that supports them from the cloud to the edge. If Scout can understand how teams work and provide proactive support for at least some day-to-day tasks, then it could play a supporting role in helping teams build agentic systems faster. 

The announcement of Scout comes after recent leaks of Google’s Remy, an OpenClaw-style agent the tech giant is rumored to be developing that can perform actions on a user’s behalf. Remy is suspected of serving as a Gemini-powered personal agent. It’s too early to tell whether and how Microsoft Scout compares to the rumored Remy, but the limited information available suggests both companies are moving toward personal agents that go beyond answering questions or summarizing content. 

The post Microsoft debuts “Scout” at Build, a new personal agent for work 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.