Agent Control Plane: Fix the Org Chart Before the Platform

You are being asked to choose an agent control plane. The vendor list is long, the demos are polished and the architecture board wants a decision this quarter. Meanwhile the business has already built agents, some of them running on service accounts that nobody remembers provisioning.

The timing is not accidental. According to Gartner's June 2025 press release, over 40% of agentic AI projects will be cancelled by the end of 2027, and the causes it names are escalating costs, unclear business value and inadequate risk controls. Model capability is not on that list.

Most platform evaluations skip the questions the platform cannot answer for you: who owns an agent, how much authority it may hold, who gets paged when it loops. This article turns those into five decisions, an operating model and a 90-day sequence that ends, rather than begins, with a vendor shortlist.

An agent control plane is the management layer that registers AI agents, grants and limits what they can do, meters what they spend, records what they did and controls when they are deployed, paused or retired. It sits between the agents and the systems they act on, and it is the single place where organisational policy becomes machine-enforced.

Strip the marketing off any product in this category and it manages six things, each a translation of a function your organisation already performs for people. That mapping is the whole argument of this article.

AI agent governance fails in most enterprises for a structural reason: human org charts rest on four assumptions that agents violate immediately.

Authority is bounded by the person. A junior analyst cannot approve a vendor payment because the analyst does not hold that authority. An agent the analyst builds can, if it runs on a shared service account provisioned two years ago for a batch job. Agents are the first workforce that can accumulate more authority than anyone on the team that built them. The OWASP Top 10 for Agentic Applications 2026, published in December 2025 with input from more than 100 contributors, lists identity and privilege abuse as its third-ranked risk (ASI03). Permissions pass through a non-human identity and lose their owner on the way.

Headcount changes slowly. You can hire an agent in seconds and retire it in milliseconds; a team of ten can be running hundreds by Friday. Governance built around quarterly headcount reviews does not notice.

People leave, and their work stops. When an employee resigns, access is revoked and tasks are reassigned. When the employee who built an agent resigns, the agent keeps running. Ownership decays silently, and in most enterprises nobody can run the query that would reveal it. [internal link needed: AI agent inventory and discovery approach]

Accountability follows the manager. A human's bad call has a manager, a conversation and a paper trail. An agent's unsanctioned action has a chat channel and a repository with three contributors. "The agent did it" is not an accountability structure. The control plane can make every one of these gaps legible. It cannot close any of them.

Delegation of authority to AI agents should follow one rule: an agent may never hold more authority than the human who owns it. Every agent gets a named owner, the owner's own entitlements set the agent's ceiling, and any irreversible action requires a second identity to approve. Everything else in the policy is detail on those three points.

Start with the owner: not a shared inbox or "the data platform team", but a person with a role who would be embarrassed if the agent did something stupid. When that person leaves or changes role, the agent is orphaned and should be paused until ownership is re-attested. Nobody can register an agent without volunteering to be accountable for it, which removes most shadow agents.

The delegation ceiling: if the owner cannot approve it, neither can their agent. Writing this sentence down is what makes the service-account problem visible.

The ceiling is where the policy bites. If the owner cannot approve a refund above an illustrative threshold of ₹50,000 or RM 5,000, neither can their agent. If the owner has read-only access to the CRM, so does the agent. Most existing agents will exceed the ceiling on day one. That is useful information: it tells you what to fix before you migrate anything onto a platform. NIST's National Cybersecurity Center of Excellence made the same connection in its February 2026 concept paper on agent identity and authorization, which proposes applying existing identity standards to agents rather than inventing new ones.

Pair the ceiling with maker-checker. Payments, deletions, bulk external communications, anything that touches a customer contract: an agent proposes, and a human or a separately owned agent disposes. Finance has run this control for a century. It transfers directly.

For most enterprises past the pilot stage, the federated agent operating model fits best: a central platform team owns the rails while business units own the agents that run on them. The other two models each work in a narrower situation, and the comparison below shows where each one fails.

The analogy to reach for is the general ledger. Finance does not stop business units from spending. It insists that all spend flows through one ledger, in one chart of accounts, so that it is legible. The central agent platform team should behave the same way: own the registry, the identity model, the policy engine and the audit trail, and let the business build. Its success metric is not agents approved. It is agents running off the rails: zero. Enterprise AI Solutions

Resist creating a Chief Agent Officer; assign four responsibilities on a RACI instead. The agent owner (a business role) is accountable for behaviour, cost and retirement. The agent platform lead owns the rails and is measured on legibility and uptime. The agent risk partner co-approves any promotion to bounded autonomy. The registrar runs a quarterly attestation that every agent has a live owner, a tier, a budget and a last-reviewed date.

