By Pavan Kumar T V · 22 August 2026

Series: Part 1 was definitions, Part 2 was money. This is Part 3. Part 4 is the org.

Give something a memory and you've accidentally given it a biography.

Run an agent for two years and the thing you're operating is not the thing you deployed. It has a history. It has scar tissue. It has opinions about your codebase that it formed on a Tuesday in March.

Nobody promoted it. Nobody wrote any of it down. It happened the way it happens to people.

So decide whether that's a career or a leak.

It Specialises Whether You Plan It or Not

Take an agent that started on the front end.

Eighty features later it has absorbed the API contracts, learned which backend changes break which screens, and picked up enough of the deployment story to know why Friday releases go badly. It is quietly full-stack. Its job description still says front end.

Or the opposite. It went narrow instead of wide. It has now seen every edge case in one payments flow, and it's the only thing in the building that genuinely understands the refund path, including the two exceptions that exist because of a decision someone made in 2019 and never documented.

Both are careers. One went broad, one went deep. That's the same fork every engineer hits around year five, for the same reason: you get shaped by the work you're handed.

The difference is that when a person specialises, the organisation notices. Their title changes. People start routing questions to them. There is a moment, with a date on it.

When an agent specialises, nothing marks it.

The only honest word for that is drift.

Growth Has to Be Legible or It's Just Drift

A promotion is an event with a date, a reason, and a new set of expectations. Anything less is your system's behaviour changing while your mental model of it stands still.

An agent that silently got broader is an agent whose output you can no longer predict. Worse, whose past output you can no longer explain. Someone asks why it made that call in April. The honest answer is that it was a different agent in April and you have no record of the difference.

So make the ladder explicit.

level 1   does the task it was asked, shows the result back
level 2   holds a memory, needs telling once instead of every time
level 3   owns a boundary, says no and routes what isn't its job
level 4   teaches, briefs other agents, condenses for the human
level 5   proposes work nobody asked for, because it sees the pattern

The levels aren't the point. The point is that moving between them should be a decision, made by a person, recorded, and reversible.

Level 3 is where most teams stall. An agent that can refuse needs a defined boundary, and defining a boundary means somebody has to write down what this thing is not responsible for. That's an hour of unglamorous work most teams skip, and skipping it is why so many agents confidently do things nobody wanted.

Level 5 is where it gets strange. Something that proposes work has an agenda, however small, and an agenda needs a leash.

The Strongest Argument Against This Post

I should give the other side properly, because it's better than the strawman version and it comes from people who have run this in production.

Harvard Business Review published a piece this May arguing that treating agents like new employees is exactly the mistake. Their case: the "promote a star performer" instinct actively hurts you, because when you widen an agent's scope there is no underlying judgement widening alongside it.

A human you promote has spent two years quietly learning what to escalate. An agent you promote has learned nothing of the kind. It gets more surface area and the same inability to know when it's out of its depth. Their recommendation is to treat it as a contractor with a narrow statement of work, and to reach for systems-engineering templates rather than HR ones. Scoped permissions, observability, a kill switch, a named owner.

I'll concede the core of it without argument. Capability does not grow with responsibility. Nothing about an agent doing eighty good months of front-end work makes it better at knowing when to stop. Anyone reading "career" as it earns its way up has read me backwards, and that's a fair reading of the word.

But look at what the objection rests on. Widening scope is dangerous because judgement doesn't come with it. Agreed. So the question becomes: who decides to widen the scope, on what evidence, and does that decision leave a mark?

That's the whole argument of this post. The ladder isn't a reward. It's a record.

Because here's what the objection doesn't address. An organisation that never promotes its agents does not thereby keep them at level 1. It keeps them at level 1 on paper, while the memory quietly fills up with API contracts and deployment lore and opinions about the refund path.

The scope widens either way. The only choice is whether a person widened it deliberately, with a date on it, or whether it happened while everyone was watching the dashboard.

Call it a contractor if you prefer. I'd take their noun, it's more accurate. Keep the machinery. The kill switch and the named owner aren't an alternative to the ladder, they're levels 3 and 5 with better names.

The Performance Review, Unironically

If it has a career, it can have a review. Less absurd than it sounds, because the questions are the useful ones.

