Intro
The pitch for an AI agent in a developer platform is usually a video of an agent shipping a feature end to end. What I actually see running in production is closer to a bot that reads a service catalog, opens a pull request, and then sits there waiting for a human to click approve. Both are real, and the gap between them is the interesting story.
I want to talk about the concrete job list for AI agents in developer platform work, not a forecast about autonomous engineering. The position I am working from is simple: the model is not the bottleneck. The interface and the permission boundary you hand it are. I run a small VPS hosting business and manage client infrastructure on AWS, GCP and OCI, which means I care a lot about what happens when an agent holds a token that can delete something. That vantage point colors everything below.
Background: how the platform got two kinds of users
Internal developer platforms used to be bespoke plumbing. A team would wire up Kubernetes, write Terraform modules, build a CI pipeline, and call it done. The original assumption was clean: a human clicks through a portal, a human reviews every change, and the audit trail is the engineer’s laptop and a Slack thread.
That assumption does not survive abundant machine-generated code. The portal now has two kinds of users, and they look identical from the database side. A developer opens a service, requests a database, picks a template, and clicks submit. An agent does the same thing through an API. The portal cannot tell them apart unless it was built to.
Model Context Protocol (MCP) is the plain answer to the question, “how does my coding tool read the service catalog without me writing a bespoke connector for every editor.” It is a standardized interface, not a product, and The New Stack’s write-up on the three roles AI agents play (opens in new tab) covers how that is reshaping vendor offerings. Red Hat Developer Hub, Port and OpenChoreo now expose MCP servers from the same portal that serves a browser.
The unglamorous prerequisite nobody sells tickets to is an accurate catalog with real ownership data. If your catalog-info.yaml points to a team that rotated two reorganizations ago, the agent asking “who owns this service” gets a wrong answer with full confidence. I have watched that exact failure mode turn a five-minute ticket into an afternoon.
What’s happening now with AI agents in developer platform tooling
The roles I can name from vendor docs and from my own use are pretty boring, which is the point. AI agents in developer platform tooling today mostly do these things: inspect a repo, author or amend a PR, scaffold IaC and pipelines from a template, triage an incident against logs and the last few deploys, and run a ticket-to-fix loop where the ticket is the prompt.
The vendor pattern converging across Red Hat Developer Hub, Port and OpenChoreo is worth naming. The portal exposes an MCP server, the same catalog serves both a browser and an agent, and the agent’s actions show up in the same audit log as a human’s. That is the actual product story, and it is mostly a packaging decision over a stack that was already there.
The identity problem shows up in concrete terms once you wire this up. A GitHub MCP server exposes read file, open PR, and push to protected branch as sibling tools. A single scoped token treats them the same. So when you later ask “which machine identity opened this PR against the production branch,” the answer is “the same one that read the file.” That is the part I lose sleep over on my own boxes.
Where I think the claims run ahead of the evidence is in the “self-optimizing platform” and autonomous policy enforcement stories. I have not seen either work unsupervised anywhere I can verify. The closest I have seen is an agent that proposes a change, a human approves it, and the platform claims the agent did it. That is a workflow, not autonomy.
What it means in practice: questions I get asked
Q: What do AI agents actually do inside a developer platform today?
They read context (catalog, ownership, templates, recent deploys) and propose changes through the same APIs a human would call. Production-touching actions are gated behind approval. Anything beyond that, in my experience, is either a demo or a future the vendor is selling.
Q: Do I need MCP to use agents on my platform?
No. An agent can call your existing REST API directly. MCP is worth adopting because it saves you writing a connector per tool and gives you one place to log, rate limit, and revoke. If you already have a clean REST surface, MCP is a convenience, not a requirement.
Q: What breaks first?
Credentials and audit. Agents get configured locally by developers, often without a procurement decision, and within a month nobody can answer which machine identity opened which PR against production. Fix the audit story first or you will not be able to tell what your own platform is doing.
Q: Is this worth it for a small team?
Honestly, I am not sure at small scale. If your team is under ten engineers, I would rather spend the same week fixing the runbook an agent would have to read anyway. The payoff shows up when the runbook is already good and the agent is multiplying the leverage of a small platform team.
What to expect next
A few things I expect to land in the next year or so, framed as expectations rather than predictions.
Agent identity is going to move from shared API keys to per-agent identities with scoped, revocable permissions. If you are running plain IAM users with long-lived keys today, the migration tax is going to arrive whether you planned for it or not.
Policy is going to drift from the application layer to the tool layer. Today, “can reach GitHub” is the unit of permission. Tomorrow, the unit will be the callable MCP tool, and you will write allow lists against named operations like open_pull_request instead of hostnames. That is a real change in how policy gets authored.
I expect a consolidation point around a single MCP gateway or hub as the inventory and audit choke point. This is really just an old proxy pattern wearing a new label, but it is a useful one. If you are picking tooling now, picking the platform that ships a clean gateway will save you from bolting one on later.
The costs I expect to show up on invoices before the value does are preview environments spun up per agent-authored branch and token spend that nobody has budgeted per team. On my own hosting, I have already seen agent-driven PRs multiply ephemeral environments by an order of magnitude. Budget for that explicitly or it will arrive as a surprise.
A next step you can take on your own platform this week
Inventory the agent connections you already have. Developers adopted most of them without a procurement decision. On a Mac, start with cat ~/.claude.json and check the MCP config in every editor your team uses (Cursor, VS Code with Continue, Zed, JetBrains). Ask every developer which servers they have configured and write down what each one can do.
Pick one read-only surface and expose it first. Service ownership and deploy history is a good starting point because the worst an agent can do is read the wrong column. Let agents run against that for a few weeks before granting a single write tool.
Create one dedicated machine identity per agent with a scoped token, and confirm in your audit log that you can trace an action back to that specific identity before it ever touches a production path. If you cannot trace it, the agent is not ready for write scope.
Finally, write down the two or three actions you will never allow without a human approval gate. Push to main, DNS changes, anything that terminates an instance. Enforce them in policy, not in a system prompt, because system prompts are not a security boundary. The whole point of doing this work is that the platform outlasts any single model or vendor.