The request that made sense to you
Somewhere this week you will type a short request to an AI and be mildly let down by the answer. It will be fluent and organized and slightly beside the point. The usual response is to try again with a few more words, or to decide that the tool is not very good at this kind of thing, and both responses leave the actual cause where it was.
The cause is rarely in the tool. It is in the request, and specifically in everything that made the request make sense to you and never reached the page. You know who the email is for. You know that the last version failed because the client dislikes bullet points. You know which of the three obvious approaches you have already tried. None of that is in the sentence you typed, and the sentence feels complete to you because you are reading it with all of that attached.
This article takes an unusual route to the advice. It does not begin with a method. It begins with the reasons people give for typing the short version, because each of those reasons is sensible, and the useful advice is whatever is left over after they have been taken seriously. The argument is built from the survivors. The cost of that order is that the practical part arrives in the second half, and a reader who wanted a template will have to read through the objections to get to it. There is also no named framework to carry away, because a name would let you apply the idea without having understood why it is true.
Four reasons for the short version
It should be able to work out what I mean. This is the oldest reason and the most natural one. Between people, a short request usually works. A colleague who has sat through the same meetings fills in the rest, and you have been rewarded for brevity for years. The belief that a capable reader will recover your meaning is a habit formed in conversations where the reader shared your situation.
What the habit hides is how much of that recovery was done by shared context rather than by intelligence. An assistant with no access to your meetings, your client or your last attempt can only be as accurate as the page allows. Cleverness does not substitute for facts it was never given, and when the facts are missing the fluent answer is an answer to the average version of your request.
Typing out the background is a waste of time, because I am not talking to a person. The first half is right and the second half does not follow. An AI system is not a colleague, and nothing here suggests you owe it small talk or courtesy. But the question of whether to explain is not a question about etiquette. It is a question about what information the reader has, and the reader has only what is on the page.
There is a further point about habit. People carry the ways they instruct other people into every new setting, and one of those ways is expecting a short instruction to be enough. That expectation is earned between people who share a situation, and it is the habit most likely to mislead when the reader does not.
I will not know what is relevant until I see an answer. This one is the best of the four, and it deserves a real concession. Often you do not know which part of your situation matters until the first response shows you what the tool assumed. In that case the first exchange is a draft of the problem, and the right move is to read the answer for what it assumed and to say what was wrong with the assumption.
Taking the objection seriously changes the advice in a specific way. It means the aim of the opening message is not completeness. It is to put the two or three facts most likely to be decisive on the page, and to let the later exchanges carry the rest. A person who waits to see an answer before supplying anything has made the first answer a guess, and a guess costs a round trip.
More context is always better, so I should paste everything. This is the overcorrection, and it belongs in the list because people arrive at it right after a disappointing answer. The research on long inputs does not support the idea that volume alone helps. Liu et al. (2024) analyzed language models on two tasks that require identifying relevant information in the input, multi-document question answering and key-value retrieval. They found that performance can degrade significantly when the position of the relevant information changes. Performance was often highest when the relevant information occurred at the beginning or end of the input context, and it degraded significantly when models had to use information in the middle of long contexts (Liu et al., 2024).
That finding comes from specific tasks and specific models, and it would be a stretch to read it as a rule about every conversation you will have. What it supports is narrower. The place where a fact sits in what you send can matter, and a long paste does not guarantee that the one thing you needed noticed is the thing that gets used. The practical reading is that a short, deliberate statement of the decisive facts, placed where it cannot be missed, is a better opening than a dump.
Set the four objections side by side and a pattern shows. The first and second assume the reader will supply what the page does not. The third is right that you cannot know everything in advance. The fourth is right that you should not send everything. What survives is a request that carries a small number of well-chosen facts, and an opening move that is more about selection than about length.
Why the gap cannot be seen from where you sit
If the missing context is so obvious once it is named, why does it go missing so reliably? The answer is that the person writing the request is the one person who cannot see the gap.
Birch and Bloom (2007) showed a version of this in adults. Their abstract reports a curse-of-knowledge bias in false-belief reasoning: adults' own knowledge of an event's outcome can compromise their ability to reason about another person's beliefs about that event (Birch & Bloom, 2007). They also found that adults' perception of the plausibility of an event mediates the extent of the bias (Birch & Bloom, 2007). The setting was a false-belief task, and this article does not have the experiment's details in front of it, so it will not describe the procedure. The general point is the one the authors draw: once you know something, you have difficulty setting it aside to judge what somebody else knows.
Applied to a request, that bias has a plain consequence. When you reread your own message before sending it, you read it with your knowledge attached, and the missing pieces are filled in by you without your noticing. The sentence feels clear because you are the one reader for whom it is already complete. The message that would have shown you the problem is the one you cannot read from your own position.
A second line of research makes the same point from the speaking side. Keysar and Henly (2002) asked participants to say ambiguous sentences while trying to convey a specific intention to an addressee, and to estimate how well the addressee understood. The speakers showed a consistent tendency to overestimate their effectiveness: they expected the addressee to understand more often than the addressee did (Keysar & Henly, 2002). In contrast, overhearers who were informed about the speakers' intention did not systematically overestimate the speakers' effectiveness (Keysar & Henly, 2002). The authors conclude that speakers underestimate the ambiguity of their own utterances and overestimate the extent to which their disambiguating cues make their intention transparent (Keysar & Henly, 2002).
The detail about the overhearers is the useful one. It shows the problem is not a general inability to judge clarity, since people who were told the intention but were not the speakers did not make the same error. The error belongs to the position of having the intention in your head. A person writing a request to an AI is in that position by definition.
There is a related result on the receiving end. Keysar et al. (2000) tracked people's eye movements while they followed instructions to manipulate objects. Addressees considered objects as potential referents even when the speaker could not see those objects, which meant they had to use mutual knowledge to correct their interpretation (Keysar et al., 2000). The authors argue that people occasionally use an egocentric heuristic when they comprehend, and that it is successful in reducing ambiguity though it could lead to a systematic error (Keysar et al., 2000). The finding concerns human addressees in a laboratory task and says nothing about how an AI system reads. It is included because it completes the picture of the person's side of a conversation: both the speaker and the listener lean on their own view, and a clear exchange takes some work to establish that the views are shared.
None of this shows that an AI fails in the same ways people do, and it should not be read that way. The claim is about the writer. Your sense that a request is clear is a poor measure of whether it is, for reasons that have been demonstrated in people, and no amount of confidence changes that.
What to say first
If you cannot trust your own sense that the message is complete, the fix has to be something you can do without that sense. It has to be a short list of things to check the message against, which does not depend on feeling that anything is missing. Four are enough, and they are acts rather than a framework.
Say what the output is for. Not the task, which you have already typed, but the use it will be put to and who will meet it. A summary for a board and a summary for yourself are different documents, and the sentence that separates them is usually the one left out because it is obvious to you.
Say what you already know or have already tried. The most common waste in a first answer is a suggestion you rejected an hour ago. One sentence naming the options you have ruled out, with the reason, removes the likeliest repetition and also shows the tool what you value.
Say what a good answer would look like and what a bad one would look like. The second half is the more informative. A person who writes that they dislike long bulleted lists, or that the last version was too cautious, has handed over a boundary that no amount of task description would have drawn.
Say what you are unsure of. If you do not know whether the real problem is the pricing or the timing, say so, and ask to have the two separated. This turns the third objection from earlier into practice: you do not need to know what is relevant, you only need to mark where you are guessing.
An illustration, with no particular person or day behind it. Imagine someone in an unnamed role who needs a short reply to a customer complaint. The short request is to write a polite reply to a complaint about a late delivery. The version built from the four checks says that the reply goes out under a named manager's signature, that the customer has already received one apology and is now asking for a refund the company cannot give, that a firm tone has worked better with this kind of customer than a soft one, and that the writer is not sure whether to offer a discount. The second request is only a few sentences longer. Its answer is a different kind of document.
The point of the illustration is the shape of the second request, which is selection. None of the added sentences is decoration, and each one removes a decision the tool would otherwise have made without telling you. My own reading, and only a reading, is that the decisive facts belong near the front, stated plainly, and that the rest can come in the next turn. The finding that performance is often highest at the beginning or end of the input context is a reason to place them there (Liu et al., 2024).
An hour with a task you already have
You do not need a new task to try this, and the exercise is better run on one you have already done.
Pick a request you sent to an AI in the past few weeks that gave a disappointing result. Find the original message. If you no longer have it, reconstruct it as closely as you can from memory and say that you did.
Read it first as the tool would, with nothing but the page. Underline every noun phrase that depends on something outside the message: the client, the usual format, last quarter's version, the meeting. Each underline marks a place where you were reading with your own knowledge attached.
Then write down, for each underline, the sentence that would have supplied what was missing. Do not rewrite the whole request. Write only the missing sentences, in a list.
Now sort the list into three piles: the facts that would have changed the answer, the facts that would have changed nothing, and the facts you are not sure about. Be strict with the second pile. Many of the things that felt important turn out to be background that the answer would have been the same without. Send nothing from that pile.
Finally, run the request again with the first pile added at the front and the third pile marked as uncertain, and compare the two answers side by side. Do not ask which is better in general. Ask which one you would have been able to use. The difference between the two, and the size of the first pile, is a measure you can keep: it tells you how much of your meaning was living in your head rather than on the page.
Two more reasons to hold back
A model that has been told too much about me will just flatter me. The worry is reasonable, and this article has no evidence to settle it. What can be said is that the four items above are mostly about the work rather than about you: the use, the options already ruled out, the boundary of a good answer, the points of doubt. A request that states what a bad answer looks like invites disagreement more than one that states only your preferred conclusion. If you suspect an answer of agreeing with you too easily, the remedy is to ask for the strongest case against it, which is another sentence of context and not a reason to send less.
Everything I would say first is private. This is the one to treat with the most care, and it belongs outside any argument about answer quality. The checks above rarely need names, figures or documents. They need the shape of the situation. A customer, a manager, a refund that cannot be given, and a tone that has worked: none of that requires identifying anyone. Before you send background, ask whether the point of each sentence survives with the identifying details removed. Usually it does, and you have lost nothing but the risk.
What the page does not carry
There is a last thing worth saying about the request that made sense to you. The sense it made was not in the words. It was in the situation around the words, and a situation does not travel unless somebody writes it down.
Seen this way, the habit of stating context before asking is less a technique for using AI than a practice of noticing how much of what you mean sits outside what you say. The research above is about the human version of that gap: speakers who expect to be understood more often than they are, and knowers who cannot easily set aside what they know. An AI system just makes the gap easy to measure, because it is a reader that has nothing but the page, and the distance between your first answer and your second is how far your meaning had to travel.
If you do the hour with the old request, you will probably find that the missing sentences were not hard to write. They were hard to see. That is the whole of the difficulty, and it is worth knowing that it was never a difficulty with the tool. What you were carrying and did not say was already yours, and the only work left was to put it where the reader could find it.