Homework — Where Agents Are Going
Lesson 13 · Module 6 · Choosing & Shipping · ~60–90 min reflection
This is the final lesson of the course, and its homework is deliberately different from every prior lesson’s. There is no code to write, no harness to extend, no answer key to compare against. Three prompts — all open-ended — ask you to take a position, defend it in writing, and bet on what will look wrong about this course three years from now.
No published answer key
These prompts have no “right” answer. Their value is in the act of writing them — forcing yourself to commit to a defensible position, with explicit trade-offs, before the next framework launch tries to talk you out of it. Treat the word counts as floors, not ceilings: 200 words is the minimum to be honest about a trade-off, not the target.
How to submit (to yourself)
Write all three responses in a single Markdown file — finale.md,
somewhere you’ll find it in six months. Date the file. Add a calendar reminder for
2026-11-25 (six months from this course’s snapshot date) to
re-read your own answers and note which ones have aged well. That re-read is the real
exercise.
Prompt 1 — Pick your framework, defend in 200 words
From the four frameworks covered in this course — Claude Agent SDK, LangGraph, OpenAI Agents SDK, CrewAI — pick the one you would default to for your next project. Write a 200-word defence that names:
- Two scorecard dimensions you weighed heavily and why. Refer back to the seven dimensions from L11 (cost, latency, lines-of-code, observability, multi-agent ergonomics, MCP support, ecosystem maturity). Be concrete about why these two outranked the others for your project shape.
- One scorecard dimension you deprioritised and why. Saying “everything matters” is not an answer — under finite engineering time, something gets less attention. Name it, and own the trade-off.
- One concrete project shape where you would not pick this framework, and what you’d pick instead. No framework is best for every job; your defence is stronger when you can name its own weak spot.
Word budget: 200 words minimum. Aim for one paragraph per bullet plus a 2–3 sentence opener that states the pick.
✓ Self-check: a teammate who didn’t take this course can read your answer and understand the pick, the two dimensions, the deprioritised dimension, and the counter-example project shape — without needing to ask follow-ups.
Prompt 2 — Identify one thing this course got wrong (yet)
Three years from now — 2029 Q2 — when you re-read this course, which claim do you predict will look most dated? Write 150 words on:
- Which specific claim. Quote it (or paraphrase tightly) from the slides or theory. The vaguer your target, the weaker the answer; pick a sentence, not a vibe.
- Why you think it’ll age poorly. Name a trend, a missing primitive, an obvious gap, or a structural force (regulation, hardware economics, open-weight model progress) that you expect to invalidate it.
- What you’d replace it with if you were updating the course in 2028. One sentence is enough — the point is that you have a successor claim in mind, not just a complaint.
Word budget: 150 words minimum. Resist the temptation to pick the safest target; pick the claim that, if it ages well, will most embarrass you to have nominated. That’s the one with signal.
✓ Self-check: your prediction is falsifiable — in 2029 Q2 you (or a teammate) can look at the claim and say definitively “you were right” or “you were wrong,” not “it depends.”
Prompt 3 — Sketch one production checklist item the course missed
The L12 theory’s section 7 listed eight production-readiness checklist items (cost caps, turn caps, structured logging, idempotent tools, kill switch, framework-agnostic evals, prompt version control, portable tool implementations). Identify one item the course should have included and didn’t. Write 150 words on:
- What the item is (one sentence). Name the missing checklist entry concisely — as if it were going to land verbatim in the L12 list.
- Why it matters (3–5 sentences). Tie it to a real failure mode you can imagine in a production agent: a runaway behaviour, a security gap, an observability blind spot, a compliance miss. The more concrete the failure, the stronger the case for inclusion.
- A concrete example of how to implement it (3–5 sentences or a short pseudo-code block). Show enough mechanism that a reader could go build it. Vague gestures at “you should monitor X” don’t count; how you monitor it does.
Word budget: 150 words minimum (plus an optional pseudo-code block, which doesn’t count against the budget). If your item duplicates one of the existing eight, pick again — the point is to find a real gap.
✓ Self-check: a senior engineer reading your item, the failure mode, and the implementation sketch agrees it’s production-grade advice — not a nice-to-have, not theoretical, not already covered by one of the existing eight.
What to do after you’ve written all three
Save the file. Set the six-month reminder. Then — and this is the most important part — go build something. The course gave you four frameworks, a reproducible scorecard, and the vocabulary to argue about agent design with numbers instead of taste. None of that compounds unless you put a real agent into a real workflow and watch what happens when it meets real users. Your future re-read of this finale will be much more useful if, by then, you have shipped — and hit production problems the course didn’t warn you about. That’s where the next iteration of this course comes from.
No published answer key — these are open-ended reflection prompts for 2026 Q2. Discuss with your team; revisit your answers in 6 months.