A city 311 agent receives one resident message covering trash pickup, a pothole, and a billing dispute. How should the agent handle the multi-concern request?
Select an answer to reveal the explanation.
Short Explanation
One resident message can be three tickets in a trench coat. Split trash, pothole, and billing into parallel lookups, then stitch one clear reply so nothing gets lost in the shuffle.
Full Explanation
Decomposing a multi-concern 311 message into parallel investigations, then synthesizing one resident-facing resolution, matches how civic service desks actually clear mixed tickets without losing items. Trash pickup, pothole repair, and billing disputes touch different systems of record, SLAs, and ownership; treating them as distinct workstreams with shared resident identity lets each lookup complete accurately while the final reply remains coherent for the person who contacted the city.
Answering only the first concern fails because municipal intake must not silently drop secondary issues until a new ticket appears—residents reasonably expect every stated problem to be acknowledged and routed. Forcing a single opaque serial tool call that tries to fix trash, potholes, and billing together fails conceptually because heterogeneous backends and policies cannot be safely collapsed into one undifferentiated action, and failures become un-debuggable. Escalating the entire message to a human without any investigation fails because staff then rebuild context the agent could have gathered, burning desk capacity on work that parallel lookups could finish before handoff.
Exam caveat: parallelism still requires shared identity and conflict checks—two concurrent paths must not post contradictory account updates. Operational check: require the agent to emit a concern inventory (each issue, owning system, status) before reply synthesis, and fail the turn if any listed concern lacks a disposition.