The Failure Pattern: Requirements-Collection AX
Form an AX team, have it tour departments collecting requirements, build tools to spec, and hand them over. This reasonable-looking structure fails repeatedly for a simple reason: the field doesn't use the tools. The company expects that when AI removes one task, people move that time into more productive work — but real incentives run the other way. For someone whose hard-won way of working is their proof of worth, pressure to stop doing it is unwelcome.
Where Successful AX Starts: Remove the Work, Move the People
The conclusion of Jungsuk Roh, who has run an AI business hands-on for four years, is unambiguous: successful AX starts from "eliminate that team's unit of work entirely," not "help that team." This is not the language of layoffs — it is a design that fully removes a unit of work and transitions the person to a new role. Stacking more tools onto existing work amounts to swapping Excel and PowerPoint for different software; company-level productivity gains never materialize.
Best Tool Is No Tool — the Plain-Vanilla Setup
Another counterintuitive conclusion: don't build efficiency tools yourself. After trying every framework and homegrown agent internally, the answer that remained was clean data connectors, prompts written with domain understanding, and a frontier model attached to a proven harness like Claude Code. This plain setup outperformed every homegrown combination.
The power to write good prompts comes from domain understanding, not engineering skill. Prompts written by someone who knows how the work actually runs and what the data looks like are the ones that finish the job.
What AX Consulting Should Examine
Before building anything, SH Consulting examines two things in AX consulting: which unit of work can be eliminated entirely, and where the person doing it will be transitioned. AX that supplies tools without this design spends the budget and changes nothing.