The operating model decides, not the tool

Many companies start their AI rollout by asking which model or framework is right: Claude, GPT, an agent framework, a workflow engine like n8n. That choice is rarely the bottleneck. The bottleneck is that the agent meets an organization built for human operators. A person handles one case, a manager approves exceptions, a ticketing system logs the history. An agent handles a hundred cases in parallel, never takes a lunch break, and still needs an answer to who's liable when it's wrong.

In most projects we see, that question stays unanswered. The agent runs as a pilot, in a sandbox, with a developer watching it. Once it's supposed to scale, the operating model is missing: no role is accountable for its behavior, no escalation is defined, no process decides when it gets switched off. The result is a surprisingly stable pattern in AI rollouts: the demo works, production doesn't happen.

For a portfolio company, that means concretely: the business case in the value creation plan was calculated correctly, but assumed the agent would launch like a feature. In reality it launches like a new department, with its own area of responsibility, its own error culture and its own escalation path.

A productive agent operation needs at least three new roles, regardless of industry or company size. The agent owner is accountable for an agent's outcomes and behavior the way a product owner is accountable for a feature, including error rate, escalations and cost per case. Without this role, an agent belongs to no one, and what belongs to no one doesn't get maintained.

The reviewer-in-the-loop checks outputs where mistakes are expensive, before they take effect, at clearly defined checkpoints: before a payment, before customer communication with legal implications, before write access to a core system. The toolchain owner maintains the foundation the agent runs on: prompts, test cases, evals, model versions. This role doesn't yet exist in most engineering organizations, because it sits between software development and the business function.

All three roles can usually be filled with existing staff. The agent owner is often the previous process owner from the business side, not IT. The reviewer is an experienced person from support, finance or operations. What matters is that the role is explicitly assigned rather than implicitly assumed.

These three roles need a fixed, short rhythm to coordinate, a weekly look at the same numbers: how many cases the agent handled, how many it escalated, where the error rate stood, what change to prompt or approval limit is coming up. The agent owner brings the business view, the reviewer brings the week's error examples, the toolchain owner brings the technical explanation for them.

Without this rhythm, the three roles drift apart: the agent owner sees only outcomes without understanding the cause. The reviewer collects errors that never turn into an improvement. The toolchain owner changes prompts without knowing what business impact that has. The rhythm is the mechanism that turns three separate roles into an operating model.

The reflex in many organizations is to set up a central control committee for AI that has to sign off on every agent deployment. That slows down exactly the cases where an agent has the biggest lever (high case volume, low individual risk), while barely protecting against the cases with real risk. More effective are approval limits built directly into the agent: an amount threshold above which a transaction goes to a human; a data class an agent may never change unreviewed; a customer segment where every communication is checked before it goes out.

Make these thresholds explicit, documented and regularly reviewed, not buried implicitly in the prompt. And they're a dial, not a fixed state: with a proven track record, the share of cases going to a human goes down. Without one, it stays high. Governance becomes a measurable quantity instead of a one-off policy decision.

A real-world example shows the difference: a bad approval limit reads "every customer reply gets reviewed before it's sent". That doesn't scale and reduces the agent to a footnote of human work. A good approval limit reads "replies to standard requests go out directly; replies involving a refund above a threshold or a recognizably dissatisfied tone go to a human." The difference lies in the precision of the boundary, not in trust in the technology.

Agentic engineering blurs the line between building and running. An agent in production needs monitoring like any software service (error rate, latency, cost per call), plus a business-quality measurement that no classic ops team covers: did the agent give the right answer, not just a syntactically valid one?

This feedback loop from production back into prompt and eval development is the core of a working operating model. Who carries the pager when an agent starts making wrong decisions at two in the morning? Without a clear answer, an agent quietly degrades every time the underlying model, the data, or customer behavior changes, and nobody notices until the damage is visible.

In practice that means: an eval suite that runs before every change to a prompt or model version, the same way a test suite runs before every software release; a dashboard that shows error rate and escalation rate over time, not just the current value; and a fixed rule for who sees a regression warning and who decides whether the agent gets rolled back to the previous version immediately on a regression.

Agent sprawl: every team builds its own agent, with no central register. Nobody knows anymore how many agents are running with what permissions. Missing audit trail: an agent makes decisions, but nobody can reconstruct afterward what data it saw and which rule it applied. That problem escalates the moment the first customer complaint or audit lands.

Lifecycle treated like a chatbot: the agent gets rolled out and never changed after that, no versioning, no rollback, no planned end date for experiments that don't work. Change management skipped: employees whose task an agent takes over aren't involved. The resistance that results then gets mistakenly treated as a technology problem, when it's actually a leadership problem.

Approval limits and ownership are not technical details to hand off to the engineering team. They are governance decisions that belong in front of leadership and the board just as much as a new line of credit. A solid board report doesn't say "we now use AI". It lists which agents are running, with what approval limits, what error rate, and who's accountable for them.

This visibility is also the difference between an AI initiative that survives the next budget cycle and one that gets cut as a cost line with no visible owner.

Once a company (or a PE portfolio across several holdings) runs not one but a dozen agents, the operating model for a single workflow no longer suffices. A lightweight central register becomes necessary: which agents exist, with which owner, which permissions, which approval limit. That's not a new control committee, it's an inventory, similar to the list of critical suppliers or systems any governance function already maintains.

Decision rights stay local: the agent owner in the respective business function or portfolio company makes the operational calls. What gets standardized centrally is only the reporting format (the same metrics, the same structure for approval limits), so that a leadership team or an operating partner can compare multiple agents without learning a separate language for each.

The pragmatic entry point is an operating model for a single workflow, not for the whole company. A team picks a process with high case volume and moderate risk, defines owner, approval limits, monitoring and escalation path for exactly that process, and gets it into production. The model that emerges from that becomes the blueprint for the next agent, not a presentation written up beforehand.