Context Turns a Request into a Task

A useful word gives an idea a handle. A useful request gives the AI something to do with it. The next step is learning to notice what a task has—and has not—made clear.

Imagine a teacher preparing a short lesson on climate change. She asks an AI, “Help me with a lesson about climate change.” That request is vague: it names a subject but leaves the task itself open. The AI might produce a lecture, a quiz, a classroom activity, or a page of background notes. None is necessarily wrong. The teacher has not yet said what “help” means.

Now consider a more specific request: “Create a 30-minute lesson for my students on the causes of climate change.” This sounds much clearer. But suppose the teacher teaches eight-year-olds, and the AI assumes older students. The task is no longer vague about its basic shape; it is underspecified. Important details remain unstated, and the system may fill them in with plausible guesses. A request can be clear in its wording and still leave out information that determines whether the answer will be useful.

A vague request leaves the destination unclear. An underspecified request points toward a destination but omits information needed to get there well. The distinction helps identify what to add: first define the task, then supply the details that could materially change its result.

A stronger brief might read: “Create a 30-minute introductory lesson for eight-year-olds explaining two human causes of climate change. Use plain language, one simple analogy, and a five-minute activity students can do in pairs. Keep the science accurate without introducing technical detail they cannot yet use. Finish with three questions I can ask to check understanding.”

This request names the audience, the desired outcome, the format, and the scope. It also signals a trade-off: keep the science accurate, but avoid detail that would overwhelm beginners. Those choices help shape an answer the teacher can assess against the lesson’s particular needs.

More detail is not automatically better. Adding the classroom’s wall color, the teacher’s favorite stationery, and every lesson taught that month would make the request longer without necessarily making it more useful. Context earns its place when it changes what a good answer should look like.

A practical test is to ask: If the AI made a reasonable guess here, could that guess materially change the result? If yes, state the detail or invite the system to ask before proceeding. Audience, purpose, length, available materials, and standards of success often matter. Decorative background often does not.

You do not need to write a miniature contract for every conversation. You do need to notice the difference between a missing detail that is harmless and one that quietly determines the answer. A clear task is not one that says everything. It is one that says enough for the AI to aim—and for you to assess whether the response fits the lesson you need.

Even when a request is clear, an answer can be wrong. If you ask for a “short announcement” without saying who will read it, the system may make a poor guess about tone. More context can help. But if you ask a precise question about a recent regulation, the answer may still be outdated, incomplete, or simply invented. Better instructions reduce some avoidable errors; they do not turn an AI model into an authority.

The difficulty is that fluent language can disguise the difference. A model may deliver a sound explanation in the same polished voice whether it is recalling a well-established fact, making a plausible inference, or filling a gap with something that merely fits the pattern. Confidence in the prose is not a reliable measure of confidence in the claim. The answer’s smoothness tells you about its style, not its warrant.

Imagine asking for the key findings of a report you have not supplied. The system might infer which report you mean—or produce a convincing summary of a different one. That is partly a specification problem: identifying the report or providing the source would help. But even with the report attached, the model could misread a table, overlook a qualification, or state a conclusion more strongly than the authors do. Context helps the system work on the right material; it does not guarantee that it will handle that material correctly.

It helps to separate three questions. Is the task clear? If not, clarify the purpose, scope, or missing details. Does the system have a sound basis for answering? It may lack current information, access to a relevant source, or the specialized knowledge the task requires. Does the answer actually follow from that basis? Even a relevant source can be misquoted or misinterpreted. These are different sources of error. Ambiguity can prompt a poor guess; missing or outdated knowledge can leave the answer unsupported. The system can also generate factually inaccurate material ^[1] or interpret material incorrectly. Each question calls for a different response: clarify, supply or seek evidence, then check the reasoning and result.

