ReWOO's Call Arithmetic, and What Its Work Phase Does With an Ambiguous Lookup

A "company due-diligence brief" feature takes a company name and produces a one-page brief. Tools: lookup_id(name), fetch_filing(id), news(id), search(query), and compute_ratios(filing). The ReAct prototype averages 7 tool calls and 8 LLM calls per brief, at roughly 30s. The team rewrites it as ReWOO; a typical plan reads:

#E1 = lookup_id(name)
#E2 = fetch_filing(#E1)
#E3 = news(#E1)
#E4 = search(name + " lawsuits")
#E5 = compute_ratios(#E2)

1. Count the LLM calls per brief under ReWOO, then use the plan's dependency structure to work out how many sequential tool round-trips sit on the critical path, and explain why the latency gain is larger than the LLM-call reduction alone predicts.
2. On one run, lookup_id returns two candidate IDs for an ambiguous name. Trace exactly what happens in the Work and Solve phases, and explain why the outcome differs from the ReAct prototype on the same input.
3. A colleague proposes "add an LLM check after every Work step that re-plans if the result looks off." Explain what that change does to the pattern's cost and identity, and propose a cheaper alternative that preserves most of ReWOO's advantage.