2026-06-07
June 7, 2026 · Issue 027
The next two years of technical leadership will be defined by whether you treat AI agents as tools you bought or as a new layer of headcount you hired — and the org chart, the comp plan, and the on-call rotation all flow from that one choice.
There is a quiet argument happening inside every large engineering org right now, and it is being lost by the side that is technically correct.
The technically correct side says: agents are tools. They are software. You don't put a SaaS license in the org chart. You don't give Jira a performance review. Treat them as platform, govern the cost, move on.
The side that is winning, even though it talks less, is the one acting as if agents are a new kind of headcount. They are giving agents owners. They are writing onboarding documents (system prompts) and capability rubrics (evals). They are running deprecation conversations that look uncomfortably like managing someone out. And they are restructuring the org around the human-agent interface instead of around services or features.
That is the bet I want to make this Sunday: in 2026 and 2027, the technical leaders who treat agents as headcount — not as tools — will run circles around the ones who don't, even when the second group has better models. The advantage is not in the model. It is in the operating system around the model.
Deloitte's 2026 Global Technology Leadership Study landed on a phrase that is going to be repeated to death this year: tech leaders are moving from operators to orchestrators. 71% of large organizations now have five or more tech leaders in the C-suite. The CIO is no longer a single throat to choke; influence is distributed across CTO, CDO, CIO, CAIO, CISO, sometimes a Chief Agent Officer. (Deloitte study release)
Underneath that distributed C-suite, the engineering org is also fragmenting in a new way. Jellyfish's State of Engineering Management 2026 puts the number at nearly 60% of management tasks now involving AI-assisted decision-making, and 64% of teams reporting at least a 25% productivity lift from AI. (Jellyfish 2026 survey) Those are the numbers the boards see. The numbers the leaders feel are different: 42% of orgs still report low or no ROI on AI investments. Both can be true at the same time, and the gap between them is exactly where the operating model fails.
The gap has a shape. Individual engineers are getting more productive. Teams are not getting more coordinated. Stack Overflow's 2025 survey found 70% of agent users say agents reduce time on specific dev tasks, but only 17% believe agents improve team collaboration. (CIO Dive coverage) Velocity is going up at the IC level while coordination — the thing senior TPMs and tech leaders are actually paid for — has not been redesigned for a world where agents are doing meaningful work between humans.
This is why the "agents as tools" frame is losing. If agents are tools, your job is to procure them, govern their cost, and make sure people can use them. That is a real job and it is largely a Finance and Platform problem. If agents are headcount, your job is something different and much harder. You have to decide what they own, who they report to, how their performance is evaluated, when they get more responsibility, when they get cut, and what humans are accountable when they fail. That is a People and Org Design problem dressed up in YAML.
The orgs that are winning the early skirmishes are acting on the second frame. LinkedIn stood up a fully funded agent platform team structured the same way they structured their storage and ML infrastructure teams — central prompt orchestration, data access, safety evaluations, deployment. (The New Stack on platform engineering for the agentic era) Salesforce reports output growing 151.3% YoY when measured as "effective output" — code that ships and stays. (Salesforce engineering becoming agentic) The single most predictive variable in industry surveys is whether the org has a named agent owner — a person accountable for an agent's behavior and lifecycle. Orgs with that role have a 2.7x higher production-conversion rate on their agent investments. (How agentic AI will reshape engineering workflows in 2026, CIO)
That is not a tool-governance pattern. That is a hiring-manager pattern with the labels swapped.
Three implications for technical leaders this year.
One: span of control is no longer a number, it is a portfolio. Tomasz Tunguz has been writing that very productive AI engineers manage 10–15 agents in flight; less productive ones can barely supervise four. (Tomasz Tunguz on the agent manager) The classic span-of-control number of seven was always a heuristic about cognitive load and trust calibration. Both of those factors look different with non-deterministic, low-trust subordinates that never sleep but also never quite learn from yesterday. Your skip-level managers are going to come to you with portfolio questions — "Priya is supervising eight agents and four humans, can she absorb the migration agent?" — and you need a framework that is not "what's our standard span." Charity Majors has been saying the center of gravity has fully shifted to agentic workflows; engineers who wait for it to be forced on them are choosing to be passive in their own careers. (Pragmatic Engineer interview with Majors) Tech leaders who wait for span-of-control guidance from HR are choosing the same.
Two: the engineer-to-PM-to-TPM-to-manager ratios you built your org on are about to be renegotiated, and not by you. Allstacks and a wave of follow-on writing have made the point that the classic 1:7 PM-to-engineer ratio assumed engineers needed a lot of clarification. (Allstacks on PM-to-engineer ratio in the AI era) When two-thirds of the "engineering" output is generated by agents that needed clarification from the engineer, the bottleneck moves. The roles that compound — the ones that get more valuable as throughput rises — are the ones that set direction and absorb ambiguity. That is TPMs at their best, engineering managers at their best, staff engineers in the Right Hand and Architect archetypes from Will Larson's framework. (Will Larson on staff archetypes) The roles that get squeezed are the ones whose value was mostly "translates a clear request into a deliverable." Junior engineers, junior PMs, junior TPMs. Notice that engineering hiring data already shows a sharp contraction in early-career roles, while AI/ML specialist roles take 97 days on average to fill — up from 72 in 2023. (Augment Code AI engineering transformation playbook) The market has already started repricing.
Three: the boundary between product, platform, and people ops gets messy on purpose. Camille Fournier has been making the case for years that platform teams need engineers, ops, and PMs together. (Fournier on platform engineering, Lenny's interview) In the agent era, the platform also needs the people-ops muscle: a capability rubric for what agents are allowed to do, a review cadence, a deprecation playbook, an incident process when an agent acts outside policy. Microsoft's platform engineering team has explicitly written that infrastructure-as-code is becoming an implementation detail; the new platform contract is intent, with guardrails (security, cost, compliance) baked into agent instructions. (Microsoft on platform engineering for the agentic era) This is what Charity Majors is calling Observability Governance — and adding as a section to the second edition of Observability Engineering, out this year. (Charity Majors on the second edition) The first wave of platform engineering was about paved roads for humans. The second wave is paved roads for agents, with audit trails for the humans who deploy them.
So: how do you actually do this on Monday?
You stop using the words "tool," "deployment," and "integration" for agents that do meaningful work. You start using "hire," "scope," "responsibility," and "review." Yes, it feels weird. That is the point. The vocabulary is what locks in the operating model. If you call an agent a tool, it lives in the SaaS budget and gets reviewed once a year. If you call it a hire, it gets an owner, an onboarding doc, a 30/60/90, a capability rubric, a deprecation path, and a place to escalate when it does the wrong thing. The second one is harder. The second one is also what is going to separate the orgs that compound from the ones that don't.
The boards already know this is coming. They are asking your CTO why 90% of the AI effort is going into productivity when they want 90% of it going to revenue. (Egon Zehnder on the CTO's new mandate) The honest answer is: because productivity is what fits in the current operating model, and revenue requires designing a new one. That redesign is your job this year, not next year.
Try this week. Pick one agent that is already doing meaningful work in your org. Write a one-page "hire packet" for it. Include: the role's scope (what it owns, what it doesn't), reporting line (who is accountable), a capability rubric (the three to five evals it must pass), an escalation path (what happens when it fails), and a deprecation criterion (what would make us shut it down). If you can't fill in any one of those five fields, that is the gap in your operating model — not in the agent.
What it is. A two-axis framework for managing tensions that don't have a "right answer." Each pole has its own upsides and downsides; the goal is not to pick a winner but to keep the system moving between them, harvesting the upsides while watching for the downsides. Originated by Barry Johnson in Polarity Management: Identifying and Managing Unsolvable Problems (1992).
When to use it. Use it when you keep relitigating the same decision — autonomy vs oversight, centralize vs federate, move fast vs ship safely, hire vs build — and notice that whichever side wins the argument, the losing side's downsides start showing up six months later. Especially useful for agent operating model decisions, where there is no end state, only a healthy oscillation.
How to run it:
When NOT to use it. Don't use it for actual decisions — questions with a right answer, even a hard one. Don't use it as a permission slip to avoid choosing; some debates are polarities, and some are just calls that the leader needs to make.
Example: at one infra org last quarter, leadership had spent six weeks debating "centralized agent governance vs team-owned agents." Reframing it as a polarity surfaced that both poles had real upsides — central was creating standards, federated was preserving speed — and the actual problem was the lack of early warnings. They set two: rollback rate (central pole's miss) and approval wait time (federated pole's miss). The debate ended.
From Operators to Orchestrators: Deloitte's 2026 Global Technology Leadership Study — The headline finding (distributed tech C-suite, 71% of orgs with five or more tech leaders) is the macro-frame for every reorg conversation you will have this year. Read it before your next exec offsite.
The State of Engineering Management 2026 — Jellyfish — 600+ engineering leaders surveyed. The 60% AI-assisted-management number and the 42% no-ROI number are the two stats your CFO will quote at you. Bring counter-data.
Platform Engineering for the Agentic AI era — Microsoft — The clearest writeup of how platform team scope shifts from infrastructure-as-code to intent-with-guardrails. Steal the framing for your own platform team's charter.
"The future is already here — it's just not evenly distributed."
— William Gibson
Don't miss what's next. Subscribe to Critical Path: