The first enterprise AI question was often:
Can the model produce a useful answer?
The Agentic AI question is more difficult:
What happens when the system can pursue a goal, use tools and continue acting after nobody is watching each individual step?
That changes the risk profile completely.
A poor answer can often be corrected in a conversation.
A poor action can change a customer record, expose information, create a financial commitment, send an external communication, modify a system or trigger another agent.
As AI agents gain authority, the challenge is no longer simply model quality.
It is control.
Enterprises therefore need something around their agents that separates intelligence from authority. This article is part of my Agentic AI reading path, alongside practical guidance on orchestration, trusted autonomy and security.
I think of this as the Agentic AI control plane.
It is the combination of:
- identity;
- permissions;
- policy enforcement;
- model routing;
- tool governance;
- cost controls;
- traceability;
- evaluation;
- human intervention; and
- operational safeguards
that determines what an agent is actually allowed to do.
Its purpose is not to eliminate autonomy.
Its purpose is to make autonomy visible, bounded and recoverable.
Autonomy Turns Software Risk Into Operating Risk
The OECD's 2026 analysis distinguishes broader Agentic AI systems through characteristics such as coordination, task decomposition, delegation, sustained operation and activity inside complex environments with limited human oversight.
Those capabilities create value precisely because an agent can keep working.
They also mean that the conventional model of reviewing one input and one output is insufficient.
An agentic system has:
- state;
- goals;
- tools;
- permissions;
- external dependencies; and
- side effects.
It may call another agent.
It may retrieve information from a source that changed five minutes ago.
It may retry a failed tool.
It may choose a different path because an exception occurred.
It may wait for an approval and resume later.
Each step introduces another point where actual behaviour can diverge from the intended outcome.
The right question is therefore not merely:
"Was the answer correct?"
It becomes:
"Was this agent authorised to take this action, based on this evidence, using this tool, for this user, under this policy?"
That is an architectural question.
The Control Plane Separates Intelligence From Authority
An LLM can propose an action.
That does not mean the model should decide whether the action is permitted.
This separation is fundamental.
The reasoning layer might conclude:
Issue a £200 customer credit.
The control plane should determine:
- whether this agent can issue credits;
- whether this user or customer is eligible;
- what evidence is required;
- whether £200 exceeds the autonomous threshold;
- whether human approval is required;
- whether the action conflicts with another policy; and
- how the action and approval should be recorded.
The model proposes.
The control plane governs execution.
That distinction will become increasingly important as enterprises operate larger numbers of AI agents. The same boundary underpins my view that autonomy should be treated as delegated authority, not simply as a capability to maximise.
Security Is a Boundary, Not a Checklist
An agent connected to CRM, ticketing, source code, financial systems or customer communications has a very different risk profile from a read-only assistant.
Least privilege therefore needs to apply not only to users, but also to agents, tools and individual actions.
A useful permission model separates several dimensions.
Read Access
Which records, systems and fields may the agent retrieve?
Write Access
Which records may it change, and which fields are writable?
Delegation
Which other agents, services or workflows may it invoke?
External Communication
Can it send something directly to a customer, partner or supplier?
Financial Authority
Can it issue a refund, credit, order or other financial commitment?
Policy Exceptions
Who can approve activity outside the normal boundary, and how is that approval recorded?
Permissions should also be purpose-limited.
A customer-service agent resolving one customer's case may need that customer's interaction history and account status.
It does not need permission to export the entire customer database.
A development agent might be allowed to create a branch and open a pull request.
Production deployment could remain controlled through a separate pipeline or human approval.
This is not about reducing the usefulness of the agent.
It is about matching authority to purpose.
Treat Context as Untrusted Until Proven Otherwise
Agent security is not limited to identity and credentials. It should follow the same security-by-default discipline applied to data, identity, dependencies and operations elsewhere in the platform.
The content an agent reads can also influence its behaviour.
Documents, tickets, websites, messages and retrieved records may contain text that looks like an instruction.
That does not make it authoritative.
The system needs to distinguish between:
data the agent may consider
and
instructions the agent is permitted to follow.
A retrieved document should not be able to expand the agent's permissions, modify its objective or bypass an approval boundary simply because its contents were included in context.
This distinction becomes particularly important when agents operate across external and semi-trusted information sources.
Model Monoculture Can Become an Enterprise Risk
Harvard Business Review's discussion of the "agentic convergence trap" raises another interesting control problem.
If several independent AI systems consume similar information, use similar models and optimise towards similar objectives, they may arrive at similar conclusions at machine speed.
That reduces genuine diversity of judgement and can amplify a shared blind spot.
The conclusion is not that every agent needs a different model.
It is that an organisation should understand where correlated failure could matter.
Model diversity may involve:
- different model families;
- different information sources;
- different prompts;
- specialist review agents;
- different optimisation objectives; or
- deliberate adversarial review.
For example, a revenue optimisation agent and a compliance review agent should not necessarily optimise towards the same definition of success.
A customer-resolution agent should not be measured only on closing cases quickly if doing so increases repeat contact or poor customer outcomes.
Diversity needs to be intentional.
Simply operating several untested models is not resilience.
Every consequential agent role should have:
- a clear responsibility;
- representative evaluation cases;
- known failure modes;
- measurable performance; and
- a defined replacement path.
The control plane should also record which model, version, tools and policies contributed to consequential decisions.
Governance Must Operate at Machine Speed
Agentic systems can act far faster than traditional governance processes.
That means governance cannot exist only as policy documents and periodic committees.
Gartner's 2026 discussion of Agentic AI highlights governance, security and FinOps among the emerging operational concerns surrounding the technology.
The implication is important.
Control is not a compliance stage added after deployment.
It is part of the runtime architecture.
A principle such as:
"Use AI responsibly"
cannot be directly enforced.
A useful control needs to be translated into rules such as:
- maximum autonomous transaction value;
- prohibited actions;
- restricted data categories;
- mandatory approval for external communication;
- evidence requirements for high-impact actions;
- maximum unattended execution time;
- retry limits;
- budget limits;
- escalation conditions;
- a kill switch;
- a named owner; and
- retention requirements for traces and outputs.
Those controls should also be versioned.
If the workflow, model, tool or policy changes, the organisation should be able to identify which runs were affected.
Cost Is Part of the Control Plane
Traditional AI cost management often focuses on token usage.
That is too narrow for Agentic AI.
An agent may:
- plan;
- retrieve;
- call tools;
- invoke another agent;
- retry;
- review its own work;
- wait;
- resume; and
- involve a human.
A workflow can be technically successful and economically unsuccessful.
The useful metric is therefore not simply:
cost per model call
but:
cost per completed business outcome.
That can include:
- model consumption;
- retrieval;
- infrastructure;
- external tool costs;
- retries;
- additional agent calls; and
- human review.
Budgets should exist at several levels.
A single run may have a limit.
A workflow may have a limit.
An agent team may have a limit.
A department may have a monthly limit.
A system that repeatedly retries a failing API or loops around an ambiguous decision should eventually stop and escalate.
Unlimited persistence is not intelligence.
Cost also influences architecture.
A smaller model may be perfectly adequate for classification or routing.
A more capable model can be reserved for the decisions that require deeper reasoning.
Stable context can be cached.
Unnecessary agent hand-offs can be removed.
FinOps can therefore expose poor workflow design, not merely expensive models.
Observability Is the Prerequisite for Trust
Traditional application monitoring asks questions such as:
Is the service running?
What is the latency?
How many errors occurred?
Agentic AI needs another level of visibility.
An operator may need to understand:
- what the agent was trying to achieve;
- what information it received;
- which information it trusted;
- which model was involved;
- which tools were called;
- what those tools returned;
- what policy allowed the action;
- where a human intervened;
- what side effect occurred; and
- what eventually happened to the business outcome.
At minimum, consequential runs should capture:
- the initiating goal, actor and business context;
- model and policy versions;
- relevant retrieved sources and timestamps;
- tool calls, arguments, permissions and responses;
- significant decisions and escalation events;
- human approvals or interventions;
- external side effects and reversals;
- run duration;
- cost; and
- retry behaviour.
That does not mean storing everything forever.
Observability itself needs governance.
Customer and employee information still requires minimisation, access controls and appropriate retention periods.
The objective is to retain enough evidence to understand and investigate behaviour without accidentally creating a second uncontrolled data repository.
Evaluation Must Test Failure, Not Just Success
Many AI evaluations still ask whether a model answered representative questions correctly.
An Agentic AI evaluation needs to ask much more.
What happens when:
- two trusted systems disagree?
- an API becomes unavailable?
- a user's permission changes during the workflow?
- retrieved content contains a malicious instruction?
- the agent cannot gather enough evidence?
- a tool repeatedly fails?
- another agent returns an unexpected response?
- the preferred model is replaced?
- the workflow exceeds its budget?
- a human rejects the recommended action?
The desired result is not always task completion.
Sometimes the correct behaviour is:
stop, explain and escalate.
A safe escalation is not an agent failure.
It may be evidence that the control plane is working correctly.
The practical release-evidence approach is covered in AI agent evaluation for complete production systems, including outcome contracts, execution checks and recurring regression tests.
Build the Control Plane Before the Agent Fleet
Platform teams should be careful about allowing dozens of independent AI agents to appear across an organisation, each with bespoke credentials, policies and integrations.
Start with shared capabilities. An AI agent orchestration platform can provide part of this shared operating layer, but it does not decide what authority each agent should receive.
At minimum, consider common mechanisms for:
- agent identity;
- authentication;
- tool registration;
- permissions;
- policy enforcement;
- run tracing;
- budgets;
- evaluation;
- approvals;
- secrets;
- credential rotation; and
- emergency shutdown.
Then place specialised agents behind those controls.
This makes the architecture easier to operate, easier to audit and easier to explain. Across technology delivery and product development, those boundaries need clear ownership and production evidence.
It also reinforces an important separation:
The model provides intelligence.
The control plane provides authority.
Test the Control Plane Like Production Software
The control plane itself needs failure testing.
Exercise the kill switch.
Rotate credentials.
Revoke an agent's access while a workflow is running.
Take a downstream dependency offline.
Change an approval policy.
Trigger a budget threshold.
Cause a tool call to fail after an earlier step has already created a side effect.
Then ask:
Can the system recover?
Can it reverse what happened?
Can an operator reconstruct the sequence?
Can we explain the outcome without asking the model to invent a narrative about its own behaviour?
Those are production engineering questions.
Agentic AI does not remove the need for them.
It makes them more important.
A Practical Control-Plane Checklist
Before expanding autonomy:
- Inventory every agent, model, data source, tool, permission and external side effect.
- Give each agent a clearly defined identity and purpose.
- Separate read, write, delegation, communication and financial permissions.
- Define approval thresholds, prohibited actions and escalation conditions.
- Establish run, workflow and organisational budgets.
- Capture privacy-conscious traces linking goals, evidence, tools, policies, outcomes and human intervention.
- Evaluate failure scenarios as well as successful ones.
- Test credential rotation, permission revocation and kill switches.
- Treat safe escalation as a valid outcome.
- Expand autonomy only when evidence shows that the control environment can support it.
Agentic AI can create enormous leverage.
But leverage without control is exposure.
The organisations that benefit most will not necessarily be those that remove humans from the largest number of decisions.
They will be the ones that create enough visibility, authority boundaries and operational discipline for autonomy to increase safely.
If you are defining these boundaries for an enterprise platform, get in touch to discuss the architecture.
The future question may therefore not be:
"How autonomous is our AI?"
It may be:
"How confidently can we control the autonomy we give it?"
Sources
- Beware the Agentic Convergence Trap - Patrick van Esch, Yuanyuan Gina Cui and J. Stewart Black, Harvard Business Review, May 2026. Summarised, not reproduced.
- The Strongest Teams of AI Agents Will Be Built Using Different Models - Mark Purdy, Harvard Business Review, June 2026. Summarised, not reproduced.
- What the 2026 Gartner Hype Cycle for Agentic AI Reveals - Rajesh Kandaswamy, Gartner, April 2026.
- The Agentic AI Landscape and Its Conceptual Foundations - OECD, February 2026.