From Doer to Orchestrator: How AI Is Rewriting the Individual Contributor's Job

By Victor Hoang · Updated Sep 22, 2026

The orchestrator role is what an individual contributor's job becomes once AI agents take on a growing share of execution. Instead of producing the output directly, the person defines the problem, sets the brief, decides what to hand off, and verifies the result. It swaps "doing the work" for "being accountable for work someone, or something, else did."

That sounds like a promotion. In practice it is a different job with a harder set of skills, and most ICs have not been trained for it.

Key Facts

• 36% of leaders expect their teams will be managing AI agents within five years, and 67% of leaders say they are already familiar with agents, versus 40% of employees. Source: Microsoft, "The 2025 Annual Work Trend Index"
• In a controlled study of 758 BCG consultants, those using GPT-4 on tasks inside the AI's capability frontier completed 12.2% more tasks, worked 25% faster, and produced work rated 40% higher in quality than a no-AI control group. Source: Harvard Business School AI Institute, "Navigating the Jagged Technological Frontier"
• On tasks outside that frontier, the same consultants using AI were roughly 19 percentage points less likely to produce a correct recommendation than the control group, which hit 84.5% correctness on its own. Source: Karim Lakhani, HBS, on the jagged frontier study
• 95% of enterprise generative AI pilots produced no measurable profit-and-loss impact, according to MIT's Project NANDA. Source: Fortune, reporting on MIT Project NANDA
• Increased verification effort measurably reduces "automation bias," the tendency to accept an automated system's output without scrutiny, even when it's wrong. Source: Microsoft Research, "Overreliance on AI: Literature Review"

The Job Didn't Shrink, It Moved

The Frontier Firm and the rise of the agent boss already covers what this looks like at the organizational level: Microsoft's term for companies where AI agents work inside daily workflows, and where every worker ends up building, delegating to, and managing agents the way a manager once managed people. That article is about the culture and the org chart. This one is about what happens to your actual job when that becomes true for you specifically.

If you write code, draft copy, build models, or handle support tickets, some real share of the physical act of producing that work is now something an agent can attempt. Not perfectly, not for everything, but for a growing slice of it. The part of your job that used to be "know the domain and produce the output" is splitting into two separate skills: knowing the domain, and directing an agent that produces a first draft of the output.

The mistake is assuming the second skill is a smaller version of the first, something you pick up by using a chat interface for a few weeks. It isn't. Specifying a task precisely enough that an agent executes it correctly, then catching the ways it went wrong, draws on a different part of your expertise than doing the task yourself ever did. Human-agent teams function well when people understand that difference, and badly when everyone assumes competence at doing the work transfers automatically to competence at directing it. Team topologies for human-plus-agent teams takes that shift up a level, into where an agent actually sits inside a team's structure rather than just inside one person's task list.

What "Orchestrator" Actually Means

Two shifts define the role, and they are easy to state and hard to live with.

From producing to specifying

The orchestrator's primary output is no longer the deliverable. It's the brief: the problem statement, the constraints, the examples of what "done" looks like, and the boundaries of what the agent is allowed to decide on its own. Get the brief wrong and the output is wrong no matter how capable the underlying model is. This is the same discipline as prompt engineering, but scaled up from a single clever instruction to a durable, reusable specification that has to work the fifth time and the fiftieth, not just the first.

From doing to reviewing, with real stakes

Reviewing an agent's output is not the same activity as reviewing a junior colleague's work, and treating it that way is one of the more common failure modes. A junior colleague who doesn't know something usually says so, or produces something visibly rough around the edges. A capable model produces confident, well-formatted, plausible-sounding output whether or not it's correct, a gap known in the field as AI hallucination. The orchestrator has to supply the skepticism the artifact itself won't signal.

The Four Core Competencies of the Orchestrator Role

1. Problem decomposition

