Kubernetes teams automate deployments without thinking about it. CI/CD pipelines fire dozens of times a day, autoscaling adjusts replicas in the background, rollback is muscle memory. But there is one category of automation where that confidence vanishes: letting a system change CPU and memory requests on a running workload without a human reviewing it first. 

And as AI inference lands on Kubernetes at scale, that hesitation is becoming hard to ignore, and increasingly expensive.

Why teams trust automation for change but not for constraint

We surveyed 321 Kubernetes practitioners at enterprise organizations earlier this year. The headline finding is one most practitioners will recognize immediately: 82% report high or complete trust in automated delivery controls. But 71% still require human review before applying resource optimization recommendations. Only 27% allow CPU and memory changes to be auto-applied, even within guardrails.

“Deploying code feels additive… rightsizing feels subtractive because you are removing safety margin from a running service, and the failure mode is fundamentally different.”

Those numbers describe a specific asymmetry. The same engineers who deploy to production dozens of times a day without hesitation slow down the moment automation wants to adjust resource allocation. And the survey data make it clear why. Deploying code feels additive. You are shipping new value, the rollback path is well understood, and if something breaks you usually see it right away. Meanwhile, rightsizing feels subtractive because you are removing safety margin from a running service, and the failure mode is fundamentally different.

As one practitioner in the survey put it: “Automated right-sizing carries a unique risk because it directly impacts the underlying stability of the application runtime. Unlike a code deployment that follows a tested path, resource changes alter the invisible contract between the workload and the scheduler.”

When you change resource requests, you change how Kubernetes schedules, prioritizes, and allocates resources. Those effects are not visible the way a code change is. You can’t trace them through a deployment pipeline. And you might not discover that something went wrong until two weeks later, when a traffic spike hits a threshold that didn’t exist at the old values. By that point, three other things have changed too, and proving causation is nearly impossible. The people responsible for those workloads are the same people who get paged at 2 a.m., and they know this.

Why AI workloads raise the stakes

That trust gap existed before inference workloads showed up. What’s changed is the cost of not closing it.

For a long time, teams could absorb the cost of manual oversight. They knew their workloads, had intuition for where the safe boundaries were, and the inefficiency of over-provisioning was a price worth paying for stability. GPU-accelerated inference workloads change that math. GPU compute is significantly more expensive per hour than CPU. The cost of over-provisioning is no longer a rounding error you can absorb quietly. And the workload behavior is less familiar, as inference jobs are bursty in ways teams haven’t built intuition for, traffic patterns shift as models are updated and usage changes, and the resource dimensions involved differ from what teams have spent years learning to tune.

That unfamiliarity compounds with scale. Rightsizing isn’t a one-lever problem the way horizontal scaling is. It involves, at minimum, CPU and memory requests and potentially limits for both, with four dimensions per workload, multiplied across hundreds or thousands of workloads per cluster. The survey data indicates that manual optimization breaks down at around 250 changes a day. Inference workloads push teams past that threshold faster than anything they’ve managed before, because the resource decisions are more frequent and the cost of getting them wrong is higher.

The economic case for automated rightsizing has never been stronger. The organization’s willingness to delegate hasn’t caught up because teams are being asked to trust automation with workloads they don’t yet have a track record with.

What the survey says about closing the gap

When we asked practitioners what would actually increase their trust in optimization automation, 48% said visibility and transparency into how decisions are made, 25% wanted proven guardrails, and 23% needed instant rollback.

Nobody asked for full manual control and very few asked for blind autonomy. What they described is automation that earns trust in stages, and that’s consistent with how the teams furthest along in their automation journey actually got there. They didn’t start with production. They started with a single namespace in a dev environment, observed the system’s behavior, compared recommendations with outcomes, and gradually expanded the scope. Different environments remained at different levels of automation maturity simultaneously, and that was intentional. Production carried more scrutiny than dev.

CI/CD followed the same curve, and the timeline is easy to forget. Most organizations took years to get from running their first automated pipeline to trusting it with production deploys without manual approval on every commit. Kubernetes resource automation is earlier in that same process, and AI workloads are extending the timeline because teams are building trust from scratch with a workload category that doesn’t yet have a track record.

Why automation design matters as much as capability

Some automation architectures deliver meaningful value only with full delegation. The system needs complete control to function the way it was designed to. That’s a form of forced autonomy, and it creates an adoption problem because it asks for exactly the level of trust that most organizations haven’t built yet. Force generally doesn’t work. Teams that feel pushed into a level of delegation they aren’t comfortable with tend to pull back entirely after the first incident.

The alternative is what I’d describe as adaptive autonomy: designing the system to work at every stage of the trust curve. A team still evaluating gets useful recommendations in read-only mode. A team ready to act but wanting boundaries can run guardrailed execution within limits they define. As confidence grows, the system handles more decisions autonomously while humans manage exceptions. And for environments where the track record supports it, closed-loop optimization runs in the background and becomes boring, which is the goal. Each stage is a legitimate operating mode, not a stepping stone you have to rush through.

That design distinction matters more with AI workloads than it ever did with traditional services, precisely because the trust-building process is starting from zero on workloads where the cost of getting it wrong is highest.

“Trust takes a long time to build and a single production incident to undermine.”

The other piece that makes this sustainable is rollout safety. Trust takes a long time to build and a single production incident to undermine. Start with the workloads showing the most headroom between requests and actual usage. Make changes incrementally, small enough that a bad outcome stays contained. Rollback needs to be fast and tied to the health signals the team already monitors. And start with opt-in, not opt-out. Let the teams willing to go first build a track record that others can look at.

The broader pattern

The 71% figure is sometimes read as resistance to automation. I think it’s a more accurate picture of how operational trust actually forms: conditional, earned over time, and moving at different speeds depending on what’s at stake. AI workloads are raising those stakes significantly, which means the path to trusted automation matters more now than it did when the cost of caution was just some unused CPU.

“Most of what gets written about Kubernetes optimization focuses on tooling capability, and the tooling is capable. The harder problem is the human one.”

Most of what gets written about Kubernetes optimization focuses on tooling capability, and the tooling is capable. The harder problem is the human one. If your team is managing AI inference workloads on Kubernetes and your optimization tooling is sitting in read-only mode, the question worth asking isn’t whether to trust the system. It’s whether the system is designed to let you build that trust gradually, starting where the stakes are low and expanding as the evidence supports it, on workloads where getting it wrong costs more than it ever has before.

The post Kubernetes teams trust automation to ship code but not to touch CPU, and AI is raising the stakes appeared first on The New Stack.

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

But speed without control is a liability.

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

“Speed without control is a liability.”

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

Agentic adoption outpaced governance

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

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

Agentic engineering needs agentic infrastructure

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

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

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

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

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

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

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

What’s next

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

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

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

The 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.

How much of Nvidia is reflected by their visionary CEO, Jenson Huang? With his praise and later support of OpenClaw, Huang took a big step beyond the corporate boundary to embrace the “bad boy” of the agent world. Where exactly does Nvidia fit in here?

The New Stack put that question to Nader Khalil, Director of Developer Technologies at Nvidia, as well as how Nvidia is working with developers on agentic AI projects.

Khalil, co-founder of Brev.dev, found himself acquired by Nvidia about two years ago. His company helped startups access Nvidia AI chipsets. He is still excited by the possibilities of AI, and his energy is proof that Nvidia is enjoying the moment. Khalil was expansive, showing a startup’s keenness for the pace of change around them.

Before anything else, Khalil defines what he believes an agent is. “I have some slides,” he threatens. But these are more to organize his thoughts on an oft-asked question- not an attempt to lecture.

“An agent is an LLM and a harness… Each loop should take us closer to our goal.”

“An agent is an LLM and a harness. And if you think about that, it involves two things. It involves the loop and the LLM. And obviously you don’t want each loop to do the same thing. You want to leverage the results from the LLM. That might include reasoning on new tools to use. Each loop should take us closer to our goal.”

Nader praises the early OpenAI initiative. “So ChatGPT innovated outside of the model. It was not just a great model they made; they also added prompts. There was a system prompt and then the user prompt; there was multimodal, and suddenly that felt really good as a way for me to use the LLM. Every user could benefit from a system prompt that OpenAI had written while you were using your individual prompt.” Khalil continues, “Then they added memory.”

“Suddenly my assistant became really useful because it remembers things about me. ChatGPT knows that I really like to barbecue. So when I ask a question, it remembers what my smoker is,” recalls Khalil. “The thing that I was missing was files.”

Of course, the story continues through Cursor to Claude. “But this is the harness. Everything here is the harness,” he says.

Khalil moves on to how Nvidia works today. “The way to get your product into this rapidly growing market is with skills. Hence the CUDA X library.”

These are the implementations of use cases that target GPU acceleration, usually for compute-intensive applications.

“And so we look at every product we build now, it needs to have a skill because you need to cater to this growing audience,” he says.

This is how Nvidia first works with in-house experts, and connects to their edge hardware.

Supporting OpenClaw

Khalil was happy with the wording that Nvidia are “supporting” OpenClaw. “We’re just squarely in the community”, agrees Khalil. “We do this by the way, through a lot of projects that are very important in the open source ecosystem.”

But OpenClaw is not just any project and could be considered quite a risk to associate with. “We have a couple of developers at the company that contribute to OpenClaw full time.” Pushed on the nature of the relationship a little more, Khalil offers, “I think we just try to contribute wherever we can. I think what’s very clear is that harnesses had a moment, right?”

“We have a couple of developers at the company that contribute to OpenClaw full time.”

It has been quite a moment. “There is a lot of change happening right now, and we’re really thankful to [Peter Steinberger], OpenClaw, and the community for creating this moment around agents and harnesses. We of course want to contribute.”

Related to this, the OpenClaw project currently has many unresolved pull requests (PRs). In fact, there were rumors that new PRs are no longer accepted at all.

