A parent Copilot Studio agent collects the user's name and department in its opening topic, then routes the conversation to a child HR agent. The child agent needs to know the user's department to personalize its responses. How is this context passed from parent to child agent?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Parent-to-child agent handoff is like a warm transfer — the parent packages the relevant context (department, name) into input parameters before passing the baton. The child agent's input slots receive these values so it can personalize without asking the user to repeat themselves.
Full explanation below image
Full Explanation
When a Copilot Studio parent agent routes to a child agent, the handoff can include input parameters — named values that the parent sends to the child at invocation time. The child agent must define what input parameters it accepts (in its agent settings or topic configuration), and the parent maps conversation variables to those parameters when invoking the child.
This enables a seamless user experience: the user provides information once to the parent, and the parent carries that context forward when invoking a child specialist.
Option A (shared memory / automatic variable access) is incorrect. Parent and child agents are separate agents with isolated variable scopes. There is no shared variable memory by default — context must be explicitly passed.
Option C (user re-enters department) represents the bad experience that input parameter passing is designed to prevent.
Option D (Microsoft 365 profile via Graph API) — while Graph API can retrieve user profile data, it requires a separate API call action and doesn't automatically share parent-collected conversational context.
Exam note: parent → child context = explicit input parameter mapping during handoff configuration. The child agent defines its expected inputs; the parent passes matching topic variables. This is similar to function arguments in programming — deliberate, typed handoff.