Plan and configure agent solutions

A user asks the HR agent to cancel a leave request and it just does it: no confirmation, no approver, no durable record of who authorised the change. Nothing malfunctioned. Generative orchestration picked a tool it was allowed to pick, at a moment nobody had pinned down, because it selects tools, knowledge sources and wording from names, descriptions and conversation context (Microsoft calls the deciding side the planner; this guide says the orchestrator). That is the shape of most failures in this domain, and it gives you the one rule the whole domain hangs on: a requirement only exists at runtime if it lands on a configuration surface, a named setting, node or page you can point at and set. The trap is the requirement written as words instead: a disclaimer buried in agent instructions, a prohibited connector listed in a project wiki, an endpoint identifier mentioned in a tool description. Instructions shape behaviour; they never enforce it.

At 30–35% this is the middle of AB-620's three domains by weight, and the only one that starts before anything exists in the product. Plan the solution (seven subtopics) settles the constraints everything else inherits: which tool mechanism reaches each enterprise system, whose identity runs each call, which channels carry the agent, what responsible AI and governance controls apply, what gets factored into reusable modules, and whether the audience is internal or external. Build the agent flows (six subtopics) is where deterministic work lives, because an agent flow runs authored actions along rule-based paths behind a declared agent-facing contract: creating one, pausing it for a human checkpoint, wiring connector operations, declaring inputs and outputs, handling failure, and monitoring runs afterwards. Configure the topics (nine subtopics) is the conversation itself, the authored call sites where you fix the exact step, wording and rendering, from flows and tools on the canvas through response formatting, custom prompts, custom knowledge, HTTP calls, generative answers, Adaptive Cards and variables. The table places every subtopic in its phase; the tree after it answers a different question, routing a requirement to where it belongs: environment governance, an agent flow, a topic, or agent-level configuration. The sibling domains take over where this one stops, with Integrate and extend agents in Copilot Studio reaching outward to enterprise data, protocols and other agents, and Test and manage agents evaluating and releasing what you built here.

Copilot Studio usually offers the same outcome at more than one level, and the tighter fit is the default this exam rewards: a topic-level tool over an agent-level tool when the moment is fixed, a structured status output over prose the topic has to interpret, a pinned input value over a hint in a description, node-level knowledge over the agent's whole set, a Power Platform data policy over a documented convention, and End user credentials over Maker-provided credentials unless the resource is deliberately shared. Two questions resolve most of these on sight: who picks the moment this runs, an authored call site or the orchestrator, and whose identity the call runs as. Then check the two facts that hold in every phase, because they decide whether your correct configuration is actually the one in front of users: nothing you change is live until you publish, and the tightest limit anywhere in the runtime path is what the user experiences.