📊 View Lecture Slides Full-screen presentation with navigation

Session 4: Context Engineering

Session Duration: 2 Hours     Block: 1 — Foundations & The Exocortex

Session clock

Minutes Mode Focus
0–50 Lecture Theoretical Foundation & Concepts
50–110 Core lab Data Formatting & Ingestion
110–120 Checkpoint Pair share / show artifact

Note: Stretch work starts only after the Core checkpoint is completed.

Learning Objectives

By the end of this session, students will be able to:

  • Explain the critical distinction between prompt engineering (instructions) and context engineering (information payload).
  • Design reusable Markdown templates for structuring raw knowledge before it is ingested by an AI model.
  • Apply specific formatting techniques to transform messy, unstructured web content into clean, AI-ready data.
  • Identify context design choices that actively reduce hallucination rates and improve response relevance.

Part 1: Theoretical Foundation — Designing What the AI Sees

1.1 Prompt Engineering vs. Context Engineering

In Session 2, we covered Prompt Engineering—the art and science of instructing the model on how to behave (its persona, formatting constraints, and step-by-step logic).

Today, we focus on Context Engineering—the art and science of designing the information payload you feed the model so it actually knows the answer to your prompt.

If prompt engineering is about giving the model a good recipe and telling it how to cook, context engineering is about providing the highest quality ingredients. The fundamental principle of AI data processing applies here: Garbage in, garbage out—at scale.

If your knowledge base (your exocortex) contains poorly formatted, redundant, or contradictory information, your AI application will reflect that confusion. Conversely, if your context is clean, semantically structured, and highly relevant, the AI has the best possible chance of producing an accurate, grounded, and useful response. Context engineering is the unsung hero of reliable AI products.

1.2 The Context Window as a Hard Constraint

Every Large Language Model has a context window. This is the absolute maximum amount of text (measured in tokens) the model can hold in its “working memory” during a single API call.

Tokens are sub-word units. As a rule of thumb, 1 token ≈ 0.75 words in English.

Tokens Approx. Word Count Practical Equivalent
4,000 ~3,000 words A short essay or a few long articles.
32,000 ~24,000 words A short corporate report or detailed manual.
128,000 ~96,000 words A small book (e.g., The Great Gatsby).
1,000,000+ ~750,000 words A massive textbook or an entire small codebase (e.g., Gemini 1.5 Pro).

Even with modern models boasting 1-million-token windows, you cannot simply dump your entire uncurated hard drive into every prompt. Why?

  1. Cost: API pricing is typically calculated per token processed. Sending 1 million tokens for a simple query is financially unviable for a production app.
  2. Latency: Processing massive context windows takes significantly longer, leading to poor user experiences.
  3. The “Lost in the Middle” Phenomenon: Research shows that LLMs are excellent at recalling information at the very beginning and very end of a massive prompt, but often ignore or “forget” information buried in the middle of a massive context dump.

Therefore, for RAG (Retrieval-Augmented Generation) systems, you must:

  1. Retrieve only the most relevant sections of your knowledge base.
  2. Format those sections as efficiently as possible.
  3. Fit them alongside the user’s query and system instructions.

1.3 Principles of Well-Engineered Context

To ensure the AI extracts exactly what it needs from your data, follow these four principles when structuring your Obsidian vault:

Principle 1: Ruthlessly Remove Redundancy Duplicate information wastes valuable context tokens and can confuse the model, especially if the duplicates contradict each other slightly. If the same fact appears in three different notes, consolidate it into one definitive source.