“We saw Peter tweeting about some of the issues they had, and we just rolled up our sleeves and were eager to help. They bless us by allowing our contributions.”

“You know,” says Khalil, “We saw Peter tweeting about some of the issues they had, and we just rolled up our sleeves and were eager to help. They bless us by allowing our contributions.”

Khalil reflects on things a little more: “You know the cardinal rule of code. It is easier to write than it is to read.”

And at over 800,000 lines of code, this must be true. Khalil continues, “It is easier not to have to process this complicated codebase, but every successful project right now has the same issue. It is easier to enlist many agents to help write code and build these PRs. The bottleneck is in merging the PRs through.” As well as dealing with the fallacies.

“OpenClaw was a major change for the industry. It was a huge moment, and everyone’s eyes are on it. It got more stars than Linux in months. Developers care deeply about the project because it was influential, and so I think you’re gonna see a mountain of PRs, right?”

“It got more stars than Linux in months… so I think you’re gonna see a mountain of PRs, right?”

Their attitude to OpenClaw is clearly to accept its problems, like that raucous friend who seems to wind up in police custody after a wild party, but is good at heart.

Blueprints and microwaves

Hermes is one of the newer projects in the wake of OpenClaw (like NanoClaw) that wants to bottle the lightning but in a safer way. Nvidia is also embracing it, but Khalil backs up to explain how Nvidia looks at projects in general.

“So, NemoClaw is our blueprint. When we see amazing harnesses, we try to figure out how we can help enterprises adopt them. Consumers sometimes want the security to run any agent; then there’s the model and harness. Then there are the skills, right. You have to give it access to your terminal.’

The term “blueprint” takes on a bit more formality in Nvidia, meaning the structure for building AI agents and systems. And of course Khalil needs to show these working with the Nemotron model and other Nvidia solutions.

“There’s a blueprint for Hermes and a blueprint for OpenClaw”. It sets up the runtime, enables the policies if there’s a local GPU, and runs the model.

Working with agents in the enterprise is seen as a significant risk. “There are a bunch of camps,” says Khalil. “There are teams within enterprises who are more worried. We have a project called OpenShell that is our security runtime and we’ll work with.”

“Our goal is to create the tooling that’s needed in the ecosystem. Developers in industry and enterprises have actually been adopting agents. And we have been building for this audience. One way to do so is to build a specialized agent or a sub-agent. “

So Nvidia doesn’t offer a big takeover solution, but fits in with where teams already are.

Your microwave, your agent

“The way to think about it is like when you use a microwave that you haven’t used before, you have to press a lot of buttons or spend time figuring it out. But when it’s your microwave at home, you just go ‘Boop, boop. Done.’ Right?”

“So every industry in enterprise will be building these specialized agents, and many already have. Nvidia is already working with CrowdStrike and Cadence, Palantir, among many others.”

The future will be agents

Khalil believes a lot of the concern over long-running agents is slowly petering out. Which leads to the final question: is Nvidia looking to stay in the open sea where there may be dragons, or become a calm port for developers to work in?

“So our approach is: Who can we help and how?” Khalil shows no fear, or lack of sea legs. “The inflection point happened months ago, so we ask what can we do to usher in all of this technology.” Here, Khalil ties his — and, to a degree, Nvidia’s — future to green-field developers.

“There are gonna be some people quick to adapt. And some people that aren’t; and what we’re noticing, if you look at the adoption curve, many people have yet to experience this. So there’s much work in helping make sure that we deliver this safely.”

The post “An agent is an LLM and a harness”: What Nvidia really thinks about OpenClaw appeared first on The New Stack.

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

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

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

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

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

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

The Origin origin story

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

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

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

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

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

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

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

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

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

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

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

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

A post-GitHub world?

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

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

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

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

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

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

“Tokens are a better metric than commits.”

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

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

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

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

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

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

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

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

— Mitchell Hashimoto (@mitchellh) December 19, 2025

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

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

— Mitchell Hashimoto (@mitchellh) June 16, 2026

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

The model is the moat

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

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

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

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

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

Introducing Composer 2.5, our most powerful model yet.

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

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

— Cursor (@cursor_ai) May 18, 2026

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

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

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

Inference is now the dominant force in enterprise AI — and with it has come an inconvenient reality: Data is almost always transported to compute. Every inference call moves sensitive enterprise information out of the systems where it lives and into external environments optimized for GPU throughput rather than data governance. This creates friction that compounds at scale: rising costs, expanding security exposure, and a growing tangle of data copies that drift out of sync with operational reality.

What enterprises actually want is different: to keep data and IP intact within the database rather than creating multiple copies and managing the resulting inconsistencies.

Research across more than 2,050 senior executives from major enterprises worldwide suggests that 95% of organizations intend to become their own AI and data platforms within the next 780 working days. Yet only 13% have successfully reached that goal. The organizations that have succeeded are achieving almost five times the return on investment of those still struggling to operationalize AI.

What separates the leaders from the followers is not model quality. It is infrastructure strategy.

The most successful organizations have adopted a sovereign-by-design approach. More than 75% are operating across multiple clouds and on-premises environments rather than relying on a single hyperscale provider. They are building AI around their own business, regulatory, and operational requirements rather than adapting those requirements to fit a cloud vendor’s architecture.

As AI moves from experimentation into production, CIOs are discovering that training models is relatively easy. Running them efficiently, securely and compliantly across thousands of operational workloads is where the real challenge begins.

The shift from training to inference

Training is a discrete event. Inference is an ongoing business process.

A model may be trained once, but it could be called millions of times each day. Every fraud assessment, insurance claim review, customer service interaction, medical recommendation, sanctions check, or predictive maintenance event relies on inference occurring against live operational data.

“What separates the leaders from the followers is not model quality. It is infrastructure strategy.”

This distinction fundamentally changes enterprise infrastructure requirements.

Training workloads prioritize compute density and GPU availability. Inference workloads prioritize latency, governance, reliability and cost control. They must operate where business data resides and where compliance requirements can be enforced.

For heavily regulated industries such as financial services, healthcare, telecommunications, energy and the public sector, inference cannot simply occur in whichever region offers the lowest compute cost. Data sovereignty requirements, audit obligations and security mandates often dictate exactly where workloads must execute.

The challenge therefore becomes much larger than AI itself. Organizations need an operating model capable of bringing together compute, data and governance without sacrificing flexibility.

Why neoclouds are emerging as a critical layer to cross the chasm to production

This is where neoclouds have become increasingly important.

Unlike traditional hyperscalers, neoclouds are purpose-built around AI infrastructure. Their focus is not delivering hundreds of generic cloud services but rather optimizing for GPU access, AI performance, and flexible consumption models.

For many enterprises, neoclouds offer a compelling answer to the growing demand for specialized AI compute. They provide access to the latest accelerator technologies while enabling organizations to scale workloads without the complexity often associated with large cloud environments.

“The future of AI architecture therefore depends on bringing models closer to data rather than moving data closer to models.”

However, neoclouds solve only one part of the enterprise AI equation.

AI does not create value in isolation. Models require context. They need access to customer records, transaction histories, operational workflows, policy documents, supply chain information and enterprise knowledge. Moving these assets into separate AI environments creates duplication, latency and governance challenges.

The future of AI architecture therefore depends on bringing models closer to data rather than moving data closer to models.

Why Postgres has become the enterprise AI foundation

As organizations look for a common platform that supports both operational and AI workloads, Postgres has emerged as a natural foundation.

Postgres already serves as the operational backbone for many of the world’s most important applications. It combines transactional reliability, extensibility, and scalability with the openness that enterprises increasingly demand. 70%+ of AI-related application development is happening on Postgres.  

What makes Postgres particularly relevant in the AI era is its ability to become more than a database. It can serve as a governed memory layer for AI systems, integrating operational data, application context, permissions, observability, and retrieval capabilities into a single architecture.

This dramatically reduces complexity.

Instead of maintaining separate infrastructures for transactional systems, vector stores, AI memory layers, and governance frameworks, organizations can consolidate around a trusted operational platform that already supports their mission-critical workloads.

For CIOs seeking to balance innovation with control, this architectural simplification represents a significant strategic advantage.

Why sovereignty matters more than ever

Sovereignty has become one of the defining themes of enterprise technology.

For banks, sovereignty means maintaining control over financial data and regulatory obligations. For healthcare organizations, it means protecting patient information while enabling innovation. For governments, it means ensuring national and citizen data remains under appropriate jurisdictional control.

The rise of AI has amplified these concerns.

Organizations increasingly need assurance that models, data, policies and operational controls can remain within designated environments while still benefiting from advances in AI technology.

This requirement is driving demand for sovereign AI architectures capable of operating across clouds, private infrastructure and on-premises environments.

The challenge is creating consistency across these environments without introducing operational complexity.

EDB Postgres AI: connecting sovereign data and sovereign AI

EDB Postgres AI addresses this challenge by bringing together operational Postgres, AI capabilities and hybrid infrastructure management into a unified platform.

Rather than forcing enterprises to choose between innovation and control, EDB Postgres AI enables organizations to deploy AI where their data already resides. Through capabilities spanning operational databases, analytics, agentic AI workloads and hybrid management, organizations can create a consistent operating model across sovereign environments.

This approach is particularly relevant for regulated industries where moving sensitive information into external AI services may introduce compliance, security or governance concerns.

By enabling inference close to operational data, organizations reduce data movement, improve performance, and strengthen their compliance posture. At the same time, they maintain the flexibility required to leverage emerging AI technologies and modern infrastructure models.

“By enabling inference close to operational data, organizations reduce data movement, improve performance, and strengthen their compliance posture.”

The result is a platform that aligns with the realities of enterprise AI rather than the assumptions of consumer AI.

“The reality is that the new AI at scale world needs a new infrastructure. That isn’t just the compute; it’s the governance, heuristic data access and level of observational and orchestration control that are absolute, governed, agile and work for humans and agents.”  Nancy Hensley, CPO, EDB