Before you can hand a task to an agent, you have to break it into pieces small and well-defined enough that "correct" and "incorrect" are checkable. A vague ask like "improve this process" isn't delegable to anything, human or agent. A decomposed version, "identify the three steps in this process with the longest cycle time and draft a proposal to cut each by 20%," is. This used to be a project-management skill practiced mostly by leads and managers. It is now a baseline expectation for anyone whose job includes directing agentic workflows.

2. Context setting

An agent only knows what's in its brief, its training, and whatever it can retrieve. It does not know the political history of why the last version of this document got rejected, or which stakeholder actually has veto power, or that "concise" means something specific at this company because the CEO hates long memos. Context setting is the practice of externalizing the tacit knowledge you'd normally apply without thinking, so the agent doesn't produce technically correct work that fails for reasons it had no way to know about. Managing AI agents as part of the team covers this same scoping discipline as an ongoing operating job, not a one-time brief: quality bars, handoffs, and escalation paths that keep working after the first task.

3. Setting the quality bar

"Good enough" is a judgment call, and it has to be made before the work starts, not after, or the review process turns into an argument with yourself about a moving target. Setting the bar means defining what evidence, format, tone, and level of rigor the output needs to clear, and doing it explicitly enough that a second person (or a second agent run) could check the work against the same standard. Teams that skip this step tend to either over-review everything out of anxiety or under-review everything out of fatigue, and both failure modes show up in the kind of low-effort, high-volume output some teams have started calling workslop.

4. Knowing when to do it yourself

This is the competency that gets the least attention and matters the most. The BCG and Harvard Business School field study found that consultants using AI were dramatically better on tasks inside the model's capability frontier and meaningfully worse on tasks outside it, and the frontier itself is jagged: two tasks that look similarly hard to a human can sit on opposite sides of it. The researchers also found that professionals split into distinct patterns of use. Roughly a third acted as "centaurs," drawing a clear line between the work they handed to AI and the work they kept for themselves, preserving their own judgment on the harder half. A much larger group blended AI into everything indiscriminately. Knowing which category of task you're looking at, and having the discipline to keep the hard, ambiguous, high-stakes pieces for yourself, is the single hardest judgment call in the orchestrator role, because the agent will attempt the task either way and rarely tells you it's out of its depth.

Old IC Skill vs. New Orchestration Equivalent

Direct production builds the deliverable; orchestration defines the task, delegates execution, and verifies the result.

Why This Is Genuinely Harder Than It Sounds

It's tempting to treat orchestration as strictly less work than doing the task yourself. Sometimes it is. But three things make it a harder skill to build well, not an easier one, and the same ceiling that limits how many people a manager can supervise well limits how many agents one orchestrator can actually direct without the reviewing turning shallow; span of control when agents do the work covers that ceiling directly.

The frontier moves and it isn't labeled

Nothing on the screen tells you whether the task you just handed off sits inside or outside the model's real capability frontier. The BCG study's 19-point drop in correctness on out-of-frontier tasks happened to consultants who were, on average, good at their jobs and using a leading model. The failure wasn't a skill gap in using AI. It was a category error: treating a task that looked routine as if it were inside the frontier when it wasn't. Building the judgment to catch that in your own domain takes deliberate practice, not familiarity with the tool.

Verification is a different cognitive load than production

Producing work keeps you inside the problem the whole time; you notice inconsistencies as they happen because you're building the thing piece by piece. Reviewing someone else's finished output, human or agent, means reconstructing that same understanding from the outside, often faster than you built it the first time. That's real cognitive effort, and skipping it is exactly how convincing-sounding errors slip through. Verification is not "less work than doing it." It's different work, and treating it as the lightweight option is how orchestration goes wrong quietly.

Most organizations haven't built the skill on purpose

MIT's Project NANDA found that most enterprise generative AI pilots never produced a measurable financial return, and a common thread across the failures wasn't the model, it was the absence of the organizational learning loop needed to use it well: clear ownership, workflow redesign, and people who actually knew how to direct the tool rather than just access it. The orchestrator competencies above are that missing loop, applied at the level of one person's job. Companies that treat the shift as "give people the tool and let them figure it out" are skipping training for a new skill and hoping the old one transfers for free.

