Why we acquired Wand: Building toward autonomous infrastructure

Today, groundcover is acquiring Wand, a Kubernetes resource optimization company. It's our first acquisition.

Wand has spent years working on a hard problem: how do you let software continuously optimize production infrastructure without sacrificing performance, reliability, or control?

That's what got our attention.

At groundcover, we've built a complete, high-fidelity understanding of what's happening in production. More recently, we've been making that context available to agents so they can investigate issues, understand changes, and take on work that previously required an engineer to piece everything together manually.

But understanding is only part of the problem.

For infrastructure to become truly autonomous, a system also needs to be able to act on what it knows.

That's where Wand comes in.

Today, Wand applies that idea to Kubernetes resource management. It continuously understands what workloads need and adjusts the infrastructure underneath them. But what interested us wasn't only the optimization itself. It was the model behind it: software with enough context to make decisions about live infrastructure and safely act on them without waiting for a human every time.

We think that's where infrastructure is going.

AI is already changing how software gets built. The software development lifecycle is turning autonomous, with agents writing code, reviewing it, testing it, and investigating issues. The same shift is coming to how software is operated.

The infrastructure of the future won’t be a static layer on top of which applications run. It will constantly self-optimize for cost and reliability and self-heal for issues that come up. It won't just reflect to engineers what's happening. It will increasingly understand what's happening, decide what needs to change, and safely take action within boundaries engineers define.

Just like in the AI-native SDLC, observability will play a huge role here, with telemetry feeding agents and programmatic decisions that make infrastructure truly autonomous–always optimized for the needs it will serve.

That's the bigger reason we acquired Wand.

The problem with local decisions

There's a line from Shon Lev-Ran, Wand's CEO, that stuck with me long before either of us imagined working together:

"Right-sizing assumes we know the future. Spoiler: we don't."

Kubernetes asks engineers to make resource decisions one workload at a time. You set a CPU request and a memory limit, usually before the service has ever run under real load, using a number that's at best an educated guess. From that moment on, the guess is load-bearing.

There are only two ways for it to be wrong, and both are expensive. Size generously and you pay for headroom that sits idle across every replica, on every node, indefinitely. Size tightly and you're gambling with stability, because the workload that fit comfortably last quarter now throttles under load or gets killed for exceeding a memory limit nobody has revisited since it was written.

Faced with that choice, every sensible team over-provisions. Nobody has ever been paged for using too little of a node. The waste isn't carelessness. It's the price of not wanting to be the person who tuned a limit too tightly and found out about it at 2 a.m.

What makes this harder is that even a good decision eventually becomes a bad one. Traffic patterns change, deployments change behavior, and a configuration that was correct in March describes a service that no longer exists by June. Right-sizing treats a moving system as static, which is why the exercise never finishes and why most teams eventually stop doing it.

The industry's answer has been more automation. Horizontal autoscalers adjust replica counts. Vertical tuners adjust requests. Cluster autoscalers add and remove nodes. Reschedulers and eviction policies clean up afterward.

Each of those systems is useful. The problem is that each sees a different part of what is happening.

Tighten a request and measured utilization rises, so the horizontal autoscaler adds replicas that may never have been needed. Those replicas change how workloads pack onto nodes, which changes what the cluster autoscaler does. Every component can be behaving correctly according to its own logic while the cluster as a whole behaves badly.

That's what Wand set out to change.

What Wand built

Wand doesn't treat vertical scaling, horizontal scaling, and node scaling as three separate problems. It makes those decisions together, at the cluster level, based on how workloads are actually behaving.

It runs continuously, analyzing how workloads behave, anticipating what they're going to need, and adjusting as things change. It installs as a Helm chart, without requiring teams to maintain another collection of thresholds and tuning rules.

Importantly, Wand optimizes for performance and availability first. Cost savings come from running the cluster better and removing unnecessary headroom, rather than treating the lowest possible infrastructure bill as the goal.

