Context vs. Intelligence: Why the Same Model Gives Different Answers

Context is the information supplied to the model when it answers: instructions, your request, available conversation messages, and any retrieved material. The model's training is different; it shaped what the model learned before this conversation.

You do not control every part of context. Products can add instructions, select files, or summarise older messages. Your practical control is the brief you provide now. If you ask “improve this email” without supplying the email, the assistant cannot edit your actual text.

Two answers can also differ because of model variability, settings, tool results, or a product update. A change in wording alone does not prove that your prompt improved the result.

The return rule contains two conditions joined by and: the wallet must be unused, and the request must be within seven days of delivery. Knowing one condition is true does not establish the other. In the worked example, adding “ten days ago” establishes that the time condition fails, so the return is outside the stated policy even though the wallet's condition remains unknown.

Think of a shop assistant with a policy card and a customer message on the desk. Training is closer to the assistant's general experience; context is closer to the material currently on that desk. This comparison helps explain why supplying the actual policy matters. It does not mean a model reads, remembers or understands in exactly the way a person does.

During training, a model's internal numerical settings are adjusted using training material. During ordinary answer generation, the model uses its learned patterns together with the available input to produce a response. Supplying “ten days ago” gives the current response a different input; it does not require retraining the model or teaching it a new permanent shop policy. Think of the difference between learning how to calculate and receiving a new set of numbers to calculate with. Google's training and inference definitions explain this distinction.

This explains why the same capable model can produce a weak answer to an incomplete brief. Its general knowledge cannot establish your shop's particular return window. It may generate a plausible policy from patterns it learned, but plausibility is different from using the correct policy. Giving it the actual seven-day rule makes the relevant evidence available. You must still check whether the answer follows it.

Extra context helps when it resolves something the task depends on. The customer's favourite colour does not decide this return; the delivery date does. A long unrelated conversation can make the relevant facts harder to isolate, while contradictory facts can leave the decision unresolved. Start with the smallest complete brief: the task, applicable rule and facts needed to apply it. Add detail for a reason, rather than assuming a longer prompt is automatically stronger.

Before drafting, make a small decision table:

Notice the difference between unknown and no. Unknown means we cannot yet evaluate that condition. No means we have evidence that it fails. In the ten-day case, learning that the wallet is unused does not repair the failed time condition. In the five-day case, asking about condition can still change the conclusion.

Now inspect this constructed mistake:

Your wallet arrived five days ago, so your return is approved. We will cover the postage.

There are two separate failures. First, “approved” skips the unused condition and claims an operational action the assistant has not performed. Second, the postage promise has no supporting policy. Repairing only the tone leaves both errors intact. A targeted correction would be:

An illustrative repair is: “Five days is within the policy's seven-day window. Is the wallet unused? We also need the shop to confirm postage arrangements, because the supplied policy does not specify them.” Every sentence now has a job: compare the date, resolve the missing condition, or identify the remaining policy gap.

More words do not necessarily mean better evidence. Suppose the fictional message now says: “It arrived five days ago. My receipt says delivery was ten days ago. The wallet is unused.” You have added information, but the delivery claims conflict.

Pause and predict: Write the next question before reading on. Should the reply accept the five-day statement because it appears first, choose ten because a receipt sounds formal, or request clarification?

Feedback: Request clarification of the actual delivery date and the relevant delivery record. Under this exercise's supplied facts, neither statement has been established as authoritative. A suitable reply is: “You mention both five and ten days since delivery. Which is the actual delivery date? The seven-day rule depends on that date.” If you immediately approved or rejected the return, you silently selected one conflicting input.

This is a different failure from missing information. Adding the same policy again will not reconcile two inconsistent dates. The repair needs better source information. Save three separate notes: what the customer claimed, what remains unresolved, and what the policy would imply once that fact is established. That separation keeps a confident sentence from hiding an uncertain decision.

Suppose a response breaks a previous word limit. Record “the answer exceeded 45 words,” rather than “the model's memory was erased.” Possible causes include conflicting instructions, missing context, or ordinary failure to follow a rule.

Re-supply the relevant policy and limit, request a corrected reply, and count the words yourself. If it still fails, simplify the task or write the reply manually. Lesson 2.3 develops this correction loop.