Platform engineering used to be the title on a few job adverts at Spotify and Netflix. In 2026 it is the default shape of any infrastructure team larger than a dozen people. The shift is worth understanding, because it is not just a rebrand of DevOps - it is a different operating model, with different tools, different incentives, and a different relationship to the developers it serves.

This post is a plain-language walk through what platform engineering actually is, why the industry has converged on it, and how the arrival of AI agents is reshaping the discipline mid-flight.

What platform engineering actually is

Platform engineering is the practice of building an internal developer platform (IDP) - a curated, opinionated layer of self-service tools, templates, and automation that product engineers use to ship software without having to assemble the underlying infrastructure themselves.

A useful mental model: if DevOps is “you build it, you run it,” platform engineering is “we build the runway so you can build and run it without a pilot’s licence.” The platform team is a product team whose customers are other engineers.

The CNCF platforms working group captured the definition that has stuck: a platform is an integrated product that abstracts away the underlying complexity of the technology stack, exposed through self-service interfaces.

What lives on the platform

Most mature IDPs end up covering a similar surface area:

  • Golden paths - opinionated templates for creating a new service, with CI, observability, secrets, and deploy config wired in from the first commit
  • Self-service environments - ephemeral preview environments and on-demand dev namespaces, provisioned by a pull request rather than a ticket
  • A developer portal - a single UI, typically Backstage or a hosted equivalent, that indexes services, ownership, runbooks, and dashboards
  • Policy as code - guardrails that enforce security, cost, and compliance without a human reviewer in the loop, usually via OPA or a similar engine
  • Paved-road CI/CD - shared pipelines that handle the uninteresting parts (build, scan, sign, deploy) so service teams can focus on what their code should do

Why teams are adopting it

Four forces have pushed the industry in this direction, and all four have sharpened over the last two years.

1. The cognitive load argument

The modern cloud-native stack is too large for any one engineer to hold in their head. Kubernetes, Terraform, Helm, service meshes, observability pipelines, IAM, secret stores, container registries - every one of those is a specialism. Asking every product team to own all of it is how you get seven inconsistent Terraform styles and four abandoned Prometheus stacks.

The book Team Topologies made this argument formally: reducing extraneous cognitive load on stream-aligned teams is a first-class design goal, and a platform team is one of the three enabling structures that delivers it.

2. The DORA evidence

Each year’s DORA State of DevOps report has found that teams with a well-adopted internal platform ship more frequently, recover faster, and report lower burnout. The 2024 and 2025 reports made the link between platform engineering adoption and elite performance explicit. By 2026, organisations that have not invested in a platform are visibly slower to hire, slower to onboard, and slower to respond to incidents.

3. The regulatory ratchet

Compliance requirements have not got easier. SOC 2, ISO 27001, DORA (the EU regulation, not the metrics), and sector-specific rules like HIPAA and PCI all require evidence that controls are applied consistently. Applying controls at the platform layer - with policy as code, signed artefacts, and centralised audit trails - is cheaper and more defensible than asking fifty product teams to each prove compliance on their own.

4. The AI agent catalyst

This is the change that made 2026 the tipping point. Once AI agents started writing real production code - a shift I wrote about in DevOps in the Age of AI Agents - the platform stopped being an optimisation and became a safety requirement. An agent that can open a PR, apply a Terraform change, or adjust a Kubernetes manifest is only safe if the platform around it enforces the guardrails: policy checks, cost caps, blast-radius limits, and a clearly defined path to production.

A platform with strong paved roads is also the most productive environment for AI coding assistants. The more opinionated the template, the less the agent has to invent - and the fewer ways it can invent something wrong.

Platform engineering vs DevOps vs SRE

These terms overlap, and the overlap is genuine. The cleanest distinction I have found:

  • DevOps is a cultural movement - breaking down the silo between development and operations, with shared ownership of the delivery lifecycle
  • SRE is an engineering discipline - applying software practices to operations, with explicit SLOs and error budgets
  • Platform engineering is an organisational model - a dedicated team building an internal product that makes DevOps and SRE practices cheap to adopt

In practice, most organisations end up with a platform team that owns the IDP, an SRE function that owns the reliability practices and on-call for critical shared services, and a DevOps-minded culture that spans both. The titles matter less than whether the responsibilities are clearly owned.

A reference architecture for 2026

Real IDPs vary, but the shape has converged. A reasonable 2026 reference stack looks like this:

  • Runtime - Kubernetes (managed - EKS, GKE, or AKS), with a service mesh such as Istio or Linkerd for mTLS and traffic policy
  • Infrastructure as code - Terraform or OpenTofu for cloud resources, with a higher-level abstraction like Crossplane or internal modules for self-service
  • CI/CD - GitHub Actions or GitLab CI for pipelines, Argo CD or Flux for GitOps-driven delivery to Kubernetes
  • Developer portal - Backstage for the service catalogue, ownership, and templates
  • Observability - OpenTelemetry as the collection standard, feeding Prometheus, Grafana, and a tracing backend such as Tempo or Jaeger
  • Policy and security - OPA or Kyverno for policy, Sigstore for artefact signing, and a secrets manager such as HashiCorp Vault or a cloud-native equivalent
  • AI layer - agent-accessible APIs for the platform itself, so coding assistants and autonomous workflows can inspect state, open PRs, and trigger deploys through the same guardrails as humans

The AI layer is the genuinely new piece. Exposing the platform to agents is not a matter of bolting on an MCP server at the end - it has to be designed in, because every capability the agent can use is also a capability it can misuse.

How to start if you do not have a platform yet

Platform engineering fails most often when it is launched as a grand rewrite. The teams that succeed treat it as a product and start embarrassingly small.

  1. Pick one painful path - service creation, environment provisioning, or the deploy pipeline. Whichever one product teams complain about most
  2. Talk to three product teams - what do they actually do today, and where do they lose time? If you cannot describe their workflow, you are not ready to replace it
  3. Ship a paved road, not a platform - a single golden-path template that genuinely works end-to-end is worth more than a half-built portal
  4. Measure adoption, not output - the number of services on the paved road is the only metric that matters in the first year
  5. Resist the urge to mandate - a platform that teams adopt because it is better is durable. A platform they adopt because leadership told them to is a queue of exceptions waiting to happen

The Thoughtworks Technology Radar and the CNCF Platforms Maturity Model are both useful sanity checks once you have something running.

Where this is heading

The interesting frontier in late 2026 is the intersection of platform engineering and AI. Platforms are becoming the control plane that AI agents act through, which raises a set of questions the industry is still working out:

  • How do you give an agent enough autonomy to be useful without giving it enough to be dangerous?
  • What does an audit trail look like when the actor is a language model rather than a person?
  • How do you express intent to a platform - “deploy this safely” - rather than a sequence of commands?

These are not theoretical. They are the questions that the next generation of tooling is being built around, and the platform teams asking them today are the ones that will define the answers.

Conclusion

Platform engineering is the organisational response to a stack that grew too complex for generalist teams to own end-to-end. It is working because it aligns with how the best teams already operate - paved roads, self-service, strong ownership - and because AI agents amplify the value of a well-designed platform.

The teams that invested in a platform in 2023 and 2024 are the ones that can safely let agents into their delivery pipelines in 2026. The ones that did not are rebuilding in a hurry, because the alternative is a fleet of autonomous tools operating without guardrails.

Building a platform is a multi-year commitment. Starting small, treating it as a product, and letting adoption - not mandate - drive scope is the pattern that keeps showing up in the teams that get it right.

Related reading: