Back to Blog
Governance2026-07-28· 7 min read

Your AI Agents Need a Control Plane Before They Need Another Model

Better models make it easier to automate more work. They do not tell the business what the agent touched, whether the action was permitted, if the data was still true, or who approved the risk.

Claude Opus 5 arrived on July 24 with stronger results on agentic software work, business automation, and computer use. Anthropic reported that even its lowest effort setting completed more end-to-end tasks on Zapier's AutomationBench than any other model tested.

This is good news for businesses. More workflows that failed six months ago will now look viable. Longer tasks can run with fewer interventions. Work that needed a specialist model may become economical on a general-purpose one.

It also makes an old management habit more dangerous: treating a model upgrade as the answer to an operating problem.

A stronger model can make a better recommendation. It cannot decide how much authority the business intended to delegate. It cannot resolve conflicting sources of truth, invent an approval policy, or prove after the fact that the right checks happened. Those are control-plane problems.

The next buying decision is not another model

Model choice still matters. Different tasks need different levels of reasoning, speed, cost, and data handling. But once agents are doing real work, the bigger question is how the business governs all of those decisions across every workflow.

OpenRouter's new classifiers make the shift visible. Teams can now tag requests by department, task type, agent complexity, audience, compliance category, and cost centre, then inspect which models and business functions drive usage. The valuable idea is not the product feature itself. It is that unclassified agent activity is becoming an operational blind spot.

If you cannot tell which agent handled a customer-facing task, which data class it used, why it selected an expensive model, or which jobs regularly require escalation, you do not have a managed system. You have a collection of demos sharing a bill.

A practical agent control plane has four layers

A control plane does not need to be a large software platform. It is the set of rules, checks, logs, and review paths that sits above individual agents and determines how work is allowed to move.

01

Classify

Tag the task, data sensitivity, business owner, risk level, and cost centre before deciding how it should run.

02

Authorize

Define which actions the agent may prepare, execute, or escalate in this workflow, not merely which apps it can access.

03

Verify

Check consequential values against a live system of record at the moment of action, including status, ownership, limits, and duplicates.

04

Review

Route high-impact or uncertain decisions to a named person with enough evidence to approve, reject, or correct them quickly.

1. Classify the work before routing it

Start by naming what the task is. A public marketing draft, an internal report, a refund recommendation, and a production database change should not enter the same workflow with the same defaults.

Classification gives the business a stable basis for choosing the model, tools, data policy, budget, and review level. It also makes cost reporting useful. Instead of learning that AI spend increased by 40 percent, an operator can see that complex customer research is using the premium route while routine classification is not.

2. Authorize the action, not just the app

Connecting an agent to the CRM does not answer what it may do there. Reading an account, drafting a note, changing an owner, deleting a record, and triggering a customer email are different grants of authority.

Strong authorization is tied to the workflow, action, and context. The same agent might be allowed to update an internal status automatically, require approval before changing a deal stage, and be blocked from exporting customer data entirely. This extends the least-privilege approach described in our AI agent security practices. The control plane turns those boundaries into operating rules across the whole agent estate.

3. Verify the live facts before execution

An action can be well-formed and fully permitted but still be wrong. A refund may target an order that was already refunded. A transfer may use a real account belonging to the wrong customer. A product update may overwrite a change made five minutes ago.

ActionRail, a new open-source project from ToolJet, calls this the last-mile correctness problem. Its runtime checks proposed values against live systems of record before returning allow, hold for a human, or block. In its published value-poisoning benchmark, every unprotected model executed at least one manipulated value. Model strength did not remove the risk.

The general lesson matters more than the tool: consequential actions should be grounded at execution time. Permission says the agent may issue a refund. Verification checks that this order belongs to this customer, remains refundable, has not already been refunded, and falls within the approved limit.

4. Review exceptions with evidence

Human review is useful when it concentrates judgment. It is wasteful when every agent output lands in another inbox with no explanation.

A good review packet shows the task class, source records, proposed action, checks performed, reason for escalation, and expected impact. The reviewer should be able to approve, reject, or correct the action without reconstructing the entire workflow.

The review outcome then becomes operating data. If the same low-risk action is approved 200 times without correction, the policy may be too cautious. If one task class produces frequent rejections, the agent, source data, or workflow definition needs work. Review is not only a safety gate. It is how the system improves.

Start with one consequential workflow

Do not begin by buying a universal governance platform. Begin with one workflow where an agent can create value and a mistake has a real cost: invoice follow-up, refund handling, lead qualification, client reporting, merchandising changes, or production support.

Sensible first implementation

01

One workflow

Choose a recurring process with a visible cost, a named owner, and a clear definition of acceptable work.

02

Three action classes

Separate read-only work, reversible internal changes, and consequential actions that affect customers, money, production, or public output.

03

One evidence trail

Record the task class, source data, proposed action, checks performed, approval decision, outcome, and cost.

04

One operating review

Review exceptions, false approvals, unnecessary escalations, and cost per accepted outcome on a fixed cadence.

This is enough to expose the important design decisions. Which system owns the truth? What can happen automatically? What must be checked immediately before execution? Who owns the exception? What evidence will prove whether the workflow created useful work?

Once those answers work for one process, reuse the control pattern. The model can change. The agent framework can change. The business rules, authority boundaries, evidence, and review discipline remain valuable.

Better agents increase the value of control

Stronger models are not a reason to slow down agent adoption. They are a reason to stop treating governance as a future problem.

The more capable the agent, the more work it can reach and the more expensive weak oversight becomes. The goal is not to place a person behind every tool call. It is to classify the work, delegate bounded authority, verify the facts that matter, and reserve human attention for decisions that deserve it.

Before shopping for another model, ask whether your current agents are visible, scoped, grounded, and reviewable. If the answer is no, better intelligence will amplify the gap.

Already piloting AI agents?

Audit the workflow before you expand its authority.

Tessera maps the task classes, source systems, permissions, live-data checks, approval gates, and evidence trail for one production workflow, then gives you a control pattern the business can reuse.

Audit the workflow

Source notes