Open a familiar text editor or word processor. Your first useful result will be something you can keep: a checklist, study plan, edited paragraph, or another small output for your own project. Then try one suitable alternative and decide whether it helps enough to keep. The alternative may be an AI assistant; your familiar method is a real candidate too.
The best tool is the one that helps you finish work you care about. A convincing demonstration cannot decide that for you: it leaves out your material, your patience, and the repair after the answer appears. Here you will compare finished results, not impressive first responses.
Our optional worked example turns an ordinary preparation procedure into an editable checklist for three paper reading packs. You will do the same transformation manually and with one assistant, using identical source text. Keep your own task if it matters more to you. You need an editor and suitable existing assistant access for the example, not an API, timer application, purchase, or software build.
Learning objectives
- Define a small personal task with observable success criteria and firm limits.
- Compare two suitable ways of doing that same task, including an incumbent or manual method.
- Finish and reopen a useful output, accounting for mistakes, repair, export, cost and data handling.
- Explain an informed choice, including keeping the incumbent or declining both alternatives.
Core concepts
1. Structure: give the comparison a job
Finish this sentence: “When I ___, I need ___, so I can ___.” Name the input, action and output. For the example: “When I prepare reading packs, I need an editable checklist from the supplied procedure, so I can follow the preparation without losing its conditions.” The input is the procedure; the action is reformatting it faithfully; the output is a checklist you can reopen in your ordinary editor.
Your task could instead be organising permitted expenses, shortening your own writing, preparing a hobby illustration, or grouping reading notes into a study plan. Compare ways to complete that job, not every feature in two products.
Write three observable signs of usefulness. “Good quality” is too vague. For the checklist, use these:
- All eight source steps remain identifiable and in order, with quantities, conditions and stop rules intact.
- Each step has an empty checkbox; the checklist adds no instructions or claims of completed work.
- The saved result is readable and editable in your normal destination, with the source title and version attached.
Separate must-haves from preferences. Fidelity to the procedure is a must-have. A preferred heading style is a preference. Attractive extras cannot compensate for a missing stop condition. For an illustration, your must-haves might instead include legible text and the export size you need.
Set a modest working-session limit and a spending ceiling before exploring. Use access you already have if possible. If a candidate cannot be tried within those limits, choose an accessible alternative rather than buying access or guessing its performance. A written ceiling is your stop rule, not an automatically enforced spending cap.
2. Understand: follow the work you already do
Complete a small instance with your current method. If you have no established method, use an editor or notebook directly once. Keep this baseline result. Notice where effort goes: understanding the input, arranging it, correcting mistakes, or moving it into another application. Fast generation is irrelevant when copying and repair consume the saving.
Record rough effort, labelling estimates as estimates. You need a practical comparison, not a laboratory benchmark. Doing the manual task first also teaches you the source, which can make reviewing the assistant easier. Record that order; do not present one small personal trial as an unbiased ranking.
A language model generates responses. The product around it may provide uploads, search, storage and export. An agent can take actions through tools. A skill supplies reusable instructions or a procedure. These additions help only when the task needs them. Turning eight supplied steps into text needs none of the assistant's optional file-writing or external-action permissions.
Two products using the same model can differ in editing and export. Two model names inside one interface do not compare complete workflows. Record the product, provider, model if shown, plan and date. If the model is undisclosed, write “not disclosed”; never infer it from a fluent answer.
Know what you are handing over
Before submitting your own material, establish that you may use it with the chosen service. Work on a permitted excerpt, leave restricted portions in an appropriate incumbent, or use the fully synthetic source below. If essential material cannot be processed in a candidate, that candidate is unsuitable for this task.
Find the provider's documentation for storage, training use, deletion and sharing under your actual account or plan. Record the link and date. Unknown is honest, but it is not permission to submit material whose handling matters. A desktop window does not establish local processing; it may send requests to a cloud provider.
“Not used for training” does not mean “not stored.” OpenAI's Data Controls FAQ (opens in a new tab), read on 11 September 2026, says turning off model improvement leaves conversations in chat history while excluding them from training. This preserves the distinction taught in the original 9 September edition; it is not an endorsement of ChatGPT or a statement about other providers.
If you later share the result, follow any applicable course or workplace disclosure rule. Describe the actual contribution: “Assistant reformatted the supplied procedure; I compared every step with the source and corrected the result,” only if you did those things. Do not claim the assistant approved the procedure or performed the preparation.
3. Choose LLMs, Agents, skills, tools
Choose two suitable candidates and stop browsing. In the example, A is your familiar editor used manually; B is one accessible assistant, followed by the same editor for the final saved output. A is a complete option, not a deliberately weak opponent. If you choose two new tools for another task, retain your current method as a lightweight baseline rather than staging a third elaborate trial.
The tools catalogue is a discovery aid. Follow promising entries to official documentation and check actual access, input limits, output formats and relevant plan terms. Inclusion is not an endorsement. The optional app-owner-new-protocol-to-bench-checklist concept in App examples supplies only this design slice: turn an approved procedure into a checklist while preserving its meaning. A catalogue brief is not executable software, a download, or evidence of a successful trial. This lesson uses ordinary paper preparation, not a wet-lab procedure.
Choose the least complicated configuration that works. A spreadsheet may suit calculations better than chat. An agent's setup and extra permissions count as costs when actions really are needed. Do not add a skill simply because one is available.
Check repeat-use cost, not just today's access. An existing paid plan may already cover the work; a free tier may have limits. Record current plan details and the check date. “No additional charge within my existing plan” is more informative than “free.” Unchecked prices remain unknown.
Runnable exercise
4. Build: make a result and an evidence-based choice
Here, building means completing the task and keeping a decision you can reuse. The exercise runs through an editor and an assistant's ordinary chat interface. No code execution is required.
Prepare the same input for both candidates
In your editor, create a new document named source-procedure.txt. Paste the following complete synthetic source. Leave this document unchanged throughout the comparison.
Reading-pack preparation — synthetic procedure v1
Purpose: prepare three paper packs for a fictional reading session.
Use only blank paper, ordinary folders and paper clips.
S1. Gather three empty folders, six blank cards and three paper clips.
If any item is missing, stop before S2 and record the missing items.
Do not substitute materials.
S2. Label the folders A, B and C, one label per folder.
S3. Label the six blank cards A1, A2, B1, B2, C1 and C2,
one label per card.
S4. Place cards A1 and A2 in folder A, B1 and B2 in folder B,
and C1 and C2 in folder C, with card 1 above card 2 in each folder.
S5. If a folder has an inside pocket, place its pair in that pocket.
Otherwise, leave its pair between the covers.
Keep card 1 above card 2 in either case.
S6. Place one paper clip on the front cover of each folder.
Do not clip the cards together.
S7. Check every folder for its matching two cards in the stated order
and one paper clip on the front cover. If a check fails, correct
that folder and repeat S7 before continuing.
S8. Stack the folders A on top, then B, then C. Record "ready" only
after S7 passes for all three folders. Otherwise leave the status
"not ready" and record the unresolved problem.
The task is to write the checklist, not to claim packs were prepared. You can try it with ordinary supplies you already have, but physical assembly and purchases are unnecessary. For your own task, substitute one small permitted source and freeze that same version for both candidates.
Make the manual baseline
Create manual-first.txt in the same editor. Read the source and turn each numbered step into an empty-checkbox instruction, keeping S1–S8. Include the title and version. Do not copy the worked answer below: producing the baseline yourself reveals the effort the alternative must improve.
Keep that first version. Review it against the source and save any corrections separately as manual-final.txt. An unchecked box means “not yet performed”; writing or reviewing an instruction does not complete it. Record what you corrected, including any manual omission. The incumbent deserves the same scrutiny as the assistant.
Give one assistant the equivalent job
Open a fresh conversation in your chosen assistant's browser or desktop chat interface. Paste this request, followed by the complete contents of source-procedure.txt. Use the source, not your manual answer. No connector or upload permission is needed for this pasted synthetic text.
Turn the supplied Reading-pack preparation — synthetic procedure v1
into a plain-text checklist I can edit and use later.
Keep the title/version and all eight source IDs S1–S8 in order.
Give each step one empty [ ] checkbox. Preserve all quantities,
labels, ordering, conditions, alternatives, prohibitions, stop rules
and repeat checks. Keep conditional instructions within their step.
Do not simplify away conditions, add preparation advice, or mark
anything completed. Do not claim any physical work was performed.
If essential information is missing, ask rather than inventing it.
Return the checklist only; no table is needed.
SOURCE:
[Paste the entire unchanged source procedure here.]
Copy the first response into a new assistant-first.txt document. Retain the prompt and product details in your decision note. For another task, replace the checklist-specific requirements with your own purpose, three criteria, output format and constraints.
Finish rather than merely generate
Compare both outputs to the source line by line. Eight boxes alone do not establish fidelity: S5 must preserve both storage branches, S6 must distinguish the front cover from the cards, and S7 must require another check after repair.
This is an authored target result, not an observed assistant response. Consult it after making the two first versions:
Reading-pack preparation — synthetic procedure v1
Checklist; no preparation steps have been marked completed.
[ ] S1. Gather three empty folders, six blank cards and three paper
clips. If any item is missing, stop before S2 and record the
missing items. Do not substitute materials.
[ ] S2. Label the folders A, B and C, one label per folder.
[ ] S3. Label the six blank cards A1, A2, B1, B2, C1 and C2,
one label per card.
[ ] S4. Place A1 and A2 in A, B1 and B2 in B, and C1 and C2 in C,
with card 1 above card 2 in each folder.
[ ] S5. If a folder has an inside pocket, place its pair in it.
Otherwise, leave its pair between the covers. Keep card 1
above card 2 in either case.
[ ] S6. Place one paper clip on the front cover of each folder.
Do not clip the cards together.
[ ] S7. Check every folder for its matching two cards in the stated
order and one paper clip on the front cover. If a check fails,
correct that folder and repeat S7 before continuing.
[ ] S8. Stack the folders A on top, then B, then C. Record "ready"
only after S7 passes for all three folders. Otherwise leave
the status "not ready" and record the unresolved problem.
A polished shortcut can change the task. Consider this deliberately faulty teaching fragment:
[ ] S5. Put each pair in its folder's pocket.
[ ] S6. Clip each pair of cards together.
S5 loses the no-pocket alternative and card order; S6 contradicts the source. The repair is not “make it clearer.” Point to the exact loss in the assistant conversation:
Restore S5's no-pocket alternative and card 1 above card 2 in both
cases. Restore S6: one paper clip on each front cover; do not clip
the cards together. Return the complete checklist, preserving all
other source requirements and empty checkboxes. Do not add steps.
Use that request only if those errors occur. For your actual result, name the actual defect. Review the whole revision because repairing one line can change another. Save the reviewed version as assistant-final.txt. If direct editing is quicker, repair it in your editor and attribute that work to yourself. Give both candidates a comparable repair opportunity within your limit; repeated prompting counts as effort. If the limit expires, preserve the unfinished result and keep the usable manual version.
Reopen each final file in the destination where you will use it. Confirm that IDs, line wrapping, conditions and empty checkboxes survived copying. Try the main interface controls with your keyboard and read at your normal zoom. For audio or video tasks, include the captions or transcripts you need. W3C's Easy Checks (opens in a new tab) provides starting points, not proof of full accessibility.
Compare the whole experience and choose
Create a new tool-choice.txt note. Keep actual observations separate from estimates and from the authored example. Do not borrow invented timings to make the note look finished.
MY TOOL CHOICE — [date]
Task and purpose:
Input/version / action / useful output:
Three success criteria; must-haves versus preferences:
Working-session limit / spending ceiling:
Current method; baseline result location:
Trial order and prior familiarity:
For EACH candidate A and B:
Product / provider / model if shown / plan / date:
Official terms and data-handling links / date read:
Permitted material; unresolved restrictions:
Instructions, settings and exact input used:
First and final output locations:
Criteria met or missed; specific remaining defects:
Repairs made, by whom, and number of attempts:
Setup / doing / review-and-repair / export-and-reopen effort:
Which effort figures are observed, estimated or unknown:
One-off learning effort versus likely repeat effort:
Actual additional trial spending:
Expected repeat-use cost, limits and assumptions:
Comfort/accessibility; ability to reopen outside the product:
Switching burden and route back to current method:
Decision: [A / B / current method / neither yet]
Why this wins for this task:
Known limitation; what I will still check myself:
Disclosure needed if shared; actual contribution wording:
Next real use; reason to reconsider:
For quality, name criteria met and important mistakes. For effort, include setup, interaction, review, repair and export. Separate one-off learning from recurring work. For cost, distinguish additional trial spending from expected repeat-use charges. For data handling, decide whether the documented conditions fit this material and purpose. Essential constraints are not points a pretty answer can cancel out.
Switching also has a cost: learning controls, transferring files, losing a familiar template, or depending on a new account. Keep the source and plain-text final outside the assistant so you can resume manually if access or terms change. If copying loses checkboxes, ordinary [ ] text in your editor is a sufficient recovery.
In a possible outcome, both checklists become faithful, but repairing the assistant's lost condition takes more effort than making the manual checklist. Keeping the editor is a sensible choice. In another, the assistant saves enough formatting effort after review to justify using it for the next similar task. These are possible decisions, not measured results. Your observation may support either—or neither. Do not replace your incumbent just to make the trial feel successful.
For the original study-plan alternative, the same distinction holds: an assistant may group topics helpfully yet schedule more study time than you have; a familiar spreadsheet may expose that limit more clearly. Choose according to your actual difficulty and correction burden, not the tool category.
Exit check
Keep one comparison packet: the unchanged input, both first outputs, reviewed final outputs where usable, and tool-choice.txt. It passes when both candidates attempted the same permitted task, you inspected and reopened the result, the note identifies actual repair effort and limits, and you can explain the choice. A failed candidate does not fail the selection exercise; describe its defect and retain a usable incumbent output. If access prevented the second attempt, label the comparison incomplete rather than inventing evidence.
For the sample checklist, inspect S1–S8 and mentally follow three cases: missing supplies stops before S2; no inside pocket follows S5's alternative without changing card order; a failed S7 check requires correction and another S7 before proceeding. No result may declare physical completion. These checks support a useful checklist, not replace it.
Finish: “For this task, I will use ___ because ___; I will still check ___.” If neither alternative helps, retain the current method and name the unmet need. When others will rely on the workflow, continue with T16-L02, Choose Tools Your Team Can Use.
Source notes
- Published baseline (opens in a new tab): the complete original manuscript was read from
editorial/drafts/T16-L01.md; the completion brief supplies the exact public-body hash. The public page was not re-fetched in this authoring session. - Original drafting: Astra / OpenAI (
openai/gpt-6-astra), 9 September 2026. Retained contributions include personal task choice, the Structure–Understand–Choose–Build progression, manual baselines, tool/model distinctions, permission, cost, accessibility, export, recovery and informed non-adoption. No Sol or Luna contribution is recorded in this source manuscript. - The original edition records 9 September checks of Payload level definitions (opens in a new tab) and the tools API (opens in a new tab), including a then-current count of 145 unverified entries. These are historical observations, not current catalogue claims; those APIs were not re-fetched here.
- OpenAI Data Controls FAQ (opens in a new tab): read on 11 September 2026 for the training/history distinction. It does not establish institutional permission or another provider's policy.
- W3C WAI Easy Checks (opens in a new tab): overview read on 11 September 2026, labelled a draft update; it expressly limits these checks to an initial, non-exhaustive review. Linked subpages and video were not reviewed.
- The assigned completion brief maps the optional checklist design slice. The reading-pack source, target checklist and deliberately faulty fragment are newly authored synthetic teaching material, not a research protocol, product transcript or observed trial.
Unknowns and limitations
No assistant comparison, physical preparation, export trial, screenshot capture or classroom outcome was observed during authoring. Learners must supply their own results; no performance winner or numerical saving is established. Product access, account terms and repeat-use costs depend on the chosen candidate and remain to be checked. One small trial cannot prove universal reliability or future pricing. Reconsider when the task, terms or observed performance changes.
This ordinary paper-preparation example does not establish suitability for laboratory, clinical or other safety-critical procedures. Preserving text is not approval of its underlying instructions.
How this book was made
Coordinator editorial update, 11 September 2026: The independent Terra reader accepted this revision. The account below records authoring-stage work; learner execution and classroom outcomes remain unobserved.
The original 9 September manuscript was written by Astra / OpenAI (openai/gpt-6-astra). This example-led revision was authored in one fresh OpenCode session by Astra / OpenAI, exposed model openai/gpt-6-astra, on 11 September 2026. The author read the full original, the completion brief, style, learnings and template, consulted the two primary-source pages above, and wrote this one manuscript with apply_patch. No other agents participated.
The production lesson is the same as the tool-choice lesson: preserve the useful incumbent before adding an alternative. Connecting the source, manual result, assistant request and concrete repair makes the choice teachable without inventing trial evidence. Coordinator verification and independent acceptance are pending; no tests, validation or browser checks ran in this authoring session. Publication, token totals, cache/reasoning counters and billing are not established here.