When AI agents can act across your business, who controls their decisions—and who owns the outcome?
Building an agent is becoming easier. Operating a growing portfolio of agents across departments requires a more deliberate architecture. My recommendation is to establish an enterprise agent control plane: a shared set of ownership, access, approval, monitoring and lifecycle controls that connects business intent to agent execution.
This is a timely discussion for the UAE. Microsoft has announced Agent 365 availability in UAE data centres starting October, positioning it around observability, governance and security. The announcement is a useful signal of industry direction; it does not establish that any particular organization is ready for autonomous operations. Source: Microsoft, September 2026.
McKinsey’s October 5 article similarly argues for redesigning work around outcomes and explicitly mapping how humans and agents cooperate. I see an architectural implication: ownership and operating rules need to travel with each workflow, rather than remain in a presentation separate from the systems doing the work. Source: McKinsey, October 5, 2026.
Watch the illustrated explanation
A 5-minute 25-second illustrated explanation, narrated with American Michael neural narration.
Watch and subscribe on YouTube
What is an agent control plane?
The control plane defines which agents exist, who owns them, what they may access, which actions require approval and how their performance is assessed. The execution layer carries out approved work through applications and tools. Keeping these responsibilities explicit makes it easier to change a model or orchestration platform without losing the business controls.
It can begin with a small agent register, existing identity controls and your current workflow engine. It does not require purchasing a new platform for every agent.
1. Strategy: assign an outcome and a decision owner
Start with a bounded business outcome such as reducing the time needed to qualify an enquiry. Name the owner who accepts the result and the people authorized to change the workflow. Then distinguish decisions the agent may make, recommendations it may prepare, and commitments reserved for a person.
For every agent, record its purpose, business owner, technical custodian, allowed actions, prohibited actions and escalation route. A workflow that can draft a proposal should not automatically inherit permission to approve discounts or commit to contractual terms.
2. Architecture: connect to trusted data and controlled tools
Map the workflow to the capabilities, information and applications it depends on. Give each agent a traceable identity and the minimum access needed for its role. Authorize tool calls at execution time; a persuasive model response is not an access decision.
Domain-owned data products can provide a useful foundation: each important dataset has an owner, defined meaning, freshness expectations and access rules. Where a data mesh approach is appropriate, shared governance and a usable platform must accompany domain ownership. Agents still need permission checks and evidence of the data used for a decision. Background: Zhamak Dehghani’s data mesh architecture.
In a multi-tenant platform, tenant identity must be enforced at every boundary: retrieval, credentials, workflow execution, storage and publishing. Do not rely on a tenant identifier placed only inside the prompt.
3. Execution: make approvals and recovery part of the workflow
Separate the stages that research, recommend, approve and execute. Define review thresholds according to the action’s consequences. Low-risk classification may run automatically; external commitments, financial actions or sensitive disclosures need the appropriate authorized review.
Each external action should have a durable record and a duplicate-prevention key. If a request times out, reconcile the destination before retrying: an uncertain response does not mean the action failed. Preserve the inputs, approval, tool result and exception path needed to investigate what happened.
Provide an operational stop mechanism and a manual route. If trusted data is unavailable or policy checks fail, the agent should hold the action and explain the missing condition to its owner.
4. Measure success: connect agent activity to business value
Measure the whole process, not just the number of agent runs. Establish a baseline before deployment and track cycle time, accepted output quality, exception rate, cost per completed outcome and realized business benefit. Monitor unauthorized-action attempts, duplicate actions and human review workload alongside productivity.
A faster workflow may still perform poorly if it creates more rework downstream. Increase autonomy only when evidence shows that the agreed quality, risk and cost thresholds are being met.
A practical example: enquiry to appointment
Illustrative scenario—not a reported client result. An agent receives a consulting enquiry, checks the permitted service catalogue and suggests a suitable appointment type. It can prepare a CRM record and an acknowledgement. The workflow checks for an existing enquiry before creating another record, and it reads approved calendar availability before proposing a slot.
The agent cannot invent a price, promise an unavailable date or use another tenant’s customer information. Unclear requests go to the consultant. Success is assessed through valid appointments, response time, conversion, errors and review effort—not simply messages generated.
A realistic first implementation
- Select one workflow with a clear owner and measurable baseline.
- Document its decisions, systems, data dependencies and approval limits.
- Register the agent and configure identity, scoped tools and tenant boundaries.
- Test normal cases, missing data, duplicate requests, timeouts and policy failures.
- Review actual results before expanding its permissions or scope.
A centralized control plane can introduce friction if it duplicates every domain decision. Keep enterprise-wide standards focused on identity, policy, evidence and shared risk; let domain owners remain accountable for their outcomes. The right balance depends on the consequences of the workflow and the organization’s operating model.
My perspective: an agentic enterprise needs a visible chain from strategy to decisions, architecture, execution and measured results. A control plane makes that chain operational—and gives leaders a practical basis for deciding where autonomy should grow.
Discuss your agentic operating model
Ahmad Al Shami · Consultant | Board Advisor · Strategy, Enterprise Architecture, Transformation & Agentic AI
Published 13 October 2026. Recommendations and the reference architecture are the author’s synthesis; the example is illustrative.