Explainer· Independently researched

Agentic AI Systems: Control, Governance, and Practical Use

Explore agentic AI systems, their control layers, governance, and how they differ from conventional AI models in business automation.

Agentic AI Systems: Control, Governance, and Practical Use

An agent is not a chatbot with extra confidence

The useful distinction between a conventional AI model and an agentic system is not that one “reasons” and the other does not. It is whether the model can cause something to happen outside the conversation.

A language model takes an input and generates an output. Ask it to draft a refund response, and it drafts one. An agentic system wraps that model in a control loop: it gives the model a goal, relevant context, a list of permitted tools, and some ability to choose the next step. The output may become an API call to retrieve an order, create a support ticket, update a CRM record, issue a refund, or send a message. That additional loop is where most of the commercial value lies, and where most of the operational risk enters.

This is why the central engineering problem is not “how intelligent is the agent?” It is: who is allowed to turn a model suggestion into an action, under what conditions, and with what evidence?

Deloitte describes one answer as an agent action enforcement layer, a control point between an agent’s proposed action and the company systems that action would affect. [2] It is a less glamorous idea than an autonomous digital worker, but it is the part that determines whether an agent is a manageable business system or an expensive way to automate mistakes.

The action boundary is where agentic AI becomes real

Consider a conventional customer-service model. A customer says that a blender arrived damaged. The model may summarize the complaint, identify the likely policy, and draft a reply. A human support representative still checks the order and presses the refund button. The model has assisted the work, but it has not acted.

An agentic refund system can do more. It may:

  1. Read the incoming email or chat.
  2. Look up the customer and order in a commerce system.
  3. Inspect the stated return policy.
  4. Ask a vision model to assess a photo of the damaged item.
  5. Calculate whether the order is eligible for an automatic refund.
  6. Call the payment or order-management API.
  7. Record the outcome and notify the customer.

That chain is not one model response. It is an orchestration system making a sequence of model calls, database queries, tool calls, permissions checks and state updates. Each step can fail independently. The model may misunderstand the complaint. The data connector may return the wrong customer record. A policy document may be outdated. An API may succeed but the logging system may not record the result. The agent can also take a perfectly valid action in the wrong business context, such as refunding an order that is technically eligible but already under chargeback investigation.

IBM Technology makes the underlying decision split clearly in its comparison between AI agents and business rules. A business rule might specify: approve a return if the order is less than 30 days old and the item is not marked final sale. The result is deterministic. Given the same facts, the rule produces the same result.

An agent works differently. It receives a goal, context and tools, then selects steps based on a language model’s probabilistic output. This makes it useful when the request contains free text, images, incomplete information or unusual circumstances. “The dumbbells were too heavy” is not a neat field in a database, but it is a reason that requires interpretation. The cost of that flexibility is that two runs may not make identical choices, and the explanation for a choice is less crisp than a rule branch.

The sensible architecture is therefore usually hybrid, not agent-only. Rules should make the decisions that are already well-defined, low-cost and subject to audit. Agents should handle ambiguity, extract facts from messy inputs, gather context and recommend or prepare actions. A further set of deterministic controls should decide whether the proposed action is allowed.

That is the enforcement layer in practical terms.

What an enforcement layer actually does

An action enforcement layer is not merely a prompt telling the agent to be careful. It is an external system that evaluates proposed actions before they reach a business system. The agent might propose:

Issue a $250 refund to customer account 18472.

The control layer turns that proposal into checks that software can verify:

  • Is this agent identity permitted to invoke the refund API?
  • Is the customer account and order ID valid?
  • Does the requested amount match the order value?
  • Does the order meet an automatic-refund rule?
  • Has the customer exceeded a refund-frequency threshold?
  • Is the amount above the agent’s financial authority?
  • Is the action taking place in a permitted jurisdiction?
  • Is a human approval required?
  • Has the same action already been attempted?
  • Will the system produce an immutable audit record?

The important design choice is that the agent does not get broad credentials and unrestricted tools. It receives narrow, scoped capabilities. An agent that can look up order details need not be able to alter a payment record. An agent allowed to offer a $20 goodwill credit should not also be able to cancel an enterprise contract.

This resembles conventional application security more than it resembles a science-fiction safety system. Permissioning, identity, policy evaluation, rate limits, approval queues and audit records are familiar controls. The difference is that agents choose actions dynamically, rather than following a fixed application workflow. The enforcement layer must therefore evaluate intent at runtime.

Deloitte’s framing matters because agent governance cannot stop at access control. [2] Role-based access control can answer whether an agent may call a tool, but not necessarily whether it should call the tool in this situation. A sales agent may be authorised to update a CRM record, for example, while still being prohibited from marking an opportunity as closed-won without a signed contract attached.

The control layer needs business context as well as technical permissions.

Why “let the model decide” is usually the expensive option

The appeal of agents is that they can replace brittle workflow design with general-purpose judgment. In a narrow set of cases, that is true. In many business processes, however, the decision logic is not actually ambiguous. It is simply poorly documented or scattered among older systems.

Alex Lieberman, co-founder of Morning Brew and 10X, describes this from the consulting side in an interview on the David Ondrej channel. His firm separates “single-player” AI, where an employee gets a capable assistant, from “multiplayer” AI, where a process is redesigned to create leverage for an entire function. He also says that many supposed AI projects quickly turn into data-engineering work because companies are not ready to build agents on their existing data.