The new enterprise AI stack

The emerging enterprise AI architecture is increasingly built around complementary rather than competing technologies.

Infrastructure layer	Primary role	Strategic value
Neoclouds	Specialized AI compute and GPU infrastructure	Access to cutting-edge AI acceleration and flexible scaling
Public Hyperscalers	Broad cloud services and global reach	Ecosystem breadth and service diversity
Postgres	Operational data foundation	Trusted, governed and scalable enterprise data platform
EDB Postgres AI	Sovereign AI and hybrid management layer	Enables AI, analytics and operational workloads to run consistently across sovereign environments
Enterprise Governance	Security, compliance and policy controls	Ensures AI aligns with regulatory and business requirements

Together, these layers create an architecture capable of supporting the complete AI lifecycle—from experimentation and model training through production inference and continuous optimization.

The CIO imperative

The organizations realizing the greatest value from AI are no longer asking how to train better models. They are asking how to operationalize AI across the enterprise while maintaining control over cost, governance, and risk.

Their answer is increasingly consistent.

They are adopting multi-cloud and hybrid strategies rather than relying on a single cloud. They are prioritizing sovereign architectures rather than centralized data movement. They are building around open operational foundations rather than proprietary lock-in. Most importantly, they are recognizing that AI success depends on bringing intelligence to data, not data to intelligence.

Neoclouds provide the compute layer required for modern AI. Postgres provides the operational foundation required for trusted enterprise systems. EDB Postgres AI connects these worlds through a sovereign architecture designed for the realities of regulated industries.

As AI transitions from experimentation to operational necessity, the winning enterprises will be those that can make inference secure, governed, low-latency, and economically sustainable at scale.

In the next era of enterprise AI, the greatest business value will not come from model selection or raw GPU access. It will come from infrastructure strategy built around data — keeping intelligence close to where data already lives, governed, trusted, and ready to act.

The post Neoclouds, sovereign AI and Postgres: The new operating model for regulated enterprises appeared first on The New Stack.

For most of its 30-year history, Postgres has been viewed as a transactional database. Organizations trust it with customer records, financial transactions, and countless other operational workloads. Its reputation was built on reliability, strong transactional guarantees, and a vibrant open-source community that has spent decades refining the database without compromising its foundations.

However, some of the most important innovations in the Postgres ecosystem today have little to do with storing data. They have to do with reducing the need to move it around.

“Some of the most important innovations in the Postgres ecosystem today have little to do with storing data. They have to do with reducing the need to move it around.”

Database innovation has historically focused on performance, scalability, and reliability. Increasingly, the harder problem is interoperability: how operational data can be shared across analytical systems, AI applications, and downstream services without creating yet another pipeline or copy.

Why Postgres keeps showing up

The reality of modern software architecture is that data rarely stays in one place. Information created in operational systems quickly finds its way into warehouses, search platforms, machine learning environments, and AI applications. Every new system solves a legitimate business problem, but it also creates another destination for data and often another copy to maintain.

The costs of this approach extend beyond infrastructure spending alone. Every additional copy introduces latency, creates another potential source of inconsistency, and increases the operational burden of keeping systems synchronized. Many organizations now spend as much effort moving data as they do storing it.

“Many organizations now spend as much effort moving data as they do storing it.”

For many businesses, Postgres serves as the system of record for customer interactions, transactions, application state, and other business-critical information. As organizations expand their analytical, machine learning, and AI capabilities, they are not looking to create another source of truth; rather, they’re looking for better ways to work with the one they already trust.

That shift is changing how Postgres fits into modern architecture. Historically, Postgres was viewed primarily as the place where operational data originated before being copied into downstream systems. Increasingly, organizations want those systems to work more seamlessly with operational data while reducing the pipelines, copies, and synchronization processes required to support them.

Technologies such as logical replication, change data capture, and foreign data wrappers have helped Postgres participate more directly in larger data ecosystems. As a result, organizations are no longer asking only whether Postgres can store their data. They’re instead asking how easily it can connect to everything around it.

That shift, from evaluating databases primarily on storage and performance to evaluating them on interoperability, may be one of the most important changes happening in the Postgres ecosystem today.

AI is exposing old problems

The recent focus on AI has brought renewed attention to data movement. AI didn’t create the problem. If anything, it exposed a limitation that has been quietly growing for years. For decades, organizations built architectures around the idea that data would move between systems through pipelines and periodic synchronization. That model worked because most analytical workloads could tolerate some degree of delay.

AI is changing those expectations. Many AI applications depend on access to current operational context. The challenge is not that organizations lack data. In many cases, they already have it. The challenge is that the data is spread across multiple systems, each with its own copy, latency profile, and synchronization process.

“AI is forcing organizations to confront a broader question: How many copies of the same data are actually necessary? The answer increasingly appears to be fewer than most architectures maintain today.”

As a result, AI is forcing organizations to confront a broader question: How many copies of the same data are actually necessary? The answer increasingly appears to be fewer than most architectures maintain today. As expectations around freshness rise, reducing unnecessary data movement becomes just as important as accelerating it. The underlying challenge is not new. AI has simply made it harder to ignore.

What’s next

The database industry spent decades solving storage. Databases became more reliable, storage became cheaper, and infrastructure became dramatically easier to operate. The next challenge is not where data lives, but how easily it can be shared across systems without introducing additional pipelines, copies, and synchronization overhead. Increasingly, the goal is not simply moving data faster. It is reducing unnecessary movement altogether.

Postgres has a habit of outlasting predictions about its replacement. For years, members of the community have joked that every year is “the year of Postgres.” The joke works because it keeps turning out to be true. 

Three decades after its creation, Postgres continues to adapt to new workloads, new architectural patterns, and new ways of building applications.

That longevity is not an accident. Enterprises continue to rely on Postgres because it provides a stable and trusted foundation for operational data.  While that foundation is unlikely to change, the scope of what organizations expect Postgres to do will continue to expand.  

As new workloads continue to emerge, much of the innovation will come through extensions that expand Postgres’s capabilities without sacrificing the stability that made it successful. In that sense, the future of Postgres may not be about reinventing the database itself, but continuously expanding what can be built on top of it.

The post The database storage problem is solved. Here’s what comes next. appeared first on The New Stack.

AI consumes a lot of data, but all-you-can-eat data in the world of agentic intelligence eventually loses its flavor. Simply increasing the sheer volume of databases, data repositories and data volumes does not necessarily enrich any given AI function’s ability to reason. 

Context, on the other hand, does.

We know that agents are only as intelligent as the context they have access to. In order to codify the inclusion of context into algorithmic logic for AI, technology vendors have extolled the virtues of using a knowledge graph to make their data more useful for agentic purposes.

AWS knows this story all too well. The organization’s sprawling datacenter footprint hosts vast pools of context on behalf of its customers, but that context often sits in a raw and unstructured form across data lakes, data warehouses, data lakehouses, databases, and data streams. It also permeates through the rarely-documented institutional knowledge that agentic engines rarely get access to.

All of which explains why the cloud giant used its AWS New York Summit today to introduce AWS Context, a new service that automatically maps the relationships that exist across a firm’s existing data into a knowledge graph and provides agentic search so AI agents in the organization can access what are governed data relationships, business rules, and domain knowledge at runtime. 

But weaving all this together is hard work. Knowledge graphs need more than simple keyword matching to work; they require structural and semantic traversal. This means they need to make multiple hops across various information silos and repositories so that they can aggregate context and (for example) be able to explain why cybersecurity vulnerability A is a factor of system compromise B, which has a core dependency link to codebase C, which executes in application D and risks taking users X, Y and Z offline. So how is AWS doing this?

A data lake of nuance & information

Mai-Lan Tomsen Bukovec, AWS vice president of technology (data and analytics) tells The New Stack that AWS Context provides a “data lake of nuance and information that AI agents swim in” to reason correctly and make the right decisions for the business. 

“This is no different from how humans work. When we take action, we depend on our own context about the domain, prior decisions and their outcomes, and other information.” – Mai-Lan Tomsen Bukovec, AWS.

“This is no different from how humans work,” Tomsen Bukovec says. “When we take action, we depend on our own context about the domain, prior decisions and their outcomes, and other information. With AWS Context, AI agents have all the nuance of every form of data in their business in a knowledge graph and in open data formats. AWS Context will make the difference between an AI agent simply taking an action versus making the right decision.”

Given the option to embrace this new service, software engineers will need to set out a plan of action and work out what to do first. For AI developers and data science professionals, this throws up the question of what to prioritize first when preparing existing enterprise data for context-aware agents using AWS Context capabilities and how they can control what data is (and isn’t fed) into the mouth of the beast.

Mercifully, it appears, options for control appear to exist.

“If developers want to exclude information from AWS Context, they will have the ability to prevent certain datasets, like test data or sandbox environments, from being included with AWS Context,” explains Tomsen Bukovec. “Because AWS Context is continuously updated as relationships between data resources changes, AI agents have the latest context available without any intervention from AI developers – and the control to set guardrails to exclude content that agents should not take action upon.”

Should developers trust this technology?

AWS Context extends the same knowledge graph technology that runs Amazon Quick, the organization’s AI work assistant that “connects scattered work” across applications and resources, including Slack, Microsoft Teams and Outlook, CRMs, databases, and documents.

So, should software developers place their trust here? After all, even once captured and connected, not all business context is useful. Some contextualizations could be corrupted, weak, fragmented and not productively useful for the business? Is AWS at risk of encapsulating context without considering how the data that comprises it is is quantified in terms of business usefulness?  

AWS has thought of this factor.

Because AWS Context uses the same knowledge graph technology that powers Amazon Quick, it can learn from usage patterns to make every interaction smarter. With AWS Context, the company says it is extending what was a personal knowledge graph into an organizational one i.e. a shared, governed context layer that agents and applications in an organization can draw from.

