02 · Choosing the Right AI Tool for a Task¶
Once you know the categories from Module 1, the next skill is choosing within and across them for a specific task in front of you. Most people default to whichever tool they opened last, regardless of whether it's actually well-suited to the job. This module gives you a decision framework you can run in under two minutes, before you've invested time in a particular tool.
1. The four-question framework¶
Ask these in order. Each answer narrows the field before you look at any specific product.
| Question | What it determines |
|---|---|
| 1. What category of output do I need? | Text, code, image, video/audio, a data answer, or an automated action — points to the category from Module 1 |
| 2. How high are the stakes if the output is wrong? | Low stakes (draft, brainstorm) tolerates a fast general tool; high stakes (published, financial, medical, legal) demands verification and often a specialized or human-reviewed tool |
| 3. Does this need to happen once, or repeatedly? | One-off tasks favor whatever tool is already open; recurring tasks justify learning a specialized tool or building an automation |
| 4. What context does the tool need to do this well? | Company data, a codebase, a long document, real-time information — determines whether you need a tool with integrations, large context handling, or live search |
2. A worked scoring rubric¶
For a recurring or higher-stakes task, it's worth scoring 2-3 candidate tools explicitly rather than picking on vibes. Use a simple 1-5 scale per criterion, weighted by what matters for this task.
| Criterion | Weight (example) | Tool A | Tool B |
|---|---|---|---|
| Output quality for this task type | 3x | ||
| Ease of use / learning curve | 1x | ||
| Cost fit for expected usage volume | 2x | ||
| Integration with tools you already use | 2x | ||
| Data handling / privacy fit (Module 6, Level 2) | 2x | ||
| Reliability / uptime for recurring use | 1x |
Multiply each score by its weight and sum. The point isn't precision to two decimal places — it's forcing you to name what actually matters for this task before you compare tools, so you don't retroactively justify whichever one you already like.
3. Stakes determine how much verification you build in¶
The single most common mistake in tool selection isn't picking the wrong tool — it's using the right tool without matching verification effort to the stakes.
| Stakes level | Example | Minimum verification habit |
|---|---|---|
| Low | Brainstorming, first drafts, casual questions | Skim for obvious errors; use as a starting point only |
| Medium | Internal documents, draft code, content you'll edit further | Read fully; spot-check any factual claims or logic |
| High | Anything published externally, sent to a client, or acted on financially/legally | Independent verification of every factual claim; human review before it goes out (see Module 9) |
A tool doesn't become "safe" because it's well-known or expensive — the verification effort scales with what happens if the output is wrong, not with which product produced it.
4. When not to use an AI tool at all¶
Part of choosing well is recognizing when the answer is "don't." Useful signals:
| Signal | Why it argues against an AI tool |
|---|---|
| The task requires information the tool has no way to access or verify | Output will be guessed, not known, even if it sounds confident |
| A wrong answer has legal, medical, financial, or safety consequences you can't independently check | Verification cost may exceed the time saved |
| The task is faster to just do directly | E.g., a two-line email you already know exactly how to write |
| The organization's or client's rules prohibit it for this data type | Policy compliance overrides convenience (Module 6, Level 2) |
Worked example¶
A small nonprofit's program coordinator needs three things this week: a donor thank-you email, a first draft of a grant application's needs statement, and a chart summarizing last quarter's program attendance from a spreadsheet.
- Thank-you email: Category = writing. Stakes = low-medium (goes to a real donor, but she'll read and personalize it). Repeats = yes, dozens per month. → Worth a specialized writing assistant with a saved template, since it recurs.
- Grant needs statement: Category = writing/research. Stakes = high (a factual overstatement could hurt the nonprofit's credibility with a funder). → Use a general assistant for structure and phrasing, but every statistic or claim gets independently verified against the source data before it's included — no exception for high-stakes external documents.
- Attendance chart: Category = data analysis. Stakes = low (internal, and she can eyeball whether the chart matches the numbers she already knows). Repeats = quarterly. → A data-analysis assistant is a fine fit; a quick sanity check against two or three known data points before trusting the chart.
How It Actually Works¶
The four-question framework works because it maps onto real technical differences in how these systems are built and deployed, not just marketing positioning. "How high are the stakes" tracks directly to a property called sampling temperature and post-training tuning: many products let a task run at a lower "temperature," which narrows the model's next-token probability distribution toward the single most likely continuation — more predictable, less creative, and (not coincidentally) generally more reliable for factual or high-stakes work. A "creative writing" mode and a "precise/factual" mode in the same product are frequently the same underlying model with this one parameter changed, plus a different system prompt.
"Does it need to know about you/your data" tracks to context window and retrieval. A model has no persistent memory of your files by default — it only "knows" what's inside its fixed-size context window for that conversation, built from your prompt plus (if the tool supports it) chunks of your documents that a separate retrieval step pulled in because they matched your query. A tool that seems to "know your codebase" or "know your documents" is running retrieval-augmented generation: search first, then generation grounded in what was found — not a model that was actually trained on your private files.
"Does it need to take an action, not just produce text" tracks to whether the product wires the model up to function calling / tool use: the model doesn't book a meeting or query a database itself — it emits a structured request (a JSON-shaped intent) that the application code recognizes, executes, and feeds the result back into the model's next turn. A tool that "only chats" versus one that "does things" is usually the same class of model; the difference is whether the surrounding application exposes it a menu of callable actions.
Exercise¶
Take three tasks from your Module 1 list. For each, run the four-question framework in section 1 and write down your answers. For the one with the highest stakes, fill out the scoring rubric in section 2 comparing two plausible tool choices (they can be types of tools if you don't know specific products yet), and state which verification tier from section 3 it requires.