A transit ops agent must observe delayed-bus complaint clusters, decide which analytics tool to call, then refine the diagnosis in discrete steps. How should that reasoning loop be orchestrated on AWS?
Select an answer to reveal the explanation.
Short Explanation
Dispatchers do not solve a delay storm in one psychic flash—they look, think, call a system, look again. Step Functions can host that ReAct loop so each tool call is logged. One blind completion or an infinite laptop loop is not ops-grade orchestration.
Full Explanation
A transit ops agent that must observe delayed-bus complaint clusters, choose analytics tools, and refine diagnosis in discrete steps needs an explicit observe–think–act loop with durable intermediate state. Orchestrating ReAct-style steps with a workflow service such as Step Functions records each tool call, decision, and state transition so operators can audit how the agent reached a diagnosis on AWS. That pattern fits municipal accountability for ops decisions and makes retries and human interruption practical. Issuing one unstructured FM completion with no tool results and accepting the first guess skips observation and tool use the stem requires. Running an infinite unmanaged loop in a laptop notebook until someone kills the process is not production orchestration and lacks governance, logging, or timeouts. Disabling reasoning traces because municipal agents must never call tools contradicts the requirement to call analytics tools and refine diagnosis. Exam caveat: observe–decide–act with tools maps to orchestrated ReAct-style workflows with recorded state—not single-shot guesses or unmanaged notebooks. Operational check: implement Step Functions (or equivalent) states for observe, plan, act, and refine; cap iterations; persist tool I/O; alert on stuck executions; and expose the trace to transit supervisors for after-action review.