Get Hired to Clean Up Agent Sprawl: The Agent-Platform Engineer

What this role actually is

An agent-platform engineer owns the substrate a company's AI agents run on: the registry that records what exists, the identity layer that gives each agent a principal which can be audited and revoked, the permission model that bounds what it can touch, the telemetry that records what it did and cost, and the pipeline that retires it when it stops earning its keep. The unit of work is the fleet, not the agent. If an agent is a service, this is the person running the service catalogue, the access plane and the deprecation process for all of them at once — and the role is routinely confused with three neighbours.

It is not the AI governance engineer. That role, covered in our companion guide to the AI governance engineer career path, starts from an obligation written in prose and produces a control that enforces it plus the evidence an auditor will ask for. It decides what the rule should be; the agent-platform engineer builds the plumbing that makes any rule enforceable at all. The two often sit in the same team, but ship different objects: one a control matrix and an assurance argument, the other a registry, a credential broker and a decommission job.

It is not the agent reliability engineer. That role is measured on whether agents behave correctly and recover when they do not — task success, latency, error budgets, incident response. The platform engineer is measured on whether the fleet is knowable and bounded. An organisation can have excellent per-agent reliability and complete fleet chaos: every agent works, and nobody can say how many there are.

And it is not a platform SRE with a fashionable noun attached. The classical platform engineer's population — services, clusters, pipelines — is created deliberately, through code review, in repositories someone can enumerate. An agent population is not: agents get created by business analysts in a low-code builder, by a product team wiring up a vendor SDK, by a partner integration nobody in platform saw, and increasingly by other agents. Discovery becomes an inference problem rather than a lookup, and that is most of what makes this a separate job.

Why the role exists now

The arithmetic is the whole argument. In its April 2026 analysis of agent sprawl, Gartner projected that the average global Fortune 500 enterprise will run more than 150,000 AI agents by 2028, up from fewer than 15 in 2025. A four-order-of-magnitude change in the population of something you are responsible for is not a scaling problem but a different problem, and the tools that worked at fifteen — a spreadsheet, an architecture diagram, everyone knowing who built which one — stop working in the low hundreds.

Against that growth, only 13 per cent of organisations believe they have adequate AI agent governance frameworks in place, and the gap between those two numbers is the commercial case for the role. Gartner predicts that by 2027, 40 per cent of enterprises will demote or decommission autonomous AI agents over governance gaps identified only after production incidents — after, not before — and that more than 40 per cent of enterprise agentic AI projects will be cancelled before the end of 2027.

The causal chain is mundane and repeats across markets. A pilot succeeds and gets scaled, then a second and a third, each owned by the team that built it. Nobody owns the fleet, because at four agents a fleet is not a thing. The population then grows quietly past the point where anyone can hold it in their head, most of that growth happening outside the platform team's line of sight. Then something breaks — a stale credential writes to production, a support agent surfaces one customer's record inside another's session, a finance review finds a spend nobody can attribute — and the review asks two unanswerable questions: how many of these do we have, and what can each of them reach. A governance retrofit gets funded within the quarter.

Gartner's framing, published by senior director analyst Max Goss in April 2026, sets out six steps to manage agent sprawl: establish a governance policy; build a centralised agent inventory; define agent identity and permissions; implement AI information governance; monitor and remediate agent behaviour; build a governance culture. Steps one and six belong to the governance engineer; steps two, three and five are engineering builds that somebody has to write.

Sprawl has two dimensions, and confusing them produces bad architecture. Identity sprawl is the population of ungoverned, undiscovered or over-permissioned agents — the ones you cannot enumerate, and the ones you can enumerate but cannot bound. Context sprawl is subtler: each agent builds its own isolated understanding of the business, so twelve agents hold twelve slightly different models of what a customer is. The first produces security incidents; the second produces the slower failure where automated decisions stop agreeing and nobody can trace why.

The shape differs by market. A global capability centre in Bengaluru running agents for a European parent inherits that parent's control expectations, while its agents were built locally by three delivery teams on different platforms; reconciling those two facts is a full-time job. A London bank under Financial Conduct Authority scrutiny faces a simpler, harder question — which automated processes touch customer data, and under whose authority. As of August 2026 the honest answer at many institutions is that nobody has a list.

The five things the job actually involves

As of August 2026, the responsibilities cluster into five, ordered by dependency: each is hard to do properly before the one above it exists.

Agent registry and discovery

Everything else depends on an accurate list, and the accuracy is the hard part. A registry built on self-declaration captures the agents whose owners knew to register them — exactly the population that was never the problem. A registry that earns its name discovers instead: it reconciles cloud audit logs, OAuth grants, service-account inventories, gateway traffic, provider billing and repository scans into one view, then flags anything calling a model endpoint that does not appear in it. That reconciliation logic is the differentiating skill.

Identity and least-privilege permissioning

