The AI pyramid has no juniors to train, and that is the problem

Watching the easy work disappear should feel like relief. It doesn’t.

Not the work you loved. The work you complained about. Password resets, access requests, the ticket that needed the same three checks before lunch.

It was tedious. It was repetitive. It was also where the system first became legible to you.

You’re not sentimental for remembering that.

You’re not asking anyone to preserve bad queues so somebody can suffer through them.

You remember opening a ticket, finding the runbook, asking the person beside you what the strange field meant, and learning that a service isn’t a screen. It’s a chain of systems, permissions, exceptions and people.

That wasn’t inefficiency.

It was apprenticeship, disguised as routine.

Nobody has to develop intentions for this to hurt.

The problem is arithmetic and it’s old.

A delivery model built its margin by putting supervised juniors on known work. The new tool is very good at known work.

2003 — You start on password resets and simple tickets. The answer is usually in the script, and the script has a name attached to it.

2011 — The service desk has a runbook for most of them. You learn which step breaks when the runbook doesn’t.

2022 — The knowledge base suggests the fix. You still recognize when the suggestion is a little too confident.

2026 — The agent resolves it. The next junior has nowhere to begin.

The pyramid was never cheap labour

Managed IT services sell a capacity product. Not a worker’s wage with a little margin painted on.

Your rate has to recover salary, benefits, payroll taxes, recruitment, training, leave, bench time, delivery management, unbilled specialists, sales, facilities, tooling, insurance, finance and profit.

Utilization is the quiet lever under all of that. The share of your paid capacity doing client work.

Accenture reported 92% utilization in fiscal 2025 alongside 14% voluntary attrition. Company-wide figures, not a target to pin on anybody’s account.

But they make the pressure visible. Take a team with 10,000 paid hours a year. At 80% utilization you get 8,000 delivery hours.

At 90% you get 9,000.

That extra thousand hours changes how fixed labour cost gets recovered. Inside a fixed managed-service price, it becomes margin before it becomes anything a customer can see.

The pyramid made that arithmetic operational.

A senior architect set patterns and approved exceptions. A lead coordinated several queues. You handled the repeatable operations, under automation, documentation, review and escalation.

Senior scarcity became a system of supervision and knowledge reuse.

Your junior work wasn’t valuable because it was cheap. It was valuable because it was bounded enough to learn without handing a fragile service to a guess.

That boundary matters more than the ratio.

One senior to twelve juniors is fine in a mature service desk with clear scripts. It’s dangerous on a legacy platform where every ticket reveals undocumented business logic.

A single blended rate conceals that difference. So does the easy claim that every ticket you resolved was an expense waiting to be removed.

The runbook belongs to the economics because it turns one person’s remembered sequence into a teachable operation.

It doesn’t turn a difficult failure into a standard case.

When a critical service changes hands, the incoming team resolves a priority incident, executes a routine change, restores a test service, and demonstrates the customer communication path before it carries your production obligation.

A thirty-day hypercare period only means something when the daily issues have a root cause, an owner, and a decision to accept, delay or remediate.

That’s what the bottom of the pyramid did for you, even on an ordinary Tuesday.

Repetition. Then supervision. Then your first encounter with the thing that didn’t fit.

You started with the password reset. You learned why the identity defect made the next three hundred tickets. You learned that hitting a fifteen-minute response target can still be a failure, if the service answered quickly and left the cause in place.

The agent inherits the runbook

A governable agent doesn’t arrive as a general replacement for an IT function.

It starts with a bounded purpose, exactly as your managed service did. Prepare a particular change for review, not “manage procurement.” Verify and prepare, not “fix this supplier.”

That narrowing isn’t a disappointing limit. It’s the part that makes routine work safe enough to hand over.

And the agent can be more diligent about the standard case than a tired person at the end of a long queue.

It retrieves the same record, applies the same bounded rule, records the same state, creates the same draft. Without ever losing patience.

That’s a real gain. You’re not weak for wanting it.

You’ve got incidents, messages, a handover, people waiting, and a life that doesn’t become more meaningful because an access request needed copying between systems.

