When CEOs ask “how do we become a Frontier Firm,” what they usually mean is “how do we get the productivity gains without the politics.” The honest answer is that you can't skip the politics — but you can sequence them so they don't blow up the work.
Here's the twelve-week sequence we run with mid-market firms (50–500 people) who want to reorganize a function around agents. It's opinionated. Skip steps at your own risk.
Weeks 1–2 · Find the unit of work
Most transformation programs fail at this step because they pick a department instead of a unit of work. “Modernize support” is a department. “Auto-triage refund tickets where the policy decision is unambiguous” is a unit of work. Only the second one can be measured, improved, and shipped.
We do this with two senior engineers sitting in on the actual work for a week. Reading tickets, watching analysts, timing tasks. By the end of week one you should have a list of 8–15 candidate units; by end of week two, three of them ranked by ROI and risk.
Weeks 3–4 · Build the smallest valuable thing
One unit of work. One agent. One eval suite. The success criterion is not “feels good in demo” — it is “hits the eval bar your team set on day one.” The eval bar is the contract between engineering and the business. Without it, “done” becomes negotiable.
Weeks 5–6 · Put it in front of one team
Not a pilot department. One team. Five to fifteen people. The agent runs alongside them, suggests actions, accepts corrections. You are measuring two things: deflection rate (did the agent handle the task) and correction rate (when humans intervened, were they fixing a real error or a stylistic preference). Both numbers tell you what to harden before scaling.
Weeks 7–8 · Harden, then widen
Use the corrections to expand the eval suite. Find the failure modes your team didn't imagine on day one — there will be five or six you didn't imagine. Patch them. Add observability for the patterns you patched. Then expand the agent to a second team.
Weeks 9–10 · Restructure the work
This is the political step. The team using the agent is now doing their job differently. They're reviewing flagged exceptions instead of processing the queue. Their job description needs to reflect that. Their KPIs need to reflect that. Their headcount plan — and this is where the politics arrives — needs to reflect that.
Our recommendation is to notreduce headcount in year one. Reallocate the recovered hours to higher-value work that has been backlogged forever. The signal you want to send across the company is “adopting agents grows the surface area of what each person can do,” not “adopting agents shrinks the team.” The second signal kills the program.
Weeks 11–12 · Generalize the pattern
By now you have one working agent, one team running on the new workflow, and one eval suite that gets you out of the “does it work” argument. The last two weeks are documenting the pattern so the second and third units of work can be done by your team, not ours. Runbook. Eval-suite template. Observability dashboard. Cost monitoring. Onboarding doc for the next team.
What you have at the end
One agent in production. One team restructured around it. A repeatable pattern your team owns. And — critically — a credibility account inside the company that you can spend on the next unit of work, which will be twice as hard.
Companies that try to do all of this at once spend a year producing a transformation deck. Companies that pick one unit of work and run this sequence have something in production by week eight. The math on which approach wins isn't close.