“Developers can govern and shape a dynamic and intelligent context layer that AI agents depend on to make the right decisions – AI agents won’t just get smarter as the models improve – they will be smarter because they have a vast amount of curated context at their fingertips.” – Tomsen Bukovec.

“AWS Context provides a data lake of context in graph and open data format,” clarifies Tomsen Bukovec. “That means that AI developers everywhere can use capabilities at the data layer to govern and shape a dynamic and intelligent context layer that AI agents depend on to make the right decisions. With this change, AI agents won’t just get smarter as the models improve – they will be smarter because they have a vast amount of curated context at their fingertips.”

Curated knowledge beyond a user’s personal graph

Existing Amazon Quick users will see that when AWS Context is enabled, Quick’s agents gain access to the broader enterprise knowledge graph, including cross-system relationships, business rules, and curated context that go beyond what any single user’s personal graph can provide. 

Tomsen Bukovec has also said that AWS Context gets smarter the more agents use it. As agents query the graph, it observes which sources produce correct results, which join paths agents rely on, and which curated rules get applied. It ranks sources by actual usage and shares what it learns across an organization, so when one agent discovers a correct join path or resolves a schema ambiguity, other agents pick it up, without requiring a human to re-curate the graph.

Any agent you put into production raises a governance question: what data can it reach, and can you show exactly what it accessed and under whose authority? The organization has explained that AWS Context answers both by making every query identity-aware.

Each call is designed to inherit the calling user’s identity access management (IAM) and Lake Formation permissions, so an agent can only see and traverse the relationships its identity is authorized to access. Because access runs through identity, every interaction is auditable. Security and compliance teams can verify what an agent accessed and under what authority, using the same controls.

AWS Glue Data Catalog

Related news to the arrival of AWS Context today saw the company also announce the preview of business context and semantic search functions for AWS Glue Data Catalog, the company’s centralized metadata repository for all data assets across various data sources. The new functions are designed to make it easier for humans and AI agents to discover and understand data. 

Also in this product stream, AWS now offers offer a preview of skill assets in Glue Data Catalog, a service designed to allow “data producers” (a somewhat arbitrary term that AWS applies to anyone who creates data, but is most likely a DBA or developer) to create skill assets. 

Associating skill assets to data assets gives agents additional context and instructions they can retrieve progressively for working with specific data without re-teaching it to every agent one prompt at a time. 

A renaissance of context engineering

Will this new drive from AWS herald the birth (or perhaps renaissance, the industry has been talking about this approach for some time) of context engineering as a sub-discipline of data science? It may well do… and if it does, it will likely drag role-based multi-agent orchestration along into the fray with it as we weave ever more complex interrelationship structures through enterprise data stacks.

If AWS or indeed the other hyperscalers or major frontier model companies starts acquiring more multi-model graph structure companies and vector database specialists, that could be the sign that things are cementing around context engineering at large. 

In the meantime, developers setting sail on the contextualized data lake of nuance are advised to wear a life jacket.

The post “A data lake of nuance for AI agents to swim in”: AWS Context gets shipshape on reasoning  appeared first on The New Stack.

AI is already inside most enterprises’ IT stacks, but it’s had a somewhat shambolic and unsystematic early adolescence. Employees use personal tools, teams adopt different models, different company departments get forced into corners by vendors who push closed stacks, and agents are beginning to act inside systems that were built for people. 

That makes AI invisible, fragmented, and hard to change later. 

AI access and control platform company Tailscale announced on Tuesday the results of its work to address and redress these imbalances with new capabilities for Aperture, the company’s flagship toolset designed to provide a stable layer for managing AI across changing models, tools, data sources, and agents.

Designed to enable software developers to control and orchestrate the arguably almost too-dynamic state of AI, Aperture now offers a new chat interface, universal data connectors for both MCP and APIs, and sandbox support. 

What makes agents useful, also makes them risky

Avery Pennarun, CEO and co-founder of Tailscale tells The New Stack that the “same mechanics” that makes AI agents useful also make them risky i.e. they can do in seconds what would take a person dozens of clicks, commands, and context switches. 

But he advises that the risk factor here is not really a matter of pitting humans against agents and trying to place one above the other in terms of potential fragility. He says that the real risk is “giving any actor too much room” to act without clear boundaries.

“With agents, that risk moves faster,” Pennarun says. “With humans, the weak point is often the control model itself. If security depends on a developer approving a long stream of prompts, they will either get slowed down or hit approval fatigue and start approving things by reflex. That is not much of a security model.”

“Agents need boring infrastructure around them – robust identity management, limited access controls, carefully tracked logs, and sandboxes – that boring outer shell is what lets them do useful work without making every developer’s laptop the place where all the risk lands,” Avery Pennarun, Tailscale CEO.

Interestingly, agents need boring infrastructure

For Pennarun, the answer lies in making sure agents have what he calls “boring infrastructure around them”, by which he means robust identity management, limited access controls, carefully tracked logs, and (where necessary) sandboxes to execute in before they are exposed to mission-critical datasets, applications, or both.

“That boring outer shell is what lets them do useful work without making every developer’s laptop the place where all the risk lands,” Pennarun clarifies. “The answer is not agentic control or human control alone. Humans set the policy and boundaries up front. Infrastructure enforces them. Agents operate inside them.”

Aperture can be defined as a centralized AI gateway built to monitor and route LLM requests in a secure manner using Tailscale’s identity layer to automatically authenticate “users” (a cohort which we now obviously expand to include both humans and machines), eliminating the need to distribute API keys to authenticate with each AI model.

The gateway holds the API keys securely, meaning that when a developer (or a container) makes a request, Aperture verifies who they are via their Tailscale identity and then automatically routes requests to upstream LLM providers such as OpenAI, Anthropic, and Google without requiring changes to existing tools or workflows.

Yeah, we use AI, dunno where

Given the amount of work-related activity currently happening on personal and free AI accounts, we might suggest that concerns here are validated i.e. organizations today can not see, govern, or recover the information streams at this level. Research cited by Axios found companies typically have 67 generative AI tools running across their systems, with 90% lacking proper licensing or approval. 

Tailscale has reemphasized the fact that AI providers are bundling models, chat interfaces, data access, and execution environments into closed stacks. Those bundles can make the first deployment easier, but they can also leave organizations locked into one provider’s models, tools, and roadmap and pricing. In a market where model quality, speed, and cost keep changing, that lock-in can quickly become a disadvantage. 

“Aperture is built to give developers a practical way to manage AI without locking down their choices. It makes approved AI tools easier to use, connects them to internal data with identity preserved, and gives agents controlled environments to work in.”

“AI agents are also changing the risk model. They can write code, call tools, browse systems, manipulate files, and run commands. In many setups, they do that with the same permissions as the person running them, which can expose local files, credentials, and internal systems if something goes wrong,” said Pennarun and team.

What it means for developers: a controlled environment for agents to work in

Aperture is built to give developers a practical way to manage AI without locking down their choices. It makes approved AI tools easier to use, connects them to internal data with identity preserved, and gives agents controlled environments to work in. It also keeps the AI stack essentially modular, so teams can keep experimenting with new models, interfaces, tools, and providers without starting over.

The new chat interface is a browser-based way to use approved AI models through Aperture. The interface supports switching between configured LLM providers and works with Aperture data connectors and sandboxes. The universal data connectors help AI tools reach internal systems, documents, APIs, and operational data without forcing every team to build its own integration path.

Teams can use Aperture’s chat UI, coding agents, agent frameworks, or implement custom interfaces through OpenWebUI or LibreChat. Sandbox support (available in private alpha at the time of writing) is designed to give AI agents controlled environments where they can complete work without acting directly on a user’s laptop, workstation, or unmanaged system.

Aperture is designed to work with API keys from major LLM providers and with tools, agents, and interfaces that can be configured to route through Aperture. 

AI stacks inevitably, constantly and persistently change

With the frontier model race apparently unlikely to slow down any time soon, the fact that the best model, interface, sandbox, and data connection will all keep constantly changing… combined with the need to juggle these balls across multi-cloud deployment instances (poly-cloud even, where one app is split into different component parts across more than one hyperscaler), organizations looking to harness AI effectively and securely will surely face challenges. 

The central technology proposition with Tailscale Aperture is that it gives software developers a stable layer for identity, access, and control, so teams can keep changing tools without losing track of who is doing what.

The post “Agents need boring infrastructure around them”: Why we need to take an interest in ‘invisible’ AI appeared first on The New Stack.

The Linux Foundation has long transcended its roots as a steward of the Linux kernel, emerging as a “foundation of foundations” spanning everything from cloud infrastructure and security, to digital wallets, and maps.

But the organization has been on a particular tear of late, becoming home to numerous AI-focused foundations and projects in the past twelve months alone, spanning agent communication protocols, agent security and governance, AI asset exchange, while on the foundation side there’s the Agentic AI Foundation (AAIF), the Tokenomics Foundation, and — now — the Appia Foundation.

The all-new Appia Foundation sits under the auspices of the Joint Development Foundation (JDF), a Linux Foundation entity that provides the legal and administrative infrastructure for organizations producing technical specifications and standards rather than code.

Announced on Wednesday, Appia’s mission is to produce open, modular specifications that give organizations across the AI supply chain a consistent, verifiable way to demonstrate that their systems meet the trust and compliance obligations placed on them — whether those come from regulators, customers, or international standards bodies.

Google, Microsoft, and OpenAI are among the 13 inaugural members, alongside a slew of industrial heavyweights.

A problem to solve

In most industries, proving that something’s safe is fairly routine. A new apartment block gets signed off by inspectors before the first tenant arrives. A kettle carries a safety mark because someone qualified tested it. The checking is so embedded that nobody thinks about it. AI has no equivalent yet — no common, recognized way for anyone in the supply chain to show that a system meets the bar, in a form the next party can actually rely on.

