LLM foundations and AI fluency

The short version

A large language model (LLM) is a program that has learned, from a very large amount of text, to predict what comes next. You give it some text, called the prompt. It predicts the next small piece of text, adds it to the end, and repeats. A long, sensible answer is built one small piece at a time.

This sounds too simple to produce useful work, but predicting the next piece well requires learning a lot: grammar, facts, styles of writing, how arguments are built, how code works. The model does not look things up in a database while it writes. Everything it 'knows' is stored as patterns in billions of numbers called parameters (or weights), learned during training.

Tokens: the pieces the model works with

Models do not read letters or whole words. They read tokens. A token is a chunk of text: often a whole short word, sometimes part of a longer word, a space, or a punctuation mark. A tokenizer is the part of the system that splits text into tokens and turns each one into a number.

Tokens matter to an FDE for three reasons. Cost is charged per token. Limits, such as the context window, are measured in tokens. And some odd behaviour comes from tokens: a model can struggle to count the letters in a word because it never sees the individual letters, only the chunks. Different model families use different tokenizers, so the same text can be a different number of tokens in different models. Vendors provide tools to count tokens exactly, and you should use them rather than guess.

Next-token prediction, step by step

Here is what happens each time the model writes one token.

• The prompt so far is split into tokens and turned into numbers.
• The model passes these numbers through many layers. Each layer lets every token 'look at' the earlier tokens and mix in what is relevant. This mechanism is called attention, and the overall design is called a transformer.
• At the end, the model produces a score for every token in its vocabulary: how likely it is to come next.
• One token is chosen from these likely options. This choice is called sampling.
• The chosen token is added to the text, and the whole process repeats for the next token.
• It stops when the model produces a special end token or reaches the maximum length you allowed.

Training versus inference

Training is how the model is made. In pretraining, the model reads huge amounts of text and adjusts its parameters, again and again, to get better at predicting the next token. This produces a model that can continue any text but is not yet a helpful assistant. In a later stage, often called post-training or fine-tuning, people and automated methods teach it to follow instructions, answer questions, refuse harmful requests and hold a conversation. Training is done by the model provider, takes a lot of computing power, and happens before you ever use the model.

Inference is using the trained model: sending a prompt and getting a response. This is what you do on a client project. The model's parameters do not change during inference. It does not learn from your conversation in the way a person does; if it seems to remember something within a chat, that is because the earlier messages are sent to it again as part of the prompt. It also has a training cutoff: it knows little or nothing about events after its training data was collected, unless you give it that information in the prompt.

Why it is probabilistic

At each step the model produces likelihoods, not one fixed answer. Sampling picks from them. A setting called temperature controls how adventurous the choice is: lower values make the model stick to the most likely tokens, higher values let it pick less likely ones more often. Because one different token early on changes everything that follows, two runs of the same prompt can give different answers.

This has practical effects. You cannot test a prompt once and call it done; you need to run it on many cases. You should not promise a client identical output every time. And when the exact answer matters, such as a number or a category, you should give the model clear rules and examples, ask for a fixed output format, and check the result with code where you can.

The short version

Every call to an LLM has input tokens (everything you send: instructions, documents, chat history, the question) and output tokens (everything the model writes back). Providers charge for both, usually as a price per million tokens, and output tokens usually cost more than input tokens. The context window is the maximum number of tokens the model can handle in one call, counting both input and output.

Latency is how long the user waits. It has two main parts: the time before the first token appears, which grows with the amount of input, and the time to write the rest, which grows with the amount of output because the model writes one token at a time.

The context window

Think of the context window as the model's desk. Everything it needs for this call must fit on the desk at once: your instructions, any documents, the conversation so far and room for the answer. Anything not on the desk does not exist for the model in that call. If a chat gets long, older messages may need to be dropped or summarised to make room.

Context windows today are large enough to hold long documents, but bigger is not always better. Long input costs more and takes longer. Models can also pay less attention to details buried in the middle of a very long prompt. A better habit is to send only what this call needs: the relevant parts of a document, not the whole archive. Check the current limits for each model on the provider's models page, because they change between model versions.

How to estimate cost, step by step

Use the same five steps on every project. Write the result down and show the client your assumptions, so they can change them.

• Measure typical input tokens per call using a token counting tool on real examples, not a guess.
• Measure typical output tokens per call the same way.
• Look up the current price per million input and output tokens for the chosen model on the provider's pricing page.
• Multiply each token count by its price and divide by one million. Add the two to get the cost per call.
• Multiply by calls per day and working days per month. Add a margin for retries and growth.

Why long context is slower and costlier

Cost: you pay for every input token on every call. If you send a 50-page manual with each question, you pay for those pages every time, even if the answer needs one paragraph. Speed: before writing the first token, the model must process all the input. More input means a longer wait before anything appears. Output is slower per token than input because each output token needs its own pass through the model.

