Intent: The First Sentence That Decides What Your Prompt Costs

The framework post introduced five levers of prompt discipline. This is the first deep dive, and I am starting with Intent for a simple reason: of the five, it returns the most for the least effort. It costs one sentence. It is the only lever you can apply without touching your data, your architecture, or your model.

A prompt with no clear intent is not a small problem. It is the single largest source of wasted tokens in most enterprise AI deployments — not because the model is expensive, but because an unclear instruction gets answered, rejected, rephrased, and answered again. The cost is not in the call. It is in the loop.

This article is about how to close that loop with the first sentence.

The lever that pays for itself first

Most attempts to improve an AI deployment start with the expensive layers. A better model. A bigger context window. A fine-tune. Each of those is a budget conversation, a procurement step, and a delay.

Intent is none of those things. It is a rewrite of the first sentence of a prompt you already have. It ships the same afternoon. And in most reviews I run, it moves the cost and quality numbers further than anything downstream of it — because almost every other failure in a prompt is an intent failure wearing a different costume. Bloated context is usually there to compensate for a vague task. Defensive parsing downstream is usually there because the output type was never stated. Fix the intent and the symptoms below it often resolve on their own.

So the question worth asking is not “is this prompt good?” It is “does this prompt know what it is for?” And there is a fast way to test that.

The three-year-old test

Here is the test I now run before any prompt goes near production.

Can I explain what the prompt must do to a three-year-old?

Not the technology — a three-year-old will never understand retrieval, token budgets, or JSON, and they do not need to. The task. Stripped of jargon, said once, in plain words a child could act on: “Find the parcel and tell me the day it arrives.” That is a clear instruction. A child can carry it out, and — more to the point — a child can tell you when it is done.

Now compare: “Handle the logistics enquiry appropriately.” A three-year-old is lost. So is the model. Both will do something — and you will spend the next three messages correcting it.

The test is not about dumbing the work down. The work can be sophisticated. The instruction must be simple. If you cannot say what the model must produce in one plain sentence, the intent is not unclear to the model — it is unclear to you. The prompt is just the place that becomes visible.

When a prompt fails the three-year-old test, it usually fails in one of three specific ways. Those three ways are the anatomy of intent.

What intent actually contains

A complete intent answers three questions in the first sentence or two.

The task. What single action is the model performing? Summarise, classify, draft, extract, rewrite. One verb — not a category of helpfulness. “Help with” and “handle” are not tasks. They are job descriptions, and a job description hands the model a decision it should never have been given.

The output type. What shape is a correct answer? A paragraph, a JSON array, a single number, a yes or no, a numbered list of at most four items. If the shape is left implicit, the model picks one — and it will pick a different one next week.

The audience. Who reads the output, and what do they already know? A summary for a finance director and a summary for a new joiner are different documents. The model cannot guess the reader. If you do not name them, it writes for an average that suits no one.

Miss the task and the model guesses what you want. Miss the output type and you get prose where you needed data. Miss the audience and you get something technically correct that still has to be rewritten. The three case studies below are composites — realistic in shape, drawn from patterns I have seen more than once, not tied to any one client — and each one is a single miss.

Case study 1 — The helpdesk bot that answered twice

An internal IT helpdesk assistant, built in Copilot Studio, answering first-line questions from non-technical staff. Its system prompt, in full, was close to this:

BEFORE:  Help the user with their IT problem.

It worked, in the sense that it replied. But the replies were long, hedged, and full of caveats. Users read the first answer, did not find their fix, and asked again in different words. Tokens per resolved question ran close to three times the estimate.

The task was named — “help” — but help is not a task. It is a category that holds at least three separate ones: diagnose the problem, walk the user through a fix, or escalate it. The output type was implicit, so the model defaulted to safe, exhaustive prose. The audience was implicit, so it pitched at no particular level.

AFTER:   You are an IT helpdesk assistant for non-technical staff.
         For the user question below, return a numbered list of at
         most four troubleshooting steps in plain language. If the
         issue needs administrator rights, do not list steps —
         reply only: "This needs IT to action. Please raise a ticket."

