What is a prompt and why the result depends on it

Why this matters

• Understand why the same model produces a useful answer in one case and a useless one in another — and what actually drives the difference
• Judge vendor proposals: what gets billed as "AI setup" is often the writing and debugging of prompts
• Know where token costs hide inside a system and how to bring them down

What a prompt is, in plain words

A new hire is handed a task: "sort out the mail." They will ask which mailbox, what "sort out" means, where the results go, what to do with anything unclear. Without answers, the task either goes undone or gets done wrong.

A language model works much the same way. It knows nothing about the company, its rules or its expectations. A prompt is the text where all of that is spelled out: what the task is, what format the answer needs, what is off limits, what a good result looks like.

Hence the point that matters for a business. The quality of an AI system's work is determined not only by the choice of model but by how precisely the instruction is written. A poor prompt turns an expensive model into a generator of platitudes. A good one gets ready-to-use results out of a plainer model.

How it works

1. The system prompt sets behaviour. It describes the model's role, the rules for answering, the format, the constraints. This part goes to the model with every request, but the user never sees it. Anything that must work identically on every call is fixed here.

2. The user request adds the specifics. This is the text from a person: a question, a document to process, data to analyse. The model sees both the system prompt and the user request, and answers with both in view.

3. Examples set the standard. One to three samples go into the prompt: this input, that output. The model adjusts to the format. Without examples the answers come out uneven; with them, predictable.

4. Constraints cut out the noise. "Do not offer anything that is not on the price list", "do not use the word unique", "if you do not know, say so." Without explicit prohibitions the model fills in the gaps, and fills them in wrongly.

5. All of it takes tokens. The prompt, the examples, the attached documents — everything is cut into tokens and paid for on every call. A ten-page instruction sent a thousand times a day becomes a visible line in the budget.

A prompt operates within the model's context window. If the instruction, the conversation history and the document do not fit inside the window, something has to be cut or the model loses the beginning.

An example from practice

The support desk of an online store received around 400 enquiries a day. The first version of the system used a short prompt: "You are a support assistant, answer politely and to the point." The model replied in generalities and in a third of cases promised things the store does not do. Operators proofread every answer; no time was saved.

The prompt was rewritten. A list of the services the store actually provides was added, along with an explicit ban on promising anything else. Three examples went in: a typical question about delivery, one about returns, one about order status, each with a model answer. The format was specified: first the answer to the question, then an offer to help with anything else, length up to 100 words.

The share of answers operators sent without edits rose from 28 to 71 percent. Measurements covered one week before and one week after, 2,000 enquiries each. The prompt grew by 1,400 tokens in the process, raising spend by roughly RUB 1,700 a month. The time saved by operators covered that sum within the first three days.

What it gives a business

• The right result the first time. A precise prompt cuts rework. Where three iterations used to be needed, one is enough — saving not only time but tokens.
• Predictable system behaviour. The prompt fixes the rules: what may be promised, in what tone to answer, how to lay things out. Without it, every answer is a lottery.
• A clear place to optimise. When a system performs badly, the prompt is the first thing to check. Rewriting it often achieves more than moving to a pricier model.
• Cost control. Prompt length feeds straight into the bill. Halving the instruction while holding quality is a way to cut spend without losing the result. The rough order of the sums for a particular case can be worked out with the budget calculator.

When this can be skipped

For one-off tasks in a chat with a model, there is no point drafting a detailed prompt. Writing a letter, summarising a document, translating a paragraph — an ordinary question is enough. The cost of a mistake here is a minute spent asking again.

The same goes for early-stage experiments. While it is still unclear whether the model solves the task at all, it is too early to spend time on the perfect prompt. The hypothesis gets tested on a rough draft first; the instruction is refined afterwards.

A prompt becomes critical once the system goes into production: hundreds or thousands of requests a day, each handled without a human involved. There, an error in the wording is multiplied by the whole flow.

What is worth checking

First: a prompt is not a one-time setting but a document that lives alongside the system. Return rules change — the prompt changes. A new type of enquiry appears — an example is added. Without version control, in a month nobody remembers why the system answers the way it does.

Second: a long prompt does not mean a good one. Superfluous instructions confuse a model just as much as missing ones. The test is simple: remove a paragraph and see whether the quality of the answers changes. If it does not, the paragraph was dead weight.

Third: ask the vendor to show the system prompt and explain every block of it. This is neither a secret nor intellectual property — it is a working document. It reveals whether the vendor understands the task or copied a template off the internet. How ready a process is for automation, including how clear the rules for a prompt are, can be assessed with a checklist.