The Org Chart After Agents

As agents move into real workflows, the org chart is coming out with the same boxes and different arrows: who depends on whom, where review time goes, and which skills matter more.

Jun 18, 2026

For about a year now, the loud prediction has been that agents will flatten the org into something leaner: a lead with a fleet of bots doing the work that used to take a team. In practice, I am seeing something else.

As we put agents into real workflows, including the marketing operator I wrote about earlier, the org chart is coming out the other side with the same boxes, headcount, and reporting lines. Around them, the arrows have moved: who depends on whom, where review time goes, and which skills started to matter more. Since the change happened in the edges, nobody signed off on it because there is nothing obvious to sign.

I don't see this part of the agent conversation written down much, probably because a lot of the people writing about agents aren't running a team that has to absorb them. From where I'm standing, the honest version has three parts: what has already started to change, what is changing now, and where the next pressure is likely to show up.

Already Changing

The headcount question is the wrong question

People usually ask first whether roles are getting cut. The roles are still there, which is why that question misses the important change.

An agent takes over a type of work, and that work is rarely sitting neatly inside one job. First-draft copy, recurring data pulls, and the "why did this number move" first pass are usually spread across several people, taking a slice of everyone's week. Once the agent takes them on, the chart keeps its boxes and the work inside each box changes.

I wish I'd understood earlier that, in the workflows I'm seeing, agents change the team by moving work around inside the headcount that is already there. The org chart hides that kind of change, which lets leaders look at the chart and conclude nothing changed.

The work is moving before the titles do

Here's what is shifting day to day: as the low-context, high-volume tasks leave people's calendars, review, judgment, and edge cases take their place. The title stays the same as the job moves up a level.

This does not happen because someone decides it in a meeting. The agent is useful at the bottom of the stack and weak at the top, so humans move upward to where they are still needed. That is the first real reorg I can see, even though it is invisible on paper.

Someone has to own the teammate, and it's a real job

One org-chart change rarely gets predicted: the agent becomes a teammate that needs a manager. That work needs real time, attention, and responsibility.

Practical questions show up quickly: who fixes it when it's confused, who owns its evals and rules, and who is on call when a workflow starts failing in the background? On our team this is slowly becoming a real job. The honest part is that the work often belongs to nobody at first. After the agent ships and works, everyone moves on, and that gap where it belongs to no one is exactly when trust starts to erode. People notice it getting small things wrong before anyone owns noticing.

I keep landing on the same lesson with agents generally: the controls are part of the product. At the org level, the thing that happens before there is language for it is that the agent becomes a teammate with no manager. A teammate like that needs a named owner.

Happening Now

Juniors are losing the bottom rung, so we have to rebuild it

Junior development is the uncomfortable part.

Grunt work juniors used to cut their teeth on is increasingly becoming the agent's job. An agent can now do the first draft you'd hand a new hire so they'd learn the shape of the work by doing it badly a few times, and it can do it instantly and pretty well. Speed improves, and a learning path that matters gets weaker, because young engineers build judgment by being bad at something and feeling the gap close. That bottom rung of the ladder is the cheapest to automate, and it's also the one people climb on.

We don't have a clean answer, at least I don't. I see the junior role moving from doing the first pass toward checking and fixing it, which only works if the person understands the work well enough to catch the agent being wrong. Because that is often harder than producing the first pass yourself, the role is getting harder earlier. I'm still not sure we've got the balance right, and anyone who tells you they've solved this is selling something.

Taste is becoming more valuable than output

Once first drafts and first passes are nearly free, judgment starts carrying more of the value: knowing which output is actually good, which claim needs evidence behind it, and which analysis sounds right but isn't.

At that point, the team starts needing people who can judge quality quickly and own the call. That's a different skill than the one many of these roles were hired and trained for, and I'm watching it change who's valuable more than any reorg memo would. As output gets easier to produce, taste and the spine to say "this is wrong, ship the other one" become harder to find.

Likely Next

Promotion criteria start lagging the work

A stale ladder starts promoting people for a job that has already changed.

Most engineering and ops ladders still reward volume and speed, at least a little, even though agents keep taking over more of that output. If we keep rewarding output, we reward the wrong thing and tell our strongest people to compete with the agent instead of doing the work only they can do. I can already feel myself looking for different signs: whether someone naturally asks "does this look off?", whether they can make a call when the answer is unclear, whether they can own and improve an agent beyond prompting it. That shift deserves its own post and it's going to get one. For now the point is narrower: when the work moves up the stack, the ladder has to move with it, or we reward the skills the agent just made cheap.

The failure mode is quiet decay

A human teammate who's underperforming gets noticed because people feel it, route around it, and eventually have the conversation. A slowly worsening agent is easier to miss. Its evals slip, its memory goes stale, and a workflow everyone has stopped trusting keeps running. It can rot for weeks because it's nobody's direct report, and "the tool" is allowed to be mediocre in a way a person isn't.

As agents spread across more workflows, this failure mode gets more common: everyone assumes someone else is watching the thing. For the team, the lesson is simple: an agent inside a workflow needs a clear owner, the same way a person in that workflow would. When someone owns it, reviews how it's doing, and is on the hook when it slips, the agent can be trusted. A workflow without that ownership carries invisible technical debt that occasionally talks back.

What I'd do next time

If I were rolling agents into a team from scratch, knowing what the org is starting to look like on the other side:

Name the owner before shipping, when trust is still intact. Ownership is the first thing to define and the last thing anyone thinks of.

Protect the juniors' learning path on purpose, because efficiency will delete the bottom rung unless rebuilding the ladder becomes a choice instead of a thing you hope happens.

Update what "good" looks like before the ladder drifts away from the actual work, rewarding judgment and checking over the output volume the agent now handles. If you don't, you promote for yesterday's job.

Stop waiting for a reorg to make the change visible. I don't think there will be one, at least early on. Boxes stay put while the change starts in the edges: who depends on whom, what counts as senior, which work is worth a human's limited attention. Put attention on the dependency graph.

Agents are leaving the formal shape of my team intact. Under that surface, the learning path is changing, taste is getting more valuable, and ownership is becoming the thing teams run out of first. Because of that, I expect ladders, review systems, and ownership models to catch up next. The chart hides all of this, which makes it a poor place to understand what an agent is doing to your team.