Module 06 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. Use a Flow rather than autonomous delegation when…
- A. The task is small
- B. The sequence is known and must be reproducible
- C. You have many agents
- D. Cost matters
2. Deterministic orchestration improves testability because…
- A. It is faster
- B. The same input follows the same path, so results can be compared run to run
- C. It uses fewer tokens
- D. It needs no tools
3. The right split between Flow and agent autonomy is…
- A. Full autonomy always
- B. Deterministic structure for known steps, agent judgement only where it is genuinely needed
- C. No autonomy ever
- D. Alternate them
4. Conditional branching in a Flow should key on…
- A. Free-text agent output
- B. Validated structured values
- C. Response length
- D. Elapsed time
5. State passed through a Flow should be…
- A. Everything accumulated
- B. Explicit and typed, so each step's inputs are clear
- C. Free-form text
- D. Hidden
---
Answer Key and Explanations
Check these only after attempting every question.
1. B - The sequence is known and must be reproducible
If you already know the order, encoding it removes an entire class of runtime variability.
2. B - The same input follows the same path, so results can be compared run to run
Reproducibility is the precondition for meaningful regression testing.
3. B - Deterministic structure for known steps, agent judgement only where it is genuinely needed
Minimise the surface where behaviour can vary; keep judgement where judgement is required.
4. B - Validated structured values
Branching on unvalidated prose is how workflows take silent wrong turns.
5. B - Explicit and typed, so each step's inputs are clear
Explicit state is what makes each step independently testable.
Practical Check
Apply this module to your own work: complete the module activity for *Flows for Deterministic Orchestration*, 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.