An enterprise is designing a Copilot Studio multi-agent solution for an HR department. A front-door agent must handle all incoming employee requests. Requests related to benefits should go to a Benefits agent, requests about payroll should go to a Payroll agent, and requests about leave management should go to a Leave agent. Requests that don't clearly match any category should be handled by the front-door agent itself using generative AI answers from an HR knowledge base. The three specialized agents already exist and are published. Which front-door agent configuration achieves this design?
Select an answer to reveal the explanation.
Short Explanation
The front-door agent with registered agent connections and generative orchestration is like a smart receptionist who reads the room — you don't need a script of every possible question, you understand intent and route accordingly. Register the Benefits, Payroll, and Leave agents as agent connections with clear domain descriptions, then let generative orchestration decide who handles what. Attach the HR knowledge base to the front-door agent so unclear requests get generative answers automatically.
Full Explanation
Copilot Studio's multi-agent architecture supports a hub-and-spoke model where a front-door agent uses generative AI orchestration to dynamically route requests to registered specialized agents. This design leverages the language model's intent understanding rather than static routing rules.
The correct configuration is the one that enables generative AI orchestration on the front-door agent, registers the Benefits, Payroll, and Leave agents as agent connections in the front-door agent's configuration, configures each specialized agent with a clear description of its domain, and attaches the HR knowledge base to the front-door agent for fallback responses. This approach uses all required platform mechanisms together. Enabling generative AI orchestration lets the front-door agent classify incoming messages by semantic intent. Registering the Benefits, Payroll, and Leave agents as agent connections makes them visible to the orchestration layer as routing targets. The description field for each agent connection is critical because the language model uses these descriptions to determine which agent is the best match for a given request. Attaching the HR knowledge base to the front-door agent provides the generative AI fallback capability: when no specialized agent's domain matches the intent, the front-door agent answers using the knowledge base.
The trigger-phrase configuration is incorrect because it creates four separate trigger phrase lists on the front-door agent, one per department, configures topic-level redirects to each specialized agent, and adds a fallback topic with a Power Automate flow that queries the HR knowledge base when no trigger phrase matches. Trigger phrase-based routing cannot handle semantic variations. Employees might ask about 'my PTO balance', 'vacation days remaining', or 'time off allowance', all of which express leave intent, but only a small fraction of actual phrasings would match a fixed trigger phrase list. The Power Automate fallback for knowledge base queries adds unnecessary complexity compared with the native knowledge source attachment in the correct configuration.
The external Azure OpenAI and REST-endpoint configuration is incorrect because it uses Azure OpenAI externally, classifies the incoming message with Azure OpenAI, routes the HTTP request to the appropriate specialized agent's REST endpoint, and returns the response to the front-door agent. This bypasses Copilot Studio's native agent-to-agent connection framework. Specialized agents in Copilot Studio do not expose REST endpoints for direct invocation in the way this approach implies; they are invoked through the platform's agent connection mechanism. This approach would require significant custom development and would lose native context propagation.
The single unified agent configuration is incorrect because it deploys a single unified agent with four separate topic sections for Benefits, Payroll, Leave, and General, shares the HR knowledge base across all topic sections, and uses condition nodes to route between sections based on entity extraction. Collapsing all domain knowledge into a single agent eliminates the architectural benefits of specialized agents: separate security contexts, independent lifecycle management, and specialization-optimized knowledge sources. Condition-node routing based on entity extraction is also a rule-based approach that suffers from the same limitations as trigger phrases when messages do not fit expected entity patterns.
Exam tip: The multi-agent hub-and-spoke pattern requires three setup steps on the front-door agent: enable generative orchestration, register specialized agents as agent connections with descriptive domain descriptions, and attach fallback knowledge sources. The language model uses agent descriptions for routing decisions, so write these descriptions carefully. 'Benefits agent helps with health insurance, dental, vision, 401k, and FSA questions' is better than 'handles benefits.'