An example offered by the Appia Foundation illustrates how quickly the problem can compound in real scenarios. An AI tool used to screen job applicants wasn’t built by one organization: a developer created the underlying model, a second company adapted it for candidate assessment, a vendor connected it to the hiring systems, and the company’s own HR team configured it for their specific hiring criteria. The recruiters relying on it need to trust it’s reliable, while the applicants it screens want to know it’s fair. The company’s leaders need confidence it’s lawful. Regulators want evidence of how it performs. Each party is asking the same question — can this be trusted?

Today, most claims about AI trustworthiness amount to self-declaration — a company’s word that its system is safe, fair, or compliant, with no standardized way for anyone else to verify it. Craig Shank, executive director of the Appia Foundation, tells The New Stack that as a global, multi-stakeholder endeavor, the foundation is focused squarely on the “practical mechanics” of verifying an AI system against defined criteria, rather than merely stating that it’s trustworthy.

“Our specifications will enable transparent, attributable and traceable technical records of who demonstrated what against which criteria and when.”

“Our membership reflects the entire international value chain — the providers who build the platforms, the enterprises deploying them across critical industries, and the independent bodies that test them,” Shank says. “Our specifications will enable transparent, attributable and traceable technical records of who demonstrated what against which criteria and when. This is the exact type of objective data that courts, counterparties and regulators will need to determine where responsibility lies.”

The 13 inaugural members span a broad spectrum of industry — model and platform providers including Google, Microsoft, OpenAI, and Arm; industrial deployers including Siemens, Mastercard, Ericsson, Schneider Electric, and Mitsubishi Electric; and the assessment and governance bodies that will ultimately do the checking, including testing and certification firm Nemko, AI governance tooling company Naaia, and AI risk insurer Armilla AI.

A checklist for the age of AI regulation

AI regulations around the world are already moving from principles to active enforcement, and organizations are under pressure to prove that an AI system is safe and accountable. International standards bodies like ISO/IEC have done the work of defining what that should look like in principle, but translating that into something a regulator, a customer, or a procurement team can verify is another matter entirely. That gap is what Appia is built to fill.

The foundation will develop what it calls “conformity specifications” — modular, publicly available documents that translate international AI standards into concrete, assessable criteria. Think of existing ISO standards as the building code, and Appia’s specifications as the inspector’s checklist: the practical means of showing that a given AI system conforms to them.

A key feature of how the specifications are designed is what Appia calls “evidence pass-through.” Because AI systems are rarely built by a single organization — a model provider, an integrator, a deployer, and others may all have a hand — the specifications are structured so that conformity evidence produced at one layer carries forward to the next. A company deploying a third-party model, for example, wouldn’t need to re-establish what the model’s developer already demonstrated; it would only need to show conformity for its own configuration and use. Each party demonstrates what relates to its role, and no more.

The foundation is also explicit about what its specifications do and do not produce. Conformity — a technical result showing that a system meets defined criteria — is distinct from compliance, which is the legal status of having met a regulatory obligation. Appia produces the former; whether that satisfies the latter is down to the relevant regulator or jurisdiction. The specifications build on standards that already exist and produce the criteria that assessment bodies need, leaving the assessment itself to those equipped to perform it.

Appia is, by its own admission, early. The specifications are being drafted now in working groups open to all members, with initial focus areas including architecture, policy, and mapping the specs to existing regulatory obligations, among them the EU AI Act.

Jim Zemlin, CEO of the Linux Foundation, says that as AI regulation hardens into enforceable law, the industry needs somewhere neutral to do the work of building shared verification infrastructure — and that Appia is that place.

“The Appia Foundation establishes a neutrally governed environment where the entire industry can collaborate on a common assessment framework,” Zemlin says in a statement. “By building this infrastructure in the open, we are helping organizations reduce complexity, lower operational costs and build trust.”

The post Google, Microsoft, and OpenAI join forces to help create AI’s missing trust layer 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.

Today it was announced SpaceX will buy Anysphere, Inc., maker of AI coding agent Cursor, for $60 billion. 

The news comes a few days after SpaceX’s historic IPO listing, with the rocket and AI company stating in its SEC filing that the Cursor deal will likely close in Q3 2026. 

Developers can now wonder how the AI coding agent might change under the Musk umbrella.

April partnership brings June ownership

SpaceX and Cursor have been flirting about a potential acquisition for a couple of months now. 

Back in April, the pair inked a unique partnership, where Elon Musk’s company agreed to either pay $10 billion to the then-independent startup in a model-training collaboration or opt to buy the whole company later on for $60 billion. 

That day has now come. 

At the time, Cursor described its partnership with SpaceX as a way to accelerate its model training efforts, stating in a brief announcement blog post that Musk’s company would enable the startup to scale up intelligence via xAI’s Colossus infrastructure. 

For its part, SpaceX posted on X back in April that working with Cursor would allow it “to build the world’s most useful models.” 

SpaceX sets its sights on AI coding

It seems SpaceX has been eyeing Cursor’s talent for quite some time.

Even before the April partnership, back in March, Reuters reported that xAI had hired two engineers from Cursor. In fact, Peter Swimm, former principal product manager — Microsoft Copilot Studio, Microsoft, tells The New Stack he expects it’s largely engineering and AI talent that SpaceX hopes to gain from the new acquisition: 

What remains genuinely scarce is elite AI engineering talent and the teams that know how to build these systems at scale.

“The more interesting lens is to view it as an acqui-hire and talent consolidation play. The AI coding assistant market is crowded, features are converging rapidly, and long-term differentiation is proving difficult. What remains genuinely scarce is elite AI engineering talent and the teams that know how to build these systems at scale.” 

SpaceX may very well need that talent. As The New Stack wrote back in April, “SpaceX’s xAI has not had a coding hit since its grok-code-fast-1 model had its time in the sun.”

Though SpaceX’s recent IPO puts its valuation at an eye-watering $2+ trillion, its coding division has not been performing up to par, as Reuters reported in March when several aXI founders left the company. Cursor, meanwhile, rocketed to a $29.3 billion valuation at the end of 2025, scooping up $2.3 billion in Series D funding.

By bringing Cursor into its fold, SpaceX is likely hoping to score more engineering talent and level up its AI coding. 

What does it mean for developers? 

Swimm tells The New Stack he thinks Cursor users can expect better performance from the coding agent, assuming access to SpaceX’s deep resources.

What he says remains to be seen is whether the tool will “maintai[n] broad model support and ecosystem neutrality” or face sweeping changes à la Twitter when Musk morphed the social media company into X:

“For Cursor users, the question isn’t whether the product gets better. With significantly more resources behind it, it probably will. The question is whether it remains an independent platform optimized for developers or becomes another component in a larger corporate strategy.” 

Whoever owns the interface where developers spend eight hours a day gains visibility into how software gets built, which models get adopted, and ultimately where AI spending flows.

If that’s the case, he also predicts procurement evaluations will change, as enterprises may now assess the coding agent as one piece of Mr. Musk’s growing AI puzzle rather than an independent vendor. 

Bigger picture, Swimm says the SpaceX acquisition highlights where real strategic value likely now sits. He doesn’t see AI coding agents, themselves, as the gamechanger but the access they provide into developer workflows: 

“What it [the acquisition] does suggest is that access to developer workflows is becoming strategically valuable. Whoever owns the interface where developers spend eight hours a day gains visibility into how software gets built, which models get adopted, and ultimately where AI spending flows.” 

The post SpaceX acquires Cursor for $60 billion. Can it fix Musk’s coding division? appeared first on The New Stack.

Amazon Web Services has added a third specialized “frontier agent” to its growing portfolio of AI tools aimed at IT operations — this one focused on the cloud bill.

AWS FinOps Agent, which the company moved into public preview last week, follows the earlier debuts of AWS’s Security Agent and DevOps Agent. It enters a domain that has historically relied on dashboards, spreadsheets, and a human analyst’s knowledge, and hands it to an agent that can be asked questions in plain English and that can act on its own when something looks wrong.

In this case, the domain is FinOps — the discipline of getting engineering, finance, and business teams to share accountability for cloud spending. AWS frames the new agent as a response to a shift it says is already underway: FinOps work moving from periodic, dashboard-driven reviews toward continuous workflows that run inside the tools engineering teams already use, namely Jira and Slack.

What the agent does

The core workflow starts where AWS Cost Anomaly Detection leaves off. Today, an anomaly alert tells a team that something changed; it doesn’t say what or why. FinOps Agent is built to take that next step — correlating the cost spike against AWS CloudTrail’s record of who changed what and when, identifying the triggering change, and assembling an investigation summary that names both a probable root cause and a responsible owner. From there, it can open a Jira ticket or post to a Slack channel automatically.

The agent answers natural-language cost questions, such as “Why did my AWS cost go up last month?” It does so by pulling from Cost Explorer, Cost Optimization Hub, and Compute Optimizer and tying the answer back to specific services and usage drivers. Organizations can upload context files mapping accounts to owners, teams, and tagging conventions, which the agent uses to translate a question like “what’s the cost of Team X” into the right set of accounts.

The public preview also adds scheduled cost reporting (daily, weekly, or monthly, exportable as HTML, PDF, or PPT) and a feature that bundles Cost Optimization Hub and Compute Optimizer recommendations into a Jira ticket engineers can act on.

The permission model is mostly read-only

For a tool that’s being given broad visibility into billing, usage, and operational data across an account, the access AWS is asking for is constrained. According to AWS’s documentation, the IAM role FinOps Agent uses is primarily read-only across billing, optimization, monitoring, logging, and infrastructure services — enough to analyze costs, investigate anomalies, and surface savings opportunities, but not enough to touch the resources themselves.

The only write access granted is for managing the agent’s own EventBridge scheduling rules, which drive its recurring automations. It can’t create, modify, or delete EC2 instances, RDS databases, Lambda functions, or networking components. The agent is built on Amazon Bedrock, which AWS says includes its standard automated abuse-detection guardrails.

Early customers

