The mobile team building against the Agent API needs each pet owner's conversation with the agent to maintain continuity across app restarts, and needs the agent's responses to reflect that specific owner's own data access rather than a single shared identity for every request. Which consideration must the integration handle correctly?
Select an answer to reveal the explanation.
Short Explanation
It's like a hospital badge system, not a single shared front-door key: the mobile app has to check each caller in properly so the agent knows exactly whose records it's allowed to pull, and can pick up the same conversation where it left off.
Full Explanation
Integrating with the Agent API means the calling application is responsible for authenticating each caller and passing the correct session and identity context with its requests, so the agent's underlying data access and conversation state correctly reflect that specific pet owner rather than some generic or shared identity. This is what allows both correct per-owner data visibility and continuity of the conversation across app restarts.
'Automatically maps every request to one shared Employee agent identity' is the closest-looking trap because it sounds like a convenient default, but it would collapse every pet owner into the same access context, which is exactly the wrong outcome and not how a properly integrated Agent API caller behaves. 'Session continuity is not supported' overstates a limitation that does not reflect how the integration is meant to work - conversations can and should persist across interactions when the integration manages session context correctly. Requiring the specialty hospital's agent to broker mobile sessions introduces an unrelated third party into what should be a direct relationship between Meridian's mobile app and Meridian's own deployed agent.
Exam takeaway: Agent API integrations own authentication and session management on the calling side; the agent does not conjure per-user identity on its own.