A software company wants an internal knowledge-base assistant that always follows the same sequence: retrieve relevant documents, pass them to the model with a fixed instruction template, then log the retrieved sources alongside the answer for auditing. A developer could write this logic in custom application code that calls the model directly, but the team instead builds it as a flow inside Microsoft Foundry with distinct connected steps for retrieval, prompt construction and logging. What is the main advantage of building this as a Foundry flow rather than a single direct model call from application code?
Select an answer to reveal the explanation.
Short Explanation
Think about the difference between writing one long tangled function versus breaking the same task into clearly labeled steps that each do one job. That is the real payoff here. When retrieval, prompt building and logging are separate, visible pieces, someone can swap out the retrieval step later, tighten the prompt template, or add a new logging field, all without touching the other parts or re-reading a giant block of custom code. None of this changes what model gets used, that still has to be chosen deliberately, and it does not make the assistant infallible, which is exactly why the team is still logging its sources for someone to check later. It also does not make any of the underlying steps free; whatever gets called still costs whatever it normally costs. The advantage is really about clarity and maintainability of a process that has several moving parts, not about the process becoming smarter, cheaper or self-selecting on its own.
Full Explanation
The correct answer is D. Structuring the work as a flow with separate steps for retrieval, prompt construction and logging makes each part of the process something the team can inspect, modify and test on its own, so if the retrieval step starts returning weak matches, or the logging needs a new field, that piece can be changed without rewriting the whole pipeline; a single direct model call buried in application code would mix all of this logic together, making it harder to reason about or reuse across other tools. Option A is incorrect because flows still require the team to choose and configure a specific model deployment for the prompt step; there is no automatic model selection happening on their behalf. Option B is incorrect because no orchestration structure guarantees correctness; a flow can still produce a wrong answer if the retrieved documents are irrelevant or the model misinterprets them, which is exactly why the team is logging sources for auditing rather than trusting the output blindly. Option C is incorrect because retrieval and logging steps that call any billed service still incur normal costs, and building steps as a flow does not itself change how usage is metered.