AWS’s announcement mentions four customer accounts, each describing a slightly different pain point the agent is meant to address. Workday‘s AI Platform Infrastructure team, which runs the company’s AI platform across many AWS accounts, described the appeal as consolidating two time sinks — “chasing down cost outliers before they become budget problems” and assembling the monthly reports leadership reviews — into one natural-language interface, according to Serjesh Sharma, Manager of Software Development Engineering at Workday.

Mitre 10, New Zealand’s largest home-improvement retailer, framed it in terms of competing priorities for a lean platform team. Eduard Kleynhans, the company’s Platform Engineering Manager, said recurring cost reviews and anomaly checks have historically “competed directly with reliability and improvement work,” and that the appeal of the agent is having those checks “run continuously in the background” so findings surface only “when there’s something that genuinely warrants attention.”

Convera, a commercial payments company operating in a regulated environment, pointed to a more specific failure mode: small, unintended cost changes that get lost in a shared queue. Ramesh Singaraj, the company’s Infrastructure Engineering and Operations Leader, said the agent’s value is that it routes a Jira ticket “to the engineering team that owns the resource, so the right engineer sees it instead of a shared queue that nobody watches.”

And AVIV Group, which operates digital real-estate marketplaces across France, Germany, and Belgium with hundreds of AWS accounts under a centralized FinOps team, framed the agent as a way to offload first-line questions, like the difference between on-demand and Savings Plan pricing, or why a particular anomaly fired, that currently route back to a small central team before resource owners can act. FinOps Director Jordi Espasa said answering those questions directly for engineers frees the central team to focus on “chargeback logic, optimization strategy and leadership reporting.”

What’s still unsettled

The preview is available only in the US East (N. Virginia) Region, though it can manage cost and usage data across other AWS Regions and accounts when deployed from a management account (GovCloud and the Beijing/Ningxia China Regions are excluded). It’s free to use during the preview, subject to a monthly usage limit, though standard charges still apply for any other AWS services the agent touches along the way.

AWS says the agent will expand over time, including cost analysis aimed specifically at AI workloads. This is notable given that AI infrastructure spend is becoming one of the larger line items FinOps teams are being asked to explain.

The post Why did my AWS bill spike? There’s now an agent for that appeared first on The New Stack.

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

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

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

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

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

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

Among the findings:

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

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

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

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

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

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

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.

Beneath the chatbots and copilots, there’s a quiet revolution happening in the data services space. From pure-play database vendors to data integration wranglers and onward to the cloud hyperscalers, the focus has shifted.

Now in the spotlight is the question of how to automate data governance for agentic AI workloads, and for good reason: Traditional manual data stewardship doesn’t scale in a world where agents are becoming increasingly autonomous (and powerful).

Aiming to cut a swath in this marketplace is data control plane company lakeFS. The organization announced its lakeFS for Agentic AI service on Wednesday, and it appears to be designed to bring governed, reproducible data access to autonomous and headless agentic workloads (those that execute decisions below the user interface level) that run at enterprise scale.

The manual model breaks

Einat Orr, CEO and co-founder of lakeFS, tells The New Stack that manual data stewardship was built for human-paced, human-reviewed workflows, i.e., someone looking at a change before it is committed.

“When dozens or hundreds of agents are making changes simultaneously, faster than any person can review, the manual model breaks,” Orr says. “This is because with a human analyst, a bad write to production is usually one mistake, caught by another human before it spreads far. An agent is different — it acts automatically, in parallel, at machine speed, and it doesn’t pause to second-guess itself. And because so much agent activity is unsupervised, you often find out after the damage is done.”

She explains that attempts to identify and roll back incorrect or corrupted production data across a wide set of data modalities, such as images, documents, metadata, and structured data, are almost impossible to pull off. Impossible, that is, unless the team has the data infrastructure in place to isolate and track such changes automatically.

While some of the more disastrous outcomes stay inside an organizaton’s perimeter (or are swept beneath the communications radar), Orr explains that real world consequences of bad agentic data writes are manifold.

“Insurance claims get inappropriately denied or approved, sensor data from machines gets misinterpreted, an incorrect medical diagnosis is made, or customer service bots provide incorrect answers to customers,” Orr says. “The cost of an individual action may be manageable, but agents performing these actions hundreds or thousands of times can have an exponentially larger impact.”

“As agents are let loose on enterprise data at a massive scale, any agent that reads or writes to production data without isolation or a reproducible trail is a liability, no matter how good the model is,”
—Einat Orr, lakeFS CEO.

Bad agents acting in the real world

Examples of this happening include the July 2025 Replit AI coding agent incident, which deleted a live production database during an explicit code freeze, wiping records for more than 1,200 executives and around 1,200 companies. To tidy up its handiwork, the agent then fabricated thousands of fake records and initially claimed the deletion couldn’t be rolled back.

Also in July 2025, Google’s Gemini CLI agent misread a single failed command, acted on a version of the file system that existed only in its own interpretation of the scenario, and permanently destroyed a user’s project files. The Gemini agent is widely reported to have said of its actions: “I have failed you completely and catastrophically. My review of the commands confirms my gross incompetence.”

“The pattern in both is the same: An autonomous agent took a destructive action that no one authorized, and the lack of isolation and a reliable rollback path turned a single mistake into permanent loss,” Orr says.

A doctor of mathematics with a track record in hardcore software engineering, the bottom line for Orr is clear: “As agents are let loose on enterprise data at a massive scale, any agent that reads or writes to production data without isolation or a reproducible trail is a liability, no matter how good the model is,” she said.

“…any agent that reads or writes to production data without isolation or a reproducible trail is a liability…”

Gartner expects 40 percent of enterprise applications to have task-specific agents embedded by the end of 2026, up from less than 5 percent a year earlier. IDC projects that agent use at the largest enterprises will grow tenfold by 2027, with the API and data calls those agents make growing a thousandfold.
That’s the scale production data has to withstand, and it’s what lakeFS is built to govern.

Agents sent to play in an isolated data sandbox 

To address these issues, lakeFS for Agentic AI gives every agent its own isolated data sandbox with a “zero-copy” branch of relevant data, so the agent can access the dataset it needs via references, snapshots, or copy-on-write techniques.

This means any changes the agent wishes to make must be validated and merged in accordance with the policy guidelines defined by the system architecture. In turn, this produces a unified audit trail across every agent action.

When running, lakeFS for Agentic AI is powered by its data version control architecture, which provides zero-copy data sandboxing. This enables isolation so that agent mistakes are automatically isolated and never corrupt production data. Every agent run is tied to an exact, immutable version of the data. Past actions can be recreated, debugged, audited, or extended using the same inputs.

Production data is gated by policy. Merges into production happen only after pre-merge validations pass. Every change can carry an agent identity, a run ID, and an execution context. The result is a unified audit trail instead of evidence scattered across orchestrators, model providers, and cloud logs.

Agents confined by branch-scoped credentials

Where agents are permitted to read and write through standard file operations. lakeFS provides file-level data access with branch-scoped credentials. These can be described as strictly cryptographically bounded, ephemeral access tokens that confine an agent to a specific branch of data or code, so that the agent operates only within its own workspace. This whole mechanism keeps each agent’s working set narrow and avoids context bloat. 

“With lakeFS Mount, a branch, or even a subset of a branch, can be mounted as a local directory inside the sandbox or virtual machine where the agent is running,” Orr confirms. “From the agent’s perspective, it’s just reading and writing to files and folders.” She further clarifies and notes that no LLM tokens are spent learning the lakeFS API. The agent works with a familiar filesystem interface, and lakeFS handles the versioning underneath.

Developers also have a couple of options for injecting custom validation logic. CEO Orr explains that software engineers can use webhooks or Lua scripts, both of which allow users to define behavior and rules that must be met before a merge can proceed. 

“Beyond automated checks, lakeFS also supports pull requests, which bring a human into the loop. In agentic workflows, this gives you a way to review and approve what an agent is proposing before it reaches production,” she clarifies.

Who else builds “Git for data” services?

Clearly, other vendors and projects exist in the data versioning market.

Apache Iceberg has functions for branching and tagging data. HPE acquired Pachyderm back in 2023 for its data versioning and pipelines technologies, which serve MLOps teams.

Originally developed by Dremio, Project Nessie is now an open-source data catalog and version control system for data lakes. Data Version Control (DVC) is an open-source data version control infrastructure designed for complex AI operations and big data environments, but now we’ve come full circle as lakeFS acquired the project in late 2025.

In the search for governance automation for agentic AI workloads, lakeFS appears to offer a comprehensive, cohesive set of tools and functions. In the “Git for data” marketplace, a variety of options exist, but lakeFS hasn’t explicitly positioned itself as a carte blanche replacement for similar or related tools.

One thing is certain: The questions of who is feeding what data to which agentic function, when, where, and why are becoming an increasingly pressing issue if we want AI to work correctly.

The post “The manual model breaks”: What happens when agents write to production data appeared first on The New Stack.

It’s no secret that generative AI has shifted the operations and business models of companies in nearly every sector. But what if I were to tell you that one day, very soon, we will view these innovations the same way smartphone owners look back on the feature phones of the nineties: early experiments in a journey towards a much more significant technological transformation? 

The fact is that AI is advancing faster than any technology in human history; faster than even its creators expected. Today, with many businesses still getting to grips with generative AI, the lens is already moving on to the next world-changing iteration of the technology: agentic AI. 

The opportunity of agentic AI for Europe’s enterprises 

Already estimated at around $9.14 billion, the agentic AI market is forecast to grow rapidly, at a compound annual growth rate (CAGR) of 40.5%, to reach $139.19 billion by 2034. Europe will be at the forefront of this boom, growing at a 42% CAGR. 

The impact of all this investment on enterprises will be profoundly beneficial. According to one study, agentic AI could generate up to $450 billion in economic value through revenue growth and cost savings by 2028. 

Today’s stand-alone AI models are rapidly being replaced by complex, multi-agent-driven automation, in which enterprise systems will be able to make decisions and act on them entirely autonomously.

