Add AI agent harnesses module

COURSE_MAP.md

@@ -13,8 +13,9 @@ The modules are ordered to build from supervised learning and data hygiene to hi
 | 8-10 | IV. Segmentation/object detection | II | Label quality, transfer learning, visual validation | Inspect and explain failed predictions |
 | 11-12 | Advanced-track selection: V. Reinforcement learning, VI. Generative models, or VII. Time-series forecasting | Foundations plus relevant prior module | Sequential decisions, synthetic data, or dynamic forecasting | Present hypothesis, baseline, and limitation |
 | 13-14 | VIII. PINNs | Calculus, differential equations, neural networks | Governing equations, inverse problems, model-form error | Modify a boundary condition and predict its effect |
+| 13-14 or a standalone lab | IX. AI agent harnesses | One prior programming-based engineering assignment | Tool boundaries, skills, MCP, plugins, verification | Defend a constrained workflow and reject an unsupported agent output |
 
-The advanced-track modules are alternatives in a typical one-semester offering. Module VI is under development, and Module VII requires a validation refresh before it is used as graded material.
+The advanced-track modules are alternatives in a typical one-semester offering. Module IX can also be used as a one- to two-week lab alongside a later project. Module VI is under development, and Module VII requires a validation refresh before it is used as graded material.
 
 ## Minimum competency standard
 

README.md

@@ -17,6 +17,7 @@ The course uses Python tutorials as the primary reproducible pathway. MATLAB tut
 - identify leakage, domain shift, model-form error, and failure cases;
 - connect model outputs to physical quantities, limits, and engineering decisions;
 - use generative-AI tools responsibly while independently verifying their outputs;
+- design and audit bounded AI-agent harnesses for engineering workflows;
 - communicate reproducible, evidence-bounded technical conclusions.
 
 ## Course map
@@ -31,6 +32,7 @@ The course uses Python tutorials as the primary reproducible pathway. MATLAB tut
 | [VI. Generative models](course_content/vi_generative_models/) | Evaluate when synthetic or reconstructed engineering data are credible | **Under development**; not yet a current assignment |
 | [VII. Time-series forecasting](course_content/vii_time_series_forecasting/) | Forecast boiling dynamics; sequence-to-sequence RNN/GRU/LSTM candidates | **Validation refresh required** before graded use |
 | [VIII. Physics-informed neural networks](course_content/viii_physics_informed_neural_networks/) | Solve and invert transient heat conduction; PINNs | Analytical/numerical verification, inverse estimate, failure audit |
+| [IX. AI agent harnesses](course_content/ix_ai_agent_harnesses/) | Constrain and verify AI-assisted engineering workflows; skills, MCP, and plugins | Harness specification, independent verification, failure audit, individual defense |
 
 See [COURSE_MAP.md](COURSE_MAP.md) for prerequisites, suggested sequencing, and instructor-facing assessment checkpoints.
 

course_content/ix_ai_agent_harnesses/ASSIGNMENT.md

@@ -0,0 +1,55 @@
+# Assignment: Harness-assisted engineering verification
+
+## Purpose
+
+Design and audit a narrowly scoped AI-agent workflow for an engineering calculation. Your grade reflects your engineering specification, verification, and defense—not how quickly an agent produces code.
+
+## Part A — harness design record (individual)
+
+Complete the [harness specification template](HARNESS_SPECIFICATION_TEMPLATE.md) for the assigned public-safe conduction fixture or an instructor-approved equivalent. State:
+
+1. the physical question, governing equation, variables, units, assumptions, and excluded physics;
+2. allowed files, tools, network status, write permissions, and prohibited actions;
+3. the chosen environment: approved commercial harness, approved local/open-source harness, or instructor-provided trace;
+4. the model/harness version or the supplied-trace identifier, date, and all AI assistance used;
+5. at least three acceptance tests, including one limiting-case or dimensional check;
+6. two foreseeable failures and the controls that prevent or reveal them.
+
+## Part B — audit and verification (individual)
+
+Using the approved boundary, ask the agent to review the fixture. Submit:
+
+- the unedited prompt and an AI-use record;
+- a short tool/file-access trace or the supplied transcript annotations;
+- the agent’s proposed diagnosis and any proposed diff;
+- your independent hand calculation and test results;
+- one accepted output and one rejected, corrected, or caveated output;
+- a 400–600 word engineering memo that states what the agent did, what you verified, what remains unvalidated, and why.
+
+## Individual defense
+
+Be prepared for a 5–8 minute individual defense. You may be asked to:
+
+- derive the conduction equation and explain its units;
+- modify one input or boundary condition and predict the direction of change before running code;
+- identify a tool permission that should be removed;
+- explain why a passing software test does not establish experimental validation;
+- diagnose an inserted mistake in an AI-generated explanation or calculation.
+
+## Grading
+
+| Criterion | Weight |
+| --- | ---: |
+| Physical formulation, units, assumptions, and acceptance tests | 30% |
+| Harness boundary, data/permission controls, and AI-use trace | 20% |
+| Independent verification and correct evidence classification | 25% |
+| Failure analysis and quality of rejected/caveated output | 15% |
+| Individual defense | 10% |
+
+## Rules
+
+- Use only public-safe course files. Do not provide credentials, student information, unpublished research, restricted datasets, sponsor material, laboratory-control access, or personal cloud content to an agent.
+- Do not enable unrestricted file writes, network access, or external connectors for this assignment.
+- An agent may assist only after you have written the physical contract in Part A.
+- A clean-looking notebook, a passing test, or an agent-generated report alone receives no credit for verification.
+- Follow the course [AI-use policy](../../teaching_resources/ASSESSMENT_AND_AI_POLICY.md) and submit the [AI-use record](../../teaching_resources/AI_USE_TEMPLATE.md).

