Tell AI the deliverable was a table── When a reply misses, naming the form of the deliverable settles it faster than adding more explanation

01Three rounds of explaining lost to one sentence naming the deliverable

In March 2026 the operator asked an AI for a table showing what a particular program could do. What came back was not a table. It was a description of the program's functions. The operator narrowed the subject and asked again. What came back was still not what had been wanted.

On the third attempt the operator changed approach. Instead of explaining what he wanted to know, he named the deliverable: a table listing the functions, nothing more. The misreading stopped there.

One pattern comes out of that record. When an AI reads a request the wrong way, adding explanation usually does not fix it. What fixes it is specifying the shape of the deliverable. Shape here means the outward form of the output: table or prose or list, which columns, how many rows.

02A request has a subject layer and a shape layer, and the drift happens in the shape layer

Every request to an AI has two layers. One is the subject: what the answer is about. The other is the shape: what form the answer arrives in.

When a reply misses, people tend to suspect the subject layer. They narrow the target, add conditions, supply background. But in this record the subject was right from the first attempt. Only the returning form was wrong.

There is a simple test for telling the two apart. If you read the reply and think the content is right but this is not what you asked for, the drift is in the shape layer. If you think the AI is answering a different question, the drift is in the subject layer.

03Rounds of explanation harden the form you did not want

Adding explanation to a shape-layer problem costs two things.

The first is rounds. Explanation moves the reply only a little at a time. In the record, three rounds went by before a table appeared. Naming the form at the start would have taken one.

The second is that the unwanted form sets. The longer an exchange runs, the more the previous output serves as the model for the next one. Ask for a table after several paragraphs of description, and you tend to get the description again with a table attached. What was wanted was a table in place of the description.

04The shape you specify comes down to four values

Specify the shape is a broad instruction. In practice there are only four values to set.

Write these four and the request gets shorter, because the background explanation becomes unnecessary. In the operator's record, the request that worked is shorter than the ones that did not.

There is a boundary. Do not set the shape while the shape is still unsettled. If you have not yet worked out what you want to know, deciding the form first means only what fits that form comes back. While you are still exploring, pass the request on as a question, and set the shape once the deliverable is in view.

05In promotional material review, a list and an essay lead to different rework

The same drift happens in material review and medical work at pharmaceutical companies. You give an AI a piece of promotional material and ask it to raise anything of concern. Back comes an assessment of the material as a whole, written as prose. Nothing in it is wrong. But it cannot be carried into the next step as it stands.

What goes into the review record is a list in which the location, the rule it falls under, and the reason sit on one line. So the request should say that first: return a table with four columns, being the location, the rule that applies, why it is a problem, and a proposed fix. Fixing the columns in advance also makes an empty evidence cell visible at a glance.

Stating the volume helps too. Ask for the ten heaviest items and you avoid a long flat output that treats everything alike. The reverse also holds: while you are still working out what the material should say and where, hand the request over without a set form. A form can only be fixed for work whose use is already decided.

06An AI supplies the specification you omitted, so form beats explanation

Why does specifying the form work so well? Three reasons.

The first is that an AI supplies whatever you left unspecified. The philosopher of language Grice set out a principle that participants in a conversation offer as much information as is required, known as the maxim of quantity. An AI given a request with no stated form estimates the required quantity itself. If that estimate runs high, the answer runs long.

The second is that AI handles ambiguity poorly. A study published by Liu and colleagues in 2023 examined how sentences open to more than one reading are teased apart, and reported that even the strongest model of the time produced readings judged correct by human evaluators only 32% of the time. Which reading an AI picks out of an ambiguous request cannot be relied on.

The third is that the outward form of a prompt moves the result itself. Work by Sclar and colleagues showed that on the same task, changing nothing but the surface formatting of the request could move accuracy by as much as 76 points. Form is not decoration; it is a condition on the output. Anthropic's own guidance advises stating the desired output format and constraints plainly, and telling the model what to do rather than what to avoid. The same company also offers a way to hand over the return format in advance as a schema.

07From tomorrow: when a reply misses, restate the form instead of explaining

Four steps.

1. Decide which layer drifted. Content right but form wrong means the shape layer. A different question answered means the subject layer.
2. If it is the shape layer, stop explaining. Do not bolt more conditions onto the previous request. Rewrite it.
3. Put kind, columns, scope and volume in one sentence. Write: for this scope, a table with these columns, up to ten rows. Leave the background out.
4. Read the reply for form alone. Are the columns all there? Is anything extra attached? Check whether the content is right after the form matches.

A request that worked becomes the model for the next one like it. In the operator's record, the request that named the form sits underneath later requests. Writing the four values down is enough to keep the same drift from happening twice.