The missing middle in AI fluency is the skill of redesigning how a piece of work gets done before anyone builds anything for it. It sits between using AI to speed up one step and building a new AI tool. In my experience it is missing because people go around it from both sides. Two founders I talked to at the end of September stopped below it, and a group of interns I met the following week went straight past it.
Two conversations
Over the weekend of 26 and 27 September I talked with two founders of small and medium businesses. My takeaway was that they see AI as basic conversation and basic automation. I see a big gap between that and completely reimagining what they do, and I noted afterwards that small and medium businesses need to rethink their approach and put real energy into learning what AI can do for them.
The following week I spent time with a lot of interns. Everyone was eager to build something with AI and get a prototype going. Nobody spent time understanding the process, dissecting it, building a plan, forming a point of view or deconstructing what the users needed.
The two groups sit at opposite ends. The founders stopped at basic uses, and the interns rushed to build. My reading is that both missed the same step: sitting with how the work is done today and deciding what should change.
Building is very easy today, which makes the decision about what to build the expensive part. Whether something works, and whether anyone adopts it, depends on whether it was the right thing to build. That comes from basic systems thinking and first-principles thought, and those are the skills I saw missing in the interns' work.
There is a career reason to care. A CIO First Look newsletter on 1 October, citing Indeed Hiring Lab data, reported that workers with more experience are seeing the biggest boost as employers shrink their entry-level pipelines into AI-adjacent roles. My read is that a smaller entry-level door rewards people who can show judgement about the work. A fast prototype on its own shows speed.
The three altitudes of AI use
I describe AI use at three altitudes. Each one changes something different, and each has a piece of evidence that proves you are working at it.
ALTITUDE WHAT CHANGES PROOF YOU ARE THERE
3 Build a new tool exists someone uses it every week
2 Redesign the process itself a before-and-after map the
people doing the work accept
1 Assist one step gets faster a task done in less time
My reading of the founders: stopped at 1
My reading of the interns: jumped to 3
Both missed: 2Altitude 1: Assist. AI helps with a step inside a process that stays the same, such as drafting the first version of an email. The proof is a task done in less time. In my view this is the right place to start. The risk is that a faster step feels like progress, so the question of whether the step should exist at all never comes up.
Altitude 2: Redesign. Here you write down how the work gets done today, step by step, and decide which steps should change, merge, move or disappear now that AI is available. Nothing new gets built yet, and the output is a map. You know you are at this altitude when the people who do the work look at your before-and-after version and accept it as accurate.
Altitude 3: Build. You make the new thing: an agent, a workflow, an application, a prototype. Its proof is weekly use without anyone being asked. A build that skipped altitude 2 can still pass a demo, and the weekly-use test is where it gets caught, because nobody checked that the step it automates was the one that mattered.
Each new problem starts you back at altitude 1. A senior person who redesigned one process last year is assisting again on the next one until they map it.
For careers, the three altitudes are moving at different speeds. In my view, altitude 1 is becoming the baseline in office work, and altitude 3 keeps getting cheaper as building gets easier. Altitude 2 still needs a person who sits with the people doing the work and notices the step they quietly skip. A model can help you draw the map once you have had that conversation. Deciding which trade-off the business should make stays with you.
How to practise the middle
My advice is four moves, done on paper, in this order.
Write today's process as it really runs. Pick one piece of work you touch every week. Write each step on its own line, in order, the way it actually happens, including the workarounds. Ask the person who does it whether you have it right, and listen for the step everyone does and nobody wrote down.
Tag every step. Beside each line, write what the step mostly needs: a judgement, a lookup, a hand-over to another person, or waiting. In my view, lookups and hand-overs are where AI helps most. Judgements are where you need to be careful about handing anything over. Waiting is often worth testing for reordering.
Ask three questions of each step. Could AI remove this step? Could it shorten it? Should it stay exactly as it is? Write the answer beside the tag. A step that stays is a valid answer. If everything on the map changes, go back and ask the people who do the work.
Write your point of view in one paragraph. State what you think should change, which step matters most, and why you believe it. That paragraph turns a map into a decision someone can agree or disagree with, and it is the thing you hand to whoever builds, including yourself.
A worked example on paper
To make the four moves concrete, here is how they might run on a process most small businesses have: turning a confirmed order into a paid invoice. This is an illustration I built for this essay, not a client's process, and your version will differ.
STEP TAG AI?
1 Order confirmed by email hand-over shorten
2 Details retyped into the ledger lookup remove
3 Invoice drafted from a template lookup shorten
4 Owner checks price and terms judgement keep
5 Invoice sent, then nobody watches waiting reorder
6 Payment chased by phone at day 30 hand-over shortenThe altitude 1 version of this process puts a chatbot on the website and lets a model draft the invoice in step 3. Both help. Neither touches step 2, where the same details are typed twice, or step 5, where the invoice sits with nobody tracking it for a month.
The altitude 3 version is the instinct to build an invoicing agent that does all six steps. It would pass a demo. It would also hand step 4, the owner's judgement on price and terms, to a model without anyone deciding that was acceptable.
The altitude 2 version is the map above. It says step 2 should go, step 4 should stay with the owner, and the waiting in step 5 is the real problem. The point of view paragraph might read: "The money is lost between sending and chasing. Fix the gap after step 5 first, keep pricing judgement with the owner, and remove the retyping." That paragraph is short enough to argue with, and it tells whoever builds exactly which step to build for.
Then build, aimed at the step the map says matters.
Three traps to watch for in a redesign
These are the ways I would expect a first redesign to go wrong.
Mapping the procedure document. A written procedure is the easiest thing to copy onto the map, and it may describe how the work was meant to run years ago. The workarounds, the spreadsheet one person keeps on the side and the call made before every large order are where the real cost can sit, and they only appear when you ask the person doing the work to walk you through last Tuesday.
Redesigning alone. A map drawn by the person who wants to build something will lean toward the step they already wanted to build. Showing the draft to the people who do the work is how you find the step you skipped, and it is also how you get them to use whatever comes next. In my view a build they helped shape starts with an owner on the floor.
Treating "remove" as the only good answer. It is tempting to judge a redesign by how many steps disappear. In the invoice example above, the most valuable decision was to keep step 4 with the owner. A map that removes every judgement step may have handed a decision to a model without saying so, and that is a choice somebody senior should make on purpose.
Where the middle shows up
Founders and business owners can use it to get past the basic-chatbot stage. Mapping one core process, such as how an order becomes an invoice or how a lead becomes a customer, is a better first step than adding another tool.
Interns and early-career people can use it as evidence of judgement. Bring the map along with the demo. A one-page before-and-after process, with a paragraph explaining why you chose the step you chose, should tell a manager you understand the business as well as the tool. In an interview, it answers the question a demo invites: why this step?
Managers can ask for it. When a team proposes an AI build, ask to see today's process and the step they want to change before approving the work.
Three things to do this week
- Pick the process and the person. Choose one piece of work you touch every week and name the colleague who does most of it. Book thirty minutes with them before Friday.
- Take paper to the meeting. Write the steps as your colleague describes them and tag each one as you go. Ask which step costs them the most time or causes the most errors.
- Send the paragraph. After the meeting, write your one-paragraph point of view and send it to that colleague. Ask them to correct it before you build anything.
What to read next
- The Five-Rung Ladder for Learning AI, and the Rung Where Most People Stall
- Why Your Team Hides Its AI Use, and Three Moves That Make It Sayable
- Every Agent Demo Sells the Ceiling. Adoption Is Decided by the Floor.
Footer
Anees Merchant writes one essay every Tuesday about enterprise AI, agentic systems, and the human side of the work. He is the author of Merchants of AI, a TEDx speaker, and a doctoral researcher in Human-AI Communication at the Swiss School of Business and Management.
The newsletter version, with extra commentary, goes out separately on Mondays. Subscribe at /newsletter.
See you Tuesday.