And Vijay Says…

Most companies have a number at which they stop trusting you.

You might be able to approve a $5,000 expense but not a $50,000 one, offer a customer a small credit but not a large one, or approve an ordinary claim but send an unusual one upstairs. We call these approval limits, and there is nothing particularly wrong with them. They are one of the ways organizations control risk.

The logic is familiar. The larger the consequence of a decision, the smaller the group of people allowed to make it. When something falls outside the rules, authority moves upward until it reaches someone the company trusts to make the call.

In The Average Is Lying to You, I argued that AI changes the mix of work left for people. In The Side Door Is the Whole Building Now, I followed that into the exception processes that increasingly have to handle it. Put those two together and you get an uncomfortable problem: the work left for people requires more judgment, while the systems governing that work were built to constrain it.

Imagine a claims manager looking at a $75,000 claim. The documentation is messy. The policy doesn’t quite fit. She’s handled hundreds of claims and thinks this one should be paid.

Should the company simply raise her approval limit from $10,000 to $75,000 and tell her to use her judgment? Of course not. The approval limit wasn’t invented because somebody disliked judgment. It exists because the company is taking risk. More discretion can mean more inconsistent decisions, more mistakes, more opportunity for fraud and, occasionally, more damage from someone who simply isn’t very good at exercising judgment. So authority can’t move by itself. Control has to move with it.

For decades, hierarchy has helped solve that problem. The claims manager sends the decision to her supervisor. The supervisor sends the unusual one to a specialist. Large enough decisions go another level higher. The organization controls risk partly by controlling who is allowed to take it. That works surprisingly well when unusual decisions are unusual. It works less well when technology systematically removes the usual ones.

Here’s where I think the interesting possibility is, and it isn’t just giving people more visibility after they’ve already decided. It’s that the boundary itself can stop being static.

Right now, that boundary is a dollar figure. Under $10K, decide. Over $10K, escalate. But a threshold like that treats every $75,000 claim the same, and every $12,000 claim the same, regardless of what’s actually inside them. Suppose instead the system looks at the case itself: a $75,000 claim with a familiar fact pattern, strong supporting evidence, an experienced adjuster and no fraud indicators can be decided on the spot. A $12,000 claim with contradictory evidence, unusual claimant behavior and a departure from normal policy gets escalated, even though it’s a fraction of the size. The dollar threshold is static. Risk isn’t.

That’s a different kind of control than watching a decision after it’s made. The evidence, the comparable cases and the departure from normal pattern are what decide, before money moves, whether this case needs another judgment or not. What gets logged afterward — her reasoning, how her decisions compare to her peers’, whether she’s repeatedly overriding the same policy — isn’t a substitute for that control. It’s what keeps recalibrating where the boundary sits.

That distinction matters because hierarchy is a fairly blunt instrument for governing judgment. A manager approving a decision doesn’t necessarily know more about the case than the person who sent it upstairs. Sometimes the manager contributes experience or judgment that genuinely improves the decision. Sometimes the decision moved because the organization decided long ago that someone with one title could take the risk and someone with another title couldn’t.

AI gives us a chance to distinguish between a decision that needs another judgment and one that merely needs another signature.

The person closest to the work can potentially have more room to exercise judgment while the organization gets better visibility into how that judgment is being used. Instead of controlling every decision through prior permission, it can decide which decisions need permission, which can happen inside defined boundaries, and which can be reviewed after the fact. Once permission can respond to context rather than just hierarchy, permission itself starts to look less like a policy and more like an architecture.

I called this Offensive Permission Architecture, or OPA, in Migrating Scarcity. The idea is that permission itself can be designed: who can act, under what conditions, with what information, inside what boundaries, and what gets reviewed before versus after the fact. Most companies inherited their answers to those questions from an operating model built before this kind of visibility was possible. AI changes enough of the underlying economics that those answers are worth reopening.

Most of the AI conversation is about the falling cost of doing work. I think something else may be falling too: the cost of controlling who is allowed to do it. If AI can make the context around a decision visible, preserve the reasoning behind it, and identify risk before and after someone acts, delegation itself becomes cheaper. We built authority around the value of the transaction because we couldn’t cheaply measure the risk of the decision. AI may change that.