course_content/ix_ai_agent_harnesses/CASE_STUDY_ME_RESEARCH_SKILL.md

@@ -0,0 +1,27 @@
+# Case study: the mechanical-engineering-research skill
+
+The public [mechanical-engineering-research skill](https://github.com/hanhuark/mechanical-engineering-research-skill) is a useful case study because it does not merely ask an AI agent to sound like an engineer. It packages domain-rigor instructions and references intended to make agents check assumptions, validity ranges, uncertainty, CFD credibility, data leakage, and claim strength in thermal-fluid work.
+
+## What students should study
+
+1. **Workflow scope.** Identify the task families it addresses: correlation use, CFD review, experiment planning, data analysis, research coding, and AI/ML credibility.
+2. **Rigor gates.** Find examples of checks that a generic coding assistant might omit: Reynolds/Prandtl/geometry validity ranges, mesh independence, boundary conditions, property models, uncertainty, and engineering tradeoffs.
+3. **Packaging.** Observe that the repository includes a skill, plugin metadata for more than one harness, workflow prompts, public-safe examples, tests, and validation guidance.
+4. **Evidence limits.** The skill can make a review more structured; it cannot create missing experimental data, establish a correlation outside its range, or turn a simulated result into a validated physical claim.
+
+## Suggested classroom exercise
+
+Give students the following deliberately overconfident claim:
+
+> A coarse-mesh CFD study proves a microchannel heat sink is optimal because its average Nusselt number is 40% higher than a baseline. The model uses constant water properties and does not report pressure drop, pumping power, grid independence, or experimental validation.
+
+Students should first review the claim without an agent. Then, using either an approved installation, an instructor-supplied output, or the repository’s public example, they compare the two reviews. They must identify:
+
+- which physical and numerical checks changed the conclusion;
+- what evidence is absent;
+- which conclusion can be supported now; and
+- what next computation or experiment would reduce the uncertainty.
+
+## Guardrail for this course
+
+Use public examples only. Do not install the skill into a workspace containing unpublished lab material or use it to upload confidential data. The learning outcome is the student’s ability to construct and assess the rigor gate, not merely invoke a named workflow.

course_content/ix_ai_agent_harnesses/HARNESS_SPECIFICATION_TEMPLATE.md

@@ -0,0 +1,54 @@
+# Harness specification record
+
+**Student:**  
+**Date:**  
+**Assignment fixture / trace identifier:**  
+**Harness type:** approved commercial / approved local-open-source / supplied trace  
+**Model and harness version (if known):**
+
+## 1. Physical task contract
+
+- Engineering question:
+- Governing equation(s):
+- Variables, symbols, and units:
+- Assumptions and system boundary:
+- Excluded physics / claims that are out of scope:
+
+## 2. Access and execution boundary
+
+| Category | Allowed | Not allowed | Evidence/log location |
+| --- | --- | --- | --- |
+| Files and data |  |  |  |
+| Tools/commands |  |  |  |
+| Network and connectors |  |  |  |
+| Writes and version control |  |  |  |
+| Human approvals |  |  |  |
+
+## 3. Prompt and workflow
+
+- Exact task request:
+- Required response format:
+- Stop conditions:
+- Tool calls or trace summary:
+
+## 4. Acceptance tests and independent checks
+
+| Check | Expected result | Result | Interpretation |
+| --- | --- | --- | --- |
+| Units/dimensional consistency |  |  |  |
+| Hand calculation / analytical solution |  |  |  |
+| Limiting or monotonic case |  |  |  |
+| Baseline or numerical test |  |  |  |
+
+## 5. Failure analysis
+
+| Plausible failure | Prevention/detection control | Did it occur? | What you changed or concluded |
+| --- | --- | --- | --- |
+| Unsupported physical assumption |  |  |  |
+| Incorrect units or equation |  |  |  |
+| Unauthorized or irrelevant tool/data access |  |  |  |
+| Unverifiable citation or claim |  |  |  |
+
+## 6. Evidence-bounded conclusion
+
+State separately what was implemented, what was verified, what was not validated, and what a responsible next check would be.

course_content/ix_ai_agent_harnesses/INSTRUCTOR_NOTES.md

@@ -0,0 +1,25 @@
+# Instructor notes
+
+## Access equity
+
+Offer three equivalent routes: an approved commercial account, an approved local/open-source configuration, or a supplied trace. Grade the specification and verification record, not tool access, token budget, model choice, or hardware performance.
+
+## Fixture design
+
+Keep the graded fixture private or rotate it by term. Use a public practice fixture and an instructor-held variant with different values, a seeded but plausible defect, and hidden tests. Avoid publishing answer keys or immutable diagnostic prompts in the student repository.
+
+## Permission controls
+
+- Begin read-only and offline whenever possible.
+- Confine writes to a disposable course directory or a student branch.
+- Do not grant browser, credentials, email, cloud-drive, institution, laboratory, or deployment access.
+- Require students to inspect proposed diffs and to record all material AI assistance.
+- Do not treat tool logs as surveillance or retain them beyond the instructional need; follow institutional policy.
+
+## Local/open-source pathway
+
+Local deployment should be an opt-in instructor-supported activity, not a requirement. Document the exact model, runtime, hardware/OS, quantization if relevant, prompts, tools, and versions if students compare runs. A local runtime may have tool-calling capability, but the instructor must still control the tool schema, permissions, data rights, and logs.
+
+## Assessment controls
+
+Use a short unassisted derivation or code-reading check before the assignment. After submission, conduct a brief individual defense using a perturbed case. Require students to predict the outcome before executing code and to explain one output they rejected. These checks measure transferable judgment more directly than AI-detection scores.

course_content/ix_ai_agent_harnesses/README.md

@@ -0,0 +1,74 @@
+# IX. AI Agent Harnesses for Engineering Workflows
+
+## Why this module exists
+
+An AI model is not an engineering workflow. An **agent harness** is the surrounding system that gives a model instructions, context, tools, permissions, and a way to record and verify work. This module teaches students to design and audit that surrounding system for a bounded engineering task.
+
+The goal is not to train students to hand an assignment to an agent. The goal is to help them decide what an agent may access or change, test its output against physics and data, and remain accountable for the resulting engineering claim.
+
+## Learning objectives
+
+After this module, a student should be able to:
+
+1. Describe the role of instructions, workspace context, tools, permissions, logs, and verification in an AI-agent harness.
+2. Compare a commercial hosted harness and a local/open-source deployment for a particular engineering task, including confidentiality, cost, capability, reproducibility, and operational burden.
+3. Write a constrained task specification that states the physical objective, units, inputs, allowed files/tools, prohibited actions, and acceptance tests.
+4. Distinguish a reusable **skill** (workflow instructions and resources), an **MCP server** (a protocol-based provider of tools/context), and a **plugin** (a distributable bundle that can include skills and connectors).
+5. Independently verify an AI-assisted calculation or code change against an analytical result, a baseline, and a stated engineering limit.
+6. Diagnose a failed or unsafe agent workflow: invalid assumptions, a false citation, improper data access, an unchecked tool call, or a result that passes a superficial test but violates physics.
+
+## Core concepts
+
+| Concept | Engineering interpretation | Required question |
+| --- | --- | --- |
+| Model | Produces candidate reasoning, code, or text | What evidence would make its output credible? |
+| Harness | Controls the model's context, tools, permissions, and execution loop | What is it permitted to read, write, run, or send? |
+| Skill | Reusable instructions, references, and optional helper scripts for a defined workflow | What domain checks must be followed every time? |
+| MCP server | A standard interface through which an agent can obtain context or call tools | What data, units, provenance, and side effects does each tool expose? |
+| Plugin | A distributable package that can bundle one or more skills and connectors | What capabilities become available after installation? |
+| Verification gate | Independent test before a result becomes an engineering conclusion | Does the output satisfy conservation, units, limits, and held-out evidence? |
+
+## Commercial and local examples
+
+The module uses examples to make the architecture concrete; it does not endorse a vendor or require a paid account.
+
+- **Commercial harnesses:** Codex and Claude Code are examples of coding-agent environments with project context, tool connections, and configurable behavior. Students may use an instructor-approved account only for public-safe, bounded class fixtures.
+- **Local/open-source harnesses:** a local model runtime, an agent client, a controlled workspace, and explicitly exposed tools can provide a local deployment. Ollama is one example of a runtime that documents tool calling. A local model does not automatically make a workflow private, reproducible, accurate, or safe; the data path, logs, model version, hardware, and tool permissions still matter.
+- **No-install path:** students without a supported commercial account or capable local hardware complete the same design, review, and verification work from an instructor-provided transcript/log. Access to a particular model must not determine the grade.
+
+## A safe engineering harness pattern
+
+```text
+Physical question and acceptance tests
+        ↓
+Task specification: inputs, units, scope, constraints
+        ↓
+Read-only public-safe fixture + limited tools
+        ↓
+Agent proposes analysis or change; all tool calls are logged
+        ↓
+Student review: assumptions, provenance, units, diff, tests
+        ↓
+Independent analytical/baseline check and individual defense
+        ↓
+Evidence-bounded engineering conclusion
+```
+
+Start with read-only access. Allow writes only inside a disposable course fixture or a student-owned branch after review. Do not connect this module to student records, unpublished data, sponsor-restricted data, institutional credentials, laboratory controls, email, cloud storage, or unsupervised web actions.
+
+## Course materials
+
+- [Harness design tutorial](TUTORIAL.md): an instructor-led walk-through of a safe agent workflow.
+- [Assignment: harness-assisted engineering verification](ASSIGNMENT.md): a two-part design, audit, and defense exercise.
+- [Case study: mechanical-engineering-research skill](CASE_STUDY_ME_RESEARCH_SKILL.md): a public example of domain-rigor instructions.
+- [Harness specification template](HARNESS_SPECIFICATION_TEMPLATE.md): the required design record.
+- [Instructor implementation notes](INSTRUCTOR_NOTES.md): access, privacy, and assessment controls.
+- [References and current product documentation](REFERENCES.md).
+
+## Recommended placement
+
+Use this as a one- to two-week advanced module after students have completed at least one programming-based ML assignment. It can also be introduced earlier as a short orientation, then revisited before the final project. It is not a prerequisite for the other ML modules.
+
+## Assessment principle
+
+A successful agent run is **not** evidence of learning. Credit is based on the student’s task boundary, independent verification, failure diagnosis, AI-use record, and short individual defense. Use the repository-wide [assessment policy](../../teaching_resources/ASSESSMENT_AND_AI_POLICY.md) and [engineering ML rubric](../../teaching_resources/ENGINEERING_ML_RUBRIC.md) alongside this module.

course_content/ix_ai_agent_harnesses/REFERENCES.md

@@ -0,0 +1,13 @@
+# References and documentation
+
+These resources describe current implementations and terminology. Product behavior, eligibility, pricing, model availability, and installation steps can change; instructors should recheck them before assigning a live setup.
+
+- [OpenAI: Build skills](https://learn.chatgpt.com/docs/build-skills) — skills package instructions, resources, and optional scripts; plugins distribute reusable skills and connectors.
+- [OpenAI: Model Context Protocol](https://learn.chatgpt.com/docs/extend/mcp?surface=cli) — Codex MCP connections and supported configuration patterns.
+- [OpenAI: Plugins](https://learn.chatgpt.com/docs/plugins) — plugins can bundle skills and connectors for ChatGPT and Codex surfaces.
+- [Anthropic: Claude Code overview](https://code.claude.com/docs/en/overview) and [MCP documentation](https://code.claude.com/docs/en/mcp) — current Claude Code concepts and MCP setup information.
+- [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) — protocol-level concepts and transport considerations.
+- [Ollama: tool calling](https://docs.ollama.com/capabilities/tool-calling) — one example of tool calling in a locally deployable runtime.
+- [Han Hu: mechanical-engineering-research skill](https://github.com/hanhuark/mechanical-engineering-research-skill) — public case study used in this module.
+
+For the course-level handling of AI-assisted work, use the repository [assessment policy](../../teaching_resources/ASSESSMENT_AND_AI_POLICY.md) and [AI-use record](../../teaching_resources/AI_USE_TEMPLATE.md).