Platform Engineering in the Age of AI

If you've ever waited on approval for a new testing environment, you know what it means to be stuck. The thrill of starting a new feature fades fast when you realize how many tickets stand between you and a working environment. Maybe, if the stars align, you get it in a week.

Platform engineering emerged to fix exactly this — and AI kicks that change up a notch. Developers can now interact with their platform in natural language: describe the environment, the database branch, the deploy, or the investigation they need, and get it in seconds. What used to be a frustrating, manual process becomes nearly frictionless. But what makes this possible isn't the model — it's the layer underneath it: a platform that turns intent into governed, auditable action, and treats AI agents and human developers as equal users of the same golden paths.

That's the model Kestrel is built around. In this post: how platform engineering got here, what changes when AI enters the picture, and what it looks like in practice when both your developers and their AI agents use the platform — safely.

From tickets to buttons to prompts

Platform engineering is an evolution of DevOps practices. DevOps improved response times, but developers didn't feel much of it — they still had to open a ticket or ask for help, and the cognitive load of provisioning shifted onto people who had to describe what they wanted without knowing what was possible.

Internal developer platforms bridged that gap: golden paths through the software delivery lifecycle, exposed as self-service actions. Developers click buttons and fill out forms instead of opening tickets. That was a massive leap — but forms and buttons still sit slightly outside the day-to-day flow of development, and the moment a portal doesn't cover a use case, developers are back in Slack asking a human for help.

Natural language collapses that last step. A request like "spin up a staging environment for feature-payments, add Redis, and tear it down in 72 hours" carries everything a form would have collected — and an AI agent can extract those parameters, match the request to the right golden path, and run it. In Kestrel this is a developer request workflow: developers ask from Slack with /kestrel-workflow, from the terminal with kestrel workflows request, or conversationally from the Developer Requests page in the dashboard. The agent matches the request to a workflow the platform team defined, extracts the parameters from the phrasing, and executes — pausing at any approval gate along the way.

There's no form to fill out, no ticket to submit, and no guesswork. If the request is missing something — a region, a size, a namespace — the agent asks. And this isn't limited to environments: the same interface provisions S3 buckets and RDS resizes on AWS, database branches on PlanetScale, production rollbacks on Vercel, GPU node groups on Nebius, DNS records on Cloudflare, and deploy pipelines on GitHub. (We showed the ten most valuable of these in Top 10 Agentic Workflows for Platform Engineering.)

The new platform user isn't human

Natural-language self-service is the visible change. The deeper one is whois using the platform. Your developers already work inside AI coding assistants — whether your organization has officially rolled any out or not — and those agents increasingly need to do platform things: spin up an environment to test against, check why a deploy failed, kick off a pipeline, look at recent executions. If the platform doesn't serve them, they work around it, and you get agentic chaos: multiple AI agents acting independently, with no central coordination, no shared rules, and no context.

The insight that carries over from a decade of platform engineering is that AI agents need exactly what human developers need:

• Golden paths — a vetted, standard way to do each thing, so an agent creating an S3 bucket gets encryption, versioning, blocked public access, and cost tags every time, not whatever the model improvised.
• Scoped permissions — access fenced to the clusters, namespaces, cloud accounts, zones, and repositories the requester is allowed to touch, whether the requester is a person or an agent acting for one.
• Context — what services exist, who owns them, what actions are available and what each one requires, so the agent can act instead of guessing.
• Review — a human in the loop where blast radius demands one, and an audit trail everywhere.

Treat agents the way you'd treat a new hire: onboard them onto the same golden paths, scope their access, review their work, and widen their responsibilities as they earn trust. Platform teams are uniquely positioned to do this, because they already built all four of those things for humans. The only thing that changed is that the platform's user base grew.

MCP: making your platform legible to AI

Here's the concrete version of that shift. Imagine you're deep in flow, iterating on a feature in Cursor, and you need to test against real infrastructure. You have two options: break flow, open a ticket, and wait — or have your coding assistant do it, right from the conversation you're already in.

Kestrel ships an MCP server that exposes the platform to AI coding agents — Cursor, Claude, Codex, or any MCP-compatible client — as tools they can call directly. Connected over MCP, your assistant can see the workflows your platform team has defined, what each one requires, and what it's allowed to do. Setup is a few lines of config; it runs as a subcommand of the Kestrel CLI and reuses your existing credentials.

Without that layer, the best answer your assistant can give to "I need a staging environment" is a suggestion that you go do it somewhere. With it, the agent finds the right workflow, supplies the parameters, runs it, and comes back with the result — or builds a new automation entirely: "create a workflow that triggers when a PagerDuty alert fires, runs Kubernetes RCA, and posts results to #incidents on Slack" generates, reviews, and activates the whole thing from inside your editor. It can answer operational questions too — "show me the last 5 failed executions and what went wrong," "are there any pending approvals? approve the production deployment one."

