The group is building two separate scheduling assistants: one for front-desk staff to manage the day's appointment board internally, and one for pet owners to request their own appointments. Why should these be two different agents rather than one agent serving both audiences?
Select an answer to reveal the explanation.
Short Explanation
Same subject, scheduling, but two very different jobs: staff need the whole board, owners need their own slot. Give the front desk an Employee agent's staff toolkit and give owners a Service agent's self-service lane, don't hand one agent both sets of keys.
Full Explanation
Even when two use cases share a subject area like scheduling, the audience and the appropriate scope of access differ sharply: front-desk staff plausibly need visibility across the day's board and internal operational tools, which is Employee agent territory, while pet owners should only ever manage their own appointments through a constrained, self-service Service agent experience. Collapsing both into one agent risks either under-serving staff by restricting them to owner-level access, or dangerously over-exposing owner-facing conversations to staff-level visibility across the whole clinic's schedule. The claim that a single agent cannot connect to more than one channel is false and is not the actual reason to split these; an agent can be deployed to multiple channels, but channel count was never the issue here, audience and access scope are. There is no platform limit of one topic per agent; agents commonly host many topics, so topic-count is not why two agents are warranted. Writing to the Appointment object is not restricted to Sales agents; any properly configured action backing, regardless of agent type, can update Appointment records provided the Agent User has the correct permissions. The real driver, worth remembering for the exam, is that audience and security scope, not subject matter, decide whether one agent or two is correct.