A sanitation supervisor needs a one-off answer about today's route delays but also wants a reusable helper that always knows the route SOP library. How should those needs map to Copilot experiences?
Select an answer to reveal the explanation.
Short Explanation
For today's route-delay question, you can tap Copilot chat like a coworker for a quick, situational answer. For a reusable helper grounded in the route SOP library, choose a configured agent with standing instructions for repeat use across shifts.
Full Explanation
Different municipal needs map to different Copilot experiences. A one-off question about today's route delays fits ad-hoc Copilot chat: it is timely and situational, so it does not call for a permanent experience. A reusable helper that knows the route SOP library fits a configured agent, which can use standing instructions and persistent knowledge grounding for repeat use across shifts. Training and publishing a custom foundation model for the sanitation fleet is unnecessary for these routine needs; Copilot fundamentals do not require a new model. The claim that only blank chat remembers SOPs permanently, while agents forget instructions every hour, reverses the model: agents are reusable, instruction-bearing experiences. The claim that agents cannot reference knowledge libraries and that only email macros can store SOPs is also wrong; grounding an agent in a knowledge library is a core use case. Exam caveat: Do not turn every delay question into an agent or keep pasting the full SOP library into fresh chats for standing guidance. Match how persistent the need is to how persistent the experience should be. Practical check: Use chat with current dispatch notes for today's delay; use an agent grounded in the approved route SOP library for recurring how-to questions, and keep that library permissioned and version-controlled so the agent stays accurate.