Choose a Tool for Your Task

The best tool for you is the one that helps you finish something you care about. It might be an AI assistant. It might be the spreadsheet you already understand. A convincing demonstration cannot decide that for you, because the demonstration does not include your material, your patience, or the work you do after the answer appears.

Choose one real personal task, try two suitable tools, and keep a usable result alongside a short decision note. You will compare result quality, effort, cost, and data handling. You are choosing how to do your own work; nobody else needs to adopt your choice.

1. Structure: give the comparison a job

Finish this sentence: “When I ___, I need ___, so I can ___.” Choose a task small enough to finish during this lesson, with an output you can actually use afterwards.

Perhaps you want to turn your reading notes into a study plan, organise expenses you are allowed to process, prepare an illustration for your hobby project, or shorten a piece of your own writing. These are optional starting points. Keep your own project if it matters more to you.

Name the input, the action, and the output. For a study plan, the input might be your notes and available study periods; the action is grouping topics and fitting them into those periods; the output is a plan you can follow. You are comparing ways to get from that input to that output, not comparing every feature in two products.

Write three signs that the output would be useful. Make them observable. “Good quality” is too vague; “includes all five topics, fits my available time, and leaves me with an editable checklist” gives you something to inspect. For a visual task, your criteria could concern legibility, composition, and an export size you need. Choose criteria that belong to your task.

Separate a must-have from a preference. A tool that cannot produce a file you can open fails a must-have. A tool whose colours you prefer may simply win a preference. Attractive extras should not compensate for missing the actual job.

Set a modest time and spending limit before exploring. You might allow one working session and use access you already have. A paid subscription is not a prerequisite. If a candidate cannot be tried within your limits, replace it with an accessible alternative rather than guessing how it would perform.

2. Understand: follow the work you already do

Complete a small instance of the task using your current method, or examine a recent instance you still have. Keep the result as your baseline: the ordinary way against which improvement will mean something. If you have no established method, do the task directly once with a familiar editor, notebook, or other appropriate tool.

Notice where the effort really goes. Is it finding relevant information, arranging it, correcting errors, or moving the result into another application? A tool that generates text quickly may be irrelevant if most of your time is spent repairing a table after copying it.

Record roughly how long the work takes and what still bothers you. Estimates are useful when labelled as estimates. You do not need a laboratory benchmark; you need enough evidence to avoid mistaking a fast first answer for a fast finished task.

Understand the candidates at the same practical level. What do you supply? What does the tool do with it? Where does the output go? A language model generates responses; a product around it may add document upload, search, storage, or export. An agent can take actions through tools. A skill is a reusable set of instructions or a procedure for a particular job. Those additions help only when your task needs them.

Two applications using the same underlying model may still give different experiences because their editing, input limits, and exports differ. Conversely, two model names inside one chat interface do not tell you which complete workflow suits you. Record the product and model if visible; do not invent a model identity when the interface does not disclose it.

Know what you are handing over

Use material you are entitled to process in the chosen service. Your own project can stay your own project without uploading every private detail. Work on an appropriate excerpt, keep restricted portions in an already suitable tool, or select a candidate that supports the required data handling. If the essential material cannot be used in a candidate, that candidate is unsuitable for this task.

Before uploading, find the provider's explanation of storage, training use, deletion, and sharing for your actual account or plan. Record a link and the date you read it. Unknown is an honest answer, but it is not permission to submit material whose handling matters.

Distinguish the questions. “Not used for training” does not mean “not stored.” OpenAI's Data Controls FAQ, checked on 9 September 2026, says turning off model improvement leaves conversations in chat history while excluding them from training. That is an example of why a single privacy switch does not answer every data question; it is not a recommendation to use ChatGPT.

Likewise, a desktop application may send requests to a cloud provider. Installing something locally does not establish that processing stays on your device. Check the actual processing route rather than inferring it from where the window opens.

3. Choose LLMs, Agents, skills, tools

Find two suitable tools that can attempt your chosen task. Your incumbent can be one of the two, and either candidate can be non-AI. If you choose two new tools, retain the current method as a lightweight baseline rather than organising a third elaborate trial.

The tools catalogue is a discovery aid: search by the work you want to do and follow promising entries to official documentation. On 9 September 2026, the public catalogue API reported 145 entries, all marked unverified. Inclusion, tags, and summaries are leads, not verified endorsements or evidence that a product currently meets your needs.

Stop browsing once you have two plausible candidates. For each, check that you can access it, supply the needed input, obtain the needed output, and use it under appropriate terms. Read the current plan details for features you actually need. A free tier may have limits; an existing paid tool may already cover the work. Record the plan and check date rather than copying an undated price from a comparison article.

Choose the least complicated configuration that does the job. A chat assistant may be enough to reorganise notes. A spreadsheet may be better for a calculation. An agent is relevant when you need actions across steps, but extra permissions and setup become part of the effort you are evaluating. Do not add a skill merely because one is available.

Copy this note into a document or notebook. Fill the brief before you start; complete the evidence and decision afterwards. A plain text file is sufficient.

MY TOOL CHOICE — [date]
Task and why it matters:
Input / action / usable output:
Three success criteria:
Must-haves:
Time limit / spending limit:
Current method and baseline result:
Baseline time: [observed or estimated]

