AI agents have crossed an important psychological line. A chatbot answers. An agent acts. It can search, summarise, call tools, update records, trigger workflows, draft code, raise tickets, compile reports and hand work to another system. That shift is why enterprise AI feels different in 2026.
Recent enterprise AI research and commentary point to a common pattern: organisations are pushing agents into workflows faster than their governance, monitoring and operating models can mature. The excitement is understandable. Every executive wants faster service, lower manual effort and better use of corporate knowledge. But the control gap is real.
Frankly, the problem is not that agents are intelligent. The problem is that many are being given authority before the organisation has defined accountability.
From assistant to actor
The first wave of generative AI was relatively contained. Employees used tools to draft emails, summarise documents, brainstorm ideas and create first-pass analysis. The risk was mostly about data leakage, hallucination, intellectual property and overreliance.
Agents change the risk profile because they interact with systems of record. An agent that summarises a sales call is helpful. An agent that updates forecast probability, offers a discount, emails a customer and opens a legal review is part of the revenue process. An agent that answers an HR policy question is one thing. An agent that changes an employee record or initiates onboarding tasks is another.
The hard truth is that enterprise control models were built around humans and applications, not semi-autonomous digital workers. Humans have managers, job descriptions, approval limits and disciplinary consequences. Applications have change controls, service owners and access policies. Agents sit awkwardly between the two.
I once advised a bank that wanted to automate parts of operations triage. The technology demo was impressive. The uncomfortable question was simple: if the agent misrouted a high-risk customer case, who owned the miss? The business team pointed to technology. Technology pointed to operations. Operations pointed to the vendor. That circular accountability was more dangerous than the model error. In production, ambiguity compounds faster than bad code, because every team waits for someone else to pull the brake.
The control gap in plain English
An enterprise control gap appears when an agent can do more than the organisation can explain, monitor or reverse. It has five common symptoms.
First, unclear ownership. Teams deploy agents as productivity aids without naming a business owner for outcomes, exceptions and failures.
Second, broad permissions. Agents inherit human-like access or service-account privileges without the narrower scope required for a specific task.
Third, weak approval paths. The agent can recommend, route or execute actions without clear thresholds for human approval.
Fourth, poor observability. Logs capture technical events but not business intent: why the agent acted, what evidence it used, and which policy allowed the decision.
Fifth, limited rollback. Once an agent updates records, sends messages or triggers downstream workflows, undoing the action becomes messy.
These are not theoretical concerns. They are the same operational weaknesses enterprises have seen with robotic process automation, shadow SaaS and poorly governed scripts. Agents simply make the weakness more scalable.
Treat agents like junior employees with system access
The best analogy I have found with executives is not “agent as software”. It is “agent as a junior employee with system access and no common sense unless you design it in”. That phrase usually changes the conversation, because executives immediately understand the management burden behind the automation promise.
A junior employee needs a role, training, supervision, limits and escalation paths. You would not give a new analyst authority to approve payments, change supplier details and email customers without oversight. Yet many agent pilots effectively do this in digital form because the interface feels harmless.
This framing helps leaders ask better questions:
- What is the agent’s job description?
- Which systems can it access?
- Which actions can it take without approval?
- Which actions require human review?
- Who reviews exceptions?
- How is performance measured?
- How is the agent retired or suspended?
The answer should not be buried in a technical design document. It should be understandable to the business owner whose process is being automated.
Governance cannot live in policy documents
Many organisations respond to AI risk by writing principles. Be fair. Be transparent. Keep humans in control. Protect data. These principles are useful, but agents need runtime governance, not just policy language.
Runtime governance means controls operate while the agent works. Permissions restrict what it can touch. Guardrails block forbidden actions. Monitoring spots unusual behaviour. Approval workflows pause high-risk decisions. Audit trails record the evidence behind actions. Kill switches suspend agents that behave outside tolerance.
This is where the operating model becomes more important than the model. A less capable agent with strong controls is often safer and more valuable than a brilliant agent with vague boundaries.
I once saw a customer-service automation programme succeed not because the AI was extraordinary, but because the escalation design was excellent. The agent could resolve routine questions, but billing disputes, cancellation threats and vulnerable-customer cases moved quickly to humans. The business did not pretend autonomy was universal. It designed autonomy around risk.
The metrics leaders should demand
If the only metric is hours saved, the programme will drift towards reckless automation. Leaders need a balanced scorecard.
For each production agent, track volume handled, human review rate, exception rate, error rate, customer or employee impact, policy violations, manual rework and financial exposure. For engineering agents, track review latency, defect escape, test coverage and rollback. For finance agents, track approval exceptions, duplicate actions and reconciliation breaks. For HR agents, track privacy incidents and sensitive-case escalation.
The P&L question is equally important. Does the agent reduce cost, improve revenue, reduce risk, or merely shift work from one team to another? I have seen automation projects celebrate a reduction in front-office effort while quietly increasing back-office reconciliation. That is not productivity; it is cost relocation.
Boards and CIOs should also ask for an agent inventory. If the organisation cannot list where agents are deployed, what they access and who owns them, it is not ready to scale.
APAC realities: language, regulation and process diversity
In APAC, agent governance has extra complexity. Regional organisations often operate across languages, regulatory expectations and locally adapted processes. A workflow that is low-risk in one market may be sensitive in another. A customer-service script that works in English may fail culturally or legally in another language. Data residency and outsourcing expectations may differ by country and sector.
This does not mean APAC firms should slow down indefinitely. It means they should design agents with jurisdiction-aware controls. Data access, retention, human review and customer communication rules should reflect local obligations. Regional CIOs need reusable governance patterns, but not one-size-fits-all deployment.
The practical approach is to start with contained workflows where success and failure are measurable. Internal knowledge retrieval, ticket classification, compliance evidence gathering and low-risk service tasks are better early candidates than autonomous financial approvals or regulated customer decisions.
The role of humans changes
The phrase “human in the loop” is often used lazily. A human who rubber-stamps hundreds of AI decisions is not control. A human who receives only ambiguous, high-impact exceptions with clear evidence can be very effective.
The future role of humans is not to watch every agent action. It is to set policy, define thresholds, handle exceptions, review outcomes and improve the playbook. That is a higher-value role, but only if the organisation invests in it.
The bottom line is that agents do not remove management work. They change its shape. Managers must become designers of decision rights, not just supervisors of people.
A practical control model
Every enterprise agent should have a simple control card before production:
- Purpose: the business outcome it supports.
- Owner: the accountable business leader.
- Data boundary: what it can read and retain.
- Action boundary: what it can change or trigger.
- Approval rules: when humans must review.
- Monitoring: what behaviour is logged and alerted.
- Exception path: where uncertain cases go.
- Failure mode: how to pause, reverse or retire it.
This is not bureaucracy for its own sake. It is the minimum management system for digital labour.
Scale with discipline, not fear
The wrong conclusion is that enterprises should avoid agents. That would be like avoiding cloud because poorly governed cloud creates risk. The right conclusion is that autonomy must be earned.
Start small, prove value, measure exceptions, strengthen controls, then widen scope. Do not jump from pilot enthusiasm to enterprise-wide authority. Do not confuse a successful demo with a production operating model. And do not allow agents to become a new form of shadow IT simply because they arrive through friendly productivity tools.
AI agents will change enterprise work. I am convinced of that. But the winners will not be the companies with the most agents. They will be the companies that know exactly what each agent is allowed to do, why it is allowed to do it, and who is accountable when it gets it wrong.