It doesn’t mean hierarchy disappears. Some decisions are important enough that another person should look at them before anything happens. Some require genuinely different expertise. Some risks should never sit with one individual. But perhaps decisions should move upward because another person’s judgment adds something, not simply because hierarchy is the only control mechanism we have.

For decades, we have used hierarchy to answer two different questions: who has the judgment to make this decision, and who are we willing to trust with the risk. AI may finally let us separate them. A decision doesn’t have to move upward because it crossed a number on an org chart. It can move because another person’s judgment would actually make it better. That’s a very different reason to have a hierarchy.

A claims manager has a stack of cases on her second monitor that she’s been putting off since lunch, and she already knows why. None of them are simple.

One photo doesn’t quite match the damage description. One claim has two pieces of documentation that don’t agree with each other, and neither is obviously wrong. One has a fraud indicator that fired for a reason nobody can fully explain, attached to a claim that otherwise looks completely legitimate. One is just a customer with a perfectly reasonable situation that nobody happened to anticipate when the policy language was written.

She’s been doing this job long enough to remember when a stack like this took most of a week to clear, spread out between the ordinary claims. Documentation arrives, coverage is clear, damage fits a familiar pattern, somebody signs off, payment goes out. The ordinary claims were most of the job. The strange ones were the exception, which is what everyone still calls them, out of habit. They’re not the exception anymore. They’re a slow Tuesday.

Somebody designed that process at a point when the hard cases showed up once in a while. Refer it, escalate it, send it to a specialist, get a sign-off from someone two levels up, that’s fine when it happens twice a week. It’s a different thing entirely when it’s the whole job. So she does what the process asks anyway. She refers the fraud-indicator case to a specialist who has eleven other referrals ahead of hers. She flags the mismatched documentation for a supervisor’s sign-off, even though she’s handled a hundred cases like it and already knows what the answer should be. The process doesn’t ask what she thinks. It asks whether this fits, and when it doesn’t, its only instruction is to ask somebody else.

Migrating Scarcity argues that technology doesn’t eliminate scarcity. It moves it. Automate execution and something else becomes scarce instead: context, coordination, judgment, the standing to act. I believe that more than when I wrote it, but what I hadn’t followed all the way through was where the migration ends up. It doesn’t stop at “judgment becomes valuable.” It runs straight into whatever part of the organization was built to hold judgment, and in most companies, that part was built for overflow, not for the main event.

Her queue used to be five hard cases mixed in with twenty easy ones. Now it’s mostly the five. The easy claims didn’t get harder or disappear on their own. A machine took every one it could actually solve, and what’s left on her desk wasn’t picked for typical difficulty. It was picked for everything a straightforward rule couldn’t touch.

The dashboard upstairs still says the department is thriving. Cost per claim is down. Processing time is down. Somebody in finance is probably building a case right now that says her team should shrink by roughly the same percentage the automated share grew. It’s the same average that lied to a call-center manager not long ago, telling the truth about the machine’s work and increasingly nothing about hers. Maybe her team should shrink. I’m not going to pretend automation doesn’t reduce how many people you need, it usually does. But shrinking the team isn’t the same decision as running the smaller team on the old assumptions.

If she used to process twenty routine claims and five hard ones, the answer isn’t to make her process five hard claims as cheaply as the old twenty. It might be closer to the opposite: put her in front of the specialist directly instead of behind eleven other referrals, let her sign off on the calls she’s already qualified to make instead of walking them up two levels, and stop timing her against a handling-time target that was built for work she doesn’t do anymore. The total cost of the process can keep falling. The cost of her part of it might need to rise. The machine is producing the savings, and she’s the one left dealing with the cases where saving time was never really the point.

The same shift is underway anywhere a queue used to be sorted into routine and exception. Cybersecurity teams triaging alerts after the obvious ones get closed automatically. Accounts payable clearing invoices after the clean ones settle themselves. In each case, the queue doesn’t just get shorter. What’s allowed into it changes.

