Finally, the rest of the industry is building the same things we were building from day one.
In the span of a few weeks this spring, multiple long-established network and infrastructure platforms shipped releases with branching, pull-request-style governance, and procurement workflows tied directly to an infrastructure model, concepts that feel quite familiar to us at OpsMill.
The fact that the industry is collectively building toward a version-controlled, policy-aware system of record feels like a breath of fresh air. It validates what we’ve known infrastructure teams have needed for years.
But we all know features don’t behave the same way when they’re built on a different foundation. And when AI agents become serious consumers of infrastructure data, picking the right one matters a lot.
What OpsMill identified early
Damien started OpsMill with a central thesis: the infrastructure source of truth was going to play a much bigger role than the industry was giving it credit for. If AI agents were coming for network automation, you couldn’t just hand them the keys to fragmented, stale underlying data.
And if that were true, three core features had to be part and parcel of a solid data management platform built for that future:
1. Flexible schema
Real infrastructure doesn’t fit a fixed data model. It just doesn’t. Network, compute, security, cloud, edge, and OT have their own object types, relationships, and constraints, and they all change all the time.
A source of truth with a rigid model causes two problems. Either:
- Teams pile on custom fields just to make things work, losing strict validation in the process, or
- All the workarounds make the tool unusable, and teams default back to a homegrown, piecemeal system of record.
That’s why Infrahub’s schema is user-defined, declared as code, versioned alongside our customers’ data, and enforced by the storage engine itself. Customers describe how their world is supposed to work, and the platform validates it.
Designing a schema from scratch takes careful thought and effort. So we’ve built templates to get our customers 90% of the way there, leaving the last 10-15% (the parts that truly need to be fully custom to their environment) to them.
With a schema that reflects how your company works, automation engineers (and soon, AI agents) gain the context they need to make changes that line up with how you want to operate.
2. Native version control
If your database isn’t versioned, you’ve lost the ability to safely roll back, audit, or rebuild, things you may have to do at one point or another.
That’s why Infrahub is built on a temporal graph. Every node, every relationship, every attribute carries its full history, and branching and merging are properties of the storage layer.
An engineer or AI agent can create a branch, propose changes against it, and assign it to a peer for review. Because the branch is a first-class object in the database, the reviewer sees exactly what changed and what it depends on. Which makes it easy to:
- Deploy changes safely. Accept and merge, or reject (and not have to suffer the consequences).
- Troubleshoot. You can see exactly what the network looked like at any point in time and compare it to now.
- Work in parallel. Teams can develop big changes (a new data center buildout, an SD-WAN rollout, a vendor migration) in separate branches and merge them in when they’re ready, without one project blocking the next.
You also get a clean input for everything downstream. Pull from the latest and greatest version of your infrastructure to render device configs, observability inventories, documentation, and audit reports in whatever format your tools need.
3. Built-in governance
If governance lives outside your source of truth (sometimes in multiple places), every change has to be reconciled with it. Approvals happen in one tool, validation in another, deployment in a third.
But if you have proposed changes, CI validation, artifact rendering, and review workflows built into a centralized platform:
- Every proposed change is validated end-to-end. Schema, data, and templates are all checked together in one pass.
- Only what’s changed gets rechecked. The system knows which parts of the infrastructure are affected, so it doesn’t have to re-run everything.
- Reviewers see the full picture. What’s changed and what it could potentially impact downstream.
Why the industry is heading in this direction
Leadership wants to know how the team is going to “use AI to their advantage.” When data is scattered across multiple systems and half of it may or may not be current, that’s not a fun challenge. It’s a risky one.
In response, the Network Automation Forum created a high-level, modular, vendor-neutral “blueprint” for an automation-ready stack (the NAF framework). And we’re already seeing incumbent platforms start to build in that direction, adding branching, change governance, and asset lifecycle. People need these features now.
But you can’t fix a broken foundation by stacking features on top of it:
- AI agents and automation pipelines fall apart when technical data and business logic are in disparate places. When agents don’t know what’s current or most accurate, they’ll guess (a disaster waiting to happen).
- AI data centers are not the data centers of five years ago. Network fabrics now have to support RDMA, scale-out Clos topologies with hundreds of thousands of GPUs, and rail-optimized designs that didn’t exist even a few years ago. You need to model relationships between devices, optical links, cooling loops, and power distribution. And that model will change every time a new generation of hardware comes out.
- The boundary between intent and operations needs to disappear. A change to intent should flow through to configs automatically to avoid a growing gap between what the network is supposed to look like and how it actually looks.
What this means for you
The data management platform a team picks today will define what they can do over the next five years, particularly with regard to AI.
If you’re evaluating this space, I’d encourage you to look at where everyone is heading and ask yourself which platforms were built with that destination in mind. And I’d invite you to give Infrahub a whirl. It was designed for this exact transition because we saw it coming.
Walk through the templated schema, see how you’d make it your own, spin up a branch. Then ask yourself: do I want these capabilities built into my source of truth? Or do I want to add them one release at a time?
We know which answer we’d give, but it’s your infrastructure.
