Who Is Allowed
To Say Yes?

Issue 4 was about conflicting records. Three or four systems holding different versions of the same customer, none formally authoritative, reconciled every day by a person with several tabs open.

Several readers came back on the same point, in different words. Fine, they said. Suppose we solve that. Suppose identity is settled, entitlement is settled, the outcome is committed somewhere defensible and everybody agrees which record wins.

The AI agent still cannot do anything.

They were right, and it is a bigger problem than the one I wrote about.

Knowing the truth about a customer is not the same as being permitted to act on it. An agent can resolve every contradiction in your estate, arrive at a perfectly evidenced view of who the customer is and what they are owed, and then discover it is not allowed to issue the refund.

That is not a data problem. It is an authority problem, and we built it ourselves.

We removed the decision, not the work

Think about what happened to front line discretion over the last fifteen years.

Scripts, so that the answer is consistent. Scorecards, so that the script is followed. Approval thresholds, so that spend is controlled. Permission matrices, so that access maps to grade. Second-signature rules on anything above a value. Quality frameworks that mark down deviation from process, including the deviation that solved the customer’s problem.

Every one of those was a reasonable decision on its own. Most were introduced by capable people responding to a real incident, a real audit finding, or a real cost pressure.

Together they produced something nobody designed. A service in which the person closest to the customer, with the most context and the strongest incentive to resolve, is the person least able to resolve anything.

The work did not go away. An advisor still handles the contact, still absorbs the frustration, still explains why they cannot help. What went away was the decision. It moved upstairs, into a queue, into a form, into a team that does not speak to the customer at all.

We industrialised the conversation and centralised the judgement.

This was not stupidity

It is worth being fair about why.

Discretion is expensive to govern. It varies by person, which makes outcomes inconsistent and complaints harder to defend. It is difficult to audit after the fact. It creates risk that sits with the organisation rather than the individual. And in an operation with high attrition, where a meaningful share of the front line has been in role for months rather than years, extending real authority to everyone is a genuinely uncomfortable proposition.

Removing discretion solved all of that. It made the service predictable, auditable and cheap to staff.

It also made it unable to say yes, and we decided that was an acceptable trade.

The point is not that somebody made a mistake. The point is that the trade was made implicitly, over years, by people solving unrelated problems, and it was never written down as a decision. Which means it has never been revisited.

Now we are automating on top of it.

What the automation inherits

Here is the mechanism, and it is more mundane than most AI commentary suggests.

When a programme starts, somebody asks what the agent should be able to do. The answer has to come from somewhere. The only machine-readable description of how the service works is the process documentation: the standard operating procedures, the decision trees, the knowledge base, the rule sets in the current platform, the wrap codes, the escalation matrix.

So that is what gets used. It is not a lazy choice. It is the only artefact that exists.

But those documents do not describe the service. They describe the service as constrained. They encode every threshold, every approval gate, every do-not-proceed-without that accumulated over fifteen years, and they encode them without any of the context that produced them.

The automation learns the constraints and treats them as the shape of the job.

Worse, the constraints arrive stripped of their reasoning. A human advisor who has been in the operation a while knows which thresholds are regulatory and which are habit. They know the ones that exist because of a specific incident in 2018, and they know which supervisor will wave something through if you explain it properly. That knowledge is nowhere in the documentation.

So the AI agent gets the rules without the judgement about the rules.

We are not closing the authority gap. We are encoding it, at scale, with better uptime.

Three permissions

In Issue 4 I set out three ownership questions – identity, entitlement, outcome. This is the companion set, and it is deliberately about permission rather than data.

What may it settle alone? Name the actions and name the limits, in currency and in scope, not in principle. A refund below a value. A re-booking within a window. A goodwill credit. A cancellation without retention. If the answer is “it depends on the case”, you have not answered, you have described the escalation you are about to build.

What may it settle with evidence? The same actions at higher value, conditional on something checkable: a delivery record, a recorded fault, an account state, a prior commitment. This is where the real design work sits, because it requires you to say what counts as evidence, who defined that, and who reviews the decisions afterwards. Most estates have never articulated this for humans, which is why it is so hard to articulate for an agent.

What must it escalate, and to whom exactly? Not to a queue. To a role with stated authority. If the human receiving the escalation also cannot decide, you have not escalated anything. You have added a step and a wait, and the customer now has to explain themselves twice to reach the same no.

Most organisations can answer the first question with some work. The second produces an argument, usually between operations and risk. The third is where you discover whether anybody has ever mapped authority end to end, and the answer is frequently that they have not.

The cost of getting this wrong

An AI agent that cannot decide anything is not neutral. It is expensive in a specific and measurable way.

Containment goes up, because the agent handles the contact. Resolution does not, because the contact was not resolved. The customer comes back, usually through a different channel, usually more annoyed, and that second contact is attributed to a different queue and often a different cost centre. The reporting improves while the service does not.

Handle time on the human side goes up too, because by the time a person is involved the customer has already invested effort, been told no by something that could not explain why, and arrives with a position rather than a question.

And the thing you were promised – that automation would free the front line for complex work – does not happen, because the complex work was always the work that required a decision, and the decision rights never moved.

