Network and infrastructure teams are under pressure to move toward agentic automation. The long-term goal is ambitious: AI agents that can handle provisioning, service fulfillment, VLAN allocation, and drift remediation in natural language, without a human in the loop for every step. In the short term, most organizations are still developing trust in agents, so they aim for agents to accurately assess and recommend actions that are then validated and executed by humans. The toolchain to do this mostly exists. But a significant bottleneck remains: the underlying data.
Most teams discover this the hard way. They start building agentic workflows, point an LLM at their existing systems, and quickly run into the same wall: the data isn’t structured for agent consumption. Devices are logged, but the relationships between them are absent. There’s no way for an agent to answer “which customers are on this device?” because that question spans three disconnected systems that don’t share a common model. Relying on an agent to synthesize conclusions across that many disparate sources is a gamble that’s not worth taking when you’re talking about mission-critical infrastructure.
What agentic automation actually needs is an AI-ready intent data foundation: a single, structured, relationship-rich source of truth that agents can query reliably, and that stays accurate as the network changes.
What Makes an Intent Data Foundation AI-Ready?
The word “intent” is important. Traditional CMDBs and inventory tools track what exists. An intent data foundation tracks what you designed, what you intended, and how it all relates to the services and customers it supports.
Concretely, an intent-ready data foundation has four properties:
- First, it can express extensive data relationships. Physical devices host virtual interfaces, which often connect to each other over virtual circuits. These are instances of services, which are delivered to customers, and are related to contracts and SLAs. All of that context needs to live in one place, in a model that reflects how your network actually works. Agents need to traverse those relationships and gain enough contextual information on the nature of the relationships to be able to take trusted actions.
- Second, it’s designed for agent consumption. The API surface needs to match how LLMs and agents are built to query data. For example, a GraphQL API, paired with an MCP abstraction layer, lets agents ask structured, relationship-aware questions without needing to understand the underlying schema complexity. The “micro schema, macro query” principle applies here: schema objects stay clean and well-scoped, but agents can ask rich, cross-domain questions against them.
- Third, it stays current. Changes must occur through a governed pipeline process that prevents drift in the automation process itself, through versioning, proposed change processes, CI checks, etc. Beyond that, it’s important to acknowledge that some level of drift is inevitable in production networks. An intent data foundation needs to support branch-based reconciliation that compares the intended state against the actual state (via discovery tool integrations), automatically surfaces deltas, and thus gives agents the confidence to act on what they’re seeing. A source of truth that’s stale is worse than no source of truth; it produces confidently wrong answers.
- Fourth, it’s built around your topology, not a vendor’s generic model. The schema has to reflect your actual environment, your service model, and your customer relationships. That design work is where most teams get stuck, and where agentic enablement helps accelerate the path from zero to a working intent data foundation.
Infrahub as the Foundation
Infrahub was built specifically to serve as this layer. It stores and relates data not just for devices but for everything connected to them: towers, access points, IPs, services, customers, contract files, etc., all in a single knowledge graph, implemented in a Graph database. Its GraphQL API and MCP interface give agents a stable, queryable surface that abstracts away schema complexity. Governed change processes and discovery integrations limit and catch drift. And the schema itself is a first-class design artifact, collaboratively built to match the team’s actual environment. Infrahub does this without requiring that you rip and replace any existing tools or data sources. It is built to integrate and synchronize those data sources into a unified, agent-ready data model.
This is what makes replacing legacy approaches with Infrahub a meaningful architectural shift rather than a tool swap. It’s not about storing more data in one place; it’s about unifying, interconnecting, and enriching intent data in a way that supports agent reasoning at production scale.
Building Faster with Infrahub Skills
A flexible schema is one of Infrahub’s most powerful features, but getting the schema right has historically been the hard part. Teams know what they need to model, but translating that into a valid, well-structured Infrahub schema takes time and expertise that most network teams don’t have on day one.
Infrahub Skills closes that gap. It’s an AI skills package that embeds Infrahub expertise directly into the coding assistants engineers already use: Claude Code, GitHub Copilot, Cursor, Windsurf, and others. Teams describe what they want to model in plain language, and Skills produces valid, best-practice schemas, generators, transforms, and checks, with the conventions applied automatically and the reasoning explained along the way.
Six skills cover the core build workflow. The Schema Manager turns a plain-language description of your domain into a valid schema with naming conventions, relationships, and generics applied. The Object Manager populates it with data that loads in the right order. Generator Manager, Transform Manager, Check Manager, and Menu Manager handle the downstream automation logic, data-to-config transformations, validation pipelines, and UI configuration, respectively.
Two skills support ongoing production use. The Data Analyzer queries a running Infrahub instance in plain language for cross-node correlation, drift detection, and data quality audits, leveraging an MCP server so engineers don’t have to hand-roll GraphQL queries. The Repo Auditor surfaces where an implementation has drifted from best practices and reports what needs to be corrected.
For teams already using AI to write Jinja2 templates and automation logic, Skills extends the same approach to the data layer. The workflow is familiar. The output is accurate. And because Skills explains its reasoning at every step, engineers build real Infrahub expertise as they work rather than depending on the AI assistant indefinitely.
The Path Forward
The companies moving fastest on agentic automation are not waiting for the data problem to solve itself. They’re building the foundation now: investing a few weeks with the right expertise to get a working, agent-driven POC in production, then extending it independently from there.
The sequence is straightforward: model your intent in Infrahub with a schema that reflects your actual topology, wire up the GraphQL and MCP interfaces your agents will query, and establish the reconciliation loop that keeps the data current. Use Infrahub Skills to accelerate every step of that build. Start with a scoped use case, prove out the pattern, then expand.
The toolchain for agentic infrastructure automation is ready. The data foundation is the last piece. Building it correctly, once, is what makes everything else work.
If you’re ready to start building an agent-ready intent data foundation, try out our sandbox, or request a demo, and we’ll get you on your journey. Or start your journey on your own via our GitHub, documentation, and Discord community.
