Bringing GitOps Patterns to Infrastructure Automation Execution

I’ve been thinking about how we got here.

Not here as in AI agents writing configs. Here as in: I can ship an application to production through a fully automated pipeline, with tests, approvals, and a complete audit trail, and then turn around and watch an infrastructure automation execute through someone SSHing into a jump host to run a script that lives in their home directory.

Same company. Same decade. Two completely different centuries of operational practice.

That gap didn’t happen overnight, and it didn’t happen because infrastructure people are behind. It happened because we brought CI/CD and GitOps patterns to how we deliver automation without modernizing where it runs. And I think 2026 is the year that stops being a tolerable inconsistency and starts being the thing that blocks everything else you want to do.

A Short History of Everyone Else Moving On

Trace the last decade and the pattern is hard to miss.

Around 2016, CI/CD stopped being the thing the cool kids did and became table stakes. If your artifact didn’t ship through a pipeline, you had some explaining to do. Hand-managed servers went from normal to exception.

By 2019, GitOps went mainstream. Git stopped being a backup of the truth and became the truth: declarative state, changes deployed by merge, and an audit trail you got for free, because the audit trail was the commit history. I remember the first time I watched a team recover an entire environment from a repo and thinking: we are never going back.

By 2022, platform engineering gave all of this a job title. Paved roads. Golden paths. Infrastructure as code as the default operating model, not the aspiration on somebody’s OKR slide.

And now it’s 2026, and AI agents are starting to take real action in operations. Which means autonomous change is arriving in environments where, in a lot of shops, the execution layer for infrastructure automation still looks like it did in 2014.

Every layer of the stack got modernized. Except the one where the work actually happens.

Be Honest About What Runs Your Automations

Be honest about what runs your automations today. For a lot of teams it’s some combination of:

• Scripts manually staged onto a server, or worse, several servers that have drifted apart
• Python virtual environments and Ansible installations built by hand, maintained by the one person who remembers how
• A tower-style control node that has quietly become a snowflake, a single point of failure, and an attack surface all at once
• VPN tunnels and firewall exceptions negotiated over weeks so a central platform can reach remote sites
• Credentials living in more places than anyone wants to admit

None of that is anyone’s fault. It’s what accumulates when the industry pours ten years of innovation into delivery and roughly zero into execution. But every one of those items is a reason your automation can’t scale, can’t be audited, and absolutely cannot be handed to an AI agent.

That last part matters more than people realize. An agent that can act on production infrastructure needs an execution plane where every action is authorized, logged, and reproducible.

If your execution layer can’t give a human that guarantee today, it definitely can’t give it to an agent tomorrow.

The GitOps Patterns Were the Answer All Along

Here’s the thing that took me a while to internalize: the industry already solved this problem. Just not for us.

The GitOps principles that fixed application delivery were never application-specific. Git as the source of truth, declarative configuration, ephemeral environments, promotion by merge: they were just proven there first. They’re exactly what infrastructure automation execution needs. Call it git-native execution.

This is the thinking behind Itential Gateway 5 – our execution engine, the thing that actually runs your playbooks, scripts, and OpenTofu plans against real infrastructure. And it’s why I’d describe it less as a product with features and more as a set of deliberate design decisions.

Content Lives in Git

Gateway 5 stores nothing about your automations. Your playbooks, scripts, and OpenTofu plans stay in your repositories, and the gateway pulls them at execution time. There’s no staging, no copying files to servers, and nothing to synchronize when you add capacity.

Dependencies live in requirements files right next to the code, and the gateway builds a clean, ephemeral environment for every execution. Run the same playbook against 500 devices at once and every run is isolated. The works-on-my-machine problem doesn’t get solved so much as it stops being possible.

GitOps Is the Architecture, Not a Bolt-On

Every gateway resource is described in declarative files you version alongside your code. Promotion from dev to stage to prod is a merge, not a rebuild. Your pipelines run the gateway. The gateway does not run you.

There Is No Web UI, On Purpose

This is the one that raises eyebrows, so let me say it plainly: a UI on an execution engine is an attack surface, a separate deployment to maintain, and a standing invitation to manage servers by hand. Gateway 5 is built for lights-out operation. Nobody logs into a gateway server in production. Administration happens through a CLI built for pipelines, and visibility lives in the platform where it belongs.

mTLS, Not VPN Tunnels

The gateway dials out to the platform over WebSocket secured with mutual TLS, where both ends of the connection authenticate each other with certificates. No inbound firewall rules, no site-to-site tunnels, no six-week ticket with the security team just to connect a site. Workflow-to-service trust instead of network-to-network exposure.

Individually, none of these decisions is exotic. That’s the point. They’re the same decisions your application platform made years ago. Execution is just the last layer to get the memo.

Why Agentic Operations Depends on Governed Execution

I said earlier that 2026 is the year this stops being tolerable, and the reason is agents.

When automation was something a human triggered, a messy execution layer was survivable. The human was the governance. They knew which script was safe, which server had the right environment, which credentials to use. Slow, but survivable.

Agents remove the human from the trigger, which means the governance has to live in the architecture. Every automation onboarded to Gateway 5 becomes a callable, governed service with structured inputs and outputs. A FlowAgent picks it up in its tool library, calls it with reasoned inputs, and gets a structured result back, through the same RBAC, the same approval gates, and the same audit trail as every human-initiated run.

External AI systems get the same treatment through FlowMCP Gateway: schema-validated, access-controlled, and audited before anything executes.

Agents reason. Automations execute. The execution plane is what keeps that division honest.

Where to Start

If any of the execution anti-patterns above looked uncomfortably familiar, you’re in good company, and you don’t have to rewrite anything to fix it. Gateway 5 connects to the Ansible, Python, and OpenTofu repositories you already have. Your engineers keep their IDE, their repos, and their workflow. What changes is where it all runs.

We put the full architecture, the deployment models, and the design decisions behind all of this into a technical white paper. No fluff, just how it works. If you’re thinking about what your execution layer needs to look like for the next decade instead of the last one, it’s worth your time.

The industry moved on. It’s time execution caught up.