Somehow, my late-night interest in a small open source project (hint: Elasticsearch) led to 20 years of building scalable infrastructure. From databases to distributed systems, I've been fortunate to work in the trenches of the transition to cloud, DevOps, and more.
One thing that I've learned, over and over, is that infrastructure is a craft. The good stuff comes from people who care, who have taste, who are curious, and spend enough time in the weeds (and dreaming of the future) to know what good can feel like.
That craft has generally assumed a person on the other end, whether it’s a first-time user reading the docs to a committed customer wiring up Terraform. But with agentic infrastructure, it’s clear that the tooling we all use daily is shifting in a way that challenges that assumption in a meaningful way. Increasingly, we’ll need to consider an autonomous or semi-autonomous agent.
I’m not entirely sure where it ends up, but that's exactly why I'm writing this post.
Everything everywhere all at once?
Over the past few months, the evidence is impossible to ignore: a growing share of infrastructure consumption will be directed by agents, not people. Much like the shift to DevOps 15 years ago, companies and platforms that adapt to (and help define) the new patterns will have a real advantage.
But from our point of view, it’s more than that. We see three structural trends that are amplified by AI and create a compelling case for agentic infrastructure at even the deepest layers:
-
The "everywhere" availability zone. Software, data, and inference are flowing in every direction — to the edge, between clouds, into sovereign environments, back to centralized clusters. The old hub-and-spoke model doesn't hold.
-
A thousand new clouds. A new ecosystem of specialized providers is forming — GPU clouds, inference providers, sovereign clouds, industry-specific platforms. Each needs connectivity, security, and routing the hyperscalers aren't incentivized to provide.
-
The splinternet. Regulation and data sovereignty requirements are fragmenting the network. Control over where data moves and who can access it is no longer optional.
An agent-first world isn't a faster, more automated version of the one we have. It's a more complex one, with far more counterparties, more data, more places, and more judgment calls about how all of it fits together. Agents may be operating the system, but the structure they operate inside has to be designed, governed, and stewarded by people who understand what's actually at stake.
Okay, so the user is an agent. Call up the humans!
To fuel our focus on this emerging space, we've started framing Datum’s priorities explicitly: agentic experience first, developer experience second, human experience third.
This isn't really about deprioritizing humans. In fact, I’d argue it's the opposite. But when the runtime user is an agent, every design decision moves upstream into the hands of the people building the platform. There's no slick UI to paper over a confusing API. No support engineer on standby to fill in a gap in the docs. The judgment, taste, and rigor have to live in the system itself, which means those elements need to live in the team that ships it.
Tom at Vercel makes a compelling case for what agentic infrastructure should be, but we're approaching this from the network and edge, which are notoriously handcrafted layers. Regardless of the complexity under the hood, I think we need a lot of focus on: ** - Machine-readable interfaces matter most. **CLIs, APIs, and declarative configs are the primary surface area to care and feed, more than ever. Happily, datumctl and our Kubernetes-native control plane were designed this way from the start — but out-of-the-box wins only get you so far.
- Agent-parseable manifests are the new onboarding. Agents need to know what your platform can do without reading a marketing site. We're thinking about skills.md files and a broader set of canonical information that can be served up with confidence.
- Deterministic, composable everything. Agents don't tolerate ambiguity well. Every action should be idempotent, well-typed, and predictable. Simple, in theory.
This is the kind of stuff that gets everyone at Datum super excited. If we can create a modern, global telco that is genuinely agent-ready, that's a big thing that is worth building. And it's the kind of work that only gets done by people who care deeply about the details both down below and up above the actual infrastructure.
We're hiring for the hard part
As a new company, one of our superpowers is our focus, which is narrow and deliberate: AI-native providers, agentic workloads, and the ecosystems forming around them. We have product values that try to be honest about what kind of company we are: opinionated but not dogmatic, focused on builders, willing to say clearly what we won't do.
The role that sits at the center of all of this is an AX/DX & Forward Engineering Lead. We see this as the first and most demanding internal user of everything we build. Someone who will:
- Define and own what agentic experience (AX) and developer experience (DX) mean
- In practice: own the CLI, work through the MCP ecosystem, and make the whole stack coherent from an agent's perspective
- Run real workloads, find friction, push the team to solutions that hold up in production
- Build out a forward-deployed infrastructure engineering function to work closely with partners and customers, and feed those signals back into our products
- Think seriously about the governance, security, and control surfaces that make an agent-ready network something enterprises and regulated industries can actually adopt
- Help shape how we share what we build: to agents first, then developers, then humans
This isn't a DevRel role, a PM role, or a solutions engineering gig. It's an engineering leadership role for someone with strong opinions about what good infrastructure tooling looks like, who is energized by ambiguity, and who believes the most important design challenge right now is the interface between autonomous systems and the humans responsible for them.
The bet
Datum's thesis is that the internet needs a new kind of infrastructure layer that is open, neutral, and built for what comes next. We think that means: agents as the primary consumers of infrastructure, operating in a world that's more regulated, more fragmented, and in greater need of real control surfaces than the one we built the last internet on.
The technical questions are interesting, and we're not certain we have all the answers. What I am certain about is that the answers come from humans: specifically, from a small number of unusually thoughtful engineers who can hold the agent's perspective and the operator's perspective in their head at the same time, and have the taste to know what to build and ship.
If this is the problem you want to work on, I'd love to talk.