TLDR; The question isn’t whether to use AI, it’s where in the system it belongs. Deterministic work (compliance calculations, production queries, anything that must behave the same way every time) should never run inside a model. But AI is often the fastest way to build the deterministic system that replaces it.
A client asked me last month whether they should use AI for their monthly compliance reporting. The reports go to a regulator, the data shapes funding decisions, and an error at any stage becomes a finding at the next audit.
My frank answer was no, not for generating the report itself. The report is signed by a real person, and the audit trail has to be defensible. But the SQL pulls, the cross-checks, the templates, the validation rules? Claude Code wrote nearly all of that in two afternoons. The pipeline now runs without a model anywhere in it, and the reports come out the same way every month.
Two years of working this way has taught me to ignore the framing most AI advice is built around. The question isn’t “should I use AI for this.” It’s “where in the system does AI belong, and where does it definitely not belong.” This piece is the prologue to the rest of the Playbook because every guide that follows assumes the reader has a working answer to that.
The work AI is bad at
Coding agents are non-deterministic by design. Two runs of the same prompt produce different outputs. That’s the same property that lets the model write good prose, weigh tradeoffs, and sometimes surprise me with a better answer than I asked for. It’s also why putting one inside a workflow that needs to behave the same way every time is a category error.
A compiler is deterministic. A SQL query against a stable dataset is deterministic. Tax calculations, currency conversions, sorting, hashing. For all of these, two different outputs from the same input is by definition a bug. None of them belong inside an AI runtime.
Simon Willison’s Vibe Engineering post makes a related point: agents do their best work inside deterministic scaffolding (tests, CI, linting) that checks what they produce. If I’m building something that needs to behave the same way every time, the question isn’t how to make the model comply. It’s whether I should be using a model at all.
The work AI is good at
The flip side of non-determinism is generativity. The same property that makes models unsuitable for payroll arithmetic makes them useful for synthesis, drafting, naming, sketching options, reading code for design problems. Work where there are multiple valid answers, the right one depends on judgement, and a fresh perspective beats a precise one.
The empirical version of this is the peer-reviewed Jagged Frontier study, run with 758 BCG consultants using GPT-4 on a defined set of consulting tasks. Tasks inside the study’s measured frontier received substantially higher evaluator scores, with consultants completing 12.2% more tasks and finishing 25.1% faster. On one task deliberately outside that frontier, participants using AI were 19% less likely to reach the correct answer. Those results support sorting tasks before delegation, but they do not establish a permanent boundary for current models or coding work.
When the cost of being wrong matters
Determinism tells me what AI can do. The cost of being wrong tells me whether I should let it.
Some decisions are reversible. I push the wrong sentence into a draft, I fix it before publish. Some aren’t. I push the wrong query into production and there’s an incident. Bezos called these two-way doors and one-way doors. Two-way doors tolerate non-determinism cheaply. One-way doors do not.
The question comes down to three things I check on any task. Will someone outside the team need an explanation of why this output was produced, a regulator, a customer, my future self? Does it run thousands of times, where small variance compounds? Can a wrong output reach money, customers, compliance posture, or live users? If the answer to any of these is yes, the runtime needs to be deterministic.
That doesn’t mean don’t use AI. It means don’t put AI in the runtime.
Using AI to build what AI can’t run
The verdict on whether AI fits is a verdict on the runtime. It says nothing about who or what builds the runtime.
A task can be deterministic, high-stakes, and audited, and still benefit from AI, as long as AI is doing the build, not the run. The compliance reporting case from earlier is exactly this. The work that “shouldn’t use AI” used Claude Code to write:
- The data extraction scripts (deterministic SQL, AI-generated)
- Cross-validation rules against the source of truth
- The templates and the audit log emitters
- A regression test suite covering every prior audit finding
- CI gates that block report generation if validation fails
None of that runs the model. The pipeline produces the same report every month, the audit trail is defensible, and getting from “we’d like to automate this” to “this is auditable” took two afternoons instead of two weeks.
The same pattern shows up in the marketing pipelines I’ve shipped. Claude drafts the first cut. Deterministic checks compare structured claims against cited source data and fail the publish step when a supported claim does not match. Claims the checks cannot parse or trace are routed to human review. The model writes; deterministic gates verify what they can; a person owns the remainder.
OpenFn frame this as build-time vs run-time and it’s the same idea. Anthropic’s Building effective agents puts it from the model vendor’s side: “we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.” Most of the time, the deterministic system you should build is one Claude can write for you in an afternoon, and that you then run without it.
Human-in-the-loop, properly done
There’s a category of work where even an AI-built deterministic system doesn’t go far enough. Anything where factual accuracy is the deliverable. Compliance-sensitive content. Medical, legal, regulatory. Things that can be wrong in ways the system can’t catch on its own.
For this work the architecture is three layers. The model drafts. Deterministic checks verify what they can, source matching, citation audits, claim verification against an authoritative database. A human reviews and signs off. Each layer catches something the next can’t. The model alone hallucinates. The checks alone can only verify what they were built to verify. The human alone doesn’t scale.
What the three layers buy is a different shape of human work. Without them, the reviewer reads the document line by line, copy-edits, fact-checks, and signs. That’s eight hours of mostly mechanical work, and after a few of them the reviewer is tired and starts missing things. With the layers, the reviewer reads the flagged exceptions and edge cases, judges them, and signs. That’s an hour of work, and the work is judgement instead of mechanical labour.
Where I see this go wrong is “human-in-the-loop” interpreted as “let the model produce the output and have a human glance at it before publishing.” That isn’t a human in the loop. It’s a rubber stamp, and within a few weeks the human stops looking carefully because the model is usually right. Deterministic gates are what keep human review honest. They catch the mechanical errors before the reviewer sees the document, which frees attention for the things only a human can catch.
For high-stakes content I’ve stopped accepting “AI plus a human reviewer” as a complete answer. The middle layer is the work.
Sort the work first
The rest of this Playbook assumes the sorting is done. Once I know which parts of a piece of work are AI-shaped and which need to behave the same way every time, the rest of the decisions follow. CLAUDE.md and skills shape the AI-mediated work. Hooks and MCP servers are mostly the deterministic gates. The agents and orchestration patterns coordinate AI work where the work is AI-shaped.
Read the rest in any order. But before any of it, work out what you’re asking AI to do. The most useful thing I’ve found AI can do this year isn’t drafting reports or writing code or answering questions. It’s building the deterministic systems around those things, so the work that needs the model gets it, and the work that doesn’t, doesn’t.
Sorting the work this way is where I start with Applied AI clients.
Related reading
- CLAUDE.md, the file that changes everything, the per-project instruction file that shapes AI-mediated work
- Skills, hooks, agents, and commands, how to use each, the four primitives that compose AI-shaped work and the deterministic gates around it
- Quality gates, session reviews, fact-checking, and code review, the deterministic-check layer that sits between model output and human sign-off
- Building custom MCP servers for your workflow, deterministic tool integrations the model can call but doesn’t run
- Using AI at work without the hype, the business-audience companion to this piece for readers who want the argument without the engineering detail
Sources
- Navigating the Jagged Technological Frontier, Dell’Acqua, McFowland, Mollick et al., Final peer-reviewed publication of the field experiment with 758 consultants: 12.2% more tasks completed, 25.1% faster, higher quality inside the measured frontier, and 19% less likely to reach the correct answer on an outside-frontier task. Organization Science, Vol. 37, Issue 2, 2026
- Centaurs and Cyborgs on the Jagged Frontier, Ethan Mollick, Mollick’s plain-English summary of the study, confirming the 758-consultant sample (≈7% of BCG’s consulting force) and the inside/outside frontier breakdown. Newsletter
- Vibe Engineering, Simon Willison, The determinism-vs-judgement framing for AI-assisted development. Blog post
- When to use AI in your workflows, and when not to, OpenFn, The build-time vs run-time framing for AI in workflows. Blog post
- Building effective agents, Anthropic, “we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.” Company research
Common questions
When should you not use AI in business?
Not in the runtime for anything that has to be deterministic: compliance calculations, production queries, tax and currency calculations, anything where two different outputs from the same input would be a bug. The same logic applies to one-way door decisions, ones you cannot easily undo, where being wrong can reach money, customers, or compliance posture.
How should I use AI in my business?
Sort the work first: reserve AI for tasks with multiple valid answers where judgement beats precision, drafting, synthesis, sketching options, and keep it out of anything that must run the same way every time. Even for high-stakes, deterministic work, AI is often the fastest way to build the deterministic system that replaces it, as I did writing a compliance pipeline’s data extraction scripts and validation rules in two afternoons.
When is AI worth using?
Use AI where judgement, synthesis and multiple valid answers matter, then verify the result in proportion to its impact. In a 758-consultant GPT-4 field experiment, participants completed 12.2% more tasks and worked 25.1% faster on tasks inside the study’s measured frontier; on one outside-frontier task, AI users were 19% less likely to reach the correct answer. The boundary was specific to that model and task set, not a permanent rule for current tools.