A typical LLM application is NOT "call the model, show the answer." It is: User input -> validate and limit it -> retrieve relevant context (documents, memory, data) -> assemble a prompt (instructions + context + conversation + question) -> call the model (possibly in a loop with tools) -> validate / parse the output -> log, evaluate, and return the result 

Input: "The capital of France is" Model: P(" Paris") = high, P(" Lyon") = low, ... Output: " Paris" -> appended -> predict next token -> "." ... 

- It generates PLAUSIBLE text, not VERIFIED text. Fluency is not accuracy. (Section 8: hallucinations) - It is STATELESS. It has no memory between calls beyond what you send it. (Section 10: conversation memory) - It has a KNOWLEDGE CUTOFF. It knows nothing about events after training, and nothing about your private data unless you supply it. - It is NON-DETERMINISTIC by default. Sampling introduces variation. - It has a bounded CONTEXT WINDOW. It can only consider so much text at once. (Section 6) 

1. PRE-TRAINING Learn language and broad knowledge by predicting next tokens over a huge text corpus. Produces a "base" model — capable but not conversational or reliably helpful. 2. FINE-TUNING Further train on curated examples (instruction/response pairs) so the (instruction model follows instructions and answers in a useful format. tuning) 3. ALIGNMENT Shape behavior toward helpful, honest, and safe responses, often using (e.g. RLHF) human feedback or preference data as a training signal (this series' AI/ML Fundamentals guide covers reinforcement learning). (Newer "reasoning" models add training to produce extended internal reasoning before answering, trading latency and cost for accuracy on hard problems.) 

LLMs are strong at: language tasks — summarizing, rewriting, extracting, classifying, translating, drafting, explaining, and generating code — and at handling messy, unstructured input. LLMs are weak at: exact arithmetic and counting, guaranteed factual recall, knowing what they don't know, acting on current or private data without being given it, and being perfectly repeatable. Design rule: Use the model for what it's good at (language, judgment, flexibility) and use ORDINARY CODE for what code is good at (math, lookups, validation, business rules, security). The best LLM applications are hybrids. 

1. ROLE / CONTEXT Who the model is acting as and the situation it's in. 2. TASK Exactly what to do — specific and unambiguous. 3. INPUT DATA The material to work on (clearly delimited from the instructions). 4. CONSTRAINTS Rules: scope, tone, length, what NOT to do, what to do when unsure. 5. OUTPUT FORMAT The exact shape of the response (a label, bullets, JSON schema...). 6. EXAMPLES Optional demonstrations of good input/output pairs (Section 4). 

BE SPECIFIC. Vague in, vague out. "Summarize this" gets a generic summary; "Summarize this support ticket in two sentences for an engineer, focusing on the reproduction steps" gets something usable. GIVE CONTEXT. The model can't read your mind or your database. Say who the audience is, what the goal is, and supply the facts it needs. STATE THE FORMAT. Say exactly what shape you want back, and why, if it helps. SAY WHAT TO DO, Positive instructions ("answer in plain language") generally work NOT ONLY WHAT better than a list of prohibitions, though explicit "do not" NOT TO DO. rules are still useful for hard constraints. GIVE AN ESCAPE Tell the model what to do when it can't comply: "If the answer HATCH. is not in the provided text, reply exactly: NOT_FOUND." This is one of the most effective anti-hallucination measures. BREAK DOWN HARD A complex task often works better as several smaller prompts TASKS. (extract, then analyze, then format) than one giant instruction. ASK FOR REASONING For problems needing multi-step logic, asking a standard model WHERE IT HELPS. to work through the steps before giving a final answer often improves accuracy. (Dedicated reasoning models do this internally, and usually need less coaxing — follow your model's guidance.) 

WEAK: Summarize this ticket. STRONG: You are a support triage assistant. Summarize the ticket below in at most two sentences for an on-call engineer. Include: the affected feature, the observed error, and any reproduction steps. If a required detail is missing, write "unknown" for it. Do not speculate. <ticket> {ticket text} </ticket> 

- Keep prompts in source control (files or resources), not scattered as inline strings. - Use TEMPLATES with named placeholders rather than ad hoc string concatenation. - Change ONE thing at a time, and measure the effect on a test set (Section 12) — not on one example you happen to like. - A model upgrade can change how a prompt behaves. Re-run your evaluations when you switch models or versions. - Treat prompt changes like code changes: review them, and be able to roll back. 

system -> the developer's standing instructions: role, rules, tone, format, safety boundaries. Sets the frame for the whole conversation. user -> what the end user (or your application, on their behalf) is asking assistant -> the model's own earlier replies, which you replay as history tool -> results returned from functions the model asked you to run 

System message -> STABLE rules that apply to every turn: identity ("You are the support assistant for ACME"), scope ("Only answer questions about ACME products"), tone, output format, what to do when unsure or out of scope, and the handling of sensitive requests. User message -> the VARIABLE part: the actual question, plus per-request data (retrieved documents, the text to summarize). 

Models generally give system instructions priority — but that is a TENDENCY, not an enforced rule. Do NOT put anything in a system prompt that you can't afford to have revealed, and do NOT rely on it alone to enforce security. PROMPT INJECTION: text in the user input — or in a document, web page, or email you feed the model — can contain instructions that try to override yours ("ignore previous instructions and..."). This is a fundamental risk whenever untrusted text enters a prompt. Defenses are layered, never a single trick: - Clearly DELIMIT untrusted content and tell the model to treat it as data, not instructions. - Give the model the LEAST privilege: only the tools and data the task needs. - Enforce permissions and validation in CODE, outside the model. - Require human confirmation for consequential actions. - Don't put secrets (API keys, credentials, private data) in prompts. 

- Never let user-supplied text be placed in the SYSTEM role. That hands the user your highest-priority channel. - Replay the assistant's previous turns faithfully; rewriting them can confuse the model. - Keep tool results in the tool role, and remember they may contain untrusted text too. 

Zero-shot : instructions only, no examples. "Classify this ticket." One-shot : instructions plus ONE example. Few-shot : instructions plus SEVERAL examples (commonly 2-10) showing the input -> output pattern you want. 

(string Text, string Label)[] examples = [ ("I was charged twice this month.", "Billing"), ("The export button crashes the app.", "Bug"), ("Please add dark mode to the dashboard.", "Feature"), ("My invoice shows the wrong company name.", "Billing"), ]; var messages = new List<ChatMessage> { new SystemChatMessage("Classify the support ticket as exactly one of: Billing, Bug, Feature. Reply with the label only.") }; // Each example becomes a user message followed by the assistant's ideal reply foreach (var (text, label) in examples) { messages.Add(new UserChatMessage(text)); messages.Add(new AssistantChatMessage(label)); } messages.Add(new UserChatMessage(newTicketText)); // the real input, answered in the same pattern ChatCompletion completion = await client.CompleteChatAsync(messages); 

- DIVERSE: cover the different categories and the tricky edge cases, not five near-duplicates. - REPRESENTATIVE: drawn from real inputs, matching what the model will actually see. - CORRECT: a wrong example teaches the wrong thing — the model imitates its examples faithfully. - CONSISTENT in format: if examples vary in structure, the output will too. - BALANCED: if 4 of 5 examples share one label, the model may be biased toward it. - ORDER can matter: the most recent examples sometimes carry extra weight, so don't accidentally put the same label last every time. 

Costs: every example consumes INPUT TOKENS on EVERY request. Ten long examples is a real, recurring cost (Section 7). Use as few as achieve the quality you need. Dynamic few-shot: instead of fixed examples, store a bank of labeled examples with embeddings and, per request, retrieve the few most SIMILAR to the new input. Often beats a fixed set for varied inputs, at the price of more machinery. When NOT to bother: simple, well-specified tasks on a capable model may work fine zero-shot — test before adding examples. Some reasoning-focused models also respond better to clear instructions than to many examples; check your model's guidance. Beyond a point: if you need dozens of examples to get consistent behavior, that's a signal to consider fine-tuning (Section 9) instead. 

You are a contract-review assistant. <instructions> Review the clause below and identify risks for the CUSTOMER. Respond only with the JSON described in <output_format>. If the clause is not a contract clause, return {"risks": [], "note": "not a contract clause"}. </instructions> <context> Customer is a small business. Jurisdiction: India. Focus on payment, termination, liability. </context> <clause> {clause text} </clause> <output_format> {"risks": [{"issue": string, "severity": "low" | "medium" | "high", "explanation": string}]} </output_format> 

- SEPARATION: delimiters (XML-style tags, Markdown headers, triple quotes) clearly mark where instructions end and untrusted data begins — which reduces confusion and gives you a (partial) defense against prompt injection. - REFERENCE: you can refer to sections by name ("using only the text in <context>"). - MAINTAINABILITY: each section can be edited, tested, and templated independently. - CONSISTENCY: the same skeleton across many tasks makes prompts predictable to write and review. 

Prompted JSON ("reply in JSON") works most of the time — and fails in production when a stray sentence or missing field breaks your parser. For anything your code consumes, prefer the API's STRUCTURED OUTPUTS feature (schema-constrained JSON) over prompt wording alone, then still validate the values (see AI APIs with .NET, Section 7). Remember: a schema guarantees SHAPE, not TRUTH. 

Instead of one giant prompt, split a job into stages, each with a focused prompt, passing output forward — and checking it between stages with ordinary code: 1. EXTRACT pull the key facts from the document (structured output) 2. VALIDATE check them in code against rules/databases 3. ANALYZE reason over the validated facts 4. DRAFT write the final response in the required tone Benefits: each step is simpler to prompt, test, and debug; failures are easier to locate; you can use a cheaper model for easy stages; and code can enforce rules between steps. Cost: more calls, more latency, more plumbing. 

// Build prompts from templates, not scattered string concatenation const string Template = """  <instructions>{0}</instructions> <document> {1} </document> """;  string prompt = string.Format(Template, instructions, documentText); 

Context window >= system prompt + conversation history + retrieved documents / tool results + tool definitions + the user's new message + the model's OUTPUT 

COST: you pay for every input token, on every request. Resending a 100-page document with each question multiplies cost quickly. LATENCY: more input tokens generally means slower responses. QUALITY: models do not use all parts of a long context equally well. Research has shown that information buried in the MIDDLE of a very long prompt can be used less reliably than information near the beginning or end, and that adding lots of irrelevant text can degrade answers. The effect varies by model and has improved over time, but "more context" can still mean "worse answers." GUIDELINE: include what's RELEVANT, not everything that's AVAILABLE. 

RETRIEVAL (RAG) Store documents in chunks with embeddings; per question, retrieve only the top few relevant chunks and include those. The standard approach for "chat with your documents." TRIMMING / SLIDING Keep only the most recent conversation turns (Section 10). WINDOW SUMMARIZATION Compress older context into a short summary and keep it plus recent turns. SELECTIVE TOOL Return only the fields the model needs from a tool, not an entire record. OUTPUT PLACEMENT Put the most important instructions and the question where the model attends well (typically at the start and/or restated at the end), and keep reference material clearly delimited. CHUNKING LONG For documents that exceed the window, process in pieces (map) and INPUT combine the results (reduce). 

If input fills the window, there's no space left for output and the reply is cut off (FinishReason = Length). Budget explicitly: available for input = context window - reserved output tokens - safety margin Count tokens BEFORE sending (Section 7) and trim to that budget deliberately, rather than discovering the limit via an error in production. 

Rule of thumb (English): 1 token ≈ 4 characters ≈ 3/4 of a word "hamburger" -> may split into several tokens " the" -> usually a single token Numbers, code, and non-English text often use MORE tokens per unit of meaning. 

1. COST Billing is per token, with INPUT and OUTPUT usually priced differently (output typically costs more). 2. LIMITS The context window and rate limits (tokens per minute) are measured in tokens. 3. SPEED Generation time grows with the number of OUTPUT tokens. 4. QUIRKS Because models see tokens, not letters, tasks like "count the letters in this word," exact character manipulation, and some arithmetic are unexpectedly error-prone. Do those in code. 

- Measure real usage from every response and log it. - Count tokens locally BEFORE sending (e.g. with a tokenizer library) to enforce budgets. - Remember that few-shot examples, long system prompts, tool definitions, and conversation history are all re-sent — and re-billed — on every request. - Set a maximum output token cap appropriate to the task. - Be aware that the same text can tokenize differently across model families, so token counts aren't directly comparable between providers. 

- FABRICATED FACTS invented names, dates, statistics, quotes - FAKE SOURCES citations, URLs, case law, or papers that don't exist - INVENTED CODE/APIS plausible-looking methods, parameters, or packages that aren't real - UNFAITHFUL SUMMARIES claims not actually present in the source document - WRONG REASONING confident, well-formatted, but flawed logic or arithmetic - STALE ANSWERS presenting out-of-date information as current 

Hallucinations are hardest to catch precisely because they LOOK right. Users trust fluent, confident text. In medicine, law, finance, security, and customer support, a confidently wrong answer can cause real harm — so the design goal is not "hope it's accurate" but "build a system where errors are made unlikely, visible, and survivable." 

1. GROUND THE MODEL IN SOURCE TEXT (RAG) Retrieve relevant documents and instruct: "Answer ONLY from the provided context." Far more reliable than relying on what the model memorized. This is the single most effective measure for factual applications. 2. GIVE IT PERMISSION TO SAY "I DON'T KNOW" "If the answer isn't in the context, say you don't know." Models often guess unless explicitly allowed to decline. 3. REQUIRE CITATIONS AND CHECK THEM Ask the model to quote or reference the supporting passage, then VERIFY in code that the quote actually appears in the retrieved source. A citation you don't verify is decoration. 4. LOWER THE TEMPERATURE For factual tasks, low randomness reduces (but doesn't eliminate) invention. 5. CONSTRAIN THE OUTPUT Structured outputs, enumerated labels, and validation against known values (does this product ID exist? is this a valid ISO currency code?) catch many errors in code. 6. USE TOOLS FOR FACTS AND MATH Don't let the model recall prices, balances, or dates, or do arithmetic — have it call a function that looks them up or computes them. 7. VERIFY HIGH-STAKES OUTPUT Second-pass checks (a separate "verifier" prompt or model), rule-based checks, and — where consequences are serious — a HUMAN in the loop before the answer is acted on. 8. COMMUNICATE UNCERTAINTY TO USERS Show sources, label AI-generated content, and don't present output as authoritative. 9. MEASURE IT Build an evaluation set with known answers and track a faithfulness / groundedness rate over time (Section 12). 

Answer the question using ONLY the information in <context>. Quote the sentence(s) that support your answer in a "sources" list. If <context> does not contain the answer, reply exactly: "I don't have enough information to answer that." Do not use outside knowledge. <context> {retrieved chunks} </context> <question> {user question} </question> 

Hallucinations can be REDUCED substantially but not ELIMINATED. Even with retrieval, a model can misread or misrepresent its sources. Design for it: validate, cite, verify, and keep humans in the loop where being wrong is costly. 

QUALITY How well does it perform on YOUR task? Public benchmarks are a rough guide; your own evaluation set is the real test (Section 12). LATENCY Time to first token and total generation time. Matters enormously for interactive chat; barely at all for overnight batch jobs. COST Price per input/output token. Multiply by your real traffic and prompt sizes. Large price gaps exist between model tiers. CONTEXT WINDOW Can it hold the documents/history your use case needs? (Section 6) CAPABILITIES Tool/function calling, structured outputs, vision or audio input, streaming, fine-tuning support, reasoning mode — only what you need. RELIABILITY Instruction-following consistency, rate limits and quotas, and provider uptime/support. DATA & COMPLIANCE Where data is processed and stored, retention and training policies, regional availability, certifications, private networking (a major reason to use a managed cloud offering such as Azure OpenAI). OPEN vs. CLOSED Open-weight models can be self-hosted (control, privacy, no per-token fee, but you own the infrastructure and operations). Hosted proprietary models are simpler to operate and often state-of-the-art, at a per-use price. 

1. DEFINE the task and what "good" means (accuracy target, latency budget, cost ceiling). 2. BUILD an evaluation set of realistic inputs with expected outputs or grading criteria. 3. START with a capable model to find out what's achievable. 4. TRY cheaper/smaller models on the same set — you may find a small model is good enough. 5. COMPARE on quality, latency, and cost together, not quality alone. 6. DECIDE, then re-evaluate periodically: models and prices change fast. 

MODEL ROUTING Send easy requests to a cheap model, hard ones to a stronger one, based on task type, input complexity, or a quick classifier. Often the largest cost saver. CASCADE Try the cheap model first; escalate only if its output fails validation or confidence checks. RIGHT MODEL PER Use a small model for classification and routing, a stronger one for final STAGE synthesis, a dedicated embedding model for retrieval. SPECIALIZE LAST Prefer prompting, then retrieval (RAG), and only then fine-tuning: prompting is cheapest to iterate; RAG gives fresh, citable knowledge; fine-tuning is best for consistent style, format, or narrow behavior — not for teaching the model new facts reliably. 

- Keep model names, parameters, and prices in CONFIGURATION, not code. - Put calls behind an interface (for example Microsoft.Extensions.AI's IChatClient) so providers can be swapped. - Plan for DEPRECATION: providers retire model versions on a schedule, so pin versions where you need stability, track retirement notices, and re-run your evaluation set before migrating. - Beware "prompt lock-in": prompts tuned to one model may need re-tuning on another. 

SHORT-TERM MEMORY The current conversation: the recent turns resent with each request. LONG-TERM MEMORY Information that persists ACROSS conversations: user preferences, facts about the user, past decisions, accumulated knowledge — stored outside the model and retrieved when relevant. 

FULL HISTORY Resend every turn. Simplest and most faithful — until cost and the context window make it impractical. SLIDING WINDOW Keep only the last N turns (or last N tokens). Simple and cheap, but the model forgets anything older. SUMMARIZATION Condense older turns into a running summary, and keep the summary plus recent turns verbatim. Preserves the gist at bounded size, at the cost of an extra model call and some detail loss. HYBRID Summary of old turns + recent turns verbatim + retrieved long-term facts. The usual production answer. 

public record Turn(string Role, string Text); public class ConversationMemory { private readonly List<Turn> _recent = new(); private readonly int _maxRecentTurns; private string _summary = ""; public ConversationMemory(int maxRecentTurns = 8) => _maxRecentTurns = maxRecentTurns; public void Add(string role, string text) => _recent.Add(new Turn(role, text)); // Fold the oldest turns into the running summary when the window is exceeded public async Task CompactAsync(ChatClient client, CancellationToken ct = default) { if (_recent.Count <= _maxRecentTurns) return; int toSummarize = _recent.Count - _maxRecentTurns; string transcript = string.Join("\n", _recent.Take(toSummarize).Select(t => $"{t.Role}: {t.Text}")); var result = await client.CompleteChatAsync( [ new SystemChatMessage("Update the running summary of this conversation. Keep names, decisions, " + "user preferences, and open questions. Maximum 150 words."), new UserChatMessage($"Current summary:\n{_summary}\n\nNew turns:\n{transcript}") ], cancellationToken: ct); _summary = result.Value.Content[0].Text; _recent.RemoveRange(0, toSummarize); } public List<ChatMessage> BuildMessages(string systemPrompt) { var messages = new List<ChatMessage> { new SystemChatMessage(systemPrompt) }; if (_summary.Length > 0) messages.Add(new SystemChatMessage($"Summary of the earlier conversation:\n{_summary}")); foreach (var turn in _recent) messages.Add(turn.Role == "user" ? new UserChatMessage(turn.Text) : new AssistantChatMessage(turn.Text)); return messages; } } 

Typical design: 1. EXTRACT After conversations, pull durable facts worth keeping ("prefers metric units", "works in the finance team", "decided to use PostgreSQL"). 2. STORE Save them in a database, with an EMBEDDING for semantic lookup. 3. RETRIEVE On each new request, fetch the few memories relevant to the current question and add them to the prompt. 4. MAINTAIN Update facts that change, merge duplicates, and expire stale ones. 

- WHAT to remember: store durable, useful facts — not every utterance. - CONSENT AND TRANSPARENCY: tell users what is remembered, and let them view, correct, and delete it. Many privacy regulations require this for personal data. - SENSITIVE DATA: don't persist secrets, credentials, or unnecessary personal data. Minimizing what you store minimizes what can leak. - ISOLATION: memory must be strictly scoped per user/tenant — a retrieval bug that surfaces one user's memories to another is a serious data breach. - ACCURACY: summaries and extracted facts can themselves be wrong (hallucinated), and a wrong memory persists and compounds. Prefer storing the user's own words, and let users correct entries. - INJECTION: anything written into memory from untrusted content can later re-enter prompts — treat stored memories as untrusted data, not instructions. 

 ┌─────────────────────────────────────────────────┐ │ │ GOAL ─> THINK (what's the next step?) ─> ACT (call a tool) ^ │ │ v └──────── OBSERVE (read the tool result) ─┘ │ goal met? ──> FINAL ANSWER 

MODEL the "brain" that reasons and chooses actions TOOLS functions it can call: search, query a database, call an API, run code, send email MEMORY the running transcript (short-term) plus any retrieved long-term knowledge LOOP the orchestration code that feeds tool results back until done GUARDRAILS limits, permissions, and approvals that bound what it can do 

WORKFLOW The steps are fixed IN YOUR CODE; the LLM fills in individual steps (classify -> retrieve -> draft -> validate). Predictable, testable, cheaper. AGENT The LLM chooses the steps dynamically at runtime. Flexible, handles open-ended tasks — but less predictable, harder to test, slower, and more expensive. Guidance: if you can describe the steps in advance, build a WORKFLOW. Reach for an agent only when the path genuinely can't be known up front. Many "agent" use cases are better served by a well-designed workflow, and the most reliable systems often combine both: a workflow that invokes a bounded agent for one open-ended step. 

public class SimpleAgent { private const int MaxSteps = 8; private<...