A 311 multi-issue agent looks up trash pickup, then needs a second tool for a related pothole ticket. Why must tool outputs re-enter the same conversation between iterations?
Select an answer to reveal the explanation.
Short Explanation
Each tool result is another clue on the case board. Stick it back into the conversation so Claude can choose the pothole lookup next instead of guessing in the dark.
Full Explanation
When a 311 multi-issue agent looks up trash pickup and then needs a second tool for a related pothole ticket, tool outputs must re-enter the same conversation between iterations so the model can perform progressive reasoning. Each tool result updates what Claude knows; the next tool_use decision—whether to open a pothole ticket, ask a clarifying question, or finish—depends on seeing the prior MCP payload in history.
Re-entry enables progressive reasoning because agentic loops are not independent one-shots. Civic multi-issue contacts often discover linked work from the first lookup, such as address confirmation, district, or open tickets. Without the trash result in context, Claude cannot reliably decide the pothole follow-up or avoid duplicate service requests that frustrate residents and crews.
Routing outputs only so operators can print raw MCP payloads without Claude seeing them fails the agent's reasoning needs. Keeping token counts fixed regardless of tools is not a valid orchestration goal if it requires dropping results. Skipping appends after the first success freezes the agent with partial knowledge and breaks multi-issue resolution across sanitation and street maintenance.
Exam caveat: if history grows large, summarize older turns carefully while retaining facts the next decision needs—do not omit the latest tool_result. Operational check: after trash pickup returns, confirm the subsequent Claude request includes that tool_result and that the next tool_use for the pothole is conditioned on fields from it.