You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1.`step1_write_prompt()` — build the system prompt and user message
71
-
2.`step2_call_api()` — call `ask()` and return the dict
72
-
3.`step3_parse_json()` — validate required keys are present
73
-
4.`step4_execute_action()` — print `recommended_action`; if `escalate=true`, print escalation notice
74
-
5.`step5_verify_result()` — return True if output meets success criteria
75
-
76
-
**Key Takeaway:** The five steps make testing trivial — you can unit-test `step3_parse_json()` independently of the API call, and mock `step2_call_api()` without touching the prompt logic.
70
+
**Key Takeaway:** Compare the output schema in the exercise (`triage_agent.py`) against the reference solution (`solutions/solution.py`). The solution reorganises the same logic into five explicit, independently testable steps — `step1_write_prompt()`, `step2_call_api()`, `step3_parse_json()`, `step4_execute_action()`, `step5_verify_result()`. Both produce a working agent; the five-step version makes unit testing trivial because each step can be tested in isolation without touching the others.
77
71
78
72
---
79
73
@@ -118,7 +112,7 @@ This is the first module where you can see your agent running in a real CI envir
118
112
## Success Criteria
119
113
120
114
-`triage_agent.py --mock` runs cleanly and prints valid JSON
121
-
- Live run returns all four keys: `diagnosis`, `confidence`, `recommended_action`, `escalate`
115
+
- Live run returns all five keys: `summary`, `likely_cause`, `next_step`, `confidence`, `escalate`
122
116
-`confidence` is `HIGH` for the `sample_log.txt` OOM scenario (the log is unambiguous)
123
117
-`escalate` is `false` — agent has a concrete fix, no human needed
Copy file name to clipboardExpand all lines: module5/README.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,16 +95,16 @@ Full result saved to `output/output_module5.json`.
95
95
96
96
## Exercise
97
97
98
-
**Part A — Quality gate:**Open `triage_agent.py`. Implement `run_agent()` — write the `ask()` call that sends `SYSTEM_PROMPT` and the pipeline results to Claude and returns the result dict. The `SYSTEM_PROMPT`is already written for you; study it before calling `ask()`.
98
+
**Part A — Read and run the quality gate:**`triage_agent.py` is fully implemented — both the `SYSTEM_PROMPT` and `run_agent()` are complete. Study the implementation before running it: read `SYSTEM_PROMPT`to understand the gate criteria, then trace how `run_agent()` loads `sample_data.json`, calls `ask()`, and prints the structured decision.
ANTHROPIC_API_KEY=sk-... python module5/triage_agent.py #live run against Claude
103
103
```
104
104
105
-
**Part B — Threshold experiment:**Lower the `threshold` for `test_coverage`in `quality-gates.json`from 95 to 70. Re-run `triage_agent.py` and observe how the decision changes — no code edit needed, just the config file.
105
+
**Part B — Threshold experiment:**Edit `quality-gates.json` — lower the `threshold` for `test_coverage` from 95 to 70. Re-run `triage_agent.py` and observe how the gate decision changes. No code edit required, only the config file. This demonstrates the architecture: the agent reads thresholds as data, not as hardcoded logic.
106
106
107
-
If you get stuck, see `solutions/solution.py` for the reference implementation.
107
+
See `solutions/solution.py` for a version with an extended six-dimension gate including a Change Risk dimension not present in the base implementation.
"answer": "The checkout-service is experiencing elevated latency (p95 = 2.3s vs 0.4s baseline) triggered by a payment-api 40% error rate starting 8 minutes after the last deployment.",
80
+
"query": "We are getting paged. What is causing the latency spike?",
81
+
"query_type": "incident",
82
+
"status_summary": "ACTIVE INCIDENT — checkout-service DOWN due to OOMKill cascading to payment-service and api-gateway.",
83
+
"narrative": "checkout-service v1.9.0 introduced a cache warm-up loading 250k records on startup. Memory peaked at 1.1Gi against a 512Mi limit, triggering an OOMKill. The pod restart loop is causing 503s that have cascaded to payment-service and tripped the api-gateway circuit breaker on /checkout/**.",
81
84
"causal_chain": [
82
-
"checkout-service deployment completed at 14:24 UTC",
83
-
"payment-api error rate began rising at 14:32 UTC (8-minute lag)",
84
-
"checkout-service latency spiked as retries accumulated against failing payment-api"
85
+
"deploy v1.9.0 introduced cache warm-up loading 250k records on startup",
86
+
"startup memory spike: 1.1Gi peak vs 512Mi limit",
87
+
"OOM killer terminates process → pod restart loop → sustained 503s",
88
+
"payment-service error rate rises to 8.7% from checkout dependency failures",
89
+
"api-gateway circuit breaker opens on /checkout/** → all checkout traffic blocked"
85
90
],
86
-
"confidence": "MEDIUM",
87
-
"follow_up_questions": [
88
-
"Was there a simultaneous change to payment-api at 14:32 UTC?",
89
-
"What does the payment-api error response body contain?"
90
-
],
91
-
"escalate": true
91
+
"confidence": "HIGH",
92
+
"recommended_action": "Immediate: roll back checkout-service to v1.8.x. Increase memory limit to 2Gi before re-deploying v1.9.0. Page on-call — P1 incident.",
93
+
"deploy_safe": false,
94
+
"escalate": true
92
95
}
93
96
```
94
97
@@ -98,18 +101,19 @@ Full result saved to `output/output_module6.json`.
98
101
99
102
## Exercise
100
103
101
-
Open `conversational_agent.py`. There are two functions to implement:
104
+
Open `conversational_agent.py`. The file is fully implemented — `phase1_route()` and `phase2_analyse()`are already complete. Study both functions carefully:
102
105
103
-
**`phase1_route(query)`** — call `ask()` with `ROUTING_SYSTEM_PROMPT`to classify the query as `incident`, `investigation`, or `health_check`. Return `result.get("query_type", "health_check")`.
106
+
**`phase1_route(query)`** — classifies the query using `ROUTING_SYSTEM_PROMPT`(64 tokens max). Notice that it uses `max_tokens=64` — classification needs no generation. The return value is `result.get("query_type", "health_check")` with a safe default.
104
107
105
-
**`phase2_analyse(query, query_type, platform_data)`** — build a `user_msg`combining the query, type, and platform data snapshot, then call`ask()` with `ANALYSIS_SYSTEM_PROMPT` and return the result dict.
108
+
**`phase2_analyse(query, query_type, platform_data)`** — builds a combined `user_msg`from the query, the type, and the full platform data snapshot, then calls`ask()` with `ANALYSIS_SYSTEM_PROMPT`. Both system prompts are defined in the file — read them before running.
python module6/conversational_agent.py --query "Is it safe to deploy?" --mock
109
113
ANTHROPIC_API_KEY=sk-... python module6/conversational_agent.py --query "We are getting paged. What is causing the latency spike?"
110
114
```
111
115
112
-
Both system prompts are already written — study them before implementing the `ask()` calls. If you get stuck, see `solutions/solution.py`.
116
+
After running, compare your understanding of the implementation against `solutions/solution.py` — the solution file isolates and annotates the two key functions with inline comments explaining each design decision.
113
117
114
118
---
115
119
@@ -150,8 +154,8 @@ When you run `conversational_agent.py` locally with the two-terminal setup, you
150
154
151
155
- Mock server starts and responds to all four endpoints
152
156
-`conversational_agent.py --mock` runs cleanly without a server or API key
0 commit comments