That distinction matters when you're giving software permission to change production.

A system designed primarily to cut costs is something you're going to watch carefully. A system designed to make sure every service has what it needs, while removing capacity it doesn't, is something you can begin to trust with more responsibility.

And teams are increasingly willing to do exactly that.

Workload optimization products don't just produce reports for humans to act on later. They modify live production. In many cases, teams hand them workloads that were previously managed through scaling configurations their platform teams spent years tuning.

That's a meaningful change in behavior. Engineering teams are already willing to hand off parts of infrastructure management to software when they believe it can make those decisions better and faster than they can manually.

Resource management is one of the first places we're seeing that happen at scale.

I don't think it will be the last.

Autonomy changes the infrastructure model

There's a tension here that I think we're going to spend a lot more time on as infrastructure becomes more autonomous.

For the last decade, we've worked hard to make infrastructure declarative. Git is the source of truth. Engineers describe what production should look like, and reconciliation loops make sure reality matches that declaration.

That model works extremely well when the correct state can be decided in advance.

An autonomous system starts from a different assumption: the correct state depends on what's happening right now.

Take something as simple as a CPU. If the right allocation for a workload changes throughout the day, then the number written in Git can't simultaneously be a permanent source of truth and something we expect a system to change continuously.

One answer is to keep the existing model. The system analyzes production, decides a workload is over-allocated, and opens a pull request. An engineer reviews it, merges it, and the new configuration is deployed.

There are plenty of situations where that's exactly what you want. But the loop still moves at the speed of the person reviewing the pull request.

The other possibility is that what engineers declare starts to change.

Instead of telling Kubernetes exactly how much CPU a workload should always have, engineers define what they actually care about: the level of performance the service needs to maintain, the boundaries it needs to stay within, how much disruption is acceptable, and what the system should never be allowed to do.

The system makes the continuous decisions underneath.

Git remains the source of truth, but it's the source of truth for intent and constraints rather than every operational decision required to achieve them.

I think that's where we're going.

Not because GitOps is wrong, but because production is dynamic. If every decision an autonomous system makes still has to wait for a human to approve it, we've improved the recommendation, but we haven't really closed the loop.

Of course, handing over those decisions creates a much higher bar for trust. Engineers need to know what the system can change, why it made a decision, what boundaries it will never cross, and what happens when something goes wrong.

Those aren't secondary concerns. They're fundamental to making autonomous infrastructure work.

Why Wand belongs at groundcover

The quality of any autonomous system depends on the context behind its decisions.

You can make a simple decision with a few metrics. Understanding a complex production environment is different.

A workload might look over-provisioned based on the last hour and perfectly provisioned based on what happens every Monday morning. A latency increase might look like an infrastructure problem until you know that a deployment happened five minutes earlier. An error in a trace means something different when you can also see the code change, the Kubernetes events around it, and what happened the last time the same service behaved this way.

This is one of the reasons we built groundcover the way we did.

Our sensor captures what's happening across applications and infrastructure without requiring teams to instrument everything first. The data stays in the customer's own environment, and our architecture makes it possible to retain high-fidelity production data without constantly deciding what needs to be sampled or thrown away.

We originally cared about this because engineers shouldn't have to predict which piece of telemetry they'll need during an incident three weeks from now.

AI makes that same architecture much more important.

Agents don't just need access to data. They need enough context to understand what that data means.

The more complete the history of a system is, the better an agent can understand what normal looks like, what changed, what happened before, and how one part of production affected another.

The more they understand, the better they can code, test, ship and remediate - paving the way for a truly autonomous software development lifecycle.

And production telemetry is only part of that context.

We're increasingly connecting groundcover with the systems where the rest of the engineering context lives, including GitHub, Linear, Notion, Slack, Atlassian, and PagerDuty. An agent can start with something happening in production and understand not only what changed, but why it changed, what happened afterward, and whether we've seen it before.

