The DevOps Platform Is Becoming the Control Plane for Agentic AI

The line between DevOps automation and agentic AI is dissolving fast. In the past two weeks alone, GitLab unveiled a rebuilt SCM layer designed for AI agents, HashiCorp shipped its Terraform MCP server for production use, and Microsoft published a detailed look at how it is migrating thousands of repositories to GitHub specifically to unlock agentic workflows. These are not isolated product launches. They are signals that the DevOps platform itself is becoming the control plane for agentic software engineering.

GitLab Rebuilds for the Agentic Era

At its Transcend 2026 conference, GitLab introduced what it calls Next Generation Source Code Management, a distributed implementation of the Git protocol that makes DevOps workflows scalable enough for AI agents to operate 50 times faster than before. The key change is a shift to distributed processing and storage engines, paired with server-side queries that are limited to only what each task requires.

Alongside the new SCM layer, GitLab launched GitLab Orbit, a context graph now in public beta that maps code, work items, pipelines, deployments, and production signals into a queryable structure for AI tools. GitLab claims Orbit delivers 11 times faster responses while consuming up to 4.5 times fewer tokens. In an era where every token matters, that efficiency gain is not cosmetic; it directly affects whether agentic workflows remain economically viable at scale.

GitLab also introduced an AI Governance framework in private beta, assigning identity, policy paths, and audit records to every agent action. DevSecOps teams get real-time visibility into agent inputs, reasoning, tool calls, and anomalous patterns. Policies such as mandatory code scans can now be enforced across the entire workflow, not just at human handoff points.

Finally, GitLab Flex bundles seats and AI credits into a single annual commitment, letting teams shift spend without renegotiating contracts. The underlying message is clear: AI is no longer an add-on. It is being wired into the platform at the protocol level.

HashiCorp Brings Terraform to the Model Context Protocol

On the infrastructure side, HashiCorp announced general availability of the Terraform MCP server for both HCP Terraform and Terraform Enterprise. MCP, or Model Context Protocol, is the open standard that lets AI assistants such as GitHub Copilot, Claude Code, and IBM Bob interact directly with external systems. Terraform MCP server is now a first-class integration.

The server lets AI assistants do three things that were previously manual:

  • Generate code using organizational standards — AI can query private module registries and produce compliant Terraform code automatically, eliminating the copy-paste hunt for approved patterns.
  • Access workspace data and configurations — Engineers can ask natural-language questions like "Which workspaces have not been updated in 90 days?" or "Show me workspaces managing more than 1,000 resources."
  • Interpret plan changes in natural language — Complex terraform plan output is parsed and explained by the AI, reducing misinterpretation risk and speeding up code review cycles.

Security is handled by design. The server enforces existing Terraform authentication and authorization, and AI assistants receive only metadata and configuration data — never credentials. The deployment supports both local execution for individual developers and shared-service mode for teams, with CORS policies, rate limiting, and OpenTelemetry integration for auditing.

GitHub Enterprise and Bot Workflow Governance

GitHub shipped Enterprise Server 3.21 this week with a set of improvements that reflect the same agentic pressure. Organization custom properties are now generally available, letting enterprise administrators tag organizations with metadata and automatically target rulesets. Hierarchy view for Projects gives teams visibility into nested issue trees without switching contexts. Most importantly, GitHub Actions workflow pages now render workflows with more than 300 jobs using lazy loading, and users can filter by status directly from the page.

In parallel, GitHub fixed a long-standing friction point: pull requests created by github-actions[bot] can now run CI/CD workflows if approved by a user with write access. Previously, bot-generated PRs could not trigger workflows at all, which meant changes could be merged without ever passing CI. This change closes a safety gap while preserving the approval gate, matching the behavior already in place for Copilot-generated pull requests.

Microsoft’s Migration as a Case Study

While vendors build the tools, Microsoft is proving the business case. At Build 2026, the company shared how its Copilot, Agents, and Platforms (CAP) organization has migrated more than 80 percent of its active repositories and 45 percent of its developers from Azure DevOps to GitHub over the past six months. CAP operates roughly 4,000 repositories across 53 Azure DevOps organizations, and it achieved this with just two dedicated engineering leads plus a small support bench.