Principle 2: Be Explicit About Structure AI models are trained on structured data (HTML, Markdown, code). They perform significantly better when sections are clearly labeled using semantic markers. Use Markdown headings (#, ##), bullet points, and explicit key-value labels.

Example of Poor Context (Implicit Structure):

The premium subscription costs £12. It comes with cloud sync and priority support. You can cancel it within 30 days.

Example of Strong Context (Explicit Structure):

## Subscription Tier: Premium

- **Price:** £12/month
- **Features Include:** Cloud Sync, Priority Support
- **Refund Policy:** 30-day cancellation window

Principle 3: Always Include Metadata Metadata provides crucial signals that help the model weight information correctly. A date stamp prevents the model from giving outdated advice. A source link grounds the information.

> **Source:** Official API Documentation v2.4
> **Last Updated:** 2024-06-15
> **Domain:** Backend Integration

Principle 4: Chunk Logically by Semantics When building a knowledge base, break long documents into semantically coherent “chunks” or atomic notes. A single chunk should ideally answer one specific type of question. Avoid arbitrary character-length splits (e.g., cutting a sentence in half just because it hit a 500-character limit), as this destroys context.

1.4 The Context Template Pattern

To maintain discipline across a growing exocortex, AI engineers use Context Templates. A context template is a reusable Markdown structure that ensures all notes in a specific category follow the exact same format.

Here is an example template for a course knowledge assistant:

---
topic: [Topic Name]
type: [concept | procedure | example | definition]
related: [[related-note-1]], [[related-note-2]]
---

## Core Idea

[A one-sentence summary of the main point. The AI reads this first.]

## Detailed Explanation

[2–4 paragraphs of clear, structured explanation.]

## Key Terms

- **Term 1:** Definition
- **Term 2:** Definition

## Concrete Examples

[A concrete example, code snippet, or case study.]

## Common Pitfalls

[What people typically misunderstand or do wrong.]

Every note written in this format contributes high-quality, highly retrievable context to your eventual AI system.

Part 2: Practical Labs — Format Web Data for AI Ingestion

_Time-box recommendation: Lab 4.1 (≤20 min) Lab 4.2 (≤25 min) Lab 4.3 (≥15 min)_

Lab 4.1 — Clean a Raw Web Page

AI models struggle when fed raw, uncleaned HTML or copy-pasted web text containing ads, navigation menus, and footer links. This lab teaches you manual data cleaning, a precursor to automated scraping.

Task:

  1. Find a Wikipedia article, a software documentation page, or an industry blog post highly relevant to your chosen project idea.
  2. Copy the entire raw text of the page and paste it into a new note in your Obsidian 04-References/ folder.
  3. Clean it: Delete all navigation text, footer content, sidebar menus, and any metadata that adds zero informational value.
  4. Structure it: Apply clear Markdown headings (##, ###) to denote sections.
  5. Format data: Convert any messy lists or tables into proper Markdown table format.
  6. Add Metadata: Add a frontmatter YAML block at the very top with topic, type, and source_url fields.

Lab 4.2 — Apply the Context Template

Using the Context Template provided in section 1.4, transform the raw information from your project domain into structured notes.

Task:

  1. Create one full, complete note for your project domain (choose whether it is a concept, procedure, or example). Fill out every section of the template thoroughly.
  2. Create two stubs (notes that only have the Title, Metadata, and the “Core Idea” sentence filled out) for two related concepts. (You can finish these later as Stretch work).

Lab 4.3 — Test Context Quality (Mandatory)

This is where you prove that context engineering works. We will run an A/B test using Google AI Studio.

  1. Open Google AI Studio and start a new Freeform prompt.
  2. Test A (No Context): Ask a highly specific question that is answered deep within the structured note you just created. Do not provide the note. See what the model outputs based purely on its training data. (It may hallucinate or give a generic answer).
  3. Test B (Engineered Context): Clear the prompt. This time, paste your beautifully structured Markdown note at the top of the prompt. Below it, write: “Based ONLY on the context provided above, answer the following question: [Your Question]”
  4. Compare: Document the differences in your 03-Project/prompts.md file. Which approach yields a more precise, grounded answer? Did the model respect your structure?

Key Takeaways

  • Context engineering focuses on designing the information fed to the AI, which is just as vital as the instructions (prompt engineering).
  • Context window limits require deliberate selection, filtering, and summarization of relevant content to save costs and reduce latency.
  • Well-structured Markdown—featuring explicit headings, semantic bullet points, metadata, and logical chunks—drastically improves AI output quality and reduces hallucinations.
  • Context templates ensure a consistent, high-quality knowledge base that an automated RAG system can easily digest.
  • Always test your context quality manually in a playground before writing the code to automate its retrieval.

Further Reading & Resources

  • “How to Think About Context Windows” — Anthropic’s excellent documentation on token limits and the “Lost in the Middle” problem.
  • Obsidian Templater Plugin — Look up documentation on how to automate the insertion of the templates you designed today.