AI agents are multiplying enterprise control points

More sophisticated AI controls can make it harder for a CIO to answer a basic question: who ultimately controls an AI action? Every new agent, model or embedded AI capability can bring systems that determine orchestration, model selection, data access, identity, permissions, observability and deployment. Each system can solve a valid problem, but their decisions can intersect. The result can be an architecture where several products exercise related authority over one AI action.

More AI controls can leave CIOs with less coherent control

That overlap makes AI control an architecture problem for CIOs. Product decisions accumulate across application, data, security and infrastructure environments, so the enterprise has to determine how their controls interact. The vocabulary is expanding with the technology: orchestration, context management, harnesses and control planes increasingly describe functions that intersect across products and layers.

As those functions spread across the AI stack, an unattributed editorial formulation captures the tension: “The control functions might be coming together. The places where those controls live are multiplying.” Individual systems can provide stronger controls while giving the enterprise more places where consequential decisions are made. CIOs therefore need to understand authority across the full workflow as well as the capability of each component.

That architectural question begins once an individual technology has been chosen. A CIO still needs to know whether a model or agent works for a particular use case, then establish which system governs its behavior, which other systems constrain it and which decision takes precedence when controls overlap. Those answers determine whether governance works coherently from the initial request through the resulting AI action.

AI control is emerging from several layers at once

The multiplication begins with orchestration, whose earlier role centered on coordinating agents, applications and workflows. An agent harness expands that surrounding function by providing context management, memory, tools, guardrails, monitoring, error handling and governance around a model. A model-agnostic harness can reduce the rebuilding required when an enterprise changes the underlying model, although replacing a model can still require other work.

Salesforce is extending this approach across agents from multiple vendors. Its Enterprise AI Harness is designed to orchestrate and govern agents across systems while bringing identity, permissions, governance, observability, orchestration and cost visibility into the surrounding environment. Salesforce calls the observability component beneath that broader harness its “AI Control Plane.” Salesforce sells enterprise AI products and benefits commercially when customers use its technology for these control functions, so the naming should be read alongside the architecture: the control plane sits inside a broader collection of controls and has authority over the functions assigned to it.

A different control decision appears at runtime, where GitHub’s experimental HydraFusion can dynamically select a model or combination of models according to the work being performed. Some model-selection authority can therefore move from initial tool adoption into execution, allowing the system to choose how a particular unit of work should be handled. GitHub has a commercial interest in developer and AI platforms that manage such execution, while HydraFusion illustrates the broader architectural consequence of runtime routing.

Once routing becomes dynamic, model selection becomes a governed runtime decision because the outcome can affect cost, behavior and the systems involved in execution. A platform making this choice holds meaningful authority over which model or set of models receives the work. HydraFusion therefore places control at a different boundary from a harness that surrounds and governs an agent.

Alteryx places another boundary around governed data and business logic. Its position between enterprise AI systems and governed information gives it a role in determining which trusted business material AI can use and under which existing logic. Alteryx commercially benefits when enterprises use its data and analytics technology in that role, while the architectural function remains distinct: it shapes what an AI action can know and rely on.

Infrastructure creates another source of authority, which Mistral addresses through deployment and provider choices. The European model provider emphasizes deployment flexibility, infrastructure control, data location and reduced dependence on individual providers in its enterprise positioning. Mistral sells models and related enterprise offerings, so it benefits from demand for those deployment options. The underlying decisions determine where AI runs, where information resides and how much dependence an enterprise accepts on particular model suppliers.

Integration introduces another control boundary because an agent can act across systems on a person’s behalf. At Boomi World Tour Sydney, Boomi’s Asia Pacific and Japan CTO described governance that covers routing queries to suitable models and carrying a person’s access rights into an agent acting for that person. Boomi is an integration vendor and commercially benefits when integration technology governs connections among enterprise systems. Its example shows why integration decisions can become identity and authorization decisions once agents cross system boundaries.

Together, these approaches place authority at different points in an AI workflow. Salesforce brings together agent orchestration and governance; HydraFusion can make model selection a runtime decision; Alteryx sits around governed information and business logic; Mistral gives enterprises choices around deployment and infrastructure; and Boomi connects routing with identity and permissions. Their functions meet when a single workflow depends on several of them, even though each platform performs a different role.

Those meeting points explain the architectural importance of agent harnesses. A harness can centralize many capabilities immediately surrounding a model or agent, while the agent may still use identity maintained elsewhere, governed data from another platform, runtime routing from another system and infrastructure controlled by a separate team or provider. Authority across the enterprise therefore depends on how the harness interacts with those external controls.

The problem appears when legitimate controls meet in one workflow

Once these control points meet, individually sensible technology choices become a system-level issue. An enterprise could use Salesforce controls, GitHub routing and an Alteryx governed data layer while also running Microsoft agents, several commercial models, internally developed models and AI embedded in applications it already owns. Each selection can address a legitimate business or technical need. Their combined operation is where CIOs have to reason about control as an architecture.

Within that combined environment, one platform might choose which model executes a task while another determines which enterprise data the task can access and a third governs the agent taking the resulting action. The workflow can cross an application, enterprise data, identity, security and infrastructure before it finishes. Agents consequently depend on trusted data, security boundaries, identity, context and oversight, along with controlled ways to interact with enterprise systems and other agents.

