Intro
Which AI tool should we use?
That is usually the first question. It feels practical. It sounds like progress. It is almost always the wrong place to start.
Useful AI adoption does not begin with finding the cleverest tool. It does not begin with the best prompt, the newest model, or the question of whether the organisation should use ChatGPT, Claude, Copilot, Cursor, or whatever lands next Tuesday and makes everyone pretend the previous thing was obviously obsolete.
Those things matter. They are not the starting point.
Most organisations don’t have an access problem anymore. They have something harder: an operating model problem. And underneath that, a question that almost nobody is naming out loud — what happens to the craft when the machine arrives?
People are already using AI. Someone is summarising meetings. Someone in engineering is using coding agents. Someone in operations is pasting messy spreadsheets into a chat window and quietly getting more done than the official automation roadmap has managed in six months.
Some of this is useful. Some of it is risky. Most of it is inconsistent.
That creates a hard management problem. You can see value, but not repeatability. You can see polished output, but not always reliable work. You can see craft quietly being eroded under output that looks finished, and nobody is sure when that started.
That is where many AI adoption efforts go wrong.
They ask which AI tool to buy. They ask whether they should build an agent, roll out a platform, write another policy, or give everyone access to the same model.
Maybe. But if the work itself has not been understood, those decisions are premature. They create activity. They do not always create direction. They create control of a kind. It is not always the right kind.
The better question is not “which tool should we use?”
The better question is: what kind of working model does this process need now that AI is part of the environment, and which parts of the craft must not be lost in the transition?
That is the work I help organisations do. Not AI adoption as a slogan. Not AI strategy as theatre. Take one real workflow. Map how it currently happens. Run AI against real inputs. Study where it helps, where it fails, where it saves time, where it creates risk, and where human judgement still needs to own the result.
Then turn that into something operational: what AI does, what humans own, what needs review, what can be automated, and what should not be automated yet.
One workflow at a time. Real inputs. Real failure modes. Clear ownership.
The goal is not to use more AI. That is a bad metric.
The goal is better work, with the craft intact.
The missing layer is not access
In many organisations, AI adoption has already started. It just hasn’t been designed.
That is why the situation feels strange. Leaders are not looking at a blank page. They are looking at scattered usage that is already producing value. One team has found a good way to draft internal reports. Another uses AI to clean up support tickets. Engineers are using coding assistants in different ways. Someone has built a useful unofficial workflow. Someone else is trusting AI too much. Another person refuses to use it at all.
Then management looks at this and asks: is this good?
Reasonable question. Hard to answer.
Because “using AI” is not one thing. Using AI to summarise internal notes is not the same as using AI to make a customer-facing recommendation. Drafting a first version is not the same as approving a decision. Producing code in a disposable branch is not the same as letting an agent change production systems.
Without a working model, these differences blur. There is no shared standard, no clear boundary between useful support and risky delegation, and no reliable way to tell whether something is repeatable or just a good-looking one-off.
So the organisation gets the worst combination: real value and real chaos.
Enough value that you cannot ignore it. Enough chaos that you cannot responsibly scale it.
That is why AI literacy is becoming more than tool literacy. Knowing how to use ChatGPT is useful. Knowing when not to use it is more useful. Knowing how to redesign the work around it — or how to refuse to redesign it — is the actual skill.
”Can AI do this?” is the wrong first question
“Can AI do this?” sounds practical. It is often a bad first question.
AI can do a lot of things badly. It can also do a lot of things surprisingly well. It can draft, summarise, scaffold, suggest, and critique. But that does not tell you enough.
The better questions are more specific. Can AI help with this part of the work? Can a human judge the result reliably? What happens when it is wrong? Would we notice? Would the failure be embarrassing, dangerous, or irreversible? Would it sit under someone’s name?
These questions matter because AI adoption does not fail only when the tool is useless. It often fails when the tool is useful enough to be trusted in the wrong place.
A bad AI output is easy to reject. A plausible AI output is more dangerous. It looks like progress. It looks finished. It looks like someone has done the work.
But has anyone owned the judgement? Has anyone checked the assumptions? Has anyone decided whether AI should draft, suggest, summarise, or stay out of the way?
That is where adoption stops being a tooling question and becomes an accountability problem.
The first output is material
Sometimes the first AI output is not supposed to be good. It is supposed to be material.
A rough shape. A block. Something you can inspect, criticise, cut apart, reuse, throw away, or use to understand the problem better.
In coding, that might be a vibe-coded first version. Maybe it is garbage. Maybe it is almost releasable. Most likely it is somewhere in the middle: wrong in places, useful in places, and valuable because it moved the work out of abstraction.
It may reveal that the requirement was unclear. It may expose hidden complexity. It may show that the imagined architecture does not fit. It may show what not to do.
That is still value.
You do not always need to babysit AI from vague intent to polished output. Sometimes it is better to let it attempt the work, inspect the result, learn what failed, and run a cleaner second attempt with better constraints.
From the AI’s point of view, the second pass is a fresh first pass. From the process’s point of view, it is a first pass after learning.
That distinction matters. The first pass is not the final sculpture. It is the block of material. The craft starts when you can see what kind of block you actually have.
The two traps
There are two traps I see often.
The first is the engineering trap. Technical people see a messy AI-assisted process and immediately want to systematise it: agents, schemas, orchestration, evaluation loops, custom tooling, and a folder full of markdown files that slowly becomes production code, except nobody admits it.
Some of this may be necessary later. But if you build it before understanding the process, you are not creating control. You are creating expensive uncertainty with better names.
You don’t yet know where AI fails. You don’t know which variance is useful and which variance is dangerous. You don’t know whether the old process should even survive contact with AI.
So the system gets built around assumptions. Then the assumptions break. Then you add more rules. Then the rules need exceptions. Then the exceptions need their own rules.
Then you are no longer adopting AI. You are maintaining a bureaucracy of prompts.
The second trap is the over-trust trap.
Non-technical adopters often prove something important: AI can push work much further than sceptics expected. Vibe coders build things that would have been inaccessible to them two years ago. Founders generate first versions of landing pages, pitch scripts, and customer flows without waiting for a specialist. Marketers generate ten angles before lunch.
This matters. Sometimes the fastest way to understand what AI can do is to stop theorising and let it attempt the work. Not forever. Not blindly. Not in production. But enough to see what happens.
The non-technical crowd often discovers possibility faster because they don’t start by building the control system.
The trap is that possibility is not reliability.
A thing that works once is not a process. A great-looking output is not automatically safe. The most expensive AI failures are not the obvious ones — they are the plausible-looking outputs that quietly went out under someone’s name and nobody checked because everything looked fine.
The mistake of engineers is to build control too early. The mistake of AI maximalists is to trust output too early.
Both are wrong in useful ways.
That is why the answer is not “engineer everything.” And it is not “just vibe it.” The answer is to learn from the attempt, then decide what kind of working model the process actually needs — including whether the process needs to change at all.
Redesign is not always the answer
There is a quieter trap underneath both of those, and it is being pushed hard right now.
The dominant story around AI adoption is that organisations should redesign their workflows around AI. Rebuild the process. Rethink the org chart. Become AI-native. The vendors selling this story have an obvious incentive: a redesigned workflow needs platforms, agents, infrastructure, training, and ongoing engagements. A workflow with AI in three places and humans owning the rest needs almost none of that.
I am not saying redesign is always wrong. Sometimes it is exactly right.
I am saying it is not the default. It is one option among several, and it is currently being treated as the only serious answer.
Sometimes the correct working model is: AI helps in three places, stays out of seven, and the workflow stays mostly the same. That is a successful adoption. It just doesn’t sell consulting engagements or platform licences.
Sometimes the craft is the product. Reorganising the work around the machine produces something faster, cheaper, and worse — worse in ways the dashboard will not show, because the things craft protects (judgement, taste, accountability, meaning) do not always live in the metrics.
A useful working model has to be allowed to conclude: AI does not belong here. Or: it belongs only at the margins. If the method can only output “here is how AI fits,” it is not a method. It is a sales funnel with extra steps.
That is the spirit underneath what comes next.
CRAFT: how I approach AI work design
The shorthand I use is CRAFT: Clarify. Run. Assess. Fit. Tighten.
Not as a rigid framework. Not as a universal recipe. Not as another transformation slogan. CRAFT is how I structure the work when an organisation needs to move from scattered AI usage to a practical working model — without losing the craft in the process.
The name is deliberate. The thing being protected is the craft. Every step exists because somewhere in the workflow, judgement, taste, meaning, or accountability could be quietly handed to a machine that produces plausible output without owning the result.
A founder will not use CRAFT the same way as a regulated organisation. A coding team will not use it the same way as a branding process. A low-risk exploratory workflow will not need the same controls as a production decision path.
That is the point.
CRAFT is not the process. CRAFT helps design the process.
Clarify produces a map of the work, including the parts that need to remain human-owned. Run produces a real AI attempt against real inputs. Assess produces a view of failure modes and judgement points. Fit produces a human-AI responsibility model that protects what should not be delegated. Tighten produces only the controls the workflow has earned.
The practical output is not “we used AI.” The practical output is a working model: this is what AI does, this is what humans own, this is where review happens, this is where failure matters, this is what can stay loose, and this is what should not be automated.
That is usually more useful than another AI strategy deck.
Clarify: what is the craft, really?
Clarify means understanding the work before AI touches it. Not a 90-page transformation deck. Just enough to see what is actually happening, and what would be lost if the wrong part of it were handed to a machine.
What is the outcome? Who owns it? Where do the decisions live? Where does risk live? Where does taste matter? Where is human approval part of quality, rather than bureaucracy?
This is especially important in work that is not purely mechanical. Branding is not just asset production. Writing is not just text production. Engineering is not just code production. Reporting, when it is done well, is not template-filling at all — it is interpretation.
A lot of work contains meaning, accountability, direction, and taste. If you hand that to AI by accident, you may still get output. You just may not get work you should own.
Clarify protects the parts of the work that need to remain owned.
The output of Clarify is a useful map of the work: what happens, who owns it, where quality enters, where risk enters, where decisions are made, where craft lives, and where AI might plausibly help.
Run: what can AI actually produce?
Run means letting AI attempt real work before building infrastructure around it. Not theoretical work. Not a toy demo. Not “write me a generic customer support policy.”
Take a real process, or a real part of one, and let ordinary AI tools attempt something useful: a draft, a research pack, a code scaffold, a customer email variant, a rough prototype.
The goal is not reliability yet. The goal is to see whether AI can create useful material at all.
Use the tools you already have: ChatGPT, Claude, Copilot, Cursor, a simple prompt, a markdown instruction, a checklist.
Don’t build the platform first. Run the work first.
This is where many organisations learn more in a week than they would from months of abstract AI planning. Real inputs expose real constraints. Real outputs expose real failure modes. Real users reveal where the work is actually messy.
Run proves possibility.
But possibility is not enough.
Assess: what happened when it failed?
Possibility is not process.
Assess what happened. Where did AI help? Where did it drift? Where did it become generic? Where did it invent? Where did it change the meaning? Where did it produce useful variation, and where did variation become dangerous?
This is also where the real risk question lives.
Don’t only ask whether AI works most of the time. Ask what happens when it fails once.
That single question changes the whole conversation.
A summarisation mistake in an internal draft is one kind of problem. A wrong compliance judgement, a bad customer instruction, or a public statement under someone’s name is another.
If the process cannot survive one failure, the process is not ready for autonomy at that point. Even if it worked 1,000 times in testing. Especially if it worked 1,000 times in testing and everyone stopped paying attention.
Assess separates impressive output from repeatable process.
The output of Assess is a failure-mode view: where AI is useful, where it is weak, where human judgement is required, where review is enough, and where automation would be irresponsible.
Fit: what stays human-owned?
Fit is where you decide what belongs where, and — more importantly — what does not belong to the machine at all.
Some parts should stay human-owned. Some can become AI-assisted. Some can become AI-heavy. Some need approval gates. Some should remain loose because useful variance is the whole point.
But Fit is not only about assigning roles inside the old process. Sometimes the old process itself should change. And sometimes — this is the part the dominant story keeps forgetting — it should not.
A lot of workflows were designed before AI was available. They assume research is slow, drafting is expensive, visual exploration is limited, and producing alternatives costs real time.
AI changes some of those assumptions. Not all of them. Enough to matter.
So Fit asks two questions, not one. Does this process still need to look like this? And: are there parts of this process that should be deliberately protected from change, because the craft they carry is the actual product?
Some steps may disappear. Some may merge. Some may move earlier. Some may need stronger human gates because AI makes production easier, and easier production means easier production of plausible nonsense. Some should stay exactly as they are.
The goal is not to preserve the old process. The goal is not to automate the whole thing. The goal is not even to redesign.
The goal is to design the right working model — which sometimes means almost no redesign at all.
Fit is where AI adoption becomes process design, and where process design becomes craft protection.
Tighten: what control is actually justified?
Only then tighten.
This may mean a checklist, a template, a rubric, a review gate, a fallback path, a log, a test, CI, or a custom tool.
Sometimes tightening means more automation. Sometimes it means less. Sometimes it means keeping AI in a small, safe part of the workflow instead of expanding it. Sometimes it means adding human approval exactly where someone was trying to remove it.
This is not anti-automation. It is anti-surprise. And it is anti-bureaucracy too — controls that don’t protect the craft are just paperwork with extra steps.
For risk-sensitive organisations, the path to business-as-usual should often start with small AI interventions: low-risk, visible, reversible, reviewable, and outside the critical decision path.
Summarise internal notes. Draft first-pass documents. Cluster feedback. Generate options for human review. Then observe.
Don’t jump from “it worked in testing” to “let it run the process.”
That is how you get the classic disaster pattern: everything worked until the one time it failed in the exact place failure mattered.
Tighten only where the process proves it needs control. Build the control to protect the craft, not to perform it.
What this produces
A useful AI adoption engagement should leave behind something operational. Not just a deck. Not just a policy. Not just a list of tools.
For one chosen workflow, the outputs should be concrete: a current-state map of how the work actually happens; a set of AI attempts against real inputs; a review of where AI helped, failed, drifted, or created false confidence; a human-AI responsibility model; a small set of controls; and a recommendation on what to scale, what to constrain, and what not to automate yet.
That gives the organisation something more useful than enthusiasm.
It gives it a working model.
Once you have that, the next conversation becomes much more practical. You are no longer asking whether AI is good or bad in the abstract. You are asking what kind of work it can support, under what conditions, with what ownership, and with what controls.
That is how AI adoption becomes cumulative instead of chaotic.
A simple example: the monthly report
Take something boring: a monthly internal report.
The obvious AI question is whether we can automate the report. Maybe. But that question hides too much.
What is the report actually doing? Is it collecting facts, explaining movement, creating accountability, preparing leadership for decisions, or protecting someone from surprise?
Clarify the work, and the report may split into several different jobs: data collection, status summaries, exception detection, narrative drafting, risk interpretation, and final accountability.
Those are not the same thing.
Then Run. Give AI last month’s structure, current notes, metrics, and project updates. Ask for a draft.
What happens?
Maybe it produces a decent first version. Maybe it spots inconsistent updates. Maybe it creates a useful executive summary. Maybe it also overstates confidence, smooths over uncertainty, hides weak signals, and turns unresolved issues into polished sentences.
That is where Assess matters. Where was it helpful? Where was it too confident? Where did it make the report look more complete than the underlying work actually was? What would happen if that mistake reached leadership? What would happen if nobody noticed?
Now Fit. Maybe AI should not own the report. Maybe it should prepare a first draft, cluster updates, highlight missing inputs, and generate questions for the report owner. Maybe the human should own interpretation, risk framing, and final wording. Maybe the report itself should look almost the same as before, just with a faster first draft and a sharper review pass.
Then Tighten. Add a template. Require source links. Force unresolved items into a separate section. Mark AI-generated sections. Keep final approval human-owned.
Now you have not “automated the monthly report.”
You have protected the craft of reporting and used AI to make parts of it faster.
Some parts got faster. Some parts became more visible. Some human judgement became more important, not less.
That is what useful AI adoption often looks like. Not magic. Not replacement. Not even redesign. Better work design, with the craft intact.
Coding shows the controls
Coding makes this visible because software already has natural control points: issues, branches, PRs, tests, reviews, CI.
There are many AI coding workflows now: vibe coding, agentic loops, approve-each-command, strict PR-driven systems, test-first approaches, loose exploratory flows.
None of them is universally correct.
A solo builder may want speed and disposable first passes. A senior engineer may want a lightweight AI coworker. A regulated team may need traceability, branch discipline, review gates, and stronger controls.
The lesson is not that one AI coding workflow wins. The lesson is that the workflow has to fit the context.
Should the agent be allowed to touch production code? Should it create a draft PR? Should it write tests before implementation? Should human review happen before or after the first implementation? Should the system optimise for speed, learning, safety, or maintainability?
Different answers create different workflows.
In coding, Clarify defines the task and the boundaries. Run produces a first implementation or scaffold. Assess finds drift, broken assumptions, weak tests, and risky changes. Fit decides what the agent may own and what humans must review. Tighten adds the checks, branch rules, tests, and PR discipline the context deserves.
Coding is the obvious example because the controls are already visible.
But it is not the only useful example.
Branding shows the judgement
Branding is more revealing in a different way, because branding is not just production. It contains identity.
AI can help explore names, logo directions, palette options, copy angles, landing page mockups, and a hundred variations that would have taken much longer to produce manually.
That can be useful. Very useful.
But the human still owns the direction. The human owns the taste. The human owns the question: does this feel like us?
A top branding expert will usually beat a generic AI-led process, especially where identity, positioning, and taste matter.
That is not the point.
The point is that not every founder has access to top branding talent on day one. AI can still create a better starting point: more material, more options, faster exploration, and a clearer basis for human judgement.
Not the final identity. Material. A block to think against.
Then the human chooses, rejects, redirects, sharpens, and owns the result.
In branding, Clarify protects identity. Run creates visual and verbal directions. Assess filters generic output, distortion, and false polish. Fit keeps meaning and taste human-owned. Tighten turns the chosen direction into a usable system: palette, typography, logo rules, examples, constraints.
AI can produce variation. It cannot own meaning. AI can create directions. It cannot decide which direction is true. AI can accelerate exploration. It cannot remove the need for taste.
That is the difference between AI replacing craft and AI supporting craft.
Internal adoption starts with one workflow
Inside organisations, the problem is often not lack of experimentation. It is unstructured experimentation.
Different people use different tools, prompts, and assumptions. Some use AI too cautiously. Others trust it too quickly. Managers are left trying to convert scattered usage into something safe, explainable, and useful.
This is where many organisations need less theatre and more process work.
Not another AI strategy deck. Not “install a chatbot and call it transformation.” Not a vague permission slip for everyone to use AI however they want. And not a roadmap that assumes every workflow needs redesigning.
A better starting point is one real process.
Something visible, useful, slightly messy, not catastrophic if the first experiment fails, and important enough to teach something.
Sit with one team. Look at one workflow. Follow one output from beginning to end.
Where does it start? Where does it wait? Where does quality enter? Where does risk enter? Where do people copy, paste, rewrite, summarise, interpret, approve, and fix? Where does work happen that nobody put in the process map?
Then test AI against that reality.
Not the imagined workflow. The actual one.
Map it. Run AI against it. Assess what happens. Fit the roles. Tighten the controls. Then decide what this teaches the organisation about AI adoption more broadly — including, sometimes, the lesson that this particular workflow is fine and AI doesn’t need to live inside it.
That is the practical layer many organisations are missing. They don’t need more excitement about AI. They need a way to turn scattered AI use into working models: visible, reviewable, explainable, and appropriate to the risk of the work.
What should you do first?
Don’t start with the biggest process. Don’t start with the most sensitive one. Don’t start with a grand roadmap that assumes you already know what AI will change.
Start with one real piece of work.
Preferably something annoying enough to matter, but safe enough to learn from: a reporting workflow, a research process, a content production process, a support triage process, a QA pass, an internal documentation flow.
Then ask the CRAFT questions.
What is the craft, really? What can AI actually produce? What happened when it failed? What stays human-owned? What control is actually justified?
You don’t need to answer everything perfectly at the start. Some questions are there to slow down bad certainty. Some are there to reveal assumptions. Some are there to make hidden work visible. Some are there because the first answer is probably wrong.
That is fine.
The goal is not to produce a perfect AI workflow on day one. The goal is to learn what kind of workflow the work deserves.
Closing
Useful AI adoption does not start with choosing the most impressive tool. It starts with understanding the work, and being honest about what in that work is worth protecting.
Pick one real process. Map how it currently happens. Run AI against real inputs. Study where it helps, where it fails, where it drifts, and where it changes the assumptions behind the process.
Then decide what should remain human-owned, what can become AI-assisted, where stronger control is needed, and — when the answer is honest — where AI doesn’t belong at all.
That is the work.
Not buying the tool. Not chasing the demo. Not scaling chaos because some of the chaos produced value. Not redesigning every workflow because the loudest voices in the room have a financial reason to recommend it.
The organisations that get this right will not be the ones that chase every new tool first. They will be the ones that learn how to inspect the work, test AI against reality, keep judgement where judgement belongs, and build control only where control is earned.
They will know which work can be accelerated, which work must remain owned, which failures must never be allowed to hide inside polished output, and which parts of the craft must not be touched by the machine at all.
That is the new craft.
Not prompt craft. Not tool craft. Not the craft of redesigning every workflow around the latest model.
The craft of deciding when the machine should reshape the work, when it should support it, and when it should be kept out of it entirely — and being willing to defend the answer either way.