Why This Matters
Most real AI system failures are misdiagnosed. A team blames the prompt when the retrieved context is stale. They blame the model when the tool surface is too broad, the verifier is missing, or the loop has no clean stopping condition. They ask for a larger model when the real problem is that the surrounding system is making the model solve the wrong task.
That diagnosis problem is why the trilogy matters. Prompt engineering was the obvious first discipline because early LLM work happened one inference at a time: write a better instruction, get a better answer. Production agent systems retrieve, compress, route, call tools, inspect state, ask for approval, retry, recover, and terminate. The engineering work has moved from phrasing a request to controlling the operating conditions around repeated model calls.
This curriculum teaches that movement as a diagnostic stack. Prompts shape a single inference. Contexts shape what the model can know and attend to at each inference. Harnesses shape what the whole system can do over time. Students who learn the stack can debug systems without superstition: they can ask whether the failure is elicitation, context construction, or control flow, then improve the layer that actually failed.
Three Layers of Increasing Control
Prompts are instruction artifacts consumed by a model call: instructions, few-shot exemplars, role framing, output-format cues, and reasoning triggers. Prompt engineering shapes how a model interprets and responds within that call. As frontier models have grown less sensitive to phrasing, the marginal value of this work has become more situational and more dependent on the surrounding system.
Context is the complete assembled input and state exposed to a model call: the prompt, retrieved documents, distilled memory, tool descriptions, compacted history, and examples drawn from a bank. Context engineering manages that input as an artifact, whether it is assembled manually or by code. Token budgeting, RAG, semantic caching, memory hierarchies, and context compression all live here.
A harness is the software control layer that assembles context and coordinates model calls, tools, state, verification, permissions, and termination over time. It owns decisions such as when to invoke the model, which tools to expose, how to route and verify outputs, when to retry or spawn subagents, and how to sandbox side effects. Claude Code's agent loop, Cursor's editing logic, Devin's planner, and Proceda are harnesses in this sense.
In agentic systems, these artifacts are nested at runtime, but the engineering disciplines overlap rather than forming strict ontological subsets. This curriculum adopts prompt → context → harness as a model of increasing control scope, not as the field's only accepted taxonomy.
Context Engineering Inside a Harness
Within an agentic harness, every step of the loop requires a decision about what window to present to the next inference: which tool descriptions to include (all of them blows the budget; route-then-load is the standard move), which prior turns to keep verbatim vs. summarize, which retrieved docs to inject, which scratchpad/memory entries are still live, and which skill files (SKILL.md and friends) to load. Those decisions are context engineering, made anew on every iteration. A harness without a context policy would just concatenate history until it OOMs.
Context engineering also exists outside agentic harnesses: a classical one-shot RAG pipeline still assembles and manages context. Harness engineering begins when a software control layer coordinates model calls, state, tools, verification, and termination over time. The distinction is one of responsibility and control scope, not strict containment between disciplines.
At higher layers, context engineering becomes a policy: what to load depends on the agent's trajectory. That's where just-in-time skill loading, progressive disclosure of tools, and dynamic compaction live, and it's also where many current reliability gains are coming from.
Agents, Scaffolds, and Harnesses
This curriculum uses an agent as the (model, harness) pair operating over an environment. The model supplies the policy — token-level decisions about what to say or which tool to call. The harness supplies everything else needed to turn those decisions into sustained, goal-directed behavior over time: the loop, the tools, the memory, the verifiers, the termination conditions, and the recovery logic. Without the harness, the system reduces to a model call. Without the model, it reduces to a workflow engine. The agent is the composition.
This gives the curriculum a clean arc. Prompt engineering teaches students to shape a single inference. Context engineering teaches them to shape what the model sees across many inferences, treating the window as a managed resource. Harness engineering teaches them to wrap those inferences in a control program that closes the loop with an environment. The agent definition then follows naturally: an agent is a harness whose context-engineering policy and tool-use trajectory are conditioned on its own prior outputs and on environmental feedback. The progression mirrors the move from open-loop to closed-loop control.
One useful framing: the three layers correspond to three different loci of programming. In prompt engineering, the primary artifact is an instruction. In context engineering, it is the assembled model input plus the process that assembles it. In harness engineering, it is a control program with the model as a callable. Their responsibilities overlap, but each step outward increases the scope of what engineers can explicitly control. Agents appear when that outer program is structured as a perception-action loop.
Scaffold vs. harness
They overlap heavily but the connotations differ, and the drift in usage tracks a real shift in what people are building.
Scaffold came out of the early AutoGPT / BabyAGI / ReAct era and carried the metaphor faithfully: temporary supporting structure around a model with limited planning, memory, and recovery. The connotation was compensatory: add a planner, a memory store, a reflection step. The implicit promise was that better models would eventually let the scaffolding come down, the way construction scaffolding comes down once a building can stand on its own. METR and ARC Evals popularized scaffold in the eval context for roughly this reason: they wanted to measure raw model capability and treated the surrounding code as a confound to be controlled.
Harness has displaced it over the last year or so, and the change in metaphor is doing real work. A harness is permanent apparatus for channeling a powerful system toward useful work; the metaphor points to engines, reactors, and other systems that need durable control surfaces. The surrounding program becomes a first-class engineering artifact whose design determines what the system can do. That matches the empirical record: scaling models alone has left surrounding code in place, and better models have raised the ceiling for well-designed loops. Claude Code, Cursor, Devin, and the SOP-Bench-style systems are harnesses in this sense.
Scaffold and harness remain near-synonyms in many uses, but the shift in framing requires explicit treatment. The scaffold framing predicts that capability gains erode the surrounding code's value; the harness framing predicts that capability gains increase the value of good surrounding code because a more capable model can be pointed at harder problems by a better-designed loop. Which framing turns out to be right is one of the live empirical questions in the field.
The Emerging Literature
The interesting feature is that the field hasn't fully settled — there are at least three competing structural framings even among the canonical pieces. Here is the lineage.
Context engineering — well-established canon
The term has a clean origin story. Tobi Lütke (X, June 18, 2025) argued that context engineering described the core skill more accurately than prompt engineering because the task is to provide enough situational material for the model to solve the problem. Andrej Karpathy amplified the term a week later (X, June 25, 2025) with the context-window formulation that became canonical. Simon Willison codified it on his blog three days later and predicted, correctly, that it would have sticking power. The Lütke-Karpathy-Willison triad is the citation chain most commonly used for the term's popularization.
The institutional follow-up: Anthropic's Effective context engineering for AI agents (Sept 2025), Lance Martin's Context Engineering for Agents on the LangChain blog (the write/select/compress/isolate taxonomy), and Philipp Schmid's Context Engineering Part 2 (2025).
The research follow-up is now concrete. Agentic Context Engineering, already part of the context course, treats context as an evolving playbook rather than a repeatedly rewritten prompt blob. Meta Context Engineering moves one level up and co-evolves the context-engineering skill with the context artifacts it produces. Together they turn context construction into an optimization target, not just a hand-tuned retrieval recipe.
Harness engineering — much more recent, more contested
This one is six months old and the term entered the mainstream through a specific sequence:
- Anthropic, Effective harnesses for long-running agents (Nov 26, 2025). First use of "harness engineering" from a frontier lab in a substantive piece.
- OpenAI, Harness engineering: leveraging Codex in an agent-first world (Feb 11, 2026). The post that put the term in everyone's mouth. The three-engineer, million-line codebase, zero-typed-code anecdote became the field's reference point.
- LangChain, Improving deep agents with harness engineering (Feb 17, 2026). The Terminal Bench 2.0 result — same GPT-5.2-Codex, score moves from 52.8% to 66.5% by changing only the harness, agent climbs from rank 30 to top 5. This became the headline empirical claim.
- Vivek Trivedy / LangChain, The Anatomy of an Agent Harness (March 10, 2026). The clearest definitional piece, the source of the canonical model-plus-harness formula, and the best single primary source on the harness-vs-agent relation.
- Birgitta Böckeler, Harness engineering for coding agent users deserves separate treatment because it uses a different framing: a user harness for coding agents as a specific form of context engineering, organized around feedforward guides, feedback sensors, computational vs. inferential controls, and regulation categories such as maintainability, architecture fitness, and behavior. This is a minority view but it's the most theoretically careful.
- Avi Chawla, The Anatomy of an Agent Harness (April 2026). A different essay with the same title — synthesizes Anthropic, OpenAI, LangChain, and Perplexity into eleven harness components. Recovers Beren Millidge's 2023 model-as-CPU, context-as-RAM, harness-as-OS analogy as the structural backbone.
Harness optimization — the 2026 research turn
Once prompts, contexts, and workflows are represented as editable artifacts, the machinery around the model can itself become the object of optimization. The search target moves outward in stages: instruction/prompt → structured context → workflow → harness code → optimizer code. Each stage asks a more powerful question — not only how to produce a better answer, but how to improve the system that produces, checks, remembers, and iterates on answers.
- AFlow: Automating Agentic Workflow Generation turns workflow design into search over code-represented graphs, using Monte Carlo Tree Search and execution feedback to refine agentic workflows.
- Meta-Harness: End-to-End Optimization of Model Harnesses makes the executable harness itself the search target, exposing prior code, scores, traces, and state through a queryable file system.
- Self-Harness: Harnesses That Improve Themselves closes the loop from execution traces to weakness mining, bounded harness edits, and held-out regression gates.
- Darwin Gödel Machine evolves coding agents by modifying their own code and retaining an archive of successful variants as stepping stones for later improvements.
- Harnesses for Inference-Time Alignment over Execution Trajectories is the necessary counterweight: decomposition and guidance can help, but over-decomposition, over-pruning, and hallucinated execution can make a more elaborate harness worse.
Lilian Weng, Harness Engineering for Self-Improvement (July 2026). The current synthesis of this optimization ladder, connecting workflow automation, file-backed state, subagents, harness search, and recursive self-improvement.
The all-three-together pieces
These are the articles that try to draw the exact map this curriculum has been building:
- Louis Bouchard, Harness Engineering: The Missing Layer Behind AI Agents (March 25, 2026). The clearest of the popular explanations, organized around the distinction between asking, supplying context, and operating the whole system.
- Atlan, Prompt vs Context vs Harness Engineering: Key Differences. Explicit nested-stack framing with the CPU/RAM/operating-system analogy. Useful because it acknowledges definitional instability directly.
- Epsilla, The Third Evolution: Why Harness Engineering Replaced Prompting in 2026. Periodizes the three phases (Prompt 2022–24, Context 2025, Harness 2026). The cleanest historical framing for week one.
- PrivOcto, Prompt Engineering vs Context Engineering vs Harness Engineering: What's the Difference in 2026? (March 2026). Argues the strongest subsumption claim: context engineering belongs inside harness engineering. This is the most aggressive nested-hierarchy reading.
- Rajnandan, Agent Harness Engineering vs Context Engineering vs Prompt Engineering. The most useful popular account for course purposes because it's framed around the misdiagnosis problem: teams often blame prompts or models when the actual failure lives in stale context or weak runtime design.
On the harness-vs-agent question specifically
The clearest direct treatments:
Agent = Model + Harness. The agent is the emergent behavior; the harness is the machinery producing it.
Three observations
First The practitioner literature named the discipline first, but the academic literature is now arriving around optimization targets: context, workflow, harness code, optimizer code, and joint harness/weight updates. Blog posts still define much of the engineering vocabulary; papers increasingly define the search spaces, failure modes, and evaluation claims.
Second Definitional instability is substantive. The nested-stack framing (prompt ⊂ context ⊂ harness) is dominant, but there are at least three serious challengers: Böckeler's "user harness as a specific form of context engineering," PrivOcto's "context is a subset of harness", and a less-articulated view in which all three are parallel disciplines that overlap. The framing this curriculum uses — three nested layers with the agent as the (model, harness) composition operating over an environment — is the most common reading, with competing readings still active. Böckeler and Trivedy give students the cleanest contrast between the main positions.
Third The trilogy framing remains nonstandard, though it lines up with the literature's current direction. The closest published analog is Avi Chawla's Anatomy of an Agent Harness piece, which uses the same three-concentric-rings framing. A careful unification piece could still claim open ground, especially if it addresses the Böckeler position and the Natural-Language Agent Harnesses challenge to the layer boundary. The field has the vocabulary but no single canonical reference that unifies the three layers carefully.
Two framing readings for lecture one
The canonical survey — Schulhoff et al., The Prompt Report: A Systematic Survey of Prompt Engineering Techniques — is a PRISMA-style review of 1,565 papers, producing a vocabulary of 33 terms and a taxonomy of 58 text-only techniques (plus 40 multimodal). It's the single most useful reference document for the syllabus and belongs early as a map of the territory. The companion site is the navigation aid.
The historical framing — Schluntz & Zhang's Building Effective Agents and Anthropic's Effective context engineering for AI agents (revisited from the other two courses) — together make the case that prompt engineering is the natural progression's first layer in a larger stack. Week one establishes why the discipline exists and why its scope has shifted.
Define prompt boundaries and how the field arrived at the term. Cover the pre-GPT-3 prompting literature (cloze prompts, PET) briefly, then the discontinuity introduced by in-context learning.
Prompt engineering depends on in-context learning, so the discipline's possibilities and limits track ICL's properties. Cover the founding empirical observation, the mechanistic theory, and the unsettling results about what makes ICL work, many of which surprise practitioners.
The most-used technique in the entire syllabus. Cover exemplar selection, ordering effects, the calibration problem, and the smaller-but-real returns as models improve.
LabReplicate a small order-sensitivity experiment on a current model. The result is usually weaker than it was in 2022, which is itself a lesson in how the field has evolved.
CoT is the canonical example of a prompt technique that elicits a model capability. Cover the original paper, the scaling result that gave it weight, and the close-reading of why it works.
Once CoT showed exemplars weren't strictly necessary, a small zoo of zero-shot reasoning techniques followed. Treat them as a family: each is a different prompted control structure over the model's reasoning trajectory.
When a single sampled trajectory is unreliable, the next move is to draw many and aggregate. This module is where prompt engineering starts pressing against the boundary with harness engineering: the techniques here are inference-time control structures around the same prompt.
LabImplement self-consistency on a small reasoning benchmark, vary the sample count, and plot the accuracy/cost curve. The lab gives students a real sense of when ensembling pays for itself.
The "stylistic" half of prompt engineering: how role assignments, output-format directives, delimiter conventions, and structural cues shape behavior. Empirically real, often overstated by practitioners.
Machine-consumed output needs more than polite JSON instructions. Cover the spectrum from "ask nicely for JSON" to logit-masking with grammars.
Cover both attacker- and defender-side prompting. The defender side belongs in a prompt engineering course because the system-prompt design space is where most production defenses live (or fail).
Canonical readings
- Perez & Ribeiro, Ignore Previous Prompt: Attack Techniques for Language Models (2022). The original prompt-injection paper.
- Wei, Haghtalab & Steinhardt, Jailbroken: How Does LLM Safety Training Fail?, NeurIPS 2023. The clearest theoretical account; the "competing objectives" and "mismatched generalization" categories are the right vocabulary.
- Greshake et al., Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, AISec 2023. The IPI paper, which frames the attack surface as data flow through the application.
- Zou et al., Universal and Transferable Adversarial Attacks on Aligned Language Models (2023). GCG — gradient-based suffix attacks, the white-box bound on what prompt-level defenses can stop.
- Schulhoff et al., Ignore This Title and HackAPrompt, EMNLP 2023. The largest crowd-sourced jailbreak dataset; useful for labs.
The case against hand-authored prompts, treated as a discipline in its own right. The arc from APE to GEPA tracks the same intellectual move the rest of the field has made: from natural-language artifacts to programs that produce them.
Canonical readings
- Zhou et al., Large Language Models Are Human-Level Prompt Engineers (APE), ICLR 2023.
- Yang et al., Large Language Models as Optimizers (OPRO), ICLR 2024. The "take a deep breath" result is the canonical demonstration.
- Pryzant et al., Automatic Prompt Optimization with "Gradient Descent" and Beam Search (ProTeGi), EMNLP 2023.
- Yuksekgonul et al., TextGrad: Automatic "Differentiation" via Text (2024). The textual-backprop framing.
- Khattab et al., DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines, ICLR 2024.
- Agrawal et al., GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning (2025). The current frontier.
LabTake a hand-tuned prompt from Module 4 or 5 and optimize it with at least two different methods (e.g., APE + DSPy's MIPRO), reporting accuracy delta and search cost.
Prompt engineering for images, code, and audio. The discipline rhymes with text prompting but has distinctive failure modes that warrant a dedicated module.
The pedagogically honest closing module. As models have improved, the marginal return on careful prompt wording has become more situational; many techniques in this syllabus are best understood as responses to an era when models needed more explicit scaffolding to reason. The skills that endure are the ones that compose into something larger — exemplar curation feeds into context engineering, CoT becomes a unit of harness control flow, automatic optimization is the bridge to programmatic systems. End the course with this synthesis.
Final LabStudents take a single complex task they prompt-engineered earlier in the semester, refactor it as (a) a DSPy program and (b) a small harness in the style of the harness course, and write up which version produced better, more reliable, more maintainable results. The lab is the bridge between this course and the other two.
A Few Pedagogical Notes
This course is best taught with a note of intellectual honesty about its subject. A 2022-style prompt engineering course would have spent much more time on phrasing patterns; a 2026 version spends most of its time on the techniques that turned out to compose into something larger and on the empirical results that taught the field its limits. Four readings anchor that critical posture: the Sclar et al. formatting-sensitivity paper, the Min et al. demonstrations paper, the Huang et al. self-correction paper, and the Tam et al. format-restriction paper. Each undermines a piece of folk wisdom that practitioners still repeat.
The organizing question for the beginning and end of the course: which of these techniques would survive a hypothetical model that was perfectly calibrated and never needed reasoning scaffolding? Working through that question is how students learn to distinguish techniques that exploited capability gaps (most of Modules 4–7) from techniques that exploit something more structural about how transformers consume sequences (Modules 8 and 10). The first kind ages; the second kind compounds. Students who can tell them apart will be useful builders for the next several years regardless of what specific models they're working with.
Finally, the same continuous reading used in the context course applies here. Simon Willison's blog is the running practitioner narrative, and his prompt-injection tag in particular is the best ongoing chronicle of how the adversarial side of prompt engineering is actually playing out in production.
Two cross-cutting framings for lecture one
The finite-resource frame — Anthropic's Effective context engineering for AI agents — treats every token in the window as competing for finite attention, with the engineering question being which configuration of those tokens most reliably produces the desired behavior.
The theoretical frame — Mei et al., A Survey of Context Engineering for Large Language Models — gives the field a formal taxonomy across retrieval/generation, processing, and management, and grounds the discipline as something distinct from prompt engineering. The companion repo, Awesome-Context-Engineering, is the running bibliography for the rest of the course.
Establish the conceptual shift: prompt engineering optimizes a string, context engineering optimizes the entire assembled window as a managed artifact, and the latter is the natural progression once production systems start having state, retrieval, and tool outputs.
Why context engineering works at all. ICL is the mechanism that lets information injected at inference time change model behavior without weight updates; understanding its mechanics determines what context-engineering interventions are even plausible.
Canonical readings
- Brown et al., Language Models are Few-Shot Learners, NeurIPS 2020. The GPT-3 paper, and the founding empirical observation.
- Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, NeurIPS 2022. The simplest demonstration that context shape changes output.
- Xie et al., An Explanation of In-Context Learning as Implicit Bayesian Inference, ICLR 2022. The canonical theoretical lens.
- Olsson et al., In-context Learning and Induction Heads (Anthropic, 2022). The mechanistic story.
- Min et al., Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?, EMNLP 2022. The unsettling result: label correctness matters less than label distribution.
RAG is the canonical context-engineering operation: programmatically inject relevant external text into the window before the model sees the query. Cover the original architecture, the dense-retrieval substrate, and the modern survey.
Canonical readings
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. The founding paper.
- Karpukhin et al., Dense Passage Retrieval for Open-Domain Question Answering, EMNLP 2020. The DPR architecture that RAG used.
- Gao et al., Retrieval-Augmented Generation for Large Language Models: A Survey (2024). The naive → advanced → modular RAG progression.
- Khattab & Zaharia, ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT, SIGIR 2020. The important late-interaction alternative.
- Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection, ICLR 2024. RAG that knows when to retrieve.
The empirical realities that constrain the design space. Larger windows alone add capacity; position effects, attention dilution, and graceful-degradation patterns determine how useful that capacity is. This module is where students stop thinking "just put it all in."
LabReplicate a small-scale context-rot experiment on a model the students can call, plotting accuracy vs. context length on a fixed task.
What gets kept across turns, in what form, where? This module covers the cognitive-science-inspired typology and the canonical implementations. Distinguish carefully from the harness course's treatment, which focuses on when memory is loaded; here the question is how it's represented.
When the window fills up, something has to give. Cover summarization-based compaction, the failure modes (brevity bias, context collapse), and the recent push toward incremental, structured updates that preserve detail.
Tool descriptions and skill files are context that the model pays for on every step. Cover the tool-catalog explosion problem, routing-before-loading, and the skill-as-progressive-disclosure pattern.
The production constraint that shapes everything in agentic context engineering: a single token's worth of variation in a long prefix invalidates the KV cache for the whole suffix. Once students see this, many design choices in production agents become legible as cache-preserving moves, even when theory would suggest a different optimum.
The case against hand-authored prompts. Treat the prompt as the artifact, but produced by a program: signatures, modules, and optimizers that compile high-level specifications into the actual text the model sees.
LabTake a hand-authored prompt from an earlier module and re-express it as a DSPy program; compile against a small dataset and compare.
The frontier framing: context as a structured artifact that accumulates, refines, and prunes over time, followed by the next question: can the mechanism that builds that context evolve too? Connect ACE and Meta Context Engineering to Reflexion-style verbal RL and to the skill systems emerging in production.
Two long-form practitioner reports that reward close reading. Both compress more useful design lessons than any single paper in the syllabus.
How to measure context engineering. Distinct from agent-level benchmarks; the evaluations here isolate the contribution of the context-construction pipeline.
Final LabStudents take their semester project (some context-engineering pipeline of their choice — RAG, compaction, programmatic prompt construction, or a combination) and submit it against a held-out LongMemEval split, reporting variance across at least five runs.
A Few Pedagogical Notes
The two courses share a tight conceptual relationship: context engineering studies the artifact, the harness course studies the program that produces it. Most students will find the conceptual handoff cleanest if they take this course first. The throughline from week one is cost: every token in the window is paid for in money (input tokens), latency (prefill time), attention budget (the lost-in-the-middle problem), and cache invalidation (the Manus argument). Almost every design pattern in the syllabus is legible as a response to one of those four costs.
The syllabus resists organizing itself around RAG. RAG was the canonical context-engineering operation in 2020–2023, but the field has moved decisively toward (a) agentic settings where retrieval is one of many context-shaping operations and (b) long-horizon context management. RAG is Module 3, but Modules 4–12 are largely about what happens after the initial retrieve-and-stuff.
A recurring blog complements the formal readings: Simon Willison's tag for "context engineering" tracks the field in real time and provides the most accessible running narrative. It stays in the background reading throughout the course.
Two cross-cutting framings for lecture one
The externalization frame — Zhou et al.'s recent survey, Externalization in LLM Agents — treats memory, skills, protocols, and the harness as cognitive artifacts that offload internal model burden onto deterministic infrastructure. This is the cleanest theoretical lens for the whole course.
The harness-as-product frame — Anthropic's Building Effective Agents (Schluntz & Zhang, with reference implementations), MongoDB's The Agent Harness, and LangChain's The Anatomy of an Agent Harness — establishes that the LLM is a small fraction of any deployed system and that the surrounding code is a first-class engineering artifact.
Establish the three layers, the agent definition, the workflow/agent distinction, and the scaffold-vs-harness terminological shift. Set up the throughline: as model capability rises, engineering responsibility moves up the stack.
The canonical perception-action loop. Cover the original formulation, its few-shot prompting roots, and the move to tool-call APIs as first-class loop primitives.
LabImplement a minimal ReAct loop in ~100 lines, no framework. The lab makes the loop's brevity and the surrounding engineering visible.
Tool calls are the agent's action interface; their design dominates reliability. Cover schema design, description-as-prompt, error contracts, tool catalog scaling, and the MCP shift from static tools to dynamic discovery.
LabBuild a tool registry with three failure modes (bad args, missing resource, timeout) and observe how error message phrasing affects recovery.
The taxonomy of how multiple model calls compose. The Anthropic patterns (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) provide the vocabulary; the multi-agent research paper shows them in production.
The harness is responsible for everything the model cannot remember. Cover the cognitive-science-inspired typology (working / episodic / semantic / procedural), retrieval policies, and the recent push beyond static RAG toward continuum memory.
Context engineering as the per-step subroutine of the harness. Compaction, just-in-time loading, tool-description budgeting, progressive disclosure, skill loading.
LabImplement progressive tool disclosure with a router model selecting from N tool clusters before the main agent sees descriptions.
Inner loops that revise outputs before the harness commits them. The critical readings keep the pattern honest: self-correction without external feedback often fails, so the harness usually needs verifiers.
Once tools execute real code, blast radius dominates design. Cover prompt injection (direct and indirect), tool permission models, capability gating, and approval contracts.
When the loop deliberately yields control. Cover the design space (HITL vs HOTL, tool-level vs request-level approval, suspension vs approval), the durable-execution problem (waits of hours/days), and the principle that humans should move up the stack to review consequential decisions at the right abstraction rather than babysit every tool call.
Traces are required for harness debugging and become training data when the harness itself is optimized. Cover span hierarchy, OpenTelemetry as the substrate, the OpenInference semantic conventions that specialize OTel for LLM workloads, and file-backed run histories that preserve successful and failed trajectories.
LabInstrument the Module 2 ReAct agent end-to-end with OpenInference, deliberately introduce a bug, and find it in the trace. Preserve the failed run as a queryable artifact rather than overwriting it with the eventual success.
How to measure a harness. Cover end-to-end task benchmarks, the variance problem, the rigor problem, tool-level evaluation as distinct from end-to-end, and evidence chains from claim to source, run, code, and metric. A plausible deliverable is not a verified one.
Canonical readings
- Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024. The canonical coding agent benchmark.
- Yao et al., τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (Sierra, 2024). The pass^k reliability metric is the important contribution.
- Mialon et al., GAIA: A Benchmark for General AI Assistants, ICLR 2024.
- Zhou et al., WebArena: A Realistic Web Environment for Building Autonomous Agents, ICLR 2024.
- Zhu et al., Establishing Best Practices for Building Rigorous Agentic Benchmarks (2025). Required critical reading — documents how up to 100% relative error inflates leaderboard claims.
- Meng et al., ScientistOne: Towards Human-Level Autonomous Research via Chain-of-Evidence (2026). The evidence-chain reading: its audit found hallucinated-reference rates up to 21%, score verification as low as 42%, and method-code alignment between 20% and 80% in baseline research agents.
- Starace et al., PaperBench (2025). Long-horizon research replication with author-developed rubrics; useful for testing whether the harness preserves evidence and executable artifacts.
End where the field is moving: from hand-authored loops to searched and self-improving harnesses. The Claude Code source exposure (March 2026) made a production harness publicly readable; the recent optimization papers turn context, workflows, and harness code into objects that agents can inspect, mutate, and validate.
The ladder for this week is: instruction/prompt → structured context → workflow → harness code → optimizer code. The practical lesson is not to let an agent rewrite everything. Keep evaluators, permissions, held-out tests, and promotion gates outside the editable surface.
Canonical readings
- WaveSpeed, Claude Code Agent Harness: Architecture Breakdown (2026).
- VILA-Lab, Dive-into-Claude-Code — a curated index of community analyses of the leak, including the systematic "Horse Book" mdBook framing it as a harness engineering case study.
- Weng, Harness Engineering for Self-Improvement (2026). The synthesis reading: workflow automation, file-backed memory, subagents, harness optimization, and the recursive self-improvement frame.
- Zhang et al., AFlow: Automating Agentic Workflow Generation, ICLR 2025. Workflow design as graph/code search with MCTS and execution feedback.
- Lee et al., Meta-Harness: End-to-End Optimization of Model Harnesses (Stanford, 2026). The harness as a search target, with source code, scores, traces, and state exposed through the file system.
- Zhang et al., Self-Harness: Harnesses That Improve Themselves (2026). Weakness mining, bounded edits, and regression-tested promotion; held-out Terminal-Bench 2.0 pass rates improved for all three tested models.
- Zhang et al., Darwin Gödel Machine (2025/2026). Open-ended evolution of coding agents through archived self-modifications.
- Wang et al., Harnesses for Inference-Time Alignment over Execution Trajectories (2026). The cautionary reading: more decomposition and guidance can reduce final task success.
- Zhang et al., General Modular Harness for LLM Agents in Multi-Turn Gaming Environments (2025). Ablations that quantify the contribution of perception / memory / reasoning modules separately.
Final LabStudents take their semester-long harness, instrument it on a small Meta-Harness-style outer loop, and report whether failure-driven automated edits beat their hand-tuned version on held-out tasks without regressing protected behaviors.
A closing bridge from general-purpose agent harnesses to domain-specific execution systems. Specialized harness engineering asks what happens when the task family is known well enough that the stable structure can move out of the model and into the runtime.
General-purpose harnesses maximize breadth: broad goals, broad tools, open-ended context gathering, and loose stopping conditions. Specialized harnesses live in the productive middle between deterministic workflows and fully open-ended agents. They assume the work has a recognizable skeleton — steps, branches, allowed actions, approvals, outputs, and failure states — but still needs model judgment for language understanding, fuzzy matching, exception handling, summarization, and local decisions.
The core move is to change the task the model sees. The runtime owns typed state, scoped tools, domain-specific context routing, policy gates, verification checks, structured outputs, and human review surfaces. The model receives a local objective with the smallest useful context and action surface. The result is usually cheaper, more inspectable, easier to audit, and easier to improve than asking a frontier model to improvise the whole procedure from a monolithic prompt.
Proceda's SOP execution architecture is the concrete case study. An SOP is parsed into explicit steps; each step receives only its own instructions and relevant tool schemas; the model advances by calling control tools such as complete_step() or request_clarification(); the executor manages transitions, approval gates, context trimming, output extraction, circuit breakers, and trace events. The SOP-Bench lesson is that procedural reliability can come from the harness absorbing planning and state-management burden, even with a smaller model.
The important caveat is that specialization is not the same thing as maximal decomposition. The trajectory-alignment view of harnesses separates task decomposition from guided execution and shows how over-decomposition, over-pruning, and hallucinated execution can reduce final task success. A good specialized harness moves stable policy, state, validation, and approvals into code while preserving model freedom where language ambiguity and exception judgment genuinely live.
LabBuild three versions of the same bounded SOP-like task: raw ReAct, a partial specialized harness, and a fully structured harness. Compare pass^k, token cost, failure categories, traceability, and whether one failure-driven harness edit improves held-out tasks.
A Few Pedagogical Notes
The course works best if labs accumulate one codebase across modules. By Module 12 students have an instrumented, sandboxed, multi-agent harness with memory and approvals, and they end by submitting it to automated optimization. The arc mirrors the field's actual move: from hand-authored loops to optimized infrastructure.
SWE-bench, τ-bench, and at least one custom domain benchmark appear from the start, so students re-evaluate the same harness across modules and see numbers move, plateau, or regress as they add components. The Module 11 readings on benchmark rigor land much harder when students have lived with their own numbers all semester.
Three readings recur throughout: Simon Willison's blog as a running practitioner narrative, Lilian Weng's LLM-Powered Autonomous Agents (2023) as the historical reference point, and Weng's Harness Engineering for Self-Improvement (2026) as the current map of the optimization frontier.
The Composition
The capstone starts with the definition, stated as cleanly as it can be:
An agent is the (model, harness) pair operating over an environment.
Everything in the three courses has been preparation for understanding why that definition is non-trivial. The model is what the prompt engineering course studied: a fixed function from a context to a distribution over next tokens. The harness is what the harness engineering course studied: a program that wraps that function in a loop, with tools, memory, control flow, and termination logic. The environment is whatever the harness reaches into through its tools — a file system, a browser, a database, an API surface, a human collaborator. The context engineering course studied the interface between model and harness: how the harness assembles, manages, and refreshes the token sequence the model sees on every step.
The definition has sharp consequences. Agent names the whole composition: model, harness, and environment together. A frontier model dropped into the wrong harness produces a worse agent than a weaker model in a well-designed one; the Meta-Harness paper's six-fold same-model performance gap is the empirical anchor for that claim. The environment is part of the definition: changing the environment changes what the agent is, as well as what it does. Improving any one component in isolation can still leave the agent worse, because the composition has dynamics that none of the parts have alone.
The clearest theoretical articulation of this composition is Sumers et al., Cognitive Architectures for Language Agents (CoALA) (2024), which formalizes language agents in terms of memory modules, action space, and decision procedure. It is the integrative reading for this lecture, with its diagrams providing the structure. Russell & Norvig, Artificial Intelligence: A Modern Approach, Chapter 2: Intelligent Agents supplies the older percept-action-environment vocabulary the field eventually rediscovered.
The historical arc: scaffold to harness
The terminological shift from "scaffold" to "harness" is the field's most legible signal that its understanding of what it's building has changed. The shift deserves careful treatment because it encodes a real intellectual claim, beyond style preference.
The scaffold era ran roughly from early 2023 through mid-2024. Its canonical artifacts are AutoGPT (Toran Bruce Richards, March 2023) and BabyAGI (Yohei Nakajima, April 2023), each a few hundred lines of Python that wrapped GPT-4 in a planning-and-execution loop with a vector store for memory. The framing was construction-site scaffolding: temporary structure around something still unable to stand on its own. The implicit prediction was that scaffolding would become unnecessary as models improved, the way construction scaffolding is removed once a building can bear its own weight. METR and ARC Evals adopted the term partly for this reason: they wanted to measure raw model capability and treated the surrounding code as a confound to be controlled.
The empirical record complicated that prediction. Models got much better over 2023–2026, while surrounding code became larger, more sophisticated, and more clearly a primary determinant of system behavior. Claude Code, Cursor, Devin, and the production systems studied in the harness course are first-class infrastructure. Their design choices — tool granularity, context compaction policy, approval contracts, sub-agent spawning rules — determine what the system can do.
The current era is the harness era. The metaphor is permanent apparatus that channels a powerful thing toward useful work: engines, reactors, and other systems that need durable control surfaces. Better models raise the value of good harness design. The same physical artifact — a loop, a tool registry, a memory store, a context manager — gets reinterpreted as the thing being built. The Externalization survey makes the same claim theoretically: memory, skills, protocols, and the harness itself are cognitive artifacts that offload internal model burden onto deterministic infrastructure, and that offloading is a permanent design feature.
The close reading compares Anthropic's Building Effective Agents, which almost never uses the word "scaffold," uses "agent" carefully and narrowly, and treats the surrounding code as the locus of design decisions, against AutoGPT's original README. The shift is visible directly in the prose.
An open empirical question anchors the section: was the scaffold framing wrong, or was it premature? The Meta-Harness result and the harness-engineering literature suggest scaffolds persist across the capability levels seen so far. But some future model may benefit less from external memory, external tools, or external control flow, at which point the harness may become more confound than capability. No compelling evidence settles it. The harness framing is currently winning because it matches the available data. The exercise asks students to argue both sides.
How the three layers compose into an agent
This is the integrative move the trilogy was building toward:
- A prompt is a fragment — an instruction, an exemplar, a tool description, a system message. In an agent, every prompt-engineered artifact ends up embedded in the harness as a template, a tool schema, or a piece of guidance that the harness emits to the model at the right moment. Prompt engineering is the discipline of designing those fragments. Most of what the prompt engineering course studied lives inside an agent as static assets the harness assembles from.
- A context is the entire token sequence the model sees on a given step — the prompt fragments plus everything the harness chose to include on this particular iteration. Context engineering is the discipline of policy: which fragments, which prior outputs, which retrieved documents, which tool descriptions, which compacted memory, all subject to finite-resource constraints and degradation curves. In an agent, context engineering is the per-step subroutine of the harness, run anew on every iteration.
- A harness is the program that runs the model in a loop, calls tools, applies the context policy, manages state, and decides when to stop. Harness engineering is the discipline of building that program.
An agent is what emerges when a harness operates over an environment in pursuit of a goal. The composition has properties no individual layer has:
- Trajectory-dependence. The same agent on the same task can take different paths through the environment depending on stochastic choices, environmental responses, and which retrieved or compacted artifacts the context policy surfaced. Reliability becomes a distribution, which is why τ-bench's pass^k metric is the right way to measure production agents.
- Closed-loop failure modes. Agents exhibit pathologies absent from single inferences: loops, goal drift, capability erosion under context rot, sub-agent cascade failures. These emerge from the dynamics of the composition, beyond what a prompt, context window, or static harness diagram can show.
- Emergent capability above the parts. The Manus team's observation that they "rebuilt the framework four times" while keeping the model fixed is evidence that agent capability is largely a harness-and-context property. The Meta-Harness six-fold gap is the same observation, formalized.
The clearest single reading on this synthesis is Lilian Weng's LLM-Powered Autonomous Agents (2023), now somewhat dated but still the cleanest narrative bridge from "LLM" to "agent" in the literature. Wang et al., A Survey on Large Language Model based Autonomous Agents (2024) supplies breadth, and Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models (2024) supplies the cleanest case study of an agent that does the integrative thing — accumulating skills the harness can later retrieve, blurring the line between context, harness, and model.
Where the frontier is heading
The course ends on three live questions.
First, the convergence of the three layers under automated optimization. GEPA and DSPy suggest prompts can be optimized. ACE and Meta Context Engineering suggest contexts and context-engineering skills can be. AFlow suggests workflow graphs can be. Meta-Harness, Self-Harness, and the Darwin Gödel Machine suggest harness code can be searched from execution history. The natural endpoint is a co-optimized stack where the boundaries blur because each layer is adjusted to a shared task signal. The Anthropic skills framing — SKILL.md files loaded by the harness on demand — is one production-grade instantiation: a skill is simultaneously a prompt fragment, a context-loading policy, and a piece of harness behavior.
The caution is equally important: trajectory-alignment harnesses show that decomposition and guided execution are not monotonic goods. The field is not converging on "more harness" as a slogan; it is converging on empirical harness design, where structure is added only when it improves reliability, cost, observability, or control on held-out tasks.
Second, agents in environments that contain other agents. Almost every reading in the trilogy assumes the environment is passive — a file system, an API, a webpage. As multi-agent systems become routine, the environment increasingly contains other agents whose harnesses are pursuing their own goals. The classical multi-agent systems literature (Wooldridge, An Introduction to MultiAgent Systems, 2009) is suddenly relevant again, and the harness designs that worked against passive environments often misbehave against active ones. This is one of the most likely sources of the next round of "harness engineering" failure modes.
Third, what scaffolding's prediction would even have looked like, if true. As a closing exercise, have students articulate what evidence would convince them that the scaffold framing was right: some capability threshold past which the surrounding code becomes more confound than capability. The exercise sharpens their thinking about the relationship between model capability and system capability, and inoculates them against the easy assumption that improvements in either are improvements in both.
Final integrative lab
Students bring forward the artifact each course produced — the prompts from the prompt course, the context-engineering pipeline from the context course, the harness from the harness course — and compose them into a single agent attacking a non-trivial task in a non-trivial environment. AppWorld or a custom domain works well. The deliverable is a paper about the system: students must report which design decisions belonged to which layer, which decisions cut across layers (and therefore which discipline's vocabulary fails to capture them), where the composition introduced behaviors none of the layers predicted, what their pass^k variance looks like over at least ten runs, and whether one failure-driven harness edit improved or regressed held-out performance. Claims must link back to source material, run artifacts, code revisions, and reproduced metrics.
The paper is the trilogy's exit exam. Students who can write it well will understand something most working practitioners miss: prompt, context, and harness engineering name adjacent regions of a single design surface, and the agent sits on top of all three.
A Closing Note for the Final Lecture
The trilogy was structured this way because the field arrived at it this way, painfully and in roughly this order. Prompt engineering came first because it was the cheapest way to get useful behavior out of a black-box model. Context engineering followed once context windows grew large enough that their contents became the bottleneck. Harness engineering became respectable only once it was clear that capable models still needed sustained, deterministic infrastructure around them to produce reliable systems.
The next layer — whatever it turns out to be — will get its own name once the field knows what to call it. The test for students is whether they can guess what that name will be. Correct guesses are most likely to come from building the thing before the field names it.