Three components, made explicit: the task (return troubleshooting steps), the output type (a numbered list, capped at four), the audience (non-technical staff). The re-prompt loop closed, because the first answer was now shaped like something a user could act on.

Case study 2 — The report nobody could use

A monthly sales summary, generated from a dataset and sent into a regional leadership review.

BEFORE:  Write a summary of this month's sales data.

The output was readable. It was also wrong for its reader. It came back as four warm paragraphs of narrative — and a leadership review wants figures against target. Every month, an analyst rewrote it by hand before the meeting.

The task was named, and the output type was loosely present (“a summary”). The miss was audience. “A summary” for a leadership review is not the same document as “a summary” for a team newsletter. The model was not told which, so it produced the friendlier, more generic of the two.

AFTER:   Summarise the sales dataset below for a regional leadership
         review. Output exactly three short paragraphs: (1) the
         headline result against target, (2) the single largest
         driver, (3) the single largest risk. Use figures, not
         adjectives. Do not include recommendations.

Naming the audience pulled the other two components into focus with it. Once “leadership review” was on the page, the right output type — three tight, numbers-led paragraphs — was obvious. The hand-rewrite stopped.

Case study 3 — The classifier that guessed

A document triage step inside a Power Automate flow. An email arrives, the model decides what kind it is, and the flow branches on the answer.

BEFORE:  Look at this email and decide what to do with it.

The model returned a sentence — sometimes a helpful one, like “This looks like an invoice, you should probably send it to accounts.” But a flow cannot branch on a sentence, so someone wrapped the step in a parser that searched the text for keywords. The parser broke whenever the phrasing changed.

The task was the deepest miss here. “Decide what to do” is not a task the model can complete — it is a decision the flow makes, based on a classification the model produces. The model was quietly being asked to do the flow’s job.

AFTER:   Classify the email below into exactly one category:
         invoice, support_request, sales_lead, or other.
         Return only the category as a single lowercase word,
         with no punctuation and no explanation.

The task narrowed to one verb — classify — with a closed list of outputs and a strict shape. The custom parser came out, and the flow stopped breaking on rephrased emails.

Write the intent first

The practical discipline is an ordering one. Write the intent sentence before you write anything else in the prompt — before the context, before the examples, before the formatting rules.

This feels backwards, because context is what you have most of and intent is what you have to think hardest about. But ordering it this way does two useful things. It forces the hard thinking to the front, while the prompt is still cheap to change. And it gives every line that follows a test to pass: does this context serve the stated intent? Does this example demonstrate the stated output type? A prompt with the intent written last is a prompt assembled without a brief.

If the intent sentence will not come — if it keeps needing a second clause, then a third, then a piece of jargon to hold it together — that is not writer’s block. That is the prompt telling you the task is actually two tasks, or that the requirement has not been decided yet. Split it, or go and decide it. Do not paper over it with context.

Quick check

Before this prompt ships, ask one question: could a new team member, reading only the first sentence, predict the shape of a correct answer — and explain the task to a three-year-old without using a single technical word?

If yes, the intent is done. If no, you have found the cheapest fix available to you, and it costs one sentence.

Intent is the first of five levers. The next, Context, is its natural partner — once the model knows precisely what it is for, you can be precise about what to feed it, and precise is almost always less. That is the subject of the next deep dive in this series.

Where to start

If you have not read the framework this lever belongs to, start there: it covers all five levers and includes a ten-point scorecard you can run any prompt through.

→ Read: Prompt Discipline: The Five Levers Behind Production-Ready Enterprise AI

→ Download: The Prompt Discipline Framework (PDF) — the printable scorecard lives at the back.

Carmen Nel is a Power Platform & AI Solutions Architect based in Ras al-Khaimah, UAE. She writes on prompt discipline, enterprise AI governance, and the practical side of low-code AI on the Microsoft stack.