Several techniques help. Send less: retrieve only the relevant sections (the next lessons explain retrieval). Ask for shorter output when you do not need long text. Use a smaller, faster model for simple tasks such as sorting emails into categories, and keep larger models for hard reasoning. Use prompt caching where the provider supports it: if many calls start with the same long instructions or document, the provider can reuse that processed part, which reduces cost and time for repeated calls. Stream the response so users see text appear as it is written, which makes waiting feel shorter even if the total time is the same.

Explaining cost and speed to a client

Clients rarely want token maths. They want to know three things: roughly what it will cost per month, what drives that cost up, and how fast users will get an answer. Give them a short table with your assumptions in plain words: 'about 3,000 words of input per email, about 300 words of reply, 2,000 emails a day'. Then show what changes the number most, which is usually volume and how much text you send per call.

For speed, measure rather than promise. Time twenty realistic calls and report the typical time and the slowest time, because users remember the slow ones. Match the design to the need. A nightly batch job can use a large model and long documents because nobody is waiting. A live chat needs a fast first token, short prompts and streaming. If the client needs both quality and speed, a common design is a fast model for the first step, such as sorting the request, and a stronger model only for the cases that need it.

The short version

A prompt is the text you send to the model. A good prompt is like a good brief to a smart new colleague who knows nothing about your client: it says who they are acting as, what to do, what background matters, what good looks like, and how to hand the result back. The model cannot ask you clarifying questions in the middle of a single call, so anything you leave out, it will guess.

Five parts cover most needs: role, task, context, examples and output format. You will not always need all five, but checking each one is a quick way to find what is missing.

The five parts, step by step

Use the parts in roughly this order. Put long documents near the top and your question near the end; this tends to work well with long inputs.

• Role: who the model should act as. 'You are an accounts payable assistant at a food distributor.' A role sets vocabulary, tone and focus.
• Task: exactly what to do, as a clear instruction. 'Classify the invoice exception and draft a one-paragraph explanation for the clerk.'
• Context: the facts and rules it needs. Business rules, definitions, the document to work on, who reads the output. Explain why a rule exists when you can; models follow rules better when they understand the reason.
• Examples: one to a few input and output pairs that show what good looks like, including a tricky case. Examples often fix problems that more instructions cannot.
• Output format: the exact shape of the answer. Length, headings, or a JSON structure with named fields. Say what to do when information is missing.

Making prompts clear

Separate the parts so the model does not mix instructions with data. A common way is to wrap each part in simple tags, such as <rules> and </rules>, or <email> and </email>. Then you can refer to them: 'Use only the rules in the rules tags.' Be direct and specific. 'Keep it short' is vague; 'Under 80 words' is clear. Say what to do, not only what not to do.

For hard tasks, allow the model to think step by step before it answers, for example by asking it to reason inside thinking tags and then give the final answer in answer tags. Many current models also have a built-in thinking feature you can turn on. Thinking usually improves accuracy on multi-step problems, at the cost of more output tokens and time.

Structured output with JSON

When code will use the answer, ask for JSON (JavaScript Object Notation), a simple text format of named fields that every programming language can read. Give the exact field names, allowed values and types. Tell the model to return only JSON, with no extra text. Then check the result in code: parse it, confirm each field exists and that values are allowed. Some providers, including Claude, offer a structured outputs feature that makes the model follow a JSON schema you provide, which removes most format errors. Even then, the content can still be wrong, so you still evaluate it.

import json

ALLOWED = {"price_mismatch", "quantity_mismatch", "missing_po", "other"}

def check_reply(text):
    data = json.loads(text)  # raises an error if it is not valid JSON
    assert data["category"] in ALLOWED, f"bad category: {data['category']}"
    assert isinstance(data["explanation"], str) and data["explanation"]
    assert isinstance(data["needs_human"], bool)
    return data

model_reply = '{"category": "price_mismatch", "explanation": "Invoice unit price 4.20 vs PO 3.90.", "needs_human": true}'
print(check_reply(model_reply))

Iterate like an engineer

Prompting is not a one-shot skill. Write a first version, run it on ten to twenty real cases, read every output, find the pattern in the failures, change one thing, and run again. Keep old versions so you can compare. The best test cases come from the client's real work, especially the ones their experts find hard.

System prompt and user message

When you call a model through an API (application programming interface, the way programs talk to the model), there are usually two places to put text. The system prompt holds the standing instructions that apply to every call: the role, the rules, the output format. The user message holds what changes each time: the email, the invoice, the question. Keeping them apart makes the prompt easier to maintain and test, because you can change the rules in one place and rerun all your cases.

Treat prompts like code. Store them in files with version numbers, not only in a chat window. Write a short note with each change saying what failure it fixes. When a client expert says 'that answer is wrong', you can then show them the exact rule the model followed and agree together how to change it. This turns prompt work into a shared, reviewable specification instead of private trial and error.

