2.4.2. Custom Prompts and the Foundry Model Catalog
💡 First Principle: A custom prompt is a packaged unit of model reasoning — instructions plus inputs plus a model — that an agent invokes as a tool. Opening the model slot to the Foundry catalog turns model choice into a per-task decision: the right model for this prompt, not one default for everything.
Custom prompts (built with AI Builder's prompt builder) are how makers embed focused generative steps into agents and topics: summarize this complaint, extract these fields, classify this request, draft this reply. Each prompt defines its inputs (text, and where supported, documents or images), its instructions, and its output shape — and each prompt selects its model. By default that's the platform's managed model; with the Foundry model catalog, the prompt can instead run a model you choose — including specialized or fine-tuned deployments — matching capability, cost, and latency to the task at hand.
The design consequence: an agent becomes a portfolio of model decisions. The high-volume classification prompt runs a small fast model; the legal-analysis prompt runs the fine-tuned deployment; the general chat stays on defaults. Each decision is local, swappable, and testable on its own — which is exactly how the exam frames it, as requirements like "the summarization step must use the department's approved model" that resolve to configure the prompt's model, not change platforms.
⚠️ Common Misconception: Custom prompts can only use the default GPT model. The model picker is per-prompt, and the Foundry catalog is the menu — easy to miss, frequently tested.
Reflection Question: One agent needs cheap high-volume ticket classification and occasional deep contract analysis. Why is "two prompts, two models" the architecture — and what would you measure to justify each model choice?