As this happens, today’s stand-alone AI models are rapidly being replaced by complex, multi-agent-driven automation, in which enterprise systems will be able to make decisions and act on them entirely autonomously. I’m not saying that businesses should abandon their current generative AI efforts. They need to start putting the foundations in place for the agentic future now. 

Ensuring cloud infrastructure is agentic-ready

Agentic AI is a very different proposition to generative AI and demands a different approach within the data center. Rather than serving discrete models, agentic AI infrastructure will need to orchestrate multiple autonomous systems as they interact with one another and with human users.

From a technical perspective, that means balancing both high-performance cloud GPUs and CPUs in an end-to-end AI-optimised stack.

GPUs will be required to run massive LLMs, process data, and generate outputs, while CPUs will need to orchestrate agents and execute the tools and policies that enable them to be autonomous. Modern cloud infrastructure needs to balance these technologies to enable agentic applications to deliver on their considerable promise fully. 

However, for European businesses, deploying agentic AI-ready cloud infrastructure comes down to much more than technical capabilities alone. To be fit for purpose, the European cloud offerings of tomorrow will need to be completely different from those currently in play. There must be a decisive break from the past. 

Data sovereignty and the need for regional AI infrastructure

Currently around two-thirds of European cloud services are provided by US hyperscalers. This situation is a legacy of a vanished world with a different set of geopolitical, economic, and regulatory conditions to our own. It harks back to a time when storing the data of European citizens and businesses overseas was much less problematic, and when cloud costs were more manageable.

Today, EU businesses need to balance agentic innovation with a renewed focus on regulatory compliance. This is because the EU is mandating measurable standards for data localization, operational control, and legal jurisdiction to address concerns about foreign surveillance risks, extraterritorial jurisdiction, and dependence on a small number of hyperscale providers. Once abstract concepts of data sovereignty have transformed into strict operating principles for European businesses. Cloud infrastructure must be stored locally and in the right operational jurisdiction to avoid foreign data subpoenas.

Addressing exploding cloud costs

A second consideration is cost. Data from Flexera shows that 81% of businesses still cite cost efficiency as their top metric for assessing progress against their cloud goals. Yet according to its research, 76% of large enterprises spend more than $5 million on the cloud each month, and nearly a third complain of wasted cloud spend. 

Part of the problem is that enterprises are locked into hyperscaler contracts characterized by opaque pricing and forced service bundling. At just the moment they need to invest in agentic AI infrastructure, enterprises are struggling to fund their core cloud workloads, a situation that’s not helped by the skyrocketing price of CPUs.

As European businesses set out on their agentic AI journeys, the case for moving beyond the hyperscalers could not be more compelling. 

Rooting cloud infrastructure in Europe

This is where alternative hyperscalers like Vultr come into their own. From a data sovereignty perspective, we operate nine European cloud data center regions, including Amsterdam, Frankfurt, London, Madrid, Manchester, Paris, Stockholm, Warsaw, and, as of 19 May, Milan (with this launch, we now operate 33 global cloud data center regions). 

These are physically isolated data centers that come with geo-fenced data management policies and guarantees that no data will be transferred or processed outside jurisdictional boundaries without explicit consent.

As well as helping European businesses comply with data sovereignty mandates, Vultr helps them avoid the high costs and systemic lock-in associated with traditional hyperscalers. With Vultr’s full-stack AI infrastructure, developers and enterprises can benefit from Vultr’s flagship CPU offering, VX1, which offers 23% better performance and 33% lower cost than comparable hyperscaler compute plans, resulting in up to 82% better price-to-performance. 

In addition, Vultr offers European businesses with access to the latest AMD and NVIDIA GPUs for AI and machine learning, high-performance computing, and more, available on demand either as virtual machines, bare metal, or self-service clusters. This is the complete, end-to-end stack of next-generation compute power that businesses will need to thrive in the era of agentic AI.

The dominance of the hyperscalers is less certain than ever as data sovereignty mandates make the case for Europe-based infrastructure.

It’s an exciting time to be in the cloud infrastructure business. The dominance of the hyperscalers is less certain than ever as data sovereignty mandates make the case for Europe-based infrastructure. Meanwhile, businesses are pushing back against the high costs and systemic lock-in that come with hyperscaler offerings. In their place, enterprises can invest in high-performance, cost-effective compute infrastructure that’s open, flexible, and ready for the demands of agentic workloads. 

Explore AI infrastructure solutions from Vultr.

The post AI agents need infrastructure: Why Europe’s regional cloud strategy matters 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.

“Keep readers reading” is the not-so-simple goal of Medium’s recommendations system. To predict what’s most likely to appeal to a particular reader at any given time, Medium continuously processes user activity signals (stories read, recommendations shown, follows, likes, etc.). It then immediately correlates that with the steady stream of new articles, which is estimated at millions per month.   

Smart models and good inference logic are required, but that’s not enough. The data must be stored and retrieved quickly enough to remain relevant while the user is browsing. That’s the job of Medium’s feature store. And getting the data model right started to matter a lot as they scaled to 1M operations per second.

Andréas Saudemont, Medium Principal Software Engineer, recently walked through how the team identified the problem and what they built to fix it. If you’d rather watch than read, you have two options: Watch a short version from Monster Scale Summit or an extended follow-up webinar

The feature store and its role in Medium’s recommendation system

The feature store ties it all together, ingesting user activity and internal events and feeding them to the ML models that power recommendations. It’s what enables customization like the “For You” feed that greets logged-in users.

Each feature is a property of an entity, usually a user or a story. Some are simple and static, like whether a user holds a paid membership. Others capture interaction history: which stories a user has read, what content they’ve recently been shown, etc.

The following diagram shows a highly simplified view of the Medium feature store architecture:

The problem with a relational features data model

When they built their feature store years ago, Medium used relational features for cross-entity relationships. Unlike regular features, a relational feature can have multiple values for a given entity ID. Each value is defined by a relation ID (the ID of the related entity) and a timestamp recording when the event occurred.

For example, a “story users have read” feature is attached to the story entity type. It relates to the user entity type, and its values indicate whether/when a given user has read that story. 

Andréas shared the following schema diagram to explain the concept:

Features sit at the center, each attached to an entity type and defined by name, version, and data type. Non-relational features are simply a feature, an entity ID, and a value. Relational features add a relation ID mapping to another entity type, plus the value itself and a timestamp.

This approach proved suboptimal from a data modeling perspective. Since relational features link two entity types, the data ends up split between two tables: one for the entity IDs and one for the values. That means you can’t get both in a single query. The first query retrieves only entity IDs (not their associated values) and relies on ALLOW FILTERING. A second query then runs for each entity ID to fetch its value. “If we have 1000 entity IDs for which we want to fetch values, then we have to run 1000 queries to fetch these values,” Andréas said.

Overrelying on ALLOW FILTERING made things worse. “This is bad,” Andréas said, referring to monitoring data showing that 90% of rows read via these queries were simply discarded. “This is just data that we don’t need. ALLOW_FILTERING should be an escape hatch, not our design pattern.”

“ALLOW_FILTERING should be an escape hatch, not our design pattern.”

The list feature model

So they reinvented their data model and shifted to a list-based feature model. Instead of splitting data across two tables, everything for a given entity lives in one place and is retrieved in a single query.

Like other features, a list feature is defined by its entity type, name, and optional version. What’s different is the value. While a non-relational feature has a single value, such as true or false, a list feature’s value is a collection of items, each containing a value and a timestamp. Item values can be of any data type; the feature store doesn’t enforce consistency within a list.

For example, consider a user’s reading history. The entity is user, the feature name is reading history, the TTL is 6 months. After that TTL is reached, the data is automatically dropped by the database (since older history isn’t useful for recommendations). The list for a given user is a collection of story IDs and the timestamps at which they were read. The same story can appear multiple times, and multiple items can share the same timestamp.

A range of operations need to be supported. Create List and Delete List operations run at most a few times per day. Remove List Items with Value, which lets a reader scrub a specific story from their history so it stops influencing recommendations, runs at 1k-10k per second. Add List Items is higher still: every story read and every thumbnail shown to a user generates an event. Get List Items is the top, at 100k-1M operations per second.

“The Add List Items, and even more the Get List Items operations, are really the reasons why we need an efficient data store.”

“The Add List Items, and even more the Get List Items operations, are really the reasons why we need an efficient data store,” Andréas said.

Multiple items, one timestamp

Beyond raw efficiency, the new data model also had to support multiple items with the same timestamp. When Medium shows a user four story thumbnails simultaneously, all four presentation events share the same timestamp, but have distinct story IDs. If this isn’t handled correctly, primary key collisions occur.

The team’s solution was a single list_items table that stores everything.

The partition key combines feature_key and entity_id, keeping all items for a given list together. All of user 123’s reading history is stored in one partition, retrieved in one query. The clustering key concatenates each item’s timestamp with an MD5 hash of its value. The hash is what makes same-timestamp items with distinct values possible. 

Relying on MD5 hashes for uniqueness raises its own set of questions, but in practice, the team hasn’t seen collisions. “The values that we are storing are sufficiently distinct, especially when you add the timestamp into the equation,” Andréas said. The table’s clustering order is set to descending so ScyllaDB can optimize for the typical read pattern (most recent N items) rather than leaving the application to sort afterward.

TTL to control storage costs

Storage cost is controlled entirely through ScyllaDB’s native TTL, with no cleanup logic required. Every row expires automatically based on its own timestamp plus the feature’s TTL duration. “We don’t have anything to do regarding that,” Andréas said. “Any row for which the TTL is expired will be considered deleted by ScyllaDB.” 

Storage plateaus for a steady write rate. When a feature is retired, its data drains away on its own. “That’s super useful for controlling our storage and usage costs.”

Implementing the list operations