Candidate A: [product, model if shown, plan, date]
Candidate B: [product, model if shown, plan, date]
For EACH candidate record:
- Official terms/data-handling link and date read:
- Material I can use here; unresolved restrictions:
- Instructions, settings and input used:
- Result location and criteria met or missed:
- Important corrections and effort to make them:
- Setup minutes / doing minutes / review-and-export minutes:
- Actual trial spending; expected repeat-use cost and assumptions:
- Can I operate it comfortably and reopen the output elsewhere?

Decision: [A / B / current method / neither yet]
Why this wins for my task:
Known limitation and what I will still check myself:
Next real use; reason to reconsider later:

4. Build: make a result and an evidence-based choice

Here, building means completing your task with the candidates and creating a decision you can reuse. You do not need to build software.

First, give both tools the same job

Use the same source material and the same success criteria. Start fresh in each tool where possible so unrelated chat history does not supply hidden context. Give each the information it needs, using its normal interface. Fair comparison means equivalent work, not forcing a spreadsheet to accept a chat prompt.

For an assistant, adapt this brief:

Help me complete [my task] using [the material supplied].
I will use the result for [purpose].
It must [three success criteria] and be usable as [output format].
Respect these constraints: [time, length, exclusions or other needs].
Ask if essential information is missing. Make uncertainty visible
rather than inventing facts or commitments.

Keep the first output. Note your starting instructions and relevant settings so you can understand the difference later. Do not paste one candidate's answer into the other unless improving that answer is itself your chosen task; doing so would change the comparison.

Next, finish rather than merely generate

Inspect each result against your criteria. Check factual statements against your actual source material, totals with an appropriate calculation, or layout at the size you intend to use. Verification should serve your project: you are deciding whether this particular result is usable, not completing an unrelated synthetic exercise.

Make a focused correction where needed. Give both candidates a similar opportunity within your time limit, and record the repair effort. If one needs repeated rewording while the other works directly, that difference matters. If a result cannot be made usable before the limit, keep the failed result and say what prevented completion.

Now carry the output to its destination. Save, copy, or export it, then reopen it in the place where you will use it. Check that important structure, links, numbers, or image details survived. A nice preview with an unusable export is not a finished task.

Also notice whether you can operate the tool comfortably. Try the main controls with your keyboard and check readability at your usual zoom. If your task includes audio or video, consider captions or transcripts you need. W3C's Easy Checks offers starting points; passing a few checks is not proof of full accessibility.

Then, compare the whole experience

For quality, write which criteria each result met and identify any important mistake. For effort, include setup, interaction, correction, and export rather than only generation time. Keep one-off learning effort separate from work likely to recur.

For cost, distinguish what you actually spent during the trial from what repeating the task would cost. Note plan limits, required upgrades, or usage charges that apply to your likely frequency. “No additional charge within my existing plan” is more useful than “free” when you already pay for access. Unchecked costs remain unknown; do not replace them with a plausible number.

For data handling, state whether the documented conditions fit this input and purpose. A tool can win on output quality and still be inappropriate for the material. Treat essential constraints as constraints, not points that a pretty result can cancel out.

An illustrative choice

Imagine you are turning your own reading notes into a plan for next week. You compare a familiar spreadsheet with an accessible assistant. In this illustration, the assistant groups related topics helpfully but schedules more study time than you have. The spreadsheet is less expressive but makes your available minutes easy to inspect.

You might choose the spreadsheet because the plan is ready to use with less correction. Alternatively, if grouping topics is your main difficulty and fixing the schedule is quick, the assistant might be worth keeping. These are possible outcomes, not measured results. Use your own evidence; you do not have to choose this task or reach either conclusion.

What to keep, and what comes next

Keep the usable output, the input or a reference to it, and your completed decision note. Finish this sentence: “For this task, I will use ___ because ___; I will still check ___.” If neither candidate helps, retain the current method and name the unmet need. That is a successful selection decision.

A small trial cannot establish a universal winner, reliability on every input, or future pricing. Model responses and product features can change. Revisit your choice when the task, relevant terms, or observed performance changes, rather than restarting the search every time a new product appears.

You are ready to leave when you have tried both tools on your task, inspected and used the result, and can explain the choice in your own words. When other people will use or rely on the workflow, continue with T16-L02, Choose Tools Your Team Can Use, where shared access, handoffs, and responsibility become part of the decision.

Source and editorial notes

All following sources were fetched on 9 September 2026. Documentation checks establish what those pages said; they are not product trials or classroom validation.

• Payload level definitions (opens in a new tab): L01 is User, responsibility “Only you”, with a 1,500–3,000-word range. The manuscript follows T06-L01's Structure, Understand, Choose, Build teaching sequence.
• Public tools API (opens in a new tab): 145 total entries; a separate verificationStatus=unverified filter returned 145. This is a dated catalogue-state observation, not verification of the listed products.
• OpenAI: Data Controls FAQ (opens in a new tab): primary provider documentation supporting the distinction between training controls and retained history. It does not establish another provider's policies or your institution's permission to use a service.
• W3C WAI: Easy Checks (opens in a new tab): primary accessibility guidance on checks including keyboard focus, zoom, and captions. The fetched page is labelled a draft update and explicitly says these checks are not exhaustive.

Original drafting: Astra / OpenAI (openai/gpt-6-astra). No vendor prices, learner results, or product-performance measurements were supplied or invented. Draft only; not published.