That same high-fidelity data will now serve the engine Wand built to make infrastructure optimization autonomous. Just like groundcover’s bring-your-own-cloud model, Wand's engine runs inside the cluster, close to where the telemetry is created.

We came to those architectures independently, but for essentially the same reason. The closer software gets to production, the less comfortable we are requiring the customer's data and decision-making to live somewhere else.

Wand’s engine, running on top of groundcover’s unique telemetry and data architecture, will allow groundcover to offer the AI-era observability platform–the grid autonomous software and infrastructure runs on.

From observability to autonomous infrastructure

For most of its history, observability has ended with understanding.

Something happened. The system collected the evidence. An engineer investigated it, understood what went wrong, and decided what to do next.

We're already watching AI change that model.

Agents can use groundcover to investigate production. They can query logs, metrics, traces, Kubernetes events, and the relationships between them. They can combine that with context from the rest of the engineering environment and carry an investigation much further than a traditional observability tool could.

The next step is closing the loop.

Wand has been working on that problem in one of the hardest possible environments: live Kubernetes infrastructure. Today, the action is resource management. Wand understands what workloads need and continuously changes infrastructure to meet those needs.

Over time, I think the boundary expands.

That doesn't mean removing engineers from production. It means changing what we ask them to spend their time on. Engineers define what they want. They set the constraints. They decide which decisions can be delegated and which ones still require a person.

That's what autonomous infrastructure means to us.

What comes next

We're starting in two places.

Our first big customer will be groundcover itself.

Our architecture runs on a BYOC data plane inside our customers’ cloud environments, so the resources it consumes show up directly on our customers' cloud bills.

Our BYOC architecture is already self-served, dynamic and fully managed. But we're going to use Wand's technology to make it even more cost-effective and resilient.

groundcover will pioneer BYOC for observability, with the best-in-class BYOC offering in the market.

There's a second-order effect here that I think is even more interesting.

The more efficiently we can store and process observability data, the more telemetry customers can afford to collect and retain at full fidelity. That means more telemetry and context for engineers when they need it and more context for agents to work with.

The more context we can economically retain, the better the understanding. And the better the understanding, the more confidently software can eventually act.

The second is bringing Wand's technology to groundcover customers.

We'll start with Kubernetes resource management because that's what the Wand team has spent years building and because it's exactly the kind of problem that should require less human intervention. Infrastructure changes continuously, the goals are measurable, and having engineers constantly retune resource configurations isn't realistic or a particularly good use of their time.

But we're not acquiring Wand because we want groundcover to become a Kubernetes cost optimization company. We're acquiring Wand because we believe the line between observing infrastructure and operating infrastructure is going to become increasingly blurred.

You need to see what's happening before you can understand it. You need to understand it before you can safely act.

groundcover and Wand have been working on different parts of that problem. Now we're going to work on it together.

Welcome, Wand

Shon, Shir and the Wand team are joining groundcover.

Yechezkel and I first met Shon and Shir when they just started Wand. We met two young entrepreneurs at the ideation stage, passionate as hell and hungry for feedback.

We’ve heard about the workload sizing problem before. The ROI was clear and measurable, but the competition was already starting to form. 

We were skeptical at first.

But these guys were thinking about it more broadly from the get-go. The problem space was their bread and butter, coming from years in DevOps and platform engineering. They’ve built a product and a team that made great companies trust them with optimizing their production infrastructure.

This is our first acquisition, and we didn't make it because we felt like we needed to do one after raising a round. We did it because we met a team that had spent years solving a hard technical problem and, underneath that problem, had arrived at many of the same conclusions we had about where infrastructure is going.

We've been approaching it from different directions.

groundcover has been building the context to understand what's happening in production.

Wand has been building a system that can use production context to make decisions and act on them.

Bringing those two things together gets us closer to infrastructure that doesn't just tell you what's happening, but can increasingly take care of what happens next.

Shahar