An agent without a first-class identity cannot be audited, revoked or held to a scope, so this is the foundation the security story rests on. The work is issuing each agent a principal, binding it to a human or team owner, and granting scopes that match the task rather than the convenience of whoever was debugging at the time. Agents in many enterprise environments are significantly over-permissioned, usually because a broad grant made a demo work and nobody narrowed it afterwards. Short-lived credentials, per-capability scopes and an exercised revocation path are the deliverables; our guide to least-privilege credentials for AI agents covers the mechanics, and control planes such as Microsoft's Agent 365 governance layer are worth knowing well enough to explain their limits.

Runtime observability and cost attribution

You need to answer, for any agent on any day, what it did, which tools it called, what data it reached and what it cost. Tracing is the technical half; attribution is the political half, turning a shared provider invoice into a per-agent, per-owner figure. Reported figures put the cost of running agents in production at three to five times initial pilot projections, so the first serious cost conversation arrives as a surprise, and whoever can already produce the breakdown shapes the response rather than absorbing it.

Blast-radius controls and kill switches

Bounding what an agent can do wrong is separate from bounding what it can access: spend caps, rate limits, write scopes, human approval above a threshold, staged rollout, and a revocation mechanism that has been pulled in a drill and timed. That last part is where most organisations are weakest: claiming a kill switch is cheap, exercising one and measuring what was still running ninety seconds later is not. Our guide to designing agents that fail safe covers the patterns; the platform engineer makes them fleet-wide defaults rather than per-agent good intentions.

The decommission pipeline

This is the responsibility everyone forgets, and the one that most reliably distinguishes a serious candidate. Agents are created constantly and retired almost never, so a fleet only ever grows. Somebody has to define dormancy, detect it, notify the owner, revoke the credentials, archive the logs to whatever retention the jurisdiction requires, and remove the registry entry. Gartner's forecast that 40 per cent of enterprises will demote or decommission agents by 2027 is, as an engineering statement, a forecast that many organisations will need a decommission process they have not built. Building it before it is urgent is the most legible thing you can do here.

The skill stack

Each responsibility maps to a recognisable set of skills and to a specific line of questioning. Nothing here is exotic; the difficulty is that the combination is rare and most of it is learned by building rather than reading.

How to build proof of work when you do not have 150,000 agents

Here is the structural advantage: almost nobody has run a fleet at that scale, so nobody can be screened on having done it. Hiring managers screen instead on whether you think in fleets, which is demonstrable against eleven agents.

Project one: a registry that discovers rather than asks

Build an inventory over whatever agent population you can reach — your own side projects, an open-source multi-agent repository, a small employer's estate with permission. The constraint that makes it interesting is that it must find things nobody told it about. Ingest from at least two independent sources, reconcile them, and report the delta: what is in the audit logs but not the declared list, and the reverse. The delta is the finding, and it is what you talk about in the interview.

The schema is where the thinking shows. A registry storing a name and an owner is an address book. One storing what an agent was granted alongside what it has been observed doing is an instrument.

# registry/models.py
"""Minimal agent registry record. The two scope fields are the point:
granted comes from the identity provider, observed comes from telemetry,
and the gap between them is the finding.
"""
from dataclasses import dataclass, field
from datetime import date, datetime


@dataclass
class AgentRecord:
    agent_id: str                      # stable across redeploys
    display_name: str
    owner_email: str                   # a person, never a distribution list
    owning_team: str
    purpose: str                       # one sentence, plain language
    environment: str                   # "prod" | "staging" | "sandbox"

    granted_scopes: set[str]           # from the IdP / OAuth grant
    observed_scopes: set[str]          # from 90 days of telemetry
    data_reach: list[str]              # systems it has actually read or written

    created_at: datetime
    last_invocation: datetime | None    # None means never observed running
    invocations_90d: int
    cost_90d_usd: float

    discovered_by: str                 # "declared" | "audit-log" | "gateway" | "billing"
    review_date: date                  # next mandatory owner review
    decommission_after: date | None = None
    tags: list[str] = field(default_factory=list)

    @property
    def unused_scopes(self) -> set[str]:
        """Granted but never exercised. The least-privilege backlog."""
        return self.granted_scopes - self.observed_scopes

    @property
    def undeclared_scopes(self) -> set[str]:
        """Exercised but not granted on paper. Investigate these first."""
        return self.observed_scopes - self.granted_scopes

    def is_dormant(self, now: datetime, days: int = 90) -> bool:
        if self.last_invocation is None:
            return True
        return (now - self.last_invocation).days >= days

Four fields carry the weight. owner_email is a named person, because a decommission notice sent to a distribution list is never actioned. discovered_by measures what proportion of the fleet self-declared. last_invocation feeds dormancy. And pairing granted_scopes with observed_scopes feeds the next project.

Project two: a permission-diff tool

