A 311 assistant needs to pull live work-order status from the public-works ticketing system. What should the architect choose to connect this proprietary source securely instead of hardcoding sample data into the agent?
Select an answer to reveal the explanation.
Short Explanation
A resident asking about a real work order needs a real, live answer, not a plausible-sounding guess pulled from examples baked into the prompt. A secure, scoped data-source connection queries the actual ticketing system, so the status the agent reports is the status that's true right now.
Full Explanation
A secure, scoped data-source connection lets Gemini Enterprise query the live proprietary ticketing system directly, mediating access so the agent returns real, current work-order status rather than static or approximated information, which matters when residents are checking on an actual open ticket. A system instruction describing typical statuses in plain language only encodes generic patterns, not the live state of any specific work order, so it would mislead residents whose ticket doesn't match the described pattern. A no-match handler that redirects to a phone number sidesteps the integration problem entirely rather than solving it, forcing residents back to a manual channel for something the agent should be able to answer directly. A few-shot prompt template listing sample work orders demonstrates format, not live data, and residents asking about their actual ticket need the real record, not an example that happens to look similar. Scope caveat: the connection's query scope should be limited to what the 311 assistant needs, keeping unrelated internal ticketing fields out of citizen-facing responses. Operational check: open a real test work order in the ticketing system and confirm the agent's reported status matches it exactly.