A pro-code team is building an internal employee assistant in Microsoft Foundry. The HR department already maintains a published Copilot Studio agent that answers benefits and leave questions from topics and knowledge that HR makers update every week. The assistant must give the same HR answers, and the developers must not take over HR content. What should the developers do?
Select an answer to reveal the explanation.
Short Explanation
Think of it like a help desk transferring your call to the HR line: you don't hire a second HR team, you just route the caller. The HR agent already exists, is published and is owned by the people who know the content. The trap is rebuilding it in Foundry, which forks the content and hands HR's job to developers.
Full Explanation
Connecting a custom agent to an existing Copilot Studio agent lets each agent stay with the team that owns it. The Foundry agent handles the overall conversation and, when a question falls in the HR domain, calls the published Copilot Studio agent and returns its response, so HR makers keep editing topics and knowledge in Copilot Studio and every change reaches both channels at once. Copying the knowledge files into Foundry and rewriting the topics as instructions creates a second copy of the HR content that drifts as soon as HR publishes its next weekly update, and it moves maintenance onto the developers. Turning HR topics into a cloud flow called for every question discards the agent's conversational logic and still requires someone to rebuild and maintain it outside Copilot Studio. Replacing the HR agent with a Foundry agent forces HR makers into a pro-code tool they do not use, which contradicts the ownership requirement. Exam caveat: the choice between Foundry and Copilot Studio follows who builds and maintains each agent, not which platform is newer. Operational check: confirm the HR agent is published, note its environment and schema name, and test that an HR question routed from the Foundry agent returns the same answer the HR channel gives.