Add List Items is a logged batch of INSERTs with atomicity guaranteed: all items land or none do. Each row carries its own TTL calculated from its timestamp, so older items expire sooner. Since items almost always carry a current timestamp, new entries append to the top of the partition, which is exactly where reads will look first.

Get List Items runs as a single-partition SELECT with a minimum timestamp and a row limit. “We run the query on a single partition,” Andréas said. “That’s the maximum efficiency that we can have.” The clustering key handles filtering and ordering directly. Post-processing is not required.

Remove List Items with Value is the one operation that couldn’t be reduced to a single query. Because value isn’t part of the primary key, a direct filter isn’t feasible.

A local secondary index built specifically for this case first finds the matching item keys, then a batch DELETE removes them by primary keys.

“Using an index is really faster than a scan because the query is highly selective,” Andréas explained. “We have very few items in a given list that have the same values compared to the total number of items in a list. And thanks to the current structure, using a local secondary index is faster than a global index.”

Andréas shared another example. Starting with the original table partition, the goal is to delete all items with the value “storyC.” Using the local secondary index, the system first identifies the two rows containing that value. It then issues two DELETE statements using the item keys from those rows, which removes them from the list. The final operation, removing all list items, is even more straightforward.

“We can just drop the partition,” Andréas said, “and ScyllaDB does its magic. It just deletes all the rows for that partition, which means that it deletes all the items for the given list. And bonus point: it’s atomic. It’s either completing successfully or not changing anything at all.

ScyllaDB vs. DynamoDB performance

Medium implemented the list operations on top of both ScyllaDB and DynamoDB. The main goal was to benchmark how both databases compared on their actual production data. “Conceptually they are very close,” Andréas noted, “but they have significant differences in how they operate.”

For AddListItems, P50 latencies were low with both databases: ScyllaDB came in under 1.5ms, DynamoDB under 5ms. “DynamoDB is extremely fast, not as fast as ScyllaDB, but extremely fast at sub 5ms latency,” Andréas commented. Things got more interesting at the P95 and P99 latencies. ScyllaDB held steady at around 5-6 ms P95s, while DynamoDB ranged from 13-45 ms. ScyllaDB’s P99s were steady single-digit milliseconds, while DynamoDB’s ranged from 40- 120 ms.

It was a similar story for GetListItems. At P50, ScyllaDB clocked in at 1 ms, DynamoDB at around 3.5 ms. At P95, ScyllaDB held around 5-6 ms while DynamoDB spiked from 30 – 60ms. And at P99, ScyllaDB remained at ~30ms while DynamoDB ranged from 70 ms all the way up to 220 ms.

“ScyllaDB is very fast, with very predictable performance, and that’s super important for us.”

One caveat: DynamoDB was running without an extra caching layer. “We expect that could have a significant impact for DynamoDB because of the high cache hit rate that we are seeing on the list,” Andréas said. “But we don’t have the data yet, so we cannot compare them.” His verdict for now: “ScyllaDB is very fast, with very predictable performance, and that’s super important for us.”

Key takeaways

One pleasant side effect of getting the data model right: Medium is now eager to use ScyllaDB for additional feature store workloads. Before, they were holding back because they didn’t want to build on the shaky relational feature foundation.

Reflecting on the path to this point, Andréas left the audience with this parting advice:

“If you have a suboptimal data model, you will have queries that are slow, that will scale badly. And most likely, you won’t be able to optimize that data model. You will have to define a new data model that will be better. So take time to think about your data model before you start the implementation, because once you have production data using your suboptimal data model, it’s too late.”

The post When your data model is the bottleneck: lessons from Medium’s feature store appeared first on The New Stack.

Memory has replaced compute as a primary constraint for modern tech teams. A perfect storm of hardware architecture limitations, semiconductor supply chain uncertainty, and changing software licensing models has left enterprises confronting increasingly memory-constrained environments. All while high-bandwidth AI workloads overload the production chain’s ability to provide sufficient memory — and when your AI token bill is starting to cost more than your salary bill.

Over the past year, the cost of high-bandwidth memory (HBM) and dynamic random access memory (DRAM) has increased by an unprecedented 170%, with some virtualization subscriptions more than doubling in price.

All this adds up to a demand for enterprises to shift from the previous buy-all-you-can mindset to a data-driven optimization strategy.

Fortunately, AI isn’t only part of the problem. When AI is applied to memory economics in modern virtualization, it becomes a vital part of the solution. 

Bharath Ram, director of product management at Hewlett-Packard Enterprise (HPE), explains it to The New Stack this way: “There’s a component shortage. Today the prices have increased. So customers are looking at ways to save and optimize the existing footprint, so that they can run their workloads on whatever and not have to procure anything new.”

By switching focus from gobbling up every bit of memory your organization can grab to optimizing your workloads and their placement across multi-cloud and hybrid-cloud environments, enterprises cannot only speed up modernization but also shorten decision-making cycle time by up to 80%, all while cutting costs by up to 50%. Read on for how to transition your enterprise from guesswork to smarter IT.

Tech has to confront its waste problem

Most enterprises operate with significant over-provisioning driven by limited visibility and risk avoidance.

These same companies are standing up legacy applications that become less efficient over time, including a significant number of zombie services running without any use. 

On top of this, most AI workloads rely on advanced memory technologies, which has led chip manufacturers to shift production priorities from DDR4 to DDR5 RAM, further reducing DDR4 supply. This impacts the whole industry, with even a personal computer costing 15% to 30% more than last year.

Add to this volatile DRAM pricing and higher core densities, and it’s clear that even non-technical leadership is worried about memory efficiency. Tech giants Microsoft, Google, Amazon, and Meta are buying up as many AI chips as they can, which is triggering even more shortages and price pressure across the supply chain. And thus more enterprises are hoarding more infrastructure and memory. 

And this overbuying isn’t limited to memory. Companies are now also buying infrastructure like servers even before they need them, too, Ram reflects, “because the cost is so exorbitant, the quote that you might have today might not be the same price that you’re quoted for the same infrastructure tomorrow. That’s how we’re seeing the market right now. It’s very volatile.” 

But it might all be ok. HPE estimates that between 20% and 40% of infrastructure is overprovisioned today. Which is an opportunity for efficiency — not only in these limited resources but also in faster, more secure workloads. 

Enterprises are more capable than ever to optimize the use of what they’ve got today, especially before they go searching for more RAM that will cost significantly more.

It all starts with understanding

So much of this waste persists because enterprise infrastructure is obscured — no one really knows what does what with which data, or which services rely on it. 

The same thing that holds companies back from doing anything more than lift-and-shift to the cloud is usually what keeps them from unlocking memory efficiency. There’s simply too little visibility across most enterprises’ complex, hybrid and multi-cloud distributed systems. Which has left organizations guessing and then rounding way up for over a decade now.

“It’s a combination of over-provisioning and not understanding underlying infrastructure. Because many of them are doing public cloud-based provisioning and self-service, where you don’t know what the underlying infrastructure is and you have admins leveraging whatever there is in terms of their service capabilities,” Ram explains. “One piece is memory shortage, and the other is understanding what’s been deployed and rightsizing it.”

To break these over-provisioning bad habits, any change has to be grounded in reality. The first step is to gather and analyze real usage data, using a tool like HPE CloudPhysics to establish a factual baseline that separates real cost drivers from those years of assumptions. 

This allows enterprises to:

• Understand their virtualization footprint and licensing exposure.
• See their workload initialization and efficiency.
• Identify true cost drivers before taking action.

You cannot right-size until you have real-time monitoring of how many hosts have how many VMs, and which are on and off.

Predictive, not reactive provisioning

Once an enterprise has a single source of truth for its complex distributed systems, it can explore what to deploy, where, when, and how.

“An application like SAP HANA is highly memory-intensive and highly latency-intensive. It’s not like this algorithm is optimized to pivot between hot and cold memory tiering” for cost reduction, Ram explains, without risking the application performance, akin to how, when older PCs had limited amounts of memory and, once that ran out, the computer would swap the program from running in memory to disk, slowing way down. 

Part of the modern solution, Ram argues, is that companies “can over-provision with what they already have. They don’t have to buy any new memory,” because of better shared resources available to all the virtual machines managed by a single host. 

“For example, a host with 64GB of physical memory may have more memory allocated across VMs than physically available,” he explains. “In practice, not all VMs consume their full allocation simultaneously, allowing unused capacity to be dynamically reassigned where needed.”

Memory ballooning, which, Ram says, is nothing new, but something desperately needed in the market right now. Version 9.0 of Morpheus, due out this summer, will feature a more modern sort of memory oversubscription, which, HPE explains, allows administrators to oversubscribe physical memory across VMs on a host, enabling higher VM density and more efficient use. This is particularly useful for testing and development environments, virtual desktop infrastructure, and workloads with variable memory demands.

Shift to architectural efficiency 

Eventually, once you’ve optimized and rightsized every memory allocation, it’s time to shift your workloads to a new platform to improve hardware efficiency. 

“The final step is increasing workload density per server, especially as per-core software licensing becomes more expensive,” Ram explains. He says this is best achieved using a virtualization solution with an open-source hypervisor, which can improve utilization now and help organizations shift toward per-socket licensing models. For suitable applications, that modernization may also include moving to containerized deployment, while in-memory deduplication reduces redundant data structures in RAM, improving memory efficiency.

“Not everybody can keep running on existing hardware forever. At some point, some organizations will need to move to a new platform to improve hardware efficiency. But higher workload density still brings added benefits,” he continues, especially at a time when even the biggest tech companies are overbuying infrastructure, driving up costs and tightening capacity.

Per-socket licensing saves more

And if you do go for a hardware refresh with HPE’s Morpheus Software, then you can unlock a different kind of subscription model, which charges per socket or CPU licensing, where multiple cores can share one socket. Some early results indicate that this can deliver up to 90% in savings.

In the end, it all starts with that baseline. Take the free cloud visibility assessment to see where your organization stands.

The post How AI is solving the memory crunch it created appeared first on The New Stack.