The reason for the move is explicit: AI capabilities arrive on GitHub first. CAP engineers are already running agentic workflows across migrated repositories, using GitHub Copilot Coding Agent, Code Review, and Copilot Chat in the flow of daily development. Agents scan repositories for security and governance issues, open GitHub Issues, and route remediation to Copilot Coding Agent — including in Windows environments via GitHub-hosted Windows Runners.

Microsoft is not abandoning Azure DevOps entirely. CAP uses a hybrid model: GitHub repositories unlock the latest AI and agentic capabilities, while Azure Boards and Azure Pipelines continue to support planning and CI/CD workflows. The Azure Pipelines GitHub app links existing pipelines to migrated repositories, and AB# syntax keeps GitHub pull requests connected to Azure Boards work items. For organizations evaluating their own path, Microsoft’s advice is to sequence deliberately, preserve critical workflows, and treat agentic capabilities as a primary value driver.

OpenTofu 1.12 and Backstage 1.51 Advance the Stack

The open source layer is not standing still. OpenTofu 1.12.0, released in mid-May, introduces dynamic prevent_destroy expressions, a -json-into flag that produces both human-readable and machine-readable output simultaneously, and a new destroy = false lifecycle option for removing objects from state without destroying remote resources. A follow-up 1.12.1 patch fixed SSH-related security vulnerabilities and revoked CA key validation. HashiCorp and OpenTofu are now running in parallel, and both are converging on the same need: safer, more observable infrastructure lifecycle management.

Backstage 1.51.0, also released in May, is a significant UI and security update. The platform added Combobox, DatePicker, and DateRangePicker components, hardened OIDC default patterns for known MCP clients, and fixed catalog pagination to exclude entities without sort fields — a fix that prevents cursor-based navigation from silently dropping results. Microsoft Graph providers now filter disabled users by default. These changes reflect Backstage’s maturation from a developer portal into a hardened internal developer platform.

Flux and GitOps Tooling Evolve

On the GitOps front, FluxCD published a new Terraform bootstrap module that solves a long-standing ownership problem. Traditionally, Terraform installs Flux but then remains on the hook for steady-state reconciliation forever. The new module takes a "create-if-missing" approach: Terraform bootstraps the Flux Operator and a FluxInstance via a Kubernetes Job, then steps aside. Secrets are handled safely — only SHA-256 hashes persist in Terraform state — and the module supports prerequisites such as CNI Helm charts applied before Flux itself, with hostNetwork support for environments where pod networking is not yet available.

Observability Meets AI Quality

Agentic workflows also create new observability requirements. Dynatrace addressed this with dt-evals, an open source CLI that evaluates LLM and agent quality from real GenAI traces. Teams can run offline evaluations against test sets or online evaluations against sampled production traffic, score outputs with an LLM judge, and write results back into Dynatrace AI Observability as business events. The goal is to make poor faithfulness scores or hallucination spikes operational signals, not just spreadsheet entries.

What This Means for Platform Teams

Taken together, these updates describe a platform engineering landscape in rapid transition. The DevOps platform is no longer just a pipeline runner. It is becoming the governance layer for autonomous agents — the place where identity, policy, audit, and rate limiting intersect with code generation, infrastructure deployment, and observability.

For platform teams, the practical implications are:

  • Auditability is now a first-class requirement. Every agent action needs an identity, a policy path, and a record. GitLab’s AI Governance and HashiCorp’s Terraform MCP server both treat this as foundational.
  • Token efficiency matters. Context graphs like GitLab Orbit and MCP-aware registries reduce the cost of agentic workflows. Teams that ignore this will hit budget walls before they hit scale.
  • Hybrid models are the pragmatic default. Microsoft’s approach — GitHub repos plus Azure Pipelines and Boards — shows that migration does not have to be all-or-nothing. Platform teams should sequence by value, not by completeness.
  • Open source is keeping pace. OpenTofu, Backstage, and Flux are all releasing features that match or exceed their proprietary counterparts in specific domains. Platform engineers should evaluate both tracks without defaulting to vendor solutions.

The DevOps platform of 2026 is being rebuilt for a world where humans and agents collaborate on the same codebase, the same infrastructure, and the same pipelines. The teams that build their platforms with agentic governance in mind will be the ones that capture the productivity gains without the chaos.

Sources