Agent design
Choose your agent and write the design doc: the task, the tool suite with stakes ratings, the guardrail plan, and the autonomy dial — before any code.
The resolution agent was the worked example. Your capstone is an agent for a task you understand and, ideally, own — support resolution, research assistance, data investigation, ops automation, a coding helper for a narrow job. Same architecture, your domain. This week is design, and for agents the design is the safety case — get it right on paper and the code follows; get it wrong and no amount of prompting saves you.
Choosing the task
- Multi-step, tool-using, decision-bearing — if a fixed pipeline would do, build a pipeline (you know how). Agents earn their complexity only when the model genuinely needs to choose the path.
- Consequential enough to be interesting, bounded enough to be safe — real actions with real stakes, but a blast radius a course project should touch. Support resolution, internal ops, and research assistants are the sweet spot; anything touching money, health, or legal at scale is a demo-with-mocks, not a deploy.
- You can specify 'correct.' If you can't write the gold outcome for a task, you can't evaluate the agent on it — and an unevaluable agent is one you can't trust or improve.
The design document (deliverable 1)
- 1The task and its trajectories — what the agent does, and 3 real example cases walked step by step (this reveals your tool needs faster than any brainstorm).
- 2The tool suite — every tool: name, model-facing description, typed schema, read/compute/write class, and for writes a stakes rating and reversibility tier. The audit: does every fact a human would look up, and every action they'd take, have a tool or an escalation path?
- 3The guardrail plan — which policy limits live in code, where the validators sit, the autonomy dial per write tool (auto/gated/propose-only), the kill switch, the action log. For every write tool, the sizing question answered: when this fires wrong, how do we detect and undo it?
- 4Memory & context plan — scratchpad? compaction threshold? long-term memory (and its governance)?
- 5Single vs. multi-agent — default to single; justify any split against a real wall, and if you split, it's almost certainly read-worker/write-actor.
- 6Success criteria as numbers — task success rate ≥ X, zero wrong actions executed, escalation recall ≥ Y, cost per task ≤ Z.
Review my agent design as a skeptical staff engineer who has shipped agents and gotten burned: [paste]. Attack it on three axes — (1) missing tools or escalation paths that will force the agent to improvise, (2) any consequential limit that lives in a prompt instead of code, (3) any write tool whose 'when it fires wrong' answer is unconvincing. Then name the one design flaw most likely to cause a real incident.
The hostile-reviewer pattern, one last time, aimed at the highest-stakes design you've done. Fix what it finds before you write a line of code — design bugs in agents become production incidents.
One agent, 6–10 tools, a 20-case task suite. The impressive capstone isn't the swarm — it's the single agent whose guardrail plan and reversibility tiers visibly agree, and whose eval you actually trust.