Prompts, Context, And Completions

Concepts Covered

• Prompt
• Context
• Completion
• Instructions
• User input
• Output format
• Context window
• Prompt engineering
• Model call
• Product boundaries

1. Plain-English Definition

A prompt is the input text or instruction you give to a language model.

Context is the information the model can see while producing an answer.

A completion is the output the model generates.

The basic shape is:

prompt + context -> model -> completion

If you ask:

Summarize this support ticket in one sentence.

that instruction is part of the prompt.

If you include the actual support ticket text, that ticket is part of the context.

The generated summary is the completion.

These words matter because language model products are mostly about controlling what the model sees, what you ask it to do, and what you do with the output.

2. Why This Idea Exists

Language models are general. That is powerful, but it also means the product has to guide them.

A model does not automatically know:

• what role it should play
• what user goal matters
• what documents are relevant
• what output format you need
• what data it is allowed to use
• what safety limits apply
• what should happen if it is unsure

The prompt and context give the model the working surface for the current request.

In normal software, function arguments shape behavior.

calculateShipping(order, address)

In language model products, prompts and context shape behavior.

model(prompt, context) -> completion

This is not just wordsmithing. It is interface design.

3. The Beginner Mental Model

Think of a model call as a conversation with a very capable but bounded component.

The model can only answer from:

• patterns it learned during training
• the prompt you send
• the context included in the request
• any tools or retrieved information the product provides

For beginner purposes:

prompt = task
context = visible information
completion = generated result

If the model does not have the right context, it may guess, answer generally, or miss an important detail.

If the prompt is vague, the model may produce a vague answer.

If the product accepts the completion without checking it, the user may see something wrong, unsafe, or poorly formatted.

4. What That Mental Model Misses

The task-visible-result model is useful, but it hides some product complexity.

First, there can be different kinds of prompt content. A product may include system instructions, developer instructions, user messages, tool results, retrieved documents, and output-format rules.

Second, context is limited. A model has a context window measured in tokens. The product cannot always include everything.

Third, context is not the same thing as memory. A model may not remember your private product data unless the product stores it and includes it again later.

Fourth, completions are not automatically correct. They are generated outputs. The product may need validation, citations, fallback behavior, human review, or retries.

Fifth, prompt quality matters, but prompt wording is not the whole product. Strong AI products often depend more on context selection, evaluation, and workflow design than clever phrasing.

5. A Concrete Example

Imagine you are building an internal document assistant.

The user asks:

What is our refund policy for annual plans?

A weak request might send only the user question:

prompt: What is our refund policy for annual plans?
context: none

The model might answer from general knowledge or guess.

A stronger product request might include:

prompt: Answer the user's question using only the provided policy excerpt.
context: Refund policy document section about annual plans.
completion: Annual plans can be refunded within 14 days...

Now the model has a specific task and relevant context.

The product can also require citations, limit the answer length, and say what to do when the policy excerpt does not contain the answer.

That is the difference between "ask the model" and "design a model-backed product path."

6. How It Works At A Practical Level

At a practical level, a language model request often follows this flow:

receive user input
choose relevant context
build prompt
call model
receive completion
validate or transform output
respond to user

The context may come from chat history, current document text, selected files, search results, database records, tool output, or user profile settings.

The prompt may include instructions like:

• answer in plain English
• use only provided context
• return JSON
• cite sources
• ask a follow-up question if missing information
• do not reveal private data

The completion may be:

• a paragraph
• a summary
• code
• structured JSON
• a tool call suggestion
• a ranked list

The product should treat the completion as generated output that needs handling, not as a guaranteed truth object.

7. Where You See This In Real AI Products

In a ChatGPT-style assistant, the prompt includes user messages and often hidden instructions. The context can include conversation history, uploaded files, tool results, or retrieved information. The completion is the answer streamed back to the user.

In a Perplexity-style search product, the context may include search results and source passages. The completion is an answer grounded in those passages.

In a coding assistant, the context may include current file contents, nearby files, diagnostics, terminal output, or previous edits. The completion may be code, an explanation, or a patch.

In a customer support assistant, the context may include ticket history, account status, policy docs, and tone guidelines. The completion may be a draft reply.

The same shape appears everywhere:

task + context -> model -> generated output

8. Common Confusions

A prompt is not the same thing as context.

The prompt tells the model what to do. Context gives it information to work with. In practice they may be sent together, but conceptually they are different.

Context is not the same thing as training data.

Training data shaped the model earlier. Context is information provided during the current request.

A completion is not the same thing as truth.

It is generated output. It may need checking.

Prompt engineering is not the whole AI product.

Prompting matters, but retrieval, evaluation, permissions, tools, and product design matter too.

The model does not automatically know your database.

Your product must retrieve or provide relevant data if the model needs it.

9. What This Does Not Mean

This does not mean all AI work is just writing prompts.

This does not mean longer prompts are always better.

This does not mean the model can safely see all available data.

This does not mean a completion should always be shown directly to the user.

This does not mean context removes the need for evaluation.

Good AI products are not built by hoping the model behaves. They are built by shaping inputs, constraining behavior, checking outputs, and learning from failures.

10. What To Learn Next

Next, learn embeddings.

Prompts and context explain what you send to a model.

Embeddings explain how software can represent meaning numerically.

That matters because products often need to find relevant context before building the prompt.

The path looks like this:

documents -> embeddings -> retrieval -> context -> prompt -> model -> completion

Once that flow is clear, retrieval and RAG become much easier to understand.