The short version

A hallucination is when a model states something false or made up as if it were true: a wrong figure, a policy that does not exist, a citation to a paper nobody wrote. It happens because the model is trained to produce likely-sounding text, and a fluent, plausible answer is often more likely than 'I do not know'.

Grounding means giving the model the real source material and telling it to answer only from that material. It is the main defence. Citations, which point to the exact passage behind each claim, let a person check the answer. Allowing and encouraging 'I do not know' stops the model from filling gaps with guesses.

Why models invent

Recall how the model works: it predicts the next token from patterns. It has no built-in check that a statement is true. When it knows a fact well from training, the likely answer and the true answer usually match. When it does not, it still produces the most likely-looking text, which can be confident and wrong.

Hallucinations are more common in some situations: rare or very specific facts (a client's internal policy, a part number), recent events after the training cutoff, exact numbers and dates, long chains of reasoning, and questions that assume something false ('Why did our Q3 policy change?' when nothing changed). They are also more likely when the prompt pushes for an answer at any cost.

Grounding, step by step

Use these steps whenever an answer must be factually correct.

• Find the source: the client's documents, database rows or system records that contain the true answer.
• Put the relevant parts in the prompt, clearly marked, for example inside document tags with a title and an id.
• Instruct the model to answer only from those documents, and to say 'I do not know' or 'not found in the documents' when the answer is not there.
• Ask for citations: a short quote or document id for each claim. For long documents, ask the model to first pull out the relevant quotes, then answer from the quotes.
• Check citations in code or by review: does each quote really appear in the source, and does it support the claim?
• Measure: in your test set, include questions whose answer is not in the documents, and count how often the model correctly says it does not know.

Going deeper: tools that help

Some providers offer a citations feature. With Claude, you can pass documents and the response comes back with references to the exact passages it used, which is easier to check than quotes the model writes itself. For numbers, let code do the maths: retrieve the figures with a database query and ask the model to explain them, rather than asking it to calculate. For high-stakes outputs, keep a human review step, and show the reviewer the sources next to the answer so checking is quick.

Also design the user experience for honesty. A screen that shows 'Source: Returns policy, section 4' next to the answer invites checking. A screen that shows only a confident paragraph invites blind trust.

What grounding cannot fix

Grounding reduces hallucination but does not remove it. The model can still misread a source, mix up two similar documents, or quote correctly but draw the wrong conclusion. If the source documents are out of date or contradict each other, the answer will reflect that. This is why evaluation on real cases and a clear review process stay necessary.

Talking to clients about hallucination

Be honest early. Tell the client in plain words that the model can produce confident wrong answers, that the design reduces this but does not remove it, and that you will measure how often it happens on their real cases. Clients handle a known, measured error rate far better than a surprise in front of their manager.

Agree on what an error costs. A wrong answer in an internal search tool may be a small annoyance. A wrong figure in a regulatory report is serious. The cost decides how much grounding, checking and human review you need. Write the agreed bar down, for example 'no unsupported claims in 100 test questions, and correct "not found" on every unanswerable question', so everyone knows what 'good enough' means before the demo, not after it.

The short version

Start with a plain model call: you send a prompt, it sends text back. Three patterns extend this. Retrieval augmented generation (RAG) finds relevant pieces of the client's documents and adds them to the prompt, so the model answers from real sources. Tool use lets the model ask your code to do something, such as look up an order or run a calculation, and then use the result. An agent is a model that uses tools in a loop, deciding its own next step, until it finishes a task.

Each step adds power and also adds cost, delay and ways to fail. The rule of thumb is: use the simplest pattern that solves the problem, and only add more when tests show you need it.

RAG: give the model the right pages

RAG solves the problem from the last lesson: the model does not know the client's documents. You prepare by splitting documents into chunks, such as sections or paragraphs, and storing them in a searchable index. When a question comes in, a search step retrieves the most relevant chunks, and these are put into the prompt with an instruction to answer from them.

The search can be keyword search, semantic search using embeddings (lists of numbers that represent meaning, so 'refund' can match 'money back'), or both. The quality of RAG depends mostly on retrieval: if the right chunk is not found, the model cannot use it. Use RAG when answers live in a large body of text that changes over time, such as policies, manuals or past tickets.

Tools: let the model ask your code

With tool use, you describe functions to the model: a name, what it does and what inputs it needs, for example get_order_status with an order_id. When the model decides it needs one, it replies with a structured request to call that tool. Your code runs the function, sends the result back, and the model writes its answer using it. The model never runs code itself; your program stays in control and decides what is allowed.

Use tools when the answer depends on live data in a system (order status, stock levels, account balance), when you need exact calculations, or when the model must take an action such as creating a ticket. Actions that change things need extra care: start with read-only tools and add human approval for anything that writes.

Agents: tools in a loop

An agent repeats a cycle: look at the goal and what has happened so far, choose a tool, run it, look at the result, and decide the next step, until the task is done or a limit is reached. This is useful when the steps cannot be known in advance, such as investigating why a shipment is late across several systems.

Anthropic's guide to building effective agents, linked below, separates workflows, where your code sets the steps in a fixed order, from agents, where the model chooses the steps. Workflows are more predictable and easier to test. Agents are more flexible but cost more, take longer and can make compounding mistakes. Many real problems are solved well by a workflow.

• Answer from documents: RAG.
• Answer needs live system data or exact maths: tools.
• Known fixed steps: a workflow of calls and tools set by your code.
• Open-ended task with steps you cannot predict: an agent, with limits and review.

Questions to ask before choosing

In discovery, a few plain questions usually make the choice clear. Where does the answer live today: in documents, in a system, or in someone's head? If it is in someone's head, no pattern will help until it is written down. How often does that information change? Fast-changing data points to tools that read the live system rather than a copy. Does the task only read information, or does it need to change something? Anything that writes needs approval and careful limits.

Also ask how many steps an expert takes and whether those steps are always the same. If an experienced person follows the same five steps every time, write those steps as a workflow in code. If they say 'it depends' and explore, that is where an agent may earn its extra cost. Finally, ask how the result will be checked. Whatever you choose, you will need real examples with known good answers to test it.

The short version

Responsible use comes down to four questions. What data is this, and how sensitive is it? Where is it allowed to go? Could the output be unfair or harmful to some people? Who checks the output before it affects anyone? The client's own policies and contracts set the answers. Your job is to ask, follow them, and design the system so the safe path is the easy one.

When in doubt, stop and ask. 'Can I send this data to this model?' is always a good question to ask the client's security or data protection team. Guessing is not.

What data may go where

Most organisations classify data into levels such as public, internal, confidential and restricted. Learn the client's levels on day one. Then check which AI tools are approved for which level. A free consumer chat app, a company-approved enterprise chat tool and an API account under a contract with the client are different places with different terms for storage, retention and training on your data. Read the provider's data and privacy terms and the client's agreement; do not assume.

Personal data, often called PII (personally identifiable information), is any information that identifies a person: names, emails, phone numbers, addresses, account numbers, ID numbers, and combinations of details that point to one person. Privacy laws such as the EU GDPR set rules for how it may be processed. Some data is extra sensitive, such as health, financial or biometric data, and some industries have their own rules.

• Use the least data that does the job. If the task is classifying complaints, you may not need customer names at all.
• Remove or mask personal data before it reaches the model where you can, for example replacing names with placeholders.
• Use synthetic or masked data for early prototypes and demos.
• Keep data in client-approved systems and accounts only. Never copy client data to personal devices or personal AI accounts.
• Never paste secrets such as passwords or API keys into prompts.

Bias and fairness

Models learn from human-written text, which carries human biases. They can treat people differently based on names, language, gender, age or location, even when told not to. The risk is highest when the output affects people: hiring, lending, insurance, pricing, benefits, discipline. In those areas, test on purpose: create pairs of cases that differ only in a sensitive detail, such as the name, and check whether the output changes. Keep a human decision maker for decisions about people, and record what the AI recommended and what the human decided.

Human in the loop, step by step

Human in the loop means a person reviews or approves the AI's output before it takes effect. Decide where to put that person based on the cost of an error.

• List what the system outputs and what happens next with each output.
• For each, ask: if this is wrong, who is harmed and how badly? Can it be undone?
• Low harm and easy to undo, such as sorting internal emails: let it run, sample and review a few each week.
• Medium harm, such as a draft reply to a customer: a person reviews and sends.
• High harm or hard to undo, such as a payment, a decision about a person or a medical statement: a person decides; the AI only prepares information.
• Make review easy: show sources next to the output and let reviewers mark errors with one click, so you can measure and improve.

Security risks specific to LLMs

LLM systems add new risks. Prompt injection is when text the model reads, such as an email or a web page, contains instructions that try to make the model do something else, like reveal data or call a tool. Treat all content the model reads as untrusted data, limit what tools can do, and require approval for actions. The OWASP Top 10 for LLM applications, linked below, is a good checklist to review with the client's security team.

Client policies come first

Every client has its own rules, and they override general advice, including this lesson. Ask for the acceptable use policy for AI tools, the data classification policy, and any contract terms with the AI provider. Find out who approves exceptions. Write the answers in your project notes and share them with your pair, so nobody has to guess later.

Keep a simple record as you build: which data went to which tool, under which approval, and how long it is kept. If the client's security team asks a question at the end of the project, you can answer in minutes. This record also helps the client owner after hand over, because they will need to explain the system to auditors and new team members.