A transit authority mobile app shows the agent's next planned tool call as a readable step before booking a paratransit ride. What design principle does that preview primarily support?
Select an answer to reveal the explanation.
Short Explanation
Before the app actually books the ride, it shows its homework—like a dispatcher reading the reservation back to you. That preview is how riders stay in the loop and consent to a real civic action.
Full Explanation
Previewing the agent’s next planned tool call as a readable step before booking a paratransit ride primarily supports informed consent: riders can review the intended booking action—time, pickup, destination, eligibility assumptions—before the booking tool executes. In civic mobility apps, that human-readable intent translation turns opaque agent tooling into an accountable decision the rider can approve or cancel.
Faster silent automation by removing rider review fails because it inverts the design goal; speed without consent is not the principle the preview implements. Mandatory encryption of every UI string fails by concept: encryption protects confidentiality in transit or at rest, but it does not create a consent gate for tool execution. Replacing booking APIs with free-form on-device chat logs fails because durable bookings require authoritative backend APIs and records, not local conversational residue.
Exam caveat: exam items often pair “show the planned tool call” with consent or transparency. Do not answer with adjacent-sounding security or storage tactics unless the stem asks for them.
Operational check: book a test paratransit trip in a lower environment, pause on the planned-tool preview, verify fields match the rider’s request, cancel once to ensure no reservation is created, then confirm once and verify the booking API creates a single ride with matching details.