Crucially, the agent's access isn't your access. Both the CLI and the MCP server authenticate with scoped API keys — granular permissions like workflows:read, executions:read, or approvals:manage, with expirations, last-used tracking, and one-click revocation. A read-only key for the assistant that only investigates, a write-scoped key for the one that builds — each independently auditable. The agent can only do what you've allowed, which is precisely how you'd treat any other platform user.

The line that makes AI safe in production

The biggest hurdle to adopting AI in engineering organizations isn't capability — it's trust. How do you trust a system when the same prompt sometimes produces different outputs? How do you put something non-deterministic in front of production infrastructure?

Kestrel's answer is an architectural line: AI builds, deterministic workflows run. The Workflow Agent turns a plain-English description into a complete workflow graph — trigger, actions, conditions, approval gates, edges already wired. You review it on a visual canvas, refine it in natural language, drag-and-drop, or the Python SDK, and activate it. From that moment, execution is fully deterministic: the exact steps you reviewed, in the exact order, with no model in the runtime loop deciding what to do next. The creative, variable part of AI happens at build time, where a human reviews the output; the production part is as repeatable as a script.

Around that line sits the governance model. Every workflow carries Allowed Users and Allowed Groups, resource fencing down to specific clusters, namespaces, cloud accounts, zones, and repositories, and approval gatesanywhere in the graph — approvable from the dashboard, from Slack, or by merging a pull request, so your existing code review process can be the approval step. Human-in-the-loop isn't a philosophy statement; it's a block on the canvas.

Click to expand

People and agents, working from the same platform

When the platform serves humans and AI as equal users, every role feels it in their own workflow:

• Developersask for what they need in Slack or the dashboard and get it in seconds — an environment, a database branch, a deploy, an answer to "why is my pod crashing?" — without learning internal CLI tools or digging through docs. If they forget a region or a size, the agent asks.
• SREs and platform engineers trigger and build automations from wherever they work — the dashboard, the terminal, or their coding assistant via MCP — and review agent-proposed remediations at approval gates instead of executing runbooks by hand at 3 a.m.
• Managers and platform leadsget a real-time view of everything automation is doing: every run, step by step, with status, timing, inline errors, pending approvals, and an audit trail of who approved what. "What did automation do this week, and who signed off on it?" is one screen.

Click to expand

This visibility is how trust in AI actually gets built — not by promising the agent is smart, but by making everything it does inspectable. Full observability into agent behavior, plus scoped keys and approval trails, means you can understand where agents are most useful, catch them when they're not, and widen their autonomy deliberately instead of accidentally.

What platform engineers build now

None of this makes platform engineering less important — it changes what the job produces. Instead of hand-building a portal feature for every use case, platform teams curate golden paths and let AI do the assembly. The Workflow Assistant converts the runbooks and scripts you already have into executable workflows; Suggested Workflows proposes ready-to-deploy automations based on the integrations you've actually connected — 30+ of them, spanning infrastructure (Kubernetes, AWS, OCI), PaaS (Vercel, Railway, Fly.io), AI compute (Nebius, Daytona, Beam), observability (OpenTelemetry, Datadog, PostHog), on-call (Slack, PagerDuty, incident.io), databases (Supabase, PlanetScale, Neon, ClickHouse), CI/CD (GitHub, GitLab, ArgoCD, Helm, Jenkins, CircleCI), and IaC (Terraform Cloud, Pulumi, OpenTofu, CloudFormation).

Click to expand

And the platform grows to fit the org instead of what you guessed up front: when a developer request doesn't match any existing workflow, it lands on the platform team's Workflow Requests page with an AI-suggested workflow to fulfill it — review and deploy, build custom, or reject. Every unmet request becomes a prompt to expand your golden paths. The platform-as-a-product loop that made IDPs work — ship, observe demand, expand — now runs with AI drafting the next feature.

Wrapping up

We've gone from submitting tickets to clicking buttons to simply asking for what we need. Developers no longer need to know how the system works under the hood — they describe what they want, and the platform figures out the rest. AI agents are joining them as platform users, whether platform teams plan for it or not.

The teams that get this right won't be the ones with the most powerful models — they'll be the ones whose platforms make AI legible, governed, and observable: golden paths agents can follow, scopes that fence what they touch, approval gates where it matters, and a record of everything they did. That's platform engineering's job in the age of AI, and it's the job Kestrel is built for — across incident response, cloud provisioning, CI/CD, developer requests, and security. For where to start, see Top 10 Agentic Workflows for Platform Engineering and Build an Internal Developer Platform with Kestrel Workflows.