Agent lifecycle management answers three questions the platform will ask you on day one: whose phone rings when an agent misbehaves, who signs off when it earns more autonomy, and what triggers its retirement.

Take paging first. An agent in a retry loop at 02:00 is calling an API thousands of times a minute and running up a bill. If the platform team is on call, you have made them responsible for every business process in the company, and they will respond by restricting what agents can do. If the agent owner is on call, they need runbooks, a kill switch they can actually operate and an escalation path to someone who can revoke credentials. Write the incident model down before you test whether a platform can page the owner rather than a central queue. OWASP's list includes cascading failures (ASI08): exactly what an unclear paging model turns from a nuisance into an outage.

The ladder in Figure 2 gives agents something they otherwise never get: a performance review. Each promotion forces someone to look at what the agent has been doing and reaffirm they still want it running. Retirement runs in reverse: an agent whose owner has left, whose budget is unfunded or whose review is overdue drops a tier automatically, and a Tier 0 agent with no owner is deleted. Gartner's June 2025 forecast that at least 15% of day-to-day work decisions will be made autonomously by 2028 is only tolerable if a structure like this decides which decisions those are.

The order matters more than the speed. Each step below produces a document that the next step consumes, and the final step is the one most organisations start with.

1. Inventory every agent already running (weeks 1–3). Include the ones nobody calls agents: the "automation", the "copilot workflow", the scheduled LLM job. Record owner, the identity it runs under, systems it touches and what one night of looping would cost. Output: an agent register with an owner column, gaps visible.
2. Choose the operating model and write the RACI (weeks 4–6). Decide centralised, federated or embedded. Name the platform lead and the risk partners. Ask each business unit head to nominate owners for the agents in the register, not to build anything new. Output: a one-page RACI signed by the unit heads.
3. Write the delegation policy (weeks 7–9). Set the ceiling rule, the maker-checker list, the autonomy ladder and the incident model. Keep it to two pages and have the CIO, the chief risk officer and at least one business unit head sign it. Output: the delegation policy, which becomes the platform specification.
4. Derive platform requirements from the policy, then shortlist (weeks 10–13). Every requirement traces to a line in the policy: pause agents whose owner leaves the directory; block scopes that exceed the owner's entitlements; page the registered owner, not a central queue. A vendor feature that traces to nothing is a demo, not a requirement. Output: a requirements matrix with a policy reference on every row, and a shortlist.

Two limits on this advice. A single-team start-up with a handful of agents does not need a RACI; the founder is the owner, the ceiling and the on-call rota. And where a regulator mandates central control of AI systems, the centralised model may be required regardless of scale, and the sequence becomes a way to design that central function well.

How do we know we bought the platform too early?

Adoption has stalled at pilots while the business runs a second, unofficial way of building agents. The central team spends its time approving things and is resented for it. Nobody can list the agents running under identities whose owner has left. Switching vendors fixes none of these; making the five decisions fixes all of them.

Does every AI agent really need a named human owner?

Yes, and specifically a person rather than a team. Team ownership diffuses accountability and survives departures silently. A named owner creates a natural trigger: when that person leaves or changes role, the agent is orphaned and the control plane pauses it until someone re-attests. That one rule removes most shadow agents without adding any approval step.

What is the difference between an agent registry and an agent control plane?

A registry is a list: which agents exist, who owns them, what they touch. A control plane is a registry plus enforcement: it grants and revokes scopes, meters spend, records actions and pauses or retires agents. The registry is the minimum you need to make the five decisions; the control plane is what enforces them afterwards.

Who should own the agent platform team: IT, data or the business?

The platform team belongs wherever your identity and access management already lives, because agent identity is an extension of that discipline. Measure it on legibility and uptime, never on approvals issued. If it is measured on approvals, it becomes a gate, and the business will route around any gate within two quarters.

Can we run the 90-day sequence if a platform is already in place?

Yes, and it is usually easier, because the platform will already hold a partial inventory. Run the sequence unchanged, then compare the derived requirements against what the platform enforces today. The gap list becomes your reconfiguration backlog, and only if the platform cannot close the gaps does it become a replacement decision.

An agent control plane is where your org chart becomes executable. It will enforce whatever structure of authority and accountability you give it, and if you give it nothing it will enforce nothing, at scale, with excellent dashboards. The five decisions here (named owner, delegation ceiling, operating model, incident model, autonomy ladder) are the structure. The platform is the enforcement.

Your next action is the inventory. Before the next vendor call, produce the register of every agent already running and count how many have no live owner. That number will tell you more about your readiness than any demo.