![\"Torque](\"https:\/\/falcoxai.com\/main\/wp-content\/uploads\/2026\/10\/ai-is-not-a-tool-rich-hickey-inline-1.jpg\")
<\/figure>\nWhat Hickey Actually Means When He Says AI Is Not a Tool<\/h2>\n
Hickey’s argument is narrower and sharper than “AI is unreliable.” He is making a claim about what the word tool<\/em> has always meant: something whose behaviour you can learn, predict, and eventually master. Strip that away and you are not holding a tool. You are working with something else that needs a different management model.<\/p>\n Every standard operating procedure you have written assumes a stable relationship between action and outcome. Set the feed rate, get the surface finish. Run the gauge R&R, get a number you can defend. The procedure works because the equipment does not improvise.<\/p>\n That assumption also governs skill. An operator with ten years on a press brake produces less variation than one with ten months, because experience narrows the output band. Failure modes are catalogued, and when something goes wrong you can trace it to wear, calibration drift, or operator error. Your entire quality system is built on that traceability.<\/p>\n A language model gives you a different answer to the same prompt on Tuesday than it gave on Monday. Experience with it does not collapse that variance the way experience with a CNC machine does. A skilled prompter gets better average output, not consistent output, and those are not the same property. You cannot inspect the reasoning either, because there is no reasoning to inspect, only a weighted path through a model you do not have access to.<\/p>\n For a marketer drafting email subject lines, none of this matters. For a quality manager signing a deviation investigation, it matters completely. Regulated work requires you to explain why a conclusion is correct, not just that it looked correct. That is the gap the AI tool mindset papers over, and it is the reason deterministic vs probabilistic is the only distinction worth arguing about before you deploy anything.<\/p>\n The two mental models produce different purchase orders, different training plans, and different dashboards. One of them bills you twice for the same work.<\/p>\n Seat-based buying spreads a probabilistic system across fifty people who each use it differently and none of whom agreed on what good output looks like. Your supplier documentation review is now happening in fifty private styles. When a certificate of analysis gets misread, you cannot trace whether the fault was the model, the prompt, or the reviewer who skimmed it.<\/p>\n Adoption KPIs make this worse because they reward volume. A quality engineer who generates twelve draft deviation reports looks productive on the dashboard. If eight of those drafts need line-by-line correction against the batch record, you have added editing work to a team that was already short on hours. Rework is invisible in an adoption metric, which is why the numbers look good right up until the audit.<\/p>\n Treat every output the way you treat a contractor’s first draft. You define the scope before the work starts, you state what finished looks like, and you reject anything that misses. For CAPA drafting, that means naming which fields the model may populate, which require human sourcing, and what evidence must be cited for a root cause statement to be accepted at all.<\/p>\n Then measure the thing that matters: percentage of output accepted on first pass, by task type. That single number tells you where delegation works and where it does not. Supplier documentation review might hit a high acceptance rate within a month while deviation narratives stay stubbornly low, and you will know to stop paying for the second one.<\/p>\n The deployment model that works treats verification cost as the first variable, not an afterthought. You are not buying capability. You are buying drafts that someone still has to accept, and the economics only work when accepting is fast.<\/p>\n Rank candidate tasks on two axes: how long it takes a competent person to produce the output, and how long it takes them to check it. You want the gap wide. A supplier audit questionnaire response takes an hour to write and four minutes to read against the evidence pack. That is a good candidate.<\/p>\n Bad candidates share one feature: checking is almost as slow as doing. Root cause determination, risk scoring, anything where the reviewer has to redo the reasoning to trust the conclusion. Start with document-heavy work where the source material is bounded and the correct answer is visible on inspection. Non-conformance write-ups, training material updates, translating work instructions across sites.<\/p>\n Write the acceptance criteria before the pilot starts. Three to five specific checks per output type, written by the person who will sign the document, not by the vendor. If nobody can articulate what “good” looks like in advance, the pilot will end in opinion rather than evidence.<\/p>\n Then name an owner for every AI-assisted artefact. One person, named in the record, accountable for the content regardless of what produced the first draft. Track two numbers: percentage of outputs accepted without rework, and median time from draft to sign-off. Ignore logins and prompt counts entirely.<\/p>\n On ROI, the honest range for drafting time on document-heavy quality work is a 30 to 60 percent reduction, and you only book it after subtracting review hours. A team that cuts drafting by half and doubles review time has saved nothing. Count both sides or you are reporting a number your finance director will eventually unpick.<\/p>\nTools are deterministic and masterable: why that assumption underpins every SOP you have<\/h3>\n
AI is a non-deterministic collaborator you cannot fully inspect<\/h3>\n
Tool Thinking vs. Agent Thinking: Where the Difference Costs You Money<\/h2>\n
\n\n
\n \nDecision<\/th>\n Tool thinking<\/th>\n Agent thinking<\/th>\n<\/tr>\n<\/thead>\n \n Procurement<\/td>\n Seats for everyone who might use it<\/td>\n Scoped tasks with defined boundaries<\/td>\n<\/tr>\n \n Training<\/td>\n One onboarding session, then self-serve<\/td>\n Standing acceptance criteria per task type<\/td>\n<\/tr>\n \n KPIs<\/td>\n Logins, prompts run, adoption rate<\/td>\n Output accepted without rework<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n What breaks in procurement, training, and KPIs under tool thinking<\/h3>\n
What changes when you treat AI output as work submitted for review<\/h3>\n
![\"Side-by-side](\"https:\/\/falcoxai.com\/main\/wp-content\/uploads\/2026\/10\/ai-is-not-a-tool-rich-hickey-inline-2.jpg\")
<\/figure>\nHow to Deploy AI When It Isn’t a Tool: A Practical Model<\/h2>\n
Scope selection: tasks with cheap verification and expensive production<\/h3>\n
Building the review loop into the process instead of bolting it on<\/h3>\n