Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-102.1 Design and implement advanced prompt engineering strategies in multi-agent solutions

Match each quality gap to its fix

Completed by the knowledge check

Learning objective

Choose prompting, grounding, model switching, or fine-tuning; compare supported supervised, preference-based, and reinforcement fine-tuning strategies (SFT, DPO, RFT) when relevant.

Core idea

Choose an intervention from the observed failure, rather than from the amount of customization it offers. An ambiguous task needs clearer instructions. Missing enterprise evidence needs grounding. A capability mismatch needs a different model. A repeated behavioral pattern that you can teach or score might justify fine-tuning.

These changes can coexist, but they solve different problems. Training a preferred writing style does not supply a policy document that changes tomorrow. Retrieving that document does not make an unsupported model interface available. For an architect, the useful comparison is the smallest change that passes the same task evaluation while meeting operational requirements. Prompt comparison and promotion are covered in 2.1.4; workload-to-model fit is covered in 1.1.11.

How it works

Diagnose before changing the model

Prompting changes what you ask the deployed model to do. Clarify the role, constraints, examples, and result contract using the patterns in 2.1.1 and 2.1.2. The Agent Service overview labels the agent optimizer preview; see 2.1.4 for its prompt-version comparison and promotion workflow.

Grounding supplies evidence at inference time. In a Foundry agent, AzureAISearchTool connects the agent to an Azure AI Search index. Its query_type supports simple, vector, semantic, vector_simple_hybrid, and vector_semantic_hybrid, with vector_semantic_hybrid as the default. Its filter applies to all queries the agent makes to that index. Use this mechanism when a response needs the organization’s retrievable facts, and inspect whether the selected evidence actually supports the answer; see 0.8.

Model switching changes the model serving the role. The preview agent optimizer’s Compare across models option evaluates candidate deployments against the same dataset with per-evaluator scores for each model. A candidate that follows the task more reliably can remove the need to train a custom model. Switching still requires the target to satisfy the role’s interface and operational constraints; do not interpret one aggregate score as proof that every role or tool path improves.

Fine-tuning updates a model from task-specific training signals. Microsoft Foundry distinguishes managed fine-tuning from interactive training. Managed jobs expose supported data, hyperparameters, and RFT graders. Interactive training is preview and requires explicit access approval; it exposes training-step control in Python. The SFT, DPO, and RFT comparison here concerns managed fine-tuning, not an assumption that every model supports arbitrary custom training loops.

Match the training signal to the method

Supervised fine-tuning (SFT) learns from prompts paired with desired responses. Use it when you can demonstrate the target behavior: a stable extraction format, domain terminology, or a role-specific response pattern. The v1 job mechanism is client.fine_tuning.jobs.create() with method.type set to "supervised". Each JSONL training example contains a conversation in messages, including the desired assistant response. Data governance and evaluation belong to 2.1.7.

Direct preference optimization (DPO) learns from comparisons. Each example has input.messages, preferred_output, and non_preferred_output, with exactly two outputs answering the same input. The job uses method.type: "dpo". Choose DPO when you can judge which response better meets a preference, such as concise but complete explanations, without claiming there is only one acceptable answer. Pairwise judgments must reflect the intended behavior rather than incidental differences in verbosity or presentation.

Reinforcement fine-tuning (RFT) learns from scores assigned to generated responses. The job uses method.type: "reinforcement" and a grader under method.reinforcement.grader. Choose it when you can reliably score task outcomes, including problems with multiple valid solutions. The grader defines the reward signal; it is not interchangeable with a preferred-response pair or a target assistant message.

The RFT guide documents string comparison, text similarity, model, Python, and combined grading approaches, subject to selected-model support. For an exact label, type: "string_check" with operation: "eq" returns a score of 1 for an exact, case-sensitive match and 0 otherwise. That mechanism fits an exact label contract, but not a nuanced explanation whose quality cannot be reduced to label equality. A model learning to maximize a weak grader can improve reward without improving the business task.

Check support before planning training

Foundry’s supported-model table makes methods model-specific. For example, gpt-4.1 version 2025-04-14 supports managed SFT and DPO, while o4-mini version 2025-04-16 supports managed RFT. The table lists gpt-4o-mini version 2024-07-18 with SFT, not all three methods. An inference-capable deployment therefore does not establish training-method support.

Verify the exact model version, training type, training region, and deployment option as separate choices. The overview distinguishes Standard, Data zone, Global, and Developer training. Data zone training supports only the US data zone. Developer training has no latency or service-level agreement guarantees and jobs can be preempted and resumed; it also provides no data residency guarantee. Do not infer serving support in a region from training availability there. Interactive training, managed-compute deployment, and Fireworks on Foundry deployment have preview labels in the overview; those labels do not establish that every managed fine-tuning method is preview. Base-model status is separate too: the table labels gpt-oss-120b, Qwen3.6-35B-A3B, and Muse-Glimmer-30B preview.

Key distinctions and trade-offs

Knowledge versus behavior: Grounding adds request-time evidence. Fine-tuning changes learned behavior. Keep changing policy content in the retrievable source even when a trained model improves how a role explains it.

Examples versus comparisons versus rewards: SFT demonstrates an answer, DPO ranks two answers, and RFT scores sampled answers. Having abundant data in one shape does not make it valid data for another method.

Prompt change versus model change: A model comparison can show that clearer instructions are sufficient, or that a different deployment performs better. Avoid combining both changes without preserving evidence of what caused the improvement.

Fine-tuning adds dataset maintenance, training, deployment, and reevaluation responsibilities. It earns that cost when the target behavior is stable enough to learn and the evaluated improvement persists beyond the training examples. Grounding and model selection still remain part of the resulting system.

Architecture / decision scenario

A support system has four measured defects. The intake agent omits a required category because its instructions leave the categories undefined. The policy agent answers from stale facts. The explanation agent produces inconsistent but factually valid responses. A reasoning specialist fails complex eligibility cases.

The team clarifies intake instructions and evaluates the prompt candidate. It grounds the policy agent through AzureAISearchTool, including the appropriate index filter. It uses the preview agent optimizer’s Compare across models option to test whether another deployment solves the reasoning failures before paying for training.

For persistent behavior defects, curated desired extraction outputs justify SFT. Paired explanations of the same policy result justify DPO when reviewers reliably prefer one. RFT becomes a candidate for eligibility reasoning only if a supported model and trustworthy outcome grader are available. The team checks gpt-4.1 SFT/DPO support separately from o4-mini RFT support and sends each dataset through the governance gates in 2.1.7. It retains retrieval for policy facts in every candidate.

Common exam traps

  • Fine-tuning to refresh frequently changing enterprise facts instead of grounding them.
  • Assuming a model supports SFT, DPO, and RFT because it supports inference.
  • Calling two unrelated responses a DPO pair.
  • Using an RFT reward increase as proof of independent task improvement.
  • Confusing training-region availability with deployment-region availability.
  • Treating interactive training preview status as the status of every managed method.

What to remember

Diagnose the failure, test prompting and grounding, compare models, and train only when a stable behavioral gap remains. Select SFT for demonstrations, DPO for same-input preference pairs, and RFT for reliable rewards. Verify the model and method together, then evaluate the resulting system against held-out tasks.

Knowledge check

References