Module 05 Knowledge Check
5 questions. Pass mark 4 out of 5. Answer every question before checking the answer key below, then retry after reading the feedback.
1. Decisions not explicitly assigned to a written rule or a person…
- A. are handled by the framework
- B. default to the agent, and are the ones nobody tests
- C. cause an error
- D. are skipped
2. An input that matches two routing rules argues for…
- A. handing the decision to the agent
- B. an explicit tie-break you can read and change
- C. removing one of the rules
- D. a longer prompt
3. Routing should read…
- A. the agent's summary
- B. validated fields the agent produced
- C. the raw user request
- D. the full trace
4. A step that fails without that failure being handled…
- A. is retried automatically
- B. discards the whole run, including work already approved
- C. escalates by default
- D. is logged and skipped
5. In a typical plan, the cost is carried by…
- A. the lookups
- B. the small number of agent steps
- C. the parsing
- D. state serialisation
---
Answer Key and Explanations
Check these only after attempting every question.
1. B - default to the agent, and are the ones nobody tests
Anything mentioned in an instruction is a decision handed over, whether or not you meant to.
2. B - an explicit tie-break you can read and change
The ambiguity is real either way. Only the written tie-break tells you which way it went.
3. B - validated fields the agent produced
A prose router breaks when the summary says 'invoicing' instead of 'billing'. Fields give you a truth table you can test.
4. B - discards the whole run, including work already approved
Catch the failures you expect and record them as an outcome, keeping the trail; let genuinely unexpected ones surface.
5. B - the small number of agent steps
Code steps contribute almost nothing. The useful question is whether two agent steps could be one call.
Practical Check
Apply this module to your own work: complete the module activity for *Planning, Routing and Deterministic Workflow Steps*, then write one sentence naming what your result shows and one naming what it does not.
Strong Answer Pattern
A strong answer names the task, the evidence used, the check performed, and the remaining limitation. It avoids "proved", "guaranteed", or "always" unless the evidence genuinely supports it.