249 lines
8.9 KiB
Markdown
249 lines
8.9 KiB
Markdown
# Instructor Guide
|
||
|
||
Teaching notes, timing, discussion questions, common mistakes, and lab troubleshooting for each module.
|
||
|
||
---
|
||
|
||
## Module 1: Foundations (4-6 hours)
|
||
|
||
### Timing Guide
|
||
|
||
| Section | Time | Format |
|
||
|---------|------|--------|
|
||
| Lesson 1.1-1.3 | 60 min | Lecture + discussion |
|
||
| Lesson 1.3a-1.4 | 40 min | Lecture + demo |
|
||
| Lesson 1.5-1.6 | 50 min | Lecture + live coding |
|
||
| Lesson 1.7 (Trust) | 15 min | Discussion |
|
||
| Lab 1.8 | 60 min | Hands-on |
|
||
| Quiz | 15 min | Individual |
|
||
|
||
### Key Discussion Questions
|
||
|
||
1. "What's the difference between vibe coding and agentic engineering?" — Lead with the 5 hard rules from mythos-learnings.md
|
||
2. "When should you NOT use an agent?" — Walk through the decision framework table
|
||
3. "Do you trust your agents?" — This is the course thesis. Get students to share their trust level.
|
||
|
||
### Common Mistakes
|
||
|
||
- **Confusing the model with the agent**: Students think "better model = better agent." Emphasize the harness.
|
||
- **No iteration limits**: Students build loops without max iterations. Always set MAX_ITERATIONS.
|
||
- **Skipping the reasoning parameter**: Students define tools without reasoning fields. Always add it.
|
||
|
||
### Lab Troubleshooting
|
||
|
||
- **API key not set**: The mock LLM client handles this. If they want real API, ensure `ANTHROPIC_API_KEY` is set.
|
||
- **File not found errors**: Labs expect files in the current directory. `cd` to the lab folder first.
|
||
|
||
---
|
||
|
||
## Module 2: Architecture (6-8 hours)
|
||
|
||
### Timing Guide
|
||
|
||
| Section | Time | Format |
|
||
|---------|------|--------|
|
||
| Lessons 2.1-2.3 | 75 min | Lecture |
|
||
| Lessons 2.4-2.6 | 75 min | Lecture + demo |
|
||
| Lessons 2.7-2.8 | 50 min | Architecture discussion |
|
||
| Lab 2.9-2.10 | 90 min | Hands-on (split across 2 labs) |
|
||
| Quiz | 15 min | Individual |
|
||
|
||
### Key Discussion Questions
|
||
|
||
1. "Which codebase architecture fits your project?" — Compare atomic vs layered vs pipeline vs vertical slice
|
||
2. "How do you handle context overflow in practice?" — Real examples from your tac/ projects
|
||
3. "What's the most common memory mistake?" — Agents that don't persist expertise between sessions
|
||
|
||
### Common Mistakes
|
||
|
||
- **One tool to rule them all**: Students try to make one tool do everything. Enforce single-responsibility.
|
||
- **No output limits**: Tool results overflow context. Cap returns at 2KB for logs, 10 items for search.
|
||
- **Flat hierarchy for complex agents**: Students skip domain locking. Add it early.
|
||
|
||
---
|
||
|
||
## Module 3: Safety & Security (5-7 hours)
|
||
|
||
### Timing Guide
|
||
|
||
| Section | Time | Format |
|
||
|---------|------|--------|
|
||
| Lesson 3.1 (ACIP + Bash) | 45 min | Lecture + probability math demo |
|
||
| Lessons 3.2-3.5 | 90 min | Technical deep dive |
|
||
| Lessons 3.6-3.7 | 60 min | Architecture + stacking |
|
||
| Labs 3.8-3.9 | 90 min | Hands-on |
|
||
| Quiz | 15 min | Individual |
|
||
|
||
### Key Discussion Questions
|
||
|
||
1. "Have you ever had an agent do something destructive?" — Share war stories. The L3 marquee break usually gets reactions.
|
||
2. "What level of security do you run?" — Most students are at L1-L2. Show them the math (1% × 100 turns = 63%).
|
||
3. "Would you trust a verifier agent?" — This is where trust becomes concrete. Demo the verifier pattern.
|
||
|
||
### The Probability Math Demo
|
||
|
||
```python
|
||
# Show this live:
|
||
for p in [0.01, 0.001, 0.0001]:
|
||
for n in [10, 50, 100, 1000]:
|
||
prob = 1 - (1-p)**n
|
||
print(f"p={p:.4f}, n={n}: {prob:.1%} failure rate")
|
||
```
|
||
|
||
### Lab Troubleshooting
|
||
|
||
- **Whitelist too restrictive**: Students block legitimate commands. Start with 10 patterns, add more as needed.
|
||
- **Verifier has no tools**: Students forget to give the verifier read tools. Check tool surface.
|
||
- **Socket connections**: The verifier lab uses Unix sockets. Windows users need WSL.
|
||
|
||
---
|
||
|
||
## Module 4: Multi-Agent Orchestration (7-9 hours)
|
||
|
||
### Timing Guide
|
||
|
||
| Section | Time | Format |
|
||
|---------|------|--------|
|
||
| Lessons 4.1-4.4 | 90 min | Architecture + patterns |
|
||
| Lessons 4.5-4.9 | 90 min | Technical deep dive |
|
||
| Lessons 4.10-4.11 | 60 min | Case study (CEO Board, UI Agents) |
|
||
| Labs 4.12-4.13 | 90 min | Hands-on |
|
||
| Quiz | 15 min | Individual |
|
||
|
||
### Key Discussion Questions
|
||
|
||
1. "One agent or many?" — Walk through the decision framework. When does multi-agent make sense?
|
||
2. "Orchestrator should never execute" — This is the hardest rule for students. They want the orchestrator to do work.
|
||
3. "Flat vs hierarchical?" — Compare P2P coms vs depth-2 delegation. Which fits your use case?
|
||
|
||
### Common Mistakes
|
||
|
||
- **Orchestrator does the work**: The orchestrator should delegate, not code. Enforce this with domain permissions.
|
||
- **No mental models**: Agents forget everything between sessions. Always include a mental model file.
|
||
- **No domain locks**: Agents step on each other's files. Always add domain permissions.
|
||
- **P2P without hop limits**: Agents loop forever. Always set MAX_HOPS=5.
|
||
|
||
---
|
||
|
||
## Module 5: Production Patterns (5-7 hours)
|
||
|
||
### Timing Guide
|
||
|
||
| Section | Time | Format |
|
||
|---------|------|--------|
|
||
| Lessons 5.1-5.4 | 90 min | Lecture + case study |
|
||
| Lessons 5.5-5.8 | 90 min | Technical deep dive |
|
||
| Labs 5.9-5.10 | 90 min | Hands-on |
|
||
| Quiz | 15 min | Individual |
|
||
|
||
### Key Discussion Questions
|
||
|
||
1. "What does production mean for agents?" — Different from traditional software. Non-deterministic behavior changes everything.
|
||
2. "Have you hit a cost surprise?" — Share stories. The 3x rule usually resonates.
|
||
3. "Shadow deployment or not?" — When is shadow worth the complexity?
|
||
|
||
### The 5-Tool Stack Demo
|
||
|
||
Show your actual mprocs config (`~/mprocs-teams.yaml`) and explain:
|
||
- Why Claude Code is the lead
|
||
- Why Pi is the customizable harness
|
||
- Why OpenCode is the OSS backup
|
||
- How agent-mux ties it together
|
||
|
||
---
|
||
|
||
## Module 6: Economics & Evaluation (4-6 hours)
|
||
|
||
### Timing Guide
|
||
|
||
| Section | Time | Format |
|
||
|---------|------|--------|
|
||
| Lessons 6.0-6.2 | 60 min | Lecture |
|
||
| Lessons 6.3-6.5 | 60 min | Technical |
|
||
| Lessons 6.6-6.7 | 40 min | A/B testing + human eval |
|
||
| Labs 6.8-6.9 | 75 min | Hands-on |
|
||
| Quiz | 15 min | Individual |
|
||
|
||
### Key Discussion Questions
|
||
|
||
1. "What's your current agent spend?" — Use the Compute Advantage Equation to calculate their leverage.
|
||
2. "Do you measure agent performance?" — Most teams don't. Show pass@k and cost per task.
|
||
3. "Would you trust an eval harness?" — The golden dataset approach. Get students to create one for their project.
|
||
|
||
### Jeff Emanuel Case Study
|
||
|
||
Share Jeff's numbers: 52 subs at $12K/mo, 85K commits/year. Ask: "What's his Compute Advantage? How would cascade routing change his costs?"
|
||
|
||
---
|
||
|
||
## Module 7: Advanced Topics (5-7 hours)
|
||
|
||
### Timing Guide
|
||
|
||
| Section | Time | Format |
|
||
|---------|------|--------|
|
||
| Lessons 7.1-7.3 | 75 min | Lecture + demo |
|
||
| Lessons 7.4-7.6 | 75 min | Architecture |
|
||
| Labs 7.7-7.8 | 90 min | Hands-on |
|
||
| Quiz | 15 min | Individual |
|
||
|
||
### Key Discussion Questions
|
||
|
||
1. "Should we trust agents to improve themselves?" — The autoresearch loop. Integrity guards are essential.
|
||
2. "What can't MCP do well?" — Beyond MCP: context cost trade-off matrix.
|
||
3. "Are we building our own replacement?" — The meta-agent exercise gets existential. Good discussion.
|
||
|
||
---
|
||
|
||
## Module 8: Capstone (8-12 hours)
|
||
|
||
### Teaching Approach
|
||
|
||
This is self-directed. Students pick one of three projects and work through 7 phases. The instructor's role:
|
||
|
||
1. **Phase 1 (Design)**: Review architecture diagrams. Check that agents have clear roles and domain permissions.
|
||
2. **Phase 3 (Integration)**: Check that agents can actually communicate. Common point of failure.
|
||
3. **Phase 5 (Testing)**: Help students create golden datasets. This is where most learning happens.
|
||
4. **Phase 7 (Review)**: Facilitate a retrospective session. Students present what broke.
|
||
|
||
### Grading
|
||
|
||
Use the rubric in M8-CAPSTONE.md. Key pass criteria:
|
||
- System runs without manual intervention
|
||
- All agents have domain-locked permissions
|
||
- Each agent has a mental model file
|
||
- pass@k > 60%
|
||
- Cost analysis within 2x of optimal
|
||
|
||
---
|
||
|
||
## Overall Teaching Tips
|
||
|
||
### Pace
|
||
|
||
- Don't let students spend more than 15 min on any single TODO in a lab
|
||
- If stuck, give them the next 3 lines of the solution, not the whole thing
|
||
- Labs are designed to fail early — celebrate failures as learning moments
|
||
|
||
### Audience Adaptation
|
||
|
||
- **Technical audience**: Focus on labs and code. Speed through theory.
|
||
- **Non-technical audience**: Use NON-TECHNICAL.md as primary material. Skip most labs.
|
||
- **Mixed audience**: Split into pairs (technical + non-technical) for labs.
|
||
|
||
### Environment Setup
|
||
|
||
Before the course starts, ensure students have:
|
||
1. Python 3.12+ installed
|
||
2. `pip install anthropic` (or they use mock LLM)
|
||
3. VS Code or any editor
|
||
4. Git
|
||
5. Optional: Claude Code, Pi Agent, or OpenCode CLI
|
||
|
||
### Handling Questions
|
||
|
||
- **"Which model should I use?"** → M6 pricing table. Cascade routing decision tree.
|
||
- **"Is this safe?"** → M3 security ladder. Always start at L3 minimum.
|
||
- **"How do I sell this to my boss?"** → NON-TECHNICAL.md. Compute Advantage Equation.
|
||
- **"What about [framework]?"** → Our course is framework-agnostic. The patterns apply everywhere.
|