The carton by the checkout

Here’s the story I use when I’m explaining how I work with AI.

Imagine you send an AI assistant on an errand. For this story, give it whatever tools it would need to shop.

The whole request

“Go to the store and buy me milk.”

Simple enough. Everybody knows what that means.

The assistant goes to the first store it finds. Just inside, next to the checkout, there’s a carton of refrigerated milk somebody took out of their cart and left sitting there. That’s the first milk it sees.

It buys the carton. Brings it home. Marks the task complete.

You look at it and say, “What the hell is this?”

“You asked me to buy milk.”

Yes. But you meant the store two miles away. You meant the refrigerated case at the back. You meant the kind your household drinks, in the size you normally buy. You meant looking at the printed date. You probably meant reaching past the first couple of cartons, because that’s what you do.

You certainly didn’t mean the warm carton abandoned by the checkout.

All those details were part of the errand in your head. Almost none of them made it into the request.

The instructions you thought you gave

When we talk to people who know us, we use shortcuts. “Get milk.” “Send the usual report.” “Find me a good computer.” We expect the other person to fill in the rest from experience, shared habits, and the situation.

That’s the useful part of the milk story: the words you said and the result you expected were different sizes.

There’s a limit to the analogy, though. AI isn’t necessarily going to grab the first carton. It can infer context, recognize ordinary expectations, and sometimes ask a good question. It might get your errand right from that one sentence.

But it can also fill in a missing detail differently than you would. It may lack current information, use a tool incorrectly, misunderstand a constraint, or report success before the work has actually been checked. A detailed request can still fail.

So I don’t use this story to say, “Every AI mistake is your fault.” I use it to ask a more useful question: What did the system need to know, do, and verify to deliver the result I wanted?

Give it the important context

Try the errand again. This time, hand over the shopping list and the map:

A more useful brief

Go to the store marked on this map, two miles away. Buy the type and size of milk on my shopping list, within the budget shown there. Get it from the refrigerated case. Check the carton’s condition and the printed date; I want at least seven days remaining. I prefer a carton a few positions behind the front ones, if it meets the same checks. Don’t let shelf position substitute for checking the carton. If nothing meets the requirements, tell me what’s available before buying a substitute. When you return, confirm what you bought, what it cost, and which checks you could actually perform.

That’s a much better description of the job.

It gives the assistant a destination, the right item, a budget, selection criteria, and a way to handle an exception. The map and shopping list carry information that the sentence “get milk” never contained.

The details are useful because they change the decision. We don’t need to dictate every footstep through the store. We need to communicate the parts that matter.

And reaching farther back or reading a printed date doesn’t magically establish quality. In the story, those are preferences and checks—not permission to ignore a damaged carton or evidence that something else is wrong.

Tell it what to do when the plan breaks

The store might be closed. Your preferred milk might be sold out. The shopping list might omit the size. The assistant’s tools might not let it inspect the carton at all.

A useful system needs an answer to “What now?”

For ordinary details, I want it to use reasonable judgment and keep working. For a change that affects the outcome—spending more than the budget, switching the requested product, claiming a check it cannot perform—I want that uncertainty made visible.

You can set that boundary in plain language: “Use your judgment on the route. Check with me before changing the item or exceeding the budget.”

The assistant should also distinguish what it observed from what it assumed. “The listing says this is available” and “the store confirmed it is in stock” are different statements. “I couldn’t verify that” is a useful result when the alternative is made-up certainty.

A confident report isn’t the receipt

There’s one more step: look at what came back.

Did the assistant buy the right item? Did it follow the constraints? Does the evidence support its report? If something went wrong, was the problem a missing preference, a bad assumption, a broken tool, or a check that never happened?

That distinction matters. Rewriting a prompt won’t repair every broken workflow.

In my AI work, I want the request, the process, and the result to agree. If the task was to update a page, I want to inspect the changed page. If it was to test a computer, I want the configuration, method, and recorded results. If it was to find a deal, I want the exact offer and the time it was checked.

The assistant saying “done” is a report. The finished work is what we evaluate.

Now replace “milk” with “computer”

“Find me a great computer for AI” sounds clear until you try to act on it.

Will the models run on the computer, or through a cloud service? What tasks matter? What budget, memory, noise level, portability, and upgrade options does the buyer need? Is an open-box machine acceptable? Does the advertised price apply to the exact configuration being discussed?

Those details can change the recommendation completely.

The same goes for “find me a deal.” A large discount on the wrong configuration isn’t automatically a useful purchase. A sale headline doesn’t answer questions about the seller, condition, shipping, warranty, or whether the offer is still available.

That’s the idea behind GoBuyMilk: explain the details that make an answer useful. Cover the AI development, identify what the hardware can actually do, describe the test honestly, and check the offer being recommended.

A brief you can reuse

Before handing off a task, give the assistant these six things when they matter:

  1. Outcome: What should be true when the work is finished?
  2. Context: What background, files, examples, or preferences would change the answer?
  3. Constraints: What must it respect—budget, compatibility, deadline, format, or scope?
  4. Judgment: What can it decide, and which exceptions need your input?
  5. Evidence: What information and tools can establish that the result is correct?
  6. Check: What should it return so you can evaluate the finished work?

For a small task, that may take two sentences. For a recurring workflow, save the useful context and checks so you don’t have to explain them from scratch every time. Keep those instructions current as the work changes.

You don’t need a magic prompt. You need an understandable job, enough shared context to do it, and a way to tell whether it worked.

“Go buy milk” is a fine place to start the conversation.

It just might not be the whole job.

Notes and further reading

The shopping trip is a hypothetical illustration, not a report of a model experiment or a claim that all AI assistants behave this way. The practical recommendations are Craig’s working approach, developed from that analogy.

  • Anthropic’s prompting guidance discusses clear instructions, relevant context, and explicit output requirements. Guidance for a particular model should be checked against the task being performed.
  • Anthropic’s Building effective agents describes systems that use tools and environmental feedback, with evaluation and human input where appropriate. That supports the distinction between asking for work and verifying its outcome.