APPENDIX H: RESUME PORTFOLIO BUILDING CAPSTONE PROJECTS

PROJECT OVERVIEW Think of a busy restaurant kitchen at dinner time. There is a head chef who reads each order and sends it to the right station, a cook who prepares the dish, and a taster who checks it before it leaves the pass. There is a clock on the wall, because no single dish may take all night. There is a rule that says if the grill breaks, the head chef calls for help rather than letting orders pile up. There is also a big red switch for turning off the stoves in an emergency. Project 5 builds that kitchen for invented customer support tickets. A supervisor reads each ticket and hands it to three worker roles in turn: a classifier that decides what kind of ticket it is, a drafter that writes a reply, and a reviewer that checks the reply against a rule. Every ticket gets its own budget, which is a set of limits on how many calls, how many tokens, and how much time the work may use. A flaky classifier fails once on one ticket, and the supervisor retries it after waiting a little longer each time, which is called exponential backoff, meaning that the waits double. One ticket sends a worker into an endless loop, and the budget catches it and hands the ticket to a human queue. A reviewer rejects a draft that makes an overly strong promise, and the supervisor allows one redraft. A kill switch, which is an environment variable that turns all work off, stops everything instantly. You will then write an incident runbook, which is a step-by-step guide for handling things when they go wrong, and a deployment plan, which describes how you would release the system safely. The workers here are ordinary scripted functions standing in for model-powered agents, so the orchestration, which is the coordination of several workers, is the thing you build and test. The project relates to Chapters 25, 42 through 45, 56 through 60, and 69, and to the fifth stage of the Practice Lab, which split one agent into a supervisor and workers and hardened it. It is different from the lab because it uses support tickets instead of resumes, it adds a kill switch and exponential backoff, and it asks you to write the runbook and deployment plan as real documents. It builds on all four earlier projects: it reuses the audit log idea from Project 3, the budget thinking from Project 1, the tests from every project, and the measuring habit from Project 4. Use only the invented tickets in this project, and never real customer messages or personal data.