Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-101.1 Design logical architecture for multi-agent solutions

Assign models from measured workload requirements

Completed by the knowledge check

Learning objective

Match model family capabilities to task quality, latency, context, tool use, and cost requirements.

Core idea

Select a model for a workload contract, not for a position in a capability ranking. A classifier, a document comparison specialist, and a tool-using planner can require different models even within the same solution. First eliminate candidates that cannot support the required input, output, API, tool interface, context, or deployment conditions. Then measure quality, latency, and cost on representative work.

Family labels help form a shortlist; they do not prove fitness. A small model can satisfy a narrow classification contract, while a reasoning model can earn its extra budget on ambiguous, multistep decisions. Both claims require evaluation for your task. See 0.1 for capability families and 0.2 for token fundamentals; this lesson turns those concepts into architectural allocation decisions.

How it works

Define quality as a task outcome

State what a successful result means before comparing models. For extraction, that might be correct fields with valid values and explicit handling of missing evidence. For planning, it might be a feasible sequence using only permitted tools. For a specialist answer, it might be accurate evidence selection and a calibrated refusal when the source cannot support a conclusion.

Use the same representative cases, output contract, and validation rules for each candidate. Include ambiguity, missing information, incorrect tool results, and difficult inputs rather than only clean examples. Measure rejected or escalated cases as outcomes rather than deleting them from the comparison.

Microsoft describes reasoning models as supporting advanced problem solving, complex document comparison, and workflow-related instruction following. Compare accepted results and downstream correctness to establish their fitness for your task.

Keep task-specific acceptance criteria and deterministic business constraints outside model discretion; see 1.1.2.

Check modality, context, and deployment limits

The Foundry catalog documents capabilities for exact model IDs and versions. For example, gpt-4.1, gpt-4.1-mini, and gpt-4.1-nano support text and image input, text output, the Chat Completions and Responses APIs, streaming, function calling, and structured outputs (Chat Completions). An image-input capability does not mean image generation or audio input is supported.

The GPT-4.1 table lists a 1,047,576-token context window but qualifies it with deployment limits: 300,000 tokens for standard deployments and 128,000 for provisioned managed and batch deployments. Maximum output is 32,768 tokens. A provisioned managed GPT-4.1 request exceeding its limit returns HTTP 400. Enable spillover to route such requests to a corresponding standard deployment. Use the applicable deployment limit and configured traffic route, not the largest number in the family table.

Budget instructions, evidence, history, tools, and output together. For a 150,000-token request, weigh spillover to a compatible standard deployment against splitting the evidence, then re-evaluate quality and latency.

Reasoning tokens also occupy context and consume the generation budget. Reserve room for deliberation, and evaluate whether the model identifies decisive evidence at realistic input lengths and positions.

Verify tool use on the selected API

Function calling, parallel tool calling, and structured output are separate capabilities. Check the exact model and API combination. A valid JSON answer does not prove that the model can call tools, and a tool-capable model does not automatically support every concurrency pattern.

Microsoft’s reasoning documentation gives an explicit compatibility case: gpt-5.6 models cannot combine function tools with reasoning effort in Chat Completions. The recommended route for reasoning with tools is the Responses API. If Chat Completions is required, the documented workaround sets reasoning_effort to none, which gives up reasoning for those tool calls. Omission is insufficient because the documented default is medium.

Verify model, API, supported parameters, and output handling as one contract when changing deployments.

Also evaluate argument correctness, tool selection, unnecessary calls, and recovery from errors. Supported tool calling is an interface capability; reliable use of your specific tools is an empirical quality requirement. Tool authorization remains the executor’s job; see 1.1.7.

Measure latency through the complete task

Distinguish time to first output from time to a completed valid result. Microsoft’s latency guidance expresses generation time as TTLT = TTFT + (TBT × Tokens Generated): time to last token combines time to first token and time spent generating the output.

Azure Monitor exposes AzureOpenAITimeToResponse for first-response responsiveness, AzureOpenAITTLTInMS for overall response time, and AzureOpenAINormalizedTBTInMS for time between tokens. Pair latency with GeneratedTokens and ProcessedPromptTokens so a longer output is not mistaken for a service regression.

