1.4.1. Foundry Boundary, Grounding, Agent Workflow, Modality
💡 First Principle: Each filter eliminates a category of wrong answer. Boundary tells you which layer the task belongs to; grounding tells you whether and how to supply data; agent workflow tells you how much agency the task needs; modality tells you which input/output type drives the service choice.
Run them in order because earlier filters constrain later ones. Boundary first: a monitoring requirement is answered in observability config, not by changing the agent — so you can discard agent-design answers immediately. Grounding next: if the requirement names private or current data, any answer lacking retrieval is wrong regardless of how sophisticated it looks. Agent workflow third: if the task is genuinely one-shot, an elaborate multi-agent answer is over-engineered; if it needs a tool call or memory, a bare completion is under-powered. Modality last: it usually decides the final service name once the other three have narrowed the field.
⚠️ Exam Trap: Don't jump straight to modality (the most concrete filter) and skip boundary and grounding. A vision-flavored question can actually be a deployment question (which model/region) or a grounding question (cite the source document), and leading with modality alone will land you on a real-but-wrong vision service.
Reflection Question: Why does running the filters in order matter — what kind of wrong answer does each earlier filter let you discard before you even consider modality?
