Intent-Driven Infrastructure in DevOps: How AI Is Replacing Manual Config Management

Intent-driven infrastructure is an operating model in which engineers declare the outcome a system must deliver, and software translates that outcome into configuration, applies it, and keeps checking that reality still matches. It is not one product. It is assembled from reconciling controllers, policy engines and, more recently, AI agents that turn a stated goal into reviewable infrastructure code.

No standards body owns the phrase. The closest formal definition comes from networking: RFC 9315, published by the Internet Research Task Force in October 2022, defines intent as goals and outcomes “defined in a declarative manner without specifying how to achieve or implement them.” This article borrows it.

How intent-driven automation differs from scripting

Intent-driven automation differs from traditional scripting in who owns the procedure and who fixes drift. A script encodes the steps and runs when someone runs it. An intent-driven system takes a declared outcome, works out the steps itself, and keeps correcting the live system until it matches.

The operational jump is the third row, and it arrived without any AI. The Kubernetes documentation describes controllers as “control loops that watch the state of your cluster, then make or request changes where needed.” Crossplane runs the same loop against cloud APIs, and its docs are explicit: change a resource in a provider’s web console and “Crossplane reverts that change.” The on-call engineer who resizes a database by hand at 2 a.m. is now arguing with a controller.

Outside networking, the fourth row is rarer. Intel’s open-source Intent Driven Orchestration project, still pre-1.0, lets users state objectives such as latency or availability targets and leaves the Kubernetes stack to choose resources that meet them.

AI sits above every row. It writes the artefact, which is then planned, checked and reconciled like any human change. What AI replaces is the hand-authoring and hand-applying of config. The config stays.

Intent-driven infrastructure tools, by layer

Intent-driven infrastructure tools fall into four layers: reconcilers that hold desired state, policy engines that bound it, intent-based network controllers, and AI agents that write the configuration.

• Reconcilers. Kubernetes controllers. Crossplane, which the CNCF graduated in November 2025. Argo CD and Flux for GitOps, which reconcile clusters against state declared in Git.
• Policy. Open Policy Agent, a graduated CNCF project, evaluates rules written in Rego and separates the policy decision from its enforcement. Intent without policy is a wish list anyone can edit.
• Network intent. Apstra Data Center Director from HPE Juniper Networking, Cisco Catalyst Center (formerly DNA Center), and Nokia Event-Driven Automation (EDA).
• AI agents over infrastructure automation. Pulumi Neo, launched in September 2025. HashiCorp’s Terraform MCP server, which gives AI clients current provider documentation, modules and policies from the Terraform Registry. Itential FlowAI, whose general availability was announced in June 2026.

Each of those AI products works through a deterministic engine (Pulumi, Terraform or the Itential Platform), not around it.

Is Terraform intent-based, or a separate category?

Terraform is declarative infrastructure as code, not an intent-based system. HashiCorp’s language documentation calls it “declarative, describing an intended goal rather than the steps to reach that goal,” which is why plenty of writing labels Terraform intent-based. The input looks like intent, though it names resources rather than outcomes. The bigger difference is the loop: Terraform compares state with real infrastructure only when a plan or apply runs, and a -refresh-only plan reports drift without changing anything.

HCP Terraform narrows that gap without closing it. In the Standard and Premium editions, health assessments check for drift on a schedule and send notifications, but remediation is still a choice between queuing a plan that overwrites the drift or updating the configuration to accept it. A person picks.

Tap to enlarge

“What is replacing Terraform?” conflates three separate moves:

• OpenTofu, the community fork accepted as a CNCF Sandbox project in April 2025, replaces the product and keeps the model.
• Crossplane replaces the on-demand run with a continuous loop.
• AI agents replace the engineer typing HCL. Pulumi’s Neo documentation says Neo “changes the IaC code rather than clicking in a console,” usually handing the change back as a pull request.

Terraform belongs in its own category: an on-demand engine that intent layers can write to.

Where intent-based networking fits in a DevOps pipeline

Intent-based networking fits a DevOps pipeline as one more declared artefact with its own controller. The pipeline delivers network intent; the network controller translates, applies and validates it. Juniper says Apstra Data Center Director “automatically generates correct vendor-specific configurations based on your intent, pre-validates every change, and continuously validates network state.” Nokia’s EDA documentation says the platform “reconciles that intent and drives configuration across devices.”

Juniper publishes a Terraform provider for Apstra, so the same pull request workflow that ships a module can ship fabric intent. The pipeline shape I would recommend:

1. The network change lands as a pull request beside the application change that needs it.
2. CI checks the proposed intent against policy as code before merge.
3. On merge, the pipeline sends intent to the controller, through its API or provider, never device commands.
4. The application rollout waits until the controller reports the intent satisfied.

Step 3 carries the failure mode: CLI config pushed around the controller creates two sources of truth, the mismatch continuous validation is built to flag.

Tap to enlarge

What the DevOps job becomes around intent

AI-driven intent systems change what DevOps engineers do rather than removing the role. The work moves from writing and applying configuration to specifying intent, writing the policy that bounds it, and reviewing what machines generate. The broader case about AI agents is in agentic DevOps. Around intent, four jobs grow:

• Writing intent precise enough that a generator cannot satisfy it in a way nobody meant.
• Authoring policy as code. Rego is where an organisation’s rules stop being tribal knowledge.
• Deciding what may self-heal. In Argo CD, automated sync leaves self-heal and pruning off by default, while Crossplane reverts console edits unless its management policies say otherwise. Choosing which loops to switch on, per environment, is an architecture decision with an incident attached.
• Reading generated plans. My view: an agent’s plan deserves more scrutiny than a colleague’s, because the agent will not be in the incident review.

Models that read telemetry to decide something is wrong are a separate discipline, covered in AIOps in DevOps.

Frequently asked questions

Next steps

Find one resource your team edited by hand in a console last month and ask where its intent is written down. If the answer is nowhere, that document is your first intent-driven infrastructure artefact, and it comes before any AI agent touches it.