Build & test
Build week: the loop, the tools, the guardrail stack, the eval suite from day one — the full agent, in the safe order that puts guardrails before real actions.
Build week. You've built every piece once on the resolution agent; now assemble them for your domain, in the order that keeps you safe. Budget four to six hours across the week — and expect, as with RAG, that the interesting time goes to tools and guardrails, not the loop.
The build order (guardrails before real actions — non-negotiable)
- 1The loop + mock tools first (Module 1): get the agent navigating on fakes. Never wire a real write tool before its validator exists.
- 2Real read tools (Module 3): database/API adapters with timeouts, shaping, caps, read-only credentials, logging.
- 3The eval suite in parallel (Module 6): 10 task specs from day one, growing to 20. Every change measured, exactly like RAG — this is the discipline that makes the week converge instead of thrash.
- 4Memory & context (Module 4): scratchpad and compaction before long tasks expose the overflow, not after.
- 5Guardrails, THEN real write tools (Module 5): validators with code-side limits, the autonomy dial, kill switch, action log — wired and tested against attacks before any tool can touch reality. This ordering is the safety discipline of the whole course.
- 6Planning & reflection (Module 2) as the task complexity demands — don't add ceremony a simple agent doesn't need.
- 7Split to multi-agent only if your design justified it and the numbers support it (Module 7).
The two traps of agent build week
- Wiring real actions before guardrails 'just to test the flow.' This is how course projects issue real refunds to fake customers. Mock the world until the validators are green; the flow tests fine on mocks.
- Chasing capability over reliability. A 5-tool agent that resolves 90% safely beats an 11-tool agent that resolves 97% with one un-undoable failure mode. The rubric — and reality — rewards the safe, evaluated, honest agent.
Here is my agent's current scorecard, my 4 worst-scoring task trajectories with failure classifications, and my remaining time (2 hours): [paste]. Rank fixes by expected impact per hour, separate the safety issues (fix regardless of cost) from the quality issues (cost-benefit), and tell me which failing cases to ACCEPT and document as known limits.
Safety findings jump the queue unconditionally; quality findings compete on ROI. Knowing which is which — and documenting the accepted limits — is a graded skill.
Version-freeze the whole system — prompts, tools, guardrails, task suite, scorecard. The demo runs on the frozen agent. And confirm, one last time, that the kill switch works: it's the thing you'll be glad exists the first time a demo goes sideways live.