AI Agents Need One Enterprise Control Layer

On 10 September, OpenAI launched the Agents API in public beta. It hosts and maintains the harness while allowing the compute environment to sit in an OpenAI-managed sandbox, the customer's own infrastructure or a partner environment. The offer turns long-running context, tool use and coordination into a managed service rather than a component every team must assemble. ¹

A day later, Salesforce described six capabilities across context, agency, action, governance, security and models, together with an AI Control Plane intended to register agents, apply identity and policy, evaluate performance, observe behaviour and outcomes, and control cost across Salesforce and third-party systems. Boomi has made a similar case from the integration layer, while Zayo has moved the idea into network operations, where approved agents can interpret conditions and take authorised action. ²³⁴

These are supplier announcements, not a settled market standard. Availability, pricing, interoperability and independent customer outcomes remain incomplete. But the convergence is strategically useful. It says that organisations moving beyond isolated assistants will need common services around them. The decision is no longer whether that layer exists. It is whether the enterprise chooses it deliberately or acquires it by accident.

First, keep one register. The organisation should know which agents exist, which business process each serves, who owns it, which supplier and model it uses, and whether it is experimenting, operating or retired. An unregistered agent is not a productivity tool; it is an unknown operating dependency.

Second, give every agent its own identity and bounded authority. It should not borrow a person's standing access or repeatedly ask for approvals until someone clicks through. NIST warns that agentic systems are repeating familiar identity mistakes, including consent fatigue and routes that can encourage users to surrender sensitive information. Its broader review of stakeholder responses also found widespread agreement that familiar security practices need adaptation for agents. Existing identity discipline still applies, but continuous software action makes scope, duration and withdrawal more important. ⁵¹¹

Third, separate business context from the model. The definitions, policies, customer commitments and workflow state that make an answer useful belong to the enterprise. They need a governed route into the agent and a portable record when the model changes.

Fourth, use one evaluation language. Each job can retain its own finish line, but reliability, human review, cost, incidents and unresolved exceptions should roll into a comparable enterprise view. Fifth, observe action rather than prompts alone. Leaders need to see what the agent attempted, which system changed, what failed and who accepted the outcome.

Sixth, manage total cost. Model usage is only one component; tool calls, infrastructure, human review, integration and rework belong beside it. Seventh, preserve exit. Policies, workflow definitions, evaluation cases, logs and business records must remain available when a supplier, model or control product changes.

The control layer needs an executive owner because fragmented ownership produces fragmented authority. The likely accountable leader is the CIO or COO, depending on whether the organisation treats agents primarily as technology infrastructure or as a new form of operating capacity. The CISO, data leader, risk function, procurement and workforce leadership should hold defined decision rights inside the design.

One owner does not mean one team approves every action. Central control should provide the register, identity pattern, minimum operating record, evaluation framework, cost view and withdrawal mechanism. Business functions should still define the outcome, permitted work, acceptable result and exceptions that require human judgement. This is a federation: common rails with local accountability.

The board's role is to approve the boundary. It should ask which functions must be common, which may vary by business unit and which decisions can never be delegated to a supplier. Without that boundary, a platform team can become an accidental policy-maker or a product team can grant authority that the enterprise has never consciously accepted.

A shared layer can remove real cost. Product teams should not each build a separate agent register, identity system, logging format, evaluation service and cost dashboard. Reuse shortens the route from a controlled experiment to an operating workflow and gives risk, security and finance one view across the portfolio.

The same layer can create deep dependency. A supplier that holds the context, policies, evaluation history and action records may become harder to replace than the model itself. The switching question therefore belongs in the original investment case, not the renewal negotiation. Buyers should require documented interfaces, export tests, independent logs and a credible customer-managed or alternative operating path for consequential work.

Current market investment shows why the choice will arrive quickly. Accenture and Google Cloud plan a dedicated Gemini Enterprise group with 1,000 forward-deployed engineers, while Oracle reported triple-digit cloud-infrastructure growth and more than US$30 billion of additional AI cloud contracts in its latest quarter. ⁷⁸ Delivery capacity and infrastructure demand are rising. They do not tell a board which control layer will create value or remain portable.

Use two budgets. The first funds the common layer as operating infrastructure. The second funds job-level deployments that must use it. This makes duplicated controls visible and prevents a successful pilot from silently carrying its local workaround into enterprise scale.

A model score can hide the operating burden around it. A recent research preprint offers a useful bounded example. Across 16 agent systems and 750 clinical-audit cases, two systems with almost the same autonomous accuracy required different levels of human review—39.2% and 29.6%—to reach the same stated reliability target under the evaluated policy. ⁶

The percentages are not a global benchmark and the paper is not peer reviewed. The newest available arXiv batch also remains dominated by early work on coordination, memory, stability and evaluation rather than representative enterprise outcomes. ¹² The management lesson is stronger than the number: similar-looking agents can create materially different supervision costs. A control layer should therefore record when people intervene, which cases are deferred, how long review takes and whether the accepted result improves the business process.

This changes the buying conversation. Ask suppliers to demonstrate the complete operating point for the defined job: reliability, permitted authority, human attention, time, total cost and failure recovery. If the answer stops at task completion, the organisation still does not know whether it can run the system responsibly.

The seven functions travel across markets, but their implementation does not. In the United States, supplier platforms and NIST's standards work may push the market toward reusable identity and interoperability patterns. Public agencies are also receiving new pricing and adoption support. In the European Union, public-service pilots begin inside a different mix of procurement, sovereignty, data protection and AI Act obligations. ⁵⁹¹⁰

Regulated sectors add another layer. The United Kingdom's new healthcare-commission blueprint is a recommendation rather than enacted reform, but it reinforces the likelihood that assurance, monitoring and accountability will vary by sector. UNESCO's global forum can shape readiness language without creating national law. A multi-market control layer must record jurisdiction, system role and sector rather than treating policy as one universal setting. ¹³¹⁴

In markets where connectivity, compute, specialist labour or local-language resources are constrained, the layer may be federated, partly manual or shared through public infrastructure. That does not lower the need for identity, bounded authority and an operating record. It changes the affordable way to provide them.

Organisations should connect the layer to existing privacy, cyber, public-sector assurance and critical-infrastructure obligations, and keep the same buyer-side ownership even when technology is hosted offshore. The common board question is simple: can the organisation still see, constrain and replace the agent under its actual local conditions?

First, inventory the ten most consequential agent workflows, including pilots. Record the job, owner, supplier, model, data, tools, authority and current lifecycle state. Do not wait for a perfect enterprise catalogue; the first pass is meant to expose variation and unknowns.

Second, choose the seven common functions and assign their owners. Decide which existing identity, data, security, observability, finance and procurement systems can be extended rather than replaced. The aim is not a new technical empire. It is one coherent enterprise record and one way to withdraw authority.

Third, run one comparison. Take two agent workflows that appear similar and compare their reliability, human review, cost, incidents and export path. This will show whether the common layer is reducing operating friction or merely adding another platform.

Finally, change the next approval paper. Any material agent proposal should state how it joins the enterprise register, receives identity, obtains context, records action, proves acceptable operation, reports full cost and exits. If those answers remain product-specific and invisible to the institution, the proposal is not ready to scale.

The board question for this week is not which agent is most impressive. It is whether the organisation has decided what every agent must have in common before the estate grows beyond anyone's view.