You end up with a faster, cheaper, more consistent, always-available way of telling people you will have to check.

It is worth putting a rough number on that.

Take a large UK retail bank handling something in the order of forty million service contacts a year. A fall of one percentage point in containment moves roughly four hundred thousand contacts from automation onto people. At a fully loaded cost per handled contact in the range most UK operations would recognise, that is several million pounds a year, arriving from a change most dashboards would report as a rounding error.

Cost is the easier half. The harder half is what it does to service. An operation running near its planned occupancy does not degrade gently when demand rises. Queue times do not move in proportion to volume, they move considerably faster, because the maths of a queue stops being linear as you approach capacity. One point of containment, arriving as unplanned demand against a roster built before anyone decided the agent could not approve a refund, is enough to put service levels somewhere the forecast never modelled.

Which connects to an argument I have made before, in Erlang Doesn’t Cover This. The workforce maths was built for a resource that behaves in known ways. Automation that hands work back unpredictably is not that resource.

Some organisations simply decided otherwise

This is not a law of the industry. I have seen it done.

An automotive operation took a different route entirely. They created a senior advisor role – super agents, internally – and gave them a plain brief. Do the right thing for the customer. Ownership of the case, and the trust to resolve it.

The part that made it real was not what they added. It was what they took away. Those advisors were not managed on average handle time.

That sounds like a soft change. It is not. AHT is described as a productivity measure, and it is one, but in practice it also operates as a discretion control. If you are measured on how quickly you finish, you cannot afford the four extra minutes it takes to check the thing that would actually resolve the case. You cannot afford to hold the line while somebody else confirms. The metric does not forbid judgement. It prices it out.

Remove the metric and judgement becomes affordable again.

Automotive is a useful place to see this, because the economics are unusually honest. A customer contacting you about a vehicle is frequently without transport, part-way through a warranty dispute, or looking at a bill they did not expect. The cost of handling that badly – a lost customer, a dealer escalation, a complaint that runs for months – is very large next to the cost of a longer call. When the arithmetic is that stark, the case for discretion argues itself.

The fear, before they did it, was goodwill.

The concern was straightforward and it is the one raised in every conversation of this kind. Take the constraint off and advisors will start handing out gestures. Credits, contributions, waived charges. It is the quickest way to end a difficult call, and nobody is watching the clock any more.

It did not happen. They stayed inside the guidelines.

The reason is the part worth taking away. Ownership changed what the customer actually needed. When somebody takes your problem, stays with it, and comes back to you, you feel you are in safe hands – and resolving the issue turns out to be enough. You do not need compensating for an experience that was not bad.

Goodwill spend is very often a proxy for something else. It is what an operation pays when it could not resolve the thing, could not explain why, and had to close the contact anyway. Give people the ownership and the authority to fix the problem properly and a meaningful part of that spend stops being necessary, because the failure it was compensating for did not occur.

The lesson is not that everyone should abolish AHT. It is that this organisation worked out which control was actually suppressing resolution, removed that one, and replaced the approval gate with ownership rather than with another layer of approval.

All of which transfers, and the goodwill point transfers most of all. When the same conversation happens about an AI agent, the question people ask is what it might give away. That is the wrong question, or at least the second one. The question that matters is what it can resolve, because what it can resolve determines what it needs to give away. An agent with no authority to fix anything will end up offering compensation instead, and it will do that at volume, consistently, at three in the morning.

What to write down before you choose a platform

None of this is a procurement question, which is precisely why it never appears in one.

Before the requirements document, write a decision rights register. It does not need to be long. For each action the service can take on a customer’s behalf, record four things: what the action is, the threshold below which it may be taken without approval, the evidence that raises that threshold, and the role accountable for the rule.

Then check two things.

First, whether a human in your operation today could take that action. If not, your AI agent will not be able to either, and no platform capability will change that. The gap is upstream of the technology.

Second, whether the register you have just written matches the standard operating procedures the automation will actually be built from. Where they differ, the SOPs will win, because the SOPs are the thing that exists in a machine-readable form and the register is a document in somebody’s drive.

That second check is the one people skip, and it is the one that determines what actually ships.

Write the assumptions, not just the answer

This connects back to an argument I made in There Is No Best Platform. The decision record that survives a replatform is not that we chose Platform A. It is the statement of what we assumed and what we permitted.

Decision rights belong in that record. Not because they are a technology choice, but because they are the constraint every technology choice will be measured against. An architecture that assumes the agent can approve a refund is a different architecture from one that assumes it cannot: different integration, different audit, different handover design, different escalation load, different staffing model behind it.

If you do not write the assumption down, you will still have made it. You will simply have made it by accident, in a process document, years before the AI programme began.

The uncomfortable truth is that this is not really an AI question at all. Agentic automation has not created the authority gap. It has made it visible, at speed, in front of customers, in a form that is much harder to explain away than a person saying they will have to check with someone.

We took the decision away from the front line and never wrote down that we had done it.

Now we are handing the same job to something that can only work from what was written down.

Who in your organisation is allowed to say yes without asking – and when did anyone last check whether that list was deliberate?