1.4.2. Reasoning Through a Scenario
💡 First Principle: The filters are only useful applied. Walking one scenario end to end shows how three plausible distractors fall away and one answer survives — which is the exact muscle the exam exercises.
Take a worked example. Requirement: "A support assistant must answer using our current product manuals, look up a customer's open ticket status, and we need to track answer quality over time." Run the filters. Boundary: this spans agent config (the assistant), a connection (the manuals), a tool (ticket lookup), and evaluation (answer quality) — so any single-layer answer is incomplete. Grounding: "current product manuals" is private, changing data → retrieval over an indexed source with citations; an answer that fine-tunes on the manuals is wrong here. Agent workflow: "look up a customer's open ticket" is an action against an external system → a tool/function call, which means an agent, not a bare completion. Modality: text in, text out → generative text plus retrieval, no vision or speech service needed. The surviving answer: a Foundry agent grounded on an indexed manual connection, with a function/connected tool for ticket lookup, plus evaluation configured to score groundedness over time. Each filter killed a tempting distractor.
⚠️ Exam Trap: A distractor will often be partially right — it nails the modality and even the grounding but omits the tool the requirement clearly needs ("look up ticket status"), or it grounds correctly but proposes fine-tuning for the fresh data. Read every requirement clause; an answer that ignores even one stated need is the wrong answer.
Reflection Question: In the worked example, which single requirement clause most cleanly eliminates a "just use a better system prompt" answer, and why?