But the agent doesn’t learn by becoming a senior.

It inherits the accumulated result of other people having learned. Its confidence isn’t your escalation layer.

None of the controls around it manufacture the person who can decide why an exception is an exception. They make that absence sharper.

The safe agent is built out of a maturity its own use may stop replenishing.

The missing middle costs money

Attrition has two prices in a managed service. Replacement cost to the provider, and lost account knowledge to the customer.

Your old pyramid acknowledged both, imperfectly.

It gave you a way to become a lead, and gave leads a way to become the people who knew an awkward interface, an old decision, a customer’s real tolerance for disruption.

That’s why your contract wants named key roles, succession plans, knowledge-transfer measures. Those aren’t ceremonial clauses around a staffing model.

They’re how an account avoids paying repeatedly to relearn itself.

The agent pitch lowers the visible cost of the first layer.

It makes a smaller team look more utilized. It removes the ticket volume that justified your junior cohort. It turns whoever’s left into reviewers of a system doing the routine cases.

The commercial presentation calls that productivity. It may be right about delivery effort.

It’s incomplete about capability formation.

You can see the old distinction inside a service level. 99.9% availability allows about 8.76 hours of unplanned downtime a year.

That number isn’t a badge. It constrains your maintenance windows, your resilience, your service credits, and the recovery knowledge that only shows up when ordinary conditions stop holding.

Automate the standard work and the odd failure still needs somebody who understands your estate. Not somebody who understands the agent’s explanation of it.

The hard part is that reduced effort can be real without becoming a complete saving.

A new arrangement carries migration, parallel running, tooling, security remediation, contract advice, training for your retained team, data cleansing, exit charges, integration.

So your commercial record needs three separate ledgers. Run service. Approved change. Transformation.

Combine them and a struggling run service can look innovative, or necessary modernization can look like provider failure.

The same correction applies to your talent.

Your lower queue had two outputs. Resolved work, and people who learned the work.

An agent may reduce the first without replacing the second. The invoice records the former. The balance sheet has no row for the latter.

That doesn’t make it unreal.

None of this argues for preserving every junior task. It argues against pretending the task was only ever a task.

Ask the typesetters. The travel agents. The translators.

Work disappears in pieces. The route into the work can disappear with it.

Not a pile of cheap tasks

Fixed price makes the temptation worse, because estimation risk becomes contractual.

Your provider on a fixed recurring price absorbs staffing and productivity risk only inside the stated scope, assumptions and demand band.

When your estate, interfaces, volumes, acceptance criteria or exception load aren’t known, the provider adds contingency, narrows assumptions, seeks change, or squeezes delivery resilience.

A thinner junior layer doesn’t make uncertainty disappear. It makes your senior layer carry it alone.

The old sourcing record has numbers quiet enough to spoil the easy story.

HM Revenue and Customs re-competed the ASPIRE contract, valued around £3 billion. The department paid £8.6 million toward bidders’ costs and £43.3 million toward contractor transition costs to keep the competition credible.

Reported procurement and transition cost reached £75 million. Roughly 2% of projected contract value.

Don’t copy those figures into your agent programme. The point is that a change in delivery model has a transition, a dependency and a continuity test before it has a clean new run rate.

Afterwards the new supplier got paid for outputs, and HMRC spent £539 million in the first year. Demand above the procurement assumption pushed the cost up.

More work isn’t automatically poor service. Fewer routine tickets aren’t automatically a complete saving.

Your service still has to price the retained organization, the integration function, the exception load, and its own future ability to understand the alternatives.

That’s the correction. You’re not mourning inefficiency.

You’re noticing that a pipeline isn’t the same thing as a pile of cheap tasks.

An agent can make the standard queue smaller, calmer and faster. It can give an experienced person time back. It can show which work was always predictable enough to automate.

But if it removes the first place people meet the system under supervision, it removes the place your next senior begins.

The service looks flatter in the quarter it gets priced.

The question is what it looks like when the runbook ends, the agent parks the case, and nobody left has learned how the service became legible in the first place.