Once your people start building or using AI agents, their role moves up a level. The agent takes over execution. The human's job becomes scoping, planning, review and judgment. Stephen Sutzer, lead operator at oAT, has watched this happen inside both small VC-backed startups and large enterprise product organizations, and the pattern holds regardless of title.
What doesn't change: someone still has to decide what's worth building, and someone still has to look at the output and say whether it's good.
The Org Chart Doesn't Flatten, It Moves Up
It's a common thought that agents flatten an organization by absorbing the junior work and leaving everyone else where they were. What we actually see is closer to a promotion that nobody announced. Here is how Stephen describes it in our enablement sessions:
"the moment that any people on your team start using either building or using agents, they essentially move up a level, they move up a layer within the org chart and it becomes important at that at that stage of of of their life to really understand that like your strategy becomes really important. Your judgment becomes really important, your taste becomes really important and like humans really need to sit in the proper review seats."
That shift asks four things of a person who was previously measured on throughput:
- Strategy. Deciding which work is worth handing to an agent at all.
- Judgment. Knowing when the output is wrong in a way that matters.
- Taste. Recognizing the difference between correct and good.
- Seat discipline. Sitting in the scoping and review positions instead of drifting back into execution.
What the Session Data Shows: Planning Against Execution
Anthropic has been publishing research on how people actually use its tools at scale, including large reviews of Claude Code sessions [1]. Stephen's read of that work is the cleanest summary I've heard of the new division of labour:
"80% of the time though in these sessions cloud code was actually executing the task 80% of the time. Humans spent 70% of the time planning."
Three things follow from that split:
- The people getting the most out of agents spend the majority of their hours before the work starts.
- Time spent planning is no longer overhead. It's the highest-leverage activity in the workflow.
- If your team's calendar still rewards visible execution, you will train them out of the exact behaviour that makes agents useful.
Worth remembering how new all of this is. Claude Code has only existed since February 2025 [2]. Nobody in your organization has ten years of experience with agentic workflows, including the loudest person in the room.
Where Humans Have to Stay in the Loop
Two seats matter, and they sit at opposite ends of the process.
The scoping seat
Before anything runs, a human decides what problem is being solved, what steps the work actually takes, and which of those steps an agent should touch. Skip this and you get speed pointed in an unhelpful direction.
The review seat
After the agent runs, a human reads the output against a standard. This is where taste lives. It's also the seat most often left empty, because reviewing feels less productive than producing.
| Seat | Question it answers | What happens when it's empty |
|---|---|---|
| Scoping | What are we solving, and what are the steps? | Agents automate a broken process faster |
| Review | Is this actually good? | Volume rises, quality drifts, nobody notices for a quarter |
Deploy Without Mapping and You Just Speed Up Slop
Stephen's warning to every organization we work with is blunt: you can't simply roll agents out and expect improvement. What you get downstream is more words, more code and more documentation than you ever had before, all of it arriving faster than anyone can read it.
The symptoms are recognizable:
- Documentation nobody trusts because nobody knows which version an agent wrote.
- Pull requests that clear review because reviewing them properly would take longer than writing them did.
- Decisions made on generated research that nobody traced back to a source.
how We Do: Map the Process Before You Install the Agent
The term going around for this kind of work is forward deployed engineering. Whatever the contract says, we approach client work from the systems level first. The sequence looks like this:
- Name the problem. State what you are solving for in one sentence, in business terms.
- Map the steps. Write out every step the work takes today, including the ugly manual ones.
- Mark the agent steps. Identify where an agent is genuinely the most capable actor.
- Mark the human seats. Decide explicitly where scoping and review sit, and who owns each.
- Then deploy. Install the agents into a process you have already codified.
Do that foundational work first and the output the agents produce becomes more consistent and higher quality. Skip it and you have bought yourself a faster version of whatever was already broken.
Where the Work Sits Before and After Agents
| Before agents | After agents | |
|---|---|---|
| Human's main activity | Task execution | Planning, scoping, review |
| Measure of a good day | Volume of output shipped | Quality of decisions made |
| Skill in demand | Craft speed | Judgment and taste |
| Failure mode | Bottleneck at the person | Unreviewed volume at the output |
| Where the process lives | In people's heads | Mapped, then codified |
The New Work That Shows Up Once Agents Take the Backlog
Most conversations about AI stop at automation. The more interesting category is the work that was never possible before. One team we worked with had an ideas board of over 7,000 items, most of it customer requests coming in through support, with no human capacity to triage any of it. That was a human process that had been broken for years. Agents can now work through that list faster than the team ever could, which moves them to a ready state and takes the backlog off the table permanently.
Every function has a backlog like that: a bundle of tasks nobody can reach because of capacity or capital constraints. Clearing one is often the best first foothold for agents inside an established company.
What fills the time afterward is the real question. For a product manager who no longer spends days triaging, the freed capacity goes to:
- Deeper market and competitor research.
- Deciding which ideas move forward and which get tested.
- Direct contact with end users, more often.
- Building a working prototype in a couple of hours and putting it in front of a customer for early feedback.
Stephen frames the test for any individual this way:
"what does this allow me to do that that enhances my humanity a bit more that actually enhances my ability to connect with the end user with the customer to understand their pain points their friction points"
Startups Turn on a Dime, Growing Companies Re-engineer
Late in 2025, Stephen joined a VC-backed client that was running its core workflow on one set of coding agents. Within two weeks the entire organization had moved to another. The CTO spent a weekend testing it himself, came back a believer, and the switch happened almost overnight.
A growing business with real headcount cannot do that, and the reason is structural.
| Early-stage startup | Established or growing business | |
|---|---|---|
| Tooling change | Days, by conviction | Months, through review layers |
| Starting position | Agent-first from the beginning | Existing process, built for humans |
| Main constraint | Knowing what to build | Re-engineering how work gets done |
| Change cost | Low, few workflows to accommodate | High, roles and rituals must be reimagined |
| Central question | What specifically should we build? | Which process are we overhauling? |
The process that got you here will not be the process that gets you where you're going.
The Roles That Are Collapsing Into Each Other
In a training with product leaders at a large client this month, the honest headline was that expert product managers and design leaders are watching their discipline merge with an adjacent one.
Product and engineering
Product is collapsing onto engineering and engineering is collapsing onto product. Engineers have to start thinking more like product people. Product people have to start thinking more like engineers.
The rituals under review
The software development life cycle these teams have lived with for a decade is being called into question. Two- and three-week sprint planning cycles look expensive when a team can move from idea to prioritization to research to a plan in an afternoon, with agents running against the backlog overnight.
What This Asks of You as the Leader
Roles are changing faster than your documentation can keep up, and people's working lives are changing with them. A few things we'd hold as non-negotiable:
- Get into the work yourself. The only way to understand where the tooling actually is now is to use it [3].
- Name the review seats out loud, with owners, before you deploy anything.
- Reward planning time in how you run reviews and set expectations.
- Pick one broken backlog as the first foothold rather than announcing a company-wide rollout.
- Ask each person what the agent frees them up to do, then protect that time.
We've argued before that the hardest hiring and structure questions are decided by what your existing team can actually absorb [4]. Agents don't change that logic. They raise the stakes on it.
FAQ
Does using AI agents eliminate jobs or just change them?
In the organizations oAT has worked inside, agent adoption changes the shape of a role before it changes headcount. Execution moves to the agent while the person moves into scoping, planning and review, which demands more strategy and judgment than the previous version of the job. The work that gets eliminated tends to be work nobody had capacity for anyway, such as an untriaged backlog.
What is a "review seat" and why does it matter?
A review seat is the defined point in a workflow where a human reads agent output against a standard and decides whether it is good enough to move forward. It matters because agents produce volume faster than teams can absorb it, so an unstaffed review point turns speed into unchecked output. Naming the seat and its owner before deployment is what keeps quality consistent.
How much of the actual work do AI agents do compared to humans?
Anthropic's published research on Claude Code usage has been the clearest public evidence on this split. As Stephen Sutzer of oAT summarizes it, agents were executing the task around 80% of the time in those sessions, while the humans using them most effectively spent roughly 70% of their time planning. The practical takeaway is that planning is now the human's primary contribution.
What new kind of work appears once agents take over execution and backlog triage?
Work that capacity constraints previously made impossible. For a product manager, that includes deeper market and competitor research, deciding which ideas to test, building quick prototypes, and spending far more time in direct contact with customers. Across other functions it usually starts with whichever backlog has been sitting untouched because no human had the hours for it.
References
- Anthropic. "Anthropic Economic Index." https://www.anthropic.com/economic-index
- Anthropic. "Claude 3.7 Sonnet and Claude Code." https://www.anthropic.com/news/claude-3-7-sonnet
- of All Trades. https://weofalltrades.com
- of All Trades. "how We Do" essays. https://ofalltrades.substack.com