The Pipeline Isn’t Your Orchestrator, It Just Thinks It Is

I spent years at HashiCorp watching enterprises fall in love with Terraform. And I get it. The promise was real: write your infrastructure as code, version it, review it, deploy it. Clean. Repeatable. Modern.

But here’s what I watched happen after the honeymoon ended: the drift started. A manual change here. An emergency fix that never made it back into the codebase. A config that was accurate in git but hadn’t reflected reality in six months. Then the team that owned it turned over, and nobody was sure what was true anymore.

This isn’t a Terraform problem. It isn’t a HashiCorp problem. It’s a Day 2 problem. And almost every IaC approach in the market, including the ones now adding AI on top, is still primarily built for Day 1.

Day 1 Is the Easy Part

Day 1 is provisioning. You write the code, run the plan, apply the change, and infrastructure appears. Every IaC tool on the market is good at this. The new generation of AI assistants, including most of the vendors Gartner just named in their inaugural Market Guide for AI Assistants for Infrastructure as Code, are making Day 1 faster and more accessible. You can describe what you want in plain language and get valid HCL or YAML back in seconds.

That’s genuinely useful. I won’t pretend otherwise.

But Day 1 is not where infrastructure breaks. It’s not where the security incidents come from. It’s not where the costs spiral. It’s not where engineers burn out at 2am.

All of that happens on Day 2.

What IaC Actually Does Well & Where It Stops

Here’s what often gets missed in these conversations: IaC tools aren’t bad at Day 2. Terraform manages drift detection, state reconciliation, and remediation within its own domain exceptionally well. If you deployed it, and it lives in the statefile, Terraform can track it, compare it, and fix it.

The problem isn’t what’s inside the statefile. It’s everything outside it.

IaC is blind to anything it didn’t deploy. A ServiceNow ticket that needs to be opened before a change can proceed. A network configuration that has to be updated by a different team using a different tool. A CMDB record that needs to stay in sync with what just changed in AWS. A database schema migration that has to coordinate with a firewall rule update before either can safely execute.

None of that lives in a statefile. None of it is visible to Terraform, Ansible, or any other IaC tool operating within its own domain.

And that’s where the real Day 2 problem starts: not within each tool’s scope, but at the boundary between them.

When CI/CD Becomes the Accidental Orchestrator

The natural response to this problem is to reach for the pipeline. If you need to coordinate a DB engine upgrade with a network change and a ServiceNow ticket, why not wire it together in your CI/CD tool? Jenkins, GitHub Actions, GitLab CI – they’re already in the stack, they can sequence steps, and your team knows how to use them.

The problem is that CI/CD tools were built for stateless application delivery, not stateful infrastructure changes. They can trigger a Terraform plan and an Ansible playbook in sequence, but they have no awareness of the operational state of the infrastructure those tools are touching. They don’t know whether the network change is safe to proceed given what the DB team just did. They don’t validate against live infrastructure state before executing. They don’t update the CMDB or close the ServiceNow ticket as a native part of the workflow.

What you end up with is a pipeline that sequences steps without understanding them – brittle dependencies, no shared state, and a coordination tax that compounds every time something changes outside the pipeline’s view. When it breaks, and it will break, you’re debugging across four systems with no unified audit trail to follow.

CI/CD is a deployment tool masquerading as an orchestrator. For stateful, cross-domain infrastructure changes, that’s a gap it was never designed to fill.

A Word on Policy Tools

It’s worth being precise here, because the ecosystem isn’t as primitive as some vendor pitches suggest. Tools like Open Policy Agent and HashiCorp Sentinel exist specifically to address policy enforcement in IaC workflows, and they’re good at what they do. OPA in particular is a mature, capable policy engine that enterprises running serious Terraform deployments already use.

But here’s the honest picture: these tools require real expertise to implement and maintain. Sentinel is powerful, but Sentinel-specific is a skill set of its own. OPA requires you to write Rego, a policy language most infrastructure engineers aren’t fluent in. And both tools operate as separate systems that need to be integrated into your workflow. They don’t come embedded in the execution layer. They’re one more specialist tool in a stack that’s already complex.

The question isn’t whether good policy tools exist. It’s whether your team has the bandwidth to implement them correctly, keep them current, and maintain them alongside everything else they’re managing.

The Real Day 2 Problem: Coordination Across Domains

So here’s what Day 2 actually looks like in a real enterprise running hybrid infrastructure:

Your database team needs to upgrade a DB engine. That’s their scope; they own the change, they understand the risk, they have the IaC to execute it. But that upgrade also requires migrating the data, and that migration touches the network team’s domain: routing, firewall rules, connectivity validation, none of which the DB team controls or should be expected to own.

Each team has capable tools within their domain. The DB team’s Terraform handles what’s in AWS. The network team’s toolchain handles what’s on the wire. But there’s no common execution layer connecting them. So the coordination happens in the pipeline – sequenced steps with no shared state awareness – or it happens manually, through change tickets and stakeholder sign-offs that each team manages separately.

Either way, the blast radius of a failure extends beyond what either team was tracking. And the audit trail, if one exists at all, is scattered across four different systems.

That’s not a skills problem. That’s an architecture problem.

What Actually Fixes It

The Itential Platform was built for exactly this scenario. A single governed workflow coordinates the DB team and the network team, validates each step against live infrastructure state, enforces policy across every domain involved, updates the ITSM ticket, syncs the CMDB, and produces a complete audit trail – without requiring either team to leave their domain or pick up a new tool.

FlowAgents orchestrate across the tools those teams already use. The DB engine upgrade and data migration run in the same workflow as the network change and firewall validation. Not sequenced blindly in a pipeline – orchestrated with awareness of the operational state of every system involved.

That’s the difference between a deployment tool and an orchestration platform. CI/CD pipelines sequence steps. Itential understands what those steps are touching – and governs the coordination between them.

Gartner’s report maps the market evolution toward intent-based agentic operations, where AI agents plan, generate, and deploy based on a stated goal, within defined guardrails. The guardrails aren’t separate. They’re properties of the platform itself, applied at execution time, across every domain your infrastructure touches.

Most of the tools in the current landscape weren’t designed for that. The ones that get there will be the ones that treat Day 2 coordination as a first-class problem, not a pipeline configuration challenge.

Day 2 Doesn’t Have to Stay Broken

If any of this sounds familiar – cross-domain changes with no common execution layer, CI/CD pipelines holding together workflows they weren’t built for, audit trails scattered across systems that don’t agree with each other – the problem isn’t your team. It’s the architecture underneath them.

The Itential Platform connects the tools your teams already use into a single governed workflow, orchestrating across network, infrastructure, ITSM, and source of truth without adding another specialist tool to the stack.

See it in action: Request a Demo →

Read what Gartner says is driving the market shift: Download the Market Guide for AI Assistants for Infrastructure as Code →

Gartner does not endorse any vendor, product or service depicted in its research publications. GARTNER is a registered trademark of Gartner, Inc. and/or its affiliates and is used herein with permission. All rights reserved.