Report, for each agent, what it was granted against what it actually used over a fixed window. The output is a ranked list of unused scopes — the least-privilege backlog, widest grants first — and a much shorter list of scopes exercised but never formally granted, which is where you look first. Publish the methodology honestly, including the window length and the failure mode it creates: a scope used quarterly looks unused over ninety days, and a tool that silently recommends revoking it will break something. Naming that limitation is worth more than the tool.

Project three: a decommission report

Apply a dormancy rule to the registry and produce the artefact an owner must respond to: agents with no invocation in the window, the credentials still live behind them, the systems they can still reach, and the owner who has to approve retirement. Then measure what happens after revocation — where you find the warm connection pool that never re-authenticated, the retry that fired from a sidecar, and the service account a colleague had quietly reused. A real revocation-latency number is memorable, because almost every organisation asserts a kill switch and almost none publishes a measurement.

The interview

Loops for this role, as of August 2026, run four or five conversations and lean on scenarios rather than algorithms. Seven shapes recur.

"How would you find every agent running in this company?" The signature question, and the one most often answered badly, by describing a form. A strong answer rejects self-declaration as a primary source, names independent discovery signals — cloud audit logs, OAuth grants, service-account activity, gateway traffic, provider billing, repository scans — and explains how to reconcile them and what each one misses. It ends with the residual population no method reaches, and a plan to shrink it.

"What counts as one agent?" A definitional question that separates people who have built a registry from people who have read about one. There is no correct answer; the panel is listening for a defensible boundary, and for awareness that counting by workload, by identity principal or by business capability gives different totals and different owners.

"An agent has broad production access it does not need. Narrow it." Observe before you cut: measure exercised scopes over a representative window, propose the reduction, stage it behind a flag with monitoring, keep a fast rollback. Candidates who start by revoking are describing an outage.

"Finance asks what agents cost last month, by team." This tests whether you thought about attribution before you needed it. Good answers tag at the point of invocation and reconcile against the provider invoice, then admit the awkward part: shared infrastructure, batch jobs and retries make clean attribution impossible, so you agree an allocation rule rather than pretending to precision.

"An agent is behaving badly at three in the afternoon. What happens?" Named mechanism, named authority, measured latency — and what stays alive after revocation, which only people who have run the drill know.

"How do you retire an agent whose owner left eight months ago?" The orphan case, and a good proxy for whether you treat decommissioning as a process rather than a delete statement. Expect ownership reassignment, dependency checks before deletion, log-retention rules that differ between an Indian and a European jurisdiction, and a grace period with revocation before removal.

"What would you build in your first ninety days?" The registry, almost always, because everything else depends on it — but the answer that lands says so and explains why rather than listing all five responsibilities. A candidate who sequences has done this before.

How to position yourself

Four adjacent roles compete for the same vocabulary, and a candidate who blurs them reads as someone who has done none of them. Internalise this table before a first screen: you will have about ten minutes to work out which of the four the vacancy actually is.

On pay, treat what follows as market reporting rather than a quote. Market reporting for 2026 puts agentic AI engineering roles at roughly $185,000 to $320,000 base in the United States, UK senior engineers at around £90,000 to £150,000 base, and senior AI roles at Indian global capability centres and product companies reaching Rs 40 to 80 lakh per annum, with GenAI engineers reported to command premiums of 30 to 60 per cent over adjacent engineering talent. Those bands move substantially with sector, city and company stage — a regulated employer in London and a twenty-person startup in the same postcode pay very differently, as do a global capability centre in Bengaluru and a domestic product company in Chennai. Calibrate expectations with them; do not argue a number from them.

The title is also unstable: as of August 2026 the same work appears as "AI Platform Engineer", "Agent Infrastructure Engineer", "AI Enablement Engineer" and, in larger organisations, as a specialisation inside an existing platform or identity team, so one search string misses most of it. The structural pattern in how these roles get filled leans towards sourcing rather than applications, because hiring managers looking for fleet thinking tend to go and find people who have shown it in public. Findability is a hiring input, not a vanity metric: the registry you built only works for you if someone can reach it before they have met you.

Key takeaways

The role exists because a population problem arrived faster than anyone's tooling. Gartner's projection of fewer than 15 agents in 2025 becoming more than 150,000 by 2028, set against a reported 13 per cent of organisations believing they have adequate agent governance, describes a gap that gets closed by hiring — and the forecast that 40 per cent of enterprises will demote or decommission agents by 2027 after post-incident discovery describes when the budget arrives, reactively.

What distinguishes the job from its neighbours is the unit of work. Governance engineers own obligations, reliability engineers own behaviour, platform SREs own infrastructure that engineers created on purpose. The agent-platform engineer owns a population that grows without permission, and the five responsibilities are the shape of owning it.

Getting hired into it, as of August 2026, is unusually tractable, because the credential filter cannot exist yet. Build the registry, publish the permission diff, run the decommission and measure the revocation. Three artefacts with one number each put you ahead of most applicants for a job that will be advertised many more times before 2028.