The constraint vocabulary

This card is not about multi-agent systems. It is about how questions on multi-agent
systems have to be built, which turns out to be predictable once you notice three
things about the exam.

Why the questions have the shape they do

It is expert level, with a prerequisite. You reach AI-500 through the Azure AI
Apps and Agents Developer Associate certification, earned by passing AI-103. So
nothing AI-103 already tests gets tested again for its own sake. You will not be
asked what an embedding is. You will be asked what to do when retrieval returns the
right-looking wrong document.

Over half the exam sits after the design is decided. Develop in Azure is 30–35%.
Evaluate, optimise and monitor is another 20–25%. Architecting — the part that feels
most expert-level and is the most enjoyable to revise — is 15–20%, the smallest
domain on the paper.

There is no single right answer at the level of names. Every orchestration
pattern is defensible in the abstract. Every build shape has a case. Which forces
question writers into scenario form, where a constraint decides.

That last point is the useful one, because it means the constraint is the
question and everything else is scenery.

Read in this order

A scenario question has four parts and they are not equally important: the setup,
the constraint, the ask, and the options.

Read the constraint first — the one or two sentences that decide the answer.
Then the ask: recommend, implement, or do first. Then the options. Then the
setup, only if you still need it.

Reading top to bottom means you meet the options while still holding all the
scenery, and the scenery is what makes a wrong-but-familiar option attractive.

The phrases that decide answers

These recur, and each points somewhere specific.

"Must be identical every time" → a deterministic tool, not an agent.
"Users should only see what they have access to" → on-behalf-of.
"Revoke one agent without affecting the others" → per-agent identity.
"We cannot know the impact until real users hit it" → canary.
"Must not be reachable from the internet" → private endpoint.
"Another team owns it and we cannot change it" → A2A.
"Several agents need the same capability" → MCP via a toolbox.
"The steps are not known in advance" → Magentic / orchestrator-subagent.
"Quality has fallen but nothing changed" → drift; a fixed set on a schedule.
"It takes twenty minutes" → background mode or durable execution.
"It must never do X" → a structural control, never an instruction.
"Minimise what we manage" → prompt agent.
"We need specific CPU and memory" → hosted agent.

Learning that list is worth more than learning any product's feature inventory,
because these phrases are how a scenario expresses a constraint without naming the
answer.

The five distractor patterns

The right idea at the wrong layer. A prompt-level answer to a structural
problem — "instruct the agent never to…" against a requirement that says must
never. This is the single most common distractor in this subject.

Correct, but not first. Everything in the option is true and good; it is simply
not the first move. When the ask says first, it is testing an ordering — and this
guide gives you three: filter → hybrid → rerank → k; the cost ladder; and workflow
→ agent → tool.

The more sophisticated answer. Multi-agent where one agent does it. Fine-tuning
where a prompt change does it. Group Chat where Sequential does it. Expert exams
reward knowing when not to reach for the powerful thing.

A measurement that does not measure the thing. Groundedness offered where
retrieval correctness is the problem. Fluency where task completion is the problem.
Live traffic where drift is the problem.

The name-swap. A real term used for the wrong concept — impersonation for
delegation, a key for a secret, RAG for fine-tuning.

Two tiebreakers

When two options both look right, one of these usually settles it.

Enforced beats requested. A control the system applies beats a behaviour the
system asks for.

Smaller beats more capable. The simplest sufficient design beats the most
powerful one.

On case studies

Extract the constraints into a list before answering anything — regulated?
cross-team? latency? residency? existing systems? You build that list once and it
answers most of the questions.

And watch for the constraint that appears in exactly one paragraph. Case studies
bury one decisive fact — a residency requirement, an agent owned by another team, a
system with per-user permissions — in the middle of otherwise neutral background.
That sentence is usually why the case study exists.

The trap

If you are revising the architecture chapters because they feel the most
expert-level, you are revising the smallest domain on the paper.

The centre of gravity of this exam is not "can you design a multi-agent system". It
is "can you make one work, prove it works, and keep it working".