Right Tool, Right Job

Problem

One model for every job - and no named exceptions

The failure isn't the standard. It's having no named exceptions. Models aren't interchangeable. Some are stronger at long documents, some at code, some at careful reasoning, some at speed and cost. Some can search the web or run code; some can't. A model that's excellent at drafting can be poor at arithmetic (Pattern 10). A tool that's great for a quick answer can be the wrong one for research you'll cite - and sometimes the right tool isn't AI at all.

When the default handles everything, the weak spots don't show up as "wrong tool." They show up as "AI isn't good at this" - and the team stops using AI for work it could do well with the right tool.

I found this out starting Level 5ive. I first tried two popular AI chat tools to build my marketing materials, and both were wrong for the job: they didn't have the depth of business knowledge I needed. When I switched, I got answers and value much faster. Neither of the first two would have gotten me where I am in three months.

Value

Better results from the AI you already pay for

Fewer "AI can't do this" conclusions that are really "this AI can't do this." That's the real cost of the wrong tool: teams stop using AI for work it could do well.

Better output on the work that matters - the right tool for long documents, code, analysis, or research, instead of one model's average.

Spend you can see - track spend by tool, or cost per recurring task, so cheaper tools go to routine work and the strongest to the hard jobs.

A deliberate standard, not an accidental one - one default for most work, with named exceptions, chosen on purpose.

Every exception has an approved data path. Each extra tool is another place company data goes, so no exception goes live without one.

Switching stays cheap - when the work lives in records (Pattern 25) and AI assets document themselves (Pattern 12), moving a task to the right tool is a quick change, not a rebuild.

Measure it: for a few recurring tasks, compare results and time across approved tools; track spend by tool; track how often people say "AI couldn't do it" before and after.

Context

When this pattern applies

It applies most to recurring tasks with real stakes: analysis that feeds decisions, code that ships, research that gets cited, content that represents the organization.

It is not an argument against standardizing. One default for most work is sensible for security, cost, and support. The pattern is about naming the exceptions on purpose.

Solution

One default, named exceptions - matched to the job and checked on your own work

Step 1

Name the job, not the tool.

Before choosing, describe the task: what goes in (a 200-page contract, a spreadsheet, a code base), how sensitive that data is, and how much data the job actually needs - which depends on the domain and the risk. Then what comes out (a summary, a number, working code), and what being wrong would cost.

Step 2

Match the job to the right kind of tool.

Start with five quick questions:

Is the work worth doing at all? If not, simplify it or drop it (AI Friction).
Does it follow fixed rules with predictable inputs? Then ordinary automation - a formula, a workflow, a report - is usually the right tool, not AI.
Does it need reasoning or judgment? That's where AI earns its place.
Can you measure and manage the risk - test it, oversee it, trace what it did?
Is the value worth the complexity? If not, start smaller.

Then match the job to a tool's strengths: long documents, code, calculation (write code, don't calculate - Pattern 10), research with sources (a tool that searches and cites), quick drafts. A fast way to start: ask the AI what it's good at and what it isn't - and ask it what other tools do well. A model that knows it can't make images will often point you to good ones. Don't just take a model's word for itself; Step 3 is the check.

Step 3

Test on your own work - with approved tools.

Run the same real task through the approved tools you have, or request a time-boxed pilot for one that isn't approved yet. Compare the output, not the demo. Do this for the few tasks that matter most, not everything.

Step 4

Set one default and name the exceptions.

This is the heart of the pattern. Keep one standard tool for most work. Write down the few tasks where another tool is better, who can use it, and its approved data path - and name who approves a new exception, so the list stays short on purpose.

Step 5

Revisit at renewal and when the tools change.

Re-run Step 3 on your key tasks at contract renewal, when a major new model is released, and when people start saying "AI can't do this" again.

Notes

Standards are usually right - exceptions should be on purpose

Procurement and security push organizations toward one AI standard for good reasons: one contract, one security review, one place data goes. This pattern doesn't argue against that. It argues for naming the few exceptions deliberately, so "AI can't do this" stops being the default answer when the real answer is "this AI can't."

Related. Pattern 10, Models Are Not Good at Math, is the clearest wrong-tool case. Pattern 12, Ghost in the Workflow, records which tool an AI asset depends on. Coming soon: AI Friction (whether AI is the right tool at all), AI Reads, Tools Copy (AI explains, tools extract), and Research Partner, Not Oracle (the right tool for cited research).

Inspired by Scott Baker His Automation and AI Decision Tree - is the work worth doing, does it follow fixed rules, does it need judgment, can the risk be managed, is the value worth the complexity - shaped the five questions in Step 2.