The Risk: Becoming a Reviewer of Work You No Longer Understand

There's a specific failure mode worth naming plainly: an IC who delegates enough of the execution, for long enough, that their own hands-on fluency in the underlying work quietly erodes, while their job title still says they're accountable for it.

This is the practical, individual version of automation bias, the well-documented tendency to accept an automated system's output with less scrutiny than it deserves, especially once it has been right often enough to earn trust. Research reviewed by Microsoft found that increased, deliberate verification effort is one of the few interventions that reliably reduces it. That's a specific, learnable habit, not a personality trait, and it needs a name inside teams: someone has to explicitly own re-checking work rather than assuming a role called "reviewer" makes it happen.

Economist David Autor's framework for how automation interacts with expertise draws a useful line here: some tools eliminate the need for expertise, and some force-multiply it, and which one you get depends on how the tool is used, not on the tool itself. An orchestrator who keeps doing the hardest 20% of the work personally, the part the model gets wrong, is using AI as a force multiplier for their own judgment. One who has quietly stopped doing any of it risks becoming a reviewer of a domain they no longer practice, a fragile place to be accountable from. Human-in-the-loop only means something if the human in question still has the standing to catch what's wrong.

What This Does to Seniority and Job Satisfaction

Seniority used to be measurable, in part, by how much work someone could produce personally and how fast. That measure is getting noisier: a junior analyst with a well-built agent workflow can now produce a volume of first-draft output that used to take a senior person's whole week. What doesn't get replaced as easily is the judgment call: knowing which 20% of a task is worth doing carefully by hand, recognizing when an agent's confident answer is quietly wrong, and setting a quality bar precise enough that the difference is checkable at all. That is exactly the expertise Autor and Thompson describe force-multiplying rather than disappearing, and it's a harder thing to put on a resume than "shipped X features" or "wrote Y reports."

Job satisfaction takes a related hit worth naming honestly. A lot of people liked doing the work itself, not just being accountable for its outcome: the sentence-level craft, the flow state of building something end to end, the puzzle of the model. Orchestration keeps the decision-making and strips out much of what felt like flow. Some of that satisfaction can move to what remains (the framing, the judgment calls, the moments a real problem surfaces), but pretending the trade is a wash for everyone isn't honest. Psychological safety matters here specifically because admitting "I miss doing this part myself" should not read as resistance to change.

How Managers Should Support the Transition

None of the four competencies above show up automatically just because someone has access to an agent. Managers who want their teams to actually develop them should:

• Teach decomposition explicitly, the same way onboarding once taught how to run a specific tool. Review a few real briefs together and point out where a vague ask hides three separate decisions.
• Protect time for verification, not just time for producing more output. If an agent cuts drafting time by half and the saved time gets absorbed entirely into more volume, nobody is actually checking anything harder.
• Redefine what "senior" output looks like on your team, explicitly, so people aren't quietly measured against a volume standard that no longer reflects value. This is org-design and evaluation work as much as it is skills work; see building an AI-ready culture for the broader version of this shift.
• Build deliberate reps on judgment, not just tool use. Give people practice catching planted errors in agent output, the same way pilots train on simulated failures rather than only flying when everything works.
• Say out loud that this is a different job, not a faster version of the old one. Naming the skill gap honestly is what makes it safe to admit you haven't closed it yet, which is the precondition for actually closing it.

Picture the version of this role done well: someone who spends less time typing the first draft and more time deciding what "correct" means before the draft exists, and who can tell you exactly which part of the output they'd bet their name on and which part they haven't checked closely enough to trust yet. That's a harder job to hire for and a harder one to train, but it's the one that's actually available now, and pretending it's the same job with a faster keyboard is how teams end up with confident, unreviewed output and nobody quite responsible for catching it.