Prompts and model settings in the playground

A prompt is the text you send to a model so it knows what to do with the user’s message. Model settings—such as temperature, top_p, and max_tokens—change how long the reply is and how much it varies from one try to the next. Together they answer a practical question: will this assistant behave the way your product needs before you wire it into code?

Concept 4 showed how to deploy a model and call it through an endpoint. This concept stays in the Microsoft Foundry portal and focuses on shaping behavior in the model playground and, when you need tools later, the agents playground. You iterate on wording and settings here so token use and reply quality are closer to what you expect when the same deployment powers an app or agent.

Microsoft Foundry playgrounds are on-demand chat environments for rapid prototyping, API exploration, and technical validation. You need an Azure subscription, a Foundry resource, and at least one deployed model. When you deploy a model in the Microsoft Foundry portal, you land on its playground immediately, so you can test prompts without creating a separate project or installing SDKs first.

• Use the model playground when you are tuning a single deployment, exporting multilingual samples, or benchmarking latency and tokens.
• Use the agents playground when the idea needs memory, knowledge, or several tool calls across turns.
• Foundry picks a modality when the model requires it—for example an images playground for gpt-image-1 or a video playground (preview) for Sora-2.
• From the Code tab in the chat pane, Open in VS Code for the Web imports your sample, endpoint, and key into a browser workspace.

Compare mode runs the same prompt against up to three deployments at once. Each model receives the same prompt context, system message, and parameter configuration, with responses streaming side by side so you can judge latency, token throughput, and answer quality. This is the fastest way to answer which model fits your price-to-performance target before you invest in deeper integration work.

• Open the playground for a deployed model and select Compare models in the upper-right corner.
• Select up to two more models from existing or new deployments; chat panes open with synced prompt bars.
• Enter a prompt in any bar; it appears in the others when sync is on. Turn sync off from the Setup pane for a model if you need different settings.
• Submit the prompt and read outputs from each model at the same time.
• Open the Code tab on the model you prefer for multilingual samples, or select Save as agent to continue in the agents playground.
• Close compare mode before you need the Tools section—tools are only available in single-model view, not while comparison panes are open.

Treat compare runs as controlled experiments: keep the system message fixed, change one setting or one model at a time, and note token usage when Concept 4’s deployment type already sets your cost per token.

In chat-based calls, messages carry roles such as system, user, and assistant. The system message is the highest-level instruction: it defines the assistant’s role and boundaries, tone, output format, and what to do when information is missing. A system message influences the model but does not guarantee compliance, so you still test with realistic and adversarial inputs.

• State the job in plain language first—what a typical successful request should produce.
• List topics or actions the assistant must refuse or avoid for your scenario.
• If the app expects a fixed shape, describe the output contract explicitly (for example JSON keys) and keep it small and stable.
• Add a when-unsure policy: ask a clarifying question, say you do not know, or refuse out-of-scope work.
• Keep instructions unambiguous and avoid conflicting rules such as be brief and be comprehensive without saying which wins.

User messages carry the task and primary content. Few-shot examples—sample user and assistant turns after the system message—show the pattern you want without retraining the model. Order matters because models can weight recent text more heavily; repeating critical instructions after long content sometimes improves adherence. Clear separators and headings in the prompt make outputs easier to parse.

Broader prompt patterns in Microsoft’s prompt engineering techniques article are not recommended for reasoning models such as gpt-5 and o-series models. For those models, rely on their native reasoning behavior and validate outputs rather than chain-of-thought style tricks meant for non-reasoning chat models.

The model playground exposes parameters that shape each reply. Temperature can be set between 0 and 2. Higher values (for example 0.7) make wording more random and divergent; lower values (for example 0.2) make replies more focused and concrete—useful when you need consistent phrasing rather than creative variation. Top_p (top probability) also controls randomness but through a different mechanism. Microsoft’s guidance is to change temperature or top_p one at a time, not both at once, then compare results.

• Long system messages consume context window space and leave less room for user content—trim prose before you raise max tokens.
• In single-model view, expand Tools, select Add, then Code interpreter, and attach code files when the model supports sandbox execution.

When your application must read the model reply programmatically, plain prose forces fragile parsing. Structured outputs make the model follow a JSON Schema you supply as part of the inference call. This differs from older JSON mode, which guaranteed valid JSON but could not enforce strict adherence to your schema. Use structured outputs for extracting fields, function calling with strict shapes, and multi-step workflows where each step expects known keys.

• With Chat Completions, define the schema in response_format; with the Responses API, define it in text.format.
• In the playground, specify the output contract in the system message as a first step, then move the same shape into code once behavior is stable.
• For function calling with structured outputs, enable strict mode; set parallel_tool_calls to false because structured outputs are not supported with parallel function calls.
• Check for refusals in SDK responses—the model may decline a request instead of returning malformed JSON.

Keep schemas minimal: required keys only, stable names, and no extra fields your code does not read. Test edge cases (empty input, ambiguous names) in the playground before you depend on parsing in production.

Example: an online shop builds a returns assistant on its existing gpt-5-mini deployment. The team writes a short system message defining scope (returns and shipping only), tone (polite, concise), and a when-unsure rule (ask for an order number). They add two few-shot user and assistant pairs showing approved refund wording, set temperature low for consistent policy language, and turn on structured output with fields order_id, issue, and next_step. They run ten real chat transcripts in compare mode against a second deployment before exporting code from the Code tab.

• Assuming a system message alone enforces safety—pair instructions with guardrails in the playground and later evaluation (Concept 8).
• Editing temperature and top_p together so you cannot tell which change helped.
• Leaving compare mode open and wondering why Tools disappeared—close extra model panes first.
• Using elaborate prompt-engineering patterns on gpt-5 or o-series models where Microsoft advises simpler prompting.
• Paying for agents playground evaluations you do not need—they are enabled by default and included in consumption-based billing until you open metrics in the upper-right of the agents playground and unselect evaluators.

Concept 6 adds knowledge—files and Azure AI Search—so answers can cite your catalog instead of guessing. Once prompts and settings behave in the playground, attach grounded knowledge and tools in the agents playground.

• Playground types, compare mode, tools, and troubleshooting: Microsoft Foundry playgrounds
• System message role, boundaries, and design checklist: System message design
• Few-shot learning, temperature, top_p, and ordering tips: Prompt engineering techniques
• JSON Schema in Chat Completions and Responses API: Structured outputs