How the Operating Model Changes With Agents

They redrew the org chart. They redesigned the billing process task by task. And they still convene the same exception committee every Tuesday at ten, even though the agent watching that queue already closed three hundred decisions since Monday.

Carlos Andrés Ramírez · 2026-08-30

I have seen this with clients who did the first two exercises well. They merged boxes on the chart that genuinely needed merging. They sat down with the claims process and decided, task by task, what the agent runs alone and what needs a human signature. Both exercises were thorough, and both, on their own terms, made sense. And yet the following Thursday the exception committee still met on the same day, with the same standing agenda, working through whatever piled up since last week as if the agent also worked in weeks.

Because nobody touched the third layer. It is not the org chart, which says who is in charge. It is not the process, which says who runs which task. It is the rhythm: how often a decision gets looked at, who looks at it, and whether calling a meeting is triggered by a threshold or by a date on the calendar. That rhythm was built for people who work eight-hour days and decide in batches. An agent has no workday. It produces decisions at the pace work arrives, and that pace matches none of the standing meetings a company already runs.

The symptom

How does the operating model change when agents do part of the work?

This question comes from someone who already handled the org chart and the process and still sees something not adding up. The symptom is not a lack of governance. There is plenty of it: an exception committee, a weekly review, a monthly board report. What is missing is that machinery speaking the agent's pace instead of the corporate calendar's pace.

The exception committee meets on a fixed day, and a decision that needed resolving within the hour waits for that day even when the cost of waiting is high.
The monthly board report compresses three hundred decisions into one chart nobody reviewed one by one, and the chart says everything is fine because no aggregate shows the one edge case that actually mattered.
Two departments share the same agent in a process that crosses both, each running its own review calendar, so the decision waits for whichever one meets less often, not whichever one could move fastest.
The same type of exception shows up for the third week running in the same meeting, and instead of turning into a written rule, it gets argued from scratch again because nobody carries memory from one session to the next.
The person accountable for reviewing the agent still treats the weekly meeting as their only checkpoint, so a problem that started Tuesday surfaces the following Thursday.

The problem underneath

The operating model does not change in a box or a process. It changes on the calendar.

The corporate calendar (weekly, monthly, quarterly) is not an innocent convention. It is a design decision made for people who need time to think, coordinate and travel to a room. None of that applies to an agent. So when a company drops agents into a process and a new org chart but leaves the governance calendar untouched, it is asking a system that decides in seconds to answer to the rhythm of a system that used to decide in weeks. The gap between those two speeds is exactly where the problems nobody sees hide, until they already cost something.

And there is an uncomfortable part again. Changing a committee's rhythm means somebody loses that fixed slot on the agenda where they got to show up, ask a question, stall something with a well-timed objection every Tuesday. The calendar is power too: whoever controls when the committee meets controls, in practice, how long any decision takes to reach review. Redesigning the rhythm takes that control away from someone specific, which is exactly why the org chart gets redesigned before the calendar does. Moving a box does not take the microphone away from anyone in a meeting that keeps existing exactly as it did.

A committee that meets on Tuesdays because it has always met on Tuesdays is not governing the agent. It is waiting for the agent to fit somebody else's agenda.
BECOME

The framework

What has to be redesigned in the operating rhythm?

Decision cadence: What gets resolved instantly against a written threshold, and what waits for the next scheduled forum. The line is drawn by cost of error and reversibility, not by how convenient the agenda is.
Exception forum: A meeting convened when the threshold triggers it, with only the people it actually needs, not the next open slot on a shared calendar.
Review sampling: What share of the agent's decisions gets reviewed after the fact, and by what criterion they get picked: weighted toward the costly and the irreversible, never random and never first come, first served.
Memory across sessions: Where it gets written down that an exception has already been resolved the same way three times, so the fourth time becomes a new rule instead of the same meeting run again from zero.
Cross-department rhythm: Which calendar rules when one agent crosses two departments with different review cadences, decided before the first exception happens, not in the middle of it.

None of the five gets solved by moving a meeting from Tuesday to Monday. It gets solved by writing down, for every type of decision the agent touches, the threshold that separates resolving it now from waiting for a forum, and that exercise forces a real number (what amount, what tolerable error rate, what maximum wait) instead of the comfort of we will look at it Tuesday.

Take the committee that currently reviews the agent with the highest volume and ask, agenda in hand, how many of last week's decisions actually needed to wait for that day. If most of them could have been resolved earlier by a written rule, the committee is not governing. It is holding a queue.

Frequently asked questions

How does the operating model change when agents do part of the work?

It changes in the decision cadence, not the org chart or a single process. Companies need to write down what gets resolved instantly against a cost-and-reversibility threshold and what waits for a scheduled forum, which committees get convened by exception instead of by calendar, and what share of the agent's decisions gets reviewed afterward and by what criterion. Without that redesigned cadence, governance still exists, it just arrives late to everything that matters.

What is the difference between redesigning a process and redesigning the operating model?

Redesigning a process decides, task by task, what an agent can run alone inside that one process. Redesigning the operating model is the layer above it: the cadence of forums, reviews and escalations that coordinates decisions across several processes and several agents at once. A well-redesigned process can still sit waiting for weeks on a committee that never changed its calendar.

How do you decide which decision waits for a committee and which resolves on its own?

With a threshold written down before the first exception happens: an amount, a level of reversibility, and a maximum acceptable wait. Below the threshold, the agent acts and the decision enters a later sample review. Above it, whoever has real authority over that exception gets convened, even if it is not the committee's scheduled day.

How do you review an agent's work without reviewing every decision one by one?

With sampling that is not random: it weights toward the most expensive and least reversible decisions, because that is where a mistake actually costs something. Reviewing all of them is not realistic at the volume an agent produces, and reviewing at random lets exactly the cases that mattered most slip through. The selection criterion has to be written down, the same as the escalation threshold.

Let's redesign your operating rhythm

From the idea to the operation

Redesigning the process before automating it is direction and operating design work, not a tooling decision.

About the author

Carlos Andrés Ramírez — Transformation Director

Specialist in business transformation and reinvention. Director of Specialised Programmes and lecturer in Artificial Intelligence at UPC's Graduate School.