Those dependencies can raise switching costs because vendors may control important routing or integration points while business logic, context, permissions and orchestration become tied to individual platforms. Replacing one vendor then requires the enterprise to identify the decisions and dependencies embedded in that platform and move them safely. The architecture of authority consequently affects future portability as well as current governance.

The same technical dependencies also cross organizational boundaries. Application, data, security, infrastructure, architecture and AI teams can each own a legitimate part of the workflow, so strong ownership within one domain still leaves responsibility for the combined action unresolved. CIOs need a way to see how those domain decisions interact when one AI agent acts across several of them.

That combined view becomes critical when two controls affect the same decision. CIOs increasingly need to understand how systems that orchestrate, route, observe and govern agents relate to one another and which system takes precedence when their decisions conflict. Functional convergence creates these intersections, while the products and teams containing those functions can continue to multiply.

The pattern resembles a familiar enterprise IT problem. Applications, integrations, data and business processes have often developed independently, producing fragmentation that enterprises later had to reduce. AI controls can create the same kind of accumulation when adopted independently, even though each control is intended to make a complex AI environment easier to manage. The risk comes from the relationships among purchases and design decisions.

Authority can be federated across control layers

Because the problem lies in those relationships, coherent authority can span several products. A single enterprise-wide control plane may be infeasible while AI technology and its vendor market continue to change quickly, and different platforms can be suited to govern different domains. The architectural objective is to assign authority clearly across the estate and define how those assignments interact.

Salesforce provides one example of such a division. An enterprise can use Salesforce orchestration while placing ultimate authority for enterprise identity, data governance or some model-routing decisions elsewhere. In the same architecture, a data platform can remain authoritative for access to trusted business information while agent governance remains with another system.

This division works when each layer has explicit boundaries. One layer can be authoritative for identity, another for data access and another for model routing, provided the enterprise knows what each layer controls, what it depends on and which decision prevails where scopes overlap. Multiple control layers then form a deliberate architecture rather than an accidental collection of products.

The exact division can vary by enterprise because AI platforms, deployment patterns and control requirements remain fluid. A universal architecture prescribed today would have to span environments with different applications, data estates, security models and infrastructure choices. Explicitly assigning authority is therefore more useful than assuming every important decision will eventually move into one control plane.

Map AI control authority before deciding what to standardize

Once authority can be distributed deliberately, the practical starting point is to make the existing distribution visible. A product inventory shows which technologies the enterprise owns, while an architectural map needs to capture what those technologies govern and how their decisions relate. Six dimensions make that map concrete:

Those six dimensions connect a control’s technical function to its place in the wider architecture. Scope and authority establish the decisions a layer can make, ownership connects those decisions to an accountable team, and dependencies show what a change can affect. Telemetry makes activity and policy decisions visible for oversight, while precedence determines the outcome when authority overlaps.

With those properties recorded, the map can follow interactions between products. If one layer governs an agent, another supplies its identity and a third routes its request to a model, the enterprise needs to trace how policy and telemetry cross those boundaries. A conflict over the same agent, identity, workflow or data then has a predetermined outcome, especially when separate teams own the systems involved.

Those interactions also show which policies belong above individual product choices. Identity and permission rules, for example, can remain consistent across platforms while application-specific orchestration stays local. Applications can then coordinate agents according to their own requirements while relying on a shared identity policy.

Data access can use the same division of authority. An enterprise can establish one authoritative source for data-access policy while allowing separate products to decide how work is routed among models. The data authority decides whether information may be used, and routing systems decide which model handles the work within their defined scope.

Observability provides another opportunity for common requirements across different products. An enterprise can require consistent observability and auditability across agents from several vendors while retaining different orchestration and agent technologies. Common visibility lets architecture and governance teams inspect activity, costs, errors and policy decisions across boundaries.

The order of these decisions matters because standardization is easier once the control points are visible. CIOs can identify controls across models, agents, data, identity and applications, then record their ownership, dependencies and interactions before choosing which controls should be common and which should remain local. Ongoing agent deployments can continue during that work, provided each new control point is added to the enterprise’s map of authority and dependencies.

That mapping also exposes a consequence of technologies designed to manage complex agent environments: each management technology can itself become another control layer. Once its scope, dependencies and precedence are explicit, the enterprise can decide whether to unify that function or keep it distributed. One platform can own a routing decision, another can own data-access policy and another can provide enterprise identity, with their combined behavior defined before an agent crosses those boundaries.

Key executive takeaways

• Treat AI control as an architecture problem: CIOs need to understand how orchestration, model routing, data access, identity, permissions and infrastructure interact. More control products can create overlapping authority across a single AI action.
• Identify where authority enters the AI stack: Harnesses, runtime routers, data platforms, integration systems and infrastructure providers can each control different parts of execution. Architecture teams can use these boundaries to establish which system governs each consequential decision.
• Define precedence across overlapping controls: A single workflow can cross several platforms and organizational owners, creating conflicts over routing, permissions, data and agent actions. CIOs can resolve these intersections by specifying which control takes precedence before agents cross system boundaries.
• Federate authority with explicit boundaries: Enterprises can assign identity, data access, model routing and agent governance to different authoritative systems. Clear scopes and precedence rules allow multiple control layers to operate as a deliberate architecture.
• Map authority before standardizing AI controls: CIOs can document each control layer’s scope, authority, owner, dependencies, telemetry and precedence, then trace interactions across products. That map reveals where common policies are useful and where local control can remain.