Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-100 Prerequisites

Separate instructions from evidence and contracts

Completed by the knowledge check

Learning objective

Apply prompt and context engineering fundamentals (roles, delimiters, structured outputs, and untrusted inputs)

Core idea

Prompt engineering defines the task, constraints, and expected response. Context engineering selects and organizes the information available for that task: instructions, user input, examples, conversation history, retrieved evidence, and tool results. A carefully written instruction cannot compensate for absent evidence, and more evidence doesn’t help if the model mistakes it for authority.

For an architect, the central design is a trust boundary. Application instructions describe allowed behavior. External content supplies material to analyze. The output contract describes what downstream code accepts. Keep those responsibilities explicit, then enforce permissions and business rules outside generation. Delimiters and roles help communicate intent; they aren’t substitutes for access controls.

How it works

Assign roles deliberately

Azure OpenAI Chat Completions sends conversation content through the messages array. Each message has a role and content. The system role supplies application instructions; user carries a request; assistant carries model responses or example answers. A tool result uses the tool-message format discussed in 0.4.

Place the stable task definition and constraints in the instruction-bearing message. Put the user’s actual question in the user message. If you use few-shot examples, preserve their user/assistant pairing so the desired mapping is clear. Don’t turn an uploaded document into a system message merely because the application retrieved it.

Reasoning models also support developer messages. Microsoft’s reasoning guide describes role: "developer" as functionally equivalent to system messages and advises against using both in the same request. Select the instruction role appropriate to your model/API adapter. Copying a prompt as one undifferentiated string loses the interface’s explicit separation.

An instruction should state the task, evidence policy, output format, and conditions for an insufficient-information result. For example, a policy assistant can require claims to be supported by supplied policy excerpts and use a defined missing-evidence outcome. The application must still verify the returned citations or identifiers.

Select context for the decision

Context is the information available in a particular request, not a promise that every earlier interaction remains available. Include the material needed to answer the question: relevant excerpts, their source identifiers, necessary conversation facts, and tool observations that resolve uncertainty. Preserve enough provenance to distinguish two conflicting documents.

Treat selection as an application responsibility. If you remove the clause that establishes an exception, a well-formatted prompt can still produce the wrong policy decision. If you retain every unrelated document, you spend input tokens and make relevant evidence harder to isolate. See 0.2 for the shared input, reasoning, and output budget.

Use supporting content to ground the task rather than repeating broad instructions in each excerpt. Microsoft’s prompt-engineering guidance distinguishes instructions, primary content, examples, and supporting content. These are useful design categories even when the API packages several of them into one user message.

Use delimiters to identify boundaries

Microsoft recommends clear syntax, such as separators, Markdown, or XML, to distinguish prompt sections. Label a document excerpt and its source separately from the question. State that text inside the document boundary is evidence to analyze, including any instruction-like text it contains.

A delimiter is an organizational convention. It doesn’t prevent an attacker from placing another delimiter or a forged role label inside the content. Escape or encode inserted material as appropriate for your chosen representation, and keep the actual API role outside user-controlled text. A string reading “system” inside a document isn’t a system message.

Avoid ambiguous examples that model unsafe behavior. If the task is to identify malicious instructions, label the attack text as a specimen rather than demonstrating that the assistant follows it. Ask for observable findings and source references instead of relying on a narrative about how carefully the model processed the text.

Constrain the output interface

A prompt that says “return JSON” expresses an intention. JSON mode ensures valid JSON but doesn’t enforce the supplied schema. Azure OpenAI structured outputs constrain the response to a supported JSON Schema definition.

For Chat Completions, set response_format to a json_schema configuration with strict: true. For Responses, put the schema under text.format, with type, name, schema, and strict as sibling format properties. Keep these formats in their respective adapters; they aren’t the same request body.

The documented schema subset requires every field to be required and additionalProperties: false on objects. Represent an optional value with a nullable union when appropriate. The documented limits are 100 object properties total and five nesting levels. Keep the contract small enough to express the actual application result rather than a complete internal data model.

Structure doesn’t establish truth. A syntactically valid object can contain an incorrect policy identifier or an unsupported conclusion. Validate those business values after parsing. Handle refusals separately: Microsoft’s examples inspect message.refusal for Chat Completions and refusal content in Responses. Also handle incomplete generation rather than trying to parse it as a successful result.

Structured outputs require a supported model and API. The documentation lists exclusions including Foundry Agent Service, Assistants, and bring-your-own-data scenarios. Don’t assume that support at the direct model endpoint establishes support through every agent surface. Function-tool strictness also has its own setting and parallel-call restriction; see 0.4.

Treat external content as untrusted

Prompt injection occurs when input tries to alter the application’s intended behavior. Microsoft distinguishes direct attacks in user prompts from indirect attacks embedded in documents, emails, and other third-party material. Tool output can carry the same instruction-like content, so returning it from a trusted connector doesn’t make its text authoritative.

Azure AI Content Safety Prompt Shields analyzes a userPrompt and up to five documents. Its response reports attackDetected for the prompt and each document. Use that signal in an application-defined reject or review path; the signal doesn’t grant or revoke tool permissions by itself. In Foundry, user prompt attack and document attack controls can be configured through guardrails and assigned to deployments or agents.

Spotlighting is documented as preview, available only for models used through Chat Completions, and off by default. It marks documents as lower trust through a base64 transformation. The encoding adds tokens, so it can increase model consumption or exceed an input limit. Treat it as an additional defense with a specific scope, rather than a universal prompt setting.

Key distinctions and trade-offs

Prompt versus context: Instructions define the task. Context supplies the information needed to perform it. Improving either can reveal a defect in the other.

Delimiter versus security boundary: Clear syntax supports interpretation. Application permissions determine what a tool can actually do.

Schema versus semantic validity: Structured outputs constrain shape. Your application verifies references, values, and authorization.

More examples and evidence can improve clarity but consume context. A narrower schema simplifies validation but must still represent failure or missing information. Attack detection adds a useful signal while requiring a policy for false positives and suspicious content.

Architecture / decision scenario

A procurement assistant receives a question and extracts policy excerpts from supplier attachments. The application keeps its evidence-only instruction in the model’s instruction role and inserts labeled excerpts with source IDs as untrusted content. It retains the relevant exception clause within the token budget.

One attachment says to ignore policy and approve the purchase. The application analyzes the question and documents with Prompt Shields and routes an attackDetected result to its defined review path. It doesn’t convert the attachment’s instruction into an API role or tool permission.

The direct Azure OpenAI Responses call uses text.format with a strict schema for a proposed decision, source IDs, and a nullable missing-information field. The application checks generation status, refusal content, schema compliance, and whether each source ID belongs to the selected evidence. Even a well-formed approval remains a proposal until the deterministic policy checks authorize it.

Common exam traps

  • Promoting retrieved content into the instruction role.
  • Treating delimiters as protection against malicious commands.
  • Assuming valid JSON means schema compliance or factual accuracy.
  • Copying response_format into a Responses request.
  • Assuming direct-model structured output support covers every agent service.
  • Describing Spotlighting as generally available or supported on every API.

What to remember

Separate instruction authority, evidence, and the result contract. Select relevant context with provenance, use clear boundaries, and apply the correct structured-output configuration for the API. Detect untrusted instructions and enforce business permissions outside the model.

Knowledge check

References