That observation is more useful than the usual claim that every company needs autonomous agents. An accounts-payable agent cannot reconcile invoices reliably if vendor identifiers differ across systems, approval histories are incomplete, and invoices arrive in inconsistent formats. The model can paper over some messiness, but it cannot establish a trustworthy source of truth where none exists.

Legacy integration is repeatedly cited as a major failure point in agent automation. [5] A phased approach, with constrained integrations and clear system boundaries, is more credible than attaching a general-purpose agent directly to a company’s production estate. [9] The limitation is not merely technical debt in the abstract. It is that an agent must make decisions across systems whose data definitions, permissions and failure modes were designed independently.

The apparent cost of an agent is often the model API bill. The real cost includes connectors, identity management, data cleaning, evaluation, exception handling, monitoring, human review and redesigning processes that previously depended on informal judgment.

That is also why claimed productivity gains deserve scrutiny. Research comparing expectations with realised productivity found a 43 percentage-point gap between anticipated gains from agentic AI and observed results in the developer setting it studied. Organisations expected a 24% speed-up, while measured productivity was a 19% slowdown. [1] That does not show that agents are useless. It shows that model capability is only one variable in a deployed workflow. Review overhead, coordination costs and poor task fit can erase a model’s apparent speed.

Communication creates a second control problem

Once companies deploy several agents, the challenge becomes more than supervising individual actions. It becomes supervising coordination.

Google Cloud Tech’s Gemini Enterprise and Workspace material presents agents as productivity tools integrated with the documents, calendars and information systems where work already happens. That is a plausible location for useful agents, because the relevant context is nearby. But proximity to company data raises the stakes for access boundaries, retention and auditability.

Google Gemini Enterprise is sold in several editions, according to secondary pricing reports: Business at $21 per user per month, Standard at $30, and Plus at $50. Frontline is described as requiring a minimum purchase of 150 Standard or Plus seats. These figures may vary by contract, region and volume discount, and Google or an authorised reseller is the appropriate source for a current quote. Business suits smaller teams seeking general enterprise AI access; Standard suits organisations needing broader deployment; Plus suits teams with more demanding capabilities and governance needs; Frontline is aimed at large frontline-worker deployments. None of these seat prices captures integration, implementation or additional compute consumption.

The agent communication issue is less visible. The AI Revolution channel describes research on latent communication, where models pass internal numerical representations rather than human-readable text. The claimed attraction is performance: fewer generated tokens and faster exchanges between agents. The channel correctly notes an important limitation of the cited auction experiment: it is a controlled setup in which agents are instructed to use a private signal, not evidence that deployed agents spontaneously invent covert languages.

Still, the governance concern is real. If an agent’s meaningful communication occurs through API calls, tool state, hidden model representations or intermediate workflow messages, a chat transcript is not an adequate audit trail. The EU AI Act’s requirements for high-risk systems include logging obligations, with guidance describing six-month log retention from August 2026. [3] Traditional logs often record that an API call occurred, not the full context that made an agent select it.

IBM has responded to this gap with monitoring capabilities for agentic systems, focused on telemetry across agent activity rather than only the final model output. [4] That is the right direction, though telemetry alone is not accountability. A useful record must link the request, retrieved information, policy version, model version, tool calls, proposed action, enforcement decision and final business outcome.

Without that chain, a company can know that a refund happened without being able to establish why it happened.

The practical definition of a good agent

A good business agent is not one that appears maximally autonomous. It is one that handles uncertainty where uncertainty genuinely exists, while leaving clear policy decisions to deterministic software and high-impact exceptions to accountable people.

IBM Technology’s refund example captures the pattern: rules resolve ordinary cases quickly; an agent interprets messy evidence or gathers missing context; guardrails constrain the resulting recommendation; a human handles high-value or high-risk decisions. That design may look less dramatic than an agent empowered to run an entire department. It is also much closer to how organisations can obtain useful automation without giving a probabilistic model unchecked authority.

Agentic AI differs from traditional AI because it operates through a loop of observation, planning, tool use and action. The enforcement layer determines whether that loop is safe enough to put near real systems. Treat it as a core product component, not compliance theatre added after deployment.

Frequently Asked Questions

What distinguishes agentic AI systems from conventional AI models?

Agentic AI systems differ from conventional AI models in that they can cause actions to happen outside the conversation. While a conventional language model generates outputs like drafted responses, an agentic system wraps the model in a control loop that provides goals, context, permitted tools, and the ability to choose next steps, resulting in actions such as API calls or database updates.

How does an agent action enforcement layer work in agentic AI?

An agent action enforcement layer is an external control system that evaluates proposed agent actions before they affect business systems. It verifies permissions, validates data, checks policy compliance, enforces approval requirements, and ensures auditability. This layer restricts agents to narrowly scoped capabilities and assesses intent at runtime to prevent unauthorized or inappropriate actions.

What are the main challenges in deploying agentic AI systems?

Key challenges include integration difficulties with legacy systems, dependency on high-quality data, opaque decision-making processes, lack of accountability, high costs of scaling, and a high failure rate in production deployments. Additionally, agents can make valid but contextually incorrect decisions, and each step in the orchestration chain can fail independently, increasing operational risk.

Why is governance important for agentic AI systems?

Governance is crucial because agentic AI systems dynamically select actions, requiring controls beyond simple access permissions. Effective governance combines role-based access control with business context to determine not only if an agent can perform an action but whether it should in a given situation. This helps manage operational risks and ensures actions comply with policies and regulations.

Sources

Watch AI Agents and Agentic AI Systems on Youtube