Map the process before you automate it. Decide upfront where an agent executes and where a human plans and reviews. Expect the first few weeks to run slower. Invest in a small group of power users, build the workflows so everyone else benefits without becoming one, and accept that most of your team will never become agent proficient.
That sequence is the difference between a rollout that raises quality and a rollout that raises volume. I want to walk through what we've seen inside both three-person startups and enterprise product organizations, and what I'd do differently if I were starting on Monday.
Map the Process Before You Automate It
Stephen Sutzer, lead operator at oAT, has spent the past two years installing these tools inside client organizations, from a VC-backed startup to a large enterprise product and engineering group. He describes the most common failure this way:
"you can't just deploy and like roll out agents in the or organization because a lot of times what ends up happening is you just speed up a lot of slop, right? Downstream, you just get you get more words, you get more code, you get more documentation than you ever had before."
The work that prevents this happens before anything gets deployed. You pick the core processes you actually want to automate, then you write down the steps it takes to complete that work today, including the steps nobody has ever documented because one person has always just known them. Only then do you ask where an agent fits, where straight automation fits, and where a human has to stay in the loop.
| Common rollout move | What it produces | The mapping fix |
|---|---|---|
| Buy licenses, announce them, wait | Scattered personal use, no shared standard | Choose two or three processes that are core to the business and start there |
| Point an agent at an undocumented workflow | Output that's confidently wrong in the same places the workflow was | Write the steps down first, including the tacit ones |
| Automate the whole chain end to end | Nobody can tell where quality broke | Name the human checkpoints before you install anything |
| Measure adoption by seat usage | Activity that looks like progress | Measure whether the mapped process now runs at better quality |
The foundational work early on is what makes the eventual output consistent. Skip it and your agents will faithfully reproduce whatever mess you already had, at speed.
Where the Human Sits: Scoping, Planning, Review
The moment anyone on your team starts building with or using agents, they effectively move up a layer in the org chart. It no longer matters much where they sit on the chart itself. Their strategy, their judgment and their taste become the constraint on quality, because the execution is no longer the constraint.
Anthropic's own analysis of how people work with its tools points the same direction: the people getting the most out of agentic coding concentrate their own hours in planning and review while the agent carries the bulk of the execution [1]. Claude Code, the terminal-based agent that changed what was possible for a lot of operators in early 2025, is built around exactly that division of labor [2].
| Stage | Who holds the pen | What breaks if you get it wrong |
|---|---|---|
| Scoping the problem | Human | You automate the wrong process beautifully |
| Planning the approach | Human, with the agent drafting options | The agent optimizes for plausible instead of correct |
| Execution | Agent, most of the time | Human hours go to work that no longer needs them |
| Review and acceptance | Human | Slop ships, and the next cycle inherits it |
Why Rollout Feels Slower Before It Gets Faster
The first stretch of a serious rollout costs time, and leaders who expected an immediate return read that as failure. Here's where those early hours go:
- Surfacing the real process. Agent work exposes people problems and process gaps that nobody had a reason to surface before.
- Codifying tacit knowledge. The steps living in one senior person's head have to become text before an agent can follow them.
- Building review muscle. Reviewing an agent's output well is a skill your team has never had to practice at volume.
- Re-engineering what already exists. If you've been operating for ten years, you are unwinding a process that was designed for human throughput.
- Reimagining roles. Job descriptions written eighteen months ago describe work that is now partly automated.
An early-stage team skips most of that cost because it has less to unwind. A growing company pays it in full. Paying it is still cheaper than shipping faster in the wrong direction.
Startups Turn on a Dime, Growing Companies Re-Engineer
Late in 2025 we came into a VC-backed startup to own a workflow that was core to their business. They were running one agentic tool. We tested an alternative, showed the CTO the results, and he spent a weekend with it himself. The entire organization switched almost overnight. That is not available to a company with several hundred people and an established software development life cycle.
| Early-stage team | Growing or enterprise organization | |
|---|---|---|
| Tool changes | Days, sometimes a weekend | Quarters, with procurement and training |
| Starting point | Agent-first from the beginning | A process built for human throughput |
| People to accommodate | A handful | Departments with overlapping workflows |
| Main risk | Building fast in the wrong direction | Automating a broken process at scale |
| Main advantage | No backlog of legacy practice | Real volume, so a fixed process compounds |
In the enterprise product groups we're working with, product is collapsing onto engineering and engineering is collapsing onto product. Product people have to think more like engineers. Engineers have to think more like product people. The process that got the company here will not be the process that gets it where it's going.
Start Where a Backlog Has Been Sitting
If you want a foothold, look for the pile of work your team has never had capacity to touch. One team we worked with had an ideas board of over 7,000 items, mostly customer requests routed through support, with no human capacity to triage any of it. A broken human process, sitting there for years. Agents cleared a path through it in a fraction of the time the team could have.
Every function has a version of this:
- Support tickets and feature requests nobody has grouped
- Sales notes and calls that never became account intelligence
- Contracts, policies or documentation nobody has reconciled
- Research and competitor material that goes stale before it's read
- Reporting that gets rebuilt by hand every month
Pick one. Map it. Install agents against it. You get a visible win and the organization learns the sequence on something low-stakes.
Not Everyone Needs to Become an AI Power User
Stephen is direct about the ceiling here:
"recognizing the limitations that the reality is the majority of people in your organization are not going to become agent proficient like they're just not and that's okay"
Designing for that reality is more productive than fighting it:
- Identify the power users. They already exist. They're the people running these tools on their own time without being asked.
- Give them the mapped processes. Their leverage comes from owning a workflow, rather than from personal productivity hacks.
- Build the workflow around everyone else. Most of your team should feel the benefit through the systems they already use, with no new interface to learn.
- Put the review seats with the people who have judgment. Reviewing well requires domain taste, and the best reviewer is often the least technical person in the room.
- Stop counting adoption. Count whether the mapped process produces better work.
The New Work That Shows Up When the Bottleneck Clears
Clearing a backlog does not leave people idle. It surfaces work that was never possible before.
For early-stage teams
When you can build and ship faster than ever, the binding question becomes what you should build. It's easy to want to build everything. The discipline is deciding which specific thing connects to an end user and moves the business.
For growing organizations
The question shifts to which process you're overhauling and what you will genuinely do differently as a result. Someone I spoke with recently had a working prototype after two hours of effort and could take it straight to a customer for feedback. A product manager who no longer spends weeks triaging is freed for market research, competitor work, and more direct contact with the people who use the product. The higher-leverage activity is the human contact, and there is finally room for it.
how We Do: Patience and Empathy as a Rollout Strategy
The sequence we use with clients looks like this:
- Choose the processes that are core to the business.
- Map the current steps, including the undocumented ones.
- Decide where humans scope, where they review, and where agents execute.
- Install against one backlog with a visible cost.
- Equip a small group of power users and build the workflow for everyone else.
- Measure quality of output, then repeat on the next process.
None of that happens from a deck. It happens with someone sitting next to your people while they work. Stephen again:
"Have a lot of patience. Have a lot of empathy. I just think that like you're not going to you're not going to roll this. You're not going to be able to like implement AI effectively unless you have people on the ground actually with your people mapping your processes and helping to actually install these practices."
People's work lives are changing faster than they ever have. A rollout that ignores that will produce compliance and quiet resistance in equal measure. That's the reason we place operators inside the client's team, in their tools, covering the functions the leader has been carrying personally [3]. We publish these field notes as we gather them on the how We Do Substack [4].
FAQ
Why does rolling out AI agents often feel slower before it gets faster?
The early weeks of an AI rollout are spent surfacing undocumented steps, codifying knowledge that lives in people's heads, and building the review habits a team has never needed at volume. An established company also has to re-engineer a process designed for human throughput. That upfront cost is what makes the eventual agent output consistent.
What happens if you deploy agents without mapping the process first?
Volume increases and quality does not. Teams that deploy agents into unmapped workflows report more documents, more code and more output than they had before, with the same underlying errors reproduced faster. Mapping the process first identifies where an agent should execute and where a human has to plan or review.
Do all employees need to become deep users of AI agents?
No. The majority of people in most organizations will not become agent proficient, and a rollout should be designed for that. Build the workflows so the wider team benefits through systems they already use, and concentrate hands-on agent skill in a smaller group of power users who own specific processes.
How do you decide who becomes a 'power user' of AI inside your organization?
Power users usually identify themselves by already using the tools without being asked. Give them ownership of a mapped process rather than a general mandate, so their leverage shows up in the business instead of in personal productivity. Pair them with reviewers who hold domain judgment, which is frequently a different person.
References
- Anthropic. "Anthropic Economic Index." https://www.anthropic.com/economic-index
- Anthropic. "Claude Code." https://www.anthropic.com/claude-code
- of All Trades. "We are of All Trades." https://weofalltrades.com
- Britt F. Gage. "how We Do." https://ofalltrades.substack.com