You can make uncertainty easier to see by asking for it explicitly. For a consequential question, try: “State the assumptions you are making. Separate what the source says from your interpretation. Identify what you cannot establish, and cite the passages or sources that support the main claims.” If the question concerns current information, ask the system to confirm dates and provide links to primary sources where available. A citation is a trail to inspect, not a certificate of truth: sources can be irrelevant, misrepresented, or nonexistent, so open them and check.

These requests do not magically make a model more reliable. They change the shape of the answer, giving you more opportunities to spot a weak foundation. Nor will every uncertainty announce itself. A system can be wrong without flagging doubt, and it can sound cautious while still being mistaken. Treat expressions such as “I’m not sure” as useful signals, not calibrated measurements.

For low-stakes brainstorming, an imperfect answer may be a reasonable starting point. For a medical decision, a legal interpretation, a financial commitment, or a claim you plan to publish, the cost of error is different. Bring in authoritative sources or qualified expertise, and verify the details that matter. The right level of checking depends not only on how plausible an answer sounds, but on what happens if it is wrong.

Clear instructions can prevent a system from having to guess what you mean. They cannot prevent every failure in what it knows, retrieves, or generates. The practical habit is therefore not to demand certainty, but to ask what the answer rests on—and inspect that foundation before you build on it.

The distinction between a useful brief and a reliable conclusion matters most when a decision depends on the answer. Put the chapter’s guidance to work with a simple sequence: specify, inspect, verify. The higher the stakes and uncertainty, the more carefully each step deserves attention.

Imagine a business owner asking an AI to help reduce cancellations from a monthly meal-planning service. “How can I improve retention?” may produce familiar suggestions: offer discounts, send more emails, reward loyalty. But the owner first needs to know whether the problem is what it appears to be. The following figures and responses are illustrative.

Specify

The owner writes:

We recorded 40 cancellations in April and 60 in May. We raised our monthly price on May 1, and customers can cancel at any time. I want to understand what changed before offering a discount. Separate observations from possible explanations. Identify the missing data needed to compare cancellation rates and investigate causes. Do not assume that the price increase caused the change.

“Cancellations rose after the price increase” is an observation. “The higher price caused the increase” is a hypothesis. Keeping them apart leaves room for other explanations, such as a service change or a different mix of customers. The brief gives the AI a focused role: help design an investigation.

Inspect

Suppose the response begins:

Your cancellation rate rose by 50 percent after the price increase, suggesting price sensitivity. A targeted discount could help restore retention.

The sentence sounds useful. But rate is doing work the evidence cannot support. The number of cancellations rose from 40 to 60, an increase of 50 percent. A cancellation rate also needs a denominator: how many subscribers were at risk of cancelling? The response then moves from an unexplained change to a proposed remedy.

The owner follows up:

You have compared cancellation counts, not rates. What subscriber totals and definitions do we need for a fair comparison? Keep the price explanation as a hypothesis and hold off on recommending discounts.

This is close reading with a consequence. Knowing the difference between a count and a rate changes the next question—and may prevent the owner from paying to solve the wrong problem.

Verify

The owner checks the subscription records. For a simple comparison, they count only subscribers active at the start of each month and cancellations among those subscribers during that month. Suppose the records show 800 subscribers at the start of April, of whom 40 cancelled, and 1,200 at the start of May, of whom 60 cancelled. Both rates are 5 percent: 40 divided by 800, and 60 divided by 1,200.

The owner checks that the figures exclude new subscribers who joined during each month and use the same cancellation definition. These details make the calculation comparable. They do not establish that the price change had no effect. The customer mix may have changed, and a stable overall rate could conceal different patterns among newer and longer-standing customers.

The useful conclusion is narrower: cancellations increased in number, but the measured monthly rate did not. Before offering a discount, the owner can compare customer groups and examine cancellation reasons. The AI’s answer has led to a better investigation because the owner corrected its framing and checked the underlying records.

Specifying made the task clear. Inspecting caught an unsupported claim. Verifying changed what the owner could reasonably conclude. Asking the model to reconsider was part of the process; checking the records supplied the evidence.