Measure the application’s end-to-end duration too. A planner that calls three tools sequentially adds tool and orchestration time beyond one inference call. Streaming improves perceived responsiveness but does not shorten the total time to generate all tokens. A streamed draft that still awaits tool validation is not a completed task.

Compare the cost of accepted outcomes

Reasoning tokens are billed as output tokens. Responses reports them in output_tokens_details.reasoning_tokens; Chat Completions reports completion_tokens_details.reasoning_tokens. A short visible answer can therefore hide substantial billed generation.

For supported reasoning models, reasoning_effort controls deliberation, but its accepted values and defaults vary by model. Do not apply one family’s setting to another without checking support. max_output_tokens in Responses and max_completion_tokens in Chat Completions cap generation including reasoning and visible output. An insufficient cap can produce an incomplete response before useful visible content appears.

Check Responses status and incomplete_details.reason, including max_output_tokens, before accepting the result. Budget savings that leave work incomplete are not equivalent to cheaper successful execution.

Compare cost per accepted result using verified deployment prices and observed tokens, repeated calls, and retries. Lower token rates can lose their advantage when a candidate needs repeated correction or escalation.

Consider managed model routing

Microsoft Foundry model router is deployed like a model and selects an underlying model for each prompt. Its routing mode offers Balanced (the default), which selects the most cost-effective model within a small quality band; Quality, which selects the highest-rated model for the prompt regardless of cost; and Cost, which permits a wider quality band to seek savings. Evaluate these modes against the same task contract rather than assuming managed routing guarantees acceptance.

Use model subset to restrict routing to approved models; that subset also defines the failover set. Select at least two models to benefit from fallback. The effective context window is limited by the smallest underlying model, so exclude candidates that cannot support the required context. A larger model elsewhere in the pool does not make every routed request safe. This managed alternative reduces hand-built selection logic while keeping model eligibility and context fit your responsibility.

Key distinctions and trade-offs

Capability versus quality: The catalog proves interface support. Representative evaluation determines whether the model meets your result contract.

Context capacity versus useful evidence: A supported token count establishes request capacity, not reliable reasoning over all supplied content.

First output versus completion: Streaming responsiveness and completed, validated work need separate latency measurements.

Token price versus task cost: Include reasoning, repeated context, retries, and correction when comparing cost per accepted result.

Compare explicit role routing with model router. Either choice must preserve approved-model eligibility, tool compatibility, context fit, and result validation.

Architecture / decision scenario

A contract review solution separates field extraction from conflict analysis and tool-backed case updates. The team shortlists gpt-4.1-mini for extraction because its documented interface supports the input and structured output contract. It accepts that deployment only after evaluation shows adequate field accuracy, latency, and task cost.

Conflict analysis reserves reasoning-token budget. Documents exceeding the GPT-4.1 provisioned managed limit would return HTTP 400 without a supported route. Weigh spillover to a corresponding standard deployment against splitting evidence, and test whether decisive clauses survive. For managed selection, evaluate model router’s Balanced, Quality, and Cost modes with an approved model subset whose smallest context window supports the request; the same subset bounds failover.

The planner must reason while calling tools. For a gpt-5.6 candidate, the architecture uses Responses rather than assuming Chat Completions supports that combination. It measures first response and full validated completion separately, records token usage including reasoning, and treats status: "incomplete" as an unsuccessful result. The final allocation satisfies all five requirements together: quality, latency, context fit, tool compatibility, and cost per accepted case.

Common exam traps

  • Choosing the strongest family for every role without a task contract.
  • Applying an advertised context maximum to every deployment type or ignoring model router’s smallest-model constraint.
  • Equating structured output with reliable tool execution.
  • Assuming streaming reduces time to complete the whole workflow.
  • Counting only visible answer tokens or accepting incomplete output as success.

What to remember

Filter by exact model, version, API, and deployment support before benchmarking. Evaluate realistic task quality, full completion latency, context fit, tool behavior, and total cost together. Allocate models by role only when each path preserves the workload’s acceptance and authorization contracts.

Knowledge check

References