Key takeaways
The through-line
The harness — not the model — is what makes an agent good. This course is about the code around the loop: what goes into context each turn, when the loop stops, what happens when it misbehaves. Two teams using the same model get very different agents because of it.
The ideas that carry
- The inner loop is small and the consequences are not. Gather context → call the model → execute tools → decide whether to continue. Every hard problem attaches to one of those four steps.
- Context management is the core competency. Finite window, growing history: compaction, summarisation, retrieval and eviction are the harness's real job, and doing them badly looks exactly like the model getting dumber over a long session.
- Loops differ by what ends them. Turn-based, goal-based, time-based and proactive loops have different failure modes; choosing the wrong one produces an agent that stops too early or never.
- Subagents are context isolation, first and foremost. Delegating a task to a fresh context keeps the parent's window clean — that is usually the point, not parallelism.
- Circuit breakers, budgets and step limits are load-bearing. An agent without them has no worst case, and "no worst case" means the worst case is your bill.
- State persistence is what makes an agent resumable across crashes, deploys and days.
- Harnesses are evaluated like any other system, on trajectories and cost, not vibes — which is the only way to know whether a harness change helped.
- Building one from scratch is worth doing once. Every SDK abstraction becomes legible after you've implemented the thing it hides.
What you can now do
Build a harness from scratch and know what an SDK is doing for you. Manage context deliberately at long horizons. Add safety rails with real limits. Measure whether a harness change actually improved anything.
If one thing sticks
You cannot prompt your way out of a bad harness. What the model sees each turn is your design, and it decides more than the wording does.