AI Agents Will Expose the Operating Model You Actually Have

Why the real work of agentic AI starts before the build

Imagine this.

It is 8:17 on a Tuesday morning. Overnight, a customer-service agent approved 143 account credits. It did not go rogue. It followed the rules exactly.

Finance is furious because one of those rules conflicts with a pricing policy Sales stopped using two years ago. Customer service knew that. They had been handling the contradiction the old-fashioned way: when an exception came up, somebody asked Luis.

Luis knew which rule actually mattered.

The agent did not know Luis.

That is what leaders are underestimating. For years, organizations have used people as middleware. People bridge the gap between the process on paper and the process that actually works. They remember which data source is wrong, which approval can be skipped, which customer gets an exception, and which policy everybody follows only when someone important is watching.

Then we automate the workflow and act surprised when the seams show.

The agent did not create the mess. It removed the humans who had been hiding it.

Your documented workflow is not your real workflow

McKinsey published an important piece on September 14, 2026 called "Stacking the odds: A blueprint for successfully scaling agentic AI." The headline finding is uncomfortable: 88 percent of organizations regularly use AI, but only 39 percent report enterprise-level EBIT impact from it.

More organizations are using AI. Far fewer are creating material value from it.

McKinsey's explanation is mostly organizational. Companies automate broken processes. They discover too late that their data are not authoritative. They make build-versus-buy decisions before they understand the work. Change gets pushed toward launch. Governance groups review progress but lack the authority to make hard decisions.

One medical-technology company in the article discovered version-control problems across its systems in the middle of an agentic customer-service build. Fixing the data problem added four to five weeks of rework. Another company chose an off-the-shelf platform before fully understanding its matching workflow and ultimately left an estimated 30 percent of the intended value outside the scope.

Neither example is really a story about a bad model.

They are stories about organizations discovering themselves late.

Humans can make a weak operating model look functional for a very long time. We compensate. We improvise. We carry tacit knowledge in our heads and relationships. We create little side channels that let the work continue even when the official process is wrong.

An agent cannot inherit what the organization has never made explicit.

Technical permission is only half the question

Most teams building agents already understand technical permissions.

Can the agent read the CRM? Can it send an email? Can it change a record? Can it issue a refund? Can it initiate a transaction?

Those questions matter. But there is another permission layer that belongs to leadership.

Should the agent make this decision at all?

What is it allowed to optimize when two goals conflict?

Which exception requires human judgment?

Who owns the consequence when the agent follows the rule and the rule turns out to be wrong?

What must the system refuse to do even when doing it would be faster?

That is organizational permission.

And if your leadership team cannot answer those questions clearly, the organization may be ready to experiment with agents, but it is not ready to hand them meaningful authority.

McKinsey's September 9 operating-model research makes the same problem visible from another direction. The firm surveyed 701 executives and senior leaders. Of 415 respondents that could be classified by AI maturity, only 53 were categorized as "reinventors," meaning their organizations were redesigning roles, workflows, and the operating model around AI rather than simply adding tools or automating existing work.

In McKinsey's related readiness research, 48 percent of leaders in the reinvention group reported meaningful enterprise value from AI. That compared with 24 percent in the automation group and 13 percent in the enablement group.

Those numbers have limits. They are based on individual survey responses, not audited organizational performance, and McKinsey says the reinventor group is overrepresented by financial services and telecom/media organizations. I would not turn 48 percent into a promise.

The pattern is still worth paying attention to.

The organizations reporting more value were changing the work, not just adding AI to it.

Run one real workflow before you buy another agent

There is a simple test leaders can run without buying anything. I do this kind of organizational diagnosis for a living, so I have an obvious incentive to tell you diagnosis matters. You do not need to hire me to run this test.

Pick one workflow you want an agent to touch. One. Take a real case from last week and put the people who did the work in the room with the people who own the outcome.

Map what actually happened.

Ask:

• Where did the work stop or wait?

• What did somebody do that is not written in the formal process?

• Which decision depended on experience, trust, or context?

• Where did two systems disagree about the same fact?

• What exception did a person resolve without escalating it?

• If an agent made the wrong call at that point, who would own the consequence?

Do not clean up the answers.

That messy map is probably closer to your real AI-readiness assessment than the polished process diagram sitting in a shared drive somewhere.

If the map surprises the executive team, good. You found the work before the software did.

Four weeks can be faster than four months

McKinsey recommends a four-to-eight-week blueprint phase before major agentic builds. The purpose is to resolve ambiguity before it becomes software.

That sounds slow when a board is asking what the organization is doing with AI right now.

McKinsey's own client experience suggests otherwise. The firm reports that programs developed from this kind of blueprint reduced overall build time by 30 to 40 percent. It also reports 40 to 60 percent higher user adoption at six months when change work was designed alongside the technical implementation from the beginning.

Those are consulting-experience figures, not controlled experimental results. Better teams may be more likely to do the blueprinting in the first place. The numbers should be read as evidence from McKinsey's client work, not as a guaranteed effect.

But the mechanism is pretty ordinary.

You can spend four weeks understanding the work before you build, or spend four months discovering the work after the agent is already touching customers, employees, money, or public services.

The second option feels faster right up until it isn't.

Agentic AI turns management choices into executable policy

This is where the conversation needs to move.

An agent is not simply another software tool inside an existing organization. Once it can interpret information, make choices, and take action across a workflow, it begins converting management choices into executable behavior.

What counts as a priority becomes executable.

What counts as an exception becomes executable.

Who has authority becomes executable.

What gets escalated and what gets ignored becomes executable.

That is why I do not think AI readiness belongs primarily to IT. Technology teams can build the system. They should not be left alone to decide what the organization believes good judgment looks like.

That is leadership work.

And leadership work gets uncomfortable because the organization often has not answered these questions for humans either.

The agent simply forces the answer.

The real risk is faithful automation

Go back to our hypothetical Tuesday morning.

The missing component was not a better model. It was Luis.

More precisely, it was the judgment sitting in Luis's head that the organization had never bothered to turn into an explicit decision. Luis had been stitching two contradictory systems together by hand, one exception at a time, and because the work kept moving nobody treated that invisible labor as infrastructure.

Then the agent removed the seam.

This is why the deepest risk in agentic AI is not always that an agent becomes too autonomous.

Sometimes the bigger risk is that it becomes faithfully autonomous inside an organization nobody has examined closely enough.

AI agents will make many organizations faster. I believe that.

They are also going to make organizations more honest.

They will expose the gap between the workflow we describe and the workflow people actually use. They will expose decisions that have never had a real owner. They will expose where policy survives only because experienced employees know when to ignore it. And they will expose which parts of organizational performance have depended on human beings quietly absorbing contradictions the system never fixed.

That exposure is not a reason to slow AI down forever.

It is a reason to diagnose before we encode.

Before you ask what your agents can do, ask what they are about to inherit.

Because once the operating model starts acting without you in the room, your organization is no longer just using AI.

It is teaching software what "how we do things here" actually means.