Companies are pouring enormous effort into redesigning the automated path right now. Models, agents, workflows, integration, all of it necessary. I’m less sure we’re redesigning the other path, the one we used to call the exception process, on the assumption that it isn’t an exception anymore. We spent decades building organizations around the normal case and bolting an escalation process onto the side for whatever didn’t fit. AI is getting very good at the normal case.

The side door is the whole building now.

A call center manager pulls up the dashboard the way she does most mornings, coffee still too hot to drink. Automation rate: up. Cost per contact: down. Service level: the best it’s been all quarter. Every number on the screen is green, and every number on the screen is telling her the year is going well.

So why does the floor feel harder to run than it did a year ago?

She can’t point to anything specific. Nobody’s quit in weeks. Escalations aren’t up, exactly. It’s just that the calls that make it to her agents lately seem to take more out of them – more silence on the line while someone reads a note, more calls that get transferred twice before they’re solved, more agents stopping by her desk to ask what they’re allowed to do about a situation the script doesn’t cover. None of that shows up as a number. The dashboard doesn’t have a field for it.

Here’s what she’s actually looking at, if she wrote it out.

Before AI, her team handled all 100 cases that came in on a given day. Some were easy – a password reset, a billing question with an obvious answer. Some were hard- an angry customer, three conflicting records, a policy that didn’t fit the situation. But on average, the work was representative of the whole. A typical case was, roughly, a real case.

Suppose AI now handles the easiest 70.

The 30 that reach her agents aren’t a smaller version of the old 100. They’re a different population. They contain more ambiguity, more conflicting information, more unhappy customers, more situations where the policy manual and the actual situation don’t line up – because AI didn’t just take the easy cases, it took the cases that were easy precisely because they didn’t require judgment. What’s left is, almost by definition, everything that does.

I’ve been thinking about this since finishing Migrating Scarcity. The book’s central claim is that technology doesn’t eliminate scarcity – it moves it. AI makes routine execution abundant, and scarcity migrates toward judgment. But there’s another consequence I didn’t spend much time on in the book. Scarcity can also move within the distribution of a single job – quietly making the average unit of remaining work harder, even as the total amount of work falls.

Which brings us back to her dashboard. Cost per contact fell because AI’s transactions are nearly free. Every blended metric that gets reported upward looks like a story about efficiency. But those averages increasingly describe the work the machine is doing, not the work her team is doing. An improving service metric doesn’t mean her agents got better at their jobs. It can mean the easy cases – the ones that used to pull the average down – aren’t reaching her agents at all anymore.

This is where it stops being a feeling she can’t name and starts being a decision someone else makes for her.

Her VP looks at the same dashboard and sees automation at 70%. The conclusion writes itself: if AI is handling seven in ten cases, the team needs roughly seven in ten fewer people. It’s a clean number, and clean numbers travel well in a budget meeting.

That conclusion might even be right, on headcount. A team handling 30 hard cases a day may genuinely need far fewer people than a team handling 100 mixed cases a day. The error isn’t necessarily the number. The error is the reasoning behind it – an assumption that capacity scales linearly with automation, while ignoring that the composition of the remaining work has changed. You can’t staff the residual 30% using the assumptions you used for the original 100%, because the residual 30% isn’t a smaller sample of the same job. It’s a harder job, done by fewer people, who now need more experience, more authority to deviate from the script, and more support than the average performer on an average day used to need.

Cut the staff by the automation rate and change nothing else, and you get a smaller team facing a harder caseload with the same training, the same authority limits, and the same thin margin for error the old team had – calibrated for a workload that no longer exists.

None of this will show up in the metrics that made the case for automation in the first place. Cost per contact will still look great. It will just be an increasingly accurate description of the transactions the machine is handling, and a decreasingly accurate one of the work left to the people still on the floor.

We keep asking what percentage of work AI will take from people. I’m starting to think that’s the wrong question.

If AI takes the easiest work first, the work left to people won’t simply be less of the old work. It will be different work.

And that means the average we’ve been managing may no longer describe the people we’re managing.