what did it learn this quarter        list the lessons, with authors
what does it still escalate           the boundary, measured not assumed
what does it get wrong repeatedly     the pattern, not the incident
what should it own now                promotion, deliberately
what should it stop owning            demotion, which needs to exist

Right now almost nobody does any of this. The number I keep seeing quoted is that an agent can run for a year in production without a single structured evaluation of whether its work is any good. We'd never do that with a person. We do it with agents because there's no calendar invite forcing it.

That last row is the one nobody builds. We've all accepted that agents accumulate. Almost nobody has built the path where an agent gets less responsibility because it earned less.

A person who keeps making the same call badly gets moved off that work. Uncomfortable, and it's how organisations stay sane. An agent that learned something wrong six months ago and has been quietly applying it since needs the same treatment, at the level of the individual lesson, not the whole system.

Rolling your agent back to last year's snapshot to remove one bad rule is a firing when what you needed was a conversation.

Which means versioned, attributable, individually reversible learning isn't an audit feature. It's what makes performance management possible at all. I've written about the write path that makes it work elsewhere.

Now the Career That Pays Your Mortgage

Here's the part I'd want to read if I were ten years into an engineering career and mildly unsettled by all of this.

If your agents are climbing that ladder, your job climbs a parallel one. It climbs whether you participate or not.

You stop being the person who does the task. You become the person who defines the job, briefs the work, reviews the output, and answers for it when it's wrong.

That isn't a metaphor for management. It is management, with a smaller headcount, a faster feedback loop, and no HR department.

So the skills that appreciate are not the ones we spent twenty years selecting for:

Writing a job description precise enough that the work comes back right. Every ambiguity you leave gets filled in confidently by something that doesn't know it guessed.

Spotting the plausible-but-wrong answer. The hardest review skill there is, and the one that separates people who ship working systems from people who ship systems that pass tests.

Knowing which decisions you're never allowed to delegate. Not because the agent can't make them. Because you're the one who'll be asked to defend them.

Deciding when to teach versus when to correct. Fixing today's output is cheap and feels permanent. Teaching costs more and changes everything downstream. Most people over-correct and never teach, which is how you end up saying the same thing forever.

Engineers who've already managed people will find this transition boring, which is a strange sentence to write. They've done it. Briefing an agent is briefing a junior with better recall and worse judgement about what matters.

Engineers who have only ever executed will find it brutal, and that isn't talked about honestly enough. Being excellent at the work is not the same skill as being able to specify the work. Plenty of brilliant people have spent a career avoiding the second one on purpose.

The Rung Keeps Moving

Both ladders are the same ladder.

Your agents move up it. You stay one rung above, and the rung doesn't stay still. The moment your agents reliably do level 3, level-3 work stops being your job and your job becomes level 4, ready or not.

Which is fine. That's every promotion anyone has ever had. It's just faster now, and nobody's going to announce it.

One thing to hold onto: the reason you stay a rung above isn't capability. It's accountability. When the agent is wrong, nobody in the room is going to ask the agent.

The Gap Nobody Has a Good Answer For

There's a hole in all of this and I'd rather name it than pretend.

If agents do level-1 work, where do junior humans get their reps?

The traditional path was: do the boring implementation for two years, absorb by osmosis why the boring things are there, then start making calls. The judgement came from the tedium. It wasn't taught in a review. It was earned in the doing.

Take away the tedium and we've removed the training ground while keeping the requirement. We now need people who can spot a plausible-but-wrong answer, without the years of being wrong that used to produce that instinct.

The best partial answer I've got: make the agent show its work, and make junior people review it. A hundred agent decisions a week, with a senior checking the reviews, might build pattern recognition faster than writing the code ever did.

Might. That's a hypothesis, not a plan. Everyone I put it to nods and then changes the subject.

So I'm leaving this one open. Every other post in this series ends with me fairly sure of something. This is the part I'd most like to be wrong about, and the part I'd most like someone to have already solved in a company I haven't seen.

My actual prediction is that this becomes a visible problem in about four years, and most companies discover it the same way: they look around for someone ready to be senior and there isn't one.

Part 4 goes back to firmer ground. Several of these things working together, and the one structural advantage an agent team has over a human team that I don't see anyone building for.